idnits 2.17.1 draft-mosko-icnrg-ccnxsemantics-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'CCN' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 714, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Mosko 3 Internet-Draft I. Solis 4 Intended status: Experimental PARC, Inc. 5 Expires: September 10, 2015 March 9, 2015 7 CCNx Semantics 8 draft-mosko-icnrg-ccnxsemantics-01 10 Abstract 12 This document describes the core concepts of the CCNx architecture 13 and presents a minimum network protocol based on two messages: 14 Interest and Content Object. It specifies the set of mandatory and 15 optional fields within those messages and describes their behavior 16 and interpretation. This architecture and protocol specification is 17 independent of a specific wire encoding. 19 The protocol also uses a Control message called an InterestReturn, 20 whereby one system can return an Interest message to the previous hop 21 due to an error condition. It indicates to the previous hop that the 22 current system will not respond to the Interest. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 60 2. Named Payload . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Interests . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Content Objects . . . . . . . . . . . . . . . . . . . . . . . 11 64 6. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 7.1. Validation Algorithm . . . . . . . . . . . . . . . . . . . 13 67 8. Interest to Content Object matching . . . . . . . . . . . . . 14 68 9. Request/Response Protocol . . . . . . . . . . . . . . . . . . 15 69 10. Interest Return . . . . . . . . . . . . . . . . . . . . . . . 16 70 10.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 16 71 10.2. ReturnCode Types . . . . . . . . . . . . . . . . . . . . . 17 72 10.3. Interest Return Protocol . . . . . . . . . . . . . . . . . 17 73 10.3.1. No Route . . . . . . . . . . . . . . . . . . . . . . 18 74 10.3.2. HopLimit Exceeded . . . . . . . . . . . . . . . . . . 19 75 10.3.3. Interest MTU Too Large . . . . . . . . . . . . . . . 19 76 10.3.4. No Resources . . . . . . . . . . . . . . . . . . . . 19 77 10.3.5. Path Error . . . . . . . . . . . . . . . . . . . . . 19 78 10.3.6. Prohibited . . . . . . . . . . . . . . . . . . . . . 19 79 10.3.7. Congestion . . . . . . . . . . . . . . . . . . . . . 19 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 85 14.2. Informative References . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 88 1. Introduction 90 This document describes the principles of the CCNx architecture. It 91 describes the network protocol based on two message types: Interests 92 and Content Objects. The description is not dependent on a specific 93 wire format or particular encodings. 95 CCNx uses subjective names to identify bytes of payload. The Name 96 combines a routable prefix with an arbitrary suffix assigned by the 97 publisher to a piece of content. The result is a "named payload". 98 This is different from other systems that use only self-certifying 99 names, where the payload name is intrinsically derivable from the 100 payload or its realization in a network object (e.g. a SHA-256 hash 101 of the payload or network object). 103 The key concept of CCNx is that a subjective name is bound to a fixed 104 payload via cryptographic operations. This implies that the fact 105 that a given publisher bound a certain subjective name to a certain 106 payload can be verified via cryptographic means. For example, a 107 publisher could use a cryptographic hash over the name and payload, 108 sign the hash, and deliver the tuple {Name, Payload, Validation}. 109 Additional information would be included as needed by different 110 validation mechanisms are used. A typical named payload is thus 111 {Name, Payload, ValidationAlgorithm}. 113 CCNx specifies a network protocol around Interests (request messages) 114 and Content Objects (response messages) to move named payloads. An 115 Interest includes the Name, the desired payload, and two optional 116 restrictions to limit responses to a specific publisher or a specific 117 Content Object. The Content Object response carries a matching Name 118 and the specified payload. Matching a Content Object to an Interest 119 is an exact match on the Name. The CCNx network protocol of 120 Interests and Content Objects imposes a restriction on Names: each 121 Name should be hierarchical and is used to route towards an 122 authoritative source. The CCNx Name looks like a URI absolute path 123 and we use URI terminology to describe CCN Names as made up of name 124 segments. In practice it has a binary encoding, not a text string. 126 The hierarchy of a CCNx Name is used for routing via the longest 127 matching prefix in a Forwarder. The longest matching prefix is 128 computed name segment by name segment in the hierarchical path name, 129 where each name segment must be exactly equal to match. There is no 130 requirement that the prefix be globally routable. Within a 131 deployment any local routing may be used, even one that only uses a 132 single flat (non-hierarchical) name segment. Some Forwarders may use 133 more advanced matching rules that allow both longest matching prefix 134 and shorter prefixes. 136 Another central concept of CCNx is that there should be flow balance 137 between Interest messages and Content Object messages. At the 138 network level, an Interest traveling along a single path should 139 elicit no more than one Content Object response. If some node sends 140 the Interest along more than one path, that node should consolidate 141 the responses such that only one Content Object flows upstream from 142 it to the requester. 144 There are additional optional attributes in an Interest message that 145 can be used to select between multiple Content Objects with matching 146 Names (it is possible that multiple publishers could issue Content 147 Objects with the same Name). An Interest may carry an optional 148 KeyIdRestriction and / or an optional ContentObjectHashRestriction. 149 If either or both of these are present, a Forwarder must ensure that 150 they exactly match the corresponding KeyId and computed 151 ContentObjectHash in the Content Object. 153 As an Interest travels the forward path following the Forwarding 154 Information Base (FIB), it leaves behind state at each Forwarder. 155 This state is stored in the Pending Interest Table (PIT), which 156 tracks the ingress and egress ports as well as the Name, 157 KeyIdRestriction (if one exists), and ContentObjectHashRestriction 158 (if one exists) of each Interest. When a Content Object arrives at 159 the node, it is exactly matched against that tuple to see if it 160 satisfies any Interests in the PIT. If it does, it is returned along 161 the matching Interest's reverse path. If it does not, the Content 162 Object is dropped. 164 If multiple Interests with the same tuple {Name, KeyIdRestriction, 165 ContentObjectHashRestriction} arrive at a node before a Content 166 Object matching the first Interest comes back, they are grouped in 167 the same PIT entry and their reverse paths aggregated. Thus, one 168 Content Object might satisfy multiple pending Interests. 170 In CCNx, higher-layer protocols often become so-called "name-based 171 protocols" because they operate on the CCNx Name. For example, a 172 versioning protocol might append additional name segments to convey 173 state about the version of payload. A content discovery protocol 174 might append certain protocol-specific name segments to a prefix to 175 discover content under that prefix. Many such protocols may exist 176 and apply their own rules to Names. They may be layered with each 177 protocol encapsulating (to the left) a higher layer's Name prefix. 179 This document also describes a control message called an 180 InterestReturn. A network element may return an Interest message to 181 a previous hop if there is an error processing the Interest. The 182 returned Interest may be further processed at the previous hop or 183 returned towards the Interest origin. When a node returns an 184 Interest it indicates that the previous hop should not expect a 185 response from that node for the Interest -- i.e. there is no PIT 186 entry left at the returning node for a Content Object to follow. 188 There are multiple ways to describe larger objects in CCNx. Some 189 options may use the namespace while others may use a structure such 190 as a Manifest. This document does not address these options at this 191 time. 193 The remainder of this document describes a named payload, and the 194 Interest/Content Object network protocol behavior in detail. 196 TODO -- we have not adopted the Requirements Language yet. 198 1.1. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in RFC 2119 [RFC2119]. 204 2. Named Payload 206 CCNx supports several cryptographic means to bind a Name to a 207 payload. Interest and Content Object messages include a section 208 called the ValidationAlgorithm, which specifies the algorithm to use 209 to verify the binding. Several validation algorithms are supported 210 including specific Message Integrity Checks (MICs), Message 211 Authentication Codes (MACs), and Signature types. These are over 212 specific wire format encodings. Additional schemes could be added in 213 the future. Interest and Content Object messages also include a 214 section called the ValidationPayload which contains the validation 215 output. 217 The KeyId is an optional field in the ValidationAlgorithm. It is an 218 octet string that identifies the key used to sign the Content Object. 219 It uniquely identifies the publisher. It is similar to a Subject Key 220 Identifier from X509 [RFC 3280, Section 4.2.1.2]. It should be 221 derived from the key used to sign, for example SHA-256 hash of the 222 key. It applies to both public/private key systems and to symmetric 223 key systems using HMAC. 225 A PublicKeyLocator is an optional field in the ValidationAlgorithm. 226 It may be one of (a) the signer's public key, (b) the signer's 227 certificate, or (c) a KeyName that points to the location of the 228 signer's key or certificate. 230 A Key inside a PublicKeyLocator is a public key corresponding to the 231 signer's private key. Examples would be PEM or DER encodings. The 232 exact encoding is up to the wire format. 234 A Certificate is an X.509 certificate of the signer's public key. 235 Examples would be PEM or DER encodings of the certificate. The exact 236 encoding is up to the wire format. 238 A KeyName is a CCNx Name and optional signer's KeyId of that name's 239 publisher. The CCNx Name points to a Key or Certificate. The 240 KeyName signer KeyId is of the signer of the target name's Content 241 Object, not of the target key or certificate. 243 A SignatureTime is an optional field in the ValidationAlgorithm. It 244 may be used as part of the signature validation check to ensure the 245 signature was generatred around the expected time. In particular, if 246 the public key is conveyed in a certificate with a validity period, 247 the verifying system may enforce that the signature came from a 248 corresponding period. Some verifiers might determine a signature 249 without a SignatureTime to be invalid. 251 3. Names 253 A CCNx name is a composition of name segments. Each name segment 254 carries a label identifying the purpose of the name segment, and a 255 value. For example, some name segments are general names and some 256 serve specific purposes, such as carrying version information or the 257 sequencing of many chunks of a large object into smaller, signed 258 Content Objects. 260 The name segment labels specified in this document are given in the 261 table below. Name Segment is a general name segment, typically 262 occurring in the routable prefix and user-specified content name. 263 Other segment types are for functional name components that imply a 264 specific purpose. 266 A forwarding table entry may contain name segments of any type. 267 Routing protocol policy and local system policy may limit what goes 268 into forwarding entries, but there is no restriction at the core 269 level. An Interest routing protocol, for example, may only allow 270 binary name segments. A load balancer or compute cluster may route 271 through additional component types, depending on their services. 273 +-------------+-----------------------------------------------------+ 274 | Name | Description | 275 +-------------+-----------------------------------------------------+ 276 | Name | A generic name segment that includes arbitrary | 277 | Segment | octets. | 278 | | | 279 | Interest | An octet string that identifies the payload carried | 280 | Payload ID | in an Interest. As an example, the Payload ID | 281 | | might be a hash of the Interest Payload. This | 282 | | provides a way to differentiate between Interests | 283 | | based on the Payload solely through a Name Segment | 284 | | without having to include all the extra bytes of | 285 | | the payload itself. | 286 | | | 287 | Application | An application-specific payload in a name segment. | 288 | Components | An application may apply its own semantics to these | 289 | | components. A good practice is to identify the | 290 | | application in a Name segment prior to the | 291 | | application component segments. | 292 +-------------+-----------------------------------------------------+ 294 Table 1: CCNx Name Segment Types 296 At the lowest level, a Forwarder does not need to understand the 297 semantics of name segments; it need only identify name segment 298 boundaries and be able to compare two name segments (both label and 299 value) for equality. The Forwarder matches paths segment-by-segment 300 against its forwarding table to determine a next hop. 302 4. Interests 304 An Interest is composed of the tuple {Name, Metadata, Payload, 305 Validator}. These fields are defined below. Only the Name is 306 mandatory. Other fields, if missing, should be interpreted as "do 307 not care". 309 Name is a hierarchical path that identifies the resource. It is 310 matched as described above. 312 An Interest may also have a Payload which carries state about the 313 Interest but is not used to match a Content Object. If an Interest 314 contains a payload, the Interest name should contain an Interest 315 Payload ID (IPID). The IPID allows a PIT table entry to correctly 316 multiplex Content Objects in response to a specific Interest with a 317 specific payload ID. The IPID could be derived from a hash of the 318 payload or could be a GUID or a nonce. An optional Metadata field 319 defines the IPID field so other systems could verify the IPID, such 320 as when it is derived from a hash of the payload. No system is 321 required to verify the IPID. 323 An Interest may contain Validation fields including a 324 ValidationAlgorithm section describing the type of validator to use 325 and the ValidationPayload fields containig the output of the 326 validation. Typically this would only be a MIC - a crc, checksum, or 327 digest. 329 An Interest contains additional fields with information about the 330 query. Two fields - the KeyIdRestriction and 331 ContentObjectHashRestriction - serve as selectors to help identify 332 the specific Content Object that should be returned. 334 The Interest Lifetime element specifies the maximum number of 335 milliseconds a Forwarder should retain the Interest in its PIT. A 336 lifetime of "0" means the requester does not expect a response from 337 the Interest - it serves as a type of notification. The lifetime is 338 only a guideline for a Forwarder, which may keep an Interest for a 339 shorter or longer time, based on local conditions and system policy. 340 It may change hop to hop if the Interest is delayed for any 341 signifiant amount of time. It is measured in millisecond resolution, 342 so in fast switching it normally would not need to change. This 343 field does not affect the matching of Content Objects. 345 The Interest HopLimit element is a counter that is decremented with 346 each hop. It limits the distance an Interest may travel. The node 347 originating the Interest may put in any value - up to the maximum - 348 in network byte order. Each node that receives an Interest with a 349 HopLimit decrements the value upon reception. If the value is 0 350 after the decrement, the Interest cannot be forwarded off the node. 351 The PIT entry should also track the maximum HopLimit forwarded. If 352 an Interest with a longer HopLimit arrives, it should be forwarded 353 even if it is identical to a previously forwarded Interest. 355 Other implementations may define additional optional headers, for 356 example Nonces for loop detection, headers for Differentiated 357 Services Code Points (DSCP), or Flow Labels. 359 5. Content Objects 361 A Content Object is composed of the same tuple as an Interest: {Name, 362 Metadata, Payload, Validator}. 364 The Name is a mandatory field that identifies the contents. 366 The Payload of a Content Object holds the upper layer payload. It 367 may be encrypted, based on outside information or a protocol 368 information header. 370 The optional Metadata PayloadType field identifies the type of 371 Content Object: "DATA" implies an opaque payload; "LINK" is a Content 372 Object with an encoded Link as a payload. "DATA" is the default. 374 The optional field ExpiryTime is a millisecond timestamp containing 375 the number of milliseconds since the epoch in UTC of when the 376 contents will expire. If it is not present, there is no expiration 377 on the Content Object. The ExpiryTime should be part of the signed 378 information covered by the Validator, if present. 380 A publisher or upstream node may include a Recommended Cache Time for 381 Content Objects. It is represented as the number of milliseconds 382 since the epoch in UTC as the desired minimum time to keep the 383 content object in cache. This recommendation is a guideline as to 384 the useful lifetime of a Content Object, but may be ignored. The 385 RecommendedCacheTime should not be covered by the Validator, if 386 present, as nodes may change the value based on their caching. The 387 ExpiryTime takes precedence over the RecommendedCacheTime, if both 388 exist. 390 Other protocols, such as versioning or chunking, could place other 391 kinds of metadata in the Content Object. 393 6. Link 395 A Link is the tuple {Name, KeyId, ContentObjectHash}. The 396 information in a Link comprises the fields the fields of an Interest 397 which would retrieve the Link target. A Content Object with 398 PayloadType = "Link" is an object whose payload is a Link. This 399 tuple may be used as a KeyName to identify a specific object with the 400 certificate wrapped key. 402 7. Validation 404 7.1. Validation Algorithm 406 The Validator consists of a ValidationAlgorithm that specifies how to 407 verify the message and a ValidationPayload containing the validation 408 output. The ValidationAlgorithm section defines the type of 409 algorithm to use and includes any necessary additional information. 410 The validation is calculated from the beginning of the CCNx Message 411 through the end of the ValidationAlgorithm section. The 412 ValidationPayload is the actual cryptographic bytes, such as a CRC 413 value or an HMAC value or a signature value. 415 Some Validators contain a KeyId, identifying the publisher 416 authenticating the Content Object. If an Interest carries a 417 KeyIdRestriction, then that KeyIdRestriction MUST exactly match the 418 Content Object's KeyId. 420 Validation Algorithms fall into three categories: MICs, MACs, and 421 Signatures. Validators using MIC algorithms do not need to provide 422 any additional information; they may be computed and verified based 423 only on the algoritm (e.g. CRC32C). MAC validators require the use 424 of a KeyId identifying the secret key used by the authenticator. 425 Because MACs are usually used between two parties that have already 426 exchanged secret keys via a key exchange protocol, the KeyId may be 427 any agreed-upon value to identify which key is used. Signature 428 validators use public key cryptography such as RSA, DSA, or 429 Elliptical Curve (EC). The KeyId field in the ValidationAlgorithm 430 identifies the public key used to verify the signature. A signature 431 may optionally include a KeyLocator, as described above, to bundle a 432 Key or Certificate or KeyName. MAC and Signature validators may also 433 include a SignatureTime, as described above. 435 A PublicKeyLocator KeyName points to a Content Object with an X509 436 certificate in the payload. In this case, the target KeyId must 437 equal the first object's KeyId. The target KeyLocator must include 438 the public key corresponding to the KeyId. That key must validate 439 the target Signature. The payload is an X.509 certificate whose 440 public key must match the target KeyLocator's key. It must be issued 441 by a trusted authority, preferably specifying the valid namespace of 442 the key in the distinguished name. 444 8. Interest to Content Object matching 446 A Content Object satisfies an Interest if and only if (a) the Content 447 Object name exactly matches the Interest name, and (b) the 448 ValidationAlgorithm KeyId of the Content Object exactly equals the 449 Interest KeyIdRestriction, if given, and (c) the computed 450 ContentObjectHash exactly equals the Interest 451 ContentObjectHashRestriction, if given. A Content Object does not 452 carry the ContentObjectHash as an expressed field, it must be 453 calculated in network to match against. It is sufficient within an 454 autonomous system to calculate a ContentObjectHash at a border router 455 and carry it via trusted means within the autonomous system. If a 456 Content Object ValidationAlgorithm does not have a KeyId then the 457 Content Object cannot match an Interest with a KeyIdRestriction. 459 9. Request/Response Protocol 461 As an Interest moves through the network following the FIB table 462 based on longest matching prefix, it leaves state at each forwarding 463 node. The state is represented in a notional Pending Interest Table 464 (PIT). The PIT tracks the Name, KeyIdRestriction, and 465 ContentObjectHashRestriction to be matched by a Content Object. If a 466 second Interest arrives with the same Name and selector values, it 467 may be aggregated with the existing pending Interest. If the second 468 Interest extends the Lifetime of the pending Interest, it should be 469 forwarded to extend the life of downstream Interests. 471 When a Content Object arrives at a Forwarder, it is matched against 472 the Interests in the PIT. For each matching Interest, the Content 473 Object is forwarded along the reverse path of that PIT entry and the 474 PIT entry is removed. 476 A Content Object that does not match any Interest in the PIT is 477 dropped. 479 A Forwarder may implement a Content Object cache called a Content 480 Store. At the core protocol level, the Content Store must obey 481 similar rules as the Forwarder. If an Interest specifies a 482 ContentObjectHashRestriction, the Content Store SHOULD NOT respond 483 unless it has verified the hash of the Content Object. If the 484 Interest carries a KeyIdRestriction then the Content Store MUST 485 cryptographically verify the signature or not respond. 487 TODO: Specify what to do in case of failure. 489 10. Interest Return 491 This section describes the process whereby a network element may 492 return an Interest message to a previous hop if there is an error 493 processing the Interest. The returned Interest may be further 494 processed at the previous hop or returned towards the Interest 495 origin. When a node returns an Interest it indicates that the 496 previous hop should not expect a response from that node for the 497 Interest -- i.e. there is no PIT entry left at the returning node. 499 The returned message maintains compatibility with the existing TLV 500 packet format (a fixed header, optional hop-by-hop headers, and the 501 CCNx message body). The returned Interest packet is modified in only 502 two ways: 504 o The PacketType is set to InterestReturn to indicate a Feedback 505 message. 507 o The ReturnCode is set to the appropriate value to signal the 508 reason for the return 510 The specific encodings of the Interest Return are specified in 511 [CCNMessages]. 513 A Forwarder is not required to send any Interest Return messages. 515 A Forwarder is not required to process any received Interest Return 516 message. If a Forwarder does not process Interest Return messages, 517 it should silently drop them. 519 The Interest Return message does not apply to a Content Object or any 520 other message type. 522 An Interest Return message is a 1-hop message between peers. It is 523 not propagated multiple hops via the FIB. An intermedate node that 524 receives an InterestReturn may take corrective actions or may 525 propagage its own InterestReturn to previous hops as indicated in the 526 reverse path of a PIT entry. 528 10.1. Message Format 530 The Interest Return message looks exactly like the original Interest 531 message with the exception of the two modifications mentioned above. 532 The PacketType is set to indicate the message is an InterestReturn 533 and the reserved byte in the Interest header is used as a Return 534 Code. The numeric values for the PacketType and ReturnCodes are in 535 [CCNMessages]. 537 10.2. ReturnCode Types 539 This section defines the InterestReturn ReturnCode introduced in this 540 RFC. The numeric values used in the packet are defined in 541 [CCNMessages]. 543 +---------------------+---------------------------------------------+ 544 | Name | Description | 545 +---------------------+---------------------------------------------+ 546 | No Route | The returning Forwarder has no route to the | 547 | (Section 10.3.1) | Interest name. | 548 | | | 549 | HopLimit Exceeded | The HopLimit has decremented to 0 and need | 550 | (Section 10.3.2) | to forward the packet. | 551 | | | 552 | Interest MTU too | The Interest's MTU does not conform to the | 553 | large | required minimum and would require | 554 | (Section 10.3.3) | fragmentation. | 555 | | | 556 | No Resources | The node does not have the resources to | 557 | (Section 10.3.4) | process the Interest. | 558 | | | 559 | Path error | There was a transmission error when | 560 | (Section 10.3.5) | forwarding the Interest along a route (a | 561 | | transient error). | 562 | | | 563 | Prohibited | An administrative setting prohibits | 564 | (Section 10.3.6) | processing this Interest. | 565 | | | 566 | Congestion | The Interest was dropped due to congestion | 567 | (Section 10.3.7) | (a transient error). | 568 +---------------------+---------------------------------------------+ 570 Table 2: Interest Return Reason Codes 572 10.3. Interest Return Protocol 574 This section describes the Forwarder behavior for the various Reason 575 codes for Interest Return. A Forwarder is not required to generate 576 any of the codes, but if it does, it must conform to this 577 specification. 579 If a Forwarder receives an Interest Return, it SHOULD take these 580 standard corrective actions. A forwarder is allowed to ignore 581 Interest Return messages, in which case its PIT entry would go 582 through normal timeout processes. 584 o Verify that the Interest Return came from a next-hop to which it 585 actually sent the Interest. 587 o If a PIT entry for the corresponding Interest does not exist, the 588 Forwarder should ignore the Interest Return. 590 o If a PIT entry for the corresponding Interest does exist, the 591 Forwarder MAY do one of the following: 593 * Try a different forwarding path, if one exists, and discard the 594 Interest Return, or 596 * Clear the PIT state and send an Interest Return along the 597 reverse path. 599 If a forwarder tries alternate routes, it MUST ensure that it does 600 not use same same path multiple times. For example, it could keep 601 track of which next hops it has tried and not re-use them. 603 If a forwarder tries an alternate route, it may receive a second 604 InterestReturn, possibly of a different type than the first 605 InterestReturn. For example, node A sends an Interest to node B, 606 which sends a No Route return. Node A then tries node C, which sends 607 a Prohibited. Node A should choose what it thinks is the appropriate 608 code to send back to its previous hop 610 If a forwarder tries an alternate route, it should decrement the 611 Interest Lifetime to account for the time spent thus far processing 612 the Interest. 614 10.3.1. No Route 616 If a Forwarder receives an Interest for which it has no route, or for 617 which the only route is back towards the system that sent the 618 Interest, the Forwarder SHOULD generate a "No Route" Interest Return 619 message. 621 How a forwarder manages the FIB table when it receives a No Route 622 message is implementation dependent. In general, receiving a No 623 Route Interest Return should not cause a forwarder to remove a route. 624 The dynamic routing protocol that installed the route should correct 625 the route or the administrator who created a static route should 626 correct the configuration. A forwarder could suppress using that 627 next hop for some period of time. 629 10.3.2. HopLimit Exceeded 631 A Forwarder MAY choose to send HopLimit Exceeded messages when it 632 receives an Interest that must be forwarded off system and the 633 HopLimit is 0. 635 10.3.3. Interest MTU Too Large 637 If a Forwarder receives an Interest whose MTU exceeds the prescribed 638 minimum, it MAY send an "Interest MTU Too Large" message, or it may 639 silently discard the Interest. 641 If a Forwarder receives an "Interest MTU Too Large" is SHOULD NOT try 642 alternate paths. It SHOULD propagate the Interest Return to its 643 previous hops. 645 10.3.4. No Resources 647 If a Forwarder receives an Interest and it cannot process the 648 Interest due to lack of resources, it MAY send an InterestReturn. A 649 lack of resources could be the PIT table is too large, or some other 650 capacity limit. 652 10.3.5. Path Error 654 If a forwarder detects an error forwarding an Interest, such as over 655 a reliable link, it MAY send a Path Error Interest Return indicating 656 that it was not able to send or repair a forwarding error. 658 10.3.6. Prohibited 660 A forwarder may have administrative policies, such as access control 661 lists, that prohibit receiving or forwarding an Interest. If a 662 forwarder discards an Interest due to a policy, it MAY send a 663 Prohibited InterestReturn to the previous hop. For example, if there 664 is an ACL that says /parc/private can only come from interface e0, 665 but the Forwarder receives one from e1, teh Forwarder must have a way 666 to return the Interet with an explanation. 668 10.3.7. Congestion 670 If a forwarder discards an Interest due to congestion, it MAY send a 671 Congestion InterestReturn to the previous hop. 673 11. Acknowledgements 674 12. IANA Considerations 676 This memo includes no request to IANA. 678 All drafts are required to have an IANA considerations section (see 679 Guidelines for Writing an IANA Considerations Section in RFCs 680 [RFC5226] for a guide). If the draft does not require IANA to do 681 anything, the section contains an explicit statement that this is the 682 case (as above). If there are no requirements for IANA, the section 683 will be removed during conversion into an RFC by the RFC Editor. 685 13. Security Considerations 687 The Interest Return message has no authenticator from the previous 688 hop. Therefore, the payload of the Interest Return should only be 689 used locally to match an Interest. A node should never forward that 690 Interest payload as an Interest. It should also verify that it send 691 the Interest in the Interest Return to that node and not allow anyone 692 to negate Interest messages. 694 If two peers require authenticated messaging, they must use an 695 external mechanism. 697 14. References 699 14.1. Normative References 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, March 1997. 704 14.2. Informative References 706 [CCN] PARC, Inc., "CCNx Open Source", 2007, 707 . 709 [CCNMessages] 710 Mosko, M., Solis, I., and M. Stapp, "CCNx Messages in TLV 711 Format (Internet draft)", 2015, . 714 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 715 Text on Security Considerations", BCP 72, RFC 3552, 716 July 2003. 718 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 719 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 720 May 2008. 722 Authors' Addresses 724 Marc Mosko 725 PARC, Inc. 726 Palo Alto, California 94304 727 USA 729 Phone: +01 650-812-4405 730 Email: marc.mosko@parc.com 732 Ignacio Solis 733 PARC, Inc. 734 Palo Alto, California 94304 735 USA 737 Phone: +01 650-812-4405 738 Email: marc.mosko@parc.com