Internet DRAFT - draft-lindgren-dtnrg-gorf
draft-lindgren-dtnrg-gorf
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: <n> (octet)
Type[1]: <Type value> (octet)
Type parameter[1]: <<Optional type parameters> (octet)
.
.
.
Type[n]: <Type value>
Type parameter[n]: <Optional type parameters>
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]
