Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Reconstructing computer networking with RINA:
how solid scientific foundations can allow
Europe to become a world leader i...
Three ideas to get out of this tutorial
• Current networking technology hasn’t got solid
foundations
– Just because someth...
WARNING!
• Please, please, please,
interrupt me at any time,
ask questions, etc..
• The goal is not to cover
the whole mat...
DECONSTRUCTING THE INTERNET
RINA Tutorial to the EC 4
1
Lets Get the Bad News
Out of the Way
• The TCP/IP Model is Fundamentally Flawed
– And has been from the Start.
• The Flaws...
What are The Flaws?
• Architecture
– Not Understanding that Layers in Networks aren’t just modules
(circa 1978)
– Lost the...
How Did It Happen?
• To some degree, A Major Factor was the Initial Focus
– The ARPANET and the Internet were production n...
8
The Beads on A String Model
• The Nature of their early technology led the Phone Companies to
Adopt what could be called...
Packet Switching
• In the early 1960s, Paul Baran at The Rand Corporation writes a series
of reports investigating the net...
ARPANET Layers
• The ARPANET was the first, so feeling our way.
• BBN is building the Subnet and it is necessarily somewhe...
But was Packet Switching
a Major Breakthrough?
• Strange as it may seem, it depends.
• During this period many things are ...
CYCLADES was Building a Network
To Do Research on Networks
• The wanted a minimalist network to use as a research tool.
• ...
The Cyclades Architecture
(1972)
• CYCLADES brings the layering from operating systems, but changes it.
• Data Link – corr...
The New Model Had 4 Characteristics
• It was a peer network of communicating equals not a hierarchical
network connecting ...
After ICCC’72, the Research Networks formed INWG* to develop
an Internet Transport Protocol
There Were Two Proposals
• INW...
After a Hot Debate
• A Synthesis was proposed: INWG 96
• There was a vote in 1976, which approved INWG 96.
• As Alex says,...
The Similarity Among all 3
Is Much More Interesting
• This is before IP was separated from TCP. All 3 of the Proposed
Tran...
Internet Model (1976)
• An Internet Layer addressed Hosts and Internet Gateways.
• Several Network Layers of different sco...
• It is not obvious.
• At first glance, one might say the Network Layer.
– After all the Protocol is called IP!
– Removing...
TCP Was Split the Wrong Way
• A Careful Analysis of this Class of Protocols shows that the
Functions naturally cleave (ort...
Watson’s Insight (1978)
• Richard Watson proves that the necessary and sufficient conditions
for distributed synchronizati...
Computer Networks are not
DataComm Networks
• In telephony and datacom networks everyone did addressing by just
numbering ...
Making the Generality
• Directory provides the mapping between Application-Names and the node
addresses of all Application...
Not in the Internet
• The Internet only has a Point of Attachment Address, an interface.
– Which is named twice!
– No wond...
IPv6: Makes Matters Worse
• Primary Problem: Router Table Size; secondarily address exhaustion.
• 1992 Rejection of IPv7 (...
Then in ‘86: Congestion Collapse
• Caught Flat-footed. Didn’t realize it could happen.
• Implies didn’t understand the rat...
Congestion Control in an Internet is
Clearly a Network Problem
• With an Internet Architecture, it clearly goes in the Net...
Would be Nice to Manage the Network
• All Management is Overhead! We need to minimize it.
– Then need Efficiency, Commonal...
But What About Security?
• Security?
• Don’t you read the papers?!
– It is terrible! And all signs are getting worse.
– IP...
So Why Is TCP/IP Dominant?
• The Usual Reason:
• He with the deepest pockets wins.
– Especially when it is someone else’s ...
Want to Feel Really Bad?
• A New eBook* James Pelkey’s "Entrepreneurial Capitalism and
Innovation: A History of Computer C...
• With a Transport Layer, this is the same as the INWG model.
• OSI stayed the course with a similar split to TCP/IP.
• So...
• INWG and OSI where on the right track, but did not see the repeating pattern
and generalize it…
• Doesn’t seem to be, wh...
INTRODUCING RINA
RINA Tutorial to the EC 45
2
RINA Architecture
• A structure of recursive layers
that provide IPC (Inter
Process Communication)
services to application...
47
Naming and addressing in RINA
• All application processes
(including IPC processes) have
a name that uniquely identifie...
That’s Pretty Bleak
The Good News Better Be Pretty Good
• Actually, It Is. In fact, very good.
• Networking is far simpler...
Just That Yields
• Multihoming for free; yields better resiliency, faster fail over, and of
course, routing tables 3 – 4 t...
But There is More!
• Separating mechanism and policy implies one data
transfer protocol and one application protocol.
– La...
Not Just a Network Model
• A Layer is a Distributed Application that Does IPC
• That Forced Us to Answer: What is a Distri...
What a Layer Looks Like
• Processing at 3 timescales, decoupled by either a State Vector or a Resource
Information Base
– ...
Only Three Kinds of Systems
• Middleboxes? We don’t need no stinking middleboxes!
• NATs: either no where or everywhere,
•...
All Communication goes through Three Phases
• Enrollment
– Operations to create sufficient state within the network to all...
How Does It Work?
Enrollment or Joining a Layer
• Nothing more than Applications establishing communication (for
managemen...
How Does It Work?
Establishing Communication
• Simple: do what IPC tells us to do.
– A asks IPC to allocate comm resources...
Routing at Different Layers
• With a Recursive Model, there are levels of routing with border
routers acting as the step-d...
Implications of the Model & Names
(Routing Table Size)
• Recursion either reduces the number of routes or shortens them.
B...
This Bounds Router Table Size
• There will be Natural Subnets within a layer around the Central Hole.
• Each can be a rout...
Names & Implications of the Model
(Basics)
• We have made a big deal of node and point of attachment, but they are
relativ...
.
Implications of the Model & Names
(Multihoming)
• Yea, so? What is the big deal? It just works
– PDU arrives at an (N-1)...
Consider the Following Network
• Since we want to emphasize that we are naming interfaces, lets
give addresses to each of ...
© John Day, 2014
Rights Reserved
63RINA Tutorial to the EC
A PDU is Sent With
Destination Address 9 From A
• A consults its Forwarding Table and sends it on outgoing address 1,
next...
What Happens When Link From F to H
Fails?
• What happens if Link with address 9 goes down?
– In a few 10s of ms, a routing...
Consider the Following Network
With Node Addresses
• Since we want to emphasize that we are naming nodes, lets just use
th...
© John Day, 2014
Rights Reserved
67RINA Tutorial to the EC
Sending a PDU from A to H
• A has a PDU addressed to H:
– A consults its Forwarding Table and sends the PDU on interface 2...
What Happens When Link From F to H
Fails?
• What happens if just after the PDU is sent the Link from F to H fails?
– In a ...
Comments on the Example
• One of the excuses for not solving this a long time ago was:
only a few needed it so the burden ...
Names & Implications of the Model
(Mobility)
• Yea, so? What is the big deal?
– It just works just like multihoming only t...
Implications of the Model & Names
(Choosing a Layer)
• In building the IPC Model, the first time there were multiple DIFs ...
Implications of the Model & Names
(A DIF Allocator)
• A DIF-Allocator incorporating a Name Space Management function
deter...
So a Global Address Space is Not Required but
Neither is a Global Application Name Space
Inter-DIF
Directory
To Peers
In O...
Scope is Determined by the
Chain of Places to Look
• The chain of databases to look for names determines the
scope of the ...
“Internet” Congestion Control
• Congestion Control has been a known issue since 1972.
– Except in the Internet who only di...
How Does It Work?
“Congestion Control”
• Congestion Control in TCP was always known to be a stop-gap.
• A DIF always has t...
How Does It Work?
Security
• A Hacker in the Public Internet cannot connect to an Application in another
DIF without eithe...
The Recursion Provided Isolation
• Security by isolation, (not obscurity)
• Hosts can not address any element of the ISP.
...
82
• Benefits of having an architecture instead of a protocol suite: the
architecture tells you where security related fun...
A Very Unexpected Result
• A DIF with no explicit security mechanisms is inherently
more secure than the current Internet ...
Other Things Fall Into Place
• Data Transfer in RINA is based on Delta-t (Watson, 1980)
• Lot has happened in 30 years, ma...
Decoupling Port Allocation and
Synchronization
• No Way to Know What CEP-ids are Being Used, Since There is
No Relation Be...
RINA is Inherently More Secure
and Less Work
• A DIF is a Securable Container. (Small, 2011)
– What info required to mount...
Internet RINA
Protocols 8 0
Non-Security
Mechanisms
59 0
Security Mechanisms 28 7
To Add
Security
© John Day, 2014
Rights ...
Why Is Internet Security So Bad?
• The Standard Rationale One Sees is that They Didn’t Think
About It at the Beginning.
– ...
IMPLICATIONS AND IMPACT
RINA Tutorial to the EC 91
3
SIMPLER, CHEAPER, MORE
PREDICTABLE NETWORKS
T-5 Alternatives to TCP/IP 92
Simpler networks
• Clean and simple structure at the macro-level: single type
of layer that repeats as needed, uniform API...
Network layers today (example)
Host
Enterprise router
IEEE 802.3 (Ethernet)
Enterprise router
TCP/UDP
App
A
Application
A
...
Network layers with RINA (example)
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
DIF
App
A
The laye...
Simpler networks (II)
• Each layer has the same components and structure,
programmable via “policies” to optimize each lay...
Internal structure of an IPC Process
IPC
Process
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiti...
Service Provider Networks
Example scenario (Fixed networks)
Border
RouterHost
Home /Enterprise DIF
Customer network
(Simpl...
Backbone DIF
Regional
DIF
SubDIF 1
Subnetwork 2
SubDIF 3
SubDIF 4Access DIF
Access DIF
Interior
Router
Service Provider Ne...
E-mall
DIF
E-mall
DIF
Metropolitan DIF
Connectivity graph and example policies
• Supports different “e-malls” – DIFs desig...
Regional DIF
Connectivity graph and example policies
• Provides connectivity to the different subDIFs of the metropolitan ...
Backbone DIF
Connectivity graph and example policies
• Provides connectivity to the different subDIFs of the regional DIF....
INTERNETWORKING
103
How Does It Work?
The Internet and ISPs
• The Internet floats on top of ISPs, a “e-mall.”
– One in the seedy part of town,...
How Does It Work?
The Internet and ISPs
• But there does not need to be ONE e-mall.
– You mean!
• Yes, it is really an INT...
How Does It Work?
The User’s Perspective
In this case, one host on the local network chooses to join
one of the available ...
5G
107RINA Tutorial to the EC
Why do we have a separate
mobile network architecture?
• RINA can be used to design and build mobile access
networks, no n...
Border
Router
Service Provider Networks
Example scenario (Mobile networks)
P2P DIF
Metro DIF
Provider Fixed Network
(neckl...
Radio Access DIF and District DIF
Example connectivity graphs
Multi-homed host
BR
BS
H H H
BS
H
Metro
DIF
Metro
DIF
Metro
...
E-mall
DIF
Metro DIF and Regional DIF
Example connectivity graphs
METRO DIF
H = IPCP at Host
BR = IPCP at Border Router
H ...
Mobility, what is needed?
• Nothing new!
• Enrollment to new DIFs follows usual procedures
• Allocation of flows follows u...
QUALITY OF SERVICE, NET
NEUTRALITY
113RINA Tutorial to the EC
Net neutrality (I)
• Lots of definitions, but the aim is protecting the user/consumer.
As with other businesses, it should...
Net neutrality (II)
• What matters is that (as in any other business)
– Operators have a clear service offering, based on
...
Propagating QoS requirements through
the layers
RINA tutorial to the EC 116
Host
Border router Interior Router
DIF
DIF DIF...
DEPLOYING RINA TODAY
117RINA Tutorial to the EC
Transition? No, Adoption
Public Internet
Rina Provider
RINA Network
RINA ApplicationsRINA supported Applications
• Adopt. ...
Shim DIFs
General requirements
• The task of a shim DIF is to put a small as possible veneer over a
legacy protocol to all...
Shim DIF over 802.1Q
Environment
• (Disclaimer: Other shim DIFs over Ethernet are possible: with no
VLANs; using LLC; over...
Shim DIF over TCP/UDP
• Wraps an IP network with the DIF IPC API
• Two QoS cubes possible: reliable and in-order-delivery ...
RINA under IP
• RINA-based ISP, internal layers are RINA, can transport IP
(can be treated as just another app) and/or oth...
Faux sockets API
An aid to adoption
• Sockets API implementation that internally maps sockets
API calls to RINA IPC API ca...
RINA STATUS, HOW CAN THE EC HELP
MOVE RINA FORWARD?
RINA Tutorial to the EC 124
4
RINA state of the art
• Draft RINA reference model and specifications
• Theoretical and experimental research on RINA prop...
Flow of RINA R&D activities
126
Prototyping & Tool
Development
Different
Platforms
Java
VM
Linux
OS
Android
OS
NetFP
GA
Co...
IRATI @ a Glance
• What? Main goals
– To advance the state of the art of RINA towards an architecture
reference model and ...
128
IRATI contributions to RINA roadmap
• Reference model and core specifications
– Detect inconsistencies and errors
• Re...
PRISTINE @ a Glance
• What? Main goals
– To design and develop an SDK for the IRATI RINA prototype, to unleash the program...
130
PRISTINE contributions to RINA roadmap
• Reference model and core specifications
– Detect inconsistencies and errors
•...
131
IRINA @ a glance
• What? Main goals
– To make a study of RINA against the current networking state of the art and
the ...
132
IRINA contributions to RINA roadmap
• Reference model and core specifications
– Compare with other architectures
• Use...
Open source IRATI
133
• IRATI github side
• http://irati.github.io/stack
• Hosts code, docs, issues
• Installation guide
•...
How could the EC contribute? (I)
• In general
– Get more informed on RINA and potential impacts. Don’t
believe it: underst...
How could the EC contribute? (II)
• Operating Systems Research
– Recursive Operating Systems would also simplify current O...
Thanks for your attention!
ict-pristine.eu
pouzinsociety.org
@ictpristine
@iratiproject
Upcoming SlideShare
Loading in …5
×

Reconstructing computer networking with RINA: how solid scientific foundations can allow Europe to become a world leader in internetworking

1,545 views

Published on

Reconstructing computer networking with RINA: how solid scientific foundations can allow Europe to become a world leader in internetworking, RINA tutorial to the EC

Published in: Internet
  • Be the first to comment

Reconstructing computer networking with RINA: how solid scientific foundations can allow Europe to become a world leader in internetworking

  1. 1. Reconstructing computer networking with RINA: how solid scientific foundations can allow Europe to become a world leader in internetworking European Commission. Brussels, June 25th 2015 Eduard Grasa, Sergi Figuerola (Fundació i2CAT) With slides and input from John Day, IRATI and PRISTINE consortiums
  2. 2. Three ideas to get out of this tutorial • Current networking technology hasn’t got solid foundations – Just because something is widely used and deployed it doesn’t mean it’s a good technical solution • There is a scientific alternative based on a sound theory, which yields cheaper, simpler, more performing, predictable and reliable networks • Europe has an incredible opportunity to lead this distributed computing and networking revolution, which could impact Europe’s Distributed computing & Telecom industry in a massive way RINA tutorial to the EC 2 1 2 3
  3. 3. WARNING! • Please, please, please, interrupt me at any time, ask questions, etc.. • The goal is not to cover the whole material, but that you understand some/most of the points supporting the three previous ideas RINA tutorial to the EC 3
  4. 4. DECONSTRUCTING THE INTERNET RINA Tutorial to the EC 4 1
  5. 5. Lets Get the Bad News Out of the Way • The TCP/IP Model is Fundamentally Flawed – And has been from the Start. • The Flaws are sufficiently deep that either they are not technically correctable or the socio-political will is not there. • And a bit of myth-busting: – The Internet was not based on the ARPANET. – It was built on the ARPANET, but it was based on CYCLADES. – Packet Switching was obvious (depending on your age). ;-) – Datagrams were far from obvious and a major insight. RINA Tutorial to the EC © John Day, 2014 Rights Reserved 5
  6. 6. What are The Flaws? • Architecture – Not Understanding that Layers in Networks aren’t just modules (circa 1978) – Lost the Internet Layer (~ 1983) – After an early concern with security (<1974), by the late 70s nobody cared. • Naming and Addressing – A IP address names the interface rather than the node (1972, ‘78, ‘92) – Failure to create a complete addressing architecture (circa 1980) • Protocol Design – Of the 4 protocols that could have become dominant, TCP was the worst choice – Failure to incorporate Watson’s discovery (1979) – An approach to congestion avoidance that causes congestion, thwarts any attempt at QoS, and is predatory (1986). The icing on the cake. • The Problems seen today are mainly Consequences of these more Problems. RINA Tutorial to the EC © John Day, 2014 Rights Reserved 6
  7. 7. How Did It Happen? • To some degree, A Major Factor was the Initial Focus – The ARPANET and the Internet were production networks to lower the cost of research on other topics; – Whereas the focus of CYCLADES was a network to do research on networks • A Major Politico-Economic War between Computer Companies and PTTs, Europe vs the US vs Japan and everyone against IBM. – Traditional “beads-on-a-string” vs a more computing model of networking • The usual reasons: hubris, tradition, NIH, and an attitude of “if ‘they’ did it we won’t.” • That’s a bit too brief, so let me elaborate just a bit. RINA Tutorial to the EC © John Day, 2014 Rights Reserved 7
  8. 8. 8 The Beads on A String Model • The Nature of their early technology led the Phone Companies to Adopt what could be called, a “Beads-on-a-String” architecture. – Deterministic, Hierarchical, master/slave. • Perfectly reasonable for what they had. • The model not only organized the work, – But was also used to define markets: Who got sell what. – This was what was taught in most data comm courses prior to the 1980s. • And for some, in a fundamental sense, never left. phone CO CO phone © John Day, 2014 Rights Reserved RINA Tutorial to the EC
  9. 9. Packet Switching • In the early 1960s, Paul Baran at The Rand Corporation writes a series of reports investigating the networking requirements for the DoD. • Donald Davies at NPL in the UK had the same idea • He finds that the requirements for data are very different than those for voice. • Data is bursty. Voice is continuous. • Data connections are short. Voice connections have long durations. • Data would be sent in individual packets, rather than as continuous stream, on a path through the network. • Packet switching is born and • By the late 1960s, the Advance Research Projects Agency decides building one would reduce the cost of research and so we have the ARPANET. 9RINA Tutorial to the EC © John Day, 2014 Rights Reserved
  10. 10. ARPANET Layers • The ARPANET was the first, so feeling our way. • BBN is building the Subnet and it is necessarily somewhere between a traditional data comm network and a new packet network, but there are no layer diagrams of it. • So everyone just sees layers in the host as modularity. • But with the advantage of an example and a lot collaboration with BBN Physical IMP-Host Host-Host (NCP) Telnet File Transfer Physical IMP-Host Host-Host (NCP) Telnet File Transfer IMP Subnet
  11. 11. But was Packet Switching a Major Breakthrough? • Strange as it may seem, it depends. • During this period many things are age dependent. • If your formative years had occurred prior to the mid-60s (pre- boomer), your model of communication was defined by telephony. – Then this is revolutionary. • If you are younger (boomer), your model is determined by computers. – Data is in buffers, How do you do communications: • Pick up a buffer and send it. – What could be more obvious! • That it was independently invented (and probably more than twice) supports that. • But there was a more radical idea coming! 12RINA Tutorial to the EC © John Day, 2014 Rights Reserved
  12. 12. CYCLADES was Building a Network To Do Research on Networks • The wanted a minimalist network to use as a research tool. • They too saw layering as a good tool for structuring the problem. • Elie and Zimmermann realized that layers in networks were not only different, but a necessity. • Layers are a loci of distributed shared state with different scopes • At the very least, differences of scope require different layers. • This property makes the earlier “beads-on-a-string” model untenable. • Talk of control and data planes is beads-on-a-string. • Not looking at layers like this underpins many other problems. Host or End System Router Increasing Scope © John Day, 2014 Rights Reserved 13RINA Tutorial to the EC
  13. 13. The Cyclades Architecture (1972) • CYCLADES brings the layering from operating systems, but changes it. • Data Link – corrects media errors, not propagated to a wider scope. • Network – relays using a connectionless datagram network, Cigale • Transport recovers from loss due to congestion creating a reliable flow. • Yielding a simpler, cheaper, more effective and robust data network. • Since the Hosts won’t trust the network anyway, the network does not have to be perfect, (and can’t be); it makes a “Best-Effort; need only be sufficiently reliable to make end-to-end cost effective • This represents a new model, in fact, a new paradigm completely at odds with the beads-on-a-string model. Physical Data Link Network Transport Application Host or End System Router TS: End-to-End Reliability Cigale Subnet © John Day, 2014 Rights Reserved 15RINA Tutorial to the EC
  14. 14. The New Model Had 4 Characteristics • It was a peer network of communicating equals not a hierarchical network connecting a mainframe master with terminal slaves. • The approach required coordinating distributed shared state at different scopes, which were treated as black boxes. This lead to the concept of layers being adopted from operating systems and • There was a shift from largely deterministic to non-deterministic approaches, not just with datagrams in networks, but also with interrupt driven, as opposed to polled, operating systems, and physical media like Ethernet, and last but far from least, • This was a computing model, a distributed computing model, not a Telecom or Data comm model. The network was the infrastructure of a computing facility. • These sound innocuous enough. They weren’t. • They were a direct threat to the business models of IBM and PTTs © John Day, 2014 Rights Reserved 16RINA Tutorial to the EC
  15. 15. After ICCC’72, the Research Networks formed INWG* to develop an Internet Transport Protocol There Were Two Proposals • INWG 39 based on the early TCP and • INWG 61 based on CYCLADES TS. • And a healthy debate, see Alex McKenzie, “INWG and the Conception of the Internet: An Eyewitness Account” IEEE Annals of the History of Computing, 2011. • Two sticking points – How fragmentation should work – Whether the data flow was an undifferentiated stream or maintained the integrity of the units sent (letter). • These were not major differences compared to the forces bearing down on them. © John Day, 2014 Rights Reserved 17RINA Tutorial to the EC
  16. 16. After a Hot Debate • A Synthesis was proposed: INWG 96 • There was a vote in 1976, which approved INWG 96. • As Alex says, NPL and CYCLADES immediately said they would convert to INWG 96; EIN said it would deploy only INWG 96. • “But we were all shocked and amazed when Bob Kahn announced that DARPA researchers were too close to completing implementation of the updated INWG 39 protocol to incur the expense of switching to another design. As events proved, Kahn was wrong (or had other motives); the final TCP/IP specification was written in 1980 after at least four revisions.” – Neither was right. The real breakthrough came two years later. • But the differences weren’t the most interesting thing about this event. © John Day, 2014 Rights Reserved 18RINA Tutorial to the EC
  17. 17. The Similarity Among all 3 Is Much More Interesting • This is before IP was separated from TCP. All 3 of the Proposed Transport Protocols carried addresses. • This means that the Architecture that INWG was working to was: • Three Layers of Different Scope each with Addresses. • If this does not hit you like a ton of bricks, you haven’t been paying attention. • This is NOT the architecture we have. Internetwork Transport Layer Network Layer Data Link Layer © John Day, 2014 Rights Reserved 19RINA Tutorial to the EC
  18. 18. Internet Model (1976) • An Internet Layer addressed Hosts and Internet Gateways. • Several Network Layers of different scope, possibly different technology, addressing hosts on that network and that network’s routers and its gateways. – Inter-domain routing at the Internet Layer; Intra-Domain routing at the Network Layer. • Data Link Layer smallest scope with addresses for the devices (hosts or routers) on segment it connects • The Internet LOST A LAYER!! Data Link Network Internet Transport Application HostInternet Gateways Data Link Network Internet Transport Application Host Network 1 Network 2 Network 3 © John Day, 2014 Rights Reserved 20RINA Tutorial to the EC
  19. 19. • It is not obvious. • At first glance, one might say the Network Layer. – After all the Protocol is called IP! – Removing the ARPANET, “removed” the Network Layer, – Everything just dropped down. • But the IP Address names the Interface, something in the layer below, just like ARPANET addresses did! – More like IP replaced the ARPANET. – At best, IP names a network entity of some sort, at worst, a data link entity – Actions speak louder than words • We must conclude that, . . . So What Layer Did They Lose? They Lost the Internet Layer!!! © John Day, 2014 Rights Reserved 24RINA Tutorial to the EC MAC TCP An Ethernet IP PPP TCP MAC IP IP MAC TCP PPP IP IP MAC TCP IP An Ethernet Leased Line HostHost Router Router
  20. 20. TCP Was Split the Wrong Way • A Careful Analysis of this Class of Protocols shows that the Functions naturally cleave (orthogonally) along lines of Control and Data. – This also facilitates the separation of mechanism and policy • In this case, the Fragmentation problem simply doesn’t occur. • All of the other proposals made this Split between Control and Data. Relaying/ Muxing Data Transfer Data Transfer Control Delimiting Seq Frag/Reassemb SDU Protection Retransmission and Flow Control © John Day, 2014 Rights Reserved 25RINA Tutorial to the EC
  21. 21. Watson’s Insight (1978) • Richard Watson proves that the necessary and sufficient conditions for distributed synchronization requires only that 3 timers are bounded: • Maximum Packet Lifetime • Maximum number of Retries • Maximum time before Ack • Develops delta-t to demonstrate the result, which has some unique implications: – Assumes all connections exist all the time. – TCBs are simply caches of state on ones with recent activity • Watson shows that TCP has all three timers and more. – delta-t is more robust under harsh conditions and more secure than TCP. – SYNs, FINs are unnecessary. • Also defines the bounds of networking or InterProcess Communication: – It is IPC if and only if Maximum Packet Lifetime can be bounded. – If MPL can’t be bounded, it is remote storage. © John Day, 2014 Rights Reserved 26RINA Tutorial to the EC
  22. 22. Computer Networks are not DataComm Networks • In telephony and datacom networks everyone did addressing by just numbering the ports or the wires coming from the switches, the end devices were simple and mostly passive. – So Did BBN, we were IMP 12. • But in a network of peers, end-devices were “participants” in the network. • Then Tinker AFB joined the ‘Net exposing the multihoming problem. • This looks like two hosts to the network. It doesn’t know the two wires go to the same place. • Need to name the node and only name the interface if it has multiple destinations. – Everyone else got this right: XNS, CYCLADES, DECNET, OSI, etc. 8 6 Host IMP IMP © John Day, 2014 Rights Reserved 27RINA Tutorial to the EC
  23. 23. Making the Generality • Directory provides the mapping between Application-Names and the node addresses of all Applications reachable without an application relay. • Routes are sequences of node addresses used to compute the next hop. • Node to point of attachment mapping for all nearest neighbors to choose path to next hop. (Because there can be multiple paths to the next hop.) • This last mapping and the Directory are the same: – Mapping of a name in the layer above to a name in the layer below of all nearest neighbors. Here And Here Directory Route Path Application Name Node (Logical Address) Point of Attachment (Physical Address) © John Day, 2014 Rights Reserved 29RINA Tutorial to the EC
  24. 24. Not in the Internet • The Internet only has a Point of Attachment Address, an interface. – Which is named twice! – No wonder there are addressing problems • There are no node addresses or application names. – Domain names are macros for IP addresses – Sockets are Jump points in low memory – This is why mobility is so hard. MAC Address IP Address Socket (local) Application Application Name Node Address Point of Attachment Address As if your computer worked only with absolute memory addresses. (kinda like DOS, isn’t it?) © John Day, 2014 Rights Reserved 30RINA Tutorial to the EC
  25. 25. IPv6: Makes Matters Worse • Primary Problem: Router Table Size; secondarily address exhaustion. • 1992 Rejection of IPv7 (CLNP), which named the node and was already deployed and operational in the routers. (the transition was over.) – By continuing to name the interface, avoided reducing router table size by a factor 3 – 4 times (as well as address usage) Reducing router table size was Major Problem – This decision above all was totally irresponsible, but typical of mob rule – Not only does it make multihoming impossible, but makes mobility the cumbersome mess MIPv6 creates. – Long list of problems today, and loc/id split only dug the hole deeper. • But did get more addresses, but can only route on /64, the rest are for NSA. – Barely able to route 1 IPv4 address space, no idea how to route 4.3 billion. – But that is okay, as we will see a global address space is unnecessary in a well-formed architecture. (More addresses isn’t a problem). • Yes, there is good news a-comin’! 31RINA Tutorial to the EC
  26. 26. Then in ‘86: Congestion Collapse • Caught Flat-footed. Didn’t realize it could happen. • Implies didn’t understand the rationale for Transport when e2e paper was written • Why? Everyone knew about this? – Had been investigated for 15 years at that point • Most important property of any congestion control scheme is minimizing time to notify. Internet maximizes it and its variance. • Strong oscillations by TCP, thwarts any to attempt to provide QoS • And implicit detection makes it predatory. – Virtually impossible to fix • Whereas, © John Day, 2014 Rights Reserved 34RINA Tutorial to the EC
  27. 27. Congestion Control in an Internet is Clearly a Network Problem • With an Internet Architecture, it clearly goes in the Network Layer – Which was what everyone else thought. • Time to Notify can be bounded and with less variance. • Explicit Congestion Detection confines effects to a specific layer in a specific network, allows different strategies for different QoS Classes • I don’t see any way out of this in the current ‘Net that isn’t very painful! This may be worse than the addressing problems. Data Link Network Internet Transport Application HostInternet Gateways Data Link Network Internet Transport Application Host Network 1 Network 2 Network 3 © John Day, 2014 Rights Reserved 35RINA Tutorial to the EC
  28. 28. Would be Nice to Manage the Network • All Management is Overhead! We need to minimize it. – Then need Efficiency, Commonality, Minimize Uncertainty • With a choice between a object-oriented protocol (HEMS) and a “simple” approach (SNMP), IETF goes with “simple” to maximize inefficiency – Must be simple, has Largest Implementation of the 3: SNMP, HEMS, CMIP. – Every thing about it contributes to inefficiency • UDP maximizes traffic and makes it hard to snapshot tables • No means to operate on multiple objects (scope and filter). Can be many orders of magnitude more requests • No attempt at commonality across MIBs. • Polls?! Assumes network is mostly failing! • Use BER, with no ability to use PER. Requests are 50% - 80% larger • Not secure, can’t use for configuration © John Day, 2014 Rights Reserved 36RINA Tutorial to the EC
  29. 29. But What About Security? • Security? • Don’t you read the papers?! – It is terrible! And all signs are getting worse. – IPsec makes IP connection-oriented, so much for resiliency to failure. – Everything does their own, so very expensive. • Privacy? Can’t fix it, so same reaction as for QoS – You don’t need it in the brave new world. • They say the Reason is that Never Considered It at the Beginning. – Later we will see how ignoring security can lead to better security. • There have been a lot of “after the fact” attempts to improve it. – With the usual results: greater complexity, overhead, new threats. © John Day, 2014 Rights Reserved RINA Tutorial to the EC 38
  30. 30. So Why Is TCP/IP Dominant? • The Usual Reason: • He with the deepest pockets wins. – Especially when it is someone else’s money. • DARPA was spending orders of magnitude more on networking than everyone else combined and then gave it away for free. – Even then, it was loose change to the DoD • Believe it or not, there is strong evidence that business left to its own devices would have come very close to getting it right. – Not entirely, but close enough to be fixed. © John Day, 2014 Rights Reserved RINA Tutorial to the EC 39
  31. 31. Want to Feel Really Bad? • A New eBook* James Pelkey’s "Entrepreneurial Capitalism and Innovation: A History of Computer Communications, 1968-1988” paints a different picture: – First companies were developing LAN products • Workstations coming in but SNA is still dominant – Then products to connect LANs together in the workplace. • Novell and others are making inroads. – Then connecting LANs over distances to create corporate networks. • Corporations were concerned about security and wanted their own networks – By the late-80s, corporations wanted their suppliers on their networks. – The next step would have been so many corporate networks wanting their suppliers on them, that it would have been advantageous to have a single network connecting the corporate networks. – Notice this is a natural progression to the INWG Model. • How Do I Know This is What Would Have Happened? – Because It Did. In the Middle of this is dumped free software and a subsidized ISP but with a flawed architecture and a lot of hype: The Internet!! © John Day, 2014 Rights Reserved RINA Tutorial to the EC 41
  32. 32. • With a Transport Layer, this is the same as the INWG model. • OSI stayed the course with a similar split to TCP/IP. • So OSI had an Internet Architecture and the Internet has a Network Architecture. • And signs of a repeating structure. Transport Layer Subnet Independent Subnet Dependent Subnet Access Data Link LLC Data Link MAC The OSI network layer was soon subdivided into 3 layers Relaying and multiplexing Error and flow control Relaying and multiplexing Error and flow control Relaying and multiplexing Error and flow control Data link scope Network scope Internetwork scope OSI also came to the INWG model 43
  33. 33. • INWG and OSI where on the right track, but did not see the repeating pattern and generalize it… • Doesn’t seem to be, what about VPNs over the Internet? – Another layer on top of the Internet • What about virtual networking? (e.g. VXLAN, STP, etc.) • What about an internetwork of internetworks? • There doesn’t seem to be a fixed number of layers, it all depends on the scenarios and use cases. Therefore the fundamental architecture of computer networks is… Internet Gateways Data Link Network Internet Application Data Link Network Internet Application Net 1 Net 2 Net 3 Host Host So is this the definitive architecture? © John Day, 2014 Rights Reserved RINA Tutorial to the EC 44
  34. 34. INTRODUCING RINA RINA Tutorial to the EC 45 2
  35. 35. RINA Architecture • 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, 2014 Rights Reserved RINA Tutorial to the EC
  36. 36. 47 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 be structured to facilitate its use within the DIF (i.e. an address).  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 21 2 DIF A DIF B DIF C DIF D DIF E DIF F RINA Tutorial to the EC
  37. 37. That’s Pretty Bleak The Good News Better Be Pretty Good • Actually, It Is. In fact, very good. • Networking is far simpler, less complex, more secure, considerably more powerful and far less cost both capex and opex. • It turns out there aren’t 5 or 7 layers, but 1 that repeats. • Networking is Interprocess Communication (IPC) and only IPC. • A Layer provides and manages IPC for a range of bandwidth, QoS and Scale, it is a unit of resource allocation. © John Day, 2014 Rights Reserved RINA Tutorial to the EC 48
  38. 38. Just That Yields • Multihoming for free; yields better resiliency, faster fail over, and of course, routing tables 3 – 4 times smaller without doing anything. • Mobility is free (Just multihoming with more frequent failures): no special protocols required, no home routers, no foreign routers and no tunnels to be created. – Much, much simpler and more secure, because • The layer is a securable container eliminating the need for firewalls, and with the repeating structure far less expensive. • Recursion allows the impact of changing addresses on mobile hosts to scale. • Recursion allows arbitrarily Bounding Router Table Size • Most addresses belong to the owner of the Network, little need of a central authority. • Congestion control is done within QoS classes, so is not one size impacts all and tighter QoS classes. • Commonality across layers makes management simpler, more effective and efficient. Less expensive staff needed. © John Day, 2014 Rights Reserved RINA Tutorial to the EC 49
  39. 39. But There is More! • Separating mechanism and policy implies one data transfer protocol and one application protocol. – Layers are tailored to the needs of their networks, not the vendors – Applications can be created and deployed faster and at much less cost. • A complete naming and addressing architecture that allows application name space to have greater scope than any address space and not requiring applications to figure out what “wire” or what network an application is on implies a Global Address space is not necessary. – This is huge. This opens the door for infinite routing with small addresses and with greater security. Address spaces of limited scope can contain bad guys and isolate. © John Day, 2014 Rights Reserved RINA Tutorial to the EC 50
  40. 40. Not Just a Network Model • A Layer is a Distributed Application that Does IPC • That Forced Us to Answer: What is a Distributed Application? • We now are working with a Unified Model for Printer USB -DIF WiFi -DIF OS - DAF DiskLaptop Operating Systems IRM Distributed Applications IRM Networks Task sched Mem Mngt IPC Task s Application Processes © John Day, 2014 Rights Reserved RINA Tutorial to the EC 51
  41. 41. What a Layer 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 applications, access control, monitoring lower layer, etc. • Remember that within a scope if there is a partitioning of functions, it will be orthogonal? Well, here it is. IPC Transfer IPC Control IPC Management Delimiting Transfer Relaying/ Muxing PDU Protection Common Application Protocol Applications, e.g., routing, resource allocation, access control, etc. Application-entities Application Process © John Day, 2014 Rights Reserved 52RINA Tutorial to the EC
  42. 42. Only Three Kinds of Systems • Middleboxes? We don’t need no stinking middleboxes! • NATs: either no where or everywhere, • NATs only break broken architectures • The Architecture may have more layers, but no box need have more than the usual complement. – Hosts may have more layers, depending on what they do. Hosts Interior Routers Border Routers © John Day, 2014 Rights Reserved 53RINA Tutorial to the EC
  43. 43. All Communication goes through Three Phases • Enrollment – Operations to create sufficient state within the network to allow an instance of communication to be created. • Allocation (also known as Establishment) – Operations required to allocate an instance of communication creating sufficient shared state among instances to support the functions of the data transfer phase. • Data Transfer – Operations to provide the actual transfer of data and functions which support it. • Most of our attention has been on the last two. The first has often been ignored and is usually seen as necessarily ad-hoc. But enrollment turns out to be key. © John Day, 2014 Rights Reserved 54RINA Tutorial to the EC
  44. 44. How Does It Work? Enrollment or Joining a Layer • Nothing more than Applications establishing communication (for management) – Authenticating that A is a valid member of the (N)-DIF – Initializing it with the current information on the DIF – Assigning it a synonym to facilitate finding IPC Processes in the DIF, i.e. an address – (see the Enrollment specification for an example.) (N-1)-DIF (N)-DIF A © John Day, 2014 Rights Reserved 55RINA Tutorial to the EC
  45. 45. How Does It Work? Establishing Communication • Simple: do what IPC tells us to do. – A asks IPC to allocate comm resources to B – Determine that B is not local to A use search rules to find B – Keep looking until we find an entry for it. – Then go see if it is really there and whether we have access. – Then tell A the result. – (See Flow Allocator specification) • This has multiple advantages. – We know it is really there. – We can enforce access control – We can return B’s policy and port-id choices – If B has moved, we find out and keep searching A BAhh, look there! © John Day, 2014 Rights Reserved 56RINA Tutorial to the EC
  46. 46. Routing at Different Layers • With a Recursive Model, there are levels of routing with border routers acting as the step-down function creating interior flows. • This tends toward a “necklace” configuration. Hosts Interior Routers Border Routers © John Day, 2014 Rights Reserved 57RINA Tutorial to the EC
  47. 47. Implications of the Model & Names (Routing Table Size) • Recursion either reduces the number of routes or shortens them. Backbone Regionals Metros © John Day, 2014 Rights Reserved 58RINA Tutorial to the EC
  48. 48. This Bounds Router Table Size • There will be Natural Subnets within a layer around the Central Hole. • Each can be a routing domain; Each Subnet is one hop across the Hole. – The hole is crossed in the layer below. • A Topological Space is imposed on the Address Space of Each Layer Backbone Regionals Metros (N)- Routing Domains (N-1)-Routing Domains © John Day, 2014 Rights Reserved 59RINA Tutorial to the EC
  49. 49. Names & Implications of the Model (Basics) • We have made a big deal of node and point of attachment, but they are relative, not absolutes. – An (N)-IPC-Process is a node in the (N)-DIF. • An (N-1)-IPC-Process is a node in the (N-1)-DIF – An (N-1)-IPC-Process is a point of attachment to an (N)-IPC-Process. – An (N)-address is a synonym for an (N)-IPC-Process. • So as long as we keep that straight, there is no point to making the distinction. • Note that it is the port-id that creates layer independence. With a port-id, No Protocol-Id Field is Necessary, or if there is such a field something is wrong. Address Port -id (N)-IPC-Process (N-1)-IPC-Process © John Day, 2014 Rights Reserved 60RINA Tutorial to the EC
  50. 50. . Implications of the Model & Names (Multihoming) • Yea, so? What is the big deal? It just works – PDU arrives at an (N-1)-IPC Process. If the address designates this (N-1)- IPC Process, the CEP-id is bound to the port-id, so after stripping off (N- 1)-PCI, it passes it up. PDUs arrive on different (N-1)-DIFs? So? – The process repeats. If the address in the (N)-PCI is this IPC-Process, it looks at the CEP-id and pass it up as appropriate. – Normal operation. Yes, the (N-1)-bindings may fail from time to time. – Not a big deal. Because not routing to the (N-1)-address, but to the (N)- address – Need an example? (Destination) Address Port -id (N)-IPC-Process (N-1)-IPC-Process © John Day, 2014 Rights Reserved 61RINA Tutorial to the EC
  51. 51. Consider the Following Network • Since we want to emphasize that we are naming interfaces, lets give addresses to each of the interfaces. • Now lets say that A wants to send a PDU to H, so it goes to DNS and looks up the address and gets 9. Now these guys have been running a routing algorithm and the route is A, B, D, F, H. • So what do the router tables look like, (next slide) G A B C E D F H 1 2 6 5 8 3 14 18 17 16 15 19 21 13 20 9 11 10 12 4 7 2 2 © John Day, 2014 Rights Reserved 62RINA Tutorial to the EC
  52. 52. © John Day, 2014 Rights Reserved 63RINA Tutorial to the EC
  53. 53. A PDU is Sent With Destination Address 9 From A • A consults its Forwarding Table and sends it on outgoing address 1, next hop 22. • B consults its FT and sends it on outgoing address 7, next hop 15. • D consults its FT and sends it on outgoing address 14, next hop 20. • F consults its FT and sends it on outgoing address 11, next hop 9. • Now another PDU is sent from A to address 9, just after it leaves, the interface goes down. G A B C E D F H 1 2 6 5 8 3 14 18 17 16 15 19 21 13 20 9 11 10 12 4 7 2 2 © John Day, 2014 Rights Reserved 64RINA Tutorial to the EC
  54. 54. What Happens When Link From F to H Fails? • What happens if Link with address 9 goes down? – In a few 10s of ms, a routing update is done, and Addresses 9 and 11 are eliminated from the forwarding table. – After several seconds and many retries, A determines that Address 9 is not responding, – All TCP connections with Address 9 are terminated. (The pseudo header kills them.) – All packets enroute to 9 are lost. – Hopefully, there is a second DNS entry that lists H as also at Address 10. – Connections are re-established using address 10. Several seconds have elapsed. G A B C E D F H 1 2 6 5 8 3 14 18 17 16 15 19 21 13 20 9 11 10 12 4 7 2 2 © John Day, 2014 Rights Reserved 65RINA Tutorial to the EC
  55. 55. Consider the Following Network With Node Addresses • Since we want to emphasize that we are naming nodes, lets just use the letters for addresses. But we still have to say which wire to send them on. – There are two cases in general: • Point-to-point Wire: No need for lower layer addresses use local identifiers. • Multi-access wired or wireless: Here we need addresses, use MAC addresses – We have only wires, so lets assign small integers as the local interface identifiers. • Now lets say that A wants to send a PDU to H, so it goes to DNS and looks up the address and gets H. Now these guys have been running a routing algorithm and the route is A, B, D, F, H. • So what do the router tables look like, (see next slide) G A B C E D F H 1 2 3 1 2 1 3 4 1 2 3 1 2 3 1 2 3 1 1 2 2 2 © John Day, 2014 Rights Reserved 66RINA Tutorial to the EC
  56. 56. © John Day, 2014 Rights Reserved 67RINA Tutorial to the EC
  57. 57. Sending a PDU from A to H • A has a PDU addressed to H: – A consults its Forwarding Table and sends the PDU on interface 2 to B. – B consults its Forwarding Table and sends the PDU on interface 2 to D. – D consults its Forwarding Table and sends the PDU on interface 2 to F. – F consults its Forwarding Table and sends the PDU on interface 2 to H G A B C E D F H 1 2 3 1 2 1 3 4 1 2 3 1 2 3 1 2 3 1 1 2 2 2 © John Day, 2014 Rights Reserved 68RINA Tutorial to the EC
  58. 58. What Happens When Link From F to H Fails? • What happens if just after the PDU is sent the Link from F to H fails? – In a few 10s of ms, a routing update is done, and a new Routing Table is generated. – The PDU gets to D after the routing update has concluded and is delivered to H as if nothing happened. – PDUs that might have been between B, D, and F might get re-routed. Only PDUs on the wire from F to H would be lost. G A B C E D F H 1 2 3 1 2 1 3 4 1 2 3 1 2 3 1 3 1 2 2 2 © John Day, 2014 Rights Reserved 69RINA Tutorial to the EC
  59. 59. Comments on the Example • One of the excuses for not solving this a long time ago was: only a few needed it so the burden shouldn’t be on everyone. – Burden? What Burden! • Not only is it free! It is far less expensive. • Notice how much smaller the router tables were? Factor 3! • Fail over times are reduced by orders of magnitude. • To be generous, this shows how tradition trumps science in the Internet. – To be less generous, in their rush to not do anything OSI did, they cut off their nose to spite their face. • Suppose that points of attachment (interfaces) fail frequently, is that a problem? – No, we call that. . . © John Day, 2014 Rights Reserved 71RINA Tutorial to the EC
  60. 60. Names & Implications of the Model (Mobility) • Yea, so? What is the big deal? – It just works just like multihoming only the (N-1)-port-ids come and go a bit more frequently. • O, worried about having to change address if it moves too far? Easy. • Assign a new synonym to it. Put it in the source address field on all outgoing traffic. Stop advertising the old address as a route to this IPC-Process. • Want to renumber the DIF for some reason? Same procedure. • Again, no special cases. No special protocols. No concept of a home router. Okay, policies in the DIF may be a bit different to accommodate faster changing points of attachment, but that is it. Address Port -id (N)-IPC-Process (N-1)-IPC-Process New Address © John Day, 2014 Rights Reserved 72RINA Tutorial to the EC
  61. 61. Implications of the Model & Names (Choosing a Layer) • In building the IPC Model, the first time there were multiple DIFs (data link layers in that case), to maintain the API a task was needed to determine which DIF to use. I A P D i r Mux Flow Mgr – User didn’t have to see all of the wires – But the User shouldn’t have to see all of the “Nets” either. • This not only generalizes but has major implications. © John Day, 2014 Rights Reserved 73RINA Tutorial to the EC
  62. 62. Implications of the Model & Names (A DIF Allocator) • A DIF-Allocator incorporating a Name Space Management function determines via what DIFs applications are available. – If this system is a not member, it either joins the DIF as before – or creates a new one. • Which Implies that the largest address space has to be only large enough for the largest e-mall. • Given the structure, 32 or 48 bits is probably more than enough. • You mean? • Right. IPv6 was a waste of time . . . • Twice. DIF-Allocator © John Day, 2014 Rights Reserved 74RINA Tutorial to the EC
  63. 63. So a Global Address Space is Not Required but Neither is a Global Application Name Space Inter-DIF Directory To Peers In Oher DIFs Actually one could still have distinct names spaces within a DIFs (synonyms) with its own directory database. • Not all names need be in one Global Directory. • Coexisting application name spaces and directory of distributed databases are not only possible, but useful. • Needless to say, a global name space can be useful, but not a requirement imposed by the architecture. • The scope of the name space is defined by the chain of databases that point to each other. © John Day, 2014 Rights Reserved 75RINA Tutorial to the EC
  64. 64. Scope is Determined by the Chain of Places to Look • The chain of databases to look for names determines the scope of the name space. – Here there are 2 non-intersecting chains of systems, that could be using the same wires, but would be entirely oblivious to the other. © John Day, 2014 Rights Reserved 76RINA Tutorial to the EC
  65. 65. “Internet” Congestion Control • Congestion Control has been a known issue since 1972. – Except in the Internet who only discovered it when it crashed around their ears in 86 • The effectiveness of any congestion control is directly related to the time to effect a change. – The longer it takes the less effective the congestion control • End-to-end implicit notification is predatory. – Longest response time. Will work against any attempt to do it at a lower level with shorter scope and better response time. • The Internet has network congestion control, – not internet congestion control © John Day, 2014 Rights Reserved 77RINA Tutorial to the EC
  66. 66. How Does It Work? “Congestion Control” • Congestion Control in TCP was always known to be a stop-gap. • A DIF always has the potential for the full capability of functions. • Do flow control (without retransmissions) between intermediate points. – Better congestion control, really flow control – Allocate different resources to different e-malls. – Allows provider much more effective management of resources. – Provides means to throttle flows being used for denial of service attacks – All of these places? Probably not all in the same DIF. Major Area for Research T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 79
  67. 67. How Does It Work? Security • A Hacker in the Public Internet cannot connect to an Application in another DIF without either joining the DIF, or creating a new DIF spanning both. Either requires authentication and access control. – Non-IPC applications that can access two DIFs are a potential security problem. • Certainly promising Public Internet ISP 1 ISP 2 ISP 3 Internet Rodeo Drive Utility SCADAMy NetFacebook Boutique Internet Mall of America © John Day, 2014 Rights Reserved RINA Tutorial to the EC 80
  68. 68. The Recursion Provided Isolation • Security by isolation, (not obscurity) • Hosts can not address any element of the ISP. • No user hacker can compromise ISP assets. • Unless ISP is physically compromised. ISP Hosts and ISPs do not share DIFS. (ISP may have more layers © John Day, 2014 Rights Reserved 81RINA Tutorial to the EC
  69. 69. 82 • 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 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 RINA Tutorial to the EC
  70. 70. A Very Unexpected Result • A DIF with no explicit security mechanisms is inherently more secure than the current Internet under the same conditions! • It would appear that – A DIF is a Securable Container. © John Day, 2014 Rights Reserved RINA Tutorial to the EC 83
  71. 71. Other Things Fall Into Place • Data Transfer in RINA is based on Delta-t (Watson, 1980) • Lot has happened in 30 years, many attacks on TCP have been found: – Port scanning – Reset Attacks – SYN attacks – Reassembly Attacks • Long after delta-t was designed, what about delta-t? • Short answer: – None of them work (Boddapati, et al., 2012) • Amazing, totally unexpected – Why not? • Multiple fundamental reasons, but all inherent in the structure: – First, have to join the DIF (all members are authenticated) – Second, No Well-Known Ports • Would have to scan all possible application names! – Third and more importantly, . . . © John Day, 2014 Rights Reserved RINA Tutorial to the EC 84
  72. 72. Decoupling Port Allocation and Synchronization • No Way to Know What CEP-ids are Being Used, Since There is No Relation Between Port-id and CEP-id. – SYN-Ack Attack: must guess which of 2^16 CEP-id. – Data Transfer: must guess CEP-id and seq num within window! – Reassembly attack: Reassembly only done once. – No well-known ports to scan. Synchronization Connection Endpoint Port Allocation Port-id Connection © John Day, 2014 Rights Reserved RINA Tutorial to the EC 85
  73. 73. RINA is Inherently More Secure and Less Work • A DIF is a Securable Container. (Small, 2011) – What info required to mount an attack, How to get the info – Small does a threat analysis at the architecture level • Implies that Firewalls are Unnecessary, – The DIF is the Firewall! • RINA Security is considerably Less Complex than the Current Internet Security (Small, 2012) – Only do a rough estimate counting protocols and mechanisms. • See paper for details. © John Day, 2014 Rights Reserved RINA Tutorial to the EC 86
  74. 74. Internet RINA Protocols 8 0 Non-Security Mechanisms 59 0 Security Mechanisms 28 7 To Add Security © John Day, 2014 Rights Reserved RINA Tutorial to the EC 87
  75. 75. Why Is Internet Security So Bad? • The Standard Rationale One Sees is that They Didn’t Think About It at the Beginning. – Neither did We. – Nor did Watson. – But RINA and delta-t are more secure. • That Seems to Imply that – Good Design May be More Important to Security than Security Is. © John Day, 2014 Rights Reserved RINA Tutorial to the EC 88
  76. 76. IMPLICATIONS AND IMPACT RINA Tutorial to the EC 91 3
  77. 77. SIMPLER, CHEAPER, MORE PREDICTABLE NETWORKS T-5 Alternatives to TCP/IP 92
  78. 78. Simpler networks • Clean and simple structure at the macro-level: single type of layer that repeats as needed, uniform API between layers – No need to differentiate “physical” vs. “virtual”, vs overlays, etc.. – Much simpler networks, with less devices and no middleboxes (no need for firewalls, NATs, tunnel terminators, DPI, etc). Just three types of systems: hosts, interior routers and border routers. – Unification of all forms of I/O and networking under the IPC paradigm – Applications can communicate with other applications just by name – regardless of their location – and request specific characteristics for the communication instance (max. delay, max loss, in order delivery, …) – See next two slides RINA Tutorial to the EC 93
  79. 79. Network layers today (example) Host Enterprise router IEEE 802.3 (Ethernet) Enterprise router TCP/UDP App A Application A Sockets API OS Sockets Layer 1. Bind/Listen to interface and port 2. Accept incoming connections 3. Connect to a remote address/port 4. Send datagram 5. Write data (bytes) to socket 6. Read data (bytes) from socket 7. Destroy socket IP IEEE 802.11 (WiFi) Carrier Ethernet Switch IEEE 802.1q (VLAN) IEEE 802.1ah (PBB) Each tech has a different API, and all are different from the application API Carrier Ethernet Switch RINA Tutorial to the EC 94
  80. 80. Network layers with RINA (example) Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF App A The layer API is always the same (and the same as the application API) Application A Layer (DIF) API IPC Process 1. Register application 2. Allocate/Deallocate flows 3. Write data (SDUs) to flows 4. Read data (SDUs) from flows 5. Get layer information (QoS cubes, Max SDU size, etc..) RINA Tutorial to the EC 95
  81. 81. Simpler networks (II) • Each layer has the same components and structure, programmable via “policies” to optimize each layer for its operating environment – No need to define new protocols for different layers, just different policies – Implementations can leverage this structure to obtain a more compact, simple, reliable and performing “network stack” – Given that layers have the same API and internal structure, interactions between layers become simpler and predictable. Multi-layer network management becomes much more simple, allowing for more sophisticated automation deployed at larger scales. – A layer is just a distributed application dedicated to do Inter Process Communication (IPC). An instantiation of a layer in a computing system is called IPC Process. – See next slide RINA Tutorial to the EC 96
  82. 82. Internal structure of an IPC Process IPC Process IPC API Data Transfer Data Transfer Control Layer Management SDU Delimiting Data Transfer Relaying and Multiplexing SDU Protection Retransmission Control Flow Control RIB Daemon RIB CDAP Parser/Generator CACEP Enrollment Flow Allocation Resource Allocation Routing Authentication StateVector StateVectorStateVector Data TransferData Transfer Retransmission Control Retransmission Control Flow Control Flow Control Namespace Management Security Management Increasing timescale (functions performed less often) System (Host) • Each IPC Process has components to provide IPC (data transfer and data transfer control), as well as components to manage IPC (enrollment, routing, flow allocation, resource allocation, security management, etc..). – Layer management components use a common abstraction (the RIB) and protocol (CDAP) to exchange information with neighbor IPCPs. This exchange of information is modeled as 6 remote operations (create, delete, reqd, write, start, stop) on obects. RINA Tutorial to the EC 97
  83. 83. Service Provider Networks Example scenario (Fixed networks) Border RouterHost Home /Enterprise DIF Customer network (Simplification, can have more internal structure probably) Access DIF Border Router Interior Router P2P DIF P2P DIF Border Router P2P DIF Interior Router P2P DIF Border Router P2P DIF P2P DIF Interior Router Border Router Provider 1 Backbone DIF P2P DIF Border Router Provider 1 Regional DIF P2P DIF Border Router Provider 1 Metropolitan DIF Border Router P2P DIF P2P DIF Provider 2 Metro DIF Interior Router P2P DIFP2P DIF Public Internet DIF Application-specific DIF DAP Provider 1 network Provider 2 network 98 RINA Tutorial to the EC
  84. 84. Backbone DIF Regional DIF SubDIF 1 Subnetwork 2 SubDIF 3 SubDIF 4Access DIF Access DIF Interior Router Service Provider Networks Provider 1 Network Border Router Interior Router P2P DIF P2P DIF Border Router P2P DIF Interior Router P2P DIF Border Router P2P DIF P2P DIF Interior Router Border Router Provider 1 Backbone DIF P2P DIF Border Router Provider 1 Regional DIF Border Router Provider 1 Metropolitan DIF P2P DIF Interior Router P2P DIF P2P DIF SubDIF 1 SubDIF 2 SubDIF 3 SubDIF 4 SubDIF 5 SubDIF 4 SubDIF 7 SubDIF 8Metropolitan DIF Access DIF 99 RINA Tutorial to the EC
  85. 85. E-mall DIF E-mall DIF Metropolitan DIF Connectivity graph and example policies • Supports different “e-malls” – DIFs designed to support applications. • Organized in subDIF, each subDIF could map to a city. • Topological addressing (<city.IPCP>), link state within a subDIF. • Need to multiplex traffic from potentially very different characteristics: need to provide multiple QoS cubes. • Strong security requirements since the DIF is exposed to customer routers MR BR BR IR BR BR ISP BR BR BR IR IR BR IR IR IR MR BR BR BR IR BRBR SubDIF 3 BR SubDIF 1 SubDIF 2 Regional DIF E-mall DIF E-mall DIF E-mall DIF E-mall DIF E-mall DIF E.mall DIF IR = IPCP at Interior Router BR = IPCP at Border Router E-mall DIF 100 RINA Tutorial to the EC
  86. 86. Regional DIF Connectivity graph and example policies • Provides connectivity to the different subDIFs of the metropolitan DIF. • Organized in subDIF, each subDIF could map to a region. • Topological addressing (<region.IPCP>), link state within a subDIF. • Traffic more aggregated than in metros, still probably need to provide support for multiple QoS cubes. MR BR BR IR BR BR ISP BR BR BR IR IR BR IR IR IR MR BR BR BR IR MR BRBRBR SubDIF 3 BR SubDIF 1 SubDIF 2 Backbone DIF Metro DIF Metro DIF Metro DIF Metro DIF Metro DIF Metro DIF IR = IPCP at Interior Router BR = IPCP at Border Router 101 RINA Tutorial to the EC
  87. 87. Backbone DIF Connectivity graph and example policies • Provides connectivity to the different subDIFs of the regional DIF. • Traffic is aggregated and therefore more deterministic, more connection- oriented like resource allocation policies make sense. • Security policies can be more relaxed: all the infrastructure is in control of the provider and not exposed outside. • Relatively small number of IPCPs: flat addressing and link-state routing may be enough (no subDIFs). • Meshed connectivity graph. IR = IPCP at Interior Router BR = IPCP at Border Router BR BR BR BR BR BR IR IR IR IR IR IR IR Regional DIF Regional DIF Regional DIF Regional DIF Regional DIF Regional DIF 102 RINA Tutorial to the EC
  88. 88. INTERNETWORKING 103
  89. 89. How Does It Work? The Internet and ISPs • The Internet floats on top of ISPs, a “e-mall.” – One in the seedy part of town, but an “e-mall” – Not the only emall and not one you always have to be connected to. Public Internet ISP 1 ISP 2 ISP 3 © John Day, 2014 Rights Reserved RINA Tutorial to the EC 104
  90. 90. How Does It Work? The Internet and ISPs • But there does not need to be ONE e-mall. – You mean! • Yes, it is really an INTERnet! Public Internet ISP 1 ISP 2 ISP 3 Internet Rodeo Drive Utility SCADAMy NetFacebook Boutique Internet Mall of America © John Day, 2014 Rights Reserved RINA Tutorial to the EC 105
  91. 91. How Does It Work? The User’s Perspective In this case, one host on the local network chooses to join one of the available e-malls. e-common DIFs Provider Network Local Customer Network Peering DIF A Customer Network has a border router that makes several e-malls available. A choice can be made whether the entire local network joins, a single host or a single application. e-common DIFs Provider Network Local Customer Network Peering DIF © John Day, 2014 Rights Reserved RINA Tutorial to the EC 106
  92. 92. 5G 107RINA Tutorial to the EC
  93. 93. Why do we have a separate mobile network architecture? • RINA can be used to design and build mobile access networks, no need for a separate architecture – It provides an ideal framework to materialize the “5G” concepts, unifying: fixed networks, mobile networks, wireless, virtual networks, overlays, etc. RINA Tutorial to the EC 108
  94. 94. Border Router Service Provider Networks Example scenario (Mobile networks) P2P DIF Metro DIF Provider Fixed Network (necklace with e-mall at the top) P2P DIF Border Router P2P DIF Border Router Interior Router (Base Station) Host (Mobile) Multi-access DIF (radio) P2P DIF District DIF Metro DIF Regional DIF Public Internet DIF Application-specific DIF DAP Border Router Regional DIF P2P DIF Mobile Infrastructure NetworkCustomer Terminal P2P DIF Interior Router Border Router P2P DIF Backbone DIF Regional Metro District P2P DIF Interior Router 109RINA Tutorial to the EC
  95. 95. Radio Access DIF and District DIF Example connectivity graphs Multi-homed host BR BS H H H BS H Metro DIF Metro DIF Metro DIF BR BS H H H BS H Metro DIF Metro DIF Metro DIF Multi-homed host Metro DIF Metro DIF Metro DIF District DIF 1 District DIF 2 Radio DIF Radio DIF Radio DIF Radio DIF DISTRICT DIF BS = IPCP at Base Station H = IPCP at Host BR = IPCP at Border Router BS H BS H H H H Multi-access DIF 1 (radio) Multi-access DIF 2 (radio) District DIF District DIF District DIF District DIF District DIF District DIF MULTI-ACCESS RADIO DIF BS = IPCP at Base Station H = IPCP at Host 110RINA Tutorial to the EC
  96. 96. E-mall DIF Metro DIF and Regional DIF Example connectivity graphs METRO DIF H = IPCP at Host BR = IPCP at Border Router H H H H H BR H H H H H BR Multi-homed host Reg. DIF H H H H H BR H District DIF District DIF District DIF BR Regional DIF H H H HH H HH H H HH H HH H H HH H HH H H HH H H Metro DIF BR HH H HH H H HH H HH H H HH H HH H HH H HH Metro DIF BR BR Metro DIF (fixed) Public Internet DIF REGIONAL DIF H = IPCP at Host BR = IPCP at Border Router 111RINA Tutorial to the EC
  97. 97. Mobility, what is needed? • Nothing new! • Enrollment to new DIFs follows usual procedures • Allocation of flows follows usual procedures • Changing address of IPCPs within a DIF as they move through it as described before • New lower layer DIFs (points of attachment) are acquired as usual • Current points of attachment are discarded when they can no longer provide an acceptable QoS (defined per DIF) 112RINA Tutorial to the EC
  98. 98. QUALITY OF SERVICE, NET NEUTRALITY 113RINA Tutorial to the EC
  99. 99. Net neutrality (I) • Lots of definitions, but the aim is protecting the user/consumer. As with other businesses, it should be regulated by outcomes, not trying to specify how networks should process packets. • “All packets should be treated equal” doesn’t make sense: – Assumes all applications will have the same requirements (WRONG! interactive vs. bulk) – Assumes all traffic is equally valid (WRONG! What about spam?) – Assumes different traffic streams are perfectly isolated (WRONG! My video stream is your Denial of Service attack) – Assumes individual packets are significant (WRONG! Flows are what matters) • Why on earth shouldn’t network operators be able to provide a differentiated service offering to their customers? – Do we ban airlines from providing business class? – Do we ban restaurants from serving different meals with different quality at a different price? – Etc … 114RINA Tutorial to the EC
  100. 100. Net neutrality (II) • What matters is that (as in any other business) – Operators have a clear service offering, based on measurable outcomes (e.g. you will get a delay of less than 200 ms 95% of the time, and in any case no bigger than 1 s). – Operators don’t discriminate users based on sex, religion, etc.. • But providing quality of service in the current Internet is hard.. what about RINA networks? – Next slide RINA tutorial to the EC 115
  101. 101. Propagating QoS requirements through the layers RINA tutorial to the EC 116 Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF App A The layer API is always the same (and the same as the application API) Application A Layer (DIF) API IPC Process 1. Register application 2. Allocate/Deallocate flows 3. Write data (SDUs) to flows 4. Read data (SDUs) from flows 5. Get layer information (QoS cubes, Max SDU size, etc..)
  102. 102. DEPLOYING RINA TODAY 117RINA Tutorial to the EC
  103. 103. Transition? No, Adoption Public Internet Rina Provider RINA Network RINA ApplicationsRINA supported Applications • Adopt. Don’t transition. – If the old stuff is okay in the Internet e-mall, leave it there. – Do the new capabilities in RINA • Operate RINA over, under, around and through the Internet. – The Internet can’t be fixed, but it will run better over RINA. – New applications and new e-malls will be better without the legacy and run better along side or over the Internet. • The Microsoft Approach or the Apple approach? – Microsoft tried to prolong the life of DOS. It still haunts them. • A clean break with the past. The legacy is just too costly. • We need engineering based on science, not myth and tradition. RINA Tutorial to the EC 118
  104. 104. Shim DIFs General requirements • The task of a shim DIF is to put a small as possible veneer over a legacy protocol to allow a RINA DIF to use it unchanged. • The shim DIF should provide no more service or capability than the legacy protocol provides. 119RINA Tutorial to the EC
  105. 105. Shim DIF over 802.1Q Environment • (Disclaimer: Other shim DIFs over Ethernet are possible: with no VLANs; using LLC; over carrier Ethernet; …) • A shim DIF over Ethernet maps to a VLAN – The DIF name is the VLAN name • The shim DIF only supports on class of service: unreliable • ARP can be used to map upper layer IPC Process names to shim DIF addresses (MAC addresses) 120RINA Tutorial to the EC Shim DIF over Ethernet Ethernet II PCI Application data
  106. 106. Shim DIF over TCP/UDP • Wraps an IP network with the DIF IPC API • Two QoS cubes possible: reliable and in-order-delivery of flows (TCP), unreliable (UDP) – More could be possible depending on the capabilities of the underlying IP network • IPCP name is mapped to an IP address and a port number – Using proprietary procedures or leveraging DNS (via SRV records) 121 IPCP a.1 IPCP b.1 Shim DIF over IP networks IP layer UDP Port:2524UDP Port:2524 Shim IPCP X.1 Shim IPCP Y.1 IP: 4.3.2.1 IP: 5.3.5.8 2 5 Flow RINA Tutorial to the EC
  107. 107. RINA under IP • RINA-based ISP, internal layers are RINA, can transport IP (can be treated as just another app) and/or other DIFs. • Almost all routing is done in RINA layers. From the IP layer perspective, the ISP is a single hop – Directly connects access routers between them or with border routers 122 App Customer network Home router Regional DIF ISP access router Shim DIF Shim DIF Shim DIF Shim DIF Backbone DIF Regional router Regional- bacbone border router Backbone router ISP border router (runs BGP sessions with peers) Customer network is not RINA enabled Public Internet layer (IP) Data transfer/control: TCP/IP Layer management: ICMP, BGP, etc… Access network layer (e.g Ethernet) AS-to-AS layer (e.g Ethernet) Peer AS is not RINA-enabled RINA Tutorial to the EC
  108. 108. Faux sockets API An aid to adoption • Sockets API implementation that internally maps sockets API calls to RINA IPC API calls – Allows applications to be deployed over RINA networks unchanged (won’t leverage the full RINA benefits) • Mapping – Need to map hostnames and transport ports to RINA names • Applications that pass IP addresses are more problematic to support – Binding a socket = Registering an application to a DIF • Single DIF vs. Multiple DIFs – Connecting a socket = Allocating a flow to a destination app • No need to perform DNS lookup since names are resolved by DIFs – Accepting incoming connections = Accepting incoming flows – Read/write to a socket = Read/write to a flow – Closing a socket = Deallocating a flow 123RINA Tutorial to the EC
  109. 109. RINA STATUS, HOW CAN THE EC HELP MOVE RINA FORWARD? RINA Tutorial to the EC 124 4
  110. 110. RINA state of the art • Draft RINA reference model and specifications • Theoretical and experimental research on RINA properties (using FIRE, GENI, particular testbeds) – BU John Day’s team – EC projects: FP7 IRATI, FP7 PRISTINE, G3+ OC winner IRINA • Open source implementations – IRATI (FP7 IRATI, FP7 IRINA, FP7 PRISTINE) – protoRINA – RINAsim (a simulator under development by FP7 IRATI) • PSOC (Pouzin Society): coordination of international R&D activities, maintenance of draft reference model and specifications T-5 Alternatives to TCP/IP 125
  111. 111. Flow of RINA R&D activities 126 Prototyping & Tool Development Different Platforms Java VM Linux OS Android OS NetFP GA Coexisting with different technologies TCP/UDP /IP VLANs WiFi LTEMPLS Prototy pes & Tools Tools Test apps Prot. analyz SDKs Research on RINA reference model Core RINA specs Research on policies for different areas Data transfer Manage ment Security Routing Resource allocation Enrollment Application discovery Multiplexing DIF creation Policy specs Design and development of simulators Simul ators Study different use cases and deployment options Use case analy sis Experiment ation and validation Data and conclu sions New Insights & Invariances RINA Tutorial to the EC
  112. 112. IRATI @ a Glance • What? Main goals – 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. Budget Total Cost 1.126.660 € EC Contribution 870.000 € Duration 2 years Start Date 1st January 2013 External Advisory Board Juniper Networks, ATOS, Cisco Systems, Telecom Italia 5 activities:  WP1: Project management  WP2: Arch., Use cases and Req.  WP3: SW Design and Implementation  WP4: Deployment into OFELIA  WP5: Dissemination, Standardisation and Exploitation Who? 5 partners 127 From 2014
  113. 113. 128 IRATI contributions to RINA roadmap • Reference model and core specifications – Detect inconsistencies and errors • Research on policies for different areas – Routing (link-state), Shim DIF over Ethernet VLANs (802.1q), shim DIFs for Hypervisors, Faux sockets API • Use cases – Corporate VPNs and VM networking • Prototyping – Initial implementation for Linux OS (user-space and kernel) • Experimentation – First experimental analysis of RINA against TCP/IP in similar conditions (focusing in LAN environments)
  114. 114. PRISTINE @ a Glance • What? Main goals – To design and develop an SDK for the IRATI RINA prototype, to unleash the programmability provided by RINA. – To use the SDK to design, implement and trial a set of a policies to create optimized DIFs for different use cases: distributed cloud, datacenter networking and network service provider. – To design and implement the first RINA multi-layer management system. Budget Total Cost 5.034.961 € EC Contribution 3.337.000 € Duration 2.5 years Start Date 1st January 2014 External Advisory Board Cisco Systems, Telecom Italia, Deutsche Telekom, Colt Telecom, BU, Interoute 7 activities:  WP1: Project management  WP2: Use cases, req. analysis and programmable reference architecture  WP3: Programmable performance- enhancing functions and protocols  WP4: Innovative security and reliability enablers  WP5: Multi-layer management plane  WP6: System-level integration, validation, trials and assessment  WP7: Dissemination, standardisation and exploitation Who? 15 partners WIT-TSSG, i2CAT, TID, Ericsson, NXW, Thales, Nexedi, Atos, BISDN, Juniper, Telecom SudParis, U Brno, UiO, CREATE-NET, iMinds
  115. 115. 130 PRISTINE contributions to RINA roadmap • Reference model and core specifications – Detect inconsistencies and errors • Research on policies for different areas – Congestion control, distributed resource allocation, addressing, routing, authentication, access control, encryption, DIF management • Use cases – Decentralized cloud, DC networking, network service provider • Prototyping – Build on IRATI implementation for Linux OS. Develop SDK to allow easier customization, develop sophisticated policies with SDK. Prototype first DIF Management System • Simulators – Development of a RINA simulator, based on OMNeT++ • Experimentation – More realistic experimentation, with more complex deployments, coexisting with several technologies at once (IPv4, IPv6, Ethernet)
  116. 116. 131 IRINA @ a glance • What? Main goals – To make a study of RINA against the current networking state of the art and the most relevant clean-slate architectures under research. – To perform a use-case study of how RINA could be better used in the NREN scenario, and showcase a lab-trial of the use case – To involve the NREN and GEANT community in the different steps of the project, in order to to get valuable feedback Budget Total Cost 199.940 € EC Contribution 149.955 € Duration 18 months Start Date 1st November 2013 5 activities:  WP1: Technical coordination and interaction with GEANT3+  WP2: Comparative analysis of network architectures  WP3: Use case study and lab trials  WP4: Dissemination and workshop organization Who? 4 partners
  117. 117. 132 IRINA contributions to RINA roadmap • Reference model and core specifications – Compare with other architectures • Use cases – Research network operators (NRENs and GEANT environment) • Prototyping – Little adaptations to the IRATI prototype (Linux OS), to be able to trial the use case in the lab • Experimentation – Focus on the requirements of NRENs
  118. 118. Open source IRATI 133 • IRATI github side • http://irati.github.io/stack • Hosts code, docs, issues • Installation guide • Experimenters (tutorials) • Developers (software arch) • Mailing list for users and developers • irati@freelists.org • Procedures to contribute under discussion, doc ongoing
  119. 119. How could the EC contribute? (I) • In general – Get more informed on RINA and potential impacts. Don’t believe it: understand it! – Consider motivating research on RINA by including it as a relevant item in future work programmes – Europe can lead this networking and distributed computing revolution this time! (unlike with the Internet or SDN) • FIRE – A RINA testbed to do research in networking would facilitate spreading the technology and its concepts among academics, research centres, SMEs and industry • 5G – RINA provides the perfect foundation to support the requirements of the 5G vision (blog post by ICT pristine) RINA tutorial to the EC 134 1 2 3
  120. 120. How could the EC contribute? (II) • Operating Systems Research – Recursive Operating Systems would also simplify current OSs, making them more flexible and robust (recursion as opposed to virtualization) • Distributed applications research – The DAF model provides a generic framework that would speed up the development of robust and flexible distributed applications RINA tutorial to the EC 135 4 5
  121. 121. Thanks for your attention! ict-pristine.eu pouzinsociety.org @ictpristine @iratiproject

×