Successfully reported this slideshow.

Vtc keynote201110

0

Share

Upcoming SlideShare
Lost layer talk 2014
Lost layer talk 2014
Loading in …3
×
1 of 63
1 of 63

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Vtc keynote201110

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 31 © John Day, All Rights Reserved, 2009 11/01/06 2: Two Application Communicating in Distinct Systems IPC-Facility Application Processes Systems
  32. 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. 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. 34 © John Day, All Rights Reserved, 2009 11/01/06 Systems 4: Communication with N Systems
  35. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 63. Thank You Questions?

×