idnits 2.17.1 draft-burleigh-cbhe-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 309. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 4, 2007) is 6320 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay-Tolerant Networking Research Group S. Burleigh 3 Internet-Draft Jet Propulsion Laboratory, 4 Intended status: Experimental California Institute of 5 Expires: July 8, 2007 Technology 6 January 4, 2007 8 Compressed Bundle Header Encoding (CBHE) 9 draft-burleigh-cbhe-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 8, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2007). 40 Abstract 42 This document describes a convention for representing Delay-Tolerant 43 Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a 44 compressed manner within the primary blocks of bundles. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [RFC2119]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Compression convention . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Transmission . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Reception . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Intellectual Property and Copyright Statements . . . . . . . . . . 8 67 1. Introduction 69 This document describes a convention for representing Delay-Tolerant 70 Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a 71 compressed manner within the primary blocks of bundles. 73 Each DTN bundle's primary block contains four BP endpoint identifiers 74 (EIDs), of which any two, any three, or even all four may be 75 lexically identical: the endpoint identifiers of the source, the 76 destination, the report-to endpoint, and the current custodian. Each 77 EID is a Uniform Record Identifier (URI), an ASCII string of the form 78 "scheme_name:scheme_specific_part". 80 A degree of block compression is provided by the design of the 81 primary block: the scheme names and scheme-specific parts of the four 82 endpoints' IDs - up to eight NULL-terminated strings - are 83 concatenated at the end of the block in a variable-length character 84 array called a "dictionary", enabling each EID to be represented by a 85 pair of integers indicating the offsets (within the dictionary) of 86 the EID's scheme name and scheme-specific part. Duplicate strings 87 may be omitted from the dictionary, so the actual number of 88 concatenated NULL-terminated strings in the dictionary may be less 89 than eight and two or more of the scheme name or scheme-specific part 90 offsets in the block may have the same value. Moreover, the eight 91 offsets in the primary block are encoded as self-delimiting numeric 92 values (SDNVs), which shrink to fit the encoded values; when the 93 total length of the dictionary is less than 127 bytes, all eight 94 offsets can be encoded into just eight bytes. 96 However, these strategems do not prevent the scheme names and scheme- 97 specific parts themselves from being arbitrarily lengthy strings of 98 ASCII text. It is therefore still possible for the length of a 99 bundle's primary header to be a very large fraction of the total 100 length of the bundle when the bundle's payload is relatively small, 101 as is anticipated for a number of DTN applications such as space 102 flight operations. 104 The Compressed Bundle Header Encoding (CBHE) convention was developed 105 to improve DTN transmission efficiency for such applications by 106 further reducing the number of bytes used to express EIDs in the 107 primary blocks of bundles. 109 2. Compression convention 110 2.1. Constraints 112 Compressed Bundle Header Encoding (CBHE) is possible only when the 113 scheme names of all non-null endpoint IDs in the primary block of a 114 given bundle (that is, all endpoint IDs in the primary block that are 115 not "dtn:none") identify a single scheme that is understood 116 universally within the network to be "CBHE-conformant". 118 All CBHE-conformant schemes are numbered and are identifiable by 119 their numbers as well as their names. A one-to-one correspondence 120 between scheme numbers and the names of CBHE-conformant schemes is 121 assumed to be well-known throughout the network (either by management 122 or, as the scope of the network grows, by means of a protocol yet to 123 be developed). 125 The scheme-specific part of each entity-identifying URI whose scheme 126 name identifies a CBHE-conformant scheme must be of the form 127 "element_number.service_number". 129 By convention, element number is a non-negative integer that can be 130 thought of as a BP node identifier, such as a spacecraft identifier. 131 Element number zero is used to indicate the null endpoint; any EID 132 whose scheme name identifies a CBHE-conformant scheme and whose 133 element number is zero, regardless of service number, is interpreted 134 within the CBHE convention as an alternative representation of the 135 standard null endpoint ID "dtn:none". 137 By convention, service number is a non-negative integer that 138 functions as a de-multiplexing token. When the protocol encapsulated 139 within BP has its own de-multiplexing identifiers, the service number 140 may function in a manner similar to that of the protocol number in an 141 IP packet, characterizing the bundle payload; alternatively, the 142 service number may function in a manner similar to that of the port 143 number in a UDP datagram. Service numbers enable inbound bundles' 144 application data units to be de-multiplexed to elements of 145 application functionality that are designed to process them, so that 146 effective communication relationships can be developed between bundle 147 producers and consumers. 149 Service number zero is used exclusively to identify BP custody signal 150 traffic. 152 Conversion of an EID in URI form - where the URI's scheme is CBHE- 153 conformant - to and from a tuple of three integers is therefore 154 straightforward. This ease of conversion enables an array of 155 integers to serve the same function as a dictionary of EID ASCII 156 strings. 158 To summarize, CBHE representation of EIDs in a given bundle's primary 159 block is constrained as follows: 161 o The scheme names of all non-null endpoint IDs must be the same. 163 o The scheme name common to all non-null endpoint IDs must identify 164 a scheme that is well-known to be CBHE-conformant, and that scheme 165 must be uniquely identified by a well-known scheme number. 167 o The scheme-specific parts of all non-null endpoint IDs must be in 168 "element_number.service_number" form, where both element_number 169 and service_number are non-negative integers. 171 o If the bundle's Current Custodian endpoint ID is not null, then 172 the service number for that endpoint ID must be zero. 174 2.2. Method 176 When the constraints summarized above are met, the CBHE block 177 compression method can be applied. In a CBHE-compressed primary 178 block, the eight SDNVs that normally contain EIDs' offsets within the 179 dictionary are instead used to contain the eight integer values 180 listed below, in the order shown: 182 1. The scheme number that is common to all non-null endpoint IDs. 184 2. The element number of the destination endpoint ID, or zero if the 185 destination endpoint is the null endpoint. 187 3. The service number of the destination endpoint ID, or zero if the 188 destination endpoint is the null endpoint. 190 4. The element number of the source endpoint ID, or zero if the 191 source endpoint is the null endpoint. 193 5. The service number of the source endpoint ID, or zero if the 194 source endpoint is the null endpoint. 196 6. The element number of the report-to endpoint ID, or zero if the 197 report-to endpoint is the null endpoint. 199 7. The service number of the report-to endpoint ID, or zero if the 200 report-to endpoint is the null endpoint. 202 8. The element number of the current custodian endpoint ID, or zero 203 if the current custodian endpoint is the null endpoint. 205 Further, the dictionary is omitted from the primary block and the 206 primary block's dictionary length is set to zero. 208 This compression method is applied at the convergence layer: the 209 transmitting convergence-layer adaptation compresses the primary 210 block as shown above, and upon reception the receiving convergence- 211 layer adaptation de-compresses the block by simply reversing the 212 process. 214 3. Specification 216 CBHE compression is a convergence-layer adaptation. It is opaque to 217 bundle processing. It therefore has no impact on the 218 interoperability of different Bundle Protocol implementations, but 219 instead affects only the interoperability of different convergence 220 layer adaptation implementations. 222 Bundle Protocol convergence-layer adapters that conform to the CBHE 223 specification must implement the following procedures. 225 3.1. Transmission 227 When and only when required by the bundle protocol agent to transmit 228 to some CBHE-conformant convergence-layer adapter a bundle whose 229 primary block's endpoint IDs satisfy the constraints summarized in 230 section 2.1 above and whose extension blocks (if any) contain no 231 citations of endpoint IDs that are contained in the primary block's 232 dictionary, the convergence layer adapter may encode the primary 233 block of the bundle in accordance with the CBHE compression 234 convention described in section 2.2 above. 236 3.2. Reception 238 Upon receiving a bundle whose dictionary length is zero (and only in 239 this circumstance), the convergence layer adapter must decode the 240 primary block of the bundle in accordance with the CBHE compression 241 convention described in section 2.2 above before delivering it to the 242 bundle protocol agent. 244 4. IANA Considerations 246 A new registry of CBHE-conformant URI schemes and corresponding 247 scheme numbers may be needed. 249 Note to RFC Editor: this section may be removed on publication as an 250 RFC. 252 5. Security Considerations 254 CBHE introduces no new security considerations beyond those discussed 255 in the DTN Bundle Protocol and Bundle Security Protocol 256 specifications. 258 6. Normative References 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 Author's Address 265 Scott Burleigh 266 Jet Propulsion Laboratory, California Institute of Technology 267 4800 Oak Grove Drive, m/s 301-490 268 Pasadena, CA 91109 269 USA 271 Full Copyright Statement 273 Copyright (C) The Internet Society (2007). 275 This document is subject to the rights, licenses and restrictions 276 contained in BCP 78, and except as set forth therein, the authors 277 retain all their rights. 279 This document and the information contained herein are provided on an 280 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 281 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 282 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 283 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 284 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 285 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 287 Intellectual Property 289 The IETF takes no position regarding the validity or scope of any 290 Intellectual Property Rights or other rights that might be claimed to 291 pertain to the implementation or use of the technology described in 292 this document or the extent to which any license under such rights 293 might or might not be available; nor does it represent that it has 294 made any independent effort to identify any such rights. Information 295 on the procedures with respect to rights in RFC documents can be 296 found in BCP 78 and BCP 79. 298 Copies of IPR disclosures made to the IETF Secretariat and any 299 assurances of licenses to be made available, or the result of an 300 attempt made to obtain a general license or permission for the use of 301 such proprietary rights by implementers or users of this 302 specification can be obtained from the IETF on-line IPR repository at 303 http://www.ietf.org/ipr. 305 The IETF invites any interested party to bring to its attention any 306 copyrights, patents or patent applications, or other proprietary 307 rights that may cover technology that may be required to implement 308 this standard. Please address the information to the IETF at 309 ietf-ipr@ietf.org. 311 Acknowledgment 313 Funding for the RFC Editor function is provided by the IETF 314 Administrative Support Activity (IASA).