1. PRISTINE
Perfect Pitch Panel
Net Futures 25th March 2015
Miguel Ponce de Leon
TSSG – Waterford Institute of Technology
Programmability In RINA for European Supremacy of Virtualised
Networks
8. RINA Architecture
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
CACE Enrollment
Flow Allocation
Resource Allocation
Forwarding Table
Generator
Authentication
StateVector
StateVector
StateVector
Data TransferData Transfer
Transmission ControlTransmission Control
Retransmission
Control
Retransmission
Control
Flow Control
Flow Control
13. 2012 2013 2014 2015 2016 2017 2018 2019 20202011
PRISTINE
01/2014-06/2016
National and
Individual projects
(US/EU)
Inter-university RINA
/ IPSec tunnels
Small lab prototypes
Linux kernel
prototype
Mature Linux
kernel prototype
IRATI
01/2013-12/2014
ALL-RINA
networks
Initial specification
(PSOC)
Standardisation
(ISO/SC6)
NREN lab
prototypes
IRINA
10/13-03/14
RINA DIFs
supported
by NRENs
DIFs being
adopted by
Carriers
Future research projects
COTS Commercial products
Niche Commercial products
14. Contact Miguel Ponce de Leon
• Email: miguelpdl@tssg.org
• Tel: +35351302952
• Twitter: @miguelpdl
• Web: https://www.ict-pristine.eu
• Twitter: @ictpristine
Notas do Editor
The Internet is a Cat-o-Net
Cat Videos, Cat Pictures
October 1969, 10:30PM: First message on the ARPANET was sent from UCLA to Stanford
Dec. 5th 1969, ARPANET deployed
Sept. 1971 Connections across America
Sept. 1973 There are International nodes connected to ARPANET
Architecture: Fixed number of layers, each one with their own function -> doesn’t work at all, virtual layers, layers 2.5, etc..
Protocol design: TCP wrongly split from IP (they are not independent) -> IP fragmentation doesn’t work, TCP pseudo-header
Protocol design: No modular protocol design -> every minor difference requires the specification of a full new protocol (e.g. multiple versions of TCP, UDP, etc)
Naming and addressing: No application names, addresses exposed to applications, IP addresses name the same as MAC addresses (an interface), routing on the interface instead of the node, no in-network directories
Congestion control at TCP (worse place to put it since it maximizes time to notify and its variance), and implicit congestion detection -> predatory must cause congestion in order to detect it
Application support: No explicit flow allocation (application has to be aware of transport protocols and statically allocate ports), no support for end-to-end QoS
Security is a chaos, product of the complexity of the design: addresses exposed to applications, no structured approach towards security, so many protocols with so many unforeseen interactions that security is not workable at a reasonable cost
Spoon boy: Do not try and fix the Internet - that's impossible. Instead, only try to realize the truth.
Neo: What truth?
Spoon boy: There is no Internet.
The Internet architecture is proving to have
weak security
scalability issues with the routing system
explosion in the complexity of the overall system
no QoS
But it was built of a network layering idea, which originally come foperating system design
In operating systems, layers are a convenience, one design choice.
In networks, they are a necessity
Started off well, but then got a 7 layer model, 5 layer model and now we have MPLS, VxLAN, GRE Tunnels,
But is there a fixed number of layers ?
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 is recursive.
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 an architecture that scales indefinitely,
The RINA Architecture
DAF Support Tasks:
The IPC Management (and other management: memory, storage, CPU) tasks are usually implemented as OS functionality.
IPC Resource Management: Creation/Deletion of IPC processes
Multiplexing (Usually inverse multiplexing, an application flow into multiple DIF flows, for example: 1 for video, 1 for audio, 1 for text, …)
SDU Protection (CRCs, encryption, TTL, …)
IDD (Inter DIF Directory, find out in what DIF the destination application process is executing)
There are the solutions to the current problems
Application names, hard to fix?
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)
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
Got a solid foundation to work from
PRISTINE will take a major step forward in the integration of networking and distributed computing, by focusing on an IPC approach
PRISTINE will use RINA to develop practical, demonstrable, and commercially exploitable solutions to address existing networking limitations. The project results will showcase the relevance of RINA as the architecture that can best support the distributed computing infrastructure of the coming years, providing theoretical and experimental evidence of its superiority compared to other alternatives and showing potential exploitation paths of the technology in different areas of the market: datacentre networking, distributed cloud overlays, and network service providers
Virtualization is a fundamental inherent attribute of the RINA architecture, and based on this aspect, the PRISTINE project shall:
Design and implement programmable functions for: supporting QoS & congestion control in aggregated levels, facilitating more efficient topological routing, security of content & application processes, providing protection and resilience and unified multi-layer RINA stack management framework for handling network layer configuration, performance and security
Demonstrate the applicability and benefits of this approach and its built-in functions in three use-cases in the environments of a Distributed cloud, Datacenter networking and Network service provider.
What’s the market ?
Much of 2014 was spent discussing software-defined networking (SDN), network functions virtualization (NFV), and other “new” networking technologies.
In short, 2014 was the year we strategically moved pieces around the board, but never reached the point of calling “checkmate.”
“2014 SDN Strategies: North American Enterprise” survey, which estimates that 87% of U.S. businesses intend to have SDN live in their data centers by 2016.
“Carrier SDN and NFV Hardware and Software Market Size and Forecast” report, which predicts that the NFV and SDN markets will reach $11 billion globally in 2018. Along with the major telcos announcing SDN deployments, we’ll also see initial NFV deployments in high-touch enterprises.
The 4K broadcasting standard has been around for some time now, and the TV sets to enable them have been available for a little over a year, but 2015 will see the standard become, well, standard.
As existing mobile networks are increasingly congested and real estate for deploying new macro towers is harder to come by, mobile operators will look to lighten the macro tower traffic load through the rollout of an increased number of small cells—which will also significantly improve overall network coverage,
mobile operators are planning to shift more than 20% of their mobile traffic from the macro network into small cells by 2018. We predict that 2015 will be the year when small cell deployments are widely adopted by mobile operators,
Agile, On-Demand Networks Are Key