RINA Tutorial @ IEEE Globecom 2014

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

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

3. John Day THE LOST LAYER: LESSONS TO BE LEARNED FROM THE PAST T-5 Alternatives to TCP/IP 3

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

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

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

7. The Beads on A String Model phone CO CO phone • The Nature of their early technology led the Phone Companies to Adopt what could be called, a “Beads-on-a-String” architecture. – Deterministic, Hierarchical, master/slave. • Perfectly reasonable for what they had. • The model not only organized the work, – But was also used to define markets: Who got sell what. – This was what was taught in most data comm courses prior to the 1980s. • And for some, in a fundamental sense, never left. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 7

8. 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. T-5 Alternatives to TCP/IP 8

9. But was Packet Switching a Major Breakthrough? • Strange as it may seem, it depends. • During this period many things are age dependent. • If your formative years had occurred prior to the mid-60s (pre-boomer), your model of communication was defined by telephony. – Then this is revolutionary. • If you are younger (boomer), your model is determined by computers. – Data is in buffers, How do you do communications: • Pick up a buffer and send it. – What could be more obvious! • That it was independently invented (and probably more than twice) supports that. • But there was a more radical idea coming! T-5 Alternatives to TCP/IP 9

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

11. 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! T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 11

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

13. A Nasty Brawl Was Shaping Up The Phone Companies Against the Computer Companies and Everyone against IBM T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 13

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

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

16. Meanwhile Back at INWG There Were Two Proposals • INWG 39 based on the early TCP and • INWG 61 based on CYCLADES TS. • And a healthy debate, see Alex McKenzie, “INWG and the Conception of the Internet: An Eyewitness Account” IEEE Annals of the History of Computing, 2011. • Two sticking points – How fragmentation should work – Whether the data flow was an undifferentiated stream or maintained the integrity of the units sent (letter). • These were not major differences compared to the forces bearing down on them. T-5 Alternatives to TCP/IP 16 © John Day, 2014 Rights Reserved

17. After a Hot Debate • A Synthesis was proposed: INWG 96 • There was a vote in 1976, which approved INWG 96. • As Alex says, NPL and CYCLADES immediately said they would convert to INWG 96; EIN said it would deploy only INWG 96. • “But we were all shocked and amazed when Bob Kahn announced that DARPA researchers were too close to completing implementation of the updated INWG 39 protocol to incur the expense of switching to another design. As events proved, Kahn was wrong (or had other motives); the final TCP/IP specification was written in 1980 after at least four revisions.” – Neither was right. The real breakthrough came two years later. • But the differences weren’t the most interesting thing about this event. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 17

18. The SimilarityAmong all 3 Is Much More Interesting • This is before IP was separated from TCP. All 3 of the Proposed Transport Protocols carried addresses. • This means that the Architecture that INWG was working to was: Internetwork Transport Layer Network Layer Data Link Layer TCP IP SNDC SNAC LLC MAC • Three Layers of Different Scope each with Addresses. • If this does not hit you like a ton of bricks, you haven’t been paying attention. • This is NOT the architecture we have. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 18

19. INWG’s Internet Model Internet Gateways Host Host Application Internet Network Data Link Application Internet Network • An Internet Layer addressed Hosts and Internet Gateways. • Several Network Layers of different scope, possibly different technology, addressing hosts on that network and that network’s routers and its gateways. – Inter-domain routing at the Internet Layer; Intra-Domain routing at the Network Layer. • Data Link Layer smallest scope with addresses for the devices (hosts or routers) on segment it connects • The Internet LOST A LAYER!! Data Link Net 1 Net 2 Net 3 T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 19

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

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

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

23. 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!!! T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 23

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

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

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

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

28. Watson’s Results (1978) • Richard Watson proves that the necessary and sufficient conditions for distributed synchronization requires only that 3 timers are bounded: • Maximum Packet Lifetime • Maximum number of Retries • Maximum time before Ack • Develops delta-t to demonstrate the result, which has some unique implications: – Assumes all connections exist all the time. – TCBs are simply caches of state on ones with recent activity • 1981 paper, Watson shows that TCP has all three timers and more. – Matta et al. (2009) shows that delta-t is more robust under harsh conditions than TCP. Boddapati et al. (2012) shows that it is more secure. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 28

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

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

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

32. Congestion Control in an Internet is Clearly a Network Problem Internet Gateways Host Host Application Internet Network Data Link Application Internet Network • With an Internet Architecture, it clearly goes in the Network Layer – Which was what everyone else thought. • Time to Notify can be bounded and with less variance. • Explicit Congestion Detection confines its effects to a specific network and to a specific layer. Data Link Net 1 Net 2 Net 3 T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 32

33. 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 T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved 33

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

35. Wait A Minute! Names the Interface? • Remember Tinker AFB? The answer was obvious. Just like OSs! • Directory provides the mapping between Application-Names and the node addresses of all Applications reachable without an application relay. • Routes are sequences of node addresses used to compute the next hop. • Node to point of attachment mapping for all nearest neighbors to choose path to next hop. (Because there can be multiple paths to the next hop.) • This last mapping and the Directory are the same: – Mapping of a name in the layer above to a name in the layer below of all nearest neighbors. Here And Here Directory Route Path Application Name Node (Logical Address) Point of Attachment (Physical Address) T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

36. Not in the Internet • The Internet only has a Point of Attachment Address, an interface. – Which is named twice! – No wonder there are addressing problems • There are no node addresses or application names. – Domain names are macros for IP addresses – Sockets are Jump points in low memory – URLs name a path to an application Application Socket (local) IP Address MAC Address Application Name Node Address Point of Attachment Address As if your computer worked only with absolute memory addresses. (kinda like DOS, isn’t it?) T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

37. 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. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

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

40. But What About Security? • Security? • Don’t you read the papers?! – It is terrible! And all signs are getting worse. – IPsec makes IP connection-oriented, so much for resiliency to failure. – Everything does their own, so very expensive. • Privacy? Can’t fix it, so same reaction as for QoS – You don’t need it in the brave new world. • They say the Reason is that Never Considered It at the Beginning. – Later we will see how ignoring security can lead to better security. • There have been a lot of “after the fact” attempts to improve it. – With the usual results: greater complexity, overhead, new threats. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

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

43. Want to Feel Really Bad? • A New eBook* James Pelkey’s "Entrepreneurial Capitalism and Innovation: A History of Computer Communications, 1968-1988” paints a different picture: – First companies were developing LAN products • Workstations coming in but SNA is still dominant – Then products to connect LANs together in the workplace. • Novell and others are making inroads. – Then connecting LANs over distances to create corporate networks. • Corporations were concerned about security and wanted their own networks – By the late-80s, corporations wanted their suppliers on their networks. – The next step would have been so many corporate networks wanting their In the Middle of this is dumped free software and a subsidized ISP but with a flawed architecture and a lot of hype: The Internet!! suppliers on them, that it would have been advantageous to have a single network connecting the corporate networks. – Notice this is a natural progression to the INWG Model. • The Meddling of Big Government Caused the Entire Mess – How Do I Know This is What Would Have Happened? – Because It Did. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

45. They Sub-Divided the Network Layer • This concern and the recognition that there would be different networks interworking lead the computer companies to divide the Network Layer into three sublayers, which might be optional depending on configuration: Subnet Independent Convergence (SNIC) Subnet Dependent Convergence (SNDC) Subnet Access (SNAC) T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

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

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

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

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

51. Finally, they just fund their favorite ideas • Named Data Network • XIA • MobilityFirst • ChoiceNet • Nebula T-5 Alternatives to TCP/IP 51 © John Day, 2014 Rights Reserved

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

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

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

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

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

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

58. John Day, Lou Chitkushev INTRODUCTION TO RINA T-5 Alternatives to TCP/IP 58

59. A Quick Review 1: Start with the Basics Two applications communicating in the same system. Application Processes IPC Facility Communication within a Single Processing System Port Ids A B Application Flow This is establishes the API. The Application should not be able to distinguish a slow correspondent from operating over the Network. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

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

62. 4: Communication with N Systems Systems T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

63. A Little Re-organizing IAP A Virtual IPC Facility? Res Finder Alloc So we have a Distributed IPC Facility for each Interface, then to maintain the API we need an application over all of them to manage their use. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

64. 5: Communicating with N Systems (On the Cheap) Dedicated IPC Systems Hosts By dedicating systems to IPC, reduce the number of lines required and even out usage by recognizing that not everyone talks to everyone else the same amount. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

66. The IPC Model (A Purely CS View) User Applications Relaying Appl EFCP EFCP Mux Mux EFCP EFCP EFCP EFCP EFCP EFCP Distributed IPC Facilities T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

67. The Implications • Networking is IPC and only IPC. – We had been concentrating on the differences, rather than the similarities. – Of course, there are layers! What else do you call cooperating shared state that is treated as a black box? A waffle!? • Notice the model never required separate protocols for relaying and error and flow control, i.e. separating TCP and IP. Always do what the model says.* • All layers have the same functions, with different scope and range. – Not all instances of layers may need all functions, but don’t need more. – As we will see, strong layering is better than soft layering. • A Layer is a Distributed Application that performs and manages IPC. – A Distributed IPC Facility (DIF) • This yields a theory and an architecture that scales indefinitely, – i.e. any bounds imposed are not a property of the architecture itself. • But this also begs the question: – If a layer is a Distributed Application that does IPC, then what is a Distributed Application? T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

68. That Wasn’t the Only Question • Well Over a Decade Ago • We Figured Out that Layers Repeated • That Created a Potential Problem: – Dykstra says they don’t! • That lead to discovering that OSs do too T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

70. The Structure of a Process Task sched Tasks Mem Mngt IPC • A Process has a recursive structure consisting of task scheduling, memory management, and inteprocess communication to manage its tasks, which are, in turn, processes. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

71. This Has Implications for DAFs • If a DIF is a set of IPC Processes, – really Distributed IPC Processes (DIPs?) • Then a DAF must be a set of Distributed Application Processes – What else but, DAPs! • What Does a DAP look like? T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

72. Structure of DAP • Local Resource Management is the basic Process structure. – Have to manage local resources. • Then a task for each of these to coordinate with other DAPs in the DAF. Sched Mem Mgt IPC Local Resource Management Tasks IPC Management RIB Daemon Resource Allocation Dist DAF Management Distributed Resource Management T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

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

75. A Single Unified Model that Encompasses Operating Systems, Distributed Applications and Networking Operating Systems Printer Laptop Disk OS - DAF USB-DIF WiFi- DIF Application Process IRM DAPs IRM DIFs Task sched Mem Mngt IPC Tasks T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

76. The Organization of The RINA Reference Model • Part 1: Basic Concepts of Distributed Systems • Part 2: Distributed Applications – Chapter 1: Basic Concepts of Distributed Applications – Chapter 2: Introduction to Distributed Management Systems • Part 3: Distributed InterProcess Communication – Chapter 1: Fundamental Structure – Chapter 2: DIF Operations • New Chapters and Extensions are expected as we learn more. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

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

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

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

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

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

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

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

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

86. Applications, e.g., routing, resource allocation, access control, etc. 86 What a Layer Looks Like IPC Transfer • Processing at 3 timescales, decoupled by either a State Vector or a Resource Information Base – IPC Transfer actually moves the data ( ≈ IP + UDP) – IPC Control (optional) for retransmission (ack) and flow control, etc. – IPC Layer Management for routing, resource allocation, locating applications, access control, monitoring lower layer, etc. • Remember that within a scope if there is a partitioning of functions, it will be orthogonal? Well, here it is. IPC Control IPC Management Delimiting Transfer Relaying/ Muxing PDU Protection Common Application Protocol Application-entities Application Process T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

87. Only Three Kinds of Systems Hosts Interior Routers Border Routers • Middleboxes? We don’t need no stinking middleboxes! • NATs: either no where or everywhere, • NATs only break broken architectures • The Architecture may have more layers, but no box need have more than the usual complement. – Hosts may have more layers, depending on what they do. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

88. All Communication goes through Three Phases • Enrollment – Operations to create sufficient state within the network to allow an instance of communication to be created. • Allocation (also known as Establishment) – Operations required to allocate an instance of communication creating sufficient shared state among instances to support the functions of the data transfer phase. • Data Transfer – Operations to provide the actual transfer of data and functions which support it. • Most of our attention has been on the last two. The first has often been ignored and is usually seen as necessarily ad-hoc. But enrollment turns out to be key. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

89. How Does It Work? Enrollment or Joining a Layer (N-1)-DIF (N)-DIF A • Nothing more than Applications establishing communication (for management) – Authenticating that A is a valid member of the (N)-DIF – Initializing it with the current information on the DIF – Assigning it a synonym to facilitate finding IPC Processes in the DIF, i.e. an address – (see the Enrollment specification for an example.) T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

90. How Does It Work? Establishing Communication A Ahh, look there! B • Simple: do what IPC tells us to do. – A asks IPC to allocate comm resources to B – Determine that B is not local to A use search rules to find B – Keep looking until we find an entry for it. – Then go see if it is really there and whether we have access. – Then tell A the result. – (See Flow Allocator specification) • This has multiple advantages. – We know it is really there. – We can enforce access control – We can return B’s policy and port-id choices – If B has moved, we find out and keep searching T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

91. Routing at Different Layers Hosts Interior Routers Border Routers • With a Recursive Model, there are levels of routing with border routers acting as the step-down function creating interior flows. • This tends toward a “necklace” configuration. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

92. Implications of the Model & Names (Routing Table Size) • Recursion either reduces the number of routes or shortens them. Metros Regionals Backbone T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

93. This Bounds Router Table Size • There will be Natural Subnets within a layer around the Central Hole. • Each can be a routing domain; Each Subnet is one hop across the Hole. – The hole is crossed in the layer below. • A Topological Space is imposed on the Address Space of Each Layer Metros Regionals Backbone (N)-Routing Domains (N-1)-Routing Domains T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

95. Names & Implications of the Model (Basics) Address (N)-IPC-Process Port -id (N-1)-IPC-Process • We have made a big deal of node and point of attachment, but they are relative, not absolutes. – An (N)-IPC-Process is a node in the (N)-DIF. • An (N-1)-IPC-Process is a node in the (N-1)-DIF – An (N-1)-IPC-Process is a point of attachment to an (N)-IPC-Process. – An (N)-address is a synonym for an (N)-IPC-Process. • So as long as we keep that straight, there is no point to making the distinction. • Note that it is the port-id that creates layer independence. With a port-id, No Protocol-Id Field is Necessary, or if there is such a field something is wrong. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

96. Names & Implications of the Model (Multihoming) (N)-IPC-Process Port -id (N-1)-IPC-Process • Yea, so? What is the big deal? – It just works Address • PDU arrives at the (N-1)-IPC Process. If the address designates this IPC Process, the CEP-id is bound to the port-id, so after stripping off (N-1)-PCI, it passes it up. • The process repeats. If the address in the (N)-PCI is this IPC-Process, it looks at the CEP-id and pass it up as appropriate. • Normal operation. Yes, the (N-1)-bindings may fail from time to time. • Not a big deal. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

97. Names & Implications of the Model (Mobility) (N)-IPC-Process Port -id (N-1)-IPC-Process • Yea, so? What is the big deal? Address New Address – It just works just like multihoming only the (N-1)-port-ids come and go a bit more frequently. • O, worried about having to change address if it moves too far? Easy. • Assign a new synonym to it. Put it in the source address field on all outgoing traffic. Stop advertising the old address as a route to this IPC-Process. • Want to renumber the DIF for some reason? Same procedure. • Again, no special cases. No special protocols. No concept of a home router. Okay, policies in the DIF may be a bit different to accommodate faster changing points of attachment, but that is it. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

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

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

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

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

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

104. 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. I A P D i r Mux Flow Mgr – User didn’t have to see all of the wires – But the User shouldn’t have to see all of the “Nets” either. • This not only generalizes but has major implications. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

105. Implications of the Model & Names (A DIF Allocator) • A DIF-Allocator incorporating a Name Space Management function determines via what DIFs applications are available. – If this system is a not member, it either joins the DIF as before – or creates a new one. DIF-Allocator • Which Implies that the largest address space has to be only large enough for the largest e-mall. • Given the structure, 32 or 48 bits is probably more than enough. • You mean? • Right. IPv6 was a waste of time . . . • Twice. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

106. So a Global Address Space is Not Required but Neither is a Global Application Name Space Inter-DIF Directory To Peers In Oher DIFs Actually one could still have distinct names spaces within a DIFs (synonyms) with its own directory database. • Not all names need be in one Global Directory. • Coexisting application name spaces and directory of distributed databases are not only possible, but useful. • Needless to say, a global name space can be useful, but not a requirement imposed by the architecture. • The scope of the name space is defined by the chain of databases that point to each other. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

107. 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. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

108. “Internet” Congestion Control • Congestion Control has been a known issue since 1972. – Except in the Internet who only discovered it when it crashed around their ears in 86 • The effectiveness of any congestion control is directly related to the time to effect a change. – The longer it takes the less effective the congestion control • End-to-end implicit notification is predatory. – Longest response time. Will work against any attempt to do it at a lower level with shorter scope and better response time. • The Internet has network congestion control, – not internet congestion control T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

109. What is the Difference Between Flow Control and Congestion Control? Control Data Flow Control is a feedback mechanism co-located with the resource being controlled. Control Notify Data Data Congestion Control is a feedback mechanism not co-located with the resource being controlled. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

110. How Does It Work? “Congestion Control” • Congestion Control in TCP was always known to be a stop-gap. • A DIF always has the potential for the full capability of functions. • Do flow control (without retransmissions) between intermediate points. – Better congestion control, really flow control – Allocate different resources to different e-malls. – Allows provider much more effective management of resources. – Provides means to throttle flows being used for denial of service attacks – All of these places? Probably not all in the same DIF. Major Area for Research T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

111. 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 T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

112. How Does It Work? The Internet and ISPs • But there does not need to be ONE e-mall. – You mean! • Yes, it is really an INTERnet! Public Internet Facebook Boutique My Net Utility SCADA ISP 1 ISP 2 ISP 3 Internet Rodeo Drive Internet Mall of America T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

113. How Does It Work? The User’s Perspective e-common DIFs e-common DIFs Provider Network Provider Network Local Customer Local Customer Network Network Peering DIF Peering DIF A Customer Network has a border router that makes several e-malls available. A choice can be made whether the entire local network joins, a single host or a single application. In this case, one host on the local network chooses to join one of the available e-malls. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

115. The Recursion Provided Isolation • Security by isolation, (not obscurity) • Hosts can not address any element of the ISP. • No user hacker can compromise ISP assets. • Unless ISP is physically compromised. ISP Hosts and ISPs do not share DIFS. (ISP may have more layers T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

116. How Does It Work? Security • A Hacker in the Public Internet cannot connect to an Application in another DIF without either joining the DIF, or creating a new DIF spanning both. Either requires authentication and access control. – Non-IPC applications that can access two DIFs are a potential security problem. • Certainly promising Public Internet Facebook Boutique My Net Utility SCADA ISP 1 ISP 2 ISP 3 Internet Rodeo Drive Internet Mall of America T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

117. But When It Was Time • The question was not, how to put in security? • The question was, • What does the IPC Model tell us about security? – Remember, our first task is always understanding. • Let the Problem Answer the Question! – Let the Problem Tell Us What to Do. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

119. A Very Unexpected Result • A DIF with no explicit security mechanisms is inherently more secure than the current Internet under the same conditions! • It would appear that – A DIF is a Securable Container. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

120. Other Things Fall Into Place • Data Transfer in RINA is based on Delta-t (Watson, 1980) • Lot has happened in 30 years, many attacks on TCP have been found: – Port scanning – Reset Attacks – SYN attacks – Reassembly Attacks • Long after delta-t was designed, what about delta-t? • Short answer: – None of them work (Boddapati, et al., 2012) • Amazing, totally unexpected – Why not? • Multiple fundamental reasons, but all inherent in the structure: – First, have to join the DIF (all members are authenticated) – Second, No Well-Known Ports • Would have to scan all possible application names! – Third and more importantly, . . . T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

121. Decoupling Port Allocation and Synchronization Port-id Port Allocation Synchronization Connection Endpoint Connection • No Way to Know What CEP-ids are Being Used, Since There is No Relation Between Port-id and CEP-id. – SYN-Ack Attack: must guess which of 2^16 CEP-id. – Data Transfer: must guess CEP-id and seq num within window! – Reassembly attack: Reassembly only done once. – No well-known ports to scan. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

123. RINA is Inherently More Secure and Less Work • A DIF is a Securable Container. (Small, 2011) – What info required to mount an attack, How to get the info – Small does a threat analysis at the architecture level • Implies that Firewalls are Unnecessary, – The DIF is the Firewall! • RINA Security is considerably Less Complex than the Current Internet Security (Small, 2012) – Only do a rough estimate counting protocols and mechanisms. • See paper for details. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

124. Internet RINA To Add Security Protocols 8 0 Non-Security Mechanisms 59 0 Security Mechanisms 28 7 Copyright © 2012, Jeremiah Small. All Rights Reserved. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

125. Why Is Internet Security So Bad? • The Standard Rationale One Sees is that They Didn’t Think About It at the Beginning. – Neither did We. – Nor did Watson. – But RINA and delta-t are more secure. • That Seems to Imply that – Good Design May be More Important to Security than Security Is. T-5 Alternatives to TCP/IP © John Day, 2014 Rights Reserved

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

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

128. Eduard Grasa DEPLOYING RINA IN THE WILD T-5 Alternatives to TCP/IP 128

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

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

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

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

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

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

135. Outline • Examples of RINA Networks – Network Service Provider (Fixed Network) – Network Service Provider (Mobile Network) – Data Center Network • Deploying RINA in the current Internet – Shim DIFs: RINA over X – Under IP – Legacy application support: faux sockets API T-5 Alternatives to TCP/IP 135

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

137. Provider 1 Backbone DIF P2P DIF P2P DIF Metropolitan DIF SubDIF 8 Regional DIF Backbone DIF P2P DIF P2P DIF SubDIF 1 Subnetwork 2 SubDIF 3 P2P DIF P2P DIF Access DIF SubDIF 4 Access DIF Interior Router Service Provider Networks Provider 1 Network T-5 Alternatives to TCP/IP Border Router Interior Router Border Router Interior Router Border Router Interior Router Border Router P2P DIF Border Router Provider 1 Regional DIF P2P DIF P2P DIF Border Router Provider 1 Metropolitan DIF P2P DIF Interior Router SubDIF 1 SubDIF 2 SubDIF 3 SubDIF 4 SubDIF 5 SubDIF 4 SubDIF 7 Access DIF 137

138. Metropolitan DIF Connectivity graph and example policies • Supports different “e-malls” – DIFs designed to support applications. • Organized in subDIF, each subDIF could map to a city. • Topological addressing (<city.IPCP>), link state within a subDIF. • Need to multiplex traffic from potentially very different characteristics: E-mall DIF E-mall DIF need to provide multiple QoS cubes. • Strong security requirements since the DIF is exposed to customer routers MR BR BR IR BR BR ISP BR BR BR IR IR BR IR IR IR MR BR BR BR BR IR BR SubDIF 3 BR SubDIF 1 SubDIF 2 Regional DIF E-mall DIF E-mall DIF E-mall DIF E-mall DIF E-mall DIF E.mall DIF IR = IPCP at Interior Router BR = IPCP at Border Router E-mall DIF T-5 Alternatives to TCP/IP 138

139. Regional DIF Connectivity graph and example policies • Provides connectivity to the different subDIFs of the metropolitan DIF. • Organized in subDIF, each subDIF could map to a region. • Topological addressing (<region.IPCP>), link state within a subDIF. • Traffic more aggregated than in metros, still probably need to provide support for multiple QoS cubes. MR BR BR IR BR BR ISP BR BR BR IR IR BR IR IR IR MR BR BR BR IR MR BR BRBR SubDIF 3 BR SubDIF 1 SubDIF 2 Backbone DIF Metro DIF Metro DIF Metro DIF Metro DIF Metro DIF Metro DIF IR = IPCP at Interior Router BR = IPCP at Border Router T-5 Alternatives to TCP/IP 139

140. Backbone DIF Connectivity graph and example policies • Provides connectivity to the different subDIFs of the regional DIF. • Traffic is aggregated and therefore more deterministic, more connection-oriented like resource allocation policies make sense. • Security policies can be more relaxed: all the infrastructure is in control of the provider and not exposed outside. • Relatively small number of IPCPs: flat addressing and link-state routing may be enough (no subDIFs). • Meshed connectivity graph. Regional IR = IPCP at Interior Router BR = IPCP at Border Router BR BR BR BR BR BR IR IR IR IR IR IR IR Regional DIF Regional DIF Regional DIF Regional DIF Regional DIF DIF T-5 Alternatives to TCP/IP 140

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

143. Radio Access DIF and District DIF Example connectivity graphs Multi-homed host Metro DIF T-5 Alternatives to TCP/IP BR BS H H H BS H Metro DIF Metro DIF Metro DIF BR BS H H H BS H Metro DIF Metro DIF Metro DIF Multi-homed host Metro DIF Metro DIF District DIF 1 District DIF 2 Radio DIF Radio DIF Radio DIF Radio DIF DISTRICT DIF BS = IPCP at Base Station H = IPCP at Host BR = IPCP at Border Router BS H BS H H H H Multi-access DIF 1 (radio) Multi-access DIF 2 (radio) District DIF District DIF District DIF District DIF District DIF District DIF MULTI-ACCESS RADIO DIF BS = IPCP at Base Station H = IPCP at Host 143

144. Metro DIF and Regional DIF Example connectivity graphs E-mall DIF Regional DIF BR Internet DIF REGIONAL DIF Metro DIF Public T-5 Alternatives to TCP/IP METRO DIF H = IPCP at Host BR = IPCP at Border Router BR H H H H H H H H H H Reg. DIF Multi-homed host H H H H H BR H District DIF District DIF District DIF BR H Metro DIF BR H H H HH HH HH H H HH HH H H HH H H HH BR H H H HH H H H HH HH H H HH H H H BR Metro DIF (fixed) H = IPCP at Host BR = IPCP at Border Router 144

145. Mobility, what is needed? • Nothing new! • Enrollment to new DIFs follows usual procedures • Allocation of flows follows usual procedures • Changing address of IPCPs within a DIF as they move through it as described before • New lower layer DIFs (points of attachment) are acquired as usual • Current points of attachment are discarded when they can no longer provide an acceptable QoS (defined per DIF) T-5 Alternatives to TCP/IP 145

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

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

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

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

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

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

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

156. Shim DIFs General requirements • The task of a shim DIF is to put a small as possible veneer over a legacy protocol to allow a RINA DIF to use it unchanged. • The shim DIF should provide no more service or capability than the legacy protocol provides. T-5 Alternatives to TCP/IP 156

157. Shim DIF over 802.1Q Environment • (Disclaimer: Other shim DIFs over Ethernet are possible: with no VLANs; using LLC; over carrier Ethernet; …) • A shim DIF over Ethernet maps to a VLAN – The DIF name is the VLAN name • The shim DIF only supports on class of service: unreliable • ARP can be used to map upper layer IPC Process names to shim DIF addresses (MAC addresses) • Only one application (a normal IPC Process) can be registered at each shim IPC Process – No way to differentiate between multiple flows from the same pair of shim IPC Processes T-5 Alternatives to TCP/IP 157

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

159. Shim DIF over 802.1Q Environment Investigating RINA as an Alternative to TCP/IP 159

160. Shim DIF over TCP/UDP Flow 2 5 UDP Port:2524 UDP Port:2524 • Wraps an IP network with the DIF IPC API • Two QoS cubes possible: reliable and in-order-delivery of flows (TCP), unreliable (UDP) – More could be possible depending on the capabilities of the underlying IP network • IPCP name is mapped to an IP address and a port number – Using proprietary procedures or leveraging DNS (via SRV records) T-5 Alternatives to TCP/IP 160 IPCP a.1 IPCP b.1 Shim DIF over IP networks IP layer Shim IPCP X.1 Shim IPCP Y.1 IP: 4.3.2.1 IP: 5.3.5.8

162. RINA under IP • RINA-based ISP, internal layers are RINA, can transport IP (can be treated as just another app) and/or other DIFs. Shim DIF Shim DIF Backbone DIF • Almost all routing is done in RINA layers. From the IP layer perspective, the ISP is a single hop – Directly connects access routers between them or with border routers T-5 Alternatives to TCP/IP 162 App Customer network Home router Regional DIF ISP access router Shim DIF Shim DIF Regional router Regional-bacbone border router Backbone router ISP border router (runs BGP sessions with peers) Customer network is not RINA enabled Public Internet layer (IP) Data transfer/control: TCP/IP Layer management: ICMP, BGP, etc… Access network layer (e.g Ethernet) AS-to-AS layer (e.g Ethernet) Peer AS is not RINA-enabled

RINA Tutorial @ IEEE Globecom 2014

You are reading a preview.

Check these out next

RINA Tutorial @ IEEE Globecom 2014

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Similar to RINA Tutorial @ IEEE Globecom 2014 (20)

Recently uploaded (20)

RINA Tutorial @ IEEE Globecom 2014