Delay Tolerant Network (DTN) Numeric Node IDs
draft-templin-dtn-numid-01.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 alphanumeric strings can consume excessive precious bandwidth over constrained links, leading to a desire for a short numeric ID format. This document discusses alternatives for a DTN numeric node ID format.

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 October 8, 2016.

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. Proposed Revised IPN Naming Scheme
• 2.3. Alternate Numeric Scheme Based on TLVs
• 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.dtnwg-bp] uses Uniform Resource Identifiers (URIs) [RFC3968] as the basis for Endpoint and Node IDs. IDs that are encoded as alphanumeric strings can consume excessive precious bandwidth over constrained links, leading to a desire for a short numeric ID format.

DTN IDs are formed as URIs in the following format:

< scheme name > : < scheme-specific part, or "SSP" >

When "scheme name" is the string "dtn", the SSP is an alphanumeric string up to 1023 bytes in length. Currently, there are no standard scheme names defined in the IETF/IRTF literature for condensed numeric representations, although a scheme name "ipn" has been defined and used in other contexts. This document discusses alternatives for a DTN numeric node ID format.

2. Numeric Node ID Alternatives

2.1. IPN Naming Scheme

In other publication forums outside the IETF and IRTF, a numeric naming scheme called: "ipn" is defined. The “ipn” scheme is 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-scheme EID is: “ipn:<node_number>.<service_number>”.

More formally, the “ipn” scheme is defined as follows. This specification uses 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.

None of the reserved characters defined in the generic URI syntax are used as delimiters within URIs of the IPN scheme. The “encoded” representation of an ipn-scheme URI’s ipn-hier-part is a sequence of two SDNVs, one for node number followed by one for service number.

Advantages: 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 environments.

Disadvantages: Node numbers are harder to remember than descriptive textual names. Administrative entities that are first claim the lower node numbers for assignment to their nodes have a permanent performance advantage.

2.2. Proposed Revised IPN Naming Scheme

The following is a proposed revision to the “ipn” scheme definition: To prevent an unseemly “land rush” to grab desirable node number ranges, we could revise the “ipn” scheme definition as follows.

1. No change to the native representation.
2. All node numbers are 63 bits in length, starting with a 1 bit, so no node number assignment range is any more advantageous than any other.
3. Node number has two components: “unit number” followed by “agent number”.
4. A "unit" is an administrative entity that is responsible for assigning all agent numbers in its scope. Each unit is identified by a number that is 7n bits in length (1 <= n <= 8); the length of the agent number of every agent in the unit’s scope is (63 – 7n) bits, and the scope of the unit is all node numbers that begin with the unit’s number.
5. The encoded representation of an ipn-scheme URI’s ipn-hier-part is still two SDNVs, node number and service number, except that the unit number component of the node number may be omitted so long as it can be determined either a. Implicitly (i.e., it's the same as the unit number of the node that's currently processing the bundle) or b. Explicitly (i.e., it's provided in a separate unit number extension block, that is attached to the bundle when the bundle must be processed by a node that is in a unit other than that of the node that's currently processing the bundle).

So bundle exchange among nodes of the same unit can benefit from abbreviated EID representations, but bundle exchange among nodes of different units is fully supported – all node numbers are unique.

2.3. Alternate Numeric Scheme Based on TLVs

The current and proposed revised IPN naming schemes are based on SDNVs. SDNV encoding provides 7 bits of data plus 1 "continuation" bit in each octet. SDNVs are permitted to carry values up to 64 bits in length, which may or may not be too restrictive in some cases.

Due to the 7 bit limitation, however, certain values can cause SDNVs to require more octets than an ordinary 8 bit octet. For example, using SDNVs the values 0-127 can be encoded in a single octet while the values 128-255 require two octets. This means that care must be taken in assigning specific numbers that would avoid inefficient SDNV encodings.

An alternate numeric scheme would have a Type, Length Value (TLV) encoding. The Type is one and the same as "scheme name" in the DTN URI format. Type is followed by a 1-octet Length field that encodes the number of Value octets that follow. Value encodes a simple numeric value up to 255 octets in length. For the purpose of this specification, alternate numeric values are in the range 0 through 2^64, meaning only up to 8 octets of Value are required.

The alternate numeric scheme is formatted as a 24bit organization code followed by a 40bit node ID. The organization code is assigned by a numbers authority such as IANA.

In the alternate numeric TLV scheme, when two communicating nodes share the same 24bit organization code the Value field can be truncated to omit the organization code plus any leading all-zero octets in the 40-bit node ID field. So, for example, if the node ID field encodes the value '1', and the correspondent encodes the same organization code, the TLV encodes the one-octet scheme name as the Type followed by a one-octet Length that encodes the value 1, followed by a one-octet Value that encodes the value 1.

3. IANA Considerations

This document introduces no IANA considerations.

4. Security Considerations

TBD.

5. Acknowledgements

TBD

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses