How in the Hell
Do You Lose a Layer?!!
UIUC-CSL
John Day
Oct 2015
“There is something fascinating about science.
One gets such wholesale returns on conjecture
out of such a trifling investment of fact.”
- Mark Twain
“Life on the Mississippi”
In a network of devices why would
we route between processes?
- Toni Stoey, RRG 2009
In the Beginning, There was
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 to sell what.
– Interfaces between boxes were market boundaries
– This was what was taught in most data comm courses prior to the 1980s.
• And for some, in a fundamental sense, never left.
© John Day, 2014
Rights Reserved
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.
© John Day, 2014
Rights Reserved
But was Packet Switching
a Major Breakthrough?
• Strange as it may seem, it depends on how old you were.
• 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.
– How to do communications? Data is in buffers
• 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!
© John Day, 2014
Rights Reserved
The Cyclades Architecture
(1972)
Host or End System
Application
TS: End-to-End Reliability
Transport
Router
Network
Data Link
Physical
Cigale Subnet
• CYCLADES brings the layering from operating systems, but its different.
• Data Link – corrects media errors, not propagated to a wider scope.
• Network – relays using a connectionless datagram network, Cigale
• Transport recovers from loss due to congestion creating a reliable flow.
• Yielding a simpler, cheaper, more effective and robust data network.
• Since the Hosts won’t trust the network anyway, the network does not have to be
perfect, (and can’t be); it makes a “Best-Effort; need only be sufficiently reliable to
make end-to-end cost effective
• This represents a new model, in fact, a new paradigm completely at odds
© John Day, 2014
with the beads-on-a-string model.
Rights Reserved
A Note about Layers
• The advent of packet switching required much more complex software
than heretofore, and so the concept of layers was brought in from
operating systems.
– From Dykstra’s THE Operating System, 1968
• In operating systems, layers were seemingly a convenience, one design
choice, merely used for modularity.
• Most networking courses teach that layers are for controlling complexity,
for modularity in a stack.
– This is true, but not the primary reason for them. The primary reason is:
• In networks, Layers are a necessity,
• And are more general.
The (really) Important Thing about Layers
(From first lecture of my intro to networks course)
•
•
•
Layers are a locus of distributed shared state of 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.
– (control and data planes only feasible in beads-on-a-string models)
•
This was why CYCLADES used layers.
Increasing
Scope
Host or End System
Router
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!
© John Day, 2014
Rights Reserved
A Nasty Brawl Was Shaping Up
The Phone Companies
Against
the Computer Companies
and
Everyone against IBM
© John Day, 2014
Rights Reserved
IBM had Two Problems
Computing and Memory Prices were headed South . . . Fast.
Computing Power and Capacity were headed North . . . Fast.
By the late 70s, it was clear that IBM’s days as the dominant
computer maker were numbered
107
Log H/W
Prices
CS Educated
Check Signers
(Linear)
103
60’s
70’s
80’s
Time
90’s
2000
And if that weren’t enough.
© John Day, 2014
Rights Reserved
In Networking
IBM Found Itself at a Dead-End
You can always make a peer architecture hierarchical
But you can’t go the other way.
Mainframe
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
The Beads-on-a-String Model
• Meanwhile the Phone Companies continues with what it is familiar with.
– Emulating the phone system in computers
– Who cares about this academic connectionless stuff? We have real networks to build.
– How do you charge for usage in a best-effort service?
• Asymmetrical/Connections/Deterministic
– And a tendency toward hierarchy
• This Model Can not Represent Scope.
• Purpose of the architecture is to define who owns what boxes (protect the monopoly).
– If you hear, X is in the network and X isn’t involved with moving bits or managing moving
bits, then it is beads-on-a-string.
The Network as seen by
the new Networking Model
Host
Interface
Router
Router
Host
DCE
Packet
-mode
DTE
Terminal
Start-stop
DTE
PAD
DCE
Interface
The Network as seen by the PTTs
© 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.
— They can still offer value-added service, but can’t claim its within their monopoly
• 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”
© John Day, 2014
Rights Reserved
1972 Was an Interesting Year
• Tinker AFB joined the ‘Net exposing the multihoming problem.
Host
8
IMP
6
IMP
• The ARPANET had its coming out party 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
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.
After a Hot Debate
•
A Synthesis was proposed: INWG 96
•
There was a vote in 1976, which approved INWG 96.
•
As McKenzie 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 the final answer. The real breakthrough came two years later.
•
But the differences weren’t the most interesting thing about this work.
The Similarity Among all 3
Is Much More Interesting
• This is before IP was separated from TCP. All 3 of the Proposed
Transport Protocols carried addresses.
• This means that the Architecture that INWG was working to was:
TCP
IP
SNDC
Internetwork Transport Layer
Network Layer
SNAC
LLC
MAC
Data Link
Layer
• 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 today.
INWG’s Internet Model
Internet Gateways
Host
Host
Application
Application
Internet
Transport
Internet
Transport
Network
Network
Data Link
Data Link
Network 1
Network 2
Network 3
• 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!!
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!!!
The Internet is a beads-on-a-string Network like the PSTN
How Did They Lose a Layer?
• Partly, because the ARPANET was the only network in their world
– And it was a black box to everyone but BBN
• The other “networks” in the their space: Ethernet, SatNet, PRNet
– Weren’t really networks but multi-access media
• As they transitioned from NCP to TCP in the late 70s with just the
ARPANET and Ethernets, you can watch it disappear.
-
In the late 1970s, people talk about Internet Gateways, but ~1983 the term
disappears and one only hears: Router.
• Cerf’s “The Catenet Model of Internetworking” (IEN#48, 1978) contains no
layer diagrams, just beads on a string pictures, and names the interface.
• We could mark the end of the Internet as an internet as Jan 1, 1983, the
day they turned off NCP.
•
The day many mark as the beginning of the Internet!
Wait A Minute!
Names the Interface?
•
•
•
•
•
Remember Tinker AFB? The answer was obvious. Do what OSs do!
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.
Application
Name
Node
(Logical Address)
Point of
Attachment
(Physical Address)
Directory
Here
Route
And
Here
Path
Not in the Internet
•
The Internet only has a Point of Attachment Address, an interface.
–
–
•
There are no node addresses or application names.
–
–
–
•
Which is named twice!
No wonder there are addressing problems
Domain names are macros for IP addresses
Sockets are Jump points in low memory
URLs name a path to an application
This makes router table size 3-4 times larger than necessary and similarly the
number of addresses needed.
Application
Name
Application
Socket (local)
Node Address
IP Address
Point of Attachment
Address
MAC Address
As if your computer worked only with absolute memory addresses.
(kinda like DOS, isn’t it?)
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!
• Problem: IP fragmentation doesn’t work (and never has).
– 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.”
– Not a “big” problem, but big enough to be suspicious.
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.
Data
Transfer
Data Transfer
Control
Delimiting
Seq Frag/Reassemb
Relaying/ Muxing
Retransmission and
Flow Control
SDU Protection
• TCP was split in the Wrong Direction!
• It is one layer, not two.
– Creating IP was a bad idea. Not to mention it names the wrong thing too!
• Are There Other Implications?
Watson’s Seminal Result (1978)
The Pouzin Society
• 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
•
Watson 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 connections with recent activity
• Watson shows that TCP has all three timers and more.
– delta-t is more robust under harsh conditions and more secure than TCP.
– Synchronization has nothing to do with a 3-way handshake.
• SYNs, FINs are unnecessary.
• Also defines the bounds of networking or InterProcess Communication:
– It is IPC if and only if Maximum Packet Lifetime can be bounded.
© John Day, 2013
All Rights Reserved
– If MPL can’t be bounded, it is remote storage.
25
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
– The path to the Application is named, but Nothing names the Application.
© John Day, 2014
Rights Reserved
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.
• Thwarts any attempt at doing Quality of Service.
• And implicit detection makes it predatory.
– Virtually impossible to fix
• Whereas,
© John Day, 2014
Rights Reserved
Congestion Control in an Internet is
Clearly a Network Problem
Internet Gateways
Host
Host
Application
Application
Internet
Transport
Internet
Transport
Network
Network
Data Link
Data Link
Network 1
Network 2
Network 3
• 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.
© John Day, 2014
Rights Reserved
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
© John Day, 2014
Rights Reserved
IPv6: Makes Matters Worse
• Primary Problem: Router Table Size; secondarily address exhaustion.
• 1992 Rejection of IPv7 (CLNP), which named the node and was already
deployed and operational in the routers. (the transition was over.)
– By continuing to name the interface, avoided reducing router table size by a factor
3 – 4 times (as well as address usage) Reducing router table size was Major Problem
• They kind of cut off their nose to spite their face
– This decision above all was totally irresponsible, but not uncommon.
– Not only does it make solving multihoming an unscalable mess, but makes
mobility the cumbersome mess MIPv6 creates.
– Long list of problems today, and loc/id split only dug the hole deeper.
• But did get more addresses, but can only route on /64, the rest are for NSA.
– Barely able to route 1 IPv4 address space, no idea how to route 4.3 billion.
– But that is okay, as we will see a global address space is unnecessary in a wellformed architecture. (More addresses isn’t a problem).
• Yes, there is good news a-comin’!
© John Day, 2014
Rights Reserved
Never Get a Busy Signal on the Internet!
2010 They Discovered Buffer Bloat!
No Interface
Flow Control
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.
© John Day, 2014
Rights Reserved
But What About Security?
• Security?
• Don’t you read the papers?!
– It is terrible! And getting worse.
– IPsec makes IP connection-oriented, so much for resiliency to failure.
– Everything does their own, so very expensive.
• Privacy? Can’t fix it, so same reaction as for QoS
– You don’t need it in the brave new world.
• They say the Reason is that Never Considered It at the Beginning.
– Later we will see how ignoring security can lead to better security.
• There have been a lot of “after the fact” attempts to improve it.
– With the usual results: greater complexity, overhead, new threats.
© John Day, 2014
Rights Reserved
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 the 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!?
© John Day, 2014
Rights Reserved
But It’s a Triumph!
(By that argument, so was DOS)
•
•
•
•
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 making it more expensive and
less predictable and taking us further from where we need to be.
© John Day, 2014
Rights Reserved
So Why Is TCP Dominant?
• The Usual Reason:
• He with the deepest pockets wins.
– It was the taxpayers’ money, so who cares!?
• DARPA was spending orders of magnitude more on networking than
everyone else combined and then gave it away for free.
– Even then, it was loose change to the DoD
• Hey! It was Free!
– I guess you get what you pay for.
• There is conclusive evidence that business left to its own devices came
very close to getting it right.
– For starters, they didn’t lose a layer, which helps a lot.
– Not entirely, but close enough to be fixed.
• Ironically, one could conclude that the mess we find ourselves in is
another case of the Meddling of Big Government! ;-)
© John Day, 2014
Rights Reserved
The Internet Never Got Past
Application
Or do whatever
you want
TCP
IP
Subnet
Or do whatever
you want
We Were Missing Something, but What was It?
Were Layers the Wrong Model?
They Weren’t Sure, But 7 Looked Good
But As Things Developed Things got more complex
Application
Application
Presentation
Session
Transport
Presentation
SNIC
Session
SNDC
Transport
SNAC
Network
LLC
Data Link
MAC
Physical
Physical
And While Better It Wasn’t The Full Answer
A Quick Review
1: Start with the Basics
Two applications communicating in the same system.
Application
Processes
A
B
Application
Flow
IPC Facility
Port
Ids
Communication within
a Single Processing System
This is establishes the API. The Application
should not be able to distinguish a slow
correspondent from operating over the Network.
How Does It Work Now?
Application
Processes
Port
Ids
FA
EFCP
FA
Distributed
IPC Facility
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.
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.
Connection-id
Dest-port
Src-port Op
Seq # CRC
Data
• Will also need an application to manage multiple users of a single resource.
4: Communication with N Systems
Systems
A Little Re-organizing
A Virtual IPC Facility?
Res
Alloc
Finder
IAP
Dir
So we have a Distributed IPC Facility for each Interface, then to
maintain the API we need an application over all of them. The user
shouldn’t have to figure out which wire to use.
But this isn’t going to scale and get expensive fast. We need a
cheaper way to do this.
5: Communicating with N Systems
(On the Cheap)
Dedicated IPC
Systems
Host Systems
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.
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
Relaying
Application
Relaying
PM
Interface
IPC
Processes
Interface
IPC
Processes
The IPC Model
(A Purely CS View)
User Applications
Relaying
Appl
Mux
Mux
EFCP
EFCP
EFCP
EFCP
EFCP
EFCP
Distributed IPC Facilities
EFCP
EFCP
The Implications
• Networking is IPC and only IPC.
– We had been concentrating on the differences, rather than the similarities.
• All layers have the same functions, with different scope and range.
– Not all instances of layers may need all functions, but don’t need more.
• A Layer is a Distributed Application that provides and manages IPC.
– A Distributed IPC Facility (DIF)
• This yields a theory and an architecture that is simple, elegant, and
scales indefinitely,
– i.e. any bounds imposed are not a property of the architecture itself.
– And capabilities we didn’t expect.
• Let’s See What the Theory Tells Us
What a Layer Looks Like
IPC IPC
IPC Management
Control
Transfer
Delimiting
Applications, e.g., routing,
resource allocation,
Transfer
access control, etc.
Relaying/ Muxing
Common Application
PDU Protection
Protocol
Application-entities
•
Processing at 3 timescales, decoupled by either a State Vector or a Resource Information Base
–
–
–
•
Application Process
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.
47
What are the Protocols?
The Pouzin Society
RIB Daemon
Flow Allocator
EFCP
Resource Allocation
RMT
IPC Management
IRM
CDAP
• Only two
– A data transfer protocol, EFCP, based on delta-t with mechanism and
policy separated. This provides both unreliable and reliable flows.
• Good Examples of separating mechanism and policy
– The common application protocol based on CDAP:
• Transition from an IPC Model to a Programming Model
• 6 Fundamental Operations on Objects.
• Assembler for Distributed Applications
© John Day, 2013
All Rights Reserved
48
Only Three Kinds of Systems
Interior
Routers
Hosts
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.
How Does It Work?
Enrollment or Joining a Layer
(N)-DIF
A
(N-1)-DIF
•
•
Do what the Model Says:
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
•
More than one way to complete enrollment.
How Does It Work?
Establishing Communication
A
Look over there!
B
• Simple: do what the model says.
–
–
–
–
–
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 it.
Actually go see if it is there and whether we have access.
Then tell A the result.
• 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’s has moved, we find out and keep searching
Decentralizes name resolution, rather than the centralized approach of DNS
Naming in RINA
IPC Process
Flow Allocator
EFCP
IRM
•
DIF
Allocator
IPC Process-name is just an application-process-name (“global” scope)
– An address is a synonym that names an IPC Process with scope restricted to the layer and
maybe structured to facilitate use within the layer.
•
•
A port-id is a Flow-Allocator-Instance-Id (local scope).
A connection-endpoint-id (CEP-id) is an EFCP-instance-id (local scope).
• Note that these are local to the IPC Process.
•
A connection-id is created by concatenating source and destination CEP-ids.
•
That’s It!
Implications of the Model & Names
(Routing Table Size)
•
Recursion either reduces the number of routes or shortens them.
Metros
Regionals
Backbone
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.
(N)Routing
Domains
Metros
Regionals
(N-1)-Routing
Domains
Backbone
© John Day, All Rights Reserved, 2009
Implications of the Model & Names
(Multihoming)
(N)-IPC-Process
(N)-Address
Port -id
(N-1)-IPC-Process
•
Yea, so? What is the big deal?
– It just works
• An IPC-Process inspects the destination address of the (N)-PDU and forwards it to its
next hop. The current forwarding tables intend to deliver to left-hand (N-1)-IPC Process,
but it goes down. There is a routing update that now recognizes that the path to that
address is through the right (N-1)-IPC Process.
– Normal operation. Nothing special to do. Even uses 50% to 75% fewer addresses
and forwarding tables are commensurately smaller as well.
– Yes, as we saw the (N-1)-bindings may fail from time to time.
• Not a big deal. Because that is
Implications of the Model & Names
(Mobility)
(N)-IPC-Process
Port -id
Address
New Address
(N-1)-IPC-Process
•
Yea, so? What is the big deal?
– It just works just like multihoming only the (N-1)-port-ids come and go a bit more
frequently.
•
O, worried about having to change address if it moves too far? Easy.
• Assign a new synonym to it. Put it in the source address field on all outgoing PDUs. Stop
advertising the old address as a route to this IPC-Process. Advertise the new one.
• Want to renumber the DIF for some reason? Same procedure.
•
Again, no special configuration to do. It just works.
The Skewed Necklace
The Pouzin Society
(DIF view)
Base
Station
Metro
Subnet
Regional
Subnet
Mobile Infrastructure Network
•
•
Traditional ISP Provider
Network with normal necklace with
an e-mall top layer.
Notice: No special mobility protocols. No concept of a Home Router, No Foreign
Routers, No Tunnels to set up. It just works.
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 full networks.
© John Day, 2013 57
Rights Reserved
Implications of the Model & Names
(Choosing a Layer)
•
In building the IPC Model, the first time there were multiple DIFs (data link
layers in that case), to maintain the API a task was needed to determine which
DIF to use.
A Virtual IPC Facility?
Finder
Res
Alloc
IAP
– User didn’t have to see all of the wires
– But the User shouldn’t have to see all of the “Networks” either.
•
This not only generalizes but has major implications.
Implications of the Model & Names
(A DIF-Allocator)
•
IPC Resource Manager (IRM) determines what DIFs applications are available.
– If this system is a not member, it either joins the DIF as before
– or creates a new one.
IRMs
– This is the generator function.
• IOW, a Global Address Space is Not Necessary.
•
Which Implies that the largest address space only has to be large enough for the
largest e-mall.
•
•
•
Given the structure, 32 or 48 bits is probably more than enough.
This is a Powerful New Tool for scaling and security.
Layers never need to get too big.
So a Global Address Space is Not Required but
Neither is a Global Application Name Space
DIF-Allocator
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.
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.
– IOW, “Global” is relative! ;-)
Stop For a Moment
• In case you hadn’t noticed: ;-)
• For us, testing the model, constantly challenging, questioning whether it
is right, teasing out new principles is as important as finding something
that works.
– What we don’t understand is as important as what to build, if anything more.
• If we don’t get the fundamentals right, they will come back and to haunt
us!
• As you have seen, it has been quite successful, most everything just
works and problems we didn’t consider initially have simply fallen out.
– It is amazing what a scientific approach, rather than a craft tradition can do.
• Like Security
How Does It Work?
Security
ISP
• 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.
Hosts and ISPs do not share DIFS.
(ISP may have more layers
How Does It Work?
Port:=Allocate(Dest-Appl, params)
Security
Access Control
Exercised
•
•
•
Do What the Model Tell Us:
Application only knows Destination Application name and its local port.
The layer ensures that Source has access to the Destination
–
•
•
•
All members of the layer are authenticated within policy.
Minimal trust: Only that the lower layer will deliver something to someone.
PDU Protection can provide protection from eavesdropping, etc.
–
•
Application must ensure Destination is who it purports to be.
Complete architecture does not require a security connection, a la IPsec.
The DIF is a securable container. DIF is secured not each component separately.
RINA is Inherently More Secure
and Does It With Less Cost
• 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!
• Many of the attacks on TCP simply don’t work because delta-t doesn’t
overload the semantics of the port-id and decouples port allocation and
synchronization. (Bodaparti, 2013)
• RINA Security is considerably Less Complex than the Current Internet
Security (Small, 2012)
– Only do a rough estimate counting protocols and mechanisms.
To Add
Security
Internet
RINA
Protocols
8
0
Non-Security
Mechanisms
59
0
Security Mechanisms
28
7
Copyright © 2012, Jeremiah Small. All Rights Reserved.
“Internet” Congestion Control
• As we saw a few minutes ago, the Internet didn’t realize this could
happen, and that they put it the worst possible place an avoidance
scheme that works by causing congestion.
• TCP congestion control “pulses” the network with a saw-tooth
oscillation based on randomly distributed round-trip times.
• QoS must be done in the network and enforced all the way to the wire.
– TCP thwarts any attempt at QoS that tries to do low jitter.
• Can’t be fixed without inflicting great pain.
How Does It Work?
“Congestion Control”
• In RINA, congestion control can not only be where it belongs,
• Because Congestion Control is done where it belongs the congestion
control strategy can be different for different layers and for different
QoS classes within layers.
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
How Does It Work?
The Internet and ISPs
• But there does not need to be ONE e-mall.
– Notice all the layers are private. Public layers are a form of private.
Facebook Boutique
Public Internet
My Net
Utility SCADA
Internet Rodeo Drive
Internet Mall of America
ISP 1
ISP 2
ISP 3
This Won’t Make Some Happy
A Wall-less Garden?
•
•
•
•
•
•
Suppose an ISP has its own e-mall and
forms an alliance with a few CDNs and Data Centers,
To give the ISP access to ~80% of the most popular destinations within its e-mall.
For the rest, create a new Special DIF for customer.
Among other things notice the implication for security:
An attack has to come either from:
»
»
»
»
The Customer’s Network
The ISP,
CDN or Data Center or
A Special DIF.
• An “Internet” is a Non-Sequitor
A Special DIF
My Provider’s E-Mall
CDN
ISP 2
DC
Not Just a Network Model
• A Layer is a Distributed Application that Does IPC
• That Forced Us to Answer: What is a Distributed Application?
• We now are working with a Unified Model for
Application Processes
Task
s
Operating Systems
Laptop
Printer
Task
sched
Mem
Mngt
IPC
Disk
Distributed
Applications
OS - DAF
WiFi
-DIF
Networks
USB
-DIF
IRM
IRM
“But You Can’t
Replace the WHOLE Internet!”
• Wish I had a dollar for every time I have heard that!
– What are they putting in the water these days?
• They told us we would never replace the PSTN or IBM’s SNA.
– Even in the late 1980s, people said data would never exceed voice. (!!)
• Of course, it won’t be replaced overnight. Perhaps never. Does it matter?
– You have already seen the transition plan.
• The Internet is just another e-mall: A good place to test malware, conduct
cyberwarfare, steal credit cards, find drug dealers, sacrifice your privacy,
etc. . . . . . All sorts of useful things!
• We build over it, under it, around it. Use it for what you want.
• We build other e-malls along side it.
– Give people a choice, after all competition is good, right?
Transition? No, Adoption
RINA supported Applications
RINA Network
RINA Applications
Public Internet
Rina Provider
• Adopt. Don’t transition.
– If the old stuff is okay in the Internet e-mall, leave it there.
– Do the new capabilities in RINA
• Operate RINA over, under, around and through the Internet.
– The Internet can’t be fixed, but it will run better over RINA.
– New applications and new e-malls will be better without the legacy and
run better along side or over the Internet.
• The Microsoft Approach or the Apple approach?
– Microsoft tried to prolong the life of DOS. It still haunts them.
10 May 10
• A clean break with the past. The legacy is just too costly.
• We need engineering based on science, not myth and tradition.
© John Day, 2010
All Rights Reserved
74
Ongoing implementations
• Three: Implementations: Java, C (user-space), C++/C (user-space and kernel)
• Java: Boston University, Mostly for education and academic purposes
• C: TRIA Network Systems, RINA software in user-space (Linux)
• C/C++ version by the IRATI and PRISTINE consortiums1 split between
user/kernel space on Linux over TCP/UDP, 802.1q (VLANs) and shared memory
for Hypervisor/VM communication
•
Status: first version of high-level software architecture design document about to be
released (will be published at IRATI website during May 2013)
• The RINA Simulator can be found at:
• https://github.com/kvetak/rina
1 More details in the RINA session after the break!
There is Much More,
And Much More to Discover!
• An Invitation: Come explore it with us.
– There is much to explore:
• Believe it or not, this talk has 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
–
–
–
–
–
Then the “Reference Model” (4 sections) and
Check out related work at
At www.pouzinsociety.org or
www.irati.eu or
csr.bu.edu/rina
Thank You