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

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

RINA Tutorial @ IEEE Globecom 2014

RINA Tutorial @ IEEE Globecom 2014

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie RINA Tutorial @ IEEE Globecom 2014

Ähnlich wie RINA Tutorial @ IEEE Globecom 2014 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (11)

RINA Tutorial @ IEEE Globecom 2014