[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            W. Eddy
Internet-Draft                           Verizon Federal Network Systems
Expires: November 26, 2006                                  May 25, 2006

  Architectural Considerations for the use of Endpoint Identifiers in
                       Delay Tolerant Networking

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   The architecture for Delay Tolerant Networking includes a type of
   address called an Endpoint Identifier.  This document describes some
   of the remaining issues regarding Endpoint Indentifiers, and how they
   can be configured and used in bundle forwarding.  These either imply
   directions for future work or highlight clarifications that should be
   made in the current architecture and protocol documents.

Eddy                    Expires November 26, 2006               [Page 1]

Internet-Draft                 EIDs in DTN                      May 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  EID Basics . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Bundling Node Configuration  . . . . . . . . . . . . . . . . .  5
   4.  Application Registration . . . . . . . . . . . . . . . . . . .  6
   5.  Bundle Processing Rules  . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   10.   Informative References . . . . . . . . . . . . . . . . . . . 12
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
       Intellectual Property and Copyright Statements . . . . . . . . 14

Eddy                    Expires November 26, 2006               [Page 2]

Internet-Draft                 EIDs in DTN                      May 2006

1.  Introduction

   The Delay Tolerant Networking (DTN) architecture is centered on the
   concept of "bundling" application data, and then exchanging bundles
   between nodes [CBH+06].  Endpoint Identifiers (EIDs) are variable-
   length strings used to refer to nodes that send, receive, or forward
   bundles.  An EID may refer to one or more nodes, and an individual
   node may have more than one EID.

   Conceptually, EIDs are well motivated and explained in the DTN
   architecture description, and they are used in several places within
   the DTN Bundle Protocol header [SB05].  However, there is no document
   that explains how EIDs are assigned to nodes, how applications
   register with bundling agents, or how forwarding decisions can be
   made based on EIDs.  There have been mailing list discussions on
   these topics, and the DTN2 Reference Implementation (RI) of the
   Bundle Protocol uses certain rules (we refer to the DTN2 RI version
   2.2.0 in this document).  In this document, we summarize some of the
   mailing list threads regarding these subjects, and describe how the
   DTN2 code operates.  The configuration and processing rules contained
   in this document are not necessarily final or normative; this is only
   an informational snapshot of current thinking and practices in the
   DTNRG.  Some of the issues brought to light in this document may
   cause future iterations that are considerably different.

   Section 2 contains a basic description of EIDs based on the DTN
   architecture and DTN2 RI.  Some ways that a DTN bundle agent might
   configure an EID are discussed in Section 3, and methods for
   applications to register EIDs are described in Section 4.  Security
   implications of EID usage are explained in Section 6.  Finally,
   several outstanding issues that have been uncovered are listed in
   Section 7.

Eddy                    Expires November 26, 2006               [Page 3]

Internet-Draft                 EIDs in DTN                      May 2006

2.  EID Basics

   The Uniform Resource Identifier (URI) standard [RFC3986] has been
   selected as the format for representing EIDs in the DTN architecture.
   URIs are used in several Internet protocols.  For the purposes of the
   DTN protocols, the URI syntax is described as an EID scheme
   identifier followed by a scheme specific part (SSP).  This allows
   multiple naming conventions (schemes) to be used in conjunction with
   the basic DTN protocols.  The current DTN specifications do not fully
   define the use of any EID schemes.  Interoperability between nodes
   using different schemes may be possible, but exact mechanisms for
   this have also not been described at this time.

   The use of EIDs has evolved from early DTN work that used the notion
   of regions.  Each node address identified a region, and contained a
   portion which was unique within that region, but with no other
   restrictions on formating [CBH+03].  This is similar in principle to
   the EID definition, since assignment of EID schemes will be regulated
   by IANA, however a notable difference is that there are no
   stipulations in the current DTN architecture that SSPs be unique
   within a scheme.

   EIDs may be of unicast, anycast, or multicast types.  The
   architecture states minimum reception group (MRG) of an EID can be
   determined by a node using the EID itself.  This is not very clear in
   the current architecture.  The way EIDs have been defined, it is more
   correct to say that at least "some" node can determine the MRG of an
   EID, rather than "a" node, which would seem to imply that any node
   could resolve an EID into an MRG.  This clearly is not the case since
   there is no guarantee that every node even understands the EID

   The "dtn" EID scheme is discussed briefly in the current
   documentation, but its SSP and usage are not.  The only concrete data
   on this scheme is that the special "none" SSP is set aside.  The DTN2
   RI classifies valid "dtn" bundle agent SSPs as consisting of
   alphanumeric characters, underscores, dashes, and periods.  To
   identify applications, "service tags" are appended to the bundle
   agent SSPs.  This does not seem to be driven by the bundle protocol
   specification or DTN architecture documents, although it certainly
   works well for the purposes of near-term experimentation and
   demonstration.  The DTN2 RI also supports an "eth" scheme where the
   SSP is an Ethernet MAC address represented in a certain format.

Eddy                    Expires November 26, 2006               [Page 4]

Internet-Draft                 EIDs in DTN                      May 2006

3.  Bundling Node Configuration

   The DTN2 RI uses a configuration file directive to set the local EID
   of a bundling agent.  The default action is to use the "dtn" scheme,
   and create an EID of the form "hostname.dtn", where the "hostname"
   portion is substituted with the host operating system's configured
   hostname.  The DTN specification documents do not codify that this is
   how EIDs in the "dtn" scheme are to be formatted or constructed.
   This method works well for demonstration purposes and small-scale
   deployments, but does not provide any expectation of uniqueness.
   Since autoconfiguration methods that guarantee global uniqueness may
   be difficult to make delay-insensitive, in order to be useful for
   small-scale experimentation and deployments in the short-term, the
   "dtn" scheme should probably be defined to preclude any such
   expectations.  It should be encouraged that other schemes be
   developed with allow for uniqueness and that these be used in real-
   world deployments, outside of laboratory or demonstration use.  One
   simple way to provide uniqueness is for bundle agents to be assigned
   EIDs from a central authority, similar to the way that DHCP assigns
   IP addresses, however pre-arranged manual assignment and
   configuration may be required in some DTN scenarios due to high-

   If DTN bundling agents become used in multiple contexts, it is
   possible that certain agents may end up bridging DTNs that are not
   commonly administered.  This could cause unforeseen issues if the
   DTNRG does not produce naming schemes that yield some expectation of
   uniqueness in a self-configured EID, or a guarantee of uniqueness in
   an assigned EID.  Designing multiple naming schemes with different
   characteristics and use cases should be a primary focus area of the
   DTNRG's future efforts, as well as more fully explaining the intended
   format and use of the "dtn" scheme.

   In addition to uniqueness, another consideration in defining naming
   schemes is route aggregation.  When routing protocols are adopted for
   DTNs, in order to limit the size of advertisements, memory required
   to hold tables, time to search tables, and power draw from all of
   these factors, EID SSP conventions should allow for aggregation in
   some way.  Otherwise the scale and scope of DTNs might be
   artificially limited by the naming schemes available.  Hierarchically
   structured EIDs are one means of acheiving aggregatability.  EID
   schemes derived from fully-qualified domain names and/or IP addresses
   could serve as examples.

Eddy                    Expires November 26, 2006               [Page 5]

Internet-Draft                 EIDs in DTN                      May 2006

4.  Application Registration

   The present architecture document is unclear on how exactly
   applications interface with bundling agents.  It is stated that
   applications express an interest in receiving data for particular
   EIDs and send data to particular EIDs, but it is not stated whether
   portions of the EID SSP should identify applications (in addition to
   nodes), or whether the SSP merely identifies a node, and some other
   multiplexing and demultiplexing is used to deliver the correct data
   to the correct applications.  This is a point that should be
   clarified, although the answer is fairly obvious based on the
   protocol specifications.

   One other point of clarification regards whether applications
   construct their own EIDs or are assigned EIDs by the bundle agent as
   part of the registration proceedure.  Another cloudy topic is whether
   an application can register an EID with a bundle agent that does not
   understand the scheme portion of the requested EID.

   In the DTN2 RI, and the "dtnping" application as an example, node
   EIDs are constructed by applications themselves appending their a
   string consisting of the application name and operating system
   process ID to the bundle agent's EID.  Registration of this
   application EID is requested of the bundle agent, and can either pass
   or fail.  Before the application closes, it requests that the
   registration be closed.

   The topic of closing EID registrations is important, since
   applications may cease running without knowledge of the bundling
   agent.  This is especially and issue when applications and bundling
   agents are not co-located on the same physical node, since network
   connectivity is assumed to be dynamic in DTNs.  An application SHOULD
   try to reliably close registrations, and a bundling agent SHOULD have
   a way of polling existing registrations for liveliness and reaping
   them as deemed appropriate for specific environments.  In some
   situations this will be more of an issue than in others, due to
   particular resource tradeoffs between persistent memory utilization,
   power and bandwidth needed to transmit and respond to registration
   keep-alives, etc.

   Application registration presents another interesting problem in that
   bundles must be addressed to remote application instances.  Without
   naming schemes that allow for either wildcarding or indirection, it
   will be difficult to efficiently send data to remote peer application
   instances.  In traditional Internet transports, this problem is
   reduced by the use of "well-known" port numbers, so DTN naming
   schemes may consider providing "well-known" SSP suffixes to help
   refer to application instances, along with other demultiplexing

Eddy                    Expires November 26, 2006               [Page 6]

Internet-Draft                 EIDs in DTN                      May 2006


Eddy                    Expires November 26, 2006               [Page 7]

Internet-Draft                 EIDs in DTN                      May 2006

5.  Bundle Processing Rules

   For the most part, the bundling protocol specification contains only
   a description of the bundle format and some rules for validity of
   bundles.  Specifically, it does not specify (nor does any companion
   document, at this time) rules for a bundling agend to configure its
   own EID or make forwarding decisions regarding incoming bundles based
   on their destination EIDs.  Of course, these are ancillary to the
   protocols wire-format and can be specified elsewhere, as has been
   done for IP.  Nevertheless, these are holes that require filling to
   complete the DTN architecture.

   A natural set of processing rules for incoming bundles starts with
   ascertaining whether the destination EID scheme is understood by the
   bundle agent.  If the destination EID is not understood, processing
   can no longer continue, but the action that should be taken is
   unclear.  Should a failure report be sent back to the report-to EID?
   What if the reply-to EID's scheme is not understood?  Perhaps, as a
   fall-back the bundle should be dropped.  Or maybe it should be placed
   in storage until it can be handed off to either another agent (for
   instance, via a "default" route).  Should support for the destination
   EID be evaluated before accepting custody of the bundle?

   Assuming the EID scheme is recognized and understood locally, there
   are still other failure modes when decoding the SSP.  For instance,
   what if the SSP is malformed with respect to what the bundle agent
   thinks that the EID scheme rules are?  This could arise if EID scheme
   definitions evolve in non-forwards or backwards-compatible ways.
   Should a similar action be taken in this case as if the EID scheme
   itself is not locally supported, or is a different response
   warranted?  Should the SSP be parsed and evaluated before accepting
   bundle custody?

   There is a related case of what should be done when the SSP can be
   parsed, but for some other reason it is non-routable.  For instance,
   if the SSP indicated an IPv4 private address space and the local
   bundle agent did not have a convergence layer adaptor capable of
   reaching that address space.  Again, it should be considered whether
   this type of error results in behavior similar to other failures we
   have listed, or whether different actions are desirable.  This may
   even require evaluation on a per-scheme or per-convergence layer

Eddy                    Expires November 26, 2006               [Page 8]

Internet-Draft                 EIDs in DTN                      May 2006

6.  Security Considerations

   The security considerations regarding EIDs are very similar to those
   regarding IP addreses as described in the context of routing and
   neighbor discover protocols [BMY04] [RFC3756].  The security threats
   are more relevent to the actual forwarding of bundles and routing
   exchanges that determine later forwarding decisions than the more
   general mechanics of how names are assigned and used.  Fully
   exploring these issues and providing solutions is outside the context
   of this document.  The security overview document [FSW06] describes a
   number of open issues in DTN security, some of which are related to
   naming and addressing.

Eddy                    Expires November 26, 2006               [Page 9]

Internet-Draft                 EIDs in DTN                      May 2006

7.  Outstanding Issues

   In this document, we have identified a number of outstanding issues
   that are unclear in the DTN architecture, as currently described:

   o  Should a base EID scheme be defined, perhaps utilizing the "dtn"
      identifier?  This does not mean that all EIDs would use this
      scheme and would not prevent the definition and use of other
      schemes, but it would provide a basis for interoperability between
      differing implementations without parties pre-arranging EID rules
      outside of the specification documents.  The use of hostnames in
      the DTN2 RI does not seem fully appropriate for this purpose.  An
      understanding of what would be desirable in a minimally-supported
      EID scheme could be helpful, along the lines of work done in the
      NSRG [LD03].

   o  What are some methods that assignment and configuration of SSPs
      can be performed within various schemes in a way that is both
      collision-resistant and not prone to breakdown under high delay
      (among other typical factors in DTNs).

   o  Should the function of mapping EIDs into MRGs be clarified to only
      be required to be possible by at least one node (identified as
      part of the EID), or by all nodes that can parse the EID scheme?
      This affects forwarding decisions

   o  Does registration necessarily entail obtaining an extended version
      of the bundling agent's EID?  Does an application request some
      portion of its EID, or is it fully assigned?  Does a bundling node
      have to know how to parse all the schemes of application EIDs
      registered with it?

   o  Do more formal guidelines regarding the removal, closing, and
      expiration of registrations need to be drafted?  What are the
      security implications?

   o  Exactly which operations with regards to parsing and resolving the
      various EIDs contained in a bundle must take place before
      accepting custody of the bundle?

   o  What failure modes should a bundle agent be configured with in
      order to handle cases where it receives bundles with EID schemes
      or EID SSPs that it does not understand or is not capable of
      reaching even indirectly (e.g.  IPv4 private address space from a
      public router)?  Does the architecture need to define this, or
      what will be the result if different implementations support
      different behaviors in these types of failure modes?

Eddy                    Expires November 26, 2006              [Page 10]

Internet-Draft                 EIDs in DTN                      May 2006

8.  IANA Considerations

   This document has no IANA considerations.

Eddy                    Expires November 26, 2006              [Page 11]

Internet-Draft                 EIDs in DTN                      May 2006

9.  Acknowledgements

   Many others have participated in the DTNRG discussions on naming and
   contributed to the DTN2 RI.  This document is only a synopsis of
   their work and conversations.

   Work on this document was performed at NASA's Glenn Research Center,
   in support of the NASA Space Communications Architecture Working
   Group (SCAWG), and the FAA/Eurocontrol Future Communications Study

10.  Informative References

   [BMY04]    Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
              Routing Protocols",
              draft-ietf-rpsec-routing-threats-07 (work in progress),
              October 2004.

   [CBH+03]   Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Network Architecture", draft-irtf-dtnrg-arch-00 (expired),
              March 2003.

   [CBH+06]   Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Network Architecture", draft-irtf-dtnrg-arch-05 (work in
              progress), March 2006.

   [FSW06]    Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant
              Networking Security Overview",
              draft-irtf-dtnrg-sec-overview-01 (work in progress),
              March 2006.

   [LD03]     Lear, E. and R. Droms, "What's In A Name: Thoughts from
              the NSRG", draft-irtf-nsrg-report-10 (expired),
              September 2003.

   [RFC3756]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
              Discovery (ND) Trust Models and Threats", RFC 3756,
              May 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [SB05]     Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", draft-irtf-dtnrg-bundle-spec-04 (work in
              progress), November 2005.

Eddy                    Expires November 26, 2006              [Page 12]

Internet-Draft                 EIDs in DTN                      May 2006

Author's Address

   Wesley M. Eddy
   Verizon Federal Network Systems
   NASA Glenn Research Center
   21000 Brookpark Rd, MS 54-5
   Cleveland, OH  44135

   Phone: 216-433-6682
   Email: weddy@grc.nasa.gov

Eddy                    Expires November 26, 2006              [Page 13]

Internet-Draft                 EIDs in DTN                      May 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Eddy                    Expires November 26, 2006              [Page 14]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/