idnits 2.17.00 (12 Aug 2021) /tmp/idnits16015/draft-mcbride-edge-data-discovery-overview-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 07, 2019) is 1048 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.irtf-icnrg-ccnxmessages' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-icnrg-ccnxsemantics' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'I-D.kutscher-icnrg-rice' is defined on line 544, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-bernardos-intarea-vim-discovery-01 ** Downref: Normative reference to an Experimental draft: draft-bernardos-intarea-vim-discovery (ref. 'I-D.bernardos-intarea-vim-discovery') == Outdated reference: A later version (-07) exists of draft-bernardos-sfc-discovery-02 ** Downref: Normative reference to an Experimental draft: draft-bernardos-sfc-discovery (ref. 'I-D.bernardos-sfc-discovery') == Outdated reference: draft-irtf-icnrg-ccnxmessages has been published as RFC 8609 ** Downref: Normative reference to an Experimental draft: draft-irtf-icnrg-ccnxmessages (ref. 'I-D.irtf-icnrg-ccnxmessages') == Outdated reference: draft-irtf-icnrg-ccnxsemantics has been published as RFC 8569 ** Downref: Normative reference to an Experimental draft: draft-irtf-icnrg-ccnxsemantics (ref. 'I-D.irtf-icnrg-ccnxsemantics') ** Downref: Normative reference to an Experimental draft: draft-kutscher-icnrg-rice (ref. 'I-D.kutscher-icnrg-rice') ** Downref: Normative reference to an Informational RFC: RFC 7927 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COINRG M. McBride 3 Internet-Draft Futurewei 4 Intended status: Standards Track D. Kutscher 5 Expires: January 8, 2020 Emden University 6 E. Schooler 7 Intel 8 CJ. Bernardos 9 UC3M 10 July 07, 2019 12 Edge Data Discovery for COIN 13 draft-mcbride-edge-data-discovery-overview-02 15 Abstract 17 This document describes the problem of distributed data discovery in 18 edge computing, and in particular for computing-in-the-network 19 (COIN), which may require both the marshalling of data at the outset 20 of a computation and the persistence of the resultant data after the 21 computation. Although the data might originate at the network edge, 22 as more and more distributed data is created, processed, and stored, 23 it becomes increasingly dispersed throughout the network. There 24 needs to be a standard way to find it. New and existing protocols 25 will need to be developed to support distributed data discovery at 26 the network edge and beyond. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 8, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Edge Data . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Edge Data Discovery Problem Scope . . . . . . . . . . . . . . 4 68 2.1. A Cloud-Edge Continuum . . . . . . . . . . . . . . . . . 5 69 2.2. Types of Edge Data . . . . . . . . . . . . . . . . . . . 6 70 3. Scenarios Requiring Discovery of Edge Data Resources . . . . 7 71 4. Edge Data Discovery . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Types of Discovery . . . . . . . . . . . . . . . . . . . 7 73 4.2. Naming the Data . . . . . . . . . . . . . . . . . . . . . 8 74 5. Use Cases of edge data discovery . . . . . . . . . . . . . . 9 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 78 9. Normative References . . . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 Edge computing is an architectural shift that migrates Cloud 84 functionality (compute, storage, networking, control, data 85 management, etc.) out of the back-end data center to be more 86 proximate to the IoT data being generated and analyzed at the edges 87 of the network. Edge computing provides local compute, storage and 88 connectivity services, often required for latency- and bandwidth- 89 sensitive applications. Thus, Edge Computing plays a key role in 90 verticals such as Energy, Manufacturing, Automotive, Video 91 Surveillance, Retail, Gaming, Healthcare, Mining, Buildings and Smart 92 Cities. 94 1.1. Edge Data 96 Edge computing is motivated at least in part by the sheer volume of 97 data that is being created by endpoint devices (sensors, cameras, 98 lights, vehicles, drones, wearables, etc.) at the very network edge 99 and that flows upstream, in a direction for which the network was not 100 originally designed. In fact, in dense IoT deployments (e.g., many 101 video cameras are streaming high definition video), where multiple 102 data flows collect or converge at edge nodes, data is likely to need 103 transformation (transcoded, subsampled, compressed, analyzed, 104 annotated, combined, aggregated, etc.) to fit over the next hop link, 105 or even to fit in memory or storage. Note also that the act of 106 performing compute on the data creates yet another new data stream! 107 Preservation of the original data streams are needed sometimes but 108 not always. 110 In addition, data may be cached, copied and/or stored at multiple 111 locations in the network on route to its final destination. With an 112 increasing percentage of devices connecting to the Internet being 113 mobile, support for in-the-network caching and replication is 114 critical for continuous data availability, not to mention efficient 115 network and battery usage for endpoint devices. 117 Additionally, as mobile devices' memory/storage fill up, in an edge 118 context they may have the ability to offload their data to other 119 proximate devices or resources, leaving a bread crumb trail of data 120 in their wakes. Therefore, although data might originate at edge 121 devices, as more and more data is continuously created, processed and 122 stored, it becomes increasingly dispersed throughout the physical 123 world (outside of or scattered across managed local data centers), 124 increasingly isolated in separate local edge clouds or data silos. 125 Thus there needs to be a standard way to find it. New and existing 126 protocols will need to be identified/developed/enhanced for these 127 purposes. Being able to discover distributed data at the edge or in 128 the middle of the network - will be an important component of Edge 129 computing. 131 1.2. Background 133 Several IETF T2T RG Edge Computing discussions have been held over 134 the last couple years, a comparative study on the definition of Edge 135 computing was presented in multiple sessions in T2T RG in 2018 and an 136 Edge Computing I-D was submitted early 2019. An IETF BEC (beyond 137 edge computing) effort has been evaluating potential gaps in existing 138 edge computing architectures. Edge Data Discovery is one potential 139 gap that was identified and that needs evaluation and a solution. 140 The newly proposed COIN RG highlights the need for computations in 141 the network to be able to marshal potentially distributed input data 142 and to handle resultant output data, i.e., its placement, storage 143 and/or possible migration strategy. 145 1.3. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 1.4. Terminology 153 o Edge: The edge encompasses all entities not in the back-end cloud. 154 The device edge represents the very leaves of the network and 155 encompasses the entities found in the last mile network. Sensors, 156 gateways, compute nodes are included. Because the things that 157 populate the IoT can be both physical and/or cyber, in some 158 solutions, particularly in software-defined or digital-twin 159 contexts, the device edge can include logical (vs physical) 160 entities. The infrastructure edge includes equipment on the 161 network operator side of the last mile network including cell 162 towers, edge data centers, cable headends, POPs, etc. See 163 Figure 1 for other possible tiers of edge clouds between the 164 device edge and the back-end cloud data center. 166 o Edge Computing: Distributed computation that is performed near the 167 network edge, where nearness is determined by the system 168 requirements. This includes high performance compute, storage and 169 network equipment on either the device or infrastructure edge. 171 o Edge Data Discovery: The process of finding required data from 172 edge entities, i.e., from databases, files systems, device memory 173 that might be physically distributed in the network, and 174 consolidating it by providing access to it logically as if it were 175 a single unified source, perhaps through its namespace, that can 176 be evaluated or searched. 178 o ICN: Information Centric Networking. An ICN-enabled network 179 routes data by name (vs address), caches content natively in the 180 network, and employs data-centric security. Data discovery may 181 require that data be associated with a name or names, a series of 182 descriptive attributes, and/or a unique identifier. 184 2. Edge Data Discovery Problem Scope 186 Our focus is on how to define and scope the edge data discovery 187 problem. This requires some discussion of the evolving definition of 188 the edge as part of a cloud-to-edge continuum and in turn what is 189 meant by edge data as well as the meta-data surrounding the edge 190 data. 192 2.1. A Cloud-Edge Continuum 194 Although Edge Computing data typically originates at edge devices, 195 there is nothing that precludes edge data from being created anywhere 196 in the cloud-to-edge computing continuum (Figure 1). New edge data 197 may result as a byproduct of computation being performed on the data 198 stream anywhere along its path in the network. For 199 example,infrastructure edges may create new edge data when multiple 200 data streams converge upon this aggregation point and require 201 transformation (e.g., to fit within the available resources, to 202 smooth raw measurements to eliminate high-frequency noise, to 203 obfuscate data for privacy). 205 An assumption is that all data will have associated policies 206 (default, inherited or configured) that describe access control 207 permissions. Consequently, the discoverability of data will be a 208 function of who or what has requested access. In other words, the 209 discoverable view into the available data will be limited to those 210 who are authorized. Discovering edge data that is exclusively 211 private is out of scope of this document, the assumption being that 212 there will be some edge clouds that do not expose or publish the 213 availability of their data. Although edge data may be sent to the 214 back-end cloud as needed, there is nothing that precludes it from 215 being discoverable if the cloud offers it as public. 217 Initially our focus is on discovery of edge data that resides at the 218 Device Edge and the Infrastructure Edge. 220 +-------------------------------+ 221 | Back-end Cloud Data Center | 222 +-------------------------------+ 223 *** Cloud 224 * * Interconnect 225 *** 226 +-------------------------------+ 227 | Core Data Center | 228 +-------------------------------+ 229 *** Backbone 230 * * Network 231 *** 232 +-------------------------------+ 233 | Regional Data Center | 234 +-------------------------------+ 235 *** Metropolitan 236 * * Network 237 *** 238 +-------------------------------+ 239 | Infrastructure Edge | 240 +-------------------------------+ 241 *** Access 242 * * Network 243 *** 244 +-------------------------------+ 245 | Device Edge | 246 +-------------------------------+ 248 Figure 1: Cloud-to-edge computing continuum 250 2.2. Types of Edge Data 252 Besides classically constrained IoT device sensor and measurement 253 data accumulating throughout the edge computing infrastructure, edge 254 data may also take the form of higher frequency and higher volume 255 streaming data (from a continuous sensor or from a camera), meta data 256 (about the data), control data (regarding an event that was 257 triggered), and/or an executable that embodies a function, service, 258 or any other piece of code or algorithm. Edge data also could be 259 created after multiple streams converge at an edge node and are 260 processed, transformed, or aggregated together in some manner. 262 Regardless of edge data type, a key problem in the Cloud-Edge 263 continuum is that data is often kept in silos. Meaning, data is 264 often sequestored within the Edge where it was created. A goal of 265 this discussion is to consider the prospect that different types of 266 edge data will be made accessible across disparate edges, for example 267 to enable richer multi-modal analytics. But this will happen only if 268 data can be described, searched and discovered across heterogeneous 269 edges in a standard way. Having a mechanism to enable granular edge 270 data discovery is the problem that needs solving either with existing 271 or new protocols. The mechanisms shouldn't care to which flavor 272 cloud or edge the request for data discovery is made. 274 3. Scenarios Requiring Discovery of Edge Data Resources 276 1. A set of data resources appears (e.g., a mobile node hosting data 277 joins a network) and they want to be discovered by an existing 278 but possibly virtualized and/or ephemeral data directory 279 infrastructure. 281 2. A device wants to discover data resources available at or near 282 its current location. As some of these resources may be mobile, 283 the available set of edge data may vary over time. 285 3. A device wants to discover to where best in the edge 286 infrastructure to opportunistically upload its data, for example 287 if a mobile device wants to offload its data to the 288 infrastructure (for greater data availability, battery savings, 289 etc.). 291 4. Edge Data Discovery 293 How can we discover data on the edge and make use of it? There are 294 proprietary implementations that collect data from various databases 295 and consolidate it for evaluation. We need a standard protocol set 296 for doing this data discovery, on the device or infrastructure edge, 297 in order to meet the requirements of many use cases. We will have 298 terabytes of data on the edge and need a way to identify its 299 existence and find the desired data. A user requires the need to 300 search for specific data in a data set and evaluate it using their 301 own tools. The tools are outside the scope of this document, but the 302 discovery of that data is in scope. 304 4.1. Types of Discovery 306 There are many aspects of discovery and many different protocols that 307 address each aspect. 309 Discovery of new devices added to an environment. Discovery of their 310 capabilities/services in client/server environments. Discovery of 311 these new devices automatically. Discovering a device and then 312 synchronizing the device inventory and configuration for edge 313 services. There are many existing protocols to help in this 314 discovery: UPnP, mDNS, DNS-SD, SSDP, NFC, XMPP, W3C network service 315 discovery, etc. 317 Edge devices discover each other in a standard way. We can use DHCP, 318 SNMP, SMS, COAP, LLDP, and routing protocols such as OSPF for devices 319 to discovery one another. 321 Discovery of link state and traffic engineering data/services by 322 external devices. BGP-LS is one solution. 324 The question is if one or more of these protocols might be a suitable 325 contender to extend to support edge data discovery? 327 4.2. Naming the Data 329 Information-Centric Networking (ICN) RFC 7927 [RFC7927] is a class of 330 architectures and protocols that provide "access to named data" as a 331 first-order network service. Instead of host-to-host communication 332 as in IP networks, ICNs often use location-independent names to 333 identify data objects, and the network provides the services of 334 processing (answering) requests for named data with the objective to 335 finally deliver the requested data objects to a requesting consumer. 337 Such an approach has profound effects on various aspects of a 338 networking system, including security (by enabling object-based 339 security on a message/packet level), forwarding behavior (name-based 340 forwarding, caching), but also on more operational aspects such as 341 bootstrapping, discovery etc. 343 The CCNx and NDN (https://named-data.net) variants of ICN are based 344 on a request/response abstraction where consumers (hosts, application 345 requesting named data) send INTEREST messages into the network that 346 are forwarded by network elements to a destination that can provide 347 the requested named data object. Corresponding responses are sent as 348 so-called DATA messages that follow the reverse INTEREST path. 350 Each unique data object is named unambiguously in a hierarchical 351 naming scheme and is authenticated through Public-Key cryptography 352 (data objects can also optionally be encrypted in different ways). 353 The naming concept and the object-based security approach lay the 354 foundation for location independent operation. The network can 355 generally operate without any notion of location, and nodes 356 (consumers, forwarders) can forward requests for named data objects 357 directly, i.e., without any additional address resolution. Location 358 independence also enables additional features, for example the 359 possibility to replicate and cache named data objects. On-patch 360 caching is a standard feature in many ICN systems -- typically for 361 enhancing reliability and performance. 363 In CCNx and NDN, forwarders are stateful, i.e., they keep track of 364 forwarded INTEREST to later match the received DATA messages. 366 Stateful forwarding (in conjunction with the general named-based and 367 location-independent operation) also empowers forwarders to execute 368 individual forwarding strategies and perform optimizations such as 369 in-network retransmissions, multicasting requests (in cases there are 370 several opportunities for accessing a particular named data object) 371 etc. 373 Naming data and application-specific naming conventions are naturally 374 important aspects in ICN. It is common that applications define 375 their own naming convention (i.e., semantics of elements in the name 376 hierarchy). Such names can often directly derived from application 377 requirements, for example a name like /my-home/living- 378 room/light/switch/main could be relevant in a smart home setting, and 379 corresponding devices and application could use a corresponding 380 convention to facilitate controllers finding sensors and actors in 381 such a system with minimal user configuration. 383 The aforementioned features make ICN amenable to data discovery. 384 Because there is no name/address chasm as in IP-based systems, data 385 can be discovered by sending INTEREST to named data objects directly 386 (assuming a naming convention as described above). Moreover, ICN can 387 authenticate received data objects directly, for example using local 388 trust anchors in the network (for example in a home network). 390 Advanced ICN features for data discovery include the concept of 391 manifests in CCNx, i.e., ICN objects that describe data collections, 392 and data set synchronization protocols in NDN (https://named- 393 data.net/publications/li2018sync-intro/) that can inform consumers 394 about the availability of new data in a tree-based data structure 395 (with automatic retrieval and authentication). Also, ICN is not 396 limited to accessing static data. Frameworks such as Named Function 397 Networking (http://www.named-function.net) and RICE can provide the 398 general ICN feature for discovery not only for data but also for name 399 functions (for in-network computing) and for their results. 401 5. Use Cases of edge data discovery 403 1. Autonomous Vehicles 405 Autonomous vehicles rely on the processing of huge amounts of complex 406 data in real-time for fast and accurate decisions. These vehicles 407 will rely on high performance compute, storage and network resources 408 to process the volumes of data they produce in a low latency way. 409 Various systems will need a standard way to discover the pertinent 410 data for decision making 412 2. Video Surveillance 413 The majority of the video surveillance footage will remain at the 414 edge infrastructure (not sent to the cloud data center). This 415 footage is coming from vehicles, factories, hotels, universities, 416 farms, etc.Much of the video footage will not be interesting to those 417 evaluating the data. A mechanism, set of protocols perhaps, is 418 needed to identify the interesting data at the edge. What 419 constitutes interesting will be context specific, e.g., video frames 420 with a car in it, a backyard nocturnal creature in it, a person or 421 bicyclist or etc. Interesting video data may be stored longer in 422 storage systems at the very edge of the network or in flight in 423 networking equipment further away from the device edge. 425 3. Elevator Networks 427 Elevators are one of many industrial applications of edge computing. 428 Edge equipment receives data from 100's of elevator sensors. The 429 data coming into the edge equipment is vibration, temperature, speed, 430 level, video, etc. We need the ability to identify where the data we 431 need to evalute is located. 433 4. Service Function Chaining 435 Service function chaining (SFC) allows the instantiation of an 436 ordered set of service functions and the subsequent "steering" of 437 traffic through them. Service functions provide a specific treatment 438 of received packets, therefore they need to be known so they can be 439 used in a given service composition via SFC. So far, how the SFs are 440 discovered and composed has been out of the scope of discussions in 441 IETF. While there are some mechanisms that can be used and/or 442 extended to provide this functionality, work needs to be done. An 443 example of this can be found in [I-D.bernardos-sfc-discovery]. 445 In an SFC environment deployed at the edge, the discovery protocol 446 may also need the following kind of meta-data information per SF: 448 o Service Function Type, identifying the category of SF provided. 450 o SFC-aware: Yes/No. Indicates if the SF is SFC-aware. 452 o Route Distinguisher (RD): IP address indicating the location of 453 the SF(I). 455 o Pricing/costs details. 457 o Migration capabilities of the SF: whether a given function can be 458 moved to another provider (potentially including information about 459 compatible providers topologically close). 461 o Mobility of the device hosting the SF, with e.g. the following 462 sub-options: 464 Level: no, low, high; or a corresponding scale (e.g., 1 to 10). 466 Current geographical area (e.g., GPS coordinates, post code). 468 Target moving area (e.g., GPS coordinates, post code). 470 o Power source of the device hosting the SF, with e.g. the following 471 sub-options: 473 Battery: Yes/No. If Yes, the following sub-options could be 474 defined: 476 Capacity of the battery (e.g., mmWh). 478 Charge status (e.g., %). 480 Lifetime (e.g., minutes). 482 Discovery of resources in an NFV environment: virtualized resources 483 do not need to be limited to those available in traditional data 484 centers, where the infrastructure is stable, static, typically 485 homogeneous and managed by a single admin entity. Computational 486 capabilities are becoming more and more ubiquitous, with terminal 487 devices getting extremely powerful, as well as other types of devices 488 that are close to the end users at the edge (e.g., vehicular onboard 489 devices for infotainment, micro data centers deployed at the edge, 490 etc.). It is envisioned that these devices would be able to offer 491 storage, computing and networking resources to nearby network 492 infrastructure, devices and things (the fog paradigm). These 493 resources can be used to host functions, for example to offload/ 494 complement other resources available at traditional data centers, but 495 also to reduce the end-to-end latency or to provide access to 496 specialized information (e.g., context available at the edge) or 497 hardware. Similar to the discovery of functions, while there are 498 mechanisms that can be reused/extended, there is no complete solution 499 yet defined. An example of work in this area is 500 [I-D.bernardos-intarea-vim-discovery]." The availability of this 501 meta-data about the capabilities of nearby physical as well as 502 virtualized resources can be made discoverable through edge data 503 discovery mechanisms. 505 6. IANA Considerations 507 N/A 509 7. Security Considerations 511 Security considerations will be a critical component of edge data 512 discovery particularly as intelligence is moved to the extreme edge 513 where data is to be extracted. 515 8. Acknowledgement 517 The co-authors thank Dave Oran for his detailed feedback on an 518 earlier version of this draft. 520 9. Normative References 522 [I-D.bernardos-intarea-vim-discovery] 523 Bernardos, C. and A. Mourad, "IPv6-based discovery and 524 association of Virtualization Infrastructure Manager (VIM) 525 and Network Function Virtualization Orchestrator (NFVO)", 526 draft-bernardos-intarea-vim-discovery-01 (work in 527 progress), February 2019. 529 [I-D.bernardos-sfc-discovery] 530 Bernardos, C. and A. Mourad, "Service Function discovery 531 in fog environments", draft-bernardos-sfc-discovery-02 532 (work in progress), March 2019. 534 [I-D.irtf-icnrg-ccnxmessages] 535 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 536 Format", draft-irtf-icnrg-ccnxmessages-09 (work in 537 progress), January 2019. 539 [I-D.irtf-icnrg-ccnxsemantics] 540 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 541 draft-irtf-icnrg-ccnxsemantics-10 (work in progress), 542 January 2019. 544 [I-D.kutscher-icnrg-rice] 545 Krol, M., Habak, K., Oran, D., Kutscher, D., and I. 546 Psaras, "Remote Method Invocation in ICN", draft-kutscher- 547 icnrg-rice-00 (work in progress), October 2018. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, 551 DOI 10.17487/RFC2119, March 1997, 552 . 554 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 555 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 556 "Information-Centric Networking (ICN) Research 557 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 558 . 560 Authors' Addresses 562 Mike McBride 563 Futurewei 565 Email: michael.mcbride@futurewei.com 567 Dirk Kutscher 568 Emden University 570 Email: ietf@dkutscher.net 572 Eve Schooler 573 Intel 575 Email: eve.m.schooler@intel.com 576 URI: http://www.eveschooler.com 578 Carlos J. Bernardos 579 Universidad Carlos III de Madrid 580 Av. Universidad, 30 581 Leganes, Madrid 28911 582 Spain 584 Phone: +34 91624 6236 585 Email: cjbc@it.uc3m.es 586 URI: http://www.it.uc3m.es/cjbc/