Download The eXpressive Internet Architecture and more Slides Computer Networks in PDF only on Docsity!
The eXpressive Internet Architecture:
Architecture and Research Overview
Funded by the NSF under awards
CNS-1040801, CNS-1040757, CNS-1040800,
CNS-1345305, CNS-1345307, CNS-1345284, and CNS-
1 XIA Architecture Overview
The goal of the XIA project is to radically improve both the evolvability and trustworthiness of the In- ternet. To meet this goal, the eXpressive Internet Architecture defines a single network that offers inher- ent support for communication between multiple communicating principals–including hosts, content, and services–while accommodating unknown future entities. Our design of XIA is based on a narrow waist, like today’s Internet, but this narrow waist can evolve to accommodate new application usage models and to incorporate improved link, storage, and computing technologies as they emerge. XIA is further designed around the core guiding principle of intrinsic security, in which the integrity and authenticity of communi- cation is guaranteed. We have also defined an initial inter-domain control plane architecture that support routing protocols for several principal types. Finally, the XIA core architecture includes the design of Scion, a path selection protocol that supports significant security benefits over traditional destination forwarding approaches.
1.1 Vision
The vision we outlined for the future Internet in the proposal is that of a single internetwork that, in contrast to today’s Internet, will: Be trustworthy: Security, broadly defined, is the most significant challenge facing the Internet today. Support long-term evolution of usage models: The primary use of the original Internet was host-based communication. With the introduction of the Web, over the last nearly two decades, the communication has shifted to be dominated today by content retrieval. Future shifts in use may cause an entirely new dominant mode to emerge. The future Internet should not only support communication between today’s popular entities (hosts and content), but it must be flexible, so it can be extended to support new entities as use of the Internet evolves. Support long-term technology evolution: Advances in link technologies as well as storage and com- pute capabilities at both end-points and network devices have been dramatic. The network architecture must continue to allow easy and efficient integration of new link technologies and evolution in functionality on all end-point and network devices in response to technology improvements and economic realities. Support explicit interfaces between network actors: The Internet encompasses a diverse set of actors playing different roles and also serving as stakeholders with different goals and incentives. The architecture must support well-defined interfaces that allow these actors to function effectively. This is true both for the interface between users (applications) and the network, and between the providers that will offer services via the future Internet.
This vision was the driver for both the original and the current XIA project.
1.2 Key Principles driving XIA
In order to realize the above vision, the XIA architecture follows three driving principles:
- The architecture must support an evolvable set of first-order principals for communication, exposing the respective network elements that are intended to be bridged by the communication, be they hosts, services, content, users, or something as-yet unexpected. Performing operations between the appropriate principal types creates opportunities to use communica- tion techniques that are most appropriate, given the available technology, network scale, destination popular- ity, etc. Such “late binding” exposes intent and can dramatically reduce overhead and complexity compared with requiring all communication to operate at a lower level (e.g., projecting all desired communications onto host-to-host communications, as in today’s Internet), or trying to “shoe-horn” all communication into a higher level (e.g., using HTTP as the new narrow waist of the Internet [96]). A set of evolvable principal types is however not sufficient to support evolution of the network archi- tecture. Experience so far shows that the concept of fallbacks is equally important. Allowing addresses to contain multiple identifiers supports only incremental deployment of principal types, but selective deploy- ment by providers and network customization.
- The security of “the network”, broadly defined, should be as intrinsic as possible—that is, not dependent upon the correctness of external configurations, actions, or databases. To realize this principle, we propose to extend the system of self-certification proposed in the Account- able Internet Protocol (AIP) [11]. In AIP, hosts are “named” by their public key. As a result, once a correspondent knows the name of the host they wish to contact, all further cryptographic security can be handled automatically, without external support. We call the generalization of this concept “intrinsic security”. Intuitively, this refers to a key integrity property that is built in to protocol interfaces: any malicious perturbation of an intrinsically secure proto- col must yield a result that is clearly identifiable as ill-formed or incorrect, under standard cryptographic assumptions. We extend the application and management of self-certifying identifiers into a global frame- work for integrity such that both control plane messages and content on the data plane of the network can be efficiently and certifiably bound to a well-defined originating principal. Intrinsic security properties can also be used to bootstrap systematic mechanisms for trust management, leading to a more secure Internet in which trust relationships are exposed to users.
- A pervasive narrow waist for all key functions, including access to principals (e.g., service, hosts, content), interaction among stakeholders (e.g., users, ISPs, content providers), and trust management. The current Internet has benefited significantly from having a “narrow waist” that identifies the minimal functionality a device needs to be Internet-capable. It is limited to host-based communication, and we propose to widen its scope while retaining the elegance of “narrowness”. The narrow waist effectively is an interface that governs the interactions between the stakeholders, so it defines what operations are supported, what controls are available, and what information can be accessed. It plays in key role in the tussle [27] of control between actors by creating explicit control points for negotiation. The architecture must incorporate a narrow waist for each principal type it supports. The narrow waist identifies the API for communication between the principal types, and for the control protocols that support the communication. The architecture must also define a narrow waist that enables a flexible set of mechanisms for trust management, allowing applications and protocols to bridge from a human-readable description to a machine-readable, intrinsically secure, identifier. Our experience so far shows that precise, minimal interfaces are not only important as control points
point in time, support for certain principal types, e.g. autonomous domains, will be mandatary to ensure interoperability, while support for other principal types will be optional. Support for an optional principal type in a specific network will depend on business and other considerations. IP is notoriously hard to secure, as network security was not a first-order consideration in its design. XIA aims to build security into the core architecture as much as possible, without impairing expressiveness. In particular, principals used in XIA source and destination addresses must be intrinsically secure. We define intrinsic security as the capability to verify type-specific security properties without relying on external information. XIDs are therefore typically cryptographically derived from the associated communicating entities in a principal type-specific fashion, allowing communicating entities to ascertain certain security and integrity properties of their communication operations [9]. The specification of a principal type must define:
- The semantics of communicating with a principal of that type.
- A unique XID type, a method for allocating XIDs and a definition of the intrinsic security properties of any communication involving the type. These intrinsically secure XIDs should be globally unique, even if, for scalability, they are reached using hierarchical means, and they should be generated in a distributed and collision-resistant way.
- Any principal-specific per-hop processing and routing of packets that must either be coordinated or kept consistent in a distributed fashion.
These three features together define the principal-specific support for a new principal type. The follow- ing paragraphs describe the administrative domain, host, service, and content principals in terms of these features. Network and host principals (NIDs and HIDs) represent autonomous routing domains and hosts that attach to the network. NIDs provide hierarchy or scoping for other principals, that is, they primarily provide control over routing. Hosts have a single identifier that is constant regardless of the interface used or network that a host is attached to. NIDs and HIDs are self-certifying: they are generated by hashing the public key of an autonomous domain or a host, unforgeably binding the key to the address. The format of NIDs and HIDs and their intrinsic security properties are similar to those of the network and host identifiers used in AIP [11]. Services represent an application service running on one or more hosts within the network. Examples range from an SSH daemon running on a host, to a Web server, to Akamai’s global content distribution service, to Google’s search service. Each service will use its own application protocol, such as HTTP, for its interactions. An SID is the hash of the public key of a service. To interact with a service, an application transmits packets with the SID of the service as the destination address. Any entity communicating with an SID can verify that the service has the private key associated with the SID. This allows the communicating entity to verify the destination and bootstrap further encryption or authentication. In today’s Internet, the true endpoints of communication are typically application processes—other than, e.g., ICMP messages, very few packets are sent to an IP destination without specifying application port numbers at a higher layer. In XIA, this notion of processes as the true destination can be made explicit by specifying an SID associated with the application process (e.g., a socket) as the intent. An NID-HID pair can be used as the “legacy path” to ensure global reachability, in which case the NID forwards the packet to the host, and the host “forwards” it to the appropriate process (SID). In [51], we show and example of how making the true process-level destination explicit facilitates transparent process migration, which is difficult in today’s IP networks because the true destination is hidden as state in the receiving end-host. Lastly, the content principal allows applications to express their intent to retrieve content without regard to its location. Sending a request packet to a CID initiates retrieval of the content from either a host, an
in-network content cache, or other future source. CIDs are the cryptographic hash (e.g., SHA-1, RIPEMD-
- of the associated content. The self-certifying nature of this identifier allows any network element to verify that the content retrieved matches its content identifier.
1.3.2 Addressing Requirements
Three key innovative features of the XIA architecture are support for multiple principal types that allow users to express their intent, support for evolution, and the use of intrinsically secure identifiers. These features all depend heavily on the format of addresses that are present in XIA packets, making the XIA addressing format one of the key architectural decisions we have to make. While this may seem like a narrow decision, the choice of packet addressing and the associated packet forwarding mechanisms have significant implica- tions on how the network can evolve, the flexibility given to end hosts, the control mechanisms provided to infrastructure providers, and the scalability of routing/forwarding. We elaborate on the implications of each of these requirements before presenting our design. The scalability requirements for XIA are daunting. The number of possible end-points in a network may be enormous - the network contains millions of end-hosts and services, and billions of content chunks. Since XIA end-points are specified using flat identifiers, this raises the issue of forwarding table size that routers must maintain. To make forwarding table size more scalable, we want to provide support for scoping by allowing packets to contain a destination network identifier, in addition to the actual destination identifier. Evolution of the network requires support for incremental deployment, i.e. a particular principal type and its associated destination identifiers may only be recognized by some parts of the network. Packets that use such a partially supported principal type may encounter a router that lacks support for such identifiers. Simply dropping the packet will hurt application performance (e.g. timeouts) or break connectivity, which means that applications will not use principal types that are not widely supported. This, in turn, makes it hard to justify adding support in routers for unpopular types. To break out of this cycle, the architecture must provide some way to handle these packets correctly and reasonably efficiently, even when a router does not support the destination type. XIA allows packets to carry a fallback destination, i.e. an alternative address, a set of addresses or a path, that routers can use when the intended destination type is not supported. In the Internet architecture, packets are normally processed independently by each router based solely on the destination address. “Upstream” routers and the source have little control over the path or processing that is done as the packet traverses the network. However, various past architectures have given additional control to these nodes, changing the balance between the control by the end-point and control by the infrastructure. For example, IP includes support for source routing and other systems have proposed techniques such as delegation. The flexibility provided by these mechanisms can be beneficial in some context, but they raise the challenge of how to ensure that upstream nodes do not abuse these controls to force downstream nodes to consume resources or violate their normal policies. In XIA, we allow packets to carry more explicit path information than just a destination; thus, giving the source and upstream routers the control needed to achieve the above tasks. The above lays out the requirements for addressing in packets, and indirectly specifies requirements for the forwarding semantics. We now present our design of an effective and compact addressing format that addresses the evolution and control requirements. Next, we discuss the forwarding semantics and router processing steps for XIA packets.
1.3.3 XIA Addressing
XIA’s addressing scheme is a direct realization of the above requirements. To implement fallback and scoping, XIA uses a restricted directed acyclic graph (DAG) representation of XIDs to specify XIP ad- dresses [51]. A packet contains both the destination DAG and the source DAG to which a reply can be sent.
Figure 2: Packet Forwarding in an XIP router
packet destined for: • → NID 1 → SID 1. A router inside NID 1 routes the request to a host that provides SID 1. The service replies with a source address bound to the host, • → NID 1 → HID 1 → SID 1 , to which subsequent packets can be sent. More usage models for DAGs are presented in [10]. It is important to view DAGs, and not individual XIDs, as addresses that are used to reach a destination. As such, DAGs are logically equivalent to IP addresses in today’s Internet. This means that the responsibility for creating and advertising the address DAG for a particular destination, e.g., a service or content provider, is the responsibility of that destination. This is important because the desitnation has a strong incentive to create a DAG that will make it accessible in a robust and efficient way. Address look up can use DNS or other means. The implications of using a flexible address format based on DAGs are far-reaching and evaluating both the benefits and challenges of this approach is an ongoing effort. Clearly, it has the potential of giving end- points more control over how packets travel through the network, as we discuss in more detail in Section 1.8.
1.3.4 XIA Forwarding and Router Processing
DAG-based addressing allows XIA to meet its goals of flexibility and evolvability, but this flexibility must not come at excess cost to efficiency and simplicity of the network core, which impacts the design of our XIA router. In what follows, we describe the processing behavior of an XIA router and how to make it efficient by leveraging parallelism appropriately. Figure 2 shows a simplified diagram of how packets are processed in an XIA router. The edges represent the flow of packets among processing components. Shaded elements are principal-type specific, whereas other elements are common to all principals. Our design isolates principal-type specific logic to make it easier to add support for new principals. Before we go through the different steps, let us briefly look at three key features that differ from tradi- tional IP packet processing:
- Processing tasks are separated in XID-independent tasks (white boxes) and XID-specific tasks (col- ored boxes). The XID-independent functions form the heart of the XIA architecture and mostly focus on how to interpret the DAG.
- There is a fallback edge that is used when the router cannot handle the XID pointed at by the last- visited XID in the DAG, as explained below.
- In addition to having per-principal forwarding functions based on the destination address, packet forwarding allows for processing functions specific to the principal type of the source address.
We now describe the steps involved in processing a packet in detail. When a packet arrives, a router first performs source XID-specific processing based upon the XID type of the sink node of the source DAG. For example, a source DAG • → NID 1 → HID 1 → CID 1 would be passed to the CID processing module.
Figure 3: XIA as a combination of three ideas
By default, source-specific processing modules are defined as a no-op since source-specific processing is often unnecessary. In our prototype, we override this default only to define a processing module for the content principal type. A CID sink node in the source DAG represents content that is being forwarded to some destination. The prototype CID processing element opportunistically caches content to service future requests for the same CID. The following stages of processing iteratively examine the outbound edges of the last-visited node (field LN in the header) of the DAG in priority order. We refer the node pointed by the edge in consideration as the next destination. To attempt to forward along an adjacency, the router examines the XID type of the next destination. If the router supports that principal type, it invokes a principal-specific component based on the type, and if it can forward the packet using the adjacency, it does so. If the router does not support the principal type or does not have an appropriate forwarding rule, it moves on to the next edge. This enables principal-specific customized forwarding ranging from simple route lookups to packet replication or diversion. If no outgoing edge of the last-visited node can be used for forwarding, the destination is considered unreachable and an error is generated. We implement a prototype of the XIP protocol and forwarding engine. It also includes a full protocol stack. The status of the prototype is discussed in more detail in Section 12.1.
1.4 Deconstructing the XIA Data Plane
While we defined XIA as a comprehensive Future Internet Architecture, we also found it useful from a research perspective to view XIA as three ideas that, in combination, form the XIA architecture. This ap- proach helps in comparing different future Internet architecture, in evaluating the architecture, e.g. by being able to evaluate the benefits of individual ideas in different deployment environments, and in establishing collaborations, e.g. by focusing on ideas rather than less critical details such as header formats. Figure 3 shows how XIA can be viewed as a combination of three ideas: support for multiple principal types, intrinsic security. XIA also proposes a specific realization for each idea: we have specific proposals for an initial set of principal types and their intrinsic security properties, and for flexible addressing. Other future Internet architecture proposals can differ in the ideas they incorporate and/or how they implement those ideas. The ideas in Figure 3 are largely orthogonal. For example, it is possible to have a network that supports multiple principal types, without having intrinsic security or flexible addressing. Similarly, network can provide intrinsic security for a single principle type (e.g. as shown in AIP [11], which in part motivated XIA), while it is possible to support flexible addressing, e.g. in the form of alternate paths or destinations, without supporting intrinsic security. While it is possible to build an architecture around just one or two of the ideas, there is significant benefit to combine all three, as we did in XIA, since the ideas leverage each
Figure 4: Bank of the Future example scenario.
ID SIDBoF to a public key for the service. One or more servers in the BoF data center will also advertise SIDBoF within the BoF’s data center network, i.e. administrative domain ADBoF (Step 3). The focus of the example is on a banking interaction between a BoF client C (HIDC). The first step is to resolve the name bof.com by contacting the Name Resolution Service using SIFResolv (Step 4), which was obtained from a trusted source, e.g. a service within ADC. The client now connects to the service by sending a packet destined to ADBoF : SIDBoF using the socket API. The source address for the packet is ADC:HIDC:SIDC, where ADC is the AD of the client, HIDC is the HID of the host that that is running the client process, and SIDC is the ephemeral SID automatically generated by connect(). The source address will be used by the service to construct a return packet to the client. The packet is routed to ADBoF , and then to S, one of the servers that serves SIDBoF (Step 5). After the initial exchange, both parties agree on a symmetric key. This means that state specific to the communication between two processes is created. Then the client has to send data specifically to process P running at S, not any other server that provides the banking service. This is achieved by having the server S bind the service ID to the location of the service, ADBoF : HIDS, then communication may continue between ADBoF : HIDS : SIDBoF and ADC:HIDC:SIDC (Step 6). Content can be retrieved directly from the server, or using content IDs, allowing it to be obtained from anywhere in the network. The initial binding of the banking service running on process P to HIDS can be changed when the server process migrates to another machine, for example, as part of load balancing. Suppose this process migrates to a server with host ID = HIDS 2 (Step 7). With appropriate OS support for process migration, a route to SIDBoF is added on the new host’s routing table and a redirection entry replaces the routing table entry on HIDS. After migration, the source address in subsequent packets from the service is changed to ADBoF : HIDS 2 : SIDBoF. Notification of the binding change propagates to the client via a packet with an SID extension header containing a message authentication code (MAC) signed by SIDBoF that certifies the
Figure 5: Multi-party conferencing example
binding change (Step 8). A client move to a new AD, ADC 2 , can be handled the same way (Step 9). The new source address of the client will then be ADC 2 :HIDC:SIDC (Step 10). When a new packet arrives at the server, the server will update the client’s address. Even though locations of both the server and the client have changed, the two SID end-points –and therefore their cryptographic verifiability– remain the same.
1.6 Interactive conferencing systems
We use an interactive conferencing system as another use scenario for XIA. This research was performed by Wei Shi as part of his undergraduate honors thesis, advised by PI Peter Steenkiste.
1.6.1 Background
With the availability of the XIA prototype (and its Xsocket API) as a platform for application development, we started to develop various user applications over XIA. Among them, we started to explore how to best support multi-party interactive conferencing, called Voice-over XIA (VoXIA). This serves a good example to show how the flexibility of using multiple principal types in XIA can deliver benefits for conversational communication applications that are important in the Internet today.
1.6.2 Approach and Findings
We compared different design options for the VoXIA appliation. We implemented a basic application with the following features: (1) each node uses the same (predefined) SIDVoXIA for the VoXIA application; (2) each node registers its own unique VoXIA identifier (VoXIA ID); (3) and binds this VoXIA ID to its DAG, e.g., AD : HID : SIDVoXIA. For the voice software stack, we used the Speex protocol for compressing audio frames and PortAudio for recording and playing back audio. In order to examine whether the use of multiple principal types in XIA can offer advantages over tra- ditional host-based communication in this context, we developed two different VoXIA designs. The first method is to send and receive all frames via XDP sockets (UDP style) and thus, no in-network caching is supported. This serves as a measurement baseline, which represents the traditional host-based communi- cation. The second one is to use XDP sockets only for exchanging a list of frame pointers (CIDs) and use XChunkP sockets (chunk transmission) for retrieving the actual voice frames. This method is supported by in-network caching, as XChunkP communication uses the content principal type. VoXIA experiments over GENI (five end-hosts and two routers) show that the chunk-style VoXIA is advantageous when multiple nodes request the same set of frames since they can effectively utilize the in-network caching. Figure 5 shows an example with four nodes that are are geographically distributed. After Node 3 retrieves a frame from Node 1, it is likely to be available in the content caches of the routers, where it can be efficiently retrieved by Nodes 2 and 4.
Figure 7: Scion trust domains, beaconing, and path selection.
be incorporated into the XIA control plane. First, Scion [124, 57] supports path-based communication in which packets are forwarded based on a previously allocated inter-domain path (Figure 7). For each edge domain, the ISPs establish a number of paths connecting that domain to the core of the Internet (sequence of straight arrows in the figure). These paths adhere to the business policies of the ISPs and may have different properties. Two domains can then communicate by choosing one of their paths and merging them to form an end to end path (e.g., AD1-AD2 and AD3-AD2 in the figure). Scion path based communication uses a new XID type, Scion IDs, and and edge networks can choose between forwarding based on destination NID or Scion IDs. The latter are more secure and offer more path control than NIDs. Second, Scion introduced several new concepts and mechanisms to securely establish and maintain paths. First, it introduced Trust Domains (TD) as a way of reducing the Trusted Computing Base for paths. This is achieved by grouping in domains in independent routing sub-planes (two in the figure). Second, it uses a beaconing protocol to identify possible paths; beacons are created by the domain in the TD root and forwarded towards the edge network. Finally, Scion uses a trust domain infrastructure in which domain share certificates to authenticate themselves. While these techniques were designed within the context of Scion, they are independent of the Scion path selection protocol and we plan to use them to enhance the security of XIAs inter-domain control plane.
1.8 Exposing and Using Control Points
The XIP protocol effectively represents the dataplane interface between network users and domains. It represents a control point that allows actors to engage in a tussle “at runtime” to define a communication agreement that meets their policy, economic, legal and other requirements [27]. Compared with IP, XIP offers significant flebility in how communication operations are performed (fourth point of the vision in Section 1.1). First, multiple principal types give users (applications or hu- man users) a choice of how to use the network. This choice affects not only performance but also privacy (CIDs potentially expose more information) and control. Similar, service providers have a choice in what principal types to support, e.g., based on economic considerations. Second, DAGs as flexible addresses that are much more expressive than today’s Internet addresses, given users a lot more control over how a packet is handled, through the use of fallbacks, weak source routing and possibly the specification of multiple paths or multiple sinks [10]. Finally, SCION offers the user a choice over the path that its packets will take through
the network, as we explain next. Experience with XIA so far shows however that flexible data plane interfaces are not sufficient to build a network that is evolvable and flexible. We also need to rethink the control plane interfaces for routing for the various principal types and resource management on a variety of time scales (congestion control, traffic engineering). Appropriate interfaces are needed not only between the ISPs but also between ISPs and their customers (residential and corporate networks, service providers, CDNs, etc.). While we have done some initial research in this area, this a central theme in our current research.
To establish a communication session with a mobile device, a corresponding client will first do a name lookup. As shown in Figure 8(left), the address DAG that is returned could include the device’s “home” locator (NIDH : HID) as the intent, and the location of a rendezvous service (NIDS : SID)) as the fallback. If the device is attached to its home network, it is delivered by following dashed Arrow 1 in the DAG. If not, it is automatically delivered to the rendezvous service using the fallback (Arrow 2). The rendezvous service could be located anywhere. For example, it could be hosted by the home network as in mobile IP, or could be a distributed commercial service. When it receives the packet, the rendezvous service looks up the current DAG address for the mobile device and forwards the packet (Arrow 3). The mobile device can then establish the connection with the communicating client. It also provides the corresponding host with its new address as described below, so future packets can be delivered directly to the new address. Clearly, other DAG formats are possible. For example, the mobile device could register the DAG of its rendezvous service with its name service when it leaves its home network, so connection requests are directly forwarded to the rendezvous service. The above solution is simple but it is not secure. A malicious party can easily intercept a session by registering its own DAG with the rendezvous service, impersonating the mobile device. The solution is to require that address registrations with the rendezvous are signed by the mobile device. This can be done in a variety of ways. For example, the mobile device can receive a shared key or other credentials when it signs up with the mobile device. In XIA, we can leverage intrinsic security. The mobile device uses the public key associated with SID in its “home” DAG address so the rendezvous service can verify the authenticity of registration without needing a prior agreement with the mobile device. We use the SID to sign the registration since it is typically the “intent” identifier, i.e., it is the true end-point associated with the DAG. In contrast, HIDs and NIDs in the DAG can change over time. The implementation of the rendezvous service raises two design questions. First, where should it be implemented in the protocol stack. Logically, it acts as a layer 3 forwarding element. It uses a forwarding table to forward packets at layer 3, but that table is directly filled in by endpoints, rather than by a traditional routing protocol. However, for simplicity of code development, we decided not to implement it at layer 3 inside click. Instead, it is is an application level process that uses the raw Xsocket interface to send and receive layer 3 packets (that include the XIA header). A second design decision is how the rendezvous service forwards packets to the client. Options include dynamic packet encapsulation or address rewriting. We decided to use address rewriting, i.e. replace the client’s old address with its new address, because it does not affect packet length, does avoiding packet fragmentation issues. To maintain an active session during mobility, the mobile host keeps the stationary host informed of its new address [51], as shown in Figure 8(right). Again, we must decide where to implement this functionality. For network-level mobility, layer 3 would be the natural place in the protocol stack. Unfortunately, since XIP is a connection-les protocol, it does not know what active (layer 4 and higher) sessions exist. In our solution, the XIP protocol prepares a change-of-address record, which is passes on to any software module (transport protocol, applications, etc.) that registered an interest in learning about address changes. These modules are then responsible for forwarding the address change to any relevant parties. In our implementation, the reliable transport protocol inserts the change of address record in the data stream, marked as control information. The change of address record is signed using the private key of the SID associated with The endpoint of the connection, as explained earlier. Status and future work - We have implemented both mechanisms and have shown that they work. Both mechanisms are very responsive, and the current bottleneck in network-level handoff is the old and slow XHCP protocol that is currently used to join a new network. Future work will focus on optimizing the protocol used to join a network and transport and session level support to optimize network performance during network mobility.
Figure 9: Using the 4ID principal type to incrementally deploy XIA
2.2 Incremental deployment
We explored whether XIA’s flexible addressing could be used to help with incremental deployment of XIA nodes and networks in IPv4 networks. This research was performed by CMU Ph.D. student Matt Mukerjee, advised by PIs Seshan and Steenkiste. Background - One of the bigest hurdles facing a new architecture is deployment in the real world over an existing infrastructure. For example, several past designs including IP Multicast, different QoS designs, and IPv6, have faced significant deployment challenges over the current IPv4 infrastructure. The most common approach that past systems have taken is the use of an overlay network. Both IPv6 and IP Multicast operate a virtual backbone - the 6bone and Mbone, respectively. Users who wish to make use of IPv6 or IP Multicast must create an overlay network link or tunnel that connects them to the backbone. Unfortunately, creating such links is a complicated process and this has limited the wide adoption of these protocols. Recent efforts [86] have tried to automate this process; however, other weaknesses associated with a tunnel-based scheme remain. By analyzing the range of IPv6 deployment methods, it quickly becomes clear that any proper de- ployment method must have certain qualities. A first key requirements is that there should be no explicit tunneling between disjoint clouds since it is a fragile. Also, there should be no address mapping that takes old addresses and puts them into the new address space. Allowing this severely limits the usefulness of the new network to the constrains of the old network. Desirable properties include minimal configuration, automatic adaptation to unforeseen changes in the underlying network topology or failure of nodes/links, and graceful degradation. Our initial design to address these requirements in XIA introduces a new XID type that we call a 4ID (named for IPv4 ID). Consider a scenario with two nodes, A and B, that are located in different XIA-based networks attached to the IPv4 Internet at different locations. Each of the two networks has a least one node that operates as a dual-stack router (i.e., a router that connects to both the XIA local network and the IPv network). In order for A to transmit a packet to B, the destination DAG address will contain the IPv4 address of B’s network’s dual-stack router as a fallback address. This entry will be encoded inside and XIA address with the type labeled as a 4ID. This design takes advantage of the fact that XIA packets can carry multiple addresses and encode relative priorities across them. In addition, unlike past designs, there is no use of a virtual backbone and no need to setup tunnels. Figure 9 illustrates the example. The dual stack router in network A will first try to forward the packet based on the intent identifier, ADS, but it does not not have a forwarding entry ADS, so it needs to use the fallback. After encapsulating the packet into an IPv4 packet using the IPv4 address enclosed in 4IDS, the packet can be delivered over the IPv4 network to ADS. The dual stack router in network B will remove the IPv4 header and forward the packet to the destination using XIP. Once the IPv4 network is upgraded to XIA,
Figure 10: Architecture for SID anycast.
- Responsiveness Decision making should be responsive to changes in the system conditions.
- Efficiency Initial request packets should be handled efficiently since many service sessions are short- lived.
- Scalability The system must have low overhead so it can scale to a potentially large number of services and client domains.
- Availability The system must have high availability, even if parts of the anycast architecture fail.
Related work in this area falls broadly in two categories. The first one is exemplified by IP anycast [93], which supports anycast over the current Internet. Its current implementation [2, 66] leverages BGP [101]. This means that instances are selected using BGP-type criteria (AD path length, etc.). While this may be sufficient for DNS [55], it does not meet the requirements of more demanding services. The most commonly used anycast service today is DNS-based. Specifically, the DNS server of the service provider will selected a service instance and return it in the form of an IP address to the client. This approach has the advantage that the service provider is fully in control of the selection process and can apply any policy they want. There are however a number of limitations and drawbacks. First, the DNS server does not have access to any network information; all it knows is an estimated location based on the client’s request. Second, it adds a roundtrip worth of latency to service access. Finally, this approach introduces a fair bit of overhead since caching of DNS responses has to be limited to make the system responsive to failures and changes in load. Approach and Findings - The key idea underlying our design that we want to place instance selection in the hands of service providers so rich policies can be implemented, but instead of relying on DNS, we want to use routing so we can incorporate more accurate information about network conditions and avoid the roundtrip latency associated with a DNS lookup. The high level design is shown in Figure 10. The figure shows an SID-enables domain with an SDN style control plane, consistent with the XIA control plane architecture (Section 1.7). The SDN controller runs an SID routing application, service router, that, together with a set of service controllers that are colocated with each service instance for a set of SIDs, implement anycast. Consistent with the 4D architecture [49], the service routers and controllers together implement discovery, dissemination and decision functions. As a first step, service controllers will use beacons to advertise their presence, allowing service routers to identify available service instances and establish communication sessions with their service controllers (step
1). Next, a network measurement application in each SID-enabled domain will collect network performance data (e.g., latency and bandwidth to service instances) and make this information available to the service controllers; we discuss the placement of SID-enabled domains later. The services controllers for each SID will then jointly decide on how service routers should forward SID requests to service instances using both the information provided by the service controllers and internal information such as service load and policies (step 3). They then forward these decisions to the service routers (step 4), which will distribute it to routers in their domain as needed (step 5). SID requests from clients will now be forwarded to the appropriate service instances without incurring additional latency (step 6). Let us elaborate on some of the key steps. First, the simplest outcome of the decision step (step 3) would be to create a forwarding entry for an SID that points at a single service instance. Unfortunately, unless the service provider has a presence in a large number of SID-enabled domains, which may not be practical for smaller service providers, this simple approach would limit load balancing options. For this reason, we are exploring an alternative design where a forwarding entry for an SID can include multiple service instances with a target load distribution. Second, our design assumes that the information collected in step 2 is representative for clients. This requires SID-enabled domains to be at the edge of the Internet, near or even inside client networks. Clearly, increasing the number of domains will improve performance. Finally, in order to keep track of changing network and server conditions, routing updates will happen periodically. Service controllers can also push updates at any time, for example to respond to failures of sudden changes in the network or load. This should improve both responsiveness and availability. This design meets the requirements we identified above by combining the benefits of the DNS-style approach with those of a routing solution.
2.4 Pushing the evolvability envelop
The XIA group at Boston University has realized a Linux implementation of the core XIA network archi- tecture and has been exploring how other FIA features can be integrated into Linux XIA at the network layer. The primary goal of this effort is fourfold: to streamline upcoming network deployments of XIA, to provide a concrete demonstration of XIA’s capability to evolve and import novel architectural function- ality created by others, to facilitate other network researchers to conduct architectural evaluations enabled by the existence of Linux XIA, and to reach beyond network researchers to other potential early adopters of XIA. This effort has been spearheaded by post-doctoral researcher Michel Machado and PI John Byers. Other team members contributing in this reporting period are PhD students Cody Doucette and Qiaobin Fu, undergraduate Alexander Breen, and Boston Academy High School student Aaron Handelman. Background - In the FIA-funded FIA XIA project, Boston University implemented an XIA protocol stack natively in Linux and started to use this implementation as a basis for realizing other FIA architectures as principals within the XIA framework. As described in Michel Machado’s Ph.D. thesis [82], the team ported the Linux implementation of the Serval service-centric architecture to XIA, and produced white paper ports of the NDN architecture, as well as the MobilityFirst architecture, and the ANTS active network protocol. XIA was able to accomodate these “foreign” architectures by introducing new principal types and using the flexible addresses, as described in previous annual reports. Another interesting take-away finding was that realizing Serval in XIA directly activates intrinsic security, cleanly remediating a key weakness in the original “Serval over IP” design. Findings - In this reporting period, the Boston team continued to build out functionality on Linux XIA, providing support for multicast using the zFilter framework from the PURSUIT project (a European future architecture), and focusing on interoperability. The goal was to evaluate how effectively and efficiently XIA’s architectural principles supports networking features, in this case supporting multicast over a legacy network. This research will be presented at ANCS’15 [83] We built a reliable multicast application that combines three principals to deliver content across a hetero-
