Changes between Version 1 and Version 2 of Architecture

Timestamp:

Jun 4, 2016, 9:51:05 PM (8 years ago)

Author:

wontoniii

Comment:

--

Architecture

@@ -12 +12 @@
 ==== GUID is the new ''narrow waist'' ====
 
-[[Image(narrow.png, 15%, nolink, center)]]
+[[Image(wiki:WikiStart:narrow.png, 15%, nolink, center)]]
 
 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.
@@ -18 +18 @@
 ==== Named Based Services ====
 
-[[Image(namedAPI.png, 800, nolink, align=center)]]
+[[Image(wiki:WikiStart:namedAPI.png, 800, nolink, align=center)]]
 
 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.
 
 === Hybrid GUID/NA Routing and Forwarding ===
-[[Image(hybrid-guid-na.png, 800, nolink, align=center)]]
+[[Image(wiki:WikiStart:hybrid-guid-na.png, 800, nolink, align=center)]]
 
 !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).
 As seen from the packet structure:
 
-[[Image(packet_structure.png, 300)]]
+[[Image(wiki:WikiStart:packet_structure.png, 300)]]
 
 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. 
 
-[[Image(multihoming_scenario.png, 500, align=center)]]
+[[Image(wiki:WikiStart:multihoming_scenario.png, 500, align=center)]]
 
 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.