Delay-Tolerant Networking Research Group S. Burleigh Internet-Draft Jet Propulsion Laboratory, Intended status: Experimental California Institute of Expires: July 8, 2007 Technology January 4, 2007 Compressed Bundle Header Encoding (CBHE) draft-burleigh-cbhe-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 July 8, 2007. Copyright Notice Copyright (C) The Internet Society (2007). 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", Burleigh Expires July 8, 2007 [Page 1] Internet-Draft CBHE January 2007 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Compression convention . . . . . . . . . . . . . . . . . . . . 3 2.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Transmission . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Reception . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Burleigh Expires July 8, 2007 [Page 2] Internet-Draft CBHE January 2007 1. Introduction 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. 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), an ASCII string of the form "scheme_name:scheme_specific_part". 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 arbitrarily 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 Burleigh Expires July 8, 2007 [Page 3] Internet-Draft CBHE January 2007 2.1. Constraints Compressed Bundle Header Encoding (CBHE) is possible only when the scheme names of all non-null endpoint IDs in the primary block of a given bundle (that is, all endpoint IDs in the primary block that are not "dtn:none") identify a single scheme that is understood universally within the network to be "CBHE-conformant". All CBHE-conformant schemes are numbered and are identifiable by their numbers as well as their names. A one-to-one correspondence between scheme numbers and the names of CBHE-conformant schemes is assumed to be well-known throughout the network (either by management or, as the scope of the network grows, by means of a protocol yet to be developed). The scheme-specific part of each entity-identifying URI whose scheme name identifies a CBHE-conformant scheme must be of the form "element_number.service_number". By convention, element number is a non-negative integer that can be thought of as a BP node identifier, such as a spacecraft identifier. Element number zero is used to indicate the null endpoint; any EID whose scheme name identifies a CBHE-conformant scheme and whose element number is zero, regardless of service number, is interpreted within the CBHE convention as an alternative representation of the standard null endpoint ID "dtn:none". 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 elements 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 used exclusively to identify BP custody signal traffic. Conversion of an EID in URI form - where the URI's scheme is CBHE- conformant - to and from a tuple of three 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. Burleigh Expires July 8, 2007 [Page 4] Internet-Draft CBHE January 2007 To summarize, CBHE representation of EIDs in a given bundle's primary block is constrained as follows: o The scheme names of all non-null endpoint IDs must be the same. o The scheme name common to all non-null endpoint IDs must identify a scheme that is well-known to be CBHE-conformant, and that scheme must be uniquely identified by a well-known scheme number. o The scheme-specific parts of all non-null endpoint IDs must be in "element_number.service_number" form, where both element_number and service_number are non-negative integers. o If the bundle's Current Custodian endpoint ID is not null, then the service number for that endpoint ID must be zero. 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 scheme number that is common to all non-null endpoint IDs. 2. The element number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint. 3. The service number of the destination endpoint ID, or zero if the destination endpoint is the null endpoint. 4. The element number of the source endpoint ID, or zero if the source endpoint is the null endpoint. 5. The service number of the source endpoint ID, or zero if the source endpoint is the null endpoint. 6. The element number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint. 7. The service number of the report-to endpoint ID, or zero if the report-to endpoint is the null endpoint. 8. The element 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 Burleigh Expires July 8, 2007 [Page 5] Internet-Draft CBHE January 2007 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, and 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 summarized 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 A new registry of CBHE-conformant URI schemes and corresponding scheme numbers may be needed. Note to RFC Editor: this section may be removed on publication as an RFC. Burleigh Expires July 8, 2007 [Page 6] Internet-Draft CBHE January 2007 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Scott Burleigh Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grove Drive, m/s 301-490 Pasadena, CA 91109 USA Burleigh Expires July 8, 2007 [Page 7] Internet-Draft CBHE January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Burleigh Expires July 8, 2007 [Page 8]