Experiences with Implementing RINA - Recursive Inter ...rina.tssg.org › docs ›...
Transcript of 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
Wednesday 7 March 2012
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?
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
What about the deep questions?
• John Day will tackle these in his talk this afternoon–“How in the Heck Do You Lose a
Layer!?”
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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).
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
Two applications communicating in the same
system.
• Communication within a Single Processing System
IPC Facility
ApplicationProcesses
PortIds
A BApplication
Flow
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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
Wednesday 7 March 2012
Communication with N Systems
Systems
Wednesday 7 March 2012
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
Wednesday 7 March 2012
The IPC Model(A Purely CS View)
RelayingAppl
EFCPEFCP
EFCP EFCP EFCP EFCP EFCP EFCP
MuxMux
User Applications
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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.
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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…
Wednesday 7 March 2012
RINA incremental deployment strategy
• Presentation by Eduard Grasa– “RINA Java Prototype demo and development
plans”
Wednesday 7 March 2012
Basic Cloud deployment scenarios
Service Provider
Multi-clouds
Federated clouds
Service ProviderInternal infra-structure
Service Provider
Bursted internal clouds
Infrastructure Provider
Infrastructure Provider
Infrastructure Provider
Infrastructure Provider
Broker
Source: OPTIMIS project
Wednesday 7 March 2012
RINA incremental deployment strategy
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
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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
Wednesday 7 March 2012
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, …)
Wednesday 7 March 2012
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,
Wednesday 7 March 2012
Miguel Ponce de Leon,Chief Technologist,TSSG, [email protected]+353 51 302952 (w)
www.tssg.org/people/miguelpdltwitter: miguelpdl
Wednesday 7 March 2012