Delay Tolerant Network (DTN) Numeric Node IDs

The Delay Tolerant Network (DTN) Bundle Protocol (BP) uses Uniform Resource Identifiers (URIs) as the basis for Endpoint IDs (EIDs) in the following format: < scheme name > : < scheme-specific part, or "SSP" > When the scheme name is "dtn", the SSP is an alphanumeric EID string up to 1023 octets in length. Since each Bundle may include several such EIDs, this could result in substantial bandwidth consumption over constrained links simply to transport EIDs, leading to a desire for a concise numeric format. When the scheme name is "ipn", the SSP is a numeric node number (between 1 and 2^64 - 1) followed by a numeric service number (between 0 and 2^64 - 1) . Values for these fields are registered with the Internet Assigned Numbers Authority (IANA) and/or delegated to independent registries such as the Space Assigned Numbers Authority (SANA) . This document discusses the "ipn" scheme, and presents candidate requirements for alternate DTN numeric node ID schemes.

and define a numeric naming scheme used to form EIDs that in native representation take the form of Uniform Record Identifiers with scheme name “ipn”. The native representation of an "ipn" EID is: “ipn:<node_number>.<service_number>”. More formally, the “ipn” scheme is defined in the Augmented Backus-Naur Form (ABNF) notation of , including the core ABNF syntax rule for DIGIT defined by that specification. Details are: ipn-uri = "ipn:" ipn-hier-part ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless node-nbr = 1*DIGIT nbr-delim = "." service-nbr = 1*DIGIT. Because the encoded representation of an ipn-scheme URI’s ipn-hier-part is so compact, EIDs expressed in this scheme are suitable for resource-constrained links, however administrative entities that are first to claim the lower node numbers for assignment to their nodes may have a permanent performance advantage. In particular, specifies the initial ipn EID assignments shown below:

=(2**42) | Reserved | This document | +--------------------+---------------------------+---------------+]]> Using octet-based encodings such as CBOR , this means that EIDs allocated to CCSDS can be represented in 2-3 octets, Private/Experimental Use EIDs can be represented in 3-4 octets and Unassigned/Reserved EIDs require 4 or more octets. This means that in a first-come, first-served assignment policy the earliest adopters will receive EIDs that can be represented in fewer octets than those received by latecomers.The "ipn" scheme further does not address all of the requirements that would be expected of addressing schemes such as those defined for the Internet Protocol, but it is necessary to consider which (if any) of the additional requirements would be applicable to DTN. The following section therefore discusses requirements for alternate numeric naming schemes for DTN, if indeed an alternate scheme is even necessary.

It is clear that the "ipn" scheme is already operational; hence, if one or more new scheme names are needed they would require a new scheme name. Some of the questions that must be taken into consideration in designing an alternate numeric naming scheme include: Should an alternate scheme include a fixed-length EID format, or variable-length to allow efficient codings for early adopters? Should an alternate scheme delegate EIDs in a (pseudo) random fashion to ensure fairness, or as consecutive values beginning with low numbers and growing proportionally to the number of allocations? "ipn" specifies a maximum EID length of 64 bits. Should an alternate scheme adopt the same maximum length? Should an alternate scheme include a range of EIDs that correspond to singleton DTN nodes? Should an alternate scheme include a range of EIDs that correspond to groups of DTN nodes for which all nodes in the group receive the bundle? If so, should the multicast EIDs be part of the same naming scheme as unicast EIDs, or should they be part of a different scheme? Should an alternate scheme include a range of EIDs that can be administratively assigned within the local DTN, even though the same EIDs may be assigned in other DTNs? If so, should the private-use EIDs be assigned from low-numbered values so that efficient coding compression can be employed? Should an alternate scheme include a range of EIDs that are guaranteed to be unique on a universal basis, e.g., in case one or more DTNs merge to form a larger DTN? Should an alternate scheme allow for "block allocations" of EIDs, or only individual allocations (i.e., one EID at a time)? If block allocations are supported, should the blocks include contiguous EID values, or (pseudo) random values? It is further worth considering that any DTN numeric naming scheme (or schemes) would entail compromises that might not be a best-fit for all applications. For example, the IPv6 addressing architecture specifies a fixed 16-octet address length which might present considerable overhead for transporting addresses across slow links. In the end, any new DTN numeric naming scheme would need to be analyzed according to specific use cases.