SlideShare a Scribd company logo

10 fn tut1

S
Scott Foster

This document provides an introduction to RINA and discusses problems with the current Internet architecture. It argues that much of what is believed about the Internet is myth rather than reality. The Internet is facing severe problems like poor security, inefficient routing, and lack of mobility and quality of service support. Additionally, the document claims guiding principles for future Internet design are not very helpful. It asserts that networking is fundamentally about inter-process communication and the answer to improving Internet architecture has been clear since the mid-1990s.

1 of 163
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
An Introduction to RINA Or How I Learned to Stop Worrying and Love the Internet FutureNet Tutorial Part I John Day May 2010 Good architecture, like good science, is maximizing the invariances and minimizing the discontinuities. 1 © John Day, 2010 11/01/06 All Rights Reserved
We Got Trouble! Right Here in River City 2 © John Day, 2010 11/01/06 All Rights Reserved
The Internet is Facing Severe Problems: I • Security is essentially non-existent. – Excuse: No one considered it in the early days • Security wasn’t a concern for a military-funded network? – Actual: Systematically weak design (hacker mentality) • Router table size is growing exponentially – Excuse: Memory is cheap – Actual: No longer on Moore’s Law, it is getting expensive and caused by • No support for multihoming – Excuse: not that many hosts need it, and we can kludge it • A military-funded network doesn’t care about suvrivability? – Actual: Since when is 107 small, and the kludge doesn’t scale. • It isn’t 107, with Smart Grid it is more like 1010. 3 © John Day, 2010 11/01/06 All Rights Reserved
The Internet is Facing Severe Problems: II • Mobility is cumbersome and doesn’t scale – Excuse: What do you mean? It works. . . . . Sort of. – Actual: With only physical addresses, hard to do “re-locatable” addressing • Congestion Control keeps Utilization around 30% – Excuse: There is great congestion control in TCP . . . Sort of. Bandwidth is Cheap don’t worry about it. – Actual: Any control theory book says put feedback as close to the resource as possible. TCP puts it as far away as possible. • Quality of Service is difficult to do. – Excuse: Net neutrality requires that all traffic be treated equally – Actual: Net neutrality is political cover for their inability to find solution. • Notice: Running out IP addresses was not listed – Not a problem. A global address space is not required 4 © John Day, 2010 11/01/06 All Rights Reserved
And if that Weren’t Bad Enough Much of What is Believed about the Internet is Myth 5 © John Day, 2010 11/01/06 All Rights Reserved
Myths of the Internet: I • The Internet is an Engine of Innovation. – The Internet has in a real sense been stagnant since the late-70s – Living on Moore’s Law and Band-aids • Lots of Innovation on top of the Internet, but even that has begun to wane. • The Internet has decentralized administration. No one owns the Internet. – Actually, Same as the global PSTN, just no sexy name. • The IETF is a Grass-Roots Democracy. – Actually, It most closely Resembles the Communist Party. • IETF meeting is the Party Congress; IESG is the Politburo – Designed to be dominated by an elite, just not the one they had in mind. • The Internet is based on the ARPANET – Actually, It is based on the French network CYCLADES – The ARPANet technology was abandoned. 6 © John Day, 2010 11/01/06 All Rights Reserved
Myths of the Internet: II • The Internet is not an internet, but a catenet. – Ceased to be an Internet on January 1, 1983. • The Internet is a dumb network. – Actually, it keeps maximal state in the network, not minimal. • The Internet has decentralized routing. – Actually, in most ISPs routes are statically allocated. • IP is the Internet Protocol. – That is what the letters stand for but at best it is a subnet protocol. • More likely just a header fragment • IP addresses name the host. – No, they name an interface to the host. • TCP isn’t perfect, but it is good enough. – Every design decision is not just wrong but makes something else worse. One thing it got right was destroyed creating IP. 7 © John Day, 2010 11/01/06 All Rights Reserved
The Reality is Quite Different • If the Internet were an Operating System, it would have more in common with DOS, than UNIX. • Imagine trying to use a modern computer with only physical memory addresses. • That is the Internet today. 8 © John Day, 2010 11/01/06 All Rights Reserved
Need to Do Something About It • For the Past Decade, DARPA, NSF, and numerous conferences, workshops, and summits have discussed and done research on a “Future InterNet Design.” – So far they have come up dry, nothing, nada. Isn’t groupthink wonderful? • No closer to an answer now than a decade ago. – “Rough consensus and running code” doesn’t exactly foster the kind of thought required to uncover theory. • The field is no longer a science, but a craft. – They have been asking “What to build?” – Not asking, “What don’t we understand?” 9 © John Day, 2010 11/01/06 All Rights Reserved
Guiding “Principles” Aren’t Much Help • Soft State/Hard State – All properly designed protocols are soft state; only some database operations are hard state. A specious distinction • Loc/Id Split – Attempt to avoid the obvious solution. Mostly post IPng trauma. – Continues to route to the wrong place • Fate Sharing – Mostly used as a rug . . . to sweep under. • End-to-End Principle – At best a lemma. More a statement of desire, by focusing attention on the dichotomy of the middle vs the edge, it obscures the point. – Hence becomes an impediment to finding a path forward. 10 © John Day, 2010 11/01/06 All Rights Reserved
The Myths and “Principles” are the Major Barrier to FINDing an Answer • The Answer has been clear since the mid-90s. • And it is very simple: • Networking is IPC and only IPC 11 © John Day, 2010 11/01/06 All Rights Reserved
CYCLADES had Shown the Way Host or End System Application Transport Router Network Data Link Physical An Architecture with Alternating Layers of Relaying and Error Control of Increasing Scope Seemed to Make a Lot of Sense. 12 © John Day, 2010 11/01/06 All Rights Reserved
So We Went With It But As Things Developed Things go more complex Application Application Presentation Session Transport Presentation SNIC Session SNDC Transport SNAC Network LLC MACLink Data Physical Physical And While Better It Wasn’t The Full Answer 13 © John Day, 2010 11/01/06 All Rights Reserved
Meanwhile the Internet Never Got Past Application Or do whatever you want TCP IP Subnet Or do whatever you want We Were Missing Something, but What was It? Were Layers the Wrong Model? 14 © John Day, 2010 11/01/06 All Rights Reserved
Probably Not, Lets Go Back to Basics • Start simple and incrementally introduce new conditions. – Taking Imre Lakatos’ Proofs and Refutations as a model. • We are going to cover ground we all know. – Or at least we think we do. (I thought so) • As we do, think about what is required when – the order is not what you might expect. – But the implications are even more interesting. 15 © John Day, 2010 11/01/06 All Rights Reserved
1: Start with the Basics Two applications communicating in the same system. Application Processes A B Application Flow Port Ids IPC Facility Communication within a Single Processing System 16 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? Application Processes A B Application Flow Port Ids IPC Facility 1) A invokes IPC to create a channel to B; a = Allocate (B, QoS); 2) IPC determines whether it has the resources to honor the request. 3) If so, IPC allocates port-id a and uses “search rules” to find B and determine whether A has access to B. 4) IPC may cause an instance of B to be created. B is notified of the IPC request from A and given a port-id, b. 5) If B responds positively, and IPC notifies A (the API could be blocking in which case the assignment of the port-id, a would be done now). 6) Thru n) Then using system calls A may send PDUs to B by calling Write(a, buf), which B receives by invoking Read(b, read_buffer) 7) When they are done one or both invoke Deallocate with the appropriate parameters 17 © John Day, 2010 11/01/06 All Rights Reserved
2: Two Application Communicating in Distinct Systems Systems Application Processes IPC-Facility 18 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work Now? Application Processes Port Ids IAP IAP 1) A invokes IPC to create a channel to B; a = Allocate (B, QoS); 2) IPC determines whether it has the resources to honor the request. 3) If so, IPC uses “search rules” to find B. and determine if A has access to B. - Management of name space is no longer under the control of a single system. - Each system no longer knows all available applications. – Local Access Control can no longer be relied on to provide adequate authorization and authentication. • Need a protocol to carry application names and access control information. – Lets call it the IPC Access Protocol 19 © John Day, 2010 11/01/06 All Rights Reserved
What Does “IAP” Look Like? • Simple Request/Response Protocol – IAP-Req(Dest-Appl-name, Src-Appl-name, QoS params, Src-Capability) – IAP-Resp(Dest-Appl-name, Src-Appl-name, QoS params, result) Op Dest Appl Name Src Appl Name QoS & Policies Capability • How do we know when to use it? – If the application isn’t here, it must be there! • But we have a problem. How do we get it there? 20 © John Day, 2010 11/01/06 All Rights Reserved
Getting from A to B • We knew this was going to be a problem sooner or later. • We need to be able to send information from A to B. • And we know: – Bad things can happen to messages in transit. Protection against lost or corrupted messages • This can be expensive – Receiver must be able to tell sender, it is going too fast. We need Flow Control, and – We have lost our means of synchronization: • No common test and set means shared memory can no longer be used • Must create shared state between two systems. An explicit synchronization mechanism is required. • We need some kind of Protocol for Error and Flow Control. 21 © John Day, 2010 11/01/06 All Rights Reserved
What Would an EFCP Look Like? • Symmetric Protocol to establish error and flow control • Transfer PDU Op Seq # CRC Data • Ack and Flow Control PDU types Op Seq # CRC Ack Op Seq # CRC Credit 22 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work Now? Application Processes Port Ids IAP IAP Distributed IPC Facility EFCP EFCP 1) A invokes IPC to create a channel to B; a = Allocate (B, QoS); 2) IPC determines whether it has the resources to honor the request. 3) Send IAP Request to access B, creating an EFCP connection and determines if A has access to B. 4) IPC may cause B to be instantiated. B is notified of the IPC request from A and given a port-id, b. 5) If B responds positively, and IPC notifies A with a different port-id, a. 6) Thru n) Then using system calls A may send PDUs to B by calling Write(a, buf), which B receives by invoking Read(b, read_buffer) over the EFCP connection 7) When they are done one or both invoke Deallocate with the appropriate parameters Just Like Before . . . .More or Less 23 © John Day, 2010 11/01/06 All Rights Reserved
Two Applications in Two Systems Required Three New Concepts • An Application Name Space that spans both systems. (not really new) – Should be location-independent in general so that applications can move. • A Protocol to carry Application Names and access control info – Applications need to know with whom they are talking – IPC must know what Application is being requested to be able to find it. • For now, if the requested Application isn’t local, it must in the other system. • A Protocol that provides the IPC Mechanism and does Error and Flow Control. – To maintain shared state about the communication, i.e. synchronization – To detect errors and ensure order – To provide flow control • Resource allocation can be handled for now by either end refusing service. 24 © John Day, 2010 11/01/06 All Rights Reserved
3: Simultaneous Communication Between Two Systems i.e. multiple applications at the same time • To support this we have multiple instances of the EFCP. EFCPEFCP EFCP EFCP EFCP EFCP Will have to add the ability in EFCP to distinguish one flow from another. Typically use the port-ids of the source and destination. Connection-id Dest-port Src-port Op Seq # CRC Data Also include the port-ids in the information sent in IAP to be used in EFCP 25 synchronization (establishment). © John Day, 2010 11/01/06 All Rights Reserved
Simultaneous Communication Between Two Systems i.e. multiple applications at the same time • In addition to multiple instances of the EFCP. EFCP EFCP EFCP EFCP EFCP EFCP Mux Mux Will also need an application to manage multiple users of a single resource. 26 © John Day, 2010 11/01/06 All Rights Reserved
Multiple Instances of IPC • New Concept: a multiplexing application to manage the single resource, the physical media. • The multiplexing application will need to be fast, its functionality should be minimized, i.e. just the scheduling of messages to send. – To provide QoS, we use the EFCP and scheduling by the Mux. • To do resource allocation, we will just let the other side refuse if it can’t satisfy the request. • Application naming gets a bit more complicated than just multiple application-names. – Must allow multiple instances of the same process 27 © John Day, 2010 11/01/06 All Rights Reserved
IPC to Support Simultaneous Communication between Two Systems Distributed IPC-Process IAP EFCP Mux Physical Media 28 © John Day, 2010 11/01/06 All Rights Reserved
4: Communication with N Systems Systems 29 © John Day, 2010 11/01/06 All Rights Reserved
Replication Entails More Management • Separate Multiplexing Application for each physical media interface. • IPC can find the destination by choosing the appropriate interface. • If enough applications, create a Directory to remember what is where, i.e. what application names are at the other end of which interfaces. • Same local names can be used to keep track of which EFCP-instances (port-ids) are bound to which Multiplexing Application. • With many destinations, may need to coordinate resource allocation information within our distributed IPC Facility. 30 © John Day, 2010 11/01/06 All Rights Reserved
With Multiple Interfaces It Gets Messy IAP Dir Coordination with Peer Res Alloc EFCP EFCP EFCP Mux Mux Mux Physical Media • So a task to manage the use of the interfaces and mask any differences. – A little organizing will help. 31 © John Day, 2010 11/01/06 All Rights Reserved
There is Some Common Structure Coordination with Peer Res Alloc IAP Dir EFCP Mux Physical Media • We can organize interface IPC into modules of similar elements. • Each one constitutes a Distributed IPC Facility of its own. – As required, consists of IAP, EFCP, Multiplexing Application, Directory, Per-Interface Resource Allocation • Then we just need an application to manage their use and moderate user requests. 32 © John Day, 2010 11/01/06 All Rights Reserved
A Little Re-organizing A Virtual IPC Facility? IAP Res Alloc Mux Dir So we have a Distributed IPC Facility for each Interface and an application over all of them to manage their use and to give the user a common interface, a Virtual IPC Facility? 33 © John Day, 2010 11/01/06 All Rights Reserved
BUT • This fully connected graph approach isn’t going to scale very well and is going to get very expensive. – And not everyone needs to talk to everyone else all the time. • Need to do something better. 34 © John Day, 2010 11/01/06 All Rights Reserved
5: Communicating with N Systems (On the Cheap) Dedicated IPC Systems Host Systems By dedicating systems to IPC, reduce the number of lines required and even out usage by recognizing that not everyone talks to everyone else the same amount. 35 © John Day, 2010 11/01/06 All Rights Reserved
Communications on the Cheap • We will need systems dedicated relaying and multiplexing. • That requires some new elements: – Globally accepted names for source and destination muxing apps. – And also for the relays. Relays require names for routing. Have to know where you are to determine where to go next. – Need routing applications too, which will need to exchange information on connectivity. • Will need a header on all PDUs to carry the names for relaying and multiplexing. – Interface IPC Facilities will need one too if they are multiple access. Dest Addr Src Addr Common Relaying and Multiplexing Application Header Relaying Routing Application Media-dependent IPC Processes 36 © John Day, 2010 11/01/06 All Rights Reserved
Communications on the Cheap • But relaying systems create problems too. – Can’t avoid momentary congestion from time-to-time. – Annoying bit errors can occur in their memories. • Will have to have an EFCP operating over the relays to ensure required QoS reliability parameters. – Our virtual IPC Facility isn’t very virtual. EFCP EFCP Relaying Relaying Application PM 37 © John Day, 2010 11/01/06 All Rights Reserved
The Big Picture But this is half way between a bead-on-a- string model and a layered model User Applications Application Layer EFCP Transport EFCP Relaying Layer Appl Mux Network Mux Layer EFCP EFCP EFCP EFCP EFCP EFCP Data Link Layer Physical Layer This should look familiar. 38 © John Day, 2010 11/01/06 All Rights Reserved
The IPC Model (A Purely CS View) User Applications Distributed IPC Facilities EFCP EFCP Relaying Appl Mux Mux EFCP EFCP EFCP EFCP EFCP EFCP 39 © John Day, 2010 11/01/06 All Rights Reserved
Summary • “Networking is InterProcess Communication” – . . . . and only IPC. • The quote is Bob Metcalfe, 1972. (The rest is mine.) • A layer is a distributed application that manges IPC consisting of a collection of SDU protection, muxing, EFCP, and their associated routing and resource management tasks. • This is a distributed computing problem, not a “telecom” problem. • And this Distributed IPC Facility repeats. • This constitutes a basis for a general theory of networking. 40 © John Day, 2010 11/01/06 All Rights Reserved
OSI Should Have Seen the Pattern Application Had Shown Itself Even There Presentation The Repeating Structure Session Transport SNIC Network SNDC SNAC LLC Data Link MAC 41 © John Day, 2010 11/01/06 All Rights Reserved
From This We Can Construct What We Need But First We Need a Few Tools • Resolving the Connection vs Connectionless Debate – The center of the 30 Years War • The Nature of Applications and their Protocols. – A Couple of Important Insights • Watson’s Fundamental Results on Synchronization – Probably the most important insight in networking since datagrams • Separating Mechanism and Policy – Pulling out the invariances 42 © John Day, 2010 11/01/06 All Rights Reserved
The Connection Connectionless War • The technical side of what was really an economic war. – The Layered Model invalidated both the PTT and IBM business models. – Connectionless removed the security blanket of determinism. – The war created a bunker mentality that made understanding hard. • All or nothing. • For years, we saw it as the amount of shared state. – Connections had lots of shared state; connectionless very little. • A function of the layer, not a service. Not related to reliability – Not visible over the layer boundary. – Ports must be allocated even for a connectionless flow. • Later it became clear that – As traffic becomes more deterministic, connections are preferred • Down in the layers and in toward the backbone – As traffic becomes more stochastic, connectionless is preferred • As one moves up and toward the periphery 43 © John Day, 2010 11/01/06 All Rights Reserved
Resolving the CO/CL Problem • Lets look at this very carefully • What makes connection-oriented so brittle to failure? • When a failure occurs, no one knows what to do. • Have to go back to the edge to find out how to recover. • What makes connectionless so resilient to failure? • Everyone knows how to route everything! • Just a minute! That means! • Yes, connectionless isn’t minimal state, but maximal state. • The dumb network ain’t so dumb. • Where did we go wrong? • We were focusing on the data transfer and ignoring the rest: 44 © John Day, 2010 11/01/06 All Rights Reserved
We Need to Look at the Whole Thing Routing xfr mngt (A bit like doing a conservation of energy problem and getting the boundaries on the system wrong.) • The amount of state is about the same, although the amount of replication is different. • We have been distributing connectivity information to every Node in a layer, but • We have insisted in distributing resource allocation information only on a need to know basis, i.e. connection-like. • Even if we aren’t too sure who needs to know. • Now we have to work out how to do resource allocation more like how we do routing. (Left as an exercise.) 45 © John Day, 2010 11/01/06 All Rights Reserved
So What Do We Know About CO/CL • It is a function of the layer. Should not be visible to applications. • Connectionless is characterized by the maximal dissemination of state information and dynamic resource allocation. • Connection-oriented mechanisms attempt to limit dissemination of state information and tends toward static resource allocation. • Applications request the allocation of comm resources. • The layer determines what mechanisms and policies to use. • Tends toward CO when traffic density is high and deterministic. • CL when traffic density is low and stochastic. 46 © John Day, 2010 11/01/06 All Rights Reserved
The Upper Layers • After the initial success, this was one of the big unknowns. – Operating Systems had been a good initial guide: • NCP - Interprocess Communication • Telnet - terminal device driver • FTP - the file system • NETRJE - RJE • But what was the general structure? • There was early work that indicated it wasn’t layered. – OSI made a stab at it – By 1983, had realized that there were no upper layers.T • There were common functions. • But the nature of the Application itself was interesting. 47 © John Day, 2010 11/01/06 All Rights Reserved
Applications and Communication: I Is the Application in or out of the IPC environment? • The early ARPANet/Internet didn’t worry too much about it. They didn’t need to. Only one FTP per system, only one remote login per system, etc. • 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. 48 © John Day, 2010 11/01/06 All Rights Reserved
Applications and Communication: II Application Outside the Network Process Inside the Network Application Application Entity Entity • The Application-Entity (AE) is that part of the application concerned with communication, i.e. shared state with its peer. • 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. 49 © John Day, 2010 11/01/06 All Rights Reserved
BUT There is only one application protocol • Huh!? Think about it. What can you do remotely? – 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 to name 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. 50 © John Day, 2010 11/01/06 All Rights Reserved
Delta-t 1980 • Richard Watson develops delta-t, a unique approach. – Assumes all connections exist all the time. – TCBs are simply caches of state on ones with recent activity • Watson proves that the conditions for distributed synchronization are met if and only if 3 timers are bounded: • Maximum Packet Lifetime • Maximum number of Retries • Maximum time before Ack – That no explicit state synchronization, i.e. hard state, is necessary. • SYNs, FINs are unnecessary • IOW, all properly designed data transfer protocols are soft-state. • Including protocols like HDLC • 1981 paper, Watson shows that TCP has all three timers and more. • And PNA figures out that . . . . 51 © John Day, 2010 11/01/06 All Rights Reserved
The Structure of Protocols Tightly-bound Loosely-bound (pipelined) (Policy processing) • 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 – Right, we split TCP in the wrong direction • Noting that syntactic differences are minimal, we can conclude that • There is one data transfer protocol with a small number of encodings. 52 © John Day, 2010 11/01/06 All Rights Reserved
Implications: Protocols I • Data Transfer Protocols modify state internal to the Protocol. Application Protocols modify state external to the protocol. • There are only two protocols (full stop): – A data transfer protocol, based on delta-t – An Application protocol that can perform 6 operations on objects: – 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 using a programming model. The application protocol is the “assembly language” for distributed computing. – As we shall see, we have now made network architecture independent of protocols. 53 © John Day, 2010 11/01/06 All Rights Reserved
Implications: Protocols II • “Hard state” only occurs for some uses of application protocols – Storing in a database may be hard-state. Everything else is soft-state. – Hence the “hard-state/soft-state” distinction at best states the obvious. • Separating mechanism and policy in a delta-t like protocol will yield the entire range from UDP-like to TCP-like. • Watson implies decoupling “port allocation” from synchronization. – Greatly simplifying and improving security, enabling multi-flow allocations of IPC, etc. • And One Other Thing: 54 © John Day, 2010 11/01/06 All Rights Reserved
Fundamental Result • 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. 55 © John Day, 2010 11/01/06 All Rights Reserved
What a Layer Looks Like IPC IPC IPC Management Control Transfer Delimiting Applications, e.g., routing, Transfer resource allocation, Relaying/ Muxing access control, etc. PDU Protection Common Application Protocol Application-entities Application Process • 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. 56 © John Day, 2010 11/01/06 All Rights Reserved 56
What are the Protocols? DTP/DTCP After Delta-t Mgmt applications, e.g. routing, IAP, resource allocation, etc. uses Relaying and the RIB or mgmt protocol for all Multiplexing Task information. Management Adds PCI for Protocol PDU protection • Only two – A data transfer protocol, based on delta-t with mechanism and policy separated. This provides both unreliable and reliable flows. – A management protocol based on CMIP leveraging the constrained form of map/reduce in CMIP. 57 © John Day, 2010 11/01/06 All Rights Reserved
The Application Entities of an IPC Process Flow Allocator (one per IPC Proc) Data Transfer AE (one per flow) IPC Process (Management) RIB Daemon RMT AE CAP AEs (one per IPC Proc) • The Application Process of an IPC Process is management. – Flow Allocator manages flows, finds the destination and does access control, manages the binding of connection-endpoint-ids to port-ids. – Data Transfer AE is the error and flow control protocol – RMT AE consists of the relaying and multiplexing task and SDU Protection – RIB Daemon maintains the local RIB information. – CAP AEs are management flows with other members of the DIF and NMS 58 © John Day, 2010 11/01/06 All Rights Reserved
But Wait a Minute! • If a Layer is a Distributed Application that Does IPC, • What is a Distributed Application? – a Distributed Application Facility (DAF). • Good Question! • What are the elements that would be common to distributed applications that don’t do manage IPC. • Notice that a DIF is primarily a DAF that manages IPC. 59 © John Day, 2010 11/01/06 All Rights Reserved
Distributed Application Facility The Application Object Information Base OIB Daemon Common SDU Protection Application Protocol • A DAF consists of SDU protection, the Common Application Protocol (CMIP + ACSE), an Object Information Base, and the OIB Daemon. • The transition from a DIF to a DAF is a transition from an IPC model to a programming language model. – The task of the OIB Daemon is to populate the OIB with whatever the Application needs on whatever schedule it needs it: a sort of “schema pager” 60 © John Day, 2010 11/01/06 All Rights Reserved
Common Distributed Application Protocol ACSE Authentication CMIP • ACSE is the common protocol for establishing application connections. It ensure that there is a known first exchange. – ACSE was defined to be used recursively and has hooks for. . . • An authentication module is policy of whatever strength required. • CMIP provides the minimal six operations and a basic object-oriented functionality (scope and filter). – Would other programming paradigms lead to different functions? 61 © John Day, 2010 11/01/06 All Rights Reserved
Only Three Kinds of Systems Interior Border Routers Routers Hosts • 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. 62 © John Day, 2010 11/01/06 All Rights Reserved
Hosts Might Have More DIFs Simple App Transaction Mail Appl Processing Application (over a VPN) Local App VPN Traditional Network Transport Layers Note that the VPN could occur one layer lower as well or even lower, “Link”{ Layers but then it would just be a PN. User Applications use whatever layer has sufficient scope to communicate with their apposite. 63 © John Day, 2010 11/01/06 All Rights Reserved
All Communication goes through Three Phases • Enrollment – Operations to create sufficient state within the network to allow an instance of communication to be created. • Allocation (also known as Establishment) – Operations required to allocate an instance of communication creating sufficient shared state among instances to support the functions of the data transfer phase. • Data Transfer – Operations to provide the actual transfer of data and functions which support it. • Most of our attention has been on the last two. The first has often been ignored and is usually seen as necessarily ad-hoc. But enrollment turns out to be key. 64 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? Joining a Layer (N)-DIF A (N-1)-DIF • 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 65 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? Establishing Communication A Ahh, here it is! 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. • 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 66 – If B’s has moved, we find out and keep searching © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? “Congestion Control” • Congestion Control in TCP was always known to be a stop-gap. • A DIF always has the potential for the full capability of functions. • Do flow control (without retransmissions) between intermediate points. – Better congestion control, really flow control – Allocate different resources to different e-malls. – Allows provider much more effective management of resources. – Provides means to throttle flows being used for denial of service attacks – All of these places? Doubtful. Research topic.. 67 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? The Internet and ISPs • ISPs have as many layers as they need to best manage their resources. Metros Regionals Backbone 68 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? The Internet and ISPs • The Internet floats on top of ISPs, a “e-mall.” – One in the seedy part of town, but an “e-mall” – Not the only emall and not one you always have to be connected to. Public Internet ISP 1 ISP 2 ISP 3 69 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? The Internet and ISPs • But there does not need to be ONE e-mall. – You mean! • Yes, it is really an INTERnet! Facebook Boutique My Net Utility SCADA Public Internet Internet Rodeo Drive Internet Mall of America ISP 1 ISP 2 ISP 3 70 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? The User’s Perspective e-common DIFs e-common DIFs Peering DIF Local Customer Peering DIF Local Customer Network Network Provider Network Provider Network 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. 71 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? Security ISP Hosts and ISPs do not share DIFS. (ISP may have more layers • 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. 72 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? Port:=Allocate(Dest-Appl, params) Security Access Control Exercised • The DIF is a securable container. DIF is secured not each component separately. • 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. 73 © John Day, 2010 11/01/06 All Rights Reserved
How Does It Work? Security • A Hacker in the Public Internet cannot connect to an Application in another DIF without either joining the DIF, or creating a new DIF spanning both. Either requires authentication and access control. – Non-IPC applications that can access two DIFs are a potential security problem. Facebook Boutique My Net Utility SCADA Public Internet Internet Rodeo Drive Internet Mall of America ISP 1 ISP 2 ISP 3 74 © John Day, 2010 11/01/06 All Rights Reserved
There More to Come • Next Naming and Addressing – It turns out to be quite straightforward and simple. • Looking at the Internals in a bit more detail – What does DTP and DTCP really look like? – What does the Flow Allocator and the RIB Daemon do? – What goes into defining a DIF? • 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 me wrong! ;-) 75 © John Day, 2010 11/01/06 All Rights Reserved
Things They Never Taught You About Naming and Addressing (FutureNet Tutorial Part II) John Day May 2010 “Did I ever tell you about Mrs. McCave Who had 23 sons and she named them all Dave? Well she did and that was not a very smart thing to do Because now when she calls, “Yoo-hoo, come into the house, Dave!” All 23 of her sons come on the run “And now she wishes that she had named them . . .” <there follows a wonderful list of Dr. Seuss names she wishes she’d named them and then concludes with this excellent advice.> “But she didn’t do it and now it is too late.” - Dr. Seuss Too Many Daves May 5, 10 . 1
Going Back to Fundamentals • Develop the concepts moving from more fundamental to more specific. – Fundamentals of Naming – Naming in Computing Systems – Naming for Communicating Processes – Naming for IPC May 5, 10 . 2
Names and Name Spaces • A name space, NS, is a set {N} of names from which all names for a given collection of objects are taken. A name from a given name space may be bound to one and only one object at a time. • A name is a unique string, N, in some alphabet, A, that unambiguously denotes some object or denotes a statement in some language, L. The statements in L are constructed using the alphabet, A. • A function, MNS, which defines the class of objects, M, that may be named with elements of NS. This is referred to as the scope of the name space (see below). This may refer to actual objects or the potential for objects to be created. • A function, FMNS, that defines the mapping of elements of NS to elements of M. This function is one-to-one and onto and is called a binding. May 5, 10 . 3
Operations on Names • Assignment, allocates a name in a name space, essentially marks it in use. Deassignment, removes it from use. Assignment makes names available to be bound. This allows certain portions of a name space to be “reserved,” not available for binding. • Binding, maps a name to an object. Once bound, any reference to the name accesses the object. Unbinding breaks the binding. Once unbound, any reference will not access any object. – An object ceases to exist when the last name referring to it is unbound. • Saltzer [1977] defines “resolve” as in “resolving a name” as “to locate an object in a particular context, given its name.” – An object cannot be identified without locating it nor located without identifying it. May 5, 10 . 4
Types of Names • Objects may be assigned more than one name. These are called synonyms or aliases. – Objects that may have more than one name, the names are unambiguous. – Objects that must have only one name, the names are unique. • Names may also denote sets of names. Associated with the set is a rule that determines which names are returned when the name of the set is resolved. In networking, – A rule that returned all members has been called multicast. – A rule that returned one member has been called anycast. – We will refer to all forms as whatevercast! • Synonyms or names of sets may be taken from the same or different name spaces. – The name of an object is the name of a set of one element. May 5, 10 . 5
Resolving Names • There are 2.5 means to resolve names: – Exhaustive Search – The name provides hints to narrow the search. • The “half” is indirection: – The name or part of the name points to an object that points to a name. • Hierarchy is the most common form of embedding hints in a name. – Hierarchy imposes a topological structure on the name space, which constrains the names that can be assigned to an object. – There may be search rules for how to utilize the “hints.” • Every thing up to this point is applicable to all naming in computing systems. May 5, 10 . 6
Address Spaces in Operating Systems (From my OS Course) Human use, relatively constant, not at all tied to the hardware, i.e. location-independent Application Name Space Location Dependent but Hardware Independent; Creates a logical address Logical Name Space space larger than the physical memory; Allows processes to be re-locatable. Location-Dependent and Physical Name Space Hardware Dependent An name space is defined as a set of identifiers with a given scope. An address space is a location-dependent name space. In Operating Systems, we have found a need for 3 such independent spaces. Virtually all uses of names in computing are for locating. May 5, 10 . 7
The Root of Internet Addressing Problems 56K Trunk Host Host 56K Trunk 56K Trunk IMP Host Host 56K Trunk A host’s address was its IMP Port Number. It was the common approach at the time. The ARPANet was first. Everyone else afterwards fixed the problem, except the Internet. So What is the Fix? May 5, 10 . 8
OS’s Were the Guide • Shoch [1978] put it eloquently: – Application names indicate what is to accessed – Node addresses indicate where it is – Routes tell you how to get there. • In 1982, Jerry Saltzer published the “other” major paper on addressing. – Wrote down the OS view of network addressing: • Saltzer, Jerry. “On the Naming and Binding of Network Destinations” in Local Computer Networks, edited by P. Ravasio et al. P North-Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498. – Application names that were location independent – Node addresses that were location dependent (the logical address) – Point of attachment addresses that were route-dependent (the physical address) – Routes which were actually a sequence of point of attachment addresses – And the three mappings between them. • Saltzer works through the problem in somewhat more detail. – Colored by the hardware of the time and the OS perspective. May 5, 10 . 9
Modeling Saltzer • A Logical Model of a Network System – Naming the binding between a (N)- and (N-1)-PM is equivalent to naming the (N-1)-PM. Need to do one or the other. • Saltzer seems to favor naming PMs. – Since ultimately we must name the application and we know it isn’t a binding, naming PMs makes sense. System Layer Application Name Node Address Point of Attachment Address May 5, 10 . 10
Saltzer’s View of Networks • Application names map to node addresses. • Node addresses map to points of attachment addresses. • Routes are sequences of points of attachments. – Just as in an operating system. – But networks are more general than operating systems. Application Name Node Address Point of Attachment Address May 5, 10 . 11
But Saltzer Missed a Case • There can be More than One path to the Next Hop. – This case does not occur in computing systems. There is only one path from the CPU to memory. • Must route on the Node addresses, not the point of attachments Application Name Node Address Point of Attachment Address May 5, 10 . 12
Generalizing Saltzer to Networks of Networks • Directory maintains 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. (Saltzer missed this because they hadn’t occurred yet.) • 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. Directory Route Path May 5, 10 . 13
The Real World is More Diverse (for better or worse, OSI understood that) Subnet Independent Subnet Dependent Subnet-Access • Two distinct cases: there may be a wire or another network. – If the former, then it is a simple Data Link Layer; otherwise – Subnetwork Access, Point of Attachment (interface) addresses (X.25, IP). • X.25 not data link, because it used HDLC (LAPB) which was. – Subnet dependent convergence - if the network needed more error control – Subnet Independent (node) addresses at the top of the Network Layer (CLNP) » (Another indicator of a repeating pattern) • If there is routing in the underlying network, it is that network’s issue. • Traditional concept of layering caused problems: don’t repeat functions. May 5, 10 . 14
To Recap Mappings between Name Spaces • Mapping between application names and node addresses: Directory. – Allows for applications moving to different systems or systems moving. • Sequence of node addresses: Routes. – Node address space is a logical abstraction of point of attachment address spaces. • Node address space must be de-coupled from the point of attachment address space(s). • Any form that concatenates a local (N)-layer identifier to an (N-1)-address to create an (N)-address will make the node address space route dependent. – From this we determine the next hop. • Mapping of node addresses to point of attachment addresses: Path. – A node needs this mapping for itself and all nearest neighbors. – Point of attachment addresses distinguish multiple paths to the next node (hop). – Note that this is the same as the Directory. • And it repeats: Node and Point of Attachment are relative, not absolutes. May 5, 10 . 15
The Fundamental Flaw in the IP Architecture • Given what we have seen already we can see the mistake, – By following Saltzer and routing on the interface, the Internet architecture assumes there is a point-to-point line under IP. • An Internet Protocol should have networks under it. • A Network is a “wire with multiple ends”, i.e. requires addresses. – Points of attachment – Where are these in the architecture? • By routing on the interface, – IP is a Network Protocol not an Internet Protocol – After IPng’s refusal to name the node, there has been a search for a workaround. There is none. Loc/id split is simply the last attempt. It is in a very real sense post-IPng trauma. May 5, 10 . 16
Applying Results to Real Architectures: The Internet (This is a Network Architecture) • The most striking feature is that half of the addressing architecture is missing. – No wonder there are addressing problems. – The only identifier we have for anything is the IP address. • There are no node addresses and no application names. – And the point of attachment is named twice! – If this is an Internet Protocol, where are the Network Addresses? – Domain Names are synonyms for IP addresses. URLs are pathnames through the stack and location dependent. Application Application Name Socket (local) Node Address IP Address Point of Attachment MAC Address Address May 5, 10 As if your computer worked only. with absolute memory addresses. 17
What Does RINA Tell Us? • If networking is a distributed application that does IPC, we should start there. May 5, 10 . 18
Communicating Processes • Application Processes exist to do work. They communicate to do that work. Communicating is not (usually) their primary raison d’etre. • So how do applications relate to communication? – Communicating applications share state on some things. – They can’t be unaware of communicating. – So what is the nature of the relation between the communication mechanism and the application process? • Now we need the Application Process/Application Entity distinction May 5, 10 . 19
Applications and Communication Application Process Application-Entities • The Application-Entity (AE) is that part of the application concerned with communication, i.e. shared state with its peer. • 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. – An HTTP library linked into a web browser is an AE; FTP is another. May 5, 10 . 20
Application Naming Application Process Application-Entities • Application-process names (APN) are globally unambiguous and location-independent, but system-dependent. – They may have synonyms of less scope from the same or different name space. – There may be multiple instances of the process in the same system. • APN-instance-identifiers are unambiguous within the scope of the Application Process. • Application-entity-identifiers are unambiguous within the application process. – There may be more than one Application-entity (AE) in a process. • Unambiguous within the scope of the Application Process. – There may be more than one instance of each type of Application-Entity. • AE-instance-identifiers are unambiguous within the scope of the AE. • Distributed Application Name is the name of a set of application processes and system- independent. • Few applications need all of these but a complete theory requires all of them. May 5, 10 . 21
What Good is All This? Application Process Application-Entities • Many capabilities not possible today or that require specific protocols are a consequence of naming and enabled by a complete architecture. – Handing off a connection from one system to another; – The need to pass IP addresses among applications is avoided; – Opening multiple connections with different “protocols” to the same instance of an application process. – Connecting to an existing “conference” call, etc. May 5, 10 . 22
What about IPC? • The IPC Model says that an IPC Process is simply an application process dedicated to doing IPC. What does this tell us about that? – There are three kinds of Application Entities: • A Flow Allocator AE to manage the creation of flows, • A Data Transfer AE to instantiate a flow, and • RIB Daemon AE to maintain shared state among the IPC Processes • Managing IPC with the (N-1)-DIF/layer May 5, 10 . 23
What is the “Application” of an IPC Process? • What is the main work of an IPC Process? Management! – Not, Data transfer. • Managing the IPC within the Layer. – Resource Allocation – Maintaining a Resource Information Base – Routing – Security Management Allocation Mngmt Data Transfer Relaying/Muxing Update PDU Protection Daemon May 5, 10 . 24
What about IPC Naming? • An IPC Process has an Application Process Name, give it a synonym of scope limited to the layer, and if structured to facilitate forwarding. • Commonly called an address • There are three local identifiers: – A Flow Allocator AE Instance Identifier, • Commonly called a port-id – A Data Transfer AE Instance Identifier, and • Commonly called a connection-endpoint-identifier – RIB Daemon AE to maintain shared state among the IPC Processes • Traditionally routing update. • This coupled with delta-t has major implications (later). bindings Address Port-ids CEP-ids Flows May 5, 10 . 25
Names for IPC Port-ids Address IPC Process CEP-ids • An Address is a synonym for the IPC Process, with scope restricted to the layer and structured to facilitate forwarding within the layer/DIF. – A port-id is the handle returned to the calling application to refer to this instance of communication, unique within its AE. – A connection-endpoint-id (CEP-id) identifies the shared state of one end of a flow/connection, unique within its AE. • A connection-id identifies flows between the same two IPC Processes, formed by concatenating CEP-ids, unique within the pair • Distributed Application Name is globally unambiguous name for the set of all Application Processes in a Distributed Application, e.g. DIF. May 5, 10 . 26
To Summarize Common Term Scope Application Term Application Process Name “Global” (unambiguous) Application Process Name Address Layer (unambiguous) Synonym for IPC Process’ Application Process Name Port-id Allocation AE (unique) Allocation AE-Instance- Identifier Connection-endpoint-identifier Data Transfer AE (unique) Data Transfer AE Instance- Identifier Connection-id Src/Dest Data Transfer AE Concatentation of data-transfer- (unique) AE-instance-identifiers DIF Management Updates IPC Process (unambiguous) AE-identifier • All identifiers except address and connection-id are local to the IPC Process. – Scope of the address is the Layer. – Scope of the connection-id is the participants in the connection. • None has more scope than it needs. May 5, 10 . 27
Principles of Naming and Addressing: I • Application names indicate what, not where. – Hence, names are organized to put similar “whats” near each other. – So what “whats” do we use? • There is no single answer. Depends on the purpose and the importance of look up performance generally in a distributed directory. – The Scope of an Application Name Space is defined by the chain of databases pointed to by the Directory Forwarding Table. • Different Application Name Spaces may name the same objects. – It is here that the concepts of query and name merge • Some schemes will produce multiple results; some a unique result • Given the move to greater granularity more schemes will be useful in keeping them tractable and useful. – The only requirement for IPC is that some collection of synonyms be associated with an application process and their mapping to the directory are made known. May 5, 10 . 28
Principles of Naming and Addressing: II • Addresses indicate where – Not quite – Within a DIF, the “what” of interest is “forwarding.” Synonyms are assigned to facilitate forwarding, call it a forwarding-id or f-id. – If the DIF has a sufficiently large number of members (or maybe if it doesn’t) to make F-ids more useful. • They are structured to reflect which elements are near each other for some concept of near. This is an address. • This is an “address” in the sense of its normal usage, expressing “where” without indicating “how to get there.” – An address is an synonym for an IPC Process whose scope is the DIF and structured to be useful within the layer. – “where” is just one kind of “what” – Application Names and Addresses are simply two different means for locating an object in different contexts. In this case, the object is an IPC Process. May 5, 10 . 29
Principles of Naming and Addressing: III • A F-id (or address) is only unambiguous within the scope of a layer. – And no more, otherwise this leads to overloading the semantics of the address and leads to problems – MAC addresses are 3 times longer than they need to be. • Routes are sequences of (node) addresses. – Source routing is a “male thing,” not willing to stop and ask directions. • The relation of node and point of attachment is relative and hence irrelevant. • A node address is an (N)-F-id; • A point of attachment address is an (N-1)-F-id. – A layer routes on its address. A node address routes this layer’s address, the point of attachment address is the address of the node in the layer below and is routed by the layer below, not by this layer. May 5, 10 . 30
Principles of Naming and Addressing: IV • Since the address is structured to facilitate its use within the layer, it must be assigned by the layer. – Only the layer knows how to make the synonym useful. • Any addresses assigned by anyone else are not addresses. • Names of systems are useful management functions, but not for forwarding. – Names of Hosts are distinct and not related to addressing. • An address should not be constructed by concatenating an identifier in this layer with one from the lower layer, i.e. don’t embed MAC addresses in IP addresses. – Why? This construction is called a pathname, hence it is route-dependent! – Addresses in adjacent layers should be completely independent. – Hierarchical address assignment within a layer organizes addresses in this layer, not the layer below. – Each layer is a level of indirection. May 5, 10 . 31
Implications of the Naming Model: I • Recursion either reduces the number of routes or shortens them. Metros Regionals Backbone May 5, 10 . 32
Implications of the Naming Model: III The Complexity of Routing Non-topological T opological Metros-DIF 3 O ( ( 2 D n)2 ) O ( ( D m)2 ) where n is the number of hosts and m is the number of hosts and border routers on a single subnet. Regionals-DIF 2 O((2Dn2)2 ) 2 O ( ( D m2) ) where n2 is the number of border routers around the outside and m2 is number of border routers at this level on a single subnet. Backbone-DIF 1 O((2Dn1)2 ) 2 O ( ( 2 D n1) ) where n1 is the number of border routers on the backbone. Note that m << n. • For the Internet O((6r)2 where r is the number of routers in the network. May 5, 10 . 33
Naming Implications of the Model: II Application An Internet Provider Independent Provider dependent • Multihoming is a consequence of the structure. – Simply a layer having more than one (N-1) binding. • Since we are routing in this layer, there is no big deal – By routing on the address, the destination address is the destination regardless of which interface the PDU arrived on. It is route-independent. – With recursion, no scaling problems, no LISP, no LISP support protocols. May 5, 10 . 34
Naming Implications of the Model: III Application An Internet Provider Independent Provider dependent • Mobility is a consequence of multihoming. – Merely acquiring new (N-1)-addresses to use or losing others. • No different than so-called “static” case, just more frequent. – (N)-address may change either by joining a different DIF • Joining another DIF is simply acquiring another point of attachment, another potential path. – or if its topological significance changes. • Assigning a new address is simply creating adding an additional synonum. Protocol processing is unaffected by the changes. May 5, 10 . 35
Naming Implications of the Model: IV Application An Internet Provider Independent Provider dependent • How to Change the Address of a member of the DIF: – Assign the IPC Process a new synonym from the address space; – Senders use the new (N)-address as source in all active flows – Receivers record the source address of all incoming PDUs as the current address. – Advertise routes to the new address, begin to deprecate the old address – After a few routing updates, the old address simply disappears. • Changing addresses is just another name to route to. That two go to the same place is mere coincidence. • PDU Processing is unaffected by the change. May 5, 10 . 36
Implications of the Model: V Choosing a Layer • In building the IPC Model, the first time we had multiple DIFs (data link layers in that case to choose from), we found we needed a task to figure out which DIF to use. Flow I MuxMgr D A i P r – 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. May 5, 10 . 37
An Inter-Net Directory? • Inter-DIF Manager 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. Inter-DIF Mngr • 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. May 5, 10 . 38
So a Global Address Space is Not Required but Neither is a Global Application Name Space Inter-DIF To Peers Directory 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. May 5, 10 . 39
Multicast and Anycast are Simpler Too • Generalized to Whatevercast: – A set and a rule that returns as many members of the set that satisfy the rule. • Unicast becomes a degenerate case of whatevercast. – Forwarding table entry maps Destination Address to a list of next hops. For unicast, the list has one element. • Primarily handled by hosts or border routers, where all whatevercast traffic is either: • On this subnet (only do spanning tree within subnet if there is a lot) or • Transit to another subnet, (both cases degenerate to point-to-point). • So we see Whatevercast devolves into Unicast. May 5, 10 . 40
Multicast and Anycast are Simpler Too • Information in topological addresses imply an approximate spanning tree, which can be used to identify the border routers. Thjus, in most cases obviating the need for a separate spanning tree (multicast) routing algorithm. • And also making it straightforward to multiplex whatevercasts with common sub-trees which will allow even greater efficiency. – Note that the common sub-trees do not have to be strict sub-trees but simply have a reasonable degree of commonality to be worthwhile. May 5, 10 . 41
Next: Digging into the Details! How Does it Really Work? May 5, 10 . 42
The Nuts and Bolts of RINA FutureNet Tutorial Part III John Day May 2010 10 May 10 © John Day, 2010 1 All Rights Reserved
The Elements of an IPC Process Flow Allocator Delimiting Data Transfer Control Data Transfer Resource Protocol Allocator Authentication Security Module Management RIB Forwarding Table Daemon Generator (routing) SDU Relaying Protection and Multiplexing • Lets Look at Each Group of Elements in Turn – The Common Distributed Application Protocol – IPC Modules – IPC Management 10 May 10 © John Day, 2010 2 All Rights Reserved
Common Distributed Application Protocol Authentication Module • The only application protocol that is required – DAFs may use others for backward compatibility – Used in DIFs for all non-data transfer communication • Three components: – Application Connection Establishment – Authentication (policy) – CMIP-like operations • Distinct flows allow operations on specific sets of objects 10 May 10 © John Day, 2010 3 All Rights Reserved
CDAP: Application Connection Establishment ACRQ ACRsp • Request/Response that carries: – Source and Destination Application-Process names and Application-Entity-identifiers (including instances) as necessary. – Application-context definition (object set available) – Syntax negotiation 10 May 10 © John Day, 2010 4 All Rights Reserved
CDAP • Why CMIP? It’s a management protocol. – Not really, it is a distributed object-oriented intermediate language – That does create/delete, read/write (get/put), action (start/stop) – With OO-support in Scope and Filter: • Scope selects the base object alone, the nth level of the base object, the base object and all its subordinates to and including the nth level, or the base object and all its subordinates. – This can be quite powerful in minimizing traffic. • Filter is an expression of assertions grouped using AND, OR, and NOT to determine equality, ordering, presence, or set comparison. – Extensions to scope and filter should be considered. • CMIP does everything required and nothing more. 10 May 10 © John Day, 2010 5 All Rights Reserved
Why Not SNMP? • Too complex. – Implementation is larger than CMIP. • Not object-oriented, no leverage. • Too many restrictions that contribute to complexity. – Can’t retrieve entire tables – Can’t modify multiple attributes in a single operation. – Can’t, Can’t, Can’t. – It was a good protocol for the mid-80s, but was obsolete by the time it was proposed. 10 May 10 © John Day, 2010 6 All Rights Reserved
The Use of CDAP • There are three primary uses of CDAP in a DIF: – Joining a DIF • Establishing a management connection between an new IPC Process and the members of the DIF, authenticating it, initializing it, and assigning it a forwarding-id. – Maintaining the Resource Information Base • The RIB Daemon (see below) – Flow Allocation (see below) – Everything but IPC – the actual data flow – itself 10 May 10 © John Day, 2010 7 All Rights Reserved
The IPC Modules Data Delimiting Transfer Control Data Transfer Protocol Relaying and Multiplexing SDU Protection • There are Five Modules: – Delimiting – The Error and Flow Control Protocol consisting of: • Data Transfer (Sequencing/Fragmentation) • Data Transfer Control (Flow control and rexmsn control) – Relaying and Multiplexing – SDU Protection 10 May 10 © John Day, 2010 8 All Rights Reserved
Delimiting • This Module delimits SDUs to ensure that the service maintains the identity on delivery. – IPC may fragment or combine SDUs but will deliver same SDUs to the destination. • External and Internal Delimiting are possible. • This module is entirely policy. – For a flow that appears to be streaming, the entire flow is a single SDU and early delivery is allowed. 10 May 10 © John Day, 2010 9 All Rights Reserved
SDU Protection • SDU Protection is also entirely policy and may include: – Data Corruption Protection (CRCs or FECs) – Time to Live – Integrity and Confidentiality (encryption) • Below we will explore why the heavy duty mechanisms of IPsec like solutions are not required. – Compression - not really protection but this is the right place for it 10 May 10 © John Day, 2010 10 All Rights Reserved
The Error and Flow Control Protocol Data Transfer Data Transfer Control Protocol • Based on delta-t with mechanism and policy separated. – Naturally cleaves into Data Transfer and Data Transfer Control • Data Transfer consists of tightly bound mechanisms – Roughly similar to IP+UDP • Data Transfer Control, if present, consists of loosely bound mechanisms. – Flow control and retransmission (ack) control • One instance per flow; policies driven by the QoS parameters. • Comes in several syntactic flavors based on the length of (address, connection-endpoint-id and sequence number) • Addresses: 8, 16, 32, 64, 128, variable. • CEP-id: 8, 16, 32, 64 • Sequence: 4, 8, 16, 32, 64 10 May 10 © John Day, 2010 11 All Rights Reserved
Data Transfer InboundQ Delimit SDU Fragment/ Concatenate Reassmb/SeqQ Sequencing/ Strip Delimiting Sequence/ Reassembly/ Address Separation CRC ClsdWinQ RexmsnQ DTCP PDUs RMT CRC • The main path is simple, straightforward and potentially very fast (see specifications for details). 10 May 10 © John Day, 2010 12 All Rights Reserved
Data Transfer PDU • Version: 8 Bit • Destination-Address: Addr-Length • Source-Address: Addr-Length • Flow-id: Struct – QoS-id: 8 Bit – Destination-CEP-id: Port-id-Length – Source-CEP-id: Port-id-length • PDUType: 8 bits • Flags: 8 bits • PDU-Length: LengthLength • SequenceNumber: SequenceNumberlength • Sequence User-Data{DelimitedSDU* | SDUFrag} 10 May 10 © John Day, 2010 13 All Rights Reserved
Data Transfer Policies and Parameters • UnknownFlowPolicy – When a PDU arrives for a Data Transfer Flow terminating in this IPC-Process and there is no active DTSV, this policy consults the ResourceAllocator to determine what to do. • SDUReassemblyTimer Policy – this policy is used when fragments of an SDU are being reassembled and all of the fragments to complete the SDU have not arrived. Typical behavior would be to discard all PDUs associated with the SDU being reassembled. • SDUGapTimer Policy – this policy is used when the SDUGapTimer expires and PDUs have not been received to a sequence of SDUs with no gaps greater than MaxGapAllowed. Typically, the action would be to signal an error or abort the flow. • ClsdWindPolicy - This policy determines what to do if the PDU should not be passed to the RMT. • MaxPDUSize – The maximum size in bytes of a PDU in this DIF. • MaxFlowPDUSize – The maximum size in bytes of a PDU on this Flow. • SeqRollOverThres – The value at which a new flow is created and assigned to this Port-id to support data integrity. • MaxGapAllowed – The maximum gap in SDUs that can be delivered to the (N)-DIF- port without compromising the requested QoS. 10 May 10 © John Day, 2010 14 All Rights Reserved
Data Transfer Control DT-SV DTCP Rexmsn Xmsn Ctl Ctl DTP Flow Ctl Re-xmsn Q Xmsn Control Q RMT Data Flow Control Flow • Control stays out of the main data flow. • This module will not exist for flows that don’t need it. 10 May 10 © John Day, 2010 15 All Rights Reserved
Data Transfer Common Control Syntax Common Control PDU Selective Ack PDU Version: 8 Bits Common Control PDU Destination-Address: Addr-Length Source-Address: Addr-Length PDU TYPE = X’8004’ Flow-id: Struct Ack/Nack: Integer(SeqNbrLength) QoS-id: 8 bits Ack/Nack List Length: Integer(8) Destination-CEP-id: CEP-id-Length Ack/Nack List: Sequence(StartingNbr Integer Source-CEP-id: CEP-id-length (SeqNbrLength), Ending Integer(SeqNbrLength)) PDUType: 8 bits Flags: 8 bits PDU-Length: LengthLength Forced NackPDU SequenceNumber: SequenceNumberLength Common Control PDU PDU TYPE = X’8006’ Ack/Flow ControlPDU Ack/Nack: Integer(SeqNbrLength) Common Control PDU Ack/Nack List Length: Integer(8) PDU TYPE = X’800C’ Ack only Ack/Nack List: Sequence(StartingNbr PDU TYPE = X’800D’ Ack and Flow Control Integer(SeqNbrLength), PDU TYPE = X’8009’ Flow Control only Ending Integer(SeqNbrLength)) Ack: Integer(SeqNbrLength) RightWindowEdge:SequenceNbrLength NewRate: RateLen TimeUnit: TimeLen 10 May 10 © John Day, 2010 16 All Rights Reserved
Data Transfer Control General Parameters and Policies • TA – Maximum time an ack is delayed before sending • TG – Maximum time to exhaust retries. • TimeUnit – for rate based flow control, i.e. # of PDUs sent per TimeUnit • FlowInitPolicy – Data Transfer Control initialization policy • SVUpdatePolicy – Updates the State Vector on arrival of a TransferPDU • LostControlPDUPolicy – What to do if a Control PDU is lost? 10 May 10 © John Day, 2010 17 All Rights Reserved
Data Transfer Control Retransmision Policy • RTTEstimator Policy – the algorithm for estimating RTT • RetransmissionTimerExpiryPolicy - what to do when a Retransmission Timer Expires, if the action is not retransmit all PDUs with sequence numbers less than this. • ReceiverRetransmission Policy - This policy is executed by the receiver to determine when to positively or negatively ack PDUs. • SenderAck Policy - provides some discretion on when PDUs may be deleted from the ReTransmissionQ. This is useful for multicast and similar situations where one might want to delay discarding PDUs from the retransmission queue. • SenderAckList Policy - similar to the previous one for selective ack 10 May 10 © John Day, 2010 18 All Rights Reserved
Data Transfer Control Flow Control Policies • InitialCredit Policy - sets the initial amount of credit on the flow. • InitialRate Policy - sets the intial sending rate to be allowed on the flow. • ReceivingFlowControlPolicy - on receipt of a Transfer PDU can update the flow control allocations. • UpdateCredit Policy – determines how to update the Credit field, i.e. whether the value is absolute or relative to the sequence number. • FlowControlOverrun Policy - what action to take if the credit or rate has been exceeded. • ReconcileFlowConflict Policy - when both Credit and Rate based flow control are in use and they disagree on whether the PM can send or receive data. 10 May 10 © John Day, 2010 19 All Rights Reserved
Relaying and Multiplexing Task PDUs from EFCP & (N-1)- DIF flows Forwarding Table Queues Ports (N-1)-DIF A (N-1)-DIF B • Queues at the top are at least one per QoS Class. • Queues at the bottom are created by the Resource Allocator and may be related to the number of QoS Classes provided by the lower DIF. 10 May 10 © John Day, 2010 20 All Rights Reserved
RMT Policies • RMTQMonitorPolicy – Policy for monitoring the status of the RMT and the QoS being provided by the (N-1)-DIF from data available to the RMT. • RMTSchedulingPolicy – Policy determines what flows are mapped to what RMT queues and how the queues are serviced. • MaxQPolicy – Policy invoked if a queue reaches its limit. 10 May 10 © John Day, 2010 21 All Rights Reserved
Flow Allocator Allocate(Dest-Appl-Name, QoS parameters) Flow Allocator Dir Local Forwarding Dir Cache Table • When Application Process generates an Allocate request, the Flow Allocator creates a flow allocator instance to manage each new flow. • The Instance is responsible for managing the flow and deallocating the ports – DTP/DTCP instances are deleted automatically after 2MPL with no traffic, • When it is given an Allocate Request it does the following: 10 May 10 © John Day, 2010 22 All Rights Reserved
Flow Allocator Input: Allocate Request 1) It inspects the Allocate request and maps the parameters to the appropriate QoS Class and the associated policy set. 2) It instantiates a DTP (and DTCP if necessary) for this flow. 3) Checks its local directory cache for the destination application name. If found, it sends a Create Flow request to destination address; otherwise consults the Dir Forwarding Table and sends the Create Flow request to the address noted there. 4) When it receives an Create Flow Response it executes an Allocate Response API call and modifies the state of the DTP as necessary. 10 May 10 © John Day, 2010 23 All Rights Reserved
Flow Allocator Input: Create Flow Request • Inspect local Directory Cache for an entry that indicates where to forward the request. – Each look up hopefully gets it closer to its destination. – The directory forwarding table can create a hierarchy of databases. • When the lookup finds that the application is here, create a new flow allocator instance to manage this end of the flow, do access control, initiate the application if necessary, and give it the Allocate indication. • When the Application responds, if positive, create the local DTP/DTCP instances, allocate local ports: if negative discard the flow allocator instance; Regardless send the create flow response to the source address with the appropriate outcome. 10 May 10 © John Day, 2010 24 All Rights Reserved
Flow Allocator Subtleties Allocate(Dest-Appl-Name, QoS parameters) Flow Allocator Dir Forwarding Table • Separating port allocation from synchronization eliminates well- known ports, and several SYN hijacking attacks. – Using Delta-t is inherently more secure the TCP • The Create Flow allows for a list of connection-endpoint-ids that can be used either in parallel or serially. – In parallel, might be used for things like p2p [sic] do. – Used serially, avoids the need for a separate security connection as in IPsec. 10 May 10 © John Day, 2010 25 All Rights Reserved
Requests are mapped to QoS Cubes • Systems are not sufficiently sensitive to be able to deliver precise QoS values. The best that can be done is a range. Parameters identified are: Average Bandwidth Undetected bit error rate Average SDU bandwidth Partial Delivery Peak bandwidth-duration Order Peak SDU bandwidth-duration Max allowable gap in Burst period SDUs Burst duration Delay Jitter 10 May 10 © John Day, 2010 26 All Rights Reserved
Protocols are Irrelevant QoS Cubes Allocation AE Delimiting Data Transfer Control Data Transfer Resource Protocol Allocator Authentication Security Module Management CMIP ACSE RIB Forwarding Table Daemon Generator (routing) SDU Relaying Protection and Multiplexing • Notice that we are defining policy sets driven by QoS classes and objects for management that configure a DIF. • Protocol becomes non-issue. 10 May 10 © John Day, 2010 27 All Rights Reserved
So How Does a Flow Get Allocated? Allocate(Dest-Appl-Name, QoS parameters) To Next Place to Flow Look Create Flow Req Allocator FA-AEI Dir Forwarding Table • An Application issues an Allocate Request to the Flow Allocator. • If well-formed, spawns an instance to manage the request and the flow. • The Flow-Allocator instance looks up the destination-application-name in its local cache and finds an address to look for the requested application. • It then instantiates an EFCP instance (whose id is the CEP-id). • Forms a Create flow request and sends it. 10 May 10 © John Day, 2010 28 All Rights Reserved
At The Next Place To Look Is this the place? To Next Place to Flow Look Create Flow Req Create Flow Req Allocator Dir Forwarding Table • Create Flow Request arrives at the next place to look. • Flow Allocator looks up the destination application name in its “local cache” • Address returned isn’t ours, so not here. • Send it there 10 May 10 © John Day, 2010 29 All Rights Reserved
Stepping Back Establishing Communication A Ahh, a big leap! B • Remember this? • We go along looking for places to look for the requested application. 10 May 10 © John Day, 2010 30 All Rights Reserved
Yet Another Place to Look Allocate Dest Application Allocate Confirm Indication Is this the place? Send to Requestor. Flow Create Flow Req Allocator Create Flow Resp Dir Forwarding Table • Create Flow Request arrives at yet another place to look. • Flow Allocator looks up the destination application name in its “local cache” • Address returned is ours. Its here! Check requestors credentials, if okay. • Deliver Allocate indication to the destination application • Which accepts or rejects, if accepts sends a Create Flow Response and • Instantiates a EFCP-instance • The connection is established. 10 May 10 © John Day, 2010 31 All Rights Reserved
Finishing Up Establishing Communication A Ahh, here it is! B • The Create Flow Response is sent back to the originator. • Data can now flow. – Remember we instantiated the EFCP at the source before we started. – Just in case data gets back before the Create Response. • Either end may start the Application Protocol exchange. 10 May 10 © John Day, 2010 32 All Rights Reserved
The Flow is Now Allocated Flow Response Arrives Allocator Create Flow Resp FA-AEI Dir Forwarding Table • The Create Flow Response arrives from the Destination • The Application is notified that the Allocate was successful and is given a port-id (in Unix this might be a file descriptor), i.e. the FA-AEI-identifier. • The application can now start exchanging information. 10 May 10 © John Day, 2010 33 All Rights Reserved
The Management Side RIB Daemon • The OIB/RIB Daemon is a generalization and combination of three facilities: routing update, event management and the management agent and performs the following: – periodically request or notify all or a subset of members of the current value of selected information (routing update); – upon certain events, notify all or a subset of members of the current value of selected information; – the latter implies that all event notifications occurring within the DIF should be delivered to the RIB Daemon because there may be a subscription that is triggered by the event, (event management); – given that elements of the DIF members should be able to request immediate notification of an event’s arrival, have it recorded in the RIB, or both (event management); – if a log of events received is to be kept (the black box function), then the RIB Daemon is the natural place or it (event management); – given that the RIB Daemon responds to requests for information from other members of the DIF, then it is the natural place to respond to external requests for information from the DIF Management System (DMS), (management agent). 10 May 10 © John Day, 2010 34 All Rights Reserved
The Management Side Resource Allocator • The resource allocator is the core of management in the IPC Process. The degree of decentralization depends on the policies and how it is used. • The RA has a set of meters and dials that it can manipulate • The meter fall in 3 categories: – Traffic characteristics from the user of the DIF – Traffic characteristics of incoming and outgoing flows – Information from other members of the DIF 10 May 10 © John Day, 2010 35 All Rights Reserved
The Management Side Resource Allocator • The Dials – Creation/Deletion of QoS Classes – Data Transfer QoS Sets – Modifying Data Transfer Policy Parameters – Creation/Deletion of RMT Queues – Modify RMT Queue Servicing – Creation/Deletion of (N-1)-flows – Assignment of RMT Queues to (N-1)-flows – Forwarding Table Generator Output 10 May 10 © John Day, 2010 36 All Rights Reserved
Initial Draft of a MIB: I IPC Process Resource Security Data Transfer AllocationAE Management Allocation Access SDU AllocationAEI Directory Authentication Forwarding Control Protection Table Mngt Forwarding Table Res Alloc Generator Policy PDU Forwarding Policy Table (e.g. Routing) One to One (N-1)-Flow Mngr One to Many 10 May 10 © John Day, 2010 37 All Rights Reserved
Initial Draft of a MIB: II Data Transfer Dest Addr Class of Service (N-1)-Flows SDU Protection (N)-Flowa Obs. Perf QoS Queues RMT DTP DT-SV DTCP PDU Forwarding Table Reassemb Q Flow Ctl Rexmsn Ctl Policy Policy Params Params 10 May 10 © John Day, 2010 38 All Rights Reserved
Transition? No, Adoption RINA supported Applications RINA Applications RINA Network Public Internet Rina Provider • Adopt. Don’t transition. – If the old stuff is okay in the Internet e-mall, leave it there. – Do the new sophisticated stuff 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. 10 May 10 © John Day, 2010 39 All Rights Reserved
Aids to Adoption An Internet API Sockets to RINA API • Allows most Internet applications to work over RINA, – Some restrictions on passing addresses since RINA never exposes them. • If available on both ends, can be faked. • But with none of the benefits of RINA. – Can only connect to a new instance of an application. – There are several ways to do this. None will give you every aspect of RINA. 10 May 10 © John Day, 2010 40 All Rights Reserved
Aids to Adoption Data Link Diversity Legacy Data Link RINA Management Protocols, e.g. 802.x etc. • To deal with the diversity at the media, use the legacy data transfer protocols, but manage it with RINA. – Provides better management. – There would be some advantage to moving to RINA data transfer as well. • Fewer protocols, less parts count, less cost, easier management, higher performance, etc. – But as an Aid to Adoption, this can be investigated. 10 May 10 © John Day, 2010 41 All Rights Reserved
Next Steps • Standardization – We need multiple implementations to test the concepts, and serve as a sanity check on implementations and interpretation – To inter-operate, we need to standardize a number of things • Minimum common object sets and operations • Common concrete syntax(es) and data representation(s) • Interoperable common (sub)sets of policy combinations – But not all DIFs have to operate within these constraints, so research and customization is not hampered – We need an organization that can help create, promulgate, and support these standards - the Pouzin Society 10 May 10 © John Day, 2010 42 All Rights Reserved
Next Steps (2) • Implementation Issues – WHY will people do implementations? What can we do to help them so that we raise the acceptance of this technology? – Many different execution targets: middleware, microkernel, OS, apps, dedicated/embedded • Different concerns may lead to radically different implementations – Proprietary concerns • If implementations don’t interoperate, they don’t reinforce one another • Basic technology and intellectual property needed for interoperable implementations needs to be availability without burden – Product details can generally be abstracted from DIF/protocols 10 May 10 © John Day, 2010 43 All Rights Reserved
Next Steps (3) • Many supporting activities will be fruitful – Research and analysis of concepts – Policy research, separated from the difficulties of making new concepts work within highly-optimized legacy implementations – Tools for measurement, testing, configuration, and analysis of implementations – Tools to generate and run simulations based on common mechanism, with experimental policies plugged in as appropriate • Impractical with hand-coded implementations of protocols • Opens new opportunities for research into protocol behavior and design 10 May 10 © John Day, 2010 44 All Rights Reserved
Next Steps (4) • We’ll be meeting this week to discuss all these issues - please feel free to join us! 10 May 10 © John Day, 2010 45 All Rights Reserved
Conclusions • RINA is a new formulation of how to do networking – It incorporates the lessons of the last 40 years, where we’ve learned both good and bad ways to do things. We’d like to step away from many things that have not worked out well. – We don’t propose that RINA overnight replace the Internet as we know it, but rather that we begin a new age of protocol research and implementation • To add new capabilities to networks • To make networks more efficient, manageable, and secure • To get past problems that have arisen in where we are now • RINA is in its early stages of development - join us and help us mature it! 10 May 10 © John Day, 2010 46 All Rights Reserved

More Related Content

PDF
PTOLEMUS - SWC - Mobile Social Networking - May 2009
Frederic Bruneteau
 
PDF
Education in the age of access
CORE Education
 
PDF
Why CIOs Must Embrace Social Media
Jo Caudron
 
PDF
The Evolving Online Consumer
Digital Next Australia
 
PDF
Imagina Round Table MakeMyWorlds
Helene Zuili
 
PDF
Social Media Small Companies 10dec09
Jo Caudron
 
PDF
The Evolving Online Consumer - Brisbane
Digital Next Australia
 
PDF
20 things I learned about browsers and the web
M.V.S.R Engineering College
 
PTOLEMUS - SWC - Mobile Social Networking - May 2009
Frederic Bruneteau
 
Education in the age of access
CORE Education
 
Why CIOs Must Embrace Social Media
Jo Caudron
 
The Evolving Online Consumer
Digital Next Australia
 
Imagina Round Table MakeMyWorlds
Helene Zuili
 
Social Media Small Companies 10dec09
Jo Caudron
 
The Evolving Online Consumer - Brisbane
Digital Next Australia
 
20 things I learned about browsers and the web
M.V.S.R Engineering College
 

Viewers also liked (9)

PDF
10 fn s31
Scott Foster
 
PDF
Design Considerations for Converged Optical Ethernet Networks
Vishal Sharma, Ph.D.
 
PDF
10 fn s46
Scott Foster
 
PDF
10 fn s48
Scott Foster
 
PDF
10 fn s32
Scott Foster
 
PDF
10 fn s47
Scott Foster
 
PDF
10 fn tut3
Scott Foster
 
PDF
10 fn s44
Scott Foster
 
PDF
10 fn tut2
Scott Foster
 
10 fn s31
Scott Foster
 
Design Considerations for Converged Optical Ethernet Networks
Vishal Sharma, Ph.D.
 
10 fn s46
Scott Foster
 
10 fn s48
Scott Foster
 
10 fn s32
Scott Foster
 
10 fn s47
Scott Foster
 
10 fn tut3
Scott Foster
 
10 fn s44
Scott Foster
 
10 fn tut2
Scott Foster
 
Ad

Similar to 10 fn tut1 (7)

PPTX
Bab I
Mustahal SSi
 
PDF
6 security130123
ARCFIRE ICT
 
PDF
6 security130123
ICT PRISTINE
 
PDF
How to open source a project at Mega Corp (Geecon - May/2011)
Martijn Verburg
 
PDF
1 lost layer130123
ARCFIRE ICT
 
PPT
Maker party Net Neuatrality
bilalshaikh7
 
PDF
SheSays Boulder // March 21, 2012
Carmel Hagen
 
Bab I
Mustahal SSi
 
6 security130123
ARCFIRE ICT
 
6 security130123
ICT PRISTINE
 
How to open source a project at Mega Corp (Geecon - May/2011)
Martijn Verburg
 
1 lost layer130123
ARCFIRE ICT
 
Maker party Net Neuatrality
bilalshaikh7
 
SheSays Boulder // March 21, 2012
Carmel Hagen
 
Ad

More from Scott Foster (20)

PDF
10 fn s48
Scott Foster
 
PDF
10 fn s47
Scott Foster
 
PDF
10 fn s46
Scott Foster
 
PDF
10 fn s45
Scott Foster
 
PDF
10 fn s44
Scott Foster
 
PDF
10 fn s43
Scott Foster
 
PDF
10 fn s42
Scott Foster
 
PDF
10 fn s40
Scott Foster
 
PDF
10 fn s38
Scott Foster
 
PDF
10 fn s37
Scott Foster
 
PDF
10 fn s36
Scott Foster
 
PDF
10 fn s35
Scott Foster
 
PDF
10 fn s34
Scott Foster
 
PDF
10 fn s33
Scott Foster
 
PDF
10 fn s32
Scott Foster
 
PDF
10 fn s31
Scott Foster
 
PDF
10 fn s29
Scott Foster
 
PDF
10 fn s28
Scott Foster
 
PDF
10 fn s26
Scott Foster
 
PDF
10 fn s23
Scott Foster
 
10 fn s48
Scott Foster
 
10 fn s47
Scott Foster
 
10 fn s46
Scott Foster
 
10 fn s45
Scott Foster
 
10 fn s44
Scott Foster
 
10 fn s43
Scott Foster
 
10 fn s42
Scott Foster
 
10 fn s40
Scott Foster
 
10 fn s38
Scott Foster
 
10 fn s37
Scott Foster
 
10 fn s36
Scott Foster
 
10 fn s35
Scott Foster
 
10 fn s34
Scott Foster
 
10 fn s33
Scott Foster
 
10 fn s32
Scott Foster
 
10 fn s31
Scott Foster
 
10 fn s29
Scott Foster
 
10 fn s28
Scott Foster
 
10 fn s26
Scott Foster
 
10 fn s23
Scott Foster
 

10 fn tut1

  • 1. An Introduction to RINA Or How I Learned to Stop Worrying and Love the Internet FutureNet Tutorial Part I John Day May 2010 Good architecture, like good science, is maximizing the invariances and minimizing the discontinuities. 1 © John Day, 2010 11/01/06 All Rights Reserved
  • 2. We Got Trouble! Right Here in River City 2 © John Day, 2010 11/01/06 All Rights Reserved
  • 3. The Internet is Facing Severe Problems: I • Security is essentially non-existent. – Excuse: No one considered it in the early days • Security wasn’t a concern for a military-funded network? – Actual: Systematically weak design (hacker mentality) • Router table size is growing exponentially – Excuse: Memory is cheap – Actual: No longer on Moore’s Law, it is getting expensive and caused by • No support for multihoming – Excuse: not that many hosts need it, and we can kludge it • A military-funded network doesn’t care about suvrivability? – Actual: Since when is 107 small, and the kludge doesn’t scale. • It isn’t 107, with Smart Grid it is more like 1010. 3 © John Day, 2010 11/01/06 All Rights Reserved
  • 4. The Internet is Facing Severe Problems: II • Mobility is cumbersome and doesn’t scale – Excuse: What do you mean? It works. . . . . Sort of. – Actual: With only physical addresses, hard to do “re-locatable” addressing • Congestion Control keeps Utilization around 30% – Excuse: There is great congestion control in TCP . . . Sort of. Bandwidth is Cheap don’t worry about it. – Actual: Any control theory book says put feedback as close to the resource as possible. TCP puts it as far away as possible. • Quality of Service is difficult to do. – Excuse: Net neutrality requires that all traffic be treated equally – Actual: Net neutrality is political cover for their inability to find solution. • Notice: Running out IP addresses was not listed – Not a problem. A global address space is not required 4 © John Day, 2010 11/01/06 All Rights Reserved
  • 5. And if that Weren’t Bad Enough Much of What is Believed about the Internet is Myth 5 © John Day, 2010 11/01/06 All Rights Reserved
  • 6. Myths of the Internet: I • The Internet is an Engine of Innovation. – The Internet has in a real sense been stagnant since the late-70s – Living on Moore’s Law and Band-aids • Lots of Innovation on top of the Internet, but even that has begun to wane. • The Internet has decentralized administration. No one owns the Internet. – Actually, Same as the global PSTN, just no sexy name. • The IETF is a Grass-Roots Democracy. – Actually, It most closely Resembles the Communist Party. • IETF meeting is the Party Congress; IESG is the Politburo – Designed to be dominated by an elite, just not the one they had in mind. • The Internet is based on the ARPANET – Actually, It is based on the French network CYCLADES – The ARPANet technology was abandoned. 6 © John Day, 2010 11/01/06 All Rights Reserved
  • 7. Myths of the Internet: II • The Internet is not an internet, but a catenet. – Ceased to be an Internet on January 1, 1983. • The Internet is a dumb network. – Actually, it keeps maximal state in the network, not minimal. • The Internet has decentralized routing. – Actually, in most ISPs routes are statically allocated. • IP is the Internet Protocol. – That is what the letters stand for but at best it is a subnet protocol. • More likely just a header fragment • IP addresses name the host. – No, they name an interface to the host. • TCP isn’t perfect, but it is good enough. – Every design decision is not just wrong but makes something else worse. One thing it got right was destroyed creating IP. 7 © John Day, 2010 11/01/06 All Rights Reserved
  • 8. The Reality is Quite Different • If the Internet were an Operating System, it would have more in common with DOS, than UNIX. • Imagine trying to use a modern computer with only physical memory addresses. • That is the Internet today. 8 © John Day, 2010 11/01/06 All Rights Reserved
  • 9. Need to Do Something About It • For the Past Decade, DARPA, NSF, and numerous conferences, workshops, and summits have discussed and done research on a “Future InterNet Design.” – So far they have come up dry, nothing, nada. Isn’t groupthink wonderful? • No closer to an answer now than a decade ago. – “Rough consensus and running code” doesn’t exactly foster the kind of thought required to uncover theory. • The field is no longer a science, but a craft. – They have been asking “What to build?” – Not asking, “What don’t we understand?” 9 © John Day, 2010 11/01/06 All Rights Reserved
  • 10. Guiding “Principles” Aren’t Much Help • Soft State/Hard State – All properly designed protocols are soft state; only some database operations are hard state. A specious distinction • Loc/Id Split – Attempt to avoid the obvious solution. Mostly post IPng trauma. – Continues to route to the wrong place • Fate Sharing – Mostly used as a rug . . . to sweep under. • End-to-End Principle – At best a lemma. More a statement of desire, by focusing attention on the dichotomy of the middle vs the edge, it obscures the point. – Hence becomes an impediment to finding a path forward. 10 © John Day, 2010 11/01/06 All Rights Reserved
  • 11. The Myths and “Principles” are the Major Barrier to FINDing an Answer • The Answer has been clear since the mid-90s. • And it is very simple: • Networking is IPC and only IPC 11 © John Day, 2010 11/01/06 All Rights Reserved
  • 12. CYCLADES had Shown the Way Host or End System Application Transport Router Network Data Link Physical An Architecture with Alternating Layers of Relaying and Error Control of Increasing Scope Seemed to Make a Lot of Sense. 12 © John Day, 2010 11/01/06 All Rights Reserved
  • 13. So We Went With It But As Things Developed Things go more complex Application Application Presentation Session Transport Presentation SNIC Session SNDC Transport SNAC Network LLC MACLink Data Physical Physical And While Better It Wasn’t The Full Answer 13 © John Day, 2010 11/01/06 All Rights Reserved
  • 14. Meanwhile the Internet Never Got Past Application Or do whatever you want TCP IP Subnet Or do whatever you want We Were Missing Something, but What was It? Were Layers the Wrong Model? 14 © John Day, 2010 11/01/06 All Rights Reserved
  • 15. Probably Not, Lets Go Back to Basics • Start simple and incrementally introduce new conditions. – Taking Imre Lakatos’ Proofs and Refutations as a model. • We are going to cover ground we all know. – Or at least we think we do. (I thought so) • As we do, think about what is required when – the order is not what you might expect. – But the implications are even more interesting. 15 © John Day, 2010 11/01/06 All Rights Reserved
  • 16. 1: Start with the Basics Two applications communicating in the same system. Application Processes A B Application Flow Port Ids IPC Facility Communication within a Single Processing System 16 © John Day, 2010 11/01/06 All Rights Reserved
  • 17. How Does It Work? Application Processes A B Application Flow Port Ids IPC Facility 1) A invokes IPC to create a channel to B; a = Allocate (B, QoS); 2) IPC determines whether it has the resources to honor the request. 3) If so, IPC allocates port-id a and uses “search rules” to find B and determine whether A has access to B. 4) IPC may cause an instance of B to be created. B is notified of the IPC request from A and given a port-id, b. 5) If B responds positively, and IPC notifies A (the API could be blocking in which case the assignment of the port-id, a would be done now). 6) Thru n) Then using system calls A may send PDUs to B by calling Write(a, buf), which B receives by invoking Read(b, read_buffer) 7) When they are done one or both invoke Deallocate with the appropriate parameters 17 © John Day, 2010 11/01/06 All Rights Reserved
  • 18. 2: Two Application Communicating in Distinct Systems Systems Application Processes IPC-Facility 18 © John Day, 2010 11/01/06 All Rights Reserved
  • 19. How Does It Work Now? Application Processes Port Ids IAP IAP 1) A invokes IPC to create a channel to B; a = Allocate (B, QoS); 2) IPC determines whether it has the resources to honor the request. 3) If so, IPC uses “search rules” to find B. and determine if A has access to B. - Management of name space is no longer under the control of a single system. - Each system no longer knows all available applications. – Local Access Control can no longer be relied on to provide adequate authorization and authentication. • Need a protocol to carry application names and access control information. – Lets call it the IPC Access Protocol 19 © John Day, 2010 11/01/06 All Rights Reserved
  • 20. What Does “IAP” Look Like? • Simple Request/Response Protocol – IAP-Req(Dest-Appl-name, Src-Appl-name, QoS params, Src-Capability) – IAP-Resp(Dest-Appl-name, Src-Appl-name, QoS params, result) Op Dest Appl Name Src Appl Name QoS & Policies Capability • How do we know when to use it? – If the application isn’t here, it must be there! • But we have a problem. How do we get it there? 20 © John Day, 2010 11/01/06 All Rights Reserved
  • 21. Getting from A to B • We knew this was going to be a problem sooner or later. • We need to be able to send information from A to B. • And we know: – Bad things can happen to messages in transit. Protection against lost or corrupted messages • This can be expensive – Receiver must be able to tell sender, it is going too fast. We need Flow Control, and – We have lost our means of synchronization: • No common test and set means shared memory can no longer be used • Must create shared state between two systems. An explicit synchronization mechanism is required. • We need some kind of Protocol for Error and Flow Control. 21 © John Day, 2010 11/01/06 All Rights Reserved
  • 22. What Would an EFCP Look Like? • Symmetric Protocol to establish error and flow control • Transfer PDU Op Seq # CRC Data • Ack and Flow Control PDU types Op Seq # CRC Ack Op Seq # CRC Credit 22 © John Day, 2010 11/01/06 All Rights Reserved
  • 23. How Does It Work Now? Application Processes Port Ids IAP IAP Distributed IPC Facility EFCP EFCP 1) A invokes IPC to create a channel to B; a = Allocate (B, QoS); 2) IPC determines whether it has the resources to honor the request. 3) Send IAP Request to access B, creating an EFCP connection and determines if A has access to B. 4) IPC may cause B to be instantiated. B is notified of the IPC request from A and given a port-id, b. 5) If B responds positively, and IPC notifies A with a different port-id, a. 6) Thru n) Then using system calls A may send PDUs to B by calling Write(a, buf), which B receives by invoking Read(b, read_buffer) over the EFCP connection 7) When they are done one or both invoke Deallocate with the appropriate parameters Just Like Before . . . .More or Less 23 © John Day, 2010 11/01/06 All Rights Reserved
  • 24. Two Applications in Two Systems Required Three New Concepts • An Application Name Space that spans both systems. (not really new) – Should be location-independent in general so that applications can move. • A Protocol to carry Application Names and access control info – Applications need to know with whom they are talking – IPC must know what Application is being requested to be able to find it. • For now, if the requested Application isn’t local, it must in the other system. • A Protocol that provides the IPC Mechanism and does Error and Flow Control. – To maintain shared state about the communication, i.e. synchronization – To detect errors and ensure order – To provide flow control • Resource allocation can be handled for now by either end refusing service. 24 © John Day, 2010 11/01/06 All Rights Reserved
  • 25. 3: Simultaneous Communication Between Two Systems i.e. multiple applications at the same time • To support this we have multiple instances of the EFCP. EFCPEFCP EFCP EFCP EFCP EFCP Will have to add the ability in EFCP to distinguish one flow from another. Typically use the port-ids of the source and destination. Connection-id Dest-port Src-port Op Seq # CRC Data Also include the port-ids in the information sent in IAP to be used in EFCP 25 synchronization (establishment). © John Day, 2010 11/01/06 All Rights Reserved
  • 26. Simultaneous Communication Between Two Systems i.e. multiple applications at the same time • In addition to multiple instances of the EFCP. EFCP EFCP EFCP EFCP EFCP EFCP Mux Mux Will also need an application to manage multiple users of a single resource. 26 © John Day, 2010 11/01/06 All Rights Reserved
  • 27. Multiple Instances of IPC • New Concept: a multiplexing application to manage the single resource, the physical media. • The multiplexing application will need to be fast, its functionality should be minimized, i.e. just the scheduling of messages to send. – To provide QoS, we use the EFCP and scheduling by the Mux. • To do resource allocation, we will just let the other side refuse if it can’t satisfy the request. • Application naming gets a bit more complicated than just multiple application-names. – Must allow multiple instances of the same process 27 © John Day, 2010 11/01/06 All Rights Reserved
  • 28. IPC to Support Simultaneous Communication between Two Systems Distributed IPC-Process IAP EFCP Mux Physical Media 28 © John Day, 2010 11/01/06 All Rights Reserved
  • 29. 4: Communication with N Systems Systems 29 © John Day, 2010 11/01/06 All Rights Reserved
  • 30. Replication Entails More Management • Separate Multiplexing Application for each physical media interface. • IPC can find the destination by choosing the appropriate interface. • If enough applications, create a Directory to remember what is where, i.e. what application names are at the other end of which interfaces. • Same local names can be used to keep track of which EFCP-instances (port-ids) are bound to which Multiplexing Application. • With many destinations, may need to coordinate resource allocation information within our distributed IPC Facility. 30 © John Day, 2010 11/01/06 All Rights Reserved
  • 31. With Multiple Interfaces It Gets Messy IAP Dir Coordination with Peer Res Alloc EFCP EFCP EFCP Mux Mux Mux Physical Media • So a task to manage the use of the interfaces and mask any differences. – A little organizing will help. 31 © John Day, 2010 11/01/06 All Rights Reserved
  • 32. There is Some Common Structure Coordination with Peer Res Alloc IAP Dir EFCP Mux Physical Media • We can organize interface IPC into modules of similar elements. • Each one constitutes a Distributed IPC Facility of its own. – As required, consists of IAP, EFCP, Multiplexing Application, Directory, Per-Interface Resource Allocation • Then we just need an application to manage their use and moderate user requests. 32 © John Day, 2010 11/01/06 All Rights Reserved
  • 33. A Little Re-organizing A Virtual IPC Facility? IAP Res Alloc Mux Dir So we have a Distributed IPC Facility for each Interface and an application over all of them to manage their use and to give the user a common interface, a Virtual IPC Facility? 33 © John Day, 2010 11/01/06 All Rights Reserved
  • 34. BUT • This fully connected graph approach isn’t going to scale very well and is going to get very expensive. – And not everyone needs to talk to everyone else all the time. • Need to do something better. 34 © John Day, 2010 11/01/06 All Rights Reserved
  • 35. 5: Communicating with N Systems (On the Cheap) Dedicated IPC Systems Host Systems By dedicating systems to IPC, reduce the number of lines required and even out usage by recognizing that not everyone talks to everyone else the same amount. 35 © John Day, 2010 11/01/06 All Rights Reserved
  • 36. Communications on the Cheap • We will need systems dedicated relaying and multiplexing. • That requires some new elements: – Globally accepted names for source and destination muxing apps. – And also for the relays. Relays require names for routing. Have to know where you are to determine where to go next. – Need routing applications too, which will need to exchange information on connectivity. • Will need a header on all PDUs to carry the names for relaying and multiplexing. – Interface IPC Facilities will need one too if they are multiple access. Dest Addr Src Addr Common Relaying and Multiplexing Application Header Relaying Routing Application Media-dependent IPC Processes 36 © John Day, 2010 11/01/06 All Rights Reserved
  • 37. Communications on the Cheap • But relaying systems create problems too. – Can’t avoid momentary congestion from time-to-time. – Annoying bit errors can occur in their memories. • Will have to have an EFCP operating over the relays to ensure required QoS reliability parameters. – Our virtual IPC Facility isn’t very virtual. EFCP EFCP Relaying Relaying Application PM 37 © John Day, 2010 11/01/06 All Rights Reserved
  • 38. The Big Picture But this is half way between a bead-on-a- string model and a layered model User Applications Application Layer EFCP Transport EFCP Relaying Layer Appl Mux Network Mux Layer EFCP EFCP EFCP EFCP EFCP EFCP Data Link Layer Physical Layer This should look familiar. 38 © John Day, 2010 11/01/06 All Rights Reserved
  • 39. The IPC Model (A Purely CS View) User Applications Distributed IPC Facilities EFCP EFCP Relaying Appl Mux Mux EFCP EFCP EFCP EFCP EFCP EFCP 39 © John Day, 2010 11/01/06 All Rights Reserved
  • 40. Summary • “Networking is InterProcess Communication” – . . . . and only IPC. • The quote is Bob Metcalfe, 1972. (The rest is mine.) • A layer is a distributed application that manges IPC consisting of a collection of SDU protection, muxing, EFCP, and their associated routing and resource management tasks. • This is a distributed computing problem, not a “telecom” problem. • And this Distributed IPC Facility repeats. • This constitutes a basis for a general theory of networking. 40 © John Day, 2010 11/01/06 All Rights Reserved
  • 41. OSI Should Have Seen the Pattern Application Had Shown Itself Even There Presentation The Repeating Structure Session Transport SNIC Network SNDC SNAC LLC Data Link MAC 41 © John Day, 2010 11/01/06 All Rights Reserved
  • 42. From This We Can Construct What We Need But First We Need a Few Tools • Resolving the Connection vs Connectionless Debate – The center of the 30 Years War • The Nature of Applications and their Protocols. – A Couple of Important Insights • Watson’s Fundamental Results on Synchronization – Probably the most important insight in networking since datagrams • Separating Mechanism and Policy – Pulling out the invariances 42 © John Day, 2010 11/01/06 All Rights Reserved
  • 43. 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 43 © John Day, 2010 11/01/06 All Rights Reserved
  • 44. 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: 44 © John Day, 2010 11/01/06 All Rights Reserved
  • 45. We Need to Look at the Whole Thing Routing xfr mngt (A bit like doing a conservation of energy problem and getting the boundaries on the system wrong.) • The amount of state is about the same, although the amount of replication is different. • We have been distributing connectivity information to every Node in a layer, but • We have insisted in distributing resource allocation information only on a need to know basis, i.e. connection-like. • Even if we aren’t too sure who needs to know. • Now we have to work out how to do resource allocation more like how we do routing. (Left as an exercise.) 45 © John Day, 2010 11/01/06 All Rights Reserved
  • 46. So What Do We Know About CO/CL • It is a function of the layer. Should not be visible to applications. • Connectionless is characterized by the maximal dissemination of state information and dynamic resource allocation. • Connection-oriented mechanisms attempt to limit dissemination of state information and tends toward static resource allocation. • Applications request the allocation of comm resources. • The layer determines what mechanisms and policies to use. • Tends toward CO when traffic density is high and deterministic. • CL when traffic density is low and stochastic. 46 © John Day, 2010 11/01/06 All Rights Reserved
  • 47. The Upper Layers • After the initial success, this was one of the big unknowns. – Operating Systems had been a good initial guide: • NCP - Interprocess Communication • Telnet - terminal device driver • FTP - the file system • NETRJE - RJE • But what was the general structure? • There was early work that indicated it wasn’t layered. – OSI made a stab at it – By 1983, had realized that there were no upper layers.T • There were common functions. • But the nature of the Application itself was interesting. 47 © John Day, 2010 11/01/06 All Rights Reserved
  • 48. 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. Only one FTP per system, only one remote login per system, etc. • 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. 48 © John Day, 2010 11/01/06 All Rights Reserved
  • 49. Applications and Communication: II Application Outside the Network Process Inside the Network Application Application Entity Entity • The Application-Entity (AE) is that part of the application concerned with communication, i.e. shared state with its peer. • 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. 49 © John Day, 2010 11/01/06 All Rights Reserved
  • 50. BUT There is only one application protocol • Huh!? Think about it. What can you do remotely? – 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 to name 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. 50 © John Day, 2010 11/01/06 All Rights Reserved
  • 51. Delta-t 1980 • Richard Watson develops delta-t, a unique approach. – Assumes all connections exist all the time. – TCBs are simply caches of state on ones with recent activity • Watson proves that the conditions for distributed synchronization are met if and only if 3 timers are bounded: • Maximum Packet Lifetime • Maximum number of Retries • Maximum time before Ack – That no explicit state synchronization, i.e. hard state, is necessary. • SYNs, FINs are unnecessary • IOW, all properly designed data transfer protocols are soft-state. • Including protocols like HDLC • 1981 paper, Watson shows that TCP has all three timers and more. • And PNA figures out that . . . . 51 © John Day, 2010 11/01/06 All Rights Reserved
  • 52. The Structure of Protocols Tightly-bound Loosely-bound (pipelined) (Policy processing) • 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 – Right, we split TCP in the wrong direction • Noting that syntactic differences are minimal, we can conclude that • There is one data transfer protocol with a small number of encodings. 52 © John Day, 2010 11/01/06 All Rights Reserved
  • 53. 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 delta-t – An Application protocol that can perform 6 operations on objects: – 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 using a programming model. The application protocol is the “assembly language” for distributed computing. – As we shall see, we have now made network architecture independent of protocols. 53 © John Day, 2010 11/01/06 All Rights Reserved
  • 54. Implications: Protocols II • “Hard state” only occurs for some uses of application protocols – Storing in a database may be hard-state. Everything else is soft-state. – Hence the “hard-state/soft-state” distinction at best states the obvious. • Separating mechanism and policy in a delta-t like protocol will yield the entire range from UDP-like to TCP-like. • Watson implies decoupling “port allocation” from synchronization. – Greatly simplifying and improving security, enabling multi-flow allocations of IPC, etc. • And One Other Thing: 54 © John Day, 2010 11/01/06 All Rights Reserved
  • 55. Fundamental Result • 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. 55 © John Day, 2010 11/01/06 All Rights Reserved
  • 56. What a Layer Looks Like IPC IPC IPC Management Control Transfer Delimiting Applications, e.g., routing, Transfer resource allocation, Relaying/ Muxing access control, etc. PDU Protection Common Application Protocol Application-entities Application Process • 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. 56 © John Day, 2010 11/01/06 All Rights Reserved 56
  • 57. What are the Protocols? DTP/DTCP After Delta-t Mgmt applications, e.g. routing, IAP, resource allocation, etc. uses Relaying and the RIB or mgmt protocol for all Multiplexing Task information. Management Adds PCI for Protocol PDU protection • Only two – A data transfer protocol, based on delta-t with mechanism and policy separated. This provides both unreliable and reliable flows. – A management protocol based on CMIP leveraging the constrained form of map/reduce in CMIP. 57 © John Day, 2010 11/01/06 All Rights Reserved
  • 58. The Application Entities of an IPC Process Flow Allocator (one per IPC Proc) Data Transfer AE (one per flow) IPC Process (Management) RIB Daemon RMT AE CAP AEs (one per IPC Proc) • The Application Process of an IPC Process is management. – Flow Allocator manages flows, finds the destination and does access control, manages the binding of connection-endpoint-ids to port-ids. – Data Transfer AE is the error and flow control protocol – RMT AE consists of the relaying and multiplexing task and SDU Protection – RIB Daemon maintains the local RIB information. – CAP AEs are management flows with other members of the DIF and NMS 58 © John Day, 2010 11/01/06 All Rights Reserved
  • 59. But Wait a Minute! • If a Layer is a Distributed Application that Does IPC, • What is a Distributed Application? – a Distributed Application Facility (DAF). • Good Question! • What are the elements that would be common to distributed applications that don’t do manage IPC. • Notice that a DIF is primarily a DAF that manages IPC. 59 © John Day, 2010 11/01/06 All Rights Reserved
  • 60. Distributed Application Facility The Application Object Information Base OIB Daemon Common SDU Protection Application Protocol • A DAF consists of SDU protection, the Common Application Protocol (CMIP + ACSE), an Object Information Base, and the OIB Daemon. • The transition from a DIF to a DAF is a transition from an IPC model to a programming language model. – The task of the OIB Daemon is to populate the OIB with whatever the Application needs on whatever schedule it needs it: a sort of “schema pager” 60 © John Day, 2010 11/01/06 All Rights Reserved
  • 61. Common Distributed Application Protocol ACSE Authentication CMIP • ACSE is the common protocol for establishing application connections. It ensure that there is a known first exchange. – ACSE was defined to be used recursively and has hooks for. . . • An authentication module is policy of whatever strength required. • CMIP provides the minimal six operations and a basic object-oriented functionality (scope and filter). – Would other programming paradigms lead to different functions? 61 © John Day, 2010 11/01/06 All Rights Reserved
  • 62. Only Three Kinds of Systems Interior Border Routers Routers Hosts • 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. 62 © John Day, 2010 11/01/06 All Rights Reserved
  • 63. Hosts Might Have More DIFs Simple App Transaction Mail Appl Processing Application (over a VPN) Local App VPN Traditional Network Transport Layers Note that the VPN could occur one layer lower as well or even lower, “Link”{ Layers but then it would just be a PN. User Applications use whatever layer has sufficient scope to communicate with their apposite. 63 © John Day, 2010 11/01/06 All Rights Reserved
  • 64. 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. 64 © John Day, 2010 11/01/06 All Rights Reserved
  • 65. How Does It Work? Joining a Layer (N)-DIF A (N-1)-DIF • 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 65 © John Day, 2010 11/01/06 All Rights Reserved
  • 66. How Does It Work? Establishing Communication A Ahh, here it is! 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. • 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 66 – If B’s has moved, we find out and keep searching © John Day, 2010 11/01/06 All Rights Reserved
  • 67. 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? Doubtful. Research topic.. 67 © John Day, 2010 11/01/06 All Rights Reserved
  • 68. How Does It Work? The Internet and ISPs • ISPs have as many layers as they need to best manage their resources. Metros Regionals Backbone 68 © John Day, 2010 11/01/06 All Rights Reserved
  • 69. 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 69 © John Day, 2010 11/01/06 All Rights Reserved
  • 70. 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! Facebook Boutique My Net Utility SCADA Public Internet Internet Rodeo Drive Internet Mall of America ISP 1 ISP 2 ISP 3 70 © John Day, 2010 11/01/06 All Rights Reserved
  • 71. How Does It Work? The User’s Perspective e-common DIFs e-common DIFs Peering DIF Local Customer Peering DIF Local Customer Network Network Provider Network Provider Network 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. 71 © John Day, 2010 11/01/06 All Rights Reserved
  • 72. How Does It Work? Security ISP Hosts and ISPs do not share DIFS. (ISP may have more layers • 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. 72 © John Day, 2010 11/01/06 All Rights Reserved
  • 73. How Does It Work? Port:=Allocate(Dest-Appl, params) Security Access Control Exercised • The DIF is a securable container. DIF is secured not each component separately. • 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. 73 © John Day, 2010 11/01/06 All Rights Reserved
  • 74. 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. Facebook Boutique My Net Utility SCADA Public Internet Internet Rodeo Drive Internet Mall of America ISP 1 ISP 2 ISP 3 74 © John Day, 2010 11/01/06 All Rights Reserved
  • 75. There More to Come • Next Naming and Addressing – It turns out to be quite straightforward and simple. • Looking at the Internals in a bit more detail – What does DTP and DTCP really look like? – What does the Flow Allocator and the RIB Daemon do? – What goes into defining a DIF? • 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 me wrong! ;-) 75 © John Day, 2010 11/01/06 All Rights Reserved
  • 76. Things They Never Taught You About Naming and Addressing (FutureNet Tutorial Part II) John Day May 2010 “Did I ever tell you about Mrs. McCave Who had 23 sons and she named them all Dave? Well she did and that was not a very smart thing to do Because now when she calls, “Yoo-hoo, come into the house, Dave!” All 23 of her sons come on the run “And now she wishes that she had named them . . .” <there follows a wonderful list of Dr. Seuss names she wishes she’d named them and then concludes with this excellent advice.> “But she didn’t do it and now it is too late.” - Dr. Seuss Too Many Daves May 5, 10 . 1
  • 77. Going Back to Fundamentals • Develop the concepts moving from more fundamental to more specific. – Fundamentals of Naming – Naming in Computing Systems – Naming for Communicating Processes – Naming for IPC May 5, 10 . 2
  • 78. Names and Name Spaces • A name space, NS, is a set {N} of names from which all names for a given collection of objects are taken. A name from a given name space may be bound to one and only one object at a time. • A name is a unique string, N, in some alphabet, A, that unambiguously denotes some object or denotes a statement in some language, L. The statements in L are constructed using the alphabet, A. • A function, MNS, which defines the class of objects, M, that may be named with elements of NS. This is referred to as the scope of the name space (see below). This may refer to actual objects or the potential for objects to be created. • A function, FMNS, that defines the mapping of elements of NS to elements of M. This function is one-to-one and onto and is called a binding. May 5, 10 . 3
  • 79. Operations on Names • Assignment, allocates a name in a name space, essentially marks it in use. Deassignment, removes it from use. Assignment makes names available to be bound. This allows certain portions of a name space to be “reserved,” not available for binding. • Binding, maps a name to an object. Once bound, any reference to the name accesses the object. Unbinding breaks the binding. Once unbound, any reference will not access any object. – An object ceases to exist when the last name referring to it is unbound. • Saltzer [1977] defines “resolve” as in “resolving a name” as “to locate an object in a particular context, given its name.” – An object cannot be identified without locating it nor located without identifying it. May 5, 10 . 4
  • 80. Types of Names • Objects may be assigned more than one name. These are called synonyms or aliases. – Objects that may have more than one name, the names are unambiguous. – Objects that must have only one name, the names are unique. • Names may also denote sets of names. Associated with the set is a rule that determines which names are returned when the name of the set is resolved. In networking, – A rule that returned all members has been called multicast. – A rule that returned one member has been called anycast. – We will refer to all forms as whatevercast! • Synonyms or names of sets may be taken from the same or different name spaces. – The name of an object is the name of a set of one element. May 5, 10 . 5
  • 81. Resolving Names • There are 2.5 means to resolve names: – Exhaustive Search – The name provides hints to narrow the search. • The “half” is indirection: – The name or part of the name points to an object that points to a name. • Hierarchy is the most common form of embedding hints in a name. – Hierarchy imposes a topological structure on the name space, which constrains the names that can be assigned to an object. – There may be search rules for how to utilize the “hints.” • Every thing up to this point is applicable to all naming in computing systems. May 5, 10 . 6
  • 82. Address Spaces in Operating Systems (From my OS Course) Human use, relatively constant, not at all tied to the hardware, i.e. location-independent Application Name Space Location Dependent but Hardware Independent; Creates a logical address Logical Name Space space larger than the physical memory; Allows processes to be re-locatable. Location-Dependent and Physical Name Space Hardware Dependent An name space is defined as a set of identifiers with a given scope. An address space is a location-dependent name space. In Operating Systems, we have found a need for 3 such independent spaces. Virtually all uses of names in computing are for locating. May 5, 10 . 7
  • 83. The Root of Internet Addressing Problems 56K Trunk Host Host 56K Trunk 56K Trunk IMP Host Host 56K Trunk A host’s address was its IMP Port Number. It was the common approach at the time. The ARPANet was first. Everyone else afterwards fixed the problem, except the Internet. So What is the Fix? May 5, 10 . 8
  • 84. OS’s Were the Guide • Shoch [1978] put it eloquently: – Application names indicate what is to accessed – Node addresses indicate where it is – Routes tell you how to get there. • In 1982, Jerry Saltzer published the “other” major paper on addressing. – Wrote down the OS view of network addressing: • Saltzer, Jerry. “On the Naming and Binding of Network Destinations” in Local Computer Networks, edited by P. Ravasio et al. P North-Holland Publishing Company, pp 311-317, 1982, republished as RFC 1498. – Application names that were location independent – Node addresses that were location dependent (the logical address) – Point of attachment addresses that were route-dependent (the physical address) – Routes which were actually a sequence of point of attachment addresses – And the three mappings between them. • Saltzer works through the problem in somewhat more detail. – Colored by the hardware of the time and the OS perspective. May 5, 10 . 9
  • 85. Modeling Saltzer • A Logical Model of a Network System – Naming the binding between a (N)- and (N-1)-PM is equivalent to naming the (N-1)-PM. Need to do one or the other. • Saltzer seems to favor naming PMs. – Since ultimately we must name the application and we know it isn’t a binding, naming PMs makes sense. System Layer Application Name Node Address Point of Attachment Address May 5, 10 . 10
  • 86. Saltzer’s View of Networks • Application names map to node addresses. • Node addresses map to points of attachment addresses. • Routes are sequences of points of attachments. – Just as in an operating system. – But networks are more general than operating systems. Application Name Node Address Point of Attachment Address May 5, 10 . 11
  • 87. But Saltzer Missed a Case • There can be More than One path to the Next Hop. – This case does not occur in computing systems. There is only one path from the CPU to memory. • Must route on the Node addresses, not the point of attachments Application Name Node Address Point of Attachment Address May 5, 10 . 12
  • 88. Generalizing Saltzer to Networks of Networks • Directory maintains 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. (Saltzer missed this because they hadn’t occurred yet.) • 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. Directory Route Path May 5, 10 . 13
  • 89. The Real World is More Diverse (for better or worse, OSI understood that) Subnet Independent Subnet Dependent Subnet-Access • Two distinct cases: there may be a wire or another network. – If the former, then it is a simple Data Link Layer; otherwise – Subnetwork Access, Point of Attachment (interface) addresses (X.25, IP). • X.25 not data link, because it used HDLC (LAPB) which was. – Subnet dependent convergence - if the network needed more error control – Subnet Independent (node) addresses at the top of the Network Layer (CLNP) » (Another indicator of a repeating pattern) • If there is routing in the underlying network, it is that network’s issue. • Traditional concept of layering caused problems: don’t repeat functions. May 5, 10 . 14
  • 90. To Recap Mappings between Name Spaces • Mapping between application names and node addresses: Directory. – Allows for applications moving to different systems or systems moving. • Sequence of node addresses: Routes. – Node address space is a logical abstraction of point of attachment address spaces. • Node address space must be de-coupled from the point of attachment address space(s). • Any form that concatenates a local (N)-layer identifier to an (N-1)-address to create an (N)-address will make the node address space route dependent. – From this we determine the next hop. • Mapping of node addresses to point of attachment addresses: Path. – A node needs this mapping for itself and all nearest neighbors. – Point of attachment addresses distinguish multiple paths to the next node (hop). – Note that this is the same as the Directory. • And it repeats: Node and Point of Attachment are relative, not absolutes. May 5, 10 . 15
  • 91. The Fundamental Flaw in the IP Architecture • Given what we have seen already we can see the mistake, – By following Saltzer and routing on the interface, the Internet architecture assumes there is a point-to-point line under IP. • An Internet Protocol should have networks under it. • A Network is a “wire with multiple ends”, i.e. requires addresses. – Points of attachment – Where are these in the architecture? • By routing on the interface, – IP is a Network Protocol not an Internet Protocol – After IPng’s refusal to name the node, there has been a search for a workaround. There is none. Loc/id split is simply the last attempt. It is in a very real sense post-IPng trauma. May 5, 10 . 16
  • 92. Applying Results to Real Architectures: The Internet (This is a Network Architecture) • The most striking feature is that half of the addressing architecture is missing. – No wonder there are addressing problems. – The only identifier we have for anything is the IP address. • There are no node addresses and no application names. – And the point of attachment is named twice! – If this is an Internet Protocol, where are the Network Addresses? – Domain Names are synonyms for IP addresses. URLs are pathnames through the stack and location dependent. Application Application Name Socket (local) Node Address IP Address Point of Attachment MAC Address Address May 5, 10 As if your computer worked only. with absolute memory addresses. 17
  • 93. What Does RINA Tell Us? • If networking is a distributed application that does IPC, we should start there. May 5, 10 . 18
  • 94. Communicating Processes • Application Processes exist to do work. They communicate to do that work. Communicating is not (usually) their primary raison d’etre. • So how do applications relate to communication? – Communicating applications share state on some things. – They can’t be unaware of communicating. – So what is the nature of the relation between the communication mechanism and the application process? • Now we need the Application Process/Application Entity distinction May 5, 10 . 19
  • 95. Applications and Communication Application Process Application-Entities • The Application-Entity (AE) is that part of the application concerned with communication, i.e. shared state with its peer. • 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. – An HTTP library linked into a web browser is an AE; FTP is another. May 5, 10 . 20
  • 96. Application Naming Application Process Application-Entities • Application-process names (APN) are globally unambiguous and location-independent, but system-dependent. – They may have synonyms of less scope from the same or different name space. – There may be multiple instances of the process in the same system. • APN-instance-identifiers are unambiguous within the scope of the Application Process. • Application-entity-identifiers are unambiguous within the application process. – There may be more than one Application-entity (AE) in a process. • Unambiguous within the scope of the Application Process. – There may be more than one instance of each type of Application-Entity. • AE-instance-identifiers are unambiguous within the scope of the AE. • Distributed Application Name is the name of a set of application processes and system- independent. • Few applications need all of these but a complete theory requires all of them. May 5, 10 . 21
  • 97. What Good is All This? Application Process Application-Entities • Many capabilities not possible today or that require specific protocols are a consequence of naming and enabled by a complete architecture. – Handing off a connection from one system to another; – The need to pass IP addresses among applications is avoided; – Opening multiple connections with different “protocols” to the same instance of an application process. – Connecting to an existing “conference” call, etc. May 5, 10 . 22
  • 98. What about IPC? • The IPC Model says that an IPC Process is simply an application process dedicated to doing IPC. What does this tell us about that? – There are three kinds of Application Entities: • A Flow Allocator AE to manage the creation of flows, • A Data Transfer AE to instantiate a flow, and • RIB Daemon AE to maintain shared state among the IPC Processes • Managing IPC with the (N-1)-DIF/layer May 5, 10 . 23
  • 99. What is the “Application” of an IPC Process? • What is the main work of an IPC Process? Management! – Not, Data transfer. • Managing the IPC within the Layer. – Resource Allocation – Maintaining a Resource Information Base – Routing – Security Management Allocation Mngmt Data Transfer Relaying/Muxing Update PDU Protection Daemon May 5, 10 . 24
  • 100. What about IPC Naming? • An IPC Process has an Application Process Name, give it a synonym of scope limited to the layer, and if structured to facilitate forwarding. • Commonly called an address • There are three local identifiers: – A Flow Allocator AE Instance Identifier, • Commonly called a port-id – A Data Transfer AE Instance Identifier, and • Commonly called a connection-endpoint-identifier – RIB Daemon AE to maintain shared state among the IPC Processes • Traditionally routing update. • This coupled with delta-t has major implications (later). bindings Address Port-ids CEP-ids Flows May 5, 10 . 25
  • 101. Names for IPC Port-ids Address IPC Process CEP-ids • An Address is a synonym for the IPC Process, with scope restricted to the layer and structured to facilitate forwarding within the layer/DIF. – A port-id is the handle returned to the calling application to refer to this instance of communication, unique within its AE. – A connection-endpoint-id (CEP-id) identifies the shared state of one end of a flow/connection, unique within its AE. • A connection-id identifies flows between the same two IPC Processes, formed by concatenating CEP-ids, unique within the pair • Distributed Application Name is globally unambiguous name for the set of all Application Processes in a Distributed Application, e.g. DIF. May 5, 10 . 26
  • 102. To Summarize Common Term Scope Application Term Application Process Name “Global” (unambiguous) Application Process Name Address Layer (unambiguous) Synonym for IPC Process’ Application Process Name Port-id Allocation AE (unique) Allocation AE-Instance- Identifier Connection-endpoint-identifier Data Transfer AE (unique) Data Transfer AE Instance- Identifier Connection-id Src/Dest Data Transfer AE Concatentation of data-transfer- (unique) AE-instance-identifiers DIF Management Updates IPC Process (unambiguous) AE-identifier • All identifiers except address and connection-id are local to the IPC Process. – Scope of the address is the Layer. – Scope of the connection-id is the participants in the connection. • None has more scope than it needs. May 5, 10 . 27
  • 103. Principles of Naming and Addressing: I • Application names indicate what, not where. – Hence, names are organized to put similar “whats” near each other. – So what “whats” do we use? • There is no single answer. Depends on the purpose and the importance of look up performance generally in a distributed directory. – The Scope of an Application Name Space is defined by the chain of databases pointed to by the Directory Forwarding Table. • Different Application Name Spaces may name the same objects. – It is here that the concepts of query and name merge • Some schemes will produce multiple results; some a unique result • Given the move to greater granularity more schemes will be useful in keeping them tractable and useful. – The only requirement for IPC is that some collection of synonyms be associated with an application process and their mapping to the directory are made known. May 5, 10 . 28
  • 104. Principles of Naming and Addressing: II • Addresses indicate where – Not quite – Within a DIF, the “what” of interest is “forwarding.” Synonyms are assigned to facilitate forwarding, call it a forwarding-id or f-id. – If the DIF has a sufficiently large number of members (or maybe if it doesn’t) to make F-ids more useful. • They are structured to reflect which elements are near each other for some concept of near. This is an address. • This is an “address” in the sense of its normal usage, expressing “where” without indicating “how to get there.” – An address is an synonym for an IPC Process whose scope is the DIF and structured to be useful within the layer. – “where” is just one kind of “what” – Application Names and Addresses are simply two different means for locating an object in different contexts. In this case, the object is an IPC Process. May 5, 10 . 29
  • 105. Principles of Naming and Addressing: III • A F-id (or address) is only unambiguous within the scope of a layer. – And no more, otherwise this leads to overloading the semantics of the address and leads to problems – MAC addresses are 3 times longer than they need to be. • Routes are sequences of (node) addresses. – Source routing is a “male thing,” not willing to stop and ask directions. • The relation of node and point of attachment is relative and hence irrelevant. • A node address is an (N)-F-id; • A point of attachment address is an (N-1)-F-id. – A layer routes on its address. A node address routes this layer’s address, the point of attachment address is the address of the node in the layer below and is routed by the layer below, not by this layer. May 5, 10 . 30
  • 106. Principles of Naming and Addressing: IV • Since the address is structured to facilitate its use within the layer, it must be assigned by the layer. – Only the layer knows how to make the synonym useful. • Any addresses assigned by anyone else are not addresses. • Names of systems are useful management functions, but not for forwarding. – Names of Hosts are distinct and not related to addressing. • An address should not be constructed by concatenating an identifier in this layer with one from the lower layer, i.e. don’t embed MAC addresses in IP addresses. – Why? This construction is called a pathname, hence it is route-dependent! – Addresses in adjacent layers should be completely independent. – Hierarchical address assignment within a layer organizes addresses in this layer, not the layer below. – Each layer is a level of indirection. May 5, 10 . 31
  • 107. Implications of the Naming Model: I • Recursion either reduces the number of routes or shortens them. Metros Regionals Backbone May 5, 10 . 32
  • 108. Implications of the Naming Model: III The Complexity of Routing Non-topological T opological Metros-DIF 3 O ( ( 2 D n)2 ) O ( ( D m)2 ) where n is the number of hosts and m is the number of hosts and border routers on a single subnet. Regionals-DIF 2 O((2Dn2)2 ) 2 O ( ( D m2) ) where n2 is the number of border routers around the outside and m2 is number of border routers at this level on a single subnet. Backbone-DIF 1 O((2Dn1)2 ) 2 O ( ( 2 D n1) ) where n1 is the number of border routers on the backbone. Note that m << n. • For the Internet O((6r)2 where r is the number of routers in the network. May 5, 10 . 33
  • 109. Naming Implications of the Model: II Application An Internet Provider Independent Provider dependent • Multihoming is a consequence of the structure. – Simply a layer having more than one (N-1) binding. • Since we are routing in this layer, there is no big deal – By routing on the address, the destination address is the destination regardless of which interface the PDU arrived on. It is route-independent. – With recursion, no scaling problems, no LISP, no LISP support protocols. May 5, 10 . 34
  • 110. Naming Implications of the Model: III Application An Internet Provider Independent Provider dependent • Mobility is a consequence of multihoming. – Merely acquiring new (N-1)-addresses to use or losing others. • No different than so-called “static” case, just more frequent. – (N)-address may change either by joining a different DIF • Joining another DIF is simply acquiring another point of attachment, another potential path. – or if its topological significance changes. • Assigning a new address is simply creating adding an additional synonum. Protocol processing is unaffected by the changes. May 5, 10 . 35
  • 111. Naming Implications of the Model: IV Application An Internet Provider Independent Provider dependent • How to Change the Address of a member of the DIF: – Assign the IPC Process a new synonym from the address space; – Senders use the new (N)-address as source in all active flows – Receivers record the source address of all incoming PDUs as the current address. – Advertise routes to the new address, begin to deprecate the old address – After a few routing updates, the old address simply disappears. • Changing addresses is just another name to route to. That two go to the same place is mere coincidence. • PDU Processing is unaffected by the change. May 5, 10 . 36
  • 112. Implications of the Model: V Choosing a Layer • In building the IPC Model, the first time we had multiple DIFs (data link layers in that case to choose from), we found we needed a task to figure out which DIF to use. Flow I MuxMgr D A i P r – 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. May 5, 10 . 37
  • 113. An Inter-Net Directory? • Inter-DIF Manager 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. Inter-DIF Mngr • 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. May 5, 10 . 38
  • 114. So a Global Address Space is Not Required but Neither is a Global Application Name Space Inter-DIF To Peers Directory 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. May 5, 10 . 39
  • 115. Multicast and Anycast are Simpler Too • Generalized to Whatevercast: – A set and a rule that returns as many members of the set that satisfy the rule. • Unicast becomes a degenerate case of whatevercast. – Forwarding table entry maps Destination Address to a list of next hops. For unicast, the list has one element. • Primarily handled by hosts or border routers, where all whatevercast traffic is either: • On this subnet (only do spanning tree within subnet if there is a lot) or • Transit to another subnet, (both cases degenerate to point-to-point). • So we see Whatevercast devolves into Unicast. May 5, 10 . 40
  • 116. Multicast and Anycast are Simpler Too • Information in topological addresses imply an approximate spanning tree, which can be used to identify the border routers. Thjus, in most cases obviating the need for a separate spanning tree (multicast) routing algorithm. • And also making it straightforward to multiplex whatevercasts with common sub-trees which will allow even greater efficiency. – Note that the common sub-trees do not have to be strict sub-trees but simply have a reasonable degree of commonality to be worthwhile. May 5, 10 . 41
  • 117. Next: Digging into the Details! How Does it Really Work? May 5, 10 . 42
  • 118. The Nuts and Bolts of RINA FutureNet Tutorial Part III John Day May 2010 10 May 10 © John Day, 2010 1 All Rights Reserved
  • 119. The Elements of an IPC Process Flow Allocator Delimiting Data Transfer Control Data Transfer Resource Protocol Allocator Authentication Security Module Management RIB Forwarding Table Daemon Generator (routing) SDU Relaying Protection and Multiplexing • Lets Look at Each Group of Elements in Turn – The Common Distributed Application Protocol – IPC Modules – IPC Management 10 May 10 © John Day, 2010 2 All Rights Reserved
  • 120. Common Distributed Application Protocol Authentication Module • The only application protocol that is required – DAFs may use others for backward compatibility – Used in DIFs for all non-data transfer communication • Three components: – Application Connection Establishment – Authentication (policy) – CMIP-like operations • Distinct flows allow operations on specific sets of objects 10 May 10 © John Day, 2010 3 All Rights Reserved
  • 121. CDAP: Application Connection Establishment ACRQ ACRsp • Request/Response that carries: – Source and Destination Application-Process names and Application-Entity-identifiers (including instances) as necessary. – Application-context definition (object set available) – Syntax negotiation 10 May 10 © John Day, 2010 4 All Rights Reserved
  • 122. CDAP • Why CMIP? It’s a management protocol. – Not really, it is a distributed object-oriented intermediate language – That does create/delete, read/write (get/put), action (start/stop) – With OO-support in Scope and Filter: • Scope selects the base object alone, the nth level of the base object, the base object and all its subordinates to and including the nth level, or the base object and all its subordinates. – This can be quite powerful in minimizing traffic. • Filter is an expression of assertions grouped using AND, OR, and NOT to determine equality, ordering, presence, or set comparison. – Extensions to scope and filter should be considered. • CMIP does everything required and nothing more. 10 May 10 © John Day, 2010 5 All Rights Reserved
  • 123. Why Not SNMP? • Too complex. – Implementation is larger than CMIP. • Not object-oriented, no leverage. • Too many restrictions that contribute to complexity. – Can’t retrieve entire tables – Can’t modify multiple attributes in a single operation. – Can’t, Can’t, Can’t. – It was a good protocol for the mid-80s, but was obsolete by the time it was proposed. 10 May 10 © John Day, 2010 6 All Rights Reserved
  • 124. The Use of CDAP • There are three primary uses of CDAP in a DIF: – Joining a DIF • Establishing a management connection between an new IPC Process and the members of the DIF, authenticating it, initializing it, and assigning it a forwarding-id. – Maintaining the Resource Information Base • The RIB Daemon (see below) – Flow Allocation (see below) – Everything but IPC – the actual data flow – itself 10 May 10 © John Day, 2010 7 All Rights Reserved
  • 125. The IPC Modules Data Delimiting Transfer Control Data Transfer Protocol Relaying and Multiplexing SDU Protection • There are Five Modules: – Delimiting – The Error and Flow Control Protocol consisting of: • Data Transfer (Sequencing/Fragmentation) • Data Transfer Control (Flow control and rexmsn control) – Relaying and Multiplexing – SDU Protection 10 May 10 © John Day, 2010 8 All Rights Reserved
  • 126. Delimiting • This Module delimits SDUs to ensure that the service maintains the identity on delivery. – IPC may fragment or combine SDUs but will deliver same SDUs to the destination. • External and Internal Delimiting are possible. • This module is entirely policy. – For a flow that appears to be streaming, the entire flow is a single SDU and early delivery is allowed. 10 May 10 © John Day, 2010 9 All Rights Reserved
  • 127. SDU Protection • SDU Protection is also entirely policy and may include: – Data Corruption Protection (CRCs or FECs) – Time to Live – Integrity and Confidentiality (encryption) • Below we will explore why the heavy duty mechanisms of IPsec like solutions are not required. – Compression - not really protection but this is the right place for it 10 May 10 © John Day, 2010 10 All Rights Reserved
  • 128. The Error and Flow Control Protocol Data Transfer Data Transfer Control Protocol • Based on delta-t with mechanism and policy separated. – Naturally cleaves into Data Transfer and Data Transfer Control • Data Transfer consists of tightly bound mechanisms – Roughly similar to IP+UDP • Data Transfer Control, if present, consists of loosely bound mechanisms. – Flow control and retransmission (ack) control • One instance per flow; policies driven by the QoS parameters. • Comes in several syntactic flavors based on the length of (address, connection-endpoint-id and sequence number) • Addresses: 8, 16, 32, 64, 128, variable. • CEP-id: 8, 16, 32, 64 • Sequence: 4, 8, 16, 32, 64 10 May 10 © John Day, 2010 11 All Rights Reserved
  • 129. Data Transfer InboundQ Delimit SDU Fragment/ Concatenate Reassmb/SeqQ Sequencing/ Strip Delimiting Sequence/ Reassembly/ Address Separation CRC ClsdWinQ RexmsnQ DTCP PDUs RMT CRC • The main path is simple, straightforward and potentially very fast (see specifications for details). 10 May 10 © John Day, 2010 12 All Rights Reserved
  • 130. Data Transfer PDU • Version: 8 Bit • Destination-Address: Addr-Length • Source-Address: Addr-Length • Flow-id: Struct – QoS-id: 8 Bit – Destination-CEP-id: Port-id-Length – Source-CEP-id: Port-id-length • PDUType: 8 bits • Flags: 8 bits • PDU-Length: LengthLength • SequenceNumber: SequenceNumberlength • Sequence User-Data{DelimitedSDU* | SDUFrag} 10 May 10 © John Day, 2010 13 All Rights Reserved
  • 131. Data Transfer Policies and Parameters • UnknownFlowPolicy – When a PDU arrives for a Data Transfer Flow terminating in this IPC-Process and there is no active DTSV, this policy consults the ResourceAllocator to determine what to do. • SDUReassemblyTimer Policy – this policy is used when fragments of an SDU are being reassembled and all of the fragments to complete the SDU have not arrived. Typical behavior would be to discard all PDUs associated with the SDU being reassembled. • SDUGapTimer Policy – this policy is used when the SDUGapTimer expires and PDUs have not been received to a sequence of SDUs with no gaps greater than MaxGapAllowed. Typically, the action would be to signal an error or abort the flow. • ClsdWindPolicy - This policy determines what to do if the PDU should not be passed to the RMT. • MaxPDUSize – The maximum size in bytes of a PDU in this DIF. • MaxFlowPDUSize – The maximum size in bytes of a PDU on this Flow. • SeqRollOverThres – The value at which a new flow is created and assigned to this Port-id to support data integrity. • MaxGapAllowed – The maximum gap in SDUs that can be delivered to the (N)-DIF- port without compromising the requested QoS. 10 May 10 © John Day, 2010 14 All Rights Reserved
  • 132. Data Transfer Control DT-SV DTCP Rexmsn Xmsn Ctl Ctl DTP Flow Ctl Re-xmsn Q Xmsn Control Q RMT Data Flow Control Flow • Control stays out of the main data flow. • This module will not exist for flows that don’t need it. 10 May 10 © John Day, 2010 15 All Rights Reserved
  • 133. Data Transfer Common Control Syntax Common Control PDU Selective Ack PDU Version: 8 Bits Common Control PDU Destination-Address: Addr-Length Source-Address: Addr-Length PDU TYPE = X’8004’ Flow-id: Struct Ack/Nack: Integer(SeqNbrLength) QoS-id: 8 bits Ack/Nack List Length: Integer(8) Destination-CEP-id: CEP-id-Length Ack/Nack List: Sequence(StartingNbr Integer Source-CEP-id: CEP-id-length (SeqNbrLength), Ending Integer(SeqNbrLength)) PDUType: 8 bits Flags: 8 bits PDU-Length: LengthLength Forced NackPDU SequenceNumber: SequenceNumberLength Common Control PDU PDU TYPE = X’8006’ Ack/Flow ControlPDU Ack/Nack: Integer(SeqNbrLength) Common Control PDU Ack/Nack List Length: Integer(8) PDU TYPE = X’800C’ Ack only Ack/Nack List: Sequence(StartingNbr PDU TYPE = X’800D’ Ack and Flow Control Integer(SeqNbrLength), PDU TYPE = X’8009’ Flow Control only Ending Integer(SeqNbrLength)) Ack: Integer(SeqNbrLength) RightWindowEdge:SequenceNbrLength NewRate: RateLen TimeUnit: TimeLen 10 May 10 © John Day, 2010 16 All Rights Reserved
  • 134. Data Transfer Control General Parameters and Policies • TA – Maximum time an ack is delayed before sending • TG – Maximum time to exhaust retries. • TimeUnit – for rate based flow control, i.e. # of PDUs sent per TimeUnit • FlowInitPolicy – Data Transfer Control initialization policy • SVUpdatePolicy – Updates the State Vector on arrival of a TransferPDU • LostControlPDUPolicy – What to do if a Control PDU is lost? 10 May 10 © John Day, 2010 17 All Rights Reserved
  • 135. Data Transfer Control Retransmision Policy • RTTEstimator Policy – the algorithm for estimating RTT • RetransmissionTimerExpiryPolicy - what to do when a Retransmission Timer Expires, if the action is not retransmit all PDUs with sequence numbers less than this. • ReceiverRetransmission Policy - This policy is executed by the receiver to determine when to positively or negatively ack PDUs. • SenderAck Policy - provides some discretion on when PDUs may be deleted from the ReTransmissionQ. This is useful for multicast and similar situations where one might want to delay discarding PDUs from the retransmission queue. • SenderAckList Policy - similar to the previous one for selective ack 10 May 10 © John Day, 2010 18 All Rights Reserved
  • 136. Data Transfer Control Flow Control Policies • InitialCredit Policy - sets the initial amount of credit on the flow. • InitialRate Policy - sets the intial sending rate to be allowed on the flow. • ReceivingFlowControlPolicy - on receipt of a Transfer PDU can update the flow control allocations. • UpdateCredit Policy – determines how to update the Credit field, i.e. whether the value is absolute or relative to the sequence number. • FlowControlOverrun Policy - what action to take if the credit or rate has been exceeded. • ReconcileFlowConflict Policy - when both Credit and Rate based flow control are in use and they disagree on whether the PM can send or receive data. 10 May 10 © John Day, 2010 19 All Rights Reserved
  • 137. Relaying and Multiplexing Task PDUs from EFCP & (N-1)- DIF flows Forwarding Table Queues Ports (N-1)-DIF A (N-1)-DIF B • Queues at the top are at least one per QoS Class. • Queues at the bottom are created by the Resource Allocator and may be related to the number of QoS Classes provided by the lower DIF. 10 May 10 © John Day, 2010 20 All Rights Reserved
  • 138. RMT Policies • RMTQMonitorPolicy – Policy for monitoring the status of the RMT and the QoS being provided by the (N-1)-DIF from data available to the RMT. • RMTSchedulingPolicy – Policy determines what flows are mapped to what RMT queues and how the queues are serviced. • MaxQPolicy – Policy invoked if a queue reaches its limit. 10 May 10 © John Day, 2010 21 All Rights Reserved
  • 139. Flow Allocator Allocate(Dest-Appl-Name, QoS parameters) Flow Allocator Dir Local Forwarding Dir Cache Table • When Application Process generates an Allocate request, the Flow Allocator creates a flow allocator instance to manage each new flow. • The Instance is responsible for managing the flow and deallocating the ports – DTP/DTCP instances are deleted automatically after 2MPL with no traffic, • When it is given an Allocate Request it does the following: 10 May 10 © John Day, 2010 22 All Rights Reserved
  • 140. Flow Allocator Input: Allocate Request 1) It inspects the Allocate request and maps the parameters to the appropriate QoS Class and the associated policy set. 2) It instantiates a DTP (and DTCP if necessary) for this flow. 3) Checks its local directory cache for the destination application name. If found, it sends a Create Flow request to destination address; otherwise consults the Dir Forwarding Table and sends the Create Flow request to the address noted there. 4) When it receives an Create Flow Response it executes an Allocate Response API call and modifies the state of the DTP as necessary. 10 May 10 © John Day, 2010 23 All Rights Reserved
  • 141. Flow Allocator Input: Create Flow Request • Inspect local Directory Cache for an entry that indicates where to forward the request. – Each look up hopefully gets it closer to its destination. – The directory forwarding table can create a hierarchy of databases. • When the lookup finds that the application is here, create a new flow allocator instance to manage this end of the flow, do access control, initiate the application if necessary, and give it the Allocate indication. • When the Application responds, if positive, create the local DTP/DTCP instances, allocate local ports: if negative discard the flow allocator instance; Regardless send the create flow response to the source address with the appropriate outcome. 10 May 10 © John Day, 2010 24 All Rights Reserved
  • 142. Flow Allocator Subtleties Allocate(Dest-Appl-Name, QoS parameters) Flow Allocator Dir Forwarding Table • Separating port allocation from synchronization eliminates well- known ports, and several SYN hijacking attacks. – Using Delta-t is inherently more secure the TCP • The Create Flow allows for a list of connection-endpoint-ids that can be used either in parallel or serially. – In parallel, might be used for things like p2p [sic] do. – Used serially, avoids the need for a separate security connection as in IPsec. 10 May 10 © John Day, 2010 25 All Rights Reserved
  • 143. Requests are mapped to QoS Cubes • Systems are not sufficiently sensitive to be able to deliver precise QoS values. The best that can be done is a range. Parameters identified are: Average Bandwidth Undetected bit error rate Average SDU bandwidth Partial Delivery Peak bandwidth-duration Order Peak SDU bandwidth-duration Max allowable gap in Burst period SDUs Burst duration Delay Jitter 10 May 10 © John Day, 2010 26 All Rights Reserved
  • 144. Protocols are Irrelevant QoS Cubes Allocation AE Delimiting Data Transfer Control Data Transfer Resource Protocol Allocator Authentication Security Module Management CMIP ACSE RIB Forwarding Table Daemon Generator (routing) SDU Relaying Protection and Multiplexing • Notice that we are defining policy sets driven by QoS classes and objects for management that configure a DIF. • Protocol becomes non-issue. 10 May 10 © John Day, 2010 27 All Rights Reserved
  • 145. So How Does a Flow Get Allocated? Allocate(Dest-Appl-Name, QoS parameters) To Next Place to Flow Look Create Flow Req Allocator FA-AEI Dir Forwarding Table • An Application issues an Allocate Request to the Flow Allocator. • If well-formed, spawns an instance to manage the request and the flow. • The Flow-Allocator instance looks up the destination-application-name in its local cache and finds an address to look for the requested application. • It then instantiates an EFCP instance (whose id is the CEP-id). • Forms a Create flow request and sends it. 10 May 10 © John Day, 2010 28 All Rights Reserved
  • 146. At The Next Place To Look Is this the place? To Next Place to Flow Look Create Flow Req Create Flow Req Allocator Dir Forwarding Table • Create Flow Request arrives at the next place to look. • Flow Allocator looks up the destination application name in its “local cache” • Address returned isn’t ours, so not here. • Send it there 10 May 10 © John Day, 2010 29 All Rights Reserved
  • 147. Stepping Back Establishing Communication A Ahh, a big leap! B • Remember this? • We go along looking for places to look for the requested application. 10 May 10 © John Day, 2010 30 All Rights Reserved
  • 148. Yet Another Place to Look Allocate Dest Application Allocate Confirm Indication Is this the place? Send to Requestor. Flow Create Flow Req Allocator Create Flow Resp Dir Forwarding Table • Create Flow Request arrives at yet another place to look. • Flow Allocator looks up the destination application name in its “local cache” • Address returned is ours. Its here! Check requestors credentials, if okay. • Deliver Allocate indication to the destination application • Which accepts or rejects, if accepts sends a Create Flow Response and • Instantiates a EFCP-instance • The connection is established. 10 May 10 © John Day, 2010 31 All Rights Reserved
  • 149. Finishing Up Establishing Communication A Ahh, here it is! B • The Create Flow Response is sent back to the originator. • Data can now flow. – Remember we instantiated the EFCP at the source before we started. – Just in case data gets back before the Create Response. • Either end may start the Application Protocol exchange. 10 May 10 © John Day, 2010 32 All Rights Reserved
  • 150. The Flow is Now Allocated Flow Response Arrives Allocator Create Flow Resp FA-AEI Dir Forwarding Table • The Create Flow Response arrives from the Destination • The Application is notified that the Allocate was successful and is given a port-id (in Unix this might be a file descriptor), i.e. the FA-AEI-identifier. • The application can now start exchanging information. 10 May 10 © John Day, 2010 33 All Rights Reserved
  • 151. The Management Side RIB Daemon • The OIB/RIB Daemon is a generalization and combination of three facilities: routing update, event management and the management agent and performs the following: – periodically request or notify all or a subset of members of the current value of selected information (routing update); – upon certain events, notify all or a subset of members of the current value of selected information; – the latter implies that all event notifications occurring within the DIF should be delivered to the RIB Daemon because there may be a subscription that is triggered by the event, (event management); – given that elements of the DIF members should be able to request immediate notification of an event’s arrival, have it recorded in the RIB, or both (event management); – if a log of events received is to be kept (the black box function), then the RIB Daemon is the natural place or it (event management); – given that the RIB Daemon responds to requests for information from other members of the DIF, then it is the natural place to respond to external requests for information from the DIF Management System (DMS), (management agent). 10 May 10 © John Day, 2010 34 All Rights Reserved
  • 152. The Management Side Resource Allocator • The resource allocator is the core of management in the IPC Process. The degree of decentralization depends on the policies and how it is used. • The RA has a set of meters and dials that it can manipulate • The meter fall in 3 categories: – Traffic characteristics from the user of the DIF – Traffic characteristics of incoming and outgoing flows – Information from other members of the DIF 10 May 10 © John Day, 2010 35 All Rights Reserved
  • 153. The Management Side Resource Allocator • The Dials – Creation/Deletion of QoS Classes – Data Transfer QoS Sets – Modifying Data Transfer Policy Parameters – Creation/Deletion of RMT Queues – Modify RMT Queue Servicing – Creation/Deletion of (N-1)-flows – Assignment of RMT Queues to (N-1)-flows – Forwarding Table Generator Output 10 May 10 © John Day, 2010 36 All Rights Reserved
  • 154. Initial Draft of a MIB: I IPC Process Resource Security Data Transfer AllocationAE Management Allocation Access SDU AllocationAEI Directory Authentication Forwarding Control Protection Table Mngt Forwarding Table Res Alloc Generator Policy PDU Forwarding Policy Table (e.g. Routing) One to One (N-1)-Flow Mngr One to Many 10 May 10 © John Day, 2010 37 All Rights Reserved
  • 155. Initial Draft of a MIB: II Data Transfer Dest Addr Class of Service (N-1)-Flows SDU Protection (N)-Flowa Obs. Perf QoS Queues RMT DTP DT-SV DTCP PDU Forwarding Table Reassemb Q Flow Ctl Rexmsn Ctl Policy Policy Params Params 10 May 10 © John Day, 2010 38 All Rights Reserved
  • 156. Transition? No, Adoption RINA supported Applications RINA Applications RINA Network Public Internet Rina Provider • Adopt. Don’t transition. – If the old stuff is okay in the Internet e-mall, leave it there. – Do the new sophisticated stuff 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. 10 May 10 © John Day, 2010 39 All Rights Reserved
  • 157. Aids to Adoption An Internet API Sockets to RINA API • Allows most Internet applications to work over RINA, – Some restrictions on passing addresses since RINA never exposes them. • If available on both ends, can be faked. • But with none of the benefits of RINA. – Can only connect to a new instance of an application. – There are several ways to do this. None will give you every aspect of RINA. 10 May 10 © John Day, 2010 40 All Rights Reserved
  • 158. Aids to Adoption Data Link Diversity Legacy Data Link RINA Management Protocols, e.g. 802.x etc. • To deal with the diversity at the media, use the legacy data transfer protocols, but manage it with RINA. – Provides better management. – There would be some advantage to moving to RINA data transfer as well. • Fewer protocols, less parts count, less cost, easier management, higher performance, etc. – But as an Aid to Adoption, this can be investigated. 10 May 10 © John Day, 2010 41 All Rights Reserved
  • 159. Next Steps • Standardization – We need multiple implementations to test the concepts, and serve as a sanity check on implementations and interpretation – To inter-operate, we need to standardize a number of things • Minimum common object sets and operations • Common concrete syntax(es) and data representation(s) • Interoperable common (sub)sets of policy combinations – But not all DIFs have to operate within these constraints, so research and customization is not hampered – We need an organization that can help create, promulgate, and support these standards - the Pouzin Society 10 May 10 © John Day, 2010 42 All Rights Reserved
  • 160. Next Steps (2) • Implementation Issues – WHY will people do implementations? What can we do to help them so that we raise the acceptance of this technology? – Many different execution targets: middleware, microkernel, OS, apps, dedicated/embedded • Different concerns may lead to radically different implementations – Proprietary concerns • If implementations don’t interoperate, they don’t reinforce one another • Basic technology and intellectual property needed for interoperable implementations needs to be availability without burden – Product details can generally be abstracted from DIF/protocols 10 May 10 © John Day, 2010 43 All Rights Reserved
  • 161. Next Steps (3) • Many supporting activities will be fruitful – Research and analysis of concepts – Policy research, separated from the difficulties of making new concepts work within highly-optimized legacy implementations – Tools for measurement, testing, configuration, and analysis of implementations – Tools to generate and run simulations based on common mechanism, with experimental policies plugged in as appropriate • Impractical with hand-coded implementations of protocols • Opens new opportunities for research into protocol behavior and design 10 May 10 © John Day, 2010 44 All Rights Reserved
  • 162. Next Steps (4) • We’ll be meeting this week to discuss all these issues - please feel free to join us! 10 May 10 © John Day, 2010 45 All Rights Reserved
  • 163. Conclusions • RINA is a new formulation of how to do networking – It incorporates the lessons of the last 40 years, where we’ve learned both good and bad ways to do things. We’d like to step away from many things that have not worked out well. – We don’t propose that RINA overnight replace the Internet as we know it, but rather that we begin a new age of protocol research and implementation • To add new capabilities to networks • To make networks more efficient, manageable, and secure • To get past problems that have arisen in where we are now • RINA is in its early stages of development - join us and help us mature it! 10 May 10 © John Day, 2010 46 All Rights Reserved