12345678901234567890123456789012345678901234567890123456789012345678901234567890
Specifications
The following sections detail the specifications for a prototype MobilityFirst network, and includes details of overall architecture, network elements, software services, protocols, end-host stack and network API.
Network Architecture
Router
MF Packet =
An MF packet is more appropriately a PDU or APDU that tries to balance requirements from both application and network sides, consequently providing high flexibility in destination addressing, delivery mechanisms, and in-route handling.
The following is the packet format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | ServiceID (SID) | NextHeader | UpperProtocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HopCount | #SourceNAs | #destNAs | PayloadOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source GUID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Source NA(s) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination GUID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Destination NA(s) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Service Header Extensions |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Storage Aware Routing
Hop-by-Hop Block Transfer
Network cache
Name Assignment Service
Name Resolution Service
Interaction between Host/Client and Name Resolution Service
LNRS servers GNRS servers
^ ^
| |
| |
v v
+-----------+ req +-------------+ +-------------+ +-------------+
| | ----> | Local Agent | ----> | | ----> | |
|Host/Client| | OR | | LNRS server | | GNRS server |
| | <---- | Gateway | <---- | | <---- | |
+-----------+ resp +-------------+ +-------------+ +-------------+
^ ^
| |
| |
v v
LNRS servers GNRS servers
A host/client may interact with the name resolution service to either (1) report or update it's present network address binding(s), or, (2) to query corresponding bindings of other network entities. The target of such a query operation may constitute either a host, a service, content or even a named context. Similarly, an update is not limited to the host's location, but of any addressable entity so long as it is authorized to do so.
As illustrated above, an request message to the GNRS may be sent either to a local NRS agent, or to the default gateway if an agent isn't configured or hasn't been established at time of request. The address of such a local agent could be a static system configuration as in a '/etc' file on Unix systems, or established by a periodic broadcast from the agent itself.
It is presumed that the local agent or gateway can interpret name resolution request messages and are configured to forward them to a local name resolution service (LNRS) server. The agent or gateway implementations may support responding to 'lookup' requests if the request options do not forbid doing so.
Next, the LNRS server may decide to respond to the request if the request options allow it, subject to the following implicit exclusions: (1) the request is an 'insert' (should be done on global service plane), (2) request is an update, and the new address bindings differ from previous beyond just the local address component
A request that reaches the global service plane is handled by the receiving GNRS server or forwarded onto a peer that can service it. The response, however, is routed directly back to the original requesting client - doesn't need to retrace onward path.
Requests
The name resolution service supports 3 types of requests from a client: insert, update and, a lookup or query request, where the operations may be thought equivalent to the basic functions on a map data structure storing key/value pairings.
The difference between the insert and update requests is that the former equals a 'set' operation wherein any previous value mapped to the key is replaced by the new network location bindings. In an update operation, the semantics may be further qualified via an options field to either 'replace' or 'merge', for example, the existing with the presented bindings.
The following is the general format of a request message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |Type of Message| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Requestor Address |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Request Payload |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Version
- protocol version
- Type of Message
- one of INSERT, UPDATE, LOOKUP
- Total Length
- total length of message including common header fields
- Request ID
- unique at client to differentiate among multiple outstanding requests
- Requestor Address
- route-able network address of request origin, for responding
- Request Payload
- variable size with format defined per request type -- see below
Insert/Update Request
An insert or update involves reporting new network location bindings to the name resolution service.
Following is the format for payload in a insert/update request.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| GUID |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size (S) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | |
| Address Type | Address Length | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Entry#1
~ ~ |
| Network Address #1 | |
~ ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
~ ~
| Entry #2 |
~ ~
|...............................................................|
~ ~
| Entry #S |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- GUID
- id of the network entity whose network address bindings are being inserted/updated
- Options
- TBD - e.g., caching restrictions, TTL
- Size
- number of network address bindings sent in this message
- Address Type
- address made generic to support multiple types such as flat network address, IP, geo location, etc
- Address Length
- length in bytes of corresponding address
- Network Address
- variable length value for the network address binding
Lookup Request
A lookup is performed to determine the present network location binding(s) of a network entity.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| GUID |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Response Messages
As indicated in arch. figure above, responses may be generated at any level in the NRS hierarchy, condition to the options stated in request. The response contains both the details of original request and the result of the request, along with details of the responder required for any client-side verification.
Following is the format of header fields of a response message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |Type of Message| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Origin Address |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
| Payload |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type of Message
- one of INSERT_ACK, UPDATE_ACK, LOOKUP_ACK
- Total Length
- total length of message including common header fields shown
- Request ID
- repeated from original request
- Origin Address
- route-able address of NRS entity that created the response
- Response Code
- integer values indicating result of operation and/or error code including SUCCESS, FAILED
- Payload
- custom response for each request type
Insert/Update Response
The payload is empty for responses to insert or update requests.
Lookup Response
The payload in a lookup response contains the network address bindings for the requested GUID, and follows format in the insert/update requests.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size (S) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | | |
| Address Type | Address Length | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Entry#1
~ ~ |
| Network Address #1 | |
~ ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
~ ~
| Entry #2 |
~ ~
|...............................................................|
~ ~
| Entry #S |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Application Programming Interface
Client Protocol Stack
Early Binding
- It is assumed that an end-host has obtained the GUID(s) of the other communication end-point or network entity through an out-of-band mechanism.
- A host can initiate communication through one of the following API:
- sendTo(GUID, message, [serviceId], [serviceOptios], ...)
- get(GUID, ...)
- ....
- Implementations of the above API within the end-host's MF stack execute early-binding when requested
- A GNRS lookup message (GL-msg) is prepared for the dest-GUID. See section on GNRS message specification for included fields.
- Target NRS server: A default or preferred server may be specified in a local config file, or one obtained by listening to local advertisements
- GL-msg is sent out on the default interface for GNRS lookups
- Closest or preferred NRS server will execute the actual lookup on the GNRS service plane
- A GNRS lookup response (GLR-msg) prepared by server with mapping is routed to the querying entity, and is picked up by the stack
- End-host stack inserts the network address from GLR-msg into the message header and transmits the packet on appropriate interface
Context Resolution Service
Context Server
7. Appendix A: Service Identifiers for the Wire Protocol
| Network service | SID Value | Description |
| Default | 0x0000 | Unicast, block transfer, temporary storage on poor link or down stream path, GNRS resolution |
| Multicast | 0x0001 | |
| Anycast | 0x0002 | |
| MultiHoming | 0x0004 | |
| GUID-routing | 0x0008 | Flat routing, no GNRS resolution |
| Stream | 0x0010 | |
| Real time | 0x0020 | |
| Delay Tolerant | 0x0040 | |
| Acknowledge on Store | 0x0080 | |
| Acknowledge on Delivery | 0x0100 | |
| Content Request | 0x0200 | |
| Content Response | 0x0400 | |
| Compute Layer Processing | 0x0800 | |
| Source Routing | 0x1000 | |
| Endpoint Broadcast | 0x2000 | Request broadcast of the data block at the destination, for example when addressing an access point. Ineffective when the destination has no mechanism to do broadcast |
| Future 1 | 0x4000 | |
| Extensions | 0x8000 |
SIDs for services not included above and to be introduced as future extensions to the delivery service follow the pattern 0x8xxx, and have to be specified as part of the extension service header. The SID value at the beginning of the field will have the high bit set to 1 to indicate there are extension service headers.
