Recursive Internetwork Architecture: Difference between revisions

Revision as of 14:26, 2 December 2017

Revision as of 15:19, 6 April 2018

Line 15:

'''1972. Multi-homing not supported by the ARPANET'''. In 1972 the [[Tinker Air Force Base]] wanted connections to two different IMPs ([[Interface Message Processors]], the predecessors of today's routers) for redundancy. [[ARPANET]] designers realized that they couldn't support this feature because host addresses were the addresses of the IMP port number the host was connected to (borrowing from telephony). To the ARPANET, two interfaces of the same host had different addresses, therefore it had no way of knowing that they belong to the same host. The solution was obvious: as in operating systems, a logical address space naming the nodes (hosts and routers) was required on top of the physical interface address space. However, the implementation of this solution was left for future work, and it is still not done today: “IP addresses of all types are assigned to interfaces, not to nodes”.<ref name="IPv6">R. Hinden and S. Deering. "IP Version 6 Addressing Architecture". {{IETF RFC|4291}} (Draft Standard), February 2006. Updated by RFCs 5952, 6052</ref> As a consequence, routing table sizes are orders of magnitude bigger than they would need to be, and multi-homing and mobility are complex to achieve, requiring both special protocols and point solutions.

'''1978. [[Transmission Control Protocol]] (TCP) split from the [[Internet Protocol]] (IP).''' Initial TCP versions performed the error and flow control (current TCP) and relaying and multiplexing (IP) functions in the same protocol. In 1978 TCP was split from IP, although the two layers had the same scope. This would not be a problem if: i) the two layers were independent and ii) the two layers didn't contain repeated functions. However, noneneither of bothone is rightthe case: in order to operate effectively IP needs to know what TCP is doing. IP fragmentation and the workaround ofThe MTU discovery that TCP does in order to avoid itIP to happenfragmentation is a clear examplesymptom of this issueinterdependency. In fact, as early as in 1987 the networking community was well aware of the IP fragmentation problems, to the point of considering it harmful.<ref>C.A. Kent and J.C. Mogul. Fragmentation considered harmful. Proceedings of Frontiers in Computer Communications Technologies, ACM SIGCOMM, 1987</ref> However, it was not understood as a symptom that TCP and IP were interdependent and therefore splitting it into two layers of the same scope was not a good decision.

'''1981. Watson's fundamental results ignored'''. Richard Watson in 1981 provided a fundamental theory of reliable transport,<ref>R. Watson. Timer-based mechanism in reliable transport protocol connection management. Computer Networks, 5:47–56, 1981</ref> whereby connection management requires only timers bounded by a small factor of the Maximum Packet Lifetime (MPL). Based on this theory, Watson et al. developed the Delta-t protocol <ref name="deltat">R. Watson. Delta-t protocol specification. Technical Report UCID-19293, Lawrence Livermore National Laboratory, December 1981</ref> in which the state of a connection at the sender and receiver can be safely removed once the connection-state timers expire without the need for explicit removal messages. And new connections are established without an explicit handshaking phase. On the other hand, TCP uses both explicit handshaking as well as more limited timer-based management of the connection’s state. Had TCP incorporated Watson's results it would be more efficient, robust and secure, eliminating the use of SYNs and FINs and therefore all the associated complexities and vulnerabilities to attack (such as [[SYN flood]]).

Line 82:

The current architecture just provides two scopes: data link (scope of layers 1 and 2), and global (scope of layers 3 and 4). However, layer 4 is just implemented in the hosts, therefore the “network side” of the Internet ends at layer 3. This means that the current Internet is able to handle a network with heterogeneous physical links, but it is not designed to handle heterogeneous networks, although this is supposed to be its operation. To be able to do it, it would require an “Internetwork” scope, which is now missing.<ref name="lostlayer"/> As ironic as it may sound, the current Internet is not really an internetwork, but a concatenation of IP networks with an end-to-end transport layer on top of them. The consequences of this flaw are several: both inter-___domain and intra-___domain routing have to happen within the network layer, and its scope had to be artificially isolated through the introduction of the concept of [[Autonomous System (Internet)]] and an [[Exterior Gateway Protocol]];<ref name="EGP"/> [[Network Address Translation]] (NATs) appeared as middleboxes in order to have a means of partitioning and reusing parts of the single IP address space.<ref>K. Egevang and P. Francis. The IP Network Address Translator (NAT). {{IETF RFC|1631}} (Informational), May 1994. Obsoleted by {{IETF RFC|3022}}</ref>

With an internetwork layer none of this would be necessary: inter-___domain routing would happen at the internetwork layer, while intra-___domain routing within each network would occur at each respective network layer. NATs would not be required since each network could have its own internal address space; only the addresses in the internetwork layer would have to be common. Moreover, congestion could be confined to individual networks, instead of having to deal with it at a global scope as it is done today. The internetwork layer was there in previous internetwork architectures, for example, the INWG architecture depicted in Figure 3, which was designed in 1976. It was somehow lost when the [[Network Control Program]] was phased out antand the Internet officially started in 1983.

The second issue in functional layering is that each layer is supposed to provide a different function, and that this function must not be repeated in the other layers of the stack. A quick analysis on today’s protocols shows that there are repeated functions in different layers; what is more they tend to alternate: layer 1 provides multiplexing and relaying over a physical media, layer 2 provides error and flow control over a data link, layer 3 provides multiplexing and relaying over a network, layer 4 provides error and flow control end-to-end. Finally, the third issue is that layers have to be independent, in order to isolate the shared state of different scopes and allow scalability. Layer violations (layers that use other layer’s information in order to achieve their job) are in the order of the day, starting with the TCP pseudo-header calculated with the information of IP source and destination addresses.

Line 89:

===Naming, addressing, routing, mobility and multi-homing===

The current Internet architecture has an incomplete naming and addressing schema, which the reason why mobility and multi-homing require ad-hoc solutions and protocols tailored to different operational environments. The only names provided are Point of Attachment (PoA) names (IP addresses), which are usually confused to be node names. The result is that the network has no way to understand that the two or more IP addresses of a multi-homed node belong to the same node, making multi-homing hard. The same choice, naming the interface and not the node, forces the Internet to perform routing on the interface level instead of the node level, resulting in having much bigger routing tables thanmuch theylarger reallythan needwould tobe benecessary. Mobility, which can be seen as dynamic multi-homing, is the next feature that suffers from having an incomplete naming schema.

In 1982, [[Jerry Saltzer]] in his work “On the Naming and Binding of network destinations” <ref name="Saltzer">J. Saltzer. On the Naming and Binding of Network Destinations. {{IETF RFC|1498}} (Informational), August 1993</ref> described the entities and the relationships that make a complete naming and addressing schema in networks. According to Saltzer four are the elements that need to be identified: applications, nodes, points of attachment to the network (PoA) and paths. An application can run in one or more nodes and should be able to move from one node to another without losing its identity in the network. A node can be connected to a pair of PoAs and should be able to move between them without losing its identity in the network. A directory maps an application name to a node address, and routes are sequences of nodes addresses and point of attachments.

Line 95:

[[File:Saltzer-naming.png|thumb|350px|Figure 5. Saltzer's point of view on naming and addressing in computer networks.]]

Saltzer took his model from operating systems, but it was not completely correct for internetworks, since there may be more than one path between the same pair of nodes (evenlet alone whole networks!). The obvious solution is that routes are sequences of nodes, and at each hop each node chooses the most appropriate PoA (path) to forward the packet to the next node. Therefore, routing is a two-step process: First the route as a sequence of node addresses is calculated, and then, for each hop, an appropriate PoA to select the specific path to be traversed is chosen. These are the steps to generate the forwarding table,: forwarding is still performed with a single lookup. Moreover, the last step can be performed more frequently in order to exploit multi-homing for load-balancing.

With this naming structure, support for mobility and multi-homing is inherent, if the properties for the names are chosen with care: application names are ___location-independent to allow an application to move around, node addresses are ___location-dependent but route-independent. PoA addresses are by nature route-dependent. Applying this naming scheme to RINA, with recursive layers, an interesting observation can be made: mapping application names to node addresses is the same mapping than mapping node addresses to PoAs. In other words, for any layer N, nodes at the layer N+1 are applications and nodes at the layer N-1 are points of attachment, making this relationship relative.