Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational S. Burleigh
Expires: January 8, 2017 JPL, Calif. Inst. Of Technology
July 7, 2016
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
Templin & Burleigh Expires January 8, 2017 [Page 1]
Internet-Draft DTN Numeric Node IDs July 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 . . . . . . . . . . . . . . . . . . . . 3
2.2. Alternate Numeric Naming Schemes . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 6
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
Templin & Burleigh Expires January 8, 2017 [Page 2]
Internet-Draft DTN Numeric Node IDs July 2016
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:
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.
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,
Templin & Burleigh Expires January 8, 2017 [Page 3]
Internet-Draft DTN Numeric Node IDs July 2016
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:
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
Templin & Burleigh Expires January 8, 2017 [Page 4]
Internet-Draft DTN Numeric Node IDs July 2016
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
[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.
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
[I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
draft-ietf-dtn-bpbis-04 (work in progress), July 2016.
[I-D.ietf-dtn-bpsec]
Birrane, E., Pierce-Mayer, J., and D. Iannicca, "Bundle
Protocol Security Specification", draft-ietf-dtn-bpsec-01
(work in progress), March 2016.
6.2. Informative References
[I-D.burleigh-dtn-rs-cbor]
Burleigh, S., "Bundle Protocol CBOR Representation
Specification", draft-burleigh-dtn-rs-cbor-01 (work in
progress), April 2016.
Templin & Burleigh Expires January 8, 2017 [Page 5]
Internet-Draft DTN Numeric Node IDs July 2016
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[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>.
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)",
RFC 6260, DOI 10.17487/RFC6260, May 2011,
<http://www.rfc-editor.org/info/rfc6260>.
[RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission
Protocol (LTP), Compressed Bundle Header Encoding (CBHE),
and Bundle Protocol IANA Registries", RFC 7116,
DOI 10.17487/RFC7116, February 2014,
<http://www.rfc-editor.org/info/rfc7116>.
Authors' Addresses
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
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 January 8, 2017 [Page 6]