Internet DRAFT - draft-dowdell-dtnwg-static
draft-dowdell-dtnwg-static
Delay-Tolerant Networking Working Group J. Dowdell
Internet-Draft Airbus Defence and Space
Intended status: Standards Track N. Benamar
Expires: January 7, 2016 Universite Moulay Ismail
July 6, 2015
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
Dowdell & Benamar Expires January 7, 2016 [Page 1]
Internet-Draft DTN Static Routing July 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Static Routing . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Endpoint Identifier . . . . . . . . . . . . . . . . . . . 5
3.3. Convergence Layer . . . . . . . . . . . . . . . . . . . . 6
3.4. Metric . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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
Dowdell & Benamar Expires January 7, 2016 [Page 2]
Internet-Draft DTN Static Routing July 2015
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
Dowdell & Benamar Expires January 7, 2016 [Page 3]
Internet-Draft DTN Static Routing July 2015
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
Dowdell & Benamar Expires January 7, 2016 [Page 4]
Internet-Draft DTN Static Routing July 2015
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
Dowdell & Benamar Expires January 7, 2016 [Page 5]
Internet-Draft DTN Static Routing July 2015
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.
Dowdell & Benamar Expires January 7, 2016 [Page 6]
Internet-Draft DTN Static Routing July 2015
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
Dowdell & Benamar Expires January 7, 2016 [Page 7]
Internet-Draft DTN Static Routing July 2015
7.1. Normative References
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[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.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram
Convergence Layers for the Delay- and Disruption-Tolerant
Networking (DTN) Bundle Protocol and Licklider
Transmission Protocol (LTP)", RFC 7122, March 2014.
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant
Networking TCP Convergence-Layer Protocol", RFC 7242, June
2014.
Authors' Addresses
John Dowdell
Airbus Defence and Space
Celtic Springs
Newport, Wales NP10 8FZ
United Kingdom
Email: john.dowdell.ietf@gmail.com
Dowdell & Benamar Expires January 7, 2016 [Page 8]
Internet-Draft DTN Static Routing July 2015
Nabil Benamar
Universite Moulay Ismail
Presidence, Marjane 2 BP:298
Meknes
Morocco
Email: benamar73@gmail.com
Dowdell & Benamar Expires January 7, 2016 [Page 9]
