Simplifying multi-layer network
management with RINA
Eduard Grasa, Fundació i2CAT, FP7 PRISTINE
TNC 2016, Prague, June 13th 2016
Simplifying Multi-layer Network Management with RINA
Automating network management …
Network Management System
Layers state
models
Reason about
events
Desired
network state
Updated
network
state
Compare with
desired state
Layers config
models
Network
state drift
Reason about
config changes
Apply
updated
config
Events
Complexity of management models key metric to evaluate the
limitations/possibilities on network automation (and its cost)
Computer network being managed
2
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
–11 The “IP protocol suite” had been designed with generality in
2
mind, allowing its protocols to adapt to specific network
environments
–24 The “IP protocol suite” is well know for having no scalability,
performance or security issues
Simplifying multi-layer network management with RINA
3
There is a better approach: RINA
•1 Network architecture resulting from a fundamental theory of
computer networking
•2 Networking is InterProcess Communication (IPC) and only IPC.
Unifies networking and distributed computing: the network is a
distributed application that provides IPC
•3 There is a single type of layer with programmable functions, that
repeats as many times as needed by the network designers
•4 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)
•5 There are only 3 types of systems: hosts, interior and border routers.
No middleboxes (firewalls, NATs, etc) are needed
•6 Deploy it over, under and next to current networking technologies
Simplifying multi-layer network management with RINA
4
RINA macro-structure (layers)
Single type of layer, consistent API, programmable policies
IPC API
Data Transfer
Layer Management
Data Transfer Control
CACEP
SDU Delimiting
Relaying and
Multiplexing
State Vector
State Vector
State Vector
DataTransfer
Transfer
Data
Data
Transfer
Retransmission
Retransmission
Retransmission
Control
Control
Control
RIB
Daemon
Flow Allocation
Authentication
Resource Allocation
CDAP
Parser/Generator
Flow Control
Flow Control
Flow Control
RIB
Namespace
Management
SDU Protection
Routing
Enrollment
Security
Management
Increasing timescale (functions performed less often) and complexity
App
B
App
A
DIF (Distributed IPC Facility)
DIF
DIF
DIF
Host
Consistent
API through
layers
Host
DIF
DIF
Border router
Interior Router
Border router
“IP protocol suite” macro-structure
(Theory)
(Practice)
• 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.)
Simplifying multi-layer network management with RINA
6
Network management
Commonality is the key to effective network management
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
• 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
Simplifying multi-layer network management with RINA
7
Separation of mechanism from policy
IPC API
Data Transfer
Layer Management
Data Transfer Control
CACEP
SDU Delimiting
Relaying and
Multiplexing
SDU Protection
•
State Vector
State Vector
State Vector
DataTransfer
Transfer
Data
Data
Transfer
Retransmission
Retransmission
Retransmission
Control
Control
Control
RIB
Daemon
Authentication
Resource Allocation
CDAP
Parser/Generator
Flow Control
Flow Control
Flow Control
RIB
Flow Allocation
Routing
Enrollment
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
8
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
IP-based DCN design
(With minimal number of protocols)
TCP or UDP or SCTP, … (transport layer)
IPv4 or IPv6 (tenant overlay)
802.3
VXLAN
802.1Q
VM
802.3
802.1Q
VM
UDP
Server
Server
IPv4 or IPv6 (Fabric layer)
Protocol conversion,
Local bridging
ToR
Fabric
Ethernet
Ethernet
Ethernet
Ethernet
Spine
ToR
Fabric
• Data plane (up), control plane (down). L3-only fabric
eBGP
TCP
TCP
eBGP
eBGP
eBGP
eBGP
TCP
TCP
TCP
TCP
IPv4 or IPv6 (Fabric layer)
LACP
ToR
Ethernet
Ethernet
Ethernet
Ethernet
Server
eBGP
Fabric
Spine
LACP
Ethernet
Ethernet
Fabric
ToR
Server
10
RINA-based DCN design
Tenant DIF
PtP DIF
VM
PtP DIF
PtP DIF
DC Fabric DIF
Server
PtP DIF
ToR
PtP DIF
PtP DIF
Fabric
Spine
Fabric
Server
PtP DIF
PtP DIF
VM
ToR
• Overall design (up), Fabric addressing plan (down)
Simplifying multi-layer network management with RINA
11
Models for the DCN fabric: IP vs RINA
Assumption (for IP): all nodes NETCONF/YANG capable
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, yangip, yang-routing , yang-bgp
daf-common-mom, dif-common-mom,
dif-default-policies
Simplifying multi-layer network management with RINA
12
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
Models for the tenant layers: IP vs RINA (I)
Assumption (for IP): all nodes NETCONF/YANG capable
Concept
IP
RINA
Port-ids to N-1 flows, just need port-id
(locally –device- unique identifier)
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
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 (loadbalancing/redundancy at server level)
Scheduling strategy
FIFO (needs max-queue size)
FIFO (needs max-queue size)
Simplifying multi-layer network management with RINA
14
Models for the tenant layers: IP vs RINA (II)
Assumption (for IP): all nodes NETCONF/YANG capable
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, yangip, 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)
Simplifying multi-layer network management with RINA
15
NMS-DAF: Manager design
Manager
Messaging: W3C Websockets
CDAP
CDAP
Connect
CDAP
Agent Connection: CDAP connector
Mgmt
Agent
(MA)
API Calls, etc.
Managed
Resource
(RINA
System)
Mgmt
Agent
(MA)
API Calls, etc.
Managed
Resource
(RINA
System)
Mgmt
Agent
(MA)
API Calls, etc.
Managed
Resource
(RINA
System)
CDAP
Messaging
System
Manager
Manager
App
Manager
App
App
Mgmt
Mgmt
Shell
/
Mgmt
Shell
/
GUI
Shell /
GUI
GUI
Other
Other
Apps
Other
Apps
Apps
NMS-DAF
• Event-source, distributed and modular design, layered design,
distributed configuration management, Java 8
Simplifying multi-layer network management with RINA
16
Demo: multi-tenant capable DCN (I)
Demo: multi-tenant capable DCN (II)
VPN1.DIF
Shim Eth
Fabric.DIF
DCAccess.DIF
IEEE 802.1q
M6
(Server 5)
Shim Eth
Shim Eth
Shim TCP UDP
IEEE 802.1q
IEEE 802.1q
TCP or UDP
M8
(Leaf 1)
IPv4 (public Internet)
M11
(Spine 2)
IEEE 802.3
IEEE 802.3
M12
(Border 1)
Client 1
VPN 1
VPN3.DIF
Shim Eth
Shim Eth
Fabric.DIF
IEEE 802.1q
IEEE 802.1q
M7
(Server 6)
Shim Eth
Shim Eth
IEEE 802.1q
IEEE 802.1q
M8
M11
M9
(Leaf 1)
(Spine 2)
(Leaf 2)
Simplifying multi-layer network management with RINA
M2
(Server 1)
18
Research, open source, standards
• Current research projects
1
–
2
–
3
–
–
4
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
–1 IRATI (Linux OS, C/C++, kernel components, policy framework, RINA
over X) http://github.com/irati/stack
–2 RINASim (RINA simulator, OMNeT++)
–3 ProtoRINA (Java, RINA over UDP, quick prototyping)
• Key RINA standardization activities
–
1 Pouzin Society (experimental specs) http://pouzinsociety.org
–
2 ISO SC6 WG7 (2 new projects: Future Network – Architectures, Future
Network- Protocols)
3 ETSI Next Generation Protocols ISG
–
Simplifying multi-layer network management with RINA
19