Internet Engineering Task Force M. Gallo Internet-Draft Alcatel-Lucent Bell Labs / IRT SystemX Intended status: Experimental D. Perino Expires: July 30, 2015 Alcatel-Lucent Bell Labs L. Muscariello Orange / IRT SystemX January 26, 2015 Content-Centric Networking Packet Header Format draft-ccn-packet-header-00 Abstract This document describes an experimental header format for CCN packets. The header is composed of a set fixed size fields followed by a set of Type-Length-Value fields in order to define a flexible, compact and easy to parse packet format for the CCN protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 30, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Gallo, et al. Expires July 30, 2015 [Page 1] Internet-Draft CCN Packet Header Format January 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Content Centric Networking packets . . . . . . . . . . . . . 4 2.1. Interest Packets . . . . . . . . . . . . . . . . . . . . 6 2.2. Data Packets . . . . . . . . . . . . . . . . . . . . . . 6 3. Type-Length-Value formats . . . . . . . . . . . . . . . . . . 7 4. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Name encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Name Components Offsets TLV format . . . . . . . . . . . 10 5.2. Name Segment ID Offset TLV format . . . . . . . . . . . . 11 6. Interest TLVs . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Interest Lifetime TLV format . . . . . . . . . . . . . . 13 7. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Data Lifetime TLV format . . . . . . . . . . . . . . . . 14 7.2. Data Signature TLV format . . . . . . . . . . . . . . . . 14 7.3. Data Signature's Key TLV format . . . . . . . . . . . . . 14 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Content-Centric Networking (CCN), initially proposed by PARC [CCN], is one of the architectures that were designed in the broad context of Information-Centric Networking (ICN). CCN, as more generally any ICN proposal, is centered around named content objects in contrast with today's host-centric nature of the TCP/IP architecture. Hence CCN packets carry a name that univocally represents a content object (or a segment of it) available in the network. In CCN, a content object is represented by a unique hierarchical name. An entire content object, for example a file or a video, is composed of a set of segments, that are identified in the content object's name using a segment identifier (See Section 5.2). Any client that needs to retrieve a content object or a specific content object's segment expresses a request (also referred to as Interest) specifying the name of the desired segment (also referred to as Data). Notice that a request an a content object or prefix name may be used by the CCN protocol for discovery mechanisms, not Gallo, et al. Expires July 30, 2015 [Page 2] Internet-Draft CCN Packet Header Format January 2015 discussed in this memo. The request is forwarded by CCN nodes or routers towards the potential source(s) that can serve it. CCN nodes can be equipped with content stores (local caches) from which they can serve the request. Hence, before propagating (forwarding) an Interest packet, a CCN node checks if it has the content segment requested by the Interest packet, in its local content store. If yes, it sends back a Data packet containing the desired content segment, and refrain from forwarding the Interest packet. If it does not have the content segment, it forwards the Interest packet based on its name-based Forwarding table. In order to populate the name-based forwarding tables, the CCN control plane distributes name prefixes (formed by any subset of components from the content names) to CCN routers in order to allow name based request routing towards potential data sources. In addition to the name-based forwarding tables, intermediate CCN nodes also keep track of pending requests: forwarded requests that are still waiting for an answer. This allows them to send back the required Data when they receive it from upstream nodes. Besides, requests with exactly the same name may be aggregated and not forwarded upstream. One of the most popular implementation for such networks is the CCNx prototype [CCNx]. CCNx has been initially proposed with a binary XML encoding which limits the possibility of implementing CCN over high speed equipments. This draft proposes a compact and flexible CCN packet header format in order to reduce the parsing delay needed by the XML encoding. Note that the packet header format that we define only specifies the fields that must be parsed by every CCN node (Core, Edge routers or end user machine). As mentioned above, there are two main types of CCN packets, Interest packets that carry requests for content objects, and Data packets that carry the objects themselves. We next give an overview of these two types of packets Gallo, et al. Expires July 30, 2015 [Page 3] Internet-Draft CCN Packet Header Format January 2015 2. Content Centric Networking packets Our CCN packet format includes: a fixed-size header (whose size depends on the packet type), a variable length content object's name, the optional name's TLVs (Section 5.1 , Section 5.2), some optional TLVs and finally the payload in some cases. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Fixed size header / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg type | Msg Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Variable Length Name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional Name TLVs / / ( Name Components Offsets TLV Name Segment ID Offset TLV) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional TLVs / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Payload / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The only difference between Interest and Data packets is in the TLVs that are inserted just after the fixed size header. +------------+------------+-----------------------------------------+ | Packet | Packet | Packet Description | | Type code | Type | | +------------+------------+-----------------------------------------+ | 0x00 | Interest | Interest packet, used to express a | | | packet. | request on a specific Content Object. | | | | | | 0x01 | Data | Data packet, used to satisfy a request | | | packet. | expressed by an Interest. | +------------+------------+-----------------------------------------+ Table 1: pkt types The versioning field is one type and used to combine different protocol versions. The pkt type and the pkt length fields are Gallo, et al. Expires July 30, 2015 [Page 4] Internet-Draft CCN Packet Header Format January 2015 respectively 1 and 2 Bytes each. The motivation behind this choice is twofold: 0 In principle, the number of packet types needed in the CCN protocol should be small; 0 With a pkt length expressed with 2 Bytes, the maximum Length of a CCN packet is limited to 65 KBytes (including the packet header). With a maximum packet size of 65 KBytes, CCN packets may not meet the Maximum Transmission Unit (MTU) of the underlying communication protocol (e.g. Ethernet MTU is 1500 Bytes). In this case, CCN packets must be fragmented and reassembled on a hop-by-hop basis, avoiding to break the one Interest / one Data correspondence of the CCN protocol. Fragmentation and reassembly are out of the scope of this draft, and can be addressed at a common convergence layer. The convergence layer may also be used in order to transfer topological information as Hop Counter, etc. However, such convergence layer is not described in this document. After the pkt type and length fields that define the packet type (Interest or Data) and its length, there is one byte Hop Limit used to limit the scope of the packet. After the hop limit, there is a Reserved/Flags field. This field is not defined yet but can be used to host some useful flags and possibly to extend the fixed size header (i.e. a field that must be inserted in the fixed size header may be optional and its presence can be indicated by a special flag). The Header Length field is similar to the Pkt Length one but it indicates the length of the Hop-by-Hop header. Additional fields may be introduced in the Hop-by-Hop header, especially for Hop-by-Hop packet frgamentation and reassebly. Such fields are not yet defined but could be introduced in a Type Lenth Value format. After fixed size header, there are the Msg type and Msg Length fields of 2 Bytes each. Their meaning is similar to the Pkt Type and Pkt Length. The reason why Msg. type and Msg. Length are inserted after the fixed size header is that, in case of fragmentation and reassembly, once the fixed headers are removed, the reconstructed CCN message must be self describing. Gallo, et al. Expires July 30, 2015 [Page 5] Internet-Draft CCN Packet Header Format January 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Pkt Type | Pkt Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Flags/Reserved| Hdr Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1. Interest Packets Interest packets are composed of the common fixed-size header plus the Msg. Type and Msg. length, repeated in ordrer to identify the message once reconstructed in case of Hop-by-Hop fragmentation and reassembly. Note that with the defined Interest fixed-size header, the Name will always start at the 13th Byte of the Interest packet header. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | 0x00 | Pkt Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Flags/Reserved| Hdr Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg type | Msg Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Variable Length Name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional Name TLVs / / ( Name Components Offsets TLV Name Segment ID Offset TLV) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional Interest TLVs / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2. Data Packets The Data packet header is very similar to the interest one. Gallo, et al. Expires July 30, 2015 [Page 6] Internet-Draft CCN Packet Header Format January 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | 0x01 | Pkt Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Flags/Reserved| Hdr Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg type | Msg Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Variable Length Name / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional Name TLVs / / ( Name Components Offsets TLV Name Segment ID Offset TLV) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional Data TLVs / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Payload / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. Type-Length-Value formats In order to encode variable length fields in CCN packets, we choose a single TLV encoding for simplicity composed by 2Bytes Type and 2Bytes Length. Despite this experimental choice, additional TLV types (i.e., 1B+2B, 1B+1B) may be needed and defined in the future using the most significant bits of the Type field. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field represents the size of the field Value expressed in Bytes, excluding the preceding Type and Length fields. With the above described TLV format up to 16K+ different fields can be defined with a maximum length of 65 KBytes each. Gallo, et al. Expires July 30, 2015 [Page 7] Internet-Draft CCN Packet Header Format January 2015 4. TLV Types In the following a list of all the supported TLV types in the current packet format. +-------+---------------+-------------------------------------------+ | First | Field Name | Field Description | | Byte | | | +-------+---------------+-------------------------------------------+ | 0x00 | Compact Name | Offsets (expressed using 1 Byte) of the | | | Components' | components in the Name field. | | | Offset | | | | | | | 0x01 | Extended Name | Offsets (expressed using 2 Bytes) of the | | | Components' | components in the Name field. | | | Offset | | | | | | | 0x02 | Name Segment | Offset of the segment ID in the Name | | | ID's Offset | field. | | | | | | 0x04 | Interest | Validity time for an Interest expressed | | | Lifetime | in milliseconds. | | | | | | 0x05 | Data Lifetime | Validity time for a Data Payload | | | | expressed in seconds. | | | | | | 0x06 | Signature | Author's Signature for the Data payload | | | | | | 0x07 | Key | The Content Object(s) that should be | | | | requested in order to retrieve the key | | | | used to sign the Data packet. | +-------+---------------+-------------------------------------------+ Table 2: TLV Types Gallo, et al. Expires July 30, 2015 [Page 8] Internet-Draft CCN Packet Header Format January 2015 5. Name encoding In CCN, Names are assumed to be a hierarchical list of components separated by a mandatory predefined separator (i.e. "/" as default) similarly to URIs [RFC3986]. Hierarchical Content Object's names allow the network to group names with a common prefix in a single entry needed for name based request forwarding, hence significantly reducing the Name-Based forwarding tables' size. Obviously, Inside a CCN packet header the Content Object's name is mandatory and must be accessible in a fast way by routers that simply need to read the name and forward the packet according to it. For that reason, the name is always put in a fixed location inside the packet header. Thanks to its fixed location (See Section 2.1 for Interest and Section 2.2 for Data ) CCN names does not need to be encoded with a dedicated TLV. Right after the packet type parsing (Interest or Data), the CCN router exactly knows where the name is located. The Name information in the CCN packet header is represented by two mandatory and two optional fields: 0 A mandatory Length field of 2 Bytes that defines the size of the name expressed in Bytes; 0 A mandatory Field of variable size representing the CCN hierarchical name; 0 An optional Name Components Offsets TLV (Section 5.1) that immediately follows the Name field. The Name Components Offsets TLV can be omitted in case of names composed by a single component; 0 An optional Name Segment Offset TLV (Section 5.2) that immediately follows the Name Components Offsets TLV. The Name Segment Offset TLV can be omitted in case of names without Segment identifier. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name Length | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / Variable Length Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Optional Name TLVs / / ( Name Components Offsets TLV Name Segment ID Offset TLV) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gallo, et al. Expires July 30, 2015 [Page 9] Internet-Draft CCN Packet Header Format January 2015 Notice that the name can be logically divided in two parts: (1) the name identifying the complete content object (a collection of segments like a file or a video) ; it is delimited by the last component offset and (2) the segment identifier that together with the content object name uniquely identify a content object's segment in the network. Application specific components or names are not part of the CCN protocol layer and can be added as separate optional TLVs. 5.1. Name Components Offsets TLV format The Name Components Offset TLV specifies the offsets that have to be applied to the Name field in order to retrieve the name's components. There are two different types of the Name Components Offsets TLV, one compact and one extended that are identified as two separate Type codes but that have the same meaning; only one type between the two can be specified per packet. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ / Variable Length Name Component Offsets / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Value field of this TLV has a fixed structure. In its compact version, (Type 0x00 and 0x40) it consists of a list of 1 Bytes fields that specify the offsets in the Name field of the different components. The first offset value indicates the name length up to the first component (component separator excluded), the second one the Name length up to the second component and so on for the other offsets. The last component delimits the content object/prefix identifier: this value corresponds to the end of the name if the packet does not have a Name Segment ID Offset TLV, or to the Name Segment Offset TLV value if present. In the extended name components offset TLV version (Type code 0x01 or 0x41), the name component's offset are represented using a list of 2 Bytes fields (instead of 1 Bytes fields). 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Compact Offset | +-+-+-+-+-+-+-+-+ Gallo, et al. Expires July 30, 2015 [Page 10] Internet-Draft CCN Packet Header Format January 2015 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ According to the Type of Name Components Offsets TLV (compact or extended), the number of name components can be immediately obtained by dividing by one (compact) or two (extended) the Name Components Offsets TLV's Length field. The Name Components Offsets TLV can be omitted if the name has a single component but, if present, it has to be put immediately after the Name. If the offset TLV is not present, the parser assumes a name composed by a single component and without any segment identifier. 5.2. Name Segment ID Offset TLV format The Name Segment ID Offset TLV, is used to specify the Segment ID offset. Contrarily to the Name components that indicates the end of a component field, the Name Segment ID Offset TLV indicates the starting point of the Segment ID inside the Name field. The Value field is composed by one offset represented using the offset extended version (2 Bytes). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x02 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment ID Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Segment ID is a special name component and is assumed to be the last, and its value corresponds to the last component offset. The segment ID has a separate offset with respect to other components for essentially 2 reasons: 0 It can be used to explicitly differentiate the content object's name from the segment one (content object name plus Segment ID); 0 It can be used by some specific caching techniques (i.e. redundancy elimination) that are not described in this memo. Moreover, the Name Segment Offset TLV only exists when the name has more than one component and the Name Components Offsets TLV is present in the packet header. The Name Segment Offset TLV if Gallo, et al. Expires July 30, 2015 [Page 11] Internet-Draft CCN Packet Header Format January 2015 present, must appear immediately after the Name Components Offsets TLV. Gallo, et al. Expires July 30, 2015 [Page 12] Internet-Draft CCN Packet Header Format January 2015 6. Interest TLVs Interest packets may have additional TLVs that, if present must be parsed by any CCN Node as they may affect the name based request forwarding operation. Those fields are introduced as optional TLVs. 6.1. Interest Lifetime TLV format Interest Lifetime is the time expressed in milliseconds for which the Interest remains valid. This means that CCN Nodes must maintain the state needed to re-route back the Data packets on the downstream at least for this amount of time. Each CCN Node can have a default Lifetime and ignore the one indicated in the Interest packet if it is not compliant with its own policy 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x04 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ / Interest Lifetime / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gallo, et al. Expires July 30, 2015 [Page 13] Internet-Draft CCN Packet Header Format January 2015 7. Data TLVs Data packets may have additional TLVs that, if present must be parsed by any CCN Node as they may affect the packet processing operation. Those fields are introduced as optional TLVs. 7.1. Data Lifetime TLV format The Data Lifetime TLV is very similar to the Interest Lifetime TLV (See Section 6.1 ). It indicates the validity of a Content Objects expressed in seconds. After that time, the Data must be considered as not valid and discarded (or ignored) if stored in the local cache. As for the Interest lifetime, the Data lifetime can be ignored and set to a default value if it is not compliant with the router policy. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x05 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ / Data Lifetime / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.2. Data Signature TLV format The Signature TLV is the field used by the Content Object's publisher to digitally sign the Data he/she published. Any node in the network can verify the Content Object's authenticity by using the public Key of the Publisher that must be provided in a separate TLV. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x06 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ / Signature / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.3. Data Signature's Key TLV format The Key TLV is basically the name under which the Publisher's Public key is available. Its value is used to retrieve the Public Key (and related information) of the authority to verify the signature. This TLV must be present if the Signature TLV is used in a Data packet. Gallo, et al. Expires July 30, 2015 [Page 14] Internet-Draft CCN Packet Header Format January 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x07 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+/ / Signature's Key / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8. Acknowledgment 9. Security Considerations This memo raises no security issues; however, according to [RFC2223], your document should contain a section near the end that discusses the security considerations of the protocol or procedures that are the main topic of your document. 10. References [CCN] Jacobson, V., Smetters, D., Thorton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", In proc. of IEEE CoNEXT, 2009. [CCNx] Palo Alto Research Center (PARC), "CCNx Project", 2007, . [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. Authors' Addresses Massimo Gallo Alcatel-Lucent Bell Labs / IRT SystemX EMail: massimo.gallo@alcatel-lucent.com, massimo.gallo@irt-systemx.fr Diego Perino Alcatel-Lucent Bell Labs EMail: diego.perino@alcatel-lucent.com Gallo, et al. Expires July 30, 2015 [Page 15] Internet-Draft CCN Packet Header Format January 2015 Luca Muscariello Orange / IRT SystemX EMail: luca.muscariello@orange.com, luca.muscariello@irt-systemx.fr Gallo, et al. Expires July 30, 2015 [Page 16]