RINA Tutorial @ IEEE Globecom 2014

T-5: Alternatives to TCP-IP tutorial
IEEE Globecom 2014. Austin, December 8th 2014
John Day, Lou Chitkushev (Boston University)
Eduard Grasa (Fundació i2CAT)
Francesco Salvestrini (Nextworks)
Dimitri Staessens (iMinds)
T-5 Alternatives to TCP/IP

Timing of the tutorial
T-5 Alternatives to TCP/IP 2

John Day
THE LOST LAYER: LESSONS TO BE
LEARNED FROM THE PAST

Preamble
• A Couple of Remarks on the Nature of Layering and a Quiz:
• The advent of packet switching required much more
complex software than heretofore, and so the concept of
layers was brought in from operating systems.
• In operating systems, layers were seemingly a convenience,
one design choice.
• Why Do We Use Layers in Network Architecture?
• In networks, they are a necessity.
© John Day, 2014
T-5 Alternatives to TCP/IP Rights Reserved 4

The (really) Important Thing about Layers
(From first lecture of my intro to networks course)
• Networks have loci of distributed shared state with
different scopes
• At the very least, differences of scope require different
layers.
• It is this property that makes the earlier telephony or
datacomm “beads-on-a-string” model untenable.
– – Or any other proposal that does not accommodate scope.
• This has always been understood.
Host or End System
Router
Increasing
Scope
T-5 Alternatives to TCP/IP © John Day, 2014
Rights Reserved
5

Refining the Concept of Layer
• The Necessary and (usually) Sufficient Condition for a Layer is
that there are loci of shared state of different scope.
• For Operating Systems and Networks, layers are ranges of resource
allocation.
• If there are layers of the same scope, their functions must be
completely independent.
• Dykstra wasn’t wrong: Functions do not repeat
. . . in layers of the same scope.
• The hardware at the time was so constrained he could only see one scope.
• If there is partitioning within the layer, it will generally be
orthogonal to the attributes that impose layers.
– Do All Layered Models Follow These Rules? Probably not. At least
Resource Allocation models do. Perhaps all those that exhibit scope.
Rights Reserved
6

The Beads on A String Model
phone CO CO phone
• 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.
Rights Reserved
7

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.

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!

The Cyclades Architecture (1972)
Host or End System
Application
Transport
Network
Data Link
Physical
• Transport Service provides end-to-end reliability.
• In that case, hop-by-hop reliability does not have to be perfect.
• Need only be sufficiently reliable to make end-to-end cost effective.
• Over a connectionless datagram network, Cigale
• Yields a simpler, more effective and robust data network.
• CYCLADES brings in the traditional layering from operating systems.
• This represents a new model, in fact, a new paradigm completely at odds with the beads-on-
a-string model.
Router
TS: End-to-End Reliability
Cigale Subnet
Rights Reserved
10

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. Not by a long shot!
Rights Reserved
11

1972 Was an Interesting Year
• Tinker AFB joined the ‘Net exposing the multihoming problem.
Host
• The ARPANET had its coming out at ICCC ‘72.
• As fallout from ICCC 72, the research networks decided it would be
good to form an International Network Working Group.
– ARPANET, NPL, CYCLADES, and other researchers
– Chartered as IFIP WG6.1 very soon after
• Major project was an Internetwork Transport Protocol.
– Also a virtual terminal protocol
– And work on formal description techniques
8 6
IMP IMP
Rights Reserved
12

A Nasty Brawl Was Shaping Up
The Phone Companies
Against
the Computer Companies
and
Everyone against IBM
Rights Reserved
13

In Networking
IBM Found Itself at a Dead-End
Mainframe
You can always make a peer architecture hierarchical
But you can’t go the other way.
But IBM and the PTTs had carefully stayed out of each other’s turf.
Had IBM made SNA a peer network and subset it for the 70s hierarchical
market, the Internet would have been nothing but an interesting research project.
© John Day, 2014
Rights Reserved

While the New Model Made Perfect Sense to Computing,
It Was a Threat to Phone Companies.
• Transport Seals Off the Lower Layers from Applications.
—Making the Network a Commodity, with very little possibility for value-add.
• TPC counters that Transport Layers are unnecessary, their networks
are reliable.
Transport
The Network
And they have their head in the sand, “Data will never exceed voice traffic”
T-5 Alternatives to TCP/IP 15 © John Day, 2014
Rights Reserved

Meanwhile Back at INWG
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.
Rights Reserved

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.
Rights Reserved
17

The SimilarityAmong 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:
Internetwork Transport Layer
Network Layer
Data Link
Layer
TCP
IP
SNDC
SNAC
LLC
MAC
• 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.
Rights Reserved
18

INWG’s Internet Model
Internet Gateways
Host Host
Application
Internet
Network
Data Link
Application
Internet
Network
• 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
Net 1 Net 2 Net 3
Rights Reserved
19

How Did They Lose a Layer?
• To Hazard a Guess: (This is subtle so pay close attention)
– A Case of Sorcerer’s Apprentices (Thought they knew more than they did)
– The Internet was a DoD project with the ARPANET at its center
• Built and operated by BBN. Only BBN made IMPs
– In a sense, BBN was their phone company, e.g. provider.
– The initial growth was LANs at the Edge connected by
• Internet Gateways: Ethernet on one side; BBN 1822 or X.25 on the other.
• The ARPANET had no “peers” in this environment.
Host Host
Internet
Gateway
TCP
ARPANET
The ARPANET
MAC 1822
An Ethernet
Now we split IP from TCP
Remember, only one or two people involved
in this were also involved in INWG
TCP
MAC
1822
TCP
ARPANET
The View About 1976 Before IP is Split from TCP
Rights Reserved
20

How Did They Lose A Layer? II
After IP is Split Off
TCP
ARPANET
1822
MAC
Router
TCP
IP IP
The View After 1976 Now IP is Split from TCP
TCP
ARPANET
Host
TCP
IP
• But the ARPANET is a black box. Only BBN can see inside it.
• So to everyone else it looks like just another LAN.
– They start to think that way.
• Most of the new entries are workstations on LANs being
connected together over short and long distances (with leased
lines).
• Which leads to a picture that looks like:
1822
An Ethernet
IP IP IP
MAC
Host
Internet
Gateway
PPP
MAC
An Ethernet
The ARPANET
Rights Reserved
21

How Did They Lose a Layer? III
Host Host
TCP
IP
MAC
An Ethernet
Router Router
TCP
IP IP
PPP
MAC
An Ethernet
Leased Line
TCP
IP IP
MAC
PPP
TCP
IP
MAC
• And there are lots of them connecting to each other!
– The ARPANET is becoming less and less important.
• Voilà! Did you see it disappear?
– This is not an Internet! It is a beads-on-a-string Network!
– Just like the ITU!!
– We have Met the Enemy and He is Us! -Walt Kelly 1970
– No Internet Gateways, only Routers. The term disappears in the early 80s
• Separating IP from TCP; not understanding the importance of
scope; the misconception of one protocol, one layer; just doing
the next thing with no plan; all contributed to being an Internet
in name only.
Rights Reserved
22

So What Layer Did They Lose?
• It is not obvious.
• At first glance, one might say the Network Layer.
– The Protocol is called IP after all!
– 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!
– 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, . . .
They Lost the Internet Layer!!!
Rights Reserved
23

The Big Mistake:
Splitting IP from TCP
• The Rules say if there are two layers of the same scope, the
functions must be completely independent.
• Are Separating Error and Flow Control from Relaying and
Multiplexing independent? No!
– IP also handles fragmentation across networks.
– Remember, Don’t repeat functions in different layers of the same scope.
• Problem: IP fragmentation doesn’t work.
– IP has to receive all of the fragments of the same packet to reassemble.
– Retransmissions by TCP are distinct and not recognized by IP.
• Must be held for MPL (5 secs!).
• There can be considerable buffer space occupied.
• There is a fix:
MTU Discovery.
– The equivalent of “Doc, it hurts when I do this!” “Then don’t do it.”
• Actually the fix doesn’t work either: many nets filter ICMP.
– Not a “big” problem, but big enough to be suspicious.
Rights Reserved
24

But it is the Nature of the Problem
That is Interesting
• The problem arises because there is a dependency between IP and
TCP. The rule is broken.
– It tries to make it a beads-on-a string solution.
• A Careful Analysis of this Class of Protocols shows that the Functions
naturally cleave (orthogonally) along lines of Control and Data.
Relaying/ Muxing
Data
Transfer
• TCP was split in the Wrong Direction!
• It is one layer, not two.
– IP was a bad idea.
• Are There Other Implications?
Data Transfer
Control
Delimiting
Seq Frag/Reassemb
SDU Protection
Retransmission and
Flow Control
Rights Reserved
25

What Do We Mean by
Separating Mechanism and Policy
• Concept first proposed by Bill Wulf [1975] for operating
systems.
• Separating what is common across solutions from what is uncommon.
• Mechanics of memory management are the same, allocation scheme or
page replacement policy is what varies.
• In protocols, there are a few mechanisms. Virtually all of the
variation is in the policies.
– Acknowledgement is mechanism; when to Ack is policy.
– This has major implication for the structure of protocols.
– By not separating mechanism and policy, we have been saying there is
one point in ~8 dimensional space that solves everything!
• Absurd! No one would expect that!
• We will apply this across the board to simplify and ensure that
cooperating layers behave in a compatible manner.
• Leverage is in the commonality, but letting what must vary vary.
– Never take it to extremes. It is subtle task.

The Structure of Protocols
• If we separate mechanism and policy, we find there are
• Two kinds of mechanisms:
– Tightly-Bound: Those that must be associated with the Transfer PDU
• policy is imposed by the sender.
– Loosely-Bound: Those that don’t have to be.
• policy is imposed by the receiver.
– Furthermore, the two are only loosely coupled through a state vector.
• Implies a very different structure for protocols and their implementations
• Noting that syntactic differences are minimal, we can conclude
that
• There is one data transfer protocol with a small number of
encodings.
Tightly-bound
(pipelined)
Loosely-bound
(Policy processing)

Watson’s Results (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
• 1981 paper, Watson shows that TCP has all three timers and more.
– Matta et al. (2009) shows that delta-t is more robust under harsh
conditions than TCP. Boddapati et al. (2012) shows that it is more secure.
Rights Reserved
28

Implications of Watson’s Results
• No explicit state synchronization, i.e. hard state, is necessary.
• SYNs, FINs are unnecessary
• All properly designed data transfer protocols are soft-state.
• Including protocols like HDLC
• And One Other Thing:
• Watson’s result also defines the bounds of networking or IPC:
– It is IPC if and only if Maximum Packet Lifetime can be bounded.
– If MPL can’t be bounded, it is remote storage.
Rights Reserved
29

A Chance to Get Things on Track
• We knew in 1972, that we needed Application Names and some
kind of Directory.
• Downloading the Host file from the NIC was clearly temporary.
• When the time came to automate it, it would be a good time to
introduce Application Names!
• Nope, Just Automate the Host File. Big step backwards with
DNS.
• Now we have domain names
– Macros for IP addresses
• And URLs
– Macros for jump points in low memory
– The path to the Application is named, but Nothing names the
Application.
Rights Reserved
30

Then in‘86: Congestion Collapse
• Caught Flat-footed. Why? Everyone knew about this?
– Had been investigated for 15 years at that point
• With a Network Architecture they put it in Transport.
– Worst place.
• Most important property of any congestion control scheme is
minimizing time to notify. Internet maximizes it and its variance.
• And implicit detection makes it predatory.
– Thwarts doing QoS in the lower layers, since TCP Congestion Avoidance is a
jitter-generator!
– Virtually impossible to fix
• Whereas
Rights Reserved
31

Congestion Control in an Internet is
Clearly a Network Problem
Internet Gateways
Host Host
Application
Internet
Network
Data Link
Application
Internet
Network
• 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 its effects to a
specific network and to a specific layer.
Data Link
Net 1 Net 2 Net 3
Rights Reserved
32

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
• Router vendors played them for suckers and they fell for it.
– Not secure, can’t use for configuration.
– (Isn’t ASN.1 an encryption algorithm?)
– Much better to send passwords in the clear.
– It is all about account control
Rights Reserved
33

IPv6 Still Names the Interface?
Why on Earth?
• Known about this problem since 1972
– No Multihoming, kludged mobility
– Notice in an Internet Architecture this is straightforward.
– Signs the Internet crowd didn’t understand the Tinker AFB lesson.
– DARPA never made them fix it.
• By the Time of IPng, Tradition trumps Everything.
• When they can’t ignore it any longer, and given post-IPng
trauma they look for a workaround.
• “Deep thought” yields
Voilà!
Loc/Id Split!
Rights Reserved
34

Wait A Minute!
Names the Interface?
• Remember Tinker AFB? The answer was obvious. Just like OSs!
• 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)
Rights Reserved

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
– URLs name a path to an application
Application
Socket (local)
IP Address
MAC Address
Application
Name
Node Address
Point of Attachment
Address
As if your computer worked only with absolute memory addresses.
(kinda like DOS, isn’t it?)
Rights Reserved

Loc/ID Split
(these are people who
lost a layer to begin with, right?)
• There are 3 problems with loc/id split:
• First off:
– Saltzer [1977] defines “resolve” as in “resolving a name” as “to
locate an object in a particular context, given its name.”
– In computing, all names locate something.
• So either nothing can be identified without locating it, nor located
without identifying it, OR
• Hence this is either a false distinction or it is meaningless.
Rights Reserved

What Does Loc/Id Name?
• Second, the locator is the interface not the end of the path.
– Getting to the last box is not the end of the path. (beads-on-a-string again)
Endpoint Identifier
Locators
• Third, the “identifier” locates communication with the
application.
• Past the end of the path!
– It names everything but the node, where all paths terminate.
• There is no workaround. IP is fundamentally flawed.
Rights Reserved

Never Get a Busy Signal on the Internet!
2010 They Discovered Buffer Bloat!
Flow Control
No Interface
Flow Control
• Golly Gee Whiz! What a Surprise!!
• With Plenty of Memory in NICs, Getting huge amounts of
buffer space backing up behind flow control.
• Well, Duh! What did you think was going to happen?
– If you push back, it has to go somewhere!
– Now you can have local congestion collapse!
• If peer flow control in the protocol, pretty obvious one
needs interface flow control as well.
Rights Reserved

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.
Rights Reserved

Taking Stock
• The Internet has:
– Botched the protocol design
– Botched the architecture
– Botched the naming and addressing
– When they had an opportunity move in the right direction with application
names, they didn’t. They did DNS.
– When they had an opportunity to move in the right direction with node
addresses, they didn’t. They did IPv6.
– More than Botched Network Management
– Botched Congestion Control twice
– Once so bad it probably can not be fixed.
– Botched Security!
• By my count this makes them 0 for 9!
• It defies reason! Do these guys have an anti-Midas touch or wha!?
Rights Reserved

But It is a Triumph!
• But It Works!
• So did DOS. Still does.
• ‘With Sufficient Thrust even Pigs Can Fly!’ - RFC 1925
• As long as fiber and Moore’s Law stayed ahead of Internet
Growth, there was no need to confront the mistakes.
– Or even notice that they were mistakes.
• Now it is catching up to us, is limiting, and it can’t be fixed.
– Fundamentally flawed from the start, a dead end.
– Any further effort based on IP is a waste of time and effort.
• Throwing good money after bad
– Every patch (and that is all we are seeing) is taking us further from where
we need to be.
(By that argument, so was DOS)
Rights Reserved

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
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!!
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.
• The Meddling of Big Government Caused the Entire Mess
– How Do I Know This is What Would Have Happened?
– Because It Did.
Rights Reserved

It Was the Computer Companies
Who Were Doing the OSI Network Layer
• The other major effort at the time.
• The well-known 7-layer model was adopted at the first meeting
in March 1978 and frozen. After that, they had to work within
that.
• They knew they would have to accommodate different networks
of different quality and different technology.
• One of their concerns in the Network Layer deliberations was
interworking over a less capable network:
high-quality
network
• Would need to enhance the less capable network with an
additional protocol
low-quality
network
high-quality
network
high-quality
network
low-quality
network
high-quality
network
Rights Reserved

They Sub-Divided the Network Layer
• This concern and the recognition that there would be
different networks interworking lead the computer
companies to divide the Network Layer into three
sublayers, which might be optional depending on
configuration:
Subnet Independent
Convergence (SNIC)
Subnet Dependent
Convergence (SNDC)
Subnet Access (SNAC)
Rights Reserved

And Came to the INWG Model
Transport Layer
Subnet Independent
Subnet Dependent
Subnet Access
Data Link LLC
Data Link MAC
• With the Transport Layer, this is the same as the INWG model.
• For different political reasons, OSI made a similar split to TCP/IP.
• Remember PTTs didn’t want a Transport Layer at all.
– This is independent confirmation. None of the OSI Network Layer group had
been involved in INWG.
• So OSI had an Internet Architecture and the Internet has an ITU-like
Network Architecture.
• You just can’t make this stuff up!
• And signs of a repeating structure.
Rights Reserved

INWG Had Been on The Right Track
Internetwork Transport Layer
Network Layer
Data Link
Layer
• They were Close to Seeing it was a Repeating Structure
– A Structure We Will See Again.
• Had the Research Community Maintained a United Front. Had
They Not Assumed They Had Final Answers.
• Had Politics Not Intervened in a Major Way. Had Business
Addressed Markets as They Arose.
– Internet boom and bust would probably have been much moderated
• We Could Have Avoided Many of the Current Problems
– There Would Still be Security Threats, but far fewer.
Rights Reserved

Not the Results I Expected
• 20 Years Ago when I embarked on this effort (in my spare time) to
nail down what it was I knew about Networking, I assumed that
the Internet and OSI weren’t that different.
– There were some things in the Internet I knew we hadn’t fixed, but
they weren’t hard to fix. There were some advances that were in OSI
we needed to include and a lot of junk from the PTTs to get rid of.
• But the more I pulled on threads sticking out here and there, the
more the whole thing unraveled.
– The more it became apparent that both were wrong and it was worse
than first suspected. Most “innovation” and “advances” in the Internet
were myths.
• But in its place emerged an incredibly simple model of
extraordinary simplicity and beauty. And the more we push on
it, the more it revealed.
• It has truly opened a New World for us to explore.
Rights Reserved

Others Saw There Were Problems
• Nearly 15 Years Ago, DARPA Funded NewArch
– All the top minds of the Internet to find a new architecture
– Two years later, they came up dry
• At the same time, the National Research Council issued a report that said in
part “t
he insiders [network researchers] had not shown that they had managed to exercise the usual elements
of a successful research program, so a back-to-basics message was fitting.”
– Must have been sobering.
• When DARPA was unwilling to throw good money after bad, they went to NSF to
fund FIND and GENI, massive projects to FIND the Answer.
– At first, there promises of bold new ideas! Clean-slate! Start from Scratch! Etc.
– That gave way to ‘The Internet is best when it evolves to new solutions.’
– Which has now given way to ‘The Internet is such a success, we should build on that
success’
– By 2010, Having not come up with anything, consensus was that they must look outside
networking: Classic indicator of running out of ideas. Someone else must have them.
• What was the problem?
Rights Reserved

Concentrated on What To Build
• Never asked what don’t we understand?
– As we just saw, there is a fair amount they don’t understand
• The emphasis on group efforts ensures GroupThink, no break with the past:
– The end-to-end principle - Emphasizes circuit-switching (source routing)
– loc/id split – We already saw its importance
– ITU Beads-on-a-String – still haven’t noticed the lost layer
– ITU Control and Data Planes - ISDN was such an inspiration for the Internet
– The OSI Narrow Waist Concept - First proposed by IBM, 2nd OSI meeting Oct 1978.
50
John Aschenbrenner’s Martini Glass
model, later cleaned up as an hour glass.
- ISO TC97/SC16/N117
© John Day, 2014
Rights Reserved

Finally, they just fund their favorite ideas
• Named Data Network
• XIA
• MobilityFirst
• ChoiceNet
• Nebula
Rights Reserved

Named Data Networking (NDN)
• “To receive data a consumer sends an Interest Packet, which carries a name that identifies
the desired data”.
– Same semantics as a database query, the difference being that in NDN databases are distributed and
users don’t know where the content is.
– This implies routing on flat “flat addresses” for every data element: 100sTB for routing tables.
• NDN pushes distributed database research and Moore’s Law, not a network model
– Recasting NDN-like capability in RINA model would be a DAF specialized for distributed database
applications, with much simpler operation and security.
© John Day, 2014
Investigating RINA as an Alternative to TCP/IP 52
Rights Reserved

XIA – Trustworthy and Evolvable
• There is that word again
• Their big deal is communication among “principals”
– Not realizing hosts and devices are irrelevant, just boxes.
– Communication is always with a “process”
• Addresses are Directed Acyclic Graphs, impressive
– IOW, hierarchical and route dependent.
• “Great deal of work on supporting mobility”
– Needs rendezvous points and a stationary peer
• Odd, No work at all, Mobility solved itself with no need of home.
• Security method seems heavy handed and complex
• One of the only ones to consider congestion control
Rights Reserved

MobilityFirst-and Trustworthy
• Also into naming “principals” (note the groupthink)
• More concerned about security of a name, not clear if they are addresses.
• Special cases for connection mobility, individual mobility, and simultaneous
mobility. Far too complicated
• Mobility (for some reason) requires a rendezvous point. Not unlike a major
digression from previous Internet proposals.
• Also doing the NDN approach, see multicast as part of this:
– Basically repeating the OSI descriptive name work, which was abandoned as too
pathological once its properties were understood.
Rights Reserved

ChoiceNet and Nebula
• Weren’t funded for 2nd phase
– ChoiceNet tried to investigate new business models,
– Create markets within the network
– Nebula had the most difficulty
– Couldn’t agree on what an architecture was
– Identified problems it had in common with other proposals
– Worked on sub-problems but had no over-arching design
• Then found it hard to bring them together in a cohesive whole
– Very connection-oriented, contains all of the common concepts.
Rights Reserved

Software Defined Networking (SDN)
• A set of “rules of thumb” to centralize functions in the equipment (such as
routing) requiring a flat ITU model and creating single points of failure.
Source: ONF
• The “control layer” is the Element
Managers to appease equipment
vendors.
• No agreements in south-bound and
north-bound APIs (protocols) .. SDN
does not specify what they should look
like.
• Only differences with traditional network management:
• Greater centralization impairs resiliency and response time to failure, suffers from the
octopus nervous system faults, and from “too many cooks”
© John Day, 2014
Rights Reserved

To Summarize
• Not network architectures (a style of construction), just buildings
• Focused on what to build, not what is not understood
• With Whiteboards, Slate-cleaning technology has been lost.
• Descriptive, not predictive. Few invariances identified.
• Many assumptions from the current Internet architecture still in (hourglass
model, flat network, etc.)
• Do not provide simpler (or any) answers to current problems
• Some do not even target networking
• ... discussion welcome if you don’t agree
– After the tutorial 
• But there is a simple solution and it was in front of us all along.
Investigating RINA as an Alternative to TCP/IP 57 © John Day, 2014
Rights Reserved

John Day, Lou Chitkushev
INTRODUCTION TO RINA

A Quick Review
1: Start with the Basics
Two applications communicating in the same system.
Application
Processes
IPC Facility
Communication within
a Single Processing System
Port
Ids
A B
Application
Flow
This is establishes the API. The Application
should not be able to distinguish a slow
correspondent from operating over the Network.
Rights Reserved

How Does It Work Now?
Application
Processes
Port
Ids
FA FA
Distributed
IPC Facility
EFCP EFCP
• Turns out that Management is the first capability needed to find the other application.
Then of course to do that one needs,
• Some sort of error and flow control protocol to transfer information between the two
systems.
Op Seq # CRC Data
Rights Reserved

Simultaneous Communication
Between Two Systems
i.e. multiple applications at the same time
• Requires two new capabilities
EFCP EFCP
EFCP EFCP
EFCP EFCP
Mux Mux
• First, Will have to add the ability in EFCP to distinguish one flow from another.
• Typically use the port-ids of the source and destination.
Op Seq # CRC Data
Connection-id
Dest-port Src-port
•Will also need an application to manage multiple users of a single resource.
Rights Reserved

4: Communication with N Systems
Systems
Rights Reserved

A Little Re-organizing
IAP
A Virtual IPC Facility? Res
Finder
Alloc
So we have a Distributed IPC Facility for each Interface, then to
maintain the API we need an application over all of them to
manage their use.
Rights Reserved

5: Communicating with N Systems
(On the Cheap)
Dedicated IPC
Systems
Hosts
By dedicating systems to IPC, reduce the number of lines required and even out
usage by recognizing that not everyone talks to everyone else the same amount.
Rights Reserved

Communications on the Cheap
• But relaying systems over a wider scope requires carrying addresses
• And creates problems too.
– Can’t avoid transient congestion and bit errors in their memories.
• Will have to have an EFCP operating over the relays to ensure the
requested QoS reliability parameters
EFCP EFCP
Dest Addr Src Addr
Common Relaying and Multiplexing Application Header
Interface
IPC
Processes
Relaying
Relaying Application
PM
Interface
IPC
Processes
Rights Reserved

The IPC Model
(A Purely CS View)
User Applications
Relaying
Appl
EFCP
EFCP
Mux
Mux
EFCP EFCP EFCP EFCP EFCP EFCP
Distributed IPC Facilities
Rights Reserved

The Implications
• Networking is IPC and only IPC.
– We had been concentrating on the differences, rather than the similarities.
– Of course, there are layers! What else do you call cooperating shared state
that is treated as a black box? A waffle!?
• Notice the model never required separate protocols for relaying and
error and flow control, i.e. separating TCP and IP. Always do what the
model says.*
• 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.
– As we will see, strong layering is better than soft layering.
• 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.
• But this also begs the question:
– If a layer is a Distributed Application that does IPC, then what is a
Distributed Application?
Rights Reserved

That Wasn’t the Only Question
• Well Over a Decade Ago
• We Figured Out that Layers Repeated
• That Created a Potential Problem:
– Dykstra says they don’t!
• That lead to discovering that OSs do too
Rights Reserved

So Looking at Dykstra’s Layers
• But thinking about Dykstra’s layers:
– A bit arcane, but 1968 was a long time ago. Machines were far
smaller and much more resource constrained.
• We wouldn’t do those layers in an OS today.
• What would we do . . . .
– kernel, supervisor, user . . .
– and they all do the same thing!
• scheduling, memory management and IPC
– OMG! OSs are recursive as well!
• Of course this is what the virtualization fad has hacked into
without seeing it.
• That lead to
hmmmmmm
Rights Reserved

The Structure of a Process
Task sched
Tasks
Mem
Mngt
IPC
• A Process has a recursive structure consisting of task scheduling,
memory management, and inteprocess communication to manage its
tasks, which are, in turn, processes.
Rights Reserved

This Has Implications for DAFs
• If a DIF is a set of IPC Processes,
– really Distributed IPC Processes (DIPs?)
• Then a DAF must be a set of Distributed Application
Processes
– What else but, DAPs!
• What Does a DAP look like?
Rights Reserved

Structure of DAP
• Local Resource Management is the basic Process structure.
– Have to manage local resources.
• Then a task for each of these to coordinate with other DAPs
in the DAF.
Sched
Mem
Mgt
IPC
Local Resource
Management
Tasks
IPC Management
RIB Daemon
Resource Allocation
Dist DAF Management
Distributed Resource
Management
Rights Reserved

Distributed Application Facility (DAF)
RIB Daemon
• A DAF consists of cooperating DAPs. Each one has
• The Basic Infrastructure:
Allocation
– Resource Management - Cooperates with its peers to manage load, generate forwarding table, etc.
– RIB Daemon - ensures that information for tasks is available on whatever period or event require, a
schema pager.
– IPC Management - manages the supporting DIFs, multiplexing and SDU Protection.
– Tasks - the real work specific to why the DAF exists.
• DAPs might be assigned synonyms with scope within the DAF and structured to
facilitate use within the DAF. (!)
• Therefore, a DIF is . . . .
DAF Management
IPC Management Common Application
Protocol
IRM
Tasks
© John Day, 2014
Rights Reserved

Distributed IPC Facility (DIF)
Flow Allocator
EFCP
• A DAF consists of cooperating DAPs. Each one has.
• The Basic Infrastructure:
RIB Daemon
Allocation
– Resource Management - Cooperates with its peers to manage load.
– RIB Daemon - ensures that information for tasks is available on whatever period or event
the tasks (and the DAF components) required, routing update, other event notifications
– IPC Management - manages the supporting DIFs, multiplexing and SDU Protection.
– Tasks - Flow Allocator, EFCP, and relaying.
• IPC Processes are assigned synonyms with scope within the DIF and structured to
facilitate routing.
DIF Management
IPC Management Common Application
Protocol
IRM
RMT
Rights Reserved

A Single Unified Model that Encompasses Operating
Systems, Distributed Applications and Networking
Operating Systems
Printer
Laptop Disk
OS - DAF
USB-DIF
WiFi-
DIF
Application Process
IRM
DAPs
IRM
DIFs
Task
sched
Mem
Mngt
IPC
Tasks
Rights Reserved

The Organization of
The RINA Reference Model
• Part 1: Basic Concepts of Distributed Systems
• Part 2: Distributed Applications
– Chapter 1: Basic Concepts of Distributed Applications
– Chapter 2: Introduction to Distributed Management Systems
• Part 3: Distributed InterProcess Communication
– Chapter 1: Fundamental Structure
– Chapter 2: DIF Operations
• New Chapters and Extensions are expected as we learn more.
Rights Reserved

The Structure of Protocols
• If we separate mechanism and policy, we find there are
• Two kinds of mechanisms:
– Tightly-Bound: Those that must be associated with the Transfer PDU
• policy is imposed by the sender.
– Loosely-Bound: Those that don’t have to be.
• policy is imposed by the receiver.
– Furthermore, the two are only loosely coupled through a state vector.
• Implies a very different structure for protocols and their implementations
• Noting that syntactic differences are minimal, we can conclude
that
• There is one data transfer protocol with a small number of
encodings.
Tightly-bound
(pipelined)
Loosely-bound
(Policy processing)
Rights Reserved

Implications: Protocols I
• Data Transfer Protocols modify state internal to the Protocol.
Application Protocols modify state external to the protocol.
• There are only two protocols (full stop):
– A data transfer protocol, based on Watson’s results,
– An Application protocol that can perform 6 operations on objects:
• Read/Write – Create/Delete – Start/Stop
– There is no distinct protocol like IP.
• Was just a common header fragment anyway.
• A Layer provides IPC to either another layer or to a Distributed
Application with a programming language model. The
application protocol is the “assembly language” for distributed
computing.
– As we shall see, we have now made network architecture independent
of protocols.
Rights Reserved

Flaw in the Concept of Connection
(in the Internet and OSI)
(N+1)-entities
(N)-address
• •
(N)-entities
(N)-connection
Connection-
Endpoint
(port-id)
• In both, a connection starts in the (N+1)-entity and goes to the peer (N+1)-entity.
– This is a beads-on-a-string view.
• (In OSI, while the PTTs insisted on it in the model, it was ignored in practice)
• This combines port allocation and synchronization
• What Watson is saying when he assumes:
– all connections exist all the time.
• Is that Port allocation and Synchronization are distinct.
Rights Reserved

Concept of Connection
Port-id
Synchronization
Connection
Endpoint
Port Allocation
Connection
• Instead delta-t works differently:
– Ports are allocated, then protocol machines create synchronization
(shared state)
– And connection-end points are bound to the port-ids.
– We use the term “connection” within the DIF; “flow,” for the service
provided
• Not conflating the two has significant implications.
– No traffic for 2MPL, connection disappears, but ports remain allocated
– Bindings are local. We will later see other implications of this.
Rights Reserved

The Connection Connectionless War
• The technical side of what was really an economic war.
– The Layered Model invalidated both the PTT and IBM business models.
– Connectionless removed the security blanket of determinism.
– The war created a bunker mentality that made understanding hard.
• All or nothing.
• For years, we saw it as the amount of shared state.
– Connections had lots of shared state; connectionless very little.
• A function of the layer, not a service. Not related to
reliability
– Not visible over the layer boundary.
– Ports must be allocated even for a connectionless flow.
• Later it became clear that
– As traffic becomes more deterministic, connections are preferred
• Down in the layers and in toward the backbone
– As traffic becomes more stochastic, connectionless is preferred
• As one moves up and toward the periphery
Rights Reserved

Resolving the CO/CL Problem
• Lets look at this very carefully
• What makes connection-oriented so brittle to failure?
• When a failure occurs, no one knows what to do.
• Have to go back to the edge to find out how to recover.
• What makes connectionless so resilient to failure?
• Everyone knows how to route everything!
• Just a minute! That means!
• Yes, connectionless isn’t minimal state, but maximal state.
• The dumb network ain’t so dumb.
• Where did we go wrong?
• We were focusing on the data transfer and ignoring the rest:
Rights Reserved

Applications and Communication: I
Is the Application in or out of the IPC environment?
• The early ARPANet/Internet didn’t worry too much about it. They didn’t need to.
They weren’t doing any new application development.
• By 1985, OSI had tackled the problem, partly due to turf. Was the Application process
inside or outside OSI?
• It wasn’t until the web came along that we had an example that in general an
application protocol might be part of many applications and an application might have
many application protocols.
• The only known example of a political turf battle leading to a major insight!
Rights Reserved

Applications and Communication: II
Application
Process
Application
Entity
Outside the Network
• The Application-Entity (AE) is that part of the application
concerned with communication, i.e. shared state with its peer.
– This will turn out to be the “tip of the iceberg,” part of a larger structure.
• The rest of the Application Process is concerned with the reason
for the application in the first place.
• An Application Process may have multiple AEs, they assumed,
for different application protocols.
Application
Entity
Inside the Network
Rights Reserved

BUT
As state earlier, there is only one application protocol
• That performs the following operations:
– Read/Write – Create/Delete – Start/Stop
– On various objects. Everything is just an object outside the protocol.
• Application protocols modify state outside the protocol.
• In that case, why do we need all this application-entity stuff?
– A particular collection of objects are required for an activity.
– May be shared with others, but has its own access control.
– One protocol, potentially shared objects, different state machines
– Hence, all application protocols are stateless, the state is in the
application.
– And, we will see that this was the tip of the iceberg.
Rights Reserved

Applications, e.g., routing,
resource allocation,
access control, etc.
86
What a Layer Looks Like
IPC
Transfer
• 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
Control
IPC Management
Delimiting
Transfer
Relaying/ Muxing
PDU Protection Common Application
Protocol
Application-entities Application Process
Rights Reserved

Only Three Kinds of Systems
Hosts
Interior
Routers
Border
Routers
• 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.
Rights Reserved

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.
Rights Reserved

How Does It Work?
Enrollment or Joining a Layer
(N-1)-DIF
(N)-DIF
A
• 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.)
Rights Reserved

How Does It Work?
Establishing Communication
A Ahh, look there! B
• 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
Rights Reserved

Routing at Different Layers
Hosts
Interior
Routers
Border
Routers
• 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.
Rights Reserved

Implications of the Model & Names
(Routing Table Size)
• Recursion either reduces the number of routes or shortens them.
Metros
Regionals
Backbone
Rights Reserved

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
Metros
Regionals
Backbone
(N)-Routing
Domains
(N-1)-Routing
Domains
Rights Reserved

Example of Topological Address Assignment
Metros
Regionals
W
N
S
E
•
• E3920
S4729
Possible Address Space
For Regional Networks
N and S would be similar
Possible Address Space
For Metro Networks
•
ESE8399
W
N
S
E
WW NW SW NE SE EE
•
WWW7428
Note that strictly
speaking the address
spaces are independent
Similarity in the upper part of the address
hierarchy can be leveraged to simplify router
calculations.
Rights Reserved

Names & Implications of the Model
(Basics)
Address
(N)-IPC-Process
Port -id
(N-1)-IPC-Process
• 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.
Rights Reserved

(Multihoming)
(N)-IPC-Process
Port -id
(N-1)-IPC-Process
• Yea, so? What is the big deal?
– It just works
Address
• PDU arrives at the (N-1)-IPC Process. If the address designates this IPC
Process, the CEP-id is bound to the port-id, so after stripping off (N-1)-PCI, it
passes it up.
• 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.
Rights Reserved

(Mobility)
(N)-IPC-Process
Port -id
(N-1)-IPC-Process
• Yea, so? What is the big deal?
Address
New Address
– 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.
Rights Reserved

The Skewed Necklace
(A Typical Mobile Network)
Base
Station
Metro
Subnet
Regional
Subnet
Mobile Infrastructure Network Traditional ISP Provider
Network with normal necklace with
an e-mall top layer.
• Space does not permit drawing networks at each layer. There would be
internal routers between the border routers in a real network.
• It appears that one could make the mobile host appear stationary to the top
layer, i.e. the top layer addresses don’t change because all the routing is
handled in the lower layers.
Rights Reserved

The Skewed Necklace
(DIF view)
Base
Station
Metro
Subnet
Regional
Subnet
Mobile Infrastructure Network Traditional ISP Provider
Network with normal necklace with
an e-mall top layer.
• Clearly more layers could be used to ensure the scope allows sufficient time for
updating relative to the time to cross the scope of the layer.
– Space does not permit drawing networks.
• It appears that one could make the mobile host appear stationary to the top layer,
i.e. the top layer addresses don’t change because all the routing is handled in the
lower layers.
Rights Reserved

What New Is Needed?
• Nothing
– Enrollment in a new DIF follows normal procedures
– Allocation of a flow follows normal procedures
– Changing the address of an IPC Process with in a DIF follows the
normal procedure.
– New points of attachments, i.e. new lower layer DIFs, are acquired
in the normal way.
• There are specific cases to work out here. In general, expect that a
wireless device will be probing for new PoAs. But then a system with
a down wireline interface should be doing the same thing.
– Current points of attachment are discarded when they can no
longer provide an acceptable QoS (criteria and measurement is policy
as it is in the wireline case).
Rights Reserved

Even the Shim DIF was Enlightening
DIF Boundary
Dest Src Protocol-id Stuff User-Data
• A Shim DIF creates the thinnest possible veneer to make a legacy layer service
look like a DIF.
• Both IP and Ethernet (without LLC) have a ‘protocol-id’ field
– Historically (1982) a problem: (N+1)-protocol identified in an (N)-protocol
• Without port-ids, there is no isolation and this implies that for each protocol
type, there can only be one “user” of the “flow.”
– There can be only one QoS-cube.
• Conclusion: Port-ids are necessary to a well-formed layer/DIF. These are ill-formed
layers.
– Ethernet with LLC is well-formed.
– Port-ids provide isolation.
Rights Reserved

To Unify WiFi and VLANs
BSS-id
We Have Applied This
Laptop
Access
Point
Router/
Cable Modem
Sndr/Rcvr
IP
“Ethernet” btwn SRC/DEST
Laptop Access
Point
Access
Point
Router/
Cable Modem
IP
“Ethernet” btwn SRC/DEST
Sndr/Rcvr Sndr/Rcvr
• Why Does WiFi have 3 or 4 Addresses?
– It is really two layers
– Three Addresses is a degenerate case (2 are the same)
• They May Look Very Different, But They Aren’t.
• They are Basically the Same Thing:
- Multiple Layers of the Same Rank using the Same Media
- VLAN Tags are Doing the Same Thing
Source: Students of BU
MET CS635 Fall 2014
Rights Reserved

We Call It WiLAN! ;-)
Station Station
Bridges
Wired Media DIFs
• One DIF for Each Media:
Access
Point
Wireless Media DIF
– Wired: Ethernet is now pt-to-pt. Enroll in a bridge. No
addresses needed.
– Wireless: Need addresses, use WiFi contention, and
‘Apple’-like enrollment
• Normal DIFs using different port-ids over the top.
• Much Simpler; Lower Overhead; Ethertype, Tags
Multiple DIFs with
potentially
different length
addresses and
different policies
unnecessary; No MAC addresses (Security problem anyway);
DIF operates over wired and wireless; probably more
secure as well.
Source: Students of BU
MET CS635 Fall 2014
Rights Reserved

(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.
Rights Reserved

(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.
DIF-Allocator
• 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.
Rights Reserved

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.
Rights Reserved

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.
Rights Reserved

“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
Rights Reserved

What is the Difference Between
Flow Control and Congestion Control?
Control
Data
Flow Control is a feedback mechanism co-located
with the resource being controlled.
Control
Notify
Data Data
Congestion Control is a feedback mechanism not
co-located with the resource being controlled.
Rights Reserved

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
Rights Reserved

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
Rights Reserved

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
Facebook Boutique My Net Utility SCADA
ISP 1 ISP 2 ISP 3
Internet Rodeo Drive
Internet Mall of America
Rights Reserved

How Does It Work?
The User’s Perspective
e-common DIFs
e-common DIFs
Provider Network
Provider Network
Local Customer
Local Customer
Network
Network
Peering DIF
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.
In this case, one host on the local network chooses to join
one of the available e-malls.
Rights Reserved

Before Tackling Security
A Word on Method
(hardly news by now)
• When trying to work out the IPC Model absolutely no thought was
given to security. All of the focus was just understanding the
structure.
• People kept asking, What about Security? Is there a security
layer?
• Didn’t Know. Hadn’t thought about it.
• There was the obvious:
– The recursion of the layer provided Isolation.
– That only the Application Name and local port-id were exposed to the
correspondents.
• Interesting, but hardly an answer
• But it wasn’t the time for those questions . . .
• At least not yet . . .
Rights Reserved

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
Rights Reserved

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
Facebook Boutique My Net Utility SCADA
ISP 1 ISP 2 ISP 3
Internet Rodeo Drive
Internet Mall of America
Rights Reserved

But When It Was Time
• The question was not, how to put in security?
• The question was,
• What does the IPC Model tell us about security?
– Remember, our first task is always understanding.
• Let the Problem Answer the Question!
– Let the Problem Tell Us What to Do.
Rights Reserved

The Problem Had a Lot to Say
• We Already Mentioned How Little is Exposed the Layer Above.
• The Original OS Model indicated where Access Control went.
• Creating the Application Connection for Enrollment indicated where Authentication
belonged, and that
– Authentication of Applications must be done by the Applications themselves.
– All members of the layer are authenticated within policy.
• SDU Protection clearly provided Confidentiality and Integrity.
• That implied that only Minimal trust was necessary:
– Only that the lower layer will deliver something to someone.
Port:=Allocate(Dest-Appl, params)
Access Control
Exercised
© John Day, 2014
Rights Reserved

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.
Rights Reserved

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, . . .
Rights Reserved

Decoupling Port Allocation and
Synchronization
Port-id
Port Allocation
Synchronization
Connection
Endpoint
Connection
• 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.
Rights Reserved

Decoupling Port Allocation and
Synchronization: No IPSec
Connection
Endpoint
Port-id
Port Allocation
Connection
SDU Protection SDU Protection
• IPsec is necessary with TCP/IP because no authentication and
Sequence numbers turn over too quickly: don’t repeat sequence
number with same CEP-id.
• With RINA and delta-t, IPC Processes all authenticated, SDU
Protection does the encryption, and packet sequence numbers slows
rollover, but if it does, then simply allocate a new connection
• And bind it to the same port-ids, old one disappears after 2MPL.
Rights Reserved

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.
Rights Reserved

Internet RINA
To Add
Security
Protocols 8 0
Non-Security
Mechanisms
59 0
Security Mechanisms 28 7
Copyright © 2012, Jeremiah Small. All Rights Reserved.
Rights Reserved

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.
Rights Reserved

Summing Up Security
• This is a MAJOR Improvement in Internet Security.
– Not only more secure, but for less cost, with less overhead.
• So is Internet Security solved?
– Hardly.
– Still need: to develop the plug-in policy modules
– to consider DDoS (we have some ideas)
– As well as protecting against Rogue IPC Processes
– and much more to explore and who knows what general principles
will fall out.
• Most attacks are in the Applications, this does nothing about that.
– But Much of this applies equally well to DAFs
• Model implies that OS security reduces to Bounds Checking on
Memory and IPC Security.
– May also make it harder, might be able to deflect more DDoS
attacks
Rights Reserved

There is Much More,
And Much More to Discover!
• A Claim: One will not find a structure that is both as rich
and as simple as this that is not equivalent to it. Prove us
wrong! ;-)
– That is the whole idea: Test Principles to Understand More, so
what we build isn’t a morass of patches. IOW, do some science
before builidng.
• An Invitation: Come explore it with us.
– There is much to explore:
• Believe it or not, I have left out a lot!
• How it applies to different environments, especially wireless.
• What are the dynamic properties?
– Routing, congestion control
• Start with Patterns in Network Architecture, Prentice Hall
– Check out related work at
– At www.pouzinsociety.org or
– http://irati.eu or http://ict-pristine.eu
– http://csr.bu.edu/rina

Eduard Grasa
DEPLOYING RINA IN THE WILD

How to design RINA Networks?
• Until here we hope to have provided multiple reasons
why RINA provides a simpler, cleaner yet more powerful
toolset for network architects than TCP/IP
• But how to put it all together to design real networks?

Designing RINA networks (I)
Number, scope of layers and goal of each one
• Decide the number and scope of the layers (DIFs) in the
network, . Example:
– Three ISPs that use multiple DIFs internally for traffic aggregation
purposes
– ISP alliance DIF: the three ISPs get together to support a number of
specialized DIFs
• Public Internet DIF (General purpose), Corporate VPN DIF, Interactive
Video DIF
Public Internet DIF
Interactive Video DIF Corporate VPN DIF
ISP 2 Metro DIF
ISP 2 Regional DIF
ISP 2 Backbone DIF
ISP 3 Metro DIF
ISP 3 Backbone DIF
ISP 1 Metro DIF
ISP 1 Backbone DIF
ISP Alliance DIF

Designing RINA networks (II)
QoS cubes to be supported by each layer
• Identify the types of traffic that should be served by each layer
and dimension it. Ideally, for each type of traffic, we would like
to know:
– Characterization in terms of burstiness, offered load, etc
– Required statistical bounds on loss and delay (e.g. 99% of
time loss should be less than 5%) -> can be derived from
required QoE
– Reliable and/or in order delivery of data required?
• From that information the number and characteristics of QoS
cubes required can be derived.

Designing RINA networks (III)
Policy sets of each layer
• Design new (or use existing) policy sets that allow each layer to
reach its design goals taking into account its operational
environment (offered traffic, QoS cubes supported, N-1 DIFs).
– Connectivity graph, addressing, routing, data transfer, delimiting, resource
allocation, relaying and multiplexing, authentication, authorization, SDU
protection, etc
IPC API
Data Transfer Data Transfer Control Layer Management
CACEP
Retransmission
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Retransmission
Control
Flow Control
RIB
Daemon
RIB
CDAP
Parser/Generator
Enrollment
Flow Allocation
Resource Allocation
Routing
Authentication
State Vector
SStatatete V Veecctotorr
DDaatata T Trarannsfsefer r
Retransmission
Control
Control
Flow Control
Flow Control
Increasing timescale (functions performed less often) and complexity
Namespace
Management
Security
Management

Designing RINA networks (IV)
Network Management System
• Analyze the role of the Network Management System (“monitor
and repair”), a number of configurations are possible – from
fairly centralized to autonomic.
• Understand the different operating ranges of the network,
decide monitors/triggers to sense them and design strategies to
automatically transition between different policy sets associated
to the operating ranges.
Mgr
MA MA MA
MA
MA
MA
MA
MA

Designing RINA networks (V)
Interoperating with legacy technology
• If it has to interoperate with existing technology or support
legacy apps, understand the required tooling for interoperation:
shim DIFs, gateways, legacy application support.
Public Internet
Gateway
Legacy
Faux Sockets
Gateway app
faux
Shim IPC
Process
Shim IPC
Process
Shim IPC
Process
VIFIB Node Gateway
TCP or UDP
(IPv6)
Ethernet
VIFIB Node VIFIB Node
Ethernet (VLAN)
Shim IPC
Process
Shim IPC
Process Public Internet (IPv4)
Ethernet . . . Ethernet Ethernet . . . Ethernet
IPC
Process
IPC
Process
IPC
Process
IPC
Process
SlapOS base
DIF
Shim DIF over UDP
Shim DIF
over 802.1Q
Shim DIFs

Outline
• Examples of RINA Networks
– Network Service Provider (Fixed Network)
– Network Service Provider (Mobile Network)
– Data Center Network
• Deploying RINA in the current Internet
– Shim DIFs: RINA over X
– Under IP
– Legacy application support: faux sockets API

Service Provider Networks
Example scenario (Fixed networks)
P2P DIF
Application-specific DIF
P2P DIF
Provider 1 Backbone DIF
P2P DIF P2P DIF
Border
Home /Enterprise DIF
P2P DIF P2P DIF
Host Router
Customer network
(Simplification, can have more
internal structure probably)
Access DIF
P2P DIF P2P DIF
Border
Router
Interior
Router
Border
Router
Interior
Router
Border
Router
Interior
Router
Border
Router
P2P DIF
Border
Router
Provider 1 Regional DIF
P2P DIF
Border
Router
Provider 1 Metropolitan DIF
Provider 2
Metro DIF
P2P DIF P2P DIF
Border
Router
Interior
Router
Public Internet DIF
DAP
Provider 1 network Provider 2 network
136

Provider 1 Backbone DIF
P2P DIF P2P DIF
Metropolitan DIF SubDIF 8
Regional
DIF
Backbone DIF
P2P DIF
P2P DIF
SubDIF 1
Subnetwork 2
SubDIF 3
P2P DIF P2P DIF
Access DIF SubDIF 4
Access DIF
Interior
Router
Provider 1 Network
Border
Router
Interior
Router
Border
Router
Interior
Router
Border
Router
Interior
Router
Border
Router
P2P DIF
Border
Router
Provider 1 Regional DIF
P2P DIF P2P DIF
Border
Router
Provider 1 Metropolitan DIF
P2P DIF
Interior
Router
SubDIF 1
SubDIF 2 SubDIF 3
SubDIF 4 SubDIF 5
SubDIF 4
SubDIF 7
Access DIF
137

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:
E-mall
DIF
E-mall
DIF
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
BR IR BR
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

Regional DIF
• 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
BR BRBR
SubDIF 3
BR
SubDIF 1
SubDIF 2
Backbone DIF
Metro
DIF
Metro
DIF
Metro
DIF
Metro
DIF
Metro
DIF
Metro
DIF

Backbone DIF
• 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.
Regional
BR
BR
BR
BR
BR
BR
IR
IR
IR
IR
IR
IR
IR
Regional
DIF
Regional
DIF
Regional
DIF
Regional
DIF
Regional
DIF
DIF

Outline
– Under IP

Border
Router
Example scenario (Mobile networks)
Application-specific DIF
P2P DIF
Metro DIF
Backbone DIF
Provider Fixed Network
(necklace with e-mall at the top)
P2P DIF
Border
Router
P2P DIF
Border
Router
District DIF
Metro DIF
Interior
Router
(Base Station)
Host
(Mobile)
Multi-access DIF
(radio) P2P DIF
Regional DIF
Public Internet DIF
DAP
Border
Router
Regional DIF
P2P DIF
Customer Terminal Mobile Infrastructure Network
P2P DIF
Interior
Router
Border
Router
P2P DIF
Regional
Metro
District
P2P DIF
Interior
Router
142

Radio Access DIF and District DIF
Example connectivity graphs
Multi-homed host
Metro
DIF
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
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
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
143

Metro DIF and Regional DIF
Example connectivity graphs
E-mall
DIF
Regional
DIF
BR
Internet DIF REGIONAL DIF
Metro
DIF
Public
METRO DIF
H = IPCP at Host
BR
H H H H H
H H H H H
Reg.
DIF
Multi-homed host
H H H H
H
BR
H
District
DIF
District
DIF
District
DIF
BR
H
Metro
DIF
BR
H H H HH HH HH H H HH HH H H HH H H HH
BR
H H H HH H H H HH HH H H HH H H H
BR
Metro DIF
(fixed)
H = IPCP at Host
144

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)

Outline
– Under IP

Datacentre(DC) Network
Example scenario: NSP owns DC and Network to customers
DAP DAP
P2P DIF P2P DIF
Border Router
(Server)
P2P DIF
VM
P2P DIF
Interior
Router
P2P DIF P2P DIF
(Top of Rack)
Interior
Router
(Aggregation)
Border Router
(DataCentre)
DataCentre (DC) Fabric DIF
P2P DIF
Border Router
(Network Service
Provider)
Provider 1 Metro DIF
Provider 1 regional DIF
Access DIF
Border Router
(Network Service
Provider)
Customer Site DIF
P2P DIF P2P DIF
Border Router
(Customer
Site)
Customer DIF (VPN)
. . .
Interior
Router
Host
DC Network Provider Network Customer Network
• Service provider owns both the network and the DC: offers “private
cluster with QoS” to customers
• Set of Private Virtual Machines available to the customer only, via the “Customer DIF”, a
VPN.
• Customer can expand the Customer DIF to his site, and include its own hosts/VMs.
• Customer can customize policies in his DIF (routing, addressing, security, etc.)
147

Example scenario: Customer access DC via the Internet
DAP DAP
Public Internet DIF
… …
P2P DIF
BR (NSP 1)
Border Router
(Server)
P2P DIF
VM
P2P DIF
Interior
Router
P2P DIF P2P DIF
(Top of Rack)
Interior
Router
(Aggregation)
Border Router
(DataCentre)
P2P DIF
BR (NSP 1)
Access DIF
BR (NSP 2)
Customer Site DIF
P2P DIF P2P DIF
Border Router
(Customer
Site)
Customer DIF (VPN)
Interior
Router
Host
BR (NSP2)
DC Network Provider 1 Network Provider 2 Network
Customer Network
• Service provider owns both the network and the DC: offers “private cluster
over the public Internet” to customers
• Set of Private Virtual Machines available to the customer only, via the “Customer DIF”, a VPN.
• Customer can expand the Customer DIF to his site, and include its own hosts/VMs.
• Customer can customize policies in his DIF (routing, addressing, security, etc.)
148

Example scenario: User accesses app via the Internet
P2P DIF P2P DIF
… …
Border Router
(Server)
P2P DIF
DAP
VM
P2P DIF
Interior
Router
(Top of Rack)
Interior
Router
(Aggregation)
Border Router
(DataCentre)
P2P DIF
BR (NSP 1)
Access DIF
BR (NSP 2)
Border Router
(Customer
Site)
Home DIF
(Wiireless)
Host
DC Network Provider 1 Network Home Network
• App deployed in the DC, made available through the public Internet
• Home user access the application from his home network (connected
to the Internet)
DAP
P2P DIF
Public Internet DIF
BR (NSP 1)
BR (NSP2)
Provider 2 Network
149

DC Model
Example
P2P DIF
P2P DIF
Border Router
(Server)
DAP
VM
Customer A DIF
Interior
Router
P2P DIF P2P DIF
(Top of Rack)
Interior
Router
(Aggregation)
Public
Internet DIF
NSP DIF
P2P DIF
Border Router
(DC)
• VM contains applications
• Server hosts VMs (internal DIFs to communicate to them). Servers are
Border Routers for VMs
• Top of Rack (ToR) routers interconnect VMs of the same Rack
• Aggregation (A) routers interconnect ToRs (multi-stage Clos Fabric or
leaf-spine connectivity, see next slide)
• Border Routers (BRs) interconnect DC to the external world
150

DC Fabric DIF
Example connectivity graph and policies
• Connects servers between them and to DC Border Routers
• Fat tree connectivity graph for full bisection BW and no oversubscription
• Resource allocation policies should effectively multiplex flows with different
capacity and latency requirements
• Connectivity graph is fixed: Hierarchical addressing to facilitate forwarding
• DIF is completely hidden within DC: relaxed security policies
BR BR BR BR
A A
ToR
A A
ToR
A A
ToR
S S S S
ToR
S S S S
ToR
S S S S
S S S S
S S S S
ToR
S S S S
A A
ToR
S S S S
ToR
S S S S
Customer
A DIF
Customer
A DIF
Customer
B DIF
Public Int.
DIF
Public Int.
DIF
Customer
C DIF
151

Customer DIF
Example connectivity graph and policies
• Connects VMs running customer applications between them and to other
infrastructure (for example at one or more customer site(s)).
• All policies are tailored to the particular needs of the customer (addressing,
routing, resource allocation, authentication, access control, SDU Protection, etc.)
To customer A site 1 To customer A site 2
S S
VM VM VM VM VM
VM VM
S
VM VM
BR BR
DC Fabric
DIF
Provider 1
Metro DIF
152

Outline
– Under IP

No need for migration: adoption!
• RINA can be deployed over, under and next to the
current TCP/IP based Internet
– If the Internet is good enough for you: keep using it!
– Otherwise… there can be an alternative!
Applications
DIF
…
DIF
TCP or UDP
Applications
DIF
…
DIF
Applications
TCP or UDP
DIF
…
DIF
End goal
Applications
DIF
…
DIF
Today
Applications
TCP or UDP
IP
Ethernet
Physical Media
IP
Ethernet
Physical Media
Ethernet
Physical Media
IP
Physical Media
Physical Media

Outline
– Under IP

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.

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)
• Only one application (a normal IPC Process) can be registered
at each shim IPC Process
– No way to differentiate between multiple flows from the same pair of shim
IPC Processes

Use of the Ethernet frame
• Source MAC @ (6 bytes)
– Source shim IPC Process address
• Destination MAC @ (6 bytes)
– Destination shim IPC Process address
• IEEE 802.1Q tag (2 bytes)
– DIF name
• Ethertype (2 bytes)
– 0x0D1F
158
Shim DIF over Ethernet
Ethernet II PCI Application data
• Minimum length: 42 bytes (46 if 802.1Q
not present)
• Maximum length: 1500 bytes

Environment

Shim DIF over TCP/UDP
Flow
2 5
UDP Port:2524 UDP Port:2524
• 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
Shim IPCP
X.1
Shim IPCP
Y.1
IP: 4.3.2.1 IP: 5.3.5.8

Outline
– Under IP

RINA under IP
• RINA-based ISP, internal layers are RINA, can transport IP
(can be treated as just another app) and/or other DIFs.
Shim DIF Shim DIF
Backbone DIF
• 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
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

Outline
– Under IP

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

Francesco Salvestrini
IMPLEMENTING RINA: THE IRATI
APPROACH

Outline
• IRATI
– Project’s outline
– Software architecture
• Kernel space
• User space
• PRISTINE
– Software Development Kit
• Wrap-up

IRATI - Outline
• FP7 Project grant #317814 (www.irati.eu)
• From Jan 2013 to Dec 2014 (2 years)
• 5 partners
– [Research] Fundació Privada i2CAT (Spain)
– [Research] iMinds VZW(Belgium)
– [SME] Nextworks s.r.l. (Italy)
– [Industry] Interoute (UK/Italy)
– [Academia] Boston University (US)
167

Implementing RINA, previous prototypes …
• Pre-2013, few RINA prototypes have been
implemented:
– ProtoRINA (https://github.com/ProtoRINA/users/wiki)
– Alba (closed source)
• (Design - and implementation - vary depending on
the goals to accomplish)
• All These prototypes:
1. Focus on the validation of the architecture
2. Are written in Java
3. Reside in user-space

… previous RINA prototypes …
• Focus on concepts, not performance
• Constrained to the limitations imposed by the OS:
– inherit limitations of both the TCP/IP stack and the (POSIX) sockets API
CACEP
Retransmission
Application Specific Tasks
Other Mgt. Tasks
IPC Mgt. Tasks
Multiplexing
User
Legacy
Net. stack
Kernel
NICs
DIF
System (Host)
IPC
Process
Shim IPC
Process
Mgmt
Agemt
System
(Router)
Shim IPC
Process
Shim IPC
Process
IPC
Process
Mgmt
Agemt
System
(Host)
IPC
Process
Shim IPC
Process
Mgmt
Agemt
Appl.
Process
Shim DIF
over TCP/UDP
Shim DIF
over Ethernet
Appl.
Process
IPC API
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Retransmission
Control
Flow Control
RIB
Daemon
RIB
CDAP
Parser/Generator
Enrollment
Flow Allocation
Resource Allocation
Routing
Authentication
State Vector
State Vector
State Vector
Retransmission
Control
Control
Flow Control
Flow Control
IPC
Resource
Mgt.
Inter DIF
Directory
SDU
Protection
Namespace
Management
Security
Management

… what was needed next?
IPC
Process
System (Host)
IPC API
CACEP
Retransmission
• Start thinking about performance
• Allow RINA to lay on all the devices OSes support nowadays
• Move to a more mature prototype
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Retransmission
Control
Flow Control
RIB
Daemon
RIB
CDAP
Parser/Generator
Enrollment
Flow Allocation
Resource Allocation
Routing
Authentication
State Vector
SStatatete V Veecctotorr
Retransmission
Control
Control
Flow Control
Flow Control
Namespace
Management
Security
Management
Increasing timescale (functions performed less often)

Project’ goals
• IRATI’s SW-related goals:
1. “RINA open source prototype over Ethernet for a UNIX-like
OS”
2. “RINA open source prototype for Hypervisors”
• (UNIX-like OS = OS/Linux)
• “… besides being the main experimentation
vehicle of the project, the prototype will
provide a solid baseline for further RINA work
after its end …”
– Desiderata (overall):
• Extendibility, portability, performances & usability

Project’s timeline
• IRATI SW release timeline:
• Release 3 versions of the prototype in 2 years
• 1st version: basic functionalities
• Unreliable flows (comparable to a UDP/IP)
• Legacy ETH support
• 2nd version: complete functionalities
• Reliable flows (comparable to a TCP/IP)
• Routing functionalities
• Hypervisors support
• 3rd version: enhancements & hardening
• RINA over IP
• However, all these(major) goals have been obtained
with incremental enhancements of the same
codebase

Where did we start …
• To reach our goals:
– we had to implement portions of the IPC Process functionalities in kernel-space
…
DIF
System (Host)
IPC
Process
Shim IPC
Process
CACEP
Retransmission
• Which ones? How do we split them? How do they communicate?
How can we maximise performances …
• … a good amount of possibilities …
Mgmt
Agemt
System
(Router)
Shim IPC
Process
Shim IPC
Process
IPC
Process
Mgmt
Agemt
System
(Host)
IPC
Process
Shim IPC
Process
Mgmt
Agemt
Appl.
Process
Shim DIF
over TCP/UDP
Shim DIF
over Ethernet
Appl.
Process
IPC API
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Retransmission
Control
Flow Control
RIB
Daemon
RIB
CDAP
Parser/Generator
Routing
Flow Allocation
Resource
Allocation
Enrollment
Authentication
State
Vector
State
Vector
State
Vector
Retransmission
Control
Control
Flow Control
Flow Control
Namespace
Management
Security
Management

Example #1: Split Between HW & SW (ideal world)
• RINA RMT/DTP performed in hardware
– Software still does DTCP and remainder of IPC Process fn’s
– Transiting PDUs need not be processed by software
AApppp IPC
New/Extended OS API Calls
DTCP
DTP Flow State
174
Process
RMT
Network Interface 1
Forwarding
Table
Application Space
OS Kernel
Network Interface 2
Hardware/Firmware

Example #2: minimum functionalities in the kernel
• Make RINA a “native” networking API
– New/Extended OS system calls provide full RINA capability
– Move (at least) DTP/DTCP into the OS kernel for speed
AApppp IPC
New/Extended OS API Calls
DTP/DTCP Flow State
175
Process
RMT
Network Device 1
Forwarding
Table
Application Space
OS Kernel
Network Device 2
“Network Device”
Might be a Shim DIF
or a RINA DIF

What goes where?
• We placed SW components in different “paths”, depending on their timing
requirements…
– … looking for our “optimum” (extendibility, performances, effort …):
• Data transfer → stringent timings → “fast-path” → kernel-space
• Layer Management → loose timings → “slow-path” → user-space
System (Host)
IPC
Process
Shim IPC
Process
Retransmission
Kernel User
DIF
CACEP
• The data-transfer parts were going to reside in-kernel …
Mgmt
Agemt
System
(Router)
Shim IPC
Process
Shim IPC
Process
IPC
Process
Mgmt
Agemt
System
(Host)
IPC
Process
Shim IPC
Process
Mgmt
Agemt
Appl.
Process
Shim DIF
over TCP/UDP
Shim DIF
over Ethernet
Appl.
Process
IPC API
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Retransmission
Control
Flow Control
RIB
Daemon
RIB
CDAP
Parser/Generator
Routing
Flow Allocation
Resource
Allocation
Enrollment
Authentication
State
Vector
State
Vector
State
Vector
Retransmission
Control
Control
Flow Control
Flow Control
Namespace
Management
Security
Management
User
Kernel

How many OS processes ?
• What about “splitting the layer management”
functionalities ?
– That’s another split (in user-space, this time)
• We decided to have different OS processes for
each daemon in user-space
• That approach targets at:
– A more “reliable” solution
IPC Process
Daemon
• IPC Manager and IPC Processes can have problems
without interfering each-other (too much)
– A tight work with the OS:
• Let the OS do what it is for: manage the resources
among its processes
– A “cleaner” implementation since the beginning
• Functionalities partitioned into “separate
containers”:
– Avoids an intertwined implementation
IPC Process
Daemon
IPC Process
Daemon
N
User
Kernel
IPC Manager
Daemon
1
Kernel

Communications among them
• OS Processes request services to the kernel with
syscalls
– User originated (user → kernel)
– “Unicast”
• Modern *NIX systems extend the user/kernel
communication mechanisms
– Netlink, uevent, devfs, procfs, sysfs etc.
• We wanted a “bus-like” mechanism: 1:1/N:1,
user/kernel & user/user
– User OR kernel originated
– Multicast/broadcast
• We adopted syscalls + Netlink
– Syscalls (fast-path):
• Bootstrapping the IPCP and then SDUs R/W (fast-path)
– Netlink (mostly slow-path):
• Management, configuration, notifications …
Application
IPC Manager
Daemon
1
Application
Application
Application
IPC Process
Daemon
IPC Process
Daemon
Application
IPC Process
Daemon
N
User
Kernel
1
Kernel

Avoid (major) wreckages … librina
• Syscalls are “wrapped” by libc [(g)libc in GNU/Linux]
– i.e. syscall(SYS_write, …) → write(…)
• All applications are linked to (g)libc
• Changes to the syscalls → changes to (g)libc
– Breaking (g)libc could break the whole host
• Sandboxed environments are necessary
– Dependencies invalidation → Time consuming compilations
– That sort of changes are really hard to get approved upstream
– etc.
• Instead of changing (g)libc …
• we introduced librina (an external library aside (g)libc), as the initial way to
overcome these problems …
– … use the code without potentially wrecking the whole OS
RINA fn’s libc librina
Application
libc
kernel
Application
kernel

librina
• librina become soon the placeholder of common code, shared
among IPC Manager, IPC Process and the applications …
• … It is now a middleware …
• Features:
– Completely abstracts the interactions with the kernel (syscalls & Netlink)
– It provides a framework to build software components on top, e.g.:
• Patterns: e.g. singletons, observers, factories, reactors
• Concurrency: e.g. threads, mutexes, semaphores, condition variables
• High level “objects” in its core
– FlowSpecification, QoSCube, RIBObject etc.
– It has explicit memory allocation (no garbage collection)
– It’s event-based
– It’s multi-threaded
– Has a portability layer and minimum external dependencies
– Exposes common “components” through its interface
– Provides scripting language extensions (i.e. Java)

librina core (HL) SW architecture
Core components
cdap faux-sockets sdu-protection ipc-process ipc-manager application API
RINA
Manager
Event Queue
nl_send() / nl_recv()
NetlinkManager
NetlinkSession
NetlinkSession
NetlinkSessions
framework
libnl / libnl_genl
RINA Netlink RINA syscalls
Application
eventPoll()
eventWait() eventPost()
common
• Allocate / deallocate flows
• Read / write SDUs to flows
• Register/unregister to 1+ DIF(s)
• Creation
• Deletion
• Configuration
• Configure PDU Forwarding Table
• Create / delete EFCP instances
• Allocation of kernel resources to support a flow
Syscall wrappers
syscall(SYS_*)
librina
User
kernel

How to RAD, effectively ?
• OO was good for modeling the architecture and represent its
entities
• We embraced C++ as the “core” language for the user-space
parts (librina as well as the other):
– Careful usage produces binaries comparable to C
– The STL reduces the dependencies
• in the plain C vs plain C++ case
– Producing C bindings (on top) is possible
– Speeds up:
• The overall modeling
• The development of the common parts
– A “simple use” allows to move back to C with low costs

Bindings to other languages
• We adopted SWIG (www.swig.org) in order to (easily) obtain the
SWIG
example_wrap.c
example.i
GCC example.py
libexample.so Python
example.h
int fact(int n);
example.c
#include "example.h"
int fact(int n) { … }
/* File: example.i */
%module example
%{
#include "example.h"
%}
int fact(int n);
Low level
wrapper
High level
wrapper
Native interface
bindings to other languages
• SWIG generates “automatically” (…) all the code needed to connect
C/C++ programs to scripting languages
– Such as Python, Java and many others …
• librina objects have been mapped to target lang. objects …

High level software architecture (1st take)
Core
Language X
imports
SWIG HL wrappers
(Language X)
SWIG LL wrappers
(C++, for language X)
API (C)
ipcmd
API (C++)
Retransmission
Security
Management
Mgmt
Agent
IPC
Proces
librina
(C++)
libnl / libnl-gen
Kernel
Third parties
SW Packages
(Applications)
rinad
(C++)
Netlink & syscalls
ipcpd
Language X “NI”
Core (C++)
IPC API
Layer Management
Data Transfer Data Transfer
Control
Flow Allocation
RIB
Daemn.
SDU Delimiting
SDU Protection
Data Transfer
Routing
Retransmission
Relaying and
Multiplexing
CDAP
Control
Flow Control
RIB
Parser/Generator
CACEP
Resource
Allocation
Enrollment
Authentication
State Vector
State Vector
State Vector
Data Transfer
Data Transfer
Retransmission
Control
Control
Flow Control
Flow Control
Namespace
Management
System (Host)
Shim
IPC
Process

Outline
• IRATI
• Kernel space
• User space
• PRISTINE
• Wrap-up

The Linux object model
• Linux has its “generic” object abstraction: kobject, kref and kset
Garbage collection & SysFS integration
struct kref { atomic_t refcount; }
struct kobject {
Naming & sysfs
const char * name; struct kset {
struct list_head entry; struct list_head list;
struct kobject * parent; spinlock_t klist_lock;
struct kset * kset; struct kobject kobj;
struct kobj_type * ktype; const struct kset set_uevent_ops * uevent_ops;
struct sysfs_dirent * sd; };
struct kref kref;
unsigned int state_initialized:1;
unsigned int state_in_sysfs:1;
unsigned int state_add_uevent_sent:1;
unsigned int state_remove_uevent_sent:1;
unsigned int uevent_suppress:1;
};
• Generic enough to be applied “everywhere”
– E.g. FS, HW Subsystems, Device drivers
Objects (dynamic) [re-]parenting
(loosely typed)
Objects grouping
References counting (explicit)
SysFS integration

kobjects, ksets and krefs in IRATI
• They are the way to go for embracing OOD/OOP kernel-wide
• In our case, their “heavy” usage could overbloat the code with:
– Ancillary functions & data structures
– (unnecessary) Resources usage
• We don’t need/want all these functionalities (everywhere):
– Reduced (finite) number of classes
• We don’t have the needs of a “generic kernel”
– Reduced concurrency (can be missing, depending on the object)
– Object parenting is “fixed”(obj x is always bound to obj y)
• E.g. DTP/DTCP are bound to EFCP …
– Not all our objects have to be published into sysfs
– We have different lookups requirements
• No needs to “look-up by name” every object
– Inter-objects bindings shouldn’t loose the object’ type
– …

Decision: a leaner OOP/OOD approach
• We adopted a (slightly) different OOD/OOP approach
• (almost) Each “entity” in the stack is an “object”
• All our “objects” provide a basic common interface & behavior
• They have no implicit embedded locking semantics
struct object_t { … };
struct obj_ops_t {
result_x_t (* method_1)(object_t * o, …);
…
result_y_t (* method_n)(object_t * o, …);
};
int obj_init(object_t * o, …);
void obj_fini(object_t * o);
object_t * obj_create(…);
object_t * obj_create_ni(…);
int obj_destroy(object_t * o);
int obj_<method_1>(object_t * o, …);
...
int obj_<method_n>(object_t * o, …);
API opaque
vtable (if needed)
Interruptable ctxt
Non-interruptable ctxt
Static
Dynamic
vtable proxy (if needed)

OOD/OOP & the framework
• This approach:
– Reduces the stack (overall) bloating
• no krefs, spinlocks, sysfs etc. where unnecessary
• Only objects requiring sysfs, debugfs and/or uevents embed a kobject
– (or it is comparable)
• E.g. the same bloating related to _init, _fini, _create and _destroy
– Speeds-up the development
– Helps debugging
• (re-)Parenting is constrained to specific objects
• No loose-typing → type-checking is maintained (no casts)
– Decouples (mildly) from the underlying kernel
• With these assumptions we built our framework
– Basic components: robj, rmem, rqueue, rfifo, rref, rtimer, rwq, rmap,
rbmp
– OOP facilities/Patterns: Factories, singletons, facades, observers,
flyweights, publisher/subscribers, smartpointers, etc.
– Ownership-passing + smart-pointing memory model

High level software architecture (2nd take)
API (C)
API (C++)
Core (C++)
Normal IPC P.
ipcpd
SWIG HL wrappers
(Language X)
SWIG LL wrappers
(C++, for language X)
Investigating RINA as an Alternative to TCP/IP
190
Personality mux/demux
KIPCM
KIPCM
core
IPCP Factories
KFA
PFT RMT EFCP
Framework
RNL
libnl / libnl-gen
Third parties
SW Packages
rinad
syscalls Netlink
shim-eth-vlan
RINA-ARP
shim-dummy
User
space
Kernel
space
rinad
librina
kernel
ipcmd
Framework
IPC API
Layer Management
Data Transfer Data Transfer
Control
Flow Allocation
RIB
Daemn.
SDU Delimiting
SDU Protection
Data Transfer
Routing
Retransmission
Relaying and
Multiplexing
CDAP
Control
Flow Control
RIB
Parser/Generator
CACEP
Resource
Allocation
Enrollment
Authentication
Retransmission
Management
State Vector
State Vector
State Vector
Data Transfer
Data Transfer
Retransmission
Control
Control
Flow Control
Flow Control
Security
Namespace
Management

API to user-space: KIPCM + RNL
• Kernel interface = syscalls + Netlink messages
• KIPCM:
– Manages the syscalls
• Syscalls: a small-numbered, well defined set of calls (#8) :
– IPCs: ipc_create and ipc_destroy
– Flows: allocate_port and deallocate_port
– SDUs: sdu_read, sdu_write, mgmt_sdu_read and mgmt_sdu_write
• RNL:
– Manages the Netlink part
• Abstracts message’s reception, sending, parsing & crafting
• Netlink: #36 message types (with dynamic attributes):
– assign_to_dif_req, assign_to_dif_resp, dif_reg_notif, dif_unreg_notif…
• Partitioning:
– Syscalls → KIPCM → “Fast-path” (read and write SDUs)
– Netlink → RNL → “Slow-path” (mostly conf and mgmt)

KIPCM & KFA
User space
Normal
IPCP i/f
EFCP
RMT
Shim
IPCP
OUT IN
KIPCM
KFA
PDU-FWD-T
syscalls
Netlink
• The KFA
– Counterpart of the FA in user-space
– Manages ports and flows
– Ports
• Flow handler and ID
• Port ID Manager
– Flows
• maps: port-id → ipc-process-instance
• The KIPCM:
– Counterpart of the IPC Manager in user-space
– Manages the lifecycle the IPC Processes and KFA
– Abstracts IPC Process instances
• Same API for all the IPC Processes regardless the
type
• maps: ipc-process-id → ipc-process-instance
• Recursion in kernel-space considered harmful
• They are the point where “recursion” is transformed into
“iteration”

From recursion to iteration (few details)
Normal IPC Process - instance
PDU-FWD-T
EFCP Container - instance
Core O
PDU-FWD-T
KIPCM / KFA
EFCP Instance
EFCP Container - instance
RMT - instance
I
Shim IPC Process
instance
EFCP Instance
RMT - instance
Core
I
O
Shim IPC Process
instance
User space
User space
Queue
Queue
Queue
Queue
Queue
Queue
DTP DTCP
DT
DTP DTCP
DT
KIPCM / KFA

The RINA Netlink Layer (RNL)
• Integrates Netlink in the SW framework
– Hides all the configuration, generation and destruction of Netlink sockets and
messages from the user
– Defines a Generic Netlink family (NETLINK_RINA) and its messages
• Upon initialization, the RNL user registers a set of
handlers for the messages it is interested in
– RNL dispatches the received messages to the
registered handlers

About IPC Processes…
• The architecture describes
– the (Normal) IPC Processes
– The Shim IPC Processes
• W.r.t. “DIF stacking”
– Normal IPC Processes
• Have “compatible” NB/SB interfaces
• Have “full-fledged” functionalities
– Shim IPC Processes:
• Have a “compatible” NB interface
• Have to lay the minimum veneer over
legacy technologies
• They wrap the technology they are laid
over
– They don’t have a “SB” interface
(Normal) IPC
Process
(Normal) IPC
Process
Shim IPC Process
2
1
0
Hardware

IPC Process Instances
• Regardless of their type
– The “NB” interface is the same
– Each IPC Process implements its “core” code:
• Shim IPC Process:
– Each Shim IPC Processes must provide its implementation
• Normal IPC Process:
– The stack provides an implementation for all of them
• Prototype related:
– 1 (Normal) IPC Process implementation
• Provides EFCP, RMT, PDU-FWT …
• To be instantiated on-the-go
– N (Shim) IPC Processes implementations
• To be instantiated depending on the HW

IPC Process Instances API
• The IPC Process “object”
• The (shims and normal) IPC Process API is the
same
– Each type decides which operations will support
• Some are specific for normal or shim, others are
common to both
• .connection_create = normal_ connection_create
• . connection_update = normal _ connection_update
• . connection_destroy = normal _ connection_destroy
• .connection_create_arrived = normal _connection_arrived
• .pft_add = normal_pft_add
• . pft_remove = normal_pft_remove
• . pft_dump = normal_pft_dump
• .application_register = x_application_register
• .application_unregister = x_application_unregister
• .assign_to_dif = x_assign_to_dif
• .sdu_write = x_sdu_write
• .flow_allocate_request = shim_allocate_request
• .flow_allocate_response = shim_allocate_response
• .flow_deallocate = shim_deallocate
instance_ops
• instance_data
• instance_ops

The IPC Process Factories …
• They are used by IPC Processes to publish/un-publish their
availability into the system
– Publish:
• x = kipcm_ipcp_factory_register(…, char * name, …)
– Unpublish:
• kipcm_ipcp_factory_unregister(x)
– Availability:
• name is made visible through SYSFS to user-space
• The factory name is the way KIPCM can look for a specific
IPC Process type
– User space requests for an IPC Process
– Request goes through KIPCM
– KIPCM
• Fetches the implementation
• Asks for an instance
• Binds the instance to the “peering” SW components

… the IPC Process Factories
• Upon registration
– A factory publishes its hooks
• Upon user-request (ipc_create)
.init → x_init
.fini → x_fini
.create → x_create
.destroy → x_destroy
.configure → x_configure
– The KIPCM creates a particular IPC Process instance
1. Looks for the correct factory (by name)
2. Calls the .create “method”
3. The factory returns a “compliant” IPC Process object
4. Binds that object into its data model
• Upon un-registration
– The factory triggers the “destruction” of all the IPC Processes it
“owns”
• Normal and Shim IPC Processes are implemented as kernel
modules
• They can be plugged & unplugged dynamically

port_id app2
RMT 1
SHIM
IPCP 2
IPCP 1
EFCP 1j
RMT 2
EFCP 2i
APP
port_id 21
Pid 10
IPCP 0
sys_sdu_write(sdu, app2)
User space
KIPCM
KFA
Kernel space
kipcm_sdu_write(sdu, app2)
normal_write(sdu, app2)
kfa_flow_sdu_write(sdu, app2)
efcp_container_write(sdu, 2i)
efcp_write(sdu)
DTP
dtp_write(sdu)
rmt_send(pdu)
kfa_flow_sdu_write(sdu*, 21)
efcp_container_write(sdu*, 1j)
EFCPC 2
EFCPC 1
efcp_write(sdu*)
kfa_flow_sdu_write(sdu**, 10)
rmt_send(pdu*)
DTP
dtp_write(sdu*)
normal_write(sdu*, 21)
shim_write(sdu**, 21)
Write operation

port_id app2
EFCP 2i
EFCP 1j
RMT 1
SHIM
IPCP 1
RMT 2
IPCP 2
APP
port_id 21
port_id 10
IPCP 0
sys_sdu_read(app2)
User space
KIPCM
KFA
Kernel space
kipcm_sdu_read(app2)
kfa_flow_sdu_read(app2)
kfa_sdu_post(sdu, app2)
efcp_receive(pdu)
efcp_container_receive(pdu, 2i)
DTP
dtp_receive(pdu)
rmt_receive(sdu*, 21)
dtp_receive(pdu*)
kfa_sdu_post(sdu*, 21)
efcp_container_receive(pdu*, 1j)
EFCPC 2
EFCPC 1
rmt_receive(sdu**, 10)
DTP
kfa_sdu_post(sdu**, 10)
efcp_receive(pdu*)
Read operation

Shim IPC Processes
• There are currently 4 shims implemented:
– shim-dummy:
• Confined into a single host (“loopback”)
• Used for debugging & testing the stack
– shim-eth-vlan:
• Runs over 802.1Q
• Uses our version of ARP implementation
• Offers 1 unreliable QoS cube
• VLAN-id = DIF name
– shim-tcp-udp:
• Uses TCP/UDP (kernel level only) stack and allows RINA to run
“over” TCP/UDP
• Offers 2 QoS cubes:
– Reliable: mapped over a TCP socket (each flow, a different socket)
– Unreliable: mapped over UDP socket (1 socket for all the flows)

Shim IPC Processes (cont.)
• shim-hv:
– Allows the stack to run in a virtualised environment
• QEMU/KVM and Xen
– Works only with “shared memory” buffers
• VMPI, VQs
– Offers 1 QoS cube
– This shim is enough to allow RINA to take advantages of HV
environments
• Get rid of software bridges and TCP/IP stack !

Shim-eth-vlan
IPC
Process
Daemon
IRATI - Investigating RINA as an Alternative to TCP/IP
User-space
Kernel
KIPCM / KFA
Shim IPC Process over 802.1Q
Devices layer
rinarp_add rinarp_remove
RINARP
rinarp_resolve
dev_queue_xmit
RINA IPC API
IPC
Manager
Daemon
shim_eth_rcv
shim_eth_create shim_eth_destroy

RINARP
shim-eth-vlan
RINARP
ARP826
Core
Maps
Tables
RX ARM
Devices
Layer
API
TX

Shim-tcp-udp
send/send_to
IPC
Process
Daemon
RINA IPC API
User-space
Kernel
KIPCM / KFA
Shim IPC Process over TCP/UDP
Networking stack – sockets
IPC
Manager
Daemon
shim_tcp_rcv
shim_tcp_create shim_tcp_destroy

Shim-hv
shim_hv_create shim_hv_destroy
vmpi_write
IPC
Process
Daemon
RINA IPC API
User-space
Kernel
KIPCM / KFA
Shim IPC Process for Hypervisors
VMPI (over Xen or KVM)
IPC
Manager
Daemon
vmpi_read_callback

shim-HV: Get rid of vNICs

Outline
• IRATI
• Kernel space
• User space
• PRISTINE
• Wrap-up

Details on the user space framework
210
Application A
Application A
Normal IPC Process
(Layer Management)
Application logic
User space
Kernel
Netlink
sockets
IPC Process Daemon
(Layer Management)
RIB & RIB
Daemon
librina
Resource
allocation
Flow
allocation
Enrollment
PDU
Forwarding
Table
Generation
System calls Netlink
sockets
Sysfs
IPC Manager
Daemon
RIB & RIB
Daemon
librina
Management agent
DIF allocator
Main logic
System calls
Netlink
sockets
Sysfs
Application A
librina
System
calls
Netlink
sockets
• IPC Manager Daemon
– Manages the IPC Processes lifecycle
– Broker between applications and IPC Processes
– Local management agent
– DIF Allocator client (to search for applications not available through local DIFs)
• IPC Process Daemon
– Layer Management components of the IPC Process (RIB Daemon, RIB, CDAP parsers/generators, CACEP, Enrollment,
Flow Allocation, Resource Allocation, PDU Forwarding Table Generation, Security Management)

Librina software architecture
211
API (C++)
Core (C++)
Event
Producer
libnl/libnl-gen
Kernel
Perform action
Netlink Manager
Netlink Message
Parsers /
Formatters
Message
Mescslaasgsee s
classes
Message
classes
Syscall wrappers
Message
reader
Thread
Message
Mescslaasgsee s
classes
Proxy
classes
Message
Mescslaasgsee s
classes
Model
classes
Message
Mescslaasgsee s
classes
Event
classes
Concurrency
classes
libpthread
Logging
framework
Events queue
User space
Get event

The IPC * Daemons is user-space
• IPC Manager Daemon
– Manages the IPC Processes lifecycle
– Broker between applications and IPC Processes
– Local management agent
– DIF Allocator client (to search for applications not available through local DIFs)
• IPC Process Daemon
– Layer Management components of the IPC Process (RIB Daemon, RIB, CDAP
parsers/generators, CACEP, Enrollment, Flow Allocation, Resource Allocation,
PDU Forwarding Table Generation, Security Management)
212

IPC Manager Daemon (C++)
librina
Flow Manager
IPC Process
Factory
IPC Manager core classes
IPC Process
Manager
IPC
Process
Message
Mescslaasgsee s
classes Event
classes
Event
Producer
Message
Mescslaasgsee s
classes Model
classes
System calls Netlink Messages
Command
Line
Interface
Server
Thread
local TCP
Connection
Main event
loop
EventProducer.eventWait()
Application
Registration
Manager
Call IPC Process Factory, IPC
Process or Application
Manager
Call operation on IPC
Manager core classes
Application Manager
CLI Session
Message
Mescslaasgsee s
classes Console
classes
Operation result
Bootstrapper
Configuration file
Call operation on IPC
Manager core classes
Message
Mescslaasgsee s
classes
Configura
tion
classes
IPC Manager Daemon
213

IPC Process Daemon
IPC Process Daemon (Java)
librina (C++)
IPC
Manager
KernelIPC
Process
Message
Mecslsaasgsee s
classes
Event
classes
Event
Producer
Message
Mecslsaasgsee s
classes
Model
classes
System calls Netlink Messages
CDAP
Message
reader
Thread
KernelIPCProcess.readMgmtSDU()
RIB Daemon
Resource
Information
Base (RIB)
RIBDaemon.cdapMessageReceived()
Main event
loop
Supporting classes
Delimiter Encoder
CDAP
parser
Layer Management function classes
Enrollment
Task
Flow
Allocator
Resource
Allocator
Forwarding
Table
Generator
Registration
Manager
Call IPCManager or
KernelIPCProcess
RIBDaemon.
sendCDAPMessage()
KernelIPCProcess.writeMgmtSDU()
214

Example workflow : IPC Process creation
• The IPC Manager reads a configuration file with instructions on the IPC
Processes it has to create at startup
– Or the system administrator can request creation through the local console
• The configuration file also instructs the IPC Manager to register the IPC
Process in one or more N-1 DIFs, and to make it member of a DIF
3. Initialize librina
4. When completed notify IPC Manager (NL)
10. Update state and forward to Kernel (NL)
215
User space
Kernel
IPC Manager Daemon
IPC Process
Daemon
5. IPC Process initialized (NL)
local TCP
Connection
CLI Session
Configuration file
OR
1. Create
IPC Process
(syscall)
2.
Fork(syscall
)
6. Register
app
request(NL)
8. Notify IPC Process registered (NL)
9. Assign to DIF request (NL)
7. Register app
response (NL)
11. Assign to
DIF request
(NL)
12. Assign to
DIF response
(NL)
13. Assign to DIF response (NL)

Example workflow : Flow allocation
• An application requests a flow to another application, without
216
specifying what DIF to use
Application A
User space
Kernel
2. Check app permissions
3. Decide what DIF to use
4. Forward request to adequate IPC Process Daemon
IPC Manager
Daemon
IPC Process
5. Allocate Flow Request (NL)
1. Allocate Flow Daemon
Request (NL)
6. Request port-id (syscall)
7. Create connection request (NL)
8. On create connection response
(NL), write CDAP message to N-1
port (syscall)
9. On getting an incoming CDAP
message response (syscall),
update connection (NL)
10. On getting update connection
response (NL) reply to IPC
Manager (NL)
11. Allocate Flow Request Result (NL)
12. Forward response to app
13. Allocate Flow
Request Result (NL)
14. Read data from the
flow (syscall) or write
data to the flow (syscall)

Testing applications: rina-echo-time
• How it works
– Client allocates 1 flow to server control AE
– Client and server negotiate test parameters (number of flows, SDUs per flow, SDU
size, SDU generation pattern, etc)
– Client allocates N flows to the server data transfer AE
– Test starts and client and/or server write and read the agreed SDUs to the flows
– Upon test completion client deallocates the N data flows
– Client and server exchange statistics measured during the test (sent/received
SDUs per second, SDU loss, flow allocation/deallocation times, etc)
– Client deallocates the control flow and reports statistics
217
DIF
rina-echo-time
(client)
Rina-echo-time
(server)
Control
AE
Data
AE
Data
AE
Control
AE
1 control flow
N data flows

Outline
• IRATI
• Kernel space
• User space
• PRISTINE
• Wrap-up

PRISTINE - Outline
• FP7 Project grant #619305 (ict-pristine.eu)
– Starts Jan 2014, ends Dec 2016 (3 years)
– 15 Partners (Research, SMEs and Industry)

PRISTINE (SW) objectives
• One of its objectives:
– “design and implementation of a SDK that will enable to exploit the
customization capabilities provided by RINA”
• It will define a set of APIs into each of the components of the IPC
Process
– This will allow to easily modify the DIFs
• It will also modify the IRATI stack to allow extension modules to
be plugged in and out of the prototype
• Policies in IRATI are hardwired ...
• ... it will finally allow to dynamically load / accept changes on its
behaviours at runtime

Pluggin’ policies, examples
IPC API
Authentication
CACEP
Retransmission
SDU Delimiting
Data Transfer
Relaying and
Multiplexing
SDU Protection
Retransmission
Control
Flow Control
RIB
Daemon
RIB
CDAP
Parser/Generator
Routing
Flow Allocation
Resource
Allocation
Enrollment
Authentication
SStatatete V Veecctotorr State Vector
DDaatata T Trarannssfefer r
Retransmission
Control
Control
Flow Control
Flow Control
Namespace
Management
Security
Management
RcvrInactivityTimer
SndrInactivityTimer
InitialSequenceNumber
TransmissionControl
MaxQ
RMTQMonitor
RMTScheduling
NewFlowRequest
AllocateRetry
NewMemberAccessControl
NewFlowAccessControl
RIBAccessControl
Checksum
Compression
Encryption
TTL
RTTExtimation
SenderACK
MonitorNMinus1Flow
NMinus1FlowDown
RoutingAlgorithm
Kernel User
• Policies have to be “plugged” in both spaces ...

RINA Plugin Infrastructure
• The RINA Plugin Infrastructure (RPI):
– plug/unplug custom policies in the IRATI stack
• Since the stack is split in two halves ...
– RPI must comply with both kernel and user spaces
characteristics ...
• ... RPI must be split in two as well:
– Kernel RPI (kRPI)
– User RPI (uRPI)
• NOTE: “plugin” = policy code + all the framework
required

Policies & policy sets
• Policies could need to cooperate/share state...
• Policy set = The set of all policies defined on a single component
of the software architecture
– A different policy set for each SW component
• Two types of policies (software-wise):
– parameters, e.g. A-timer value for DTCP, MaxQLength for RMT
queues
– behaviours, e.g. SchedulingPolicy for RMT, NewFlowAccessControl
for the Security Manager
• This way: different “behavioural” policies in the same
component can cooperate (share state) in a plugin-specific
way

kRPI - Basics
• Plugins are loadable kernel modules (LKMs)
• A plugin publishes policy sets to the stack
– They become available for later selection on running
components
• Plugin unpublishes a policy set
– It cannot be selected anymore
• W.r.t. LKM mechanics:
– Publishing expected to happen in the module .init
– Unpublishing is expected to happen in the module .exit

kRPI - Factories
• Policy sets published using factories
• A factory contains:
– The name of the policy-set
• To be used for its “selection”
– A constructor method
• To create policy set instances
– A destructor method
• to destroy policy set instances

kRPI - Policy set lifecycle
1
2
3
4

uRPI - Basics
• kRPI mechanisms mostly valid also for uRPI
– Publishing/unpublishing of factories
– Policy-set lifecycle
– Policy-set classes
• Even if the methodologies are similar ...
• ... the implementations of uRPI and kRPI frameworks
are different:
– Plugins are shared objects to be dynamically loaded by the
IPC process daemon
– Plugins are “loaded“ using the libdl library
• i.e. dlopen(), dlsym() ...

uRPI - Policy set lifecycle
1
2
3
4

Components addressing
• Address of an IPC Process component in a processing system:
• IPC Porcess ID (uint)
• Path in the IP Process component tree
• Example:
• Custom passwd policy-set for Security Manager is addressed by
• Security-manager.passwd

Changing policies
• Access the IPC Manager console:
– telnet 127.0.0.1 32766
• select-policy-set command to change the policy set instance
associated to a specific IPC Process component
• set-policy-set-param command to change parameter values
(parameter policy or policy-set-specific parameter)
• Commands report information about success or failure

... and routing ...
• Commands (e.g. select a policy or set a value)turned into
Netlink request messages
• Requests routed to user-space or kernel-space
– depending on the addressed component
• Response messages received back

Outline
• IRATI
• Kernel space
• User space
• PRISTINE
• Wrap-up

Where we are …
• After almost 2 years of continuous development …
• The codebase provides the following (major) features:
– IPC Manager daemon
– IPC Process daemon
• Transport and management layers
– Provides unreliable and reliable flows functionalities
• Has routing functionalities
– A set of shims:
• Shim DIF for Ethernet over VLAN
• Shim DIF for HV (KVM/Qemu & Xen)
• Shim DIF for TCP/UDP
– A library for building native-RINA applications
– A testing framework
• Regression (runs at build-time, installation-time …)
• A testing application: rina-echo-time

… where we are …
• The sources are partitioned into different packages
– rinad: provides the IPC Process & IPC Manager daemons
(user-space parts)
• Requires librina
– rina-tools: provides the rina-echo-time application
• Requires librina
– librina: user-space libraries
• requires the IRATI (modified Linux) kernel
– linux: the Linux sources enhanced with RINA functionalities
(kernel-space parts)
• Sources almost confined in net/rina, to allow easier upgrades

… where we are …
• The codebase also:
– Builds on major OS/Linux systems:
• Debian, Ubuntu, ArchLinux …
– Has minor porting quirks …
• Should run unchanged on other OS/Linux systems
– … and a small set of (runtime) external dependencies
• libnl, libnl-gen …
• Sources have been released:
– http://irati.github.io/stack

.. where do we go
• PRISTINE’s will be enhancing the RINA specs and
contributing to the (Open) IRATI stack
• In the following years, new improvements and
functionalities will be integrated, to allow experiment with
it:
– The RINA SDK
– Management Agent, updates to the RIB library
– …
– As well as …enhancements and bug-fixes
• We’ll be keeping the implementation in-sync with the
specs
Join us on GitHub!

Thanks!

Dimitri Staessens
EXPERIMENTING WITH RINA USING
THE OFELIA TESTBED

OUTLINE
• Introduction to the OFELIA test bed
• Introduction to the iMinds virtual wall
• Stack installation procedures
• Demo scenario / tutorial
• Brief experimental results

OFELIA TESTBED

OpenFlow in Europe: Linking
Infrastructure and Applications
M. Sune et al., “Design and implementation of the OFELIA FP7 facility: The European
OpenFlow testbed”, Computer Networks 61, pp 132-150 March 2014

OFELIA “Island”

Request Computational Resources (VMs)

VIRTUAL WALL

Large Test Setups
 Can be very time consuming
 Requires a lot of hardware
 No shared usage of hardware
Stream Capturer Stream Capturer Stream Capturer Stream Capturer
Vakgroep
 Creating large test setups:
Informatiete
chnologie –
Breedbandc
ommunicati
enetwerken
SmartBits 6000B Performance Analysis System R
Server Router
Fluke Tab
Shaping, Scheduling,
Caching, transcoding, ...
Video Servers
Traffic
Generator
VLAN Switch Network Router
Network Emulator
Home Router
QoS Support,
QoS feedback, ...
High End
Video Clients
Fluke Tab
Video Testbed Control Software
Video Quality Analysis
ISP
(Belnet, Belgacom,
Telenet,…)
DUT
Mirrored Port
Mirrored Port
VLAN Switch
Video Test Bed

Large emulation setups
p. 252
Not an ideal solution !

254
Virtual Wall: Topology Control

255
Virtual Wall: Topology Control

Emulab: architecture
emulab Architecture
PC PC
Programmable “Patch Panel”
p. 256
Web/DB/SNMP
Users Switch Mgmt
Internet
Control Switch/Router
Serial
168
PowerCntl

Emulab: programmable patch panel
p. 257

Physical components
(wall1)
 Server nodes (100x)
 Dual CPU, dual core
 4GB RAM
 4x 80GB harddisk
 60x 6 and 40x 4 network interfaces
 Central switch: Force 10 networks
 576x Gb/s port
 8x 10 Gb/s port
 1.6Tb/s backplane
 Displays

Summary of test facilities
• OFELIA
– Disperse islands
– Different physical
locations across
Europe
– Interconnected over
public Internet via
central Hub
– OCF (OpenFlow)
– Virtual Machines
– NEC 8800 OF switches
– OS/Linux
– IRATI VM image
• Virtual Wall
– 3 Virtual wall instances
– Single location: @
iMinds IBCN in Ghent,
Belgium
– Wall 1 and Wall2
interconnected via
1/10GbE
– Emulab
– ~300 Physical Servers
– Force10
– OS/Linux / Win / BSD
– IRATI disk image

DEMONSTRATION

Installing the IRATI stack in OS/Linux
• Build/install the kernel space components:
– kernel-package libncurses5-dev fakeroot wget bzip2
– build a debian package make-kpkg
– install using dpkg
• To install the user space parts:
– maven libnl-genl-3-dev libnl-3-dev libtool autoconf2.13
openjdk-6-jdk git libpcre3 pkg-config libpcre3-dev
libprotobuf-dev protobuf-compiler tcpdump
– libnl-3-dev libprotobuf-dev protobuf-compiler

Demo scenario
Application
Process
Application
Process
test1.
IRATI
16
test2.
IRATI
17
Host A
Host R
Normal
DIF A
Host B
test3.
IRATI
18
Normal
DIF A
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
VLAN 300 VLAN 400
ipcm
ipcm
ipcm

Preparing the hosts
• Setup VLANs
– Host A: ip link add link ethx name ethx.300 type vlan id 300
– Host b: ip link add link ethx name ethx.400 type vlan id 400
– Host r:
• ip link add link ethx name ethx.300 type vlan id 300
• ip link add link ethy name ethy.400 type vlan id 400
– Enable all the vlans (ifconfig ethx.vlan up)
• Load IPC process kernel modules
– modprobe shim-eth-vlan
– modprobe normal-ipcp

Where are we?
Host A Host B
Host R
VLAN 300 VLAN 400

ipcmanager.conf:
Specify the (shim) IPC processes
• "ipcProcessesToCreate“
– "apName" : "test-eth-vlan“
– "apInstance" : "1“
– "difName" : “300“
– "apName" : "test1.IRATI“
– "apInstance" : "1”
– "difName" : "normal.DIF"
– "difsToRegisterAt" : [“300"]
• "ipcProcessesToCreate“
– "apName" : "test-eth-vlan4“
– "difName" : “400“
– "apInstance" : "1”
– "difName" : "normal.DIF"
– "difsToRegisterAt" : [“400"]

We specified this:
Shim IPC
Process
Shim IPC
Process
VLAN 300 VLAN 400
test1.
IRATI
test3.
IRATI
Shim DIF ETH VLAN Shim DIF ETH VLAN

Configure the (shim) IPC processes
Host R
• "ipcProcessesToCreate"
– "apName" : "test-eth-vlan“
– "difName" : “300"
– "apName" : "test-eth-vlan2“
– "difName" : “400" }
– "difName" : "normal.DIF“
– "difsToRegisterAt" : [“300", “400"]

We specified this:
test2.
IRATI
Shim IPC
Process
Shim IPC
Process
Shim IPC
Process
Shim IPC
Process
VLAN 300 VLAN 400
test1.
IRATI
test3.
IRATI
Shim DIF ETH VLAN Shim DIF ETH VLAN

Configuring the DIFs
• Attach shim-eth to the correct interfaces (difConfigurations)
– "difName" : “300“ #”400”
– "difType" : "shim-eth-vlan"
– "configParameters"
• "interface-name" : "eth2“
• Configure the normal.DIF
– "difName" : "normal.DIF",
– "difType" : "normal-ipc",
– "dataTransferConstants" :
– "addressLength" : 2
– "cepIdLength" : 2
– "lengthLength" : 2
– "portIdLength" : 2
– "qosIdLength" : 2
– "sequenceNumberLength" : 4
– "maxPduSize" : 10000
– "maxPduLifetime" : 30

Set addresses for the normal IPC
processes
• "knownIPCProcessAddresses"
– "apName" : "test1.IRATI",
– "apInstance" : "1",
– "address" : 16
– "address" : 17
– "address" : 18

Start the IPC managers
• The IPC manager will start the IPC processes
– sudo ipcm –c ../etc/ipcmanager.conf
test2.
IRATI
17
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
VLAN 300 VLAN 400
ipcm
ipcm
ipcm
test1.
IRATI
16
test3.
IRATI
18

Enroll the normal IPC processes (A)
test1.
IRATI
16
test2.
IRATI
17
Host A
Host R
Normal
DIF A
Host B
test3.
IRATI
18
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
VLAN 300 VLAN 400
ipcm
ipcm
ipcm
• Connect to ipc manager: telnet localhost 32766
• listipcps 2:test1.IRATI
• enroll-to-dif 2 normal.DIF 300 test2.IRATI 1

Enroll the normal IPC processes (B)
test1.
IRATI
16
test2.
IRATI
17
Host A
Host R
Normal
DIF A
Host B
test3.
IRATI
18
Normal
DIF A
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
VLAN 300 VLAN 400
ipcm
ipcm
ipcm

Start the applications
rina-echo
time
server
test1.
IRATI
16
test2.
IRATI
17
Host A
Host R
Normal
DIF A
Host B
test3.
IRATI
18
Normal
DIF A
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
VLAN 300 VLAN 400
ipcm
ipcm
ipcm
• HostA: rina-echo-time -l –d
normal.DIF

Start the applications
rina-echo
time
server
rina-echo
time
client
test1.
IRATI
16
test2.
IRATI
17
Host A
Host R
Normal
DIF A
Host B
test3.
IRATI
18
Normal
DIF A
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
Shim IPC
Process
Shim IPC
Process
Shim DIF ETH VLAN
VLAN 300 VLAN 400
ipcm
ipcm
ipcm
• HostA: rina-echo-time -l –d normal.DIF
• Host B: rina-echo-time –c 10 –s 200 –d
normal.DIF

IRATI Prototype initial tests
Host A Host B
IPC
Process
IPC
Process
Application
Process
Application
Process
IPC
Process
IPC
Process
Shim IPC
Process
Shim IPC
Process
Normal
DIF B
Normal
DIF A
Shim DIF
277
Source: S. Vrijders et al.
“Experimental evaluation of RINA Prototype”,
IEEE Globecom, Dec 2014

Link-state routing test (IS-IS based)

Future plans
• IRINA [03/2015]
– Use case analysis of RINA as the future NREN and GEANT
architecture
– Experimental analysis using Open IRATI prototype
– Contribution of traffic generation tools to Open IRATI
• PRISTINE [06/2016]
– Research on RINA in the areas of congestion control,
distributed resource allocation, addressing and routing,
security, resiliency and network management.
– Software Development Kit for Open IRATI
– Policies developed with the SDK for Open IRATI
– Network Management System for Open IRATI
– First RINA Simulator (based on OMNeT++)

T-5: Alternatives to TCP-IP tutorial
Thanks for your attention!
http://irati.eu
http://ict-pristine.eu

RINA Tutorial @ IEEE Globecom 2014

More Related Content

What's hot

Viewers also liked

Similar to RINA Tutorial @ IEEE Globecom 2014

Recently uploaded

RINA Tutorial @ IEEE Globecom 2014