| 9 | | The !MobilityFirst project is founded on the premise that the Internet is approaching an historic inflection point, with mobile platforms and applications poised to replace the fixed-host/server model that has dominated the Internet since its inception. This predictable, yet fundamental, shift presents a unique opportunity to design a next generation Internet in which mobile devices, and applications, and the consequent changes in service, trustworthiness, and management are primary drivers of a new architecture. The goal of !MobilityFirst is to better accommodate mobile entities on the Internet in a scalable, trustworthy, and useable manner. Inherently a clean-slate project, MobilityFirst takes a radical approach to redesigning the Internet including rethinking end-point naming, such as through IP, and connection-oriented protocols, such as TCP. At a high level, !MobilityFirst allows applications to securely interact with abstract, mobile entities in a connectionless fashion, providing connectivity and minimal user-disruption in the presence of mobility. In order to realize this goal, the !MobilityFirst team is engaged in a three-pronged, parallel effort on architectural design, protocol design, and implementation. Making use of the Rutgers-based ORBIT test as well as the national GENI infrastructure, !MobilityFirst protocols are currently being implemented and tested on a nationwide scale. The source code at the base of this implementation has been released and is available for testing to other research groups. |
| | 13 | For a quick overview of the high level features of the architecture, that will help form an idea of the different pieces of the software release, please visit the [wiki:Architecture Architecture Highlights] page or head back to the[http://mobilityfirst.winlab.rutgers.edu MobilityFirst project website]. |
| 11 | | The following subsections will introduce some of the core architectural concepts. |
| 12 | | |
| 13 | | === Name-based Networking === |
| 14 | | The !MobilityFirst architecture which emerged over the past 2-3 years is centered around a new name-based service layer which services as the “narrow-waist” of the protocol – this name-based service layer makes it possible to build advanced mobility-centric services in a flexible manner while also improving security and privacy properties. |
| 15 | | |
| 16 | | 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. |
| 17 | | |
| 18 | | ==== GUID is the new ''narrow waist'' ==== |
| 19 | | |
| 20 | | [[Image(narrow.png, 15%, nolink, center)]] |
| 21 | | |
| 22 | | A name-based service layer serves as the "narrow waist" of MobilityFirst protocol stack. All the traffic in MobilityFirst internet architecture runs over GUID namespace addressing. GUIDs are public key assigned by a name certification service (NCS) and are long lasting network-level names for objects. The GUID-based communication is assisted by GNRS (Global Name Resolution Service) and is sufficiently flexible to accommodate a variety of endpoint principals including interfaces, devices, users, services, content, context-aware descriptors and location-independent communication primitives such as device-to-device, device-to-service, content retrieval, context-aware delivery, multicast, anycast, and more. |
| 23 | | |
| 24 | | ==== Named Based Services ==== |
| 25 | | |
| 26 | | [[Image(namedAPI.png, 800, nolink, align=center)]] |
| 27 | | |
| 28 | | At the core of the architecture is a name-based networking abstraction that contrasts with the name-address conflated communication interface associated with Berkeley sockets and the TCP/IP stack. All network-attached objects in the !MobilityFirst architecture enjoy direct addressability through long lasting unique network names or identifiers (we use GUIDs). This new GUID-centric network service API, first presented in offers network primitives for basic messaging (send, recv) and content operations (get and post) while supporting several delivery modes innately supported by the MF network such as multihoming, multicast, anycast and DTN delivery. Combined with the GUID indirection and group- ing (GUID mapped to one or more other GUIDs) concepts supported by the naming services, the new communication API can produce novel addressing and delivery capabilities only indirectly possible (and with certain in-efficiency) in today’s IP architecture. Supporting the variety of services that are introduced in this API are then fundamental towards the validation of the architecture design. |
| 29 | | |
| 30 | | === Hybrid GUID/NA Routing and Forwarding === |
| 31 | | [[Image(hybrid-guid-na.png, 800, nolink, align=center)]] |
| 32 | | |
| 33 | | !MobilityFirst naming involves three layers: User level descriptor, such as Joe's car or John's mobile is first translated into a network level identifier. This is the globally unique identifier (GUID) that is a long lasting identifier at the network level. Next, in order to deliver packet to the end points, a GUID needs to be mapped to the current location of the GUID in the network. The mapping of the identifier to its routable network address (NA) is maintained by the global name resolution service (GNRS). |
| 34 | | As seen from the packet structure: |
| 35 | | |
| 36 | | [[Image(packet_structure.png, 300)]] |
| 37 | | |
| 38 | | data for an end-host is addressed both by its GUID and the NA it is currently attached to. Address can be resolved incrementally as the packet progresses through the network. |
| 39 | | |
| 40 | | [[Image(multihoming_scenario.png, 500, align=center)]] |
| 41 | | |
| 42 | | The figure shows a multihomed vehicle receiving data from a back-end server and highlights three types of binding of GUID to NA. At the source the GUID of Joe's car is resolved into the set of NAs it is currently attached to, through an early or at-source binding. However, while the data is in transit, if the end-host moves an attaches to a new location, a re-resolution occurs on failure, which is referred to as late binding. The hybrid GUID/NA naming also facilitates progressive binding by the network, which means the GUID is not directly bound to the exact port number attachment of the end point, but only to the network the end-point its is currently located in. When the data reaches that network, another lookup is performed that binds it to a local port within that network itself. |
| 43 | | |
| 44 | | |
| 45 | | |
| 46 | | |
| 47 | | {{{#!comment |
| 48 | | * [wiki:GeneralProjectMaterials General Project Materials] |
| 49 | | * [wiki:Architecture Architecture WG] |
| 50 | | * [wiki:NamingRouting Naming/Routing WG] |
| 51 | | * [wiki:SecurityPrivacy Security & Privacy WG] |
| 52 | | * [wiki:NetworkManagement Network Management WG] |
| 53 | | * [wiki:PervasiveMobile Pervasive/Mobile WG] |
| 54 | | * [wiki:Economics Economics WG] |
| 55 | | * [wiki:SystemPrototyping System Prototyping WG] |
| 56 | | * [wiki:EvaluationValidation Evaluation/Validation WG] |
| 57 | | * [wiki:ContentServices Content Services WG] |
| 58 | | * [wiki:ContextServices Context Services WG] |
| 59 | | |
| 60 | | |
| 61 | | * [wiki:SummerInternship Summer Internship] |
| 62 | | * [wiki:SummerInternship/2012 Summer Internship 2012] |
| 63 | | * [wiki:SummerInternship/2013 Summer Internship 2013] |
| 64 | | * [wiki:WINLABMeetings/Fall2013 WINLAB MF Meetings - Fall 2013] |
| 65 | | * [wiki:StudentPages Student Pages] |
| 66 | | }}} |
| 67 | | |
| | 15 | For any additional information, please free to contact Francesco Bronzino (bronzino@winlab.rutgers.edu) or Ivan Seskar (seskar@winlab.rutgers.edu). |
