The fundamental concept around which the architecture is built, is the information dispatch point (IDP). IDPs are inspired by the work on network pointers [9] and are also somehow similar to file descriptors and sockets in Unix systems. IDPs are typically bound to functional blocks (FB). Functional blocks are information processing units that implement data transmission functionality (for example sending and receiving of IP packets) or some additional functionality as for example traffic monitoring. Generally, functional blocks can be used to implement network services like those described in [10]. IDPs also abstract information channels (IC) via which remote nodes and protocols are reached. However, unlike file descriptors and sockets, the binding of an IDP is dynamic and may change over time as the "network stack" is re-configured. From an implementation standpoint, an IDP is identified by a randomly generated label.

In order to keep track of all available functional blocks and IDPs, there is a central entity on each node. This entity has two tables: one that describes all functional blocks and a second that stores the mappings between IDPs and functional blocks. Those tables are used to forward messages between the individual FB.

The objective of IDPs is actually two-fold: first, they provide a generic communication means between the various functional blocks running inside a node and, second, they provide the flexibility to re-organize the communication paths. Examples of such communication paths are illustrated in Fig. 1. In Fig. 1 (a), a functional block (FB1) sends data to an IDP 'a' which is bound to another functional block (FB2). In Fig. 1 (b), the IDP is rebound to the functional block FB3 and in 1 ©, the IDP is bound to the information channel IC1.

The important property of this re-binding operation is that it is not disruptive: in this example, any FB which was sending packets to IDP 'a' (e.g., FB1) continues to send to IDP 'a' without even being aware of the re-binding operation.

The IDP bindings are stored in a forwarding table within the node where each IDP is identified by a node-local label. This table, called the information dispatch table (IDT), is illustrated by Fig. 2. As shown in the figure, the IDT stores the binding between IDP values and the entity (FB or IC) to which they are bound. When a packet is sent to some IDP, it is forwarded to the FB or IC to which the IDP is currently bound. It is then up to the entity receiving a packet to decide what to do next with the packet: consume the data, add a header and reforward the packet to the next IDP, drop the packet, etc. For example, in Fig. 2, FB1 either forwards data to the IDP 'b' or directly to IDP 'c' (from which data is sent to some network interface for example). Note that a FB/IC may have multiple IDPs attached to it, as shown in the figure where IDPs 'y' and 'b' are both attached to FB2.

As previously stated, the binding of an IDP is not fixed and may be changed dynamically. For example, between Figures 2 and 3, the IDP 'a' was re-bound to functional block FB3. In order to perform a re-binding, only the entry of the particular IDP has to be changed in the information dispatch table. Note that the re-binding has been fully "transparent" to the application, which continues to send data to IDP 'a'. For packet forwarding, IDPs permit to implement forwarding tables which are fully decoupled from addresses and names: i.e., the next hop FBs (inside a node) and (remote) nodes are always identified by IDPs. This hence allows to add and use new networking technologies and protocols as long as they "export" their communication services as IDPs.

To enable communication between hosts and routers implementing and using the same set of functional blocks, we also introduce the concept of compartments. A compartment is a set of FBs, IDPs and ICs with some commonly agreed set of communication principles, protocols and policies. Typical network compartments are an Ethernet segment, the public IPv4 Internet, a private IPv4 subnet, the DNS, peer-to-peer systems like Skype, or distributed web caching networks like Akamai. Note that the concept of compartment is different to the notion of layer, in the sense that the compartment concept captures the idea of a network instance regardless of the level(s) at which it operates in the network architecture. In addition to network compartments, our architecture introduces a special compartment called the node compartment. We indeed consider each networking host to be itself a network composed by the functional blocks running on the host. The node compartment thus encompasses all FBs and IDPs within a node. Throughout this paper network compartments are depicted as dashed blue lines and the node compartment as a solid blue line.