Delay Tolerant Network (DTN) Numeric Node IDs
draft-templin-dtn-numid-02.txt

Abstract

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

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 January 8, 2017.

Copyright Notice

Copyright (c) 2016 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
• 2. Numeric Node ID Alternatives
• 2.1. IPN Naming Scheme
• 2.2. Alternate Numeric Naming Schemes
• 3. IANA Considerations
• 4. Security Considerations
• 5. Acknowledgements
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

The Delay Tolerant Network (DTN) Bundle Protocol (BP) [I-D.ietf-dtn-bpbis] uses Uniform Resource Identifiers (URIs) [RFC3968] 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) [RFC6260]. 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) [RFC7116].

This document discusses the "ipn" scheme, and presents candidate requirements for alternate DTN numeric node ID schemes.

2. Numeric Node ID Alternatives

2.1. IPN Naming Scheme

[RFC6260] and [RFC7116] 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 [RFC5234], 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, [RFC7116] specifies the initial ipn EID assignments shown below:

    +--------------------+---------------------------+---------------+
    |              Value | Description               | Reference     |
    +--------------------+---------------------------+---------------+
    |                  0 | Reserved                  | This document |
    |       1--(2**14)-1 | Unassigned                | This document |
    | (2**14)--(2**21)-1 | Allocated to CCSDS (SANA) | This document |
    | (2**21)--(2**28)-1 | Private/Experimental Use  | This document |
    | (2**28)--(2**42)-1 | Unassigned                | This document |
    |          >=(2**42) | Reserved                  | This document |
    +--------------------+---------------------------+---------------+

Using octet-based encodings such as CBOR [I-D.burleigh-dtn-rs-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.

2.2. Alternate Numeric Naming Schemes

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:

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

Q1 (Fixed vs Variable-length):

Should an alternate scheme include a fixed-length EID format, or variable-length to allow efficient codings for early adopters?

Q2: (Pseudo-Random vs. Consecutive Assignments):

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?

Q3 (Maximum EID Length):

"ipn" specifies a maximum EID length of 64 bits. Should an alternate scheme adopt the same maximum length?

Q4 (Unicast EIDs):

Should an alternate scheme include a range of EIDs that correspond to singleton DTN nodes?

Q5 (Multicast EIDs):

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?

Q6 (Private-use EIDs):

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?

Q7 (Universal EIDs):

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?

Q8 (Block Allocations vs. Individual Allocations):

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

3. IANA Considerations

This document introduces no IANA considerations.

4. Security Considerations

[I-D.ietf-dtn-bpsec] documents the Bundle Protocol Security (BPsec) specification..

5. Acknowledgements

TBD

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses