| Version 12 (modified by , 11 years ago) ( diff ) |
|---|
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 data block by the destination, for example when addressing an access point. In effective 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.
Note:
See TracWiki
for help on using the wiki.
