One document matched: draft-irtf-dtnrg-cbhe-00.txt
Network Working Group S. Burleigh
Internet-Draft Jet Propulsion Laboratory,
Intended status: Experimental California Institute of
Expires: June 7, 2009 Technology
December 4, 2008
Compressed Bundle Header Encoding (CBHE)
draft-irtf-dtnrg-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 June 7, 2009.
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 [RFC2119].
Burleigh Expires June 7, 2009 [Page 1]
Internet-Draft CBHE December 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Compression convention . . . . . . . . . . . . . . . . . . . . 3
2.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Transmission . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Reception . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Burleigh Expires June 7, 2009 [Page 2]
Internet-Draft CBHE December 2008
1. Introduction
This document describes a convention for representing Delay-Tolerant
Networking (DTN) Bundle Protocol (BP) [RFC5050] 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].
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
2.1. Constraints
Compressed Bundle Header Encoding (CBHE) is possible only when all
non-null endpoint IDs in the primary block of a given bundle (that
Burleigh Expires June 7, 2009 [Page 3]
Internet-Draft CBHE December 2008
is, all endpoint IDs in the primary block that are not "dtn:none")
are "CBHE-conformant".
Two classes of endpoint IDs are CBHE-conformant.
First, any endpoint ID whose scheme name is "ipn" is CBHE-conformant.
The scheme specification for the "ipn" scheme requires that the hier-
part be a path-rootless of the form NODE_NUMBER.SERVICE_NUMBER. For
example, "ipn:9.37" would be a valid URI and a CBHE-conformant
endpoint ID.
Second, any endpoint ID whose scheme name is "dtn" and whose
authority component is "cbhe.ccsds.org" is CBHE-conformant. The
scheme specification for the "dtn" scheme requires that the path
component of each URI formed within the "dtn" scheme that is
characterized by authority component "cbhe.ccsds.org" be a path-
absolute of the form /NODE_NUMBER.SERVICE_NUMBER. For example,
"dtn://cbhe.ccsds.org/9.37" would be a valid URI and a CBHE-
conformant endpoint ID.
CBHE-conformant endpoint IDs of both classes that have the same node
number and service number are equivalent and interchangeable
identifiers for the same endpoint.
By convention, node number is some non-negative integer that
identifies a BP node. In a spacecraft flight operations context, for
example, spacecraft identifier might be used as node number.
Node number zero is used to indicate the null endpoint. Any CBHE-
conformant EID whose node number is zero, regardless of service
number, is interpreted 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 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
Burleigh Expires June 7, 2009 [Page 4]
Internet-Draft CBHE December 2008
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.
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.
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;
the scheme of each resulting endpoint identifier may be either "ipn"
Burleigh Expires June 7, 2009 [Page 5]
Internet-Draft CBHE December 2008
or "dtn", an implementation choice.
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
Permanent registration of the scheme name "ipn" will be requested.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
CBHE introduces no new security considerations beyond those discussed
in the DTN Bundle Protocol and Bundle Security Protocol
specifications.
Burleigh Expires June 7, 2009 [Page 6]
Internet-Draft CBHE December 2008
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 June 7, 2009 [Page 7]
Internet-Draft CBHE December 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Burleigh Expires June 7, 2009 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 10:43:12 |