idnits 2.17.1 draft-lindgren-dtnrg-gorf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 31, 2013) is 3922 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 505 -- Looks like a reference, but probably isn't: '2' on line 506 -- Looks like a reference, but probably isn't: '3' on line 508 == Unused Reference: 'RFC1058' is defined on line 3967, but no explicit reference was found in the text == Unused Reference: 'RFC6257' is defined on line 3978, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-tcp-clayer-06 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTN Research Group A. Lindgren 3 Internet-Draft SICS 4 Intended status: Experimental E. Davies 5 Expires: February 1, 2014 Folly Consulting 6 A. Doria 7 Consultant 8 July 31, 2013 10 Generic Opportunistic Routing Framework 11 draft-lindgren-dtnrg-gorf-00 13 Abstract 15 This document defines GORF, a Generic Opportunistic Routing 16 Framework. GORF specifies all necessary basic functionality that is 17 common for all utility-based routing protocols that are variants of 18 the epidemic routing protocol for intermittently connected networks 19 that operates by pruning the epidemic distribution tree to minimize 20 resource usage while still attempting to achieve the best case 21 routing capabilities of epidemic routing. It is intended for use in 22 sparse mesh networks where there is no guarantee that a fully 23 connected path between source and destination exists at any time, 24 rendering traditional routing protocols unable to deliver messages 25 between hosts. These networks are examples of networks where there 26 is a disparity between the latency requirements of applications and 27 the capabilities of the underlying network (networks often referred 28 to as Delay- and Disruption-Tolerant). The document presents an 29 architectural overview followed by the protocol specification. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 1, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Relation to the Delay Tolerant Networking architecture . . 4 66 1.2. Applicability of the routing framework . . . . . . . . . . 5 67 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 6 68 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.1. Routing Algorithm Module Conceptual Overview . . . . . . . 7 70 2.2. GORF . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2.1. Forwarding Strategies . . . . . . . . . . . . . . . . 7 72 2.3. Bundle Agent to Routing Agent Interface . . . . . . . . . 8 73 2.4. GORF Zone Gateways . . . . . . . . . . . . . . . . . . . . 9 74 2.5. Lower Layer Requirements and Interface . . . . . . . . . . 9 75 3. Routing Algorithm Modules . . . . . . . . . . . . . . . . . . 11 76 3.1. Routing Algorithm Identifier . . . . . . . . . . . . . . . 11 77 3.2. Module API - Internal State . . . . . . . . . . . . . . . 11 78 3.2.1. Metric format description syntax . . . . . . . . . . . 11 79 3.2.2. Routing Metric Format . . . . . . . . . . . . . . . . 14 80 3.2.3. Node Characteristics Format . . . . . . . . . . . . . 14 81 3.3. Module API - Functions . . . . . . . . . . . . . . . . . . 15 82 3.3.1. getMetricFormat() . . . . . . . . . . . . . . . . . . 16 83 3.3.2. getNodeCharFormat() . . . . . . . . . . . . . . . . . 16 84 3.3.3. getNodeCharacteristics() . . . . . . . . . . . . . . . 16 85 3.3.4. encounteredNode . . . . . . . . . . . . . . . . . . . 16 86 3.3.5. getRoutingState() . . . . . . . . . . . . . . . . . . 17 87 3.3.6. updateRoutingState() . . . . . . . . . . . . . . . . . 17 88 3.3.7. generateOffer . . . . . . . . . . . . . . . . . . . . 18 89 3.3.8. generateResponse . . . . . . . . . . . . . . . . . . . 18 90 3.3.9. bundleSent() . . . . . . . . . . . . . . . . . . . . . 19 91 3.3.10. getInformationExchangeTimer() . . . . . . . . . . . . 19 92 3.3.11. newBundleArrived() . . . . . . . . . . . . . . . . . . 20 93 3.3.12. nodeDisconnected() . . . . . . . . . . . . . . . . . . 20 94 3.3.13. dropAdvice . . . . . . . . . . . . . . . . . . . . . . 20 95 3.3.14. ackReceived() . . . . . . . . . . . . . . . . . . . . 21 97 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 22 98 4.1. Neighbor Awareness . . . . . . . . . . . . . . . . . . . . 22 99 4.2. Information Exchange Phase . . . . . . . . . . . . . . . . 22 100 4.2.1. Routing Information Base Dictionary . . . . . . . . . 25 101 4.2.2. Handling Multiple Simultaneous Contacts . . . . . . . 26 102 4.3. Bundle Passing . . . . . . . . . . . . . . . . . . . . . . 26 103 4.4. When a Bundle Reaches its Destination . . . . . . . . . . 26 104 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 28 105 5.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . . 29 106 5.2. TLV Structure . . . . . . . . . . . . . . . . . . . . . . 34 107 5.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 5.3.1. Hello TLV . . . . . . . . . . . . . . . . . . . . . . 35 109 5.3.2. Error TLV . . . . . . . . . . . . . . . . . . . . . . 37 110 5.3.3. Routing Information Base Dictionary TLV . . . . . . . 39 111 5.3.4. Routing Information Base TLV . . . . . . . . . . . . . 41 112 5.3.5. Bundle Offer and Response TLVs . . . . . . . . . . . . 42 113 6. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 47 114 6.1. High Level State Tables . . . . . . . . . . . . . . . . . 47 115 6.2. Hello Procedure . . . . . . . . . . . . . . . . . . . . . 51 116 6.2.1. Hello Procedure State Tables . . . . . . . . . . . . . 53 117 6.3. Information Exchange and Bundle Passing Phase . . . . . . 54 118 6.3.1. Initiator Role State Definitions . . . . . . . . . . . 57 119 6.3.2. Listener Role State Definitions . . . . . . . . . . . 62 120 6.3.3. Recommendations for Information Exchange Timer 121 Periods . . . . . . . . . . . . . . . . . . . . . . . 68 122 6.3.4. Information Exchange State Tables . . . . . . . . . . 69 123 7. Security Considerations . . . . . . . . . . . . . . . . . . . 83 124 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 125 8.1. DTN Routing Protocol Number . . . . . . . . . . . . . . . 85 126 8.2. GORF Protocol Version . . . . . . . . . . . . . . . . . . 85 127 8.3. GORF Header Flags . . . . . . . . . . . . . . . . . . . . 86 128 8.4. GORF Result Field . . . . . . . . . . . . . . . . . . . . 86 129 8.5. GORF Codes for Success and Codes for Failure . . . . . . . 87 130 8.6. GORF TLV Type . . . . . . . . . . . . . . . . . . . . . . 88 131 8.7. Hello TLV Flags . . . . . . . . . . . . . . . . . . . . . 89 132 8.8. Error TLV Flags . . . . . . . . . . . . . . . . . . . . . 90 133 8.9. RIB Dictionary TLV Flags . . . . . . . . . . . . . . . . . 90 134 8.10. RIB TLV Flags . . . . . . . . . . . . . . . . . . . . . . 91 135 8.11. RIB Flags . . . . . . . . . . . . . . . . . . . . . . . . 92 136 8.12. Bundle Offer and Response TLV Flags . . . . . . . . . . . 93 137 8.13. Bundle Offer and Response B Flags . . . . . . . . . . . . 94 138 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 95 139 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 96 140 10.1. Normative References . . . . . . . . . . . . . . . . . . . 96 141 10.2. Informative References . . . . . . . . . . . . . . . . . . 96 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 144 1. Introduction 146 A lot of research on Delay Tolerant Networking (DTN) [RFC4838] has 147 been carried out over the past decade. Much of this research have 148 focused on routing protocols and many routing algorithms have been 149 proposed in research papers. However, most protocol never get 150 further than a research paper, a simulation implementation, and 151 possibly an implementation for a real system that is not well 152 documented. This has the problem that it is hard to reproduce 153 research results. Designing a full routing protocol with all the 154 required details of protocol operation, message formats, state 155 machines, etc, is also a daunting and time-consuming task. This 156 makes experimentation with new ideas and routing algorithms 157 difficult, slowing potential progress in the area. 159 Many of the existing routing algorithms have a lot of similarities in 160 the way the operate. The protocols are essentially creating and 161 maintaining some sort of routing metric for different destinations. 162 This information is exchanged with other nodes as they 163 opportunistically meet. The nodes then make use of this information 164 to determine how to forward bundles in the network. While there are 165 many differences in how the routing metrics are maintained and 166 calculated, and what decision processes are used to make bundle 167 forwarding decisions, the basic mechnisms of the protocols are mostly 168 the same. 170 This document presents a framework for opportunistic routing 171 protocols in intermittently connected networks, using the mobility of 172 nodes to delivery messages. Many different algorithms exist for 173 determining how the selection of forwarding path is done, and this is 174 accomodated in the framework by providing a well-defined interface 175 that allows each routing algorithm to be specified in a separate 176 document. 178 Having a system like this has multiple benefits. First of all, it 179 makes it easy for people to create a well-defined and implementable 180 (interoperable) specification of a new routing algorithm that can 181 easily be used in a real system. Further, it makes prototyping and 182 testing of new routing algorithms quick and easy. Once the routing 183 framework is implemented, it is only necessary to create a new class/ 184 dynamic library/etc (depending on the implementation language) that 185 plugs into the main implementation. 187 1.1. Relation to the Delay Tolerant Networking architecture 189 The GORF routing framework is primarily designed to be used for 190 intermittently connected networks using the Delay-Tolerant Networking 191 (DTN) architecture [RFC4838] for communication in environments where 192 traditional communication protocols can not be used due to excessive 193 delays, link outages and other extreme conditions. Communication in 194 this architecture uses the bundle protocol [RFC5050], which provides 195 a way for applications to "bundle" an entire session, including both 196 data and meta-data, into a single message, or bundle, that can be 197 sent as a unit. The bundle protocol also provides end-to-end 198 addressing and acknowledgments. The GORF routing framework was 199 originally intended to provide routing services in a network 200 environment that uses bundles as its data transfer mechanism. 201 However, there are also many systems that utilize other types of 202 addressing and naming of nodes and content. There are currently 203 plans to add support in future versions of this document to 204 arbitrarily specify the format of node, destination, and message 205 identifiers to allow the GORF framework to also be used in systems 206 utilizing IP or some other underlying communication architecture. 208 1.2. Applicability of the routing framework 210 The GORF routing framework is mainly targeted at situations where at 211 least some of the nodes are mobile with mobility that creates 212 connectivity patterns that are not completely random over time but 213 have a degree of predictability. Such connectivity patterns can also 214 occur in networks where nodes switch off radios to preserve power. 216 The GORF framework expects nodes to be able to establish a local TCP 217 link in order to exchange the information needed by the framework. 218 Protocol signaling is done out-of-band over this TCP link, without 219 involving the Bundle Protocol agent [RFC5050]. The GORF framework 220 however expected to interact with the Bundle Protocol agent to 221 retrieve information about available bundles as well as requesting 222 that a bundle is sent to another node (it is expected that the 223 associated bundle agents are then able to establish a link (probably 224 over the TCP convergence layer [I-D.irtf-dtnrg-tcp-clayer]) to 225 perform this bundle transfer). 227 Since TCP offers reliable delivery, it is RECOMMENDED that the 228 positive acknowledgment capability is not used when GORF is run over 229 a TCP transport or similar protocol. When running over TCP, 230 implementations MAY safely ignore positive acknowledgments. 232 In a large Delay- and Disruption-Tolerant Network (DTN), network 233 conditions may vary widely, and in different parts of the network, 234 different routing protocols may be appropriate. In this 235 specification, we consider routing within a single "GORF zone", which 236 is a set of nodes among which messages are routed using an instance 237 of the GORF framework. In many cases, a GORF zone will not span the 238 entire DTN, but there will be other parts of the network with other 239 characteristics that run other routing protocols. To handle this, 240 there may be nodes within the zone that act as gateways to other 241 nodes that are the destinations for bundles generated within the zone 242 or that insert bundles into the zone. 244 1.3. Requirements notation 246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 248 document are to be interpreted as described in RFC 2119 [RFC2119]. 250 2. Architecture 252 This section provides an outline of the GORF architecture. More 253 details will be provided in subsequent sections. 255 2.1. Routing Algorithm Module Conceptual Overview 257 The GORF framework enables different routing algorithms for 258 intermittently connected networks to be easily defined and 259 implemented by specifying a Routing Algorithm Module. This module 260 implements a set of functions that provide the specialized 261 functionality required for that particular routing algorithm. A 262 detailed specification of the Routing Algorithm Module interface that 263 each module must implement is given in Section 3. This section 264 provides a conceptual overview of routing algorithm modules and their 265 use in the GORF framework. 267 Traditional routing protocols associate a cost (often the hop-count 268 with each destination) with each destination. The same is true for 269 utility-based routing protocols for metric associated with each known 270 destination. 272 2.2. GORF 274 When two GORF nodes have a communication opportunity, they first 275 exchange routing metrics for all relevant destinations known by the 276 nodes. This information is used by the nodes to update the internal 277 routing state based on the functions defined by the GORF API and 278 implemented by the routing algorithm module. After that, the nodes 279 exchange information (including destination and size) about the 280 bundles each node carries and the routing algorithm module then use 281 this information in conjunction with the updated routing state to 282 decide which bundles to request to be forwarded from the other node. 284 2.2.1. Forwarding Strategies 286 In traditional routing protocols, choosing where to forward a message 287 is usually a simple task; the message is sent to the neighbor that 288 has the path to the destination with the lowest cost (often the 289 shortest path). Normally the message is also only sent to a single 290 node since the reliability of paths is relatively high. However, in 291 the settings we envision here, things are radically different. The 292 first possibility that must be considered when a bundle arrives at a 293 node is that there might not be a path to the destination available, 294 so the node has to buffer the bundle and upon each encounter with 295 another node, the decision must be made whether or not to transfer a 296 particular bundle. Furthermore, having duplicates of messages (on 297 different nodes, as the bundle offer/request mechanism described in 298 Section 5.3.5 ensures that a node does not receive a bundle it 299 already carries) may also be sensible, as forwarding a bundle to 300 multiple nodes can increase the delivery probability of that bundle. 302 In a protocol based on the GORF framework, the decisions on which 303 bundle to forward is taken by the routing algorithm modules in the 304 generateOffer() and generateResponse() functions as defined in 305 Section 3.3.7 and Section 3.3.8. 307 2.3. Bundle Agent to Routing Agent Interface 309 The bundle protocol [RFC5050] introduces the concept of a "bundle 310 agent" that manages the interface between applications and the 311 "convergence layers" that provide the transport of bundles between 312 nodes during communication opportunities. This specification extends 313 the bundle agent with a routing agent that controls the actions of 314 the bundle agent during an (opportunistic) communications 315 opportunity. 317 This specification defines the details of the GORF framework routing 318 agent, but the interface defines a more general interface that is 319 also applicable to alternative routing protocols. 321 To enable the GORF framework routing agent to operate properly, it 322 must be aware of the bundles stored at the node, and it must also be 323 able to tell the bundle agent of that node to send a bundle to a 324 peering node. Therefore, the bundle agent needs to provide the 325 following interface/functionality to the routing agent: 327 Get Bundle List 328 Returns a list of the stored bundles and their attributes to the 329 routing agent. 331 Send Bundle 332 Makes the bundle agent send a specified bundle. 334 Accept Bundle 335 Gives the bundle agent a new bundle to store. 337 Bundle Delivered 338 Tells the bundle agent that a bundle was delivered to its 339 destination. 341 Drop Bundle Advice 342 Advises the bundle agent that a specified bundle should not be 343 offered for forwarding in future and may be dropped by the 344 bundle agent if appropriate. 346 Route Import 347 Can be used by a gateway node in a GORF zone to import 348 reachability information about EIDs that are external to the 349 GORF zone. Translation functions dependent on the external 350 routing protocol will be used to set the appropriate delivery 351 predictabilities for imported destinations as described in 352 Section 2.4. 354 Route Export 355 Can be used by a gateway node in a GORF zone to export 356 reachability information (destination EIDs and corresponding 357 delivery predictabilities) for use by routing protocols in other 358 parts of the DTN. 360 Implementation Note: Depending on the distribution of functions in 361 a complete bundle agent supporting the GORF framework, reception 362 and delivery of bundles may not be carried out directly by the 363 GORF framework module. In this case, the framework can inform the 364 bundle agent about bundles that have been requested from 365 communicating nodes. Then the Accept Bundle and Bundle Delivered 366 functions can be implemented as notifications of the GORF 367 framework module when the relevant bundles arrive at the node or 368 are delivered to local applications. 370 2.4. GORF Zone Gateways 372 GORF is designed to handle routing primarily within a "GORF zone," 373 i.e., a set of nodes that all implement the GORF routing framework 374 with a specific routing algorithm. However, since we recognise that 375 a GORF routing zone is unlikely to encompass an entire DTN, there may 376 be nodes within the zone that act as gateways to other nodes that are 377 the destinations for bundles generated within the zone or that insert 378 bundles into the zone. 380 GORF MAY elect to export and import routes across a bundle agent 381 interface. The delivery predictability to use for routes that are 382 imported depends on the routing protocol used to manage those routes. 383 If a translation function between the external routing protocol and 384 the GORF routing algorithm instance in use exists, it SHOULD be used 385 to set the delivery predictability. If no such translation function 386 exists, the delivery predictability SHOULD be set to 1. For those 387 routes that are exported, the current delivery predictability will be 388 exported with the route. 390 2.5. Lower Layer Requirements and Interface 392 GORF can be run on a large number of underlying networking 393 technologies. To accommodate its operation on all kinds of lower 394 layers, it requires the lower layers to provide the following 395 functionality and interfaces. 397 Neighbor discovery and maintenance 398 A GORF node needs to know the identity of its neighbors and when 399 new neighbors appear and old neighbors disappear. Some wireless 400 networking technologies might already contain mechanisms for 401 detecting neighbors and maintaining this state. To avoid 402 redundancies and inefficiencies, neighbor discovery is thus not 403 included as a part of GORF, but GORF relies on such a mechanism 404 in lower layers. The lower layers MUST provide the two 405 functions listed below. If the underlying networking technology 406 does not support such services, a simple neighbor discovery 407 scheme using local broadcasts of beacon messages could be run 408 in-between GORF and the underlying layer. 410 New Neighbor 411 Signals to the GORF framework agent that a new node has 412 become a neighbor. A neighbor is here defined as another 413 node that is currently within communication range of the 414 wireless networking technology in use. The GORF agent 415 should now start the Hello procedure as described in 416 Section 6.2. 418 Neighbor Gone 419 Signals to the GORF agent that one of its neighbors have 420 left. 422 Local Address 423 An address used by the underlying communication layer (e.g., an 424 IP or MAC address) that identifies the sender address of the 425 current message. This address must be unique among the nodes 426 that can currently communicate, and is only used in conjunction 427 with an Instance Number to identify a communicating pair of 428 nodes as described in Section 5.1. This address and its format 429 is dependent on the communication layer that is being used by 430 the GORF framework layer. 432 3. Routing Algorithm Modules 434 When defining a new routing algorithm module to be used with the GORF 435 framework, a section of the specificaion document should follow the 436 structure of this section, and provide definitions to the following 437 items/interfaces defined in the GORF API: 439 3.1. Routing Algorithm Identifier 441 Each module needs to specify which value should be used in the 442 Routing Algorithm Identifier in the GORF header defined in 443 Section 5.1. 445 3.2. Module API - Internal State 447 Each module needs to, at a minimum, define two pieces of internal 448 state information, the format of the routing metric and the format of 449 the node characteristic information to be shared among nodes. This 450 is further described in the rest of this section. 452 In addition to this, each routing module should in this section also 453 define any other internal state required for the routing algorithm to 454 work properly. This includes local variables, data structures, etc. 456 3.2.1. Metric format description syntax 457 Format definition: 459 Length: (octet) 460 Type[1]: (octet) 461 Type parameter[1]: < (octet) 462 . 463 . 464 . 465 Type[n]: 466 Type parameter[n]: 468 Where the type values are given by the table below. 470 +==================================================================+ 471 | Type value | Type description | Type parameter | Length | 472 +============+=========================+================+==========+ 473 | 0x00 | Reserved | N/A | N/A | 474 +------------+-------------------------+----------------+----------+ 475 | 0x01 | 8 bit integer value | N/A | 8 bits | 476 +------------+-------------------------+----------------+----------+ 477 | 0x02 | 16 bit integer value | N/A | 16 bits | 478 | | in network byte order | | | 479 +------------+-------------------------+----------------+----------+ 480 | 0x03 | 32 bit integer value | N/A | 32 bits | 481 | | in network byte order | | | 482 +------------+-------------------------+----------------+----------+ 483 | 0x04 | 64 bit integer value | N/A | 64 bits | 484 | | in network byte order | | | 485 +------------+-------------------------+----------------+----------+ 486 | 0x05 | SDNV integer value as | N/A | Variable | 487 | | defined in RFCxxxx | | | 488 +------------+-------------------------+----------------+----------+ 489 | 0x06 | String | N/A | Variable | 490 +------------+-------------------------+----------------+----------+ 491 | 0x07 | Bit sequence | N/A | Variable | 492 +------------+-------------------------+----------------+----------+ 493 | 0x08 | List | List type | Variable | 494 +==================================================================+ 496 Example specification. Assume a protocol has a node metric that 497 includes its position (two coordinates as 16 bit integers), and a 498 list of the IP addresses of all its currently connected neighbors (a 499 list of 32 bit integers). Then the metric format specification looks 500 like this: 502 Format definition: 503 ----------------------- 504 Length: 3 505 Type[1]: 0x02 506 Type[2]: 0x02 507 Type[3]: 0x08 508 Type parameter[3]: 0x03 509 ----------------------- 511 3.2.1.1. Binary representation as octet sequence 513 This format definition can also be described in a compact format as a 514 sequence of octets where each item in the structure above (length/ 515 type/type parameter) is one octet (the example above is given by the 516 octet sequence {0x03, 0x02, 0x02, 0x08, 0x03}). This format is what 517 is returned by the functions getMetricFormat() and 518 getNodeCharFormat() described further down in this section, and what 519 is included in GORF protocol messages. 521 3.2.1.2. Encoding of metric values 523 An instance/value of a particular metric format is given by an octet 524 sequence, where each item of a particular type is encoded as follows: 526 8 bit integer: Fixed length 8 bit integer value in the range 527 0-255. 529 16 bit integer: Fixed length 16 bit unsigned integer value in 530 network byte order. 532 32 bit integer: Fixed length 32 bit unsigned integer value in 533 network byte order. 535 64 bit integer: Fixed length 64 bit unsigned integer value in 536 network byte order. 538 SDNV value: Variable length integer value represented as SDNV. 540 String: Text string, formatted as follows: 542 String Length: 16 bit integer specifying the 543 number of characters in the 544 string 546 Characters: Sequence of characters making 547 up the string. 549 Bit sequence: Generic sequence of bits, formatted as follows: 551 Sequence Length: 16 bit integer specifying the 552 number of octets in the bit 553 sequence. 555 Octets: Octets making up the bit 556 sequence. 558 List: List of items, formatted as follows: 560 List type: 8 bit integer specifying the 561 type of the items in this list. 563 List length: 16 bit integer specifying the 564 number of items in this list. 566 List items: Sequence of items, formatted 567 according to the type of the 568 list. 570 3.2.2. Routing Metric Format 572 During the information exchange phase, two peering GORF nodes will 573 exchange a list of relevant destinations and the routing metrics 574 associated with them. As different routing algorithms may have need 575 for different such routing metrics Each routing algorithm module 576 specification should have a section that defines the format of this 577 routing metric according to the syntax defined in Section 3.2.1. The 578 binary format of this format is returned by the getMetricFormat() 579 function defined below. 581 3.2.3. Node Characteristics Format 583 In addition to distributing routing information in terms of routing 584 metrics associated with different destinations, a routing algorithm 585 may also need to exchange information about its local characteristics 586 with an encountered node. Such information could include location 587 information, resource availability (battery level or buffer space), 588 or any other information that the other node may possibly need to 589 make forwarding decisions and update its routing state. Each routing 590 algorithm module specification should have a section that defines the 591 format of this node characteristics metric according to the syntax 592 defined in Section 3.2.1. The binary format of this format is 593 returned by the getNodeCharFormat() function defined below. 595 3.3. Module API - Functions 597 A routing algorithm module need to define the following functions 598 that will be called by the GORF framework: 600 o Functions related to keeping track of routing metrics and node 601 characteristics: 603 * getMetricFormat() 605 * getNodeCharFormat() 607 * getNodeCharacteristic() 609 o Functions related to meeting new nodes and exchanging routing 610 information: 612 * encounteredNode() 614 * getRoutingState() 616 * updateRoutingState() 618 o Functions related to determining which bundles to exchange: 620 * generateOffer() 622 * generateResponse() 624 * bundleSent() 626 o Functions related to maintaining and using long-lived connections: 628 * informationExchangeTimer() 630 * newBundleArrived() 632 * nodeDisconnected() 634 o Functions related to buffer management: 636 * dropAdvice() 638 * ackReceived() 640 3.3.1. getMetricFormat() 642 Input: 644 o N/A 646 Output: 648 o Routing metric format string 650 This function returns the binary represenation (as defined in 651 Section 3.2.1.1) of the format of the routing metric as defined in 652 Section 3.2.2 used by this routing algorithm module. 654 3.3.2. getNodeCharFormat() 656 o N/A 658 Output: 660 o Node characteristics metric format string 662 This function returns the binary represenation (as defined in 663 Section 3.2.1.1) of the format of the node characteristics metric as 664 defined in Section 3.2.3 used by this routing algorithm module. This 665 is called by the GORF framework to insert the correct information in 666 the Hello messages. 668 3.3.3. getNodeCharacteristics() 670 o N/A 672 Output: 674 o Node characteristics metric string 676 This function returns the current value of the node characteristics 677 metric as defined in Section 3.2.3 used by this routing algorithm 678 module. This is called by the GORF framework to insert the correct 679 information in the Hello messages. 681 3.3.4. encounteredNode 683 Input: 685 o nodeID: node identifier of encountered node 686 o node characteristics: node characteristics field sent by the 687 peering node in the Hello message 689 o node characteristics format: (do we need to include this?) 691 Output: 693 o void 695 This function is called by the GORF framework when a new node is 696 encountered. The node identifier of the encountered node and the 697 node characteristics metric that was sent by the other node in the 698 Hello message is passed to the function. The function does not 699 return any value, but may update the internal routing state. 701 3.3.5. getRoutingState() 703 Input: 705 o fromNode: node identifier of encountered node 707 o (internal state) 709 Output: 711 o [(destination id, routing metric)]: list of destination id/routing 712 metric tuples 714 This function is called by the GORF framework whenever a routing 715 information should be sent to a peering node. The node id of the 716 encountered node is given to the function and it returns a list of 717 tuples containing destination ids and the associated routing metric 718 describing the internal routing state to be sent to the peering node. 719 A routing algorithm may choose not to only send a subset of its 720 routing state to the peering node based on internal state and the 721 identity of the peering node. 723 3.3.6. updateRoutingState() 725 Input: 727 o [(destination, routing metric)]: list of destination/routing 728 metric tuples 730 o fromNode: node identifier of encountered node 732 o (internal state) 733 Output: 735 o void 737 o (updated internal state) 739 This function is called by the GORF framework during the Information 740 Exchange Phase when the RIB with routing information has been 741 received from the peering node. The function takes a list of tuples 742 containing destination ids and the associated routing metric (in the 743 format given by the current routing metric format). The function 744 does not return anything, but uses the received information to update 745 the internal routing state. 747 3.3.7. generateOffer 749 Input: 751 o [(destination, routing metric)]: list of destination/routing 752 metric tuples 754 o fromNode: node identifier of encountered node 756 Output: 758 o [bundle ids]: list of bundles to be offered to the peering node 760 This function is called by the GORF framework during the Information 761 Exchange Phase to determine which bundles should be offered to a 762 peering node. The function takes a list of tuples containing 763 destination ids and the associated routing metric (in the format 764 given by the current routing metric format) and the node identifier 765 of the peering node. The function returns a list of bundle ids that 766 should be offered to the peering node based on the routing policy and 767 internal state of the routing algorithm. The list should be sorted 768 in the order that it is suggested that bundles are requested. 770 3.3.8. generateResponse 772 Input: 774 o [bundle ids]: list of bundles offered by the peering node 776 o [(destination, routing metric)]: list of destination/routing 777 metric tuples from peering node 779 o fromNode: node identifier of peering node 780 Output: 782 o [bundle ids]: list of bundles to be requested from the peering 783 node 785 This function is called by the GORF framework during the Information 786 Exchange Phase to determine which of the offered bundles should be 787 requested from a peering node. The function takes a list of offered 788 bundle ids, a list of tuples containing destination ids and the 789 associated routing metric (in the format given by the current routing 790 metric format) from the peering node, and the node identifier of the 791 peering node. The function returns a list of bundle ids that should 792 be requested from the peering, sorted in the order that the bundles 793 should be requested. 795 3.3.9. bundleSent() 797 Input: 799 o bundle id: The bundle id of the bundle sent to the peering node 801 o toNode: node identifier of the node that the bundle was sent to 803 Output: 805 o void 807 This function is called by the GORF framework when a bundle has been 808 forwarded to another node. Routing algorithms may want to keep track 809 of this information for future forwarding decisions. 811 3.3.10. getInformationExchangeTimer() 813 Input: 815 o N/A 817 Output: 819 o This function returns the value (in seconds) that should be used 820 for the Information Exchange Timer to trigger periodic restarts of 821 the Information Exchange Phase. If the function returns 0, this 822 trigger will be disabled. 824 3.3.11. newBundleArrived() 826 Input: 828 o bundle id: id of new bundle 830 o [peers]: list of currently connected peers 832 Output: 834 o [peers]: list of peers to offer this bundle to 836 This function is called by the GORF framework if a new bundle arrives 837 between two scheduled instances of the Information Exchange Phase. 838 The function uses the internal routing state and the routing metrics 839 received from the other peers currently connected with this node to 840 determine if this bundle should be offered to any of the peering 841 node. The function returns a list (possibly of length 0) of the 842 peers that should be offered this bundle. The GORF framework then 843 generates a BundleOffer message and sends to the corresponding nodes 844 in order to initiate a bundle transfer. 846 3.3.12. nodeDisconnected() 848 Input: 850 o nodeID: node identifier of the disconnected node 852 Output: 854 o void 856 This function is called by the GORF framework when a connection to a 857 peering node is lost. Routing algorithm modules may use this to, for 858 example, influence routing metrics depending on the duration of 859 contact opportunities. 861 3.3.13. dropAdvice 863 Input: 865 o n: number of bundles to drop 867 Output: 869 o [bundle ids]: list of bundle ids 871 This function is called by the GORF framework if buffer space is 872 limted such that some bundle must be prematurely deleted. The 873 function takes a number as input that defines the number of bundle 874 ids that it should return as candidates to be dropped. The function 875 returns a list of bundle ids of bundles that may be dropped by the 876 GORF framework, sorted in the order of preference for dropping. If 877 the input parameter is greater than the total number of bundles, the 878 resulting list will consist of all bundle ids. 880 3.3.14. ackReceived() 882 Input: 884 o ackList: List of bundle ids 886 Output: 888 o void 890 This function is called by the GORF framework when one or more GORF 891 ACKs are received. ackList contains a list of bundle ids for the 892 acked bundles. The function does not return anything, but may use 893 this information to update internal routing state. 895 4. Protocol Overview 897 4.1. Neighbor Awareness 899 Since the operation of the protocol is dependent on the encounters of 900 nodes running the GORF framework, the nodes must be able to detect 901 when a new neighbor is present. The protocol may be run on several 902 different networking technologies, and as some of them might already 903 have methods available for detecting neighbors, the GORF framework 904 does not include a mechanism for neighbor discovery. Instead, it 905 requires the underlying layer to provide a mechanism to notify the 906 protocol of when neighbors appear and disappear as described in 907 Section 2.5. 909 When a new neighbor has been detected, the protocol starts to set up 910 a link with that node through the Hello message exchange as described 911 in Section 6.2. The Hello message exchange allows for negotiation of 912 capabilities between neighbors. At present the only generic 913 capability is a request that the offering node should or should not 914 include bundle payload lengths with all offered bundles rather than 915 just for fragments. The Hello procedure is also used to exchange the 916 format used by the current routing algorithm to describe routing 917 metrics and destination identities (as described in Section 3.2.2). 918 Once the link has been set up the protocol may continue to the 919 Information Exchange Phase (see Section 4.2). This phase involves 920 the exchange of routing metrics that the nodes use to update their 921 internal state based on the current routing algorithm. Based on this 922 updated state and the information received from the peering node, 923 decisions are made on which bundles should be passed between the 924 encountering nodes using the corresponding functions in GORF API as 925 provided by the routing algorithm module. 927 4.2. Information Exchange Phase 929 The Information Exchange Phase involves the transfer of sets of four 930 types of information between the pair of connected nodes: 932 o Routing Information Base Dictionary (RIB Dictionary or RIBD), 934 o Routing Information Base (RIB), 936 o Bundle Offers, and 938 o Bundle Responses. 940 During a communication opportunity several sets of each type of 941 information may be transferred in each direction as explained in the 942 rest of this section. Each set can be transferred in one or more 943 messages. When (and only when) using a connection oriented reliable 944 transport protocol such as TCP as envisaged in this draft, a set can 945 be be partitioned across messages by the software layer above the 946 GORF routing framework engine. 948 In this case the last message in a set is flagged in the protocol. 949 This allows the higher level software to minimize the buffer memory 950 requirements by avoiding the need to build very large messages in one 951 go, and allows the message size to be controlled outside of the GORF 952 routing framework. However, this scheme is only usable if the 953 transport protocol provides reliable, in-order delivery of messages 954 as the messages are not explicitly sequence numbered and the overall 955 size of the set is not passed explicitly. 957 The specification of GORF also provides a sub-message mechanism and 958 retransmission that allows large messages specified by the higher 959 level to be transmitted in smaller chunks. This mechanism is 960 provided to allow GORF to operate over unreliable transport protocols 961 such as UDP, but can also be used with reliable transports if the 962 higher level software does not want to handle message fragmentation. 963 However, the sequencing and length adds overhead that is redundant if 964 the transport protocol already provides reliable, in-order delivery. 966 The first step in the Information Exchange Phase is for the protocol 967 to send one or more messages containing a RIB Dictionary TLV (Type- 968 Length-Value message component) to the node it is peering with. This 969 set of messages contain a dictionary of the Endpoint Identifiers 970 (EIDs) of the nodes that will be listed in the Routing Information 971 Base (RIB - see Section 4.2.1 for more information about this 972 dictionary). After this, one or more messages containing a Routing 973 Information Base TLV are sent. This TLV contains a list of the EIDs 974 that the node has knowledge of, and the corresponding routing metric 975 (as defined by the routing algorithm module) for those destinations, 976 together with flags describing the capabilities of the sending node. 977 Upon reception of a complete set of these messages, the peer node 978 updates its internal routing state according to the algorithm defined 979 by the updateRoutingState() function in the GORF API. The peer node 980 then applies its forwarding strategy as defined in the 981 generateOffer() function in the GORF API to determine which of its 982 stored bundles it wishes to offer the node that sent the RIB, which 983 will then be the receiver for any bundles to be transferred. 985 After making this decision, one or more Bundle Offer TLVs are 986 prepared, listing the bundle identifiers and their destinations for 987 all bundles the peer node wishes to offer to the receiver node that 988 sent the RIB. As described in [RFC5050], a bundle identifier 989 consists of up to five component parts. For a complete bundle the 990 identifier consists of 991 o Source EID, 993 o Creation Timestamp - Time of creation, and 995 o Creation Timestamp - Sequence Number. 997 Additionally, for a bundle fragment, the identifier also contains 999 o Offset within the payload at which the fragment payload data 1000 starts, and 1002 o Length of the fragment payload data. 1004 If any of the Bundle Offer TLVs lists a bundle for which the source 1005 or destination EID was not included in the previous set of RIB 1006 Dictionary information sent, one or more new RIBD TLVs are sent next 1007 with an incremental update of the dictionary. When the receiver node 1008 has a dictionary with all necessary EIDs, the Bundle Offer TLVs are 1009 sent to it. The Bundle Offer TLVs may also contain a list of GORF 1010 ACKs (see Section 4.4). If requested by the receiver node during the 1011 Hello phase the Bundle Offer TLV will also specify the payload length 1012 for all bundles rather than just for fragments. This information can 1013 be used by the receiving node to assist with the selection of bundles 1014 to be accepted from the offered list, especially if the available 1015 bundle storage capacity is limited. 1017 The receiving node then inputs the list of offered bundles to the 1018 generateResponse() function in the GORF API, which selects bundles 1019 that it will accept based on the routing algorithm used. The list 1020 returned by generateResponse() is sorted according to the priority 1021 order that the routing algorithm wants the bundles transferred in. 1022 The offering node SHOULD forward the selected bundles in this order. 1023 The prioritized list is sent to the offering node in one or more 1024 Bundle Response TLVs using the same EID dictionary as was used for 1025 the Bundle Offer TLV. 1027 When a new bundle arrives at a node, the node calls the 1028 newBundleArrived() function of the GORF API to inform the routing 1029 algorithm that a new bundle is available. The routing algorithm MAY 1030 inspect its list of available neighbors, and if one of them is a 1031 candidate to forward the bundle, a new Bundle Offer TLV MAY be sent 1032 to that node. If two nodes remain connected over a longer period of 1033 time, the Information Exchange Phase will be periodically re- 1034 initiated when the next_exchange timer expires to allow new routing 1035 metric information to be spread through the network and new bundle 1036 exchanges to take place. 1038 The Information Exchange phase of the protocol is described in more 1039 detail in Section 6.3. 1041 4.2.1. Routing Information Base Dictionary 1043 To reduce the overhead of the protocol, the Routing Information Base 1044 and Bundle Offer/Response TLVs utilize an EID dictionary. This 1045 dictionary maps variable length EIDs as defined in [RFC4838], which 1046 may potentially be quite long, to shorter numerical identifiers, 1047 coded as Self-Delimiting Numeric Values (SDNVs - see Section 4.1. of 1048 RFC 5050 [RFC5050]),that are used in place of the EIDs in subsequent 1049 TLVs. 1051 This dictionary is a shared resource between the two peering nodes. 1052 Each can add to the dictionary by sending a RIB Dictionary TLV to its 1053 peer. To allow either node to add to the dictionary at any time, the 1054 identifiers used by each node are taken from disjoint sets: 1055 identifiers originated by the node that started the Hello procedure 1056 have the least significant bit set to 0 (i.e., are even numbers) 1057 whereas those originated by the other peer have the least significant 1058 bit set to 1 (i.e., are odd numbers). This means that the dictionary 1059 can be expanded by either node at any point in the information 1060 exchange phase and the new identifiers can then be used in subsequent 1061 TLVs until the dictionary is reinitialized. 1063 The dictionary that is established only persists through a single 1064 encounter with a node (i.e., while the same link set up by the Hello 1065 procedure, with the same instance numbers, remains open). 1067 Having more then one identifier for the same EID does not cause any 1068 problems. This means that it is possible for the peers to create 1069 their dictionary entries independently if required by an 1070 implementation, but this may be inefficient as a dictionary entry for 1071 an EID might be sent in both directions between the peers. 1072 Implementers can choose to inspect entries sent by the node that 1073 started the Hello procedure and thereby eliminate any duplicates 1074 before sending the dictionary entries from the other peer. Whether 1075 postponing sending the other peer's entries is more efficient depends 1076 on the nature of the physical link technology and the transport 1077 protocol used. With a genuinely full duplex link it may be faster to 1078 accept possible duplication and send dictionary entries concurrently 1079 in both directions. If the link is effectively half-duplex (e.g., 1080 Wi-Fi), then it will generally be more efficient to wait and 1081 eliminate duplicates. 1083 If a node receives a RIB Dictionary TLV containing an identifier that 1084 is already in use, the node MUST confirm that the EID referred to is 1085 identical to the EID in the existing entry. Otherwise the node must 1086 send an error response to the message with the TLV containing the 1087 error and ignore the TLV containing the error. If a node receives a 1088 RIB, Bundle Offer or Bundle Response TLV that uses an identifier that 1089 is not in its dictionary, the node MUST send an error response and 1090 ignore the TLV containing the error. 1092 4.2.2. Handling Multiple Simultaneous Contacts 1094 From time to time a mobile node may, for example, be in wireless 1095 range of more than one other mobile node. The GORF neighbor 1096 awareness protocol will establish multiple simultaneous contacts with 1097 these nodes and commence information exchanges with each of them. 1099 If these simultaneous contacts persist for some time, then, as 1100 described in Section 4.2, the information exchange process will be 1101 periodically rerun for each contact according to the configured timer 1102 interval as given by the function informationExchangeTimer() in the 1103 GORF API (if a routing module chooses to have this function return 0, 1104 this means that the periodic reinitiation of the information exchange 1105 will be disabled). The interval between reruns of the information 1106 exchange will be set depending on the characteristics and behaviour 1107 of the routing algorithm defined by the current routing module, but 1108 will generally be set to a small fraction of the expected time 1109 between independent encounters of pairs of nodes. 1111 4.3. Bundle Passing 1113 Upon reception of the Bundle Offer TLV, the list of offered bundles 1114 is sent to the routing algorithm module through a call to the 1115 generateRequest() function in the GORF API. This function inspects 1116 the list of bundles and decides (based on the routing algorithm) 1117 which bundles it is willing to store for future forwarding, or that 1118 it is able to deliver to their destination. The function will 1119 generate a Bundle Response TLV with a list of requested bundles that 1120 is then sent by the GORF framework to its peering node, which in 1121 response to that sends the requested bundle(s). If a node has some 1122 bundles it would prefer to receive ahead of others offered (e.g., 1123 bundles that it can deliver to their final destination), it MAY 1124 request the bundles in that priority order. This is often desirable 1125 as there is no guarantee that the nodes will remain in contact with 1126 each other for long enough to transfer all the acceptable bundles. 1127 Otherwise, the node SHOULD assume that the bundles are listed in a 1128 priority order determined by the peering node's forwarding strategy, 1129 and request bundles in that order. 1131 4.4. When a Bundle Reaches its Destination 1133 When a bundle reaches its destination within the GORF zone (i.e., 1134 within the part of the network where the GORF based routing protocol 1135 is used for routing; not necessarily the final destination of the 1136 bundle), a GORF ACK for that bundle is issued. A GORF ACK is a 1137 confirmation that a bundle has been delivered to its destination in 1138 the GORF zone (bundles might traverse several different types of 1139 networks using different routing protocols; thus, this might not be 1140 the final destination of the bundle). When nodes exchange Bundle 1141 Offer TLVs, bundles that have been ACKed are also listed, having the 1142 "GORF ACK" flag set. The node that receives this list updates its 1143 own list of ACKed bundles to be the union of its previous list and 1144 the received list. To prevent the list of ACKed bundles growing 1145 indefinitely, each GORF ACK should have a timeout that MUST NOT be 1146 longer than the timeout of the bundle to which the ACK corresponds. 1148 When a node receives a GORF ACK for a bundle it is carrying, it MAY 1149 delete that bundle from its storage, unless the node holds custody of 1150 that bundle. The GORF ACK only indicates that a bundle has been 1151 delivered to its destination within the GORF zone, so the reception 1152 of a GORF ACK is not a guarantee that the bundle has been delivered 1153 to its final destination. The GORF framework will also call the 1154 ackReceived() function in the GORF API to inform the routing module 1155 that an ACK has been received for this bundle. 1157 Nodes MAY keep track of which nodes they have sent GORF ACKs for 1158 certain bundles to, and MAY in that case refrain from sending 1159 multiple GORF ACKs for the same bundle to the same node. 1161 If necessary in order to preserve system resources, nodes MAY drop 1162 GORF ACKs prematurely, but SHOULD refrain from doing so if possible. 1164 It is important to keep in mind that GORF ACKs and bundle 1165 ACKs[RFC5050] are different things. GORF ACKs are only valid within 1166 the GORF part of the network, while bundle ACKs are end-to-end 1167 acknowledgments that may go outside of the GORF zone. 1169 5. Message Formats 1171 This section defines the message formats of the GORF routing protocol 1172 framework. In order to allow for variable length fields, many 1173 numeric fields are encoded as Self-Delimiting Numeric Values (SDNVs). 1174 The format of SDNVs is defined in [RFC5050]. Furthermore, certain 1175 fields describing routing metrics or node characteristics are encoded 1176 according to the routing metric encoding format defined in 1177 Section 3.2.2. Since many of the fields are coded as SDNVs or in the 1178 routing algorithm dependent metric format, the size and alignment of 1179 fields indicated in many of the specification diagrams below are 1180 indicative rather than prescriptive. Where SDNVs and/or text strings 1181 are used, the octets of the fields will be packed as closely as 1182 possible with no intervening padding between fields. 1184 Explicit length fields are specified for all variable length string 1185 fields. Accordingly, strings are not null-terminated and just 1186 contain the exact set of octets in the string. 1188 The basic message format shown in Figure 1 consists of a header (see 1189 Section 5.1) followed by a sequence of one or more Type-Length-Value 1190 components (TLVs) taken from the specifications in Section 5.2 1192 0 1 2 3 1193 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | | 1196 ~ Header ~ 1197 | | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | | 1200 ~ TLV 1 ~ 1201 | | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | . | 1204 ~ . ~ 1205 | . | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | | 1208 ~ TLV n ~ 1209 | | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 Figure 1: Basic GORF Message Format 1214 5.1. Header 1216 0 1 2 3 1217 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 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 |Protocol Number|Version| Flags | Result | Code | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Routing Algorithm Identifier | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | Receiver Instance | Sender Instance | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | Transaction Identifier | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 |S| SubMessage Number | Length (SDNV) | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | | 1230 ~ Message Body ~ 1231 | | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 Figure 2: GORF Message Header 1236 Protocol Number 1237 The DTN Routing Protocol Number encoded as 8 bit unsigned 1238 integer in network bit order. The value of this field is 0x01. 1239 The GORF header is organized in this way so that in principle 1240 GORF messages could be sent as the Protocol Data Unit of an IP 1241 packet if an IP protocol number was allocated for GORF. At 1242 present GORF is only specified to use a TCP transport for 1243 carriage of GORF packets so that the protocol number serves only 1244 to identify the GORF protocol within DTN. 1246 Version 1247 The Version of the GORF Protocol. Encoded as a four bit 1248 unsigned integer in network bit order. This document defines 1249 version 2. 1251 Flags 1252 Reserved field of 4 bits. 1254 Result 1255 Field that is used to indicate whether a response is required to 1256 the request message if the outcome is successful. A value of 1257 "NoSuccessAck" indicates that the request message does not 1258 expect a response if the outcome is successful, and a value of 1259 "AckAll" indicates that a response is expected if the outcome is 1260 successful. In both cases a failure response MUST be generated 1261 if the request fails. If running over a TCP transport or 1262 similar protocol that offers reliable in order delivery, 1263 deployments MAY choose not to send "Success" responses when an 1264 outcome is successful. To achieve this the Result field is set 1265 to the "NoSuccessAck" value in all request messages. 1267 In a response message, the result field can have two values: 1268 "Success," and "Failure". The "Success" results indicates a 1269 success response. All messages that belong to the same success 1270 response will have the same Transaction Identifier. The 1271 "Success" result indicates a success response that may be 1272 contained in a single message or the final message of a success 1273 response spanning multiple messages. 1275 ReturnReceipt is a value of the result field used to indicate 1276 that an acknowledgement is required for the message. The 1277 default for Messages is that the controller will not acknowledge 1278 responses. In the case where an acknowledgement is required, it 1279 will set the Result Field to ReturnReceipt in the header of the 1280 Message. 1282 The result field is encoded as an 8 bit unsigned integer in 1283 network bit order. The following values are currently defined: 1285 NoSuccessAck: Result = 1 1286 AckAll: Result = 2 1287 Success: Result = 3 1288 Failure: Result = 4 1289 ReturnReceipt Result = 5 1291 Code 1292 This field gives further information concerning the result in a 1293 response message. It is mostly used to pass an error code in a 1294 failure response but can also be used to give further 1295 information in a success response message or an event message. 1296 In a request message, the code field is not used and is set to 1297 zero. 1299 If the Code field indicates that the Error TLV is included in 1300 the message, further information on the error will be found in 1301 the Error TLV, which MUST be the the first TLV after the header. 1303 The Code field is encoded as an 8 bit unsigned integer in 1304 network bit order. Separate number code spaces are used for 1305 success and failure response messages. In each case a range of 1306 values is provided reserved for use in specifications and 1307 another range for private and experimental use. For success 1308 messages the following values are defined: 1310 Generic Success 0x00 1311 Submessage Received 0x01 1312 Reserved 0x02 - 0x7F 1313 Private/Experimental Use 0x80 - 0xFF 1315 The Submessage Received code is used to acknowledge reception of 1316 a message segment. The Generic Success code is used to 1317 acknowledge receipt of a complete message and successful 1318 processing of the contents. 1320 For failure messages, the following values are defined: 1322 Reserved 0x00 - 0x01 1323 Unspecified Failure 0x02 1324 Reserved 0x03 - 0x7F 1325 Private/Experimental Use 0x80 - 0xFE 1326 Error TLV in message 0xFF 1328 The Unspecified Failure code can be used to report a failure for 1329 which there is no more specific code or Error TLV value defined. 1331 Routing Algorithm Identifier 1332 The Routing Algorithm Identifier specifies which routing 1333 algorithm module specification is to be used to define the 1334 functions outlined in Section 3.3 that will be called by the 1335 GORF API to implement the specific routing algorithm 1336 functionality. 1338 The encoding of the Routing Algorithm Identifier field is: 1340 +------------------+-------------+----------------------------------+ 1341 | Routing | Value | Reference | 1342 | Algorithm | | | 1343 +------------------+-------------+----------------------------------+ 1344 | Reserved (do not | 0x0000 | This document | 1345 | allocate) | | | 1346 | | | | 1347 | Epidemic Routing | 0x0001 | draft-lindgren-dtnrg-gorf-epidem | 1348 | | | i c-00 | 1349 | | | | 1350 | PRoPHETv2 | 0x0002 | draft-lindgren-dtnrg-gorf-prophe | 1351 | | | t -00 | 1352 | | | | 1353 | dLife? | 0x0003 | draft-mendes-dtnrg-gorf-dlife-00 | 1354 | | | ?? | 1355 | | | | 1356 | Reserved | 0x0004-0xFF | Specification required | 1357 | | E F | | 1358 | Private/Experime | 0xFFF0-0xFF | Experimental | 1359 | n tal use | F E | | 1360 +------------------+-------------+----------------------------------+ 1362 Sender Instance 1363 For messages during the Hello phase with the Hello SYN, Hello 1364 SYNACK, and Hello ACK functions (which are explained in 1365 Section 6.2), it is the sender's instance number for the link. 1366 It is used to detect when the link comes back up after going 1367 down or when the identity of the entity at the other end of the 1368 link changes. The instance number is a 16-bit number that is 1369 guaranteed to be unique within the recent past and to change 1370 when the link or node comes back up after going down. Zero is 1371 not a valid instance number. For the RSTACK function (also 1372 explained in detail in Section 6.2), the Sender Instance field 1373 is set to the value of the Receiver Instance field from the 1374 incoming message that caused the RSTACK function to be 1375 generated. Messages sent after the Hello phase is completed 1376 should use the sender's instance number for the link. The 1377 Sender Instance is encoded as a 16 bit unsigned integer in 1378 network bit order. 1380 Receiver Instance 1381 For messages during the Hello phase with the Hello SYN, Hello 1382 SYNACK, and Hello ACK functions, is what the sender believes is 1383 the current instance number for the link, allocated by the 1384 entity at the far end of the link. If the sender of the message 1385 does not know the current instance number at the far end of the 1386 link, this field MUST be set to zero. For the RSTACK message, 1387 the Receiver Instance field is set to the value of the Sender 1388 Instance field from the incoming message that caused the RSTACK 1389 message to be generated. Messages sent after the Hello phase is 1390 completed should use what the sender believes is the current 1391 instance number for the link, allocated by the entity at the far 1392 end of the link. The Sender Instance is encoded as a 16 bit 1393 unsigned integer in network bit order. 1395 Transaction Identifier 1396 Used to associate a message with its response message. This 1397 should be set in request messages to a value that is unique for 1398 the sending host within the recent past. Reply messages contain 1399 the Transaction Identifier of the request they are responding 1400 to. The Transaction Identifier is a 32 bit bit pattern. 1402 S-flag 1403 If S is set (value 1) then the SubMessage Number field indicates 1404 the total number of SubMessage segments that compose the entire 1405 message. If it is not set (value 0) then the SubMessage Number 1406 field indicates the sequence number of this SubMessage segment 1407 within the whole message. the S field will only be set in the 1408 first sub-message of a sequence. 1410 SubMessage Number 1411 When a message is segmented because it exceeds the MTU of the 1412 link layer or otherwise, each segment will include a SubMessage 1413 Number to indicate its position. Alternatively, if it is the 1414 first sub-message in a sequence of sub-messages, the S flag will 1415 be set and this field will contain the total count of SubMessage 1416 segments. The SubMessage Number is encoded as a 15-bit unsigned 1417 integer in network bit order. The SubMessage number is zero- 1418 based, i.e., for a message divided into n sub-messages, they are 1419 numbered from 0 to (n - 1). For a message that it is not 1420 divided into sub-messages the single message has the S-flag 1421 cleared (0) and the SubMessage Number is set to 0 (zero). 1423 Length 1424 Length in octets of this message including headers and message 1425 body. If the message is fragmented, this field contains the 1426 length of this SubMessage. The Length is encoded as an SDNV. 1428 Message Body 1429 As specified in Section 5, the Message Body consists of a 1430 sequence of one or more of the TLVs specified in Section 5.2. 1432 The protocol also requires extra information about the link that the 1433 underlying communication layer MUST provide. This information is 1434 used in the Hello procedure described in more detail in Section 6.2. 1435 Since this information is available from the underlying layer, there 1436 is no need to carry it in GORF messages. The following values are 1437 defined to be provided by the underlying layer: 1439 Sender Local Address 1440 An address used by the underlying communication layer as 1441 described in Section 2.5 that identifies the sender address of 1442 the current message. This address must be unique among the 1443 nodes that can currently communicate, and is only used in 1444 conjunction with the Receiver Local Address and the Receiver 1445 Instance and Sender Instance to identify a communicating pair of 1446 nodes. 1448 Receiver Local Address 1449 An address used by the underlying communication layer as 1450 described in Section 2.5 that identifies the receiver address of 1451 the current message. This address must be unique among the 1452 nodes that can currently communicate, and is only used in 1453 conjunction with the Sender Local Address and the Receiver 1454 Instance and Sender Instance to identify a communicating pair of 1455 nodes. 1457 When GORF is run over TCP, the IP addresses of the communicating 1458 nodes are used as Sender and Receiver Local Addresses. 1460 5.2. TLV Structure 1462 All TLVs have the following format, and can be nested. 1464 0 1 2 3 1465 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 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | TLV Type | TLV Flags | TLV Length (SDNV) | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | | 1470 ~ TLV Data ~ 1471 | | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 Figure 3: TLV Format 1476 TLV Type 1477 Specific TLVs are defined in Section 5.3. The TLV Type is 1478 encoded as an 8 bit unsigned integer in network bit order. Each 1479 TLV will have fields defined that are specific to the function 1480 of that TLV. 1482 TLV Flags 1483 These are defined per TLV type. Flag n corresponds to bit 15-n 1484 in the TLV. Any flags which are specified as reserved in 1485 specific TLVs SHOULD be transmitted as 0 and ignored on receipt. 1487 TLV Length 1488 Length of the TLV in octets, including the TLV header and any 1489 nested TLVs. Encoded as an SDNV. Note that TLVs are not padded 1490 to any specific alignment unless explicitly required in the 1491 description of the TLV. No TLVs in this document specify any 1492 padding. 1494 5.3. TLVs 1496 This section describes the various TLVs that can be used in GORF 1497 messages. 1499 5.3.1. Hello TLV 1501 The Hello TLV is used to set up and maintain a link between two GORF 1502 nodes. Hello messages with the SYN function are transmitted 1503 periodically as beacons or keep alives. The Hello TLV is the first 1504 TLV exchanged between two GORF nodes when they encounter each other. 1505 No other TLVs can be exchanged until the first Hello sequence is 1506 completed. 1508 Once a communication link is established between two GORF nodes, the 1509 Hello TLV will be sent once for each interval as defined in the 1510 interval timer. If a node experiences the lapse of HELLO_DEAD Hello 1511 intervals without receiving a Hello TLV on a connection in the 1512 INFO_EXCH state (as defined in the state machine in Section 6.1), the 1513 connection SHOULD be assumed broken. 1515 0 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | TLV Type=0x01 |L| Resv | HF | TLV Length (SDNV) | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | Timer (SDNV) |EID Length,SDNV| Sender EID (variable length) | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Node Characteristics Format (variable length) | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | Node Characteristics (variable length) | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 Figure 4: Hello TLV Format 1529 TLV Flags 1530 The TLV Flags field contains two single bit flags (S and L) and 1531 a three bit Hello Function (HF) number that specifies one of 1532 four functions for the Hello TLV. The remaining three bits 1533 (Resv) are unused and reserved: 1535 HF 1536 TLV Flags bits 0, 1, and 2 are treated as an unsigned 3 bit 1537 integer coded in network bit order. The value of the 1538 integer specifies the Hello Function (HF) of the Hello TLV. 1539 Four functions are specified for the Hello TLV. 1541 The encoding of the Hello Function is: 1543 SYN: HF = 1 1544 SYNACK: HF = 2 1545 ACK: HF = 3 1546 RSTACK: HF = 4 1548 The remaining values (0, 5, 6 and 7) are unused and 1549 reserved. If a Hello TLV with any of these values is 1550 received, the link should be reset. 1552 Resv 1553 TLV Flags bits 3, 4, 5, and 6 are reserved. They SHOULD be 1554 set to 0 on transmission and ignored on reception. 1556 L 1557 The L bit flag (TLV Flags bit 7) is set (1) to request that 1558 the Bundle Offer TLV sent during the Information Exchange 1559 phase contains bundle payload lengths for all bundles, 1560 rather than only for bundle fragments if the L flag is 1561 cleared (0), when carried in a Hello TLV with Hello 1562 Function SYN or SYNACK. The flag is ignored for other 1563 Hello Function values. 1565 TLV Data 1567 Timer 1568 The Timer field is used to inform the receiver of the timer 1569 value used in the Hello processing of the sender. The 1570 timer specifies the nominal time between periodic Hello 1571 messages. It is a constant for the duration of a session. 1572 The timer field is specified in units of 100ms and is 1573 encoded as an SDNV. 1575 EID Length 1576 The EID Length field is used to specify the length of the 1577 Sender EID field in octets. If the Endpoint Identifier 1578 (EID) has already been sent at least once in a message with 1579 the current Sender Instance, a node MAY choose to set this 1580 field to zero, omitting the Sender EID from the Hello TLV. 1581 The EID Length is encoded as an SDNV and the field is thus 1582 of variable length. 1584 Sender EID 1585 The Sender EID field specifies the DTN endpoint identifier 1586 (EID) of the sender that is to be used in updating routing 1587 information and making forwarding decisions. If a node has 1588 multiple EIDs, one should be chosen for GORF routing. This 1589 field is of variable length. 1591 Node Characteristics Format 1592 The Node Characteristics Format field specifies the format 1593 used to describe the node characteristics of the node. The 1594 field is in the binary octet sequence representation of 1595 this format as described in Section 3.2.1.1. The GORF 1596 framework will call the getNodeCharFormat() function 1597 described in Section 3.3.2 to get this value. 1599 Node Characteristics 1600 The Node Characteristics field contains the value of the 1601 node characteristics that should be sent to the peering 1602 node. The content of this field is formatted according to 1603 the format given in the previous field. The GORF framework 1604 will call the getNodeCharacteristics() function in the GORF 1605 API described in Section 3.3.3 to get this value. 1607 5.3.2. Error TLV 1609 0 1 2 3 1610 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 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | TLV type=0x02 | TLV Flags | TLV Length (SDNV) | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1614 | | 1615 ~ TLV Data ~ 1616 | | 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1619 Figure 5: Error TLV Format 1621 TLV Flags 1622 For Error TLVs the TLV Flags field carries an identifier for the 1623 Error TLV type as an 8 bit unsigned integer encoded in network 1624 bit order. A range of values is available for private and 1625 experimental use in addition to the values defined here. The 1626 following Error TLV types are defined: 1628 Dictionary Conflict 0x00 1629 Bad String ID 0x01 1630 Reserved 0x02 - 0x7F 1631 Private/Experimental Use 0x80 - 0xFF 1633 TLV Data 1634 The contents and interpretation of the TLV Data field are 1635 specific to the type of Error TLV. For the Error TLVs defined 1636 in this document the TLV Data is defined as follows: 1638 Dictionary Conflict 1639 The TLV Data consists of the String ID causing the conflict 1640 encoded as an SDNV followed by the Endpoint Identifier 1641 string that conflicts with the previously installed value. 1642 The Endpoint Identifier is NOT null terminated. The length 1643 of the Endpoint Identifier can be determined by subtracting 1644 the length of the TLV Header and the length of the SDNV 1645 containing the String ID. 1647 Bad String ID 1648 The TLV Data consists of the String ID that is not found in 1649 the dictionary encoded as an SDNV. 1651 5.3.3. Routing Information Base Dictionary TLV 1653 The Routing Information Base Dictionary includes the list of endpoint 1654 identifiers used in making routing decisions. The referents remain 1655 constant for the duration of a session over a link where the instance 1656 numbers remain the same and can be used by both the Routing 1657 Information Base messages and the bundle offer/response messages. 1658 The dictionary is a shared resource (see Section 4.2.1) built in each 1659 of the paired peers from the contents of one or more incoming TLVs of 1660 this type and the information used to create outgoing TLVs of this 1661 type. 1663 0 1 2 3 1664 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 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | TLV type=0xA0 | TLV Flags | TLV Length (SDNV) | 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 | RIBD Entry Count (SDNV) | 1669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1670 ~ ~ 1671 ~ Variable Length Routing Address Strings ~ 1672 ~ ~ 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 ~ Routing Address String 1 ~ 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | String ID 1 (SDNV) | Length (SDNV) | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 ~ Endpoint Identifier 1 (variable length) ~ 1681 | | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | . | 1684 ~ Routing Address String n . ~ 1685 | . | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | String ID n (SDNV) | Length (SDNV) | 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | | 1690 ~ Endpoint Identifier n (variable length) ~ 1691 | | 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 Figure 6: Routing Information Base Dictionary TLV Format 1696 TLV Flags 1697 The encoding of the Header flag field relates to the 1698 capabilities of the Source node sending the RIB Dictionary: 1700 Flag 0: Sent by Listener 0b1 1701 Flag 1: Reserved 0b1 1702 Flag 2: Reserved 0b1 1703 Flag 3: Reserved 0b1 1704 Flag 4: Reserved 0b1 1705 Flag 5: Reserved 0b1 1706 Flag 6: Reserved 0b1 1707 Flag 7: Reserved 0b1 1709 The Sent by Listener flag is set to 0 if this TLV was sent by a 1710 node in the Initiator role and set to 1 if this TLV was sent by 1711 a node in the Listener role (see Section 4.2 for explanations of 1712 these roles). 1714 TLV Data 1716 RIBD Entry Count 1717 Number of entries in the database. Encoded as SDNV. 1719 String ID 1720 SDNV identifier that is constant for the duration of a 1721 session. String ID zero is predefined as the node 1722 initiating the session through sending the Hello SYN 1723 message, and String ID one is predefined as the node 1724 responding with the Hello SYNACK message. These entries do 1725 not need to be sent explicitly as the EIDs are exchanged 1726 during the Hello procedure. 1728 In order to ensure that the String IDs originated by the 1729 two peers do not conflict, the String IDs generated in the 1730 node that sent the Hello SYN message MUST have their least 1731 significant bit set to 0 (i.e., are even numbers) and the 1732 String IDs generated in the node that responded with the 1733 Hello SYNACK message MUST have their least significant bit 1734 set to 1 (i.e., they are odd numbers). 1736 Length 1737 Length of Endpoint Identifier in this entry. Encoded as 1738 SDNV. 1740 Endpoint Identifier 1741 Text string representing the Endpoint Identifier. Note 1742 that it is NOT null terminated as the entry contains the 1743 length of the identifier. 1745 5.3.4. Routing Information Base TLV 1747 The Routing Information Base lists the destinations (endpoints) a 1748 node knows of, and the routing metrics it has associated with them. 1749 This information is needed by the GORF framework and its routing 1750 algorithm modules to make decisions on routing and forwarding. 1752 0 1 2 3 1753 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 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 | TLV Type=0xA1 | TLV Flags | TLV Length (SDNV) | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 | Routing Metric Format (variable length) | 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | RIB String Count (SDNV) | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 | RIBD String ID 1 (SDNV) | Routing metric (var length) | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 | RIB Flags 1 | . ~ 1764 +-+-+-+-+-+-+-+-+ . ~ 1765 ~ . ~ 1766 ~ . ~ 1767 ~ . ~ 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | RIBD String ID n (SDNV) | P-Value | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | RIB Flags n | 1772 +-+-+-+-+-+-+-+-+ 1774 Figure 7: Routing Information Base TLV Format 1776 TLV Flags 1777 The encoding of the Header flag field relates to the 1778 capabilities of the Source node sending the RIB: 1780 Flag 0: More RIB TLVs 0b1 1781 Flag 1: Reserved 0b1 1782 Flag 2: Reserved 0b1 1783 Flag 3: Reserved 0b1 1784 Flag 4: Reserved 0b1 1785 Flag 5: Reserved 0b1 1786 Flag 6: Reserved 0b1 1787 Flag 7: Reserved 0b1 1789 The "More RIB TLVs" flag is set to 1 if the RIB requires more 1790 TLVs to be sent in order to be fully transferred. This flag is 1791 set to 0 if this is the final TLV of this RIB. 1793 TLV Data 1795 Routing Metric Format 1796 The Routing Metric Format field specifies the format used 1797 to describe the routing metrics in the rest of this TLV. 1798 The field is in the binary octet sequence representation of 1799 this format as described in Section 3.2.1.1. The GORF 1800 framework will call the getMetricFormat() function 1801 described in Section 3.3.1 to get this value. 1803 RIB String Count 1804 Number of routing entries in the TLV. Encoded as SDNV. 1806 RIBD String ID 1807 String ID of the endpoint identifier of the destination for 1808 which this entry specifies the routing metric as predefined 1809 in a dictionary TLV. Encoded as SDNV. 1811 Routing metric 1812 Variable length field containing the value of the routing 1813 metric for the destination of this entry in the format give 1814 in the Routing Metric Format field. The GORF framework 1815 will call the getRoutingState() function in the GORF API 1816 described in Section 3.3.5 to get the list of routing 1817 metrics used to populate this field. 1819 RIB Flag 1820 The encoding of the 8 bit RIB Flag field is: 1822 Flag 0: Reserved 0b1 1823 Flag 1: Reserved 0b1 1824 Flag 2: Reserved 0b1 1825 Flag 3: Reserved 0b1 1826 Flag 4: Reserved 0b1 1827 Flag 5: Reserved 0b1 1828 Flag 6: Reserved 0b1 1829 Flag 7: Reserved 0b1 1831 5.3.5. Bundle Offer and Response TLVs 1833 After the routing information has been passed, the node will ask the 1834 other node to review available bundles and determine which bundles it 1835 will accept for relay based on the routing algorihm module in use. 1836 The source relay will determine which bundles to offer based on the 1837 generateOffer() function in the GORF API. 1839 Depending on the bundles stored in the offering node, the Bundle 1840 Offer TLV might contain descriptions of both complete bundles and 1841 bundle fragments. In order to correctly identify bundle fragments, a 1842 bundle fragment descriptor MUST contain the offset of the payload 1843 fragment in the bundle payload and the length of the payload 1844 fragment. If requested by the receiving node by setting the L flag 1845 in the SYN or SYNACK message during the neighbor awareness phase, the 1846 offering node MUST include the length of the payload in the 1847 descriptor for complete bundles. The appropriate flags MUST be set 1848 in the B_flags for the descriptor to indicate if the descriptor 1849 contains the payload length field (set for fragments in all cases and 1850 for complete bundles if the L flag was set) and if the descriptor 1851 contains a payload offset field (fragments only). 1853 The Bundle Offer TLV also lists the bundles that a GORF 1854 acknowledgement has been issued for. Those bundles have the GORF ACK 1855 flag set in their entry in the list. When a node receives a GORF ACK 1856 for a bundle, it SHOULD, if possible, signal to the bundle agent that 1857 this bundle is no longer required for transmission by the GORF 1858 framework, and it MUST call the ackReceived() function in the GORF 1859 API. Even if the bundle is deleted, the node SHOULD keep an entry of 1860 the acknowledged bundle to be able to further propagate the GORF ACK. 1862 The Response TLV format is identical to the Offer TLV with the 1863 exception of the TLV Type field. Bundles that are being accepted 1864 from the corresponding Offer are explicitly marked with a B_flag. 1865 Specifications for bundles that are not being accepted MAY either be 1866 omitted or left in but not marked as accepted. The payload length 1867 field MAY be omitted for complete bundles in the Response message 1868 even if it was included in the Offer message. The B_flags payload 1869 length flag MUST be set correctly to indicate if the length field is 1870 included or not. The Response message MUST include both payload 1871 offset and payload length fields for bundle fragments, and the 1872 B_flags MUST be set to indicate that both are present. 1874 0 1 2 3 1875 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 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | TLV Type | TLV Flags | TLV Length (SDNV) | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | Bundle Offer Count (SDNV) | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 | B_flags | Bundle Source | Bundle Destination | 1882 | | String Id 1 (SDNV) | String Id 1 (SDNV) | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 | Bundle 1 Creation Timestamp Time | 1885 | (SDNV) | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 | Bundle 1 Creation Timestamp Sequence Number | 1888 | (SDNV) | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | Bundle 1 Payload Offset - only present if bundle is a fragment| 1891 | (SDNV) | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Bundle 1 Payload Length - only present if bundle is a fragment| 1894 | or transmission of length requested (SDNV) | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 ~ . ~ 1897 ~ . ~ 1898 ~ . ~ 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | B_flags | Bundle Source | Bundle Destination | 1901 | | String Id n (SDNV) | String Id n (SDNV) | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Bundle n Creation Timestamp Time | 1904 | (SDNV) | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Bundle n Creation Timestamp Sequence Number | 1907 | (SDNV) | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 | Bundle n Payload Offset - only present if bundle is a fragment| 1910 | (SDNV) | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Bundle n Payload Length - only present if bundle is a fragment| 1913 | or transmission of length requested (SDNV) | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 Figure 8: Bundle Offer and Response TLV Format 1918 TLV Type 1919 The TLV Type for a Bundle Offer is 0xA4. The TLV Type for a 1920 Bundle Response is 0xA5. 1922 TLV Flags 1923 The encoding of the Header flag field relates to the 1924 capabilities of the Source node sending the RIB: 1926 Flag 0: More Offer/Response 1927 TLVs Following 0b1 1928 Flag 1: Reserved 0b1 1929 Flag 2: Reserved 0b1 1930 Flag 3: Reserved 0b1 1931 Flag 4: Reserved 0b1 1932 Flag 5: Reserved 0b1 1933 Flag 6: Reserved 0b1 1934 Flag 7: Reserved 0b1 1936 If the Bundle Offers or Bundle Responses are divided between 1937 several TLVs, the More Offer/Response TLVs Following flag MUST 1938 be set to 1 in all but the last TLV in the sequence where it 1939 MUST be set to 0. 1941 TLV Data 1943 Bundle Offer Count 1944 Number of bundle offer/response entries. Encoded as an 1945 SDNV. Note that 0 is an acceptable value. In particular a 1946 Bundle Response TLV with 0 entries is used to signal that a 1947 cycle of information exchange and bundle passing is 1948 completed. 1950 B-Flags 1951 The encoding of the B_Flags is: 1953 Flag 0: Bundle Accepted 0b1 1954 Flag 1: Bundle is a Fragment 0b1 1955 Flag 2: Bundle Payload Length 1956 included in TLV 0b1 1957 Flag 3: Reserved 0b1 1958 Flag 4: Reserved 0b1 1959 Flag 5: Reserved 0b1 1960 Flag 6: Reserved 0b1 1961 Flag 7: GORF ACK 0b1 1963 Bundle Source String Id 1964 String ID of the source EID of the bundle as predefined in 1965 a dictionary TLV. Encoded as an SDNV. 1967 Bundle Destination String Id 1968 String ID of the destination EID of the bundle as 1969 predefined in a dictionary TLV. Encoded as an SDNV. 1971 Bundle Creation Timestamp Time 1972 Time component of the Bundle Creation Timestamp for the 1973 bundle. Encoded as an SDNV. 1975 Bundle Creation Timestamp Sequence Number 1976 Sequence Number component of the Bundle Creation Timestamp 1977 for the bundle. Encoded as an SDNV. 1979 Bundle Payload Offset 1980 Only included if the bundle is a fragment and the fragment 1981 bit is set (value 1) in the bundle B_flags. Offset of the 1982 start of the fragment payload in the complete bundle 1983 payload. Encoded as an SDNV. 1985 Bundle Payload Length 1986 Only included if the bundle length included bit is set 1987 (value 1) in the bundle B_flags. Length of the payload in 1988 the bundle specified. This is either the total payload 1989 length if the bundle is a complete bundle or the bundle 1990 fragment payload length if the bundle is a fragment. 1991 Encoded as an SDNV. 1993 6. Detailed Operation 1995 In this section, some more details on the operation of GORF are given 1996 along with state tables to help in implementing the framework. (*** 1997 The state tables need to be updated further so that all calls to the 1998 functions in the GORF API are included here. ***) 2000 As explained in Section 1.2. it is RECOMMENDED that "Success" 2001 responses should not be requested or sent when operating over a 2002 reliable, in order transport protocol such as TCP. If GORF is 2003 operated over an unreliable transport protocol, positive 2004 acknowledgements would be necessary to signal successful delivery of 2005 (sub)messages. In this section the phrase "send a message" should be 2006 read as *successful* sending of a message, signaled by receipt of the 2007 appropriate "Success" response if running over an unreliable 2008 protocol, but guaranteed by TCP or other reliable protocol otherwise. 2009 Hence the state descriptions below do not explicitly mention positive 2010 acknowledgements, whether they are being sent or not. 2012 6.1. High Level State Tables 2014 This section gives high level state tables for the operation of the 2015 GORF framework. The following sections will describe each part of 2016 the operation in more detail (including state tables for the internal 2017 states of those procedures). 2019 The following main or high level states are used in the state tables: 2021 WAIT_NB This is the state all nodes start in. Nodes remain in this 2022 state until they are notified that a new neighbor is available. 2023 At that point, the hello procedure should be started with the 2024 new neighbor, and the node transitions into the HELLO state. 2025 Nodes SHOULD be able to handle multiple neighbors in parallel, 2026 maintaining separate state machines for each neighbor. This 2027 could be handled by creating a new thread or process during the 2028 transition to the HELLO state that then takes care of the 2029 communication with the new neighbor while the parent remains in 2030 state WAIT_NB waiting for additional neighbors to communicate. 2031 In this case when the neighbor can no longer be communicated 2032 with (described as 'neighbor gone' in the tables below), the 2033 thread or process created is destroyed and, when a connection 2034 oriented protocol is being used to communicate with the 2035 neighbor, the connection is closed. The current version of the 2036 protocol is specified to use TCP for neighbor connections so 2037 that these will be closed when the neighbor is no longer 2038 accessible. 2040 HELLO Nodes are in the HELLO state from when a new neighbor is 2041 detected until the Hello procedure is completed and a link is 2042 established (which happens when the Hello procedure enters the 2043 ESTAB state as described in Section 6.2 - during this 2044 procedure, the states ESTAB, SYNSENT, and SYNRCVD will be used, 2045 but these are internal to the Hello procedure and are not 2046 listed here). If the node is notified that the neighbor is no 2047 longer in range before a link has been established, it returns 2048 to the WAIT_NB state and, if appropriate, any additional 2049 process or thread created to handle the neighbor MAY be 2050 destroyed. 2052 INFO_EXCH After a link has been set up by the Hello procedure, the 2053 node transitions to the INFO_EXCH state in which the 2054 information exchange and bundle passing are done. The node 2055 remains in this state as long as Information Exchange Phase 2056 TLVs (Routing RIB, Routing RIB Dictionary) and bundle passing 2057 TLVs (Bundle Offer, Bundle Response) are being received. If 2058 the node is notified that the neighbor is no longer in range 2059 before all information and bundles have been exchanged, any 2060 associated connection is closed and the node returns to the 2061 WAIT_NB state to await new neighbors. 2063 In the INFO_EXCH state the nodes at both ends of the 2064 established link are able to update their internal routing 2065 state as routing information from the peering node is sent to 2066 the updateRoutingState() function of the GORF API. The nodes 2067 can then make offers of bundles for exchange (using the 2068 generateOffer() function) which may be accepted or not by the 2069 peer. To manage these processes, each node acts both as an 2070 Initiator and a Listener for the information exchange and 2071 bundle passing processes, maintaining subsidiary state machines 2072 for the two roles. The Initiator and Listener terms refer to 2073 the sending of the Routing RIB information: it is perhaps 2074 counterintuitive that the Listener becomes the bundle offeror 2075 and the Initiator the bundle acceptor during the bundling 2076 passing part. 2078 The protocol is designed so that the two exchanges MAY be 2079 carried out independently but concurrently with the messages 2080 multiplexed onto on a single bidirectional link (such as is 2081 provided by the TCP connection). Alternatively, the exchanges 2082 MAY be carried out partially or wholly sequentially if 2083 appropriate for the implementation. The information exchange 2084 process is explained in more detail in Section 4.2 2085 When an empty Bundle Response TLV (i.e., no more bundles to 2086 send) is received, the node starts the next_exchange timer 2087 based on the getInformationExchangeTimer() function in the GORF 2088 API. If this function returns 0, the timer is not started. 2089 When this timer expires, assuming that the neighbor is still 2090 connected, the Initiator reruns the information exchange 2091 process. If there is only one neighbor connected at this time, 2092 this may change the internal routing state of the routing 2093 module (depending on the routing algorithm). If there is more 2094 than one neighbor connected or other communication 2095 opportunities have happened since the previous information 2096 exchange occurred, then the changes resulting from these other 2097 encounters will be passed on to the connected neighbor. The 2098 next_exchange timer is restarted once the information exchange 2099 has completed again. 2101 If one or more new bundles are receieved by this node (either 2102 from a peering node or from an application running on this 2103 node) while waiting for the next_exchange timer to expire, the 2104 GORF framework will call the newBundleArrived() function in the 2105 GORF API. The routing algorithm module will use its internal 2106 state and the bundle id of the new bundle to determine if it 2107 would be appropriate to forward the new bundle to a connected 2108 node. If so, the new bundle(s) SHOULD be immediately offered 2109 to the connected neighbor and transferred if accepted. 2111 State: WAIT_NB 2113 +==================================================================+ 2114 | Condition | Action | New State | 2115 +==================+===================================+===========+ 2116 | New Neighbor | Start Hello procedure for neighbor| HELLO | 2117 | | Call encounteredNode() in GORF API| | 2118 | | Keep waiting for more neighbors | WAIT_NB | 2119 +==================================================================+ 2120 State: HELLO 2122 +==================================================================+ 2123 | Condition | Action | New State | 2124 +==================+===================================+===========+ 2125 | Hello TLV rcvd | | HELLO | 2126 +------------------+-----------------------------------+-----------+ 2127 | Enter ESTAB state| Start Information Exchange Phase | INFO_EXCH | 2128 +------------------+-----------------------------------+-----------+ 2129 | Neighbor Gone | | WAIT_NB | 2130 +==================================================================+ 2132 State: INFO_EXCH 2134 +==================================================================+ 2135 | Condition | Action | New State | 2136 +==================+===================================+===========+ 2137 | On entry | Start keep alive timer | | 2138 | | Uses Hello Timer interval | INFO_EXCH | 2139 +------------------+-----------------------------------+-----------+ 2140 |Info Exch TLV rcvd| (processed by subsidiary state | | 2141 | | machines) | INFO_EXCH | 2142 +------------------+-----------------------------------+-----------+ 2143 | No more bundles | Start next_exchange timer | INFO_EXCH | 2144 +------------------+-----------------------------------+-----------+ 2145 | Keep Alive expiry| Send Hello SYN message | INFO_EXCH | 2146 +------------------+-----------------------------------+-----------+ 2147 | Hello SYN rcvd | Record reception, restart timer | INFO_EXCH | 2148 +------------------+-----------------------------------+-----------+ 2149 | Neighbor Gone | | WAIT_NB | 2150 +==================================================================+ 2152 The Keep Alive messages (messages with Hello SYN TLV) are processed 2153 by the high level state machine in the INFO_EXCH state. All other 2154 messages are delegated to the subsidiary state machines of the 2155 information exchange phase described in Section 6.3. The receipt of 2156 Keep Alive messages is recorded and may be used by the subsidiary 2157 machines to check if the peer is still functioning. The connection 2158 will be aborted as described in Section 5.3.1 if several Keep Alive 2159 messages are not received. 2161 6.2. Hello Procedure 2163 The hello procedure is described by the following rules and state 2164 tables. In this section the messages sent consist of the GORF header 2165 (see Figure 1 and a single Hello TLV (see Section 5.3.1) with the HF 2166 (Hello Function) field set to the specified value (SYN, SYNACK, ACK 2167 or RSTACK). 2169 The state of the L flag in the latest SYN or SYNACK message is 2170 recorded in the node that receives the message If the L flag is set 2171 (1) the receiving node MUST send the payload length for exch bundle 2172 that it offers to the peer during the information exchange phase. 2174 The rules and state tables use the following operations: 2176 o The "Update Peer Verifier" operation is defined as storing the 2177 values of the Sender Instance and Sender Local Address fields from 2178 a Hello SYN or Hello SYNACK function message received from the 2179 entity at the far end of the link. 2181 o The procedure "Reset the link" is defined as: 2183 When using TCP or other reliable connection-oriented transport: 2184 Close the connection and terminate any separate thread or 2185 process managing the connection. 2187 Otherwise: 2189 1. Generate a new instance number for the link. 2191 2. Delete the peer verifier (set to zero the values of 2192 Sender Instance and Sender Local Address previously 2193 stored by the Update Peer Verifier operation). 2195 3. Send a SYN message. 2197 4. Transition to the SYNSENT state. 2199 o The state tables use the following Boolean terms and operators: 2201 A The Sender Instance in the incoming message matches the value 2202 stored from a previous message by the "Update Peer Verifier" 2203 operation. 2205 B The Sender Instance and Sender Local Address fields in the 2206 incoming message match the values stored from a previous 2207 message by the "Update Peer Verifier" operation. 2209 C The Receiver Instance and Receiver Local Address fields in 2210 the incoming message match the values of the Sender Instance 2211 and Sender Local Address used in outgoing Hello SYN, Hello 2212 SYNACK, and Hello ACK messages. 2214 SYN A Hello SYN message has been received. 2216 SYNACK 2217 A Hello SYNACK message has been received. 2219 ACK A Hello ACK message has been received. 2221 "&&" Represents the logical AND operation 2223 "||" Represents the logical OR operation 2225 "!" Represents the logical negation (NOT) operation. 2227 o A timer is required for the periodic generation of Hello SYN, 2228 Hello SYNACK, and Hello ACK messages. The value of the timer is 2229 announced in the Timer field. To avoid synchronization effects, 2230 uniformly distributed random jitter of +/-5% of the Timer field 2231 SHOULD be added to the actual interval used for the timer. 2233 There are two independent events: the timer expires, and a packet 2234 arrives. The processing rules for these events are: 2236 Timer Expires: Reset Timer 2237 If state = SYNSENT Send SYN message 2238 If state = SYNRCVD Send SYNACK message 2239 If state = ESTAB Send ACK message 2241 Packet Arrives: 2242 If incoming message is an RSTACK message: 2243 If (A && C && !SYNSENT) Reset the link 2244 Else discard the message. 2245 If incoming message is a SYN, SYNACK, or ACK message: 2246 Response defined by the following State Tables. 2247 If incoming message is any other GORF TLV and 2248 state != ESTAB: 2249 Discard incoming message. 2250 If state = SYNSENT Send SYN message(Note 1) 2251 If state = SYNRCVD Send SYNACK message(Note 1) 2253 Note 1: No more than two SYN or SYNACK messages should be 2254 sent within any time period of length defined by the timer. 2256 o A connection across a link is considered to be achieved when the 2257 protocol reaches the ESTAB state. All TLVs, other than Hello 2258 TLVs, that are received before synchronization is achieved, will 2259 be discarded. 2261 6.2.1. Hello Procedure State Tables 2263 State: SYNSENT 2265 +==================================================================+ 2266 | Condition | Action | New State | 2267 +==================+===================================+===========+ 2268 | SYNACK && C | Update Peer Verifier; | ESTAB | 2269 | | Send ACK message | | 2270 +------------------+-----------------------------------+-----------+ 2271 | SYNACK && !C | Send RSTACK message | SYNSENT | 2272 +------------------+-----------------------------------+-----------+ 2273 | SYN | Update Peer Verifier; | SYNRCVD | 2274 | | Send SYNACK message | | 2275 +------------------+-----------------------------------+-----------+ 2276 | ACK | Send RSTACK message | SYNSENT | 2277 +==================================================================+ 2279 State: SYNRCVD 2281 +==================================================================+ 2282 | Condition | Action | New State | 2283 +==================+===================================+===========+ 2284 | SYNACK && C | Update Peer Verifier; | ESTAB | 2285 | | Send ACK message | | 2286 +------------------+-----------------------------------+-----------+ 2287 | SYNACK && !C | Send RSTACK message | SYNRCVD | 2288 +------------------+-----------------------------------+-----------+ 2289 | SYN | Update Peer Verifier; | SYNRCVD | 2290 | | Send SYNACK message | | 2291 +------------------+-----------------------------------+-----------+ 2292 | ACK && B && C | Send ACK message | ESTAB | 2293 +------------------+-----------------------------------+-----------+ 2294 | ACK && !(B && C) | Send RSTACK message | SYNRCVD | 2295 +==================================================================+ 2296 State: ESTAB 2298 +==================================================================+ 2299 | Condition | Action | New State | 2300 +=================+====================================+===========+ 2301 | SYN || SYNACK | Send ACK message (notes 2, and 3) | ESTAB | 2302 +-----------------+------------------------------------+-----------+ 2303 | ACK && B && C | Send ACK message (note 3) | ESTAB | 2304 +-----------------+------------------------------------+-----------+ 2305 | ACK && !(B && C)| Send RSTACK message | ESTAB | 2306 +==================================================================+ 2308 Note 2: No more than two ACK messages should be sent within any 2309 time period of length defined by the timer. Thus, one ACK message 2310 MUST be sent every time the timer expires. In addition, one 2311 further ACK message may be sent between timer expirations if the 2312 incoming message is a SYN or SYNACK. This additional ACK allows 2313 the Hello functions to reach synchronization more quickly. 2315 Note 3: No more than one ACK message should be sent within any 2316 time period of length defined by the timer. 2318 6.3. Information Exchange and Bundle Passing Phase 2320 After the Hello messages have been exchanged, and the nodes are in 2321 the ESTAB state, the information exchange and bundle passing phase is 2322 initiated. This section describes the procedure and shows the state 2323 transitions necessary in this phase, and the following sections 2324 describe the various TLVs passed in this phase in detail. On 2325 reaching the ESTAB state in the high level HELLO state there is an 2326 automatic transition to the INFO_EXCH high level state. 2328 The GORF framework runs over a bidirectional transport as documented 2329 in Section 1.2 so that when a pair of nodes (A and B) have reached 2330 the ESTAB state they are able to perform the information exchange and 2331 bundle passing processes for both the A to B and B to A directions 2332 over the link that has just been established. In principle, these 2333 two processes are independent of each other and can be performed 2334 concurrently. However complete concurrency may not be the most 2335 efficient way to implement the complete process. As explained in 2336 Section 4.2.1, the Routing Information Base Dictionary is a shared 2337 resource assembled from a combination of information generated 2338 locally on each node and information passed from the peer node. 2339 Overlaps in this information and, hence the amount of information 2340 that has to be passed between the nodes, can be minimized by 2341 sequential rather than concurrent operation of the dictionary 2342 generation and update processes. It may also be possible to reduce 2343 the number of bundles that need to be offered by the second offeror 2344 by examining the offers received from the first offeror - there is no 2345 need for the second offeror to offer a bundle that is already present 2346 in the first offeror's offer list, as it will inevitably be refused. 2348 All implementations MUST be capable of operating in a fully 2349 concurrent manner. Each implementation needs to define a policy, 2350 which SHOULD be configurable, as to whether it will operate in a 2351 concurrent or sequential manner during the information exchange and 2352 bundle passing phase. If it is to operate sequentially, then further 2353 choices can be made as to whether to interleave dictionary, offer and 2354 response exchange parts or complete all parts in one direction before 2355 initiating the other direction. 2357 One possible interleaving strategy is to alternate between sending 2358 from the two nodes. For example, if the Hello SYN node sends its 2359 initial dictionary entries while the Hello SYNACK node waits until 2360 this is complete, the Hello SYNACK node can then prune its proposed 2361 dictionary entries before sending to avoid duplication. This 2362 approach can be repeated for the second tranche of dictionary entries 2363 needed for the Bundle Offers and Responses, and also for the Bundle 2364 Offers, where any bundles that are offered by the Hello SYN node that 2365 are already present in the Hello SYNACK node need not be offered to 2366 the Hello SYN node. This approach is well suited to a transport 2367 protocol and physical medium that is effectively half-duplex. 2369 The decision to operate concurrently or sequentially is purely a 2370 matter of local policy in each node at present. If nodes have 2371 inconsistent policies, the behavior at each encounter will depend on 2372 which node takes the SYN role which is a matter of chance depending 2373 on random timing of the start of communications during the encounter. 2375 To manage the information transfer, two subsidiary state machines are 2376 created in each node to control the stages of the information 2377 exchange and bundle passing process within the INFO_EXCH high level 2378 state as shown in Figure 9. Each subsidiary state machine consists 2379 of two essentially independent components known as the "Initiator 2380 role" and the "Listener role". One of these components is 2381 instantiated in each node. The Initiator role starts the information 2382 exchange process in each node and the Listener role responds to the 2383 initial messages, but it is not a passive listener as it also 2384 originates messages. The transition from the ESTAB state is a 2385 "forking" transition in that it starts both subsidiary state 2386 machines. The two subsidiary state machines operate in parallel for 2387 as long as the neighbor remains in range and connected. 2389 + - - - - - - - - + + - - - - - - - - + 2391 | SYN node | GORF messages with : | SYNACK node | 2393 | +-------------+ | A. Routing Metrics | +-------------+ | 2394 | Subsidiary |--->---->---->---->---->---->---->| Subsidiary | 2395 | | State | | C. Bundle Responses | | State | | 2396 | Machine 1: | | Machine 1: | 2397 | | Initiator | | B. Bundle Offers | | Listener | | 2398 | Role |<----<----<----<----<----<----<---| Role | 2399 | +-------------+ | D. Requested Bundles | +-------------+ | 2401 | +-------------+ | A. Routing Metrics | +-------------+ | 2402 | Subsidiary |<----<----<----<----<----<----<---| Subsidiary | 2403 | | State | | C. Bundle Responses | | State | | 2404 | Machine 2: | | Machine 2: | 2405 | | Listener | | B. Bundle Offers | | Initiator | | 2406 | Role |--->---->---->---->---->---->---->| Role | 2407 | +-------------+ | D. Requested Bundles | +-------------+ | 2409 + - - - - - - - - + + - - - - - - - - + 2411 The letters (A - D) indicate the sequencing of messages. 2413 Figure 9: Information Exchange Subsidiary State Machines 2415 These subsidiary state machines can be thought of as mirror images: 2416 for each state machine one node takes on the Initiator role while the 2417 other node takes on the Listener role. TLVs sent by a node from the 2418 Initiator role will be processed by the peer node in the Listener 2419 role and vice versa. As indicated in Figure 9 the Initiator role 2420 handles sending that node's current set of routing metrics for known 2421 destinations to the Listener role node. The Listener role node uses 2422 the supplied values to update its internal routing state according to 2423 the updateRoutingState() function defined in Section 3.3.6. It then 2424 decides which bundles that it has in store should be offered for 2425 transfer to the Initiator role node as a result of comparing the 2426 local routing state and those supplied by the Initiator node. When 2427 these offers are delivered to the Initiator role node, it decides 2428 which ones to accept and supplies the Listener node role with a 2429 prioritized list of bundles that it wishes to accept. The Listener 2430 role node then sends the requested bundles. 2432 These exchanges are repeated periodically for as long as the nodes 2433 remain in contact. Additionally, if new bundles arrive from other 2434 sources they may be offered, accepted and sent in between these 2435 exchanges. 2437 The GORF routing framework is designed so that in most cases the TLV 2438 type determines the role in which it will be processed on reception. 2439 The only exception to this is that both roles may send RIB Dictionary 2440 TLVs: the Initiator role sends dictionary entries for use in the 2441 subsequent RIB TLV(s) and the Listener role may send additional 2442 dictionary entries for use in subsequent Bundle Offer TLVs. The two 2443 cases are distinguished by a TLV flag to ensure that they are 2444 processed in the right role context on reception. If this flag was 2445 not provided there are states where both roles could accept the RIB 2446 Dictionary TLV making it impossible to ensure that the correct role 2447 state machine took action. Note that the correct updates would be 2448 made to the dictionary whichever role processed the TLV and that the 2449 ambiguity would not arise if the roles are adopted completely 2450 sequentially, i.e., if the information exchange and associated bundle 2451 passing run to completion in one direction before the process for the 2452 reverse direction is started. 2454 If sequential operation is selected, the node which sent the Hello 2455 SYN function message MUST be the node which sends the first message 2456 in the information exchange process. This ensures that there is a 2457 well-defined order of events with the Initiator role in the Hello SYN 2458 node (i.e., the node identified by String ID 0) starting first. The 2459 Hello SYNACK node MAY then postpone sending its first message until 2460 the Listener role state machine in the Hello SYNACK node has reached 2461 any of a number of points in its state progression according to 2462 locally configured policy and the nature of the physical link for the 2463 current encounter between the nodes as described above. If 2464 concurrent operation is selected, the Hello SYNACK node can start 2465 sending messages immediately without waiting to receive messages from 2466 the peer. 2468 6.3.1. Initiator Role State Definitions 2470 The state machine component with the Initiator role in each node 2471 starts the transfer of information from one node to its peer during 2472 the information exchange process. The process from the Initiator's 2473 point of view does the following: 2475 o The Initiator role determines the set of routing metrics to be 2476 sent to the peer node (returned by the getRoutingState() function 2477 in the GORF API as called during the Hello process), sends RIB 2478 dictionary entries necessary to interpret the set of RIB routing 2479 metric values that are sent after the dictionary updates. On 2480 second and subsequent executions of this state machine during a 2481 single session with the same peer there may be no RIB dictionary 2482 entries to send. Either an empty TLV can be sent or the TLV can 2483 be omitted. 2485 o The Initiator then waits to receive any RIB dictionary updates 2486 followed by bundle offers from the Listener role on the peer node. 2488 o The Initiator calls the generateResponse() function in the GORF 2489 API to determine which of the bundle offers should be accepted and 2490 in what order they should be requested. The possibly reordered 2491 list of accepted bundles is sent to the peer node using one or 2492 more bundle responses. 2494 o The peer then sends the accepted bundles to the Initiator in turn. 2496 o Assuming that the link remains open during the bundle sending 2497 process, the Initiator signals that the bundle passing phase is 2498 complete by sending a message with an empty Bundle Response TLV 2499 (i.e, with the Bundle Offer Count set to 0 and no bundle offers 2500 following the TLV header). 2502 o When the bundle transfer is complete, the Initiator starts the 2503 next_exchange timer, set to the value returned by the 2504 getInformationExchangeTimer() function. Assuming that the 2505 connection to the neighbor remains open, when the timer expires 2506 the Initiator restarts the information exchange process. During 2507 this period, Hello SYN messages are exchanged as keep alives to 2508 check that the neighbor is still present. The keep alive 2509 mechanism is common to the Initiator and Listener machines and is 2510 handled in the high level state machine (see Section 6.1. 2512 A timer is provided which restarts the Initiator role state machine 2513 if Bundle Offers are not received after sending the RIB. If this 2514 node receives a Hello ACK message containing an Error TLV indicating 2515 there has been a protocol problem then the connection MUST be 2516 terminated. 2518 The following states are used: 2520 CREATE_DR 2521 The initial transition to this state from the ESTAB state is 2522 immediate and automatic for the node that sent the Hello SYN 2523 message. For the peer (Hello SYNACK sender) node it may be 2524 immediate for nodes implementing a fully concurrent process or may 2525 be postponed until the corresponding Listener has reached a 2526 specified state if a sequential process is configured in the node 2527 policy. 2529 The local dictionary is initialized when this state is entered for 2530 the first time from the ESTAB state. The initial state of the 2531 dictionary contains two entries: the EID of the node that sent the 2532 Hello SYN (String ID 0) and the EID of the node that sent the 2533 Hello SYNACK (String ID 1). If the peer reports via a Hello ACK 2534 message containing an Error TLV reporting a Dictionary Conflict or 2535 Bad String ID error then the connection MUST be terminated. 2537 The CREATE_DR state will be entered in the same way from the 2538 REQUEST state when the Timer(next_exchange) expires, signaling the 2539 start of a new round of information exchange and bundle passing. 2541 When in this state: 2543 * Call the getRoutingState() function in the GORF API to etermine 2544 the destination EIDs for which routing metrics will be sent to 2545 the peer in a RIB TLV, if any. Record the prior state of the 2546 local dictionary (assuming that String IDs are numbers 2547 allocated sequentially, the state information needed is just 2548 the highest ID used before this process started) so that the 2549 process can be restarted if necessary. Update the local 2550 dictionary if any new EIDS are required, format one or more RIB 2551 Dictionary TLVs and one or more RIB TLVs and send them to the 2552 peer. If there are no dictionary entries to send, TLVs with 2553 zero entries MAY be sent, or the TLV can be omitted, but an 2554 empty RIB TLV MUST be sent if there is no data to send. The 2555 RIB Dictionary TLVs generated here MUST have the 2556 Sent by Listener flag set to 0 to indicate that they were sent 2557 by the Initiator. 2559 * If an Error TLV indicating a Dictionary Conflict or 2560 Bad String ID is received during or after sending the RIB 2561 Dictionary TLVs and/or the RIB TLVs, abort any in progress 2562 Initiator or Listener process, and terminate the connection to 2563 the peer. 2565 * Start a timer (known as Timer(info)) and transition to the 2566 SEND_DR state. 2568 Note that when (and only when) running over a transport protocol 2569 such as TCP, both the RIB Dictionary and RIB information MAY be 2570 spread across multiple TLVs and messages if required by known 2571 constraints of the transport protocol or to reduce the size of 2572 memory buffers. Alternatively the information can be formatted 2573 into single RIB Dictionary and RIB TLVs and the submessage 2574 capability of GORF or the inherent capabilities of the transport 2575 protocol used to segment the message if required. This discussion 2576 of segmentation applies to the other states and the Bundle Offer 2577 and Bundle Response messages and will not be repeated. 2579 If more than one RIB TLV is to be used, all but the last one have 2580 the "More RIB TLVs" flag set to 1 in the TLV flags. It is not 2581 necessary to distinguish the last RIB Dictionary TLV because the 2582 actions taken at the receiver are essentially passive (recording 2583 the contents) and the sequence is ended by the sending of the 2584 first RIB TLV. 2586 SEND_DR 2587 In this state the Initiator node expects to be receiving Bundle 2588 Offers and sending Bundle Responses: 2590 * Clear the set of bundles offered by the peer on entry to the 2591 state. 2593 * If the Timer(info) expires, resend the RIB Dictionary and RIB 2594 information sent in the previous CREATE_DR state using the 2595 stored state to recreate the information. The RIB dictionary 2596 update process in the peer is idempotent provided that the 2597 mappings between the EID and the String ID in the resent RIB 2598 Dictionary TLVs are the same as in the original. This means 2599 that it does not matter if some of the RIB Dictionary TLVs had 2600 already been processed in the peer. Similarly resending RIB 2601 TLVs will not cause a problem. 2603 * If a message with a RIB Dictionary TLV marked as sent by a 2604 Listener is received, update the local dictionary based on the 2605 received TLV. If any of the entries in the RIB Dictionary TLV 2606 conflict with existing entries (i.e., an entry is received that 2607 uses the same String ID as some previously received entry but 2608 the EID in the entry is different), send a Response message 2609 with an Error TLV containing a Dictionary Conflict indicator, 2610 abort any in progress Initiator or Listener process, and 2611 terminate the connection to the peer. Note that in some 2612 circumstances no dictionary updates are needed and the first 2613 message received in this state will carry a Bundle Offer TLV. 2615 * If a message with a Bundle Offer TLV is received, restart the 2616 Timer(info) if the More Offer/Response TLVs Following flag is 2617 set in the TLV or otherwise stop the Timer(info). Then process 2618 any GORF ACKS in the TLV by informing the Bundle Agent, calling 2619 the ackReceived() function in the GORF API, and add the bundles 2620 offered in the TLV to the set of bundles offered. If the 2621 More Offer/Response TLVs Following flag is set in the TLV wait 2622 for further Bundle Offer TLVs. If a Bundle Offer TLV is 2623 received with a String ID that is not in the dictionary send a 2624 message with an Error TLV containing a Bad String ID indicator, 2625 abort any in progress Initiator or Listener process, and 2626 terminate the connection to the peer. 2628 * If the More Offer/Response TLVs Following flag is clear in the 2629 last Bundle Offer TLV received, pass the list of bundle ids 2630 offered to the generateResponse() function in the GORF API to 2631 determine the set of bundles that are to be accepted. Record 2632 the set of bundles accepted so that reception can be checked in 2633 the bundle passing phase. Format one or more Bundle Response 2634 TLVs flagging the accepted offers and send them to the peer. 2635 If more than one Bundle Response TLV is sent, all but the last 2636 one should have the More Offer/Response TLVs Following TLV flag 2637 set to 1. At least one Bundle Response TLV MUST be sent even 2638 if the node does not wish to accept any of the offers. In this 2639 case the Bundle Response TLV contains an emoty set of 2640 acceptances. 2642 * If an Error TLV indicating a Bad String ID is received during 2643 or after sending the Bundle Response TLVs, abort any in 2644 progress Initiator or Listener process, reinitialize the local 2645 dictionary and terminate the connection to the peer. 2647 * Restart the Timer(info) timer in case the peer does not start 2648 sending the requested bundles. 2650 * Transition to state REQUEST. 2652 REQUEST 2653 In this state the Initiator node expects to be receiving the 2654 bundles accepted in the Bundle Response TLV(s): 2656 * Keep track of the bundles received and delete them from the set 2657 of bundles accepted. 2659 * If the Timer(info) expires while waiting for bundles, format 2660 and send one or more Bundle Response TLVs listing the bundles 2661 previously accepted but not yet received. If more than one 2662 Bundle Response TLV is sent, all but the last one should have 2663 the More Offer/Response TLVs Following TLV flag set to 1. 2665 * If an Error TLV indicating a Bad String ID is received during 2666 or after sending the Bundle Response TLVs, abort any in 2667 progress Initiator or Listener process, reinitialize the local 2668 dictionary and terminate the connection to the peer. 2670 * Restart the Timer(info) timer after each bundle is received in 2671 case the peer does not continue sending the requested bundles. 2673 * When all the requested bundles have been received, format a 2674 Bundle Response TLV with the Bundle Offer Count set to zero and 2675 with the More Offer/Response TLVs Following flag cleared to 0 2676 to signal completion to the peer node. Also signal the 2677 Listener in this node that the Initiator has completed. If the 2678 peer node is using a sequential policy, the Listener may still 2679 be in the initial state in which case it needs to start a timer 2680 to ensure that it detects if the peer fails to start the 2681 Initiator state machine. Thereafter coordinate with the 2682 Listener state machine in the same node: when the Listener has 2683 received the completion notification from the peer node and 2684 this Initiator has sent its completion notification, start a 2685 Timer(next_exchange). 2687 * If the Timer(next_exchange) expires, transition to state 2688 CREATE_DR to restart the information exchange process. 2690 Note that if Timer(info) timeout occurs a number of times 2691 (configurable, typically 3) without any bundles being received 2692 then this SHOULD generally be interpreted as a problem that 2693 indicates that the link to the peer is no longer functional and 2694 the session should be terminated. However, some bundles may be 2695 very large and take a long time to transmit. Before terminating 2696 the session this state machine needs to check if a large bundle is 2697 actually being received although no new completed bundles have 2698 been received since the last expiry of the timer. In this case 2699 the timer should be restarted without sending the Bundle Response 2700 TLV. Also if the bundles are being exchanged over a transport 2701 protocol that can detect link failure, then the session MUST be 2702 terminated if the bundle exchange link is shut down because it has 2703 failed. 2705 6.3.2. Listener Role State Definitions 2707 The state machine component with the Listener role in each node 2708 initially waits to receive a RIB Dictionary update followed by a set 2709 of RIB routing metrics during the information exchange process. The 2710 process from the point of view of the Listener does the following: 2712 o Receive RIB Dictionary updates and RIB values from the peer. Note 2713 that in some circumstances no dictionary updates are needed and 2714 RIBD dictionary TLV will contain no entries or may be omitted 2715 completely. 2717 o When all RIB messages have been received, the updateRoutingState() 2718 function in the GORF API is run using the values received from the 2719 Initiator node. 2721 o Using the updated internal routing state and the policies of the 2722 current routing algorithms are applied by calling the 2723 generateOffer() function in the GORF API to determine the set of 2724 bundles to be offered to the Initiator and order the list 2725 according to the forwarding priority. The Bundle Offer TLVs are 2726 also used to notify the peer of any GORF Acks that have been 2727 received by this node. 2729 o Send the list of bundles in one or more bundle offers, preceded if 2730 necessary by one or more RIB dictionary updates to add any EIDs 2731 required for the source or destination EIDs of the offered 2732 bundles. These updates MUST be marked as being sent by the 2733 Listener role so that they will be processed by the Initiator role 2734 in the peer. 2736 o Wait for the Initiator to send a bundle responses indicating which 2737 bundles should be sent and possibly a modified order for the 2738 sending. Send the bundles accepted in the specified order. The 2739 bundle sending will normally be carried out over a separate 2740 connection using a suitable DTN convergence layer. 2742 o On completion of the sending, wait for a message with an empty 2743 Bundle Response TLV indicating correct completion of the process. 2745 o The Listener process will be notified if any new bundles or GORF 2746 ACKs are received by the node after the completion of the bundle 2747 sending resulting from this information exchange and the 2748 newBundleArrived() or ackReceived() functions in the GORF API will 2749 be called to inform the routing algorithm module and allow it to 2750 determine if this information should be sent to the peer. If it 2751 is determined that one or more bundles and/or ACKs ought to be 2752 forwarded, a new set of bundle offers are sent to the peer. If 2753 the peer accepts them by sending bundle responses, the bundles 2754 and/or ACKS are transferred as previously 2756 o Periodically, the Initiator in the peer will restart the complete 2757 information exchange by sending a RIB TLV that may be, optionally, 2758 preceded by RIB Dictionary entries if they are required for the 2759 updated RIB. 2761 Timers are used to ensure that the Listener does not lock up if 2762 messages are not received from the Initiator in a timely fashion. 2763 The Listener is restarted if the RIB is not received and a Hello Ack 2764 message is sent to force the Initiator to restart. If Bundle 2765 Response messages are not received in a timely fashion, the Listener 2766 resends the Bundle Offers and associated dictionary updates. The 2767 following states are used: 2769 WAIT_DICT 2770 The Listener subsidiary state machine transitions to this state 2771 automatically and immediately from the state ESTAB in both peers. 2772 This state will be entered in the same way if the 2773 Timer(next_exchange) expires in the peer, signaling the start of a 2774 new round of information exchange and bundle passing. This will 2775 result in one or more RIB TLVs being sent to the Listener by the 2776 peer node's Initiator. 2778 * When a RIB Dictionary TLV is received, use the TLV to update 2779 the local dictionary, start or, if it is running, restart the 2780 Timer(peer) and transition to state WAIT_RIB. If any of the 2781 entries in the RIB Dictionary TLV conflict with existing 2782 entries (i.e., an entry is received that uses the same String 2783 ID as some previously received entry but the EID in the entry 2784 is different), send a Rersponse message with an Error TLV 2785 containing a Dictionary Conflict indicator, abort any in 2786 progress Initiator or Listener process, and terminate the 2787 connection to the peer. 2789 * If a Hello ACK message is received from the peer node, 2790 transition to state WAIT_DICT and restart the process. 2792 If multiple timeouts occur (configurable, typically 3), assume 2793 that the link is broken and terminate the session. Note that the 2794 RIB Dictionary and RIB TLVs may be combined into a single message. 2795 The RIB TLV should be passed on to be processed in the WAIT_RIB 2796 state. 2798 WAIT_RIB 2799 In this state the Listener expects to be receiving one or more RIB 2800 TLVs and possibly additional RIB Dictionary TLVs. 2802 * On entry to this state clear the set of received routing 2803 metrics. 2805 * Whenever a new message is received, restart the Timer(peer) 2806 timer. 2808 * If a RIB dictionary TLV is received, use it to update the local 2809 dictionary and remain in this state. If any of the entries in 2810 the RIB Dictionary TLV conflict with existing entries (i.e., an 2811 entry is received that uses the same String ID as some 2812 previously received entry but the EID in the entry is 2813 different), send a message with an Error TLV containing a 2814 Dictionary Conflict indicator, abort any in progress Initiator 2815 or Listener process, and terminate the connection to the peer. 2817 * If a RIB TLV is received, record the received routing metric 2818 value for use in recalculating the local routing metric. If a 2819 routing metric value is received for an EID that is already in 2820 the set of received routing metrics, overwrite the previously 2821 received value with the latest value. If a routing metric 2822 value is received with a String ID that is not in the 2823 dictionary send a message with an Error TLV containing a 2824 Bad String ID indicator, abort any in progress Initiator or 2825 Listener process, and terminate the connection to the peer. 2827 * When a RIB TLV is received with the More RIB TLVs flag cleared, 2828 initiate the recalculation of the internal routing state by 2829 calling the updateRoutingState() function in the GORF API and 2830 stop the Timer(peer). Use the update routing state to create a 2831 list of bundles to be offered to the peer node by calling the 2832 generateOffer() function. 2834 * Record the state of the local dictionary in case the offer 2835 procedure has to be restarted. Determine if any new dictionary 2836 entries are required for use in the Bundle Offer TLV(s). If so 2837 record them in the local dictionary, then format and send RIB 2838 Dictionary entries in zero or more RIB Dictionary TLV messages 2839 to update the dictionary in the peer if necessary. 2841 * Format and send Bundle Offer TLV(s) carrying the identifiers of 2842 the bundles to be offered together with any GORF ACKs received 2843 or generated by this node. If more than one Bundle Offer TLV 2844 is sent, all but the last Bundle Offer TLV sent MUST have the 2845 More Offer/Response TLVs Following flag set to 1. 2847 * When all Bundle Offer TLVs have been sent start the Timer(info) 2848 and transition to state OFFER. 2850 * If the Timer(peer) expires, send a Hello ACK TLV to the peer, 2851 restart the timer and transition to state WAIT_DICT. 2853 * If an Error TLV indicating a Dictionary Conflict or 2854 Bad String ID is received during or after sending the RIB 2855 Dictionary TLVs and/or the Bundle Offer TLVs, abort any in 2856 progress Initiator or Listener process, and terminate the 2857 connection to the peer. 2859 * If a Hello ACK message is received from the peer node, 2860 transition to state WAIT_DICT and restart the process. 2862 OFFER 2863 In this state the Listener expects to be receiving one or more 2864 Bundle Response TLVs detailing the bundles accepted by the 2865 Initiator node. The ordered list of accepted bundles is 2866 communicated to the Bundle Protocol Agent which controls sending 2867 them to the peer node over a separate connection. 2869 * When a Bundle Response TLV is received with a non-zero count of 2870 Bundle Offers, extract the list of accepted bundles and send 2871 the list to the Bundle Protocol Agent so that it can start 2872 transmission to the peer node. Ensure that the order of offers 2873 from the TLV is maintained. Restart the Timer(info) unless the 2874 last Bundle Response TLV received has the More Offer/ 2875 Response TLVs Following flag set to 0. If a Bundle Response 2876 TLV is received with a String ID that is not in the dictionary 2877 send a message with an Error TLV containing a Bad String ID 2878 indicator, abort any in progress Initiator or Listener process, 2879 and terminate the connection to the peer. 2881 * After receiving a Bundle Response TLV with the More Offer/ 2882 Response TLVs Following flag set to 0 stop the Timer(info) and 2883 transition to state SND_BUNDLE. 2885 * If the Timer(info) expires, send a Hello ACK TLV to the peer, 2886 restart the timer and transition to state WAIT_DICT. 2888 * If a Hello ACK message is received from the peer node, 2889 transition to state WAIT_DICT and restart the process. 2891 SND_BUNDLE 2892 In this state the Listener monitors the sending of bundles to the 2893 Initiator peer node. In the event of disruption in transmission, 2894 the Initiator node will, if possible, resend the list of bundles 2895 that were accepted but have not yet been received. The Bundle 2896 Protocol Agent has to be informed of any updates to the list of 2897 bundles to send (this is likely to involve resending one or more 2898 bundles). Otherwise the Listener is quiescent in this state. 2900 * When a Bundle Response TLV is received with a non-zero count of 2901 Bundle Offers, extract the list of accepted bundles and update 2902 the list previously passed to the Bundle Protocol Agent so that 2903 it can (re)start transmission to the peer node. Ensure that 2904 the order of offers from the TLV is maintained so far as is 2905 possible. Restart the Timer(info) unless the last Bundle 2906 Response TLV received has the More Offer/ 2907 Response TLVs Following flag set to 0. If a Bundle Response 2908 TLV is received with a String ID that is not in the dictionary 2909 send a message with an Error TLV containing a Bad String ID 2910 indicator, abort any in progress Initiator or Listener process, 2911 reinitialize the local dictionary and restart the information 2912 exchange process as if the ESTAB state had just been reached. 2914 * After receiving a Bundle Response TLV with the More Offer/ 2915 Response TLVs Following flag set to 0 stop the Timer(info) and 2916 wait for completion of bundle sending. 2918 * If the Timer(info) expires, send a Hello ACK TLV to the peer, 2919 restart the timer and transition to state WAIT_DICT. 2921 * If a Hello ACK message is received from the peer node, 2922 transition to state WAIT_DICT and restart the process. 2924 * When a Bundle Response TLV is received with a zero count of 2925 Bundle Offers, the bundle passing phase is complete. Notify 2926 the Initiator that the Listener process is complete and 2927 transition to state WAIT_MORE. 2929 As explained in the Initiator state REQUEST description, depending 2930 on the transport protocol (convergence layer) used to send the 2931 bundles to the peer node, it may be necessary to monitor the 2932 liveness of the connection to the peer node in the Initiator 2933 process during the bundle sending process using a timer. 2935 WAIT_MORE 2936 In this state the Listener monitors the reception of new bundles 2937 that might be received from a number of sources, including 2939 * local applications on the node, 2941 * other mobile nodes that connect to the node while this 2942 connection is open, and 2944 * permanent connections such as might occur at an Intenet 2945 gateway. 2947 When the Listener is notified of received bundles, it calls the 2948 newBundleArrived() function in the GORF API to determine if they 2949 should be offered to the peer. The peer may also reinitiate the 2950 information exchange process periodically. 2952 * When the Bundle Protocol Agent notifies the Listener that new 2953 bundles and/or new GORF ACKs have been received, the Listener 2954 applies calls the newBundleArrived() and/or ackReceived() 2955 functions to determine if any of the items ought to be offered 2956 to the connected peer. If so it carries out the same 2957 operations as are described in the WAIT_RIB state to build and 2958 send any necessary RIB Dictionary TLVs and RIB TLVs to the 2959 Initiator in the peer. 2961 * When all Bundle Offer TLVs have been sent start the Timer(info) 2962 and transition to state OFFER. 2964 * If a RIB dictionary TLV is received, use it to update the local 2965 dictionary and transition to state WAIT_RIB. If any of the 2966 entries in the RIB Dictionary TLV conflict with existing 2967 entries (i.e., an entry is received that uses the same String 2968 ID as some previously received entry but the EID in the entry 2969 is different), send a message with an Error TLV containing a 2970 Dictionary Conflict indicator, abort any in progress Initiator 2971 or Listener process, and terminate the connection to the peer. 2973 Note that the RIB Dictionary and RIB TLVs may be combined into a 2974 single message. The RIB TLV should be passed on to be processed 2975 in the WAIT_RIB state. 2977 6.3.3. Recommendations for Information Exchange Timer Periods 2979 The information exchange process state definitions define a number of 2980 timers. This section provides advice and recommendations for the 2981 periods that are appropriate for these timers. *** define this in 2982 routing algorithm module descriptions *** 2984 Both Timer(info) and Timer(peer) are used to ensure that the state 2985 machines do not become locked into inappropriate states if the peer 2986 node does not apparently respond to messages sent in a timely fashion 2987 either because of message loss in the network or unresponsiveness 2988 from the peer. The appropriate values are to some extent dependent 2989 on the speed of the network connection between the nodes and the 2990 capabilities of the nodes executing the GORF framework 2991 implementations. Values in the range 1 to 10 seconds SHOULD be used, 2992 with a value of 5 seconds RECOMMENDED as default. The period should 2993 not be set to too low a value as this might to inappropriate restarts 2994 if the hardware is relatively slow or there are large numbers of 2995 pieces of information to process before responding. When using a 2996 reliable transport protocol such as TCP, these timers effectively 2997 provide a keepalive mechanism and ensure that a failed connection is 2998 detected as rapidly as possible so that remedial action can be taken 2999 if possible or the connection shut down tidily if the peer node has 3000 moved out of range. 3002 Timer(next_exchange) is used to determine the maximum frequency of 3003 (i.e., minimum period between) successive reexecutions of the 3004 information exchange state machines during a single session between a 3005 pair of nodes. Selection of the timer period SHOULD reflect the 3006 trade off between load on the node processor and desire for timely 3007 forwarding of bundles received from other nodes. It is RECOMMENDED 3008 that the timer periods used should be randomized over a range from 3009 50% to 150% of the base value to avoid any risk of synchronization 3010 between multiple nodes occurring. Consideration SHOULD be given to 3011 the expected length of typical encounters and the likelihood of 3012 encounters between groups of nodes when setting this period. Base 3013 values in the range of 20 to 60 seconds are RECOMMENDED. 3015 6.3.4. Information Exchange State Tables 3017 This section shows the state transitions that nodes go through during 3018 the information exchange and bundle passing phase. State tables are 3019 given for the Initiator role and for the Listener role of the 3020 subsidiary state machines. Both nodes will be running machines in 3021 each role during the information exchange and bundle passing phase 3022 and this can be done either concurrently or sequentially, depending 3023 on the implementation, as explained in Section 6.3. The state tables 3024 in this section should be read in conjunction with the state 3025 descriptions in Sections 6.3.1 and 6.3.2. 3027 6.3.4.1. Common Notation, Operations and Events 3029 The following notation is used: 3031 nS Node that sent the Hello SYN message. 3033 nA Node that sent the Hello SYNACK message. 3035 The following events are common to the Initiator and Listener state 3036 tables:: 3038 ErrDC Dictionary Conflict Error TLV received. 3040 ErrBadSI Bad String ID Error TLV received. 3042 HelloAck Hello ACK TLV received. This message is delivered to 3043 both Initiator and Listener roles in order to cause a 3044 restart of the information exchange process in the 3045 event of message loss or protocol problems. 3046 nodeEncountered() called 3048 InitStart Sent by Listener role to Initiator role to signal the 3049 Initiator role to commence sending messages to peer. 3050 If the Listener instance is running in the node that 3051 sent the Hello SYN (nS) then InitStart is signaled 3052 immediately the state is entered. For the node that 3053 sent the Hello SYNACK (nA), InitStart may be signaled 3054 immediately if the operational policy requires 3055 concurrent operation of the Initiator and Listener 3056 roles or postponed until the Listener role state 3057 machine has reached a state defined by the configured 3058 policy. 3060 RIBnotlast RIB TLV received with More RIBs Follow flag set to 1. 3062 RIBlast RIB TLV received with More RIBs Follow flag set to 0. 3064 REQnotlast Bundle Response TLV received with More Offer/Response 3065 TLVs Following flag set to 1. 3067 REQlast Bundle Response TLV received with More Offer/Response 3068 TLVs Following flag set to 0. 3070 RIBDi RIBD TLV received with Sent by Listener flag set to 0 3071 (i.e., it was sent by Initiator role). 3073 RIBDl RIBD TLV received with Sent by Listener flag set to 1 3074 (i.e., it was sent by Listener role). 3076 Timeout(info) The Timer(info) has expired. 3078 Timeout(peer) The Timer(peer) has expired. 3080 Both the Initiator and Listener state tables use the following common 3081 operations: 3083 o The "Initialize Dictionary" operation is defined as emptying any 3084 existing local dictionary and inserting the two initial entries: 3085 the EID of the node that sent the Hello SYN (String ID 0) and the 3086 EID of the node that sent the Hello SYNACK (String ID 1). 3088 o The "Send RIB Dictionary Updates" operation is defined as: 3090 1. Determining what dictionary updates will be needed for any 3091 extra EIDs in the previously selected RIB entries set that are 3092 not already in the dictionary and updating the local 3093 dictionary with these EIDs. The set of dictionary updates may 3094 be empty if no extra EIDs are needed. The set may be empty 3095 even on the first execution if sequential operation has been 3096 selected, this is the second node to start and the necessary 3097 EIDs were in the set previously sent by the first node to 3098 start. 3100 2. Formatting zero or more RIBD TLVs for the set of dictionary 3101 updates identified in the "Build RIB Entries" operation and 3102 sends them to the peer. The RIBD TLVs MUST have the "Sent by 3103 Listener" flag set to 0 if the updates are sent by the 3104 Initiator role and to 1 if sent by the Listener role. In the 3105 case of the Initiator role an empty RIBD TLV MUST be sent even 3106 if the set of updates is empty in order to trigger the 3107 Listener state machine. 3109 o The "Update Dictionary" operation uses received RIBD TLV entries 3110 to update the local dictionary. The received entries are checked 3111 against the existing dictionary. If the String ID in the entry is 3112 already in use, the entry is accepted if the EID in the received 3113 entry is identical to that stored in the dictionary previously. 3114 If it is identical, the entry is unchanged, but if it is not a 3115 Response message with an Error TLV indicating "Dictionary 3116 Conflict" is sent to the peer in an Error Response message, the 3117 whole received RIBD TLV is ignored and the Initiator and Listener 3118 processes are restarted as if the ESTAB state has just been 3119 reached. 3121 o The "Abort Exchange" operation is defined as aborting any in 3122 progress information exchange state machines, terminating the 3123 connection to the peer. 3125 o The Start TI" operation is defined as (re)starting the Timer(info) 3126 timer. 3128 o The "Start TP" operation is defined as (re)starting the 3129 Timer(peer) timer. 3131 o The "Cancel TI" operation is defined as canceling the Timer(info) 3132 timer. 3134 o The "Cancel TP" operation is defined as canceling the Timer(info) 3135 timer. 3137 6.3.4.2. Initiator Role State Tables 3139 The rules and state tables for the Initiator role use the following 3140 operations: 3142 o The "Build RIB Entries" operation is defined as: 3144 1. Recording the state of the local dictionary. 3146 2. Determining the set of EIDs for which RIB entries should be 3147 sent during this execution of the Initiator role state machine 3148 component using the getRoutingState() function of the GORF 3149 API. If this is a second or subsequent run of the state 3150 machine in this node during the current session with the 3151 connected peer then the set of EIDs may be empty if no changes 3152 have occurred since the previous run of the state machine. 3154 3. Determining and extracting the current routing metric 3155 information for the set of EIDs selected. 3157 o The "Send RIB Entries" operation formats one or more RIB TLVs with 3158 the set of RIB entries identified in the "Build RIB Entries" 3159 operation and sends them to the peer. If the set is empty, a 3160 single RIB TLV with zero entries is sent. If more than one RIB 3161 TLV is sent, all but the last one MUST have the "More RIB TLVs" 3162 flag set to 1; the last or only one MUST have the flag set to 0. 3164 o The "Clear Bundle Lists" operation is defined as emptying the 3165 lists of bundles offered by and bundles requested from the peer. 3167 o The "Notify Acks" operation is defined as informing the bundle 3168 agent that GORF Acks has been received for one or more bundles in 3169 a Bundle Offer TLV using the Bundle Delivered interface (see 3170 Section 2.3). 3172 o The "Record Offers" operation is defined as recording all the 3173 bundles offered in a Bundle Offer TLV in the list of bundles 3174 offers. 3176 o The "Select for Request" operation prunes and sorts the list of 3177 offered bundles held into the list of requested bundles according 3178 to policy and available resources ready for sending to the 3179 offering node. 3181 o The "Send Requests" operation is defined as formatting one or more 3182 non-empty Bundle Response TLVs and sending them to the offering 3183 node.If more than one Bundle Offer TLV is sent, all but the last 3184 one MUST have the More Offer/ 3185 Response TLVs Following flag set to 1; the last or only 3186 one MUST have the flag set to 0. 3188 o The "Record Bundle Received" operation deletes a successfully 3189 received bundle from the list of requests. 3191 o The "All Requests Done" operation is defined as formatting and 3192 sending an empty Bundle Offer TLV, with the More Offer/ 3193 Response TLVs Following flag set to 0, to the offering 3194 node. 3196 o The "Check Receiving" operation is defined as checking with the 3197 node bundle agent if bundle reception from the peer node is 3198 currently in progress. Needed in case a timeout occurs while 3199 waiting for bundle reception and a very large bundle is being 3200 processed. 3202 The following events are specific to the Initiator role state 3203 machine: 3205 LastBndlRcvd Bundle received from peer that is the only remaining 3206 bundle in Bundle Requests List. 3208 NotLastBndlRcvd Bundle received from peer that is not the only 3209 remaining bundle in Bundle Requests List. 3211 OFRnotlast Bundle Offer TLV received with More Offer/Response TLVs 3212 Following flag set to 1. 3214 OFRlast Bundle Offer TLV received with More Offer/Response TLVs 3215 Following flag set to 0 3217 Timeout(next_exch) The Timer(next_exchange) has expired 3219 State: CREATE_DR 3221 +==================================================================+ 3222 | Condition | Action | New State | 3223 +==================+===================================+===========+ 3224 | On Entry | If previous state was ESTAB: | | 3225 | | Initialize Dictionary | | 3226 | | Always: | | 3227 | | Build RIB Entries | | 3228 | | Wait for Init Start | CREATE_DR | 3229 +------------------+-----------------------------------+-----------+ 3230 | InitStart | Send RIB Dictionary Updates | | 3231 | | Send RIB Entries | | 3232 | | Start TI | SEND_DR | 3233 +------------------+-----------------------------------+-----------+ 3234 | ErrDC | Abort Exchange |(finished) | 3235 +------------------+-----------------------------------+-----------+ 3236 | ErrBadSI | Abort Exchange |(finished) | 3237 +------------------+-----------------------------------+-----------+ 3238 | HelloAck | Abort Exchange | CREATE_DR | 3239 +==================================================================+ 3240 State: SEND_DR 3242 +==================================================================+ 3243 | Condition | Action | New State | 3244 +==================+===================================+===========+ 3245 | On Entry | Clear Bundle Lists | SEND_DR | 3246 +------------------+-----------------------------------+-----------+ 3247 | Timeout(info) | Send RIB Dictionary Updates | | 3248 | | Send RIB Entries (note 1) | SEND_DR | 3249 +------------------+-----------------------------------+-----------+ 3250 | RIBDl received | Update Dictionary (note 2) | | 3251 | | If Dictionary Conflict found: | | 3252 | | Abort Exchange | CREATE_DR | 3253 | | Else: | | 3254 | | Start TI | SEND_DR | 3255 +------------------+-----------------------------------+-----------+ 3256 | OFRnotlast | Notify Acks | | 3257 | | Record Offers | | 3258 | | Start TI | SEND_DR | 3259 +------------------+-----------------------------------+-----------+ 3260 | OFRlast | Cancel TI | | 3261 | | Notify Acks | | 3262 | | Record Offers | | 3263 | | Select for Request | | 3264 | | Send Requests | | 3265 | | Start TI | REQUEST | 3266 +------------------+-----------------------------------+-----------+ 3267 | ErrDC | Abort Exchange |(finished) | 3268 +------------------+-----------------------------------+-----------+ 3269 | ErrBadSI | Abort Exchange |(finished) | 3270 +------------------+-----------------------------------+-----------+ 3271 | HelloAck | Abort Exchange | CREATE_DR | 3272 +==================================================================+ 3273 State: REQUEST 3275 +==================================================================+ 3276 | Condition | Action | New State | 3277 +==================+===================================+===========+ 3278 | Timeout(info) | Check Receiving | | 3279 | | If bundle reception in progress: | | 3280 | | Start TI | REQUEST | 3281 | | Otherwise: | | 3282 | | Send Requests | | 3283 | | Start TI (note 3) | REQUEST | 3284 +------------------+-----------------------------------+-----------+ 3285 | NotLastBndlRcvd | Record Bundle Received | | 3286 | | Start TI | REQUEST | 3287 +------------------+-----------------------------------+-----------+ 3288 | LastBndlRecd | Cancel TI | | 3289 | | All Requests Done | | 3290 | | Start next_exchange timer | REQUEST | 3291 +------------------+-----------------------------------+-----------+ 3292 |Timeout(next_exch)| | CREATE_DR | 3293 +------------------+-----------------------------------+-----------+ 3294 | HelloAck | Abort Exchange | CREATE_DR | 3295 +==================================================================+ 3297 Note 1: 3298 No response to the RIB has been received before the timer expired, 3299 so we resend the dictionary and RIB TLVs. If the timeout occurs 3300 repeatedly it is likely that communication has failed and the 3301 connection MUST be terminated. 3303 Note 2: 3304 If a Dictionary Conflict error has to be sent the state machine 3305 will be aborted. If this event occurs repeatedly it is likely 3306 that there is either a serious software problem or a security 3307 issue. The connection MUST be terminated. 3309 Note 3: 3310 Remaining requested bundles have not arrived before the timer 3311 expired, so we resend the list of outstanding requests. If the 3312 timeout occurs repeatedly it is likely that communication has 3313 failed and the connection MUST be terminated. 3315 6.3.4.3. Listener Role State Tables 3317 The rules and state tables for the Listener role use the following 3318 operations: 3320 o The "Clear Supplied RIBs" operation is defined as setting up a an 3321 empty container to hold the set of RIBs supplied by the peer node. 3322 Note that any existing set of routing metrics should be retained 3323 in case an empty set is supplied meaning that the existing set 3324 should be reused. 3326 o The "Record RIBs Supplied" operation is defined as: 3328 1. Taking the RIB entries from a received RIB TLV. 3330 2. Verifying that the String ID used in each entry is present in 3331 the dictionary. If not an Error TLV containing the offending 3332 String ID is sent to the peer, the Initiator and Listener 3333 processes are aborted and restarted as if the ESTAB state had 3334 just been reached. 3336 3. If all the String IDs are present in the dictionary, record 3337 the routing metrics for each EID in the entries. 3339 o The "Update Routing State" operation uses the algorithms defined 3340 by the updateRoutingState() function in the GORF API to update the 3341 local state using the using the set of routing metrics supplied by 3342 the peer in RIB TLVs. 3344 o The "Determine Offers" operation determines the set of bundles to 3345 be offered to the peer. The local routing state and the routing 3346 metrics supplied by the peer are compared and a prioritized choice 3347 of the bundles stored in this node to be offered to the peer is 3348 made according to the configured queuing policy and forwarding 3349 strategy. 3351 o The "Determine Acks" operation is defined as obtaining the set of 3352 GORF Acks recorded by the bundle agent that need to be forwarded 3353 to the peer. The list of GORF ACks is maintained internally by 3354 the GORF framework implementation rather than the main bundle 3355 agent (see Section 4.4). 3357 o The "Determine Offer Dict Updates" operation is defined as 3358 determining any extra EIDs that are not already in the dictionary, 3359 recording the previous state of the local dictionary and then 3360 adding the required extra entries to the dictionary. 3362 o The "Send Offers" operation is defined as formatting one or more 3363 non-empty Bundle Offer TLVs incorporating the sets of Offers and 3364 GORF Acks previously determined and sending them to the peer node. 3365 If more than one Bundle Offer TLV is sent, all but the last one 3366 MUST have the More Offer/Response TLVs Following flag set to 1; 3367 the last or only one MUST have the flag set to 0. 3369 o The "Record Requests" operation is defined as recording all the 3370 bundles offered in a Bundle Offer TLV in the list of bundles 3371 offers. Duplicates MUST be ignored. The order of requests in the 3372 TLVs MUST be maintained so far as is possible (it is potentially 3373 possible that a bundle has to be resent and this may result in out 3374 of order delivery>) 3376 o The "Send Bundles" operation is defined as sending, in the order 3377 requested, the bundles in the requested list. This requires the 3378 list to be communicated to the bundle agent (see Section 2.3). 3380 o The "Check Initiator Start Point" operation is defined as checking 3381 the configured sequential operation policy to determine if the 3382 Listener role has reached the point where the Initiator role 3383 should be started. If so the InitStart notification is sent to 3384 the Initiator role in the same node. 3386 The following events are specific to the Listener role state machine: 3388 RIBnotlast RIB TLV received with More RIB TLVs flag set to 1. 3390 RIBlast RIB TLV received with More RIB TLVs flag set to 0 and a 3391 non-zero count of RIB Entries. 3393 REQnotlast Bundle Response TLV received with More Offer/Response 3394 TLVs Following flag set to 1. 3396 REQlast Bundle Response TLV received with More Offer/Response 3397 TLVs Following flag set to 0 and a non-zero count of 3398 Bundle Offers. 3400 REQempty Bundle Response TLV received with More Offer/Response 3401 TLVs Following flag set to 0 and a zero count of Bundle 3402 Offers. 3404 State: WAIT_DICT 3406 +==================================================================+ 3407 | Condition | Action | New State | 3408 +==================+===================================+===========+ 3409 | On Entry | Check Initiator Start Point | WAIT_DICT | 3410 +------------------+-----------------------------------+-----------+ 3411 | RIBDi | Update Dictionary (note 1) | | 3412 | | If Dictionary Conflict found: | | 3413 | | Abort Exchange |(finished) | 3414 | | Else: | | 3415 | | Start TP | WAIT_RIB | 3416 +------------------+-----------------------------------+-----------+ 3417 | HelloAck | Abort Exchange | WAIT_DICT | 3418 +==================================================================+ 3419 State: WAIT_RIB 3421 +==================================================================+ 3422 | Condition | Action | New State | 3423 +==================+===================================+===========+ 3424 | On Entry | Clear Supplied RIBS | WAIT_RIB | 3425 +------------------+-----------------------------------+-----------+ 3426 | RIBDi | Update Dictionary (note 1) | | 3427 | | If Dictionary Conflict found: | | 3428 | | Abort Exchange |(finished) | 3429 | | Else: | | 3430 | | Start TP | WAIT_RIB | 3431 +------------------+-----------------------------------+-----------+ 3432 | RIBnotlast | Record RIBS Supplied (note 2) | | 3433 | | If EID missing in dictionary: | | 3434 | | Abort Exchange |(finished) | 3435 | | Else: | | 3436 | | Start TP | WAIT_RIB | 3437 +------------------+-----------------------------------+----------- 3438 | RIBlast | Check Initiator Start Point | | 3439 | | Record RIBS Supplied (note 2) | | 3440 | | If EID missing in dictionary: | | 3441 | | Abort Exchange |(finished) | 3442 | | Otherwise | | 3443 | | updateRoutingState() | | 3444 | | Cancel TP | | 3445 | | generateOffers() | | 3446 | | Determine Acks | | 3447 | | Determine Offer | | 3448 | | Dict Updates | | 3449 | | Send RIB Dictionary | | 3450 | | Updates | | 3451 | | Send Offers | | 3452 | | Start TI | OFFER | 3453 +------------------+-----------------------------------+-----------+ 3454 | HelloAck | Abort Exchange | WAIT_DICT | 3455 +------------------+-----------------------------------+-----------+ 3456 |Any Other TLV rcvd| Abort Exchange |(finished) | 3457 +------------------+-----------------------------------+-----------+ 3458 | Timeout(peer) | Send RIB Dictionary Updates | | 3459 | | Send Offers | | 3460 | | Start TI (note 3) | OFFER | 3461 +==================================================================+ 3462 State: OFFER 3464 +==================================================================+ 3465 | Condition | Action | New State | 3466 +==================+===================================+===========+ 3467 | REQnotlast | Send Bundles | | 3468 | | Start TI | OFFER | 3469 +------------------+-----------------------------------+-----------+ 3470 | REQlast | Cancel TI | | 3471 | | Check Initiator Start Point | | 3472 | | Send Bundles | SND_BUNDLE| 3473 +------------------+-----------------------------------+-----------+ 3474 | REQempty | Cancel TI | | 3475 | | Check Initiator Start Point | WAIT_MORE| 3476 +------------------+-----------------------------------+-----------+ 3477 | HelloAck | Abort Exchange | WAIT_DICT | 3478 +------------------+-----------------------------------+-----------+ 3479 | Timeout(info) | Send RIB Dictionary Updates | | 3480 | | Send Offers | | 3481 | | Start TI (note 3) | OFFER | 3482 +==================================================================+ 3484 State: SND_BUNDLE 3486 +==================================================================+ 3487 | Condition | Action | New State | 3488 +==================+===================================+===========+ 3489 | REQnotlast | Send Bundles | | 3490 | | Start TI | SND_BUNDLE| 3491 +------------------+-----------------------------------+-----------+ 3492 | REQlast | Cancel TI | | 3493 | | Send Bundles | SND_BUNDLE| 3494 +------------------+-----------------------------------+-----------+ 3495 | REQempty | Cancel TI | | 3496 | | Check Initiator Start Point | WAIT_MORE| 3497 +------------------+-----------------------------------+-----------+ 3498 | HelloAck | Abort Exchange | WAIT_DICT | 3499 +------------------+-----------------------------------+-----------+ 3500 | Timeout(info) | Send RIB Dictionary Updates | | 3501 | | Send Offers | | 3502 | | Start TI (note 3) | OFFER | 3503 +==================================================================+ 3504 State: WAIT_MORE 3506 +==================================================================+ 3507 | Condition | Action | New State | 3508 +==================+===================================+===========+ 3509 | More Bundles | newBundleArrived() | | 3510 | | Determine Acks | | 3511 | | Determine Offer | | 3512 | | Dict Updates | | 3513 | | Send RIB Dictionary | | 3514 | | Updates | | 3515 | | Send Offers | | 3516 | | Start TI | OFFER | 3517 +------------------+-----------------------------------+-----------+ 3518 | RIBDi | Update Dictionary (note 1) | | 3519 | | If Dictionary Conflict found: | | 3520 | | Abort Exchange |(finished) | 3521 | | Else: | | 3522 | | Start TP | WAIT_RIB | 3523 +------------------+-----------------------------------+-----------+ 3524 | REQnotlast | Send Bundles | | 3525 | | Start TI | SND_BUNDLE| 3526 +------------------+-----------------------------------+-----------+ 3527 | REQlast | Cancel TI | | 3528 | | Send Bundles | SND_BUNDLE| 3529 +------------------+-----------------------------------+-----------+ 3530 | REQempty | Cancel TI | | 3531 | | Check Initiator Start Point | SND_BUNDLE| 3532 +------------------+-----------------------------------+-----------+ 3533 | HelloAck | Abort Exchange | WAIT_DICT | 3534 +------------------+-----------------------------------+-----------+ 3535 | Timeout(info) | Send RIB Dictionary Updates | | 3536 | | Send Offers | | 3537 | | Start TI (note 3) | OFFER | 3538 +==================================================================+ 3540 Note 1: Both the dictionary and the RIB TLVs may come in the same 3541 GORF message. In that case, the state will change to WAIT_RIB and 3542 the RIB will then immediately be processed. 3544 Note 2: Send an ACK if the timer for the peering node expires. 3545 Either the link has been broken, and then the link setup will 3546 restart, or it will trigger the information exchange phase to 3547 restart. 3549 Note 3: When the RIB is received it is possible for the GORF agent 3550 to update its internal routing state according to 3551 updateRoutingState() in the GORF API. The routing metrics and the 3552 RIB is then used together with the routing algorithm policy in 3553 generateOffer() in use to create a bundle offer TLV. This is sent 3554 to the peering node. 3556 Note 4: No more bundles are requested by the other node, transfer 3557 is complete. 3559 Note 5: No response to the bundle offer has been received before 3560 the timer expired, so we resend the bundle offer. 3562 7. Security Considerations 3563 8. IANA Considerations 3565 Following the policies outlined in "Guidelines for Writing an IANA 3566 Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following 3567 name spaces are defined in GORF: 3569 o For fields in the GORF message header (Section 5.1): 3571 * DTN Routing Protocol Number 3573 * GORF Protocol Version 3575 * GORF Header Flags 3577 * GORF Result Field 3579 * GORF Codes for Success and Codes for Failure 3581 o Identifiers for TLVs carried in GORF messages: 3583 * GORF TLV Type (Section 5.2) 3585 o Definitions of TLV Flags and other flag fields in TLVs: 3587 * Hello TLV Flags (Section 5.3.1) 3589 * Error TLV Flags (Section 5.3.2) 3591 * Routing Information Base (RIB) Dictionary TLV Flags 3592 (Section 5.3.3) 3594 * Routing Information Base (RIB) TLV Flags (Section 5.3.4) 3596 * Routing Information Base (RIB) Flags per entry (Section 5.3.4) 3598 * Bundle Offer and Response TLV Flags (Section 5.3.5) 3600 * Bundle Offer and Response B Flags per offer or response 3601 (Section 5.3.5) 3603 The following subsections lists the registries that are requested to 3604 be created. Initial values for the registries are given below; 3605 future assignments are to be made through the Specification Required 3606 policy. Where specific values are defined in the IANA registries to 3607 be setup according to the specifications in the sub-sections below, 3608 the registry should refer to this document as defining the 3609 allocation. 3611 8.1. DTN Routing Protocol Number 3613 The encoding of the Protocol Number field in the GORF header 3614 (Section 5.1) is: 3616 +--------------------------+-----------+------------------------+ 3617 | Protocol | Value | Allocation Control | 3618 +--------------------------+-----------+------------------------+ 3619 | PRoPHET Protocol | 0x00 | RFC6693 | 3620 | | | | 3621 | GORF Protocol | 0x01 | This document | 3622 | | | | 3623 | Reserved | 0x02-0xEF | Specification required | 3624 | | | | 3625 | Private/Experimental use | 0xF0-0xFE | Experimental | 3626 +--------------------------+-----------+------------------------+ 3628 8.2. GORF Protocol Version 3630 The encoding of the GORF Version field in the GORF header 3631 (Section 5.1) is: 3633 +------------------------------+-----------+------------------------+ 3634 | Version | Value | Allocation Control | 3635 +------------------------------+-----------+------------------------+ 3636 | Reserved | 0x00 | (Do not allocate) | 3637 | | | | 3638 | This protocol | 0x01 | This document | 3639 | | | | 3640 | Reserved | 0x02-0xEF | Specification required | 3641 | | | | 3642 | Private | 0xF0-0xFE | Experimental | 3643 | | | | 3644 | Reserved for future | 0xFF | Specification required | 3645 | expansion | | | 3646 +------------------------------+-----------+------------------------+ 3648 8.3. GORF Header Flags 3650 The following Flags are defined for the GORF Header (Section 5.1): 3652 +----------+--------------+------------------------+ 3653 | Meaning | Bit Position | Explanation | 3654 +----------+--------------+------------------------+ 3655 | Reserved | Bit 0 | Specification required | 3656 | | | | 3657 | Reserved | Bit 1 | Specification required | 3658 | | | | 3659 | Reserved | Bit 2 | Specification required | 3660 | | | | 3661 | Reserved | Bit 3 | Specification required | 3662 +----------+--------------+------------------------+ 3664 8.4. GORF Result Field 3666 The encoding of the Result field in the GORF header (Section 5.1) is: 3668 +--------------------------+-------------+------------------------+ 3669 | Result Value | Value | Allocation Control | 3670 +--------------------------+-------------+------------------------+ 3671 | NoSuccessAck | 0x01 | This document | 3672 | | | | 3673 | AckAll | 0x02 | This document | 3674 | | | | 3675 | Success | 0x03 | This document | 3676 | | | | 3677 | Failure | 0x04 | This document | 3678 | | | | 3679 | ReturnReceipt | 0x05 | This document | 3680 | | | | 3681 | Reserved | 0x06 - 0x7F | Specification required | 3682 | | | | 3683 | Private/Experimental Use | 0x80 - 0xFF | Experimental | 3684 +--------------------------+-------------+------------------------+ 3686 8.5. GORF Codes for Success and Codes for Failure 3688 The encoding for Code field in the GORF header (Section 5.1) for 3689 "Success" messages is: 3691 +--------------------------+-------------+------------------------+ 3692 | Code Name | Values | Allocation Control | 3693 +--------------------------+-------------+------------------------+ 3694 | Generic Success | 0x00 | This document | 3695 | | | | 3696 | Submessage Received | 0x01 | This document | 3697 | | | | 3698 | Reserved | 0x02 - 0x7F | Specification required | 3699 | | | | 3700 | Private/Experimental Use | 0x80 - 0xFF | Experimental | 3701 +--------------------------+-------------+------------------------+ 3703 The encoding for Code in the GORF header (Section 5.1) for "Failure" 3704 messages is: 3706 +--------------------------+-------------+------------------------+ 3707 | Code Name | Values | Allocation Control | 3708 +--------------------------+-------------+------------------------+ 3709 | Reserved | 0x00 - 0x01 | (Do not allocate) | 3710 | | | | 3711 | Unspecified Failure | 0x02 | This document | 3712 | | | | 3713 | Reserved | 0x03 - 0x7F | Specification required | 3714 | | | | 3715 | Private/Experimental Use | 0x80 - 0xFE | Experimental | 3716 | | | | 3717 | Error TLV in message | 0xFF | This document | 3718 +--------------------------+-------------+------------------------+ 3720 8.6. GORF TLV Type 3722 The TLV Types defined for GORF (Section 5.2) are: 3724 +--------------------------+-------------+------------------------+ 3725 | Type | Value | Allocation Control | 3726 +--------------------------+-------------+------------------------+ 3727 | Hello TLV | 0x01 | This document | 3728 | | | | 3729 | Error TLV | 0x02 | This document | 3730 | | | | 3731 | Reserved | 0x03 - 0x9F | Specification required | 3732 | | | | 3733 | RIB dictionary TLV | 0xA0 | This document | 3734 | | | | 3735 | RIB TLV | 0xA1 | This document | 3736 | | | | 3737 | Bundle Offer | 0xA2 | (Deprecated) | 3738 | | | | 3739 | Bundle Response | 0xA3 | (Deprecated) | 3740 | | | | 3741 | Bundle Offer (v2) | 0xA4 | This document | 3742 | | | | 3743 | Bundle Response (v2) | 0xA5 | This document | 3744 | | | | 3745 | Reserved | 0xA6 - 0xCF | Specification required | 3746 | | | | 3747 | Private/Experimental Use | 0xD0 - 0xFF | Experimental | 3748 +--------------------------+-------------+------------------------+ 3750 8.7. Hello TLV Flags 3752 The following TLV Flags are defined for the Hello TLV 3753 (Section 5.3.1). Flag numbers 0, 1 and 2 are treated as a three bit 3754 unsigned integer with five of the eight possible values allocated and 3755 the other three reserved. The remaining bits are treated 3756 individually: 3758 +----------+-------------------+------------------------+ 3759 | Meaning | Value | Allocation Control | 3760 +----------+-------------------+------------------------+ 3761 | | (Flags 0,1 and 2) | | 3762 | | | | 3763 | Reserved | 0b000 | Do not allocate | 3764 | | | | 3765 | SYN | 0b001 | This document | 3766 | | | | 3767 | SYNACK | 0b010 | This document | 3768 | | | | 3769 | ACK | 0b011 | This document | 3770 | | | | 3771 | RSTACK | 0x100 | This document | 3772 | | | | 3773 | Reserved | 0b101 - 0b111 | Specification required | 3774 | | | | 3775 | | (Flags 3 - 7) | | 3776 | | | | 3777 | Reserved | Flag 3 | Specification required | 3778 | | | | 3779 | Reserved | Flag 4 | Specification required | 3780 | | | | 3781 | Reserved | Flag 5 | Specification required | 3782 | | | | 3783 | Reserved | Flag 6 | Specification required | 3784 | | | | 3785 | L Flag | Flag 7 | This document | 3786 +----------+-------------------+------------------------+ 3788 8.8. Error TLV Flags 3790 The TLV Flags field in the Error TLV (Section 5.3.2) is treated as an 3791 unsigned 8 bit integer encoding the Error TLV number. The following 3792 values are defined: 3794 +---------------------+------------------+------------------------+ 3795 | Error TLV Name | Error TLV Number | Allocation Control | 3796 +---------------------+------------------+------------------------+ 3797 | Dictionary Conflict | 0x00 | This document | 3798 | | | | 3799 | Bad String ID | 0x01 | This document | 3800 | | | | 3801 | Reserved | 0x02 - 0x7F | Specification required | 3802 | | | | 3803 | Private | 0x80 - 0xFF | Experimental | 3804 +---------------------+------------------+------------------------+ 3806 8.9. RIB Dictionary TLV Flags 3808 The following TLV Flags are defined for the RIB Base Dictionary TLV 3809 (Section 5.3.3): 3811 +------------------+--------------+------------------------+ 3812 | Meaning | Bit Position | Allocation Control | 3813 +------------------+--------------+------------------------+ 3814 | Sent by Listener | Flag 0 | This document | 3815 | | | | 3816 | Reserved | Flag 1 | Reserved | 3817 | | | | 3818 | Reserved | Flag 2 | Reserved | 3819 | | | | 3820 | Reserved | Flag 3 | Specification required | 3821 | | | | 3822 | Reserved | Flag 4 | Specification required | 3823 | | | | 3824 | Reserved | Flag 5 | Specification required | 3825 | | | | 3826 | Reserved | Flag 6 | Specification required | 3827 | | | | 3828 | Reserved | Flag 7 | Specification required | 3829 +------------------+--------------+------------------------+ 3831 8.10. RIB TLV Flags 3833 The following TLV Flags are defined for the RIB TLV (Section 5.3.4): 3835 +---------------+--------------+------------------------+ 3836 | Meaning | Bit Position | Allocation Control | 3837 +---------------+--------------+------------------------+ 3838 | More RIB TLVs | Flag 0 | This document | 3839 | | | | 3840 | Reserved | Flag 1 | Reserved | 3841 | | | | 3842 | Reserved | Flag 2 | Reserved | 3843 | | | | 3844 | Reserved | Flag 3 | Specification required | 3845 | | | | 3846 | Reserved | Flag 4 | Specification required | 3847 | | | | 3848 | Reserved | Flag 5 | Specification required | 3849 | | | | 3850 | Reserved | Flag 6 | Specification required | 3851 | | | | 3852 | Reserved | Flag 7 | Specification required | 3853 +---------------+--------------+------------------------+ 3855 8.11. RIB Flags 3857 The following RIB Flags are defined for the individual entries in the 3858 RIB TLV (Section 5.3.4): 3860 +----------+--------------+------------------------+ 3861 | Meaning | Bit Position | Allocation Control | 3862 +----------+--------------+------------------------+ 3863 | Reserved | Flag 0 | Specification required | 3864 | | | | 3865 | Reserved | Flag 1 | Specification required | 3866 | | | | 3867 | Reserved | Flag 2 | Specification required | 3868 | | | | 3869 | Reserved | Flag 3 | Specification required | 3870 | | | | 3871 | Reserved | Flag 4 | Specification required | 3872 | | | | 3873 | Reserved | Flag 5 | Specification required | 3874 | | | | 3875 | Reserved | Flag 6 | Specification required | 3876 | | | | 3877 | Reserved | Flag 7 | Specification required | 3878 +----------+--------------+------------------------+ 3880 8.12. Bundle Offer and Response TLV Flags 3882 The following TLV Flags are defined for the Bundle Offer and Response 3883 TLV (Section 5.3.5): 3885 +------------------------------+-------------+----------------------+ 3886 | Meaning | Bit | Allocation Control | 3887 | | Position | | 3888 +------------------------------+-------------+----------------------+ 3889 | More Offer/Response TLVs | Flag 0 | This document | 3890 | Following | | | 3891 | | | | 3892 | Reserved | Flag 1 | Specification | 3893 | | | required | 3894 | | | | 3895 | Reserved | Flag 2 | Specification | 3896 | | | required | 3897 | | | | 3898 | Reserved | Flag 3 | Specification | 3899 | | | required | 3900 | | | | 3901 | Reserved | Flag 4 | Specification | 3902 | | | required | 3903 | | | | 3904 | Reserved | Flag 5 | Specification | 3905 | | | required | 3906 | | | | 3907 | Reserved | Flag 6 | Specification | 3908 | | | required | 3909 | | | | 3910 | Reserved | Flag 7 | Specification | 3911 | | | required | 3912 +------------------------------+-------------+----------------------+ 3914 8.13. Bundle Offer and Response B Flags 3916 The following B Flags are defined for each Bundle Offer in the Bundle 3917 Offer and Response TLV (Section 5.3.5): 3919 +--------------------------------+------------+---------------------+ 3920 | Meaning | Bit | Allocation Control | 3921 | | Position | | 3922 +--------------------------------+------------+---------------------+ 3923 | Bundle Accepted | Flag 0 | This document | 3924 | | | | 3925 | Bundle is a Fragment | Flag 1 | This document | 3926 | | | | 3927 | Bundle Payload Length Included | Flag 2 | This document | 3928 | in TLV | | | 3929 | | | | 3930 | Reserved | Flag 3 | Specification | 3931 | | | required | 3932 | | | | 3933 | Reserved | Flag 4 | Specification | 3934 | | | required | 3935 | | | | 3936 | Reserved | Flag 5 | Specification | 3937 | | | required | 3938 | | | | 3939 | Reserved | Flag 6 | Specification | 3940 | | | required | 3941 | | | | 3942 | GORF Ack | Flag 7 | This document | 3943 +--------------------------------+------------+---------------------+ 3945 9. Acknowledgements 3947 ... 3949 10. References 3951 10.1. Normative References 3953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3954 Requirement Levels", BCP 14, RFC 2119, March 1997. 3956 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 3957 Specification", RFC 5050, November 2007. 3959 10.2. Informative References 3961 [I-D.irtf-dtnrg-tcp-clayer] 3962 Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant 3963 Networking TCP Convergence Layer Protocol", 3964 draft-irtf-dtnrg-tcp-clayer-06 (work in progress), 3965 May 2013. 3967 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 3968 June 1988. 3970 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 3971 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 3972 Networking Architecture", RFC 4838, April 2007. 3974 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3975 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 3976 May 2008. 3978 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 3979 "Bundle Security Protocol Specification", RFC 6257, 3980 May 2011. 3982 Authors' Addresses 3984 Anders F. Lindgren 3985 SICS Swedish ICT 3986 Box 1263 3987 Kista SE-164 29 3988 SE 3990 Phone: +46707177269 3991 Email: andersl@sics.se 3992 URI: http://www.sics.se/~andersl 3994 Elwyn Davies 3995 Folly Consulting 3996 Soham 3997 UK 3999 Phone: 4000 Email: elwynd@folly.org.uk 4001 URI: 4003 Avri Doria 4004 Consultant 4005 Providence RI 4006 US 4008 Phone: 4009 Email: avri@acm.org 4010 URI: http://psg.com/~avri