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


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 has a particular focus on requirements derived from the mobile Internet scenario as outlined in the figure below.  The figure shows that in addition to conventional fixed network services, the future mobile Internet should be able to deal with requirements such as user mobility and multihomings, assocaited with heterogeneous access technologies, rapidly fluctuating bandwidth and occasional disconnections.  Further ad hoc mobility scenarios such as vehicular networks are becoming increasingly important so that the architeccture should be able to deal with ad hoc formation of networks and their movement from one point of attachement to another.  Another important emerging service is that of edge clouds where services are accessed by mobile devices based on the functionality and proximity motivating some form of "anycast" service.  Emebbeded IoT devices are also an important part of the future Internet, and these will require additional capabilities such as context-aware messaging and efficient multicasting.  Media and content delivery will continue to be a major part of the traffic in the Internet, motivating improved techniques for information centric delivery which takes adantage of in-network caches and processing functions.


The resulting design requirements can be summarized into five distinct categories as follows:
  • Security related functions: authentication, data security, robustnes against DDOS attacks, etc.
  • Mobility related functions: end-point and network mobility, in-network storage/delay tolerance, edge awareness in routing, ad hoc modes
  • Multiple Interface related functions:separation of object names from network addresses, multi-homing, multi-path
  • Content and Context support:named content retrieval, context multicast, in-network caching
  • In-network processing: optional features for media transcoding, cloud services, data aggregation

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.

MobilityFirst Architecture Overview: The MobilityFirst architecture is centered around a new name-based service layer which services as the “narrow-waist” of the protocol – this named-object service layer makes it possible to build advanced mobility-centric services in a flexible manner while also improving security and privacy properties.  The name-based service layer uses the concept of “flat” globally unique identifiers (GUIDs) for network attached objects, a single abstraction which covers a broad range of communicating objects from a simple device such as a smartphone, a person, a group of devices/people, content or even context. 

As shown in the figure, named objects are assigned a secure public key GUID by a name certification service at the upper layers of the protocol stack. Network services are defined by the source and destination GUID along with a service identifier (SID) used to specify the delivery mode such as multicast, anycast, multi-homing, content retrieval or context-based message delivery.  A hybrid name/address based routing scheme is used for scalability, employing a fast global name resolution service (GNS) to dynamically bind the GUID to a current set of network addresses (NAs).  The GNS is a central feature of the architecture, enabling on-the-fly binding of names to routable addresses as needed for dynamic mobility, disconnection or cloud migration scenarios.  Actual delivery of data through the network is based on hop-by-hop transfer of large files with in-network storage to deal with link quality variations and disconnections due to mobility.  The corresponding intra- and inter-domain routing protocols used in the network have new features such as edge network awareness and late binding capabilities needed to achieve the design goals. The overall philosophy of the design is thus back to the basics of packet switching with hop-by-hop routing of entire data files with a minimum of in-network state – the packets themselves carry destination and service identifiers that can be dynamically bound to routable addresses during transit through the network.


Some of the major design features of the architecture are discussed further below:

Separation of Names and Addresses:  MobilityFirst cleanly separates human-readable names, globally unique identifiers, and network address locators. In contrast to the current Internet, the human-readable name can be managed and assigned to a unique GUID by multiple name certification services (NCSs) without a global root of trust.  No coordination is required between NCS providers because the GUID space is very large with arbitrarily low probability of duplication.  GUIDs assigned to network objects are mapped to a set of network addresses (NAs) or locators corresponding to the current points of attachment.


Security based on Public Key Based Globally Unique Identifier:  The GUID assigned by an NCS is a public key identifier that provides a uniform cryptographic basis for authentication and security services in the network.  The use of public keys also makes it possible to support anonymous or self-certifying end-points if so desired.


Name-based Network Service API: The service API in MobilityFirst is based on the names of source and destination network objects, rather than on the network addresses/interfaces.  This allows us to build abstract services involving multi-homed devices, groups of objects, named content, etc.  Because a single network object may consist of multiple devices or have multiple interfaces, the service abstraction is inherently multicast in nature and is thus well matched to the wireless environment.


Global Name Resolution Service: The proposed architecture uses hybrid name/address based routing in the interest of scalability.  The total name space of attached network objects is perhaps ~10-100B, while the number of unique routable networks tends to be much lower ~0.1-1M, thus making it expedient to map GUIDs to NAs and then route using NAs where available.  This approach requires the existence of a global service (which we call the GNS) that dynamically maps GUIDs to NAs.  Clearly, scale and speed of the GNS are critical design requirements for the proposed approach to be viable for mobility services.


Mobile End Points with Multi-Homing: Our future Internet design assumes the existence of billions of mobile end-points each of which traverses as many as 100’s of wireless access networks in a day.  In addition, mobile end-points will typically be multi-homed devices with access to multiple wireless networks such as WiFi and cellular.  Name (GUID) based message delivery makes it possible to offer seamless mobility and multi-homing services without the problems associated with today’s IP.  Note that multi-homing generally involves reaching a mobile device via two or more distinct network domains, and thus has implications for both intra- and inter-domain routing.


Network Mobility, Ad-Hoc and Disconnected Modes: The MobilityFirst protocol stack is also being designed to support network mobility, i.e. migration of entire networks and not just end-points.  In addition, the network should support ad hoc infrastructure-less communication between mobile devices in proximity (for example vehicle-to-vehicle) without the need for a connection to the Internet.  Thus the name resolution and routing protocols should be able to deal with periods of disconnection in a robust manner.


Heterogeneous Wireless Access:  Heterogeneity is a basic property of the wireless/mobile environment for which the MobilityFirst protocol is designed.  Differences in radio access technology (e.g. WiFi vs cellular vs. Zigbee) along with variations in signal quality can lead to orders-of-magnitude differences in available bit-rate even during a single session, motivating techniques such as in-network storage and edge-aware routing.


Routers with Storage and Late-Binding: Routers in the MobilityFirst network are designed to deliver large files on a hop-by-hop basis with the option for temporary storage (to overcome short-term link quality fluctuations and disconnections) and late binding (to deal with changing points of attachment due to mobility). 


Hybrid Name/Address Based Routing: The MobilityFirst protocol uses both GUIDs (i.e. names) and NAs to deliver data across the network.  Source and destination GUIDs define the authoritative packet header while an optional set of NAs can be added to specify a “fast path” wherever possible. Routers normally forward packets based on NAs but refer back to the GUID as needed to deal with topology changes due to mobility or disconnection.  End-to-end routing between network objects thus requires the combination of the GNS and an NA-based global routing protocol.


Storage-Aware Intra-domain and Edge-Aware Inter-Domain Routing: MobilityFirst intra domain routing protocols are designed to support in-network storage to overcome link quality fluctuations and disconnection.  In addition, the global inter-domain routing protocol is designed to have some degree of edge awareness because of the need to deliver data efficiently to/from multiple edge networks with very different properties, e.g. slow cellular vs. fast wired vs. ad hoc.  Both intra and inter domain routing protocols have the feature of “late binding” which allows for GUID to NA lookups at routers in the network as needed to deal with mobility or disconnection.


Hop-by-Hop Transport: The MobilityFirst protocol uses hop-by-hop (or segment-by-segment) transfer of large files between routers, with the entire file received and stored at each node before sending on to the next hop.  This approach makes it possible to implement storage and late binding functions at routers, while also providing important performance benefits (over conventional flows with end-to-end transport) in complex wireless/mobile environments.


Optional in-network computing services:  Storage of messages/files at routers makes it possible to introduce enhanced services via an optional computing layer at the routers.  This computing layer can be invoked for certain GUIDs and SIDs, enabling functions such as content caching, location-aware routing, or context-aware message delivery.  This feature also offers a path for evolution of protocol functionality over time.



Technical Details: Core Technology


Future Internet Architecture: The MF protocol stack is based on the concept of delivering information to and from network-attached objects which are denoted by a cryptographically secure identifier called the globally unique identifier (“GUID”). The “narrow waist” of the MF stack is the GUID service layer supported by a logically centralized global name service (“GNS”) which enables creation of flexible services such as mobility, multicast, multi-homing and delay-tolerant delivery with in-network storage. The key architectural insight which has emerged from the project is the recognition that a logically centralized GNS can significantly enhance mobility, security, and network layer functionality. The following figure shows MF protocol stack.

MobilityFirst Protocol Stack


Name Address Seperation: In order to understand how the protocol works in further detail, first consider how a name is converted into a GUID by the name certification service (NCS). A number of specialized NCS providers may cater to name assignment and trust management in different domains such as devices/hosts, M2M, content or context. There may also be a network naming and trust services from which constituent networks obtain their GUIDs and build trust relationships with other peer networks. Next, consider how a message is sent between two end points. As shown in below figure, a host wishing to send a message to all of “John’s devices” will obtain the corresponding GUID from either the NCS or the end-user and then invoke the service API using a command such as send (GUID, options, data), where options can include service features such as anycast, multicast, timed delivery and so on. The host stack then prepares a MobilityFirst packet with GUID and SID in the header as shown. The GUID is then resolved through a GNRS lookup (either at the sending host or at the edge router) to the set of network addresses (NAs) corresponding to the current points of attachment of this abstract object, in this case NA99 and NA32. The packet header actually sent out by the host (or edge router) then consists of a destination GUID, SID and list of NAs. Routers in the network use the NAs (which can be thought of as a “fast path”) to make forwarding decisions, with multicast and copy functions added in where appropriate to reach both NA99 and NA32. If a delivery failure occurs due to disconnection or mobility, the packet is stored inside the network and the GNRS is periodically queried for a rebinding of the GUID with NAs. Depending on requested delivery service (e.g., delay tolerant) and local policy, the packet is either delivered to the new destination within a certain amount of time, or discarded due to time-out.


Routing: This section details routing in MF.


Global Name Resolution Service (GNRS): The GNRS provides a service to map a network object (e.g., a user, a device, a content, etc) to its current network address/locator. Users send queries to the GNRS with the name of the object and GNRS replies to the user with the current network address of the object. An enhanced in-network GNRS design called GMap was developed and evaluated via large scale simulations and prototyping during this reporting period. GMap achieves low lookup latency through a hierarchical organization which exploits common spatial locality patterns in lookup queries while retaining the simplicity and scalability of the replicated random DHT approach. Server workload balance is achieved by deploying K replicas for each identifier-to-locator mapping supplemented by small caches deployed along lookup query routing paths. The K replicas provide balanced workloads for normal network entity queries while the caches alleviate replica server congestion caused by hotspot network entities’ queries, whose query popularities are orders of magnitude higher than normal. Specific design issues such as server churn behaviors, cache cost and correctness, and expected server capacity have been addressed. Evaluation results were obtained from a large-scale event driven network simulator of the Internet with over 22,000 ASs under real world geographic and demographic information. The results show that geolocality aware replica placement reduces the 95th percentile query latency from roughly 100ms to less than 40ms and that the maximum server workload deviation is reduced more than fifty-fold compared to the best prior in-network GNRS scheme DMap.


Transport Protocol: This section details transport protocol for MF.


Security and Privacy: This section details security and privacy.


Technical Details: Use Cases


Content Delivery: Content delivery has been the core functionality of nowadays Internet. To better optimize user experience (with lower latency, higher throughput), existing solutions tend to place popular contents (caches) closer to the clients. Content-Delivery Network (CDN) is a particular example of such kind of solutions. Companies like Akamai, AT&T, Verizon, etc., provide explicit CDN services. The contents placed in CDNs can also range from smaller popular web pages, images to even videos with several GB in size. Video-on-Demand (VoD) is a typical use case of CDNs. To better support VoD, content providers usually place popular contents to the caches in the neighborhoods. Instead of querying data from the servers, which are far away, the clients can get the contents directly from the cache in the neighborhood. The reason why such mechanism works is, although the users are querying different contents at different times, the popularity of the contents still follows Zipf distribution – hot contents like newly released film/TV series/shows will be queries much more often than the others. Therefore, placing these contents in the edge cache can satisfy most of the queries although the cache might be much smaller than the total video size. In CDNs, especially the ones for VoD, each piece of content usually has to be sent to multiple destinations based on the policy of the provider. To enable efficient content delivery, companies like AT&T build their backbone network and transmit data using IP multicast. We argue that for this kind of multicast scenario in which the destinations are usually distributed in geo-location, broadcast media like satellite can be leveraged to ease the data dissemination and therefore the terrestrial links can be used for timely unicast communications (e.g., VoIP). Therefore, in this project, we try to build such a Satellite CDN (S-CDN) framework using MobilityFirst. Below figure shows a simplified scenario of S-CDN. When the provider wants to send a piece of content (Movie A) to a set of edge caches, either it is because there are queries, or because it predicts Movie A will be popular, it can send the content to the satellite. Then, the satellite can forward the data to all the edge caches via broadcast media. The edge caches can choose if it will cache the movie based on its own policy. We believe that MobilityFirst is a suitable network architecture for such communication since it shifts the focus from location (IP) to information. In MobilityFirst, Globally Unique IDentifiers (GUIDs) are used to represent objects including nodes, applications and even contents. Thanks to the awareness of contents in the network, the client requests will be anycasted to a best source (server or cache) without complicated translation like how DNS is used for CDN data retrieval, or application-layer interference like P2P network. With natural content support in the network also has the potential to increase the flexibility and dynamicity in content retrieval.


Virtual Networks: Network virtualization, over the years, has become a fundamental technique to implement network advanced services, exploit network resources and utilize QoS oriented set-ups. Current virtualization techniques are limited by a number of factors such as (a) Tunnels, which provide multi-domain virtualization, have high overhead and (b) SDN solutions, which do not overcome scaling problem especially in inter-domain cases. In this work a detailed solution for network virtualization based on MobilityFirst’s name objects and a dynamic name-resolution service for mapping names to routable network entities is proposed. Our system exploits recursion in a name resolution service to implement a simple and clean design for Virtual Networks (VNs). Finally, this system can be integrated into larger systems that can support high performance future networking scenario such as Cyber Physical Systems (CPS). The key features of MF utilized in this work are name-based services enabled by GNRS, along with routing support for anycast delivery, and the ability to introduce extended computing logic into the routing fabric. Our study here confirms that MobilityFirst is well suited for VN and Application Specific Routing. Named-Object Based Virtual Networks (NOVN) exploits named-objects to create partitions across logical layers. First a name resolution server (NRS) is used to map physical network resources to their names, eliminating the need of perpetually keeping track of routers' addresses and possible configuration changes. A second layer of abstraction then maps network elements to the participants in the VN, creating a logical network on top of the infrastructure. A forwarding plane is implemented through a form of tunneling that uses names to address traversed routers on a hop-by-hop manner.


Internet of Things (MF-IoT): There is a recognized need for unified IoT platforms where objects can be made accessible to applications across organizations and domains. However, most available solutions are based on client-server overlays on today’s Internet. These solutions inherit the inefficiencies of the current Internet – especially in terms of mobility, scalability, and communication reliability. To address this problem, we propose to build the unified IoT platform leveraging the key features of Information-Centric Network (ICN) architectures, which we refer to as ICN-IoT. Specifically, we have designed a context-aware Mobility First IoT middleware to support seamless device configuration, naming, context processing and publish/subscribe. Please see the MF-IoT middleware architecture below.


Emergency Response: Below figure shows the overall architecture of MobilityFirst Pub/Sub System for emergency response. The Information Layer (concepts) store and manage the relationship of the objects; the flat GUID Layer (network identities) that identifies each network object; and the Routing Layer (network entities) forwards the data towards the destination. We use different components to link the layers together: the name certification service (NCS) grants each topic a GUID; the object resolution service (ORS) maps the topics onto different GUIDs; and the global name resolution service (GNRS) stores the mapping between each GUID and the corresponding network addresses (NAs). In the figure, we show an example of an incident management system. The group (topic) relationship is a graph since there are multiple dimensions to define a team. The dimensions include: 1) function, starting from bottom left, “First Responders” to “Police” and “Fireman”; 2) location, starting from top right, “US” to “NJ” and “CA”; and 3) incident, starting from top left, “Incidents” to “Incident X” (a particular incident). We allow the combination of topics, e.g., “NJ Fire” is a team belonging to both “NJ” and “Firemen”, and therefore whoever sends a command to “NJ” (a command that should be received by all first responders in NJ), or “Firemen” (a command that should be received by all firemen), the firemen listening to “NJ Fire” should receive it. The GUID layer is relatively simple. It contains flat IDs for each topic in the information layer. To forward data, we place the functionality in the GNRS. By slightly modifying the multicast protocol in MF, we enable the graph-based relationship. In the example, the survivor wants to send a message to all the firemen dealing with incident X (“X Fire”). The survivor can get the GUID of “X Fire” from the ORS and use it as the destination of the message. On receiving the message, the GNRS would perform a “recursive lookup” by knowing “Team 1” and “Team 2” are the sub-groups. By combining all the NAs that are subscribing to “X Fire”, “Team 1” and “Team 2” (including all the 3 firemen in the example), the network forwards the message in the multicast manner, for the efficiency and timeliness.


5G / Cellular: As Internet-connected mobile devices will soon outnumber fixed PCs, a convergence of business models and technical standards associated with mobile networks and the Internet may be expected over the next decade. This convergence process has already started, with cellular standards embracing the concept of “flat” IP-based networks without centralized gateways. With the emergence of the “5G” cellular roadmap there are new opportunities to set industry standards with better alignment between the 3GPP based mobile networks and the Internet. For example, an industry-driven standards activity has been started within the IETF and EU NGP on protocol extensions for identifier-based networks intended to support 5G mobility and other advanced services. The MF team has been making contributions to this effort including a March 2017 IETF draft on name resolution services based on the work done on global name resolution services (GNRS) in the FIA NP project. In our view, the next logical step in this direction is unified mobile Internet architecture with native support for basic services such as authentication, dynamic association, multi-homing, handover, inter-network roaming, and disconnection tolerance. In this aspect of the MobilityFirst project, we focus on the protocol design and related techniques needed to enable such a unified mobile Internet architecture. As shown in below figure, in the integrated “mobile Internet” architecture, it will be possible to “plug in” multiple wireless access technologies such as 4G, 5G or WiFi without requiring gateways. Such a uniform protocol solution across wired and wireless network technologies will eventually lead to convergence of cellular and Internet standards, in view of the fact that both industries are serving the same mobile end-users. Beyond mobile data, any new protocol architecture should also support the requirements of emerging machine-to-machine (M2M) communications between embedded sensors, vehicular networks, and Internet-of-Things devices, which are expected to grow significantly over the next decade to an estimated 1.5 billion devices by 2017.


Vehicular Networking: The growing popularity of smartphones and connected vehicles has resulted in a significant increase in network utilization in challenging high mobility scenarios. Infotainment services such as audio/video streaming and automatic transfers of information between cloud servers and related in-vehicle devices for autonomous driving require high throughput links. Providing reliable services in these scenarios is intertwined with intelligent usage of urban infrastructure (e.g., multi-homing) as well as leveraging available peer-to-peer WiFi links by forming ad hoc networks among mobile nodes (i.e., forming vehicular ad hoc networks (VANETs)). Multi-hop forwarding within VANETs facilitates providing high quality services to nodes in weak coverage zones or adopting more cost-efficient data transfer strategies (e.g., cellular offloading). To implement multi-hop forwarding, there are VANET-specific challenges including short-lifetime links and connection disruptions due to fast changing topology, being prone to channel congestion due to exchanging more control data, the broadcast storm problem, and unpredictable network load due to random density of nodes. Being designed for networks of fixed entities, the IP architecture is not well suited for dynamic scenarios with intermittent connectivity, frequent changes in network address, and unreliable wireless links. In addition, mobile nodes in IP networks suffer from the identity-location conflation problem due to employing the same name for both an interface and a network location. In this work, we present the design and evaluation of a framework for providing high-throughput in-vehicle Internet access and seamless connectivity. In this regard, our primary contribution is twofold. First, to improve in-vehicle Internet accessibility, we propose FastMF, a mechanism for multi-hop bidirectional path discovery between vehicular nodes and Internet gateways based on a distributed cluster formation algorithm. Under FastMF, we observe significant improvements in terms of connectivity, overall throughput, and average latency for file delivery. Second, to provide seamless connectivity and efficient delivery in presence of dynamic links, our designed protocol leverages an in-network real-time distributed database of mappings between object IDs and their current network addresses (NAs) (e.g., global name resolution service (GNRS) implemented in MobilityFirst).









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


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.