ABSTRACT[1]
The Recursive Network Architecture (RNA) explores the relationship of layering to protocol and network architecture. RNA examines the implications of using a single, tunable protocol for different layers of the protocol stack, reusing basic protocol operations across different protocol layers to avoid reimplementation. Its primary goal is to encourage cleaner cross-layer interaction and to support dynamic service composition, and to gain an understanding of how layering affects architecture. This document provides a preliminary description of RNA, its rationale, and discusses its features and challenges.
1. INTRODUCTION
The Recursive Network Architecture (RNA) reuses a single, flexible protocol for different layers of the protocol stack. RNA allows basic protocol operations to be reused in different protocol layers, avoiding recapitulation of implementation as well as encouraging cleaner cross-layer interaction. It allows protocols and protocol stacks to adjust at runtime, which allows more dynamic composition of services, both within stacks and in the way networking combines the stacks of individual hops into an overall network architecture.
RNA helps us explore the impact of layering on network architecture and avoid redesign of basic protocol constructs used in a variety of protocol layers. By providing a basic metaprotocol – a single protocol to be instantiated at all layers of a stack – RNA facilitates the composition of as-needed stacks at runtime, based only on the capabilities required over the regions desired. This extends the notion of a single configurable protocol, as in XTP and TP++, to retain the layering necessary to partition capabilities across regions (links, subnets, nets, ASes) in a network [7][10]. The resulting architecture makes it easier to apply a wide range of capabilities throughout the stack, to combine these layers dynamically, and to integrate related capabilities like security and congestion control – at different layers using a similar API.
2. Reasons for a new architecture
The current Internet architecture has been accused of ossification, but it has demonstrated numerous extensions over the years [19]. Various layers and capabilities have been added, including shim layers like SHIM6, HIP, security with IPsec and IKE, and TLS [8][12][13][16][18]. Some facilities have been added in new protocols, e.g., multiplexing in the SCTP transport layer and BEEP session layer protocols, and addressing in IPv6 [21][26].
Many of these extensions challenge the static nature of the conventional protocol stack, introducing alternate layers that must be selected at runtime. This particularly plagues the choice between IPv4 and IPv6, which is typically solved at the application layer rather than in the interface between transport and network. It also affects the choice between TCP, DCCP, and SCTP, which suffice equally well for a number of applications [14][20][26].
Adding new services to protocol layers often recapitulates services available at existing layers. TCP included state establishment and coordination from its inception in 1981; the need for similar ‘connection’ services have crept into a number of other layers, including tunnel protocols (MPLS, GRE), key exchange and filtering protocols (GRE, IPsec/IKE), sessions (BEEP), and other transport protocols (SCTP, DCCP, RTP) [9][12][13][21] [22][25].
Virtualization has been added at a variety of layers, including link (L2VPN), network (L3VPN, X-Bone, RON, Detour), and application (DHTs) [1][2][6][24][28]. Virtual layers, like shim layers noted earlier, add layers to a formerly static protocol stack. The distinction between virtual and real layers is a somewhat artificial one, however.
RNA addresses these shortcomings of the current Internet architecture by providing a single, flexible architecture based on the reuse of a metaprotocol over different regions, and thus at different layers in the protocol stack. RNA reuses component services, such as three-way handshake, soft-state management, feedback-based congestion control, virtualization, and authentication at many protocol layers. It unifies the basic properties of a variety of protocols and protocol layers, and supports runtime protocol layer selection, enabling new dynamic stacks.
3. The Recursive Network Architecture
RNA is based on the notion that protocol stacks have design gaps, both between the layers (vertically), and between stacks (horizontally, also hop-by-hop), as shown in Figure 1. These gaps stem from the lack of understanding of how one protocol can link to or stack upon another (vertical), and how the forwarding operation (horizontal) integrates with traversing layers in a stack (vertical).
The interlayer (left) gaps affect next-layer resolution, where upper layer protocols are typically bound tightly to lower layer protocols, e.g., TCP being bound to IPv4 or IPv6 by the socket layer above TCP. The interstack gaps (right) affect next-hop resolution, in which each stack is typically bound to a particular network forwarding mechanism. RNA addresses these gaps, to enable protocol layers to be more coordinated within a stack and between different stacks throughout a network architecture.
Figure 1 Gaps in one stack (L) or between (R)
RNA uses a single metaprotocol as a generic protocol layer. This metaprotocol includes a number of basic services, as well as hooks to configurable capabilities (Figure 2). This distinguishes RNA from configurable protocol systems such as Click and Netgraph; RNA develops the generic protocol, rather than just the software system in which it could be built. The metaprotocol includes interlayer coordination, such as might integrate identity management at various layers, or couple flow control.
This metaprotocol provides the building block from which protocol layers are formed. The architecture based on this metaprotocol is based on three fundamental observations about protocol design: that services are relative to a layer, that recapitulation (including virtualization support) should be avoided, and that composition (esp. dynamic composition) should be supported.
3.1 Observation 1: Services are Relative
There are a variety of services which can be implemented at multiple layers in a conventional protocol stack, including security, reliability, state management, policy (filtering), and congestion control. A number of earlier protocol systems were developed to try to modularize these capabilities, so that a particular instance of a protocol could have only the most efficient subset enabled. The eXpress Transfer Protocol (XTP) and TP++ were two such protocol systems. These systems assumed that only a key subset of desired capabilities should be enabled at any given layer [7][10].
It is useful to note that all services are relative, local only to the layer in which they are presented. Link security operates only over a single link hop; network layer security can protect the network layer, but is not sufficient for application layer security. This hints that we should revisit some aspects of the (in)famous End-to-End (E2E) Argument, which is based on the principle of non-composition [23]:
¬ E2E Principle: End-to-end services cannot be provided solely by the composition of hop-by-hop services.
As important as the principle is, there is a corollary which is often overlooked [27]:
¬ E2E Corollary: Hop-by-hop services may help performance, but they enhance, rather than replace, corresponding end-to-end services.
Networkers are familiar with the ISO 7-layer stack, in which each layer is imbued with a particular function, and provides particular capabilities (Figure 3). For example, the data link layer is responsible for formatting the data onto the next-lower layer (physical), and the network layer is responsible for multiplexing messages from the next-higher layer (transport). RNA notes that many of these services (including the two examples) occur at many layers in the stack; data formatting is also done at the presentation layer; multiplexing is also done at the session layer.
Figure 3 ISO 7-layer reference model
RNA observes that hop-by-hop services are the definition of layer-based services; all services within a layer are local to the endpoints of that layer. The E2E Corollary suggests that it might be useful to provide almost any service at a particular layer, notably in enhancing the performance of other layers.
The notion of a protocol layer is more than just a header format and processing rules. A layer exists relative to the layers it is between in the protocol stack. A layer is also local to a region, providing services only over those regions.
A layer builds on the services provided by the layers below, and provides them to layers above. Ethernet delivers frames between Ethernet endpoints, and IP delivers packets to IP endpoints – assuming a link layer such as Ethernet coupled with a forwarding mechanism at intermediate locations. Layers are also specific to regions; IP encompasses the public Internet, but a VPN encompasses that, plus private regions as well. IP is local to a pair of end systems, whereas HTTP is local to a pair of end applications.
RNA observes that the particular services of a protocol are context dependent, relative to the layers below and above, and that the services are local to its endpoints (Figure 4). There is little other difference between protocols, however. Protocols at the link, network, transport, and session layers may all require shared state to manage authentication and its associated filtering, but the distinctions between WEP, IPsec/IKE, TCP/MD5, and TLS are less significant. There are places where a particular protocol mechanism is better suited to its context – i.e., where stateless or soft-state coordination is better than hard state, but that is based on context more than layer per se.
Figure 4 Services are local to endpoints of a layer
As a result of the current fixed layer architecture, new services are added either by wedging new layers between existing ones or by adding layers of virtualization (Figure 5, left and right respectively). Neither fits well within the current, static notion of a stack, and each begs the question of what services need to be added to existing protocol layers, and whether a new protocol is required to do so.
Figure 5 Add shim layers (L) or virtual layers (R)
As a result, in RNA, no service is specific to a particular layer; the same protocol, with a variety of services, suffices at any layer. That metaprotocol is tuned (manually or automatically) to the context at which it is deployed, and the same service may – and should – be deployed at a number of layers in the protocol stack.
3.2 Observation 2: Recapitulation is Avoidable
Offering similar services at many protocol layers invites recapitulation. There are many such examples, e.g., of security being re-implemented at the link, network, transport, session, and application layers, sometimes based on the same algorithms (e.g., DES or MD5). Some of these services include:
- handshake / state management
- security
- policy (admission control, filtering)
- multiplexing and demultiplexing
- retransmission
- reordering
- pacing / congestion control
- switching / forwarding
It is not always useful to implement all of these services at every l