RINA: Update on Research and Prototyping Activities
Global Future Internet Summit September 14th, 2012
Eduard Grasa Research Manager @ DANA
Fundació i2CAT
Before we start… our perspective
What is the “Future Internet”? We don’t know, we’re just interested in building better computer networks
and finding out the correct ways of doing so.
Is RINA “clean slate”? We’re retaking the direction of computer network research in the mid-70s,
continuing where INWG left off, and learning from the success and mistakes of 40+ years of computer networking. If we were starting with “no assumptions” we would not be learning from the past (“Those who don’t know history are destined to repeat it”)
What are the design goals of RINA? No design goals, we just look at solving the problem of computer networking
and try to maximize the invariances and minimize the discontinuities. All the results and insights have emerged from listening to the problem.
Do you have all the answers? No way! We’re just beginning to explore the properties of a new paradigm*
that simplifies computer networking by orders of magnitude. Do you want to join us?
2 * Not so new to be honest, initial computer network research (CYCLADES, INWG) was headed in this direction
Outline
Quick Introduction to RINA
Java prototype over IP
Inter DIF Directory
RINA Security Assessment
FP7 IRATI Project: Kernel prototype over Ethernet
3
RINA Architecture
4
• 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. – 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.
© John Day, All Rights Reserved, 2011"
Naming and addressing in RINA All application processes
(including IPC processes) have a name that uniquely identifies them within the application process namespace.
In order to facilitate its operation within a DIF, each IPC process within a DIF gets a synonym that may have be structured to facilitate its use within the DIF (i.e. an address).
5
The scope of an address is the DIF, addresses are not visible outside of the DIF.
The Flow Allocator function of the DIF finds the DIF IPC Process through which a destination Application process can be accessed.
Because the architecture is recursive, applications, nodes and PoAs are relative For a given DIF of rank N, the IPC Process is a node, the process at the layer N+1
is an application and the process at the layer N-1 is a Point of Attachment.
1 2 3 4
1 2 1 2 3 1 2
1 2 1 2
DIF A
DIF B DIF C
DIF D
DIF E DIF F
RINA vs. the current Internet
Architecture: Current: 5/7? layers, layers “2.5”, layer violations, “overlays”, “virtual networks”,
“middleboxes” (NATs, firewalls, application-layer gateways) Getting complex! Unforeseen interactions
RINA: Repeating structure, DIF (one type of layer, repeat as needed)
Naming, addressing and routing: Current: No independent application names, no node names, just PoA names,
routing on PoAs (no wonder why multi-homing and mobility is hard to support)
RINA: Complete naming & addressing, routing on the node; support for multi-homing and mobility without special protocols. No need for global address space.
Congestion control: Current: Put in TCP, the worst place it could be, since it maximizes the delay and
variance of the control loop (makes the system chaotic: self-similar traffic) RINA: Each layer can perform congestion control, confining the effects of
congestion to that layer. The delay and variance of control loops can be bound. 6
RINA vs. the current Internet
Scalability: Current: Limited due to the fixed number of layers in the architecture RINA: Recursion provides a divide and conquer approach, the way to scalability
Security: Current: No systematic approach to security, secure each protocol or add boxes in
between to improve security (firewalls). RINA: Strong design tells you where security functions go in the architecture (see
later in the presentation). DIFs are securable containers.
Quality of Service: Current: Best effort is the dogma, “network neutrality” RINA: Each DIF is free to provide the QoS classes it wants, using different policies for
resource allocation, routing and data transfer
Management: Current: Complex, reflecting the complexity in the architecture and the high
number of protocols. RINA: The commonality in the structure simplifies management by orders of
magnitude, 7
Outline
Quick Introduction to RINA
Java prototype over IP
Inter DIF Directory
RINA Security Assessment
FP7 IRATI Project: Kernel prototype over Ethernet
8
RINA Adoption strategy
Start as an overlay to IP, validate technology, work on initial concepts, develop DIF machinery. Useful by itself: internetwork layer(s), decouple application from infrastructure,
improved application API, support for multi-homing and mobility.
9
IP
Ethernet
Physical Media
Applications
Today
TCP or UDP
IP
Ethernet
Physical Media
Applications
Current Prototype
TCP or UDP
DIF
DIF …
Ethernet
Physical Media
Applications
DIF
DIF …
IP
Physical Media
Applications
TCP or UDP
DIF
DIF …
Physical Media
Applications
DIF
DIF …
End goal
RINA over IP benefits: Internetwork layer(s)
What if application A wants to communicate with Application C? It cannot do it, unless you start deploying middleboxes like NATs, application-layer gateways, …
The architecture doesn’t accommodate internetworking!
10
Data Link Data Link Data Link Data Link Data Link
IP
IP Layer A (Public Internet)
IP
IP Layer B (Enterprise Network)
TCP
Appl. A Appl. B
Data Link Data Link Data Link Data Link Data Link
IP
IP Layer A (Public Internet)
IP
IP Layer B (Enterprise Network)
Shim DIF
Appl. A Appl. B Appl. C
Shim DIF
DIF
TCP
Appl. C
RINA over IP benefits: Separate applications from infrastructure
There is no separate application namespace, but synonyms that stand for an IP address and a TCP/UDP port number:
A path to an application. This makes anything but client/server hard to achieve, e.g. mobility
In RINA application names are independent of the layers below (DIFs) Application names can be structured in a way that makes sense for
the application The application name doesn’t contain the semantics of where the
application is in the network (i.e. what is its point of attachment to the layer below) 11
http://pouzinsociety.org
Synonym of an interface of a host
Port (Endpoint of TCP connection)
:80
RINA over IP benefits: Next generation VPN
DIFs are customizable VPNs that can span multiple IP layers. Each DIF has its own addressing scheme, security mechanisms (authentication,
authorization), routing strategy, resource allocation strategy (support for different levels of QoS), flow control strategy, data transfer/data transfer control, …
Processes (and not systems) are members of the DIFs (different processes can access different DIFs in each system). Processes may not have access to the whole range of DIFs available on their system
DIFs open the door to VPNs optimized for certain applications
12
Data Link Data Link Data Link Data Link Data Link
IP
IP Layer A (Public Internet)
IP
IP Layer B (Enterprise Network)
Shim DIF
Appl. A Appl. B Appl. C
Shim DIF
DIF
Architectural model
DIF
System (Host)
IPC Process
IPC Process
Mgmt Agemt
System (Router)
IPC Process
IPC Process
IPC Process
Mgmt Agemt
System (Host)
IPC Process
IPC Process
Mgmt Agemt
Appl. Process
DIF DIF
Appl. Process
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and Multiplexing
SDU Protection
Transmission Control
Retransmission Control
Flow Control
RIB Daemon
RIB CDAP Parser/Generator
CACEP Enrollment
Flow Allocation
Resource Allocation
Forwarding Table Generator
Authentication
State
Ve
cto
r Sta
te V
ec
tor
State
Ve
cto
r
Data Transfer Data Transfer
Transmission Control
Transmission Control
Retransmission Control
Retransmission Control
Flow Control Flow Control
13
IPC Resource
Mgt.
Inter DIF Directory
SDU Protec
tion
Multiplexing
IPC Mgt. Tasks
Other Mgt. Tasks
Application Specific Tasks
Increasing timescale (functions performed less often) and complexity
The Shim DIF
14
Public Internet Private IP network
“Shim IPC Process”
“Shim IPC Process”
IPC Process
“Shim IPC Process”
IPC Process
IPC Process
“Shim IPC Process”
Shim DIF Shim DIF
DIF
Appl. Process
Appl. Process
UDP flow UDP flow TCP flow(s) TCP flow(s)
The “shim IPC Process” for IP layers is not a “real IPC Process”. It just presents an IP layer as if it was a regular DIF. Wraps the IP layer with the DIF interface. Maps the names of the IPC Processes of the layer above to IP addresses in the
IP layer. Creates TCP and/or UDP flows based on the QoS requested by an “allocate
request”.
Implementation platform
Implemented as part of the TINOS framework (a network protocol experimentation framework) https://github.com/PouzinSociety/tinos
Implemented in Java, using the OSGi technology (OSGi container provided by Eclipse Virgo) OSGi is a component model that facilitates building modular Java
applications
Developed on Mac OS X and Linux Debian, but should be multi-platform (support all the platforms that Eclipse Virgo supports) Found some OS resource allocation issues with Mac OS X
Not yet fully integrated with TINOS (once it is, it will be possible to instantiate several “systems” within a single Java process, using XMPP as the underlying “physical substrate”)
15
Java Virtual Machine
Why using TINOS instead of raw Java? To facilitate experimentation: bigger scenarios without adding more hardware
IP (Jnode)
Data Link Data Link Data Link
Shim DIF
Data Link Data Link
IP (Jnode)
Shim DIF
DIF
Java Virtual Machine
IP (Jnode)
Data Link Data Link Data Link
Shim DIF
Data Link Data Link
IP (Jnode)
Shim DIF
DIF
Java Virtual Machine
Data Link IP (OS stack) Shim DIF
Java Virtual Machine
Data Link
IP (JNode)
Shim DIF
DIF
XMPP network
LAN
With TINOS multiple nodes can be created within the same Java JVM, with different network connectivity with each other and other JVMs (TINOS uses adapted IP stack from JNode and XMPP for this)
Current status & some conclusions
Since all the layers have the same mechanisms with different policies, implementation becomes much simpler than today’s protocol suite(therefore more effort can be devoted to making it more robust and efficient) Also no need to distinguish between ‘physical’ or ‘virtual’ networking protocols: it’s all IPC.
Customization & innovation in networking becomes much easier Just focus on the area you’re interested in and change the relevant policies for yours (NOTE:
Today “changing the policies” in the prototype means modifying the code, since developing a pluggable policy framework is out of the scope of the initial prototype)
Interoperability with existing networking technologies is not an issue Just wrap the XX layer as a shim DIF, and there you go 17
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and Multiplexing
SDU Protection
Transmission Control
Retransmission Control
Flow Control
RIB Daemon
RIB CDAP Parser/Generator
CACE Enrollment
Flow Allocation
Resource Allocation
Forwarding Table Generator
Authentication
State
Ve
cto
r Sta
te V
ec
tor
State
Ve
cto
r
Data Transfer Data Transfer
Transmission Control
Transmission Control
Retransmission Control
Retransmission Control
Flow Control Flow Control
Outline
Quick Introduction to RINA
Java prototype over IP
Inter DIF Directory
RINA Security Assessment
FP7 IRATI Project: Kernel prototype over Ethernet
18
What’s a layer? Although the term “layer” has been extensively used in
networking, the concept itself has not been clearly defined.
In its origin layers were adopted from its use in operating systems. But in operating systems, using layers is a choice, whereas using layers in networks is a necessity because of the distributed shared state of different scopes
The necessary and sufficient condition for a layer is distributed shared state of different scope.
Therefore we can describe a layer as the collection of application processes that share state.
Physical
Data Link
Network
Transport
Application
Host or End System
Router
Less Scope
More Scope
19
Application discovery involves also layer discovery
host H2 router R2 router R3
host H1
Layer 1
web server application
B
web browser
application A
router R4
router R1
host H4
Layer 3 Layer 2 Layer 4
Layer 6
Layer 5
router R5
host H3
web server application
C
20
The InterDIF Directory (IDD)
A distributed application, Distributed Application Facility (DAF) as it’s called in RINA, which is a collection of two or more cooperating application processes in one or more processing systems, which exchange information using IPC and maintain shared state
The IDD DAF maintains a distributed database that keeps mappings of application names to list of supporting layers
The IDD is responsible for two main distinct functions: a) Discovery of the application b) Creation of the supporting DIF
21
A) Discovery of the application (I)
IDD-Request Destination IDD Name, Source IDD Name, Requested Application
Process Name, Access Control Information, Quality of Service, Termination Condition
Forwarding of the request between the peer IDDs until the destination application is found or the pre-defined termination condition is met
host H2 router R2 router R3
host H1
web server application
B
web browser
application A
router R4
router R1
host H4
Layer 6
router R5
host H3
...
Layer 1
Layer 3 Layer 2 Layer 4 Layer 5
IDD DAF
web server application
C
22
A) Discovery of the application (II)
Confirmation that the requested application is executing in the destination system and authorization check that the requesting application has the rights to access it
host H2 router R2 router R3
host H1
web server application
B
web browser
application A
router R4
router R1
host H4
Layer 6
router R5
host H3
...
Layer 1
Layer 3 Layer 2 Layer 4 Layer 5
IDD DAF
web server application
C
23
B) Creation of the supporting DIF
A DIF supporting the communication between the two user applications has to be found
This either involves creating a new DIF from scratch or expanding (joining) an existing one so that it spans from the source to the destination system
host H2 router R2 router R3
host H1
web server application
B
web browser
application A
router R4
router R1
host H4
Layer 6
router R5
host H3
...
Layer 1
Layer 3 Layer 2 Layer 4 Layer 5
IDD DAF
web server application
C
24
Current status
Ph.D. thesis ongoing
Defined the IDD Framework. Current research is focused in application discovery; looking at different policies to perform the IDD search, the replication of the directory information, and compare them in terms of: Time to discover the requested application Average number of messages generated on the IDD DAF per search Average number of hops needed to locate the destination application Time to distribute directory updates, and average number of messages
generated by directory update
Java simulator of the IDD is being implemented. After results have been tested in the simulator, the IDD framework and some selected policies will be ported to the prototypes
25
Outline
Quick Introduction to RINA
Java prototype over IP
Inter DIF Directory
RINA Security Assessment
FP7 IRATI Project: Kernel prototype over Ethernet
26
Benefits of having an architecture instead of a protocol suite: the architecture tells you where security related functions are placed.
Instead of thinking protocol security, think security of the architecture: no more ‘each protocol has its own security’, ‘add another protocol for security’ or ‘add another box that does security’
Allocating a flow to destination application
Access control
Sending/receiving PDUs through N-1 DIF
Confidentiality, integrity
Placement of security related functions
27
N DIF
N-1 DIF
IPC Process
IPC Process
IPC Process
IPC Process Joining a DIF
authentication, access control
Sending/receiving PDUs through N-1 DIF
Confidentiality, integrity
Allocating a flow to destination application
Access control
IPC Process
Appl. Process
Access control (DIF members)
Confidentiality, integrity
Authentication
Access control (Flow allocations to apps)
DIF Operation Logging
DIF Operation Logging
DIFs are securable containers
Master thesis on RINA security assessment (results to be published) Possible attacks to a DIF Information required to perform these attacks Mitigation measures against these attacks Comparison to the current Internet
Concludes that DIFs are securable containers if proper standard security tools are used (authentication, access control, confidentiality, integrity and strong auditing) Securable = A structure used to hold or transport something that can be
made to be not subject to threat
Again, with a proper structure in place, achieving better security in networks is much simpler and cost-effective than in the current situation
28
Outline
Quick Introduction to RINA
Java prototype over IP
Inter DIF Directory
RINA Security Assessment
FP7 IRATI Project: Kernel prototype over Ethernet
29
What? Main goal To advance the state of the art of RINA towards an architecture reference model and
specifications that are closer to enable implementations deployable in production scenarios. The design and implementation of a RINA prototype on top of Ethernet will enable the experimentation and evaluation of RINA in comparison to TCP/IP.
Who? 4 partners
How? Requested 870.000 € funding to the EC to perform 5 activities WP1: Project management WP2: Architecture, Use cases and Requirements WP3: Software Design and Implementation WP4: Deployment into OFELIA testbed, Experimentation and Validation WP5: Dissemination, Standardisation and Exploitation
Project at a glance
Nextworks Interoute
i2CAT
IBBT
Thanks for your attention!
You can contact me at [email protected]
More information about RINA at http://rina.tssg.org, http://pouzinsociety.org, http://csr.bu.edu/rina
More information about the prototype at https://github.com/PouzinSociety/tinos/wiki/RINA-Prototype
More information about IRATI at http://irati.eu