Static Routing for DTN
draft-dowdell-dtnwg-static-00

Abstract

Static Routing in Delay-Tolerant Networks cannot make full use of standard IPv4 or IPv6 static routing as defined in section 7.4 of [RFC1812], due to the DTN feature of Late Binding where the IP address or addresses associated with an Endpoint Identifier may not be known when a packet is originated. This draft presents a specification for static routing in the DTN environment.

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 January 7, 2016.

Copyright Notice

Copyright (c) 2015 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. Overview
• 2. Terminology
• 3. Static Routing
• 3.1. Introduction
• 3.2. Endpoint Identifier
• 3.3. Convergence Layer
• 3.4. Metric
• 3.5. Time
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgments
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Overview

The static routing protocol for Delay-Tolerant Networks (DTN) enables the forwarding of traffic towards an Endpoint along a path which has been manually configured by an administrator. The path may be minimally defined by a combination of Endpoint identifier and a DTN Convergence Layer, optionally supplemented by other attributes as available.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document also uses the following terminology directly extracted from [RFC5050] and expanded with additional text as follows:

Bundle

A bundle is a protocol data unit of the DTN Bundle Protocol, which defines a series of contiguous data blocks as a bundle. Each bundle serves a different purpose and contains enough semantic and associated information to permit to application to perform a transaction, where an individual data block may not. The goal is to reduce Round-trip exchanges by bundling together all the information required for a transaction, which is useful in DTN environment. Multiple instances of the same bundle (the same unit of DTN protocol data) might exist concurrently in different parts of a network - possibly in different representations - in the local memory of one or more bundle nodes and/or in transit between nodes. In the context of the operation of the bundle node, a bundle is an instance of some bundle in the network that is in that node's local memory.

Bundle Payload

A bundle payload (or simply "payload") is the application data whose conveyance to the bundle's destination is the purpose for the transmission of a given bundle. The terms "bundle content", "bundle payload" and "payload" are used interchangeably in this document. The "nominal" payload for a bundle forwarded in response to a bundle transmission request is the application data unit whose location is provided as a parameter to that request. The nominal payload for a bundle forwarded in response to the reception of that bundle is the payload of the received bundle.

Bundle Node

A bundle node (or, in the context of this document, simply a "node") is any entity that can send and/or receive bundles in the DTN environment based on the store-carry and forward paradigm. In the most familiar case, a bundle node is instantiated as a single process running on a general-purpose computer, but in general the definition is meant to be broader: a bundle node might alternatively be a thread, an object in an object-oriented operating system, a special-purpose hardware device, etc. Each bundle node has three conceptual components, defined below: a "bundle protocol agent", a set of zero or more "convergence layer adapters", and an "application agent".

Bundle Protocol Agent

The Bundle Protocol Agent (BPA) of a node is the node component that offers the BP services and executes the procedures of the bundle protocol. The manner in which it does so is wholly an implementation matter. For example, BPA functionality might be coded into each node individually; it might be implemented as a shared library that is used in common by any number of bundle nodes on a single computer; it might be implemented as a daemon whose services are invoked via interprocess or network communication by any number of bundle nodes on one or more computers; it might be implemented in hardware.

Convergence Layer Adaptor

A Convergence Layer Adaptor (CLA) sends and receives bundles on behalf of the BPA, utilising the services of some 'native' internet protocol that is supported in one of the internets within which the node is functionally located. The manner in which a CLA sends and receives bundles is wholly an implementation matter, exactly as described for the BPA.

Bundle Endpoint

A Bundle Endpoint (or simply "endpoint") is a set of zero or more bundle nodes that all identify themselves for BP purposes by some single text string, called a "bundle endpoint ID" (or, in this document, simply "endpoint ID"; endpoint IDs are described in detail in section 4.4 of [RFC5050]). The special case of an endpoint that never contains more than one node is termed a "singleton" endpoint; every bundle node must be a member of at least one singleton endpoint. Singletons are the most familiar sort of endpoint, but in general the endpoint notion is meant to be broader. For example, the nodes in a sensor network might constitute a set of bundle nodes that identify themselves by a single common endpoint ID and thus form a single bundle endpoints. Note also that a given bundle node might identify itself by multiple endpoint IDs and thus be a member of multiple bundle endpoints.

Forwarding

When the bundle protocol agent of a node determines that a bundle must be "forwarded" to an endpoint, it causes the bundle to be sent to all of the nodes that the bundle protocol agent currently believes are in the "minimum reception group" of that endpoint. The minimum reception group of an endpoint may be any of the following: (a) ALL of the nodes registered in an endpoint that is permitted to contain multiple nodes (in which case forwarding to the endpoint is functionally similar to "multicast" operations in the Internet, though possibly very different in implementation); (b) ANY N of the nodes registered in an endpoint that is permitted to contain multiple nodes, where N is the range from zero to the cardinality of the endpoint (in which case forwarding to the endpoint is functionally similar to "any cast" operations on the Internet); or (c) THE SOLE NODE registered in a singleton endpoint (in which case forwarding to the endpoint is functionally similar to "unicast" operations on the Internet). The nature of the minimum reception group for a given endpoint can be determined from the endpoint's ID (again, see section 4.4 of [RFC5050]): for some endpoint ID "schemes", the nature of the minimum reception group is fixed - in a manner that is defined by the scheme - for all endpoints identified under the scheme; for other schemes, the nature of the minimum reception group is indicated by some lexical feature of the "scheme-specific part" of the endpoint ID, in a manner that is defined by the scheme.

Transmission

A transmission is a sustained effort by a node's bundle protocol agent to cause a bundle to be sent to all nodes in the minimum reception group of some endpoint (which may be the bundle's destination or may be some intermediate forwarding endpoint) in response to a transmission request issued by the node's application agent. Any number of transmissions may be concurrently undertaken by the bundle protocol agent of a given node.

3. Static Routing

3.1. Introduction

As stated in section 7.4 of [RFC1812], static routing provides a means of explicitly defining the next hop from a router for a particular destination, typically by administrative configuration. A router SHOULD therefore provide a means for defining a static route to a destination. However, in Delay Tolerant Networks (DTNs) it may not be possible to define such a destination by a network prefix, since the network prefix may not be known at the time of transmission. In DTNs, the Endpoint is addressed primarily through the mechanism of the Endpoint Identifier, an identifier based on the Universal Resource Identifier as tailored to DTNs.

In order to select a path to a distant Endpoint Identifier, the static routing protocol SHALL establish a set of information comprising as a minimum the Endpoint Identifier of the next hop and the Convergence Layer that is available to transport the Bundle to the next hop.

Additionally, the set of information SHALL also include a metric where a dynamic routing protocol is also employed on the router to aid in the process of next hop selection. The set of information MAY also include additional attributes of the path to the next hop where such attributes are useful or are provisioned on the Convergence Layer. One such attribute is Time, or more correctly the time period between which the connection through the Convergence Layer is available.

The elements comprising the set of information are further discussed below.

3.2. Endpoint Identifier

The concept of Endpoint Identifiers is explained in section 3.3 of [RFC4838], each Identifier being used to identify a Bundle Endpoint. Therefore in a DTN router, the processes that enable the static routing feature require access to a forwarding table that SHALL have a means of recording the Endpoint Identifiers that can be reached through static routing, even if there is not an entry for the Endpoint Identifier in question.

3.3. Convergence Layer

It is not uncommon in Delay Tolerant Networks to use transport protocols other than the well known Transmission Control Protocol [RFC0793] and User Datagram Protocol [RFC0768], and as stated in section 6 of [RFC4838] not all those transport protocols provide the same exact functionality, hence some adaptation or augmentation on a per-protocol or per-protocol family may be required. The adaptation or augmentation is accomplished by the Convergence Layer which then presents a consistent interface to the bundle layer. Examples of Convergence Layers are described in [RFC7122] and [RFC7242].

Therefore against each Endpoint Identifier that is listed in the means of explicitly defining the next hop, the Convergence Layer used to transport the Bundle to the next hop SHALL be identified.

The route lookup algorithm is based upon a comparison of the wanted distant Endpoint Identifier with those available in the set of information, but given the complexity of performing a trade-off between Convergence Layers for approximately matching Endpoint identifiers, the lookup algorithm is for further study. Where two or more Convergence Layers are identified for the same distant and next hop Endpoint Identifiers, the method of choosing between those Convergence Layers is for further study.

3.4. Metric

As also stated in [RFC1812], the static routing mechanism SHOULD also allow for a metric to be defined for each static route. Where two or more next hops are defined for an Endpoint ID, the metric value will allow the router to select which next hop to use to forward the Bundle concerned, based on the state of the presence of the next hop.

Where one or more dynamic routing protocols are also present on the router supporting static routing, the metric value associated with each of the static route(s) MAY be taken into account by the dynamic routing protocol in selecting the next hop, where the preference between static and dynamic routes MAY be configured administratively.

3.5. Time

Delay Tolerant Networks are typically comprised of mobile nodes, such that the connection between nodes is limited in time, typically due to wireless connections being out of range. In some networks, including networks where energy conservation is a key factor, it is advantageous to schedule connectivity 'windows' when it is expected that Transmission and Reception will occur. How such scheduling information is acquired is out of scope for this draft. The accuracy of the locally-known time in relation to some coordinated time is also out of scope for this draft.

Where present, the Time attribute SHALL be comprised of StartTime and EndTime, indicating the earliest time that Transmission or Reception (or both) MAY commence to or from that next hop Endpoint, and the time by which the Transmission or Reception (or both) SHALL cease.

4. IANA Considerations

There are no IANA considerations at this time.

5. Security Considerations

Security considerations for this routing protocol are for further study. However since this protocol is configured manually, either by direct access to the router concerned, or by the distribution of configuration data by remote file transfer or a network management protocol, standard precautions regarding security of management access and control apply, including the authentication of management users and appropriately securing the local or remote access protocol used to connect to the management agent of the router.

6. Acknowledgments

The authors are indebted to the DTN Research Group and the wealth of information that has been published, and for the implementation of the protocols embodied in DTN2 code including static routing. The authors also acknowledge the work of NASA JPL in developing the ION implementation of certain DTN and CCSDS protocols, also including static routing.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses