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