idnits 2.17.1 draft-irtf-icnrg-deployment-guidelines-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 3, 2019) is 1695 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-01 == Outdated reference: A later version (-15) exists of draft-irtf-icnrg-ccninfo-02 == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icn-lte-4g-03 == Outdated reference: A later version (-08) exists of draft-irtf-icnrg-terminology-04 == 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-04 Summary: 0 errors (**), 0 flaws (~~), 7 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: March 6, 2020 InterDigital Europe, Ltd 6 D. Kutscher 7 University of Applied Sciences Emden/Leer 8 R. Ravindran 9 Futurewei 10 September 3, 2019 12 Deployment Considerations for Information-Centric Networking (ICN) 13 draft-irtf-icnrg-deployment-guidelines-07 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 March 6, 2020. 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 . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 13 80 5.4. Core Network Migration . . . . . . . . . . . . . . . . . 14 81 6. Deployment Trial Experiences . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . 35 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. 426 The work in [VSER] positions ICN as an edge service gateway driven by 427 a generalized ICN based service orchestration system with its own 428 compute and network virtualization controllers to manage an ICN 429 infrastructure. The platform also offers service discovery 430 capabilities to enable user applications to discover appropriate ICN 431 service gateways. To exemplify a use case scenario, the [VSER] 432 platform shows the realization of a multi-party audio/video 433 conferencing service over such a edge cloud deployment of ICN routers 434 realized over commodity hardware platforms. This platform has also 435 been extended to offer seamless mobility and mobility as a service 436 [VSER-Mob] features. 438 4.3.2. Core Network 440 In this sub-option, a core network would utilize edge-based protocol 441 mapping onto the native ICN underlay. For instance, [POINT] proposes 442 to map HTTP transactions, or some other IP based transactions such as 443 CoAP, directly onto an ICN-based message exchange. This mapping is 444 realized at the NAP, such as realized in access points or customer 445 premise equipment, which in turn provides a standard IP interface to 446 existing user devices. The NAPs thus provides the apparent 447 perception of an IP-based core network towards any external peering 448 network. 450 The work in [White] proposes a similar deployment configuration. 451 There, the goal is to use ICN for content distribution within CDN 452 server farms. Specifically, the protocol mapping is realized at the 453 ingress of the server farm where the HTTP-based retrieval request is 454 served, while the response is delivered through a suitable egress 455 node translation. 457 4.4. ICN-as-a-Slice 459 The objective of Network slicing [NGMN-5G] is to multiplex a general 460 pool of compute, storage and bandwidth resources among multiple 461 service networks with exclusive SLA requirements on transport and 462 compute level QoS and security. This is enabled through NFV and SDN 463 technology functions that enables functional decomposition hence 464 modularity, independent scalability of control and/or the user-plane 465 functions, agility and service driven programmability. Network 466 slicing is often associated with 5G but is clearly not limited to 467 such systems. However, from a 5G perspective, the definition of 468 slicing includes access network enabling dynamic slicing the spectrum 469 resources among various services hence naturally extending itself to 470 end points and also cloud resources across multiple domains, to offer 471 end-to-end guarantees. These slices once instantiated could include 472 a mix of connectivity services like LTE-as-a-service or OTT services 473 like VoD or other IoT services through composition of a group of 474 virtual and/or physical network functions at control, user and 475 service plane level. Such a framework can also be used to realize 476 ICN slices with its own control and forwarding plane over which one 477 or more end-user services can be delivered [NGMN-Network-Slicing]. 479 The 5G next generation architecture [fiveG-23501] provides the 480 flexibility to deploy the ICN-as-a-Slice over either the edge (RAN), 481 Mobile core network, or the ICN-as-a-Slice may be deployed end-to- 482 end. Further discussions on extending the architecture presented in 483 [fiveG-23501] and the corresponding procedures in [fiveG-23502] to 484 support ICN has been provided in [I-D.ravi-icnrg-5gc-icn]. The draft 485 elaborates on two possible approaches to enable ICN. First, as an 486 edge service using the local data network (LDN) feature in 5G using 487 UPF classification functions to fast handover to the ICN forwarder; 488 the other is as a native deployment using the non-IP PDU support that 489 would allow new network layer PDU to be handed over to ICN UPFs 490 collocated with the gNB functions, without invoking any IP functions. 491 While the former deployment would still rely on 3GPP based mobility 492 functions, the later would allow mobility to be handled natively by 493 ICN. However both these deployment modes should benefit from other 494 ICN features such as in-network caching and computing. Associated 495 with this ICN user plan enablement, control plane extensions are also 496 proposed leveraging 5GC's interface to other application functions 497 (AF) to allow new network service level programmability. Such a 498 generalized network slicing framework should be able to offer service 499 slices over both IP and ICN. Coupled with the view of ICN functions 500 as being "chained service functions" [RFC7665], an ICN deployment 501 within such a slice could also be realized within the emerging 502 control plane that is targeted for adoption in future (e.g., 5G 503 mobile) network deployments. Finally, it should be noted that ICN is 504 not creating the network slice, but instead that the slice is created 505 to run an 5G-ICN instance [Ravindran]. 507 At the level of the specific technologies involved, such as ONAP 508 [ONAP] that can be used to orchestrate slices, the 5G-ICN slice 509 requires compatibility for instance at the level of the forwarding/ 510 data plane depending on if it is realized as an overlay or using 511 programmable data planes. With SDN emerging for new network 512 deployments, some ICN approaches will need to integrate with SDN as a 513 data plane forwarding function, as briefly discussed in Section 4.1. 514 Further cross domain ICN slices can also be realized using frameworks 515 such as [ONAP]. 517 4.5. Composite-ICN Approach 519 Some deployments do not clearly correspond to any of the previously 520 defined basic configurations of (1) Clean-slate ICN; (2) ICN-as-an- 521 Overlay; (3) ICN-as-an-Underlay; and (4) ICN-as-a-Slice. Or, a 522 deployment may contain a composite mixture of the properties of these 523 basic configurations. For example, the Hybrid ICN [H-ICN_1] approach 524 carries ICN names in existing IPv6 headers and does not have distinct 525 gateways or tunnels connecting ICN islands, or any other distinct 526 feature identified in the previous basic configurations. So we 527 categorize Hybrid ICN, and other approaches that do not clearly 528 correspond to one of the other basic configurations, as a Composite- 529 ICN approach. 531 5. Deployment Migration Paths 533 We now focus on the various migration paths that will have importance 534 to the various stakeholders that are usually involved in the 535 deployment of ICN networks. We can identify these stakeholders as: 537 o Application providers 539 o ISPs and service providers, both as core as well as access network 540 providers, and also ICN network providers 542 o CDN providers (due to the strong relation of the ICN proposition 543 to content delivery) 545 o End device manufacturers and users 547 Our focus is on technological aspects of such migration. Economic or 548 regulatory aspects, such as studied in [Tateson], [Techno_Economic] 549 and [Internet_Pricing] are left out of our discussion. 551 5.1. Application and Service Migration 553 The Internet supports a multitude of applications and services using 554 the many protocols defined over the packet level IP service. HTTP 555 provides one convergence point for these services with many Web 556 development frameworks based on the semantics provided by it. In 557 recent years, even services such as video delivery have been 558 migrating from the traditional RTP-over-UDP delivery to the various 559 HTTP-level streaming solutions, such as DASH [DASH] and others. 560 Nonetheless, many non-HTTP services exist, all of which need 561 consideration when migrating from the IP-based Internet to an ICN- 562 based one. 564 The underlay deployment configuration option presented in Section 4.3 565 aims at providing some level of compatibility to the existing 566 ecosystem through a proxy based message flow mapping mechanism (e.g., 567 mapping of existing HTTP/TCP/IP message flows to HTTP/ICN message 568 flows). A related approach of mapping TCP/IP to TCP/ICN message 569 flows is described in [Moiseenko]. Another approach described in 571 [Marchal] uses HTTP/NDN gateways and focuses in particular on the 572 right strategy to map HTTP to NDN to guarantee a high level of 573 compatibility with HTTP while enabling an efficient caching of Data 574 in the ICN island. The choice of approach is a design decision based 575 on how to configure the protocol stack. For example, the approach 576 described in [Moiseenko] carries the TCP layer into the ICN underlay. 577 While the [Marchal] approach terminates both HTTP and TCP at the edge 578 of the ICN underlay and maps these functionalities onto existing ICN 579 functionalities. 581 Alternatively, ICN as an overlay (Section 4.2), as well as ICN-as- 582 a-Slice (Section 4.4), allow for the introduction of the full 583 capabilities of ICN through new application/service interfaces as 584 well as operations in the network. With that, these approaches of 585 deployment are likely to aim at introducing new application/services 586 capitalizing on those ICN capabilities, such as in-network multicast 587 and/or caching. 589 Finally, [I-D.irtf-icnrg-icn-lte-4g] outlines a dual-stack end user 590 device approach that is applicable for all deployment configurations. 591 Specifically, it introduces middleware layers (called the TCL) in the 592 device that will dynamically adapt existing applications to either an 593 underlying ICN protocol stack or standard IP protocol stack. This 594 involves end device signalling with the network to determine which 595 protocol stack instance and associated middleware adaptation layers 596 to utilize for a given application transaction. 598 5.2. Content Delivery Network Migration 600 A significant number of services and applications are devoted to 601 content delivery in some form, either as video delivery, social media 602 platforms, and many others. CDNs are deployed to assist these 603 services through localizing the content requests and therefore 604 reducing latency and possibly increase utilization of available 605 bandwidth as well as reducing the load on origin servers. Similar to 606 the previous sub-section, the underlay deployment configuration 607 presented in Section 4.3 aim at providing a migration path for 608 existing CDNs. This is also highlighted in a BIER use case document 609 [I-D.ietf-bier-multicast-http-response], specifically with potential 610 benefits in terms of utilizing multicast in the delivery of content 611 but also reducing load on origin as well as delegation server. We 612 return to this benefit in the trial experiences in Section 6. 614 5.3. Edge Network Migration 616 Edge networks often see the deployment of novel network level 617 technology, e.g., in the space of IoT. Such IoT deployments have for 618 many years relied, and often still do, on proprietary protocols for 619 reasons such as increased efficiency, lack of standardization 620 incentives and others. Utilizing the underlay deployment 621 configuration in Section 4.3.1, application gateways/proxies can 622 integrate such edge deployments into IP-based services, e.g., 623 utilizing CoAP [RFC7252] based M2M platforms such as oneM2M [oneM2M] 624 or others. 626 Another area of increased edge network innovation is that of mobile 627 (access) networks, particularly in the context of the 5G Mobile 628 networks. With the proliferation of network softwarization (using 629 technologies like service orchestration frameworks leveraging NFV and 630 SDN concepts) access networks and other network segments, the ICN-as- 631 a-Slice deployment configuration in Section 4.4 provides a suitable 632 migration path for integration non-IP-based edge networks into the 633 overall system through virtue of realizing the relevant (ICN) 634 protocols in an access network slice. 636 With the advent of SDN and NFV capabilities, so-called campus or 637 site-specific deployments could see the introduction of ICN islands 638 at the edge for scenarios such as gaming or AR/VR-based deployments 639 for, e.g., smart cities or theme parks. 641 5.4. Core Network Migration 643 Migrating core networks of the Internet or Mobile networks requires 644 not only significant infrastructure renewal but also the fulfillment 645 of the key performance requirements, particularly in terms of 646 throughput. For those parts of the core network that would migrate 647 to an SDN-based optical transport the ICN-as-a-Slice deployment 648 configuration in Section 4.4 would allow the introduction of native 649 ICN solutions within slices. This would allow for isolating the ICN 650 traffic while addressing the specific ICN performance benefits, such 651 as in-network multicast or caching, and constraints, such as the need 652 for specific network elements within such isolated slices. For ICN 653 solutions that natively work on top of SDN, the underlay deployment 654 configuration in Section 4.3.2 provides an additional migration path, 655 preserving the IP-based services and applications at the edge of the 656 network, while realizing the core network routing through an ICN 657 solution (possibly itself realized in a slice of the SDN transport 658 network). 660 6. Deployment Trial Experiences 662 In this section, we will outline trial experiences, often conducted 663 within collaborative project efforts. Our focus here is on the 664 realization of the various deployment configurations identified in 665 Section 4, and we therefore categorize the trial experiences 666 according to these deployment configurations. While a large body of 667 work exists at the simulation or emulation level, we specifically 668 exclude these studies from our analysis to retain the focus on real 669 life experiences. 671 6.1. ICN-as-an-Overlay 673 6.1.1. FP7 PURSUIT Efforts 675 Although the FP7 PURSUIT [IEEE_Communications] efforts were generally 676 positioned as a Clean-slate ICN replacement of IP (Section 4.1), the 677 project realized its experimental test bed as an L2 VPN-based overlay 678 between several European, US as well as Asian sites, following the 679 overlay deployment configuration presented in Section 4.2. Software- 680 based forwarders were utilized for the ICN message exchange, while 681 native ICN applications, e.g., for video transmissions, were 682 showcased. At the height of the project efforts, about 70+ nodes 683 were active in the (overlay) network with presentations given at 684 several conferences as well as to the ICNRG. 686 6.1.2. FP7 SAIL Trial 688 The Network of Information (NetInf) is the approach to ICN developed 689 by the EU FP7 SAIL project [SAIL]. NetInf provides both name-based 690 forwarding with CCNx-like semantics and name resolution (for 691 indirection and late-binding). The NetInf architecture supports 692 different deployment options through its convergence layer such as 693 using UDP, HTTP, and even DTN underlays. In its first prototypes and 694 trials, NetInf was deployed mostly in an HTTP embedding and in a UDP 695 overlay following the overlay deployment configuration in 696 Section 4.2. Reference [SAIL_Prototyping] describes several trials 697 including a stadium environment and a multi-site testbed, leveraging 698 NetInf's Routing Hint approach for routing scalability 699 [SAIL_Content_Delivery]. 701 6.1.3. NDN Testbed 703 The Named Data Networking (NDN) is one of the research projects of 704 the National Science Foundation (NSF) of the USA as part of the 705 Future Internet Architecture (FIA) Program. The original NDN 706 proposal was positioned as a Clean-slate ICN replacement of IP 707 (Section 4.1). However, in several trials, NDN generally follows the 708 overlay deployment configuration of Section 4.2 to connect 709 institutions over the public Internet across several continents. The 710 use cases covered in the trials include real-time video-conferencing, 711 geo-locating, and interfacing to consumer applications. Typical 712 trials involve up to 100 NDN enabled nodes [NDN-testbed] [Jangam]. 714 6.1.4. ICN2020 Efforts 716 ICN2020 is an ICN related project of the EU H2020 research program 717 and NICT [ICN2020-overview]. ICN2020 has a specific focus to advance 718 ICN towards real-world deployments through applications such as video 719 delivery, interactive videos and social networks. The federated 720 testbed spans the USA, Europe and Japan. Both NDN and CCN approaches 721 are within the scope of the project. 723 ICN2020 has released a set of interim public technical reports 724 [ICN2020]. The report [ICN2020-Experiments] contains a detailed 725 description of the progress made in both local testbeds as well as 726 federated testbeds. The plan for the federated testbed includes 727 integrating the NDN testbed, the CUTEi testbed [RFC7945] [CUTEi] and 728 the GEANT testbed [GEANT] to create an overlay deployment 729 configuration of Section 4.2 over the public Internet. The total 730 network contains 37 nodes. Since video was an important application 731 typical throughput was measured in certain scenarios and found to be 732 in the order of 70 Mbps per node. 734 6.1.5. UMOBILE Efforts 736 UMOBILE is another of the ICN research projects under the H2020 737 research program [UMOBILE-overview]. The UMOBILE architecture 738 integrates the principles of DTN and ICN in a common framework to 739 support edge computing and mobile opportunistic wireless environments 740 (e.g., post-disaster scenarios and remote areas). The UMOBILE 741 architecture [UMOBILE-2] was developed on top of the NDN framework by 742 following the overlay deployment configuration of Section 4.2. 743 UMOBILE aims to extend Internet functionally by combining ICN and DTN 744 technologies. 746 One of the key aspects of UMOBILE was the extension of the NDN 747 framework to locate network services (e.g., mobility management, 748 intermittent connectivity support) and user services (e.g., pervasive 749 content management) as close as possible to the end-users to optimize 750 bandwidth utilization and resource management. Another aspect was 751 the evolution of the NDN framework to operate in challenging wireless 752 networks, namely in emergency scenarios [UMOBILE-3] and environments 753 with intermittent connectivity. To achieve this, the NDN framework 754 was leveraged with a new messaging application called Oi! 755 [UMOBILE-4] [UMOBILE-5] that supports intermittent wireless 756 networking. UMOBILE also implements a new data-centric wireless 757 routing protocol, DABBER [UMOBILE-6] [I-D.mendes-icnrg-dabber], which 758 was designed based on data reachability metrics that take into 759 consideration availability of adjacent wireless nodes and different 760 data sources. The contextual-awareness of the wireless network 761 operation is obtained via a machine learning agent running within the 762 wireless nodes [UMOBILE-7]. 764 The consortium has completed several ICN deployment trails. In a 765 post disaster scenario trial [UMOBILE-8], a special DTN face was 766 created to provide reachability to remote areas where there is no 767 typical Internet connection. Another trail was the ICN deployment 768 over the "Guifi.net" community network in the Barcelona region. This 769 trial focused on the evaluation of ICN edge computing platform, 770 called PiCasso [UMOBILE-9]. In this trial, ten (10) raspberry Pis 771 were deployed across Barcelona to create an ICN overlay network on 772 top of the existing IP routing protocol (e.g., qMp routing). This 773 trial showed that ICN can play a key role in improving data delivery 774 QoS as well as reducing the traffic in intermittent connectivity 775 environments (e.g., wireless community network). A third trial in 776 Italy was focused on displaying the capability of the UMOBILE 777 architecture to reach disconnected areas and assist responsible 778 authorities in emergencies, corresponding to an infrastructure 779 scenario. The demonstration encompassed seven (7) end-user devices, 780 one (1) access-point, and one (1) gateway. 782 6.2. ICN-as-an-Underlay 784 6.2.1. H2020 POINT and RIFE Efforts 786 POINT and RIFE are two more ICN related research projects of the 787 H2020 research program. The efforts in the H2020 POINT+RIFE projects 788 follow the underlay deployment configuration in Section 4.3.2, edge- 789 based NAPs provide the IP/HTTP-level protocol mapping onto ICN 790 protocol exchanges, while the SDN underlay (or the VPN-based L2 791 underlay) is used as a transport network. 793 The multicast as well as service endpoint surrogate benefits in HTTP- 794 based scenarios, such as for HTTP-level streaming video delivery, 795 have been demonstrated in the deployed POINT test bed with 80+ nodes 796 being utilized. Demonstrations of this capability have been given to 797 the ICNRG, and public demonstrations were also provided at events 798 [MWC_Demo]. The trial has also been accepted by the ETSI MEC group 799 as a public proof-of-concept demonstration. 801 While the afore-mentioned demonstrations all use the overlay 802 deployment, H2020 also has performed ICN underlay trials. One such 803 trial involved commercial end users located in the Primetel network 804 in Cyprus with the use case centered on IPTV and HLS video 805 dissemination. Another trial was performed over the "Guifi.net" 806 community network in the Barcelona region, where the solution was 807 deployed in 40 households, providing general Internet connectivity to 808 the residents. Standard IPTV STBs as well as HLS video players were 809 utilized in accordance with the aim of this deployment configuration, 810 namely to provide application and service migration. 812 6.2.2. H2020 FLAME Efforts 814 The H2020 FLAME efforts concentrate on providing an experimental 815 ground for the aforementioned POINT/RIFE solution in initially two 816 city-scale locations, namely in Bristol and Barcelona. This trial 817 followed the underlay deployment configuration in Section 4.3.2 as 818 per POINT/RIFE approach. Experiments were conducted with the city/ 819 university joint venture Bristol-is-Open (BIO), to ensure the 820 readiness of the city-scale SDN transport network for such 821 experiments. Another trial was for the ETSI MEC PoC. This trial 822 showcased operational benefits provided by the ICN underlay for the 823 scenario of a location-based game. These benefits aim at reduced 824 network utilization through improved video delivery performance 825 (multicast of all captured videos to the service surrogates deployed 826 in the city at six locations) as well as reduced latency through the 827 playout of the video originating from the local NAP, collocated with 828 the WiFi AP instead of a remote server, i.e., the playout latency was 829 bounded by the maximum single hop latency. 831 Twenty three (23) large-scale media service experiments are planned 832 as part of the H2020 FLAME efforts in the area of Future Media 833 Internet (FMI). The platform, which includes the ICN capabilities 834 integrated with NFV and SDN capabilities of the infrastructure. The 835 ultimate goal of these platform efforts is the full integration of 836 ICN into the overall media function platform for the provisioning of 837 advanced (media-centric) Internet services. 839 6.2.3. CableLabs Content Delivery System 841 The Cablelabs ICN work reported in [White] proposes an underlay 842 deployment configuration based on Section 4.3.2. The use case is ICN 843 for content distribution within complex CDN server farms to leverage 844 ICN's superior in-network caching properties. This "island of ICN" 845 based CDN is then used to service standard HTTP/IP-based content 846 retrieval request coming from the general Internet. This approach 847 acknowledges that whole scale replacement (see Section 4.1) of 848 existing HTTP/IP end user applications and related Web infrastructure 849 is a difficult proposition. [White] is clear that the architecture 850 proposed had not yet been tested experimentally but that 851 implementations were in process and expected in the 3-5 year time 852 frame. 854 6.2.4. NDN IoT Trials 856 [Baccelli] summarizes the trial of an NDN system adapted specifically 857 for a wireless IoT scenario. The trial was run with 60 nodes 858 distributed over several multi-story buildings in a university campus 859 environment. The NDN protocols were optimized to run directly over 860 6LoWPAN wireless link layers. The performance of the NDN based IoT 861 system was then compared to an equivalent system running standard IP 862 based IoT protocols. It was found that the NDN based IoT system was 863 superior in several respects including in terms of energy 864 consumption, and for RAM and ROM footprints [Baccelli] 865 [Anastasiades]. For example, the binary file size reductions for NDN 866 protocol stack versus standard IP based IoT protocol stack on given 867 devices were up to 60% less for ROM size and up to 80% less for RAM 868 size. 870 6.2.5. NREN ICN Testbed 872 The National Research and Education Network (NREN) ICN Testbed is a 873 project sponsored by Cisco, Internet2, and the US Research and 874 Education community. Participants include universities and US 875 federal government entities that connect via a nation-wide VPN-based 876 L2 underlay. The testbed uses the CCN approach and is based on the 877 [CICN] open source software. There are approximately 15 nodes spread 878 across the USA which connect to the testbed. The project's current 879 focus is to advance data-intensive science and network research by 880 improving data movement, searchability, and accessibility. 882 6.2.6. Doctor Testbed 884 The Doctor project is a French research project meaning "Deployment 885 and Securisation of new Functionalities in Virtualized Networking 886 Environments". The project aims to run NDN over virtualized NFV 887 infrastructure [Doctor] (based on Docker technology) and focuses on 888 the NFV MANO aspects to build an operational NDN network focusing on 889 important performance criteria such as security, performance and 890 interoperability. 892 The data-plane relies on a HTTP/NDN gateway [Marchal] that processes 893 HTTP traffic and transports it in an optimized way over NDN to 894 benefit from the properties of the NDN-island (i.e., by mapping HTTP 895 semantics to NDN semantics within the NDN-island). The testbed 896 carries real Web traffic of users, and has been currently evaluated 897 with the top-1000 most popular Web sites. The users only need to set 898 the gateway as the Web proxy. The control-plane relies on a central 899 manager which uses machine learning based detection methods [Mai-1] 900 from the date gathered by distributed probes and applies orchestrated 901 counter-measures against NDN attacks [Nguyen-1] [Nguyen-2] [Mai-2] or 902 performance issues. A remediation can be, for example, the scale-up 903 of a bottleneck component, or the deployment of a security function 904 like a firewall or a signature verification module. Test results 905 thus far have indicated that key attacks can be detected accurately. 906 For example, content poisioning attacks can be detected at up to over 907 95% accuracy (with less than 0.01% false positives) [Nguyen-3]. 909 6.3. Composite-ICN Approach 911 Hybrid ICN [H-ICN_1] [H-ICN_2] is an approach where the ICN names are 912 mapped to IPv6 addresses, and other ICN information is carried as 913 payload inside the IP packet. This allows standard (ICN-unaware) IP 914 routers to forward packets based on IPv6 info, but enables ICN-aware 915 routers to apply ICN semantics. The intent is to enable rapid hybrid 916 deployments and seamless interconnection of IP and Hybrid ICN 917 domains. Hybrid ICN uses [CICN] open source software. Initial tests 918 have been done with 150 clients consuming DASH videos which showed 919 good scalability properties at the Server Side using the Hybrid ICN 920 transport [H-ICN_3] [H-ICN_2]. 922 6.4. Summary of Deployment Trials 924 In summary, there have been significant trials over the years with 925 all the major ICN protocol flavors (e.g., CCN, NDN, POINT) using both 926 the ICN-as-an-Overlay and ICN-as-an-Underlay deployment 927 configurations. The major limitations of the trials include the fact 928 that only a limited number of applications have been tested. 929 However, the tested applications include both native ICN and existing 930 IP based applications (e.g., video-conferencing and IPTV). Another 931 limitation of the trials is that all of them involve less than 1k 932 users. 934 The ICN-as-a-Slice configuration has just started being trialled by 935 Huawei and China Unicom to demonstrate ICN features of security, 936 mobility and bandwidth efficiency over a wired infrastructure using 937 video conferencing as the application scenario [Chakraborti], also 938 this prototype has been extended to demonstrate this over a 5G-NR 939 access. 941 The Clean-slate ICN approach has obviously never been trialled as 942 complete replacement of Internet infrastructure (e.g., existing 943 applications, TCP/IP protocol stack, IP routers, etc.) is no longer 944 considered a viable alternative. 946 Finally, Hybrid ICN is a Composite-ICN approach that offers an 947 interesting alternative as it allows ICN semantics to be embedded in 948 standard IPv6 packets so the packets can be routed through either IP 949 routers or Hybrid ICN routers. Note that some other trials such as 950 the Doctor testbed (Section 6.2.6) could also be characterized as a 951 Composite-ICN approach because it contains both ICN gateways (as in 952 ICN-as-an-Underlay) and virtualized infrastructure (as in ICN-as- 953 a-Slice). However, for the Doctor testbed we have chosen to 954 characterize it as an ICN-as-an-Underlay configuration because that 955 is a dominant characteristic. 957 7. Deployment Issues Requiring Further Standardization 959 The ICN Research Challenges [RFC7927] describes key ICN principles 960 and technical research topics. As the title suggests, [RFC7927] is 961 research oriented without a specific focus on deployment or 962 standardization issues. This section addresses this open area by 963 identifying key protocol functionality that that may be relevant for 964 further standardization effort in IETF. The focus is specifically on 965 identifying protocols that will facilitate future interoperable ICN 966 deployments correlating to the scenarios identified in the deployment 967 migration paths in Section 5. The identified list of potential 968 protocol functionality is not exhaustive. 970 7.1. Protocols for Application and Service Migration 972 End user applications and services need a standardized approach to 973 trigger ICN transactions. For example, in Internet and Web 974 applications today, there are established socket APIs, communication 975 paradigms such as REST, common libraries, and best practices. We see 976 a need to study application requirements in an ICN environment 977 further and, at the same time, develop new APIs and best practices 978 that can take advantage of ICN communication characteristics. 980 7.2. Protocols for Content Delivery Network Migration 982 A key issue in CDNs is to quickly find a location of a copy of the 983 object requested by an end user. In ICN, a Named Data Object (NDO) 984 is typically defined by its name. [RFC6920] defines a mechanism that 985 is suitable for static naming of ICN data objects. Other ways of 986 encoding and representing ICN names have been described in 987 [I-D.irtf-icnrg-ccnxmessages] and [I-D.irtf-icnrg-ccnxsemantics]. 988 Naming dynamically generated data requires different approaches 989 (e.g., hash digest based names would normally not work), and there is 990 lack of established conventions and standards. 992 Another CDN issue for ICN is related to multicast distribution of 993 content. Existing CDNs have started using multicast mechanisms for 994 certain cases such as for broadcast streaming TV. However, as 995 discussed in Section 6.2.1, certain ICN approaches provide 996 substantial improvements over IP multicast, such as the implicit 997 support for multicast retrieval of content in all ICN flavours. 999 Caching is an implicit feature in many ICN architectures that can 1000 improve performance and availability in several scenarios. The ICN 1001 in-network caching can augment managed CDN and improve its 1002 performance. The details of the interplay between ICN caching and 1003 managed CDN need further consideration. 1005 7.3. Protocols for Edge and Core Network Migration 1007 ICN provides the potential to redesign current edge and core network 1008 computing approaches. Leveraging ICN's inherent security and its 1009 ability to make name data and dynamic computation results available 1010 independent of location, can enable a light-weight insertion of 1011 traffic into the network without relying on redirection of DNS 1012 requests. For this, proxies that translate from commonly used 1013 protocols in the general Internet to ICN message exchanges in the ICN 1014 domain could be used for the migration of application and services 1015 within deployments at the network edge but also in core networks. 1016 This is similar to existing approaches for IoT scenarios where a 1017 proxy translates CoAP request/responses to other message formats. 1018 For example, [RFC8075] specifies proxy mapping between CoAP and HTTP 1019 protocols. Also, [RFC8613] is an example of how to pass end-to-end 1020 encrypted content between HTTP and COAP by an application layer 1021 security mechanism. Further work is required to identify if an 1022 [RFC8613]-like approach, or some other approach, is suitable to 1023 preserve ICN message security through future protocol translation 1024 functions of gateways/proxies. 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. One alternative 1174 would be to consider an approach similiar to [RFC8613] which is used 1175 to pass end-to-end encrypted content between HTTP and COAP by an 1176 application layer security mechanism. Further investigation is 1177 required to see if this approach is suitable to preserve ICN message 1178 security through future protocol translation functions (e.g., ICN to 1179 HTTP, or COAP to ICN) of gateways/proxies. 1181 Finally, the Doctor project discussed in Section 6.2.6 is an example 1182 of an early deployment that is looking at specific attacks against 1183 ICN infrastructure. In this case, looking at Interest Flooding 1184 Attacks [Nguyen-2] and Content Poisoning Attacks [Nguyen-1] [Mai-2] 1185 [Nguyen-3] and evaluation of potential counter-measures based on MANO 1186 orchestrated actions on the virtualized infrastructure [Mai-1] . 1188 11. Acknowledgments 1190 The authors want to thank Alex Afanasyev, Hitoshi Asaeda, Giovanna 1191 Carofiglio, Xavier de Foy, Guillaume Doyen, Hannu Flinck, Anil 1192 Jangam, Michael Kowal, Adisorn Lertsinsrubtavee, Paulo Mendes, Luca 1193 Muscariello, Thomas Schmidt, Jan Seedorf, Eve Schooler, Samar 1194 Shailendra, Milan Stolic, Prakash Suthar, Atsushi Mayutan, and Lixia 1195 Zhang for their very useful reviews and comments to the document. 1197 Special thanks to Dave Oran (ICNRG co-chair) and Marie-Jose Montpetit 1198 for their extensive and thoughtful reviews of the document. Their 1199 reviews helped to immeasurably improve the document quality. 1201 12. Informative References 1203 [Anastasiades] 1204 Anastasiades, C., "Information-centric communication in 1205 mobile and wireless networks", PhD Dissertation, 2016, 1206 . 1208 [Baccelli] 1209 Baccelli, E. and et al., "Information Centric Networking 1210 in the IoT: Experiments with NDN in the Wild", ACM 1211 20164, Paris, France, 2014, 1212 . 1215 [C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking 1216 over OpenFlow", Open Networking Summit, April, 2012, 1217 . 1220 [CCNx_UDP] 1221 PARC, "CCNx Over UDP", 2015, 1222 . 1225 [Chakraborti] 1226 Chakraborti, A. and et al., "Design and Evaluation of a 1227 Multi-source Multi-destination Real-time Application on 1228 Content Centric Network", IEEE, HoT ICN, 2018 , 2018. 1230 [CICN] CICN, "Community Information-Centric Networking (CICN)", 1231 2017, . 1233 [CONET] Veltri, L. and et al., "CONET Project: Supporting 1234 Information-Centric Functionality in Software Defined 1235 Networks", Workshop on Software Defined Networks, , 2012, 1236 . 1239 [Contrace] 1240 Asaeda, H. and et al., "Contrace: A Tool for Measuring and 1241 Tracing Content-Centric Networks", IEEE Communications 1242 Magazine, Vol.53, No.3 , 2015. 1244 [CUTEi] Asaeda, H. and N. Choi, "Container-Based Unified Testbed 1245 for Information Centric Networking", IEEE Network, Vol.28, 1246 No.6 , 2014. 1248 [DASH] DASH, "DASH Industry Forum", 2017, . 1250 [Doctor] Doctor, "Deployment and Securisation of new 1251 Functionalities in Virtualized Networking Environments 1252 (Doctor)", 2017, 1253 . 1255 [fiveG-23501] 1256 3gpp-23.501, "Technical Specification Group Services and 1257 System Aspects; System Architecture for the 5G System 1258 (Rel.15)", 3GPP , 2017. 1260 [fiveG-23502] 1261 3gpp-23.502, "Technical Specification Group Services and 1262 System Aspects; Procedures for the 5G System (Rel.15)", 1263 3GPP , 2017. 1265 [GEANT] GEANT, "GEANT Overview", 2016, . 1267 [H-ICN_1] Cisco, "Hybrid ICN: Cisco Announces Important Steps toward 1268 Adoption of Information-Centric Networking", 2017, 1269 . 1272 [H-ICN_2] Cisco, "Mobile Video Delivery with Hybrid ICN: IP- 1273 Integrated ICN Solution for 5G", 2017, 1274 . 1278 [H-ICN_3] Muscariello, L. and et al., "Hybrid Information-Centric 1279 Networking: ICN inside the Internet Protocol", 2018, 1280 . 1284 [H-ICN_4] Sardara, M. and et al., "(h)ICN Socket Library for HTTP: 1285 Leveraging (h)ICN socket library for carrying HTTP 1286 messages", 2018, . 1290 [I-D.anilj-icnrg-icn-qos] 1291 Jangam, A., suthar, P., and M. Stolic, "Supporting QoS 1292 aware Data Delivery in Information Centric Networks", 1293 draft-anilj-icnrg-icn-qos-00 (work in progress), July 1294 2018. 1296 [I-D.ietf-bier-multicast-http-response] 1297 Trossen, D., Rahman, A., Wang, C., and T. Eckert, 1298 "Applicability of BIER Multicast Overlay for Adaptive 1299 Streaming Services", draft-ietf-bier-multicast-http- 1300 response-01 (work in progress), June 2019. 1302 [I-D.irtf-icnrg-ccninfo] 1303 Asaeda, H., Ooka, A., and X. Shao, "CCNinfo: Discovering 1304 Content and Network Information in Content-Centric 1305 Networks", draft-irtf-icnrg-ccninfo-02 (work in progress), 1306 July 2019. 1308 [I-D.irtf-icnrg-ccnxmessages] 1309 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1310 Format", draft-irtf-icnrg-ccnxmessages-09 (work in 1311 progress), January 2019. 1313 [I-D.irtf-icnrg-ccnxsemantics] 1314 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 1315 draft-irtf-icnrg-ccnxsemantics-10 (work in progress), 1316 January 2019. 1318 [I-D.irtf-icnrg-icn-lte-4g] 1319 suthar, P., Stolic, M., Jangam, A., Trossen, D., and R. 1320 Ravindran, "Native Deployment of ICN in LTE, 4G Mobile 1321 Networks", draft-irtf-icnrg-icn-lte-4g-03 (work in 1322 progress), March 2019. 1324 [I-D.irtf-icnrg-icniot] 1325 Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Burke, 1326 J., Ahlgren, B., and A. Azgin, "Design Considerations for 1327 Applying ICN to IoT", draft-irtf-icnrg-icniot-03 (work in 1328 progress), May 2019. 1330 [I-D.irtf-icnrg-terminology] 1331 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 1332 D., and C. Tschudin, "Information-Centric Networking 1333 (ICN): CCN and NDN Terminology", draft-irtf-icnrg- 1334 terminology-04 (work in progress), June 2019. 1336 [I-D.irtf-nfvrg-gaps-network-virtualization] 1337 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 1338 Aranda, P., and P. Lynch, "Network Virtualization Research 1339 Challenges", draft-irtf-nfvrg-gaps-network- 1340 virtualization-10 (work in progress), September 2018. 1342 [I-D.kutscher-icnrg-netinf-proto] 1343 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 1344 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 1345 progress), February 2013. 1347 [I-D.mendes-icnrg-dabber] 1348 Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos, 1349 S., Sarros, C., Borrego, C., and J. Borrell, "Information- 1350 centric Routing for Opportunistic Wireless Networks", 1351 draft-mendes-icnrg-dabber-02 (work in progress), February 1352 2019. 1354 [I-D.moiseenko-icnrg-flowclass] 1355 Moiseenko, I. and D. Oran, "Flow Classification in 1356 Information Centric Networking", draft-moiseenko-icnrg- 1357 flowclass-04 (work in progress), July 2019. 1359 [I-D.paik-icn-deployment-considerations] 1360 Paik, E., Yun, W., Kwon, T., and h. 1361 hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for 1362 Information-Centric Networking", draft-paik-icn- 1363 deployment-considerations-00 (work in progress), July 1364 2013. 1366 [I-D.ravi-icnrg-5gc-icn] 1367 Ravindran, R., suthar, P., Trossen, D., Wang, C., and G. 1368 White, "Enabling ICN in 3GPP's 5G NextGen Core 1369 Architecture", draft-ravi-icnrg-5gc-icn-04 (work in 1370 progress), May 2019. 1372 [ICN2020] ICN2020, "ICN2020 Deliverables", 2017, 1373 . 1376 [ICN2020-Experiments] 1377 ICN2020, "Deliverable D4.1: 1st yearly report on Testbed 1378 and Experiments (WP4)", 2017, 1379 . 1382 [ICN2020-overview] 1383 ICN2020, "ICN2020 Project Overview", 2016, 1384 . 1386 [ICNRGCharter] 1387 NDN, "Information-Centric Networking Research Group 1388 Charter", 2013, 1389 . 1391 [IEEE_Communications] 1392 Trossen, D. and G. Parisis, "Designing and Realizing an 1393 Information-Centric Internet", Information-Centric 1394 Networking, IEEE Communications Magazine Special Issue, 1395 2012. 1397 [Internet_Pricing] 1398 Trossen, D. and G. Biczok, "Not Paying the Truck Driver: 1399 Differentiated Pricing for the Future Internet", ReArch 1400 Workshop in conjunction with ACM Context, December, 2010. 1402 [Jacobson] 1403 Jacobson, V. and et al., "Networking Named Content", 1404 Proceedings of ACM Context, , 2009. 1406 [Jangam] Jangam, A. and et al., "Porting and Simulation of Named- 1407 data Link State Routing Protocol into ndnSIM", ACM 1408 DIVANet'17, Miami Beach, USA, 2017, 1409 . 1411 [Mai-1] Mai, H. and et al., "Implementation of Content Poisoning 1412 Attack Detection and Reaction in Virtualized NDN 1413 Networks", 21st Conference on Innovation in Clouds, 1414 Internet and Networks, ICIN 2018 (demo paper) IEEE, 2018, 1415 . 1418 [Mai-2] Mai, H. and et al., "Towards a Security Monitoring Plane 1419 for Named Data Networking: Application to Content 1420 Poisoning Attack", Proceedings of the 2018 IEEE/IFIP 1421 Symposium on Network Operations and Management (NOMS) 1422 IEEE, 2018. 1424 [Marchal] Marchal, X. and et al., "Leveraging NFV for the Deployment 1425 of NDN: Application to HTTP Traffic Transport", 1426 Proceedings of the 2018 IEEE/IFIP Symposium on Network 1427 Operations and Management (NOMS), 2018, 1428 . 1431 [Moiseenko] 1432 Moiseenko, I. and D. Oran, "TCP/ICN : Carrying TCP over 1433 Content Centric and Named Data Networks", 2016, 1434 . 1437 [MWC_Demo] 1438 InterDigital, "InterDigital Demo at Mobile World Congress 1439 (MWC)", 2016, . 1442 [NDN-testbed] 1443 NDN Testbed, "Named Data Networking (NDN) Testbed", 2010, 1444 . 1446 [NFD] NDN, "NFD - Named Data Networking Forwarding Daemon", 1447 2017, . 1449 [NGMN-5G] NGMN, "NGMN 5G White Paper", 2015, 1450 . 1453 [NGMN-Network-Slicing] 1454 NGMN, "NGMN Description of Network Slicing Concept", 2016, 1455 . 1458 [Nguyen-1] 1459 Nguyen, T. and et al., "Content Poisoning in Named Data 1460 Networking: Comprehensive Characterization of real 1461 Deployment", Proceedings of the 15th IEEE/IFIP 1462 International Symposium on Integrated Network Management, 1463 2017. 1465 [Nguyen-2] 1466 Nguyen, T., Cogranne, R., and G. Doyen, "An Optimal 1467 Statistical Test for Robust Detection against Interest 1468 Flooding Attacks in CCN", Proceedings of the 14th IEEE/ 1469 IFIP International Symposium on Integrated Network 1470 Management, 2015. 1472 [Nguyen-3] 1473 Nguyen, T. and et al., "A Security Monitoring Plane for 1474 Named Data Networking Deployment", IEEE Communications 1475 Magazine, Nov 2018. 1477 [ONAP] ONAP, "Open Network Automation Platform", 2017, 1478 . 1480 [oneM2M] OneM2M, "oneM2M Service Layer Standards for M2M and IoT", 1481 2017, . 1483 [Overlay_ICN] 1484 Shailendra, S. and et al., "A Novel Overlay Architecture 1485 for F Networking", 2016, . 1489 [POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better 1490 IP?", European Conference on Networks and Communications 1491 (EuCNC), , 2015. 1493 [Ravindran] 1494 Ravindran, R. and et al., "5G-ICN : Delivering ICN 1495 Services over 5G using Network Slicing", IEEE 1496 Communication Magazine, May, 2016, 1497 . 1499 [Reed] Reed, M. and et al., "Stateless Multicast Switching in 1500 Software Defined Networks", ICC 2016, Kuala Lumpur, 1501 Malaysia, 2016. 1503 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1504 Keranen, A., and P. Hallam-Baker, "Naming Things with 1505 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1506 . 1508 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1509 Application Protocol (CoAP)", RFC 7252, 1510 DOI 10.17487/RFC7252, June 2014, 1511 . 1513 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1514 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1515 Defined Networking (SDN): Layers and Architecture 1516 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1517 2015, . 1519 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1520 Chaining (SFC) Architecture", RFC 7665, 1521 DOI 10.17487/RFC7665, October 2015, 1522 . 1524 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1525 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1526 "Information-Centric Networking (ICN) Research 1527 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1528 . 1530 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1531 and G. Boggia, "Information-Centric Networking: Evaluation 1532 and Security Considerations", RFC 7945, 1533 DOI 10.17487/RFC7945, September 2016, 1534 . 1536 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1537 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1538 the Constrained Application Protocol (CoAP)", RFC 8075, 1539 DOI 10.17487/RFC8075, February 2017, 1540 . 1542 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1543 "Object Security for Constrained RESTful Environments 1544 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1545 . 1547 [SAIL] SAIL, "Scalable and Adaptive Internet Solutions (SAIL)", 1548 2013, . 1550 [SAIL_Content_Delivery] 1551 FP7, "SAIL Content Delivery and Operations", 2013, 1552 . 1555 [SAIL_Prototyping] 1556 FP7, "SAIL Prototyping and Evaluation", 2013, 1557 . 1560 [Tateson] Tateson, J. and et al., "Final Evaluation Report on 1561 Deployment Incentives and Business Models", 2010, 1562 . 1565 [Techno_Economic] 1566 Trossen, D. and A. Kostopolous, "Techno-Economics Aspects 1567 of Information-Centric Networking", Journal for 1568 Information Policy, Volume 2, 2012. 1570 [UMOBILE-2] 1571 Sarros, C. and et al., "Connecting the Edges: A Universal, 1572 Mobile-Centric, and Opportunistic Communications 1573 Architecture", IEEE Communications Magazine, vol. 56, 1574 February 2018. 1576 [UMOBILE-3] 1577 Tavares, M., Aponte, O., and P. Mendes, "Named-data 1578 Emergency Network Services", Proc. of ACM MOBISYS, Munich, 1579 Germany, June 2018. 1581 [UMOBILE-4] 1582 Lopes, L. and et al., "Oi! - Opportunistic Data 1583 Transmission Based on Wi-Fi Direct", Proc. of IEEE 1584 INFOCOM, San Francisco, USA, April 2016. 1586 [UMOBILE-5] 1587 Dynerowicz, S. and P. Mendes, "Named-Data Networking in 1588 Opportunistic Networks", Proc. of ACM ICN, Berlin, 1589 Germany, September 2017. 1591 [UMOBILE-6] 1592 Mendes, P. and et al., "Information-centric Routing for 1593 Opportunistic Wireless Networks", Proc. of ACM ICN, 1594 Boston, USA, September 2018. 1596 [UMOBILE-7] 1597 Sofia, R., "The UMOBILE Contextual Manager Service. 1598 Technical Report. Technical Report Senception 001, 2018 1599 (base for UMOBILE deliverable D4.5 - Report on Data 1600 Collection and Inference Models", 2018. 1602 [UMOBILE-8] 1603 Sarros, C. and et al., "ICN-based edge service deployment 1604 in challenged networks", Proceedings of the 4th ACM 1605 Conference on Information-Centric Networking (ICN '17). 1606 ACM, New York, NY, USA, 2017 . 1608 [UMOBILE-9] 1609 Lertsinsrubtavee, A. and et al., "Information-Centric 1610 Multi-Access Edge Computing Platform for Community Mesh 1611 Networks", Proceedings of the 1st ACM SIGCAS Conference on 1612 Computing and Sustainable Societies (COMPASS '18). ACM, 1613 New York, NY, USA, 2018 . 1615 [UMOBILE-overview] 1616 UMOBILE, "Universal Mobile-centric and Opportunistic 1617 Communications Architecture (UMOBILE)", 2018, 1618 . 1620 [VSER] Ravindran, R. and et al., "Towards software defined ICN 1621 based edge-cloud services", 1622 CloudNetworking(CloudNet), IEEE Internation Conference on, 1623 IEEE Internation Conference on CloudNetworking(CloudNet), 1624 2013. 1626 [VSER-Mob] 1627 Azgin, A. and et al., "Seamless Mobility as a Service in 1628 Information-centric Networks", ACM ICN Sigcomm, IC5G 1629 Workshop, 2016. 1631 [White] White, G. and G. Rutz, "Content Delivery with Content 1632 Centric Networking, CableLabs White Paper", 2016, 1633 . 1637 Appendix A. Change Log 1639 [Note to RFC Editor: Please remove this section before publication.] 1641 Changes from draft-irtf-rev-06 to draft-irtf-rev-07: 1643 o Added reference to OSCORE (RFC 8613) which is a way of passing 1644 end-to-end encrypted content between HTTP and COAP without 1645 invalidating encryption. Thus it can be a potential model for 1646 HTTP to ICN, or COAP to ICN, to consider in the future. 1648 o Updated affiliation information for author Ravi Ravindran. 1650 Changes from draft-irtf-rev-05 to draft-irtf-rev-06: 1652 o Various updates to ensure that draft complies with RFC 5743 1653 (Definition of an Internet Research Task Force (IRTF) Document 1654 Stream) section 2.1. 1656 Changes from draft-irtf-rev-04 to draft-irtf-rev-05: 1658 o Addressed detailed review comments from Marie-Jose Montpetit. 1660 Changes from draft-irtf-rev-03 to draft-irtf-rev-04: 1662 o Added text from Paulo Mendes and Adisorn Lertsinsrubtavee on 1663 UMOBILE Trial Experiences. 1665 o Incorporated off-line editorial comments from Hitoshi Asaeda and 1666 Anil Jangam. 1668 Changes from draft-irtf-rev-02 to draft-irtf-rev-03: 1670 o Editorial update of description and references of Doctor testbed 1671 as per comments from Guillaume Doyen. 1673 o Ran IETF spell checker tool and corrected various spelling errors. 1675 Changes from draft-irtf-rev-01 to draft-irtf-rev-02: 1677 o Updated description of Doctor testbed as per comments from 1678 Guillaume Doyen. Also referenced Doctor testbed from the Security 1679 Considerations section. 1681 o Added "Composite-ICN" configuration to cover the Hybrid ICN and 1682 similar configurations which do not clearly fit in one of the 1683 other basic configurations. 1685 o Updated description of the ICN-as-a-Slice configuration to clarify 1686 that it may also apply to non-5G systems. 1688 Changes from draft-irtf-rev-00 to draft-irtf-rev-01: 1690 o Added text from Michael Kowal describing NREN ICN Testbed. 1692 o Added text from Guillaume Doyen describing Doctor Project. 1694 o Updated text on Hybrid ICN based on input from Luca Muscariello. 1696 Changes from draft-rahman-rev-05 to draft-irtf-rev-00: 1698 o Changed draft status from individual draft-rahman-icnrg- 1699 deployment-guidelines-05 to RG adopted draft-irtf-icnrg- 1700 deployment-guidelines-00. 1702 Changes from rev-04 to rev-05: 1704 o Added this Change Log in Appendix A. 1706 o Removed references to Hybrid ICN from section 3.2 (ICN-as-an- 1707 Overlay definition). Instead, consolidated all Hybrid ICN info in 1708 the Deployment Trial Experiences under a new subsection 5.3 (Other 1709 Configurations). 1711 o Updated ICN2020 description in Section 5.1.4 with text received 1712 from Mayutan Arumaithurai and Hitoshi Asaeda. 1714 o Clarified in ICN-as-a-Slice description (section 3.4) that it may 1715 be deployed on either the Edge (RAN) or Core Network, or the ICN- 1716 as-a-Slice may be deployed end-to-end through the entire Mobile 1717 network. 1719 o Added several new references in various sections. 1721 o Various minor editorial updates. 1723 Authors' Addresses 1725 Akbar Rahman 1726 InterDigital Communications, LLC 1727 1000 Sherbrooke Street West, 10th floor 1728 Montreal H3A 3G4 1729 Canada 1731 Email: Akbar.Rahman@InterDigital.com 1732 URI: http://www.InterDigital.com/ 1734 Dirk Trossen 1735 InterDigital Europe, Ltd 1736 64 Great Eastern Street, 1st Floor 1737 London EC2A 3QR 1738 United Kingdom 1740 Email: Dirk.Trossen@InterDigital.com 1741 URI: http://www.InterDigital.com/ 1742 Dirk Kutscher 1743 University of Applied Sciences Emden/Leer 1744 Constantiapl. 4 1745 Emden 26723 1746 Germany 1748 Email: ietf@dkutscher.net 1749 URI: https://www.hs-emden-leer.de/en/ 1751 Ravi Ravindran 1752 Future Technologies 1753 2330 Central Expressway 1754 Santa Clara 95050 1755 USA 1757 Email: ravi.ravindran@futurewei.com