Internet-Draft | DTN IP Neighbor Discovery (IPND) | October 2023 |
Ellard, et al. | Expires 9 April 2024 | [Page] |
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 or unspecified 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 DTN IPND.¶
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 https://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 9 April 2024.¶
Copyright (c) 2023 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 disconnecting.¶
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 [RFC9174]), available routers (e.g. PRoPHET [RFC6693]), tunnels, etc. Newly discovered nodes will then typically participate in bundle [RFC9171] 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).¶
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.¶
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].¶
The following terminology is used for describing DTN IPND.¶
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. When the IP underlay is based on the the IPv4 protocol, these beacon messages, detailed in Section 2.6, may be sent as UDP datagrams in either unicast, multicast, or broadcast packets. When the IP underlay uses IPv6, the beacon messages may be sent as either unicast or multicast 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. IPv4 multicast [RFC1112] or IPv6 multicast [RFC4291] 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 [RFC9174] or Datagram [RFC7122] CLA. The CLA then negotiates the connection per its individual specification and installs the appropriate next-hop routing information in the local node.¶
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 implementation-defined.¶
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] [RFC4291] and multicast IGMP / MLD group membership [RFC3376] [RFC2710] [RFC3810]. A node MAY support IP broadcast destinations. IPv4 multicast addresses for IPND 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. Likewise, IPv6 multicast addresses for IPND should have link-local scope [RFC4291] [RFC7346].¶
An IPND node MAY also use other multicast addresses as required, such as IPv4 multicast addresses from the IANA assigned Internetwork Control Block [RFC5771] or IPv6 multicast addresses with wider scope than link-local. One use case for this would be a mobile ad hoc network (MANET) environment which includes nodes that are not DTN-capable, but do support IP multicast forwarding, e.g. by means of SMF [RFC6621]. Those nodes that are DTN-capable would then be able to discover each other over multiple IP hops.¶
In all multicast addressing cases, a node MUST support a configurable IPv4 time-to-live value or IPv6 Hop Limit value for all beacon messages.¶
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.¶
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 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 sender.¶
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, the link SHOULD then be considered bi-directional.¶
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.¶
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
The beacon message is comprised of the following fields:¶
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 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. Bit 3 Beacon Period present: iff set, indicates that a Beacon Period field is present. Bits 4-7 Reserved.¶
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 [RFC6693]) 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 services.¶
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
A service block is comprised of the following fields:¶
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:¶
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 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 64-127.¶
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 +-------+---+-----------------------+
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 (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 values.¶
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:¶
+---------------------------------------------------+ |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
Note that a special case exists for representing the empty string and the empty byte array for the “string” and “bytes” data types, 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.¶
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 CLA-DCCP-v4 {IP (fixed32), Port (fixed16), | | Servicecode (fixed32)} | | 71 CLA-DCCP-v6 {IP (bytes), Port (fixed16), | | Servicecode (fixed32)} | | 72 CLA-DCCP-HN {Hostname (string), Port (fixed16), | | Servicecode (fixed32)} | | 73-125 UNASSIGNED | | 126 NBF-Hashes Hash IDs (bytes) | | 127 NBF-Bits Bit Array (bytes) | |128-255 PRIVATE USE | +------------------------------------------------------------+
An IPND node MUST support the service definitions for CLA-TCP-v6 and CLA-UDP-v6; that is, a node MUST support the standard definitions for TCP CLA advertisements and UDP CLA advertisements, respectively (both supporting IPv6 128-bit addresses). An example bitwise representation of the CLA-TCP-v6 service is depicted in {{figure6}. Note that the format of the CLA-UDP-v6 service is identical except for the initial tag number, which would instead be 67 (hex 0x43).¶
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 0x42 | Len 0x15 (*) | 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
An IPND node MAY support the CLA-TCP-v4, CLA-UDP-v4, CLA-TCP-HN, CLA-UDP-HN, CLA-DCCP-v4, CLA-DCCP-v6 and CLA-DCCP-HN service definitions. Bitwise representations of the CLA-UDP-v4, CLA-TCP-HN and CLA-DCCP-v6 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.¶
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 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
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
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 structures.¶
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).¶
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.¶
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.¶
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 OLSRv2 neighborhood discovery protocol(NHDP)[RFC6130] 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.¶
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] project.¶
An earlier version of this specification has also been implemented as part of the [IBR-DTN] project at Technical University of Braunschweig, Germany.¶
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 / Hop Limit scope of beacons when setting implementation-specific parameters, particularly when a setting affects larger regions of the network.¶
Port number 4450 is requested to be assigned as the default UDP port for IPND.¶
Service Name: dtn-ipnd¶
Transport Protocol(s): UDP¶
Assignee: Scott Johnson (scott@spacelypackets.com)¶
Contact: Scott Johnson (scott@spacelypackets.com)¶
Description: DTN IP Neighbor Discovery Protocol¶
Reference: (This document)¶
Port Number: 4550¶
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.¶
+-------------------------------------------------------+ | 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 CLA-DCCP-v4 service tag This Document | | 71 CLA-DCCP-v6 service tag This Document | | 72 CLA-DCCP-HN service tag This Document | | 73-125 Unassigned (constructed only) | | 126 NBF-Hashes service tag This Document | | 127 NBF-Bits service tag This Document | |128-255 Private/Experimental Use | +-------------------------------------------------------+
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 0x41 | Len 0x08 (*) | Tag 0x04 | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address (cont) | Tag 0x03 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Number | +-+-+-+-+-+-+-+-++-+-+-+-+-++-+-+ (*) Denotes the use of SDNV encoding
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
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 0x47 | Len 0x1A (*) | Tag 0x09 | Len 0x10 (*) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag 0x03 | Port Number | Tag 0x04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DCCP Service Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (*) Denotes the use of SDNV encoding
The following describes a fictional implementation-specific routing service in order to demonstrate the use of IPND-SD-TLV encoding rules. Figure 13 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 14 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