Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8609

Content-Centric Networking (CCNx) Messages in TLV Format

Pages: 46
Experimental
Part 1 of 3 – Pages 1 to 16
None   None   Next

Top   ToC   RFC8609 - Page 1
Internet Research Task Force (IRTF)                             M. Mosko
Request for Comments: 8609                                    PARC, Inc.
Category: Experimental                                          I. Solis
ISSN: 2070-1721                                                 LinkedIn
                                                                 C. Wood
                                         University of California Irvine
                                                               July 2019


        Content-Centric Networking (CCNx) Messages in TLV Format

Abstract

Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification. This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review among ICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8609.
Top   ToC   RFC8609 - Page 2
Copyright Notice

   Copyright (c) 2019 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
   (https://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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Type-Length-Value (TLV) Packets . . . . . . . . . . . . . . . 5 3.1. Overall Packet Format . . . . . . . . . . . . . . . . . . 7 3.2. Fixed Headers . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Interest Fixed Header . . . . . . . . . . . . . . . . 9 3.2.1.1. Interest HopLimit . . . . . . . . . . . . . . . . 9 3.2.2. Content Object Fixed Header . . . . . . . . . . . . . 9 3.2.3. Interest Return Fixed Header . . . . . . . . . . . . 10 3.2.3.1. Interest Return HopLimit . . . . . . . . . . . . 10 3.2.3.2. Interest Return Flags . . . . . . . . . . . . . . 10 3.2.3.3. Return Code . . . . . . . . . . . . . . . . . . . 10 3.3. Global Formats . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Pad . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.2. Organization-Specific TLVs . . . . . . . . . . . . . 12 3.3.3. Hash Format . . . . . . . . . . . . . . . . . . . . . 12 3.3.4. Link . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Hop-by-Hop TLV Headers . . . . . . . . . . . . . . . . . 14 3.4.1. Interest Lifetime . . . . . . . . . . . . . . . . . . 14 3.4.2. Recommended Cache Time . . . . . . . . . . . . . . . 15 3.4.3. Message Hash . . . . . . . . . . . . . . . . . . . . 16 3.5. Top-Level Types . . . . . . . . . . . . . . . . . . . . . 17 3.6. CCNx Message TLV . . . . . . . . . . . . . . . . . . . . 18 3.6.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.1.1. Name Segments . . . . . . . . . . . . . . . . . . 20 3.6.1.2. Interest Payload ID . . . . . . . . . . . . . . . 20 3.6.2. Message TLVs . . . . . . . . . . . . . . . . . . . . 21 3.6.2.1. Interest Message TLVs . . . . . . . . . . . . . . 21 3.6.2.2. Content Object Message TLVs . . . . . . . . . . . 23 3.6.3. Payload . . . . . . . . . . . . . . . . . . . . . . . 25 3.6.4. Validation . . . . . . . . . . . . . . . . . . . . . 25 3.6.4.1. Validation Algorithm . . . . . . . . . . . . . . 25 3.6.4.2. Validation Payload . . . . . . . . . . . . . . . 32
Top   ToC   RFC8609 - Page 3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
     4.1.  Packet Type Registry  . . . . . . . . . . . . . . . . . .  33
     4.2.  Interest Return Code Registry . . . . . . . . . . . . . .  34
     4.3.  Hop-by-Hop Type Registry  . . . . . . . . . . . . . . . .  35
     4.4.  Top-Level Type Registry . . . . . . . . . . . . . . . . .  36
     4.5.  Name Segment Type Registry  . . . . . . . . . . . . . . .  37
     4.6.  Message Type Registry . . . . . . . . . . . . . . . . . .  37
     4.7.  Payload Type Registry . . . . . . . . . . . . . . . . . .  38
     4.8.  Validation Algorithm Type Registry  . . . . . . . . . . .  39
     4.9.  Validation-Dependent Data Type Registry . . . . . . . . .  40
     4.10. Hash Function Type Registry . . . . . . . . . . . . . . .  40
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  41
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  44
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  44
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  44
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

1. Introduction

This document specifies a Type-Length-Value (TLV) packet format and the TLV type and value encodings for CCNx messages. A full description of the CCNx network protocol, providing an encoding-free description of CCNx messages and message elements, may be found in [RFC8569]. CCNx is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. It does not use endpoint addresses; the Internet Protocol does. Restrictions in a request can limit the response by the public key of the response's signer or the cryptographic hash of the response. Every CCNx forwarder along the path does the name matching and restriction checking. The CCNx protocol fits within the broader framework of Information-Centric Networking (ICN) protocols [RFC7927]. This document describes a TLV scheme using a fixed 2-byte T and a fixed 2-byte L field. The rational for this choice is described in Section 5. Briefly, this choice avoids multiple encodings of the same value (aliases) and reduces the work of a validator to ensure compliance. Unlike some uses of TLV in networking, each network hop must evaluate the encoding, so even small validation latencies at each hop could add up to a large overall forwarding delay. For very small packets or low-throughput links, where the extra bytes may become a concern, one may use a TLV compression protocol, for example, [compress] and [CCNxz]. This document uses the terms CCNx Packet, CCNx Message, and CCNx Message TLV. A CCNx Packet refers to the entire Layer 3 datagram as specified in Section 3.1. A CCNx Message is the ABNF token defined in the CCNx Semantics document [RFC8569]. A CCNx Message TLV refers to the encoding of a CCNx Message as specified in Section 3.6.
Top   ToC   RFC8609 - Page 4
   This document specifies:

   o  the CCNx Packet format,

   o  the CCNx Message TLV format,

   o  the TLV types used by CCNx messages,

   o  the encoding of values for each type,

   o  top-level types that exist at the outermost containment,

   o  Interest TLVs that exist within Interest containment, and

   o  Content Object TLVs that exist within Content Object containment.

   This document is supplemented by these documents:

   o  [RFC8569], which covers message semantics and the protocol
      operation regarding Interest and Content Object, including the
      Interest Return protocol.

   o  [CCNxURI], which covers the CCNx URI notation.

   The type values in Section 4 conform to the IANA-assigned numbers for
   the CCNx protocol.  This document uses the symbolic names defined in
   that section.  All TLV type values are relative to their parent
   containers.  For example, each level of a nested TLV structure might
   define a "type = 1" with a completely different meaning.

   Packets are represented as 32-bit wide words using ASCII art.  Due to
   the nested levels of TLV encoding and the presence of optional fields
   and variable sizes, there is no concise way to represent all
   possibilities.  We use the convention that ASCII art fields enclosed
   by vertical bars "|" represent exact bit widths.  Fields with a
   forward slash "/" are variable bit widths, which we typically pad out
   to word alignment for picture readability.

   The document represents the consensus of the ICN RG.  It is the first
   ICN protocol from the RG, created from the early CCNx protocol [nnc]
   with significant revision and input from the ICN community and RG
   members.  The document has received critical reading by several
   members of the ICN community and the RG.  The authors and RG chairs
   approve of the contents.  The document is sponsored under the IRTF
   and is not issued by the IETF and is not an IETF standard.  This is
   an experimental protocol and may not be suitable for any specific
   application and the specification may change in the future.
Top   ToC   RFC8609 - Page 5

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Definitions

These definitions summarize items defined in [RFC8569]. This document defines their encodings. o Name: A hierarchically structured variable-length identifier. It is an ordered list of path segments, which are variable-length octet strings. In human-readable form, it is represented in URI format as "ccnx:/path/part". There is no host or query string. See [CCNxURI] for complete details. o Interest: A message requesting a Content Object with a matching Name and other optional selectors to choose from multiple objects with the same Name. Any Content Object with a Name and attributes that matches the Name and optional selectors of the Interest is said to satisfy the Interest. o Content Object: A data object sent in response to an Interest request. It has an optional Name and a content payload that are bound together via cryptographic means.

3. Type-Length-Value (TLV) Packets

We use 16-bit Type and 16-bit Length fields to encode TLV-based packets. This provides 65,536 different possible types and value field lengths of up to 64 KiB. With 65,536 possible types at each level of TLV encoding, there should be sufficient space for basic protocol types, while also allowing ample room for experimentation, application use, vendor extensions, and growth. This encoding does not allow for jumbo packets beyond 64 KiB total length. If used on a media that allows for jumbo frames, we suggest defining a media adaptation envelope that allows for multiple smaller frames.
Top   ToC   RFC8609 - Page 6
   +--------+------------------+---------------------------------------+
   | Abbrev |       Name       | Description                           |
   +--------+------------------+---------------------------------------+
   | T_ORG  | Vendor Specific  | Information specific to a vendor      |
   |        |   Information    | implementation (Section 3.3.2).       |
   |        |                  |                                       |
   | T_PAD  |     Padding      | Adds padding to a field (Section      |
   |        |                  | 3.3.1).                               |
   |        |                  |                                       |
   |  n/a   |   Experimental   | Experimental use.                     |
   +--------+------------------+---------------------------------------+

                        Table 1: Reserved TLV Types

   There are several global TLV definitions that we reserve at all
   hierarchical contexts.  The TLV types in the range 0x1000 - 0x1FFF
   are Reserved for Experimental Use.  The TLV type T_ORG is also
   Reserved for Vendor Extensions (see Section 3.3.2).  The TLV type
   T_PAD is used to optionally pad a field out to some desired
   alignment.

                        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             |
   +---------------+---------------+---------------+---------------+

                    Figure 1: Type and Length encoding

   The Length field contains the length of the Value field in octets.
   It does not include the length of the Type and Length fields.  The
   Length MAY be zero.

   TLV structures are nestable, allowing the Value field of one TLV
   structure to contain additional TLV structures.  The enclosing TLV
   structure is called the container of the enclosed TLV.

   Type values are context dependent.  Within a TLV container, one may
   reuse previous type values for new context-dependent purposes.
Top   ToC   RFC8609 - Page 7

3.1. Overall Packet Format

Each CCNx Packet includes the 8-byte fixed header, described below, followed by a set of TLV fields. These fields are optional hop-by- hop headers and the Packet Payload. 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 | PacketType | PacketLength | +---------------+---------------+---------------+---------------+ | PacketType-specific fields | HeaderLength | +---------------+---------------+---------------+---------------+ / Optional hop-by-hop header TLVs / +---------------+---------------+---------------+---------------+ / PacketPayload TLVs / +---------------+---------------+---------------+---------------+ Figure 2: Overall Packet Format The PacketPayload of a CCNx Packet is the protocol message itself. The Content Object Hash is computed over the PacketPayload only, excluding the fixed and hop-by-hop headers, as those might change from hop to hop. Signed information or similarity hashes should not include any of the fixed or hop-by-hop headers. The PacketPayload should be self-sufficient in the event that the fixed and hop-by-hop headers are removed. See Message Hash (Section 3.4.3). Following the CCNx Message TLV, the PacketPayload may include optional Validation TLVs. 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 +---------------+---------------+---------------+---------------+ | CCNx Message TLV / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationAlgorithm TLV / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationPayload TLV (ValidationAlg required) / +---------------+---------------+---------------+---------------+ Figure 3: PacketPayload TLVs After discarding the fixed and hop-by-hop headers, the remaining PacketPayload should be a valid protocol message. Therefore, the PacketPayload always begins with 4 bytes of type-length that specifies the protocol message (whether it is an Interest, Content Object, or other message type) and its total length. The embedding
Top   ToC   RFC8609 - Page 8
   of a self-sufficient protocol data unit inside the fixed and hop-by-
   hop headers allows a network stack to discard the headers and operate
   only on the embedded message.  It also decouples the PacketType field
   -- which specifies how to forward the packet -- from the
   PacketPayload.

   The range of bytes protected by the Validation includes the CCNx
   Message TLV and the ValidationAlgorithm TLV.

   The ContentObjectHash begins with the CCNx Message TLV and ends at
   the tail of the CCNx Packet.

3.2. Fixed Headers

In Figure 2, the fixed header fields are: o Version: defines the version of the packet, which MUST be 1. o HeaderLength: The length of the fixed header (8 bytes) and hop-by- hop headers. The minimum value MUST be 8. o PacketType: describes forwarder actions to take on the packet. o PacketLength: Total octets of packet including all headers (fixed header plus hop-by-hop headers) and protocol message. o PacketType-specific Fields: specific PacketTypes define the use of these bits. The PacketType field indicates how the forwarder should process the packet. A Request Packet (Interest) has PacketType PT_INTEREST, a Response (Content Object) has PacketType PT_CONTENT, and an Interest Return has PacketType PT_RETURN. HeaderLength is the number of octets from the start of the CCNx Packet (Version) to the end of the hop-by-hop headers. PacketLength is the number of octets from the start of the packet to the end of the packet. Both lengths have a minimum value of 8 (the fixed header itself). The PacketType-specific fields are reserved bits whose use depends on the PacketType. They are used for network-level signaling.
Top   ToC   RFC8609 - Page 9

3.2.1. Interest Fixed Header

If the PacketType is PT_INTEREST, it indicates that the packet should be forwarded following the Interest pipeline in Section 2.4.4 of [RFC8569]. For this type of packet, the Fixed Header includes a field for a HopLimit as well as Reserved and Flags fields. The Reserved field MUST be set to 0 in an Interest. There are currently no flags defined, so the Flags field MUST be set to 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 | PT_INTEREST | PacketLength | +---------------+---------------+---------------+---------------+ | HopLimit | Reserved | Flags | HeaderLength | +---------------+---------------+---------------+---------------+ Figure 4: Interest Header
3.2.1.1. Interest HopLimit
For an Interest message, the HopLimit is a counter that is decremented with each hop. It limits the distance an Interest may travel on the network. The node originating the Interest MAY put in any value up to the maximum of 255. Each node that receives an Interest with a HopLimit decrements the value upon reception. If the value is 0 after the decrement, the Interest MUST NOT be forwarded off the node. It is an error to receive an Interest from a remote node with the HopLimit field set to 0.

3.2.2. Content Object Fixed Header

If the PacketType is PT_CONTENT, it indicates that the packet should be forwarded following the Content Object pipeline in Section 2.4.4 of [RFC8569]. A Content Object defines a Flags field; however, there are currently no flags defined, so the Flags field must be set to 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 | PT_CONTENT | PacketLength | +---------------+---------------+---------------+---------------+ | Reserved | Flags | HeaderLength | +---------------+---------------+---------------+---------------+ Figure 5: Content Object Header
Top   ToC   RFC8609 - Page 10

3.2.3. Interest Return Fixed Header

If the PacketType is PT_RETURN, it indicates that the packet should be processed following the Interest Return rules in Section 10 of [RFC8569]. The only difference between this Interest Return message and the original Interest is that the PacketType is changed to PT_RETURN and a ReturnCode is put into the ReturnCode field. All other fields are unchanged from the Interest packet. The purpose of this encoding is to prevent packet length changes so no additional bytes are needed to return an Interest to the previous hop. 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 | PT_RETURN | PacketLength | +---------------+---------------+---------------+---------------+ | HopLimit | ReturnCode | Flags | HeaderLength | +---------------+---------------+---------------+---------------+ Figure 6: Interest Return Header
3.2.3.1. Interest Return HopLimit
This is the original Interest's HopLimit, as received before decrement at the node sending the Interest Return.
3.2.3.2. Interest Return Flags
These are the original Flags as set in the Interest.
3.2.3.3. Return Code
This section maps the Return Code name [RFC8569] to the TLV symbolic name. Section 4.2 maps the symbolic names to numeric values. This field is set by the node creating the Interest Return. A return code of "0" MUST NOT be used, as it indicates that the returning system did not modify the Return Code field.
Top   ToC   RFC8609 - Page 11
   +-------------------------------------+-----------------------------+
   |             Return Type             | Name in RFC 8569            |
   +-------------------------------------+-----------------------------+
   |          T_RETURN_NO_ROUTE          | No Route                    |
   |                                     |                             |
   |       T_RETURN_LIMIT_EXCEEDED       | Hop Limit Exceeded          |
   |                                     |                             |
   |        T_RETURN_NO_RESOURCES        | No Resources                |
   |                                     |                             |
   |         T_RETURN_PATH_ERROR         | Path Error                  |
   |                                     |                             |
   |         T_RETURN_PROHIBITED         | Prohibited                  |
   |                                     |                             |
   |          T_RETURN_CONGESTED         | Congested                   |
   |                                     |                             |
   |        T_RETURN_MTU_TOO_LARGE       | MTU too large               |
   |                                     |                             |
   | T_RETURN_UNSUPPORTED_HASH_RESTRICTI | Unsupported ContentObjectHa |
   |                  ON                 | shRestriction               |
   |                                     |                             |
   |     T_RETURN_MALFORMED_INTEREST     | Malformed Interest          |
   +-------------------------------------+-----------------------------+

                           Table 2: Return Codes

3.3. Global Formats

This section defines global formats that may be nested within other TLVs.

3.3.1. Pad

The pad type may be used by sources that prefer word-aligned data. Padding 4-byte words, for example, would use a 1-byte, 2-byte, and 3-byte Length. Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length. One MUST NOT pad inside a Name. Apart from that, a pad MAY be inserted after any other TLV in the CCNx Message TLV or in the ValidationAlgorithm TLV. In the remainder of this document, we will not show optional Pad TLVs.
Top   ToC   RFC8609 - Page 12
                        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
   +---------------+---------------+---------------+---------------+
   |             T_PAD             |             Length            |
   +---------------+---------------+---------------+---------------+
   /                 variable-length pad MUST be zeros             /
   +---------------+---------------+---------------+---------------+

                          Figure 7: Pad Encoding

3.3.2. Organization-Specific TLVs

Organization-specific TLVs (also known as Vendor TLVs) MUST use the T_ORG type. The Length field is the length of the organization- specific information plus 3. The Value begins with the 3 byte organization number derived from the network byte order encoding of the IANA "Private Enterprise Numbers" registry [IANA-PEN], followed by the organization-specific information. A T_ORG MAY be used as a path segment in a Name. It is treated like any other path segment. 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 +---------------+---------------+---------------+---------------+ | T_ORG | Length (3+value length) | +---------------+---------------+---------------+---------------+ | PEN[0] | PEN[1] | PEN[2] | / +---------------+---------------+---------------+ + / Vendor Specific Value / +---------------+---------------+---------------+---------------+ Figure 8: Organization-Specific TLVs

3.3.3. Hash Format

Hash values are used in several fields throughout a packet. This TLV encoding is commonly embedded inside those fields to specify the specific hash function used and its value. Note that the reserved TLV types are also reserved here for user-defined experimental functions. The LENGTH field of the hash value MUST be less than or equal to the hash function length. If the LENGTH is less than the full length, it is taken as the left LENGTH bytes of the hash function output. Only specified truncations are allowed, not arbitrary truncations.
Top   ToC   RFC8609 - Page 13
   This nested format is used because it allows binary comparison of
   hash values for certain fields without a router needing to understand
   a new hash function.  For example, the KeyIdRestriction is bit-wise
   compared between an Interest's KeyIdRestriction field and a
   ContentObject's KeyId field.  This format means the outer field
   values do not change with differing hash functions so a router can
   still identify those fields and do a binary comparison of the hash
   TLV without need to understand the specific hash used.  An
   alternative approach, such as using T_KEYID_SHA512-256, would require
   each router keeps an up-to-date parser and supporting user-defined
   hash functions here would explode the parsing state-space.

   A CCNx entity MUST support the hash type T_SHA-256.  An entity MAY
   support the remaining hash types.

                  +-----------+------------------------+
                  |   Abbrev  |    Lengths (octets)    |
                  +-----------+------------------------+
                  | T_SHA-256 |           32           |
                  |           |                        |
                  | T_SHA-512 |         64, 32         |
                  |           |                        |
                  |    n/a    | Experimental TLV types |
                  +-----------+------------------------+

                       Table 3: CCNx Hash Functions

                        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
   +---------------+---------------+---------------+---------------+
   |             T_FOO             |              36               |
   +---------------+---------------+---------------+---------------+
   |           T_SHA512            |               32              |
   +---------------+---------------+---------------+---------------+
   /                        32-byte hash value                     /
   +---------------+---------------+---------------+---------------+

                Figure 9: Example nesting inside type T_FOO

3.3.4. Link

A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}. It is a general encoding that is used in both the payload of a Content Object with PayloadType = "Link" and in a Content Object's KeyLink field. A Link is essentially the body of an Interest.
Top   ToC   RFC8609 - Page 14
                        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
   +---------------+---------------+---------------+---------------+
   / Mandatory CCNx Name                                           /
   +---------------+---------------+---------------+---------------+
   / Optional KeyIdRestriction                                     /
   +---------------+---------------+---------------+---------------+
   / Optional ContentObjectHashRestriction                         /
   +---------------+---------------+---------------+---------------+

                         Figure 10: Link Encoding

3.4. Hop-by-Hop TLV Headers

Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached to their ordering. Three hop-by-hop headers are described in this document: +-------------+--------------------+--------------------------------+ | Abbrev | Name | Description | +-------------+--------------------+--------------------------------+ | T_INTLIFE | Interest Lifetime | The time an Interest should | | | (Section 3.4.1) | stay pending at an | | | | intermediate node. | | | | | | T_CACHETIME | Recommended Cache | The Recommended Cache Time for | | | Time (Section | Content Objects. | | | 3.4.2) | | | | | | | T_MSGHASH | Message Hash | A cryptographic hash (Section | | | (Section 3.4.3) | 3.3.3). | +-------------+--------------------+--------------------------------+ Table 4: Hop-by-Hop Header Types Additional hop-by-hop headers are defined in higher level specifications such as the fragmentation specification.

3.4.1. Interest Lifetime

The Interest Lifetime is the time that an Interest should stay pending at an intermediate node. It is expressed in milliseconds as an unsigned integer in network byte order. A value of 0 (encoded as 1 byte 0x00) indicates the Interest does not elicit a Content Object response. It should still be forwarded, but no reply is expected and a forwarder could skip creating a PIT entry.
Top   ToC   RFC8609 - Page 15
                        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
   +---------------+---------------+---------------+---------------+
   |          T_INTLIFE            |             Length            |
   +---------------+---------------+---------------+---------------+
   /                                                               /
   /                      Lifetime (Length octets)                 /
   /                                                               /
   +---------------+---------------+---------------+---------------+

                   Figure 11: Interest Lifetime Encoding

3.4.2. Recommended Cache Time

The Recommended Cache Time (RCT) is a measure of the useful lifetime of a Content Object as assigned by a content producer or upstream node. It serves as a guideline to the Content Store cache in determining how long to keep the Content Object. It is a recommendation only and may be ignored by the cache. This is in contrast to the ExpiryTime (described in Section 3.6.2.2.2) which takes precedence over the RCT and must be obeyed. Because the Recommended Cache Time is an optional hop-by-hop header and not a part of the signed message, a content producer may re-issue a previously signed Content Object with an updated RCT without needing to re-sign the message. There is little ill effect from an attacker changing the RCT as the RCT serves as a guideline only. The Recommended Cache Time (a millisecond timestamp) is an unsigned integer in network byte order that indicates the time when the payload expires (as the number of milliseconds since the epoch in UTC). It is a 64-bit field. 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 +---------------+---------------+---------------+---------------+ | T_CACHETIME | 8 | +---------------+---------------+---------------+---------------+ / / / Recommended Cache Time / / / +---------------+---------------+---------------+---------------+ Figure 12: Recommended Cache Time Encoding
Top   ToC   RFC8609 - Page 16

3.4.3. Message Hash

Within a trusted domain, an operator may calculate the message hash at a border device and insert that value into the hop-by-hop headers of a message. An egress device should remove the value. This permits intermediate devices within that trusted domain to match against a ContentObjectHashRestriction without calculating it at every hop. The message hash is a cryptographic hash from the start of the CCNx Message TLV to the end of the packet. It is used to match against the ContentObjectHashRestriction (Section 3.6.2.1.2). The Message Hash may be of longer length than an Interest's restriction, in which case the device should use the left bytes of the Message Hash to check against the Interest's value. The Message Hash may only carry one hash type and there may only be one Message Hash header. The Message Hash header is unprotected, so this header is only of practical use within a trusted domain, such as an operator's autonomous system. 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 +---------------+---------------+---------------+---------------+ | T_MSGHASH | (length + 4) | +---------------+---------------+---------------+---------------+ | hash type | length | +---------------+---------------+---------------+---------------+ / hash value / +---------------+---------------+---------------+---------------+ Figure 13: Message Hash Header


(next page on part 2)

Next Section