Network Working Group S. Burleigh
Internet-Draft Jet Propulsion Laboratory,
Intended status: Experimental California Institute of
Expires: August 22, 2010 Technology
February 18, 2010
Compressed Bundle Header Encoding (CBHE)
draft-irtf-dtnrg-cbhe-04
Abstract
This document describes a convention by which Delay-Tolerant
Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters
may represent endpoint identifiers in a compressed form within the
primary blocks of bundles, provided those endpoint identifiers
conform to the structure prescribed by this convention.
CBHE compression is a convergence-layer adaptation. It is opaque to
bundle processing. It therefore has no impact on the
interoperability of different Bundle Protocol implementations, but
instead affects only the interoperability of different convergence
layer adaptation implementations.
This document is a product of the Delay Tolerant Networking Research
Group and has been reviewed by that group. No objections to its
publication as an RFC were raised.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
Burleigh Expires August 22, 2010 [Page 1]
Internet-Draft CBHE February 2010
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2010.
Copyright Notice
Copyright (c) 2010 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 BSD License.
Burleigh Expires August 22, 2010 [Page 2]
Internet-Draft CBHE February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Compression convention . . . . . . . . . . . . . . . . . . . . 5
2.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transmission . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Reception . . . . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Burleigh Expires August 22, 2010 [Page 3]
Internet-Draft CBHE February 2010
1. Introduction
This document describes a convention by which Delay-Tolerant
Networking (DTN) Bundle Protocol (BP) [RFC5050] "convergence-layer
adapters" may represent endpoint identifiers in a compressed form
within the primary blocks of bundles, provided those endpoint
identifiers conform to the structure prescribed by this convention.
Each DTN bundle's primary block contains at least the following four
BP endpoint identifiers (EIDs), of which any two, any three, or even
all four may be lexically identical: the endpoint identifiers of the
source, the destination, the report-to endpoint, and the current
custodian. Each EID is a Uniform Record Identifier (URI) as defined
by [RFC3986]. More specifically, each BP EID is a URI consisting of
a "scheme name" followed by ":", followed by a sequence of characters
-- historically termed the "scheme-specific part" (SSP) in DTN
specifications -- conforming to URI syntax as defined by RFC3986.
The only valid scheme name for BP EIDs identified to date is "dtn".
No specification of valid SSP syntax for URIs composed within the
"dtn" scheme has yet been formally defined, but at the time of this
writing there is rough consensus within the DTN Research Group that a
"dtn"-scheme SSP must be either the string "none" or else a sequence
of one or more "DTN URI elements" separated by "!" characters. Each
DTN URI element must consist of an optional "operation name" followed
by a mandatory ":", followed by a string -- here termed a
"designator" -- that is itself in the form of a URI. Within any
single DTN URI element, the portion of the designator that would be
interpreted as the scheme name if the designator were parsed as a URI
is termed the designator's "namespace name" and the portion following
the ":" that delimits the namespace name is termed the designator's
namespace-specific string (NSS). Adherence to this syntax
specification is assumed in the definition of CBHE.
A degree of block compression is provided by the design of the
primary block: the scheme names and scheme-specific parts of the four
endpoints' IDs - up to eight NULL-terminated strings - are
concatenated at the end of the block in a variable-length character
array called a "dictionary", enabling each EID to be represented by a
pair of integers indicating the offsets (within the dictionary) of
the EID's scheme name and scheme-specific part. Duplicate strings
may be omitted from the dictionary, so the actual number of
concatenated NULL-terminated strings in the dictionary may be less
than eight and two or more of the scheme name or scheme-specific part
offsets in the block may have the same value. Moreover, the eight
offsets in the primary block are encoded as self-delimiting numeric
values (SDNVs), which shrink to fit the encoded values; when the
total length of the dictionary is less than 127 bytes, all eight
Burleigh Expires August 22, 2010 [Page 4]
Internet-Draft CBHE February 2010
offsets can be encoded into just eight bytes.
However, these strategems do not prevent the scheme names and
especially the scheme-specific parts themselves from being lengthy
strings of ASCII text. It is therefore still possible for the length
of a bundle's primary header to be a very large fraction of the total
length of the bundle when the bundle's payload is relatively small,
as is anticipated for a number of DTN applications such as space
flight operations (and as is in any case true of bundles carrying BP
administrative records).
The Compressed Bundle Header Encoding (CBHE) convention was developed
to improve DTN transmission efficiency for such applications by
further reducing the number of bytes used by convergence-layer
adapters to represent EIDs in the primary blocks of bundles.
2. Compression convention
2.1. Constraints
Compressed Bundle Header Encoding (CBHE) is possible only when all
endpoint IDs in the primary block of a given bundle are "CBHE-
conformant". Two forms of endpoint ID are CBHE-conformant: (a) the
null endpoint ID "dtn:none" and (b) any endpoint ID formed within the
"dtn" scheme whose SSP comprises only a single DTN URI element whose
operation name is of length zero and whose designator's NSS is of the
form NODE_NUMBER.SERVICE_NUMBER.
Any number of different namespace names may appear in the designators
of CBHE-conformant EIDs. However, CBHE compression is possible
between a pair of convergence-layer adapters only when each one is
configured to compress only those CBHE-conformant EIDs that cite some
single assigned namespace *and* that assigned namespace is the same
for both adapters.
The node number is a positive integer that notionally identifies a BP
node. In a spacecraft flight operations context, for example,
spacecraft identifiers might be used as node numbers. However,
methods for assigning node numbers to BP nodes are beyond the scope
of this document; in particular, no requirement or guarantee of a
one-to-one mapping between node numbers and BP nodes may be inferred.
Node number must be an integer in the range 1 to (2^64 - 1).
Negative integers and integers larger than (2^64 - 1) cannot be
encoded into the SDNVs that are used for representation of scheme
name and SSP offsets in the primary blocks of bundles and therefore
could not be compressed as described later in this specification.
Burleigh Expires August 22, 2010 [Page 5]
Internet-Draft CBHE February 2010
Node number zero is reserved for representation of the null endpoint
ID in the compressed form described later; decompressing a compressed
null EID must always yield the standard null endpoint ID URI "dtn:
none".
The service number is a non-negative integer that notionally
functions as a de-multiplexing token. When the bundle payload is a
protocol data unit of some protocol that has its own de-multiplexing
identifiers, the service number may function in a manner similar to
that of the protocol number in an IP packet, characterizing the
encapsulated protocol; alternatively, the service number may function
in a manner similar to that of the port number in a UDP datagram.
Service numbers enable inbound bundles' application data units to be
de-multiplexed to instances of application functionality that are
designed to process them, so that effective communication
relationships can be developed between bundle producers and
consumers.
Service number must not be negative or exceed (2^64 - 1) for the same
reason that node number must not do so.
For example, "dtn::ipn:9.37" would be a CBHE-conformant endpoint ID
citing the namespace "ipn".
Conversion of a CBHE-conformant EID to and from a tuple of two
integers is therefore straightforward: all characters in the EID
other than the node number and service number are constant (either as
defined by CBHE or as assigned during convergence-layer adapter
configuration) and the node number and service number are taken as
the two integers of the tuple. This ease of conversion enables an
array of integers to serve the same function as a dictionary of EID
ASCII strings.
Note, however, that CBHE decompression cannot faithfully recreate the
dictionary of a compressed primary block from an array of integers
unless the order of the scheme names and scheme-specific part strings
in the dictionary of the original, uncompressed block is known. (The
bundle protocol specification does not require that the strings in
the dictionary appear in any particular order and does not require
that redundant strings be omitted from the dictionary.) Therefore, a
further precondition to CBHE compression is that the strings in the
dictionary of the bundle to be compressed must be exactly as follows,
in this order and without addition:
1. The scheme name of the destination endpoint ID.
2. The scheme-specific part of the destination endpoint ID.
Burleigh Expires August 22, 2010 [Page 6]
Internet-Draft CBHE February 2010
3. The scheme name of the source endpoint ID, if and only if
different from any prior string in the dictionary.
4. The scheme-specific part of the source endpoint ID, if and only
if different from any prior string in the dictionary.
5. The scheme name of the report-to endpoint ID, if and only if
different from any prior string in the dictionary.
6. The scheme-specific part of the report-to endpoint ID, if and
only if different from any prior string in the dictionary.
7. The scheme name of the current custodian endpoint ID, if and only
if different from any prior string in the dictionary.
8. The scheme-specific part of the current custodian endpoint ID, if
and only if different from any prior string in the dictionary.
Note: this constraint implies that a bundle which includes any
extension blocks containing EID references to endpoint IDs other than
the block's destination, source, report-to, and current custodian
cannot be CBHE-compressed.
2.2. Method
When the constraints summarized above are met, the CBHE block
compression method can be applied by the convergence layer adapter at
the time the bundle is transmitted via a convergence-layer protocol.
In a CBHE-compressed primary block, the eight SDNVs that normally
contain EIDs' scheme name and SSP offsets within the dictionary are
instead used to contain the eight integer values listed below, in the
order shown:
1. The node number of the destination endpoint ID, or zero if the
destination endpoint is the null endpoint.
2. The service number of the destination endpoint ID, or zero if the
destination endpoint is the null endpoint.
3. The node number of the source endpoint ID, or zero if the source
endpoint is the null endpoint.
4. The service number of the source endpoint ID, or zero if the
source endpoint is the null endpoint.
5. The node number of the report-to endpoint ID, or zero if the
report-to endpoint is the null endpoint.
Burleigh Expires August 22, 2010 [Page 7]
Internet-Draft CBHE February 2010
6. The service number of the report-to endpoint ID, or zero if the
report-to endpoint is the null endpoint.
7. The node number of the current custodian endpoint ID, or zero if
the current custodian endpoint is the null endpoint.
8. The service number of the current custodian endpoint ID, or zero
if the current custodian endpoint is the null endpoint.
Further, the dictionary is omitted from the primary block and the
primary block's dictionary length is set to zero.
Upon reception the receiving convergence-layer adaptation de-
compresses the block by simply reversing the process so that the
bundle presented to the bundle protocol agent has the standard form
(i.e., the dictionary is reconstituted).
3. Specification
CBHE compression is a convergence-layer adaptation. It is opaque to
bundle processing. It therefore has no impact on the
interoperability of different Bundle Protocol implementations, but
instead affects only the interoperability of different convergence
layer adaptation implementations.
Bundle Protocol convergence-layer adapters that conform to the CBHE
specification must implement the following procedures.
3.1. Transmission
When and only when required by the bundle protocol agent to transmit
to some CBHE-conformant convergence-layer adapter a bundle whose
primary block's endpoint IDs satisfy the constraints identified in
section 2.1 above, the convergence layer adapter MAY encode the
primary block of the bundle in accordance with the CBHE compression
convention described in section 2.2 above.
Note that CBHE compression may be applied only when the receiving
convergence-layer adapter is known to be CBHE-conformant, i.e., able
to decode the encoded primary block. When the convergence-layer
adapter to which the bundle is to be transmitted is not known to be
CBHE-conformant, CBHE compression MUST NOT be applied. The manner in
which this determination is made is an implementation matter.
Burleigh Expires August 22, 2010 [Page 8]
Internet-Draft CBHE February 2010
3.2. Reception
Upon receiving a bundle whose dictionary length is zero (and only in
this circumstance), a CBHE-conformant convergence layer adapter MUST
decode the primary block of the bundle in accordance with the CBHE
compression convention described in section 2.2 above before
delivering it to the bundle protocol agent.
Note that when a non-CBHE-conformant convergence layer adapter
receives a bundle whose dictionary length is zero, it has no choice
but to pass it to the bundle agent without modification. In this
case the bundle protocol agent will be unable to dispatch the
received bundle, because it will be unable to determine the
destination endpoint. The behavior of the bundle protocol agent in
this circumstance is an implementation matter.
4. IANA Considerations
This document has no IANA considerations.
5. Security Considerations
The Bundle Security Protocol may under some conditions insert
additional endpoint ID strings into the dictionary of a bundle and
reference those strings in BSP extension blocks. Because a bundle
which includes any extension blocks containing EID references to
endpoint IDs other than the block's destination, source, report-to,
and current custodian cannot be CBHE-compressed, bundles cannot be
compressed under those conditions.
Specifically, the specification detailed above implies that a bundle
cannot be CBHE-compressed when the security source endpoint for the
Bundle Authentication Block (BAB) is noted in the dictionary
(typically because there is no other way for the receiving bundle
protocol agent to determine the security source endpoint), when the
security destination endpoint for the BAB is noted in the dictionary
(in the rare case that the receiving endpoint is not the security
destination endpoint), when the security source endpoint for the
Payload Integrity Block (PIB), Payload Confidentiality Block (PCB),
or Extension Security Block (ESB) is not the source endpoint, or when
the security destination endpoint for the PIB, PCB, or ESB is not the
destination endpoint.
These caveats aside, CBHE introduces no new security considerations
beyond those discussed in the DTN Bundle Protocol and Bundle Security
Protocol specifications.
Burleigh Expires August 22, 2010 [Page 9]
Internet-Draft CBHE February 2010
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
Author's Address
Scott Burleigh
Jet Propulsion Laboratory, California Institute of Technology
4800 Oak Grove Drive, m/s 301-490
Pasadena, CA 91109
USA
Phone: +1 818 393 3353
Email: Scott.C.Burleigh@jpl.nasa.gov
Burleigh Expires August 22, 2010 [Page 10]
