MobilityFirst Future Internet Architecture Project

Technical Approach

 

MobilityFirst Papers & Documents:

Reference list for text
in this section

MobiArch 2011 paper on
GSTAR Routing

Network Assisted Multi-Homing in MF - WINLAB Technical Report 2013

Hop Transport Protocol

CNF architecture for
mobile content delivery

HLP - Next-Generation Internet Routing

Global Name Resolution Service (GNRS) Paper -Proc. ICDCS 2012

Comparison of MobilityFirst GUID Routing with Named Data Networking (NDN) - NOMEN Workshop 2012

Wireless Access Network Perspective for MobilityFirst Architecture - Sarnoff 2012

Internet-of-Things (IoT) Use Case for MobilityFirst - IoT W3 ET 2012

 

IEnabling Internet-of-Things Services,

IEEE SoS 2012

Storage-Aware Routing Performance, ICC FutureNet V, June 2012

 

Vehicular Networking with MobilityFirst, IEEE WoWMoM 2013

Content Delvery in MobilityFirst, Sarnoff Symposium 2012

Architectural Overview Paper, ACM CCR 2014

 

Integrating Advanced Mobility Services into the Future Internet Architecture,

IEEE Comsnets 2015

 

Multihoming in MobilityFirst, IEEE PIMRC2014

 

Cut-Through Switching in MobilityFirst, ANTS2013

Link to full list of related papers by MobilityFirst project members

TECHNICAL APPROACH SUMMARY:

The MobilityFirst architecture is based on the following high-level requirements:  

  • Mobility as the norm: Seamless host and network mobility at scale; multi-provider mobile network access; heterogeneous wireless technologies.
  • Robustness: with respect to intrinsic properties of wireless medium (disconnection, varying bandwidth, high error rates, scarce spectrum).
  • Trustworthiness: Enhanced security for mobile networks and wired infrastructure (strong authentication, enhanced trust models, privacy, DDoS resistance, secure routing).
  • Usability: Architectural support for context-aware pervasive mobile services; evolvable core network services; network manageability; economic viability, regulability and universal access.

Our design is also informed by strategic core technology trends that determine the feasibility of implementation during the target period in which the network is to be used.  These include:

  • Edge/core disparity: Radio spectrum scarcity (implying the need for efficiency in wireless access networks) and wired bandwidth abundance (that can be traded off against usability objectives).  
  • Moore’s law: Rapidly declining costs of memory (for large routing tables), storage (for in-network caching), and computing (for increased in-network programmability).
  • Energy: Energy constraints in mobile and sensor devices, motivating power-aware network protocol design (disconnected operation, power-saving modes, network mobility)

The network architecture resulting from these considerations is summarized in the MobilityFirst Summary Presentation.  Because the design is aimed at supporting billions of mobile users, a central feature is a fast global naming service that dynamically maps device names to network addresses while providing strong authentication. This allows end-users to have a permanent name and receive dynamic addresses as they move from one attachment point to another, or reconnect after a period of disconnection.  For strong security, we use self-certifying public key network addresses and associated flat label (or hybrid flat/topological) routing in the core. Data transport is based on the concept of a class of routers with in-network storage and connectionless transport of application-level blocks over path segments between such storage-capable routers as the norm.   Coupled with generalized delay-tolerant network (GDTN) routing in the access network, this provides significant robustness in presence of link/network disconnections, as well as a foundation for adding programmable computing services such as enhanced security or content/context-sensitive delivery. Other features include a cleanly separated control and management plane for enhanced trustworthiness and improved visibility across the network.  In addition, the computing layer can be used with virtualization to provide commonly-used services within the network, including location and optional privacy modes.

ARCHITECTURAL CONSIDERATIONS:

Our position is that a credible FIA effort must be driven by compelling design goals that satisfy two properties: (1) Each design goal must be precise enough so that it is possible to validate or refute the claim that a given architectural realization satisfies that goal. (2) The current Internet fails to satisfy that design goal.   Architecture is part science and part art, so we cannot expect black-or-white design goals alone to simply dictate the realization of the architecture. Thus, we postulate additional design principles that guide the transition from design goals to realization. Unlike a design goal, a design principle is a philosophical stance that is informed by our collective experience and expertise, so it is both subjective and subject to debate. For example, a design principle that the current Internet embodies well is "minimalism" [3] or the "end-to-end principle" [4]. A design principle that the current Internet does not embody well is "isolation of control and data". The next three sections describe the design goals, design principles, and realization of the proposed architecture.

Design goals: We postulate the following design goals for an FIA. As with the current Internet, an implicit top-level design goal is that the architecture must enable multiplexed utilization of existing interconnected networks [5] - see link in left column of this page for the reference list. Unlike the current Internet however, mobility and trustworthiness form the starting point for these design goals.

  • Host and network mobility (G1): End-to-end communication must continue (i) despite frequent mobility of end-hosts or networks; (ii) despite the absence of a contemporaneous end-to-end path.
  • No global root of trust (G2): Correct network behavior must not depend on a single root of trust. 
  • Intentional data receipt (G3): An end-host must receive data only if the transmission is consistent with its receipt policy.
  • Byzantine robustness (G4): End-to-end communication must continue despite the compromise of (a small fraction of) end-hosts or infrastructural nodes.
  • Content addressability (G5): The network should assist with content retrieval in addition to enabling host-to-host communication.
  • Evolvable network services (G6): The architecture should allow for the co-existence or rapid creation of new and different network services.

Next, we discuss the ways in which the current Internet fails to meet these design goals. The current Internet does not satisfy G1, as the assumption that end-hosts and networks are mostly stationary is deeply embedded in its architecture. This is evident in three fundamental aspects of its architecture:

  • Naming and addressing: The current Internet relies on DNS to bind a host name to an IP address. DNS is designed to be queried frequently but updated slowly, as evidenced by its heavy reliance on caching, which enables scalability at the cost of update-propagation delay.
  • Routing: aggregation of local IP addresses into prefixes is central to routing scalability. Host mobility is assumed to be infrequent enough to be relegated to an indirect routing approach that is inefficient and requires additional infrastructure not universally available. Network mobility (e.g., mobile networks of vehicles, planes, or VMs) scales poorly with the Internet's interdomain routing protocol.
  • Disruption-tolerance: The TCP/IP stack assumes that hosts and routers are stationary long enough so that the routing protocol can compute a contemporaneous end-to-end path and the transport protocol can respond to end-to-end loss and congestion signals along that path. Consequently, the TCP/IP stack falls short in emerging wireless scenarios such as vehicular, sensor, or deep space networks.

The current Internet fails to satisfy G2 as it relies on ICANN as a single root of global trust for assigning names and IP addresses. This centralized control over naming stifles open competition and innovation in name services, creates political discord [19,20,21], delays deployment of security and privacy mechanisms, [18], and leads to abuse of naming services [7-16].

The Internet also falls short of meeting design goal G3 as it generally treats receivers as passive devices. The network responds to senders by delivering sent packets.  However, except in special cases (e.g.,  multicast) a receiver does not exert control over the data it receives, making it vulnerable to denial-of-service attacks. The lack of support for intentional data receipt goes beyond DoS. The architecture makes it difficult for multi-homed end-hosts or networks to engineer incoming traffic. The architecture does not permit a receiver to defer receipt to a future point in time, or otherwise customize receipt based on its context such as its resource constraints or environment characteristics.

The existing Internet architecture does not satisfy G4 as a legacy of an original design aimed at tolerating failures but not malicious behavior. For example, a single benignly misconfigured router [6] has on several occasions rendered large portions of the Internet unreachable. Denial-of-service (DDoS) is another example--a botnet with hundreds or thousands of nodes can render a server unavailable to large numbers of legitimate users, thus violating G4.

The Internet also fails to satisfy G5 as the network enables a host to send data to another host but does not help a host retrieve named content without specifying a host location. Although peer-to-peer and other overlay content distribution services enable location diversity, the network itself remains content-unaware thereby missing opportunities for in-network caching and traffic engineering.

The Internet Protocol does not achieve G6 as the network service model is limited to basic best-effort packet delivery without the provision for adding new service extensions.  While this was a reasonable approach at the time IP was first designed, rapid advances in computing power now make it possible to consider adding some level of programmability and virtualization into the network layer in order to add new services (e.g.,  geolocation, anonymous routing) or to support multiple virtual networks for some degree of evolvability and backwards compatibility.

Design principles:  Beyond design goals, our architectural realization is informed by the following design principles which are more subjective in nature, but are also important considerations:.

  • Visibility and choice (P1): Networks and end-users should have visibility and choice in determining what resources are available and how they are used.
  • Usability (P2): The architecture should be easy to use for end-users, operators and app developers, suggesting plug-and-play interfaces and socket APIs that simplify app development.
  • Manageability (P3): Networks should be easy to manage. This principle suggests a well-instrumented management plane that provides necessary aggregate views to operators.
  • Simplicity (P4): As a general principle, the design should favor simple methods that do not involve significant control complexity or maintain per-flow or per-packet state in the network.
  • Regulability (P5): The architecture should confirm to specifiable public policies and laws.
  • Commercializability (P6): The architecture must be economically viable.
  • Technology-awareness (P7): The architecture should be cognizant of foreseeable technology trends.

2.3 Architecture Realization: Figure 2 summarizes how key design goals and principles were taken into account during our design process.  Each major component of the architecture is described below:

 

Fig 2: Overview of Architecture Realization

 

A Decentralized Naming Service: The proposed naming service dynamically maps names (users, devices, content names, context labels, etc.) to network addresses with real-time response latencies.  Such a service is feasible with current processing power, storage and bandwidth and is the key to supporting mobility requirement G1.  A name service that can map arbitrary names to network addresses also helps achieve content and context addressability (G5). As explained later, the service also provides strong authentication of network users as a default service.

A key feature of our name service design is to move away from centralized control over name and address ownership which forms a single root of global trust. The opportunities for competition in naming are evident from the abuses with which the current name resolution system (DNS) is plagued. Today’s name resolution system is a vehicle for activities ranging from fraud and exposure to malware via typosquatting [7-12] and homograph attacks [13,14], shady profiteering through domain speculation (e.g., tasting and frontrunning [15]), and overtly criminal activity and evasion (e.g., botnets employing DNS fluxing, such as Torpig [16]). We believe that competition will lead to innovation in defending against such abuses, in contrast to the current situation with a single DNS service. Competition in naming also paves the way for new types of services such as private resolution of names [17]. 

It is for these reasons that we believe that decentralizing control over name and address ownership is a necessary, albeit radical, departure from today’s Internet. Fortunately, public key cryptography provides the means by which addresses can be claimed and ownership proved without relying on others to assign those addresses, provided that the public key itself (or a collision-resistant hash thereof) is used as the address. To decentralize control of naming, however, seemingly requires permitting multiple, indeed arbitrarily many, naming authorities, each of which defines its own namespace. Users can choose to utilize any resolution service, or many such services. Services can compete on the basis of their speed, robustness, or, as discussed above, abuse defenses or the attributes of the parties whose addresses (public keys) they serve, and the rigor with which they verify those attributes.  The proposed naming service consists of the following elements:

  • Name certification service (NCS):  The name certification service maps a human readable name, e.g., www.cnn.com, to a self-certifying host identifier GID that is its public key. Unlike ICANN, which has a single root of trust, the NCS has a decentralized trust model. For example, each country could have its own NCS for its citizen or Google and Yahoo could provide this service to their customers.  Note that the NCS also includes strong user/device authentication as a baseline capability.
  • Addressing: Packet headers by default carry a self-certifying global identifier (GID) which can be thought of as the "meta-level" network address.  Packet headers will carry the GID and optionally may also include a second level of topologically significant network addresses.  GID's and network addresses will be protected by public key cryptography as required to maintain security against a variety of spoofing and DOS attacks.
  • Location service:  A location (or GID to network address) service maps a network object's GID to a complete network address (NA) used for routing.  The specific structures of the GID and NA to be used in the proposed approach are still under consideration to be determined during the first phase of the project.

Mobility is handled using two mechanisms: (1) updating the location service to reflect the new network address (NA), or (2) using a home agent in a designated primary NA to redirect (using direct or indirect routing) traffic to the new NA. The former option is sufficient when nodes are slow moving, and the latter option could optionally be used to enable seamless mobility during the course of an ongoing session. Multihoming is handled by having the location service map GID's to multiple NAs, e.g., NA1,HA, NA2,HA, NA3,P, and so on.  Besides node mobility, explicit support for network mobility through mechanisms such as routing state partition within an AS and scoped updates across ASes is provided as discussed in the next section.

The above naming and related routing achieves design goal G3 as it eliminates a single root of global trust in ownership of names and addresses. It also prevents problems with IP addressing such as hijacking or spoofing by using self-certifying addresses: merely by claiming a public key, an entity owns that as its address as no other entity possesses the corresponding private key.

Disruption-tolerant Routing and Transport: MobilityFirst generalizes routing and transport in the current Internet in two fundamental ways: (1) disruption-tolerance, and (2) path and location diversity. The core network layer is based on best-effort packet switching with support for a small number of globally supported service classes. We envision the following classes--control and management traffic, real-time traffic, and elastic traffic--that that can be served in priority order or (in the case of control and management) may be carried over a logically separate network. Our position is that best-effort packet switching with prioritized service classes and good traffic engineering is simple and sufficiently general. We adopt this position informed both by the phenomenal success of packet switching and difficulties in adding QoS to IP networks (even more difficult in heterogeneous, varying-capacity wireless networks) – see design principle P4.

Disruption tolerance: Enabling disruption tolerant communication requires that packets make forward progress despite the absence of a contemporaneous end-to-end route to the destination. This requires us to rethink the clean separation of functionality in the TCP/IP stack, where the routing protocol computes an end-to-end route and a connection-oriented transport protocol delivers a reliable, in-order data stream based on end-to-end loss and delay feedback along that route, i.e., it essentially requires us to rethink the end-to-end principle. Although wireless and mobile scenarios make the most compelling case for rethinking the end-to-end principle [4, 22], the resulting architectural mechanisms are valuable for wired networks as well. The MobilityFirst design ensures that disruption tolerant routing and transport protocols perform well in wired network scenarios, and can support fast switching in the core as a special case.

Enabling disruption-tolerance requires the following key components: (1) storage at network intermediaries, (2) forwarding with uncertain path information, (3) a large forwarding unit of data (variously referred to as bundles [23], blocks [24], or files [25]) to amortize overhead and efficiently utilize forwarding opportunities. To synthesize these components into a holistic routing and transport approach for both wired and wireless regimes, we propose a "segmented" forwarding approach. A segment is a sequence of adjacent links terminated by a router with storage. A large unit of elastic data or "block" is reliably transported across and cached at the end of each segment. An end-to-end path consists of one or more segments and each segment may use a different protocol (e.g., TCP) to transport a block. A well-connected and provisioned wired end-to-end path can be treated as a single segment, while end-to-end paths spanning heterogeneous or disruption-prone wireless links consist of multiple segments. Congestion is controlled by propagating backpressure at each segment while reliability is achieved using end-to-end acknowledgments.  [We note that the use of in-network storage taking advantage of remarkable declines in $/GB unit memory costs corresponds to design principle P7.]

Generalized DTN routing (GDTN): Routing algorithms used in MobilityFirst are based on a generalization of DTN and on-demand routing protocol concepts, and that seamlessly scale across the range of well-connected wired environments to varying-capacity wireless scenarios with occasional disconnection.  The cache-and-forward (CNF) approach considered in [25,26,27] involves the use of two-dimensional routing metrics corresponding to “short-term” and “long-term” path quality/cost and using these to create a decision region for storing and forwarding.  The basic idea is to switch/forward when short- and long-term path quality are roughly equal, to store when short-term quality is poor and long-term is good, and to push opportunistically when short-term is good and long term is poor. This type of storage-aware routing metric will also be applied to inter-domain routing scenarios by exchanging path-quality information in addition to reachability.  An open design issue is that of aggregating such path metrics across AS boundaries. A related research issue to be considered in this project is that of interfacing the MobilityFirst network layer efficiently with an optical core network.

Path and location diversity: Path diversity improves utilization of network capacity as well as resilience to failures. Although the current Internet's datagram service model allows different packets to take different paths, the network does not expose this diversity to end-hosts, so different applications have to independently engineer support for path diversity [28,29,30]. Enabling path diversity is especially important in resource-constrained and time-varying mobile and wireless environments. The proposed architecture provides support for path diversity through two mechanisms: (1) detour routers, and (2) content addressability. To enable detour routing, a small fraction of routers advertise themselves as one-hop detour routers. End-hosts can request packets to be routed to a destination via a specified detour router. In mobile and wireless environments, an access point or base station can provide this detouring service. End-hosts can use multiple detour paths in parallel in conjunction with a multipath transport protocol. To enable content addressability, the location service translates content or service names to one or more locations. The transport protocol supports a multipoint-to-point interface enabling an end-host to receive blocks of data from multiple locations.

Network mobility: To effectively support a group of nodes moving together, e.g., from a bus or a plane, the proposed architecture makes the distinction between mobility within a domain and across domains to realize fast convergence to the routing state. To support the former, aggregation routers, which scalably partition the routing state within an AS, capture the routing change.  For the latter, we investigate mechanisms based on our existing work of the WINMO protocol [31], a simple, systematic solution for wide-area IP network mobility using techniques including route aggregation, scoped update propagation, and packet mobility states.  This solution generates minimal global routing overhead to prevent global instability, ensures good location privacy [32,33], and helps to defend against denial-of-service attacks. We expect to adapt the protocol to accommodate the new addressing scheme by identifying the aggregation points, which are routers that contain more detailed routing state and the mobility information of the mobile networks.

Intentional data receipt:  A critical limitation of the current Internet is that receivers are passive entities, i.e., the network responds to send actions but a receiver cannot specify whether or how it wishes to receive sent data. This limitation is at the heart of the denial-of-service (DoS) problem [32 - 46]. However, the lack of receiver control also hurts in other ways. For example, a mobile device with multiple wireless interfaces and providers may wish to engineer incoming traffic across those interfaces to optimize cost, performance, or power consumption. However, engineering incoming traffic is difficult today, as a receiver lacks a mechanism to specify receipt policies to the network.

The proposed architecture will enable a receiving host to specify "intentional' receipt policies to the network via its immediately adjacent routers. The policy may install filters, whitelists, or blacklists of senders to thwart DoS attacks; or specify which senders are allowed to send data via which interface; or adapt such policies based on context or content attributes. Routers adjacent to the receiver may propagate parts of these policies deeper inside the network as necessary. Our view is that intentional data receipt is a powerful and general approach to alleviate the DoS problem through network layer mechanisms. DoS attacks happen today because (1) receivers can not refuse data, and (2) malicious senders can drown out legitimate senders by not abiding by congestion control. Existing DoS defense schemes are based on blacklists (e.g., filtering and pushback [46-50]) or whitelists (e.g., network capabilities [41-44,50]), dynamic end-host-based authentication and admission control ([51]) with varying levels of network support. Intentional data receipt subsumes the power of all of these approaches by enabling receivers to specify sophisticated receipt policies. For example, a receiver could specify a congestion policing policy that limits congestion misbehavior, or it could limit rate from unauthenticated senders.

Management plane: The proposed architecture includes the possibility of a separate control and management plane that can be used to provide visibility and manageability across the network (design principles P1,P2,P3).  For wireless access networks, there are several advantages to be realized by separating the management/control and data planes including: (i) expanded geographic reach for management and control messages allowing for more efficient MAC and handoff protocols [52], and inter-BS coordination; (ii) dedicated signaling channel(s) that are always available for control, even when the characteristics and availability of data channel(s) may vary due to interference.  Additional advantages for both wired and wireless scenarios are (iii) hardened signaling channels more trustworthy than data channels via over-provisioning, stronger encryption, and authentication, and (iv) avoiding performance-related control-plane problems resulting from poor data plane performance [53, 54]. Along these lines, the 4D project has also argued the importance of separating the “decision logic” from the “protocols that govern the interactions among network elements” [55].

Client-assisted management: One of the challenges in designing an effective management strategy is to provide an appropriate level of visibility. In the current Internet architecture, events are often “invisible” since there is no infrastructure to measure or observe them. At the wireless edge, the problem is further exacerbated because many performance characteristics have location-specific properties — what is observable at a specific location is not necessarily observable from even a nearby location. Without access to such observations, effective management of the wireless and mobile edge is particularly difficult [56]. To address these limitations, we propose the notion of client-assisted management, where some form of client participation or assistance, in addition to infrastructural support, can be provided.

Signaling support in core networks: We further propose that the management plane of the proposed network architecture offer the following two basic functionalities: signaling support for resource queries and allocation; and mechanism for routers to provide feedback on network conditions. For example, the management plane could directly expose the current network status to the extent satisfying privacy concerns to influence route selection, especially for multi-path routing based on diverse performance metrics to reroute around performance disruptions.  We plan to extend the design guidelines proposed by Sollins [57] in designing support for network management. These include a signaling protocol that allows end-hosts and networks to dynamically query or request resources, and a feedback mechanism to allow network elements to provide feedback on network conditions.

Computing and storage layer: The MobilityFirst architecture incorporates a programmable computing layer inside the network that includes access to computing and storage resources. A MobilityFirst router includes not only packet forwarding and routing, but also a computing layer that uses virtualization [58-61] to host various network services. Upper-level service providers called virtual service providers may lease slices of the computing layer to offer a rich set of network services, such as geolocation [62], DDoS protection [33,45,46], and anonymous routing [63]. Unlike previous proposals that bring programmability to the network layer [115-117], the computing and storage layer in the MobilityFirst architecture runs only trusted code (not arbitrary code carried by packets) from virtual service providers, is located on a packet’s forwarding path, and supports upper-layer services as well as enhanced network-layer services. This design enables the MobilityFirst architecture to provide services to end systems that need them without imposing costs to those that do not. Today’s IP adopts a minimalist design, with the network layer providing only a best-effort forwarding service. This design keeps the network substrate simple, but has the downside of lacking many needed functions [5,59]. With the MobilityFirst design, ISPs can add new services at the network layer in an evolutionary manner.  In contrast to overlays, virtual services co-located with routers can obtain necessary information about network conditions (such as link load or loss rates) and use that to better engineer performance [64-66]. New ISP services are important for revenue generation, and hence overall economic viability (design principle P6).

Context-Aware Pervasive/Mobile Services:  Architectural support for context-aware services [67,71] can significantly improve the quality of mobile applications. For example, downloading of a large content file may be deferred if the user is predicted to move into a high bandwidth coverage area.  Another example is that of geographically constrained delivery of messages to nearby cars on a highway, or connecting to a local sensor with certain attributes. The MobilityFirst architecture presented above enables such context-aware services with the following approach. First, the naming and location service (2.3.1) can support attributes other than a self-certifying address NA, HA, e.g., it can return NA:P where P represents the device's geographic location or other context information. Second, intentional data receipt policies can be used by a mobile device to leverage network support to filter or transcode content or engineer traffic across diverse wireless access technologies based on context information. Third, the computing and storage layer can cache and reuse content of geographically local interest. Fourth, the support for disruption-tolerant routing and transport naturally incorporates infrastructure-less mobile-to-mobile network communication without requiring a separate protocol stack.

Economics and policy:  Future Internet designs will need to reflect greater attention to economic and public governance (policy/regulatory) issues both because the Internet has become essential social/economic infrastructure and because components of the Internet are increasingly capable of acting strategically, like economic agents in their own right, which is a direct consequence of the wider distribution of intelligence across the Internet. We take this proposition to be self-evident, and hence, as applicable to our MobilityFirst architecture.  Protocol support needed to enable this kind of decentralized economic activity is thus an important capability for the proposed architecture (design principle P6).  Our design includes two types of mechanisms: the management layer discussed earlier which enables visibility of resources across the network, and the computing layer which enables construction of new services which can be programmed to automate different kinds of barter, cooperation and monetary exchanges. 

Technical Highlights
and links:

Architectural Overview Paper, ACM CCR 2014

MobilityFirst tutorial paper - ACM MC2R 2012

 

ACM MobiArch2013 Best Paper Award

" Network Service Abstractions for a Mobility-Centric Future Internet Architecture"

Francesco Bronzino, Kiran Nagaraja, Ivan Seskar, D. Raychaudhuri

Architecture Summary Document v1.0, July 2012

MF Concept Summary Slides, Nov 2011

 

NSF Review Meeting Slides, March 11, 2013

Overview Slides for Oct 2012 FIA Meeting

Review Slides from April 2012 External Advisory Board (EAB) Meeting

Oct 2011 NSF Review Meeting at WINLAB

Presentations/Slides

Project Summary & Security Overview
D. Raychaudhuri Slides from May 2011 FIA Meeting

 

For problems or questions regarding this webpage contact webmaster (at) winlab (dot) rutgers (dot) edu.