12345678901234567890123456789012345678901234567890123456789012345678901234567890 [[br]] = 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. }}} == 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 location 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. }}} ==== Request Messages ==== {{{ 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 (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Requestor Address N-bytes | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | 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 originator, for responding Request Payload:: variable size with format defined per request type -- see below ===== Update Request ===== {{{ An insert or update involves reporting new network location bindings to the name resolution service. }}} {{{ 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 N-bytes | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Size (S) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | | | | Type of Binding | Length of Binding (LB) | | | | | |Entry +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |for ~ ~ |Binding#1 | Network Location Binding | | ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ ~ ~ | Bindings #2-#S | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ }}} ===== 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 N-bytes | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. }}} {{{ 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 (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Responder Address N-bytes | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response Code | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ | Response 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 Responder Address:: route-able address of NRS entity that responded to request Response Code:: integer values indicating result of operation and/or error code including SUCCESS, FAILED ==== 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