Large scale RINA Experimentation on FIRE +
Designing a converged network operator
with RINA: any access, any application
From Research to Standardization workshop
May 10, 11 Sophia Antipolis
A converged network vision..
• Any access media, any application requirement supported
by a common network infrastructure
• Single architecture, single management system, single
users database (regardless of access)
Large-scale RINA Experimentation on FIRE+ 2
Manage users and sessions,
Local managed services
Capillarity, Capacity,
Mobility support
Multiplexing Switching,
Transport
Control functions,
Regional managed services
Devices
Places
Users Access Aggregation Local Points of Presence Core Regional Data Centres
Radio
Fiber
Are “All IP networks” fit for this purpose?
• 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
Large-scale RINA Experimentation on FIRE+ 3
1
2
1
42
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
RINA macro-structure (layers)
Single type of layer, consistent API, programmable policies
5
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
“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.)
Large-scale RINA Experimentation on FIRE+ 6
(Theory) (Practice)
Naming and addressing, mobility, routing
No need for special protocols
Large-scale RINA Experimentation on FIRE+ 7
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)
Security: DIFs are securable containers
Secure layers instead of protocols, expose less to apps, scope
Large-scale RINA Experimentation on FIRE+ 8
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
Large-scale RINA Experimentation on FIRE+ 9
• 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
Deployment
Clean-slate concepts but incremental deployment
Large-scale RINA Experimentation on FIRE+ 10
• 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
Service provider, RINA, Internet (e-mall) Access
Access
router
PtP DIF
CPE
Edge
Service
Router
MAN P.E MAN P. E.
MAN Access DIF
MAN Core DIF
PtP DIF PtP DIF
PtP DIF PtP DIF
MAN P
PtP DIF
Host
Core Backbone DIF
PtP DIF
Core router Core router e-mall
Access
Router
E-mall
Border
Router
Customer network Service Prov. 1 network
Access Aggregation Service Edge Core Internet Edge
Internet ( e-mall)
eXchange Point
Core PoP, city B
Core PoP, city ACity A MAN
City A Cabinets
PtP DIF PtP DIF PtP DIF
Service Provider Top Level DIF
E-mall 1 DIF
PtP DIF
E-mall 2 DIF
Service provider, RINA, Internet (e-mall) Access
Access
router
PtP DIF
Cell Tower
(eNodeB)
Mobile Edge
Service
Router
MAN P.E MAN P. E.
MAN Access DIF
MAN Core DIF
PtP DIF
PtP DIF
PtP DIF PtP DIF
MAN P
Cell DIF
Mobile
Host
(or border
router)
Core Backbone DIF
PtP DIF
Core router Core router e-mall
Access
Router
E-mall
Border
Router
Service Prov. 1 network
Access Aggregation Service Edge Core Internet Edge
PtP DIF PtP DIF PtP DIF
Service Provider Top Level DIF
E-mall 1 DIF
PtP DIF
E-mall 2 DIF
Mobile Access DIF
Internet ( e-mall)
eXchange Point
Core PoP, city B
Core PoP, city A
City A MANCity A Cabinets
Cell sites
From research to standardisation
Large-scale RINA Experimentation on FIRE+ 13
• 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
Editor's Notes
Layers are resource allocators, provide IPC services over a certain scope, they all have the same functions
- Complexity, complexity, complexity (unbounded, nobody knows what new combinations of layers may be needed in the future
Start by emalls, CPEs connecting to e-mall DIFs.
* The man’s scope may be a city (then it is really a metropolitan area network) or a region aggregating several towns/rural areas (then it is a regional area network)
e.Mall access router may be reachable from the same core PoP where a customer is connected or from a different one (as in picture)
Divided e-mall access and border router, may be a single router
* Mobile Access DIF Hides Cell Towers from Service Provider TL. DIF, and makes the Mobile Hosts appear stationary to the Mobile Edge Service Router (mobility anchor), where the Mobile Host User can access the Service Provider Top Level DIF and from there communicate with other service provider customers or to one or more of the available e-malls.
* More Mobile Access DIF layers with more “local” mobility anchors could be added as well if the deployment required it.