[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network Working Group                                          D. Ellard
Internet-Draft                                                R. Altmann
Intended status: Experimental                                   A. Gladd
Expires: May 12, 2013                          Raytheon BBN Technologies
                                                                D. Brown
                                                               Bit9 Inc.
                                                        November 8, 2012

                    DTN IP Neighbor Discovery (IPND)


   Disruption Tolerant Networking (DTN) IP Neighbor Discovery (IPND), is
   a method for otherwise oblivious nodes to learn of the existence,
   availability, and addresses of other DTN participants.  IPND both
   sends and listens for small IP UDP announcement "beacons."  Beacon
   messages are addressed to an IP unicast, multicast, or broadcast
   destination to discover specified remote neighbors, or unspecified
   local neighbors in the topology, e.g. within wireless range.  IPND
   beacons advertise neighbor availability by including the DTN node's
   canonical endpoint identifier.  IPND beacons optionally include
   service availability and parameters.  In this way, neighbor discovery
   and service discovery may be coupled or decoupled as required.  Once
   discovered, new neighbor pairs use advertised availabilities to
   connect, exchange routing information, etc.  This document describes

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 May 12, 2013.

Copyright Notice

Ellard, et al.            Expires May 12, 2013                  [Page 1]

Internet-Draft                  DTN-IPND                   November 2012

   Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Beacon Period  . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Unknown Neighbors  . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Enumerated Neighbors . . . . . . . . . . . . . . . . . . .  6
     2.4.  Allowing Data to Substitute for Beacons  . . . . . . . . .  6
     2.5.  Discovering Bidirectional Links  . . . . . . . . . . . . .  7
     2.6.  Beacon Message Format  . . . . . . . . . . . . . . . . . .  7
       2.6.1.  Service Block  . . . . . . . . . . . . . . . . . . . .  9
       2.6.2.  IPND Service Definition TLV Encoding . . . . . . . . . 10
       2.6.3.  Services . . . . . . . . . . . . . . . . . . . . . . . 13
       2.6.4.  Neighborhood Bloom Filter  . . . . . . . . . . . . . . 14
     2.7.  IPND and CLAs  . . . . . . . . . . . . . . . . . . . . . . 16
     2.8.  Disconnection  . . . . . . . . . . . . . . . . . . . . . . 16
   3.  Relation to Other Discovery Protocols  . . . . . . . . . . . . 17
   4.  Implementation Experience  . . . . . . . . . . . . . . . . . . 18
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Appendix A.  Additional Figures  . . . . . . . . . . . . . . . . . 24
   Appendix B.  Fictional Private Service Example . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26

Ellard, et al.            Expires May 12, 2013                  [Page 2]

Internet-Draft                  DTN-IPND                   November 2012

1.  Introduction

   Delay and Disruption Tolerant Networks (DTNs) [RFC4838] make no
   presumptions about network topology, routing, or availability.  DTNs
   therefore attempt to provide communication in challenged environments
   where, for instance, contemporaneous end-to-end paths do not exist.
   Examples of such DTNs arise in a variety of contexts including mobile
   social networks, space communications, rural message delivery,
   military networks, etc.

   In many DTN scenarios, the identity and meeting schedule of
   participating nodes is not known in advance.  Therefore, an important
   primitive is Neighbor Discovery (ND), or the ability to dynamically
   discover other DTN nodes.  This document specifies Internet Protocol
   Neighbor Discovery (IPND).  In contrast to link or physical layer
   discovery, IPND enables a general form of neighbor discovery across a
   heterogeneous range of links, as are often found in DTN networks.
   IPND is particularly useful in mobile, ad-hoc DTN environments where
   meeting opportunities are not known a priori and connections may
   appear or disappear without warning.  For example, two mobile nodes
   might come into radio distance of each other, discover the new
   connection, and move data along that connection before physically

   In addition to discovering neighbors, it is often valuable to
   simultaneously discover services available from that neighbor.
   Examples of DTN services include a neighbor's available Convergence
   Layer Adapters (CLAs) and their parameters (e.g.  TCP CLA [TCPCLA]),
   available routers (e.g.  Prophet [PROPHET]), tunnels, etc.  Newly
   discovered nodes will then typically participate in bundle [RFC5050]
   routing and delivery.

   In other situations it is useful to decouple service discovery from
   neighbor discovery for efficiency and generality.  For example, upon
   discovering a neighbor, a DTN node might initiate a separate
   negotiation process to establish 1-hop connectivity via a particular
   convergence layer, perform routing setup, exchange availability
   information, etc.

   IPND beacons thus optionally advertise a node's available services
   while maintaining the ability to decouple node and service discovery
   as necessary.  This flexibility is important to various DTN use
   scenarios where connection opportunities may be limited (thus
   necessitating an atomic message for all availability information),
   bandwidth might be scarce (thus implying that service discovery
   should be an independent negotiation to lower beacon overhead), or
   connections have very large round-trip-times (service negotiation is
   therefore too costly with respect to time).

Ellard, et al.            Expires May 12, 2013                  [Page 3]

Internet-Draft                  DTN-IPND                   November 2012

   DTN IPND is designed to be simple, efficient, and general.

   Although this document describes a neighbor discovery protocol in
   terms of IP, the principles and basic mechanisms used in this
   protocol may also be expressed in terms of other datagram protocols.

   The remainder of this document describes DTN IPND.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

   The following terminology is used for describing DTN IPND.

   Bundle  A PDU as defined in [RFC5050].

   Node  A DTN entity in the network that receives and processes

   Beacon message  An IPND-specific message, defined in this document,
      used to announce the presence of a DTN node and parameters with
      which to connect to that node.

   Convergence layer adapter  A convergence layer adapter (CLA) sends
      and receives bundles on behalf of a node by providing the
      conversion between bundles and a transport protocol such as TCP or

Ellard, et al.            Expires May 12, 2013                  [Page 4]

Internet-Draft                  DTN-IPND                   November 2012

2.  Protocol Description

   Nodes use DTN IPND beacons, small UDP messages in the IP underlay, to
   advertise presence.  Similarly, IPND beacons received from other
   nodes serve to detect the availability of DTN neighbors.  Nodes
   SHOULD both send and receive beacons.  These beacon messages,
   detailed in Section 2.6, may be sent either as IP unicast, multicast,
   or broadcast UDP packets.  The beacon message content is agnostic to
   the underlying transport mode.

   Broadcast beacons are designed to reach unknown neighbors in
   neighborhoods within the local network broadcast domain.  Multicast
   [RFC1112] beacons extend the scope of beacon dissemination to
   potentially include multiple networks across routed boundaries.  On
   broadcast media such as Ethernet or wireless, multicast and broadcast
   beacons are sent as link-layer broadcast messages.

   Broadcast and multicast discovery are described in Section 2.2.  In
   contrast, unicast beacons are sent only to explicitly known and
   enumerated neighbors as described in Section 2.3.

   Upon discovering a neighbor and its services, IPND can establish a
   connection to the new neighbor via an IP-based Convergence Layer
   Adapter (CLA), for example the TCP [TCPCLA] or UDP [UDPCLA] CLA.  The
   CLA then negotiates the connection per its individual specification
   and installs the appropriate next-hop routing information in the
   local node.

2.1.  Beacon Period

   An IPND node SHOULD send beacons periodically.  The time interval
   between beacons SHOULD be appropriate for the conditions of the
   network and MAY be configurable.

   An IPND node MAY make use of the OPTIONAL Beacon Period field in the
   beacon message to explicitly inform neighbors of the interval on
   which to expect future beacons.  The Beacon Period is not fixed for a
   given sender and MAY change with each beacon message.  If the Beacon
   Period is included and set to zero, then it SHALL be interpreted as
   negating any expectation for future beacons.

   A receiving node SHOULD either know the expected beacon interval of
   neighbors or extract the interval from the Beacon Period field of
   arriving messages.  The beacon interval along with the existence and
   receive time of beacons SHOULD be used to determine the state of the
   sender's ability to transmit to the receiver (i.e. the up or down
   state of the sender-to-receiver link).  The exact algorithm for
   determining the link status based on received beacons is

Ellard, et al.            Expires May 12, 2013                  [Page 5]

Internet-Draft                  DTN-IPND                   November 2012


2.2.  Unknown Neighbors

   In the general case, the IP addresses of potential neighbors are not
   known in advance.  To discover unknown neighbors, IPND beacon
   messages are sent as IP packets with either multicast or broadcast
   destination addresses.  An IPND node MUST support multicast IP
   destination addresses [RFC1112] and multicast IGMP group membership
   [RFC3376].  A node MAY support IP broadcast destinations.  IPND
   multicast addresses SHOULD be from the IANA assigned local network
   control block 224.0.0/24 [RFC5771].  This block of multicast
   addresses is intentionally scoped to the local network to prevent
   dissemination to the wider Internet.

   An IPND node MAY also use other multicast addresses as required, such
   as multicast addresses from the IANA assigned Internetwork Control
   Block [RFC5771].

   In all multicast addressing cases, a node MUST support a configurable
   IP time-to-live value for all beacon messages.

2.3.  Enumerated Neighbors

   An IPND node SHOULD support unicast beacons.  Since multicast or
   broadcast discovery may not always be feasible over internetworks,
   the IP addresses of potential neighbors reachable only across
   multiple underlay hops must be explicitly enumerated for discovery.
   While the neighbor's address is therefore known, the availability of
   that neighbor is not known.  IPND thus permits DTN nodes to discover
   available remote neighbors across multiple IP underlay hops when
   provided with the addresses of those neighbors.  In this way, IPND
   can be used to bridge IP-based DTNs while detecting disconnections
   among and between the DTNs.

2.4.  Allowing Data to Substitute for Beacons

   Sending data to an IP address matching a configured beacon
   destination SHOULD suppress the generation of beacon messages to that
   destination for a period of time up to but no longer than the beacon
   sending interval.  This suppression SHOULD NOT occur if the
   parameters of a new beacon message would differ from the preceding
   beacon including the advertised services (Section 2.6.3) or the
   Neighborhood Bloom Filter (NBF) (Section 2.6.4).

   Upon receiving a data packet from a neighbor where the packets do not
   represent a beacon, a node SHOULD behave as if a beacon had been
   received from that neighbor, as follows.  If the data packet is

Ellard, et al.            Expires May 12, 2013                  [Page 6]

Internet-Draft                  DTN-IPND                   November 2012

   addressed to this node via a unicast address, then the behavior
   SHOULD be as if the implied received beacon contains a Neighborhood
   Bloom Filter advertisement which indicates the membership of the
   receiving node in the sender's 1-hop neighborhood.  Otherwise, if the
   destination address is multicast or broadcast, then the receiving
   node should presume that the link is bidirectional if and only if its
   state was bidirectional prior to receiving the data packet
   (Section 2.5).  The sender's advertised services and beacon period
   are presumed to be unchanged since the sender's last received beacon.
   If no beacons have previously been received from such a neighbor,
   then it is presumed that there are no services associated with the

2.5.  Discovering Bidirectional Links

   Many routing protocols work correctly only when links are bi-
   directional.  In wired IP networks, link bi-directionality can often
   be presumed.  For other types of networks, such as Mobile Ad-Hoc
   Networks (MANETs) this assumption often does not hold.  If a link to
   a neighbor is said to be "up" only because one or more beacon
   messages have been received from that neighbor over a wireless
   medium, it is not generally safe to assume that the link is
   bidirectional.  In practice, MANETs often have links that are only
   unidirectional due to differences in antennae, transmit power,
   hardware variability, multi-path effects, etc.

   To discover the bi-directionality of links, an IPND Neighborhood
   Bloom Filter (NBF) (Section 2.6.4) facility MAY be employed in which
   each node advertises a Bloom filter representation of the set of
   neighbors from whom it has received enough recent beacons to be
   considered "up".  Upon receiving a beacon from an "up" neighbor that
   advertises an NBF which represents a set containing the receiving
   node's ID, then the link SHOULD be considered bi-directional.

2.6.  Beacon Message Format

   Figure 1 depicts the format of beacon messages.  Note that IPND
   follows the DTN convention of using Self-Delimiting Numeric Values
   (SDNVs) [RFC6256] to represent variable length integers.  An IPND
   node MUST use UDP checksums to ensure correctness.

Ellard, et al.            Expires May 12, 2013                  [Page 7]

Internet-Draft                  DTN-IPND                   November 2012

   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
   |    Version    |     Flags     |     Beacon Sequence Number    |
   |          EID Len  (*)         |   Canonical EID (variable)    |
   |                                                               |
   /                    Service Block (optional)                   /
   |                                                               |
   |  Beacon Period (*) (optional) |
    (*) Denotes the use of SDNV encoding

                      Figure 1: Beacon Message Format

   The beacon message is comprised of the following fields:

   o  Version: An 8-bit field indicating the version of IPND that
      constructed this beacon.  The present document describes version
      0x04 of IPND.  This version field is incremented for IPND if
      either the IPND protocol is modified or the Bundle Protocol
      version is incremented.  In this way the field can also be used to
      determine the BP version supported by a potential DTN neighbor.

   o  Flags: An 8-bit field indicating IPND processing flags.  Four
      flags are currently defined. 0x00 indicates that no special
      processing should be performed on the beacon.  If more than one of
      the Flags bits is set, then the associated structures will appear
      in the beacon message according to their bit order (Bit 0 is
      first).  Semantics of bits are described here from least
      significant (LSb) to most significant (MSb).

      Bit 0  Source EID present: iff set, indicates that the source
         node's EID is present in the beacon.  If the EID is present, it
         is preceded by an SDNV indicating its length.  An IPND node
         SHOULD include the its EID in all beacons, therefore this flag
         SHOULD always be set.

      Bit 1  Service Block present: iff set, indicates that a service
         block is present.

      Bit 2  Neighborhood Bloom Filter present: iff set, indicates that
         a Neighbor Bloom Filter is present within the Service Block.

Ellard, et al.            Expires May 12, 2013                  [Page 8]

Internet-Draft                  DTN-IPND                   November 2012

      Bit 3  Beacon Period present: iff set, indicates that a Beacon
         Period field is present.

      Bits 4-7  Reserved.

   o  Beacon sequence number: A two-octet unsigned integer value
      incremented once for each beacon transmitted to a particular IP

   o  EID Length: The byte length of the canonical EID contained in the
      beacon.  The EID length field is an SDNV and is therefore variable
      length.  A two-octet length is shown for convenience of

   o  Canonical EID: The canonical end node identifier of the neighbor
      advertised by the beacon message.  The canonical EID is variable
      length and represented as a Uniform Resource Identifier [RFC3986].

   o  Service Block: Optional announced services (Section 2.6.1) in the
      beacon.  Services MAY include CLAs (Section 2.6.3), routing
      parameters, a Neighborhood Bloom Filter (Section 2.6.4), and other
      implementation-dependent services.

   o  Beacon Period: Optional field indicating the sender's current
      beacon interval in seconds.  A value of zero indicates that the
      beacon period is undefined.  The Beacon Period is an SDNV and is
      therefore variable length.  A two-octet length is shown for
      convenience of representation.

2.6.1.  Service Block

   As described previously, beacon messages may optionally include a
   block of service availability information.  The service block is
   intended to contain representations of available CLAs, routers, a
   Neighborhood Bloom Filter, etc., but is sufficiently general to
   accommodate implementation-specific services provided by the
   advertising node.

   For example, the source IP address of a received beacon suffices to
   identify the remote node at the IP level.  However, the IP address
   alone does not inform other processes via which transport mechanism
   (e.g.  TCP or UDP) or via which transport port the remote node is
   offering a connection.  Similarly, nodes do not know which routers
   (e.g.  Prophet [PROPHET]) are running on a remote node in order to
   inform bundle exchange.  Therefore, a beacon MAY contain a service
   block which serves to notify nodes about the availability of these

Ellard, et al.            Expires May 12, 2013                  [Page 9]

Internet-Draft                  DTN-IPND                   November 2012

   The format of a service block is given in Figure 2.

   |   Number of Services N (*)    |
   |                                                               |
   \          Service Definition 0 (IPND-SD-TLV encoded)           \
   |                                                               |
   \                              ...                              \
   |                                                               |
   \         Service Definition N-1 (IPND-SD-TLV encoded)          \
   |                                                               |
    (*) Denotes the use of SDNV encoding

                      Figure 2: Service Block Format

   A service block is comprised of the following fields:

   o  Number of services: The number of services described in the block.
      The number of services is an SDNV and is therefore variable

   o  Service Definition(s): A list of service definitions encoded
      according to the IPND Service Definition TLV encoding
      (Section 2.6.2) specification.

2.6.2.  IPND Service Definition TLV Encoding

   The IPND Service Definition TLV encoding scheme (IPND-SD-TLV)
   provides for the standardization of service definitions using a
   format that focuses on simplicity, flexibility, and efficiency.
   IPND-SD-TLV borrows many ideas from from the ASN.1 Basic Encoding
   Rules (BER) specification [ASN1-BER].  Like ASN.1 BER, IPND-SD-TLV
   structures are generally composed of three distinct parts:

   1.  Tag: A numeric token which identifies the structure (REQUIRED).

   2.  Length: A numeric value which specifies the size of the content
       block (sometimes REQUIRED).

   3.  Value: The content block, which contains the value(s) described
       by the tag (REQUIRED).

   IPND-SD-TLV tags SHALL be 8-bit values, providing IPND a range of 256
   possible tag numbers.  Tag assignments are designed to provide a

Ellard, et al.            Expires May 12, 2013                 [Page 10]

Internet-Draft                  DTN-IPND                   November 2012

   basic, standard set of building blocks while remaining flexible
   enough to allow the implementation of unforeseen specifications.  The
   first 128 tag numbers (i.e. 0-127) SHALL be reserved for standard
   definitions; the remaining tags (i.e. 128-255) MAY be used for
   implementation-specific (private) definitions.  This design allows a
   node to inspect the most significant bit (bit-7, zero-indexed) of the
   tag to determine whether it is a reserved or private value.

   IPND-SD-TLV defines two classes of data types: Primitive and
   Constructed (the difference between these data types is discussed
   below).  Reserved tag numbers are designed such that the class of a
   data type can be determined by examining the second-most significant
   bit (bit-6, zero-indexed) of the tag.  If this bit is not set, the
   data type is primitive, otherwise it is constructed.  As a result of
   this design, reserved primitive types SHALL be assigned tag numbers
   0-63, while reserved constructed types SHALL be assigned tag numbers

   Private tag numbers are always expected to represent constructed data
   types, therefore private (implementation-specific) constructed types
   (if in use by IPND) SHALL be assigned tag numbers 128-255.

   The construction of IPND-SD-TLV tags is depicted in Figure 3

   |             Reserved              |
   |  Bit  | 7 | 6 |        5-0        |
   |       | 0 | 0 |    Tag Number     |  Reserved Primitive Types
   + Value +---+---+-------------------+
   |       | 0 | 1 | (Tag Number) - 64 |  Reserved Constructed Types

   |             Private               |
   |  Bit  | 7 |         6-0           |
   | Value | 1 |  (Tag Number) - 128   |  Private Constructed Types

                        Figure 3: IPND-SD-TLV Tags

   In order to keep encoded services simple and compact, IPND-SD-TLV
   SHALL omit the length field in cases where the content's length is
   always fixed (e.g. an IP address) or described in-place (e.g. an SDNV
   value).  In the cases where an explicit length field is required

Ellard, et al.            Expires May 12, 2013                 [Page 11]

Internet-Draft                  DTN-IPND                   November 2012

   (e.g. string content), an IPND node SHALL SDNV encode the length
   values.  Additionally, a length field MUST be included in constructed
   types immediately following the tag value which describes the length,
   in bytes, of the structure's content block.  This constraint allows a
   node to skip constructed types that are unrecognized while reading a
   received Service Block.  An IPND node SHALL SDNV encode these length

   Again, IPND-SD-TLV defines two classes of data types: Primitive and
   Constructed.  Primitive types represent fundamental data types such
   as integers or strings.  An IPND node MUST support the primitive data
   types specified in Figure 4.  Note that primitive types use one of
   three distinct length specifiers:

   o  Fixed: The content always has a fixed length and SHALL NOT include
      a length field.  Fixed length numeric values (including floating
      point numbers) SHALL be written in network byte order.

   o  Variable: The content is variable length but is encoded as an
      SDNV, therefore it SHALL NOT include a length field.

   o  Explicit: The content is variable and does not describe its own
      length, therefore it MUST include a length field immediately
      following the tag value.

   |TAG #   Definition  Length Type   Content Length   |
   |                                  (unencoded bytes)|
   |    0   boolean     Fixed                     1    |
   |    1   uint64      Variable                1-8*   |
   |    2   sint64      Variable                1-8*   |
   |    3   fixed16     Fixed                     2    |
   |    4   fixed32     Fixed                     4    |
   |    5   fixed64     Fixed                     8    |
   |    6   float       Fixed                     4    |
   |    7   double      Fixed                     8    |
   |    8   string      Explicit                1-N    |
   |    9   bytes       Explicit                1-N    |
   |10-63   UNASSIGNED                                 |
    *Denotes content that is SDNV encoded

                   Figure 4: IPND-SD-TLV Primitive Types

   Note that a special case exists for representing the empty string and
   the empty byte array for the "string" and "bytes" data types,

Ellard, et al.            Expires May 12, 2013                 [Page 12]

Internet-Draft                  DTN-IPND                   November 2012

   respectively.  In both cases, "empty" is represented by an explicit
   length value of 1 and content of a single null byte.

   Constructed data types represent structures that are composed of
   other data types.  As described earlier, reserved constructed types
   SHALL be assigned tag numbers 64-127.  Additionally, nodes MAY assign
   tag numbers 128-255 to private constructed types in order to allow
   for implementation-specific constructed types.  An IPND node SHALL
   use constructed types to specify service definitions as described in
   Section 2.6.3.

   It is important to note that the order in which other types are
   composed within a constructed type need not be explicitly stated.
   Ordering only becomes an issue in the case where a constructed type
   (not representing an array structure) contains multiple instances of
   the same data type.  In order to defeat this issue, implementations
   MUST create data type wrappers in order to differentiate identical
   types.  This design allows IPND to be order-agnostic when it comes to
   reading data types that compose a constructed type.  Appendix B
   describes an example where data type wrappers are used to
   differentiate identical fundamental types.

2.6.3.  Services

   A service is an IPND-SD-TLV structure that represents an
   advertisement for a DTN-related resource available on the beacon
   source node.  Each service type SHALL have a unique tag number in
   order to identify it within the service block.  Nodes SHALL use the
   initial set of tag assignments described in Figure 5 (the rationale
   for tag numbering is described in Section 2.6.2).

   |  TAG #   Definition   Construction                           |
   |     64   CLA-TCP-v4   {IP (fixed32), Port (fixed16)}         |
   |     65   CLA-UDP-v4   {IP (fixed32), Port (fixed16)}         |
   |     66   CLA-TCP-v6   {IP (bytes), Port (fixed16)}           |
   |     67   CLA-UDP-v6   {IP (bytes), Port (fixed16)}           |
   |     68   CLA-TCP-HN   {Hostname (string), Port (fixed16)}    |
   |     69   CLA-UDP-HN   {Hostname (string), Port (fixed16)}    |
   | 70-125   UNASSIGNED                                          |
   |    126   NBF-Hashes   Hash IDs (bytes)                       |
   |    127   NBF-Bits     Bit Array (bytes)                      |
   |128-255   PRIVATE USE                                         |

                Figure 5: IPND-SD-TLV Constructed Services

Ellard, et al.            Expires May 12, 2013                 [Page 13]

Internet-Draft                  DTN-IPND                   November 2012

   An IPND node MUST support the service definitions for CLA-TCP-v4 and
   CLA-UDP-v4; that is, a node MUST support the standard definitions for
   TCP CLA advertisements and UDP CLA advertisements, respectively (both
   supporting IPv4 32-bit addresses).  An example bitwise representation
   of the CLA-TCP-v4 service is depicted in Figure 6.  Note that the
   format of the CLA-UDP-v4 service is identical except for the initial
   tag number, which would instead be 65 (hex 0x41).

   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
   |   Tag 0x40    | Len 0x08 (*)  |   Tag 0x04    | IPv4 Address  |
   |              IPv4 Address (cont)              |   Tag 0x03    |
   |          Port Number          |
    (*) Denotes the use of SDNV encoding

                    Figure 6: CLA-TCP-v4 Service Format

   An IPND node MAY support the CLA-TCP-v6, CLA-UDP-v6, CLA-TCP-HN, and
   CLA-UDP-HN service definitions.  Bitwise representations of the CLA-
   UDP-v6 and CLA-TCP-HN services are depicted in Appendix A.
   Additionally, a node MAY support the Neighborhood Bloom Filter
   services (NBF-Hashes and NBF-Bits).  These services are described
   below (Section 2.6.4).  Lastly, a node MAY support any
   implementation-specific services with tag numbers 128-255.
   Appendix B describes an example of an implementation-specific service
   that makes use of private tag number assignments.

2.6.4.  Neighborhood Bloom Filter

   In order to efficiently determine link bi-directionality, a node
   represents the set of its 1-hop neighbors using a Bloom filter
   referred to as the Neighborhood Bloom Filter (NBF).  Upon receiving a
   beacon from a neighbor that contains NBF service information, a node
   can quickly determine whether it is in the neighbor's NBF set, and
   thereby determine whether the link is bidirectional.

   Every node that might operate in an environment where discovered
   links may not be bidirectional SHOULD include NBF service
   advertisements in its multicast or broadcast beacons which describe
   the membership of its 1-hop neighbor set.  This is especially true if
   a node's routing protocol presumes that links are bidirectional.

   An NBF need not be included within every beacon, but one SHOULD be
   present within at least one broadcast or multicast beacon following a

Ellard, et al.            Expires May 12, 2013                 [Page 14]

Internet-Draft                  DTN-IPND                   November 2012

   change in the 1-hop neighborhood of the node.  An NBF advertisement
   MAY be present in every broadcast or multicast beacon.

   In order to advertise an NBF, an IPND node MUST include two distinct
   services in the Service Block of some (or all) of its beacons: NBF-
   Hashes, which describes the hash algorithms used to compute the NBF
   bit array; and NBF-Bits, which contains the actual bit array of the
   NBF.  The bits set in the NBF-Bits structure MUST be defined by
   computing hashes on the canonical EID of each 1-hop neighbor
   considered to be "up".  Each hash algorithm used to compute the NBF
   bit array MUST be identified in the NBF-Hashes structure (using
   numerical identifiers; one byte per identifier).  Exemplary bitwise
   formats of fictional NBF-Hashes and NBF-Bits structures are depicted
   in Figure 7 and Figure 8, respectively.  Note that the NBF bit array
   in the NBF-Bits structure must be byte-aligned, and SHALL be padded
   with zero bits at the end of the bit array to achieve byte-alignment.

   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
   |   Tag 0x7E    | Len 0x05 (*)  |   Tag 0x09    | Len 0x03 (*)  |
   |   Hash 0 ID   |   Hash 1 ID   |   Hash 2 ID   |
    (*) Denotes the use of SDNV encoding

               Figure 7: Fictional NBF-Hashes Service Format

   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
   |   Tag 0x7F    | Len 0x06 (*)  |   Tag 0x09    | Len 0x04 (*)  |
   |     Byte 0    |     Byte 1    |     Byte 2    |     Byte 3    |
    (*) Denotes the use of SDNV encoding

                Figure 8: Fictional NBF-Bits Service Format

   Different networks naturally have distinct requirements, tolerance
   for overhead, and node computing resources, so the parameters of the
   Bloom Filter such as the bit array length, and the number and types
   of hash algorithms, are not mandated by IPND.  However, all nodes
   participating in such a DTN SHOULD be aware of the same set of hash
   algorithms and their respective identifiers used in NBF-Hashes

Ellard, et al.            Expires May 12, 2013                 [Page 15]

Internet-Draft                  DTN-IPND                   November 2012

   NBF services, if present, MAY be ignored by a receiving IPND node if
   its implementation does not provide for it, or if the parameters of
   the Bloom filter cannot be determined with certainty (e.g. if the
   hash function identifiers are not recognized).

2.7.  IPND and CLAs

   IP-based CLAs are generally expected to depend on an IPND
   implementation module for their discovery service.  A CLA MAY opt not
   to use IPND, either because that CLA does not require discovery or
   provides its own.

   Once IPND discovers a new neighbor it MUST inform all CLAs which
   depend on IPND of the neighbor's existence and the discovered
   parameters.  The exact means by which IPND communicates with the CLAs
   is implementation dependent.

   Similarly, once IPND determines that a link has gone down, it MUST
   inform all dependent CLAs of the link down event.

2.8.  Disconnection

   Note that an IPND node SHOULD maintain state over all existing
   neighbors in order to prevent CLAs from needlessly attempting to
   establish connections between nodes that are already connected.  To
   maintain the current neighbor set, IPND removes stale neighbors after
   the defined neighbor receive timeout period elapses without receiving
   any beacon messages from a particular neighbor.

   Upon detecting a neighbor that is no longer available, IPND MAY
   provide hints to the CLAs that the neighbor is gone.  Note that some
   CLAs themselves provide keepalive-type functionality and therefore
   IPND is not necessarily required to detect down neighbors.  However,
   relying on IPND to provide both discovery and availability
   information provides a single, coherent point in the system design to
   maintain neighbor information.

Ellard, et al.            Expires May 12, 2013                 [Page 16]

Internet-Draft                  DTN-IPND                   November 2012

3.  Relation to Other Discovery Protocols

   A variety of discovery protocols exist in other contexts and domains.
   These discovery protocols include the ability to discover available
   neighbors and services.  For example, the IETF zero configuration
   working group [RFC3927], the bonjour protocol [BONJOUR], and the OLSR
   discovery protocol [NHDP] all provide similar functionality.

   Other rendezvous mechanisms are possible that allow a node to find a
   neighbor of a particular type or with particular properties.  For
   example, the Domain Name System (DNS) or Distributed Hash Tables
   (DHTs) could be used to find a neighbor that provides an inter-
   planetary gateway.  Such advanced rendezvous schemes are beyond the
   scope of this document.

   In contrast, DTN-IPND is designed to be DTN-specific, efficient, and
   extremely lightweight.  For instance, DTN-IPND is capable of
   supporting arbitrary length DTN EIDs, and may include CLA information
   in order to maximize the utility of each beacon message without
   requiring multiple round-trip transmissions in order to perform
   complex protocol negotiation.

   While DTN-IPND MAY be used in non-DTN environments, its use is
   RECOMMENDED only in DTNs.

Ellard, et al.            Expires May 12, 2013                 [Page 17]

Internet-Draft                  DTN-IPND                   November 2012

4.  Implementation Experience

   Raytheon BBN Technologies (BBN) developed an implementation of DTN
   IPND which has been added to the bundle protocol reference
   implementation, DTN2, as an experimental build option.

   BBN has also implemented and deployed an earlier version of DTN IPND
   as part of the SPINDLE [SPINDLE] project.

Ellard, et al.            Expires May 12, 2013                 [Page 18]

Internet-Draft                  DTN-IPND                   November 2012

5.  Security Considerations

   Neighbor discovery may be perceived as an impediment to security
   because it advertises a potential target for attacks.  Discovering
   the existence of a particular node is orthogonal to securing the
   services of that node.  Nodes that desire or require higher-levels of
   security SHOULD disable the broadcast IPND beacons and rely instead
   on static neighbor configuration.

   Further, neighbor discovery represents a potential source of network
   congestion and contention.  Therefore, careful consideration should
   be made to the frequency and TTL scope of beacons when setting
   implementation-specific parameters, particularly when a setting
   affects larger regions of the network.

Ellard, et al.            Expires May 12, 2013                 [Page 19]

Internet-Draft                  DTN-IPND                   November 2012

6.  IANA Considerations

   A new IANA registry should be created to document the standard tag
   number assignments for IPND Service Definition TLV structures.  The
   registry shall define a single numberspace with values representing
   the IPND-SD-TLV tag numbers as described in Section 2.6.2.

   The registration policy for this new registry shall be:

   0-63:  Specification Required.  Specifications in this subset must
      only be for primitive datatypes, and the specification must
      describe which "length type" will be used for the new datatype as
      well as the unencoded content length (see Figure 4).  New
      registrations shall only be approved for datatypes reasonably
      expected to have a use case applicable throughout the community.

   64-127:  Specification Required.  Specifications in this subset must
      only be for constructed datatypes, and the specification must
      describe the composition of the new datatype using references to
      existing datatypes (as in Figure 5).  New registrations shall only
      be approved for datatypes reasonably expected to have a use case
      applicable throughout the community.

   128-255:  Private or Experimental use.  No assignment by IANA.

   The value range is: unsigned 8-bit integer.

Ellard, et al.            Expires May 12, 2013                 [Page 20]

Internet-Draft                  DTN-IPND                   November 2012

   |  Value   Description                    Reference     |
   |      0   Primitive boolean tag          This Document |
   |      1   Primitive uint64 tag           This Document |
   |      2   Primitive sint64 tag           This Document |
   |      3   Primitive fixed16 tag          This Document |
   |      4   Primitive fixed32 tag          This Document |
   |      5   Primitive fixed64 tag          This Document |
   |      6   Primitive float tag            This Document |
   |      7   Primitive double tag           This Document |
   |      8   Primitive string tag           This Document |
   |      9   Primitive byte array tag       This Document |
   |  10-63   Unassigned (primitive only)                  |
   |     64   CLA-TCP-v4 service tag         This Document |
   |     65   CLA-UDP-v4 service tag         This Document |
   |     66   CLA-TCP-v6 service tag         This Document |
   |     67   CLA-UDP-v6 service tag         This Document |
   |     68   CLA-TCP-HN service tag         This Document |
   |     69   CLA-UDP-HN service tag         This Document |
   | 70-125   Unassigned (constructed only)                |
   |    126   NBF-Hashes service tag         This Document |
   |    127   NBF-Bits service tag           This Document |
   |128-255   Private/Experimental Use                     |

             Figure 9: IANA IPND-SD-TLV Tag Number Assignments

Ellard, et al.            Expires May 12, 2013                 [Page 21]

Internet-Draft                  DTN-IPND                   November 2012

7.  References

7.1.  Normative References

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

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

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

   [RFC6256]  Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
              Values in Protocols", RFC 6256, May 2011.

7.2.  Informative References

              ITU-T Rec. X.690, "Abstract Syntax Notation One (ASN.1).
              Encoding Rules: Specification of Basic Encoding Rules
              (BER), Canonical Encoding Rules (CER) and Distinguished
              Encoding Rules (DER)", ISO/IEC 8825-1:2002, 2002.

   [BONJOUR]  Cheshire, S., "Bonjour", Apr 2005.

   [NHDP]     Clausen, T., Dearlove, C., and J. Dean, "MANET
              Neighborhood Discovery Protocol (NHDP)", Mar 2009.

   [PROPHET]  Lindgren, A. and A. Doria, "Probabilistic Routing Protocol
              for Intermittently  Connected Networks", Mar 2006.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              May 2005.

Ellard, et al.            Expires May 12, 2013                 [Page 22]

Internet-Draft                  DTN-IPND                   November 2012

   [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
              IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
              March 2010.

   [SPINDLE]  Krishnan, R., "Survivable Policy-Influenced Networking:
              Disruption-tolerance through Learning and Evolution",
              Oct 2006.

   [TCPCLA]   Demmer, M. and J. Ott, "Delay Tolerant Networking TCP
              Convergence Layer Protocol", Nov 2008.

   [UDPCLA]   Kruse, H. and S. Ostermann, "UDP Convergence Layers for
              the DTN Bundle and LTP Protocols", Nov 2008.

Ellard, et al.            Expires May 12, 2013                 [Page 23]

Internet-Draft                  DTN-IPND                   November 2012

Appendix A.  Additional Figures

   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
   |   Tag 0x43    | Len 0x0C (*)  |   Tag 0x09    | Len 0x10 (*)  |
   |                          IPv6 Address                         |
   |                      IPv6 Address (cont)                      |
   |                      IPv6 Address (cont)                      |
   |                      IPv6 Address (cont)                      |
   |   Tag 0x03    |          Port Number          |
    (*) Denotes the use of SDNV encoding

                   Figure 10: CLA-UDP-v6 Service Format

   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
   |   Tag 0x44    | Len 0x0F (*)  |   Tag 0x08    | Len 0x0A (*)  |
   |                    Hostname ("dtnfoo.net")                    |
   |                Hostname ("dtnfoo.net") (cont)                 |
   |Hostname ("dtnfoo.net") (cont) |   Tag 0x03    |   Port Num    |
   |Port Num (cont)|
    (*) Denotes the use of SDNV encoding

                   Figure 11: CLA-TCP-HN Service Format

Ellard, et al.            Expires May 12, 2013                 [Page 24]

Internet-Draft                  DTN-IPND                   November 2012

Appendix B.  Fictional Private Service Example

   The following describes a fictional implementation-specific routing
   service in order to demonstrate the use of IPND-SD-TLV encoding
   rules.  Figure 12 defines the construction of the service structure
   using tag numbers out of the private tag assignment space.  Note the
   use of "wrapper" data types in order to differentiate between what
   would otherwise be identical data types within the composition of the
   router service's definition.

   | TAG #   Definition   Construction             |
   |   128   FooRouter    {Seed (SeedVal),         |
   |                       BaseWeight (WeightVal), |
   |                       RootHash (bytes)}       |
   |   129   SeedVal      Value (fixed16)          |
   |   130   WeightVal    Value (fixed16)          |

                  Figure 12: Fictional Router Definition

   Figure 13 depicts the bitwise representation of an IPND-SD-TLV
   encoded FooRouter service using fictional content values.  Note that
   the ordering of the service's composition does not exactly match the
   definition; this should not be an issue for a receiving node with
   knowledge of the FooRouter service.

   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
   |   Tag 0x80    | Len 0x11 (*)  |   Tag 0x82    | Len 0x03 (*)  |
   |   Tag 0x03    |  Weight Value (e.g. 0x123F)   |   Tag 0x09    |
   | Len 0x05 (*)  |   Byte 0xDE   |   Byte 0xAD   |   Byte 0xBE   |
   |   Byte 0xEF   |   Byte 0x04   |   Tag 0x81    | Len 0x03 (*)  |
   |   Tag 0x03    |   Seed Value (e.g. 0xB4A1)    |
    (*) Denotes the use of SDNV encoding

                   Figure 13: Fictional FooRouter Format

Ellard, et al.            Expires May 12, 2013                 [Page 25]

Internet-Draft                  DTN-IPND                   November 2012

Authors' Addresses

   Daniel Ellard
   Raytheon BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138

   Email: dellard@bbn.com

   Richard Altmann
   Raytheon BBN Technologies
   9861 Broken Land Parkway, Suite 400
   Columbia, MD  21046

   Email: raltmann@bbn.com

   Alex Gladd
   Raytheon BBN Technologies
   9861 Broken Land Parkway, Suite 400
   Columbia, MD  21046

   Email: agladd@bbn.com

   Daniel Brown
   Bit9 Inc.
   266 Second Ave.
   Waltham, MA  02451

   Email: dbrown@bit9.com

Ellard, et al.            Expires May 12, 2013                 [Page 26]

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