DTN Research Group A. Lindgren Internet-Draft SICS Intended status: Experimental E. Davies Expires: February 1, 2014 Folly Consulting A. Doria Consultant July 31, 2013 Generic Opportunistic Routing Framework draft-lindgren-dtnrg-gorf-00 Abstract This document defines GORF, a Generic Opportunistic Routing Framework. GORF specifies all necessary basic functionality that is common for all utility-based routing protocols that are variants of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as Delay- and Disruption-Tolerant). The document presents an architectural overview followed by the protocol specification. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 1, 2014. Copyright Notice Lindgren, et al. Expires February 1, 2014 [Page 1] Internet-Draft GORF July 2013 Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Relation to the Delay Tolerant Networking architecture . . 4 1.2. Applicability of the routing framework . . . . . . . . . . 5 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 6 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Routing Algorithm Module Conceptual Overview . . . . . . . 7 2.2. GORF . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Forwarding Strategies . . . . . . . . . . . . . . . . 7 2.3. Bundle Agent to Routing Agent Interface . . . . . . . . . 8 2.4. GORF Zone Gateways . . . . . . . . . . . . . . . . . . . . 9 2.5. Lower Layer Requirements and Interface . . . . . . . . . . 9 3. Routing Algorithm Modules . . . . . . . . . . . . . . . . . . 11 3.1. Routing Algorithm Identifier . . . . . . . . . . . . . . . 11 3.2. Module API - Internal State . . . . . . . . . . . . . . . 11 3.2.1. Metric format description syntax . . . . . . . . . . . 11 3.2.2. Routing Metric Format . . . . . . . . . . . . . . . . 14 3.2.3. Node Characteristics Format . . . . . . . . . . . . . 14 3.3. Module API - Functions . . . . . . . . . . . . . . . . . . 15 3.3.1. getMetricFormat() . . . . . . . . . . . . . . . . . . 16 3.3.2. getNodeCharFormat() . . . . . . . . . . . . . . . . . 16 3.3.3. getNodeCharacteristics() . . . . . . . . . . . . . . . 16 3.3.4. encounteredNode . . . . . . . . . . . . . . . . . . . 16 3.3.5. getRoutingState() . . . . . . . . . . . . . . . . . . 17 3.3.6. updateRoutingState() . . . . . . . . . . . . . . . . . 17 3.3.7. generateOffer . . . . . . . . . . . . . . . . . . . . 18 3.3.8. generateResponse . . . . . . . . . . . . . . . . . . . 18 3.3.9. bundleSent() . . . . . . . . . . . . . . . . . . . . . 19 3.3.10. getInformationExchangeTimer() . . . . . . . . . . . . 19 3.3.11. newBundleArrived() . . . . . . . . . . . . . . . . . . 20 3.3.12. nodeDisconnected() . . . . . . . . . . . . . . . . . . 20 3.3.13. dropAdvice . . . . . . . . . . . . . . . . . . . . . . 20 3.3.14. ackReceived() . . . . . . . . . . . . . . . . . . . . 21 Lindgren, et al. Expires February 1, 2014 [Page 2] Internet-Draft GORF July 2013 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Neighbor Awareness . . . . . . . . . . . . . . . . . . . . 22 4.2. Information Exchange Phase . . . . . . . . . . . . . . . . 22 4.2.1. Routing Information Base Dictionary . . . . . . . . . 25 4.2.2. Handling Multiple Simultaneous Contacts . . . . . . . 26 4.3. Bundle Passing . . . . . . . . . . . . . . . . . . . . . . 26 4.4. When a Bundle Reaches its Destination . . . . . . . . . . 26 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. TLV Structure . . . . . . . . . . . . . . . . . . . . . . 34 5.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3.1. Hello TLV . . . . . . . . . . . . . . . . . . . . . . 35 5.3.2. Error TLV . . . . . . . . . . . . . . . . . . . . . . 37 5.3.3. Routing Information Base Dictionary TLV . . . . . . . 39 5.3.4. Routing Information Base TLV . . . . . . . . . . . . . 41 5.3.5. Bundle Offer and Response TLVs . . . . . . . . . . . . 42 6. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 47 6.1. High Level State Tables . . . . . . . . . . . . . . . . . 47 6.2. Hello Procedure . . . . . . . . . . . . . . . . . . . . . 51 6.2.1. Hello Procedure State Tables . . . . . . . . . . . . . 53 6.3. Information Exchange and Bundle Passing Phase . . . . . . 54 6.3.1. Initiator Role State Definitions . . . . . . . . . . . 57 6.3.2. Listener Role State Definitions . . . . . . . . . . . 62 6.3.3. Recommendations for Information Exchange Timer Periods . . . . . . . . . . . . . . . . . . . . . . . 68 6.3.4. Information Exchange State Tables . . . . . . . . . . 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 8.1. DTN Routing Protocol Number . . . . . . . . . . . . . . . 85 8.2. GORF Protocol Version . . . . . . . . . . . . . . . . . . 85 8.3. GORF Header Flags . . . . . . . . . . . . . . . . . . . . 86 8.4. GORF Result Field . . . . . . . . . . . . . . . . . . . . 86 8.5. GORF Codes for Success and Codes for Failure . . . . . . . 87 8.6. GORF TLV Type . . . . . . . . . . . . . . . . . . . . . . 88 8.7. Hello TLV Flags . . . . . . . . . . . . . . . . . . . . . 89 8.8. Error TLV Flags . . . . . . . . . . . . . . . . . . . . . 90 8.9. RIB Dictionary TLV Flags . . . . . . . . . . . . . . . . . 90 8.10. RIB TLV Flags . . . . . . . . . . . . . . . . . . . . . . 91 8.11. RIB Flags . . . . . . . . . . . . . . . . . . . . . . . . 92 8.12. Bundle Offer and Response TLV Flags . . . . . . . . . . . 93 8.13. Bundle Offer and Response B Flags . . . . . . . . . . . . 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 96 10.1. Normative References . . . . . . . . . . . . . . . . . . . 96 10.2. Informative References . . . . . . . . . . . . . . . . . . 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 Lindgren, et al. Expires February 1, 2014 [Page 3] Internet-Draft GORF July 2013 1. Introduction A lot of research on Delay Tolerant Networking (DTN) [RFC4838] has been carried out over the past decade. Much of this research have focused on routing protocols and many routing algorithms have been proposed in research papers. However, most protocol never get further than a research paper, a simulation implementation, and possibly an implementation for a real system that is not well documented. This has the problem that it is hard to reproduce research results. Designing a full routing protocol with all the required details of protocol operation, message formats, state machines, etc, is also a daunting and time-consuming task. This makes experimentation with new ideas and routing algorithms difficult, slowing potential progress in the area. Many of the existing routing algorithms have a lot of similarities in the way the operate. The protocols are essentially creating and maintaining some sort of routing metric for different destinations. This information is exchanged with other nodes as they opportunistically meet. The nodes then make use of this information to determine how to forward bundles in the network. While there are many differences in how the routing metrics are maintained and calculated, and what decision processes are used to make bundle forwarding decisions, the basic mechnisms of the protocols are mostly the same. This document presents a framework for opportunistic routing protocols in intermittently connected networks, using the mobility of nodes to delivery messages. Many different algorithms exist for determining how the selection of forwarding path is done, and this is accomodated in the framework by providing a well-defined interface that allows each routing algorithm to be specified in a separate document. Having a system like this has multiple benefits. First of all, it makes it easy for people to create a well-defined and implementable (interoperable) specification of a new routing algorithm that can easily be used in a real system. Further, it makes prototyping and testing of new routing algorithms quick and easy. Once the routing framework is implemented, it is only necessary to create a new class/ dynamic library/etc (depending on the implementation language) that plugs into the main implementation. 1.1. Relation to the Delay Tolerant Networking architecture The GORF routing framework is primarily designed to be used for intermittently connected networks using the Delay-Tolerant Networking (DTN) architecture [RFC4838] for communication in environments where Lindgren, et al. Expires February 1, 2014 [Page 4] Internet-Draft GORF July 2013 traditional communication protocols can not be used due to excessive delays, link outages and other extreme conditions. Communication in this architecture uses the bundle protocol [RFC5050], which provides a way for applications to "bundle" an entire session, including both data and meta-data, into a single message, or bundle, that can be sent as a unit. The bundle protocol also provides end-to-end addressing and acknowledgments. The GORF routing framework was originally intended to provide routing services in a network environment that uses bundles as its data transfer mechanism. However, there are also many systems that utilize other types of addressing and naming of nodes and content. There are currently plans to add support in future versions of this document to arbitrarily specify the format of node, destination, and message identifiers to allow the GORF framework to also be used in systems utilizing IP or some other underlying communication architecture. 1.2. Applicability of the routing framework The GORF routing framework is mainly targeted at situations where at least some of the nodes are mobile with mobility that creates connectivity patterns that are not completely random over time but have a degree of predictability. Such connectivity patterns can also occur in networks where nodes switch off radios to preserve power. The GORF framework expects nodes to be able to establish a local TCP link in order to exchange the information needed by the framework. Protocol signaling is done out-of-band over this TCP link, without involving the Bundle Protocol agent [RFC5050]. The GORF framework however expected to interact with the Bundle Protocol agent to retrieve information about available bundles as well as requesting that a bundle is sent to another node (it is expected that the associated bundle agents are then able to establish a link (probably over the TCP convergence layer [I-D.irtf-dtnrg-tcp-clayer]) to perform this bundle transfer). Since TCP offers reliable delivery, it is RECOMMENDED that the positive acknowledgment capability is not used when GORF is run over a TCP transport or similar protocol. When running over TCP, implementations MAY safely ignore positive acknowledgments. In a large Delay- and Disruption-Tolerant Network (DTN), network conditions may vary widely, and in different parts of the network, different routing protocols may be appropriate. In this specification, we consider routing within a single "GORF zone", which is a set of nodes among which messages are routed using an instance of the GORF framework. In many cases, a GORF zone will not span the entire DTN, but there will be other parts of the network with other characteristics that run other routing protocols. To handle this, Lindgren, et al. Expires February 1, 2014 [Page 5] Internet-Draft GORF July 2013 there may be nodes within the zone that act as gateways to other nodes that are the destinations for bundles generated within the zone or that insert bundles into the zone. 1.3. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Lindgren, et al. Expires February 1, 2014 [Page 6] Internet-Draft GORF July 2013 2. Architecture This section provides an outline of the GORF architecture. More details will be provided in subsequent sections. 2.1. Routing Algorithm Module Conceptual Overview The GORF framework enables different routing algorithms for intermittently connected networks to be easily defined and implemented by specifying a Routing Algorithm Module. This module implements a set of functions that provide the specialized functionality required for that particular routing algorithm. A detailed specification of the Routing Algorithm Module interface that each module must implement is given in Section 3. This section provides a conceptual overview of routing algorithm modules and their use in the GORF framework. Traditional routing protocols associate a cost (often the hop-count with each destination) with each destination. The same is true for utility-based routing protocols for metric associated with each known destination. 2.2. GORF When two GORF nodes have a communication opportunity, they first exchange routing metrics for all relevant destinations known by the nodes. This information is used by the nodes to update the internal routing state based on the functions defined by the GORF API and implemented by the routing algorithm module. After that, the nodes exchange information (including destination and size) about the bundles each node carries and the routing algorithm module then use this information in conjunction with the updated routing state to decide which bundles to request to be forwarded from the other node. 2.2.1. Forwarding Strategies In traditional routing protocols, choosing where to forward a message is usually a simple task; the message is sent to the neighbor that has the path to the destination with the lowest cost (often the shortest path). Normally the message is also only sent to a single node since the reliability of paths is relatively high. However, in the settings we envision here, things are radically different. The first possibility that must be considered when a bundle arrives at a node is that there might not be a path to the destination available, so the node has to buffer the bundle and upon each encounter with another node, the decision must be made whether or not to transfer a particular bundle. Furthermore, having duplicates of messages (on different nodes, as the bundle offer/request mechanism described in Lindgren, et al. Expires February 1, 2014 [Page 7] Internet-Draft GORF July 2013 Section 5.3.5 ensures that a node does not receive a bundle it already carries) may also be sensible, as forwarding a bundle to multiple nodes can increase the delivery probability of that bundle. In a protocol based on the GORF framework, the decisions on which bundle to forward is taken by the routing algorithm modules in the generateOffer() and generateResponse() functions as defined in Section 3.3.7 and Section 3.3.8. 2.3. Bundle Agent to Routing Agent Interface The bundle protocol [RFC5050] introduces the concept of a "bundle agent" that manages the interface between applications and the "convergence layers" that provide the transport of bundles between nodes during communication opportunities. This specification extends the bundle agent with a routing agent that controls the actions of the bundle agent during an (opportunistic) communications opportunity. This specification defines the details of the GORF framework routing agent, but the interface defines a more general interface that is also applicable to alternative routing protocols. To enable the GORF framework routing agent to operate properly, it must be aware of the bundles stored at the node, and it must also be able to tell the bundle agent of that node to send a bundle to a peering node. Therefore, the bundle agent needs to provide the following interface/functionality to the routing agent: Get Bundle List Returns a list of the stored bundles and their attributes to the routing agent. Send Bundle Makes the bundle agent send a specified bundle. Accept Bundle Gives the bundle agent a new bundle to store. Bundle Delivered Tells the bundle agent that a bundle was delivered to its destination. Drop Bundle Advice Advises the bundle agent that a specified bundle should not be offered for forwarding in future and may be dropped by the bundle agent if appropriate. Lindgren, et al. Expires February 1, 2014 [Page 8] Internet-Draft GORF July 2013 Route Import Can be used by a gateway node in a GORF zone to import reachability information about EIDs that are external to the GORF zone. Translation functions dependent on the external routing protocol will be used to set the appropriate delivery predictabilities for imported destinations as described in Section 2.4. Route Export Can be used by a gateway node in a GORF zone to export reachability information (destination EIDs and corresponding delivery predictabilities) for use by routing protocols in other parts of the DTN. Implementation Note: Depending on the distribution of functions in a complete bundle agent supporting the GORF framework, reception and delivery of bundles may not be carried out directly by the GORF framework module. In this case, the framework can inform the bundle agent about bundles that have been requested from communicating nodes. Then the Accept Bundle and Bundle Delivered functions can be implemented as notifications of the GORF framework module when the relevant bundles arrive at the node or are delivered to local applications. 2.4. GORF Zone Gateways GORF is designed to handle routing primarily within a "GORF zone," i.e., a set of nodes that all implement the GORF routing framework with a specific routing algorithm. However, since we recognise that a GORF routing zone is unlikely to encompass an entire DTN, there may be nodes within the zone that act as gateways to other nodes that are the destinations for bundles generated within the zone or that insert bundles into the zone. GORF MAY elect to export and import routes across a bundle agent interface. The delivery predictability to use for routes that are imported depends on the routing protocol used to manage those routes. If a translation function between the external routing protocol and the GORF routing algorithm instance in use exists, it SHOULD be used to set the delivery predictability. If no such translation function exists, the delivery predictability SHOULD be set to 1. For those routes that are exported, the current delivery predictability will be exported with the route. 2.5. Lower Layer Requirements and Interface GORF can be run on a large number of underlying networking technologies. To accommodate its operation on all kinds of lower Lindgren, et al. Expires February 1, 2014 [Page 9] Internet-Draft GORF July 2013 layers, it requires the lower layers to provide the following functionality and interfaces. Neighbor discovery and maintenance A GORF node needs to know the identity of its neighbors and when new neighbors appear and old neighbors disappear. Some wireless networking technologies might already contain mechanisms for detecting neighbors and maintaining this state. To avoid redundancies and inefficiencies, neighbor discovery is thus not included as a part of GORF, but GORF relies on such a mechanism in lower layers. The lower layers MUST provide the two functions listed below. If the underlying networking technology does not support such services, a simple neighbor discovery scheme using local broadcasts of beacon messages could be run in-between GORF and the underlying layer. New Neighbor Signals to the GORF framework agent that a new node has become a neighbor. A neighbor is here defined as another node that is currently within communication range of the wireless networking technology in use. The GORF agent should now start the Hello procedure as described in Section 6.2. Neighbor Gone Signals to the GORF agent that one of its neighbors have left. Local Address An address used by the underlying communication layer (e.g., an IP or MAC address) that identifies the sender address of the current message. This address must be unique among the nodes that can currently communicate, and is only used in conjunction with an Instance Number to identify a communicating pair of nodes as described in Section 5.1. This address and its format is dependent on the communication layer that is being used by the GORF framework layer. Lindgren, et al. Expires February 1, 2014 [Page 10] Internet-Draft GORF July 2013 3. Routing Algorithm Modules When defining a new routing algorithm module to be used with the GORF framework, a section of the specificaion document should follow the structure of this section, and provide definitions to the following items/interfaces defined in the GORF API: 3.1. Routing Algorithm Identifier Each module needs to specify which value should be used in the Routing Algorithm Identifier in the GORF header defined in Section 5.1. 3.2. Module API - Internal State Each module needs to, at a minimum, define two pieces of internal state information, the format of the routing metric and the format of the node characteristic information to be shared among nodes. This is further described in the rest of this section. In addition to this, each routing module should in this section also define any other internal state required for the routing algorithm to work properly. This includes local variables, data structures, etc. 3.2.1. Metric format description syntax Lindgren, et al. Expires February 1, 2014 [Page 11] Internet-Draft GORF July 2013 Format definition: Length: (octet) Type[1]: (octet) Type parameter[1]: < (octet) . . . Type[n]: Type parameter[n]: Where the type values are given by the table below. +==================================================================+ | Type value | Type description | Type parameter | Length | +============+=========================+================+==========+ | 0x00 | Reserved | N/A | N/A | +------------+-------------------------+----------------+----------+ | 0x01 | 8 bit integer value | N/A | 8 bits | +------------+-------------------------+----------------+----------+ | 0x02 | 16 bit integer value | N/A | 16 bits | | | in network byte order | | | +------------+-------------------------+----------------+----------+ | 0x03 | 32 bit integer value | N/A | 32 bits | | | in network byte order | | | +------------+-------------------------+----------------+----------+ | 0x04 | 64 bit integer value | N/A | 64 bits | | | in network byte order | | | +------------+-------------------------+----------------+----------+ | 0x05 | SDNV integer value as | N/A | Variable | | | defined in RFCxxxx | | | +------------+-------------------------+----------------+----------+ | 0x06 | String | N/A | Variable | +------------+-------------------------+----------------+----------+ | 0x07 | Bit sequence | N/A | Variable | +------------+-------------------------+----------------+----------+ | 0x08 | List | List type | Variable | +==================================================================+ Example specification. Assume a protocol has a node metric that includes its position (two coordinates as 16 bit integers), and a list of the IP addresses of all its currently connected neighbors (a list of 32 bit integers). Then the metric format specification looks like this: Lindgren, et al. Expires February 1, 2014 [Page 12] Internet-Draft GORF July 2013 Format definition: ----------------------- Length: 3 Type[1]: 0x02 Type[2]: 0x02 Type[3]: 0x08 Type parameter[3]: 0x03 ----------------------- 3.2.1.1. Binary representation as octet sequence This format definition can also be described in a compact format as a sequence of octets where each item in the structure above (length/ type/type parameter) is one octet (the example above is given by the octet sequence {0x03, 0x02, 0x02, 0x08, 0x03}). This format is what is returned by the functions getMetricFormat() and getNodeCharFormat() described further down in this section, and what is included in GORF protocol messages. 3.2.1.2. Encoding of metric values An instance/value of a particular metric format is given by an octet sequence, where each item of a particular type is encoded as follows: 8 bit integer: Fixed length 8 bit integer value in the range 0-255. 16 bit integer: Fixed length 16 bit unsigned integer value in network byte order. 32 bit integer: Fixed length 32 bit unsigned integer value in network byte order. 64 bit integer: Fixed length 64 bit unsigned integer value in network byte order. SDNV value: Variable length integer value represented as SDNV. String: Text string, formatted as follows: String Length: 16 bit integer specifying the number of characters in the string Lindgren, et al. Expires February 1, 2014 [Page 13] Internet-Draft GORF July 2013 Characters: Sequence of characters making up the string. Bit sequence: Generic sequence of bits, formatted as follows: Sequence Length: 16 bit integer specifying the number of octets in the bit sequence. Octets: Octets making up the bit sequence. List: List of items, formatted as follows: List type: 8 bit integer specifying the type of the items in this list. List length: 16 bit integer specifying the number of items in this list. List items: Sequence of items, formatted according to the type of the list. 3.2.2. Routing Metric Format During the information exchange phase, two peering GORF nodes will exchange a list of relevant destinations and the routing metrics associated with them. As different routing algorithms may have need for different such routing metrics Each routing algorithm module specification should have a section that defines the format of this routing metric according to the syntax defined in Section 3.2.1. The binary format of this format is returned by the getMetricFormat() function defined below. 3.2.3. Node Characteristics Format In addition to distributing routing information in terms of routing metrics associated with different destinations, a routing algorithm may also need to exchange information about its local characteristics with an encountered node. Such information could include location information, resource availability (battery level or buffer space), or any other information that the other node may possibly need to make forwarding decisions and update its routing state. Each routing algorithm module specification should have a section that defines the format of this node characteristics metric according to the syntax defined in Section 3.2.1. The binary format of this format is returned by the getNodeCharFormat() function defined below. Lindgren, et al. Expires February 1, 2014 [Page 14] Internet-Draft GORF July 2013 3.3. Module API - Functions A routing algorithm module need to define the following functions that will be called by the GORF framework: o Functions related to keeping track of routing metrics and node characteristics: * getMetricFormat() * getNodeCharFormat() * getNodeCharacteristic() o Functions related to meeting new nodes and exchanging routing information: * encounteredNode() * getRoutingState() * updateRoutingState() o Functions related to determining which bundles to exchange: * generateOffer() * generateResponse() * bundleSent() o Functions related to maintaining and using long-lived connections: * informationExchangeTimer() * newBundleArrived() * nodeDisconnected() o Functions related to buffer management: * dropAdvice() * ackReceived() Lindgren, et al. Expires February 1, 2014 [Page 15] Internet-Draft GORF July 2013 3.3.1. getMetricFormat() Input: o N/A Output: o Routing metric format string This function returns the binary represenation (as defined in Section 3.2.1.1) of the format of the routing metric as defined in Section 3.2.2 used by this routing algorithm module. 3.3.2. getNodeCharFormat() o N/A Output: o Node characteristics metric format string This function returns the binary represenation (as defined in Section 3.2.1.1) of the format of the node characteristics metric as defined in Section 3.2.3 used by this routing algorithm module. This is called by the GORF framework to insert the correct information in the Hello messages. 3.3.3. getNodeCharacteristics() o N/A Output: o Node characteristics metric string This function returns the current value of the node characteristics metric as defined in Section 3.2.3 used by this routing algorithm module. This is called by the GORF framework to insert the correct information in the Hello messages. 3.3.4. encounteredNode Input: o nodeID: node identifier of encountered node Lindgren, et al. Expires February 1, 2014 [Page 16] Internet-Draft GORF July 2013 o node characteristics: node characteristics field sent by the peering node in the Hello message o node characteristics format: (do we need to include this?) Output: o void This function is called by the GORF framework when a new node is encountered. The node identifier of the encountered node and the node characteristics metric that was sent by the other node in the Hello message is passed to the function. The function does not return any value, but may update the internal routing state. 3.3.5. getRoutingState() Input: o fromNode: node identifier of encountered node o (internal state) Output: o [(destination id, routing metric)]: list of destination id/routing metric tuples This function is called by the GORF framework whenever a routing information should be sent to a peering node. The node id of the encountered node is given to the function and it returns a list of tuples containing destination ids and the associated routing metric describing the internal routing state to be sent to the peering node. A routing algorithm may choose not to only send a subset of its routing state to the peering node based on internal state and the identity of the peering node. 3.3.6. updateRoutingState() Input: o [(destination, routing metric)]: list of destination/routing metric tuples o fromNode: node identifier of encountered node o (internal state) Lindgren, et al. Expires February 1, 2014 [Page 17] Internet-Draft GORF July 2013 Output: o void o (updated internal state) This function is called by the GORF framework during the Information Exchange Phase when the RIB with routing information has been received from the peering node. The function takes a list of tuples containing destination ids and the associated routing metric (in the format given by the current routing metric format). The function does not return anything, but uses the received information to update the internal routing state. 3.3.7. generateOffer Input: o [(destination, routing metric)]: list of destination/routing metric tuples o fromNode: node identifier of encountered node Output: o [bundle ids]: list of bundles to be offered to the peering node This function is called by the GORF framework during the Information Exchange Phase to determine which bundles should be offered to a peering node. The function takes a list of tuples containing destination ids and the associated routing metric (in the format given by the current routing metric format) and the node identifier of the peering node. The function returns a list of bundle ids that should be offered to the peering node based on the routing policy and internal state of the routing algorithm. The list should be sorted in the order that it is suggested that bundles are requested. 3.3.8. generateResponse Input: o [bundle ids]: list of bundles offered by the peering node o [(destination, routing metric)]: list of destination/routing metric tuples from peering node o fromNode: node identifier of peering node Lindgren, et al. Expires February 1, 2014 [Page 18] Internet-Draft GORF July 2013 Output: o [bundle ids]: list of bundles to be requested from the peering node This function is called by the GORF framework during the Information Exchange Phase to determine which of the offered bundles should be requested from a peering node. The function takes a list of offered bundle ids, a list of tuples containing destination ids and the associated routing metric (in the format given by the current routing metric format) from the peering node, and the node identifier of the peering node. The function returns a list of bundle ids that should be requested from the peering, sorted in the order that the bundles should be requested. 3.3.9. bundleSent() Input: o bundle id: The bundle id of the bundle sent to the peering node o toNode: node identifier of the node that the bundle was sent to Output: o void This function is called by the GORF framework when a bundle has been forwarded to another node. Routing algorithms may want to keep track of this information for future forwarding decisions. 3.3.10. getInformationExchangeTimer() Input: o N/A Output: o This function returns the value (in seconds) that should be used for the Information Exchange Timer to trigger periodic restarts of the Information Exchange Phase. If the function returns 0, this trigger will be disabled. Lindgren, et al. Expires February 1, 2014 [Page 19] Internet-Draft GORF July 2013 3.3.11. newBundleArrived() Input: o bundle id: id of new bundle o [peers]: list of currently connected peers Output: o [peers]: list of peers to offer this bundle to This function is called by the GORF framework if a new bundle arrives between two scheduled instances of the Information Exchange Phase. The function uses the internal routing state and the routing metrics received from the other peers currently connected with this node to determine if this bundle should be offered to any of the peering node. The function returns a list (possibly of length 0) of the peers that should be offered this bundle. The GORF framework then generates a BundleOffer message and sends to the corresponding nodes in order to initiate a bundle transfer. 3.3.12. nodeDisconnected() Input: o nodeID: node identifier of the disconnected node Output: o void This function is called by the GORF framework when a connection to a peering node is lost. Routing algorithm modules may use this to, for example, influence routing metrics depending on the duration of contact opportunities. 3.3.13. dropAdvice Input: o n: number of bundles to drop Output: o [bundle ids]: list of bundle ids This function is called by the GORF framework if buffer space is Lindgren, et al. Expires February 1, 2014 [Page 20] Internet-Draft GORF July 2013 limted such that some bundle must be prematurely deleted. The function takes a number as input that defines the number of bundle ids that it should return as candidates to be dropped. The function returns a list of bundle ids of bundles that may be dropped by the GORF framework, sorted in the order of preference for dropping. If the input parameter is greater than the total number of bundles, the resulting list will consist of all bundle ids. 3.3.14. ackReceived() Input: o ackList: List of bundle ids Output: o void This function is called by the GORF framework when one or more GORF ACKs are received. ackList contains a list of bundle ids for the acked bundles. The function does not return anything, but may use this information to update internal routing state. Lindgren, et al. Expires February 1, 2014 [Page 21] Internet-Draft GORF July 2013 4. Protocol Overview 4.1. Neighbor Awareness Since the operation of the protocol is dependent on the encounters of nodes running the GORF framework, the nodes must be able to detect when a new neighbor is present. The protocol may be run on several different networking technologies, and as some of them might already have methods available for detecting neighbors, the GORF framework does not include a mechanism for neighbor discovery. Instead, it requires the underlying layer to provide a mechanism to notify the protocol of when neighbors appear and disappear as described in Section 2.5. When a new neighbor has been detected, the protocol starts to set up a link with that node through the Hello message exchange as described in Section 6.2. The Hello message exchange allows for negotiation of capabilities between neighbors. At present the only generic capability is a request that the offering node should or should not include bundle payload lengths with all offered bundles rather than just for fragments. The Hello procedure is also used to exchange the format used by the current routing algorithm to describe routing metrics and destination identities (as described in Section 3.2.2). Once the link has been set up the protocol may continue to the Information Exchange Phase (see Section 4.2). This phase involves the exchange of routing metrics that the nodes use to update their internal state based on the current routing algorithm. Based on this updated state and the information received from the peering node, decisions are made on which bundles should be passed between the encountering nodes using the corresponding functions in GORF API as provided by the routing algorithm module. 4.2. Information Exchange Phase The Information Exchange Phase involves the transfer of sets of four types of information between the pair of connected nodes: o Routing Information Base Dictionary (RIB Dictionary or RIBD), o Routing Information Base (RIB), o Bundle Offers, and o Bundle Responses. During a communication opportunity several sets of each type of information may be transferred in each direction as explained in the rest of this section. Each set can be transferred in one or more Lindgren, et al. Expires February 1, 2014 [Page 22] Internet-Draft GORF July 2013 messages. When (and only when) using a connection oriented reliable transport protocol such as TCP as envisaged in this draft, a set can be be partitioned across messages by the software layer above the GORF routing framework engine. In this case the last message in a set is flagged in the protocol. This allows the higher level software to minimize the buffer memory requirements by avoiding the need to build very large messages in one go, and allows the message size to be controlled outside of the GORF routing framework. However, this scheme is only usable if the transport protocol provides reliable, in-order delivery of messages as the messages are not explicitly sequence numbered and the overall size of the set is not passed explicitly. The specification of GORF also provides a sub-message mechanism and retransmission that allows large messages specified by the higher level to be transmitted in smaller chunks. This mechanism is provided to allow GORF to operate over unreliable transport protocols such as UDP, but can also be used with reliable transports if the higher level software does not want to handle message fragmentation. However, the sequencing and length adds overhead that is redundant if the transport protocol already provides reliable, in-order delivery. The first step in the Information Exchange Phase is for the protocol to send one or more messages containing a RIB Dictionary TLV (Type- Length-Value message component) to the node it is peering with. This set of messages contain a dictionary of the Endpoint Identifiers (EIDs) of the nodes that will be listed in the Routing Information Base (RIB - see Section 4.2.1 for more information about this dictionary). After this, one or more messages containing a Routing Information Base TLV are sent. This TLV contains a list of the EIDs that the node has knowledge of, and the corresponding routing metric (as defined by the routing algorithm module) for those destinations, together with flags describing the capabilities of the sending node. Upon reception of a complete set of these messages, the peer node updates its internal routing state according to the algorithm defined by the updateRoutingState() function in the GORF API. The peer node then applies its forwarding strategy as defined in the generateOffer() function in the GORF API to determine which of its stored bundles it wishes to offer the node that sent the RIB, which will then be the receiver for any bundles to be transferred. After making this decision, one or more Bundle Offer TLVs are prepared, listing the bundle identifiers and their destinations for all bundles the peer node wishes to offer to the receiver node that sent the RIB. As described in [RFC5050], a bundle identifier consists of up to five component parts. For a complete bundle the identifier consists of Lindgren, et al. Expires February 1, 2014 [Page 23] Internet-Draft GORF July 2013 o Source EID, o Creation Timestamp - Time of creation, and o Creation Timestamp - Sequence Number. Additionally, for a bundle fragment, the identifier also contains o Offset within the payload at which the fragment payload data starts, and o Length of the fragment payload data. If any of the Bundle Offer TLVs lists a bundle for which the source or destination EID was not included in the previous set of RIB Dictionary information sent, one or more new RIBD TLVs are sent next with an incremental update of the dictionary. When the receiver node has a dictionary with all necessary EIDs, the Bundle Offer TLVs are sent to it. The Bundle Offer TLVs may also contain a list of GORF ACKs (see Section 4.4). If requested by the receiver node during the Hello phase the Bundle Offer TLV will also specify the payload length for all bundles rather than just for fragments. This information can be used by the receiving node to assist with the selection of bundles to be accepted from the offered list, especially if the available bundle storage capacity is limited. The receiving node then inputs the list of offered bundles to the generateResponse() function in the GORF API, which selects bundles that it will accept based on the routing algorithm used. The list returned by generateResponse() is sorted according to the priority order that the routing algorithm wants the bundles transferred in. The offering node SHOULD forward the selected bundles in this order. The prioritized list is sent to the offering node in one or more Bundle Response TLVs using the same EID dictionary as was used for the Bundle Offer TLV. When a new bundle arrives at a node, the node calls the newBundleArrived() function of the GORF API to inform the routing algorithm that a new bundle is available. The routing algorithm MAY inspect its list of available neighbors, and if one of them is a candidate to forward the bundle, a new Bundle Offer TLV MAY be sent to that node. If two nodes remain connected over a longer period of time, the Information Exchange Phase will be periodically re- initiated when the next_exchange timer expires to allow new routing metric information to be spread through the network and new bundle exchanges to take place. The Information Exchange phase of the protocol is described in more Lindgren, et al. Expires February 1, 2014 [Page 24] Internet-Draft GORF July 2013 detail in Section 6.3. 4.2.1. Routing Information Base Dictionary To reduce the overhead of the protocol, the Routing Information Base and Bundle Offer/Response TLVs utilize an EID dictionary. This dictionary maps variable length EIDs as defined in [RFC4838], which may potentially be quite long, to shorter numerical identifiers, coded as Self-Delimiting Numeric Values (SDNVs - see Section 4.1. of RFC 5050 [RFC5050]),that are used in place of the EIDs in subsequent TLVs. This dictionary is a shared resource between the two peering nodes. Each can add to the dictionary by sending a RIB Dictionary TLV to its peer. To allow either node to add to the dictionary at any time, the identifiers used by each node are taken from disjoint sets: identifiers originated by the node that started the Hello procedure have the least significant bit set to 0 (i.e., are even numbers) whereas those originated by the other peer have the least significant bit set to 1 (i.e., are odd numbers). This means that the dictionary can be expanded by either node at any point in the information exchange phase and the new identifiers can then be used in subsequent TLVs until the dictionary is reinitialized. The dictionary that is established only persists through a single encounter with a node (i.e., while the same link set up by the Hello procedure, with the same instance numbers, remains open). Having more then one identifier for the same EID does not cause any problems. This means that it is possible for the peers to create their dictionary entries independently if required by an implementation, but this may be inefficient as a dictionary entry for an EID might be sent in both directions between the peers. Implementers can choose to inspect entries sent by the node that started the Hello procedure and thereby eliminate any duplicates before sending the dictionary entries from the other peer. Whether postponing sending the other peer's entries is more efficient depends on the nature of the physical link technology and the transport protocol used. With a genuinely full duplex link it may be faster to accept possible duplication and send dictionary entries concurrently in both directions. If the link is effectively half-duplex (e.g., Wi-Fi), then it will generally be more efficient to wait and eliminate duplicates. If a node receives a RIB Dictionary TLV containing an identifier that is already in use, the node MUST confirm that the EID referred to is identical to the EID in the existing entry. Otherwise the node must send an error response to the message with the TLV containing the Lindgren, et al. Expires February 1, 2014 [Page 25] Internet-Draft GORF July 2013 error and ignore the TLV containing the error. If a node receives a RIB, Bundle Offer or Bundle Response TLV that uses an identifier that is not in its dictionary, the node MUST send an error response and ignore the TLV containing the error. 4.2.2. Handling Multiple Simultaneous Contacts From time to time a mobile node may, for example, be in wireless range of more than one other mobile node. The GORF neighbor awareness protocol will establish multiple simultaneous contacts with these nodes and commence information exchanges with each of them. If these simultaneous contacts persist for some time, then, as described in Section 4.2, the information exchange process will be periodically rerun for each contact according to the configured timer interval as given by the function informationExchangeTimer() in the GORF API (if a routing module chooses to have this function return 0, this means that the periodic reinitiation of the information exchange will be disabled). The interval between reruns of the information exchange will be set depending on the characteristics and behaviour of the routing algorithm defined by the current routing module, but will generally be set to a small fraction of the expected time between independent encounters of pairs of nodes. 4.3. Bundle Passing Upon reception of the Bundle Offer TLV, the list of offered bundles is sent to the routing algorithm module through a call to the generateRequest() function in the GORF API. This function inspects the list of bundles and decides (based on the routing algorithm) which bundles it is willing to store for future forwarding, or that it is able to deliver to their destination. The function will generate a Bundle Response TLV with a list of requested bundles that is then sent by the GORF framework to its peering node, which in response to that sends the requested bundle(s). If a node has some bundles it would prefer to receive ahead of others offered (e.g., bundles that it can deliver to their final destination), it MAY request the bundles in that priority order. This is often desirable as there is no guarantee that the nodes will remain in contact with each other for long enough to transfer all the acceptable bundles. Otherwise, the node SHOULD assume that the bundles are listed in a priority order determined by the peering node's forwarding strategy, and request bundles in that order. 4.4. When a Bundle Reaches its Destination When a bundle reaches its destination within the GORF zone (i.e., within the part of the network where the GORF based routing protocol Lindgren, et al. Expires February 1, 2014 [Page 26] Internet-Draft GORF July 2013 is used for routing; not necessarily the final destination of the bundle), a GORF ACK for that bundle is issued. A GORF ACK is a confirmation that a bundle has been delivered to its destination in the GORF zone (bundles might traverse several different types of networks using different routing protocols; thus, this might not be the final destination of the bundle). When nodes exchange Bundle Offer TLVs, bundles that have been ACKed are also listed, having the "GORF ACK" flag set. The node that receives this list updates its own list of ACKed bundles to be the union of its previous list and the received list. To prevent the list of ACKed bundles growing indefinitely, each GORF ACK should have a timeout that MUST NOT be longer than the timeout of the bundle to which the ACK corresponds. When a node receives a GORF ACK for a bundle it is carrying, it MAY delete that bundle from its storage, unless the node holds custody of that bundle. The GORF ACK only indicates that a bundle has been delivered to its destination within the GORF zone, so the reception of a GORF ACK is not a guarantee that the bundle has been delivered to its final destination. The GORF framework will also call the ackReceived() function in the GORF API to inform the routing module that an ACK has been received for this bundle. Nodes MAY keep track of which nodes they have sent GORF ACKs for certain bundles to, and MAY in that case refrain from sending multiple GORF ACKs for the same bundle to the same node. If necessary in order to preserve system resources, nodes MAY drop GORF ACKs prematurely, but SHOULD refrain from doing so if possible. It is important to keep in mind that GORF ACKs and bundle ACKs[RFC5050] are different things. GORF ACKs are only valid within the GORF part of the network, while bundle ACKs are end-to-end acknowledgments that may go outside of the GORF zone. Lindgren, et al. Expires February 1, 2014 [Page 27] Internet-Draft GORF July 2013 5. Message Formats This section defines the message formats of the GORF routing protocol framework. In order to allow for variable length fields, many numeric fields are encoded as Self-Delimiting Numeric Values (SDNVs). The format of SDNVs is defined in [RFC5050]. Furthermore, certain fields describing routing metrics or node characteristics are encoded according to the routing metric encoding format defined in Section 3.2.2. Since many of the fields are coded as SDNVs or in the routing algorithm dependent metric format, the size and alignment of fields indicated in many of the specification diagrams below are indicative rather than prescriptive. Where SDNVs and/or text strings are used, the octets of the fields will be packed as closely as possible with no intervening padding between fields. Explicit length fields are specified for all variable length string fields. Accordingly, strings are not null-terminated and just contain the exact set of octets in the string. The basic message format shown in Figure 1 consists of a header (see Section 5.1) followed by a sequence of one or more Type-Length-Value components (TLVs) taken from the specifications in Section 5.2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV 1 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | ~ . ~ | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV n ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Basic GORF Message Format Lindgren, et al. Expires February 1, 2014 [Page 28] Internet-Draft GORF July 2013 5.1. Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Protocol Number|Version| Flags | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Algorithm Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Instance | Sender Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| SubMessage Number | Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Message Body ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: GORF Message Header Protocol Number The DTN Routing Protocol Number encoded as 8 bit unsigned integer in network bit order. The value of this field is 0x01. The GORF header is organized in this way so that in principle GORF messages could be sent as the Protocol Data Unit of an IP packet if an IP protocol number was allocated for GORF. At present GORF is only specified to use a TCP transport for carriage of GORF packets so that the protocol number serves only to identify the GORF protocol within DTN. Version The Version of the GORF Protocol. Encoded as a four bit unsigned integer in network bit order. This document defines version 2. Flags Reserved field of 4 bits. Result Field that is used to indicate whether a response is required to the request message if the outcome is successful. A value of "NoSuccessAck" indicates that the request message does not expect a response if the outcome is successful, and a value of "AckAll" indicates that a response is expected if the outcome is successful. In both cases a failure response MUST be generated if the request fails. If running over a TCP transport or Lindgren, et al. Expires February 1, 2014 [Page 29] Internet-Draft GORF July 2013 similar protocol that offers reliable in order delivery, deployments MAY choose not to send "Success" responses when an outcome is successful. To achieve this the Result field is set to the "NoSuccessAck" value in all request messages. In a response message, the result field can have two values: "Success," and "Failure". The "Success" results indicates a success response. All messages that belong to the same success response will have the same Transaction Identifier. The "Success" result indicates a success response that may be contained in a single message or the final message of a success response spanning multiple messages. ReturnReceipt is a value of the result field used to indicate that an acknowledgement is required for the message. The default for Messages is that the controller will not acknowledge responses. In the case where an acknowledgement is required, it will set the Result Field to ReturnReceipt in the header of the Message. The result field is encoded as an 8 bit unsigned integer in network bit order. The following values are currently defined: NoSuccessAck: Result = 1 AckAll: Result = 2 Success: Result = 3 Failure: Result = 4 ReturnReceipt Result = 5 Code This field gives further information concerning the result in a response message. It is mostly used to pass an error code in a failure response but can also be used to give further information in a success response message or an event message. In a request message, the code field is not used and is set to zero. If the Code field indicates that the Error TLV is included in the message, further information on the error will be found in the Error TLV, which MUST be the the first TLV after the header. The Code field is encoded as an 8 bit unsigned integer in network bit order. Separate number code spaces are used for success and failure response messages. In each case a range of values is provided reserved for use in specifications and another range for private and experimental use. For success messages the following values are defined: Lindgren, et al. Expires February 1, 2014 [Page 30] Internet-Draft GORF July 2013 Generic Success 0x00 Submessage Received 0x01 Reserved 0x02 - 0x7F Private/Experimental Use 0x80 - 0xFF The Submessage Received code is used to acknowledge reception of a message segment. The Generic Success code is used to acknowledge receipt of a complete message and successful processing of the contents. For failure messages, the following values are defined: Reserved 0x00 - 0x01 Unspecified Failure 0x02 Reserved 0x03 - 0x7F Private/Experimental Use 0x80 - 0xFE Error TLV in message 0xFF The Unspecified Failure code can be used to report a failure for which there is no more specific code or Error TLV value defined. Routing Algorithm Identifier The Routing Algorithm Identifier specifies which routing algorithm module specification is to be used to define the functions outlined in Section 3.3 that will be called by the GORF API to implement the specific routing algorithm functionality. The encoding of the Routing Algorithm Identifier field is: +------------------+-------------+----------------------------------+ | Routing | Value | Reference | | Algorithm | | | +------------------+-------------+----------------------------------+ | Reserved (do not | 0x0000 | This document | | allocate) | | | | | | | | Epidemic Routing | 0x0001 | draft-lindgren-dtnrg-gorf-epidem | | | | i c-00 | | | | | | PRoPHETv2 | 0x0002 | draft-lindgren-dtnrg-gorf-prophe | | | | t -00 | | | | | | dLife? | 0x0003 | draft-mendes-dtnrg-gorf-dlife-00 | | | | ?? | | | | | | Reserved | 0x0004-0xFF | Specification required | | | E F | | Lindgren, et al. Expires February 1, 2014 [Page 31] Internet-Draft GORF July 2013 | Private/Experime | 0xFFF0-0xFF | Experimental | | n tal use | F E | | +------------------+-------------+----------------------------------+ Sender Instance For messages during the Hello phase with the Hello SYN, Hello SYNACK, and Hello ACK functions (which are explained in Section 6.2), it is the sender's instance number for the link. It is used to detect when the link comes back up after going down or when the identity of the entity at the other end of the link changes. The instance number is a 16-bit number that is guaranteed to be unique within the recent past and to change when the link or node comes back up after going down. Zero is not a valid instance number. For the RSTACK function (also explained in detail in Section 6.2), the Sender Instance field is set to the value of the Receiver Instance field from the incoming message that caused the RSTACK function to be generated. Messages sent after the Hello phase is completed should use the sender's instance number for the link. The Sender Instance is encoded as a 16 bit unsigned integer in network bit order. Receiver Instance For messages during the Hello phase with the Hello SYN, Hello SYNACK, and Hello ACK functions, is what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. If the sender of the message does not know the current instance number at the far end of the link, this field MUST be set to zero. For the RSTACK message, the Receiver Instance field is set to the value of the Sender Instance field from the incoming message that caused the RSTACK message to be generated. Messages sent after the Hello phase is completed should use what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. The Sender Instance is encoded as a 16 bit unsigned integer in network bit order. Transaction Identifier Used to associate a message with its response message. This should be set in request messages to a value that is unique for the sending host within the recent past. Reply messages contain the Transaction Identifier of the request they are responding to. The Transaction Identifier is a 32 bit bit pattern. S-flag If S is set (value 1) then the SubMessage Number field indicates the total number of SubMessage segments that compose the entire message. If it is not set (value 0) then the SubMessage Number Lindgren, et al. Expires February 1, 2014 [Page 32] Internet-Draft GORF July 2013 field indicates the sequence number of this SubMessage segment within the whole message. the S field will only be set in the first sub-message of a sequence. SubMessage Number When a message is segmented because it exceeds the MTU of the link layer or otherwise, each segment will include a SubMessage Number to indicate its position. Alternatively, if it is the first sub-message in a sequence of sub-messages, the S flag will be set and this field will contain the total count of SubMessage segments. The SubMessage Number is encoded as a 15-bit unsigned integer in network bit order. The SubMessage number is zero- based, i.e., for a message divided into n sub-messages, they are numbered from 0 to (n - 1). For a message that it is not divided into sub-messages the single message has the S-flag cleared (0) and the SubMessage Number is set to 0 (zero). Length Length in octets of this message including headers and message body. If the message is fragmented, this field contains the length of this SubMessage. The Length is encoded as an SDNV. Message Body As specified in Section 5, the Message Body consists of a sequence of one or more of the TLVs specified in Section 5.2. The protocol also requires extra information about the link that the underlying communication layer MUST provide. This information is used in the Hello procedure described in more detail in Section 6.2. Since this information is available from the underlying layer, there is no need to carry it in GORF messages. The following values are defined to be provided by the underlying layer: Sender Local Address An address used by the underlying communication layer as described in Section 2.5 that identifies the sender address of the current message. This address must be unique among the nodes that can currently communicate, and is only used in conjunction with the Receiver Local Address and the Receiver Instance and Sender Instance to identify a communicating pair of nodes. Receiver Local Address An address used by the underlying communication layer as described in Section 2.5 that identifies the receiver address of the current message. This address must be unique among the nodes that can currently communicate, and is only used in conjunction with the Sender Local Address and the Receiver Lindgren, et al. Expires February 1, 2014 [Page 33] Internet-Draft GORF July 2013 Instance and Sender Instance to identify a communicating pair of nodes. When GORF is run over TCP, the IP addresses of the communicating nodes are used as Sender and Receiver Local Addresses. 5.2. TLV Structure All TLVs have the following format, and can be nested. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Flags | TLV Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: TLV Format TLV Type Specific TLVs are defined in Section 5.3. The TLV Type is encoded as an 8 bit unsigned integer in network bit order. Each TLV will have fields defined that are specific to the function of that TLV. TLV Flags These are defined per TLV type. Flag n corresponds to bit 15-n in the TLV. Any flags which are specified as reserved in specific TLVs SHOULD be transmitted as 0 and ignored on receipt. TLV Length Length of the TLV in octets, including the TLV header and any nested TLVs. Encoded as an SDNV. Note that TLVs are not padded to any specific alignment unless explicitly required in the description of the TLV. No TLVs in this document specify any padding. 5.3. TLVs This section describes the various TLVs that can be used in GORF messages. Lindgren, et al. Expires February 1, 2014 [Page 34] Internet-Draft GORF July 2013 5.3.1. Hello TLV The Hello TLV is used to set up and maintain a link between two GORF nodes. Hello messages with the SYN function are transmitted periodically as beacons or keep alives. The Hello TLV is the first TLV exchanged between two GORF nodes when they encounter each other. No other TLVs can be exchanged until the first Hello sequence is completed. Once a communication link is established between two GORF nodes, the Hello TLV will be sent once for each interval as defined in the interval timer. If a node experiences the lapse of HELLO_DEAD Hello intervals without receiving a Hello TLV on a connection in the INFO_EXCH state (as defined in the state machine in Section 6.1), the connection SHOULD be assumed broken. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type=0x01 |L| Resv | HF | TLV Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timer (SDNV) |EID Length,SDNV| Sender EID (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Characteristics Format (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node Characteristics (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Hello TLV Format TLV Flags The TLV Flags field contains two single bit flags (S and L) and a three bit Hello Function (HF) number that specifies one of four functions for the Hello TLV. The remaining three bits (Resv) are unused and reserved: HF TLV Flags bits 0, 1, and 2 are treated as an unsigned 3 bit integer coded in network bit order. The value of the integer specifies the Hello Function (HF) of the Hello TLV. Four functions are specified for the Hello TLV. The encoding of the Hello Function is: SYN: HF = 1 SYNACK: HF = 2 ACK: HF = 3 RSTACK: HF = 4 Lindgren, et al. Expires February 1, 2014 [Page 35] Internet-Draft GORF July 2013 The remaining values (0, 5, 6 and 7) are unused and reserved. If a Hello TLV with any of these values is received, the link should be reset. Resv TLV Flags bits 3, 4, 5, and 6 are reserved. They SHOULD be set to 0 on transmission and ignored on reception. L The L bit flag (TLV Flags bit 7) is set (1) to request that the Bundle Offer TLV sent during the Information Exchange phase contains bundle payload lengths for all bundles, rather than only for bundle fragments if the L flag is cleared (0), when carried in a Hello TLV with Hello Function SYN or SYNACK. The flag is ignored for other Hello Function values. TLV Data Timer The Timer field is used to inform the receiver of the timer value used in the Hello processing of the sender. The timer specifies the nominal time between periodic Hello messages. It is a constant for the duration of a session. The timer field is specified in units of 100ms and is encoded as an SDNV. EID Length The EID Length field is used to specify the length of the Sender EID field in octets. If the Endpoint Identifier (EID) has already been sent at least once in a message with the current Sender Instance, a node MAY choose to set this field to zero, omitting the Sender EID from the Hello TLV. The EID Length is encoded as an SDNV and the field is thus of variable length. Sender EID The Sender EID field specifies the DTN endpoint identifier (EID) of the sender that is to be used in updating routing information and making forwarding decisions. If a node has multiple EIDs, one should be chosen for GORF routing. This field is of variable length. Lindgren, et al. Expires February 1, 2014 [Page 36] Internet-Draft GORF July 2013 Node Characteristics Format The Node Characteristics Format field specifies the format used to describe the node characteristics of the node. The field is in the binary octet sequence representation of this format as described in Section 3.2.1.1. The GORF framework will call the getNodeCharFormat() function described in Section 3.3.2 to get this value. Node Characteristics The Node Characteristics field contains the value of the node characteristics that should be sent to the peering node. The content of this field is formatted according to the format given in the previous field. The GORF framework will call the getNodeCharacteristics() function in the GORF API described in Section 3.3.3 to get this value. 5.3.2. Error TLV 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV type=0x02 | TLV Flags | TLV Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Error TLV Format TLV Flags For Error TLVs the TLV Flags field carries an identifier for the Error TLV type as an 8 bit unsigned integer encoded in network bit order. A range of values is available for private and experimental use in addition to the values defined here. The following Error TLV types are defined: Dictionary Conflict 0x00 Bad String ID 0x01 Reserved 0x02 - 0x7F Private/Experimental Use 0x80 - 0xFF TLV Data The contents and interpretation of the TLV Data field are specific to the type of Error TLV. For the Error TLVs defined in this document the TLV Data is defined as follows: Lindgren, et al. Expires February 1, 2014 [Page 37] Internet-Draft GORF July 2013 Dictionary Conflict The TLV Data consists of the String ID causing the conflict encoded as an SDNV followed by the Endpoint Identifier string that conflicts with the previously installed value. The Endpoint Identifier is NOT null terminated. The length of the Endpoint Identifier can be determined by subtracting the length of the TLV Header and the length of the SDNV containing the String ID. Bad String ID The TLV Data consists of the String ID that is not found in the dictionary encoded as an SDNV. Lindgren, et al. Expires February 1, 2014 [Page 38] Internet-Draft GORF July 2013 5.3.3. Routing Information Base Dictionary TLV The Routing Information Base Dictionary includes the list of endpoint identifiers used in making routing decisions. The referents remain constant for the duration of a session over a link where the instance numbers remain the same and can be used by both the Routing Information Base messages and the bundle offer/response messages. The dictionary is a shared resource (see Section 4.2.1) built in each of the paired peers from the contents of one or more incoming TLVs of this type and the information used to create outgoing TLVs of this type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV type=0xA0 | TLV Flags | TLV Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIBD Entry Count (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ Variable Length Routing Address Strings ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Routing Address String 1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ID 1 (SDNV) | Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Endpoint Identifier 1 (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | ~ Routing Address String n . ~ | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ID n (SDNV) | Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Endpoint Identifier n (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Routing Information Base Dictionary TLV Format Lindgren, et al. Expires February 1, 2014 [Page 39] Internet-Draft GORF July 2013 TLV Flags The encoding of the Header flag field relates to the capabilities of the Source node sending the RIB Dictionary: Flag 0: Sent by Listener 0b1 Flag 1: Reserved 0b1 Flag 2: Reserved 0b1 Flag 3: Reserved 0b1 Flag 4: Reserved 0b1 Flag 5: Reserved 0b1 Flag 6: Reserved 0b1 Flag 7: Reserved 0b1 The Sent by Listener flag is set to 0 if this TLV was sent by a node in the Initiator role and set to 1 if this TLV was sent by a node in the Listener role (see Section 4.2 for explanations of these roles). TLV Data RIBD Entry Count Number of entries in the database. Encoded as SDNV. String ID SDNV identifier that is constant for the duration of a session. String ID zero is predefined as the node initiating the session through sending the Hello SYN message, and String ID one is predefined as the node responding with the Hello SYNACK message. These entries do not need to be sent explicitly as the EIDs are exchanged during the Hello procedure. In order to ensure that the String IDs originated by the two peers do not conflict, the String IDs generated in the node that sent the Hello SYN message MUST have their least significant bit set to 0 (i.e., are even numbers) and the String IDs generated in the node that responded with the Hello SYNACK message MUST have their least significant bit set to 1 (i.e., they are odd numbers). Length Length of Endpoint Identifier in this entry. Encoded as SDNV. Endpoint Identifier Text string representing the Endpoint Identifier. Note that it is NOT null terminated as the entry contains the length of the identifier. Lindgren, et al. Expires February 1, 2014 [Page 40] Internet-Draft GORF July 2013 5.3.4. Routing Information Base TLV The Routing Information Base lists the destinations (endpoints) a node knows of, and the routing metrics it has associated with them. This information is needed by the GORF framework and its routing algorithm modules to make decisions on routing and forwarding. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type=0xA1 | TLV Flags | TLV Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Metric Format (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIB String Count (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIBD String ID 1 (SDNV) | Routing metric (var length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIB Flags 1 | . ~ +-+-+-+-+-+-+-+-+ . ~ ~ . ~ ~ . ~ ~ . ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIBD String ID n (SDNV) | P-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIB Flags n | +-+-+-+-+-+-+-+-+ Figure 7: Routing Information Base TLV Format TLV Flags The encoding of the Header flag field relates to the capabilities of the Source node sending the RIB: Flag 0: More RIB TLVs 0b1 Flag 1: Reserved 0b1 Flag 2: Reserved 0b1 Flag 3: Reserved 0b1 Flag 4: Reserved 0b1 Flag 5: Reserved 0b1 Flag 6: Reserved 0b1 Flag 7: Reserved 0b1 Lindgren, et al. Expires February 1, 2014 [Page 41] Internet-Draft GORF July 2013 The "More RIB TLVs" flag is set to 1 if the RIB requires more TLVs to be sent in order to be fully transferred. This flag is set to 0 if this is the final TLV of this RIB. TLV Data Routing Metric Format The Routing Metric Format field specifies the format used to describe the routing metrics in the rest of this TLV. The field is in the binary octet sequence representation of this format as described in Section 3.2.1.1. The GORF framework will call the getMetricFormat() function described in Section 3.3.1 to get this value. RIB String Count Number of routing entries in the TLV. Encoded as SDNV. RIBD String ID String ID of the endpoint identifier of the destination for which this entry specifies the routing metric as predefined in a dictionary TLV. Encoded as SDNV. Routing metric Variable length field containing the value of the routing metric for the destination of this entry in the format give in the Routing Metric Format field. The GORF framework will call the getRoutingState() function in the GORF API described in Section 3.3.5 to get the list of routing metrics used to populate this field. RIB Flag The encoding of the 8 bit RIB Flag field is: Flag 0: Reserved 0b1 Flag 1: Reserved 0b1 Flag 2: Reserved 0b1 Flag 3: Reserved 0b1 Flag 4: Reserved 0b1 Flag 5: Reserved 0b1 Flag 6: Reserved 0b1 Flag 7: Reserved 0b1 5.3.5. Bundle Offer and Response TLVs After the routing information has been passed, the node will ask the other node to review available bundles and determine which bundles it will accept for relay based on the routing algorihm module in use. The source relay will determine which bundles to offer based on the Lindgren, et al. Expires February 1, 2014 [Page 42] Internet-Draft GORF July 2013 generateOffer() function in the GORF API. Depending on the bundles stored in the offering node, the Bundle Offer TLV might contain descriptions of both complete bundles and bundle fragments. In order to correctly identify bundle fragments, a bundle fragment descriptor MUST contain the offset of the payload fragment in the bundle payload and the length of the payload fragment. If requested by the receiving node by setting the L flag in the SYN or SYNACK message during the neighbor awareness phase, the offering node MUST include the length of the payload in the descriptor for complete bundles. The appropriate flags MUST be set in the B_flags for the descriptor to indicate if the descriptor contains the payload length field (set for fragments in all cases and for complete bundles if the L flag was set) and if the descriptor contains a payload offset field (fragments only). The Bundle Offer TLV also lists the bundles that a GORF acknowledgement has been issued for. Those bundles have the GORF ACK flag set in their entry in the list. When a node receives a GORF ACK for a bundle, it SHOULD, if possible, signal to the bundle agent that this bundle is no longer required for transmission by the GORF framework, and it MUST call the ackReceived() function in the GORF API. Even if the bundle is deleted, the node SHOULD keep an entry of the acknowledged bundle to be able to further propagate the GORF ACK. The Response TLV format is identical to the Offer TLV with the exception of the TLV Type field. Bundles that are being accepted from the corresponding Offer are explicitly marked with a B_flag. Specifications for bundles that are not being accepted MAY either be omitted or left in but not marked as accepted. The payload length field MAY be omitted for complete bundles in the Response message even if it was included in the Offer message. The B_flags payload length flag MUST be set correctly to indicate if the length field is included or not. The Response message MUST include both payload offset and payload length fields for bundle fragments, and the B_flags MUST be set to indicate that both are present. Lindgren, et al. Expires February 1, 2014 [Page 43] Internet-Draft GORF July 2013 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Flags | TLV Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle Offer Count (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B_flags | Bundle Source | Bundle Destination | | | String Id 1 (SDNV) | String Id 1 (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle 1 Creation Timestamp Time | | (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle 1 Creation Timestamp Sequence Number | | (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle 1 Payload Offset - only present if bundle is a fragment| | (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle 1 Payload Length - only present if bundle is a fragment| | or transmission of length requested (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ . ~ ~ . ~ ~ . ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B_flags | Bundle Source | Bundle Destination | | | String Id n (SDNV) | String Id n (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle n Creation Timestamp Time | | (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle n Creation Timestamp Sequence Number | | (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle n Payload Offset - only present if bundle is a fragment| | (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bundle n Payload Length - only present if bundle is a fragment| | or transmission of length requested (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Bundle Offer and Response TLV Format Lindgren, et al. Expires February 1, 2014 [Page 44] Internet-Draft GORF July 2013 TLV Type The TLV Type for a Bundle Offer is 0xA4. The TLV Type for a Bundle Response is 0xA5. TLV Flags The encoding of the Header flag field relates to the capabilities of the Source node sending the RIB: Flag 0: More Offer/Response TLVs Following 0b1 Flag 1: Reserved 0b1 Flag 2: Reserved 0b1 Flag 3: Reserved 0b1 Flag 4: Reserved 0b1 Flag 5: Reserved 0b1 Flag 6: Reserved 0b1 Flag 7: Reserved 0b1 If the Bundle Offers or Bundle Responses are divided between several TLVs, the More Offer/Response TLVs Following flag MUST be set to 1 in all but the last TLV in the sequence where it MUST be set to 0. TLV Data Bundle Offer Count Number of bundle offer/response entries. Encoded as an SDNV. Note that 0 is an acceptable value. In particular a Bundle Response TLV with 0 entries is used to signal that a cycle of information exchange and bundle passing is completed. B-Flags The encoding of the B_Flags is: Flag 0: Bundle Accepted 0b1 Flag 1: Bundle is a Fragment 0b1 Flag 2: Bundle Payload Length included in TLV 0b1 Flag 3: Reserved 0b1 Flag 4: Reserved 0b1 Flag 5: Reserved 0b1 Flag 6: Reserved 0b1 Flag 7: GORF ACK 0b1 Lindgren, et al. Expires February 1, 2014 [Page 45] Internet-Draft GORF July 2013 Bundle Source String Id String ID of the source EID of the bundle as predefined in a dictionary TLV. Encoded as an SDNV. Bundle Destination String Id String ID of the destination EID of the bundle as predefined in a dictionary TLV. Encoded as an SDNV. Bundle Creation Timestamp Time Time component of the Bundle Creation Timestamp for the bundle. Encoded as an SDNV. Bundle Creation Timestamp Sequence Number Sequence Number component of the Bundle Creation Timestamp for the bundle. Encoded as an SDNV. Bundle Payload Offset Only included if the bundle is a fragment and the fragment bit is set (value 1) in the bundle B_flags. Offset of the start of the fragment payload in the complete bundle payload. Encoded as an SDNV. Bundle Payload Length Only included if the bundle length included bit is set (value 1) in the bundle B_flags. Length of the payload in the bundle specified. This is either the total payload length if the bundle is a complete bundle or the bundle fragment payload length if the bundle is a fragment. Encoded as an SDNV. Lindgren, et al. Expires February 1, 2014 [Page 46] Internet-Draft GORF July 2013 6. Detailed Operation In this section, some more details on the operation of GORF are given along with state tables to help in implementing the framework. (*** The state tables need to be updated further so that all calls to the functions in the GORF API are included here. ***) As explained in Section 1.2. it is RECOMMENDED that "Success" responses should not be requested or sent when operating over a reliable, in order transport protocol such as TCP. If GORF is operated over an unreliable transport protocol, positive acknowledgements would be necessary to signal successful delivery of (sub)messages. In this section the phrase "send a message" should be read as *successful* sending of a message, signaled by receipt of the appropriate "Success" response if running over an unreliable protocol, but guaranteed by TCP or other reliable protocol otherwise. Hence the state descriptions below do not explicitly mention positive acknowledgements, whether they are being sent or not. 6.1. High Level State Tables This section gives high level state tables for the operation of the GORF framework. The following sections will describe each part of the operation in more detail (including state tables for the internal states of those procedures). The following main or high level states are used in the state tables: WAIT_NB This is the state all nodes start in. Nodes remain in this state until they are notified that a new neighbor is available. At that point, the hello procedure should be started with the new neighbor, and the node transitions into the HELLO state. Nodes SHOULD be able to handle multiple neighbors in parallel, maintaining separate state machines for each neighbor. This could be handled by creating a new thread or process during the transition to the HELLO state that then takes care of the communication with the new neighbor while the parent remains in state WAIT_NB waiting for additional neighbors to communicate. In this case when the neighbor can no longer be communicated with (described as 'neighbor gone' in the tables below), the thread or process created is destroyed and, when a connection oriented protocol is being used to communicate with the neighbor, the connection is closed. The current version of the protocol is specified to use TCP for neighbor connections so that these will be closed when the neighbor is no longer accessible. Lindgren, et al. Expires February 1, 2014 [Page 47] Internet-Draft GORF July 2013 HELLO Nodes are in the HELLO state from when a new neighbor is detected until the Hello procedure is completed and a link is established (which happens when the Hello procedure enters the ESTAB state as described in Section 6.2 - during this procedure, the states ESTAB, SYNSENT, and SYNRCVD will be used, but these are internal to the Hello procedure and are not listed here). If the node is notified that the neighbor is no longer in range before a link has been established, it returns to the WAIT_NB state and, if appropriate, any additional process or thread created to handle the neighbor MAY be destroyed. INFO_EXCH After a link has been set up by the Hello procedure, the node transitions to the INFO_EXCH state in which the information exchange and bundle passing are done. The node remains in this state as long as Information Exchange Phase TLVs (Routing RIB, Routing RIB Dictionary) and bundle passing TLVs (Bundle Offer, Bundle Response) are being received. If the node is notified that the neighbor is no longer in range before all information and bundles have been exchanged, any associated connection is closed and the node returns to the WAIT_NB state to await new neighbors. In the INFO_EXCH state the nodes at both ends of the established link are able to update their internal routing state as routing information from the peering node is sent to the updateRoutingState() function of the GORF API. The nodes can then make offers of bundles for exchange (using the generateOffer() function) which may be accepted or not by the peer. To manage these processes, each node acts both as an Initiator and a Listener for the information exchange and bundle passing processes, maintaining subsidiary state machines for the two roles. The Initiator and Listener terms refer to the sending of the Routing RIB information: it is perhaps counterintuitive that the Listener becomes the bundle offeror and the Initiator the bundle acceptor during the bundling passing part. The protocol is designed so that the two exchanges MAY be carried out independently but concurrently with the messages multiplexed onto on a single bidirectional link (such as is provided by the TCP connection). Alternatively, the exchanges MAY be carried out partially or wholly sequentially if appropriate for the implementation. The information exchange process is explained in more detail in Section 4.2 Lindgren, et al. Expires February 1, 2014 [Page 48] Internet-Draft GORF July 2013 When an empty Bundle Response TLV (i.e., no more bundles to send) is received, the node starts the next_exchange timer based on the getInformationExchangeTimer() function in the GORF API. If this function returns 0, the timer is not started. When this timer expires, assuming that the neighbor is still connected, the Initiator reruns the information exchange process. If there is only one neighbor connected at this time, this may change the internal routing state of the routing module (depending on the routing algorithm). If there is more than one neighbor connected or other communication opportunities have happened since the previous information exchange occurred, then the changes resulting from these other encounters will be passed on to the connected neighbor. The next_exchange timer is restarted once the information exchange has completed again. If one or more new bundles are receieved by this node (either from a peering node or from an application running on this node) while waiting for the next_exchange timer to expire, the GORF framework will call the newBundleArrived() function in the GORF API. The routing algorithm module will use its internal state and the bundle id of the new bundle to determine if it would be appropriate to forward the new bundle to a connected node. If so, the new bundle(s) SHOULD be immediately offered to the connected neighbor and transferred if accepted. State: WAIT_NB +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | New Neighbor | Start Hello procedure for neighbor| HELLO | | | Call encounteredNode() in GORF API| | | | Keep waiting for more neighbors | WAIT_NB | +==================================================================+ Lindgren, et al. Expires February 1, 2014 [Page 49] Internet-Draft GORF July 2013 State: HELLO +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | Hello TLV rcvd | | HELLO | +------------------+-----------------------------------+-----------+ | Enter ESTAB state| Start Information Exchange Phase | INFO_EXCH | +------------------+-----------------------------------+-----------+ | Neighbor Gone | | WAIT_NB | +==================================================================+ State: INFO_EXCH +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | On entry | Start keep alive timer | | | | Uses Hello Timer interval | INFO_EXCH | +------------------+-----------------------------------+-----------+ |Info Exch TLV rcvd| (processed by subsidiary state | | | | machines) | INFO_EXCH | +------------------+-----------------------------------+-----------+ | No more bundles | Start next_exchange timer | INFO_EXCH | +------------------+-----------------------------------+-----------+ | Keep Alive expiry| Send Hello SYN message | INFO_EXCH | +------------------+-----------------------------------+-----------+ | Hello SYN rcvd | Record reception, restart timer | INFO_EXCH | +------------------+-----------------------------------+-----------+ | Neighbor Gone | | WAIT_NB | +==================================================================+ The Keep Alive messages (messages with Hello SYN TLV) are processed by the high level state machine in the INFO_EXCH state. All other messages are delegated to the subsidiary state machines of the information exchange phase described in Section 6.3. The receipt of Keep Alive messages is recorded and may be used by the subsidiary machines to check if the peer is still functioning. The connection will be aborted as described in Section 5.3.1 if several Keep Alive messages are not received. Lindgren, et al. Expires February 1, 2014 [Page 50] Internet-Draft GORF July 2013 6.2. Hello Procedure The hello procedure is described by the following rules and state tables. In this section the messages sent consist of the GORF header (see Figure 1 and a single Hello TLV (see Section 5.3.1) with the HF (Hello Function) field set to the specified value (SYN, SYNACK, ACK or RSTACK). The state of the L flag in the latest SYN or SYNACK message is recorded in the node that receives the message If the L flag is set (1) the receiving node MUST send the payload length for exch bundle that it offers to the peer during the information exchange phase. The rules and state tables use the following operations: o The "Update Peer Verifier" operation is defined as storing the values of the Sender Instance and Sender Local Address fields from a Hello SYN or Hello SYNACK function message received from the entity at the far end of the link. o The procedure "Reset the link" is defined as: When using TCP or other reliable connection-oriented transport: Close the connection and terminate any separate thread or process managing the connection. Otherwise: 1. Generate a new instance number for the link. 2. Delete the peer verifier (set to zero the values of Sender Instance and Sender Local Address previously stored by the Update Peer Verifier operation). 3. Send a SYN message. 4. Transition to the SYNSENT state. o The state tables use the following Boolean terms and operators: A The Sender Instance in the incoming message matches the value stored from a previous message by the "Update Peer Verifier" operation. B The Sender Instance and Sender Local Address fields in the incoming message match the values stored from a previous message by the "Update Peer Verifier" operation. Lindgren, et al. Expires February 1, 2014 [Page 51] Internet-Draft GORF July 2013 C The Receiver Instance and Receiver Local Address fields in the incoming message match the values of the Sender Instance and Sender Local Address used in outgoing Hello SYN, Hello SYNACK, and Hello ACK messages. SYN A Hello SYN message has been received. SYNACK A Hello SYNACK message has been received. ACK A Hello ACK message has been received. "&&" Represents the logical AND operation "||" Represents the logical OR operation "!" Represents the logical negation (NOT) operation. o A timer is required for the periodic generation of Hello SYN, Hello SYNACK, and Hello ACK messages. The value of the timer is announced in the Timer field. To avoid synchronization effects, uniformly distributed random jitter of +/-5% of the Timer field SHOULD be added to the actual interval used for the timer. There are two independent events: the timer expires, and a packet arrives. The processing rules for these events are: Timer Expires: Reset Timer If state = SYNSENT Send SYN message If state = SYNRCVD Send SYNACK message If state = ESTAB Send ACK message Packet Arrives: If incoming message is an RSTACK message: If (A && C && !SYNSENT) Reset the link Else discard the message. If incoming message is a SYN, SYNACK, or ACK message: Response defined by the following State Tables. If incoming message is any other GORF TLV and state != ESTAB: Discard incoming message. If state = SYNSENT Send SYN message(Note 1) If state = SYNRCVD Send SYNACK message(Note 1) Note 1: No more than two SYN or SYNACK messages should be sent within any time period of length defined by the timer. Lindgren, et al. Expires February 1, 2014 [Page 52] Internet-Draft GORF July 2013 o A connection across a link is considered to be achieved when the protocol reaches the ESTAB state. All TLVs, other than Hello TLVs, that are received before synchronization is achieved, will be discarded. 6.2.1. Hello Procedure State Tables State: SYNSENT +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | SYNACK && C | Update Peer Verifier; | ESTAB | | | Send ACK message | | +------------------+-----------------------------------+-----------+ | SYNACK && !C | Send RSTACK message | SYNSENT | +------------------+-----------------------------------+-----------+ | SYN | Update Peer Verifier; | SYNRCVD | | | Send SYNACK message | | +------------------+-----------------------------------+-----------+ | ACK | Send RSTACK message | SYNSENT | +==================================================================+ State: SYNRCVD +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | SYNACK && C | Update Peer Verifier; | ESTAB | | | Send ACK message | | +------------------+-----------------------------------+-----------+ | SYNACK && !C | Send RSTACK message | SYNRCVD | +------------------+-----------------------------------+-----------+ | SYN | Update Peer Verifier; | SYNRCVD | | | Send SYNACK message | | +------------------+-----------------------------------+-----------+ | ACK && B && C | Send ACK message | ESTAB | +------------------+-----------------------------------+-----------+ | ACK && !(B && C) | Send RSTACK message | SYNRCVD | +==================================================================+ Lindgren, et al. Expires February 1, 2014 [Page 53] Internet-Draft GORF July 2013 State: ESTAB +==================================================================+ | Condition | Action | New State | +=================+====================================+===========+ | SYN || SYNACK | Send ACK message (notes 2, and 3) | ESTAB | +-----------------+------------------------------------+-----------+ | ACK && B && C | Send ACK message (note 3) | ESTAB | +-----------------+------------------------------------+-----------+ | ACK && !(B && C)| Send RSTACK message | ESTAB | +==================================================================+ Note 2: No more than two ACK messages should be sent within any time period of length defined by the timer. Thus, one ACK message MUST be sent every time the timer expires. In addition, one further ACK message may be sent between timer expirations if the incoming message is a SYN or SYNACK. This additional ACK allows the Hello functions to reach synchronization more quickly. Note 3: No more than one ACK message should be sent within any time period of length defined by the timer. 6.3. Information Exchange and Bundle Passing Phase After the Hello messages have been exchanged, and the nodes are in the ESTAB state, the information exchange and bundle passing phase is initiated. This section describes the procedure and shows the state transitions necessary in this phase, and the following sections describe the various TLVs passed in this phase in detail. On reaching the ESTAB state in the high level HELLO state there is an automatic transition to the INFO_EXCH high level state. The GORF framework runs over a bidirectional transport as documented in Section 1.2 so that when a pair of nodes (A and B) have reached the ESTAB state they are able to perform the information exchange and bundle passing processes for both the A to B and B to A directions over the link that has just been established. In principle, these two processes are independent of each other and can be performed concurrently. However complete concurrency may not be the most efficient way to implement the complete process. As explained in Section 4.2.1, the Routing Information Base Dictionary is a shared resource assembled from a combination of information generated locally on each node and information passed from the peer node. Overlaps in this information and, hence the amount of information that has to be passed between the nodes, can be minimized by Lindgren, et al. Expires February 1, 2014 [Page 54] Internet-Draft GORF July 2013 sequential rather than concurrent operation of the dictionary generation and update processes. It may also be possible to reduce the number of bundles that need to be offered by the second offeror by examining the offers received from the first offeror - there is no need for the second offeror to offer a bundle that is already present in the first offeror's offer list, as it will inevitably be refused. All implementations MUST be capable of operating in a fully concurrent manner. Each implementation needs to define a policy, which SHOULD be configurable, as to whether it will operate in a concurrent or sequential manner during the information exchange and bundle passing phase. If it is to operate sequentially, then further choices can be made as to whether to interleave dictionary, offer and response exchange parts or complete all parts in one direction before initiating the other direction. One possible interleaving strategy is to alternate between sending from the two nodes. For example, if the Hello SYN node sends its initial dictionary entries while the Hello SYNACK node waits until this is complete, the Hello SYNACK node can then prune its proposed dictionary entries before sending to avoid duplication. This approach can be repeated for the second tranche of dictionary entries needed for the Bundle Offers and Responses, and also for the Bundle Offers, where any bundles that are offered by the Hello SYN node that are already present in the Hello SYNACK node need not be offered to the Hello SYN node. This approach is well suited to a transport protocol and physical medium that is effectively half-duplex. The decision to operate concurrently or sequentially is purely a matter of local policy in each node at present. If nodes have inconsistent policies, the behavior at each encounter will depend on which node takes the SYN role which is a matter of chance depending on random timing of the start of communications during the encounter. To manage the information transfer, two subsidiary state machines are created in each node to control the stages of the information exchange and bundle passing process within the INFO_EXCH high level state as shown in Figure 9. Each subsidiary state machine consists of two essentially independent components known as the "Initiator role" and the "Listener role". One of these components is instantiated in each node. The Initiator role starts the information exchange process in each node and the Listener role responds to the initial messages, but it is not a passive listener as it also originates messages. The transition from the ESTAB state is a "forking" transition in that it starts both subsidiary state machines. The two subsidiary state machines operate in parallel for as long as the neighbor remains in range and connected. Lindgren, et al. Expires February 1, 2014 [Page 55] Internet-Draft GORF July 2013 + - - - - - - - - + + - - - - - - - - + | SYN node | GORF messages with : | SYNACK node | | +-------------+ | A. Routing Metrics | +-------------+ | | Subsidiary |--->---->---->---->---->---->---->| Subsidiary | | | State | | C. Bundle Responses | | State | | | Machine 1: | | Machine 1: | | | Initiator | | B. Bundle Offers | | Listener | | | Role |<----<----<----<----<----<----<---| Role | | +-------------+ | D. Requested Bundles | +-------------+ | | +-------------+ | A. Routing Metrics | +-------------+ | | Subsidiary |<----<----<----<----<----<----<---| Subsidiary | | | State | | C. Bundle Responses | | State | | | Machine 2: | | Machine 2: | | | Listener | | B. Bundle Offers | | Initiator | | | Role |--->---->---->---->---->---->---->| Role | | +-------------+ | D. Requested Bundles | +-------------+ | + - - - - - - - - + + - - - - - - - - + The letters (A - D) indicate the sequencing of messages. Figure 9: Information Exchange Subsidiary State Machines These subsidiary state machines can be thought of as mirror images: for each state machine one node takes on the Initiator role while the other node takes on the Listener role. TLVs sent by a node from the Initiator role will be processed by the peer node in the Listener role and vice versa. As indicated in Figure 9 the Initiator role handles sending that node's current set of routing metrics for known destinations to the Listener role node. The Listener role node uses the supplied values to update its internal routing state according to the updateRoutingState() function defined in Section 3.3.6. It then decides which bundles that it has in store should be offered for transfer to the Initiator role node as a result of comparing the local routing state and those supplied by the Initiator node. When these offers are delivered to the Initiator role node, it decides which ones to accept and supplies the Listener node role with a prioritized list of bundles that it wishes to accept. The Listener role node then sends the requested bundles. These exchanges are repeated periodically for as long as the nodes remain in contact. Additionally, if new bundles arrive from other sources they may be offered, accepted and sent in between these exchanges. Lindgren, et al. Expires February 1, 2014 [Page 56] Internet-Draft GORF July 2013 The GORF routing framework is designed so that in most cases the TLV type determines the role in which it will be processed on reception. The only exception to this is that both roles may send RIB Dictionary TLVs: the Initiator role sends dictionary entries for use in the subsequent RIB TLV(s) and the Listener role may send additional dictionary entries for use in subsequent Bundle Offer TLVs. The two cases are distinguished by a TLV flag to ensure that they are processed in the right role context on reception. If this flag was not provided there are states where both roles could accept the RIB Dictionary TLV making it impossible to ensure that the correct role state machine took action. Note that the correct updates would be made to the dictionary whichever role processed the TLV and that the ambiguity would not arise if the roles are adopted completely sequentially, i.e., if the information exchange and associated bundle passing run to completion in one direction before the process for the reverse direction is started. If sequential operation is selected, the node which sent the Hello SYN function message MUST be the node which sends the first message in the information exchange process. This ensures that there is a well-defined order of events with the Initiator role in the Hello SYN node (i.e., the node identified by String ID 0) starting first. The Hello SYNACK node MAY then postpone sending its first message until the Listener role state machine in the Hello SYNACK node has reached any of a number of points in its state progression according to locally configured policy and the nature of the physical link for the current encounter between the nodes as described above. If concurrent operation is selected, the Hello SYNACK node can start sending messages immediately without waiting to receive messages from the peer. 6.3.1. Initiator Role State Definitions The state machine component with the Initiator role in each node starts the transfer of information from one node to its peer during the information exchange process. The process from the Initiator's point of view does the following: o The Initiator role determines the set of routing metrics to be sent to the peer node (returned by the getRoutingState() function in the GORF API as called during the Hello process), sends RIB dictionary entries necessary to interpret the set of RIB routing metric values that are sent after the dictionary updates. On second and subsequent executions of this state machine during a single session with the same peer there may be no RIB dictionary entries to send. Either an empty TLV can be sent or the TLV can be omitted. Lindgren, et al. Expires February 1, 2014 [Page 57] Internet-Draft GORF July 2013 o The Initiator then waits to receive any RIB dictionary updates followed by bundle offers from the Listener role on the peer node. o The Initiator calls the generateResponse() function in the GORF API to determine which of the bundle offers should be accepted and in what order they should be requested. The possibly reordered list of accepted bundles is sent to the peer node using one or more bundle responses. o The peer then sends the accepted bundles to the Initiator in turn. o Assuming that the link remains open during the bundle sending process, the Initiator signals that the bundle passing phase is complete by sending a message with an empty Bundle Response TLV (i.e, with the Bundle Offer Count set to 0 and no bundle offers following the TLV header). o When the bundle transfer is complete, the Initiator starts the next_exchange timer, set to the value returned by the getInformationExchangeTimer() function. Assuming that the connection to the neighbor remains open, when the timer expires the Initiator restarts the information exchange process. During this period, Hello SYN messages are exchanged as keep alives to check that the neighbor is still present. The keep alive mechanism is common to the Initiator and Listener machines and is handled in the high level state machine (see Section 6.1. A timer is provided which restarts the Initiator role state machine if Bundle Offers are not received after sending the RIB. If this node receives a Hello ACK message containing an Error TLV indicating there has been a protocol problem then the connection MUST be terminated. The following states are used: CREATE_DR The initial transition to this state from the ESTAB state is immediate and automatic for the node that sent the Hello SYN message. For the peer (Hello SYNACK sender) node it may be immediate for nodes implementing a fully concurrent process or may be postponed until the corresponding Listener has reached a specified state if a sequential process is configured in the node policy. The local dictionary is initialized when this state is entered for the first time from the ESTAB state. The initial state of the dictionary contains two entries: the EID of the node that sent the Hello SYN (String ID 0) and the EID of the node that sent the Lindgren, et al. Expires February 1, 2014 [Page 58] Internet-Draft GORF July 2013 Hello SYNACK (String ID 1). If the peer reports via a Hello ACK message containing an Error TLV reporting a Dictionary Conflict or Bad String ID error then the connection MUST be terminated. The CREATE_DR state will be entered in the same way from the REQUEST state when the Timer(next_exchange) expires, signaling the start of a new round of information exchange and bundle passing. When in this state: * Call the getRoutingState() function in the GORF API to etermine the destination EIDs for which routing metrics will be sent to the peer in a RIB TLV, if any. Record the prior state of the local dictionary (assuming that String IDs are numbers allocated sequentially, the state information needed is just the highest ID used before this process started) so that the process can be restarted if necessary. Update the local dictionary if any new EIDS are required, format one or more RIB Dictionary TLVs and one or more RIB TLVs and send them to the peer. If there are no dictionary entries to send, TLVs with zero entries MAY be sent, or the TLV can be omitted, but an empty RIB TLV MUST be sent if there is no data to send. The RIB Dictionary TLVs generated here MUST have the Sent by Listener flag set to 0 to indicate that they were sent by the Initiator. * If an Error TLV indicating a Dictionary Conflict or Bad String ID is received during or after sending the RIB Dictionary TLVs and/or the RIB TLVs, abort any in progress Initiator or Listener process, and terminate the connection to the peer. * Start a timer (known as Timer(info)) and transition to the SEND_DR state. Note that when (and only when) running over a transport protocol such as TCP, both the RIB Dictionary and RIB information MAY be spread across multiple TLVs and messages if required by known constraints of the transport protocol or to reduce the size of memory buffers. Alternatively the information can be formatted into single RIB Dictionary and RIB TLVs and the submessage capability of GORF or the inherent capabilities of the transport protocol used to segment the message if required. This discussion of segmentation applies to the other states and the Bundle Offer and Bundle Response messages and will not be repeated. Lindgren, et al. Expires February 1, 2014 [Page 59] Internet-Draft GORF July 2013 If more than one RIB TLV is to be used, all but the last one have the "More RIB TLVs" flag set to 1 in the TLV flags. It is not necessary to distinguish the last RIB Dictionary TLV because the actions taken at the receiver are essentially passive (recording the contents) and the sequence is ended by the sending of the first RIB TLV. SEND_DR In this state the Initiator node expects to be receiving Bundle Offers and sending Bundle Responses: * Clear the set of bundles offered by the peer on entry to the state. * If the Timer(info) expires, resend the RIB Dictionary and RIB information sent in the previous CREATE_DR state using the stored state to recreate the information. The RIB dictionary update process in the peer is idempotent provided that the mappings between the EID and the String ID in the resent RIB Dictionary TLVs are the same as in the original. This means that it does not matter if some of the RIB Dictionary TLVs had already been processed in the peer. Similarly resending RIB TLVs will not cause a problem. * If a message with a RIB Dictionary TLV marked as sent by a Listener is received, update the local dictionary based on the received TLV. If any of the entries in the RIB Dictionary TLV conflict with existing entries (i.e., an entry is received that uses the same String ID as some previously received entry but the EID in the entry is different), send a Response message with an Error TLV containing a Dictionary Conflict indicator, abort any in progress Initiator or Listener process, and terminate the connection to the peer. Note that in some circumstances no dictionary updates are needed and the first message received in this state will carry a Bundle Offer TLV. * If a message with a Bundle Offer TLV is received, restart the Timer(info) if the More Offer/Response TLVs Following flag is set in the TLV or otherwise stop the Timer(info). Then process any GORF ACKS in the TLV by informing the Bundle Agent, calling the ackReceived() function in the GORF API, and add the bundles offered in the TLV to the set of bundles offered. If the More Offer/Response TLVs Following flag is set in the TLV wait for further Bundle Offer TLVs. If a Bundle Offer TLV is received with a String ID that is not in the dictionary send a message with an Error TLV containing a Bad String ID indicator, abort any in progress Initiator or Listener process, and terminate the connection to the peer. Lindgren, et al. Expires February 1, 2014 [Page 60] Internet-Draft GORF July 2013 * If the More Offer/Response TLVs Following flag is clear in the last Bundle Offer TLV received, pass the list of bundle ids offered to the generateResponse() function in the GORF API to determine the set of bundles that are to be accepted. Record the set of bundles accepted so that reception can be checked in the bundle passing phase. Format one or more Bundle Response TLVs flagging the accepted offers and send them to the peer. If more than one Bundle Response TLV is sent, all but the last one should have the More Offer/Response TLVs Following TLV flag set to 1. At least one Bundle Response TLV MUST be sent even if the node does not wish to accept any of the offers. In this case the Bundle Response TLV contains an emoty set of acceptances. * If an Error TLV indicating a Bad String ID is received during or after sending the Bundle Response TLVs, abort any in progress Initiator or Listener process, reinitialize the local dictionary and terminate the connection to the peer. * Restart the Timer(info) timer in case the peer does not start sending the requested bundles. * Transition to state REQUEST. REQUEST In this state the Initiator node expects to be receiving the bundles accepted in the Bundle Response TLV(s): * Keep track of the bundles received and delete them from the set of bundles accepted. * If the Timer(info) expires while waiting for bundles, format and send one or more Bundle Response TLVs listing the bundles previously accepted but not yet received. If more than one Bundle Response TLV is sent, all but the last one should have the More Offer/Response TLVs Following TLV flag set to 1. * If an Error TLV indicating a Bad String ID is received during or after sending the Bundle Response TLVs, abort any in progress Initiator or Listener process, reinitialize the local dictionary and terminate the connection to the peer. * Restart the Timer(info) timer after each bundle is received in case the peer does not continue sending the requested bundles. * When all the requested bundles have been received, format a Bundle Response TLV with the Bundle Offer Count set to zero and with the More Offer/Response TLVs Following flag cleared to 0 Lindgren, et al. Expires February 1, 2014 [Page 61] Internet-Draft GORF July 2013 to signal completion to the peer node. Also signal the Listener in this node that the Initiator has completed. If the peer node is using a sequential policy, the Listener may still be in the initial state in which case it needs to start a timer to ensure that it detects if the peer fails to start the Initiator state machine. Thereafter coordinate with the Listener state machine in the same node: when the Listener has received the completion notification from the peer node and this Initiator has sent its completion notification, start a Timer(next_exchange). * If the Timer(next_exchange) expires, transition to state CREATE_DR to restart the information exchange process. Note that if Timer(info) timeout occurs a number of times (configurable, typically 3) without any bundles being received then this SHOULD generally be interpreted as a problem that indicates that the link to the peer is no longer functional and the session should be terminated. However, some bundles may be very large and take a long time to transmit. Before terminating the session this state machine needs to check if a large bundle is actually being received although no new completed bundles have been received since the last expiry of the timer. In this case the timer should be restarted without sending the Bundle Response TLV. Also if the bundles are being exchanged over a transport protocol that can detect link failure, then the session MUST be terminated if the bundle exchange link is shut down because it has failed. 6.3.2. Listener Role State Definitions The state machine component with the Listener role in each node initially waits to receive a RIB Dictionary update followed by a set of RIB routing metrics during the information exchange process. The process from the point of view of the Listener does the following: o Receive RIB Dictionary updates and RIB values from the peer. Note that in some circumstances no dictionary updates are needed and RIBD dictionary TLV will contain no entries or may be omitted completely. o When all RIB messages have been received, the updateRoutingState() function in the GORF API is run using the values received from the Initiator node. o Using the updated internal routing state and the policies of the current routing algorithms are applied by calling the generateOffer() function in the GORF API to determine the set of Lindgren, et al. Expires February 1, 2014 [Page 62] Internet-Draft GORF July 2013 bundles to be offered to the Initiator and order the list according to the forwarding priority. The Bundle Offer TLVs are also used to notify the peer of any GORF Acks that have been received by this node. o Send the list of bundles in one or more bundle offers, preceded if necessary by one or more RIB dictionary updates to add any EIDs required for the source or destination EIDs of the offered bundles. These updates MUST be marked as being sent by the Listener role so that they will be processed by the Initiator role in the peer. o Wait for the Initiator to send a bundle responses indicating which bundles should be sent and possibly a modified order for the sending. Send the bundles accepted in the specified order. The bundle sending will normally be carried out over a separate connection using a suitable DTN convergence layer. o On completion of the sending, wait for a message with an empty Bundle Response TLV indicating correct completion of the process. o The Listener process will be notified if any new bundles or GORF ACKs are received by the node after the completion of the bundle sending resulting from this information exchange and the newBundleArrived() or ackReceived() functions in the GORF API will be called to inform the routing algorithm module and allow it to determine if this information should be sent to the peer. If it is determined that one or more bundles and/or ACKs ought to be forwarded, a new set of bundle offers are sent to the peer. If the peer accepts them by sending bundle responses, the bundles and/or ACKS are transferred as previously o Periodically, the Initiator in the peer will restart the complete information exchange by sending a RIB TLV that may be, optionally, preceded by RIB Dictionary entries if they are required for the updated RIB. Timers are used to ensure that the Listener does not lock up if messages are not received from the Initiator in a timely fashion. The Listener is restarted if the RIB is not received and a Hello Ack message is sent to force the Initiator to restart. If Bundle Response messages are not received in a timely fashion, the Listener resends the Bundle Offers and associated dictionary updates. The following states are used: Lindgren, et al. Expires February 1, 2014 [Page 63] Internet-Draft GORF July 2013 WAIT_DICT The Listener subsidiary state machine transitions to this state automatically and immediately from the state ESTAB in both peers. This state will be entered in the same way if the Timer(next_exchange) expires in the peer, signaling the start of a new round of information exchange and bundle passing. This will result in one or more RIB TLVs being sent to the Listener by the peer node's Initiator. * When a RIB Dictionary TLV is received, use the TLV to update the local dictionary, start or, if it is running, restart the Timer(peer) and transition to state WAIT_RIB. If any of the entries in the RIB Dictionary TLV conflict with existing entries (i.e., an entry is received that uses the same String ID as some previously received entry but the EID in the entry is different), send a Rersponse message with an Error TLV containing a Dictionary Conflict indicator, abort any in progress Initiator or Listener process, and terminate the connection to the peer. * If a Hello ACK message is received from the peer node, transition to state WAIT_DICT and restart the process. If multiple timeouts occur (configurable, typically 3), assume that the link is broken and terminate the session. Note that the RIB Dictionary and RIB TLVs may be combined into a single message. The RIB TLV should be passed on to be processed in the WAIT_RIB state. WAIT_RIB In this state the Listener expects to be receiving one or more RIB TLVs and possibly additional RIB Dictionary TLVs. * On entry to this state clear the set of received routing metrics. * Whenever a new message is received, restart the Timer(peer) timer. * If a RIB dictionary TLV is received, use it to update the local dictionary and remain in this state. If any of the entries in the RIB Dictionary TLV conflict with existing entries (i.e., an entry is received that uses the same String ID as some previously received entry but the EID in the entry is different), send a message with an Error TLV containing a Dictionary Conflict indicator, abort any in progress Initiator or Listener process, and terminate the connection to the peer. Lindgren, et al. Expires February 1, 2014 [Page 64] Internet-Draft GORF July 2013 * If a RIB TLV is received, record the received routing metric value for use in recalculating the local routing metric. If a routing metric value is received for an EID that is already in the set of received routing metrics, overwrite the previously received value with the latest value. If a routing metric value is received with a String ID that is not in the dictionary send a message with an Error TLV containing a Bad String ID indicator, abort any in progress Initiator or Listener process, and terminate the connection to the peer. * When a RIB TLV is received with the More RIB TLVs flag cleared, initiate the recalculation of the internal routing state by calling the updateRoutingState() function in the GORF API and stop the Timer(peer). Use the update routing state to create a list of bundles to be offered to the peer node by calling the generateOffer() function. * Record the state of the local dictionary in case the offer procedure has to be restarted. Determine if any new dictionary entries are required for use in the Bundle Offer TLV(s). If so record them in the local dictionary, then format and send RIB Dictionary entries in zero or more RIB Dictionary TLV messages to update the dictionary in the peer if necessary. * Format and send Bundle Offer TLV(s) carrying the identifiers of the bundles to be offered together with any GORF ACKs received or generated by this node. If more than one Bundle Offer TLV is sent, all but the last Bundle Offer TLV sent MUST have the More Offer/Response TLVs Following flag set to 1. * When all Bundle Offer TLVs have been sent start the Timer(info) and transition to state OFFER. * If the Timer(peer) expires, send a Hello ACK TLV to the peer, restart the timer and transition to state WAIT_DICT. * If an Error TLV indicating a Dictionary Conflict or Bad String ID is received during or after sending the RIB Dictionary TLVs and/or the Bundle Offer TLVs, abort any in progress Initiator or Listener process, and terminate the connection to the peer. * If a Hello ACK message is received from the peer node, transition to state WAIT_DICT and restart the process. Lindgren, et al. Expires February 1, 2014 [Page 65] Internet-Draft GORF July 2013 OFFER In this state the Listener expects to be receiving one or more Bundle Response TLVs detailing the bundles accepted by the Initiator node. The ordered list of accepted bundles is communicated to the Bundle Protocol Agent which controls sending them to the peer node over a separate connection. * When a Bundle Response TLV is received with a non-zero count of Bundle Offers, extract the list of accepted bundles and send the list to the Bundle Protocol Agent so that it can start transmission to the peer node. Ensure that the order of offers from the TLV is maintained. Restart the Timer(info) unless the last Bundle Response TLV received has the More Offer/ Response TLVs Following flag set to 0. If a Bundle Response TLV is received with a String ID that is not in the dictionary send a message with an Error TLV containing a Bad String ID indicator, abort any in progress Initiator or Listener process, and terminate the connection to the peer. * After receiving a Bundle Response TLV with the More Offer/ Response TLVs Following flag set to 0 stop the Timer(info) and transition to state SND_BUNDLE. * If the Timer(info) expires, send a Hello ACK TLV to the peer, restart the timer and transition to state WAIT_DICT. * If a Hello ACK message is received from the peer node, transition to state WAIT_DICT and restart the process. SND_BUNDLE In this state the Listener monitors the sending of bundles to the Initiator peer node. In the event of disruption in transmission, the Initiator node will, if possible, resend the list of bundles that were accepted but have not yet been received. The Bundle Protocol Agent has to be informed of any updates to the list of bundles to send (this is likely to involve resending one or more bundles). Otherwise the Listener is quiescent in this state. * When a Bundle Response TLV is received with a non-zero count of Bundle Offers, extract the list of accepted bundles and update the list previously passed to the Bundle Protocol Agent so that it can (re)start transmission to the peer node. Ensure that the order of offers from the TLV is maintained so far as is possible. Restart the Timer(info) unless the last Bundle Response TLV received has the More Offer/ Response TLVs Following flag set to 0. If a Bundle Response TLV is received with a String ID that is not in the dictionary send a message with an Error TLV containing a Bad String ID Lindgren, et al. Expires February 1, 2014 [Page 66] Internet-Draft GORF July 2013 indicator, abort any in progress Initiator or Listener process, reinitialize the local dictionary and restart the information exchange process as if the ESTAB state had just been reached. * After receiving a Bundle Response TLV with the More Offer/ Response TLVs Following flag set to 0 stop the Timer(info) and wait for completion of bundle sending. * If the Timer(info) expires, send a Hello ACK TLV to the peer, restart the timer and transition to state WAIT_DICT. * If a Hello ACK message is received from the peer node, transition to state WAIT_DICT and restart the process. * When a Bundle Response TLV is received with a zero count of Bundle Offers, the bundle passing phase is complete. Notify the Initiator that the Listener process is complete and transition to state WAIT_MORE. As explained in the Initiator state REQUEST description, depending on the transport protocol (convergence layer) used to send the bundles to the peer node, it may be necessary to monitor the liveness of the connection to the peer node in the Initiator process during the bundle sending process using a timer. WAIT_MORE In this state the Listener monitors the reception of new bundles that might be received from a number of sources, including * local applications on the node, * other mobile nodes that connect to the node while this connection is open, and * permanent connections such as might occur at an Intenet gateway. When the Listener is notified of received bundles, it calls the newBundleArrived() function in the GORF API to determine if they should be offered to the peer. The peer may also reinitiate the information exchange process periodically. * When the Bundle Protocol Agent notifies the Listener that new bundles and/or new GORF ACKs have been received, the Listener applies calls the newBundleArrived() and/or ackReceived() functions to determine if any of the items ought to be offered to the connected peer. If so it carries out the same operations as are described in the WAIT_RIB state to build and Lindgren, et al. Expires February 1, 2014 [Page 67] Internet-Draft GORF July 2013 send any necessary RIB Dictionary TLVs and RIB TLVs to the Initiator in the peer. * When all Bundle Offer TLVs have been sent start the Timer(info) and transition to state OFFER. * If a RIB dictionary TLV is received, use it to update the local dictionary and transition to state WAIT_RIB. If any of the entries in the RIB Dictionary TLV conflict with existing entries (i.e., an entry is received that uses the same String ID as some previously received entry but the EID in the entry is different), send a message with an Error TLV containing a Dictionary Conflict indicator, abort any in progress Initiator or Listener process, and terminate the connection to the peer. Note that the RIB Dictionary and RIB TLVs may be combined into a single message. The RIB TLV should be passed on to be processed in the WAIT_RIB state. 6.3.3. Recommendations for Information Exchange Timer Periods The information exchange process state definitions define a number of timers. This section provides advice and recommendations for the periods that are appropriate for these timers. *** define this in routing algorithm module descriptions *** Both Timer(info) and Timer(peer) are used to ensure that the state machines do not become locked into inappropriate states if the peer node does not apparently respond to messages sent in a timely fashion either because of message loss in the network or unresponsiveness from the peer. The appropriate values are to some extent dependent on the speed of the network connection between the nodes and the capabilities of the nodes executing the GORF framework implementations. Values in the range 1 to 10 seconds SHOULD be used, with a value of 5 seconds RECOMMENDED as default. The period should not be set to too low a value as this might to inappropriate restarts if the hardware is relatively slow or there are large numbers of pieces of information to process before responding. When using a reliable transport protocol such as TCP, these timers effectively provide a keepalive mechanism and ensure that a failed connection is detected as rapidly as possible so that remedial action can be taken if possible or the connection shut down tidily if the peer node has moved out of range. Timer(next_exchange) is used to determine the maximum frequency of (i.e., minimum period between) successive reexecutions of the information exchange state machines during a single session between a pair of nodes. Selection of the timer period SHOULD reflect the Lindgren, et al. Expires February 1, 2014 [Page 68] Internet-Draft GORF July 2013 trade off between load on the node processor and desire for timely forwarding of bundles received from other nodes. It is RECOMMENDED that the timer periods used should be randomized over a range from 50% to 150% of the base value to avoid any risk of synchronization between multiple nodes occurring. Consideration SHOULD be given to the expected length of typical encounters and the likelihood of encounters between groups of nodes when setting this period. Base values in the range of 20 to 60 seconds are RECOMMENDED. 6.3.4. Information Exchange State Tables This section shows the state transitions that nodes go through during the information exchange and bundle passing phase. State tables are given for the Initiator role and for the Listener role of the subsidiary state machines. Both nodes will be running machines in each role during the information exchange and bundle passing phase and this can be done either concurrently or sequentially, depending on the implementation, as explained in Section 6.3. The state tables in this section should be read in conjunction with the state descriptions in Sections 6.3.1 and 6.3.2. 6.3.4.1. Common Notation, Operations and Events The following notation is used: nS Node that sent the Hello SYN message. nA Node that sent the Hello SYNACK message. The following events are common to the Initiator and Listener state tables:: ErrDC Dictionary Conflict Error TLV received. ErrBadSI Bad String ID Error TLV received. HelloAck Hello ACK TLV received. This message is delivered to both Initiator and Listener roles in order to cause a restart of the information exchange process in the event of message loss or protocol problems. nodeEncountered() called InitStart Sent by Listener role to Initiator role to signal the Initiator role to commence sending messages to peer. If the Listener instance is running in the node that sent the Hello SYN (nS) then InitStart is signaled immediately the state is entered. For the node that sent the Hello SYNACK (nA), InitStart may be signaled Lindgren, et al. Expires February 1, 2014 [Page 69] Internet-Draft GORF July 2013 immediately if the operational policy requires concurrent operation of the Initiator and Listener roles or postponed until the Listener role state machine has reached a state defined by the configured policy. RIBnotlast RIB TLV received with More RIBs Follow flag set to 1. RIBlast RIB TLV received with More RIBs Follow flag set to 0. REQnotlast Bundle Response TLV received with More Offer/Response TLVs Following flag set to 1. REQlast Bundle Response TLV received with More Offer/Response TLVs Following flag set to 0. RIBDi RIBD TLV received with Sent by Listener flag set to 0 (i.e., it was sent by Initiator role). RIBDl RIBD TLV received with Sent by Listener flag set to 1 (i.e., it was sent by Listener role). Timeout(info) The Timer(info) has expired. Timeout(peer) The Timer(peer) has expired. Both the Initiator and Listener state tables use the following common operations: o The "Initialize Dictionary" operation is defined as emptying any existing local dictionary and inserting the two initial entries: the EID of the node that sent the Hello SYN (String ID 0) and the EID of the node that sent the Hello SYNACK (String ID 1). o The "Send RIB Dictionary Updates" operation is defined as: 1. Determining what dictionary updates will be needed for any extra EIDs in the previously selected RIB entries set that are not already in the dictionary and updating the local dictionary with these EIDs. The set of dictionary updates may be empty if no extra EIDs are needed. The set may be empty even on the first execution if sequential operation has been selected, this is the second node to start and the necessary EIDs were in the set previously sent by the first node to start. 2. Formatting zero or more RIBD TLVs for the set of dictionary updates identified in the "Build RIB Entries" operation and Lindgren, et al. Expires February 1, 2014 [Page 70] Internet-Draft GORF July 2013 sends them to the peer. The RIBD TLVs MUST have the "Sent by Listener" flag set to 0 if the updates are sent by the Initiator role and to 1 if sent by the Listener role. In the case of the Initiator role an empty RIBD TLV MUST be sent even if the set of updates is empty in order to trigger the Listener state machine. o The "Update Dictionary" operation uses received RIBD TLV entries to update the local dictionary. The received entries are checked against the existing dictionary. If the String ID in the entry is already in use, the entry is accepted if the EID in the received entry is identical to that stored in the dictionary previously. If it is identical, the entry is unchanged, but if it is not a Response message with an Error TLV indicating "Dictionary Conflict" is sent to the peer in an Error Response message, the whole received RIBD TLV is ignored and the Initiator and Listener processes are restarted as if the ESTAB state has just been reached. o The "Abort Exchange" operation is defined as aborting any in progress information exchange state machines, terminating the connection to the peer. o The Start TI" operation is defined as (re)starting the Timer(info) timer. o The "Start TP" operation is defined as (re)starting the Timer(peer) timer. o The "Cancel TI" operation is defined as canceling the Timer(info) timer. o The "Cancel TP" operation is defined as canceling the Timer(info) timer. 6.3.4.2. Initiator Role State Tables The rules and state tables for the Initiator role use the following operations: o The "Build RIB Entries" operation is defined as: 1. Recording the state of the local dictionary. 2. Determining the set of EIDs for which RIB entries should be sent during this execution of the Initiator role state machine component using the getRoutingState() function of the GORF API. If this is a second or subsequent run of the state Lindgren, et al. Expires February 1, 2014 [Page 71] Internet-Draft GORF July 2013 machine in this node during the current session with the connected peer then the set of EIDs may be empty if no changes have occurred since the previous run of the state machine. 3. Determining and extracting the current routing metric information for the set of EIDs selected. o The "Send RIB Entries" operation formats one or more RIB TLVs with the set of RIB entries identified in the "Build RIB Entries" operation and sends them to the peer. If the set is empty, a single RIB TLV with zero entries is sent. If more than one RIB TLV is sent, all but the last one MUST have the "More RIB TLVs" flag set to 1; the last or only one MUST have the flag set to 0. o The "Clear Bundle Lists" operation is defined as emptying the lists of bundles offered by and bundles requested from the peer. o The "Notify Acks" operation is defined as informing the bundle agent that GORF Acks has been received for one or more bundles in a Bundle Offer TLV using the Bundle Delivered interface (see Section 2.3). o The "Record Offers" operation is defined as recording all the bundles offered in a Bundle Offer TLV in the list of bundles offers. o The "Select for Request" operation prunes and sorts the list of offered bundles held into the list of requested bundles according to policy and available resources ready for sending to the offering node. o The "Send Requests" operation is defined as formatting one or more non-empty Bundle Response TLVs and sending them to the offering node.If more than one Bundle Offer TLV is sent, all but the last one MUST have the More Offer/ Response TLVs Following flag set to 1; the last or only one MUST have the flag set to 0. o The "Record Bundle Received" operation deletes a successfully received bundle from the list of requests. o The "All Requests Done" operation is defined as formatting and sending an empty Bundle Offer TLV, with the More Offer/ Response TLVs Following flag set to 0, to the offering node. o The "Check Receiving" operation is defined as checking with the node bundle agent if bundle reception from the peer node is Lindgren, et al. Expires February 1, 2014 [Page 72] Internet-Draft GORF July 2013 currently in progress. Needed in case a timeout occurs while waiting for bundle reception and a very large bundle is being processed. The following events are specific to the Initiator role state machine: LastBndlRcvd Bundle received from peer that is the only remaining bundle in Bundle Requests List. NotLastBndlRcvd Bundle received from peer that is not the only remaining bundle in Bundle Requests List. OFRnotlast Bundle Offer TLV received with More Offer/Response TLVs Following flag set to 1. OFRlast Bundle Offer TLV received with More Offer/Response TLVs Following flag set to 0 Timeout(next_exch) The Timer(next_exchange) has expired State: CREATE_DR +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | On Entry | If previous state was ESTAB: | | | | Initialize Dictionary | | | | Always: | | | | Build RIB Entries | | | | Wait for Init Start | CREATE_DR | +------------------+-----------------------------------+-----------+ | InitStart | Send RIB Dictionary Updates | | | | Send RIB Entries | | | | Start TI | SEND_DR | +------------------+-----------------------------------+-----------+ | ErrDC | Abort Exchange |(finished) | +------------------+-----------------------------------+-----------+ | ErrBadSI | Abort Exchange |(finished) | +------------------+-----------------------------------+-----------+ | HelloAck | Abort Exchange | CREATE_DR | +==================================================================+ Lindgren, et al. Expires February 1, 2014 [Page 73] Internet-Draft GORF July 2013 State: SEND_DR +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | On Entry | Clear Bundle Lists | SEND_DR | +------------------+-----------------------------------+-----------+ | Timeout(info) | Send RIB Dictionary Updates | | | | Send RIB Entries (note 1) | SEND_DR | +------------------+-----------------------------------+-----------+ | RIBDl received | Update Dictionary (note 2) | | | | If Dictionary Conflict found: | | | | Abort Exchange | CREATE_DR | | | Else: | | | | Start TI | SEND_DR | +------------------+-----------------------------------+-----------+ | OFRnotlast | Notify Acks | | | | Record Offers | | | | Start TI | SEND_DR | +------------------+-----------------------------------+-----------+ | OFRlast | Cancel TI | | | | Notify Acks | | | | Record Offers | | | | Select for Request | | | | Send Requests | | | | Start TI | REQUEST | +------------------+-----------------------------------+-----------+ | ErrDC | Abort Exchange |(finished) | +------------------+-----------------------------------+-----------+ | ErrBadSI | Abort Exchange |(finished) | +------------------+-----------------------------------+-----------+ | HelloAck | Abort Exchange | CREATE_DR | +==================================================================+ Lindgren, et al. Expires February 1, 2014 [Page 74] Internet-Draft GORF July 2013 State: REQUEST +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | Timeout(info) | Check Receiving | | | | If bundle reception in progress: | | | | Start TI | REQUEST | | | Otherwise: | | | | Send Requests | | | | Start TI (note 3) | REQUEST | +------------------+-----------------------------------+-----------+ | NotLastBndlRcvd | Record Bundle Received | | | | Start TI | REQUEST | +------------------+-----------------------------------+-----------+ | LastBndlRecd | Cancel TI | | | | All Requests Done | | | | Start next_exchange timer | REQUEST | +------------------+-----------------------------------+-----------+ |Timeout(next_exch)| | CREATE_DR | +------------------+-----------------------------------+-----------+ | HelloAck | Abort Exchange | CREATE_DR | +==================================================================+ Note 1: No response to the RIB has been received before the timer expired, so we resend the dictionary and RIB TLVs. If the timeout occurs repeatedly it is likely that communication has failed and the connection MUST be terminated. Note 2: If a Dictionary Conflict error has to be sent the state machine will be aborted. If this event occurs repeatedly it is likely that there is either a serious software problem or a security issue. The connection MUST be terminated. Note 3: Remaining requested bundles have not arrived before the timer expired, so we resend the list of outstanding requests. If the timeout occurs repeatedly it is likely that communication has failed and the connection MUST be terminated. 6.3.4.3. Listener Role State Tables The rules and state tables for the Listener role use the following operations: Lindgren, et al. Expires February 1, 2014 [Page 75] Internet-Draft GORF July 2013 o The "Clear Supplied RIBs" operation is defined as setting up a an empty container to hold the set of RIBs supplied by the peer node. Note that any existing set of routing metrics should be retained in case an empty set is supplied meaning that the existing set should be reused. o The "Record RIBs Supplied" operation is defined as: 1. Taking the RIB entries from a received RIB TLV. 2. Verifying that the String ID used in each entry is present in the dictionary. If not an Error TLV containing the offending String ID is sent to the peer, the Initiator and Listener processes are aborted and restarted as if the ESTAB state had just been reached. 3. If all the String IDs are present in the dictionary, record the routing metrics for each EID in the entries. o The "Update Routing State" operation uses the algorithms defined by the updateRoutingState() function in the GORF API to update the local state using the using the set of routing metrics supplied by the peer in RIB TLVs. o The "Determine Offers" operation determines the set of bundles to be offered to the peer. The local routing state and the routing metrics supplied by the peer are compared and a prioritized choice of the bundles stored in this node to be offered to the peer is made according to the configured queuing policy and forwarding strategy. o The "Determine Acks" operation is defined as obtaining the set of GORF Acks recorded by the bundle agent that need to be forwarded to the peer. The list of GORF ACks is maintained internally by the GORF framework implementation rather than the main bundle agent (see Section 4.4). o The "Determine Offer Dict Updates" operation is defined as determining any extra EIDs that are not already in the dictionary, recording the previous state of the local dictionary and then adding the required extra entries to the dictionary. o The "Send Offers" operation is defined as formatting one or more non-empty Bundle Offer TLVs incorporating the sets of Offers and GORF Acks previously determined and sending them to the peer node. If more than one Bundle Offer TLV is sent, all but the last one MUST have the More Offer/Response TLVs Following flag set to 1; the last or only one MUST have the flag set to 0. Lindgren, et al. Expires February 1, 2014 [Page 76] Internet-Draft GORF July 2013 o The "Record Requests" operation is defined as recording all the bundles offered in a Bundle Offer TLV in the list of bundles offers. Duplicates MUST be ignored. The order of requests in the TLVs MUST be maintained so far as is possible (it is potentially possible that a bundle has to be resent and this may result in out of order delivery>) o The "Send Bundles" operation is defined as sending, in the order requested, the bundles in the requested list. This requires the list to be communicated to the bundle agent (see Section 2.3). o The "Check Initiator Start Point" operation is defined as checking the configured sequential operation policy to determine if the Listener role has reached the point where the Initiator role should be started. If so the InitStart notification is sent to the Initiator role in the same node. The following events are specific to the Listener role state machine: RIBnotlast RIB TLV received with More RIB TLVs flag set to 1. RIBlast RIB TLV received with More RIB TLVs flag set to 0 and a non-zero count of RIB Entries. REQnotlast Bundle Response TLV received with More Offer/Response TLVs Following flag set to 1. REQlast Bundle Response TLV received with More Offer/Response TLVs Following flag set to 0 and a non-zero count of Bundle Offers. REQempty Bundle Response TLV received with More Offer/Response TLVs Following flag set to 0 and a zero count of Bundle Offers. Lindgren, et al. Expires February 1, 2014 [Page 77] Internet-Draft GORF July 2013 State: WAIT_DICT +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | On Entry | Check Initiator Start Point | WAIT_DICT | +------------------+-----------------------------------+-----------+ | RIBDi | Update Dictionary (note 1) | | | | If Dictionary Conflict found: | | | | Abort Exchange |(finished) | | | Else: | | | | Start TP | WAIT_RIB | +------------------+-----------------------------------+-----------+ | HelloAck | Abort Exchange | WAIT_DICT | +==================================================================+ Lindgren, et al. Expires February 1, 2014 [Page 78] Internet-Draft GORF July 2013 State: WAIT_RIB +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | On Entry | Clear Supplied RIBS | WAIT_RIB | +------------------+-----------------------------------+-----------+ | RIBDi | Update Dictionary (note 1) | | | | If Dictionary Conflict found: | | | | Abort Exchange |(finished) | | | Else: | | | | Start TP | WAIT_RIB | +------------------+-----------------------------------+-----------+ | RIBnotlast | Record RIBS Supplied (note 2) | | | | If EID missing in dictionary: | | | | Abort Exchange |(finished) | | | Else: | | | | Start TP | WAIT_RIB | +------------------+-----------------------------------+----------- | RIBlast | Check Initiator Start Point | | | | Record RIBS Supplied (note 2) | | | | If EID missing in dictionary: | | | | Abort Exchange |(finished) | | | Otherwise | | | | updateRoutingState() | | | | Cancel TP | | | | generateOffers() | | | | Determine Acks | | | | Determine Offer | | | | Dict Updates | | | | Send RIB Dictionary | | | | Updates | | | | Send Offers | | | | Start TI | OFFER | +------------------+-----------------------------------+-----------+ | HelloAck | Abort Exchange | WAIT_DICT | +------------------+-----------------------------------+-----------+ |Any Other TLV rcvd| Abort Exchange |(finished) | +------------------+-----------------------------------+-----------+ | Timeout(peer) | Send RIB Dictionary Updates | | | | Send Offers | | | | Start TI (note 3) | OFFER | +==================================================================+ Lindgren, et al. Expires February 1, 2014 [Page 79] Internet-Draft GORF July 2013 State: OFFER +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | REQnotlast | Send Bundles | | | | Start TI | OFFER | +------------------+-----------------------------------+-----------+ | REQlast | Cancel TI | | | | Check Initiator Start Point | | | | Send Bundles | SND_BUNDLE| +------------------+-----------------------------------+-----------+ | REQempty | Cancel TI | | | | Check Initiator Start Point | WAIT_MORE| +------------------+-----------------------------------+-----------+ | HelloAck | Abort Exchange | WAIT_DICT | +------------------+-----------------------------------+-----------+ | Timeout(info) | Send RIB Dictionary Updates | | | | Send Offers | | | | Start TI (note 3) | OFFER | +==================================================================+ State: SND_BUNDLE +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | REQnotlast | Send Bundles | | | | Start TI | SND_BUNDLE| +------------------+-----------------------------------+-----------+ | REQlast | Cancel TI | | | | Send Bundles | SND_BUNDLE| +------------------+-----------------------------------+-----------+ | REQempty | Cancel TI | | | | Check Initiator Start Point | WAIT_MORE| +------------------+-----------------------------------+-----------+ | HelloAck | Abort Exchange | WAIT_DICT | +------------------+-----------------------------------+-----------+ | Timeout(info) | Send RIB Dictionary Updates | | | | Send Offers | | | | Start TI (note 3) | OFFER | +==================================================================+ Lindgren, et al. Expires February 1, 2014 [Page 80] Internet-Draft GORF July 2013 State: WAIT_MORE +==================================================================+ | Condition | Action | New State | +==================+===================================+===========+ | More Bundles | newBundleArrived() | | | | Determine Acks | | | | Determine Offer | | | | Dict Updates | | | | Send RIB Dictionary | | | | Updates | | | | Send Offers | | | | Start TI | OFFER | +------------------+-----------------------------------+-----------+ | RIBDi | Update Dictionary (note 1) | | | | If Dictionary Conflict found: | | | | Abort Exchange |(finished) | | | Else: | | | | Start TP | WAIT_RIB | +------------------+-----------------------------------+-----------+ | REQnotlast | Send Bundles | | | | Start TI | SND_BUNDLE| +------------------+-----------------------------------+-----------+ | REQlast | Cancel TI | | | | Send Bundles | SND_BUNDLE| +------------------+-----------------------------------+-----------+ | REQempty | Cancel TI | | | | Check Initiator Start Point | SND_BUNDLE| +------------------+-----------------------------------+-----------+ | HelloAck | Abort Exchange | WAIT_DICT | +------------------+-----------------------------------+-----------+ | Timeout(info) | Send RIB Dictionary Updates | | | | Send Offers | | | | Start TI (note 3) | OFFER | +==================================================================+ Note 1: Both the dictionary and the RIB TLVs may come in the same GORF message. In that case, the state will change to WAIT_RIB and the RIB will then immediately be processed. Note 2: Send an ACK if the timer for the peering node expires. Either the link has been broken, and then the link setup will restart, or it will trigger the information exchange phase to restart. Lindgren, et al. Expires February 1, 2014 [Page 81] Internet-Draft GORF July 2013 Note 3: When the RIB is received it is possible for the GORF agent to update its internal routing state according to updateRoutingState() in the GORF API. The routing metrics and the RIB is then used together with the routing algorithm policy in generateOffer() in use to create a bundle offer TLV. This is sent to the peering node. Note 4: No more bundles are requested by the other node, transfer is complete. Note 5: No response to the bundle offer has been received before the timer expired, so we resend the bundle offer. Lindgren, et al. Expires February 1, 2014 [Page 82] Internet-Draft GORF July 2013 7. Security Considerations Lindgren, et al. Expires February 1, 2014 [Page 83] Internet-Draft GORF July 2013 8. IANA Considerations Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following name spaces are defined in GORF: o For fields in the GORF message header (Section 5.1): * DTN Routing Protocol Number * GORF Protocol Version * GORF Header Flags * GORF Result Field * GORF Codes for Success and Codes for Failure o Identifiers for TLVs carried in GORF messages: * GORF TLV Type (Section 5.2) o Definitions of TLV Flags and other flag fields in TLVs: * Hello TLV Flags (Section 5.3.1) * Error TLV Flags (Section 5.3.2) * Routing Information Base (RIB) Dictionary TLV Flags (Section 5.3.3) * Routing Information Base (RIB) TLV Flags (Section 5.3.4) * Routing Information Base (RIB) Flags per entry (Section 5.3.4) * Bundle Offer and Response TLV Flags (Section 5.3.5) * Bundle Offer and Response B Flags per offer or response (Section 5.3.5) The following subsections lists the registries that are requested to be created. Initial values for the registries are given below; future assignments are to be made through the Specification Required policy. Where specific values are defined in the IANA registries to be setup according to the specifications in the sub-sections below, the registry should refer to this document as defining the allocation. Lindgren, et al. Expires February 1, 2014 [Page 84] Internet-Draft GORF July 2013 8.1. DTN Routing Protocol Number The encoding of the Protocol Number field in the GORF header (Section 5.1) is: +--------------------------+-----------+------------------------+ | Protocol | Value | Allocation Control | +--------------------------+-----------+------------------------+ | PRoPHET Protocol | 0x00 | RFC6693 | | | | | | GORF Protocol | 0x01 | This document | | | | | | Reserved | 0x02-0xEF | Specification required | | | | | | Private/Experimental use | 0xF0-0xFE | Experimental | +--------------------------+-----------+------------------------+ 8.2. GORF Protocol Version The encoding of the GORF Version field in the GORF header (Section 5.1) is: +------------------------------+-----------+------------------------+ | Version | Value | Allocation Control | +------------------------------+-----------+------------------------+ | Reserved | 0x00 | (Do not allocate) | | | | | | This protocol | 0x01 | This document | | | | | | Reserved | 0x02-0xEF | Specification required | | | | | | Private | 0xF0-0xFE | Experimental | | | | | | Reserved for future | 0xFF | Specification required | | expansion | | | +------------------------------+-----------+------------------------+ Lindgren, et al. Expires February 1, 2014 [Page 85] Internet-Draft GORF July 2013 8.3. GORF Header Flags The following Flags are defined for the GORF Header (Section 5.1): +----------+--------------+------------------------+ | Meaning | Bit Position | Explanation | +----------+--------------+------------------------+ | Reserved | Bit 0 | Specification required | | | | | | Reserved | Bit 1 | Specification required | | | | | | Reserved | Bit 2 | Specification required | | | | | | Reserved | Bit 3 | Specification required | +----------+--------------+------------------------+ 8.4. GORF Result Field The encoding of the Result field in the GORF header (Section 5.1) is: +--------------------------+-------------+------------------------+ | Result Value | Value | Allocation Control | +--------------------------+-------------+------------------------+ | NoSuccessAck | 0x01 | This document | | | | | | AckAll | 0x02 | This document | | | | | | Success | 0x03 | This document | | | | | | Failure | 0x04 | This document | | | | | | ReturnReceipt | 0x05 | This document | | | | | | Reserved | 0x06 - 0x7F | Specification required | | | | | | Private/Experimental Use | 0x80 - 0xFF | Experimental | +--------------------------+-------------+------------------------+ Lindgren, et al. Expires February 1, 2014 [Page 86] Internet-Draft GORF July 2013 8.5. GORF Codes for Success and Codes for Failure The encoding for Code field in the GORF header (Section 5.1) for "Success" messages is: +--------------------------+-------------+------------------------+ | Code Name | Values | Allocation Control | +--------------------------+-------------+------------------------+ | Generic Success | 0x00 | This document | | | | | | Submessage Received | 0x01 | This document | | | | | | Reserved | 0x02 - 0x7F | Specification required | | | | | | Private/Experimental Use | 0x80 - 0xFF | Experimental | +--------------------------+-------------+------------------------+ The encoding for Code in the GORF header (Section 5.1) for "Failure" messages is: +--------------------------+-------------+------------------------+ | Code Name | Values | Allocation Control | +--------------------------+-------------+------------------------+ | Reserved | 0x00 - 0x01 | (Do not allocate) | | | | | | Unspecified Failure | 0x02 | This document | | | | | | Reserved | 0x03 - 0x7F | Specification required | | | | | | Private/Experimental Use | 0x80 - 0xFE | Experimental | | | | | | Error TLV in message | 0xFF | This document | +--------------------------+-------------+------------------------+ Lindgren, et al. Expires February 1, 2014 [Page 87] Internet-Draft GORF July 2013 8.6. GORF TLV Type The TLV Types defined for GORF (Section 5.2) are: +--------------------------+-------------+------------------------+ | Type | Value | Allocation Control | +--------------------------+-------------+------------------------+ | Hello TLV | 0x01 | This document | | | | | | Error TLV | 0x02 | This document | | | | | | Reserved | 0x03 - 0x9F | Specification required | | | | | | RIB dictionary TLV | 0xA0 | This document | | | | | | RIB TLV | 0xA1 | This document | | | | | | Bundle Offer | 0xA2 | (Deprecated) | | | | | | Bundle Response | 0xA3 | (Deprecated) | | | | | | Bundle Offer (v2) | 0xA4 | This document | | | | | | Bundle Response (v2) | 0xA5 | This document | | | | | | Reserved | 0xA6 - 0xCF | Specification required | | | | | | Private/Experimental Use | 0xD0 - 0xFF | Experimental | +--------------------------+-------------+------------------------+ Lindgren, et al. Expires February 1, 2014 [Page 88] Internet-Draft GORF July 2013 8.7. Hello TLV Flags The following TLV Flags are defined for the Hello TLV (Section 5.3.1). Flag numbers 0, 1 and 2 are treated as a three bit unsigned integer with five of the eight possible values allocated and the other three reserved. The remaining bits are treated individually: +----------+-------------------+------------------------+ | Meaning | Value | Allocation Control | +----------+-------------------+------------------------+ | | (Flags 0,1 and 2) | | | | | | | Reserved | 0b000 | Do not allocate | | | | | | SYN | 0b001 | This document | | | | | | SYNACK | 0b010 | This document | | | | | | ACK | 0b011 | This document | | | | | | RSTACK | 0x100 | This document | | | | | | Reserved | 0b101 - 0b111 | Specification required | | | | | | | (Flags 3 - 7) | | | | | | | Reserved | Flag 3 | Specification required | | | | | | Reserved | Flag 4 | Specification required | | | | | | Reserved | Flag 5 | Specification required | | | | | | Reserved | Flag 6 | Specification required | | | | | | L Flag | Flag 7 | This document | +----------+-------------------+------------------------+ Lindgren, et al. Expires February 1, 2014 [Page 89] Internet-Draft GORF July 2013 8.8. Error TLV Flags The TLV Flags field in the Error TLV (Section 5.3.2) is treated as an unsigned 8 bit integer encoding the Error TLV number. The following values are defined: +---------------------+------------------+------------------------+ | Error TLV Name | Error TLV Number | Allocation Control | +---------------------+------------------+------------------------+ | Dictionary Conflict | 0x00 | This document | | | | | | Bad String ID | 0x01 | This document | | | | | | Reserved | 0x02 - 0x7F | Specification required | | | | | | Private | 0x80 - 0xFF | Experimental | +---------------------+------------------+------------------------+ 8.9. RIB Dictionary TLV Flags The following TLV Flags are defined for the RIB Base Dictionary TLV (Section 5.3.3): +------------------+--------------+------------------------+ | Meaning | Bit Position | Allocation Control | +------------------+--------------+------------------------+ | Sent by Listener | Flag 0 | This document | | | | | | Reserved | Flag 1 | Reserved | | | | | | Reserved | Flag 2 | Reserved | | | | | | Reserved | Flag 3 | Specification required | | | | | | Reserved | Flag 4 | Specification required | | | | | | Reserved | Flag 5 | Specification required | | | | | | Reserved | Flag 6 | Specification required | | | | | | Reserved | Flag 7 | Specification required | +------------------+--------------+------------------------+ Lindgren, et al. Expires February 1, 2014 [Page 90] Internet-Draft GORF July 2013 8.10. RIB TLV Flags The following TLV Flags are defined for the RIB TLV (Section 5.3.4): +---------------+--------------+------------------------+ | Meaning | Bit Position | Allocation Control | +---------------+--------------+------------------------+ | More RIB TLVs | Flag 0 | This document | | | | | | Reserved | Flag 1 | Reserved | | | | | | Reserved | Flag 2 | Reserved | | | | | | Reserved | Flag 3 | Specification required | | | | | | Reserved | Flag 4 | Specification required | | | | | | Reserved | Flag 5 | Specification required | | | | | | Reserved | Flag 6 | Specification required | | | | | | Reserved | Flag 7 | Specification required | +---------------+--------------+------------------------+ Lindgren, et al. Expires February 1, 2014 [Page 91] Internet-Draft GORF July 2013 8.11. RIB Flags The following RIB Flags are defined for the individual entries in the RIB TLV (Section 5.3.4): +----------+--------------+------------------------+ | Meaning | Bit Position | Allocation Control | +----------+--------------+------------------------+ | Reserved | Flag 0 | Specification required | | | | | | Reserved | Flag 1 | Specification required | | | | | | Reserved | Flag 2 | Specification required | | | | | | Reserved | Flag 3 | Specification required | | | | | | Reserved | Flag 4 | Specification required | | | | | | Reserved | Flag 5 | Specification required | | | | | | Reserved | Flag 6 | Specification required | | | | | | Reserved | Flag 7 | Specification required | +----------+--------------+------------------------+ Lindgren, et al. Expires February 1, 2014 [Page 92] Internet-Draft GORF July 2013 8.12. Bundle Offer and Response TLV Flags The following TLV Flags are defined for the Bundle Offer and Response TLV (Section 5.3.5): +------------------------------+-------------+----------------------+ | Meaning | Bit | Allocation Control | | | Position | | +------------------------------+-------------+----------------------+ | More Offer/Response TLVs | Flag 0 | This document | | Following | | | | | | | | Reserved | Flag 1 | Specification | | | | required | | | | | | Reserved | Flag 2 | Specification | | | | required | | | | | | Reserved | Flag 3 | Specification | | | | required | | | | | | Reserved | Flag 4 | Specification | | | | required | | | | | | Reserved | Flag 5 | Specification | | | | required | | | | | | Reserved | Flag 6 | Specification | | | | required | | | | | | Reserved | Flag 7 | Specification | | | | required | +------------------------------+-------------+----------------------+ Lindgren, et al. Expires February 1, 2014 [Page 93] Internet-Draft GORF July 2013 8.13. Bundle Offer and Response B Flags The following B Flags are defined for each Bundle Offer in the Bundle Offer and Response TLV (Section 5.3.5): +--------------------------------+------------+---------------------+ | Meaning | Bit | Allocation Control | | | Position | | +--------------------------------+------------+---------------------+ | Bundle Accepted | Flag 0 | This document | | | | | | Bundle is a Fragment | Flag 1 | This document | | | | | | Bundle Payload Length Included | Flag 2 | This document | | in TLV | | | | | | | | Reserved | Flag 3 | Specification | | | | required | | | | | | Reserved | Flag 4 | Specification | | | | required | | | | | | Reserved | Flag 5 | Specification | | | | required | | | | | | Reserved | Flag 6 | Specification | | | | required | | | | | | GORF Ack | Flag 7 | This document | +--------------------------------+------------+---------------------+ Lindgren, et al. Expires February 1, 2014 [Page 94] Internet-Draft GORF July 2013 9. Acknowledgements ... Lindgren, et al. Expires February 1, 2014 [Page 95] Internet-Draft GORF July 2013 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. 10.2. Informative References [I-D.irtf-dtnrg-tcp-clayer] Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant Networking TCP Convergence Layer Protocol", draft-irtf-dtnrg-tcp-clayer-06 (work in progress), May 2013. [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011. Lindgren, et al. Expires February 1, 2014 [Page 96] Internet-Draft GORF July 2013 Authors' Addresses Anders F. Lindgren SICS Swedish ICT Box 1263 Kista SE-164 29 SE Phone: +46707177269 Email: andersl@sics.se URI: http://www.sics.se/~andersl Elwyn Davies Folly Consulting Soham UK Phone: Email: elwynd@folly.org.uk URI: Avri Doria Consultant Providence RI US Phone: Email: avri@acm.org URI: http://psg.com/~avri Lindgren, et al. Expires February 1, 2014 [Page 97]