Internet DRAFT - draft-templin-dtn-numid
draft-templin-dtn-numid
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]
