Delay Tolerant Network (DTN) Numeric
Node IDsBoeing Research & TechnologyP.O. Box 3707SeattleWA98124USAfltemplin@acm.orgJPL, Calif. Inst. Of Technology4800 Oak Grove Dr.PasadenaCA91109-8099USA+1 818 393 3353Scott.Burleigh@jpl.nasa.govI-DInternet-DraftThe Delay Tolerant Network (DTN) Bundle Protocol (BP) uses Uniform
Resource Identifiers (URIs) as the basis for Endpoint and Node IDs. IDs
that are encoded as long alphanumeric strings can consume precious
bandwidth over constrained links, leading to a desire for a concise
numeric ID format. This document discusses design alternatives for 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-partipn-hier-part = node-nbr nbr-delim service-nbr ; a
path-rootlessnode-nbr = 1*DIGITnbr-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: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.This document introduces no IANA considerations. documents the Bundle Protocol
Security (BPsec) specification..TBD