1. The Recursive InterNetwork Architecture: An Opportunity for NRENs to lead Internet Research
Eduard Grasa, Leonardo Bergesio, Miquel Tarzan (i2Cat), Jason Barron, Micheal Crotty (WIT-TSSG),
Francesco Salvestrini (Nextworks),
Dimitri Staessens, Didier Colle (iMinds)
TERENA networking conference, Dublin,16 April, 2019

2. Challenges in the current architecture
weak security
no QoS
scalability issues with the routing system
explosion in the complexity of the overall system

3. What are the causes of the current problems?
requirements have changed and the Internet is no longer capable to cope with them.
changing requirements are not the main reason behind the Internet problems related to multi-homing, mobility, security or QoS
ARPANET was a promising technology taken into production very early in its lifecycle
the current Internet is based on incremental updates to keep it running
Computer networking research efforts of the 1970s like CYCLADES or the INWG (International Network Working Group) where headed on the right direction.

4. 1969: ARPANET
29 October 1969, 10:30PM: First message on the ARPANET was sent from UCLA to Stanford by student programmer Charley Kline.
The message text was the word login; the l and the o letters were transmitted, but the system then crashed.
Dec. 5th 1969, ARPANET deployed

5. ARPANET 1971

6. 1972. Multihoming problem encountered
Tinker AFB wanted connections to two different IMPs for redundancy.
ARPANET designers realized that they couldn't support this feature
two interfaces of the same host had different addresses therefore the ARPANET had no way of knowing that they belong to the same host.
Routing should be to nodes, not interfaces….
Left for “future work”

7. The network grows: intercontinental connections

8. The International Network Working Group (1972)
1976: INWG 96 architecture
The International Network Working Group (1972)
Including the ARPANET, CYCLADES, NPL, and others
Goal: International Transport Protocol
INWG 37 based on the early TCP
INWG 61 based on CYCLADES TS.
A synthesis was proposed and voted in 1976: INWG 96
InterNetwork Transport Layer
Network Layer
Data Link Layer
3 layers of different scope
each with addresses
NOT the current Internet!

9. Meanwhile, ARPANET keeps on growing

10. Internetwork layer (TCP)
1983. Flag Day
Internetwork layer (TCP)
Network layer (NCP)
Transport layer
Network layer
Datalink layer
Datalink layer
J. Day “How in the Heck do you lose a layer!?” Network of the Future (NOF), 2011 International Conference on the, Nov. 2011

11. But that’s not really it…

12. 1983. DNS, First opportunity to fix naming and addressing missed
1970: limited number of applications, TELNET, FTP, RJE but the need to map application names to addresses were well understood and todo when the host file was to be automated
DNS continued to use well known ports to name applications
:80
Fundamental issue: static binding between layers: Application names depend on the layers below! -> not location independent!
Synonym of an interface of a host
Port number(Endpoint of TCP connection)

13. 1992. IPv6. Resolve the scaling problems of the IPv4 based Internet.
Three types of solutions were proposed [RFC1454]:
introduce CIDR (Classless InterDomain Routing) to mitigate the problem
TUBA, design the next version of IP (IPv7) based on CLNP (ConnectionLess Network Protocol) , CNLP was an OSI based protocol that addressed nodes instead of interfaces.
continue the research into naming, addressing and routing.
CIDR was introduced but the IETF didn't accept an IPv7 based on CLNP, since it came from the OSI world.
IAB reconsidered its decision and the IPng process started, culminating with IPv6. One of the rules for IPng was not to change the semantics of the IP address, which continues to name the interface perpetuating the multi-homing problem.

14. What are the fundamental solutions to these challenges?

15. Application names, hard to fix?
Allocate a flow to app B
App B is at node N2 A B N1 N2
System 1
System 2
Solution: Name applications (independent namespace), the network maps application names to node names
This mapping is dynamic, and maintained in directories (what applications are available in each system – host, router - )
Application developers and users don’t care about node names
They just request communication to a remote application
Seems simple, nobody realized before?
CYCLADES (1973) solved it from the beginning
XNS, DECNET, OSI also understood the problem and solved it from the beginning

16. IP and multihoming, hard to fix?
Host H1
Host H2
H2 is
reachable
Interface 2
Interface 3
Get H1/index.htm
Network
Interface 1
Solution: Name nodes (independent namespace), calculate routes based on node names
Selecting what interface to use to reach a certain node is a local (between adjacent nodes) matter.
Seems simple, nobody realized before?
ARPAnet was presented with this problem in 1972, they knew how to solve it (didn’t do it)
CYCLADES (1973) solved it from the beginning
XNS, DECNET, OSI also understood the problem and solved it from the beginning
IPv6 continues to route on the interface. “IPv6 addresses of all types are assigned to interfaces, not nodes” (RFC 4291, IPv6 addressing architecture).

17. must route on node addresses, not interfaces!
Host
Router
Router
Host
Routing is a two step process:
Calculate the sequence of nodes (route) to generate the next hop
Select an appropriate path (Point of Attachment) to get to the next node
Name and address properties:
Application: Location independent (so that it can move)
Node addresses: Location dependent (to optimize routing)
PoA addresses: Unambiguous between adjacent nodes
Application Name
Directory
Node Address
Route
Path
Point of Attachment Address

18. So is this the definitive architecture?
Internet Gateways
Data Link
Network
Internet
Application
Net 1
Net 2
Net 3
Host
Doesn’t seem to be, what about VPNs over the Internet?
Another layer on top of the Internet
What about virtual networking? (e.g. VXLAN, STP, etc.)
What about an internetwork of internetworks?
There doesn’t seem to be a fixed number of layers, it all depends on the scenarios and use cases. Therefore a fundamental architecture of computer networks should be recursive.

19. Putting it all together: The Recursive Internet Architecture

20. RINA Distributed IPC Facility (DIF).
A structure of recursive layers that provide IPC (Inter Process Communication) services to applications on top
There’s a single type of layer that repeats as many times as required by the network designer
Separation of mechanism from policy
All layers have the same functions, with different scope and range.
Not all instances of layers may need all functions, but don’t need more.
A Layer is a Distributed Application that performs and manages IPC
Distributed IPC Facility (DIF).
This yields a theory and a scalable architecture

21. RINA Architecture System (Host) System (Host) System (Router)
Appl.
Process
Mgmt
Agemt
Appl.
Process
IPC Process
DIF
IPC Process
IPC Process
Mgmt
Agemt
Mgmt
Agemt
DIF
IPC Process
DIF
IPC Process
IPC Process
IPC Process
IPC API
Remember, this is the architecture!
DAF Support Tasks:
The IPC Management (and other management: memory, storage, CPU) tasks are usually implemented as OS functionality.
IPC Resource Management: Creation/Deletion of IPC processes
Multiplexing (Usually inverse multiplexing, an application flow into multiple DIF flows, for example: 1 for video, 1 for audio, 1 for text, …)
SDU Protection (CRCs, encryption, TTL, …)
IDD (Inter DIF Directory, find out in what DIF the destination application process is executing)
Data Transfer
Data Transfer Control
Layer Management
SDU Delimiting
Transmission Control
Transmission Control
CACE
Transmission Control
Enrollment
RIB Daemon
Data Transfer
Data Transfer
State Vector
Authentication
Flow Allocation
Data Transfer
State Vector
State Vector
Retransmission Control
Retransmission Control
Retransmission Control
RIB
Resource Allocation
Relaying and Multiplexing
CDAP Parser/Generator
Flow Control
Flow Control
Flow Control
Forwarding Table Generator
SDU Protection

22. Phases of Operation Enrollment (between IPC processes)
Creates, maintains distributes and deletes the information required to create instances of communication
~IP: Manual configuration or DHCP
Flow allocation
Creates, maintains distributes and deletes the information required to support the functions of data transfer
Data Transfer Phase
Actual transfer of data.

23. The IPC API
Presents the service provided by a DIF: a communication flow between applications, with certain quality attributes.
6 operations:
portId _allocateFlow(destAppName, List<QoSParams>)
void _write(portId, sdu)
sdu _read(portId)
void _deallocate(portId)
void _registerApp(appName, List<difName>)
void _unregisterApp(appName, List<difName>)
QoSParams are defined in a technology-agnostic way
Bandwidth-related, delay, jitter, in-order-delivery, loss rates, …
Aid to adoption: faux sockets API.
Presents the sockets API to the applications, but internally maps the calls to the IPC API
Current applications can be deployed in RINA networks untouched, but won’t enjoy all RINA features

24. Shim DIFs
Appl.
Process
Appl.
Process
IPC Process
DIF
IPC Process
IPC Process
“Shim IPC Process”
Shim DIF over TCP/UDP
“Shim IPC Process”
“Shim IPC Process”
Shim DIF over 802.1q
“Shim IPC Process”
VLAN
Public Internet
UDP flow
TCP flow(s)
“Ethernet flow”
Wraps around a non-RINA layer (e.g., wire, Internet, LAN) and presents enough of the RINA API to allow an application to treat the layer as a RINA DIF
Main duties of a shim DIF
Map N+1 layer application names to addresses in the shim DIF layer
Allocate and deallocate “flows” within the shim DIF
Where a flow is a communication resource with well defined characteristics (e.g. TCP connection, UDP flow, the set of Ethernet frames with the same source/destination …)

25. Bootstrapping a RINA network
host
Edge router
Internal AS router
Edge router
host X Y F3 F1 F2 F4 C2 C1 D2 D1 D3 E1 E2 B1 B2 A1 A2

26. Key RINA benefits over TCP/IP
Application naming ensures mobility and multihoming
Supports QoS in the architecture
No need for CGN middleboxes etc
Smaller routing table sizes, addressing tailored to the scope of the network layer
Day, J.; Trouva, E.; Grasa, E.; Phelan, P.; de Leon, M.P.; Bunch, S.; Matta, I.; Chitkushev, L.T.; Pouzin, L., "Bounding the router table size in an ISP network using RINA," Proc. Network of the Future (NOF), 2011, vol., no., pp.57,61, Nov. 2011
Improved security inherent in architecture
Boddapati, G.; Day, J.; Matta, I. & Chitkushev, L. T. (2012), Assessing the security of a clean-slate Internet architecture., in 'ICNP' , IEEE, , pp
Allows product/service differentiation through the design of custom DIFs
Potential to significantly reduce Opex.and possibly Capex

27. IRINA
Investigating RINA as the next generation GEANT and NREN network Architecture

28. Research question ?

29. IRINA GN3+ OC clean slate design for Future Internet architectures

30. Initial use case

31. NREN future requirements (TERENA compendium and IRINA survey)
Bandwidth issues -> improve throughput/link utilisation
Wireless access -> saturation of peering points with mobile operators
Security -> mitigation of DDoS attacks
Mobility of users
Distributed deployment of cloud services

32. Current State of the Art

33. RINA TIMELINE National and Individual projects (US/EU) PRISTINE
01/ /2016
National and Individual projects
(US/EU)
IRATI
01/ /2014
Future research projects (H2020 and beyond)
IRINA
10/13-03/14
Small lab prototypes
Linux kernel prototype
Mature Linux kernel prototype
COTS Commercial products
Niche Commercial products
Supported by NRENs
Inter-university RINA / IPSec tunnels
NREN lab prototypes
Adopted by Carriers
Architecture specification (PSOC)
Standardisation (ISO/SC6)
2011
2012
2013
2014
2015
2016

34. FP7 IRATI [ ]
Open Source RINA prototype in the Linux Kernel, first public release: June 2014.
Tutorial and demonstration at IEEE GlobeCOM 2014
Sander Vrijders, Francesco Salvestrini, Eduard Grasa, Miquel Tarzan, Leonardo Bergesio, Dimitri Staessens, Didier Colle, "Prototyping the Recursive Internet Architecture: The IRATI Project Approach", IEEE Network, Vol. 28, no. 2, pp , March 2014.

35. QoS and congestion control
FP7 PRISTINE [2014-mid 2016]
Security
QoS and congestion control
protection and resilience
multi-layer management agents

36. RINA Adoption strategy
FP7 IRATI Project Prototype
Applications
Current PSOC prototype
DIF …
End goal
Today
Applications
Applications
Ethernet
Applications
DIF …
DIF …
Physical Media
TCP/IP or UDP/IP
Ethernet
UDP/IP
Applications
Physical Media
Physical Media
Ethernet
TCP/IP or UDP/IP
Physical Media
DIF …
No migration, just adoption!
In other words, no need for a “Flag Day”
Start using it above IP, below IP or near IP
Where it proves useful the use can be extended
Physical Media

37. Are you ready for a simpler future?

38. Tutorial “Alternatives to TCP/IP” Globecom 2014, 8-12 dec. Austin, TX
Tutorial “Alternatives to TCP/IP” Globecom 2014, 8-12 dec. Austin, TX