| 3 | | 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. |
| 4 | | |
| 5 | | |
| 6 | | == Name Resolution Service == |
| 7 | | |
| 8 | | |
| 9 | | {{{ |
| 10 | | LNRS servers GNRS servers |
| 11 | | ^ ^ |
| 12 | | | | |
| 13 | | | | |
| 14 | | +-----------------+ +-----------------+ |
| 15 | | +---------------+ request +-----------------+ | | | | |
| 16 | | | | ---------> | Local Agent | ----------> | Local Name | -----------> | Global Name | |
| 17 | | | Host/Client | | Or | | Resolution | | Resolution | |
| 18 | | | | <--------- | Default Gateway | <---------- | Service(LNRS) | <----------- | Service(GNRS) | |
| 19 | | +---------------+ response +-----------------+ | server | | server | |
| 20 | | +-----------------+ +-----------------+ |
| 21 | | | | |
| 22 | | | | |
| 23 | | v v |
| 24 | | LNRS servers GNRS servers |
| 25 | | }}} |
| 26 | | |
| 27 | | === Host - GNRS interaction === |
| 28 | | |
| 29 | | A host may interact with the name resolution service to either (1) report/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. |
| 30 | | |
| 31 | | 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. |
| | 5 | {{{ |
| | 6 | The following sections detail the specifications for a prototype MobilityFirst |
| | 7 | network, and includes details of overall architecture, network elements, software |
| | 8 | services, protocols, end-host stack and network API. |
| | 9 | }}} |
| | 10 | |
| | 11 | == Interaction between Host/Client and Name Resolution Service == |
| | 12 | |
| | 13 | |
| | 14 | {{{ |
| | 15 | LNRS servers GNRS servers |
| | 16 | ^ ^ |
| | 17 | | | |
| | 18 | | | |
| | 19 | v v |
| | 20 | +-----------+ req +-------------+ +-------------+ +-------------+ |
| | 21 | | | -------> | Local Agent | ------> | | ------> | | |
| | 22 | |Host/Client| | OR | | LNRS server | | GNRS server | |
| | 23 | | | <------- | Gateway | <------ | | <------ | | |
| | 24 | +-----------+ resp +-------------+ +-------------+ +-------------+ |
| | 25 | ^ ^ |
| | 26 | | | |
| | 27 | | | |
| | 28 | v v |
| | 29 | LNRS servers GNRS servers |
| | 30 | }}} |
| | 31 | |
| | 32 | {{{ |
| | 33 | A host/client may interact with the name resolution service to either (1) report |
| | 34 | or update it's present network location binding(s), or, (2) to query corresponding |
| | 35 | bindings of other network entities. The target of such a query operation may |
| | 36 | constitute either a host, a service, content or even a named context. Similarly, |
| | 37 | an update is not limited to the host's location, but of any addressable entity so |
| | 38 | long as it is authorized to do so. |
| | 39 | |
| | 40 | As illustrated above, an request message to the GNRS may be sent either to a local |
| | 41 | NRS agent, or to the default gateway if an agent isn't configured or hasn't been |
| | 42 | established at time of request. The address of such a local agent could be a |
| | 43 | static system configuration as in a '/etc' file on Unix systems, or established |
| | 44 | by a periodic broadcast from the agent itself. |
| | 45 | |
| | 46 | }}} |
| 35 | | |
| 36 | | The following is the header of a name resolution request message: |
| 37 | | |
| | 50 | {{{ |
| | 51 | |
| | 52 | The name resolution service supports 3 types of requests from a client: insert, |
| | 53 | update and, a lookup or query request, where the operations may be thought |
| | 54 | equivalent to the basic functions on a map data structure storing key/value |
| | 55 | pairings. The difference between the insert and update requests is that the |
| | 56 | former equals a 'set' operation wherein any previous value mapped to the key is |
| | 57 | replaced by the new network location bindings. In an update operation, the |
| | 58 | semantics may be further qualified via an options field to either 'replace' or |
| | 59 | 'merge', for example, the existing with the presented bindings. |
| | 60 | |
| | 61 | }}} |
| | 62 | |
| | 63 | The following is the general format of a request message: |
| 46 | | | Request ID | |
| 47 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 48 | | ~ ~ |
| 49 | | | Sender Address N-bytes | |
| 50 | | ~ ~ |
| 51 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 52 | | ~ ~ |
| 53 | | | Request Payload | |
| 54 | | ~ ~ |
| 55 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 56 | | }}} |
| 57 | | |
| 58 | | * Update Request Message |
| | 72 | | Request ID | |
| | 73 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 74 | ~ ~ |
| | 75 | | Requestor Address N-bytes | |
| | 76 | ~ ~ |
| | 77 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 78 | ~ ~ |
| | 79 | | Request Payload | |
| | 80 | ~ ~ |
| | 81 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 82 | }}} |
| | 83 | |
| | 84 | Version:: |
| | 85 | protocol version |
| | 86 | Type of Message:: |
| | 87 | one of INSERT, UPDATE, LOOKUP |
| | 88 | Total Length:: |
| | 89 | total length of message including common header fields |
| | 90 | Request ID:: |
| | 91 | unique at client to differentiate among multiple outstanding requests |
| | 92 | Requestor Address:: |
| | 93 | route-able network address of request originator, for responding |
| | 94 | Request Payload:: |
| | 95 | variable size with format defined per request type -- see below |
| | 96 | |
| | 97 | ===== Update Request ===== |
| 73 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----+ |
| 74 | | | | | | |
| 75 | | | Type of Binding | Length of Binding (LB) | | |
| 76 | | | | | | |
| 77 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |---- Entry for Binding #1 |
| 78 | | ~ ~ | |
| 79 | | | Network Location Binding | | |
| 80 | | ~ ~ | |
| 81 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----+ |
| | 115 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ |
| | 116 | | | | | |
| | 117 | | Type of Binding | Length of Binding (LB) | | |
| | 118 | | | | |Entry |
| | 119 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |for |
| | 120 | ~ ~ |Binding#1 |
| | 121 | | Network Location Binding | | |
| | 122 | ~ ~ | |
| | 123 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ |
| | 148 | |
| | 149 | ==== Response Messages ==== |
| | 150 | |
| | 151 | {{{ |
| | 152 | As indicated in arch. figure above, responses may be generated at any level in the NRS |
| | 153 | hierarchy, condition to the options stated in request. The response contains both the |
| | 154 | details of original request and the result of the request, along with details of the |
| | 155 | responder required for any client-side verification. |
| | 156 | }}} |
| | 157 | |
| | 158 | {{{ |
| | 159 | |
| | 160 | 0 1 2 3 |
| | 161 | 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 |
| | 162 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 163 | | Version |Type of Message| Total Length (L) | |
| | 164 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 165 | | Request ID | |
| | 166 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 167 | ~ ~ |
| | 168 | | Responder Address N-bytes | |
| | 169 | ~ ~ |
| | 170 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 171 | | Response Code | | |
| | 172 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 173 | ~ ~ |
| | 174 | | Response Payload | |
| | 175 | ~ ~ |
| | 176 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | 177 | }}} |
| | 178 | |
| | 179 | Type of Message:: |
| | 180 | one of INSERT_ACK, UPDATE_ACK, LOOKUP_ACK |
| | 181 | Total Length:: |
| | 182 | total length of message including common header fields shown |
| | 183 | Request ID:: |
| | 184 | repeated from original request |
| | 185 | Responder Address:: |
| | 186 | route-able address of NRS entity that responded to request |
| | 187 | Response Code:: |
| | 188 | integer values indicating result of operation and/or error code including SUCCESS, FAILED |
