reconstructing computer networking with rina: how solid scientific foundations can allow europe to...
TRANSCRIPT
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
RINA tutorial to the EC 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
1
2
3
RINA tutorial to the EC 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 4
DECONSTRUCTING THE INTERNET1
Lets Get the Bad NewsOut 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
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
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
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
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.
RINA Tutorial to the EC © John Day, 2014 Rights Reserved
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
12
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!RINA Tutorial to the EC © John Day, 2014 Rights Reserved
CYCLADES was Building a NetworkTo 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
Incr
easi
ng
Sco
pe
© John Day, 2014 Rights Reserved
13RINA Tutorial to the EC
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
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
After ICCC’72, the Research Networks formed INWG* to developan 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
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
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 LinkLayer
© John Day, 2014 Rights Reserved
19RINA Tutorial to the EC
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
• 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 Reserved24RINA 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
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
DataTransfer
Data TransferControl
Delimiting
Seq Frag/Reassemb
SDU Protection
Retransmission and Flow Control
© John Day, 2014 Rights Reserved
25RINA Tutorial to the EC
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 Reserved26RINA Tutorial to the EC
Computer Networks are notDataComm 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
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
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)
ApplicationApplication
Name
Node Address
Point of AttachmentAddress
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
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
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 Reserved34RINA Tutorial to the EC
Congestion Control in an Internet isClearly 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
36
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
RINA Tutorial to the EC
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
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
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
• 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
• 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
RINA Tutorial to the EC 45
INTRODUCING RINA2
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
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 BDIF C
DIF D
DIF E DIF F
RINA Tutorial to the EC
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
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 ReservedRINA Tutorial to the EC 49
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 ReservedRINA Tutorial to the EC 50
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
DiskLaptopOperating Systems
IRM
Distributed Applications
IRM
NetworksTask sched
MemMngt
IPC
Tasks
Application Processes
© John Day, 2014 Rights Reserved
RINA Tutorial to the EC 51
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.
IPCTransfer
IPCControl
IPC Management
DelimitingTransfer
Relaying/ MuxingPDU 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
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
InteriorRouters
BorderRouters
© John Day, 2014 Rights Reserved
53RINA Tutorial to the EC
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
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
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
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
InteriorRouters
BorderRouters
© John Day, 2014 Rights Reserved
57RINA Tutorial to the EC
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
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
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
.
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) AddressPort -id
(N)-IPC-Process
(N-1)-IPC-Process
© John Day, 2014 Rights Reserved
61RINA Tutorial to the EC
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
26
5
8
3 14
1817 16
15
19
21
13
209
11
10
12
4
7
22
© John Day, 2014 Rights Reserved
62RINA Tutorial to the EC
© 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 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
26
5
8
3 14
1817 16
15
19
21
13
209
11
10
12
4
7
22
© John Day, 2014 Rights Reserved
64RINA Tutorial to the EC
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
26
5
8
3 14
1817 16
15
19
21
13
209
11
10
12
4
7
22
© John Day, 2014 Rights Reserved
65RINA Tutorial to the EC
Consider the Following NetworkWith 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
12
3
1
21
3
4
12
3
12
3
1 2
3
1
1
22
2
© John Day, 2014 Rights Reserved
66RINA Tutorial to the EC
© 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 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
H1
2
3
1
21
3
4
12
3
12
3
1 2
3
1
1
22
2
© John Day, 2014 Rights Reserved
68RINA Tutorial to the EC
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
H1
2
3
1
21
3
4
12
3
12
3
1
3
1 22
2
© John Day, 2014 Rights Reserved
69RINA Tutorial to the EC
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
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
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.
IAPDir
MuxFlowMgr
– 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
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
So a Global Address Space is Not Required but
Neither is a Global Application Name Space
Inter-DIFDirectory
To PeersIn 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
Scope is Determined by theChain 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 Reserved76RINA Tutorial to the EC
“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
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
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
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
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 PDUsthrough N-1 DIF
Confidentiality, integrity
Placement of security related functions
N DIF
N-1 DIF
IPC Process IPC Process
IPC Process
IPC ProcessJoining a DIF
authentication, access control
Sending/receiving PDUsthrough 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 OperationLogging
DIF OperationLogging
RINA Tutorial to the EC
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
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
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
ConnectionEndpoint
Port Allocation
Port-id
Connection
© John Day, 2014 Rights Reserved
RINA Tutorial to the EC 85
RINA is Inherently More Secureand 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
Internet RINA
Protocols 8 0
Non-Security Mechanisms
59 0
Security Mechanisms 28 7
To AddSecurity
© John Day, 2014 Rights Reserved
RINA Tutorial to the EC 87
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 ReservedRINA Tutorial to the EC 88
RINA Tutorial to the EC 91
IMPLICATIONS AND IMPACT3
T-5 Alternatives to TCP/IP 92
SIMPLER, CHEAPER, MORE PREDICTABLE NETWORKS
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
Network layers today (example)
Host Enterprise router
IEEE 802.3 (Ethernet)
Enterprise router
TCP/UDP
App A
Application A
Sockets API
OS SocketsLayer
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
Network layers with RINA (example)
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIFDIF
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
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 slideRINA Tutorial to the EC 96
Internal structure of an IPC Process
IPCProcess
IPC API
Data Transfer Data Transfer Control Layer Management
SDU Delimiting
Data Transfer
Relaying and Multiplexing
SDU Protection
Retransmission Control
Flow Control
RIB Daemon
RIBRIB
CDAP Parser/Generator
CACEP
Enrollment
Flow Allocation
Resource Allocation
Routing
Authentication
State VectorState VectorState Vector
Data Transfer Data Transfer
Retransmission Control
Retransmission Control
Flow ControlFlow 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 EC97
98
Service Provider NetworksExample scenario (Fixed networks)
BorderRouterHost
Home /Enterprise DIF
Customer network
(Simplification, can have more internal structure probably)
Access DIF
BorderRouter
InteriorRouter
P2P DIF P2P DIF
BorderRouter
P2P DIF
InteriorRouter
P2P DIF
BorderRouter
P2P DIF P2P DIF
InteriorRouter
BorderRouter
Provider 1 Backbone DIF
P2P DIF
BorderRouter
Provider 1 Regional DIF
P2P DIF
BorderRouter
Provider 1 Metropolitan DIF
BorderRouter
P2P DIF P2P DIF
Provider 2 Metro DIF
InteriorRouter
P2P DIFP2P DIF
Public Internet DIF
Application-specific DIF
DAP
Provider 1 network Provider 2 network
RINA Tutorial to the EC
99
Backbone DIF
RegionalDIF
SubDIF 1Subnetwork 2
SubDIF 3
SubDIF 4Access DIF Access DIF
InteriorRouter
Service Provider NetworksProvider 1 Network
BorderRouter
InteriorRouter
P2P DIF P2P DIF
BorderRouter
P2P DIF
InteriorRouter
P2P DIF
BorderRouter
P2P DIF P2P DIF
InteriorRouter
BorderRouter
Provider 1 Backbone DIF
P2P DIF
BorderRouter
Provider 1 Regional DIFBorderRouter
Provider 1 Metropolitan DIF
P2P DIF
InteriorRouter
P2P DIF P2P DIF
SubDIF 1
SubDIF 2 SubDIF 3
SubDIF 4 SubDIF 5
SubDIF 4
SubDIF 7
SubDIF 8Metropolitan DIF
Access DIF
RINA Tutorial to the EC
100
E-mallDIF
E-mallDIF
Metropolitan DIFConnectivity 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
MRBR
BR
IR
BR
BR
ISPBR
BR
BR
IRIR
BR
IR
IR
IR
MRBR
BR
BR
IR BRBR
SubDIF 3
BR
SubDIF 1
SubDIF 2
Regional DIF
E-mallDIF
E-mallDIF
E-mallDIF
E-mallDIF
E-mallDIF
E.mallDIF
IR = IPCP at Interior RouterBR = IPCP at Border Router
E-mallDIF
RINA Tutorial to the EC
101
Regional DIFConnectivity 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.
MRBR
BR
IR
BR
BR
ISPBR
BR
BR
IRIR
BR
IR
IR
IR
MRBR
BR
BR
IRMRBRBRBR
SubDIF 3
BR
SubDIF 1
SubDIF 2
Backbone DIF
MetroDIF
Metro DIF
Metro DIFMetro
DIF
MetroDIF
MetroDIF
IR = IPCP at Interior RouterBR = IPCP at Border Router
RINA Tutorial to the EC
102
Backbone DIFConnectivity 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 RouterBR = IPCP at Border Router
BRBR
BR
BR
BR
BR
IR
IR
IR
IR
IR
IR
IR
RegionalDIF
RegionalDIF
RegionalDIF
RegionalDIF
RegionalDIF
RegionalDIF
RINA Tutorial to the EC
103
INTERNETWORKING
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
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
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
107
5G
RINA 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 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
109
BorderRouter
Service Provider NetworksExample scenario (Mobile networks)
P2P DIF
Metro DIF
Provider Fixed Network(necklace with e-mall at the top)
P2P DIF
BorderRouter
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
BorderRouter
Regional DIF
P2P DIF
Mobile Infrastructure NetworkCustomer Terminal
P2P DIF
InteriorRouter
BorderRouter
P2P DIF
Backbone DIF
Regional
Metro
District
P2P DIF
InteriorRouter
RINA Tutorial to the EC
110
Radio Access DIF and District DIFExample connectivity graphs
Multi-homed host
BR
BS
H H H
BS
H
MetroDIF
MetroDIF
MetroDIF
BR
BS
H H H
BS
H
MetroDIF
MetroDIF
MetroDIF
Multi-homed host
MetroDIF
MetroDIF
MetroDIF
District DIF 1 District DIF 2
Radio DIFRadio
DIF Radio DIFRadio
DIF
DISTRICT DIF
BS = IPCP at Base Station H = IPCP at Host
BR = IPCP at Border Router
BS
H
BS
H HH
H
Multi-access DIF 1(radio) Multi-access DIF 2
(radio)
DistrictDIF
DistrictDIF
DistrictDIF
DistrictDIF
DistrictDIF
DistrictDIF
MULTI-ACCESS RADIO DIF
BS = IPCP at Base Station H = IPCP at Host
RINA Tutorial to the EC
111
E-mallDIF
Metro DIF and Regional DIFExample connectivity graphs
METRO DIF
H = IPCP at HostBR = IPCP at Border Router
H H H H H
BR
H H H H H
BR
Multi-homed host
Reg.DIF
H H H HH
BR
H
DistrictDIF
DistrictDIF
DistrictDIF
BR
RegionalDIF
H
H H HH H HH H H HH H HH H H HH H HH H H HH H H
MetroDIF
BR
HH H HH H H HH H HH H H HH H HH H HH H HH
MetroDIF
BR
BRMetro DIF
(fixed)
Public Internet DIF REGIONAL DIF
H = IPCP at HostBR = IPCP at Border Router
RINA Tutorial to the EC
112
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)
RINA Tutorial to the EC
113
QUALITY OF SERVICE, NET NEUTRALITY
RINA Tutorial to the EC
114
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 …
RINA Tutorial to the EC
RINA tutorial to the EC 115
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 116
Propagating QoS requirements through the layers
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIFDIF
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..)
117
DEPLOYING RINA TODAY
RINA Tutorial to the EC
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
119
Shim DIFsGeneral 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.
RINA Tutorial to the EC
Shim DIF over 802.1QEnvironment
• (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
121
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)
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
122
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
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
Backbonerouter
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
123
Faux sockets APIAn 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 flowRINA Tutorial to the EC
RINA Tutorial to the EC 124
RINA STATUS, HOW CAN THE EC HELP MOVE RINA FORWARD?
4
T-5 Alternatives to TCP/IP 125
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
126
Flow of RINA R&D activities
Prototyping & ToolDevelopment
Different Platforms
Java VM
Linux OS
Android OS
NetFPGA
Coexisting with
different technologies
TCP/UDP/IP
VLANs
WiFi
LTEMPLS
Prototypes & Tools
Tools
Test apps
Prot. analyz
SDKs
Research on RINA
reference model
Core RINA specs
Research on policies for
different areas
Data transfer
Management
Security
Routing Resource allocation
Enrollment
Application discovery
MultiplexingDIF
creation
Policy specs
Design and development of
simulators
Simulators
Study different use cases and deployment
options
Use case analy
sis
Experimentation and validation
Data and
conclusions
New Insights &
Invariances
RINA Tutorial to the EC
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
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)
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
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)
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
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
133
Open source IRATI
• 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• [email protected]
• Procedures to contribute under discussion, doc ongoing
RINA tutorial to the EC 134
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)
1
2
3
RINA tutorial to the EC 135
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
4
5
Thanks for your attention!ict-pristine.eu
pouzinsociety.org@ictpristine
@iratiproject