Internet DRAFT - draft-ccn-packet-header
draft-ccn-packet-header
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,
<http://www.ccnx.org>.
[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]