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]