One document matched: draft-burleigh-cbhe-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 13:41:53 |