experiences with implementing rina - recursive inter ...rina.tssg.org › docs ›...

Experiences with Implementing RINA - Recursive Inter Network Architecture

Miguel Ponce de Leon,Eduard Grasa,John Day

PhD Course: University of KaiserslauternFuture Network Architectures and Experimentation 07 Mar 2012

Wednesday 7 March 2012

What is this presentation about ?• Highlight that the current Internet architecture -

based on functional layering and TCP/IP is not complete !

• Highlight that past efforts (70s, 80s) provided a more complete architecture with less fundamental limitations !

• Introduce a new architecture that provides a structure that overcomes these limitations: RINA

• Provide an example implementation


Wait a minute! Who am I?• The goals of the talk look a bit ambitious, donʼt

they?• Of course much work has been done by John

Day, Louis Pouzin, and other networking pioneers.

• Iʼm just learning from them, with them and want to understand the issues more, donʼt you?


The common consensus• “ A large number of challenges in the realms of

technology, business, society and governance have to be overcome if the future development of the Internet is to sustain the networked society of tomorrow”

• Most people argue that requirements have changed and therefore the Internet is no longer capable to cope with them


Have the requirements of the Internet changed?

• The environment in which TCP/IP operates today is very different from when the protocols where conceived in the late 1970s.

• However historical research shows that the root of the problems stem from a disconnect between the developments prior to about 1977 and the current Internet.


The Internet is FacingSevere Problems: I

• Security is essentially non-existent.– Excuse: No one considered it in the early days

• Security was not a concern for a military-funded network?– Actual: Systematically weak design

• Router table size is growing exponentially– Excuse: Yea, So? Memory is cheap– Actual: No longer on Mooreʼs Law, it is getting expensive and caused

by• No support for multihoming

– Excuse: not that many hosts need it, and we can kludge it• A military-funded network doesnʼt care about redundancy?

– Actual: Since when is 107 small, and the kludge doesnʼt scale.• It isnʼt 107, with Smart Grid it is more like 1010.


The Internet is FacingSevere Problems: II

• Mobility is cumbersome and doesnʼt scale– Excuse: What do you mean? It works. . . . . Sort of.– Actual: With only physical addresses, hard to do “re-locatable”

addressing• Congestion keeps Utilization Low

– Excuse: There is great congestion control in TCP . . . Sort of. Bandwidth is Cheap donʼt worry about it.

– Actual: Any control theory book says put feedback as close to the resource as possible. TCP puts it as far away as possible, but great thesis generator!

• Quality of Service is difficult to do.– Excuse: Net neutrality requires that all traffic be treated equally– Actual: Net neutrality is political cover for their inability to do it.


Myths of the Internet: I• The Internet is an Engine of Innovation.

– The Internet has in a real sense been stagnant since the late-70s– Living on Mooreʼs Law and Band-aids

• Lots of Innovation on top of the Internet, but even that has begun to wane.

• The Internet is decentralized. No one owns the Internet.– Actually, Same as the global PSTN, just no sexy name.

• The Internet is based on the ARPANET– Actually, it is based on CYCLADES

• The Internet is not an internet, but a catenet.– Ceased to be an Internet on January 1, 1983.

• The Internet is a dumb network. – Actually, it keeps maximal state in the network, not minimal.


The Reality is Quite Different

• If the Internet were an Operating System, it would have more in common with DOS, than UNIX.

• Imagine trying to use a modern computer with only physical memory addresses.

• That is the Internet today.


What about the deep questions?

• John Day will tackle these in his talk this afternoon–“How in the Heck Do You Lose a

Layer!?”


Who is John Day and what is RINA ?

• RINA: Recursive InterNetwork Architecture – is an Internet architecture proposed to resolve

the challenges of todayʼs internet.

–Patterns in Network Architecture: A Return to Fundamentals by John Day, Published by Prentice Hall ISBN 0132252422


http://www.amazon.com/Patterns-Network-Architecture-Return-Fundamentals/dp/0132252422/ref=sr_11_1?ie=UTF8&qid=1239572904&sr=11-1

http://www.amazon.com/Patterns-Network-Architecture-Return-Fundamentals/dp/0132252422/ref=sr_11_1?ie=UTF8&qid=1239572904&sr=11-1

The Myths and “Principles” are the Major Barrier to

FINDing an Answer• The field is no longer a science, but a craft.

– Researchers have been asking “What to build?” – Not asking, “What donʼt we understand?”

• The Answer has been clear since the mid-90s– And it is very simple:

• Networking is IPC and only IPC


Networking is IPC• RINA is based on the principle that “Networking is a

distributed application, specialised to do Inter Process Communication”

– All 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).


Lets Go Back to Basics• Start simple and incrementally introduce new

conditions.– Taking Imre Lakatosʼ Proofs and Refutations

as a model.• We are going to cover ground we all know.

– Or at least we think we do. (I thought so)• As we do, think about what is required when

– the order is not what you might expect.– But the implications are even more interesting.


Two applications communicating in the same

system.

• Communication within a Single Processing System

IPC Facility

ApplicationProcesses

PortIds

A BApplication

Flow


IPC with two directly connected systems.

• Turns out the first thing you need is management to find the other application. Then of course to do that one needs,

• Some sort of error and flow control protocol to transfer information between the two systems.

DistributedIPC Facility

EFCP EFCP

IAP IAP

ApplicationProcesses

PortIds


Simultaneous Communication Between Two Systems

• multiple applications at the same time• Also Multiple Users of a Single Resource• Will also need an application to manage multiple users of a single resource.

Mux Mux

EFCP EFCPEFCP EFCPEFCP EFCP


Communication with N Systems

Systems


Simultaneous Communication Between Two Systems

• By dedicating systems to IPC, reduce the number of lines required and even out usage by recognizing that not everyone talks to everyone else the same amount.

Host Systems

Dedicated IPCSystems


The IPC Model(A Purely CS View)

RelayingAppl

EFCPEFCP

EFCP EFCP EFCP EFCP EFCP EFCP

MuxMux

User Applications


Should Have Seen It Sooner

• Repeating Structure Had Shown Itself Even There

SNIC

SNDC

SNAC

LLC

MAC

Application

Session

Presentation

Transport

Network

Data Link

The Repeating StructureH

ad Shown Itself Even There

Physical


The Implications• Networking is IPC and only IPC.

– We had been concentrating on the differences, rather than the similarities.

– Of course, there are layers! What else do you call cooperating shared state that is treated as a black box?

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

– A Distributed IPC Facility (DIF)• This yields a theory and an architecture that scales indefinitely,

– i.e. any bounds imposed are not a property of the architecture itself.


The Implications• A DIF manages a given range of bandwidth and QoS.• The greater the range in a network the more DIFs required.• There is only one data transfer protocol for all layers.• There is only one application protocol needed.• Multihoming and mobility fall out for free.• Multicast is simpler and easily scales.• A Global Address Space is Unnecessary. • IPv6 has been a waste of time• A DIF is a securable container. There are no NATs or Firewalls• With no additional security measures, a DIF is more secure than the

current architecture• Networking requires that Maximum Packet Lifetime be bounded.


IPC over different scopes

• 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!

A B

hostLocal IPC

A

host

B

hostIPC over a wired link

Wired link

A

host

B

hostrouterIPC over a wired linkWired link

IPC over a wireless link

IPC over a network

Wireless link


Distributed IPC Facility (DIF)

• 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

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


What a DIF Looks Like

• Processing at 3 timescales, decoupled by either a State Vector or a Resource Information Base– IPC Transfer actually moves the data ( ≈ IP + UDP)– IPC Control (optional) for retransmission (ack) and flow control, etc.– IPC Layer Management for routing, resource allocation, locating

IPCTransfer

IPCControl

IPC Management

DelimitingTransfer

Relaying/ MuxingSDU Protection Common Application

Protocol

Applications, e.g., routing, resource allocation, access control, etc.

Application-entities Application Process


RINA Design Principles• Principle 1: Maximizing Invariances and Minimizing Discontinuities. This

leads to the separation of mechanism and policy.• Principle 2: To scale, resource allocation problems require a repeating or

recursive structure. A common repeating structure that allows divide and conquer is one of the few solutions known to scale

• Principle 3: Networking is IPC and only IPC.• Principle 4: Complete naming and addressing architecture: • Principle 5: The Necessary and Sufficient Condition for Synchronization is

to bound 3 timers. (Watson) This implies Separation of port allocation from synchronisation in the transport protocol.

• These then imply: – that multihoming and mobility are inherent in the structure– Security is inherent in the structure– Integrating connectionless and connection-oriented networking.


Recursive Layers: the ends are relative

• Functional Layering the perfect world: This time itʼs 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)

IP Router

IP Router

Host Host

Application

Transport

Network

Data Link

Physical

Application

Transport

Network

Data Link

Physical

Network

Data Link

Physical

Network

Data Link

Physical

TCP


Recursive Layers: the ends are relative

• Functional Layering the Issues

• Functions are repeated at different layers– Error and flow control on data link layer and transport layer– Routing in several layers (spanning tree at layer 2, OSPF at layer 3)

• Layer violations– TCP pseudo-header (requires data from the IP layer)– IP Fragmentation

• What we are seeing today are: repeated functions, protocols that do not fit in layers, broken layering, …

– Doesnʼt seem like an unheld principle for the current Internet.


Recursive Layers: the ends are relative• Functional Layering the Issues• In fact from a single link to the whole Internet, there is NO layering which

means that distributed functions have to manage the complete granularity of resource allocation at once.

• No layering means protocols have to operate effectively over different physical media and provide an efficient service to different applications at the same time.

• Layers are supposed to provide a divide-and-conquer approach, by isolating shared state of different scope (link, network, network of networks, …).

• There should be no separation between networks and applications.• Which leads us to the principle that : “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


RINA incremental deployment strategy

• The First RINA prototype is being build on top of UDP/IP.

• Based on Java, but applications donʼt need to use Java to interact with it

• The prototype uses underlying IP Networks as if they were the physical media

Physical Media

Applications

IP

Ethernet

Physical Media

Applications

TCP or UDP

IP

Ethernet

Physical Media

Applications

UDP

DIF

DIF…

Ethernet

Physical Media

Applications

DIF

DIF…

Today

First RINA Prototype

More advanced RINA Prototype

Final deployment

DIF

DIF…



• Presentation by Eduard Grasa– “RINA Java Prototype demo and development

plans”


Basic Cloud deployment scenarios

Service Provider

Multi-clouds

Federated clouds

Service ProviderInternal infra-structure

Service Provider

Bursted internal clouds

Infrastructure Provider




Broker

Source: OPTIMIS project



Cloud Provider(A )

Application Model specification

Set of Virtual Computing Resources

Storage Resources

Network topology

Cloud Provider 2

System PortabilityVM Migration

Service MigrationSecure and

Dynamic network configuration

Data Portability and Clustering

Cloud Provider 3

RINA (DIFs)RINA (DIFs)

RINA-enabled experimental network between orgnisations

Source: ATOS


Example deployment of the prototype

• The picture shows two hosts hosting applications A and B (A and B are application names).

• The IPC processes in each DIF are shown with its address (not its application name). As they are internal to each DIF, they can be repeated between DIFs.

• DIFs have a name (it is its distributed application name).

AppA

IPC Proc 1

IPC Proc 2

IPC Proc 3

AppB

IPC Proc 4

IPC Proc 2

IPC Proc 1 DIF AB

Private IP Network Public Internet Private IP Network

IPC Proc 1

IPC Proc 2DIF AC IPC

Proc 1IPC

Proc 2DIF AD

DIF AA

host router router host


IPC Process interface• Provides at least the 4 basic operations:

– int portId = allocate (Source AP name, destination AP name, QoS params)– byte[] pdu = read(portId)– write(byte[] pdu, portId)– deallocate(portId)

• Example (referring to the previous slide)– App A would invoke allocate(A,B,[params])– IPC Process 1 in DIF AA would:

• Query its local directory to find that B is reachable through IPC Process 4• Map the QoS params to one of the QoS cubes (categories) available in DIF AA• Instantiate the Data Transfer Protocol with the right policies to comply with the

selected QoS cube• Send a “Create Flow” request to IPC Process 4 (using the CDAP Protocol)• Upon successful reception of the “Create Flow” response, it notifies App A, passing

it the portId• App A can start reading and writing PDUs


How do apps know what DIF to use ?

• Apps just want to connect to a destination application with a certain QoS, they donʼt have to care through what network they should do it

• Thatʼs the role of the IPC Manager• The IPC Manager redirects the allocate requests from the apps to the

proper DIF• It knows what applications are available on what DIFs

AppA

IPC Proc 1

IPC Proc 1

Private IP Network

DIF AA

DIF AB

AppA

IPC Proc 1

IPC Proc 1

Private IP Network

DIF AA

DIF AB

IPC Manager


IPC Manager implementation

• The IPC Manager will be listening at a well known port for connections at the loopback interface

• Applications wonʼt have to establish the socket connection with the IPC Manager directly, they will use either

– 1) a modified implementation of the Sockets API (provides the same interface than the sockets API but it talks to the IPC Manager instead of the TCP/IP stack). This is for supporting legacy applications without modifying them.

– 2) a native RINA API. Applications modified to use this API (or new apps) can benefit from all the RINA features (call Apps by name, request different QoS options, multi-homing, mobility, …)

• These libraries will initially be available in Java, and later ported to other languages

Application AIPC

Manager

Faux Sockets

API Local socket

Legacy applica?on

Application AIPC

ManagerNative

RINA API Local socket

New (or ported) applica?on


Example deployment for cloud use case

• The distributed apps running at the hosts could choose if they just want flows through DIF AA or if they require a new DIF tailored to its needs (DIF AE in this example).

• You can think of this DIF as a VPN, but more advanced: supporting its own security policies, QoS cubes, routing strategies, …

AppA

IPC Proc 1

IPC Proc 2

IPC Proc 3

AppB

IPC Proc 4

IPC Proc 2

IPC Proc 1 DIF AB

Cloud Provider APrivate IP Network

Public Internet Cloud Provider BPrivate IP Network

IPC Proc 1

IPC Proc 2DIF AC IPC

Proc 1IPC

Proc 2DIF AD

DIF AA

host router router

IPC Proc 1

IPC Proc 2DIF AE

Cloud Provider A Cloud Provider B


Prototype limitations (= research opportunities) !

• Will just support two QoS cubes– 1 equivalent to TCP and 1 equivalent to UDP– Research topic: provide policies that provide support for different QoS

cubes• Has to work on top of UDP/IP

– Research topic: Improve it to run on top of Ethernet, implement the right policies

– Research topic: Prototype on top of wireless (WiFi), implement the right policies

• Addressing is just simple enumeration– Research topic: Topological addressing schemes to optimize routing

• Congestion control not implemented– Research topic: Strategies for congestion control within a DIF.

Influence of congestion control


Prototype limitations (= research opportunities) !

• Rudimentary resource allocation– Research topic: Explore different resource allocation strategies (e.g. to

dimension the different queues, to design the different schedulers, …). Exploit the unification of the connection and connectionless approaches.

• Authentication/Authorization not implemented– Research topic: Plug-in different authentication/authorization schemes and

study their pros&cons, suitability to different apps, …

• Rudimentary management capabilities– The application protocol (management protocol) is there: CDAP, and a

rudimentary DMS (DIF management system) is expected, mainly to manage the instantiation of new DIFs

– Research topic: Complete DMS, what are the required objects, how to design the RIB (Resource Information Base, equivalent to the MIB), exploit the autonomic properties of the DIF for management, …

• And more open areas yet (whatevercast, DIF structures, application naming structures, …)


Implementing RINA

– A detailed overview of RINA innovations and features can be found the Pouzin Society (PSOC) website [ http://www.pouzinsociety.org/ ] and as an example of what we do at the TSSG [http://rina.tssg.org]

• Developing open implementation of RINA within OpenTinos.

• Experimental Sandbox / Testbed– OpenTinos has it origins as a prototype in the EU FP7 research project ICT 4WARD,


http://www.pouzinsociety.org/%255D

http://www.pouzinsociety.org/%255D

http://www.pouzinsociety.org/

http://www.pouzinsociety.org/

http://rina.tssg.org

http://rina.tssg.org

http://www.4ward-project.eu/

http://www.4ward-project.eu/

Miguel Ponce de Leon,Chief Technologist,TSSG, [email protected]+353 51 302952 (w)

www.tssg.org/people/miguelpdltwitter: miguelpdl


mailto:[email protected]

mailto:[email protected]

experiences with implementing rina - recursive inter ...rina.tssg.org › docs ›...

Documents