Pristine rina-tnc-2016

Simplifying Multi-layer Network Management with RINA

Simplifying multi-layer network management with RINA

Eduard Grasa, Fundació i2CAT, FP7 PRISTINETNC 2016, Prague, June 13th 2016

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)

Simplifying multi-layer network management with RINA 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

121

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

1

2

3

4

5

6


RINA macro-structure (layers)Single type of layer, consistent API, programmable policies

Host

Border router Interior Router

DIF

DIF DIF

Border router

DIFDIF

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

State VectorState VectorState Vector

Data Transfer Data Transfer



Flow ControlFlow 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.)

(Theory) (Practice)


7

Network managementCommonality is the key to effective network management

• 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


8

Separation of mechanism from policyIPC API

Data Transfer Data Transfer Control Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection


Flow Control

RIB Daemon

RIB

CDAP Parser/Generator

CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State VectorState VectorState Vector

Data Transfer Data Transfer



Flow ControlFlow 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?


10

IP-based DCN design(With minimal number of protocols)

• Data plane (up), control plane (down). L3-only fabricToR 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 FabricServerServer

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


RINA-based DCN design

• Overall design (up), Fabric addressing plan (down)

PtP DIF PtP DIF PtP DIF PtP DIF

PtP DIF PtP DIFPtP DIFPtP DIFDC Fabric DIF

Tenant DIF

ToR ToR

VM Server Server VM

FabricFabric Spine


Models for the DCN fabric: IP vs RINAAssumption (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, yang-ip, yang-routing , yang-bgp

daf-common-mom, dif-common-mom, dif-default-policies


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 @)


Models for the tenant layers: IP vs RINA (I)Assumption (for IP): all nodes NETCONF/YANG capable

Concept IP RINA

Interfaces

Ethernet interfaces: need MAC address (one per interface)

802.1q interfaces: need VLAN-idVTEP interfaces: need VXLAN-id, local IP address and UDP port, remote IP address

and UDP portIPv4 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)


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, 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)


NMS-DAF: Manager designManager

MgmtAgent(MA)

CDAPConnect

ManagedResource

(RINA System)

API Calls, etc.CDAP

ManagerApp

ManagerApp

ManagerApp

MessagingSystem

MgmtShell /

GUI

MgmtShell /

GUI

MgmtShell /

GUI OtherApps

OtherApps

OtherApps

MgmtAgent(MA)

ManagedResource

(RINA System)

API Calls, etc.

MgmtAgent(MA)

ManagedResource

(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

Demo: multi-tenant capable DCN (I)


Demo: multi-tenant capable DCN (II)

M6 (Server 5)

Fabric.DIF

M11(Spine 2)

M12(Border 1)

M8 (Leaf 1)

Shim Eth

DCAccess.DIF

Client 1VPN 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• 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


http://ict-pristine-eu/

http://ict-arcfire.eu/

http://csr.bu.edu/rina

http://github.com/irati/stack

http://pouzinsociety.org/