close Warning: Can't synchronize with repository "(default)" ("(default)" is not readable or not a Git repository.). Look in the Trac log for more information.

Changes between Version 1 and Version 2 of Architecture


Ignore:
Timestamp:
Jun 4, 2016, 9:51:05 PM (5 years ago)
Author:
wontoniii
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Architecture

    v1 v2  
    1212==== GUID is the new ''narrow waist'' ====
    1313
    14 [[Image(narrow.png, 15%, nolink, center)]]
     14[[Image(wiki:WikiStart:narrow.png, 15%, nolink, center)]]
    1515
    1616A 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.
     
    1818==== Named Based Services ====
    1919
    20 [[Image(namedAPI.png, 800, nolink, align=center)]]
     20[[Image(wiki:WikiStart:namedAPI.png, 800, nolink, align=center)]]
    2121
    2222At 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.
    2323
    2424=== Hybrid GUID/NA Routing and Forwarding ===
    25 [[Image(hybrid-guid-na.png, 800, nolink, align=center)]]
     25[[Image(wiki:WikiStart:hybrid-guid-na.png, 800, nolink, align=center)]]
    2626
    2727!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).
    2828As seen from the packet structure:
    2929
    30 [[Image(packet_structure.png, 300)]]
     30[[Image(wiki:WikiStart:packet_structure.png, 300)]]
    3131
    3232data 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.
    3333
    34 [[Image(multihoming_scenario.png, 500, align=center)]]
     34[[Image(wiki:WikiStart:multihoming_scenario.png, 500, align=center)]]
    3535
    3636The 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.