idnits 2.17.1 draft-irtf-icnrg-terminology-05.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 (September 7, 2019) is 1692 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.irtf-icnrg-disaster' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC7476' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC7927' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'RFC7933' is defined on line 726, but no explicit reference was found in the text == Unused Reference: 'RFC7945' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'RFC8569' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'RFC8609' is defined on line 744, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-disaster-04 Summary: 0 errors (**), 0 flaws (~~), 9 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: March 10, 2020 University of California Irvine 6 A. Afanasyev 7 Florida International University 8 L. Zhang 9 UCLA 10 D. Oran 11 Network Systems Research & Design 12 C. Tschudin 13 University of Basel 14 September 7, 2019 16 Information-Centric Networking (ICN): CCNx and NDN Terminology 17 draft-irtf-icnrg-terminology-05 19 Abstract 21 Information Centric Networking (ICN) is a novel paradigm where 22 network communications are accomplished by requesting named content, 23 instead of sending packets to destination addresses. Named Data 24 Networking (NDN) and Content-Centric Networking (CCNx) are two 25 prominent ICN architectures. This document provides an overview of 26 the terminology and definitions that have been used in describing 27 concepts in these two implementations of ICN. While there are other 28 ICN architectures, they are not part of the NDN and CCNx concepts and 29 as such are out of scope for this document. This document is a 30 product of the Information-Centric Networking Research Group (ICNRG). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on March 10, 2020. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. A Sketch of the Big Picture of ICN . . . . . . . . . . . . . 3 68 3. Terms by category . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Generic terms . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Terms related to ICN Nodes . . . . . . . . . . . . . . . 6 71 3.3. Terms related to the Forwarding plane . . . . . . . . . . 7 72 3.4. Terms related to Packet Types . . . . . . . . . . . . . . 10 73 3.5. Terms related to Name Types . . . . . . . . . . . . . . . 11 74 3.6. Terms related to Name Usage . . . . . . . . . . . . . . . 13 75 3.7. Terms related to Data-Centric Security . . . . . . . . . 14 76 4. Semantics and Usage . . . . . . . . . . . . . . . . . . . . . 15 77 4.1. Data Transfer . . . . . . . . . . . . . . . . . . . . . . 15 78 4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 15 79 4.3. Lookup Service . . . . . . . . . . . . . . . . . . . . . 15 80 4.4. Database Access . . . . . . . . . . . . . . . . . . . . . 15 81 4.5. Remote Procedure Call . . . . . . . . . . . . . . . . . . 15 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 7. Informational References . . . . . . . . . . . . . . . . . . 16 85 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 Information-centric networking (ICN) is an architecture to evolve the 91 Internet infrastructure from the existing host-centric design to a 92 data-centric architecture, where accessing data by name becomes the 93 essential network primitive. The goal is to let applications refer 94 to data independently of their location or means of transportation, 95 which enables native multicast delivery, ubiquitous in-network 96 caching and replication of data objects. 98 As the work on this topic continues to evolve, many new terms are 99 emerging. The goal of this document is to collect the key terms with 100 a corresponding definition as they are used in the CCNx and NDN 101 projects. Other ICN projects such as NetInf, or MobilityFirst are 102 not covered and will be the subject of other documents. 104 To help provide context for the individual defined terms, in this 105 draft we first sketch the bigger picture of an ICN network by 106 introducing the basic concepts and identifying the major components 107 of the architecture in Section 2, after which, in Section 3, ICN 108 related terms are listed by different categories. 110 This document represents the consensus of the Information-Centric 111 Networking Research Group (ICNRG). It has been reviewed extensively 112 by the Research Group (RG) members active in the specific areas of 113 work covered by the document. It is not an IETF product and is not 114 intended for standardization in the IETF. 116 2. A Sketch of the Big Picture of ICN 118 In networking terms, an ICN is a delivery infrastructure for named 119 data. For other complementing views see Section 4. 121 requestor zero or more data sources or 122 (node) forwarding nodes replica nodes 123 | | ... | |...| 124 | Interest(n) | | Interest(n) | | 125 | --------------> | | ---------------> | | 126 | | | -------------------> | 127 | | | | | 128 | | | Data([n],c,[s]) | | 129 | | | <--------------- | | 130 | | | <------------------- | 131 | Data([n],c,[s]) | | | | 132 | <-------------- | | | | 134 Figure 1: Request-Reply Protocol of ICN networking. Legend: n=name, 135 c=content, s=signature. 137 The following list describes the basic ICN concepts needed to discuss 138 the implementation of this service abstraction. 140 *Request-Reply Protocol (Interest and Data Packet)*: 142 An ICN's lookup service is implemented by defining two types of 143 network packet formats: Interest packets that request content by 144 name, and Data packets that carry the requested content. The 145 returned Data packet must match the request's parameters (e.g., 146 having a partially or fully matching name). If the request is 147 ambiguous and several Data packets would satisfy the request, the 148 ICN network returns only one matching Data packet (flow balance 149 between Interest and Data packets over individual links). 151 *Packet and Content Names* 153 Without an irrefutable binding between the name of a Data packet 154 and its content, Data packet names would be useless for fetching 155 specific content. In ICN, verification of a Data packet's name- 156 to-content binding is achieved through cryptographic means, either 157 by (1) a cryptographic signature that explicitly binds an 158 application-chosen name to a Data packet's content, or (2) relying 159 on an implicit name (cryptographic hash of the Data packet with or 160 without application-chosen name) that the data consumer obtained 161 through other means. 163 *Data Authenticity and Encryption*: 165 Any data consumer and network element can validate the 166 authenticity of a Data packet by verifying its cryptographic name- 167 to-content binding. In contrast, whether a Data packet's content 168 (payload) itself is encrypted or not is irrelevant to the ICN 169 network. The use and management of content encryption keys is an 170 application-layer concern. 172 *Trust*: 174 Data authenticity is distinct from data trustworthiness, though 175 the two concepts are related. A packet is authentic if it has a 176 valid name-to-content binding. A packet is trustworthy, i.e., it 177 comes from a reputable or trusted origin, if this binding is valid 178 in the context of a trust model. 180 *Segmenting and Versioning*: 182 An ICN network will be engineered for some packet size limit. As 183 application-level data objects will often be considerably larger, 184 objects must be segmented into multiple Data packets. The names 185 for these Data packets can, for example, be constructed by 186 choosing one application-level object name to which a different 187 suffix is added for each segment. The same method can be used to 188 handle different versions of an application-level object by 189 including a version number into the name of the overall object. 191 *Packet and Frame*: 193 NDN and CCNx introduce Protocol Data Units (PDUs) which typically 194 are larger than the maximum transmission unit of the underlying 195 networking technology. We refer to PDUs as packets and the 196 (potentially fragmented) packet parts that traverse MTU-bound 197 links as frames. Handling link-layer technologies which lead to 198 fragmentation of ICN packets is done inside the ICN network and is 199 not visible at the service interface. 201 *ICN Node*: 203 A node within an ICN network can fulfill the role of a data 204 producer, a data consumer, and/or a forwarder for Interest and 205 Data packets. When a forwarder has connectivity to neighbor 206 nodes, it performs Interest and Data packet forwarding in real 207 time. It can also behave like a packet mule, that is it may carry 208 an Interest or Data packet for some time before forwarding it to 209 next node. An ICN node may also run routing protocols to assist 210 its Interest forwarding decisions. 212 *Forwarding Plane*: 214 The canonical way of implementing packet forwarding in an ICN 215 network relies on three data structures that capture a node's 216 state: a Forwarding Interest Table (FIB), a Pending Interest 217 Table (PIT), and a Content Store (CS). It also utilizes Interest 218 forwarding strategies which takes input from both FIB and 219 measurements to make Interest forwarding decisions. When a node 220 receives an Interest packet, it checks its CS and PIT to find a 221 matching entry; if no match is found, the node records the 222 Interest in its PIT and forwards the Interest to the next hop(s) 223 towards the requested content, based on the information in its 224 FIB. 226 3. Terms by category 228 3.1. Generic terms 230 *Information-Centric Networking (ICN)*: 232 A networking architecture that retrieves Data packets as response 233 to Interest packets. Content-Centric Networking (CCNx 1.x) and 234 Named Data Networking (NDN) are two realizations (designs) of the 235 ICN architecture. 237 *Data packet immutability*: 239 After a data packet is created, it cannot change. If the content 240 carried in the data packet is mutable, versioning should be used, 241 so that each version uniquely identifies an immutable instance of 242 the content. This allows disambiguation of coordination in 243 distributed systems. 245 3.2. Terms related to ICN Nodes 247 *ICN Interface*: 249 A generalization of the network interface that can represent a 250 physical network interface (ethernet, wifi, bluetooth adapter, 251 etc.), an overlay inter-node channel (IP/UDP tunnel, etc.), or an 252 intra-node inter-process communication (IPC) channel to an 253 application (unix socket, shared memory, intents, etc.). 255 Common aliases include: face. 257 *ICN Consumer*: 259 An ICN entity that requests Data packets by generating and sending 260 out Interest packets towards local (using intra-node interfaces) 261 or remote (using inter-node interfaces) ICN Forwarders. 263 Common aliases include: consumer, information consumer, data 264 consumer, consumer of the content. 266 *ICN Producer*: 268 An ICN entity that creates Data packets and makes them available 269 for retrieval. 271 Common aliases include: producer, publisher, information 272 publisher, data publisher, data producer. 274 *ICN Forwarder*: 276 An ICN entity that implements stateful forwarding. 278 Common aliases include: ICN router. 280 *Data Mule*: 282 An ICN entity that temporarily stores and potentially carries an 283 Interest or Data packet before forwarding it to next ICN entity. 285 3.3. Terms related to the Forwarding plane 287 *Stateful forwarding*: 289 A forwarding process that records incoming Interest packets in the 290 PIT and uses the recorded information to forward the retrieved 291 Data packets back to the consumer(s). The recorded information 292 can also be used to measure data plane performance, e.g., to 293 adjust interest forwarding strategy decisions. 295 Common aliases include: ICN Data plane, ICN Forwarding. 297 *Forwarding strategy*: 299 A module of the ICN stateful forwarding (ICN data) plane that 300 implements a decision on where/how to forward the incoming 301 Interest packet. The forwarding strategy can take input from the 302 Forwarding Information Base (FIB), measured data plane performance 303 parameters, and/or use other mechanisms to make the decision. 305 Common aliases include: Interest forwarding strategy. 307 *Upstream (forwarding)*: 309 Forwarding packets in the direction of Interests (i.e., Interests 310 are forwarded upstream): consumer, router, router, ..., producer. 312 *Downstream (forwarding)*: 314 Forwarding packets in the opposite direction of Interest 315 forwarding (i.e., Data and Interest Nacks are forwarded 316 downstream): producer, router, ..., consumer(s). 318 *Interest forwarding*: 320 A process of forwarding Interest packets using the Names carried 321 in the Interests. In case of Stateful forwarding, creating an 322 entry in the PIT. The forwarding decision is made by the 323 Forwarding Strategy. 325 *Interest aggregation*: 327 A process of combining multiple Interest packets with the same 328 Name and additional restrictions for the same Data into a single 329 PIT entry. Not the same as Interest suppression. 331 Common aliases include: Interest collapsing. 333 *Data forwarding*: 335 A process of forwarding the incoming Data packet to the 336 interface(s) recorded in the corresponding PIT entry (entries) and 337 removing the corresponding PIT entry (entries). 339 *Satisfying an Interest*: 341 An overall process of returning content that satisfies the 342 constraints imposed by the Interest, most notably a match in the 343 provided Name. 345 *Interest match in FIB (longest prefix match)*: 347 A process of finding a FIB entry with the longest Name (in terms 348 of Name components) that is a prefix of the specified Name. 350 *Interest match in PIT (exact match)*: 352 A process of finding a PIT entry that stores the same Name as 353 specified in the Interest (including Interest restrictions, if 354 any). 356 *Data match in PIT (all match)*: 358 A process of finding (a set of) PIT entries that can be satisfied 359 with the specified Data packet. 361 *Interest match in CS (any match)*: 363 A process of finding an entry in router's Content Store that can 364 satisfy the specified Interest. 366 *Pending Interest Table (PIT)*: 368 A database that records received and not yet satisfied Interests 369 with the interfaces from where they were received. The PIT can 370 also store interfaces to where Interests were forwarded, and 371 information to assess data plane performance. Interests for the 372 same Data are aggregated into a single PIT entry. 374 *Forwarding Information Base (FIB)*: 376 A database that contains a set of prefixes, each prefix associated 377 with one or more faces that can be used to retrieve Data packets 378 with Names under the corresponding prefix. The list of faces for 379 each prefix can be ranked, and each face may be associated with 380 additional information to facilitate forwarding strategy 381 decisions. 383 *Content Store (CS)*: 385 A database in an ICN router that provides caching. 387 *In-network storage*: 389 An optional process of storing a Data packet within the network 390 (opportunistic caches, dedicated on/off path caches, and managed 391 in-network storage systems), so it can satisfy an incoming 392 Interest for this Data packet. The in-network storages can 393 optionally advertise the stored Data packets in the routing plane. 395 *Opportunistic caching*: 397 A process of temporarily storing a forwarded Data packet in the 398 router's memory (RAM or disk), so it can be used to satisfy future 399 Interests for the same Data, if any. 401 Common aliases include: on-path in-network caching 403 *Managed caching*: 405 A process of temporarily, permanently, or scheduled storing of a 406 selected (set of) Data packet(s). 408 Common aliases include: off-path in-network storage 410 *Managed in-network storage*: 412 An entity acting as an ICN publisher that implements managed 413 caching. 415 Common aliases include: repository, repo 417 *ICN Routing plane*: 419 An ICN protocol or a set of ICN protocols to exchange information 420 about Name space reachability. 422 *ICN Routing Information Base (RIB)*: 424 A database that contains a set of prefix-face mappings that are 425 produced by running one or multiple routing protocols. The RIB is 426 used to populate the FIB. 428 3.4. Terms related to Packet Types 430 *Interest packet*: 432 A network-level packet that expresses the request for a data 433 packet using either an exact name or a name prefix. An Interest 434 packet may optionally carry a set of additional restrictions 435 (e.g., Interest selectors). An Interest may be associated with 436 additional information to facilitate forwarding and can include 437 Interest lifetime, hop limit, forwarding hints, labels, etc. In 438 different ICN designs, the set of additional associated 439 information may vary. 441 Common aliases include: Interest, Interest message, information 442 request 444 *Interest Nack*: 446 A packet that contains the Interest packet and optional 447 annotation, which is sent by the ICN Router to the interface(s) 448 the Interest was received from. Interest Nack is used to inform 449 downstream ICN nodes about inability to forward the included 450 Interest packet. The annotation can describe the reason. 452 Common aliases include: network NACK, Interest return. 454 *Data packet*: 456 A network-level packet that carries payload, uniquely identified 457 by a name, and is directly secured. 459 Common aliases include: data, data object, content object, 460 content object packet, data message, named data object, named 461 data. 463 *Link*: 465 A type of Data packet whose body contains the Name of another Data 466 packet. This inner Name is often a Full Name, i.e., it specifies 467 the Packet ID of the corresponding Data packet, but this is not a 468 requirement. 470 Common aliases include: pointer. 472 *Manifest*: 474 A type of Data packet that contains Full Name Links to one or more 475 Data Packets. Manifests group collections of related Data packets 476 under a single Name. This has the additional benefit of 477 amortizing the signature verification cost for each Data packet 478 referenced by the inner Links. Manifests typically contain 479 additional metadata, e.g., the size (in bytes) of each linked Data 480 packet and the cryptographic hash digest of all Data contained in 481 the linked Data packets. 483 3.5. Terms related to Name Types 485 *Name*: 487 A Data packet identifier. An ICN name is hierarchical (a sequence 488 of name components) and usually is semantically meaningful, making 489 it expressive, flexible and application-specific (akin to a HTTP 490 URL). A Name may encode information about application context, 491 semantics, locations (topological, geographical, hyperbolic, 492 etc.), a service name, etc. 494 Common aliases include: data name, interest name, content name. 496 *Name component*: 498 A sequence of octets and optionally a numeric type representing a 499 single label in the hierarchical structured name. 501 Common aliases include: name segment (as in CCNx). 503 *Packet ID*: 505 A unique cryptographic identifier for a Data packet. Typically, 506 this is a cryptographic hash digest of a data packet (such as 507 SHA256), including its name, payload, meta information, and 508 signature. 510 Common aliases include: implicit digest. 512 *Selector*: 514 A mechanism (condition) to select an individual Data packet from a 515 collection of Data packets that match a given Interest that 516 requests data using a prefix or exact Name. 518 Common aliases include: interest selector, restrictor, interest 519 restrictor. 521 *Nonce*: 523 A field of an Interest packet that transiently names an Interest 524 instance (instance of Interest for a given name). 526 *Exact Name*: 528 A name that is encoded inside a Data packet and which typically 529 uniquely identifies this Data packet. 531 *Full Name*: 533 An exact Name with the Packet ID of the corresponding Data packet. 535 *Prefix Name*: 537 A Name that includes a partial sequence of Name components 538 (starting from the first one) of a Name encoded inside a Data 539 packet. 541 Common aliases include: prefix. 543 3.6. Terms related to Name Usage 545 *Naming conventions*: 547 A convention, agreement, or specification for the Data packet 548 naming. a Naming convention structures a namespace. 550 Common aliases include: Naming scheme, ICN naming scheme, 551 namespace convention 553 *Hierarchically structured naming*: 555 The naming scheme that assigns and interprets a Name as a sequence 556 of labels (Name components) with hierarchical structure without an 557 assumption of a single administrative root. A structure provides 558 useful context information for the Name. 560 Common aliases include: hierarchical naming, structured naming. 562 *Flat naming*: 564 The naming scheme that assigns and interprets a Name as a single 565 label (Name component) without any internal structure. This can 566 be considered a special (or degenerated) case of structured names. 568 *Segmentation*: 570 A process of splitting large application content into a set of 571 uniquely named data packets. When using hierarchically structured 572 names, each created data packet has a common prefix and additional 573 component representing the segment (chunk) number. 575 Common aliases include: chunking 577 *Versioning*: 579 A process of assigning a unique Name to the revision of the 580 content carried in the Data packet. When using a hierarchically 581 structured Name, the version of the Data packet can be carried in 582 a dedicated Name component (e.g., prefix identifies data, unique 583 version component identifies the revision of the data). 585 *Fragmentation*: 587 A process of splitting PDUs into frames so that they can be 588 transmitted over the link with a smaller MTU size. 590 3.7. Terms related to Data-Centric Security 592 *Data-Centric Security*: 594 A security property associated with the Data packet, including 595 data (Data-Centric) integrity, authenticity, and optionally 596 confidentiality. These security properties stay with the data 597 packet regardless where it is stored and how it is retrieved. 599 Common aliases include: directly securing data packet 601 *Data Integrity* 603 A cryptographic mechanism to ensure the consistency of the Data 604 packet bits. The Data integrity property validates that the Data 605 packet content has not been corrupted during transmission, e.g., 606 over lossy or otherwise unreliable paths. 608 *Data Authenticity* 610 A cryptographic mechanism to ensure trustworthiness of a Data 611 packet, based on a selected (e.g., by a consumer/producer) trust 612 model. Typically, data authenticity is assured through the use of 613 asymmetric cryptographic signatures (e.g., RSA, ECDSA), but can 614 also be realized using symmetric signatures (e.g., HMAC) within 615 trusted domains. 617 *Data Confidentiality* 619 A cryptographic mechanism to ensure secrecy of a Data packet. 620 Data confidentiality includes separate mechanisms: content 621 confidentiality and Name confidentiality 623 *Content Confidentiality* 625 A cryptographic mechanism to prevent an unauthorized party to get 626 access to the plain-text payload of a Data packet. Can be 627 realized through encryption (symmetric, asymmetric, hybrid) and 628 proper distribution of the decryption keys to authorized parties. 630 *Name Confidentiality* 631 A cryptographic mechanism to prevent an observer of Interest-Data 632 exchanges (e.g., intermediate router) from gaining detailed meta 633 information about the Data packet. This mechanism can be realized 634 using encryption (same as content confidentiality) or obfuscation 635 mechanisms. 637 4. Semantics and Usage 639 The terminology described above is the manifestation of intended 640 semantics of NDN and CCNx operations (what do we expect the network 641 to do?). In this section we summarize the most commonly proposed use 642 cases and interpretations. 644 4.1. Data Transfer 646 The networking view of NDN and CCNx is that the request/reply 647 protocol implements a basic, unreliable data transfer service for 648 single, named packets. 650 4.2. Data Transport 652 Data transfer can be turned into a data transport service for 653 application-level objects by additional logic. This transport logic 654 must understand and construct the series of names needed to 655 reassemble the segmented object. Various flavors of transport can be 656 envisaged (reliable, streaming, mailbox, etc). 658 4.3. Lookup Service 660 In a more distributed systems view of the basic request/reply 661 protocol, NDN and CCNx provide a distributed lookup service: given a 662 key value (=name), the service will return the corresponding value. 664 4.4. Database Access 666 A lookup service can be turned into into a database access protocol 667 by using the namespace structure to specify names as access keys into 668 a database. A name prefix therefore stands for a collection or table 669 of a database, while the rest of the name specifies the query 670 expression to be executed. 672 4.5. Remote Procedure Call 674 The names as defined here for Interests and Data can refer to Remote 675 Procedure call functions, their input arguments, and their results. 677 *Interest match in FIB (longest prefix match)*: 679 A process of finding a FIB entry with the longest Name (in terms 680 of Name components) that is a prefix of the specified Name. 682 *Interest match in PIT (exact match)*: 684 A process of finding a PIT entry that stores the same Name as 685 specified in the Interest (including Interest restrictions, if 686 any). 688 *Data match in PIT (all match)*: 690 A process of finding (a set of) PIT entries that can be satisfied 691 with the specified Data packet. 693 *Interest match in CS (any match)*: 695 A process of finding an entry in router's Content Store that can 696 satisfy the specified Interest. 698 5. IANA Considerations 700 There are no IANA considerations related to this document. 702 6. Security Considerations 704 This document introduces no new security considerations. 706 7. Informational References 708 [I-D.irtf-icnrg-disaster] 709 Seedorf, J., Arumaithurai, M., Tagami, A., Ramakrishnan, 710 K., and N. Blefari-Melazzi, "Research Directions for Using 711 ICN in Disaster Scenarios", draft-irtf-icnrg-disaster-04 712 (work in progress), February 2019. 714 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 715 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 716 "Information-Centric Networking: Baseline Scenarios", 717 RFC 7476, DOI 10.17487/RFC7476, March 2015, 718 . 720 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 721 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 722 "Information-Centric Networking (ICN) Research 723 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 724 . 726 [RFC7933] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C., 727 Azgin, A., Liu, W., Mueller, C., Detti, A., Corujo, D., 728 Wang, J., Montpetit, M., and N. Murray, "Adaptive Video 729 Streaming over Information-Centric Networking (ICN)", 730 RFC 7933, DOI 10.17487/RFC7933, August 2016, 731 . 733 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 734 and G. Boggia, "Information-Centric Networking: Evaluation 735 and Security Considerations", RFC 7945, 736 DOI 10.17487/RFC7945, September 2016, 737 . 739 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 740 Networking (CCNx) Semantics", RFC 8569, 741 DOI 10.17487/RFC8569, July 2019, . 744 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 745 Networking (CCNx) Messages in TLV Format", RFC 8609, 746 DOI 10.17487/RFC8609, July 2019, . 749 Appendix A. Acknowledgments 751 Mark Mosco provided much guidance and helpful precision in getting 752 these terms carefully formed and the definitions precise. Marie-Jose 753 Montpetit did a through IRSG review, which helped a lot to finalise 754 the text. 756 Authors' Addresses 758 Bastiaan Wissingh 759 TNO 761 EMail: bastiaan.wissingh@tno.nl 763 Christopher A. Wood 764 University of California Irvine 766 EMail: woodc1@uci.edu 768 Alex Afanasyev 769 Florida International University 771 EMail: aa@cs.fiu.edu 773 Lixia Zhang 774 UCLA 776 EMail: lixia@cs.ucla.edu 778 David Oran 779 Network Systems Research & Design 781 EMail: daveoran@orandom.net 783 Christian Tschudin 784 University of Basel 786 EMail: christian.tschudin@unibas.ch