Delay Tolerant Network (DTN) Numeric Node IDs
draft-templin-dtn-numid-01

Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                               S. Burleigh
Expires: October 8, 2016                 JPL, Calif. Inst. Of Technology
                                                           April 6, 2016

             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

Templin & Burleigh       Expires October 8, 2016                [Page 1]
Internet-Draft            DTN Numeric Node IDs                April 2016

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Numeric Node ID Alternatives  . . . . . . . . . . . . . . . .   2
     2.1.  IPN Naming Scheme . . . . . . . . . . . . . . . . . . . .   2
     2.2.  Proposed Revised IPN Naming Scheme  . . . . . . . . . . .   3
     2.3.  Alternate Numeric Scheme Based on TLVs  . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

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

Templin & Burleigh       Expires October 8, 2016                [Page 2]
Internet-Draft            DTN Numeric Node IDs                April 2016

   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:

   o  ipn-uri = "ipn:" ipn-hier-part

   o  ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless

   o  node-nbr = 1*DIGIT

   o  nbr-delim = "."

   o  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

Templin & Burleigh       Expires October 8, 2016                [Page 3]
Internet-Draft            DTN Numeric Node IDs                April 2016

       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

Templin & Burleigh       Expires October 8, 2016                [Page 4]
Internet-Draft            DTN Numeric Node IDs                April 2016

   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

   [I-D.dtnwg-bp]
              Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
              draft-dtnwg-bp-00 (work in progress), June 2015.

6.2.  Informative References

   [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
              (IANA) Header Field Parameter Registry for the Session
              Initiation Protocol (SIP)", BCP 98, RFC 3968,
              DOI 10.17487/RFC3968, December 2004,
              <http://www.rfc-editor.org/info/rfc3968>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

Authors' Addresses

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org

Templin & Burleigh       Expires October 8, 2016                [Page 5]
Internet-Draft            DTN Numeric Node IDs                April 2016

   Scott Burleigh
   JPL, Calif. Inst. Of Technology
   4800 Oak Grove Dr.
   Pasadena, CA  91109-8099
   USA

   Phone: +1 818 393 3353
   Email: Scott.Burleigh@jpl.nasa.gov

Templin & Burleigh       Expires October 8, 2016                [Page 6]