1. Leaving the Dark Ages
of Networking Behind:
Welcome to the RINAssiance!
John Day
Boston University
VTC2020 Workshop on
New Network Architecture
Powering Internet-of-Things
Nov 2020
A good architect suffers from
the topologists vision defect:
Can’t tell a coffee cup from a donut!

2. © John Day, 2011
Rights Reserved
2
But C’mon, Day.
Isn’t “Dark Ages” a bit of Hyperbole!?
• You tell me:
• ARPANET sees Networking as IPC
– Walden, RFC61 (70); Metcalfe, NCP paper (72); Padlipsky, RFC871 (82)
• Englebart’s NLS with mouse and keyset on a Workstation
• (well, an IMLAC)
– Forward and reverse hypertext system 20 years before the Web.
• Metcalfe invents Ethernet after working on AlohaNet
• Unix extracted from Multics, a high point in OSs
• Physicists at Argonne collaborating with CERN (illegally over the Net) ;-)
• Multiple problems of opposites solved by finding an elegant
synthesis that makes them both degenerate cases.

3. © John Day, 2011
Rights Reserved
3
New Ideas Were Everywhere
Clearly in “new paradigm territory”
things being re-thought
• Not just technology, Music, the Arts, Film the Environment
– Earth Day, Civil Rights, ‘68 in the US and France
– Man on the Moon
• Major Advances in Distributed Databases
– No way to know a network is partitioned until it is over
– Two major approaches to updating multiple copies
• Maps being created from ERTS Satellite photos
– Do processing at UCLA, generate graphics at Utah, print pics at Illinois
• Illinois puts First Unix on the Net Summer of ‘75, then
– Stripped down Unix to fit on an LSI-11 with plasma screen and touch, a
decade before X-windows, maps down to the square mile for a land use
planning system for 6 counties around Chicago from databases on both
coasts transparently.
• By 76, I was commuting over the Net from Houston to UIUC.
• And much more!

4. © John Day, 2011
Rights Reserved
4
They Were Heady Times
- Pun intended ;-)
• 1972 – Tinker AFB joins the Net and we learn addressing is interesting
– But the solution is obvious. Must route to the node, not the interface.
• XNS, CYCLADES already knew it
• 1972 – ICCC: The ARPANET Coming Out Party
– Demonstrated Instant Messaging, Searchable AP Wire, SAIL’s Doctor
talking to MIT-AI’s paranoid patient; distributed computing, etc.
– AT&T is unimpressed, in fact, laughed at it.
– Learn about CYCLADES provides Impetus for, research networks to start
an initial standards effort and form INWG IFIP WG6.1
• First major focus is a Transport Protocol
• Also Virtual Terminal and Formal Description
• 1973 – USING is formed in the ARPANET to develop application
protocols for a resource sharing network, even a network-wide editor!
– There is much excitement.

5. Major Breakthrough in Europe
The Cyclades Architecture
(1972)
• The Layers as developed by CYCLADES were:
• Transport Layer provides end-to-end reliability, primarily recovering from loss due to
congestion.
• The Network Layer Does Relaying and Multiplexing of datagrams with the primary
loss due to congestion and rare memory errors.
• The Data Link Layer detects corrupted packets and may do flow control.
• Hence, the loss rate must be much less than the loss due to congestion by the Network Layer.
• The Physical Layer is the Wire.
• Networking is IPC here too. CYCLADES was already an internet.
Physical
Data Link
Network
Transport
Application
Host or End System
Router
TS: End-to-End Reliability
Cigale Subnet
© John Day,
All Rights Reserved, 2009

6. 6
© John Day,
All Rights Reserved, 2009
11/01/06
The (really) Important Thing about Layers
• A Layer is a distributed resource allocator.
In OSs, Layering was a convenience, here it is a necessity.
• Different Layers should have different scope
• Either in terms of number of elements or range of operation
• There are multiple layers at the same rank.
• This is also why the concepts of control and data planes are
untenable: Not all systems are in the same “plane.”
• This was a whole new model, a new paradigm
Host or End System
Router
Increasing
Scope

7. © John Day, 2014
Rights Reserved
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 operating
systems moving from polled to interrupt driven, and development of
Ethernet, etc, 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!
– This invalidated the business models of the PTTs and IBM. The Internet
never got the memo. The phone companies keep trying to go back.

8. © John Day, 2011
Rights Reserved
“Who Are Those Guys!”
- Paul Newman as
Butch Cassidy, 1969
• By 1975, we ran into the PTTs with a very different view of networking:
It was just like the phone system and they had lots of power!
– Hierarchical, deterministic, not-peer, but doesn’t scale well.
– The old guard vs the young turks
• They used the architecture to define what was theirs and what was the
subscribers’ (not much) NET2030 is based on this model
– Their big dream was services ‘in the network’ so they would own it.
– Precluded by the Transport Layer, Means All Services are at the Edge.
• Kinda makes “Edge Computing” a non-sequitur.
– Worse It Relegated Them to a Commodity Business. In their view,
– No TRANSPORT LAYER! No CONNECTIONLESS
• The Battle is on!! Networking vs CCITT (ITU) and IBM’s SNA
• A very intense battle.
– Why are you pushing this? You Will Never Replace the PSTN and SNA!
– Because it is the right answer. 8

9. © John Day, 2011
Rights Reserved
9
In INWG
An International Transport Protocol
• To counter CCITT (a little), researchers form INWG, IFIP WG6.1
• There Were Two Proposals in 1975:
– INWG 37 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.
• So a Synthesis in INWG 96
– Adopted by NPL, CYCLADES, EIN and the basis for OSI TP4
– But DARPA had no interest in compromise. My way or the highway

10. © John Day, 2011
Rights Reserved
10
But It is Similarity Among all 3
that Is Much More Interesting
• This is before IP was separated from TCP. INWG 96 also carried
addresses, as did INWG 61.
• This means that the architecture that INWG was working to was:
• Three Layers of Different Scope each with Addresses.
• If this does not hit you like a ton of bricks, you haven’t been paying
attention.
• This is NOT the architecture we have.
• A Layer is MISSING!!
Internetwork Transport Layer
Network Layer
Data Link
Layer
TCP
IP
MAC
LLC
SNDC
SNAC

11. © John Day, 2014
Rights Reserved
Let’s Pause a Minute
It Was Clear to Everyone
• That networks would need to be interconnected.
– That was pretty obvious
• There were basically two ways to do that:
– The Traditional DataComm/Phone Approach using Protocol Translation,
• creates an N2 problem, Adopted by ITU. (figures, doesn’t it)
• Prefers deterministic, static allocation, virtual circuit, beads-on-a-string
– The Internetworking Approach using an Overlay and No Translation
• The Researchers adopted this approach.
• Layers of different scope. Non-deterministic, dynamic allocation, datagrams.
• Each network must support the minimal service expected by the overlay.
• More fuel to the fire!

12. © John Day, 2014
Rights Reserved
How Did the Internet Lose a Layer?
• Consider the networks for DARPA’s Internet:
– Ethernet
– Packet Radio
– Satellite Network and of course
– the ARPANET, but it is a black box.
• And They are Building an INTERNET!
– So they need an overlay
• But the first 3 are not networks, but multi-access media (only link layers)
– And with the common overlay
• And then split IP from TCP. This should look familiar.
Network
Data Link
Network
Data Link
TCP
TCP
IP

13. © John Day, 2014
Rights Reserved
The Layered Internet Model
(1976)
• An Internet Layer addressing 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
• (OSI independently rediscovers this structure a decade later.)
Internet Gateways
Data Link
Network
Internet
Application
Host
Data Link
Network
Internet
Application
Host
Network 1 Network 2 Network 3

14. © John Day, 2011
Rights Reserved
14
USING Didn’t Last Long
• Two Meetings - Lots of Great Ideas and Proposals
– Even agreed on a Network Standard Editor
• 1974 DARPA shuts down USING. Afraid they are losing
control of the‘Net. (They already had, just didn’t know it) ;-)
– Things are closing down
• NO NEW APPLICATIONS in the Net for 20 years!
• Not Getting Dark You Say?!
• By 1983, the Internet Has Lost the Internet Layer and is firmly
in the ITU Model.

15. Software Engineering Question
• There is this module:
• There is a need to partition it into two modules. The question is along
what lines does one partition it?
• One could partition it one way, but it breaks an internal function:
• Or along different lines, which doesn’t break anything,
• Which one do you choose?
• Then Why Didn’t They Do that with TCP?!

16. © John Day, 2011
Rights Reserved
16
When They Split IP from TCP,
They Broke Something
• Error and Flow Control separated from Relaying and Multiplexing are
independent. But IP also handles fragmentation across networks.
• Protocol Translation
• Problem: IP fragmentation doesn’t work, 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:
– The equivalent of “doc, it hurts when I do this!”
“Then don’t do it.”
It doesn’t work either. ICMP is blocked, often used for DDoS attacks
MTU Discovery

17. © John Day, 2011
Rights Reserved
17
But it is the Nature of the Problem
that is Interesting
• The problem arises because it is protocol translation and the split of
functions between IP and TCP is not independent.
– This makes it a bead-on-a-string model, really striped beads
• A Careful Analysis of this Class of Protocols shows that the Functions
naturally cleave along lines of Control and Data.
• TCP was split in the wrong Direction!
• It is one Layer not Two
– IP was not a good idea, IP + UDP would’ve been better, but even then . . .
Relaying/ Muxing
Data
Transfer
Data Transfer
Control
Delimiting
Seq Frag/Reassemb
SDU Protection
Retransmission and
Flow Control

18. © John Day, 2014
Rights Reserved
Why Does IP
Name 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)
Solves Multihoming

19. © John Day, 2014
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
– Getting dimmer?
MAC Address
IP Address
Socket (local)
Application
Application
Name
Node Address
Point of Attachment
Address
As if your computer worked only with absolute memory addresses.
(kinda like DOS, isn’t it?)

20. © John Day, 2014
Rights Reserved
The API to the Network
A Missed Opportunity
• In 1975, the network API for first UNIX system on the ‘Net used file_io
– Open, close, read, write.
• Open(<host name>/<application name>) e.g. Open (ucsd/telnet)
– Notice this would lay the ground work for a seamless transition to
application names instead of the status quo of domain names.
– This also puts the name look up below the layer boundary (where it belongs)
and doesn’t require the application to do anything different.
– Instead, Sockets which breaks every rule about layers, exposes too much of the
internal layer machinery. Makes conversion to IPv6 a nightmare.
Open(UCSD/Telnet)
Name
Look-up
Transport
Protocol

21. © John Day, 2011
Rights Reserved
21
A Chance to Get Things on Track
• It had been clear since ~1970 Application Names and some kind of
Directory were needed.
• We knew downloading the Host file from the NIC was temporary.
• When it needed to be automated 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
– Names a path to an arbitrary instance of an application.
– Did the lights flicker?

22. © 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.
• The Effectiveness of any Congestion Strategy Deteriorates with
Increasing Time-to-Notify. Internet maximizes it and it is increasing.
• And implicit detection (lost acks) makes it predatory.
– Appears impossible to fix without great pain.
• Whereas,

23. © John Day, 2014
Rights Reserved
Congestion Control in an Internet is
Clearly a Network Problem
• With an Internet Architecture, it clearly goes in the Network Layer
– Which was what everyone else thought.
• Time to Notify can be bounded and with less variance.
• Can be coordinated with QoS mechanisms.
• Explicit Congestion Detection confines its effects to a specific
network and to a specific layer.
– Did we know better at the time? Yes, Raj Jain’s work
Internet Gateways
Data Link
Network
Internet
Application
Data Link
Network
Internet
Application
Net 1 Net 2 Net 3
Host Host

24. © John Day, 2014
Rights Reserved
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.
– Another step backwards . . . Still darker
• 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!

25. © John Day, 2014
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.
• 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)
• Third, the “identifier” locates communication with the application.
• Past the end of the path!
– It names everything but the node, where all paths terminate.
– But they keep trying to make it work with more elaborate fixes.
• There is no workaround. IP is fundamentally flawed.

26. © John Day, 2011
Rights Reserved
26
Taking Stock
• The Internet:
– Botched the protocol design
– Botched the architecture
– Botched the naming and addressing
• Things getting kind of dim in here
– No New Applications for 20 years.
– With an obvious API, they had to make a mess of it.
– When they had an opportunity to move in the right direction with
application names, they didn’t. They did DNS.
• darker yet
– With an opportunity to do node addresses, they didn’t. They did IPv6.
• Anybody gotta light!?
– Botched the Congestion Control twice
– Once so bad it probably can’t be fixed.
• Can’t see my hand in front of my face
• By my count this makes them 0 for 8!
• It defies reason! Do these guys have an anti-Midas touch or wha!?

27. © John Day, 2011
Rights Reserved
27
But It is a Triumph!
(By that argument, So was DOS)
• But It Works!
– So does DOS.
– With Enough Thrust even Pigs can Fly! - RFC 1925
• As long as fiber and Moore’s Law stayed ahead of Internet Growth, no
need to confront their mistakes.
– This mess impacts billions of dollars and billions of people.
• For 20 Years, There has been a Quest for a Future Internet
– Billions Have Been Spent On It. All have failed.
– And They Will Continue to Fail, Because
– They are in the wrong paradigm, the wrong model.
– What is the Right Paradigm?
– Lets see . . .

28. © John Day, 2014
Rights Reserved
Picking up the Threads
• By the 90s, it was clear that we had gone wrong some place.
• The 7-layer model turned out not to be what we thought:
– By 1983, we knew the upper 3 layers were one layer.
– By 1986, OSI re-discovered what INWG knew in 1975:
– There was a Network Layer and an Internet Layer.
• Determined I needed to find out what I knew about networks
independent of hardware, standards, politics, vested interests, etc.
– There had been some promising patterns that had come up during the OSI
work. But there was more interest a political position than following the
problem.
– Separating mechanism and policy
– The lower layers were looking very similar.
– And Dick Watson’s seminal result on protocols:
• Remember I said we were still two years out from the big insight into protocol
design.

29. Necessary and Sufficient
• In the late 1970s, Richard Watson makes a remarkable discovery.
• The necessary and sufficient conditions for Synchronization of Reliable
Data Transfer is to bound three timers:
– MPL - Maximum Packet Lifetime
– A - Maximum Hold Time before Ack
– R - Maximum Time to Re-try
• Assumes all connections exist all the time and always have
• A state vector is merely a cache of information on recently active
connections.
• No traffic for 2(MPL+A+R), discard the state vector.
– 3-way handshake is irrelevant, has nothing to do with why it works.
– It works Because, the Timers are Bounded not because 3 PDUs were exchanged
• This yields a more robust and more secure protocol.
TCP bounds MPL explicitly but assumes the other two are
bounded, consequently isn’t as robust. © John Day, All Rights Reserved, 2009

30. 30
© John Day,
All Rights Reserved, 2009
11/01/06
1: Start with the Basics
Two applications communicating in the same system.
Port-id
B
IPC-Facility
Application
Processes

31. 31
© John Day,
All Rights Reserved, 2009
11/01/06
2: Two Application Communicating
in Distinct Systems
IPC-Facility
Application
Processes
Systems

32. 32
© John Day,
All Rights Reserved, 2009
11/01/06
3: Simultaneous Communication
Between Two Systems
i.e. multiple applications at the same time
• To support this we have multiple instances of the EFCP.
Will have to add the ability in EFCP to distinguish one flow from another.
Op Seq # CRC Data
Connection-id
Src-port
Dest-port
Typically use the port-ids of the source and destination.
Also include the port-ids in the information sent in IAP to be used in EFCP
synchronization (establishment).
EFCP EFCP
EFCP EFCP
EFCP EFCP

33. 33
© John Day,
All Rights Reserved, 2009
11/01/06
Simultaneous Communication
Between Two Systems
i.e. multiple applications at the same time
• In addition to multiple instances of the EFCP.
Mux Mux
Will also need an application to manage multiple users of a single resource.
EFCP EFCP
EFCP EFCP
EFCP EFCP

34. 34
© John Day,
All Rights Reserved, 2009
11/01/06
Systems
4: Communication with N Systems

35. 35
© John Day,
All Rights Reserved, 2009
11/01/06
Host Systems
Dedicated IPC
Systems
5: Communicating with N Systems
(On the Cheap)
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.

36. 36
© John Day,
All Rights Reserved, 2009
11/01/06
The IPC Model
(A Purely CS View)
Relaying
Appl
EFCP
EFCP
EFCP EFCP EFCP EFCP EFCP EFCP
Mux
Mux
User Applications
Distributed
IPC
Facilities

37. 37
© John Day,
All Rights Reserved, 2009
11/01/06
Networking is IPC
and only IPC
• Right, We are Back Where We Started.
• We are Back to the Ideas that fueled the Golden Age.
• The Internet has been Wandering in the Dark for 30 years.
– All of the characteristics: stagnation, lost knowledge, etc.
• Layers are not divisions of functionality, but ranges of allocation.
– All Layers have the same functions, for a different range of the problem.
• Dykstra was right functions don’t repeat . . . in the same scope.
• Those functions have not been performed over that scope.
• A Layer is a Distributed Application that Does IPC.
– A Distributed Resource Allocator
• Application-names and port-ids are the only externally visible identifiers.
– The only information an application must and should know to establish
communication is the destination application-name and its port-id.
• Already security is better and we haven’t done anything yet.

38. © John Day, 2014
Rights Reserved
How to Distinguish the Two Models
• The ITU Beads-on-a-String Model
– Boxes, wires are dominant.
• Just look at the figures in every paper: boxes and wires.
– Layers are just modules in a Box.
– Lots of talk of ‘planes’: control planes, data planes, “you-name-it” planes
• (I have yet to find anyone who can define precisely what one is)
• The Layered Model
– Processes and Layers are Dominant
– Boxes are just what they reside in.
– It is Distributed Systems

39. © John Day, 2014
Rights Reserved
The RINA Approach
• Maximize invariance and minimize discontinuities.
– I had various aphorisms, like a topologist, I can’t tell a coffee cup from a donut!
– Logicians have found that abstraction is invariance
• (Doh! That should have been obvious! Topology is the study of invariances.)
– Maximizing invariance, maximizes simplicity.
– Minimize Discontinuities. IOW, Degenerate cases are preferred to special cases.
• Degenerate cases are consistent with the invariances, special cases break the
invariances.
– Construct the Model to Not Break the Invariances.
• No Devils in the Details, Only Angels
• Do what the problem says.
– Don’t try to impose your view. The problem is smarter than we are. Do what it
says regardless. If you don’t, the problem will extract a price later. And the longer
it takes to you admit you ignored the problem, the more it will cost. ;-)
• Continually try to prove the Model wrong.
– We can’t prove it right and we can't be sure we heard the problem clearly. So
keep looking for what you have missed.

40. 40
© John Day,
All Rights Reserved, 2009
There are Many Incredible Results: I
• There is one layer and it repeats over different ranges of capacity, QoS,
and Scope. This architecture scales indefinitely, only limited by physics.
• Separating mechanism and policy yields one data transfer protocol and
one application protocol.
– A huge complexity collapse.
• Because there is a full addressing model, true multihoming is inherent in
the model. No additional mechanisms or costs are necessary. It just works.
• Because mobility is just multihoming where points of attachment change
more frequently, mobility requires nothing new. It just works.
– No home or foreign agents, no tunnels, no anchors, no new protocols.
• Because addresses are synonyms a network can be renumbered in seconds
to minutes without affecting traffic. Nothing special. It just works.
• Congestion Avoidance can be coordinated with QoS policies.
• Guaranteed QoS source to destination
• And it scales.
11/01/06

41. 41
© John Day,
All Rights Reserved, 2009
There are Many Incredible Results: II
• Routing on the node reduces router table size by a factor at least 4 or 5.
• Router Table Size can be bounded.
• The layer is a securable container. Security is much less expensive.
– No firewalls are necessary.
• Because port allocation and synchronization are distinct, data transfer is
impervious to attacks common to TCP
• All networks are private. Public networks are more open private networks.
– This combined with policies puts providers in control of their nets, not vendors.
• A global address space is unnecessary, but all applications can be reached.
• Unlike TCP, flow allocation verifies the existence of the application.
• A flow can be allocated to a specific instance of the destination application.
• Two Applications using different protocols can allocate flows to the same
instance of a destination application.
• And much much more!
11/01/06

42. © John Day, All Rights Reserved, 2009
If We Look at This From Above,
It Looks Like This
Divide and Conquer
42
Border
Routers
Backbone
Subnet Subnet
Host or Border
Router
Host or Border
Router

43. © John Day, All Rights Reserved, 2009
10 November 2020 . 43
Implications of the Model & Names
(Multihoming)
• Yea, so? What is the big deal?
– It just works
• To Send an (N)-PDU, the (N)-IPC-Process looks up the Destination Address in its
Forwarding Table and finds the (N-1)-port-id to send it on. (The (N-1)-port-id is bound to
a flow to the (N-1)-IPC-Process of the Next Hop. The (N-1)-Layer sends an (N-1)-PDU
to the Next Hop.
• (N-1)-PDU arrives at an (N-1)-IPC Process. If the (N-1)-address designates this (N-1)-IPC
Process, the (N-1)-CEP-id is bound to the port-id, so after stripping off (N-1)-PCI, it
passes it up. PDUs arrive on different (N-1)-DIFs? So?
• The process repeats. If the (N)-address in the (N)-PCI is this IPC-Process, it looks at the
CEP-id and pass it up as appropriate.
• Normal operation. Yes, the (N-1)-bindings may fail from time to time.
• Not a big deal. Because that is . . .
(N)-Address
Port -id
(N)-IPC-Process
(N-1)-IPC-Process

44. © John Day, All Rights Reserved, 2009
10 November 2020 . 44
Implications of the Model & Names
(Mobility)
• Yea, so? What is the big deal?
– It just works just like multihoming only the (N-1)-port-ids come and go a bit more
frequently.
• Again, no special cases. No special protocols. No concept of a home or foreign
router. No tunnels. Okay, policies in the DIF may be a bit different to
accommodate faster changing points of attachment, but that is it.
• Recursing layers ensures that scope of the layer matches the rate of change.
• We will come back to this.
Address
Port -id
(N)-IPC-Process
(N-1)-IPC-Process

45. © John Day, All Rights Reserved, 2009
10 November 2020 . 45
Implications of the Model & Names
(Mobility)
• O, worried about having to change address if it moves too far? Easy.
– Assign a new synonym to the IPC Process.
– Notify all EFCP flows originating here of the change in source address.
• Tells all destinations of the new address.
– Stop advertising the old address as a route to this IPC-Process.
– Advertise the new address in router updates.
• Want to renumber the DIF for some reason? Same procedure.
Address
Port -id
(N)-IPC-Process
(N-1)-IPC-Process
New Address

46. © John Day, 2013 46
Rights Reserved
The Pouzin Society
The Skewed Necklace
(DIF view)
• 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.
Base
Station
Metro
Subnet
Regional
Subnet
Mobile Infrastructure Network Traditional ISP Provider
Network with normal necklace with
an e-mall top layer.

47. How Does It Work?
Security
• 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
– Application must ensure Destination is who it purports to be.
• 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.
– Complete architecture does not require a security connection, a la IPsec.
• The DIF is a securable container. DIF is secured not each component separately.
Port:=Allocate(Dest-Appl, params)
Access Control
Exercised

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

49. 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

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

51. This Won’t Make Some Happy
• 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
CDN ISP 2 DC
My Provider’s E-Mall
A Special DIF
A Wall-less Garden?

52. The Pouzin Society
© John Day, 2013
All Rights Reserved
52
Okay, Day, Your So Smart!
• If a DIF is Distributed Application that Does IPC, What is a Distributed
Application!?
– Kinda walked into that one, didn’t I? ;-)
• In figuring how repeating layers fit with Dykstra’s view found out
– OSs recurse too!
• When threads were created, no one seem to ask, what is the process for?!
– The Process is the OS for the threads
– O, and threads are processes.
• I contend that this answers a lot of questions there have been about threads and
makes them a much more elegant and useful construct.
• Hence,

53. The Pouzin Society
© John Day, 2013
All Rights Reserved
53
The Structure of a Process
• A Process has a recursive structure consisting of task scheduling,
memory management, and inteprocess communication to manage its
tasks, which are, in turn, processes.
• Which means that a Distributed Application Facility (DAF) is a set of
Distributed Application Processes (DAP) that are cooperating to
perform some function.
Task sched
Mem
Mngt IPC
Tasks

54. The Pouzin Society
© John Day, 2013 54
Rights Reserved
A DAP Consists of
• We are still exploring this.
• Conjecture: In general the Tasks do not use IPC, but the RIB Daemon
makes the information the tasks need available.
– IOW, the function of a distributed application is reduced to a local
programming problem.
• Which means . . .
Sched
Mem
Mgt IPC
Local Resource
Management
Tasks
IPC
Management
RIB
Daemon
Resource
Allocation
DAF
Management
Distributed Resource
Management

55. The Pouzin Society
© John Day, 2013
All Rights Reserved
55
The OS is actually
a Distributed Management System
• A traditional OS is a heterogeneous DAF that includes the peripherals.
– The traditional device drivers are members of the DAF.
– In the case of the disk, it might have several members: one, looks like a
file system, one that looks like a database, and one that yields track and
sector access.
USB-DIF WiFi-DIF
OS - DAF
Printer Disk
Laptop
System

56. From There, It is a Short Step to This
• A traditional OS is a heterogeneous DAF that includes the peripherals.
– Wherever they are.
• Somehow this is much different once you look at the picture.
OS - DAF
Printer Disk
Laptop
System

57. Not Just a Network Model
• A Layer is a Distributed Application that Does IPC
• That Forced Us to Answer: What is a Distributed Application?
• We now are working with a Unified Model for
Printer
USB
-DIF
WiFi
-DIF
OS - DAF
Disk
Laptop
Operating Systems
IRM
Distributed
Applications
IRM
Networks
Task
sched
Mem
Mngt
IPC
Tasks
Application Processes

58. What About IoT!?
Major New Requirements!
• Huh? I just showed you. We have been doing IoT for 35 years.
– Worked out the architecture in 1984.
– Network Management is IoT with a Particular Set of Object Models
– For IoT, We just swap in other Object Models and DAFs with DAF-
Application Management.
• (We still have to manage the network. It was just the null case.)
• But New Lower Layer Protocols are needed:
– We have surveyed 20+ IoT data transfer protocols all can be done by
minor changes of policy. (Actually, their similarity was surprising!)
• But Different Application Protocols are needed!
– Different Object Models are needed and consistency across related object
models is needed, but not new application protocols.
– This is a much faster path to product. Changing object models is much
easier than building new protocols.

59. What About IoT?
• But there Will Be 10s of Millions of new Devices on the Net!!
– Yes. So What? Not a big deal. Stop and think.
– Someone is going to install and own those devices. They are not going to make
them widely available on the Public Internet. They are going to be a private
subnet. 100K, 500K devices? Well within the range of what we do now.
– Owners might make some information available, but not the devices.
• New policies, new DIFs, but a different architecture is not necessary.
– Reminder about architecture:
– The Difference between an Architecture and Something Built to that
Architecture, which are you doing?
• All of the hype right now about IoT,
• Serves one purpose and one purpose alone:
• To create barriers to entry to competitors and to lock-in customers.

60. “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. (!!)
• Who cares if it is replaced? 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?

61. © John Day, 2010
All Rights Reserved
10 May 10 61
Transition? No, Adoption
• 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.
• Microsoft tried to prolong the life of DOS. It still haunts them.
• A clean break with the past. The legacy is just too costly.
• We need engineering based on science, not myth and tradition.
Public Internet
Rina Provider
RINA Network
RINAApplications
RINA supported Applications

62. There is Much More,
And Much More to Discover!
• An Invitation: Come explore it with us.
– There is much to explore:
• You probably have a lot of questions. That is because I left out a lot.
• How it applies to different environments, especially wireless.
• 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 ict-pristine.eu
– www.irati.eu or ict-arcfire.eu
Welcome to the RINAissance!

63. Thank You
Questions?