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. 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. 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. DECONSTRUCTING THE INTERNET
RINA Tutorial to the EC 4
1

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. 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. 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
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.
9RINA Tutorial to the EC © John Day, 2014
Rights Reserved

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. 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. 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. 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. 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. 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. 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. 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. 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. • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. • 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. • 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. INTRODUCING RINA
RINA Tutorial to the EC 45
2

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. .
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. 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. © John Day, 2014
Rights Reserved
63RINA Tutorial to the EC

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. 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. 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. © John Day, 2014
Rights Reserved
67RINA Tutorial to the EC

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. 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. 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. 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. 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. 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. 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. 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. “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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. IMPLICATIONS AND IMPACT
RINA Tutorial to the EC 91
3

77. SIMPLER, CHEAPER, MORE
PREDICTABLE NETWORKS
T-5 Alternatives to TCP/IP 92

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. INTERNETWORKING
103

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. 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. 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. 5G
107RINA Tutorial to the EC

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. 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. 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. 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. 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. QUALITY OF SERVICE, NET
NEUTRALITY
113RINA Tutorial to the EC

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. 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. 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. DEPLOYING RINA TODAY
117RINA Tutorial to the EC

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. 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. 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. 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. 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. 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. RINA STATUS, HOW CAN THE EC HELP
MOVE RINA FORWARD?
RINA Tutorial to the EC 124
4

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Thanks for your attention!
ict-pristine.eu
pouzinsociety.org
@ictpristine
@iratiproject