Compressed Bundle Header Encoding (CBHE)
draft-irtf-dtnrg-cbhe-01

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

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 September 6, 2009.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document describes a convention for representing Delay-Tolerant Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a compressed manner within the primary blocks of bundles.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

1.  Introduction
2.  Compression convention
    2.1.  Constraints
    2.2.  Method
3.  Specification
    3.1.  Transmission
    3.2.  Reception
4.  IANA Considerations
5.  Security Considerations
6.  Normative References
§  Author's Address

1.  Introduction

This document describes a convention for representing Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] (Scott, K. and S. Burleigh, “Bundle Protocol Specification,” November 2007.) endpoint identifiers in a compressed manner within the primary blocks of bundles.

Each DTN bundle's primary block contains 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] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).

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 offsets can be encoded into just eight bytes.

However, these strategems do not prevent the scheme names and 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.

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 to express 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 whose scheme name is "dtn" and whose authority component is "cbhe.ccsds.org".

The specification for URIs formed within the "dtn" scheme requires that the path component of each such URI that is characterized by authority component "cbhe.ccsds.org" be a path-absolute of the form /NODE_NUMBER.SERVICE_NUMBER.

By convention, node number is a natural number that identifies a BP node. In a spacecraft flight operations context, for example, spacecraft identifier might be used as node number.

Node number must be an integer in the range 1 to (2^64 - 1). Node number zero is reserved for representation of the null endpoint ID in the compressed form described later in this specification; decompressing a compressed null EID must always yield the standard null endpoint ID URI "dtn:none". Negative integers and integers larger than (2^64 - 1) cannot be compressed into the SDNVs that are used for representation of endpoint ID references in the primary blocks of bundles and therefore could not be compressed as described later.

By convention, service number is a non-negative integer that functions as a de-multiplexing token. When the protocol encapsulated within BP 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 bundle payload; 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 zero is reserved for BP administrative traffic, i.e., custody signals and bundle status reports. Service number must be zero whenever a CBHE-conformant EID is used as the source or destination EID of a custody signal. Service number may be zero whenever a CBHE-conformant EID is used as the source or destination EID of a bundle status report. 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://cbhe.ccsds.org/9.37" would be a CBHE-conformant endpoint ID.

Conversion of a CBHE-conformant EID to and from a tuple of two integers is therefore straightforward. 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 endpoint ID reference 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 block compression is that the endpoint ID reference strings in the dictionary of the bundle to be compressed must be as follows:

1. The scheme name of the destination endpoint ID.
2. The scheme-specific part of the destination endpoint ID.
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.

2.2.  Method

When the constraints summarized above are met, the CBHE block compression method can be applied. In a CBHE-compressed primary block, the eight SDNVs that normally contain EIDs' 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.
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 constant BP administration service number zero.

Further, the dictionary is omitted from the primary block and the primary block's dictionary length is set to zero.

This compression method is applied at the convergence layer: the transmitting convergence-layer adaptation compresses the primary block as shown above. Upon reception the receiving convergence-layer adaptation de-compresses the block by simply reversing the process.

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 and whose extension blocks (if any) contain no citations of endpoint IDs that are contained in the primary block's dictionary, 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.

3.2.  Reception

Upon receiving a bundle whose dictionary length is zero (and only in this circumstance), the 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.

4.  IANA Considerations

This document has no IANA considerations.

5.  Security Considerations

CBHE introduces no new security considerations beyond those discussed in the DTN Bundle Protocol and Bundle Security Protocol specifications.

6. Normative References

Author's Address