1. Large scale RINA Experimentation on FIRE +
RINA high-level Overview
RINA Workshop @ Telefonica
TBD

2. HOW TO CONSTRUCT A BETTER
NETWORK ARCHITECTURE
4
2

3. 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
3
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

4. 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
4
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

5. 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)
5
Host
DIF
Host
App
A
App
B
RouterRouter

6. 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?
6
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
DIF
Host
App
A
App
B
Consistent API
through layers

7. 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
7
Network 1

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

9. 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?
9

10. 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)
10
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 ControlRetransmission Control
Flow Control
Flow Control
Namespace Management Security ManagementEFCP
App A
IPC API
IPC
Process

11. Unified layer management
11
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

12. Benefits of unified layer management framework
• Only need one common layer management protocol for all layers, which allows
layer management functions to remotely operate on objects (which model the
function’s externally visible state)
• Only need one common distributed memory/database manager for layer
management functions
– With pluggable replication policies (on demand, event-based, periodic, etc..)
• Layer management functions just need to specify an object schema, and the
behaviour when the common protocol operations are invoked on the objects
• This is a huge reduction in network complexity, coming from a world were every
single layer management/control plane function has one or more standalone
protocols, independently designed (ICMP, RSVP, OSPF, RIP, BGP, IS-IS, ARP,
DNS, etc..)
12

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

14. Naming and addressing, mobility, routing
No need for special protocols
14
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)

15. Implications for multi-homing
15
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)

16. Security: DIFs are securable containers
Secure layers instead of protocols, expose less to apps, scope
16
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

17. Network management
Commonality is the key to effective network management
17
• 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

18. Let’s go to our to-do list
• We have improved
– Structure
– Protocol design
– Naming and addressing scheme
– Service model / Application API
– Security
– Network management
• And made Homer happy!
18

19. Summing up.. RINA is not a protocol!
19
• 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

20. AND HOW DO YOU PRETEND TO DEPLOY
THIS STUFF?
5
20

21. 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
21