The Recursive Inter Network Architecture An Opportunity for

The Recursive Inter. Network Architecture: An Opportunity for NRENs to lead Internet Research Eduard Grasa, Leonardo Bergesio, Miquel Tarzan (i 2 Cat), Jason Barron, Micheal Crotty (WIT-TSSG), Francesco Salvestrini (Nextworks), Dimitri Staessens, Didier Colle (i. Minds) TERENA networking conference, Dublin, 15 September 2020

Challenges in the current architecture weak security no Qo. S scalability issues with the routing system explosion in the complexity of the overall system Connect | Communicate | Collaborate 2

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 Qo. S 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 1970 s like CYCLADES or the INWG (International Network Working Group) where headed on the right direction. Connect | Communicate | Collaborate 3

1969: ARPANET 29 October 1969, 10: 30 PM: 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. 5 th 1969, ARPANET deployed Connect | Communicate | Collaborate 4

ARPANET 1971 Connect | Communicate | Collaborate 5

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” Connect | Communicate | Collaborate 6

The network grows: intercontinental connections Connect | Communicate | Collaborate 7

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 Inter. Network Transport Layer v 3 layers of different scope Network Layer v each with addresses Data Link Layer Connect | Communicate | Collaborate v NOT the current Internet! 8 8

Meanwhile, ARPANET keeps on growing Connect | Communicate | Collaborate 9

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

But that’s not really it… Connect | Communicate | Collaborate 11

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 http: //www. geant. net Synonym of an interface of a host : 80 Port number(Endpoint of TCP connection) Fundamental issue: static binding between layers: Application names depend on the layers below! -> not location independent! Connect | Communicate | Collaborate 12

1992. IPv 6. Resolve the scaling problems of the IPv 4 based Internet. Three types of solutions were proposed [RFC 1454]: introduce CIDR (Classless Inter. Domain Routing) to mitigate the problem TUBA, design the next version of IP (IPv 7) based on CLNP (Connection. Less 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 IPv 7 based on CLNP, since it came from the OSI world. IAB reconsidered its decision and the IPng process started, culminating with IPv 6. 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. Connect | Communicate | Collaborate 13

What are the fundamental solutions to these challenges?

Application names, hard to fix? Allocate a flow to app B App B is at node N 2 A N 1 System 1 B N 2 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 Connect | Communicate | Collaborate 15

IP and multihoming, hard to fix? Host Interface 1 H 1 Get H 1/index. htm Network H 2 is reachable Interface 2 Host H 2 Interface 3 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 IPv 6 continues to route on the interface. “IPv 6 addresses of all types are assigned to interfaces, not nodes” (RFC 4291, IPv 6 addressing architecture). Connect | Communicate | Collaborate 16

must route on node addresses, not interfaces! Host Router Host Application Name Directory Node Address Route Point of Attachment Address Path 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) Po. A addresses: Unambiguous between adjacent nodes Connect | Communicate | Collaborate 17

So is the definitive architecture? Internet Gateways Host Application Internet Network Data Link Net 1 Net 2 Net 3 Data Link 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. Connect | Communicate | Collaborate 18

Putting it all together: The Recursive Internet Architecture

RINA • • 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 Connect | Communicate | Collaborate 20

RINA Architecture System (Host) System (Router) Appl. Process Mgmt Agemt IPC Process Mgmt Agemt DIF IPC Process Appl. Process IPC Process DIF IPC Process System (Host) Mgmt Agemt IPC Process IPC API Data Transfer Relaying and Multiplexing State Vector State. Vector SDU Delimiting Layer Management Data Transfer Control Transmission Control Retransmission Control SDU Protection Connect | Communicate | Collaborate Flow Control RIB Daemon RIB CACE Enrollment Authentication Flow Allocation CDAP Parser/Generator Resource Allocation Forwarding Table Generator 21

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. Connect | Communicate | Collaborate 22

The IPC API • Presents the service provided by a DIF: a communication flow between applications, with certain quality attributes. • 6 operations: • • Qo. SParams are defined in a technology-agnostic way • • port. Id _allocate. Flow(dest. App. Name, List<Qo. SParams>) void _write(port. Id, sdu) sdu _read(port. Id) void _deallocate(port. Id) void _register. App(app. Name, List<dif. Name>) void _unregister. App(app. Name, List<dif. Name>) 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 Connect | Communicate | Collaborate 23

Shim DIFs Appl. Process IPC Process “Shim IPC Process” Shim DIF over TCP/UDP DIF IPC Process “Shim IPC Process” Shim DIF over 802. 1 q UDP flow TCP flow(s) Public Internet • • “Ethernet flow” VLAN 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 MAC @s, …) Connect | Communicate | Collaborate 24

Bootstrapping a RINA network host Edge router Internal AS router Edge router X Y F 3 C 2 host F 1 C 1 F 2 D 2 A 1 Connect | Communicate | Collaborate D 1 A 2 D 3 B 1 F 4 E 1 E 2 B 2 25

Key RINA benefits over TCP/IP Application naming ensures mobility and multihoming Supports Qo. S 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, 28 -30 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. 1 -6. Allows product/service differentiation through the design of custom DIFs Potential to significantly reduce Opex. and possibly Capex Connect | Communicate | Collaborate 26

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

Research question ? Connect | Communicate | Collaborate 28

IRINA GN 3+ OC clean slate design for Future Internet architectures Connect | Communicate | Collaborate 29

Initial use case Connect | Communicate | Collaborate 30

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 DDo. S attacks Mobility of users Distributed deployment of cloud services Connect | Communicate | Collaborate 31

Current State of the Art

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

FP 7 IRATI [2013 -2014] Open Source RINA prototype in the Linux Kernel, first public release: June 2014. Tutorial and demonstration at IEEE Globe. COM 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. 20 -25, March 2014. Connect | Communicate | Collaborate 34

FP 7 PRISTINE [2014 -mid 2016] • Security • Qo. S and congestion control • protection and resilience • multi-layer management agents Connect | Communicate | Collaborate 35

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

Are you ready for a simpler future? Connect | Communicate | Collaborate 37 37

http: //www. geant. net/opencall http: //irati. eu http: //www. ict-pristine. eu Tutorial “Alternatives to TCP/IP” Globecom 2014, 8 -12 dec. Austin, TX Connect | Communicate | Collaborate www. geant. net www. twitter. com/GEANTnews | www. facebook. com/GEANTnetwork | www. youtube. com/GEANTtv dimitri. staessens@intec. ugent. be Connect | Communicate | Collaborate 38