idnits 2.17.1 draft-mosko-icnrg-selectors-00.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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (August 1, 2016) is 2818 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'CCNx' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 510, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-03 -- Unexpected draft version: The latest known version of draft-mosko-icnrg-ccnxsemantics is -01, but you're referring to -03. -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG M. Mosko 3 Internet-Draft PARC, Inc. 4 Intended status: Experimental August 1, 2016 5 Expires: February 2, 2017 7 CCNx Selector Based Discovery 8 draft-mosko-icnrg-selectors-00 10 Abstract 12 CCNx selector based discovery uses exclusions and interest name 13 suffix matching to discover content in the network. Participating 14 nodes may respond with matching Content Objects from cache using an 15 encapsulation protocol. This document specifies the available 16 selectors, their encoding in a name path segment, and the 17 encapsulation protocol. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 2, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Protocol Description . . . . . . . . . . . . . . . . . . . . 3 56 3. Name Labels and TLV types . . . . . . . . . . . . . . . . . . 5 57 3.1. Child Selector . . . . . . . . . . . . . . . . . . . . . 7 58 3.2. Interest Min(Max)SuffixComponents . . . . . . . . . . . . 7 59 3.3. Name Excludes . . . . . . . . . . . . . . . . . . . . . . 7 60 3.3.1. Exclude Singleton . . . . . . . . . . . . . . . . . . 8 61 3.3.2. Exclude Range . . . . . . . . . . . . . . . . . . . . 9 62 3.3.3. Examples . . . . . . . . . . . . . . . . . . . . . . 9 63 4. Content Store and Caching . . . . . . . . . . . . . . . . . . 10 64 5. Annex A: Examples . . . . . . . . . . . . . . . . . . . . . . 11 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 8.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 Content Discovery is an important feature of CCNx. This document 75 specifies a discovery mechanism that uses a name path segment to 76 encode a discovery query in an Interest. Participating nodes may 77 reply with a Content Object if it matches the encoded query. The 78 query uses exclusions to work around incorrect responses. 80 This document specifies a new name TLV type, T_SELECTOR, for selector 81 query. It also specifies a new Content Object PayloadType that 82 encapsulates another Content Object. The inner Content Object is 83 used to return a Content Object with a longer name than in an 84 interest. The inner object's signature should verify. 86 Not all nodes along the Interest path need to participate in the 87 discovery process. A non-participating node should forward the 88 Interest and encapsulating Content Object as normal per 89 [CCNSemantics]. A participating node should verify that the inner 90 Content Object matches the selector query in the PIT entry. 92 Note that Selector discovery is not needed when asking for a Content 93 Object by its ContentObjectHash, as there should only ever be one 94 match for that. 96 Selector discovery in CCNx 1.0 differs in three ways from the current 97 NDN and prior CCNx 0.x selector discovery. First, CCNx 1.0 uses a 98 distinguished field for the ContentObjectHashRestriction. It is not 99 appended to the name to form the so-called "full name." This means 100 that there is no implicit digest name segment. Thus, using a 101 MinSuffixComponents and MaxSuffixComponents of 0 will match the exact 102 name in the Interest without needing to add one extra component to 103 account for the implicit digest. Second, there is a HashExcludes 104 field that lists ContentObjectHashRestrictions to exclude instead of 105 appending them as an implicit name component. Third, the encoding of 106 Excludes differs from prior encodings and uses a simpler formulation 107 with the same expressiveness that also takes in to consideration that 108 name segments in CCNx 1.0 have TLV types associated with them. 110 CCNx 1.0 allows Content Objects to have no name and be retrieved by 111 hash only. As they have no name, they are not discoverable via name- 112 based selector discovery. 114 Packets are represented as 32-bit wide words using ASCII art. 115 Because of the TLV encoding and optional fields or sizes, there is no 116 concise way to represent all possibilities. We use the convention 117 that ASCII art fields enclosed by vertical bars "|" represent exact 118 bit widths. Fields with a forward slash "/" are variable bitwidths, 119 which we typically pad out to word alignment for picture readability. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 2. Protocol Description 129 Selector based discovery uses six query variables to discover 130 content. These selectors are encoded as a single name path segment 131 affixed to an Interest name. The selectors operate on the prefix up 132 to, but not including the selector name path segment. The selector 133 name path segment should be the last path segment. 135 The selectors are: 137 o MinSuffixComponents: the minimum number of additional name path 138 segments a matching Content Object must have in its name. The 139 default value is 0. 141 o MaxSuffixComponents: The maximum number of additional name path 142 segments a matching Content Object may have in its name. The 143 default value is unlimited. 145 o ChildSelector: Answer with the left-most or right-most child. 147 o NameExcludes: A set of range and singleton exclusions to eliminate 148 Content Objects. The exclusions match against the name path 149 segment that would immediately follow the Interest name prefix up 150 to but not including the Selector path segment. 152 o InnerKeyId: Matches the KeyId of the encapsulated object. 154 o HashExcludes: A list of ContentObjectHashRestrictions to exclude. 156 A node using Selector discovery appends a Selector name path segment 157 to the end of the Interest name. Even if no selectors are used, the 158 Selector path segment is added to the end, which indicates to a 159 participating node that it should apply Selector based matching to 160 the Interest. In this case, the default values -- if any -- of each 161 selector are used. 163 A node receiving a Selector Interest should match against the Content 164 Store using the selector rules. Based on the sort order, it should 165 pick the appropriate Content Object, if any, and return it in an 166 Encapsulation Object. If no Content Objects match, the Interest 167 should be forwarded or NACKed as normal. 169 An Encapsulation Object is a Content Object that matches the Selector 170 Interest and whose payload is the discovered Content Object. The 171 ContentType of an Encapsulation Object is "ENCAP". The outer name 172 matches the Selector Interest name. The inner Content Object name 173 matches the Selector discovery. 175 The KeyIdRestriction of the Interest matches the outer KeyId of the 176 outer Content Object, as normal. This allows a responding cache or 177 producer to sign (or MAC or MIC) the response. The InnerKeyId of the 178 Selector matches the inner ContentObject in the same way. This 179 allows the selector to discriminate discovery including the inner 180 KeyId. 182 The HashExcludes eliminate any Content Objects whose 183 ContentObjectHash matches any of the listed values. It should not 184 matter if matching objects are discarded before name prefix selector 185 matching or after. A Content Object must always pass both the 186 HashExcludes filter and the name prefix selector filters, wether it 187 is done first or last does not matter. HashExcludes are encoded the 188 same way as a ContentObjectHashRestriction value in an Interest. 189 Note that this Selector does not exist in NDN or CCNx 0.x. We use an 190 explicit set of HashExcludes rather than constructing a full name 191 with the implicit digest component at the end. 193 If an authoritative producer receives a Selector discovery, it SHOULD 194 generate the inner Content Object as normal and encapsulate it as 195 normal. It MAY also respond with an Interest Return or not respond 196 at all. At the present, responding directly to the Selector Interest 197 with data without encapsulating it is not supported. Note that an 198 application is NOT REQUIRED to implement Selector discovery; if the 199 application wishes to make use of this mechanism, then it must 200 implement it, if it does not use this mechanism then it does not need 201 to implement it. 203 Normally, the outer Content Object does not have a Validation 204 section. A responding node MAY include a CRC32C or other integrity 205 check. Signing or MACing an outer Content Object is possible, but 206 should only be used in environments where that degree of trust is 207 necessary. Signing the outer Content Object in no way replaces the 208 signature (if any) of the inner Content Object. The outer signature 209 only identifies the responding cache (or producer). 211 3. Name Labels and TLV types 213 The Selector name segment type T_SELECTOR has type %x0010. 215 The PayloadType of T_PAYLOADTYPE_ENCAP has the value 8. 217 +------+-----------------+------------+-----------------------------+ 218 | Type | Symbol | Name | Description | 219 +------+-----------------+------------+-----------------------------+ 220 | 1 | T_MINSUFFIX | Selectors: | Minimum number of | 221 | | | Min Suffix | additional name components | 222 | | | Components | after given name to match | 223 | | | | (0 default if missing). | 224 | | | | | 225 | 2 | T_MAXSUFFIX | Selectors: | Maximum number of | 226 | | | Max Suffix | additional name components | 227 | | | Components | after given name to match | 228 | | | | (unlimited default is | 229 | | | | missing). | 230 | | | | | 231 | 3 | T_CHILD | Selectors: | 0 = left, 1 = right | 232 | | | Child | (default) | 233 | | | Selector | | 234 | | | | | 235 | 4 | T_NAME_EXCLUDES | Name | Encloses ExcludeComponents | 236 | | | Excludes | | 237 | | | | | 238 | 1 | T_EX_SINGLE | Exclude | Exclude a single name path | 239 | | | Singleton | segment. | 240 | | | | | 241 | 2 | T_EX_RANGE | Exclude | Exclude an half-open range, | 242 | | | Range | beginning at this value and | 243 | | | | continuing up to the next | 244 | | | | Singleton, or to infinity | 245 | | | | if omitted on the last | 246 | | | | entry. | 247 | | | | | 248 | 5 | T_INNER_KEYID | Inner | A restriction on the inner | 249 | | | KeyId | keyid. If present, it must | 250 | | | | match the KeyId of the | 251 | | | | inner Content Object in the | 252 | | | | encapsulated response. | 253 | | | | | 254 | 6 | T_HASH_EXCLUDES | Hash | Excludes a set of | 255 | | | Excludes | ContentObjectHash from the | 256 | | | | allowed responses. Each | 257 | | | | restriction is encoded | 258 | | | | using its Hash Function | 259 | | | | Type Registry type (e.g. | 260 | | | | T_SHA-256) from | 261 | | | | [CCNMessages]. | 262 +------+-----------------+------------+-----------------------------+ 264 Table 1: Selector Types 266 3.1. Child Selector 268 If there are multiple choices to answer an Interest, the Child 269 Selector specifies the desired ordering of responses. %x00 = 270 leftmost, %x01 = rightmost. 272 1 2 3 273 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 274 +---------------+---------------+---------------+ 275 | T_CHILD | 1 | selector | 276 +---------------+---------------+---------------+ 278 3.2. Interest Min(Max)SuffixComponents 280 The Min and Max suffix components are encoded as a minimum-length 281 unsigned integer in network byte order number inside the value. A 282 "0" is represented as a single byte %0x00. A length 0 value is 283 interpreted the same as the type not being present. 285 1 2 3 286 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 287 +---------------+---------------+---------------+---------------+ 288 | type | length | / 289 +---------------+---------------+ / 290 / Min(Max)SuffixComponents / 291 +---------------+---------------+---------------+---------------+ 292 type = T_MINSUFFIX or T_MAXSUFFIX 294 3.3. Name Excludes 296 Interest Excludes specify a set of singletons and ranges to exclude 297 when matching Content Object names to an Interest. They match the 298 name component immediately following the last component of the 299 Interest name (not including the Selector TLV). The excludes must be 300 sorted in ascending order, using the normal Name sorting rules. 302 A name exclusion is the full TLV expression of a name component, not 303 just it's value. 305 An exclusion value A is less than B iff the TLV type of A is less 306 than the TLV type of B, or being equal, the TLV value of A is 307 shortlex less than the TLV value of B. A shortlex comparison means 308 that X is less than Y is X is shorter than Y or the lengths being 309 equal, X lexicagraphically sorts before Y. 311 A zero-length exclusion is the minimum exclusion and must appear 312 before any other exclusion. Note that a zero-length exlcusion has no 313 TLV type for the name component, so it will match any name segment 314 TLV type. It is equivalent to minus infinity. 316 The zero-length name component is the minimum name component of that 317 name component type (e.g.T_NAMESEGMENT). 319 An exclude may contain either an Exclude Range type or an Exclude 320 Singleton type. An Exclude Range type means the given value starts a 321 half-open exclusion range that begins inclusive of the Range value 322 and ends open at the next Singleton or at infinity if it is the last 323 exclude component. An Exclude Singleton means to exclude the exact 324 value given. 326 Note that this syntax does not require the "ANY" exclude component 327 that is part of the NDN and CCNx 0.x syntax. 329 1 2 3 330 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 331 +---------------+---------------+---------------+---------------+ 332 | T_EXCLUDES | length | 333 +---------------+---------------+---------------+---------------+ 334 / Zero or more exclude-components / 335 +---------------------------------------------------------------+ 337 exclude-components = *component [start-range-tlv] 338 component = (start-range-tlv singleton-tlv) / singleton-tlv 340 The ABNF of the exclude-component allows for zero or more components 341 followed by an option start-range-tlv. A component is either a half- 342 open range (start-range-tlv singleton-tlv) or a singleton-tlv. 344 The optional final start-range-tlv has no terminating singleton-tlv. 345 This means it extends out to plus infinity. 347 Note that to exclude from negative infinity to some value "foo", we 348 do not need to include an ANY element because the zero-length name 349 component is, by definition, the minimum element and we use inclusive 350 range start. Therefore, begining an exlcusion with the zero-length 351 range effectively excludes from minus infinity. 353 3.3.1. Exclude Singleton 355 A singleton exclude component means to exclude a name path segment 356 exactly matching the given value. 358 1 2 3 359 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 360 +---------------+---------------+---------------+---------------+ 361 | T_EX_SINGLE | length | 362 +---------------+---------------+---------------+---------------+ 363 / TLV name segment / 364 +---------------+---------------+---------------+---------------+ 366 3.3.2. Exclude Range 368 A Range exclude means to exclude the from the given value up to but 369 not including the next Singleton. If the Range is the last component 370 in the Exclude, it means to exclude to infinity. 372 1 2 3 373 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 374 +---------------+---------------+---------------+---------------+ 375 | T_EX_RANGE | length | 376 +---------------+---------------+---------------+---------------+ 377 / TLV name segment / 378 +---------------+---------------+---------------+---------------+ 380 3.3.3. Examples 382 In these examples, we will use the notation S[foo] to represent a 383 singleton exclusion "foo" and R[foo] to represent a range exclusion 384 beginning at "foo." In the column Range, we use standard open 385 (parenthesis) and closed (square bracket) interval notation. We 386 assume all TLV name types of T_NAMESEGMENT if there is no explicit 387 name segment type given. In our notation, something like S[VER=bar] 388 would exclude a TLV type Version and value "bar". 390 +---------------+---------------------------------------------------+ 391 | Exclude | Range | 392 | Pattern | | 393 +---------------+---------------------------------------------------+ 394 | S[ace] | NAME=ace | 395 | | | 396 | S[ace] R[bat] | NAME=ace, [NAME=bat, infty) | 397 | | | 398 | R[ace] S[bat] | [NAME=ace, NAME=bat) | 399 | | | 400 | R[CHUNK=0] | [CHUNK=0, CHUNK=20) | 401 | S[CHUNK=20] | | 402 | | | 403 | R[] S[ace] | (-infty, NAME=ace), matches any preceeding TLV | 404 | | types using a zero-length Range exclude | 405 | | | 406 | R[NAME=] | [NAME=, NAME=ace) | 407 | S[ace] | | 408 | | | 409 | R[] | (-infty, +infty) | 410 | | | 411 | S[zoo] S[ape] | Invalid range, not sorted | 412 | | | 413 | R[NAME=ace] | [NAME=ace, CHUNK=0), this will span TLV ranges | 414 | S[CHUNK=0] | type between T_NAMESEGMENT and T_CHUNK | 415 | | | 416 | R[CHUNK=] | [CHUNK=, CHUNK+1=), excludes all CHUNK TLV | 417 | S[CHUNK+1=] | possibilities | 418 +---------------+---------------------------------------------------+ 420 Table 2: CCNx Name Types 422 4. Content Store and Caching 424 The encapsulated responses to discovery are cachable, like all 425 Content Objects. A participating forwarder MAY cache the inner 426 Content Object separately from the outer Content Object assuming it 427 passes the selector tests. A non-participating forwarder MAY only 428 cache the outer Content Object (encapsulating the inner). 430 A participating content store MUST obey both the outer and inner 431 cache control directives: ExpiryTime and RecommendedCacheTime. Thus, 432 a responding cache can reduce or prevent the response being cached by 433 setting a short or zero ExpiryTime independently of the caching 434 behavior of the encapsulated inner Content Object. 436 A non-participating content store MUST objey the outer cache control 437 directives, as normal. The inner content object is opaque data to 438 it. 440 It is RECOMMENDED that a participating node creating the encapsulated 441 response set a short RecommendedCacheTime and MAY set an ExpirtyTime. 443 Note that cached respones are, in general, not a problem for the 444 discovery process. Participating nodes will always do a full 445 selector match, so a consumer can work around incorrect responses as 446 normal. Because Selector interests with differnent Exclude blocks 447 will result in different names, prior responses will not match in the 448 caches of non-participating nodes, esepcially if the 449 RecommendedCacheTime (or ExpireTime) is set to 0. 451 5. Annex A: Examples 453 TODO: Provide complete examples of Interests and responses. 455 6. IANA Considerations 457 This memo includes no request to IANA. TODO: If this document is 458 submitted as an official draft, this section must be updated to 459 reflect the IANA registries described in [CCNMessages] 461 7. Security Considerations 463 Because respones use encapsulation, there is size expansion in the 464 response from the original Content Object. The expansion will be the 465 length of the encapsulating Selector name plus the size of any 466 validation uses on the outer Content Object (e.g. a CRC32C), plus 467 framing overhead. This means that one cannot respond with a Content 468 Object that is too close to the maximum packet size. 470 Participating nodes should be able to filter incorrect responses just 471 as they do in NDN or CCNx 0.x. If all node participate, then one has 472 equivalent in-network filtering behavior as those other protocols. 474 If the outer Content Object is signed, the consumer should, as 475 normal, verify the signature for accuracy. However, the trust of the 476 outer signature is normally not important and usually reflects 477 operation in a specific environment. An outer Validation section is 478 usually used only for integrity checks. 480 8. References 482 8.1. Normative References 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 8.2. Informative References 491 [CCNMessages] 492 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 493 Format (Internet draft)", 2016, 494 . 497 [CCNSemantics] 498 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics 499 (Internet draft)", 2016, . 502 [CCNx] PARC, Inc., "CCNx Open Source", 2007, 503 . 505 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 506 Text on Security Considerations", BCP 72, RFC 3552, 507 DOI 10.17487/RFC3552, July 2003, 508 . 510 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 511 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 512 DOI 10.17487/RFC5226, May 2008, 513 . 515 Author's Address 517 Marc Mosko 518 PARC, Inc. 519 Palo Alto, California 94304 520 USA 522 Phone: +01 650-812-4405 523 Email: marc.mosko@parc.com