1. Is the Internet an unfinished demo? Meet RINA!
16/12/2017
Is the Internet an unfinished demo? Meet RINA!
© Fundació i2CAT 2004

2. What is this talk about?
Show that the current Internet architecture -based on functional layering and TCP/IP- is not complete
It doesn’t provide the right structure to solve the current Internet issues
Show that past efforts (70s, 80s) provided a more complete architecture with less fundamental limitations
And seem to have been forgotten
Introduce a new architecture that provides an structure that overcomes these limitations: RINA
And provides network architects with a better toolset

3. Issue 1: Naming and Addressing

4. IP and multihoming
Host
is not reachable!
Get /index.htm
IP Network
Problem: The network doesn’t know that two or more IP addresses belong to the same system (host, router)
Fundamental issue: The network is calculating a route to a place on the path to the destination, but not to the final destination.
The destination is not the interface of the node, it is an application executing in the node, so routing must be done on the node address
The network is routing on the interface instead of the node! There are even no identifiers for nodes!

5. 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).

6. On node names
16/12/2017
For large networks with a big number of nodes, choosing the right properties for a node name makes a difference
If the name provides some hints on where the node is, routing is easier to scale: location-dependent names (=address)
Where not in absolute terms (i.e. geographical location), but in relation to the other nodes of the network
Addresses of nodes that are closer should be more similar than addresses of nodes that are further appart
Organizing the node namespace forming a hierarchy removes the need to store the default routes to everywhere
Only special routes (shortcuts in the hierarchy) have to be announced and maintained in routing tables
Example [region][metro][campus][node]
First of all, because the addresses indicate
where the node is, the address represents an abstract route, a sort of “anycast”
route. We say “anycast” because the address does not indicate a specific path
but any of several paths through the subnet hierarchy. The routers know that at
least as a default they can route along paths that move up or down the tree of
Subnets.
© Fundació i2CAT 2004

7. But IP is routing on the interface …
16/12/2017
No node names, just interfaces, routing based on the interface
Each node has more than one interface (in the case of routers usually 10s or 100s), more routes to maintain
IP addresses are not location dependent (see below), even default routes have to be maintained in routing tables
An IP is no really an address, but a label that is manually allocated by some organizations
Every time the packet travels through a different network, the IP address range changes (because it is provider based). No sense of location at all
© Fundació i2CAT 2004

8. Application names in TCP/IP
Synonym of an interface of a host
Socket (Endpoint of TCP connection)
:80
Fundamental issue: static binding between layers (Path through the layers). Application names depend on the layers below! Point of Attachment addresses are exposed to application developers and users!
What if the application wants to move? What if the transport connection crashes?
In general: a layer’s addresses/names should be independent of the other layers addresses/names.

9. 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
Node names are internal to the network and managed by it (no need for central organizations allocating addresses manually)
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

10. Mobility
Just a dynamic version of multi-homing, with expected failures.
The host that moves acquires new points of attachment and drops the old ones: it is just routing updates for the network.
With appropriate application names, node addresses and Point of attachment names, mobility is supported without the need of any special protocols
As it was in CYCLADES (1973), DECNET, XNS or OSI

11. Naming and addressing wrap-up
16/12/2017
Host
Router
Router
Host
Application Name
Directory
Node Address
Route
Path
Point of Attachment Address
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
Explain how they provide IPC services to each other
Explain how the naming and addressing schema in DIFs
© Fundació i2CAT 2004

12. Let’s stress this out
Back in the 1970s there were running networks that supported multi-homing and mobility, and had a routing system much more scalable than TCP/IP
What has happened the last 30 years?
The principles are quite simple, why didn’t TCP/IP adopt them?
Open question

13. Issue 2: Layering, or what is the structure?

14. Functional Layering This time is not just TCP/IP 
CYCLADES, DECNET, XNS and OSI also used functional layering as an organizing principle
Functional layering: Each layer is a black box, performing a single function not repeated by the other layers of the stack.
Each layer provides a different service to the layers above
Fixed number of layers (5, 7)
Host
Host
IP Router
IP Router
Application
Application
TCP
Transport
Transport
Network
Network
Network
Network
Data Link
Data Link
Data Link
Data Link
Physical
Physical
Physical
Physical

15. Functional layering issues
Functions are repeated at different layers
Error and flow control on data link and transport
Routing in several layers (spanning tree at layer 2, OSPF at layer 3)
Protocols that do not match a layer strictly
MPLS (Layer 2.5? What is this layer?)
Layer violations
TCP pseudo-header (requires data from the IP layer)
Summing up: repeated functions, protocols that do not fit in layers, broken layering, …
Doesn’t seem to be a good organizing principle

16. So… no layers?
From a single link to the whole Internet, no layering means that distributed functions have to manage the complete granularity of resource allocation at once
No layering means protocols would have to operate effectively over different physical media and provide an efficient service to different applications at the same time
Layers provide a divide-and-conquer approach, by isolating shared state of different scope (link, network, network of networks, …)
This seems to provide a good start for a definition!
Let’s adopt a principle: “networking is IPC and only IPC”
As all the entities executing in computing systems are processes, networking can be seen as distributed inter-process communication

17. IPC over a wireless link
What is the structure? A B
host
Local IPC A
host B
IPC over a wired link
Wired link A
host B
router
IPC over a wired link
Wired link
IPC over a wireless link
IPC over a network
Wireless link
Different examples of IPC between application process A and application process B.
The mechanisms for doing IPC in the different cases are the same, they just need a different configuration.
It is a repeating structure: distributed applications doing IPC at a bigger scope (network) use the services of distributed IPC at smaller scopes (link)
Recursive structure of distributed applications that do IPC!

18. Applications vs. network?
No more separation between networks and applications: Networking is a distributed application, specialized to do Inter Process Communication.
All the entities in computer systems are processes.
They communicate with each other using IPC services.
IPC within one system is easy: local access control, shared memory, message passing, local queues, …
IPC between two or more systems is more complicated: need error control, flow control, multiplexing, distributed access control, …
Need a distributed application that provides IPC over a certain scope (a direct link, a network, an internetwork).

19. What is the structure (2)
16/12/2017
IPC process. Application Process that does IPC.
DIF. Distributed IPC Facility; set of IPC processes that cooperate to provide distributed IPC.
The structure can accommodate as many levels of DIFs as required by the network designer.
DIFs provide the following service (interface):
Allocate a flow to the destination application with a certain QoS
Write data to the flow
Read data from the flow
Deallocate the flow resources
There are 5 systems (boxes) connected through 4 physical links.
Each layer (DIF) is just a distributed application specialized to provide IPC services. It is composed of individual IPC process executing at each system.
Explain an example of communication between S and D
It is recursive (for DIFs anything on top it is an application process)
Stress: one single type of layer, repeated as many times as required
© Fundació i2CAT 2004

20. Issue 3: What’s inside a layer (DIF)?

21. What we have today? REPEATING PATTERN!
16/12/2017
Each layer = one or more protocols, let’s look at the lower 4
REPEATING PATTERN!
4. Network. Host to host error and flow control
It make sense, since every time we relay or multiplex there’s the risk of losing or corrupting data, so that’s why after that we need to correct errors
3. Network. Relaying and multiplexing over different networks
2. Data link. Error and flow control over a link
1. Physical. Relaying and multiplexing over the physical media
© Fundació i2CAT 2004

22. What about DIFs?
Comparing the recursive structure to functional layering:
1st level DIF is equivalent to the physical and data link layers together
2nd level DIF is equivalent to the network and transport layers together
A DIF has to do relaying and multiplexing (over underlying DIFs or physical medias) and error and flow control
Ok, but still, how many protocols inside each DIF? Different protocols for different DIFs?
2nd level DIF
1st level DIF

23. How many protocols today?
Each layer = different function, so each layer = different protocol
Even within the same layer, different protocols
Different physical medias have different requirements (IEEE 802.x, SONET, SDH, USB, Bluetooth, …)
Different applications have different requirements (TCP and all of its variations, UDP)
Are the different protocols so different? What if we separate mechanism from policy? E.g. data transfer
Addressing, Relaying, multiplexing, ordering, fragmentation, reassembly, encryption, data corruption detection, flow control, lost and duplicate detection, … are mechanisms
A policy is a configuration of the mechanism

24. What’s inside a DIF?
Single data transfer protocol, configurable through policies
Adapted to different physical media or different applications
Spitted in 2: DTP (data transfer) and DTCP (data transfer control)
Layer management. Distributed management functions (routing, resource allocation, access control, flow allocation, …)
Applications that use a single application protocol to communicate: CDAP
Object oriented, objects are stored in the RIB (Resource Information Base)

25. DIF Characteristics Complete naming and addressing architecture
16/12/2017
Complete naming and addressing architecture
Names for applications, nodes and Points of Attachment (PoA).
Directories to map Apps to nodes, and nodes to PoAs.
This enables support for multi-homing, mobility and multicast.
Configurable Error and Flow Control Protocol (EFCP)
Different policies can optimize the protocol for different physical media (lower level DIFs) or applications (higher level DIFs).
Support for Quality of Service
Each DIF can implement the Quality of Service mechanisms the way it wants, it just needs to understand what QoS the application requests and what QoS the underlying DIF (or physical media) provides.
Authentication and access control
IPC processes have to authenticate before being able to join a DIF.
© Fundació i2CAT 2004

26. Issue 4: Yeah right, nice… And now you pretend the world will be migrating to this stuff?

27. RINA Deployment … … … Don’t need migration, just need adoption!
Start small: create DIFs on top of the Internet (TCP/IP), refine specifications, experiment, validate
Push DIFs down the current layers
DIFs peering with IP autonomous systems
DIFs on top of Ethernet
DIFs on top of physical media (wireless, cellular, optical, …)
Applications
DIF …
Applications
Applications
DIF …
Applications
TCP/IP
DIF …
Ethernet
TCP/IP
Physical Media
Ethernet
Ethernet
Physical Media
Physical Media
Physical Media

28. About to finish! Just need to conclude

29. www.pouzinsociety.org - csr.bu.edu/rina/ - fi2.cat/rinaproject
Recursive InterNetwork Architecture: RINA
Networking is Inter-Process Communication (IPC) and only IPC
What’s different?
Functional layering, where ach layer has the responsibility of a different function
Fixed number of layers
Routing on the interface (data link layer)
Exposing addresses to applications
Use of well-known ports
Incomplete naming and addressing schema
Lack of a security mechanism: A long list of threats and vulnerabilities
Lack of a built-in mechanism to provide specific QoS: Only best effort service
Exploding size of router tables
Lack of a directory that maps applications to nodes
CURRENT INTERNET
structure
routing
simplicity
and more
A layer (DIF) is a distributed application that provides IPC services over a given scope
Relative number of layers, each layer manages a range of bandwidth and QoS
DIFs recurse providing IPC services to each other
Routing on the node
A complete naming and addressing schema
Applications have an independent namespace
Mobility and multi-homing inherently
Fundamental functions to provide communication
Separation of mechanism and policy
All layers use the same protocols but are configured differently through policy to achieve the desired service
A single application protocol
A single data transfer protocol
Joining a DIF requires authentication, addresses are not exposed to the applications, no well-known ports are used, which results to a more secure network
Each DIF can support a set of QoS cubes and provides an API to allow applications to request service with certain QoS parameters
Each DIF has its own private internal addresses, which means that a global address space is not required
Names for applications, nodes and Points of Attachments to the network exist, as well as a directory, mapping applications to nodes
RINA
This slide is the RINA poster we have at our i2CAT booth, and provides a summary of the comparison between the current Internet and RINA. Taking into account the shortcomings, incompleteness and limitations explained in the presentation, we think we’ve made our point that we can call the Internet an unfinished demo, that has been living on band-aids and Moore’s law until today (brute force approach). RINA provides a complete, simple architecture based on fundamental networking patterns, we challenge you to come explore RINA with us and/or find a more complete or simpler structure.
What’s coming next?
Adoption,
no migration!
A collaboration between:
Development of a first RINA prototype on top of TCP/IP
Measurements and evaluation against the current Internet architecture
Refinement of the current specification
- csr.bu.edu/rina/ - fi2.cat/rinaproject

30. John Day talk @ Barcelona
If you want to know more, John will be providing a more complete overview of RINA and its implications in a talk at Barcelona, tomorrow at 10:30 am CEST
A pity it is the same schedule as tomorrow’s closing plenary, but it will be recorded
Follow it from (live streaming or recorded session)

31. Thanks for your attention!
More information: