idnits 2.17.1 draft-rahman-icnrg-deployment-guidelines-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2017) is 2532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-04 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-04 Summary: 0 errors (**), 0 flaws (~~), 3 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: November 19, 2017 D. Kutscher 6 Huawei 7 May 18, 2017 9 Deployment Considerations for Information-Centric Networking (ICN) 10 draft-rahman-icnrg-deployment-guidelines-01 12 Abstract 14 Information-Centric Networking (ICN) is now reaching technological 15 maturity after many years of fundamental research and 16 experimentation. This document provides a number of deployment 17 considerations in the interest of helping the ICN community move 18 forward to the next step of live deployments. The major deployment 19 configurations for ICN are first described including the main overlay 20 and underlay approaches. Then proposed deployment migration paths 21 are outlined to address major practical issues such as network and 22 application migration. Next, selected ICN trial experiences are 23 summarized. Finally, protocol areas that require further 24 standardization are identified to facilitate future interoperable ICN 25 deployments. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 19, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Deployment Configurations . . . . . . . . . . . . . . . . . . 4 64 3.1. Wholesale Replacement . . . . . . . . . . . . . . . . . . 4 65 3.2. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 4 66 3.3. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 5 67 3.3.1. Core Network . . . . . . . . . . . . . . . . . . . . 5 68 3.3.2. Edge Network . . . . . . . . . . . . . . . . . . . . 5 69 3.4. ICN-in-a-Slice . . . . . . . . . . . . . . . . . . . . . 6 70 4. Deployment Migration Paths . . . . . . . . . . . . . . . . . 6 71 4.1. Application and Service Migration . . . . . . . . . . . . 7 72 4.2. Content Delivery Network Migration . . . . . . . . . . . 7 73 4.3. Edge Network Migration . . . . . . . . . . . . . . . . . 8 74 4.4. Core Network Migration . . . . . . . . . . . . . . . . . 8 75 5. Deployment Trial Experiences . . . . . . . . . . . . . . . . 8 76 5.1. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 9 77 5.1.1. FP7 PURSUIT Efforts . . . . . . . . . . . . . . . . . 9 78 5.1.2. FP7 SAIL Trial . . . . . . . . . . . . . . . . . . . 9 79 5.1.3. NDN Testbed . . . . . . . . . . . . . . . . . . . . . 9 80 5.1.4. ICN2020 Efforts . . . . . . . . . . . . . . . . . . . 9 81 5.2. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 10 82 5.2.1. H2020 POINT and RIFE Efforts . . . . . . . . . . . . 10 83 5.2.2. H2020 FLAME Efforts . . . . . . . . . . . . . . . . . 11 84 5.2.3. CableLabs Content Delivery System . . . . . . . . . . 11 85 6. Deployment Issues Requiring Further Standardization . . . . . 11 86 6.1. Protocols for Application and Service Migration . . . . . 12 87 6.2. Protocols for Content Delivery Network Migration . . . . 12 88 6.3. Protocols for Edge and Core Network Migration . . . . . . 12 89 6.4. Summary of ICN Protocol Gaps and Potential IETF Efforts . 13 90 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 94 11. Informative References . . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 The ICNRG charter identifies deployment guidelines as an important 100 topic area for the ICN community. Specifically, the charter states 101 that defining concrete migration paths for ICN deployments which 102 avoid forklift upgrades, and defining practical ICN interworking 103 configurations with the existing Internet paradigm, are key topic 104 areas that require further investigation. Also, it is well 105 understood that results and conclusions from any mid to large-scale 106 ICN experiments in the live Internet will also provide useful 107 guidance for deployments. 109 However, so far outside of some preliminary investigations such as 110 [I-D.paik-icn-deployment-considerations], there has not been much 111 progress on this topic. This draft attempts to fill some of these 112 gaps by defining clear deployment configurations for ICN, and 113 associated migration pathways for these configurations. Also, 114 selected deployment trial experiences of ICN technology are 115 summarized. Finally, recommendations are made for future IETF 116 standardization of key protocol functionality that will facilitate 117 interoperable ICN deployments going forward. 119 2. Terminology 121 The following key terms and concepts are defined: 123 Information-Centric Networking (ICN) - ICN is an approach to 124 evolve the Internet infrastructure (e.g. routers, caches, servers) 125 towards accessing named data as a first-order network layer 126 service. In this approach, Named Data Objects (NDOs) are named 127 and secured individually. Hashing and/or Public-Key Cryptography 128 are used to provide NDO authentication and integrity validation 129 (amongst other services). ICN's data-oriented security (instead 130 of connection-based security) can enable several benefits: message 131 authentication and optionally encryption are fundamental elements 132 of the system, and the forwarding layer can be empowered to 133 implement suitable forwarding strategies and additional 134 functionality such as caching, local retransmissions, etc. 136 Software-Defined Networking (SDN) - SDN is a network control and 137 implementation architecture that disaggregates the network control 138 and forwarding functions. This enables programming network 139 elements (e.g. routers, switches) that implement packet forwarding 140 functions using a control abstraction, e.g., OpenFlow's Match- 141 Action-based abstraction. Corresponding controllers can have 142 visibility and control of a larger set of SDN elements in a 143 network deployment, which enables network programmability. This 144 can be used to achieve several objectives such as network 145 virtualization, optimized forwarded, failure resilience, etc. 147 Deployment - In the context of this document, deployment refers to 148 the final stage of the process of setting up an ICN network that 149 is (1) integrated and interoperable with the rest of the Internet, 150 and (2) ready for useful work (e.g. transmission of end user video 151 and text) in a live environment. 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 (in Section 5) 158 experiences with various of these configurations, 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 have not been 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 CCN routers [Jacobson] or Bloom-filter based forwarding 172 elements [IEEE_Communications]. All major ICN approaches have 173 explored this option as one of their paths to deployment. 175 While such replacement could be seen as exclusive for ICN 176 deployments, some ICN approaches [POINT] rely on the deployment of 177 infrastructure upgrades, here SDN switches. Such upgrades, while 178 being possibly utilized for a "clean slate" ICN deployment would not 179 necessary be used exclusively for an ICN deployment. Different 180 proposals have been made for various ICN approaches to enable the 181 operation over an SDN transport [Reed][CONET][C_FLOW]. 183 3.2. ICN-as-an-Overlay 185 Similar to other significant changes to the Internet routing fabric, 186 particularly the transition from IPv4 to IPv6 or the introduction of 187 IP multicast, this deployment configuration foresees the creation of 188 an ICN overlay. Note that this overlay approach is sometimes also 189 referred to as a tunneling approach. The overlay approach could be 190 done directly such as ICN-over-UDP as described in [CCNx_UDP]. 192 Alternatively, the overlay could be done via ICN-in-L2-in-IP as 193 described in [IEEE_Communications]. 195 Another flavor of overlay would be embedding ICN semantics into 196 existing protocols. A recently announced approach is [Hybrid_ICN] 197 where the ICN names are mapped to IPv6 addresses. Another approach 198 used in the Network of Information (NetInf) is to define a 199 convergence layer to map NetInf semantics to HTTP 200 [I-D.kutscher-icnrg-netinf-proto]. Regardless of the flavor, 201 however, the overlay approach results in islands of ICN deployments 202 over existing IP-based infrastructure. 204 3.3. ICN-as-an-Underlay 206 Proposals such as [POINT] and [White] outline the deployment option 207 of using an ICN underlay that would integrate with existing IP-based 208 services, while possibly still allowing for native ICN applications 209 to emerge. The main reasons for such configuration option is the 210 backward-compatible introduction of ICN technology, while possibly 211 reaping the benefits of ICN in terms of multicast delivery, mobility 212 support, fast indirection due to location independence, and possibly 213 more. 215 3.3.1. Core Network 217 In this sub-option, a core network would utilize edge-based protocol 218 mapping onto the native ICN underlay. For instance, [POINT] proposes 219 to map either raw IP packets or HTTP transactions directly onto an 220 ICN-based message exchange. This mapping is realized at the network 221 attachment point, such as realized in access points or customer 222 premise equipment, which in turn provides a standard IP interface to 223 existing user devices. Towards peering networks, such network 224 attachment point turns into a modified border gateway/proxy, 225 preserving the perception of an IP-based core network towards any 226 peering network. 228 The work in [White] proposes a similar deployment configuration. 229 Here, the target is the use of ICN for content distribution within 230 CDN server farms, i.e., the protocol mapping is realized at the 231 ingress of the server farm where the HTTP-based retrieval request is 232 served, while the response is delivered through a suitable egress 233 node translation. 235 3.3.2. Edge Network 237 Native ICN networks may be found at the edge of the network, mostly 238 proposed for Internet of Things (IoT) deployments. The integration 239 with the current IP protocol suite takes place at an application 240 gateway/proxy at the edge network boundary, e.g., translating 241 incoming CoAP request/response transactions [RFC7252] into ICN 242 message exchanges. However, ICN will allow us to evolve the role of 243 gateways/proxies as ICN message security should be preserved through 244 the protocol translation function of a gateway/proxy and thus offer a 245 substantial gain. 247 3.4. ICN-in-a-Slice 249 With the advent of network slicing, i.e., the ability to isolate 250 network resources exclusively towards a specific set of network 251 functions, the deployment of ICN within such isolated slice is 252 emerging as another deployment configuration. Coupled with the view 253 of ICN functions as being "chained service functions" [RFC7665], an 254 ICN deployment within such a slice could be realized within the 255 emerging control plane that is targeted for adoption in future (e.g., 256 5th generation mobile) network deployments. It should be noted that 257 ICN is not creating the network slice, but instead that the slice is 258 created to run a 5G-ICN instance [Ravindran]. 260 At the level of the specific technologies involved, the 5G-ICN slice 261 requires compatibility for instance at the level of the forwarding/ 262 data plane. With SDN emerging as a novel data plane for new network 263 deployments, some ICN approaches will need to integrate with SDN as a 264 data plane forwarding function, as briefly discussed in Section 3.1. 266 4. Deployment Migration Paths 268 After outlining the various ICN deployment configurations in 269 Section 3, we now focus on the various migration paths that might 270 have an importance to the various stakeholders that are usually 271 involved in the deployment of a technology at (ultimately) large 272 scale. We can identify these stakeholders as: 274 o Application developers and service providers 276 o ISPs, both as core as well as access network providers 278 o CDN providers (due to the strong relation of the ICN proposition 279 to content delivery) 281 Note that our presentation purely focuses on technological aspects of 282 such migration. Economic or regulatory aspects, such as studied in 283 [Tateson], [Techno_Economic] and [Internet_Pricing] are left out of 284 our discussion. 286 4.1. Application and Service Migration 288 The internet is full of applications and services, utilizing the 289 innovation capabilities of the many protocols defined over the packet 290 level IP service. HTTP provides one convergence point for these 291 services with many web development frameworks based on the semantics 292 provided by the hypertext transfer protocol. In recent years, even 293 services such as video delivery have been migrating from the 294 traditional RTP-over-UDP delivery to the various HTTP-level streaming 295 solutions, such as DASH [DASH] and others. Nonetheless, many non- 296 HTTP services exist, all of which need consideration when migrating 297 from the IP-based internet to an ICN-based one. 299 The underlay deployment configuration options presented in 300 Section 3.3.1 and Section 3.3.2 aim at providing some level of 301 backward compatibility to this existing ecosystem through a proxy 302 based message flow mapping mechanism (e.g., mapping of existing 303 HTTP/TCP/IP message flows to HTTP/TCP/IP/ICN message flows). A 304 related approach of mapping TCP/IP to TCP/ICN message flows is 305 described in [Moiseenko] 307 Alternatively, ICN as an overlay (Section 3.2), as well as ICN-in- 308 a-Slice (Section 3.4), allows introduction of the full capabilities 309 of ICN through new service interfaces as well as operations in the 310 network. This overlay and ICN-in-a-Slice approaches of deployment 311 are likely to be more disruptive at the application and service 312 level, however more new services are expected to be introduced based 313 on such an approach. 315 4.2. Content Delivery Network Migration 317 A significant number of services and applications are devoted to 318 content delivery in some form, either as video delivery services, 319 social media platforms, and many others. Content delivery networks 320 (CDNs) are deployed to assist these services through localizing the 321 content requests and therefore reducing latency and possibly increase 322 utilization of available bandwidth. Similar to the previous sub- 323 section, the underlay deployment configurations presented in 324 Section 3.3.1 and Section 3.3.2 aim at providing a migration path for 325 existing CDNs. This is also highlighted in the BIER WG use case 326 draft [I-D.ietf-bier-use-cases], specifically with potential benefits 327 in terms of utilizing multicast in the delivery of content. We 328 return to this benefit in the trial experiences in Section 5. 330 4.3. Edge Network Migration 332 Edge networks often see the deployment of novel network level 333 technology, e.g., in the space of IoT. Such IoT deployments have for 334 many years relied, and often still do, on proprietary protocols for 335 reasons such as increased efficiency, lack of standardization 336 incentives and others. Utilizing the underlay deployment 337 configuration in Section 3.3.2, application gateways/proxies can 338 integrate such edge deployments into IP-based services, e.g., 339 utilizing CoAP [RFC7252] based machine-to-machine (M2M) platforms 340 such as oneM2M [oneM2M] or others. 342 Another area of increased edge network innovation is that mobile 343 (access) networks, particularly in the context of the 5th generation 344 of mobile networks (often called "5G"). With the proliferation of 345 SDN-based transport for access networks, the ICN-in-a-Slice 346 deployment configuration in Section 3.4 provides a suitable migration 347 path for integration non-IP-based edge networks into the overall 348 system through virtue of realizing the relevant (ICN) protocols in an 349 access network slice. 351 4.4. Core Network Migration 353 Migrating the core network of the Internet requires not only 354 significant infrastructure renewal but also the fulfillment of the 355 significant performance requirements, particularly in terms of 356 throughput. For those parts of the core network that would see a 357 migration to an SDN-based transport, such as proposed by major 358 operators such as AT&T, the ICN-in-a-Slice deployment configuration 359 in Section 3.4 could see the introduction of native ICN solutions 360 within slices provided by the SDN-enabled transport network. For ICN 361 solutions that natively work on top of SDN, the underlay deployment 362 configuration in Section 3.3.1 provides an additional migration path, 363 preserving the IP-based services and applications at the edge of the 364 network, while realizing the core network routing through an ICN 365 solution (possibly itself realized in a slice of the SDN transport 366 network). 368 5. Deployment Trial Experiences 370 In this section, we will outline trial experiences, often conducted 371 within international collaborative project efforts. Our focus here 372 is on the realization of the various deployment configurations in 373 Section 3, and we therefore categorize the trial experiences 374 according to these deployment configurations. While a large body of 375 work exists at the simulation or emulation level, we specifically 376 exclude these studies from our presentation to retain the focus on 377 real life experiences. 379 5.1. ICN-as-an-Overlay 381 5.1.1. FP7 PURSUIT Efforts 383 Although the FP7 PURSUIT [IEEE_Communications] efforts were generally 384 positioned as a wholesale replacement of IP (Section 3.1), the 385 project realized its experimental test bed as an L2 VPN-based overlay 386 between several European, US as well as Asian sites, i.e., following 387 the overlay deployment configuration presented in Section 3.2. 388 Software-based forwarders were utilized for the ICN message exchange, 389 while native ICN applications, e.g., for video transmissions, were 390 showcased. At the height of the project efforts, about 70+ nodes 391 were active in the (overlay) network with presentations given at 392 several conferences as well as to the ICNRG. 394 5.1.2. FP7 SAIL Trial 396 The Network of Information (NetInf) is the approach to Information- 397 Centric Networking developed by the European Union (EU) FP7 SAIL 398 project (http://www.sail-project.eu/). NetInf provides both name- 399 based forwarding with CCNx-like semantics and name resolution (for 400 indirection and late-binding). The NetInf architecture supports 401 different deployment options through its convergence layer 402 abstraction. In its first prototypes and trials, NetInf was deployed 403 mostly in an HTTP embedding and in a UDP overlay following the 404 overlay deployment configuration in Section 3.2. Reference 405 [SAIL_NetInf] describes several trials including a stadium 406 environment large crowd scenario and a multi-site testbed, leveraging 407 NetInf's Routing Hint approach for routing scalability. 409 5.1.3. NDN Testbed 411 The Named Data Networking (NDN) is one of the research projects 412 funded by the National Science Foundation (NSF) of the USA as part of 413 the Future Internet Architecture Program. The original NDN proposal 414 was positioned as a wholesale replacement of IP (Section 3.1). 415 However, in several trials, NDN generally follows the overlay 416 deployment configuration of Section 3.2 to connect institutions over 417 the public Internet across several continents. The use cases covered 418 in the trials include real-time video-conferencing, geo-locating, and 419 interfacing to consumer applications. Typical trials involve several 420 hundred NDN enabled nodes (https://named-data.net/ndn-testbed/). 422 5.1.4. ICN2020 Efforts 424 ICN2020 is an ICN related research project funded by the EU as part 425 of the H2020 research and innovation program 426 (http://www.icn2020.org/). ICN2020 has a specific focus to advance 427 ICN towards real-world deployments through innovative applications 428 and global scale experimentation. Both NDN and CCN approaches are 429 within the scope of the project. 431 ICN2020 was kicked off in late 2016 and so has not yet published 432 results relating to deployment trials. The plan, however, is to 433 involve ICN testbeds in EU, Japan and the USA and federate them. The 434 GEANT testbed (https://www.geant.org/) is being considered as one 435 means to federate the different ICN testbeds in the overlay 436 deployment configuration of Section 3.2 over the public Internet. 438 5.2. ICN-as-an-Underlay 440 5.2.1. H2020 POINT and RIFE Efforts 442 POINT and RIFE are two more ICN related research projects funded by 443 the EU as part of the H2020 effort. The efforts in the H2020 444 POINT+RIFE projects follow the underlay deployment configuration in 445 Section 3.3.1, although this is mixed with utilizing an overlay 446 deployment to provide multi-national connectivity. However, SDN- 447 based deployments do exist at various project partner sites, e.g., at 448 Essex University, without any overlaying being realized. Edge-based 449 network attachment points (NAPs) provide the IP/HTTP-level protocol 450 mapping onto ICN protocol exchanges, while the SDN underlay (or the 451 VPN-based L2 underlay) is used as a transport network. 453 The multicast as well as service endpoint surrogate benefits in HTTP- 454 based scenarios, such as for HTTP-level streaming video delivery, 455 have been demonstrated in the deployed POINT test bed with 80+ nodes 456 being utilized. Demonstrations of this capability have been given to 457 the ICNRG in 2016, while public demonstrations were also provided at 458 events such as Mobile World Congress in 2016 [MWC_Demo]. The trial 459 has also been accepted by the ETSI MEC group as a proof-of-concept 460 with a demonstration at the ETSI MEC World Congress in 2016." 462 While the mentioned demonstrations all use the overlay international 463 deployment, both H2020 efforts plan ICN underlay trials in the summer 464 and fall of 2017. One such trial will involve commercial end users 465 located in the Primetel network in Cyprus with the use case centered 466 on IPTV and HLS video dissemination. Another trial is planned for 467 fall 2017 in the community network of "guifi.net" in the Barcelona 468 region, where the solution will be deployed in 40 households, 469 providing general Internet connectivity to the residents. Standard 470 IPTV STBs as well as HLS video players will be utilized in accordance 471 with the aim of this deployment configuration, namely to provide 472 application and service migration. 474 5.2.2. H2020 FLAME Efforts 476 Starting in January 2017, the H2020 FLAME efforts aims at providing 477 an experimental ground for the aforementioned POINT/RIFE solution in 478 initially two city-scale locations, namely in Bristol and Barcelona. 479 This trial will again follow the underlay deployment configuration in 480 Section 3.3.1 as per POINT/RIFE approach. Currently, experiments are 481 ongoing,conducted by the city/university joint venture Bristol-is- 482 Open (BIO), to ensure the readiness of the city-scale SDN transport 483 network for such experiments. A third trial of the aforementioned 484 ETSI MEC PoC is planned for mid 2017. This trial will showcase 485 operational benefits provided by the ICN underlay for the scenario of 486 a location-based game. These benefits aim at reduced network 487 utilization through improved video delivery performance (multicast of 488 all captured videos to the service surrogates deployed in the city at 489 six locations) as well as reduced latency through the playout of the 490 video originating from the local NAP instead of a remote server. 492 Ensuring the technology readiness and the early trialing of the ICN 493 capabilities lays the ground for the goal of the H2020 FLAME efforts 494 to conduct 23 large-scale experiments in the area of Future Media 495 Internet (FMI) throughout 2018 and 2019. Standard media service 496 functions as well as applications will ultimately utilize the ICN 497 underlay in the delivery of their experience. The platform, which 498 includes the ICN capabilities, will utilize concepts of SFC, 499 integrated with NFV and SDN capabilities of the infrastructure. The 500 ultimate goal of these platform efforts is the full integration of 501 ICN into the overall media function platform for the provisioning of 502 advanced (media-centric) internet services. 504 5.2.3. CableLabs Content Delivery System 506 The work in [White] proposes an underlay deployment configuration 507 based on Section 3.3.1. The use case is ICN for content distribution 508 within CDN server farms (which can be quite large and complex) to 509 leverage ICN's superior in-network caching properties. This "island 510 of ICN" based CDN is then used to service standard HTTP/IP-based 511 content retrieval request coming from the general Internet. This 512 approach acknowledges that whole scale replacement (see Section 3.1) 513 of existing HTTP/IP end user applications and related Web 514 infrastructure is a difficult proposition. [White] does not yet 515 provide results but indicated that experiments will be forthcoming. 517 6. Deployment Issues Requiring Further Standardization 519 The ICN Research Challenges [RFC7927] describes key ICN principles 520 and technical research topics. As the title suggests, [RFC7927] is 521 research oriented without a specific focus on deployment or 522 standardization issues. This section will address this open area by 523 identifying key protocol functionality that that we deem relevant for 524 further standardization effort in IETF. The focus is specifically on 525 identifying protocols that will facilitate future interoperable ICN 526 deployments correlating to the scenarios identified in the deployment 527 migration paths in Section 4. The identified list of required 528 protocol functionality is not exhaustive. 530 6.1. Protocols for Application and Service Migration 532 End user applications and services need a standardized approach to 533 trigger ICN transactions. For example, in Internet and Web 534 applications today, there are established socket APIs, communication 535 paradigms such as REST, common libraries, and best practices. We see 536 a need to study application requirements in an ICN environment 537 further and, at the same time, develop new APIs and best practices 538 that can take advantage of ICN communication characteristics. 540 6.2. Protocols for Content Delivery Network Migration 542 A key issue in CDNs is to quickly find a location of a copy of the 543 object requested by an end user. In ICN, a Named Data Object (NDO) 544 is typically defined by its name. There already exists [RFC6920] 545 that is suitable for static naming of ICN data objects. Other ways 546 of encoding and representing ICN names have been described in 547 [I-D.irtf-icnrg-ccnxmessages] and [I-D.mosko-icnrg-ccnxurischeme]. 548 Naming dynamically generated data requires different approaches (for 549 example, hash digest based names would normally not work), and there 550 is lack of established conventions and standards. 552 Another CDN issue for ICN is related to multicast distribution of 553 content. Existing CDNs have started using multicast mechanisms for 554 certain cases such as for broadcast streaming TV. However, as 555 discussed in Section 5.2.1, certain ICN approaches provide 556 substantial improvements over IP multicast, such as the implicit 557 support for multicast retrieval of content in all ICN flavours. 559 Caching is an implicit feature in many ICN architectures that can 560 improve performance and availability in several scenarios. The ICN 561 in-network caching can augment managed CDN and improve its 562 performance. The details of the interplay between ICN caching and 563 managed CDN need further consideration. 565 6.3. Protocols for Edge and Core Network Migration 567 ICN provides the potential to redesign current edge and core network 568 computing approaches. Leveraging ICN's inherent security and its 569 ability to make name data and dynamic computation results available 570 independent of location, can enable a secure, yet light-weight 571 insertion of traffic into the network without relying on redirection 572 of DNS requests. For this, proxies that translate from commonly used 573 protocols in the general Internet to ICN message exchanges in the ICN 574 domain could be used for the migration of application and services 575 within deployments at the network edge but also in core networks. 576 This is similar to existing approaches for IoT scenarios where a 577 proxy translates CoAP request/responses to other message formats. 578 For example, [RFC8075] specifies proxy mapping between CoAP and HTTP 579 protocols. However, as mentioned previously, ICN will allow us to 580 evolve the role of gateways/proxies as ICN message security should be 581 preserved through the protocol translation function of a thus offer a 582 substantial gain. Another area is integration of ICN into networks 583 that support virtualized infrastructure in the form of NFV/SDN. 584 Further work is required to validate this idea and document best 585 practices. 587 6.4. Summary of ICN Protocol Gaps and Potential IETF Efforts 589 Without claiming completeness, Table 1 maps the open the open ICN 590 deployment protocol issues identified in this document to potential 591 IETF groups that could address some aspects of them. An example of a 592 specific gap that the group could potentially address is identified 593 in parenthesis beside the group name. 595 +--------------+----------------------------------------------------+ 596 | ICN Protocol | Potential IETF Group | 597 | Gaps | | 598 +--------------+----------------------------------------------------+ 599 | 1-Support of | HTTPBIS and CORE WG | 600 | REST APIs | (e.g., HTTP/CoAP support of ICN semantics) | 601 | | | 602 | 2-Naming | New BoF/WG** | 603 | | (e.g., Dynamic naming of ICN data objects) | 604 | | | 605 | 3-Multicast | BIER or new BoF/WG** | 606 | distribution | (e.g., Multicast enhancements for ICN) | 607 | | | 608 | 4-In-network | New BoF/WG** | 609 | caching | (e.g., Cache placement and sharing) | 610 | | | 611 | 5-NFV/SDN | SFC or New BoF/WG** | 612 | Support | (e.g., Integration of ICN with NFV/SDN) | 613 | | | 614 | 6-ICN | New BoF/WG** | 615 | mapping | (e.g., Mapping of HTTP and other protocols onto | 616 | | ICN message exchanges while preserving ICN message | 617 | | security) | 618 | | | 619 | | ** May be a single BoF/WG, or multiple BoF/WGs, | 620 | | that addresses all these topics. | 621 +--------------+----------------------------------------------------+ 623 Table 1: Mapping of ICN Protocol Gaps to Potential IETF Groups 625 7. Conclusion 627 This document provides high level deployment considerations for the 628 ICN community. Specifically, the major configurations of possible 629 ICN deployments are identified as (1) wholesale replacement of 630 existing Internet infrastructure; (2) ICN-as-an-Overlay; (3) ICN-as- 631 an-Underlay; and (4) ICN-in-a-Slice. Existing ICN trial systems fall 632 either under the ICN-as-an-Overlay or ICN-as-an-Underlay 633 configuration. 635 In terms of deployment migration paths, ICN-as-an-Underlay offers a 636 clear migration path for existing CDN, edge and core networks to go 637 to an ICN paradigm. ICN-in-a-Slice is an attractive deployment 638 option for future 5G systems (i.e., for 5G radio and core networks) 639 which will naturally support network slicing, but this still has to 640 be validated through actual trial experiences. Finally, for the 641 crucial issue of existing application and service migration to ICN, 642 various mapping schemes are possible to mitigate impacts. For 643 example, HTTP/TCP/IP flows may be mapped to ICN message flows at a 644 proxy in the ICN-as-an-Underlay configurations leaving the massive 645 number of existing end point applications/services untouched or 646 minimally impacted. 648 Finally, this document describes a set of technical features in ICN 649 that warrant future specification work. For initial and incremental 650 deployment it will be useful to address some of these features and 651 corresponding specification work items in existing IETF working 652 groups and/or new BoFs. We have proposed a corresponding mapping of 653 topics to potential WGs and/or BoFs to provide a representative 654 framework. The fundamental details of the protocol specification 655 effort, however, are best left for future study by the appropriate 656 WGs and/or BoFs. 658 8. IANA Considerations 660 This document requests no IANA actions. 662 9. Security Considerations 664 ICN was purposefully designed from the start to have certain 665 intrinsic security properties. The most well known of which are 666 authentication of delivered content and (optional) encryption of the 667 content. [RFC7945] has an extensive discussion of various aspects of 668 ICN security including many which are relevant to deployments. 669 Specifically, [RFC7945] points out that ICN access control, privacy, 670 security of in-network caches, and protection against various network 671 attacks (e.g. DoS) have not yet been fully developed due to the lack 672 of real deployments. [RFC7945] also points out relevant advances 673 occurring in the ICN research community that hold promise to address 674 each of the identified security gaps. Lastly, [RFC7945] points out 675 that as secure communications in the existing Internet (e.g. HTTPS) 676 becomes the norm, that major gaps in ICN security will inevitably 677 slow down the adoption of ICN. 679 In addition to the security findings of [RFC7945], this document has 680 highlighted that all anticipated ICN deployment configurations will 681 involve co-existence with existing Internet infrastructure and 682 applications. Thus even the basic authentication and encryption 683 properties of ICN content will need to account for interworking with 684 non-ICN content to preserve end-to-end security. For example, in the 685 edge network underlay deployment configuration described in 686 Section 3.3.2, the gateway/proxy that translates HTTP or CoAP 687 request/responses into ICN message exchanges will need to support a 688 model to preserve end-to-end security. 690 10. Acknowledgments 692 The authors want to thank Alex Afanasyev, Xavier de Foy, Hannu 693 Flinck, Dave Oran, Ravishankar Ravindran, and Prakash Suthar for 694 their very useful reviews and comments to the document. 696 11. Informative References 698 [C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking 699 over OpenFlow", Open Networking Summit, April, 2012, 700 . 703 [CCNx_UDP] 704 PARC, , "CCNx Over UDP", 2015, 705 . 708 [CONET] Veltri, L. and et al., "CONET Project: Supporting 709 Information-Centric Functionality in Software Defined 710 Networks", Workshop on Software Defined Networks, , 2012, 711 . 714 [DASH] DASH, , "DASH Industry Forum", 2017, . 716 [Hybrid_ICN] 717 Cisco, , "Hybrid ICN: Cisco Announces Important Steps 718 toward Adoption of Information-Centric Networking", 2017, 719 . 722 [I-D.ietf-bier-use-cases] 723 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 724 Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., 725 Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases", 726 draft-ietf-bier-use-cases-04 (work in progress), January 727 2017. 729 [I-D.irtf-icnrg-ccnxmessages] 730 marc.mosko@parc.com, m., Solis, I., and C. Wood, "CCNx 731 Messages in TLV Format", draft-irtf-icnrg-ccnxmessages-04 732 (work in progress), March 2017. 734 [I-D.kutscher-icnrg-netinf-proto] 735 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 736 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 737 progress), February 2013. 739 [I-D.mosko-icnrg-ccnxurischeme] 740 marc.mosko@parc.com, m. and c. cwood@parc.com, "The CCNx 741 URI Scheme", draft-mosko-icnrg-ccnxurischeme-01 (work in 742 progress), April 2016. 744 [I-D.paik-icn-deployment-considerations] 745 Paik, E., Yun, W., Kwon, T., and h. 746 hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for 747 Information-Centric Networking", draft-paik-icn- 748 deployment-considerations-00 (work in progress), July 749 2013. 751 [IEEE_Communications] 752 Trossen, D. and G. Parisis, "Designing and Realizing an 753 Information-Centric Internet", Information-Centric 754 Networking, IEEE Communications Magazine Special Issue, 755 2012. 757 [Internet_Pricing] 758 Trossen, D. and G. KBiczok, "Not Paying the Truck Driver: 759 Differentiated Pricing for the Future Internet", ReArch 760 Workshop in conjunction with ACM Context, December, 2010. 762 [Jacobson] 763 Jacobson, V. and et al., "Networking Named Content", 764 Proceedings of ACM Context, , 2009. 766 [Moiseenko] 767 Moiseenko, I. and D. Oran, "TCP/ICN : Carrying TCP over 768 Content Centric and Named Data Networks", 2016, 769 . 772 [MWC_Demo] 773 InterDigital, , "InterDigital Demo at Mobile World 774 Congress (MWC)", 2016, . 777 [oneM2M] OneM2M, , "oneM2M Service Layer Standards for M2M and 778 IoT", 2017, . 780 [POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better 781 IP?", European Conference on Networks and Communications 782 (EuCNC), , 2015. 784 [Ravindran] 785 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 786 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 787 Network Slicing", 2016, . 790 [Reed] Reed, M. and et al., "Stateless Multicast Switching in 791 Software Defined Networks", ICC 2016, Kuala Lumpur, 792 Malaysia, 2016. 794 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 795 Keranen, A., and P. Hallam-Baker, "Naming Things with 796 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 797 . 799 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 800 Application Protocol (CoAP)", RFC 7252, 801 DOI 10.17487/RFC7252, June 2014, 802 . 804 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 805 Chaining (SFC) Architecture", RFC 7665, 806 DOI 10.17487/RFC7665, October 2015, 807 . 809 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 810 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 811 "Information-Centric Networking (ICN) Research 812 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 813 . 815 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 816 and G. Boggia, "Information-Centric Networking: Evaluation 817 and Security Considerations", RFC 7945, 818 DOI 10.17487/RFC7945, September 2016, 819 . 821 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 822 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 823 the Constrained Application Protocol (CoAP)", RFC 8075, 824 DOI 10.17487/RFC8075, February 2017, 825 . 827 [SAIL_NetInf] 828 FP7, , "SAIL Prototyping and Evaluation", 2013, 829 . 832 [Tateson] Tateson, J. and et al., "Final Evaluation Report on 833 Deployment Incentives and Business Models", 2010, 834 . 837 [Techno_Economic] 838 Trossen, D. and A. Kostopolous, "Techno-Economics Aspects 839 of Information-Centric Networking", Journal for 840 Information Policy, Volume 2, 2012. 842 [White] White, G. and G. Rutz, "Content Delivery with Content 843 Centric Networking, CableLabs White Paper", 2010, 844 . 848 Authors' Addresses 850 Akbar Rahman 851 InterDigital Inc. 852 1000 Sherbrooke Street West, 10th floor 853 Montreal H3A 3G4 854 Canada 856 Email: Akbar.Rahman@InterDigital.com 857 URI: http://www.InterDigital.com/ 859 Dirk Trossen 860 InterDigital Inc. 861 64 Great Eastern Street, 1st Floor 862 London EC2A 3QR 863 United Kingdom 865 Email: Dirk.Trossen@InterDigital.com 866 URI: http://www.InterDigital.com/ 868 Dirk Kutscher 869 Huawei German Research Center 870 Riesstrasse 25 871 Munich 80992 872 Germany 874 Email: ietf@dkutscher.net 875 URI: http://www.Huawei.com/