RFC 8569
Content-Centric Networking (CCNx) Semantics
Pages: 40
Experimental
Experimental
Part 1 of 2 – Pages 1 to 20
Internet Research Task Force (IRTF) M. Mosko Request for Comments: 8569 PARC, Inc. Category: Experimental I. Solis ISSN: 2070-1721 LinkedIn C. Wood University of California Irvine July 2019 Content-Centric Networking (CCNx) SemanticsAbstract
This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding. The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest. This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and 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/rfc8569. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. Message Grammar . . . . . . . . . . . . . . . . . . . . . 10 2.2. Consumer Behavior . . . . . . . . . . . . . . . . . . . . 14 2.3. Publisher Behavior . . . . . . . . . . . . . . . . . . . 15 2.4. Forwarder Behavior . . . . . . . . . . . . . . . . . . . 16 2.4.1. Interest HopLimit . . . . . . . . . . . . . . . . . . 16 2.4.2. Interest Aggregation . . . . . . . . . . . . . . . . 17 2.4.3. Content Store Behavior . . . . . . . . . . . . . . . 19 2.4.4. Interest Pipeline . . . . . . . . . . . . . . . . . . 19 2.4.5. Content Object Pipeline . . . . . . . . . . . . . . . 20 3. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1. Name Examples . . . . . . . . . . . . . . . . . . . . . . 23 3.2. Interest Payload ID . . . . . . . . . . . . . . . . . . . 23 4. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 23 5. Content Object Hash . . . . . . . . . . . . . . . . . . . . . 24 6. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Hashes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Validation Algorithm . . . . . . . . . . . . . . . . . . 25 8.2. Message Integrity Codes . . . . . . . . . . . . . . . . . 26 8.3. Message Authentication Codes . . . . . . . . . . . . . . 26 8.4. Signature . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Interest to Content Object Matching . . . . . . . . . . . . . 28 10. Interest Return . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Message Format . . . . . . . . . . . . . . . . . . . . . 30 10.2. ReturnCode Types . . . . . . . . . . . . . . . . . . . . 31 10.3. Interest Return Protocol . . . . . . . . . . . . . . . . 32 10.3.1. No Route . . . . . . . . . . . . . . . . . . . . . . 32 10.3.2. HopLimit Exceeded . . . . . . . . . . . . . . . . . 33 10.3.3. Interest MTU Too Large . . . . . . . . . . . . . . . 33 10.3.4. No Resources . . . . . . . . . . . . . . . . . . . . 33 10.3.5. Path Error . . . . . . . . . . . . . . . . . . . . . 33 10.3.6. Prohibited . . . . . . . . . . . . . . . . . . . . . 33 10.3.7. Congestion . . . . . . . . . . . . . . . . . . . . . 34 10.3.8. Unsupported Content Object Hash Algorithm . . . . . 34 10.3.9. Malformed Interest . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 13.2. Informative References . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
This document describes the principles of the CCNx architecture. It describes a network protocol that uses a hierarchical name to forward requests and to match responses to requests. It does not use endpoint addresses, such as Internet Protocol. 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 concerns the semantics of the protocol and is not dependent on a specific wire encoding. The CCNx Messages [RFC8609] document describes a type-length-value (TLV) wire-protocol encoding. This section introduces the main concepts of CCNx, which are further elaborated in the remainder of the document. The CCNx protocol derives from the early ICN work by Jacobson, et al. [nnc]. Jacobson's version of CCNx is known as the 0.x version ("CCNx 0.x"), and the present work is known as the 1.0 version ("CCNx 1.0"). There are two active implementations of CCNx 1.0. The most complete implementation is Community ICN (CICN) [cicn], a Linux Foundation project hosted at fd.io. Another active implementation is CCN-lite [ccn-lite], with support for Internet of Things (IoT) systems and the RIOT operating system. CCNx 0.x formed the basis of the Named Data Networking (NDN) [ndn] university project. The current CCNx 1.0 specification diverges from CCNx 0.x in a few significant areas. The most pronounced behavioral difference between CCNx 0.x and CCNx 1.0 is that CCNx 1.0 has a simpler response processing behavior. In both versions, a forwarder uses a hierarchical longest prefix match of a request name against the forwarding information base (FIB) to send the request through the network to a system that can issue a response. A forwarder must then match a response's name to a request's name to determine the reverse path and deliver the response to the requester. In CCNx 0.x, the Interest name may be a hierarchical prefix of the response name, which allows a form of Layer 3 (L3) content discovery. In CCNx 1.0, a response's name must exactly equal a request's name. Content discovery is performed by a higher-layer protocol. The selector protocol "CCNx Selectors" [selectors] is an example of using a higher-layer protocol on top of the CCNx 1.0 L3 to perform content discovery. The selector protocol uses a method similar to the original CCNx 0.x techniques without requiring partial name matching of a response to a request in the forwarder.
This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). 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. This document has received critical reading by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. This document is sponsored under the IRTF, 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. The specification may change in the future.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.1.2. Architecture
We describe the architecture of the network in which CCNx operates and introduce certain terminology from [terminology]. The detailed behavior of each component and message grammar is in Section 2. A producer (also called a "publisher") is an endpoint that encapsulates content in Content Objects for transport in the CCNx network. A producer has a public/private keypair and signs (directly or indirectly) the Content Objects. Usually, the producer's KeyId (hash of the public key) is well known or may be derived from the producer's namespace via standard means. A producer operates within one or more namespaces. A namespace is a name prefix that is represented in the forwarding information base (FIB). This allows a request to reach the producer and fetch a response (if one exists). The FIB is a table that tells a forwarder where to send a request. It may point to a local application, a local cache or Content Store, or to a remote system. If there is no matching entry in the FIB, a forwarder cannot process a request. The detailed rules on name matching to the FIB are given in Section 2.4.4. An endpoint has a FIB, though it may be a simple default route. An intermediate system (i.e., a router) typically has a much larger FIB. A core CCNx forwarder, for example, would know all the global routes.
A consumer is an endpoint that requests a name. It is beyond the scope of this document to describe how a consumer learns of a name or publisher KeyId; higher-layer protocols built on top of CCNx handle those tasks, such as search engines or lookup services or well-known names. The consumer constructs a request, called an Interest, and forwards it via the endpoint's FIB. The consumer should get back either a response (called a Content Object) that matches the Interest or a control message (called an Interest Return) that indicates the network cannot handle the request. There are three ways to detect errors in Interest handling. An Interest Return is a network control message that indicates a low- level error like "no route" or "out of resources". If an Interest arrives at a producer, but the producer does not have the requested content, the producer should send an application-specific error message (e.g., a "not found" message). Finally, a consumer may not receive anything; in which case, it should timeout and, depending on the application, retry the request or return an error to the application.1.3. Protocol Overview
The goal of CCNx is to name content and retrieve the content from the network without binding it to a specific network endpoint. A routing system (specified separately) populates the FIB tables at each CCNx router with hierarchical name prefixes that point towards the content producers under that prefix. A request finds matching content along those paths, in which case a response carries the data, or, if no match is found, a control message indicates the failure. A request may further refine acceptable responses with a restriction on the response's signer and the cryptographic hash of the response. The details of these restrictions are described below. The CCNx name is a hierarchical series of name segments. Each name segment has a type and zero or more bytes. Matching two names is done as a binary comparison of the type and value, and is done segment by segment. The human-readable form is defined under a URI scheme "ccnx:" [ccnx-uri], though the canonical encoding of a name is a series of pairs (type, octet string). There is no requirement that any name segment be human readable or UTF-8. The first few segments in a name will be matched against the FIB, and a routing protocol may put its own restrictions on the routable name components (e.g., a maximum length or character-encoding rules). In principle, name segments and names have unbounded length, though in practice they are limited by the wire encoding and practical considerations imposed by a routing protocol. Note that in CCNx, name segments use binary comparison, whereas in a URI, the authority uses a case-insensitive hostname (due to DNS).
The CCNx name, as used by the forwarder, is purposefully left as a
general octet-encoded type and value without any requirements on
human readability and character encoding. The reason for this is
that we are concerned with how a forwarder processes names. We
expect that applications, routing protocols, or other higher layers
will apply their own conventions and restrictions on the allowed name
segment types and name segment values.
CCNx is a request and response protocol that fetches chunks of data
using a name. The integrity of each chunk may be directly asserted
through a digital signature or Message Authentication Code (MAC), or,
alternatively, indirectly via hash chains. Chunks may also carry
weaker Message Integrity Codes (MICs) or no integrity protection
mechanism at all. Because provenance information is carried with
each chunk (or larger indirectly protected block), we no longer need
to rely on host identities, such as those derived from TLS
certificates, to ascertain the chunk legitimacy. Therefore, data
integrity is a core feature of CCNx; it does not rely on the data
transmission channel. There are several options for data
confidentiality, discussed later.
This document only defines the general properties of CCNx names. In
some isolated environments, CCNx users may be able to use any name
they choose and either inject that name (or prefix) into a routing
protocol or use other information foraging techniques. In the
Internet environment, there will be policies around the formats of
names and assignments of names to publishers, though those are not
specified here.
The key concept of CCNx is that a subjective name is
cryptographically bound to a fixed payload. These publisher-
generated bindings can therefore be cryptographically verified. A
named payload is thus the tuple {{Name, ExtraFields, Payload,
ValidationAlgorithm}, ValidationPayload}, where all fields in the
inner tuple are covered by the validation payload (e.g., signature).
Consumers of this data can check the binding integrity by recomputing
the same cryptographic hash and verifying the digital signature in
ValidationPayload.
In addition to digital signatures (e.g., RSA), CCNx also supports
message authentication codes (e.g., Hashed Message Authentication
Code (HMAC)) and message integrity codes (e.g., Cyclic Redundancy
Checks (CRC)). To maintain the cryptographic binding, there should
be at least one object with a signature or authentication code, but
not all objects require it. For example, a first object with a
signature could refer to other objects via a hash chain, a Merkle
tree, or a signed manifest. The later objects may not have any
validation and rely purely on the references. The use of an integrity code (e.g., CRC) is intended for detecting accidental corruption in an Interest. CCNx specifies a network protocol around Interests (request messages) and Content Objects (response messages) to move named payloads. An Interest includes the Name field, which identifies the desired response, and optional matching restrictions. Restrictions limit the possible matching Content Objects. Two restrictions exist: the Key ID restriction (KeyIdRestr) and Content Object Hash restriction (ContentObjectHashRestr). The first restriction on the KeyId limits responses to those signed with a ValidationAlgorithm KeyId field equal to the restriction. The second is the Content Object Hash restriction, which limits the response to one where the cryptographic hash of the entire named payload is equal to the restriction. Section 9 fully explains how these restrictions limit matching of a Content Object to an Interest. The hierarchy of a CCNx name is used for routing via the longest matching prefix in a forwarder. The longest matching prefix is computed name segment by name segment in the hierarchical name, where each name segment must be exactly equal to match. There is no requirement that the prefix be globally routable. Within a deployment, any local routing may be used, even one that only uses a single flat (nonhierarchical) name segment. Another concept of CCNx is that there should be flow balance between Interest messages and Content Object messages. At the network level, an Interest traveling along a single path should elicit no more than one Content Object response. If some node sends the Interest along more than one path, that node should consolidate the responses such that only one Content Object flows back towards the requester. If an Interest is sent broadcast or multicast on a multiple-access media, the sender should be prepared for multiple responses unless some other media-dependent mechanism like gossip suppression or leader election is used. As an Interest travels the forward path following the FIB, it establishes state at each forwarder such that a Content Object response can trace its way back to the original requester(s) without the requester needing to include a routable return address. We use the notional Pending Interest Table (PIT) as a method to store state that facilitates the return of a Content Object. The notional PIT stores the last hop of an Interest plus its Name field and optional restrictions. This is the data required to match a Content Object to an Interest (see Section 9). When a Content
Object arrives, it must be matched against the PIT to determine which entries it satisfies. For each such entry, at most one copy of the Content Object is sent to each listed last hop in the PIT entries. An actual PIT is not mandated by this specification. An implementation may use any technique that gives the same external behavior. There are, for example, research papers that use techniques like label switching in some parts of the network to reduce the per-node state incurred by the PIT [dart]. Some implementations store the PIT state in the FIB, so there is not a second table. If multiple Interests with the same {Name, [KeyIdRestr], [ContentObjectHashRestr]} tuple arrive at a node before a Content Object matching the first Interest comes back, they are grouped in the same PIT entry and their last hops are aggregated (see Section 2.4.2). Thus, one Content Object might satisfy multiple pending Interests in a PIT. In CCNx, higher-layer protocols are often called "name-based protocols" because they operate on the CCNx name. For example, a versioning protocol might append additional name segments to convey state about the version of payload. A content discovery protocol might append certain protocol-specific name segments to a prefix to discover content under that prefix. Many such protocols may exist and apply their own rules to names. They may be layered with each protocol encapsulating (to the left) a higher layer's name prefix. This document also describes a control message called an Interest Return. A network element may return an Interest message to a previous hop if there is an error processing the Interest. The returned Interest may be further processed at the previous hop or returned towards the Interest origin. When a node returns an Interest, it indicates that the previous hop should not expect a response from that node for the Interest, i.e., there is no PIT entry left at the returning node for a Content Object to follow. There are multiple ways to describe larger objects in CCNx. Aggregating L3 Content Objects into larger objects is beyond the scope of this document. One proposed method, File-Like ICN Collection (FLIC) [flic], uses a manifest to enumerate the pieces of a larger object. Manifests are, themselves, Content Objects. Another option is to use a convention in the Content Object name, as in the CCNx Chunking [chunking] protocol where a large object is broken into small chunks and each chunk receives a special name component indicating its serial order.
At the semantic level, described in this document, we do not address fragmentation. One experimental fragmentation protocol, BeginEnd Fragments [befrags], uses a multipoint PPP-style technique for use over L2 interfaces with the specification for CCNx Messages [RFC8609] in TLV wire encoding. With these concepts, the remainder of the document specifies the behavior of a forwarder in processing Interest, Content Object, and Interest Return messages.2. Protocol
This section defines the grammar of a CCNx Message (Interest, Content Object, or Interest Return). It then presents typical behaviors for a consumer, a publisher, and a forwarder. In the forwarder section, there are detailed descriptions about how to handle the forwarder- specific topics, such as HopLimit and Content Store, along with detailed processing pipelines for Interest and Content Object messages.2.1. Message Grammar
The CCNx Message ABNF [RFC5234] grammar is shown in Figure 1. The grammar does not include any encoding delimiters, such as TLVs. Specific wire encodings are given in a separate document. If a Validation section exists, the Validation Algorithm covers from the Body (BodyName or BodyOptName) through the end of the ValidationAlg section. The InterestLifetime, CacheTime, and Return Code fields exist outside of the validation envelope and may be modified. HashType, PayloadType, and Private Enterprise Number (PEN) need to correspond to IANA values registered in the "CCNx Hash Function Types" and "CCNx Payload Types" registries [ccnx-registry], as well as the "Private Enterprise Numbers" registry [eprise-numbers], respectively. The various fields, in alphabetical order, are defined as: AbsTime: Absolute times are conveyed as the 64-bit UTC time in milliseconds since the epoch (standard POSIX time). CacheTime: The absolute time after which the publisher believes there is low value in caching the Content Object. This is a recommendation to caches (see Section 4). Cert: Some applications may wish to embed an X.509 certificate to both validate the signature and provide a trust anchor. The Cert is a DER-encoded X.509 certificate.
ConObjField: These are optional fields that may appear in a Content
Object.
ConObjHash: The value of the Content Object Hash, which is the
SHA256-32 over the message from the beginning of the body to the
end of the message. Note that this coverage area is different
from the ValidationAlg. This value SHOULD NOT be trusted across
domains (see Section 5).
ContentObjectHashRestr: The Content Object Hash restriction. A
Content Object must hash to the same value as the restriction
using the same HashType. The ContentObjectHashRestr MUST use
SHA256-32.
ExpiryTime: An absolute time after which the Content Object should
be considered expired (see Section 4).
Hash: Hash values carried in a Message carry a HashType to identify
the algorithm used to generate the hash followed by the hash
value. This form is to allow hash agility. Some fields may
mandate a specific HashType.
HashType: The algorithm used to calculate a hash, which must
correspond to one of the IANA "CCNx Hash Function Types"
[ccnx-registry].
HopLimit: Interest messages may loop if there are loops in the
forwarding plane. To eventually terminate loops, each Interest
carries a HopLimit that is decremented after each hop and no
longer forwarded when it reaches zero. See Section 2.4.
InterestField: These are optional fields that may appear in an
Interest message.
KeyId: An identifier for the key used in the ValidationAlg. See
Validation (Section 8) for a description of how it is used for
MACs and signatures.
KeyIdRestr: The KeyId Restriction. A Content Object must have a
KeyId with the same value as the restriction.
KeyLink: A Link (see Section 6) that names how to retrieve the key
used to verify the ValidationPayload (see Section 8).
Lifetime: The approximate time during which a requester is willing
to wait for a response, usually measured in seconds. It is not
strongly related to the network round-trip time, though it must
necessarily be larger.
Name: A name is made up of a nonempty first segment followed by zero
or more additional segments, which may be of 0 length. Name
segments are opaque octet strings and are thus case sensitive if
encoding UTF-8. An Interest MUST have a Name. A Content Object
MAY have a Name (see Section 9). The segments of a name are said
to be complete if its segments uniquely identify a single Content
Object. A name is exact if its segments are complete. An
Interest carrying a full name is one that specifies an exact name
and the Content Object Hash restriction of the corresponding
Content Object.
Payload: The message's data, as defined by PayloadType.
PayloadType: The format of the Payload field. If missing, assume
Data type (T_PAYLOADTYPE_DATA) [ccnx-registry]. Data type means
the payload is opaque application bytes. Key type
(T_PAYLOADTYPE_KEY [ccnx-registry]) means the payload is a DER-
encoded public key or X.509 certificate. Link type
(T_PAYLOADTYPE_LINK [ccnx-registry]) means it is one or more Links
(see Section 6).
PublicKey: Some applications may wish to embed the public key used
to verify the signature within the message itself. The PublickKey
is DER encoded.
RelTime: A relative time, measured in milliseconds.
ReturnCode: States the reason an Interest message is being returned
to the previous hop (see Section 10.2).
SigTime: The absolute time (UTC milliseconds) when the signature was
generated. The signature time only applies to the validation
algorithm; it does not necessarily represent when the validated
message was created.
Vendor: Vendor-specific opaque data. The Vendor data includes the
IANA Private Enterprise Numbers [eprise-numbers], followed by
vendor-specific information. CCNx allows vendor-specific data in
most locations of the grammar.
Message = Interest / ContentObject / InterestReturn
Interest = IntHdr BodyName [Validation]
IntHdr = HopLimit [Lifetime] *Vendor
ContentObject = ConObjHdr BodyOptName [Validation]
ConObjHdr = [CacheTime / ConObjHash] *Vendor
InterestReturn= ReturnCode Interest
BodyName = Name Common
BodyOptName = [Name] Common
Common = *Field [Payload] Validation = ValidationAlg ValidationPayload Name = FirstSegment *Segment FirstSegment = 1*OCTET / Vendor Segment = *OCTET / Vendor ValidationAlg = (RSA-SHA256 / EC-SECP-256K1 / EC-SECP-384R1 / HMAC-SHA256 / CRC32C) *Vendor ValidationPayload = 1*OCTET PublicAlg = KeyId [SigTime] [KeyLink] [PublicKey] [Cert] RSA-SHA256 = PublicAlg EC-SECP-256K1 = PublicAlg EC-SECP-384R1 = PublicAlg HMAC-SHA256 = KeyId [SigTime] [KeyLink] CRC32C = [SigTime] AbsTime = 8OCTET ; 64-bit UTC msec since epoch CacheTime = AbsTime ConObjField = ExpiryTime / PayloadType ConObjHash = Hash ExpiryTime = AbsTime Field = InterestField / ConObjField / Vendor Hash = HashType 1*OCTET HashType = 2OCTET ; IANA "CCNx Hash Function Types" HopLimit = OCTET InterestField = KeyIdRestr / ContentObjectHashRestr KeyId = Hash KeyIdRestr = Hash KeyLink = Link Lifetime = RelTime Link = Name [KeyIdRestr] [ContentObjectHashRestr] ContentObjectHashRestr = Hash Payload = *OCTET PayloadType = OCTET ; IANA "CCNx Payload Types" PublicKey = *OCTET ; DER-encoded public key Cert = *OCTET ; DER-encoded X.509 Certificate RelTime = 1*OCTET ; msec ReturnCode = OCTET ; see Section 10.2 SigTime = AbsTime Vendor = PEN *OCTET PEN = 1*OCTET ; IANA "Private Enterprise Number" Figure 1: CCNx Message ABNF Grammar
2.2. Consumer Behavior
To request a piece of content for a given {Name, [KeyIdRest], [ContentObjectHashRestr]} tuple, a consumer creates an Interest message with those values. It MAY add a validation section, typically only a CRC32C. A consumer MAY put a Payload field in an Interest to send additional data to the producer beyond what is in the name. The name is used for routing and may be remembered at each hop in the notional PIT to facilitate returning a Content Object; storing large amounts of state in the name could lead to high memory requirements. Because the payload is not considered when forwarding an Interest or matching a Content Object to an Interest, a consumer SHOULD put an Interest Payload ID (see Section 3.2) as part of the name to allow a forwarder to match Interests to Content Objects and avoid aggregating Interests with different payloads. Similarly, if a consumer uses a MAC or a signature, it SHOULD also include a unique segment as part of the name to prevent the Interest from being aggregated with other Interests or satisfied by a Content Object that has no relation to the validation. The consumer SHOULD specify an InterestLifetime, which is the length of time the consumer is willing to wait for a response. The InterestLifetime is an application-scale time, not a network round- trip time (see Section 2.4.2). If not present, the InterestLifetime will use a default value (2 seconds). The consumer SHOULD set the Interest HopLimit to a reasonable value or use the default 255. If the consumer knows the distances to the producer via routing, it SHOULD use that value. A consumer hands off the Interest to its first forwarder, which will then forward the Interest over the network to a publisher (or replica) that may satisfy it based on the name (see Section 2.4). Interest messages are unreliable. A consumer SHOULD run a transport protocol that will retry the Interest if it goes unanswered, up to the InterestLifetime. No transport protocol is specified in this document. The network MAY send to the consumer an Interest Return message that indicates the network cannot fulfill the Interest. The ReturnCode specifies the reason for the failure, such as no route or congestion. Depending on the ReturnCode, the consumer MAY retry the Interest or MAY return an error to the requesting application.
If the content was found and returned by the first forwarder, the
consumer will receive a Content Object. The consumer uses the
following set of checks to validate a received Content Object:
o The consumer MUST ensure the Content Object is properly formatted.
o The consumer MUST verify that the returned Content Object matches
one or more pending Interests as per Section 9.
o If the Content Object is signed, the consumer SHOULD
cryptographically verify the signature as per Section 8. If it
does not have the corresponding key, it SHOULD fetch the key, such
as from a key resolution service or via the KeyLink.
o If the signature has a SigTime, the consumer MAY use that in
considering if the signature is valid. For example, if the
consumer is asking for dynamically generated content, it should
expect the SigTime not to be before the time the Interest was
generated.
o If the Content Object is signed, the consumer SHOULD assert the
trustworthiness of the signing key to the namespace. Such an
assertion is beyond the scope of this document, though one may use
traditional PKI methods, a trusted key resolution service, or
methods like [trust].
o The consumer MAY cache the Content Object for future use, up to
the ExpiryTime if present.
o The consumer MAY accept a Content Object off the wire that is
expired. A packet Content Object may expire while in flight;
there is no requirement that forwarders drop expired packets in
flight. The only requirement is that Content Stores, caches, or
producers MUST NOT respond with an expired Content Object.
2.3. Publisher Behavior
This document does not specify the method by which names populate a
FIB table at forwarders (see Section 2.4). A publisher is either
configured with one or more name prefixes under which it may create
content or it chooses its name prefixes and informs the routing layer
to advertise those prefixes.
When a publisher receives an Interest, it SHOULD:
o Verify that the Interest is part of the publisher's namespace(s).
o If the Interest has a Validation section, verify it as per
Section 8. Usually an Interest will only have a CRC32C, unless
the publisher application specifically accommodates other
validations. The publisher MAY choose to drop Interests that
carry a Validation section if the publisher application does not
expect those signatures, as this could be a form of computational
denial of service. If the signature requires a key that the
publisher does not have, it is NOT RECOMMENDED that the publisher
fetch the key over the network unless it is part of the
application's expected behavior.
o Retrieve or generate the requested Content Object and return it to
the Interest's previous hop. If the requested content cannot be
returned, the publisher SHOULD reply with an Interest Return or a
Content Object with application payload that says the content is
not available; this Content Object should have a short ExpiryTime
in the future or not be cacheable (i.e., an expiry time of 0).
2.4. Forwarder Behavior
A forwarder routes Interest messages based on a Forwarding
Information Base (FIB), returns Content Objects that match Interests
to the Interest's previous hop, and processes Interest Return control
messages. It may also keep a cache of Content Objects in the
notional Content Store table. This document does not specify the
internal behavior of a forwarder, only these and other external
behaviors.
In this document, we will use two processing pipelines: one for
Interests and one for Content Objects. Interest processing is made
up of checking for duplicate Interests in the PIT (see
Section 2.4.2), checking for a cached Content Object in the Content
Store (see Section 2.4.3), and forwarding an Interest via the FIB.
Content Store processing is made up of checking for matching
Interests in the PIT and forwarding to those previous hops.
2.4.1. Interest HopLimit
Interest looping is not prevented in CCNx. An Interest traversing
loops is eventually discarded using the hop-limit field of the
Interest, which is decremented at each hop traversed by the Interest.
A loop may also terminate because the Interest is aggregated with its
previous PIT entry along the loop. In this case, the Content Object
will be sent back along the loop and eventually return to a node that
already forwarded the content, so it will likely not have a PIT entry
anymore. When the content reaches a node without a PIT entry, it
will be discarded. It may be that a new Interest or another looped
Interest will return to that same node, in which case the node will
return a cached response to make a new PIT entry, as below.
The HopLimit is the last resort method to stop Interest loops where a
Content Object chases an Interest around a loop and where the
intermediate nodes, for whatever reason, no longer have a PIT entry
and do not cache the Content Object.
Every Interest MUST carry a HopLimit. An Interest received from a
local application MAY have a 0 HopLimit, which restricts the Interest
to other local sources.
When an Interest is received from another forwarder, the HopLimit
MUST be positive, otherwise the forwarder will discard the Interest.
A forwarder MUST decrement the HopLimit of an Interest by at least 1
before it is forwarded.
If the decremented HopLimit equals 0, the Interest MUST NOT be
forwarded to another forwarder; it MAY be sent to a local publisher
application or serviced from a local Content Store.
A RECOMMENDED HopLimit-processing pipeline is below:
o If Interest received from a remote system:
* If received HopLimit is 0, optionally send Interest Return
(HopLimit Exceeded), and discard Interest.
* Otherwise, decrement the HopLimit by 1.
o Process as per Content Store and Aggregation rules.
o If the Interest will be forwarded:
* If the (potentially decremented) HopLimit is 0, restrict
forwarding to the local system.
* Otherwise, forward as desired to local or remote systems.
2.4.2. Interest Aggregation
Interest aggregation is when a forwarder receives an Interest message
that could be satisfied by the response to another Interest message
already forwarded by the node, so the forwarder suppresses forwarding
the new Interest; it only records the additional previous hop so a
Content Object sent in response to the first Interest will satisfy
both Interests.
CCNx uses an Interest aggregation rule that assumes the
InterestLifetime is akin to a subscription time and is not a network
round-trip time. Some previous aggregation rules assumed the
lifetime was a round-trip time, but this leads to problems of
expiring an Interest before a response comes if the RTT is estimated
too short or interfering with an Automatic Repeat reQuest (ARQ)
scheme that wants to retransmit an Interest but a prior Interest
overestimated the RTT.
A forwarder MAY implement an Interest aggregation scheme. If it does
not, then it will forward all Interest messages. This does not imply
that multiple, possibly identical, Content Objects will come back. A
forwarder MUST still satisfy all pending Interests, so one Content
Object could satisfy multiple similar Interests, even if the
forwarder did not suppress duplicate Interest messages.
A RECOMMENDED Interest aggregation scheme is:
o Two Interests are considered "similar" if they have the same Name,
KeyIdRestr, and ContentObjectHashRestr, where a missing optional
field in one must be missing in the other.
o Let the notional value InterestExpiry (a local value at the
forwarder) be equal to the receive time plus the InterestLifetime
(or a platform-dependent default value if not present).
o An Interest record (PIT entry) is considered invalid if its
InterestExpiry time is in the past.
o The first reception of an Interest MUST be forwarded.
o A second or later reception of an Interest similar to a valid
pending Interest from the same previous hop MUST be forwarded. We
consider these a retransmission request.
o A second or later reception of an Interest similar to a valid
pending Interest from a new previous hop MAY be aggregated (not
forwarded). If this Interest has a larger HopLimit than the
pending Interest, it MUST be forwarded.
o Aggregating an Interest MUST extend the InterestExpiry time of the
Interest record. An implementation MAY keep a single
InterestExpiry time for all previous hops or MAY keep the
InterestExpiry time per previous hop. In the first case, the
forwarder might send a Content Object down a path that is no
longer waiting for it, in which case the previous hop (next hop of
the Content Object) would drop it.
2.4.3. Content Store Behavior
The Content Store is a special cache that is an integral part of a CCNx forwarder. It is an optional component. It serves to repair lost packets and handle flash requests for popular content. It could be prepopulated or use opportunistic caching. Because the Content Store could serve to amplify an attack via cache poisoning, there are special rules about how a Content Store behaves. 1. A forwarder MAY implement a Content Store. If it does, the Content Store matches a Content Object to an Interest via the normal matching rules (see Section 9). 2. If an Interest has a KeyId restriction, then the Content Store MUST NOT reply unless it knows the signature on the matching Content Object is correct. It may do this by external knowledge (i.e., in a managed network or system with prepopulated caches) or by having the public key and cryptographically verifying the signature. A Content Store is NOT REQUIRED to verify signatures; if it does not, then it treats these cases like a cache miss. 3. If a Content Store chooses to verify signatures, then it MAY do so as follows. If the public key is provided in the Content Object itself (i.e., in the PublicKey field) or in the Interest, the Content Store MUST verify that the public key's hash is equal to the KeyId and that it verifies the signature (see Section 8.4). A Content Store MAY verify the digital signature of a Content Object before it is cached, but it is not required to do so. A Content Store SHOULD NOT fetch keys over the network. If it cannot or has not yet verified the signature, it should treat the Interest as a cache miss. 4. If an Interest has a Content Object Hash restriction, then the Content Store MUST NOT reply unless it knows the matching Content Object has the correct hash. If it cannot verify the hash, then it should treat the Interest as a cache miss. 5. It must obey the cache control directives (see Section 4).2.4.4. Interest Pipeline
1. Perform the HopLimit check (see Section 2.4.1). 2. If the Interest carries a validation, such as a MIC or a signature with an embedded public key or certificate, a forwarder MAY validate the Interest as per Section 8. A forwarder SHOULD NOT fetch keys via a KeyLink. If the forwarder drops an Interest
due to failed validation, it MAY send an Interest Return
(Section 10.3.9).
3. Determine if the Interest can be aggregated as per Section 2.4.2.
If it can be, aggregate and do not forward the Interest.
4. If forwarding the Interest, check for a hit in the Content Store
as per Section 2.4.3. If a matching Content Object is found,
return it to the Interest's previous hop. This injects the
Content Store as per Section 2.4.5.
5. Look up the Interest in the FIB. Longest Prefix Match (LPM) is
performed name segment by name segment (not byte or bit). It
SHOULD exclude the Interest's previous hop. If a match is found,
forward the Interest. If no match is found or the forwarder
chooses not to forward due to a local condition (e.g.,
congestion), it SHOULD send an Interest Return message as per
Section 10.
2.4.5. Content Object Pipeline
1. It is RECOMMENDED that a forwarder that receives a Content Object
check that the Content Object came from an expected previous hop.
An expected previous hop is one pointed to by the FIB or one
recorded in the PIT as having had a matching Interest sent that
way.
2. A Content Object MUST be matched to all pending Interests that
satisfy the matching rules (see Section 9). Each satisfied
pending Interest MUST then be removed from the set of pending
Interests.
3. A forwarder SHOULD NOT send more than one copy of the received
Content Object to the same Interest previous hop. It may happen,
for example, that two Interests ask for the same Content Object
in different ways (e.g., by name and by name and KeyId), and that
they both come from the same previous hop. It is normal to send
the same Content Object multiple times on the same interface,
such as Ethernet, if it is going to different previous hops.
4. A Content Object SHOULD only be put in the Content Store if it
satisfied an Interest (and passed rule #1 above). This is to
reduce the chances of cache poisoning.
(next page on part 2)