idnits 2.17.1 draft-irtf-icnrg-deployment-guidelines-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 (March 7, 2019) is 1875 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-bier-multicast-http-response-00 == Outdated reference: A later version (-15) exists of draft-irtf-icnrg-ccninfo-00 == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icn-lte-4g-02 == Outdated reference: A later version (-03) exists of draft-irtf-icnrg-icniot-02 == Outdated reference: A later version (-08) exists of draft-irtf-icnrg-terminology-02 == Outdated reference: A later version (-05) exists of draft-mendes-icnrg-dabber-02 == Outdated reference: A later version (-07) exists of draft-moiseenko-icnrg-flowclass-03 == Outdated reference: A later version (-04) exists of draft-ravi-icnrg-5gc-icn-03 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 A. Rahman 3 Internet-Draft InterDigital Communications, LLC 4 Intended status: Informational D. Trossen 5 Expires: September 8, 2019 InterDigital Europe, Ltd 6 D. Kutscher 7 University of Applied Sciences Emden/Leer 8 R. Ravindran 9 Huawei 10 March 7, 2019 12 Deployment Considerations for Information-Centric Networking (ICN) 13 draft-irtf-icnrg-deployment-guidelines-05 15 Abstract 17 Information-Centric Networking (ICN) is now reaching technological 18 maturity after many years of fundamental research and 19 experimentation. This document provides a number of deployment 20 considerations in the interest of helping the ICN community move 21 forward to the next step of live deployments. First, the major 22 deployment configurations for ICN are described including the key 23 overlay and underlay approaches. Then proposed deployment migration 24 paths are outlined to address major practical issues such as network 25 and application migration. Next, selected ICN trial experiences are 26 summarized. Finally, protocol areas that require further 27 standardization are identified to facilitate future interoperable ICN 28 deployments. 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 https://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 September 8, 2019. 47 Copyright Notice 49 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Acronyms List . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Deployment Configurations . . . . . . . . . . . . . . . . . . 8 68 4.1. Clean-slate ICN . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 8 70 4.3. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 9 71 4.3.1. Edge Network . . . . . . . . . . . . . . . . . . . . 9 72 4.3.2. Core Network . . . . . . . . . . . . . . . . . . . . 10 73 4.4. ICN-as-a-Slice . . . . . . . . . . . . . . . . . . . . . 10 74 4.5. Composite-ICN Approach . . . . . . . . . . . . . . . . . 11 75 5. Deployment Migration Paths . . . . . . . . . . . . . . . . . 12 76 5.1. Application and Service Migration . . . . . . . . . . . . 12 77 5.2. Content Delivery Network Migration . . . . . . . . . . . 13 78 5.3. Edge Network Migration . . . . . . . . . . . . . . . . . 13 79 5.4. Core Network Migration . . . . . . . . . . . . . . . . . 14 80 6. Deployment Trial Experiences . . . . . . . . . . . . . . . . 14 81 6.1. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 15 82 6.1.1. FP7 PURSUIT Efforts . . . . . . . . . . . . . . . . . 15 83 6.1.2. FP7 SAIL Trial . . . . . . . . . . . . . . . . . . . 15 84 6.1.3. NDN Testbed . . . . . . . . . . . . . . . . . . . . . 15 85 6.1.4. ICN2020 Efforts . . . . . . . . . . . . . . . . . . . 15 86 6.1.5. UMOBILE Efforts . . . . . . . . . . . . . . . . . . . 16 87 6.2. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 17 88 6.2.1. H2020 POINT and RIFE Efforts . . . . . . . . . . . . 17 89 6.2.2. H2020 FLAME Efforts . . . . . . . . . . . . . . . . . 18 90 6.2.3. CableLabs Content Delivery System . . . . . . . . . . 18 91 6.2.4. NDN IoT Trials . . . . . . . . . . . . . . . . . . . 18 92 6.2.5. NREN ICN Testbed . . . . . . . . . . . . . . . . . . 19 93 6.2.6. Doctor Testbed . . . . . . . . . . . . . . . . . . . 19 94 6.3. Composite-ICN Approach . . . . . . . . . . . . . . . . . 20 95 6.4. Summary of Deployment Trials . . . . . . . . . . . . . . 20 96 7. Deployment Issues Requiring Further Standardization . . . . . 21 97 7.1. Protocols for Application and Service Migration . . . . . 21 98 7.2. Protocols for Content Delivery Network Migration . . . . 21 99 7.3. Protocols for Edge and Core Network Migration . . . . . . 22 100 7.4. Summary of ICN Protocol Gaps and Potential Protocol 101 Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 105 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 106 12. Informative References . . . . . . . . . . . . . . . . . . . 26 107 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 35 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 110 1. Introduction 112 The ICNRG charter identifies deployment guidelines as an important 113 topic area for the ICN community. Specifically, the charter states 114 that defining concrete migration paths for ICN deployments which 115 avoid forklift upgrades, and defining practical ICN interworking 116 configurations with the existing Internet paradigm, are key topic 117 areas that require further investigation [ICNRGCharter]. Also, it is 118 well understood that results and conclusions from any mid to large- 119 scale ICN experiments in the live Internet will also provide useful 120 guidance for deployments. 122 So far, outside of some preliminary investigations such as 123 [I-D.paik-icn-deployment-considerations], there has not been much 124 progress on this topic. This document attempts to fill some of these 125 gaps by defining clear deployment configurations for ICN, and 126 associated migration pathways for these configurations. Also, 127 selected deployment trial experiences of ICN technology are 128 summarized. Recommendations are also made for potential future IETF 129 standardization of key protocol functionality that will facilitate 130 interoperable ICN deployments going forward. 132 The major configurations of possible ICN deployments are identified 133 in this document as (1) Clean-slate ICN replacement of existing 134 Internet infrastructure; (2) ICN-as-an-Overlay; (3) ICN-as-an- 135 Underlay; (4) ICN-as-a-Slice; and (5) Composite-ICN. Existing ICN 136 trial systems primarily fall under the ICN-as-an-Overlay, ICN-as-an- 137 Underlay and Composite-ICN configurations. Each of these deployment 138 configurations have their respective strengths and weaknesses. This 139 document will aim to provide guidance for current and future members 140 of the ICN community when they consider deployment of ICN 141 technologies. 143 2. Terminology 145 This document assumes readers are, in general, familiar with the 146 terms and concepts that are defined in [RFC7927] and 147 [I-D.irtf-icnrg-terminology]. In addition, this document defines the 148 following terminology: 150 Deployment - In the context of this document, deployment refers to 151 the final stage of the process of setting up an ICN network that 152 is (1) ready for useful work (e.g., transmission of end user video 153 and text) in a live environment, and (2) integrated and 154 interoperable with the Internet. We consider the Internet in its 155 widest sense where it encompasses various access networks (e.g., 156 WiFi, Mobile radio network), service edge networks (e.g., for edge 157 computing), transport networks, CDNs, core networks (e.g., Mobile 158 core network), and back-end processing networks (e.g., Data 159 Centres). However, throughout the document we typically limit the 160 discussion to edge networks, core networks and CDNs for 161 simplicity. 163 Information-Centric Networking (ICN) - A data-centric network 164 architecture where accessing data by name is the essential network 165 primitive. See [I-D.irtf-icnrg-terminology] for further 166 information. 168 Network Functions Virtualization (NFV): A networking approach 169 where network functions (e.g., firewalls, load balancers) are 170 modularized as software logic that can run on general purpose 171 hardware, and thus are specifically decoupled from the previous 172 generation of proprietary and dedicated hardware. See 173 [I-D.irtf-nfvrg-gaps-network-virtualization] for further 174 information. 176 Software-Defined Networking (SDN) - A networking approach where 177 the control and data plane for switches are separated, allowing 178 for realizing capabilities such as traffic isolation and 179 programmable forwarding actions. See [RFC7426] for further 180 information. 182 3. Acronyms List 184 API - Application Programming Interface 186 BIER - Bit Indexed Explicit Replication 188 BoF - Birds of a Feather (session) 190 CCN - Content Centric Networking 191 CCNx - Content Centric Networking 193 CDN - Content Distribution Network 195 CoAP - Constrained Application Protocol 197 DASH - Dynamic Adaptive Streaming over HTTP 199 DiffServ - Differentiated Services 201 DoS - Denial of Service 203 DTN - Delay Tolerant Networking 205 ETSI - European Telecommunication Standards Institute 207 EU - European Union 209 FP7 - 7th Framework Programme for Research and Technological 210 Development 212 HLS - HTTP Live Streaming 214 HTTP - Hyper Text Transfer Protocol 216 HTTPS- Hyper Text Transfer Protocol Secure 218 H2020- Horizon 2020 (research program) 220 ICN - Information-Centric Networking 222 ICNRG- Information-Centric Networking Research Group 224 IETF - Internet Engineering Task Force 226 IntServ - Integrated Services 228 IoT - Internet of Things 230 IP - Internet Protocol 232 IPv4 - Internet Protocol Version 4 234 IPv6 - Internet Protocol Version 6 236 IPTV - Internet Protocol Television 238 ISIS - Intermediate System to Intermediate System 239 ISP - Internet Service Provider 241 k - kilo (1000) 243 L2 - Layer 2 245 LTE - Long Term Evolution (or 4th generation cellular system) 247 MANO - Management and Orchestration 249 MEC - Mobile Edge Computing 251 Mbps - Megabits per second 253 M2M - Machine-to-Machine 255 NAP - Network Attachment Point 257 NDN - Named Data Networking 259 NETCONF - Network Configuration Protocol 261 NetInf - Network of Information 263 NFD - Named Data Networking Forwarding Daemon 265 NFV - Network Functions Virtualization 267 NICT - National Institute of Information and Communications 268 Technology of Japan 270 NR - New Radio (access network for 5G) 272 OAM - Operations and Maintenance 274 ONAP - Open Network Automation Platform 276 OSPF - Open Shortest Path First 278 PoC - Proof of Concept (demo) 280 POINT- IP Over ICN - the better IP (project) 282 qMp - Quick Mesh Project 284 QoS - Quality of Service 286 RAM - Random Access Memory 287 RAN - Radio Access Network 289 REST - Representational State Transfer (architecture) 291 RESTCONF - Representational State Transfer Configuration 292 (protocol) 294 RIFE - Architecture for an Internet For Everybody (project) 296 RIP - Routing Information Protocol 298 ROM - Read Only Memory 300 RSVP - Resource Reservation Protocol 302 RTP - Real-time Transport Protocol 304 SDN - Software-Defined Networking 306 SFC - Service Function Chaining 308 SLA - Service Level Agreement 310 TCL - Transport Convergence Layer 312 TCP - Transmission Control Protocol 314 UDP - User Datagram Protocol 316 UMOBILE - Universal Mobile-centric and Opportunistic 317 Communications Architecture 319 US - United States 321 USA - United States of America 323 VoD - Video on Demand 325 VPN - Virtual Private Network 327 WG - Working Group 329 YANG - Yet Another Next Generation (data modeling language) 331 5G - Fifth Generation (cellular network) 333 6LoWPAN - IPv6 over Low-Power Wireless Personal Area Networks 335 4. Deployment Configurations 337 In this section, we present various deployment options for ICN. 338 These are presented as "configurations" that allow for studying these 339 options further. While this document will outline experiences with 340 various of these configurations (in Section 6), we will not provide 341 an in-depth technical or commercial evaluation for any of them - for 342 this we refer to existing literature in this space such as [Tateson]. 344 4.1. Clean-slate ICN 346 ICN has often been described as a "clean-slate" approach with the 347 goal to renew or replace the complete IP infrastructure of the 348 Internet. As such, existing routing hardware as well as ancillary 349 services such as existing applications which are typically tied 350 directly to the TCP/IP protocol stack are not taken for granted. For 351 instance, a Clean-slate ICN deployment would see existing IP routers 352 being replaced by ICN-specific forwarding and routing elements, such 353 as NFD [NFD], CCN routers [Jacobson] or PURSUIT forwarding nodes 354 [IEEE_Communications]. 356 While such clean-slate replacement could be seen as exclusive for ICN 357 deployments, some ICN approaches (e.g., [POINT]) also rely on the 358 deployment of general infrastructure upgrades, in this case SDN 359 switches. Different proposals have been made for various ICN 360 approaches to enable the operation over an SDN transport 361 [Reed][CONET][C_FLOW]. 363 4.2. ICN-as-an-Overlay 365 Similarly to other significant changes to the Internet routing 366 fabric, particularly the transition from IPv4 to IPv6 or the 367 introduction of IP multicast, this deployment configuration foresees 368 the creation of an ICN overlay. Note that this overlay approach is 369 sometimes, informally, also referred to as a tunneling approach. The 370 overlay approach can be implemented directly such as ICN-over-UDP as 371 described in [CCNx_UDP]. Alternatively, the overlay can be 372 accomplished via ICN-in-L2-in-IP as in [IEEE_Communications] which 373 describes a recursive layering process. Another approach used in the 374 Network of Information (NetInf) is to define a convergence layer to 375 map NetInf semantics to HTTP [I-D.kutscher-icnrg-netinf-proto]. 376 Finally, [Overlay_ICN] describes an incremental approach to deploying 377 an ICN architecture particularly well-suited to SDN based networks by 378 also segregating ICN user and control plane traffic. 380 Regardless of the flavor, however, the overlay approach results in 381 islands of ICN deployments over existing IP-based infrastructure. 382 Furthermore, these ICN islands are typically connected to each other 383 via ICN/IP tunnels. In certain scenarios this requires 384 interoperability between existing IP routing protocols (e.g., OSPF, 385 RIP, ISIS) and ICN based ones. ICN-as-an-Overlay can be deployed 386 over the IP infrastructure in either edge or core networks. This 387 overlay approach is thus very attractive for ICN experimentation and 388 testing as it allows rapid and easy deployment of ICN over existing 389 IP networks. 391 4.3. ICN-as-an-Underlay 393 Proposals such as [POINT] and [White] outline the deployment option 394 of using an ICN underlay that would integrate with existing 395 (external) IP-based networks by deploying application layer gateways 396 at appropriate locations. The main reasons for such a configuration 397 option is the introduction of ICN technology in given islands (e.g., 398 inside a CDN or edge IoT network) to reap the benefits of native ICN 399 in terms of underlying multicast delivery, mobility support, fast 400 indirection due to location independence, in-network computing and 401 possibly more. The underlay approach thus results in islands of 402 native ICN deployments which are connected to the rest of the 403 Internet through protocol conversion gateways or proxies. Routing 404 domains are strictly separated. Outside of the ICN island, normal IP 405 routing protocols apply. Within the ICN island, ICN based routing 406 schemes apply. The gateways transfer the semantic content of the 407 messages (i.e., IP packet payload) between the two routing domains. 409 4.3.1. Edge Network 411 Native ICN networks may be located at the edge of the network where 412 the introduction of new network architectures and protocols is easier 413 in so-called greenfield deployments. In this context ICN is an 414 attractive option for scenarios such as IoT [I-D.irtf-icnrg-icniot]. 415 The integration with the current IP protocol suite takes place at an 416 application gateway/proxy at the edge network boundary, e.g., 417 translating incoming CoAP request/response transactions [RFC7252] 418 into ICN message exchanges or vice versa. Furthermore, ICN will 419 allow enhancement of the role of gateways/proxies as ICN message 420 security should be preserved through the protocol translation 421 function of a gateway/proxy and thus offer a substantial gain in 422 terms of message integrity. 424 The work in [VSER] positions ICN as an edge service gateway driven by 425 a generalized ICN based service orchestration system with its own 426 compute and network virtualization controllers to manage an ICN 427 infrastructure. The platform also offers service discovery 428 capabilities to enable user applications to discover appropriate ICN 429 service gateways. To exemplify a use case scenario, the [VSER] 430 platform shows the realization of a multi-party audio/video 431 conferencing service over such a edge cloud deployment of ICN routers 432 realized over commodity hardware platforms. This platform has also 433 been extended to offer seamless mobility and mobility as a service 434 [VSER-Mob] features. 436 4.3.2. Core Network 438 In this sub-option, a core network would utilize edge-based protocol 439 mapping onto the native ICN underlay. For instance, [POINT] proposes 440 to map HTTP transactions, or some other IP based transactions such as 441 CoAP, directly onto an ICN-based message exchange. This mapping is 442 realized at the NAP, such as realized in access points or customer 443 premise equipment, which in turn provides a standard IP interface to 444 existing user devices. The NAPs thus provides the apparent 445 perception of an IP-based core network towards any external peering 446 network. 448 The work in [White] proposes a similar deployment configuration. 449 There, the goal is to use ICN for content distribution within CDN 450 server farms. Specifically, the protocol mapping is realized at the 451 ingress of the server farm where the HTTP-based retrieval request is 452 served, while the response is delivered through a suitable egress 453 node translation. 455 4.4. ICN-as-a-Slice 457 The objective of Network slicing [NGMN-5G] is to multiplex a general 458 pool of compute, storage and bandwidth resources among multiple 459 service networks with exclusive SLA requirements on transport and 460 compute level QoS and security. This is enabled through NFV and SDN 461 technology functions that enables functional decomposition hence 462 modularity, independent scalability of control and/or the user-plane 463 functions, agility and service driven programmability. Network 464 slicing is often associated with 5G but is clearly not limited to 465 such systems. However, from a 5G perspective, the definition of 466 slicing includes access network enabling dynamic slicing the spectrum 467 resources among various services hence naturally extending itself to 468 end points and also cloud resources across multiple domains, to offer 469 end-to-end guarantees. These slices once instantiated could include 470 a mix of connectivity services like LTE-as-a-service or OTT services 471 like VoD or other IoT services through composition of a group of 472 virtual and/or physical network functions at control, user and 473 service plane level. Such a framework can also be used to realize 474 ICN slices with its own control and forwarding plane over which one 475 or more end-user services can be delivered [NGMN-Network-Slicing]. 477 The 5G next generation architecture [fiveG-23501] provides the 478 flexibility to deploy the ICN-as-a-Slice over either the edge (RAN), 479 Mobile core network, or the ICN-as-a-Slice may be deployed end-to- 480 end. Further discussions on extending the architecture presented in 481 [fiveG-23501] and the corresponding procedures in [fiveG-23502] to 482 support ICN has been provided in [I-D.ravi-icnrg-5gc-icn]. The draft 483 elaborates on two possible approaches to enable ICN. First, as an 484 edge service using the local data network (LDN) feature in 5G using 485 UPF classification functions to fast handover to the ICN forwarder; 486 the other is as a native deployment using the non-IP PDU support that 487 would allow new network layer PDU to be handed over to ICN UPFs 488 collocated with the gNB functions, without invoking any IP functions. 489 While the former deployment would still rely on 3GPP based mobility 490 functions, the later would allow mobility to be handled natively by 491 ICN. However both these deployment modes should benefit from other 492 ICN features such as in-network caching and computing. Associated 493 with this ICN user plan enablement, control plane extensions are also 494 proposed leveraging 5GC's interface to other application functions 495 (AF) to allow new network service level programmability. Such a 496 generalized network slicing framework should be able to offer service 497 slices over both IP and ICN. Coupled with the view of ICN functions 498 as being "chained service functions" [RFC7665], an ICN deployment 499 within such a slice could also be realized within the emerging 500 control plane that is targeted for adoption in future (e.g., 5G 501 mobile) network deployments. Finally, it should be noted that ICN is 502 not creating the network slice, but instead that the slice is created 503 to run an 5G-ICN instance [Ravindran]. 505 At the level of the specific technologies involved, such as ONAP 506 [ONAP] that can be used to orchestrate slices, the 5G-ICN slice 507 requires compatibility for instance at the level of the forwarding/ 508 data plane depending on if it is realized as an overlay or using 509 programmable data planes. With SDN emerging for new network 510 deployments, some ICN approaches will need to integrate with SDN as a 511 data plane forwarding function, as briefly discussed in Section 4.1. 512 Further cross domain ICN slices can also be realized using frameworks 513 such as [ONAP]. 515 4.5. Composite-ICN Approach 517 Some deployments do not clearly correspond to any of the previously 518 defined basic configurations of (1) Clean-slate ICN; (2) ICN-as-an- 519 Overlay; (3) ICN-as-an-Underlay; and (4) ICN-as-a-Slice. Or, a 520 deployment may contain a composite mixture of the properties of these 521 basic configurations. For example, the Hybrid ICN [H-ICN_1] approach 522 carries ICN names in existing IPv6 headers and does not have distinct 523 gateways or tunnels connecting ICN islands, or any other distinct 524 feature identified in the previous basic configurations. So we 525 categorize Hybrid ICN, and other approaches that do not clearly 526 correspond to one of the other basic configurations, as a Composite- 527 ICN approach. 529 5. Deployment Migration Paths 531 We now focus on the various migration paths that will have importance 532 to the various stakeholders that are usually involved in the 533 deployment of ICN networks. We can identify these stakeholders as: 535 o Application providers 537 o ISPs and service providers, both as core as well as access network 538 providers, and also ICN network providers 540 o CDN providers (due to the strong relation of the ICN proposition 541 to content delivery) 543 o End device manufacturers and users 545 Our focus is on technological aspects of such migration. Economic or 546 regulatory aspects, such as studied in [Tateson], [Techno_Economic] 547 and [Internet_Pricing] are left out of our discussion. 549 5.1. Application and Service Migration 551 The Internet supports a multitude of applications and services using 552 the many protocols defined over the packet level IP service. HTTP 553 provides one convergence point for these services with many Web 554 development frameworks based on the semantics provided by it. In 555 recent years, even services such as video delivery have been 556 migrating from the traditional RTP-over-UDP delivery to the various 557 HTTP-level streaming solutions, such as DASH [DASH] and others. 558 Nonetheless, many non-HTTP services exist, all of which need 559 consideration when migrating from the IP-based Internet to an ICN- 560 based one. 562 The underlay deployment configuration option presented in Section 4.3 563 aims at providing some level of compatibility to the existing 564 ecosystem through a proxy based message flow mapping mechanism (e.g., 565 mapping of existing HTTP/TCP/IP message flows to HTTP/ICN message 566 flows). A related approach of mapping TCP/IP to TCP/ICN message 567 flows is described in [Moiseenko]. Another approach described in 568 [Marchal] uses HTTP/NDN gateways and focuses in particular on the 569 right strategy to map HTTP to NDN to guarantee a high level of 570 compatibility with HTTP while enabling an efficient caching of Data 571 in the ICN island. The choice of approach is a design decision based 572 on how to configure the protocol stack. For example, the approach 573 described in [Moiseenko] carries the TCP layer into the ICN underlay. 575 While the [Marchal] approach terminates both HTTP and TCP at the edge 576 of the ICN underlay and maps these functionalities onto existing ICN 577 functionalities. 579 Alternatively, ICN as an overlay (Section 4.2), as well as ICN-as- 580 a-Slice (Section 4.4), allow for the introduction of the full 581 capabilities of ICN through new application/service interfaces as 582 well as operations in the network. With that, these approaches of 583 deployment are likely to aim at introducing new application/services 584 capitalizing on those ICN capabilities, such as in-network multicast 585 and/or caching. 587 Finally, [I-D.irtf-icnrg-icn-lte-4g] outlines a dual-stack end user 588 device approach that is applicable for all deployment configurations. 589 Specifically, it introduces middleware layers (called the TCL) in the 590 device that will dynamically adapt existing applications to either an 591 underlying ICN protocol stack or standard IP protocol stack. This 592 involves end device signalling with the network to determine which 593 protocol stack instance and associated middleware adaptation layers 594 to utilize for a given application transaction. 596 5.2. Content Delivery Network Migration 598 A significant number of services and applications are devoted to 599 content delivery in some form, either as video delivery, social media 600 platforms, and many others. CDNs are deployed to assist these 601 services through localizing the content requests and therefore 602 reducing latency and possibly increase utilization of available 603 bandwidth as well as reducing the load on origin servers. Similar to 604 the previous sub-section, the underlay deployment configuration 605 presented in Section 4.3 aim at providing a migration path for 606 existing CDNs. This is also highlighted in a BIER use case document 607 [I-D.ietf-bier-multicast-http-response], specifically with potential 608 benefits in terms of utilizing multicast in the delivery of content 609 but also reducing load on origin as well as delegation server. We 610 return to this benefit in the trial experiences in Section 6. 612 5.3. Edge Network Migration 614 Edge networks often see the deployment of novel network level 615 technology, e.g., in the space of IoT. Such IoT deployments have for 616 many years relied, and often still do, on proprietary protocols for 617 reasons such as increased efficiency, lack of standardization 618 incentives and others. Utilizing the underlay deployment 619 configuration in Section 4.3.1, application gateways/proxies can 620 integrate such edge deployments into IP-based services, e.g., 621 utilizing CoAP [RFC7252] based M2M platforms such as oneM2M [oneM2M] 622 or others. 624 Another area of increased edge network innovation is that of mobile 625 (access) networks, particularly in the context of the 5G Mobile 626 networks. With the proliferation of network softwarization (using 627 technologies like service orchestration frameworks leveraging NFV and 628 SDN concepts) access networks and other network segments, the ICN-as- 629 a-Slice deployment configuration in Section 4.4 provides a suitable 630 migration path for integration non-IP-based edge networks into the 631 overall system through virtue of realizing the relevant (ICN) 632 protocols in an access network slice. 634 With the advent of SDN and NFV capabilities, so-called campus or 635 site-specific deployments could see the introduction of ICN islands 636 at the edge for scenarios such as gaming or AR/VR-based deployments 637 for, e.g., smart cities or theme parks. 639 5.4. Core Network Migration 641 Migrating core networks of the Internet or Mobile networks requires 642 not only significant infrastructure renewal but also the fulfillment 643 of the key performance requirements, particularly in terms of 644 throughput. For those parts of the core network that would migrate 645 to an SDN-based optical transport the ICN-as-a-Slice deployment 646 configuration in Section 4.4 would allow the introduction of native 647 ICN solutions within slices. This would allow for isolating the ICN 648 traffic while addressing the specific ICN performance benefits, such 649 as in-network multicast or caching, and constraints, such as the need 650 for specific network elements within such isolated slices. For ICN 651 solutions that natively work on top of SDN, the underlay deployment 652 configuration in Section 4.3.2 provides an additional migration path, 653 preserving the IP-based services and applications at the edge of the 654 network, while realizing the core network routing through an ICN 655 solution (possibly itself realized in a slice of the SDN transport 656 network). 658 6. Deployment Trial Experiences 660 In this section, we will outline trial experiences, often conducted 661 within collaborative project efforts. Our focus here is on the 662 realization of the various deployment configurations identified in 663 Section 4, and we therefore categorize the trial experiences 664 according to these deployment configurations. While a large body of 665 work exists at the simulation or emulation level, we specifically 666 exclude these studies from our analysis to retain the focus on real 667 life experiences. 669 6.1. ICN-as-an-Overlay 671 6.1.1. FP7 PURSUIT Efforts 673 Although the FP7 PURSUIT [IEEE_Communications] efforts were generally 674 positioned as a Clean-slate ICN replacement of IP (Section 4.1), the 675 project realized its experimental test bed as an L2 VPN-based overlay 676 between several European, US as well as Asian sites, following the 677 overlay deployment configuration presented in Section 4.2. Software- 678 based forwarders were utilized for the ICN message exchange, while 679 native ICN applications, e.g., for video transmissions, were 680 showcased. At the height of the project efforts, about 70+ nodes 681 were active in the (overlay) network with presentations given at 682 several conferences as well as to the ICNRG. 684 6.1.2. FP7 SAIL Trial 686 The Network of Information (NetInf) is the approach to ICN developed 687 by the EU FP7 SAIL project [SAIL]. NetInf provides both name-based 688 forwarding with CCNx-like semantics and name resolution (for 689 indirection and late-binding). The NetInf architecture supports 690 different deployment options through its convergence layer such as 691 using UDP, HTTP, and even DTN underlays. In its first prototypes and 692 trials, NetInf was deployed mostly in an HTTP embedding and in a UDP 693 overlay following the overlay deployment configuration in 694 Section 4.2. Reference [SAIL_Prototyping] describes several trials 695 including a stadium environment and a multi-site testbed, leveraging 696 NetInf's Routing Hint approach for routing scalability 697 [SAIL_Content_Delivery]. 699 6.1.3. NDN Testbed 701 The Named Data Networking (NDN) is one of the research projects of 702 the National Science Foundation (NSF) of the USA as part of the 703 Future Internet Architecture (FIA) Program. The original NDN 704 proposal was positioned as a Clean-slate ICN replacement of IP 705 (Section 4.1). However, in several trials, NDN generally follows the 706 overlay deployment configuration of Section 4.2 to connect 707 institutions over the public Internet across several continents. The 708 use cases covered in the trials include real-time video-conferencing, 709 geo-locating, and interfacing to consumer applications. Typical 710 trials involve up to 100 NDN enabled nodes [NDN-testbed] [Jangam]. 712 6.1.4. ICN2020 Efforts 714 ICN2020 is an ICN related project of the EU H2020 research program 715 and NICT [ICN2020-overview]. ICN2020 has a specific focus to advance 716 ICN towards real-world deployments through applications such as video 717 delivery, interactive videos and social networks. The federated 718 testbed spans the USA, Europe and Japan. Both NDN and CCN approaches 719 are within the scope of the project. 721 ICN2020 has released a set of interim public technical reports 722 [ICN2020]. The report [ICN2020-Experiments] contains a detailed 723 description of the progress made in both local testbeds as well as 724 federated testbeds. The plan for the federated testbed includes 725 integrating the NDN testbed, the CUTEi testbed [RFC7945] [CUTEi] and 726 the GEANT testbed [GEANT] to create an overlay deployment 727 configuration of Section 4.2 over the public Internet. The total 728 network contains 37 nodes. Since video was an important application 729 typical throughput was measured in certain scenarios and found to be 730 in the order of 70 Mbps per node. 732 6.1.5. UMOBILE Efforts 734 UMOBILE is another of the ICN research projects under the H2020 735 research program [UMOBILE-overview]. The UMOBILE architecture 736 integrates the principles of DTN and ICN in a common framework to 737 support edge computing and mobile opportunistic wireless environments 738 (e.g., post-disaster scenarios and remote areas). The UMOBILE 739 architecture [UMOBILE-2] was developed on top of the NDN framework by 740 following the overlay deployment configuration of Section 4.2. 741 UMOBILE aims to extend Internet functionally by combining ICN and DTN 742 technologies. 744 One of the key aspects of UMOBILE was the extension of the NDN 745 framework to locate network services (e.g., mobility management, 746 intermittent connectivity support) and user services (e.g., pervasive 747 content management) as close as possible to the end-users to optimize 748 bandwidth utilization and resource management. Another aspect was 749 the evolution of the NDN framework to operate in challenging wireless 750 networks, namely in emergency scenarios [UMOBILE-3] and environments 751 with intermittent connectivity. To achieve this, the NDN framework 752 was leveraged with a new messaging application called Oi! 753 [UMOBILE-4] [UMOBILE-5] that supports intermittent wireless 754 networking. UMOBILE also implements a new data-centric wireless 755 routing protocol, DABBER [UMOBILE-6] [I-D.mendes-icnrg-dabber], which 756 was designed based on data reachability metrics that take into 757 consideration availability of adjacent wireless nodes and different 758 data sources. The contextual-awareness of the wireless network 759 operation is obtained via a machine learning agent running within the 760 wireless nodes [UMOBILE-7]. 762 The consortium has completed several ICN deployment trails. In a 763 post disaster scenario trial [UMOBILE-8], a special DTN face was 764 created to provide reachability to remote areas where there is no 765 typical Internet connection. Another trail was the ICN deployment 766 over the "Guifi.net" community network in the Barcelona region. This 767 trial focused on the evaluation of ICN edge computing platform, 768 called PiCasso [UMOBILE-9]. In this trial, ten (10) raspberry Pis 769 were deployed across Barcelona to create an ICN overlay network on 770 top of the existing IP routing protocol (e.g., qMp routing). This 771 trial showed that ICN can play a key role in improving data delivery 772 QoS as well as reducing the traffic in intermittent connectivity 773 environments (e.g., wireless community network). A third trial in 774 Italy was focused on displaying the capability of the UMOBILE 775 architecture to reach disconnected areas and assist responsible 776 authorities in emergencies, corresponding to an infrastructure 777 scenario. The demonstration encompassed seven (7) end-user devices, 778 one (1) access-point, and one (1) gateway. 780 6.2. ICN-as-an-Underlay 782 6.2.1. H2020 POINT and RIFE Efforts 784 POINT and RIFE are two more ICN related research projects of the 785 H2020 research program. The efforts in the H2020 POINT+RIFE projects 786 follow the underlay deployment configuration in Section 4.3.2, edge- 787 based NAPs provide the IP/HTTP-level protocol mapping onto ICN 788 protocol exchanges, while the SDN underlay (or the VPN-based L2 789 underlay) is used as a transport network. 791 The multicast as well as service endpoint surrogate benefits in HTTP- 792 based scenarios, such as for HTTP-level streaming video delivery, 793 have been demonstrated in the deployed POINT test bed with 80+ nodes 794 being utilized. Demonstrations of this capability have been given to 795 the ICNRG, and public demonstrations were also provided at events 796 [MWC_Demo]. The trial has also been accepted by the ETSI MEC group 797 as a public proof-of-concept demonstration. 799 While the afore-mentioned demonstrations all use the overlay 800 deployment, H2020 also has performed ICN underlay trials. One such 801 trial involved commercial end users located in the Primetel network 802 in Cyprus with the use case centered on IPTV and HLS video 803 dissemination. Another trial was performed over the "Guifi.net" 804 community network in the Barcelona region, where the solution was 805 deployed in 40 households, providing general Internet connectivity to 806 the residents. Standard IPTV STBs as well as HLS video players were 807 utilized in accordance with the aim of this deployment configuration, 808 namely to provide application and service migration. 810 6.2.2. H2020 FLAME Efforts 812 The H2020 FLAME efforts concentrate on providing an experimental 813 ground for the aforementioned POINT/RIFE solution in initially two 814 city-scale locations, namely in Bristol and Barcelona. This trial 815 followed the underlay deployment configuration in Section 4.3.2 as 816 per POINT/RIFE approach. Experiments were conducted with the city/ 817 university joint venture Bristol-is-Open (BIO), to ensure the 818 readiness of the city-scale SDN transport network for such 819 experiments. Another trial was for the ETSI MEC PoC. This trial 820 showcased operational benefits provided by the ICN underlay for the 821 scenario of a location-based game. These benefits aim at reduced 822 network utilization through improved video delivery performance 823 (multicast of all captured videos to the service surrogates deployed 824 in the city at six locations) as well as reduced latency through the 825 playout of the video originating from the local NAP, collocated with 826 the WiFi AP instead of a remote server, i.e., the playout latency was 827 bounded by the maximum single hop latency. 829 Twenty three (23) large-scale media service experiments are planned 830 as part of the H2020 FLAME efforts in the area of Future Media 831 Internet (FMI). The platform, which includes the ICN capabilities 832 integrated with NFV and SDN capabilities of the infrastructure. The 833 ultimate goal of these platform efforts is the full integration of 834 ICN into the overall media function platform for the provisioning of 835 advanced (media-centric) Internet services. 837 6.2.3. CableLabs Content Delivery System 839 The Cablelabs ICN work reported in [White] proposes an underlay 840 deployment configuration based on Section 4.3.2. The use case is ICN 841 for content distribution within complex CDN server farms to leverage 842 ICN's superior in-network caching properties. This "island of ICN" 843 based CDN is then used to service standard HTTP/IP-based content 844 retrieval request coming from the general Internet. This approach 845 acknowledges that whole scale replacement (see Section 4.1) of 846 existing HTTP/IP end user applications and related Web infrastructure 847 is a difficult proposition. [White] is clear that the architecture 848 proposed had not yet been tested experimentally but that 849 implementations were in process and expected in the 3-5 year time 850 frame. 852 6.2.4. NDN IoT Trials 854 [Baccelli] summarizes the trial of an NDN system adapted specifically 855 for a wireless IoT scenario. The trial was run with 60 nodes 856 distributed over several multi-story buildings in a university campus 857 environment. The NDN protocols were optimized to run directly over 858 6LoWPAN wireless link layers. The performance of the NDN based IoT 859 system was then compared to an equivalent system running standard IP 860 based IoT protocols. It was found that the NDN based IoT system was 861 superior in several respects including in terms of energy 862 consumption, and for RAM and ROM footprints [Baccelli] 863 [Anastasiades]. For example, the binary file size reductions for NDN 864 protocol stack versus standard IP based IoT protocol stack on given 865 devices were up to 60% less for ROM size and up to 80% less for RAM 866 size. 868 6.2.5. NREN ICN Testbed 870 The National Research and Education Network (NREN) ICN Testbed is a 871 project sponsored by Cisco, Internet2, and the US Research and 872 Education community. Participants include universities and US 873 federal government entities that connect via a nation-wide VPN-based 874 L2 underlay. The testbed uses the CCN approach and is based on the 875 [CICN] open source software. There are approximately 15 nodes spread 876 across the USA which connect to the testbed. The project's current 877 focus is to advance data-intensive science and network research by 878 improving data movement, searchability, and accessibility. 880 6.2.6. Doctor Testbed 882 The Doctor project is a French research project meaning "Deployment 883 and Securisation of new Functionalities in Virtualized Networking 884 Environments". The project aims to run NDN over virtualized NFV 885 infrastructure [Doctor] (based on Docker technology) and focuses on 886 the NFV MANO aspects to build an operational NDN network focusing on 887 important performance criteria such as security, performance and 888 interoperability. 890 The data-plane relies on a HTTP/NDN gateway [Marchal] that processes 891 HTTP traffic and transports it in an optimized way over NDN to 892 benefit from the properties of the NDN-island (i.e., by mapping HTTP 893 semantics to NDN semantics within the NDN-island). The testbed 894 carries real Web traffic of users, and has been currently evaluated 895 with the top-1000 most popular Web sites. The users only need to set 896 the gateway as the Web proxy. The control-plane relies on a central 897 manager which uses machine learning based detection methods [Mai-1] 898 from the date gathered by distributed probes and applies orchestrated 899 counter-measures against NDN attacks [Nguyen-1] [Nguyen-2] [Mai-2] or 900 performance issues. A remediation can be, for example, the scale-up 901 of a bottleneck component, or the deployment of a security function 902 like a firewall or a signature verification module. Test results 903 thus far have indicated that key attacks can be detected accurately. 904 For example, content poisioning attacks can be detected at up to over 905 95% accuracy (with less than 0.01% false positives) [Nguyen-3]. 907 6.3. Composite-ICN Approach 909 Hybrid ICN [H-ICN_1] [H-ICN_2] is an approach where the ICN names are 910 mapped to IPv6 addresses, and other ICN information is carried as 911 payload inside the IP packet. This allows standard (ICN-unaware) IP 912 routers to forward packets based on IPv6 info, but enables ICN-aware 913 routers to apply ICN semantics. The intent is to enable rapid hybrid 914 deployments and seamless interconnection of IP and Hybrid ICN 915 domains. Hybrid ICN uses [CICN] open source software. Initial tests 916 have been done with 150 clients consuming DASH videos which showed 917 good scalability properties at the Server Side using the Hybrid ICN 918 transport [H-ICN_3] [H-ICN_2]. 920 6.4. Summary of Deployment Trials 922 In summary, there have been significant trials over the years with 923 all the major ICN protocol flavors (e.g., CCN, NDN, POINT) using both 924 the ICN-as-an-Overlay and ICN-as-an-Underlay deployment 925 configurations. The major limitations of the trials include the fact 926 that only a limited number of applications have been tested. 927 However, the tested applications include both native ICN and existing 928 IP based applications (e.g., video-conferencing and IPTV). Another 929 limitation of the trials is that all of them involve less than 1k 930 users. 932 The ICN-as-a-Slice configuration has just started being trialled by 933 Huawei and China Unicom to demonstrate ICN features of security, 934 mobility and bandwidth efficiency over a wired infrastructure using 935 video conferencing as the application scenario [Chakraborti], also 936 this prototype has been extended to demonstrate this over a 5G-NR 937 access. 939 The Clean-slate ICN approach has obviously never been trialled as 940 complete replacement of Internet infrastructure (e.g., existing 941 applications, TCP/IP protocol stack, IP routers, etc.) is no longer 942 considered a viable alternative. 944 Finally, Hybrid ICN is a Composite-ICN approach that offers an 945 interesting alternative as it allows ICN semantics to be embedded in 946 standard IPv6 packets so the packets can be routed through either IP 947 routers or Hybrid ICN routers. Note that some other trials such as 948 the Doctor testbed (Section 6.2.6) could also be characterized as a 949 Composite-ICN approach because it contains both ICN gateways (as in 950 ICN-as-an-Underlay) and virtualized infrastructure (as in ICN-as- 951 a-Slice). However, for the Doctor testbed we have chosen to 952 characterize it as an ICN-as-an-Underlay configuration because that 953 is a dominant characteristic. 955 7. Deployment Issues Requiring Further Standardization 957 The ICN Research Challenges [RFC7927] describes key ICN principles 958 and technical research topics. As the title suggests, [RFC7927] is 959 research oriented without a specific focus on deployment or 960 standardization issues. This section addresses this open area by 961 identifying key protocol functionality that that may be relevant for 962 further standardization effort in IETF. The focus is specifically on 963 identifying protocols that will facilitate future interoperable ICN 964 deployments correlating to the scenarios identified in the deployment 965 migration paths in Section 5. The identified list of potential 966 protocol functionality is not exhaustive. 968 7.1. Protocols for Application and Service Migration 970 End user applications and services need a standardized approach to 971 trigger ICN transactions. For example, in Internet and Web 972 applications today, there are established socket APIs, communication 973 paradigms such as REST, common libraries, and best practices. We see 974 a need to study application requirements in an ICN environment 975 further and, at the same time, develop new APIs and best practices 976 that can take advantage of ICN communication characteristics. 978 7.2. Protocols for Content Delivery Network Migration 980 A key issue in CDNs is to quickly find a location of a copy of the 981 object requested by an end user. In ICN, a Named Data Object (NDO) 982 is typically defined by its name. [RFC6920] defines a mechanism that 983 is suitable for static naming of ICN data objects. Other ways of 984 encoding and representing ICN names have been described in 985 [I-D.irtf-icnrg-ccnxmessages] and [I-D.irtf-icnrg-ccnxsemantics]. 986 Naming dynamically generated data requires different approaches 987 (e.g., hash digest based names would normally not work), and there is 988 lack of established conventions and standards. 990 Another CDN issue for ICN is related to multicast distribution of 991 content. Existing CDNs have started using multicast mechanisms for 992 certain cases such as for broadcast streaming TV. However, as 993 discussed in Section 6.2.1, certain ICN approaches provide 994 substantial improvements over IP multicast, such as the implicit 995 support for multicast retrieval of content in all ICN flavours. 997 Caching is an implicit feature in many ICN architectures that can 998 improve performance and availability in several scenarios. The ICN 999 in-network caching can augment managed CDN and improve its 1000 performance. The details of the interplay between ICN caching and 1001 managed CDN need further consideration. 1003 7.3. Protocols for Edge and Core Network Migration 1005 ICN provides the potential to redesign current edge and core network 1006 computing approaches. Leveraging ICN's inherent security and its 1007 ability to make name data and dynamic computation results available 1008 independent of location, can enable a light-weight insertion of 1009 traffic into the network without relying on redirection of DNS 1010 requests. For this, proxies that translate from commonly used 1011 protocols in the general Internet to ICN message exchanges in the ICN 1012 domain could be used for the migration of application and services 1013 within deployments at the network edge but also in core networks. 1014 This is similar to existing approaches for IoT scenarios where a 1015 proxy translates CoAP request/responses to other message formats. 1016 For example, [RFC8075] specifies proxy mapping between CoAP and HTTP 1017 protocols. Further work is required to identify the best approaches 1018 to evolve the role of gateways/proxies so that ICN message security 1019 is preserved through the protocol translation function. 1021 Interaction and interoperability between existing IP routing 1022 protocols (e.g., OSPF, RIP, ISIS) and ICN routing approaches(e.g., 1023 NFD, CCN routers) are expected especially in the overlay approach. 1024 Another important topic is the integration of ICN into networks that 1025 support virtualized infrastructure in the form of NFV/SDN and most 1026 likely utilizing SFC as a key protocol. Further work is required to 1027 validate this idea and document best practices. 1029 There are several existing approaches to supporting QoS in IP 1030 networks including DiffServ, IntServ and RSVP. Some initial ideas 1031 for QoS support in ICN networks are outlined in 1032 [I-D.moiseenko-icnrg-flowclass] which proposes a flow classification 1033 based approach to enable functions such ICN rate control and cache 1034 control. Also [I-D.anilj-icnrg-icn-qos] proposes how to use DiffServ 1035 DSCP codes to support QoS for ICN based data path delivery. Further 1036 work is required to identify the best approaches for support of QoS 1037 in ICN networks. 1039 OAM is a crucial area that has not yet been fully addressed by the 1040 ICN research community, but which is obviously critical for future 1041 deployments of ICN. Potential areas that need investigation include 1042 whether the YANG data modelling approach and associated NETCONF/ 1043 RESTCONF protocols need any specific updates for ICN support. 1044 Another open area is how to measure and benchmark performance of ICN 1045 networks comparable to the sophisticated techniques that exist for 1046 standard IP networks, virtualized networks and data centers. It 1047 should be noted that some initial progress has been made in the area 1048 of ICN network path traceroute facility with approaches such as 1049 CCNinfo [I-D.irtf-icnrg-ccninfo] [Contrace]. 1051 7.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts 1053 Without claiming completeness, Table 1 maps the open ICN issues 1054 identified in this document to potential protocol efforts that could 1055 address some aspects of the gap. 1057 +--------------+----------------------------------------------------+ 1058 | ICN Gap | Potential Protocol Effort | 1059 +--------------+----------------------------------------------------+ 1060 | 1-Support of | HTTP/CoAP support of ICN semantics | 1061 | REST APIs | | 1062 | | | 1063 | 2-Naming | Dynamic naming of ICN data objects | 1064 | | | 1065 | 3-Routing | Interactions between IP and ICN routing protocols | 1066 | | | 1067 | 4-Multicast | Multicast enhancements for ICN | 1068 | distribution | | 1069 | | | 1070 | 5-In-network | ICN Cache placement and sharing | 1071 | caching | | 1072 | | | 1073 | 6-NFV/SDN | Integration of ICN with NFV/SDN and including | 1074 | support | possible impacts to SFC | 1075 | | | 1076 | 7-ICN | Mapping of HTTP and other protocols onto ICN | 1077 | mapping | message exchanges (and vice-versa) while | 1078 | | preserving ICN message security | 1079 | | | 1080 | 8-QoS | Support of ICN QoS via mechanisms such as DiffServ | 1081 | support | and flow classification | 1082 | | | 1083 | 9-OAM | YANG models, NETCONF/RESTCONF protocols, | 1084 | support | and network performance measurements | 1085 | | | 1086 +--------------+----------------------------------------------------+ 1088 Table 1: Mapping of ICN Gaps to Potential Protocol Efforts 1090 8. Conclusion 1092 This document provides high level deployment considerations for 1093 current and future members of the ICN community. Specifically, the 1094 major configurations of possible ICN deployments are identified as 1095 (1) Clean-slate ICN replacement of existing Internet infrastructure; 1096 (2) ICN-as-an-Overlay; (3) ICN-as-an-Underlay; (4) ICN-as-a-Slice; 1097 and (5) Composite-ICN. Existing ICN trial systems primarily fall 1098 under the ICN-as-an-Overlay, ICN-as-an-Underlay and Composite-ICN 1099 configurations. 1101 In terms of deployment migration paths, ICN-as-an-Underlay offers a 1102 clear migration path for CDN, edge or core networks to go to an ICN 1103 paradigm (e.g., for an IoT deployment) while leaving the critical 1104 mass of existing end user applications untouched. ICN-as-an-Overlay 1105 is the easiest configuration to deploy rapidly as it leaves the 1106 underlying IP infrastructure essentially untouched. However, its 1107 applicability for general deployment must be considered on a case by 1108 case basis (e.g., can it support all required user applications). 1109 ICN-as-a-Slice is an attractive deployment option for up coming 5G 1110 systems (i.e., for 5G radio and core networks) which will naturally 1111 support network slicing, but this still has to be validated through 1112 more trial experiences. Composite-ICN, by its nature, can combine 1113 some of the best characteristics of the other configurations, but its 1114 applicability for general deployment must again be considered on a 1115 case by case basis (e.g., can enough IP routers be upgraded to 1116 support Composite-ICN functionality to provide sufficient performance 1117 benefits). 1119 There has been significant trial experience with all the major ICN 1120 protocol flavors (e.g., CCN, NDN, POINT). However, only a limited 1121 number of applications have been tested so far, and the maximum 1122 number of users in any given trial has been less than 1k users. It 1123 is recommended that future ICN deployments scale their users 1124 gradually and closely monitor network performance as they go above 1k 1125 users. A logical approach would be to increase the number of users 1126 in a slowly increasing linear manner and monitor network performance 1127 and stability especially at every multiple of 1k users. 1129 Finally, this document describes a set of technical features in ICN 1130 that warrant potential future IETF specification work. This will aid 1131 initial and incremental deployments to proceed in an interoperable 1132 manner. The fundamental details of the potential protocol 1133 specification effort, however, are best left for future study by the 1134 appropriate IETF WGs and/or BoFs. The ICNRG can aid this process in 1135 the near and mid-term by continuing to examine key system issues like 1136 QoS mechanisms, flexible naming schemes and OAM support for ICN. 1138 9. IANA Considerations 1140 This document requests no IANA actions. 1142 10. Security Considerations 1144 ICN was purposefully designed from the start to have certain 1145 intrinsic security properties. The most well known of which are 1146 authentication of delivered content and (optional) encryption of the 1147 content. [RFC7945] has an extensive discussion of various aspects of 1148 ICN security including many which are relevant to deployments. 1149 Specifically, [RFC7945] points out that ICN access control, privacy, 1150 security of in-network caches, and protection against various network 1151 attacks (e.g., DoS) have not yet been fully developed due to the lack 1152 of a sufficient mass of deployments. [RFC7945] also points out 1153 relevant advances occurring in the ICN research community that hold 1154 promise to address each of the identified security gaps. Lastly, 1155 [RFC7945] points out that as secure communications in the existing 1156 Internet (e.g., HTTPS) becomes the norm, that major gaps in ICN 1157 security will inevitably slow down the adoption of ICN. 1159 In addition to the security findings of [RFC7945], this document has 1160 highlighted that all anticipated ICN deployment configurations will 1161 involve co-existence with existing Internet infrastructure and 1162 applications. Thus even the basic authentication and encryption 1163 properties of ICN content will need to account for interworking with 1164 non-ICN content to preserve end-to-end security. For example, in the 1165 edge network underlay deployment configuration described in 1166 Section 4.3.1, the gateway/proxy that translates HTTP or CoAP 1167 request/responses into ICN message exchanges will need to support a 1168 security model to preserve end-to-end security. 1170 Finally, the Doctor project discussed in Section 6.2.6 is an example 1171 of an early deployment that is looking at specific attacks against 1172 ICN infrastructure. In this case, looking at Interest Flooding 1173 Attacks [Nguyen-2] and Content Poisoning Attacks [Nguyen-1] [Mai-2] 1174 [Nguyen-3] and evaluation of potential counter-measures based on MANO 1175 orchestrated actions on the virtualized infrastructure [Mai-1] . 1177 11. Acknowledgments 1179 The authors want to thank Alex Afanasyev, Hitoshi Asaeda, Giovanna 1180 Carofiglio, Xavier de Foy, Guillaume Doyen, Hannu Flinck, Anil 1181 Jangam, Michael Kowal, Adisorn Lertsinsrubtavee, Paulo Mendes, Luca 1182 Muscariello, Thomas Schmidt, Jan Seedorf, Eve Schooler, Samar 1183 Shailendra, Milan Stolic, Prakash Suthar, Atsushi Mayutan, and Lixia 1184 Zhang for their very useful reviews and comments to the document. 1186 Special thanks to Dave Oran (ICNRG co-chair) and Marie-Jose Montpetit 1187 for their extensive and thoughtful reviews of the document. Their 1188 reviews helped to immeasurably improve the document quality. 1190 12. Informative References 1192 [Anastasiades] 1193 Anastasiades, C., "Information-centric communication in 1194 mobile and wireless networks", PhD Dissertation, 2016, 1195 . 1197 [Baccelli] 1198 Baccelli, E. and et al., "Information Centric Networking 1199 in the IoT: Experiments with NDN in the Wild", ACM 1200 20164, Paris, France, 2014, 1201 . 1204 [C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking 1205 over OpenFlow", Open Networking Summit, April, 2012, 1206 . 1209 [CCNx_UDP] 1210 PARC, "CCNx Over UDP", 2015, 1211 . 1214 [Chakraborti] 1215 Chakraborti, A. and et al., "Design and Evaluation of a 1216 Multi-source Multi-destination Real-time Application on 1217 Content Centric Network", IEEE, HoT ICN, 2018 , 2018. 1219 [CICN] CICN, "Community Information-Centric Networking (CICN)", 1220 2017, . 1222 [CONET] Veltri, L. and et al., "CONET Project: Supporting 1223 Information-Centric Functionality in Software Defined 1224 Networks", Workshop on Software Defined Networks, , 2012, 1225 . 1228 [Contrace] 1229 Asaeda, H. and et al., "Contrace: A Tool for Measuring and 1230 Tracing Content-Centric Networks", IEEE Communications 1231 Magazine, Vol.53, No.3 , 2015. 1233 [CUTEi] Asaeda, H. and N. Choi, "Container-Based Unified Testbed 1234 for Information Centric Networking", IEEE Network, Vol.28, 1235 No.6 , 2014. 1237 [DASH] DASH, "DASH Industry Forum", 2017, . 1239 [Doctor] Doctor, "Deployment and Securisation of new 1240 Functionalities in Virtualized Networking Environments 1241 (Doctor)", 2017, 1242 . 1244 [fiveG-23501] 1245 3gpp-23.501, "Technical Specification Group Services and 1246 System Aspects; System Architecture for the 5G System 1247 (Rel.15)", 3GPP , 2017. 1249 [fiveG-23502] 1250 3gpp-23.502, "Technical Specification Group Services and 1251 System Aspects; Procedures for the 5G System (Rel.15)", 1252 3GPP , 2017. 1254 [GEANT] GEANT, "GEANT Overview", 2016, . 1256 [H-ICN_1] Cisco, "Hybrid ICN: Cisco Announces Important Steps toward 1257 Adoption of Information-Centric Networking", 2017, 1258 . 1261 [H-ICN_2] Cisco, "Mobile Video Delivery with Hybrid ICN: IP- 1262 Integrated ICN Solution for 5G", 2017, 1263 . 1267 [H-ICN_3] Muscariello, L. and et al., "Hybrid Information-Centric 1268 Networking: ICN inside the Internet Protocol", 2018, 1269 . 1273 [H-ICN_4] Sardara, M. and et al., "(h)ICN Socket Library for HTTP: 1274 Leveraging (h)ICN socket library for carrying HTTP 1275 messages", 2018, . 1279 [I-D.anilj-icnrg-icn-qos] 1280 Jangam, A., suthar, P., and M. Stolic, "Supporting QoS 1281 aware Data Delivery in Information Centric Networks", 1282 draft-anilj-icnrg-icn-qos-00 (work in progress), July 1283 2018. 1285 [I-D.ietf-bier-multicast-http-response] 1286 Purkayastha, D., Rahman, A., Trossen, D., and T. Eckert, 1287 "Applicability of BIER Multicast Overlay for Adaptive 1288 Streaming Services", draft-ietf-bier-multicast-http- 1289 response-00 (work in progress), February 2019. 1291 [I-D.irtf-icnrg-ccninfo] 1292 Asaeda, H. and X. Shao, "CCNinfo: Discovering Content and 1293 Network Information in Content-Centric Networks", draft- 1294 irtf-icnrg-ccninfo-00 (work in progress), October 2018. 1296 [I-D.irtf-icnrg-ccnxmessages] 1297 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1298 Format", draft-irtf-icnrg-ccnxmessages-09 (work in 1299 progress), January 2019. 1301 [I-D.irtf-icnrg-ccnxsemantics] 1302 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1303 draft-irtf-icnrg-ccnxsemantics-10 (work in progress), 1304 January 2019. 1306 [I-D.irtf-icnrg-icn-lte-4g] 1307 suthar, P., Stolic, M., Jangam, A., Trossen, D., and R. 1308 Ravindran, "Native Deployment of ICN in LTE, 4G Mobile 1309 Networks", draft-irtf-icnrg-icn-lte-4g-02 (work in 1310 progress), October 2018. 1312 [I-D.irtf-icnrg-icniot] 1313 Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Burke, 1314 J., Ahlgren, B., and A. Azgin, "Design Considerations for 1315 Applying ICN to IoT", draft-irtf-icnrg-icniot-02 (work in 1316 progress), October 2018. 1318 [I-D.irtf-icnrg-terminology] 1319 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 1320 D., and C. Tschudin, "Information-Centric Networking 1321 (ICN): CCN and NDN Terminology", draft-irtf-icnrg- 1322 terminology-02 (work in progress), February 2019. 1324 [I-D.irtf-nfvrg-gaps-network-virtualization] 1325 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 1326 Aranda, P., and P. Lynch, "Network Virtualization Research 1327 Challenges", draft-irtf-nfvrg-gaps-network- 1328 virtualization-10 (work in progress), September 2018. 1330 [I-D.kutscher-icnrg-netinf-proto] 1331 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 1332 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 1333 progress), February 2013. 1335 [I-D.mendes-icnrg-dabber] 1336 Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos, 1337 S., Sarros, C., Borrego, C., and J. Borrell, "Information- 1338 centric Routing for Opportunistic Wireless Networks", 1339 draft-mendes-icnrg-dabber-02 (work in progress), February 1340 2019. 1342 [I-D.moiseenko-icnrg-flowclass] 1343 Moiseenko, I. and D. Oran, "Flow Classification in 1344 Information Centric Networking", draft-moiseenko-icnrg- 1345 flowclass-03 (work in progress), January 2019. 1347 [I-D.paik-icn-deployment-considerations] 1348 Paik, E., Yun, W., Kwon, T., and h. 1349 hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for 1350 Information-Centric Networking", draft-paik-icn- 1351 deployment-considerations-00 (work in progress), July 1352 2013. 1354 [I-D.ravi-icnrg-5gc-icn] 1355 Ravindran, R., suthar, P., Trossen, D., Wang, C., and G. 1356 White, "Enabling ICN in 3GPP's 5G NextGen Core 1357 Architecture", draft-ravi-icnrg-5gc-icn-03 (work in 1358 progress), March 2019. 1360 [ICN2020] ICN2020, "ICN2020 Deliverables", 2017, 1361 . 1364 [ICN2020-Experiments] 1365 ICN2020, "Deliverable D4.1: 1st yearly report on Testbed 1366 and Experiments (WP4)", 2017, 1367 . 1370 [ICN2020-overview] 1371 ICN2020, "ICN2020 Project Overview", 2016, 1372 . 1374 [ICNRGCharter] 1375 NDN, "Information-Centric Networking Research Group 1376 Charter", 2013, 1377 . 1379 [IEEE_Communications] 1380 Trossen, D. and G. Parisis, "Designing and Realizing an 1381 Information-Centric Internet", Information-Centric 1382 Networking, IEEE Communications Magazine Special Issue, 1383 2012. 1385 [Internet_Pricing] 1386 Trossen, D. and G. Biczok, "Not Paying the Truck Driver: 1387 Differentiated Pricing for the Future Internet", ReArch 1388 Workshop in conjunction with ACM Context, December, 2010. 1390 [Jacobson] 1391 Jacobson, V. and et al., "Networking Named Content", 1392 Proceedings of ACM Context, , 2009. 1394 [Jangam] Jangam, A. and et al., "Porting and Simulation of Named- 1395 data Link State Routing Protocol into ndnSIM", ACM 1396 DIVANet'17, Miami Beach, USA, 2017, 1397 . 1399 [Mai-1] Mai, H. and et al., "Implementation of Content Poisoning 1400 Attack Detection and Reaction in Virtualized NDN 1401 Networks", 21st Conference on Innovation in Clouds, 1402 Internet and Networks, ICIN 2018 (demo paper) IEEE, 2018, 1403 . 1406 [Mai-2] Mai, H. and et al., "Towards a Security Monitoring Plane 1407 for Named Data Networking: Application to Content 1408 Poisoning Attack", Proceedings of the 2018 IEEE/IFIP 1409 Symposium on Network Operations and Management (NOMS) 1410 IEEE, 2018. 1412 [Marchal] Marchal, X. and et al., "Leveraging NFV for the Deployment 1413 of NDN: Application to HTTP Traffic Transport", 1414 Proceedings of the 2018 IEEE/IFIP Symposium on Network 1415 Operations and Management (NOMS), 2018, 1416 . 1419 [Moiseenko] 1420 Moiseenko, I. and D. Oran, "TCP/ICN : Carrying TCP over 1421 Content Centric and Named Data Networks", 2016, 1422 . 1425 [MWC_Demo] 1426 InterDigital, "InterDigital Demo at Mobile World Congress 1427 (MWC)", 2016, . 1430 [NDN-testbed] 1431 NDN Testbed, "Named Data Networking (NDN) Testbed", 2010, 1432 . 1434 [NFD] NDN, "NFD - Named Data Networking Forwarding Daemon", 1435 2017, . 1437 [NGMN-5G] NGMN, "NGMN 5G White Paper", 2015, 1438 . 1441 [NGMN-Network-Slicing] 1442 NGMN, "NGMN Description of Network Slicing Concept", 2016, 1443 . 1446 [Nguyen-1] 1447 Nguyen, T. and et al., "Content Poisoning in Named Data 1448 Networking: Comprehensive Characterization of real 1449 Deployment", Proceedings of the 15th IEEE/IFIP 1450 International Symposium on Integrated Network Management, 1451 2017. 1453 [Nguyen-2] 1454 Nguyen, T., Cogranne, R., and G. Doyen, "An Optimal 1455 Statistical Test for Robust Detection against Interest 1456 Flooding Attacks in CCN", Proceedings of the 14th IEEE/ 1457 IFIP International Symposium on Integrated Network 1458 Management, 2015. 1460 [Nguyen-3] 1461 Nguyen, T. and et al., "A Security Monitoring Plane for 1462 Named Data Networking Deployment", IEEE Communications 1463 Magazine, Nov 2018. 1465 [ONAP] ONAP, "Open Network Automation Platform", 2017, 1466 . 1468 [oneM2M] OneM2M, "oneM2M Service Layer Standards for M2M and IoT", 1469 2017, . 1471 [Overlay_ICN] 1472 Shailendra, S. and et al., "A Novel Overlay Architecture 1473 for F Networking", 2016, . 1477 [POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better 1478 IP?", European Conference on Networks and Communications 1479 (EuCNC), , 2015. 1481 [Ravindran] 1482 Ravindran, R. and et al., "5G-ICN : Delivering ICN 1483 Services over 5G using Network Slicing", IEEE 1484 Communication Magazine, May, 2016, 1485 . 1487 [Reed] Reed, M. and et al., "Stateless Multicast Switching in 1488 Software Defined Networks", ICC 2016, Kuala Lumpur, 1489 Malaysia, 2016. 1491 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1492 Keranen, A., and P. Hallam-Baker, "Naming Things with 1493 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1494 . 1496 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1497 Application Protocol (CoAP)", RFC 7252, 1498 DOI 10.17487/RFC7252, June 2014, 1499 . 1501 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1502 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1503 Defined Networking (SDN): Layers and Architecture 1504 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1505 2015, . 1507 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1508 Chaining (SFC) Architecture", RFC 7665, 1509 DOI 10.17487/RFC7665, October 2015, 1510 . 1512 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1513 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1514 "Information-Centric Networking (ICN) Research 1515 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1516 . 1518 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1519 and G. Boggia, "Information-Centric Networking: Evaluation 1520 and Security Considerations", RFC 7945, 1521 DOI 10.17487/RFC7945, September 2016, 1522 . 1524 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1525 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1526 the Constrained Application Protocol (CoAP)", RFC 8075, 1527 DOI 10.17487/RFC8075, February 2017, 1528 . 1530 [SAIL] SAIL, "Scalable and Adaptive Internet Solutions (SAIL)", 1531 2013, . 1533 [SAIL_Content_Delivery] 1534 FP7, "SAIL Content Delivery and Operations", 2013, 1535 . 1538 [SAIL_Prototyping] 1539 FP7, "SAIL Prototyping and Evaluation", 2013, 1540 . 1543 [Tateson] Tateson, J. and et al., "Final Evaluation Report on 1544 Deployment Incentives and Business Models", 2010, 1545 . 1548 [Techno_Economic] 1549 Trossen, D. and A. Kostopolous, "Techno-Economics Aspects 1550 of Information-Centric Networking", Journal for 1551 Information Policy, Volume 2, 2012. 1553 [UMOBILE-2] 1554 Sarros, C. and et al., "Connecting the Edges: A Universal, 1555 Mobile-Centric, and Opportunistic Communications 1556 Architecture", IEEE Communications Magazine, vol. 56, 1557 February 2018. 1559 [UMOBILE-3] 1560 Tavares, M., Aponte, O., and P. Mendes, "Named-data 1561 Emergency Network Services", Proc. of ACM MOBISYS, Munich, 1562 Germany, June 2018. 1564 [UMOBILE-4] 1565 Lopes, L. and et al., "Oi! - Opportunistic Data 1566 Transmission Based on Wi-Fi Direct", Proc. of IEEE 1567 INFOCOM, San Francisco, USA, April 2016. 1569 [UMOBILE-5] 1570 Dynerowicz, S. and P. Mendes, "Named-Data Networking in 1571 Opportunistic Networks", Proc. of ACM ICN, Berlin, 1572 Germany, September 2017. 1574 [UMOBILE-6] 1575 Mendes, P. and et al., "Information-centric Routing for 1576 Opportunistic Wireless Networks", Proc. of ACM ICN, 1577 Boston, USA, September 2018. 1579 [UMOBILE-7] 1580 Sofia, R., "The UMOBILE Contextual Manager Service. 1581 Technical Report. Technical Report Senception 001, 2018 1582 (base for UMOBILE deliverable D4.5 - Report on Data 1583 Collection and Inference Models", 2018. 1585 [UMOBILE-8] 1586 Sarros, C. and et al., "ICN-based edge service deployment 1587 in challenged networks", Proceedings of the 4th ACM 1588 Conference on Information-Centric Networking (ICN '17). 1589 ACM, New York, NY, USA, 2017 . 1591 [UMOBILE-9] 1592 Lertsinsrubtavee, A. and et al., "Information-Centric 1593 Multi-Access Edge Computing Platform for Community Mesh 1594 Networks", Proceedings of the 1st ACM SIGCAS Conference on 1595 Computing and Sustainable Societies (COMPASS '18). ACM, 1596 New York, NY, USA, 2018 . 1598 [UMOBILE-overview] 1599 UMOBILE, "Universal Mobile-centric and Opportunistic 1600 Communications Architecture (UMOBILE)", 2018, 1601 . 1603 [VSER] Ravindran, R. and et al., "Towards software defined ICN 1604 based edge-cloud services", 1605 CloudNetworking(CloudNet), IEEE Internation Conference on, 1606 IEEE Internation Conference on CloudNetworking(CloudNet), 1607 2013. 1609 [VSER-Mob] 1610 Azgin, A. and et al., "Seamless Mobility as a Service in 1611 Information-centric Networks", ACM ICN Sigcomm, IC5G 1612 Workshop, 2016. 1614 [White] White, G. and G. Rutz, "Content Delivery with Content 1615 Centric Networking, CableLabs White Paper", 2016, 1616 . 1620 Appendix A. Change Log 1622 [Note to RFC Editor: Please remove this section before publication.] 1624 Changes from draft-irtf-rev-04 to draft-irtf-rev-05: 1626 o Addressed detailed review comments from Marie-Jose Montpetit. 1628 Changes from draft-irtf-rev-03 to draft-irtf-rev-04: 1630 o Added text from Paulo Mendes and Adisorn Lertsinsrubtavee on 1631 UMOBILE Trial Experiences. 1633 o Incorporated off-line editorial comments from Hitoshi Asaeda and 1634 Anil Jangam. 1636 Changes from draft-irtf-rev-02 to draft-irtf-rev-03: 1638 o Editorial update of description and references of Doctor testbed 1639 as per comments from Guillaume Doyen. 1641 o Ran IETF spell checker tool and corrected various spelling errors. 1643 Changes from draft-irtf-rev-01 to draft-irtf-rev-02: 1645 o Updated description of Doctor testbed as per comments from 1646 Guillaume Doyen. Also referenced Doctor testbed from the Security 1647 Considerations section. 1649 o Added "Composite-ICN" configuration to cover the Hybrid ICN and 1650 similar configurations which do not clearly fit in one of the 1651 other basic configurations. 1653 o Updated description of the ICN-as-a-Slice configuration to clarify 1654 that it may also apply to non-5G systems. 1656 Changes from draft-irtf-rev-00 to draft-irtf-rev-01: 1658 o Added text from Michael Kowal describing NREN ICN Testbed. 1660 o Added text from Guillaume Doyen describing Doctor Project. 1662 o Updated text on Hybrid ICN based on input from Luca Muscariello. 1664 Changes from draft-rahman-rev-05 to draft-irtf-rev-00: 1666 o Changed draft status from individual draft-rahman-icnrg- 1667 deployment-guidelines-05 to RG adopted draft-irtf-icnrg- 1668 deployment-guidelines-00. 1670 Changes from rev-04 to rev-05: 1672 o Added this Change Log in Appendix A. 1674 o Removed references to Hybrid ICN from section 3.2 (ICN-as-an- 1675 Overlay definition). Instead, consolidated all Hybrid ICN info in 1676 the Deployment Trial Experiences under a new subsection 5.3 (Other 1677 Configurations). 1679 o Updated ICN2020 description in Section 5.1.4 with text received 1680 from Mayutan Arumaithurai and Hitoshi Asaeda. 1682 o Clarified in ICN-as-a-Slice description (section 3.4) that it may 1683 be deployed on either the Edge (RAN) or Core Network, or the ICN- 1684 as-a-Slice may be deployed end-to-end through the entire Mobile 1685 network. 1687 o Added several new references in various sections. 1689 o Various minor editorial updates. 1691 Authors' Addresses 1693 Akbar Rahman 1694 InterDigital Communications, LLC 1695 1000 Sherbrooke Street West, 10th floor 1696 Montreal H3A 3G4 1697 Canada 1699 Email: Akbar.Rahman@InterDigital.com 1700 URI: http://www.InterDigital.com/ 1701 Dirk Trossen 1702 InterDigital Europe, Ltd 1703 64 Great Eastern Street, 1st Floor 1704 London EC2A 3QR 1705 United Kingdom 1707 Email: Dirk.Trossen@InterDigital.com 1708 URI: http://www.InterDigital.com/ 1710 Dirk Kutscher 1711 University of Applied Sciences Emden/Leer 1712 Constantiapl. 4 1713 Emden 26723 1714 Germany 1716 Email: ietf@dkutscher.net 1717 URI: https://www.hs-emden-leer.de/en/ 1719 Ravi Ravindran 1720 Huawei Research Center 1721 2330 Central Expressway 1722 Santa Clara 95050 1723 USA 1725 Email: ravi.ravindran@huawei.com 1726 URI: http://www.Huawei.com/