idnits 2.17.1 draft-ccn-packet-header-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2015) is 3377 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2223 (Obsoleted by RFC 7322) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Gallo 3 Internet-Draft Alcatel-Lucent Bell Labs / IRT SystemX 4 Intended status: Experimental D. Perino 5 Expires: July 30, 2015 Alcatel-Lucent Bell Labs 6 L. Muscariello 7 Orange / IRT SystemX 8 January 26, 2015 10 Content-Centric Networking Packet Header Format 11 draft-ccn-packet-header-00 13 Abstract 15 This document describes an experimental header format for CCN 16 packets. The header is composed of a set fixed size fields followed 17 by a set of Type-Length-Value fields in order to define a flexible, 18 compact and easy to parse packet format for the CCN protocol. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 30, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may not be modified, and derivative works of it may not 53 be created, except to format it for publication as an RFC or to 54 translate it into languages other than English. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Content Centric Networking packets . . . . . . . . . . . . . 4 60 2.1. Interest Packets . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Data Packets . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Type-Length-Value formats . . . . . . . . . . . . . . . . . . 7 63 4. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. Name encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Name Components Offsets TLV format . . . . . . . . . . . 10 66 5.2. Name Segment ID Offset TLV format . . . . . . . . . . . . 11 67 6. Interest TLVs . . . . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. Interest Lifetime TLV format . . . . . . . . . . . . . . 13 69 7. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 7.1. Data Lifetime TLV format . . . . . . . . . . . . . . . . 14 71 7.2. Data Signature TLV format . . . . . . . . . . . . . . . . 14 72 7.3. Data Signature's Key TLV format . . . . . . . . . . . . . 14 73 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 Content-Centric Networking (CCN), initially proposed by PARC [CCN], 80 is one of the architectures that were designed in the broad context 81 of Information-Centric Networking (ICN). CCN, as more generally any 82 ICN proposal, is centered around named content objects in contrast 83 with today's host-centric nature of the TCP/IP architecture. Hence 84 CCN packets carry a name that univocally represents a content object 85 (or a segment of it) available in the network. 87 In CCN, a content object is represented by a unique hierarchical 88 name. An entire content object, for example a file or a video, is 89 composed of a set of segments, that are identified in the content 90 object's name using a segment identifier (See Section 5.2). 92 Any client that needs to retrieve a content object or a specific 93 content object's segment expresses a request (also referred to as 94 Interest) specifying the name of the desired segment (also referred 95 to as Data). Notice that a request an a content object or prefix 96 name may be used by the CCN protocol for discovery mechanisms, not 97 discussed in this memo. The request is forwarded by CCN nodes or 98 routers towards the potential source(s) that can serve it. CCN nodes 99 can be equipped with content stores (local caches) from which they 100 can serve the request. Hence, before propagating (forwarding) an 101 Interest packet, a CCN node checks if it has the content segment 102 requested by the Interest packet, in its local content store. If 103 yes, it sends back a Data packet containing the desired content 104 segment, and refrain from forwarding the Interest packet. If it does 105 not have the content segment, it forwards the Interest packet based 106 on its name-based Forwarding table. 108 In order to populate the name-based forwarding tables, the CCN 109 control plane distributes name prefixes (formed by any subset of 110 components from the content names) to CCN routers in order to allow 111 name based request routing towards potential data sources. In 112 addition to the name-based forwarding tables, intermediate CCN nodes 113 also keep track of pending requests: forwarded requests that are 114 still waiting for an answer. This allows them to send back the 115 required Data when they receive it from upstream nodes. Besides, 116 requests with exactly the same name may be aggregated and not 117 forwarded upstream. 119 One of the most popular implementation for such networks is the CCNx 120 prototype [CCNx]. CCNx has been initially proposed with a binary XML 121 encoding which limits the possibility of implementing CCN over high 122 speed equipments. This draft proposes a compact and flexible CCN 123 packet header format in order to reduce the parsing delay needed by 124 the XML encoding. Note that the packet header format that we define 125 only specifies the fields that must be parsed by every CCN node 126 (Core, Edge routers or end user machine). 128 As mentioned above, there are two main types of CCN packets, Interest 129 packets that carry requests for content objects, and Data packets 130 that carry the objects themselves. We next give an overview of these 131 two types of packets 133 2. Content Centric Networking packets 135 Our CCN packet format includes: a fixed-size header (whose size 136 depends on the packet type), a variable length content object's name, 137 the optional name's TLVs (Section 5.1 , Section 5.2), some optional 138 TLVs and finally the payload in some cases. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 / / 144 / Fixed size header / 145 / / 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Msg type | Msg Length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 / Variable Length Name / 150 / / 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 / Optional Name TLVs / 153 / ( Name Components Offsets TLV Name Segment ID Offset TLV) / 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 / Optional TLVs / 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 / / 158 / Payload / 159 / / 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 The only difference between Interest and Data packets is in the TLVs 163 that are inserted just after the fixed size header. 165 +------------+------------+-----------------------------------------+ 166 | Packet | Packet | Packet Description | 167 | Type code | Type | | 168 +------------+------------+-----------------------------------------+ 169 | 0x00 | Interest | Interest packet, used to express a | 170 | | packet. | request on a specific Content Object. | 171 | | | | 172 | 0x01 | Data | Data packet, used to satisfy a request | 173 | | packet. | expressed by an Interest. | 174 +------------+------------+-----------------------------------------+ 176 Table 1: pkt types 178 The versioning field is one type and used to combine different 179 protocol versions. The pkt type and the pkt length fields are 180 respectively 1 and 2 Bytes each. The motivation behind this choice 181 is twofold: 183 0 In principle, the number of packet types needed in the CCN 184 protocol should be small; 186 0 With a pkt length expressed with 2 Bytes, the maximum Length of 187 a CCN packet is limited to 65 KBytes (including the packet 188 header). 190 With a maximum packet size of 65 KBytes, CCN packets may not meet the 191 Maximum Transmission Unit (MTU) of the underlying communication 192 protocol (e.g. Ethernet MTU is 1500 Bytes). In this case, CCN 193 packets must be fragmented and reassembled on a hop-by-hop basis, 194 avoiding to break the one Interest / one Data correspondence of the 195 CCN protocol. Fragmentation and reassembly are out of the scope of 196 this draft, and can be addressed at a common convergence layer. The 197 convergence layer may also be used in order to transfer topological 198 information as Hop Counter, etc. However, such convergence layer is 199 not described in this document. 201 After the pkt type and length fields that define the packet type 202 (Interest or Data) and its length, there is one byte Hop Limit used 203 to limit the scope of the packet. After the hop limit, there is a 204 Reserved/Flags field. This field is not defined yet but can be used 205 to host some useful flags and possibly to extend the fixed size 206 header (i.e. a field that must be inserted in the fixed size header 207 may be optional and its presence can be indicated by a special flag). 209 The Header Length field is similar to the Pkt Length one but it 210 indicates the length of the Hop-by-Hop header. Additional fields may 211 be introduced in the Hop-by-Hop header, especially for Hop-by-Hop 212 packet frgamentation and reassebly. Such fields are not yet defined 213 but could be introduced in a Type Lenth Value format. 215 After fixed size header, there are the Msg type and Msg Length fields 216 of 2 Bytes each. Their meaning is similar to the Pkt Type and Pkt 217 Length. The reason why Msg. type and Msg. Length are inserted after 218 the fixed size header is that, in case of fragmentation and 219 reassembly, once the fixed headers are removed, the reconstructed CCN 220 message must be self describing. 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Version | Pkt Type | Pkt Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Hop Limit | Flags/Reserved| Hdr Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 2.1. Interest Packets 232 Interest packets are composed of the common fixed-size header plus 233 the Msg. Type and Msg. length, repeated in ordrer to identify the 234 message once reconstructed in case of Hop-by-Hop fragmentation and 235 reassembly. 237 Note that with the defined Interest fixed-size header, the Name will 238 always start at the 13th Byte of the Interest packet header. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Version | 0x00 | Pkt Length | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Hop Limit | Flags/Reserved| Hdr Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Msg type | Msg Length | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 / Variable Length Name / 250 / / 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 / Optional Name TLVs / 253 / ( Name Components Offsets TLV Name Segment ID Offset TLV) / 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 / Optional Interest TLVs / 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 2.2. Data Packets 260 The Data packet header is very similar to the interest one. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Version | 0x01 | Pkt Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Hop Limit | Flags/Reserved| Hdr Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Msg type | Msg Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 / Variable Length Name / 272 / / 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 / Optional Name TLVs / 275 / ( Name Components Offsets TLV Name Segment ID Offset TLV) / 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 / Optional Data TLVs / 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 / / 280 / Payload / 281 / / 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 3. Type-Length-Value formats 286 In order to encode variable length fields in CCN packets, we choose a 287 single TLV encoding for simplicity composed by 2Bytes Type and 2Bytes 288 Length. Despite this experimental choice, additional TLV types 289 (i.e., 1B+2B, 1B+1B) may be needed and defined in the future using 290 the most significant bits of the Type field. 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 The Length field represents the size of the field Value expressed in 299 Bytes, excluding the preceding Type and Length fields. 301 With the above described TLV format up to 16K+ different fields can 302 be defined with a maximum length of 65 KBytes each. 304 4. TLV Types 306 In the following a list of all the supported TLV types in the current 307 packet format. 309 +-------+---------------+-------------------------------------------+ 310 | First | Field Name | Field Description | 311 | Byte | | | 312 +-------+---------------+-------------------------------------------+ 313 | 0x00 | Compact Name | Offsets (expressed using 1 Byte) of the | 314 | | Components' | components in the Name field. | 315 | | Offset | | 316 | | | | 317 | 0x01 | Extended Name | Offsets (expressed using 2 Bytes) of the | 318 | | Components' | components in the Name field. | 319 | | Offset | | 320 | | | | 321 | 0x02 | Name Segment | Offset of the segment ID in the Name | 322 | | ID's Offset | field. | 323 | | | | 324 | 0x04 | Interest | Validity time for an Interest expressed | 325 | | Lifetime | in milliseconds. | 326 | | | | 327 | 0x05 | Data Lifetime | Validity time for a Data Payload | 328 | | | expressed in seconds. | 329 | | | | 330 | 0x06 | Signature | Author's Signature for the Data payload | 331 | | | | 332 | 0x07 | Key | The Content Object(s) that should be | 333 | | | requested in order to retrieve the key | 334 | | | used to sign the Data packet. | 335 +-------+---------------+-------------------------------------------+ 337 Table 2: TLV Types 339 5. Name encoding 341 In CCN, Names are assumed to be a hierarchical list of components 342 separated by a mandatory predefined separator (i.e. "/" as default) 343 similarly to URIs [RFC3986]. Hierarchical Content Object's names 344 allow the network to group names with a common prefix in a single 345 entry needed for name based request forwarding, hence significantly 346 reducing the Name-Based forwarding tables' size. 348 Obviously, Inside a CCN packet header the Content Object's name is 349 mandatory and must be accessible in a fast way by routers that simply 350 need to read the name and forward the packet according to it. For 351 that reason, the name is always put in a fixed location inside the 352 packet header. Thanks to its fixed location (See Section 2.1 for 353 Interest and Section 2.2 for Data ) CCN names does not need to be 354 encoded with a dedicated TLV. Right after the packet type parsing 355 (Interest or Data), the CCN router exactly knows where the name is 356 located. 358 The Name information in the CCN packet header is represented by two 359 mandatory and two optional fields: 361 0 A mandatory Length field of 2 Bytes that defines the size of 362 the name expressed in Bytes; 364 0 A mandatory Field of variable size representing the CCN 365 hierarchical name; 367 0 An optional Name Components Offsets TLV (Section 5.1) that 368 immediately follows the Name field. The Name Components Offsets 369 TLV can be omitted in case of names composed by a single 370 component; 372 0 An optional Name Segment Offset TLV (Section 5.2) that 373 immediately follows the Name Components Offsets TLV. The Name 374 Segment Offset TLV can be omitted in case of names without 375 Segment identifier. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Name Length | / 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 382 / Variable Length Name / 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 / Optional Name TLVs / 385 / ( Name Components Offsets TLV Name Segment ID Offset TLV) / 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Notice that the name can be logically divided in two parts: (1) the 388 name identifying the complete content object (a collection of 389 segments like a file or a video) ; it is delimited by the last 390 component offset and (2) the segment identifier that together with 391 the content object name uniquely identify a content object's segment 392 in the network. Application specific components or names are not 393 part of the CCN protocol layer and can be added as separate optional 394 TLVs. 396 5.1. Name Components Offsets TLV format 398 The Name Components Offset TLV specifies the offsets that have to be 399 applied to the Name field in order to retrieve the name's components. 400 There are two different types of the Name Components Offsets TLV, one 401 compact and one extended that are identified as two separate Type 402 codes but that have the same meaning; only one type between the two 403 can be specified per packet. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | 0x01 | Length | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ 410 / Variable Length Name Component Offsets / 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 The Value field of this TLV has a fixed structure. In its compact 414 version, (Type 0x00 and 0x40) it consists of a list of 1 Bytes fields 415 that specify the offsets in the Name field of the different 416 components. The first offset value indicates the name length up to 417 the first component (component separator excluded), the second one 418 the Name length up to the second component and so on for the other 419 offsets. The last component delimits the content object/prefix 420 identifier: this value corresponds to the end of the name if the 421 packet does not have a Name Segment ID Offset TLV, or to the Name 422 Segment Offset TLV value if present. In the extended name components 423 offset TLV version (Type code 0x01 or 0x41), the name component's 424 offset are represented using a list of 2 Bytes fields (instead of 1 425 Bytes fields). 427 0 428 0 1 2 3 4 5 6 7 429 +-+-+-+-+-+-+-+-+ 430 |Compact Offset | 431 +-+-+-+-+-+-+-+-+ 432 0 1 433 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Extended Offset | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 According to the Type of Name Components Offsets TLV (compact or 439 extended), the number of name components can be immediately obtained 440 by dividing by one (compact) or two (extended) the Name Components 441 Offsets TLV's Length field. 443 The Name Components Offsets TLV can be omitted if the name has a 444 single component but, if present, it has to be put immediately after 445 the Name. If the offset TLV is not present, the parser assumes a 446 name composed by a single component and without any segment 447 identifier. 449 5.2. Name Segment ID Offset TLV format 451 The Name Segment ID Offset TLV, is used to specify the Segment ID 452 offset. Contrarily to the Name components that indicates the end of 453 a component field, the Name Segment ID Offset TLV indicates the 454 starting point of the Segment ID inside the Name field. The Value 455 field is composed by one offset represented using the offset extended 456 version (2 Bytes). 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | 0x02 | Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Segment ID Offset | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 The Segment ID is a special name component and is assumed to be the 467 last, and its value corresponds to the last component offset. The 468 segment ID has a separate offset with respect to other components for 469 essentially 2 reasons: 471 0 It can be used to explicitly differentiate the content object's 472 name from the segment one (content object name plus Segment ID); 474 0 It can be used by some specific caching techniques (i.e. 475 redundancy elimination) that are not described in this memo. 477 Moreover, the Name Segment Offset TLV only exists when the name has 478 more than one component and the Name Components Offsets TLV is 479 present in the packet header. The Name Segment Offset TLV if 480 present, must appear immediately after the Name Components Offsets 481 TLV. 483 6. Interest TLVs 485 Interest packets may have additional TLVs that, if present must be 486 parsed by any CCN Node as they may affect the name based request 487 forwarding operation. Those fields are introduced as optional TLVs. 489 6.1. Interest Lifetime TLV format 491 Interest Lifetime is the time expressed in milliseconds for which the 492 Interest remains valid. This means that CCN Nodes must maintain the 493 state needed to re-route back the Data packets on the downstream at 494 least for this amount of time. Each CCN Node can have a default 495 Lifetime and ignore the one indicated in the Interest packet if it is 496 not compliant with its own policy 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | 0x04 | Length | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ 503 / Interest Lifetime / 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 7. Data TLVs 508 Data packets may have additional TLVs that, if present must be parsed 509 by any CCN Node as they may affect the packet processing operation. 510 Those fields are introduced as optional TLVs. 512 7.1. Data Lifetime TLV format 514 The Data Lifetime TLV is very similar to the Interest Lifetime TLV 515 (See Section 6.1 ). It indicates the validity of a Content Objects 516 expressed in seconds. After that time, the Data must be considered 517 as not valid and discarded (or ignored) if stored in the local cache. 519 As for the Interest lifetime, the Data lifetime can be ignored and 520 set to a default value if it is not compliant with the router policy. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | 0x05 | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ 527 / Data Lifetime / 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 7.2. Data Signature TLV format 532 The Signature TLV is the field used by the Content Object's publisher 533 to digitally sign the Data he/she published. Any node in the network 534 can verify the Content Object's authenticity by using the public Key 535 of the Publisher that must be provided in a separate TLV. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | 0x06 | Length | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ 542 / Signature / 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 7.3. Data Signature's Key TLV format 547 The Key TLV is basically the name under which the Publisher's Public 548 key is available. Its value is used to retrieve the Public Key (and 549 related information) of the authority to verify the signature. This 550 TLV must be present if the Signature TLV is used in a Data packet. 552 0 1 2 3 553 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 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | 0x07 | Length | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ 557 / Signature's Key / 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 8. Acknowledgment 562 9. Security Considerations 564 This memo raises no security issues; however, according to [RFC2223], 565 your document should contain a section near the end that discusses 566 the security considerations of the protocol or procedures that are 567 the main topic of your document. 569 10. References 571 [CCN] Jacobson, V., Smetters, D., Thorton, J., Plass, M., 572 Briggs, N., and R. Braynard, "Networking Named Content", 573 In proc. of IEEE CoNEXT, 2009. 575 [CCNx] Palo Alto Research Center (PARC), "CCNx Project", 2007, 576 . 578 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 579 RFC 2223, October 1997. 581 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 582 Resource Identifier (URI): Generic Syntax", STD 66, RFC 583 3986, January 2005. 585 Authors' Addresses 587 Massimo Gallo 588 Alcatel-Lucent Bell Labs / IRT SystemX 590 EMail: massimo.gallo@alcatel-lucent.com, massimo.gallo@irt-systemx.fr 592 Diego Perino 593 Alcatel-Lucent Bell Labs 595 EMail: diego.perino@alcatel-lucent.com 596 Luca Muscariello 597 Orange / IRT SystemX 599 EMail: luca.muscariello@orange.com, luca.muscariello@irt-systemx.fr