idnits 2.17.1 draft-irtf-icnrg-terminology-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 24, 2017) is 2277 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.irtf-icnrg-ccnxmessages' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-ccnxsemantics' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-disaster' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC7476' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC7927' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'RFC7933' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'RFC7945' is defined on line 731, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-04 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-04 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-disaster-02 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 icnrg B. Wissingh 3 Internet-Draft TNO 4 Intended status: Informational C. Wood 5 Expires: June 27, 2018 University of California Irvine 6 A. Afanasyev 7 L. Zhang 8 UCLA 9 D. Oran 10 Network Systems Research & Design 11 C. Tschudin 12 University of Basel 13 December 24, 2017 15 Information-Centric Networking (ICN): CCN and NDN Terminology 16 draft-irtf-icnrg-terminology-00 18 Abstract 20 Information Centric Networking (ICN) is a new paradigm where network 21 communications are accomplished by requesting named content, instead 22 of sending packets to destination addresses. Named Data Networking 23 (NDN) and Content-Centric Networking (CCN) are two prominent ICN 24 architectures. This document provides an overview of the terminology 25 and definitions that have been used in describing concepts in these 26 two projects. While there are other ICN architectures, they are not 27 part of the NDN and CCN vision and as such are out of scope for this 28 document. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 27, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. A Sketch of the Big Picture of ICN . . . . . . . . . . . . . 3 66 3. Terms by category . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Generic terms . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Terms related to ICN Nodes . . . . . . . . . . . . . . . 6 69 3.3. Terms related to the Forwarding plane . . . . . . . . . . 7 70 3.4. Terms related to Packet Types . . . . . . . . . . . . . . 9 71 3.5. Terms related to Name Types . . . . . . . . . . . . . . . 11 72 3.6. Terms related to Name Usage . . . . . . . . . . . . . . . 12 73 3.7. Terms related to Data-Centric Security . . . . . . . . . 13 74 3.8. Uncategorized terms . . . . . . . . . . . . . . . . . . . 14 75 4. Semantics and Usage . . . . . . . . . . . . . . . . . . . . . 15 76 4.1. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 15 77 4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 15 78 4.3. Lookup Service . . . . . . . . . . . . . . . . . . . . . 15 79 4.4. Database Access . . . . . . . . . . . . . . . . . . . . . 15 80 4.5. Remote Procedure Call . . . . . . . . . . . . . . . . . . 15 81 5. Informational References . . . . . . . . . . . . . . . . . . 16 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 Information-centric networking (ICN) is an approach to evolve the 88 Internet infrastructure from the existing host-centric design to a 89 data-centric architecture, where accessing data by name becomes the 90 essential network primitive. The goal is to let applications refer 91 to data independently of their location or means of transportation, 92 which enables native multicast delivery, ubiquitous in-network 93 caching and replication of data objects. 95 As the work on this topic continues to evolve, many new terms are 96 emerging over time. The goal of this document is to provide a 97 thorough collection of these terms with a corresponding definition as 98 they are used in the CCNx and NDN projects. Other ICN projects such 99 as NetInf, or MobilityFirst are not covered and will be the subject 100 of other documents. 102 To help provide context for the individual terms to be defined, in 103 this draft we first sketch the bigger picture of an ICN network by 104 introducing the basic concepts and identifying the major components 105 of the architecture in Section 2, after which in Section 3 ICN 106 related terms are listed by different categories. 108 2. A Sketch of the Big Picture of ICN 110 In networking terms, an ICN is a delivery infrastructure for named 111 data. For other, complementing views see Section 4. 113 requestor zero or more data sources or 114 (node) forwarding nodes replica nodes 115 | | ... | |...| 116 | Interest(n) | | Interest(n) | | 117 | --------------> | | ---------------> | | 118 | | | -------------------> | 119 | | | | | 120 | | | Data([n],c,[s]) | | 121 | | | <--------------- | | 122 | | | <------------------- | 123 | Data([n],c,[s]) | | | | 124 | <-------------- | | | | 126 Figure 1: Request-Reply Protocol of ICN networking. Legend: n=name, 127 c=content, s=signature. 129 The following list describes the basic ICN concepts needed to discuss 130 the implementation of this service abstraction. 132 *Request-Reply Protocol (Interest and Data Packet)*: 134 An ICN's lookup service is implemented by defining two types of 135 network packet formats: Interest packets that request content by 136 name, and Data packets that carry the requested content. The 137 returned Data packet must match the request's parameters (e.g., 138 having a partially or fully matching name). If the request is 139 ambiguous and several Data packets would satisfy the request, the 140 ICN network returns only one matching Data packet (flow balance 141 between Interest and Data packets over individual links). 143 *Packet and Content Names* 145 Without an irrefutable binding between a name of a Data packet and 146 its content, Data packet names would be useless for fetching 147 specific content. In ICN, verification of a Data packet's name- 148 to-content binding is achieved through cryptographic means, either 149 by (1) a cryptographic signature that explicitly binds an 150 application-chosen name to a Data packet's content, or (2) relying 151 on an implicit name (cryptographic hash of the Data packet with or 152 without application-chosen name) that the data consumer obtained 153 through other means. 155 *Data Authenticity and Encryption*: 157 Any data consumer and network element can validate the 158 authenticity of a Data packet by verifying its cryptographic name- 159 to-content binding. In contrast, whether a Data packet's content 160 (payload) itself is encrypted or not is irrelevant to the ICN 161 network. The use and management of content encryption keys is an 162 application-layer concern. 164 *Trust*: 166 Data authenticity is distinct from data trustworthiness, though 167 the two concepts are related. A packet is authentic if it has a 168 valid name-to-content binding. A packet is trustworthy, i.e., it 169 comes from a reputable or trusted origin, if this binding is valid 170 in the context of a trust model. 172 *Segmenting and Versioning*: 174 An ICN network will be engineered for some packet size limit. As 175 application-level data objects will often be considerably larger, 176 objects must be segmented into multiple Data packets. The names 177 for these Data packets can, for example, be constructed by 178 choosing one application-level object name to which a different 179 suffix is added for each segment. The same method can be used to 180 handle different versions of an application-level object by 181 including a version number into the name of the overall object. 183 *Packet and Frame*: 185 NDN and CCNx introduce Protocol Data Units (PDUs) which typically 186 are larger than the maximum transmission unit of the underlying 187 networking technology. We refer to PDUs as 'packets' and the 188 (potentially fragmented) packet parts that traverse MTU-bound 189 links as 'frames'. Handling link-layer technologies which lead to 190 fragmentation of ICN packets is done inside the ICN network and is 191 not visible at the service interface. 193 *ICN Node*: 195 A node within an ICN network can fulfill the role of a data 196 producer, a data consumer, and/or a forwarder for Interest and 197 Data packets. When a forwarder has connectivity to neighbor 198 nodes, it performs Interest and Data packet forwarding in real 199 time. It can also behave like a packet mule, that is it may carry 200 an Interest or Data packet for some time before forwarding it to 201 next node. An ICN node may also run routing protocols to assist 202 its Interest forwarding decisions. 204 --> add ASCII art here 205 (of a forwarding node 206 and its PIT, FIB, CS) 208 Figure 2: Structure of an ICN forwarding node. 210 *Forwarding Plane*: 212 The canonical way of implementing packet forwarding in an ICN 213 network relies on three data structures that capture a node's 214 state: a Forwarding Interest Table (FIB), a Pending Interest 215 Table (PIT), and a Content Store (CS). It also utilizes Interest 216 forwarding strategies which takes input from both FIB and 217 measurements to make Interest forwarding decisions. When a node 218 receives an Interest packet, it checks its CS and PIT to find a 219 matching entry; if no match is found, the node records the 220 Interest in its PIT and forwards the Interest to the next hop(s) 221 towards the requested content based on the information in its FIB. 223 3. Terms by category 225 3.1. Generic terms 227 *Information-Centric Networking (ICN)*: 229 A networking architecture that retrieves Data packets as response 230 to Interest packets. Content-Centric Networking (CCNx 1.x) and 231 Named Data Networking (NDN) are two realizations (designs) of the 232 ICN architecture. 234 *Data packet immutability*: 236 After a data packet is created, it cannot change. If the content 237 carried in the data packet is mutable, versioning should be used, 238 so that each version uniquely identifies an immutable instance of 239 the content. This allows disambiguation of coordination in 240 distributed systems. 242 3.2. Terms related to ICN Nodes 244 *ICN Interface*: 246 A generalization of the network interface that can represent a 247 physical network interface (ethernet, wifi, bluetooth adapter, 248 etc.), an overlay inter-node channel (IP/UDP tunnel, etc.), or an 249 intra-node IPC channel to an application (unix socket, shared 250 memory, intents, etc.). 252 Common aliases include: face. 254 *ICN Consumer*: 256 An ICN entity that requests Data packets by generating and sending 257 out Interest packets towards local (using intra-node interfaces) 258 or remote (using inter-node interfaces) ICN Forwarders. 260 Common aliases include: consumer, information consumer, data 261 consumer, consumer of the content. 263 *ICN Producer*: 265 An ICN entity that creates Data packets and makes them available 266 for retrieval. 268 Common aliases include: producer, publisher, information 269 publisher, data publisher, data producer. 271 *ICN Forwarder*: 273 An ICN entity that implements stateful forwarding. 275 Common aliases include: ICN router. 277 *Data Mule*: 279 An ICN entity that temporarily stores and potentially carries an 280 Interest or Data packet before forwarding it to next ICN entity. 282 3.3. Terms related to the Forwarding plane 284 *Stateful forwarding*: 286 A forwarding process that records incoming Interest packets in the 287 PIT and uses the recorded information to forward the retrieved 288 Data packets back to the consumer(s). The recorded information 289 can also be used to measure data plane performance, e.g., to 290 adjust interest forwarding strategy decisions. 292 Common aliases include: ICN Data plane, ICN Forwarding. 294 *Forwarding strategy*: 296 A module of the ICN stateful forwarding (ICN data) plane that 297 implements a decision on where/how to forward the incoming 298 Interest packet. The forwarding strategy can take input from the 299 Forwarding Information Base (FIB), measured data plane performance 300 parameters, and/or use other mechanisms to make the decision. 302 Common aliases include: Interest forwarding strategy. 304 *Upstream (forwarding)*: 306 Forwarding packets in the direction of Interests (i.e., Interests 307 are forwarded upstream): consumer, router, router, ..., producer. 309 *Downstream (forwarding)*: 311 Forwarding packets in the opposite direction of Interest 312 forwarding (i.e., Data and Interest Nacks are forwarded 313 downstream): producer, router, ..., consumer(s). 315 *Interest forwarding*: 317 A process of forwarding Interest packets using the Names carried 318 in the Interests. In case of Stateful forwarding, creating an 319 entry in PIT. The forwarding decision is made by the Forwarding 320 Strategy. 322 *Interest aggregation*: 324 A process of combining multiple identical Interest packets for the 325 same Data into a single PIT entry. Not the same as Interest 326 suppresion. 328 Common aliases include: Interest collapsing. 330 *Data forwarding*: 332 A process of forwarding the incoming Data packet to the 333 interface(s) recorded in the corresponding PIT entry (entries) and 334 removing the corresponding PIT entry (entries). 336 *Satisfying an Interest*: 338 An overall process of returning content that satisfies the 339 constraints imposed by the Interest, most notably a match in the 340 provided Name. 342 *Pending Interest Table (PIT)*: 344 A database that records received and not yet satisfied Interests 345 with the interfaces from where they were received. The PIT can 346 also store interfaces to where Interests were forwarded, and 347 information to assess data plane performance. Interests for the 348 same Data are aggregated into a single PIT entry. 350 *Forwarding Information Base (FIB)*: 352 A database that contains a set of prefixes, each prefix associated 353 with one or more faces that can be used to retrieve Data packets 354 with Names under the corresponding prefix. The list of faces for 355 each prefix can be ranked, and each face may be associated with 356 additional information to facilitate forwarding strategy 357 decisions. 359 *Content Store (CS)*: 361 A database in an ICN router that provides caching. 363 *In-network storage*: 365 An optional process of storing a Data packet within the network 366 (opportunistic caches, dedicated on/off path caches, and managed 367 in-network storage systems), so it can satisfy an incoming 368 Interest for this Data packet. The in-network storages can 369 optionally advertise the stored Data packets in the routing plane. 371 *Opportunistic caching*: 373 A process of temporarily storing a forwarded Data packet in the 374 router's memory (RAM or disk), so it can be used to satisfy future 375 Interests for the same Data, if any. 377 Common aliases include: on-patch in-network caching 379 *Managed caching*: 381 A process of temporarily, permanently, or scheduled storing of a 382 selected (set of) Data packet(s). 384 Common aliases include: off-patch in-network storage 386 *Managed in-network storage*: 388 An entity acting as an ICN publisher that implements managed 389 caching. 391 Common aliases include: repository, repo 393 *ICN Routing plane*: 395 An ICN protocol or a set of ICN protocols to exchange information 396 about Name space reachability. 398 *ICN Routing Information Base (RIB)*: 400 A database that contains a set of prefix-face mappings that are 401 produced by running one or multiple routing protocols. The RIB is 402 used to populate the FIB. 404 3.4. Terms related to Packet Types 406 *Interest packet*: 408 A network-level packet that expresses the request for a data 409 packet using either an exact name or a name prefix. An interest 410 packet may optionally carry a set of additional restrictions 411 (e.g., interest selectors). An interest may be associated with 412 additional information to facilitate forwarding and can include 413 Interest lifetime, hop limit, forwarding hints, labels, etc. In 414 different ICN designs, the set of additional associated 415 information may vary. 417 Common aliases include: interest, interest message, information 418 request 420 *Interest Nack*: 422 A packet that contains the Interest packet and optional 423 annotation, which is sent by the ICN Router to the interface(s) 424 the Interest was received from. Interest Nack is used to inform 425 downstream ICN nodes about inability to forward the included 426 Interest packet. The annotation can describe the reason. 428 Common aliases include: network NACK, Interest return. 430 *Data packet*: 432 A network-level packet that carries payload, uniquely identified 433 by a name, and is directly secured. 435 Common aliases include: data, data object, content object, 436 content object packet, data message, named data object, named 437 data. 439 *Link*: 441 A type of Data packet whose body contains the Name of another Data 442 packet. This inner Name is often a Full Name, i.e., it specifies 443 the Packet ID of the corresponding Data packet, but this is not a 444 requirement. 446 Common aliases include: pointer. 448 *Manifest*: 450 A type of Data packet that contains Full Name Links to one or more 451 Data Packets. Manifests group collections of related Data packets 452 under a single Name. This has the additional benefit of 453 amortizing the signature verification cost for each Data packet 454 referenced by the inner Links. Manifests typically contain 455 additional metadata, e.g., the size (in bytes) of each linked Data 456 packet and the cryptographic hash digest of all Data contained in 457 the linked Data packets. 459 3.5. Terms related to Name Types 461 *Name*: 463 A Data packet identifier. An ICN name is hierarchical (a sequence 464 of name components) and usually is semantically meaningful, making 465 it expressive, flexible and application-specific (akin to a HTTP 466 URL). A Name may encode information about application context, 467 semantics, locations (topological, geographical, hyperbolic, 468 etc.), a service name, etc. 470 Common aliases include: data name, interest name, content name. 472 *Name component*: 474 A sequence of octets and optionally a numeric type representing a 475 single label in the hierarchical structured name. 477 Common aliases include: name segment (as in CCN). 479 *Packet ID*: 481 a unique cryptographic identifier for a Data packet. Typically, 482 this is a cryptographic hash digest of a data packet (such as 483 SHA256), including its name, payload, meta information, and 484 signature. 486 *Selector*: 488 A mechanism (condition) to select an individual Data packet from a 489 collection of Data packets that match a given Interest that 490 requests data using a prefix or exact Name. 492 Common aliases include: interest selector, restrictor, interest 493 restrictor. 495 *Nonce*: 497 A field of an Interest packet that transiently 'names' an Interest 498 instance (instance of Interest for a given name). 500 *Exact Name*: 502 A name that is encoded inside a Data packet and which typically 503 uniquely identifies this Data packet. 505 *Full Name*: 507 An exact Name with the Packet ID of the corresponding Data packet. 509 *Prefix Name*: 511 A Name that includes a partial sequence of Name components 512 (starting from the first one) of a Name encoded inside a Data 513 packet. 515 Common aliases include: prefix. 517 3.6. Terms related to Name Usage 519 *Naming conventions*: 521 A convention, agreement, or specification for the Data packet 522 naming. Naming convention structures a namespace. 524 Common aliases include: Naming scheme, ICN naming scheme, 525 namespace convention 527 *Hierarchically structured naming*: 529 The naming scheme that assigns and interprets a Name as a sequence 530 of labels (Name components) with hierarchical structure without an 531 assumption of a single administrative root. A structure provides 532 useful context information for the Name. 534 Common aliases include: hierarchical naming, structured naming. 536 *Flat naming*: 538 The naming scheme that assigns and interprets a Name as a single 539 label (Name component) without any internal structure. This can 540 be considered a special (or degenerated) case of structured names. 542 *Segmentation*: 544 A process of splitting large application content into a set of 545 uniquely named data packets. When using hierarchically structured 546 names, each created data packet has a common prefix and additional 547 component representing the segment (chunk) number. 549 Common aliases include: chunking 551 *Versioning*: 553 A process of assigning a unique Name to the revision of the 554 content carried in the Data packet. When using a hierarchically 555 structured Name, the version of the Data packet can be carried in 556 a dedicated Name component (e.g., prefix identifies data, unique 557 version component identifies the revision of the data). 559 *Fragmentation*: 561 A process of splitting data packets into frames so that they can 562 be transmitted over the link with a smaller MTU size. 564 3.7. Terms related to Data-Centric Security 566 *Data-Centric Security*: 568 A security property associated with the Data packet, including 569 data (Data-Centric) integrity, authenticity, and optionally 570 confidentiality. These security properties stay with the data 571 packet regardless where it is stored and how it is retrieved. 573 Common aliases include: directly securing data packet 575 *Data Integrity* 577 A cryptographic mechanism to ensure the consistency of the Data 578 packet bits. The Data integrity property validates that the Data 579 packet content has not been corrupted during transmission, e.g., 580 over lossy channels. 582 *Data Authenticity* 584 A cryptographic mechanism to ensure trustworthiness of a Data 585 packet, based on a selected (e.g., by a consumer/producer) trust 586 model. Typically, data authenticity is assured through the use of 587 asymmetric cryptographic signatures (e.g., RSA, ECDSA), but can 588 also be realized using symmetric signatures (e.g., HMAC) within 589 trusted domains. 591 *Data Confidentiality* 593 A cryptographic mechanism to ensure secrecy of a Data packet. 594 Data confidentiality includes separate mechanisms: content 595 confidentiality and Name confidentiality 597 *Content Confidentiality* 599 A cryptographic mechanism to prevent an unauthorized party to get 600 access to the plain-text payload of a Data packet. Can be 601 realized through encryption (symmetric, asymmetric, hybrid) and 602 proper distribution of the decryption keys to authorized parties. 604 *Name Confidentiality* 606 A cryptographic mechanism to prevent an observer of Interest-Data 607 exchanges (e.g., intermediate router) from gaining detailed meta 608 information about the Data packet. This mechanism can be realized 609 using encryption (same as content confidentiality) or obfuscation 610 mechanisms. 612 3.8. Uncategorized terms 614 *Route-By-Name Routing (RBNR)* 616 *Lookup-By-Name Routing (LBNR)* 618 *Bread-crumbs routing* 620 *Replication-by-name* 622 *Routing Locator Signing* 624 *Location-independence* 626 *Content based* 628 *ICN API* 629 *Information Centric Delay Tolerant Network* 631 *Located-Named-Data* 633 *Sessionless* 635 4. Semantics and Usage 637 The terminology described above is the manifestation of intended 638 semantics of NDN and CCN operations (what do we expect the network to 639 do?). In this section we summarize the most commonly proposed use 640 cases and interpretations. 642 4.1. Data Transfer 644 The networking view of NDN and CCN is that the request/reply protocol 645 implements a basic, unreliable data transfer service for single, 646 named packets. 648 4.2. Data Transport 650 Data transfer can be turned into a data transport service for 651 application-level objects by additional logic. This transport logic 652 must understand and construct the series of names needed to 653 reassemble the segmented object. Various flavors of transport can be 654 envisaged (reliable, streaming, mailbox, etc) 656 4.3. Lookup Service 658 A more distributed systems view of the basic request/reply protocol 659 is that NDN and CCN provide a distributed lookup service: Given a key 660 value (=name), the service will return the corresponding value. 662 4.4. Database Access 664 The lookup service turns into a database access protocol by ... 665 namespace design ... prefix standing for a collection ... The DB 666 query expression must be encoded as a name. 668 4.5. Remote Procedure Call 670 More generally, ... parameters in the interest ... used e.g.,/ as 671 command channel for remote control of neighbor routers. 673 *Interest match in FIB (longest prefix match)*: 675 A process of finding a FIB entry with the longest Name (in terms 676 of Name components) that is a prefix of the specified Name. 678 *Interest match in PIT (exact match)*: 680 A process of finding a PIT entry that stores the same Name as 681 specified in the Interest (including Interest restrictions, if 682 any). 684 *Data match in PIT (all match)*: 686 A process of finding (a set of) PIT entries that can be satisfied 687 with the specified Data packet. 689 *Interest match in CS (any match)*: 691 A process of finding an entry in router's Content Store that can 692 satisfy the specified Interest. 694 5. Informational References 696 [I-D.irtf-icnrg-ccnxmessages] 697 marc.mosko@parc.com, m., Solis, I., and c. cwood@parc.com, 698 "CCNx Messages in TLV Format", draft-irtf-icnrg- 699 ccnxmessages-04 (work in progress), March 2017. 701 [I-D.irtf-icnrg-ccnxsemantics] 702 marc.mosko@parc.com, m., Solis, I., and c. cwood@parc.com, 703 "CCNx Semantics", draft-irtf-icnrg-ccnxsemantics-04 (work 704 in progress), March 2017. 706 [I-D.irtf-icnrg-disaster] 707 Seedorf, J., Arumaithurai, M., Tagami, A., Ramakrishnan, 708 K., and N. Blefari-Melazzi, "Research Directions for Using 709 ICN in Disaster Scenarios", draft-irtf-icnrg-disaster-02 710 (work in progress), July 2017. 712 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 713 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 714 "Information-Centric Networking: Baseline Scenarios", 715 RFC 7476, DOI 10.17487/RFC7476, March 2015, 716 . 718 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 719 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 720 "Information-Centric Networking (ICN) Research 721 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 722 . 724 [RFC7933] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C., 725 Azgin, A., Liu, W., Mueller, C., Detti, A., Corujo, D., 726 Wang, J., Montpetit, M., and N. Murray, "Adaptive Video 727 Streaming over Information-Centric Networking (ICN)", 728 RFC 7933, DOI 10.17487/RFC7933, August 2016, 729 . 731 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 732 and G. Boggia, "Information-Centric Networking: Evaluation 733 and Security Considerations", RFC 7945, 734 DOI 10.17487/RFC7945, September 2016, 735 . 737 Appendix A. Acknowledgments 739 Mark Mosco, ... 741 Authors' Addresses 743 Bastiaan Wissingh 744 TNO 746 EMail: bastiaan.wissingh@tno.nl 748 Christopher A. Wood 749 University of California Irvine 751 EMail: woodc1@uci.edu 753 Alex Afanasyev 754 UCLA 756 EMail: aa@cs.ucla.edu 758 Lixia Zhang 759 UCLA 761 EMail: lixia@cs.ucla.edu 763 David Oran 764 Network Systems Research & Design 766 EMail: daveoran@orandom.net 768 Christian Tschudin 769 University of Basel 771 EMail: christian.tschudin@unibas.ch