February 7th 2017
RINA Introduction
Eduard Grasa

Together we’ll try to make sense of ...
• What (computer) network architecture is
What is the current one
• What are its main flaws
• How to construct a better architecture
1
2
3
4
2

WHAT IS A NETWORK
ARCHITECTURE?
1
3

What is architecture?
• “The style of design and method of construction of
buildings and other physical structures”
• Architecture provides a set of patterns and methodology
that guides building designers in carrying out their task
• The same architecture is used to design many different
buildings with different requirements
– Architecture captures the rules and patterns that are invariant with
respect to the specific requirements of each building
4

Elements of the gothic architecture
Grand, Tall Designs, Which Swept
Upwards With Height and Grace
These flying buttresses are a
feature of gothic architecture. The Pointed Arch
The Vaulted Ceiling
Light, Airy Interiors
The Emphasis Upon the Decorative Style and the Ornate
5

Buildings of gothic architecture
City Hall
Palace
Cathedral Fish market
City gates 6

Elements of the modernist architecture
The catalan vault Use of iron Use of bricks
Assymetric forms Curvy lines Nature as source of inspiration7

Buildings of modernist architecture
Houses Hotels Cathedrals
Parks
Music Halls
8

What is architecture?
• Architecture provides a set of patterns and methodology
that guides building designers in carrying out their task
• Architecture captures the rules and patterns that are
invariant with respect to the specific requirements of
each building
9

What is computer networking?
• Who are the “users” of networking services?
– (or what are the “endpoints” of communication”)
• What service is networking providing?
– Imperfect remote data replication a.k.a communication
services
Applications!
Ok, if you really want to be
precise about it : instances of
OS processes or equivalents
Perfect would mean 0 packet
loss, 0 delay, ∞ capacity
Network are just large data
copying machines
10

So, computer networks are …
• Computer networking is Inter Process Communication (IPC)
– Robert Metcalfe, inventor of Ethernet, 1972
Machine 1 Machine 2
“The network”
A distributed, imperfect machine that copies data between
instances of applications, introducing loss and delay in the process
App
A
App
B
“I believe it is natural to think of resources as being
associated with processes and available only through
communication with these processes. Therefore, I
view the fundamental problem of resource sharing to
be the problem of interprocess communication. I
also share with Carr, Crocker, and Cerf the view that
interprocess communication over a network is a
subcase of general interprocess communication in a
multi-programmed environment”
D.C. Walden, ARPANET design team, 1970 (RFC 62)
End-to-end protocols (often called "Host-
Host" protocols) are installed on top of the
packet switching service to provide users
with an interprocess communication
facility
Cerf, Zimmerman, McKenzie (INWG), 1976
Thus, all communication is viewed as
interprocess communication
DARPA, RFC 793 (TCP spec), 1981
11

Conclusions on network architecture
• Network architecture provides a set of patterns and
methodology that guides network (protocol) designers
in carrying out their task
• Network architecture captures the rules and patterns that
are invariant with respect to the specific requirements of
each individual network
– General rules and patterns to provide distributed IPC services to
any application over any physical media
Cellular networks Wireless networks Datacentre networks
ISP networks
12

WHAT IS THE CURRENT NETWORK
ARCHITECTURE?
2
13

WHAT ARE THE MAIN FLAWS3
14

Structure (layering)
• Current networks loosely based on the OSI reference
model
Application
Presentation
Session
Transport
Network
Physical
OSI (Initial)
Data Link
Application
Transport
Network
LLC
Physical
OSI (Final)
SubNet Indep. C.
SubNet Dep. C.
SubNet Access
Data Link
MAC
Application
Transport
LLC
Physical
Internet (theory)
MAC
Internet
Data Link
and others
and others
For cellular
networks
In textbooks
(and was wrong)
Ignored
(Supports Internets)
Current one
(In reality a network model)
15

The “Internet” is not an Internet..
• Internet (theoretical model)
• OSI model
Host Router Router Border
Router
Router Router HostBorder
Router
Physical Physical Physical Physical Physical Physical Physical
LLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MAC
Internet
Transport
Network 1 Network 2
Host Router Router Border
Router
Router Router HostBorder
Router
Physical Physical Physical Physical Physical Physical Physical
LLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MACLLC/MAC
Transport
Network 1 Network 2
SNAC
SNDC
SNAC
SNDC
SNIC
Application
Application
16

Layering: problems (I)
• Internet architecture does not have room for different
network protocols (there is a common Internet layer
directly over data link layers)
• If a network wants to do its own non-IP forwarding, or do
IP forwarding but hide internal routers from the Internet,
ad-hoc extensions are required:
– “Layers 2.5” -> MPLS
– Tunnelling protocols -> e.g. GTP for mobile networks, IP-in-IP
tunnelling protocols, MAC-in-MAC, etc.. (every SDO designing its
ad-hoc solution(s) for its problem domain, independently)
• Note that this was already covered in the OSI
architecture by SNDC and SNAC
17

Layering: problems (II)
• Fixed number of layers, sometimes more needed
between transport and application
– Need concepts like “overlay”, “VPN”, “virtual networks”, ..
• Although the need for scope is clear (link, network,
Internet, VPN …) layers are organised as units of
modularity, with each layer providing a different function
to each other
(Theory)
(Practice)
18

Layers and protocols
• Each layer provides a different
function to each other
– Multiple protocols within the same
layer
• Protocols are usually
– Independently designed from
each other (little commonality) in
different SDOs, even within the
same SDO
– Almost each new use case
requires a new protocol
19
• Flaws in the architecture (e.g. multi-homing, mobility) require
special protocols

Result: protocol proliferation!
20

Is there any structure?
21
• Each layer performs a number of distributed functions
coordinated via network protocols, which can be
categorised:
– Data transfer (or data plane) functions. The functions that are
associated to every single packet (PDU), such as multiplexing,
scheduling, forwarding, addressing, concatenation, fragmentation,
sequencing, encryption, etc..
– Data transfer control (or also data plane) functions. Feedback
functions that are loosely associated to the data transfer ones,
such as flow control, congestion control or retransmission control.
– Layer management (or control plane) functions. Functions to
manage the functioning of a layer, not directly associated to the
data of the layer users, such as: authentication, access control,
routing, resource allocation, security management.

Complexity is your enemy
• Complexity makes all other network problems worst
(security, management, etc), makes networks hard (and
expensive!) to manage and less reliable.
22

Naming and addressing
• Domain names are mapped to IP addresses by DNS
• IP addresses are assigned to interfaces
• MAC addresses are assigned to interfaces
• Transport layers and below know nothing about domain names 23
 http://www.i2cat.net
Synonym of an
interface of a
host
Port number
(Endpoint of
TCP connection)
:80
App App
App name = domain
name + port number
IP address
MAC address
IP address
MAC address
Internet layer routes
on IP addresses

Issues: multi-homing
24
AppApp
1.1.1.1
1.2.1.1
2.1.1.1
The network doesn’t know that 1.1.1.1 and 1.2.1.1 actually go to the
same place. If one of the two interfaces crashes, packets can’t be re-
routed to the other one
• A number of special protocols designed to partially deal with it: SHIM6,
Multipath TCP, BGP (multi-homing at the AS level), SCTP
AppApp
1.1.1.1
2.1.1.1
Solution is trivial: assign addresses to the
“node”, not interfaces. Route on node addresses

Issues: mobility (II)
• Seamless (application does not notice it) mobility is
complicated due to incomplete naming&addressing:
– Applications need an identifier that is stable when their host
moves across networks
– To make routing scale the network addresses need to change as
the host attaches to different networks
• But in the Internet (layer) there is only one identifier: the
IP address
– Special protocols to try to make it work: Mobile IP(v4/v6), Proxy
Mobile IP (v4/v6), GTP for cellular (create a huge layer 2 subnet),
LISP
– Most of them require tunnels (expensive to setup), all have
limitations at the scale they can provide seamless mobility
25

Application API
• Applications must know about transport protocol and choose it
• Addresses exposed to applications (security problem)
• No way to request QoS parameters (loss, delay, etc..)
• Barrier to adoption of new protocols (IETF TAPS tries to address this)
26
Host
Transport
Host
App
A
App
B
Application
A
Sockets API
OS Sockets
Layer
1. Bind/Listen to interface and port
2. Accept incoming connections
3. Connect to a remote address/port
4. Send datagram
5. Write data (bytes) to socket
6. Read data (bytes) from socket
7. Destroy socket
Internet

Summing up
• Current network architecture has a flawed …
– Structure
– Protocol design
– Naming and addressing scheme
– Service model / Application API
– And we didn’t touch security
– or network management
• But enough complaining!
27

HOW TO CONSTRUCT A BETTER
NETWORK ARCHITECTURE
4
28

So.. What do we want?
• As much invariants as possible in the architecture, so that
we can minimize the number of protocols and maximize
their commonality
29
Architecture:
patterns, invariants, building
blocks, methods
Protocols
Today:
• Architecture has too little
patterns/commonality, and
they are a bit broken
• Too many protocols, too little
commonality
Architecture:
patterns, invariants, building
blocks, methods
What we want:
• Architecture provides as
much invariants as possible
• Few protocols, sharing lots of
commonalityProtocols

Application API: IPC services
• Application names are location independent (the network locates the
apps); addresses internal to the network
• Application provides service requirements for their flows (loss, delay,
etc.), the network chooses the right protocols to provide them
30
Host Host
App
A
App
B
App A
IPC API
OS
IPC
1. Register/Unregister App
2. Allocate/Deallocate flows
3. Write data (SDUs) to flows
4. Read data (SDUs) from flows
The network locates the destination application
(directory), and configures protocols for each flow
“The network” provides communication flows

What is the nework?
• Provides IPC services, but what is it? Some hints:
– Executes in computers running operating systems (PCs, laptops,
routers, sensors, smartphones, tables, switches, etc.)
– Has instances distributed through many machines, exchanging
information and collaborating
– Just like… the web, Skype, email, etc.
• Therefore the network is just a distributed application
specialised to provide IPC
– We’ll call this application a DIF (Distributed IPC Facility)
31
Host
DIF
Host
App
A
App
B
RouterRouter

Structure: layering (I)
• But a single DIF for all applications and all machines in the
world/universe is not very scalable ...
– We need to isolate scopes (link, network, Internet, VPN, etc.)
• Multiple DIFs, providing IPC services to each other!
– After all a DIF is just a distributed application, right?
32
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
DIF
Host
App
A
App
B
Consistent
API through
layers

Layering, a better pattern (II)
• Single type of layer, providing an IPC Service that repeats
as many times as needed by the network designer
• A layer is a resource allocator that provides an manages
the IPC service over a given scope (link, network, Internet,
VPN, etc.). A layer allocates resources (memory in buffers,
scheduling capacity, bandwidth) to competing flows.
Host Router Router Border
Router
Router Router HostBorder
Router
Network 2
SNAC
SNDC
SNIC
Application
DIF DIF DIF DIF DIF DIFDIF
DIF DIF
DIF
33

Let’s go to our to-do list
• We have fixed
– Structure
– Protocol design
– Naming and addressing scheme
– Service model / Application API
– Security
– Network management
• Still work to do, let’s move on!
34

What protocols inside a DIF?
• A DIF is a distributed application, how can we organise its
functions?
– Remember: data transfer, data transfer control, layer
management
• But we want to limit the variability in protocols to the
minimum: apply separation of mechanism and policy
– Mechanism are the parts in a protocol that are fixed (e.g. an
acknowledgement ACK)
– Policy is the part of the protocol that can change (e.g. when to
send an ACK is policy)
• Each DIF has different requirements, so we cannot have
the same protocols in all of them, but can we abstract
invariances so that we end up with:
– 1 protocol (framework) for data transfer?
– 1 protocol (framework) for layer management? 35

EFCP: Error and Flow Control Protocol
• By separating data transfer protocol elements between
mechanism (invariant) and policy (variant), it is possible to
specify a data transfer protocol framework from which multiple
data transfer protocols can be generated by
– Choosing a concrete syntax (length of header fields)
– Plugging in the right policies (for flow control, retx. control,
congestion contol) 36
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
EFCP
App A
IPC API
IPC
Process

Unified layer management
37
Resource Information Base (RIB): Schema that defines the external representation of the set of
objects that model the state of the IPCP (object names, attributes, relationships, allowed CDAP
operations and their effects)
Common Distributed Application Protocol (CDAP): Application protocol that allows two
applications to operate on the objects of each other’s RIB. Provides 6 operations
(create/delete/read/write/start/stop).
RIB Daemon: Entity that processes incoming CDAP messages (delegating RIB operations to layer
mgmt tasks) and generates outgoing CDAP messages from layer management tasks’ requests

Let’s go to our to-do list
• We have fixed
– Structure
– Protocol design
– Naming and addressing scheme
– Service model / Application API
– Security
– Network management
• Still work to do, let’s move on!
39

Naming and addressing, mobility, routing
No need for special protocols
40
Name Indicates Property RINA IP
Application name What Location independent Yes No
Node address Where Location dependent, route
independent
Yes No
Point of
Attachment
How to get
there
Route dependent Yes Yes (twice:
IP, MAC)

Implications for multi-homing
41
G
A
B
C
E
D
F
H
1
2
6
5
8
3 14
18
17 16
15
19
21
13
20
9
11
10
12
4
7
2
2
G
A
B
C
E
D
F
H
1
2
3
1
2
1
3
4
1
2
3
1
2
3
1 2
3
1
1
2
2
2
• Addressing the node instead of the
interface: 3-4x time
routing/forwarding table reduction!
• No need for special protocols to
support multi-homing
Addresses assigned to interfaces (like in IP) Addresses assigned to nodes (like in RINA)

Security: DIFs are securable containers
Secure layers instead of protocols, expose less to apps, scope
42
Allocating a flow to
destination application
Access control
Sending/receiving SDUs
through N-1 DIF
Confidentiality, integrity
N DIF
N-1 DIF
IPC
Process
IPC
Process
IPC
Process
IPC
Process Joining a DIF
authentication, access
control
Sending/receiving SDUs
through N-1 DIF
Confidentiality, integrity
Allocating a flow to
destination application
Access control
IPC
Process
Appl.
Process
DIF Operation
Logging/Auditing
DIF Operation
Logging/Auditing
RINA IP protocol suite
Consistent security model, enforced by each
layer via pluggable policies
Each protocol has its own security
model/functions (IPsec, TLS, BGPsec, DNSsec,
etc.)
Scope as a native construct: controlled
connectivity by default
Single scope (global), connectivity to everyone by
default. Scope via ad-hoc means: firewalls, ACLs,
VLANs, VPNs, etc.
Complete naming and addressing, separation of
synchronization from port allocation
No application names, addresses exposed to
applications, well-known ports

Network management
Commonality is the key to effective network management
43
• 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
RINA Introduction

Let’s go to our to-do list
• We have fixed
– Structure
– Protocol design
– Naming and addressing scheme
– Service model / Application API
– Security
– Network management
44

Summing up.. RINA is not a protocol!
45
• 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 (DIF!)
• 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

Examples: RINA in a PBB-VPLS style config
• RINA recursive layering structure cleans up and generalizes
the current protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from
customers addresses and VLANs
46

Examples: RINA in a PBB-VPLS style config
• RINA recursive layering structure cleans up and generalizes
the current protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from
customers addresses and VLANs
47
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF

Examples: RINA in a PBB-VPLS style config
• RINA recursive layering structure cleans up and generalizes
the current protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from
customers addresses and VLANs
48
Metro DIF Metro DIFCore DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF

Examples: RINA in a PBB-VPLS style config
• RINA recursive layering structure cleans up and generalizes
the current protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from
customers addresses and VLANs
49
Provider VPN Service DIF
Metro DIF Metro DIFCore DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF

Examples: RINA in a PBB-VPLS style config
• RINA recursive layering structure cleans up and generalizes
the current protocol stack.
• Example 1: PBB-VPLS (Virtual Private LAN Service)
– Uses MAC-in-MAC encapsulation to isolate provider’s core from
customers addresses and VLANs
50
Green Customer VPN DIF
Provider VPN Service DIF
Metro DIF Metro DIFCore DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF

Examples: RINA in a LTE style config
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
51
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi

Examples: RINA in a LTE style config
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
52
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Multi-access radio
DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF

Examples: RINA in a LTE style config
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
53
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Multi-access radio
DIF
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF

Examples: RINA in a LTE style config
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
54
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Mobile Access Network Top Level DIF
Multi-access radio
DIF
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF

Examples: RINA in a LTE style config
• Example 2: LTE (Long Term Evolution)
– Uses PDCP, GTP to transport user’s IP payload, and also relies on internal
IP network.
55
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Protocol
conversion
GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Public Internet DIF
Mobile Access Network Top Level DIF
Multi-access radio
DIF
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF

Examples: RINA in a Virt. DC style config
• Example 3: Data Center Network with NVO3
– Network Virtualization Over Layer 3, uses overlay virtual networks on top
of the DCN’s fabric layer 3 to support multi-tenancy
• Recursion provides a cleaner, simpler solution than
virtualization
– Repeat the same building block, with the same interface. 56
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

Examples: RINA in a Virt. DC style config
• Example 3: Data Center Network with NVO3
– Network Virtualization Over Layer 3, uses overlay virtual networks on top
of the DCN’s fabric layer 3 to support multi-tenancy
• Recursion provides a cleaner, simpler solution than
virtualization
– Repeat the same building block, with the same interface. 57
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 PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF

Examples: RINA in a Virt. DC style config
• Example 3: Data Center Network with NVO3
– Network Virtualization Over Layer 3, uses overlay virtual networks on top
of the DCN’s fabric layer 3 to support multi-tenancy
• Recursion provides a cleaner, simpler solution than
virtualization
– Repeat the same building block, with the same interface. 58
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 PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF
DC Fabric DIF

Examples: RINA in a Virt. DC style config
• Example 3: Data Center Network with NVO3
– Network Virtualization Over Layer 3, uses overlay virtual networks on top
of the DCN’s fabric layer 3 to support multi-tenancy
• Recursion provides a cleaner, simpler solution than
virtualization
– Repeat the same building block, with the same interface. 59
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 PtP DIF PtP DIF PtP DIF PtP DIF
PtP DIF PtP DIFPtP DIFPtP DIF
DC Fabric DIF
Tenant DIF

AND HOW DO YOU PRETEND TO
DEPLOY THIS STUFF?
5
60

Incremental deployment
• IPv6 brings very small improvements to IPv4, but requires a
clean slate deployment (not compatible to IPv4)
• RINA can be deployed incrementally where it has the right
incentives, and interoperate with current technologies (IP,
Ethernet, MPLS, etc.)
– Over IP (just like any overlay such as VXLAN, NVGRE, GTP-U, etc.)
– Below IP (just like any underlay such as MPLS or MAC-in-MAC)
– Next to IP (gateways/protocol translation such as IPv6)
IP Network
RINA Provider
RINA Network
Sockets ApplicationsRINA supported Applications
IP or Ethernet or MPLS, etc
61

IF IT IS SO NICE.. WHY IS NOT
ALREADY OUT THERE?6
62

• … but can also be the basis of RINA-based products
– Tightly integrated with the Operating System
– Capable of being optimized for high performance
– Enables future hardware offload of some functions
– Capable of seamlessly supporting existing applications
– IP over RINA
RINA implementation goals
• Build a platform that enables RINA experimentation …
– Flexible, adaptable (host, interior router, border router)
– Modular design
– Programmable
– RINA over X (Ethernet, TCP, UDP, USB, shared memory, etc.)
– Support for native RINA applications
1
2
3
4
5
1
2
3
4
5
63

Some decisions and tradeoffs
Decision Pros Cons
Linux/OS vs other
Operating systems
Adoption, Community, Stability,
Documentation, Support
Monolithic kernel (RINA/
IPC Model may be better
suited to micro-kernels)
User/kernel split
vs user-space only
IPC as a fundamental OS service,
access device drivers, hardware
offload, IP over RINA, performance
More complex
implementation and
debugging
C/C++
vs Java, Python, …
Native implementation
Portability, Skills to master
language (users)
Multiple user-space
daemons vs single one
Reliability, Isolation between IPCPs
and IPC Manager
Communication overhead,
more complex impl.
Soft-irqs/tasklets vs.
workqueues (kernel)
Minimize latency and context
switches of data going through the
“stack”
More complex kernel
locking and debugging
64

High-level software arch.
65

Thanks for your patience!
• Current research projects
– FP7 PRISTINE (2014-2016) http://ict-pristine-eu
– H2020 ARCFIRE (2016-2018) 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
66

IRATI Demo
• Datacentre configuration, using demonstrator
• 107 VMs, leaf-spine “topology”, each ToR has 12
Machines, each ToR conncted to 3 spines
• 8 VPN DIFs “floating” on top of the DC Fabric DIF
DC Fabric DIF
One of the 8 VPN DIFs 67