idnits 2.17.1 draft-mosko-icnrg-ccnxchunking-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (June 1, 2016) is 2885 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'CCNx' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 315, but no explicit reference was found in the text -- Unexpected draft version: The latest known version of draft-mosko-icnrg-ccnxsemantics is -01, but you're referring to -03. -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Mosko 3 Internet-Draft PARC, Inc. 4 Intended status: Experimental June 1, 2016 5 Expires: December 3, 2016 7 CCNx Content Object Chunking 8 draft-mosko-icnrg-ccnxchunking-02 10 Abstract 12 This document specifies a chunking protocol for dividing a user 13 payload into CCNx Content Objects. This includes specification for 14 the naming convention to use for the chunked payload and a field 15 added to a Content Object to represent the last chunk of an object. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 3, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Chunking . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Cryptographic material . . . . . . . . . . . . . . . . . . 5 55 2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Name Types . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1.1. Chunk Number . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Protocol Information . . . . . . . . . . . . . . . . . . . 6 60 3.2.1. EndChunkNumber . . . . . . . . . . . . . . . . . . . . 7 61 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 CCNx Content Objects [CCNSemantics] are sized to amortize 72 cryptographic operations over user data while simultaneously staying 73 a reasonable size for transport over today's networks. This means a 74 Content Object is usually within common UDP or jumbo Ethernet size. 75 If a publisher has a larger amount of data to associate with a single 76 Name, the data should be chunked with this chunking protocol. This 77 protocol uses state in the Name and in an optional field within the 78 Content Object. A chunked object may also have an external metadata 79 content object that describes the original pre-chunked object. 81 CCNx uses two types of messages: Interests and Content Objects 82 [CCNSemantics]. An Interest carries the hierarchically structured 83 variable-length identifier (HSVLI), or Name, of a Content Object and 84 serves as a request for that object. If a network element sees 85 multiple Interests for the same name, it may aggregate those 86 Interests. A network element along the path of the Interest with a 87 matching Content Object may return that object, satisfying the 88 Interest. The Content Object follows the reverse path of the 89 Interest to the origin(s) of the Interest. A Content Object contains 90 the Name, the object's Payload, and the cryptographic information 91 used to bind the Name to the payload. 93 This specification adds a new segment to the Name TLV for conveying 94 the chunk number. It updates [CCNMessages]. It also provides 95 guidelines for the usage of the Key Locator in chunked objects. 97 Packets are represented as 32-bit wide words using ASCII art. 98 Because of the TLV encoding and optional fields or sizes, there is no 99 concise way to represent all possibilities. We use the convention 100 that ASCII art fields enclosed by vertical bars "|" represent exact 101 bit widths. Fields with a forward slash "/" are variable bitwidths, 102 which we typically pad out to word alignment for picture readability. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 2. Chunking 112 Chunking, as used in this specification, means serializing user data 113 into one or more chunks, each encapsulated in a CCNx Content Object. 114 A chunk is a contiguous byte range within the user data. One segment 115 in the Name of that Content Object represents the chunk number. A 116 field in the Content Object - only mandatory in the final chunk - 117 represents the end of the stream. Chunks are denoted by a serial 118 counter, beginning at 0 and incrementing by 1 for each contiguous 119 chunk. The chunking ends at the final chunk. No valid user data 120 exists beyond the final chunk, and reading beyond the final chunk 121 MUST NOT return any user data. 123 Chunking MUST use a fixed block size, where only the final chunk MAY 124 use a smaller block size. This is required to allow a reader to seek 125 to a specific byte offset once it knows the block size. The 126 blocksize may be inferred from the size of the first chunk of user 127 data. The first chunk of user data may not be chunk 0. 129 Because of the requirement for a fixed block size, the inclusion of 130 certain cryptographic fields in the same content objects as user data 131 would throw off the ability to seek. Therefore, it is RECOMMENDED 132 that all required cryptographic data, such as public keys or key name 133 links, be included in the leading chunks before the first byte of 134 user data. User data SHOULD then run continuously and with the same 135 block size through the remainder of the content objects. 137 This draft introduces a new Name path segment TLV type, called the 138 ChunkNumber name segment. The ChunkNumber name segment is the serial 139 order of the chunks. It MUST begin at 0 and MUST be incremented by 140 1. The ChunkNumber name segment is appended to the base name of the 141 user data, and is usually the last name segment. 143 The new Content Object field is the EndChunkNumber. It MUST be 144 included in the Content Object which is the last chunk of user data, 145 but SHOULD be present at the earliest time it is known. The value of 146 the EndChunkNumber should be the network byte order value of the last 147 ChunkNumber. For example, if 3000 bytes of user data is split with a 148 1200 byte block size, there will be 3 chunks: 0, 1, and 2. The 149 EndChunkNumber is 2. 151 The EndChunkNumber may be updated in later Chunks to a larger value, 152 as long as it has not yet reached the end. The EndChunkNumber SHOULD 153 NOT decrease. If a publisher wishes to close a stream before 154 reaching the End Chunk, it should publish empty Content Objects to 155 fill out to the maximum EndChunkNumber ever published. These padding 156 chunks MUST contain the true EndChunkNumber. 158 2.1. Cryptographic material 160 Chunk 0 SHOULD include the public key or key name link used to verify 161 the chunked data. It is RECOMMENDED to use the same key for the 162 whole set of chunked data. If a publisher uses multiple keys, then 163 the public key or key name link for all keys SHOULD be in the leading 164 chunks before any user data. 166 The rationel for putting all cryptographic data up front is because 167 the protocol requires using a fixed block size for all user data to 168 enable seeking in the chunked stream. 170 2.2. Examples 172 Here are some examples of chunked Names using the Labeled Content 173 Identifier URI scheme in human readable form (ccnx:). 175 In this example, the content producer publishes a JPG that takes 4 176 Chunks. The EndChunkNumber is missing in the first content object 177 (Chunk 0), but is known and included when Chunk 1 is published. It 178 is omitted in Chunk 2, then appears in Chunk 3, where it is 179 mandatory. 181 ccnx:/Name=parc/Name=picture.jpg/Chunk=0 -- 182 ccnx:/Name=parc/Name=picture.jpg/Chunk=1 EndChunkNumber=3 183 ccnx:/Name=parc/Name=picture.jpg/Chunk=2 -- 184 ccnx:/Name=parc/Name=picture.jpg/Chunk=3 EndChunkNumber=3 186 In this example, the publisher is writing an audio stream that ends 187 before expected so the publisher fills empty Content Objects out to 188 the maximum ChunkNumber, stating the correct EndChunkNumber. Chunks 189 4, 5, and 6 do not contain any new user data. 191 ccnx:/Name=parc/Name=talk.wav/Chunk=0 -- 192 ccnx:/Name=parc/Name=talk.wav/Chunk=1 EndChunkNumber=6 193 ccnx:/Name=parc/Name=talk.wav/Chunk=2 -- 194 ccnx:/Name=parc/Name=talk.wav/Chunk=3 EndChunkNumber=3 195 ccnx:/Name=parc/Name=talk.wav/Chunk=4 EndChunkNumber=3 196 ccnx:/Name=parc/Name=talk.wav/Chunk=5 EndChunkNumber=3 197 ccnx:/Name=parc/Name=talk.wav/Chunk=6 EndChunkNumber=3 199 3. TLV Types 201 This section specifies the TLV types used by CCNx chunking. 203 3.1. Name Types 205 CCNx chunking uses two new Name types: Chunk Number and Chunk 206 Metadata. 208 +--------+---------+-----------------+------------------------------+ 209 | Type | Abbrev | Name | Description | 210 +--------+---------+-----------------+------------------------------+ 211 | %x0010 | T_CHUNK | Chunk Number | The current Chunk Number, is | 212 | | | (Section 3.1.1) | an unsigned integer in | 213 | | | | network byte order without | 214 | | | | leading zeros. The value of | 215 | | | | zero is represented as the | 216 | | | | single byte %x00. | 217 +--------+---------+-----------------+------------------------------+ 219 Table 1: Name Types 221 3.1.1. Chunk Number 223 The current chunk number, as an unsigned integer in network byte 224 order without leading zeros. The value of zero is represented as the 225 single byte %x00. 227 In ccnx: URI form, it is denoted as "Chunk". 229 1 2 3 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 231 +---------------+---------------+---------------+--------------+ 232 | T_CHUNK | Length | 233 +---------------+---------------+---------------+--------------+ 234 | variable length integer / 235 +---------------+---------------+ 237 3.2. Protocol Information 239 CCNx chunking introduces one new TLV for use in a Content Object. 241 +--------+------------+-----------------+---------------------------+ 242 | Type | Abbrev | Name | Description | 243 +--------+------------+-----------------+---------------------------+ 244 | %x000C | T_ENDCHUNK | EndChunkNumber | The last Chunk number, as | 245 | | | (Section 3.1.1) | an unsigned integer in | 246 | | | | network byte order | 247 | | | | without leading zeros. | 248 | | | | The value of zero is | 249 | | | | represented as the single | 250 | | | | byte %x00. | 251 +--------+------------+-----------------+---------------------------+ 253 Table 2: Content Object Types 255 3.2.1. EndChunkNumber 257 The ending chunk number, as an unsigned integer in network byte order 258 without leading zeros. The value of zero is represented as the 259 single byte %x00. 261 1 2 3 262 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 263 +---------------+---------------+---------------+--------------+ 264 | T_ENDCHUNK | Length | 265 +---------------+---------------+---------------+--------------+ 266 | variable length integer / 267 +---------------+---------------+ 269 4. Acknowledgements 270 5. IANA Considerations 272 The draft adds new types to the CCNx Name Segment Types registry and 273 the CCNx Content Object Types registry. 275 6. Security Considerations 277 This draft does not put any requirements on how chunked data is 278 signed or validated. 280 7. References 282 7.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 286 RFC2119, March 1997, 287 . 289 7.2. Informative References 291 [CCNMessages] 292 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 293 Format (Internet draft)", 2016, . 296 [CCNSemantics] 297 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics 298 (Internet draft)", 2016, . 301 [CCNx] PARC, Inc., "CCNx Open Source", 2007, 302 . 304 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 305 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 306 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 307 RFC2616, June 1999, 308 . 310 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 311 Text on Security Considerations", BCP 72, RFC 3552, 312 DOI 10.17487/RFC3552, July 2003, 313 . 315 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 316 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 317 DOI 10.17487/RFC5226, May 2008, 318 . 320 Author's Address 322 Marc Mosko 323 PARC, Inc. 324 Palo Alto, California 94304 325 USA 327 Phone: +01 650-812-4405 328 Email: marc.mosko@parc.com