idnits 2.17.1 draft-rahman-icnrg-deployment-guidelines-03.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 (August 14, 2017) is 2446 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'NGMN' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'VSER-Mob' is defined on line 1000, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-05 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-04 == Outdated reference: A later version (-10) exists of draft-irtf-nfvrg-gaps-network-virtualization-06 == Outdated reference: A later version (-04) exists of draft-suthar-icnrg-icn-lte-4g-02 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 D. Trossen 4 Intended status: Informational InterDigital Inc. 5 Expires: February 15, 2018 D. Kutscher 6 R. Ravindran 7 Huawei 8 August 14, 2017 10 Deployment Considerations for Information-Centric Networking (ICN) 11 draft-rahman-icnrg-deployment-guidelines-03 13 Abstract 15 Information-Centric Networking (ICN) is now reaching technological 16 maturity after many years of fundamental research and 17 experimentation. This document provides a number of deployment 18 considerations in the interest of helping the ICN community move 19 forward to the next step of live deployments. First, the major 20 deployment configurations for ICN are described including the main 21 overlay and underlay approaches. Then proposed deployment migration 22 paths are outlined to address major practical issues such as network 23 and application migration. Next, selected ICN trial experiences are 24 summarized. Finally, protocol areas that require further 25 standardization are identified to facilitate future interoperable ICN 26 deployments. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 15, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Deployment Configurations . . . . . . . . . . . . . . . . . . 4 65 3.1. Wholesale Replacement . . . . . . . . . . . . . . . . . . 4 66 3.2. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 5 67 3.3. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 5 68 3.3.1. Core Network . . . . . . . . . . . . . . . . . . . . 5 69 3.3.2. Edge Network . . . . . . . . . . . . . . . . . . . . 6 70 3.4. ICN-as-a-Slice . . . . . . . . . . . . . . . . . . . . . 6 71 4. Deployment Migration Paths . . . . . . . . . . . . . . . . . 7 72 4.1. Application and Service Migration . . . . . . . . . . . . 8 73 4.2. Content Delivery Network Migration . . . . . . . . . . . 8 74 4.3. Edge Network Migration . . . . . . . . . . . . . . . . . 9 75 4.4. Core Network Migration . . . . . . . . . . . . . . . . . 9 76 5. Deployment Trial Experiences . . . . . . . . . . . . . . . . 10 77 5.1. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 10 78 5.1.1. FP7 PURSUIT Efforts . . . . . . . . . . . . . . . . . 10 79 5.1.2. FP7 SAIL Trial . . . . . . . . . . . . . . . . . . . 10 80 5.1.3. NDN Testbed . . . . . . . . . . . . . . . . . . . . . 10 81 5.1.4. ICN2020 Efforts . . . . . . . . . . . . . . . . . . . 11 82 5.2. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 11 83 5.2.1. H2020 POINT and RIFE Efforts . . . . . . . . . . . . 11 84 5.2.2. H2020 FLAME Efforts . . . . . . . . . . . . . . . . . 12 85 5.2.3. CableLabs Content Delivery System . . . . . . . . . . 12 86 5.2.4. NDN IoT Trials . . . . . . . . . . . . . . . . . . . 13 87 5.3. Summary of Deployment Trials . . . . . . . . . . . . . . 13 88 6. Deployment Issues Requiring Further Standardization . . . . . 13 89 6.1. Protocols for Application and Service Migration . . . . . 14 90 6.2. Protocols for Content Delivery Network Migration . . . . 14 91 6.3. Protocols for Edge and Core Network Migration . . . . . . 14 92 6.4. Summary of ICN Protocol Gaps and Potential Protocol 93 Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 98 11. Informative References . . . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Introduction 103 The ICNRG charter identifies deployment guidelines as an important 104 topic area for the ICN community. Specifically, the charter states 105 that defining concrete migration paths for ICN deployments which 106 avoid forklift upgrades, and defining practical ICN interworking 107 configurations with the existing Internet paradigm, are key topic 108 areas that require further investigation [ICNRGCharter]. Also, it is 109 well understood that results and conclusions from any mid to large- 110 scale ICN experiments in the live Internet will also provide useful 111 guidance for deployments. 113 However, so far outside of some preliminary investigations such as 114 [I-D.paik-icn-deployment-considerations], there has not been much 115 progress on this topic. This document attempts to fill some of these 116 gaps by defining clear deployment configurations for ICN, and 117 associated migration pathways for these configurations. Also, 118 selected deployment trial experiences of ICN technology are 119 summarized. Finally, recommendations are made for potential future 120 IETF standardization of key protocol functionality that will 121 facilitate interoperable ICN deployments going forward. 123 2. Terminology 125 This document assumes readers are, in general, familiar with the 126 terms and concepts that are defined in [RFC7927]. In addition, this 127 document defines the following terminology: 129 Deployment - In the context of this document, deployment refers to 130 the final stage of the process of setting up an ICN network that 131 is (1) integrated and interoperable with the rest of the Internet, 132 and (2) ready for useful work (e.g. transmission of end user video 133 and text) in a live environment. 135 Information-Centric Networking (ICN) - A data-centric network 136 architecture where accessing data by name is the essential network 137 primitive. See [ICNterm] for further information. 139 Network Function Virtualization (NFV): A networking approach where 140 network functions (e.g. firewalls, load balancers) are modularized 141 as software logic that can run on general purpose hardware, and 142 thus are specifically decoupled from the previous generation of 143 proprietary and dedicated hardware. See 144 [I-D.irtf-nfvrg-gaps-network-virtualization] for further 145 information. 147 Software-Defined Networking (SDN) - A networking approach where 148 the control and data plane for switches are separated, allowing 149 for realizing capabilities such as traffic isolation and 150 programmable forwarding actions. See [RFC7426] for further 151 information. 153 3. Deployment Configurations 155 In this section, we present various deployment options for ICN. 156 These are presented as "configurations" that allow for studying these 157 options further. While this document will outline experiences with 158 various of these configurations (in Section 5), we will not provide 159 an in-depth technical or commercial evaluation for any of them - for 160 this we refer to existing literature in this space such as [Tateson]. 162 3.1. Wholesale Replacement 164 ICN has often been described as a "clean-slate" approach with the 165 goal to renew or replace the current IP routing fabric of the 166 Internet. As such, existing routing hardware as well as ancillary 167 services are not taken for granted. This clean-slate view is 168 reflected as deployment configurations we label as "wholesale 169 replacement" of large part of the existing Internet infrastructure. 170 For instance, such configuration would see existing IP routers being 171 replaced by ICN-specific forwarding and routing elements, such as NFD 172 (Named Data Networking Forwarding Daemon) [NFD], CCN routers 173 [Jacobson] or PURSUIT forwarding nodes [IEEE_Communications]. All 174 major ICN approaches have explored this option as one of their paths 175 to deployment. 177 While such replacement could be seen as exclusive for ICN 178 deployments, some ICN approaches [POINT] rely on the deployment of 179 infrastructure upgrades, here SDN switches. Such upgrades, while 180 being possibly utilized for a "clean slate" ICN deployment would not 181 necessary be used exclusively for an ICN deployment. Different 182 proposals have been made for various ICN approaches to enable the 183 operation over an SDN transport [Reed][CONET][C_FLOW]. 185 3.2. ICN-as-an-Overlay 187 Similar to other significant changes to the Internet routing fabric, 188 particularly the transition from IPv4 to IPv6 or the introduction of 189 IP multicast, this deployment configuration foresees the creation of 190 an ICN overlay. Note that this overlay approach is sometimes, 191 informally, also referred to as a tunneling approach. The overlay 192 approach could be done directly such as ICN-over-UDP as described in 193 [CCNx_UDP]. Alternatively, the overlay could be done via ICN-in-L2- 194 in-IP as in [IEEE_Communications] which describes a recursive 195 layering process. 197 Another flavor of overlay would be embedding ICN semantics into 198 existing protocols. A recently announced approach is [Hybrid_ICN] 199 where the ICN names are mapped to IPv6 addresses. Another approach 200 used in the Network of Information (NetInf) is to define a 201 convergence layer to map NetInf semantics to HTTP 202 [I-D.kutscher-icnrg-netinf-proto]. Regardless of the flavor, 203 however, the overlay approach results in islands of ICN deployments 204 over existing IP-based infrastructure. Furthermore, these ICN 205 islands are connected to each other via ICN/IP tunnels. This overlay 206 approach is thus very attractive for ICN experimentation and testing 207 as it allows rapid and easy deployment of ICN over existing IP 208 networks. The applicability of the overlay configuration for a 209 general deployment must be considered on a case by case basis. 211 3.3. ICN-as-an-Underlay 213 Proposals such as [POINT] and [White] outline the deployment option 214 of using an ICN underlay that would integrate with existing 215 (external) IP-based networks by deploying application layer gateways 216 at appropriate locations, while possibly still allowing for native 217 ICN applications to emerge. The main reasons for such a 218 configuration option is the introduction of ICN technology in given 219 islands (e.g., inside a CDN or edge IoT network) to reap the benefits 220 of native ICN in terms of underlying multicast delivery, mobility 221 support, fast indirection due to location independence, in-network 222 computing and possibly more. The underlay approach thus results in 223 islands of native ICN deployments which are connected to the rest of 224 the Internet through protocol conversion gateways or proxies. 226 3.3.1. Core Network 228 In this sub-option, a core network would utilize edge-based protocol 229 mapping onto the native ICN underlay. For instance, [POINT] proposes 230 to map HTTP transactions, or some other IP based transactions such as 231 CoAP, directly onto an ICN-based message exchange. This mapping is 232 realized at the network attachment point, such as realized in access 233 points or customer premise equipment, which in turn provides a 234 standard IP interface to existing user devices. Towards peering 235 networks, such network attachment point turns into a modified border 236 gateway/proxy, preserving the perception of an IP-based core network 237 towards any peering network. 239 The work in [White] proposes a similar deployment configuration. 240 Here, the target is the use of ICN for content distribution within 241 CDN server farms, i.e., the protocol mapping is realized at the 242 ingress of the server farm where the HTTP-based retrieval request is 243 served, while the response is delivered through a suitable egress 244 node translation. 246 3.3.2. Edge Network 248 Native ICN networks may be found at the edge of the network, mostly 249 proposed for Internet of Things (IoT) deployments, which allows the 250 possibility of introducing new network architectures and protocols, 251 and in this context ICN can be a possible candidate considering its 252 suitability for IoT and fixed network scenarios 253 [I-D.zhang-icnrg-icniot]. The integration with the current IP 254 protocol suite takes place at an application gateway/proxy at the 255 edge network boundary, e.g., translating incoming CoAP request/ 256 response transactions [RFC7252] into ICN message exchanges or vice 257 versa. Furthermore, ICN will allow us to evolve the role of 258 gateways/proxies as ICN message security should be preserved through 259 the protocol translation function of a gateway/proxy and thus offer a 260 substantial gain. 262 The work in [VSER] positions ICN as an edge service gateway driven by 263 a generalized ICN based service orchestration system with its own 264 compute and network virtualization controllers to manage an ICN 265 infrastructure. The platform also offers service discovery 266 capabilities to enable user applications to discover appropriate ICN 267 service gateways. To exemplify a use case scenario, the platform 268 shows the realization of a multi-party audio/video conferencing 269 service over such a edge cloud deployment of ICN routers realized 270 over commodity hardware platforms. This platform has also been 271 extended to offer seamless mobility and mobility as a service [VSER- 272 Mob] features. 274 3.4. ICN-as-a-Slice 276 The objective of Network slicing [NGMN]is to multiplex a general pool 277 of compute, storage and bandwidth resources among multiple services 278 with exclusive SLA requirements on transport level QoS and security. 279 These services could include both connectivity services like LTE-as- 280 a-service or OTT services like VoD or other IoT services. Such a 281 framework can also be used to realize ICN slices with its own control 282 and forwarding plane over which one or more end-user services can be 283 delivered. 285 An ICN slice can itself be overlaid over IP or can be underlaid using 286 generalized programmable data planes like P4/POF. Such a generalized 287 network slicing framework should be able to offer service slices to 288 be realized over both IP and ICN. Network slicing will rely heavily 289 on network softwarization and programmability using SDN/NFV 290 technologies for efficient utilization of available resources without 291 compromising on the slice requirements. Coupled with the view of ICN 292 functions as being "chained service functions" [RFC7665], an ICN 293 deployment within such a slice could be realized within the emerging 294 control plane that is targeted for adoption in future (e.g., 5th 295 generation mobile) network deployments. Finally, it should be noted 296 that ICN is not creating the network slice, but instead that the 297 slice is created to run a 5G-ICN instance [Ravindran]. 299 At the level of the specific technologies involved, the 5G-ICN slice 300 requires compatibility for instance at the level of the forwarding/ 301 data plane depending on if it is realized as an overlay or using 302 programmable data planes. With SDN emerging for new network 303 deployments, some ICN approaches will need to integrate with SDN as a 304 data plane forwarding function, as briefly discussed in Section 3.1. 306 4. Deployment Migration Paths 308 After outlining the various ICN deployment configurations in 309 Section 3, we now focus on the various migration paths that will have 310 importance to the various stakeholders that are usually involved in 311 the deployment of a technology at (ultimately) large scale. We can 312 identify these stakeholders as: 314 o Application developers and service providers 316 o ISPs, both as core as well as access network providers, and also 317 ICN network providers 319 o CDN providers (due to the strong relation of the ICN proposition 320 to content delivery) 322 Note that our presentation purely focuses on technological aspects of 323 such migration. Economic or regulatory aspects, such as studied in 324 [Tateson], [Techno_Economic] and [Internet_Pricing] are left out of 325 our discussion. 327 4.1. Application and Service Migration 329 The internet is full of applications and services, utilizing the 330 innovation capabilities of the many protocols defined over the packet 331 level IP service. HTTP provides one convergence point for these 332 services with many web development frameworks based on the semantics 333 provided by the hypertext transfer protocol. In recent years, even 334 services such as video delivery have been migrating from the 335 traditional RTP-over-UDP delivery to the various HTTP-level streaming 336 solutions, such as DASH [DASH] and others. Nonetheless, many non- 337 HTTP services exist, all of which need consideration when migrating 338 from the IP-based internet to an ICN-based one. 340 The underlay deployment configuration options presented in 341 Section 3.3.1 and Section 3.3.2 aim at providing some level of 342 backward compatibility to this existing ecosystem through a proxy 343 based message flow mapping mechanism (e.g., mapping of existing 344 HTTP/TCP/IP message flows to HTTP/TCP/IP/ICN message flows). A 345 related approach of mapping TCP/IP to TCP/ICN message flows is 346 described in [Moiseenko] 348 Alternatively, ICN as an overlay (Section 3.2), as well as ICN-as- 349 a-Slice (Section 3.4), allow for the introduction of the full 350 capabilities of ICN through new service interfaces as well as 351 operations in the network. With that, these approaches of deployment 352 are likely to aim at introducing new services capitalizing on those 353 ICN capabilities. 355 Finally, [I-D.suthar-icnrg-icn-lte-4g] outlines a hybrid approach 356 that is applicable for all deployment configurations based on the 357 approach of a dual-stack end user device. Specifically, 358 [I-D.suthar-icnrg-icn-lte-4g] introduces middleware layers in the 359 device that will dynamically adapt existing applications to either an 360 underlying ICN protocol stack or standard IP protocol stack. This 361 involves end device signalling with the network to determine which 362 protocol stack instance and associated middleware adaptation layers 363 to utilize for a given application transaction. 365 4.2. Content Delivery Network Migration 367 A significant number of services and applications are devoted to 368 content delivery in some form, either as video delivery services, 369 social media platforms, and many others. Content delivery networks 370 (CDNs) are deployed to assist these services through localizing the 371 content requests and therefore reducing latency and possibly increase 372 utilization of available bandwidth as well as reducing the load on 373 origin servers. Similar to the previous sub-section, the underlay 374 deployment configurations presented in Section 3.3.1 and 375 Section 3.3.2 aim at providing a migration path for existing CDNs. 376 This is also highlighted in the BIER WG use case document 377 [I-D.ietf-bier-use-cases], specifically with potential benefits in 378 terms of utilizing multicast in the delivery of content but also 379 reducing load on origin as well as delegation server. We return to 380 this benefit in the trial experiences in Section 5. 382 4.3. Edge Network Migration 384 Edge networks often see the deployment of novel network level 385 technology, e.g., in the space of IoT. Such IoT deployments have for 386 many years relied, and often still do, on proprietary protocols for 387 reasons such as increased efficiency, lack of standardization 388 incentives and others. Utilizing the underlay deployment 389 configuration in Section 3.3.2, application gateways/proxies can 390 integrate such edge deployments into IP-based services, e.g., 391 utilizing CoAP [RFC7252] based machine-to-machine (M2M) platforms 392 such as oneM2M [oneM2M] or others. 394 Another area of increased edge network innovation is that of mobile 395 (access) networks, particularly in the context of the 5th generation 396 of mobile networks (often called "5G"). With the proliferation of 397 network softwarization (using technologies like service orchestration 398 frameworks leveraging NFV and SDN concepts) access networks and other 399 network segments, the ICN-as-a-Slice deployment configuration in 400 Section 3.4 provides a suitable migration path for integration non- 401 IP-based edge networks into the overall system through virtue of 402 realizing the relevant (ICN) protocols in an access network slice. 404 4.4. Core Network Migration 406 Migrating the core network of the Internet requires not only 407 significant infrastructure renewal but also the fulfillment of the 408 significant performance requirements, particularly in terms of 409 throughput. For those parts of the core network that would see a 410 migration to an SDN-based optical transport, such as proposed by 411 major operators such as AT&T, the ICN-as-a-Slice deployment 412 configuration in Section 3.4 could see the introduction of native ICN 413 solutions within slices provided by the SDN-enabled transport network 414 or as virtual network functions, allowing for isolating the ICN 415 traffic while addressing the specific ICN performance benefits and 416 constraints within such isolated slice. For ICN solutions that 417 natively work on top of SDN, the underlay deployment configuration in 418 Section 3.3.1 provides an additional migration path, preserving the 419 IP-based services and applications at the edge of the network, while 420 realizing the core network routing through an ICN solution (possibly 421 itself realized in a slice of the SDN transport network). 423 5. Deployment Trial Experiences 425 In this section, we will outline trial experiences, often conducted 426 within international collaborative project efforts. Our focus here 427 is on the realization of the various deployment configurations in 428 Section 3, and we therefore categorize the trial experiences 429 according to these deployment configurations. While a large body of 430 work exists at the simulation or emulation level, we specifically 431 exclude these studies from our presentation to retain the focus on 432 real life experiences. 434 5.1. ICN-as-an-Overlay 436 5.1.1. FP7 PURSUIT Efforts 438 Although the FP7 PURSUIT [IEEE_Communications] efforts were generally 439 positioned as a wholesale replacement of IP (Section 3.1), the 440 project realized its experimental test bed as an L2 VPN-based overlay 441 between several European, US as well as Asian sites, i.e., following 442 the overlay deployment configuration presented in Section 3.2. 443 Software-based forwarders were utilized for the ICN message exchange, 444 while native ICN applications, e.g., for video transmissions, were 445 showcased. At the height of the project efforts, about 70+ nodes 446 were active in the (overlay) network with presentations given at 447 several conferences as well as to the ICNRG. 449 5.1.2. FP7 SAIL Trial 451 The Network of Information (NetInf) is the approach to Information- 452 Centric Networking developed by the European Union (EU) FP7 SAIL 453 project (http://www.sail-project.eu/). NetInf provides both name- 454 based forwarding with CCNx-like semantics and name resolution (for 455 indirection and late-binding). The NetInf architecture supports 456 different deployment options through its convergence layer 457 abstraction. In its first prototypes and trials, NetInf was deployed 458 mostly in an HTTP embedding and in a UDP overlay following the 459 overlay deployment configuration in Section 3.2. Reference 460 [SAIL_NetInf] describes several trials including a stadium 461 environment large crowd scenario and a multi-site testbed, leveraging 462 NetInf's Routing Hint approach for routing scalability. 464 5.1.3. NDN Testbed 466 The Named Data Networking (NDN) is one of the research projects 467 funded by the National Science Foundation (NSF) of the USA as part of 468 the Future Internet Architecture Program. The original NDN proposal 469 was positioned as a wholesale replacement of IP (Section 3.1). 470 However, in several trials, NDN generally follows the overlay 471 deployment configuration of Section 3.2 to connect institutions over 472 the public Internet across several continents. The use cases covered 473 in the trials include real-time video-conferencing, geo-locating, and 474 interfacing to consumer applications. Typical trials involve several 475 hundred NDN enabled nodes (https://named-data.net/ndn-testbed/). 477 5.1.4. ICN2020 Efforts 479 ICN2020 is an ICN related research project funded by the EU as part 480 of the H2020 research and innovation program 481 (http://www.icn2020.org/). ICN2020 has a specific focus to advance 482 ICN towards real-world deployments through innovative applications 483 and global scale experimentation. Both NDN and CCN approaches are 484 within the scope of the project. 486 ICN2020 was kicked off in late 2016 and so has not yet published 487 results relating to deployment trials. The plan, however, is to 488 involve ICN testbeds in EU, Japan and the USA and federate them. The 489 GEANT testbed (https://www.geant.org/) is being considered as one 490 means to federate the different ICN testbeds in the overlay 491 deployment configuration of Section 3.2 over the public Internet. 493 5.2. ICN-as-an-Underlay 495 5.2.1. H2020 POINT and RIFE Efforts 497 POINT and RIFE are two more ICN related research projects funded by 498 the EU as part of the H2020 effort. The efforts in the H2020 499 POINT+RIFE projects follow the underlay deployment configuration in 500 Section 3.3.1, although this is mixed with utilizing an overlay 501 deployment to provide multi-national connectivity. However, underlay 502 SDN-based deployments do exist at various project partner sites, 503 e.g., at Essex University, without any overlaying being realized. 504 Edge-based network attachment points (NAPs) provide the IP/HTTP-level 505 protocol mapping onto ICN protocol exchanges, while the SDN underlay 506 (or the VPN-based L2 underlay) is used as a transport network. 508 The multicast as well as service endpoint surrogate benefits in HTTP- 509 based scenarios, such as for HTTP-level streaming video delivery, 510 have been demonstrated in the deployed POINT test bed with 80+ nodes 511 being utilized. Demonstrations of this capability have been given to 512 the ICNRG in 2016, while public demonstrations were also provided at 513 events such as Mobile World Congress in 2016 [MWC_Demo]. The trial 514 has also been accepted by the ETSI MEC group as a proof-of-concept 515 with a demonstration at the ETSI MEC World Congress in 2016. 517 While the afore-mentioned demonstrations all use the overlay 518 international deployment, both H2020 efforts plan ICN underlay trials 519 in the summer and fall of 2017. One such trial will involve 520 commercial end users located in the Primetel network in Cyprus with 521 the use case centered on IPTV and HLS video dissemination. Another 522 trial is planned for fall 2017 in the community network of 523 "guifi.net" in the Barcelona region, where the solution will be 524 deployed in 40 households, providing general Internet connectivity to 525 the residents. Standard IPTV STBs as well as HLS video players will 526 be utilized in accordance with the aim of this deployment 527 configuration, namely to provide application and service migration. 529 5.2.2. H2020 FLAME Efforts 531 Starting in January 2017, the H2020 FLAME efforts aims at providing 532 an experimental ground for the aforementioned POINT/RIFE solution in 533 initially two city-scale locations, namely in Bristol and Barcelona. 534 This trial will again follow the underlay deployment configuration in 535 Section 3.3.1 as per POINT/RIFE approach. Currently, experiments are 536 ongoing,conducted by the city/university joint venture Bristol-is- 537 Open (BIO), to ensure the readiness of the city-scale SDN transport 538 network for such experiments. A third trial of the aforementioned 539 ETSI MEC PoC is planned for mid 2017. This trial will showcase 540 operational benefits provided by the ICN underlay for the scenario of 541 a location-based game. These benefits aim at reduced network 542 utilization through improved video delivery performance (multicast of 543 all captured videos to the service surrogates deployed in the city at 544 six locations) as well as reduced latency through the playout of the 545 video originating from the local NAP instead of a remote server. 547 Ensuring the technology readiness and the early trialing of the ICN 548 capabilities lays the ground for the goal of the H2020 FLAME efforts 549 to conduct 23 large-scale experiments in the area of Future Media 550 Internet (FMI) throughout 2018 and 2019. Standard media service 551 functions as well as applications will ultimately utilize the ICN 552 underlay in the delivery of their experience. The platform, which 553 includes the ICN capabilities, will utilize concepts of SFC, 554 integrated with NFV and SDN capabilities of the infrastructure. The 555 ultimate goal of these platform efforts is the full integration of 556 ICN into the overall media function platform for the provisioning of 557 advanced (media-centric) internet services. 559 5.2.3. CableLabs Content Delivery System 561 The work in [White] proposes an underlay deployment configuration 562 based on Section 3.3.1. The use case is ICN for content distribution 563 within CDN server farms (which can be quite large and complex) to 564 leverage ICN's superior in-network caching properties. This "island 565 of ICN" based CDN is then used to service standard HTTP/IP-based 566 content retrieval request coming from the general Internet. This 567 approach acknowledges that whole scale replacement (see Section 3.1) 568 of existing HTTP/IP end user applications and related Web 569 infrastructure is a difficult proposition. [White] does not yet 570 provide results but indicated that experiments will be forthcoming. 572 5.2.4. NDN IoT Trials 574 [Baccelli] summarizes the trial of an NDN system adapted specifically 575 for a wireless IoT scenario. The trial was run with 60 nodes 576 distributed over several multi-story buildings in a university campus 577 environment. The NDN protocols were optimized to run directly over 578 6LoWPAN wireless link layers. The performance of the NDN based IoT 579 system was then compared to an equivalent system running standard IP 580 based IoT protocols. It was found that the NDN based IoT system was 581 superior in several respects including in terms of energy 582 consumption, and for RAM and ROM footprints [Baccelli] 583 [Anastasiades]. 585 5.3. Summary of Deployment Trials 587 In summary, there have been significant trials over the years with 588 all the major ICN protocol flavors (e.g., CCN, NDN, POINT). Also, 589 both the ICN-as-an-Overlay and ICN-as-an-Underlay deployment 590 configurations have been proven in various scenarios. The major 591 limitations of the trials include the fact that only a limited number 592 of applications have been tested. However, the tested applications 593 include both native ICN and existing IP based applications (e.g. 594 video-conferencing and IPTV). Another limitation of the trials is 595 that all of them involve less than 1000 users maximum. Finally, the 596 ICN-as-a-Slice configuration still has not be trialled primarily due 597 to the fact that 5G standards are still in flux and not expected to 598 be stable before the 2018 time frame. 600 6. Deployment Issues Requiring Further Standardization 602 The ICN Research Challenges [RFC7927] describes key ICN principles 603 and technical research topics. As the title suggests, [RFC7927] is 604 research oriented without a specific focus on deployment or 605 standardization issues. This section addresses this open area by 606 identifying key protocol functionality that that may be relevant for 607 further standardization effort in IETF. The focus is specifically on 608 identifying protocols that will facilitate future interoperable ICN 609 deployments correlating to the scenarios identified in the deployment 610 migration paths in Section 4. The identified list of potential 611 protocol functionality is not exhaustive. 613 6.1. Protocols for Application and Service Migration 615 End user applications and services need a standardized approach to 616 trigger ICN transactions. For example, in Internet and Web 617 applications today, there are established socket APIs, communication 618 paradigms such as REST, common libraries, and best practices. We see 619 a need to study application requirements in an ICN environment 620 further and, at the same time, develop new APIs and best practices 621 that can take advantage of ICN communication characteristics. 623 6.2. Protocols for Content Delivery Network Migration 625 A key issue in CDNs is to quickly find a location of a copy of the 626 object requested by an end user. In ICN, a Named Data Object (NDO) 627 is typically defined by its name. There already exists [RFC6920] 628 that is suitable for static naming of ICN data objects. Other ways 629 of encoding and representing ICN names have been described in 630 [I-D.irtf-icnrg-ccnxmessages] and [I-D.mosko-icnrg-ccnxurischeme]. 631 Naming dynamically generated data requires different approaches (for 632 example, hash digest based names would normally not work), and there 633 is lack of established conventions and standards. 635 Another CDN issue for ICN is related to multicast distribution of 636 content. Existing CDNs have started using multicast mechanisms for 637 certain cases such as for broadcast streaming TV. However, as 638 discussed in Section 5.2.1, certain ICN approaches provide 639 substantial improvements over IP multicast, such as the implicit 640 support for multicast retrieval of content in all ICN flavours. 642 Caching is an implicit feature in many ICN architectures that can 643 improve performance and availability in several scenarios. The ICN 644 in-network caching can augment managed CDN and improve its 645 performance. The details of the interplay between ICN caching and 646 managed CDN need further consideration. 648 6.3. Protocols for Edge and Core Network Migration 650 ICN provides the potential to redesign current edge and core network 651 computing approaches. Leveraging ICN's inherent security and its 652 ability to make name data and dynamic computation results available 653 independent of location, can enable a secure, yet light-weight 654 insertion of traffic into the network without relying on redirection 655 of DNS requests. For this, proxies that translate from commonly used 656 protocols in the general Internet to ICN message exchanges in the ICN 657 domain could be used for the migration of application and services 658 within deployments at the network edge but also in core networks. 659 This is similar to existing approaches for IoT scenarios where a 660 proxy translates CoAP request/responses to other message formats. 662 For example, [RFC8075] specifies proxy mapping between CoAP and HTTP 663 protocols. However, as mentioned previously, ICN will allow us to 664 evolve the role of gateways/proxies as ICN message security should be 665 preserved through the protocol translation function of a thus offer a 666 substantial gain. Another area is integration of ICN into networks 667 that support virtualized infrastructure in the form of NFV/SDN and 668 most likely utilizing Service Function Chaining (SFC) as a key 669 protocol. Further work is required to validate this idea and 670 document best practices. 672 Operations and Maintenance (OAM) is a crucial area that has not yet 673 been fully addressed by the ICN research community, but which is 674 obviously critical for future deployments of ICN. Potential areas 675 that need investigation include whether the YANG data modelling 676 approach and associated NETCONF/RESTCONF protocols need any specific 677 updates for ICN support. Also, how to measure and benchmark 678 performance of ICN networks comparable to the sophisticated 679 techniques that exist for standard IP networks, virtualized networks 680 and data centers. 682 6.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts 684 Without claiming completeness, Table 1 maps the open the open ICN 685 issues identified in this document to potential protocol efforts that 686 could address some aspects of the gap. 688 +--------------+----------------------------------------------------+ 689 | ICN Gap | Potential Protocol Effort | 690 +--------------+----------------------------------------------------+ 691 | 1-Support of | HTTP/CoAP support of ICN semantics | 692 | REST APIs | | 693 | | | 694 | 2-Naming | Dynamic naming of ICN data objects | 695 | | | 696 | 3-Multicast | Multicast enhancements for ICN | 697 | distribution | | 698 | | | 699 | 4-In-network | ICN Cache placement and sharing | 700 | caching | | 701 | | | 702 | 5-NFV/SDN | Integration of ICN with NFV/SDN and including | 703 | support | possible impacts to SFC | 704 | | | 705 | 6-ICN | Mapping of HTTP and other protocols onto ICN | 706 | mapping | message exchanges (and vice-versa) while | 707 | | preserving ICN message security | 708 | | | 709 | 7-OAM | YANG models, NETCONF/RESTCONF protocols, | 710 | support | and network performance measurements | 711 | | | 712 +--------------+----------------------------------------------------+ 714 Table 1: Mapping of ICN Gaps to Potential Protocol Efforts 716 7. Conclusion 718 This document provides high level deployment considerations for the 719 ICN community. Specifically, the major configurations of possible 720 ICN deployments are identified as (1) wholesale replacement of 721 existing Internet infrastructure; (2) ICN-as-an-Overlay; (3) ICN-as- 722 an-Underlay; and (4) ICN-as-a-Slice. Existing ICN trial systems 723 mainly fall under either the ICN-as-an-Overlay or ICN-as-an-Underlay 724 configuration. 726 In terms of deployment migration paths, ICN-as-an-Underlay offers a 727 clear migration path for existing CDN, edge and core networks to go 728 to an ICN paradigm. ICN-as-a-Slice is an attractive deployment 729 option for future 5G systems (i.e., for 5G radio and core networks) 730 which will naturally support network slicing, but this still has to 731 be validated through actual trial experiences. For the crucial issue 732 of existing application and service migration to ICN, various mapping 733 schemes are possible to mitigate impacts. For example, HTTP/TCP/IP 734 flows may be mapped to ICN message flows at a proxy in the ICN-as-an- 735 Underlay configurations leaving the massive number of existing end 736 point applications/services untouched or minimally impacted. Also 737 dual stack end user devices that include middleware to allow 738 applications to communicate in both ICN mode and standard IP mode are 739 an attractive proposition for gradual and geographically 740 discontinuous introduction for all deployment configurations. 742 There has been significant trial experience with all the major ICN 743 protocol flavors (e.g., CCN, NDN, POINT). However, only a limited 744 number of applications have been tested so far, and the maximum 745 number of users in any given trial has been less than 1000 users. It 746 is recommended that future ICN deployments scale their users 747 gradually and closely monitor network performance if they go above 748 1000 users. 750 Finally, this document describes a set of technical features in ICN 751 that warrant potential future IETF specification work. This will aid 752 initial and incremental deployments to proceed in an interoperable 753 manner. The fundamental details of the potential protocol 754 specification effort, however, are best left for future study by the 755 appropriate IETF WGs and/or BoFs. 757 8. IANA Considerations 759 This document requests no IANA actions. 761 9. Security Considerations 763 ICN was purposefully designed from the start to have certain 764 intrinsic security properties. The most well known of which are 765 authentication of delivered content and (optional) encryption of the 766 content. [RFC7945] has an extensive discussion of various aspects of 767 ICN security including many which are relevant to deployments. 768 Specifically, [RFC7945] points out that ICN access control, privacy, 769 security of in-network caches, and protection against various network 770 attacks (e.g. DoS) have not yet been fully developed due to the lack 771 of real deployments. [RFC7945] also points out relevant advances 772 occurring in the ICN research community that hold promise to address 773 each of the identified security gaps. Lastly, [RFC7945] points out 774 that as secure communications in the existing Internet (e.g. HTTPS) 775 becomes the norm, that major gaps in ICN security will inevitably 776 slow down the adoption of ICN. 778 In addition to the security findings of [RFC7945], this document has 779 highlighted that all anticipated ICN deployment configurations will 780 involve co-existence with existing Internet infrastructure and 781 applications. Thus even the basic authentication and encryption 782 properties of ICN content will need to account for interworking with 783 non-ICN content to preserve end-to-end security. For example, in the 784 edge network underlay deployment configuration described in 785 Section 3.3.2, the gateway/proxy that translates HTTP or CoAP 786 request/responses into ICN message exchanges will need to support a 787 model to preserve end-to-end security. 789 10. Acknowledgments 791 The authors want to thank Alex Afanasyev, Xavier de Foy, Hannu 792 Flinck, Dave Oran, Thomas Schmidt, Jan Seedorf, Eve Schooler, Prakash 793 Suthar, and Lixia Zhang for their very useful reviews and comments to 794 the document. 796 11. Informative References 798 [Anastasiades] 799 Anastasiades, C., "Information-centric communication in 800 mobile and wireless networks", PhD Dissertation, 2016, 801 . 803 [Baccelli] 804 Baccelli, E. and et al., "Information Centric Networking 805 in the IoT: Experiments with NDN in the Wild", ACM 806 20164, Paris, France, 2014, 807 . 810 [C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking 811 over OpenFlow", Open Networking Summit, April, 2012, 812 . 815 [CCNx_UDP] 816 PARC, "CCNx Over UDP", 2015, 817 . 820 [CONET] Veltri, L. and et al., "CONET Project: Supporting 821 Information-Centric Functionality in Software Defined 822 Networks", Workshop on Software Defined Networks, , 2012, 823 . 826 [DASH] DASH, "DASH Industry Forum", 2017, . 828 [Hybrid_ICN] 829 Cisco, "Hybrid ICN: Cisco Announces Important Steps toward 830 Adoption of Information-Centric Networking", 2017, 831 . 834 [I-D.ietf-bier-use-cases] 835 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 836 Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., 837 Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases", 838 draft-ietf-bier-use-cases-05 (work in progress), July 839 2017. 841 [I-D.irtf-icnrg-ccnxmessages] 842 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 843 Format", draft-irtf-icnrg-ccnxmessages-04 (work in 844 progress), March 2017. 846 [I-D.irtf-nfvrg-gaps-network-virtualization] 847 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 848 Aranda, P., and P. Lynch, "Network Virtualization Research 849 Challenges", draft-irtf-nfvrg-gaps-network- 850 virtualization-06 (work in progress), July 2017. 852 [I-D.kutscher-icnrg-netinf-proto] 853 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 854 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 855 progress), February 2013. 857 [I-D.mosko-icnrg-ccnxurischeme] 858 marc.mosko@parc.com, m. and c. cwood@parc.com, "The CCNx 859 URI Scheme", draft-mosko-icnrg-ccnxurischeme-01 (work in 860 progress), April 2016. 862 [I-D.paik-icn-deployment-considerations] 863 Paik, E., Yun, W., Kwon, T., and h. 864 hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for 865 Information-Centric Networking", draft-paik-icn- 866 deployment-considerations-00 (work in progress), July 867 2013. 869 [I-D.suthar-icnrg-icn-lte-4g] 870 suthar, P., Stolic, M., and A. Jangam, "Native Deployment 871 of ICN in LTE, 4G Mobile Networks", draft-suthar-icnrg- 872 icn-lte-4g-02 (work in progress), July 2017. 874 [I-D.zhang-icnrg-icniot] 875 Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E., 876 Burke, J., Ravindran, R., Wang, G., Lindgren, A., Ahlgren, 877 B., and O. Schelen, "Design Considerations for Applying 878 ICN to IoT", draft-zhang-icnrg-icniot-01 (work in 879 progress), June 2017. 881 [ICNRGCharter] 882 NDN, "Information-Centric Networking Research Group 883 Charter", 2013, . 886 [ICNterm] Wissingh, B., "Information-Centric Networking (ICN): 887 Terminology", 2017, . 890 [IEEE_Communications] 891 Trossen, D. and G. Parisis, "Designing and Realizing an 892 Information-Centric Internet", Information-Centric 893 Networking, IEEE Communications Magazine Special Issue, 894 2012. 896 [Internet_Pricing] 897 Trossen, D. and G. KBiczok, "Not Paying the Truck Driver: 898 Differentiated Pricing for the Future Internet", ReArch 899 Workshop in conjunction with ACM Context, December, 2010. 901 [Jacobson] 902 Jacobson, V. and et al., "Networking Named Content", 903 Proceedings of ACM Context, , 2009. 905 [Moiseenko] 906 Moiseenko, I. and D. Oran, "TCP/ICN : Carrying TCP over 907 Content Centric and Named Data Networks", 2016, 908 . 911 [MWC_Demo] 912 InterDigital, "InterDigital Demo at Mobile World Congress 913 (MWC)", 2016, . 916 [NFD] NDN, "NFD - Named Data Networking Forwarding Daemon", 917 2017, . 919 [NGMN] NGMN, "NGMN 5g Initiative White Paper", 2015, 920 . 923 [oneM2M] OneM2M, "oneM2M Service Layer Standards for M2M and IoT", 924 2017, . 926 [POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better 927 IP?", European Conference on Networks and Communications 928 (EuCNC), , 2015. 930 [Ravindran] 931 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 932 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 933 Network Slicing", IEEE Communication Magazine, May, 2016, 934 . 936 [Reed] Reed, M. and et al., "Stateless Multicast Switching in 937 Software Defined Networks", ICC 2016, Kuala Lumpur, 938 Malaysia, 2016. 940 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 941 Keranen, A., and P. Hallam-Baker, "Naming Things with 942 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 943 . 945 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 946 Application Protocol (CoAP)", RFC 7252, 947 DOI 10.17487/RFC7252, June 2014, 948 . 950 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 951 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 952 Defined Networking (SDN): Layers and Architecture 953 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 954 2015, . 956 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 957 Chaining (SFC) Architecture", RFC 7665, 958 DOI 10.17487/RFC7665, October 2015, 959 . 961 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 962 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 963 "Information-Centric Networking (ICN) Research 964 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 965 . 967 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 968 and G. Boggia, "Information-Centric Networking: Evaluation 969 and Security Considerations", RFC 7945, 970 DOI 10.17487/RFC7945, September 2016, 971 . 973 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 974 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 975 the Constrained Application Protocol (CoAP)", RFC 8075, 976 DOI 10.17487/RFC8075, February 2017, 977 . 979 [SAIL_NetInf] 980 FP7, "SAIL Prototyping and Evaluation", 2013, 981 . 984 [Tateson] Tateson, J. and et al., "Final Evaluation Report on 985 Deployment Incentives and Business Models", 2010, 986 . 989 [Techno_Economic] 990 Trossen, D. and A. Kostopolous, "Techno-Economics Aspects 991 of Information-Centric Networking", Journal for 992 Information Policy, Volume 2, 2012. 994 [VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G. 995 Wang, "Towards software defined ICN based edge-cloud 996 services", CloudNetworking(CloudNet), IEEE Internation 997 Conference on, IEEE Internation Conference on 998 CloudNetworking(CloudNet), 2013. 1000 [VSER-Mob] 1001 Azgin, A., Ravindran, R., Chakraborti, A., and G. Wang, 1002 "Seamless Mobility as a Service in Information-centric 1003 Networks", ACM ICN Sigcomm, IC5G Workshop, 2016. 1005 [White] White, G. and G. Rutz, "Content Delivery with Content 1006 Centric Networking, CableLabs White Paper", 2010, 1007 . 1011 Authors' Addresses 1013 Akbar Rahman 1014 InterDigital Inc. 1015 1000 Sherbrooke Street West, 10th floor 1016 Montreal H3A 3G4 1017 Canada 1019 Email: Akbar.Rahman@InterDigital.com 1020 URI: http://www.InterDigital.com/ 1022 Dirk Trossen 1023 InterDigital Inc. 1024 64 Great Eastern Street, 1st Floor 1025 London EC2A 3QR 1026 United Kingdom 1028 Email: Dirk.Trossen@InterDigital.com 1029 URI: http://www.InterDigital.com/ 1031 Dirk Kutscher 1032 Huawei German Research Center 1033 Riesstrasse 25 1034 Munich 80992 1035 Germany 1037 Email: ietf@dkutscher.net 1038 URI: http://www.Huawei.com/ 1040 Ravi Ravindrna 1041 Huawei Research Center 1042 2330 Central Expressway 1043 Santa Clara 95050 1044 USA 1046 Email: ravi.ravindran@huawei.com 1047 URI: http://www.Huawei.com/