SImplifying multi-layer network management

1. Simplifying Multi-layer Network Management with RINA
Simplifying multi-layer network
management with RINA
Eduard Grasa, Fundació i2CAT, FP7 PRISTINE
TNC 2016, Prague, June 13th 2016

2. Computer network being managed
Events
Reason about
events
Layers state
models
Compare with
desired state
Updated
network
state
Desired
network state
Reason about
config changes
Network
state drift
Layers config
models
Apply
updated
config
Network Management System
2
Automating network management …
Complexity of management models key metric to evaluate the
limitations/possibilities on network automation (and its cost)

3. Are “All IP networks” easy to automate?
• Computer networking & telecom industry has been steadily
moving towards an “all IP” world.
– Is “all-IP convergence” a simple, scalable, robust, manageable,
performing and future-proof solution for all types of computer
networks?
• Could be if
– The “IP protocol suite” had been designed with generality in mind,
allowing its protocols to adapt to specific network environments
– The “IP protocol suite” is well know for having no scalability,
performance or security issues
Simplifying multi-layer network management with RINA 3
1
2
1
42

4. There is a better approach: RINA
• Network architecture resulting from a fundamental theory of computer
networking
• Networking is InterProcess Communication (IPC) and only IPC. Unifies
networking and distributed computing: the network is a distributed
application that provides IPC
• There is a single type of layer with programmable functions, that repeats
as many times as needed by the network designers
• All layers provide the same service: instances or communication (flows) to
two or more application instances, with certain characteristics (delay, loss,
in-order-delivery, etc)
• There are only 3 types of systems: hosts, interior and border routers. No
middleboxes (firewalls, NATs, etc) are needed
• Deploy it over, under and next to current networking technologies
4
1
2
3
4
5
6
Simplifying multi-layer network management with RINA

5. RINA macro-structure (layers)
Single type of layer, consistent API, programmable policies
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
DIF (Distributed IPC Facility)
Host
App
A
App
B
Consistent
API through
layers
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Retransmission
Control
Flow Control
RIB
Daemon
RIB
CDAP
Parser/Generator
CACEP
Enrollment
Flow Allocation
Resource Allocation
Routing
Authentication
StateVector
StateVector
StateVector
Data TransferData Transfer
Retransmission
Control
Retransmission
Control
Flow Control
Flow Control
Increasing timescale (functions performed less often) and complexity
Namespace
Management
Security
Management

6. “IP protocol suite” macro-structure
• Functional layers organized for modularity, each layer provides
a different service to each other
– As the RM is applied to the real world, it proofs to be incomplete.
As a consequence, new layers are patched into the reference
model as needed (layers 2.5, VLANs, VPNs, virtual network
overlays, tunnels, MAC-in-MAC, etc.)
6
(Theory) (Practice)
Simplifying multi-layer network management with RINA

7. Network management
Commonality is the key to effective network management
7
• Commonality and consistency in RINA greatly simplifies management
models, opening the door to increased automation in multi-layer
networks
– Reduce opex, network downtime, speed-up network service delivery, reduce
components that need to be standardised
From managing a set of layers, each with its
own protocols, concepts and definitions …
… to managing a common, repeating structure
of two protocols and different policies
Simplifying multi-layer network management with RINA

8. Separation of mechanism from policy
8
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Retransmission
Control
Flow Control
RIB
Daemon
RIB
CDAP
Parser/Generator
CACEP
Enrollment
Flow Allocation
Resource Allocation
Routing
Authentication
StateVector
StateVector
StateVector
Data TransferData Transfer
Retransmission
Control
Retransmission
Control
Flow Control
Flow Control
Namespace
Management
Security
Management
• All layers have the same mechanisms and 2 protocols (EFCP for data
transfer, CDAP for layer management), programmable via policies.
– All data transfer and layer management functions are programmable!
• Don’t specify/implement protocols, only policies
– Re-use common layer structure, re-use policies across layers
• This approach greatly simplifies the network structure, minimizing the
management overhead and the cost of supporting new requirements, new
physical media or new applications

9. Case study: Large-scale DC Network
• Large-scale DCN connects around 100k servers, how to realize
and manage the DCN with RINA and IP?
Simplifying multi-layer network management with RINA
9

10. IP-based DCN design
(With minimal number of protocols)
• Data plane (up), control plane (down). L3-only fabric
10
ToR ToRFabric Spine Fabric
Server ServerIPv4 or IPv6 (Fabric layer)
UDPVM VM
Ethernet Ethernet Ethernet Ethernet
VXLAN802.1Q802.3 802.1Q
IPv4 or IPv6 (tenant overlay)
TCP or UDP or SCTP, … (transport layer)
802.3
Protocol conversion,
Local bridging
ToR ToRFabric Spine FabricServer
Server
IPv4 or IPv6 (Fabric layer)
TCP
Ethernet Ethernet Ethernet Ethernet
LACP
Ethernet
LACP
Ethernet
TCP
eBGP eBGP
TCP TCP
eBGP eBGP
TCP
eBGP
TCP
eBGP

11. RINA-based DCN design
• Overall design (up), Fabric addressing plan (down)
Simplifying multi-layer network management with RINA 11
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF
DC Fabric DIF
Tenant DIF
ToR ToR
VM Server Server VM
FabricFabric Spine

12. Models for the DCN fabric: IP vs RINA
Assumption (for IP): all nodes NETCONF/YANG capable
Simplifying multi-layer network management with RINA 12
Concept IP RINA
Interfaces
IPv4 interfaces, need IP address (one per
interface), unique in the layer.
Port-ids to N-1 flows, just need port-id
(locally –device- unique identifier)
Data Transfer protocol
syntax
IPv4 syntax, TCP syntax (TCP is used by the
control plane)
EFCP (length of fields). Need address
(one per device in the layer), unique in
the layer
Forwarding entity Router, one per device in the layer, has FIB
entries (forwarding table)
Relaying and Multiplexing Task (RMT),
one per device in the layer, has
forwarding table entries.
Forwarding strategy Longest prefix matching, ECMP Longest prefix matching, ECMP
Scheduling strategy FIFO (needs max-queue size) FIFO (needs max-queue size)
Routing protocol BGP with different routing policies. Needs
AS numbers, router-id (IP address),
neighbours’ IP addresses and AS numbers.
CDAP with link-state routing policy and
topological addressing
Directory protocol - CDAP with centralized directory policy.
Mgmt protocol NETCONF CDAP
Mgmt models yang-common-types, yang-interfaces, yang-
ip, yang-routing , yang-bgp
daf-common-mom, dif-common-mom,
dif-default-policies

13. Configuration overhead: # of addresses in
the DCN fabric
• IP. 2*number of interfaces in the DCN fabric (MAC @, IP @)
• RINA. 1*number of devices in the DCN fabric (IPCP @)
Simplifying multi-layer network management with RINA 13

14. Models for the tenant layers: IP vs RINA (I)
Assumption (for IP): all nodes NETCONF/YANG capable
Simplifying multi-layer network management with RINA 14
Concept IP RINA
Interfaces
Ethernet interfaces: need MAC address
(one per interface)
802.1q interfaces: need VLAN-id
VTEP interfaces: need VXLAN-id, local IP
address and UDP port, remote IP address
and UDP port
IPv4 interfaces: need IP address (one per
interface), unique in tenant overlay
Port-ids to N-1 flows, just need port-id
(locally –device- unique identifier)
Data Transfer protocol
syntax
IEEE 802.3 (Ethernet), IEEE 802.1q, IPv4,
UDP, VXLAN, TCP
EFCP (length of fields). Need address
(one per device in the layer), unique in
the layer
Forwarding entity router: one per VM
Ethernet bridge: one per server per tenant
overlay
E-VRF: one per ToR per tenant overlay
Relaying and Multiplexing Task (RMT),
one per device in the layer, has
forwarding table entries.
Forwarding strategy Exact (MAC) address matching Longest prefix matching, ECMP (load-
balancing/redundancy at server level)
Scheduling strategy FIFO (needs max-queue size) FIFO (needs max-queue size)

15. Models for the tenant layers: IP vs RINA (II)
Assumption (for IP): all nodes NETCONF/YANG capable
Simplifying multi-layer network management with RINA 15
Concept IP RINA
Routing protocol BGP with multi-protocol extensions. Needs
route distinguisher and VPN targets
CDAP with link-state routing policy and
topological addressing
Directory protocol DNS (resolve domain names of apps
executing in the tenant DIF to IP @s)
CDAP with distributed directory policy.
Maintains Directory Forwarding Table
Redundancy protocol Link Aggregation Control Protocol – needs
local Ethernet interface addresses
-
Mgmt protocol NETCONF CDAP
Mgmt models yang-common-types, yang-interfaces, yang-
ip, yang-bridging, yang-routing, yang-bgp,
yang-vxlan, yang-evpn, yang-lacp
daf-common-mom, dif-common-mom,
dif-default-policies
Concept # (IP) # (RINA)
Interface types 4 1
DT protocol syntaxes 5 1 (2 different field lengths)
Types of forwarding entities 3 1
Layer mgmt/control plane protocols 3 1 (with 4 policies)

16. NMS-DAF: Manager design
Simplifying multi-layer network management with RINA 16
Manager
Mgmt
Agent
(MA)
CDAP
Connect
Managed
Resource
(RINA
System)
API Calls, etc.
CDAP
Manager
App
Manager
App
Manager
App
Messaging
System
Mgmt
Shell /
GUI
Mgmt
Shell /
GUI
Mgmt
Shell /
GUI Other
Apps
Other
Apps
Other
Apps
Mgmt
Agent
(MA)
Managed
Resource
(RINA
System)
API Calls, etc.
Mgmt
Agent
(MA)
Managed
Resource
(RINA
System)
API Calls, etc.
CDAP
CDAP
NMS-DAF
• Event-source, distributed and modular design, layered design,
distributed configuration management, Java 8
Messaging: W3C Websockets
Agent Connection: CDAP connector

17. Demo: multi-tenant capable DCN (I)

18. Demo: multi-tenant capable DCN (II)
Simplifying multi-layer network management with RINA 18
M6
(Server 5)
Fabric.DIF
M11
(Spine 2)
M12
(Border 1)
M8
(Leaf 1)
Shim Eth
DCAccess.DIF
Client 1
VPN 1
Shim TCP UDP
VPN1.DIF
TCP or UDP
IPv4 (public Internet)
IEEE 802.3 IEEE 802.3
IEEE 802.1q
Shim Eth
IEEE 802.1q
Shim Eth
IEEE 802.1q
M7
(Server 6)
Fabric.DIF
M11
(Spine 2)
M9
(Leaf 2)
M8
(Leaf 1)
Shim Eth
VPN3.DIF
IEEE 802.1q
Shim Eth
IEEE 802.1q
Shim Eth
IEEE 802.1q
Shim Eth
IEEE 802.1q
M2
(Server 1)

19. Research, open source, standards
19
• Current research projects
– FP7 PRISTINE (2014-2016) http://ict-pristine-eu
– H2020 ARCFIRE (2016-2017) http://ict-arcfire.eu
– Norwegian project OCARINA(2016-2021)
– BU RINA team http://csr.bu.edu/rina
• Open source implementations
– IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over
X) http://github.com/irati/stack
– RINASim (RINA simulator, OMNeT++)
– ProtoRINA (Java, RINA over UDP, quick prototyping)
• Key RINA standardization activities
– Pouzin Society (experimental specs) http://pouzinsociety.org
– ISO SC6 WG7 (2 new projects: Future Network – Architectures, Future
Network- Protocols)
– ETSI Next Generation Protocols ISG
1
2
3
4
1
2
3
1
2
3
Simplifying multi-layer network management with RINA