idnits 2.17.1 draft-rahman-icnrg-deployment-guidelines-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2017) is 2595 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-03 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 5 Expires: September 12, 2017 D. Kutscher 6 Huawei 7 March 11, 2017 9 Deployment Configurations for Information-Centric Networks (ICN) 10 draft-rahman-icnrg-deployment-guidelines-00 12 Abstract 14 This document provides technical deployment guidelines for the ICN 15 community. First, the possible deployment configurations for ICN are 16 described including overlay and underlay approaches. Then proposed 17 deployment migration paths for these configurations are outlined to 18 address the major issues facing ICN such as application migration, 19 and core and edge network migration. Next, selected ICN trial 20 experiences are summarized. Finally, recommendations are given for 21 protocol areas that require further standardization to facilitate 22 future ICN interoperable deployments. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 12, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Deployment Configurations . . . . . . . . . . . . . . . . . . 4 61 3.1. Wholesale Replacement . . . . . . . . . . . . . . . . . . 4 62 3.2. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 4 63 3.3. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 5 64 3.3.1. HTTP/IP-over-ICN . . . . . . . . . . . . . . . . . . 5 65 3.3.2. Native ICN with Application Gateways . . . . . . . . 5 66 3.4. ICN-as-a-Slice . . . . . . . . . . . . . . . . . . . . . 6 67 4. Deployment Migration Paths . . . . . . . . . . . . . . . . . 6 68 4.1. Application and Service Migration . . . . . . . . . . . . 6 69 4.2. Content Delivery Network Migration . . . . . . . . . . . 7 70 4.3. Edge Network Migration . . . . . . . . . . . . . . . . . 7 71 4.4. Core Network Migration . . . . . . . . . . . . . . . . . 8 72 5. Deployment Trial Experiences . . . . . . . . . . . . . . . . 8 73 5.1. FP7 Pursuit Efforts . . . . . . . . . . . . . . . . . . . 8 74 5.2. H2020 POINT and RIFE Efforts . . . . . . . . . . . . . . 8 75 5.3. H2020 FLAME Efforts . . . . . . . . . . . . . . . . . . . 9 76 5.4. FP7 SAIL Trial . . . . . . . . . . . . . . . . . . . . . 10 77 5.5. NDN Testbed . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.6. CableLabs Content Delivery System . . . . . . . . . . . . 10 79 6. Deployment Issues Requiring Further Standardization . . . . . 11 80 6.1. Protocols for Application and Service Migration . . . . . 11 81 6.2. Protocols for Content Delivery Network Migration . . . . 11 82 6.3. Protocols for Edge and Core Network Migration . . . . . . 12 83 6.4. Summary of ICN Protocol Gaps and Potential IETF Efforts . 12 84 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 88 11. Informative References . . . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 The ICNRG charter identifies deployment guidelines as an important 94 topic area for the ICN community. Specifically, the charter states 95 that defining concrete migration paths for ICN deployments which 96 avoid forklift upgrades, and defining practical ICN interworking 97 configurations with the existing Internet paradigm, are key topic 98 areas that require further investigation. Also, it is well 99 understood that results and conclusions from any mid to large-scale 100 ICN experiments in the live Internet will also provide useful 101 guidance for deployments. 103 However, so far outside of some preliminary investigations such as 104 [I-D.paik-icn-deployment-considerations], there has not been much 105 progress on this topic. This draft attempts to fill some of these 106 gaps by defining clear deployment configurations for ICN, and 107 associated migration pathways for these configurations. Also, 108 selected deployment trial experiences of ICN technology are 109 summarized. Finally, recommendations are made for future IETF 110 standardization of key protocol functionality that will facilitate 111 interoperable ICN deployments going forward. 113 2. Terminology 115 The following key terms and concepts are defined: 117 Information-Centric Networking (ICN) - ICN is an approach to 118 evolve the Internet infrastructure (e.g. routers, caches, servers) 119 towards accessing named data as a first-order network layer 120 service. In this approach, Named Data Objects (NDOs) are named 121 and secured individually. Hashing and/or Public-Key Cryptography 122 are used to provide NDO authentication and integrity validation 123 (amongst other services). ICN's data-oriented security (instead 124 of connection-based security) can enable several benefits: message 125 authentication and optionally encryption are fundamental elements 126 of the system, and the forwarding layer can be empowered to 127 implement suitable forwarding strategies and additional 128 functionality such as caching, local retransmissions, etc. 130 Software-Defined Networking (SDN) - SDN is a network control and 131 implementation architecture that disaggregates the network control 132 and forwarding functions. This enables programming network 133 elements (e.g. routers, switches) that implement packet forwarding 134 functions using a control abstraction, e.g., OpenFlow's Match- 135 Action-based abstraction. Corresponding controllers can have 136 visibility and control of a larger set of SDN elements in a 137 network deployment, which enables network programmability. This 138 can be used to achieve several objectives such as network 139 virtualization, optimized forwarded, failure resilience, etc. 141 Deployment - In the context of this document, deployment refers to 142 the final stage of the process of setting up an ICN network that 143 is (1) integrated and interoperable with the rest of the Internet, 144 and (2) ready for useful work (e.g. transmission of end user video 145 and text) in a live environment. 147 3. Deployment Configurations 149 In this section, we present various deployment options for ICN. 150 These are presented as "configurations" that allow for studying these 151 options further. While this document will outline (in Section 5) 152 experiences with various of these configurations, we will not provide 153 an in-depth technical or commercial evaluation for any of them - for 154 this we refer to existing literature in this space such as [Tateson]. 156 3.1. Wholesale Replacement 158 ICN has often been described as a "clean-slate" approach with the 159 goal to renew or replace the current IP routing fabric of the 160 Internet. As such, existing routing hardware as well as ancillary 161 services have not been taken for granted. This clean-slate view is 162 reflected as deployment configurations we label as "wholesale 163 replacement" of large part of the existing Internet infrastructure. 164 For instance, such configuration would see existing IP routers being 165 replaced by CCN routers [Jacobson] or Bloom-filter based forwarding 166 elements [IEEE_Communications]. All major ICN flavors have explored 167 this option as their path to deployment. 169 While such replacement could be seen as exclusive for ICN 170 deployments, some ICN propositions [POINT] rely on the deployment of 171 infrastructure upgrades, here SDN switches. Such upgrades, while 172 being possibly utilized for a "clean slate" ICN deployment would not 173 necessary be used exclusively for an ICN deployment. Different 174 proposals have been made for various ICN flavors to enable the 175 operation over an SDN transport [Reed][CONET][C_FLOW]. 177 3.2. ICN-as-an-Overlay 179 Similar to other significant changes to the Internet routing fabric, 180 particularly the transition from IPv4 to IPv6 or the introduction of 181 IP multicast, this deployment configuration foresees the creation of 182 an ICN overlay. Note that this overlay approach is sometimes also 183 referred to as a tunneling approach. The overlay approach could be 184 done directly such as ICN-over-UDP as described in [CCNx_UDP]. 185 Alternatively, the overlay could be done via ICN-in-L2-in-IP as 186 described in [IEEE_Communications]. 188 Another flavor of overlay would be embedding ICN semantics into 189 existing proposals. A recently announced approach is [Hybrid_ICN] 190 where the ICN names are mapped to IPv6 addresses. Another approach 191 used in the Network of Information (NetInf) is to define a 192 convergence layer to map NetInf semantics to HTTP 193 [I-D.kutscher-icnrg-netinf-proto]. Regardless of the flavor, 194 however, the overlay approach results in islands of ICN deployments 195 over existing IP-based infrastructure. 197 3.3. ICN-as-an-Underlay 199 Proposals such as [POINT] and [White] outline the deployment option 200 of using an ICN underlay that would integrate with existing IP-based 201 services, while possibly still allowing for native ICN applications 202 to emerge. The main reasons for such configuration option is the 203 backward-compatible introduction of ICN technology, while possibly 204 reaping the benefits of ICN in terms of multicast delivery, mobility 205 support, fast indirection due to location independence, and possibly 206 more. 208 3.3.1. HTTP/IP-over-ICN 210 In this sub-option, a deployment configuration would utilize edge- 211 based protocol mapping onto the native ICN underlay. For instance, 212 [POINT] proposes to map either raw IP packets or HTTP transactions 213 directly onto an ICN-based message exchange. This mapping is 214 realized at the network attachment point, such as realized in access 215 points or customer premise equipment, which in turn provides a 216 standard IP interface to existing user devices. Towards peering 217 networks, such network attachment point turns into a modified border 218 gateway, preserving the perception of an IP-based network towards any 219 peering network. 221 The work in [White] proposes a similar deployment configuration. 222 Here, the target is the use of ICN for content distribution within 223 CDN server farms, i.e., the protocol mapping is realized at the 224 ingress of the server farm where the HTTP-based retrieval request is 225 served, while the response is delivered through a suitable egress 226 node translation. 228 3.3.2. Native ICN with Application Gateways 230 Native ICN networks may be found at the edge of the network, mostly 231 proposed for Internet-of-Things deployments. The integration with 232 the current IP protocol suite takes place at an application gateway 233 at the edge network boundary, e.g., translating incoming CoAP 234 request/response transactions [RFC7252] into ICN message exchanges. 235 However, ICN will allow us to evolve the role of gateways as ICN 236 message security should be preserved through the protocol translation 237 function of a gateway and thus offer a substantial gain. 239 3.4. ICN-as-a-Slice 241 With the advent of network slicing, i.e., the ability to isolate 242 network resources exclusively towards a specific set of network 243 functions, the deployment of ICN within such isolated slice is 244 emerging as another deployment configuration. Coupled with the view 245 of ICN functions as being "chained service functions" [RFC7665], an 246 ICN deployment within such a slice could be realized within the 247 emerging control plane that is targeted for adoption in future (e.g., 248 5th generation mobile) network deployments. Nonetheless, at the 249 level of the specific technologies involved, this requires 250 compatibility for instance at the level of the forwarding/data plane. 251 With SDN emerging as a novel data plane for new network deployments, 252 ICN flavors will need to integrate with SDN as a data plane 253 forwarding function, as briefly discussed in Section 3.1. 255 4. Deployment Migration Paths 257 After outlining the various ICN deployment configurations in 258 Section 3, we now focus on the various migration paths that might 259 have an importance to the various stakeholders that are usually 260 involved in the deployment of a technology at (ultimately) large 261 scale. We can identify these stakeholders as: 263 o Application developers and service providers 265 o ISPs, both as core as well as access network providers 267 o CDN providers (due to the strong relation of the ICN proposition 268 to content delivery) 270 Note that our presentation purely focuses on technological aspects of 271 such migration. Economic or regulatory aspects, such as studied in 272 [Tateson], [Techno_Economic] and [Internet_Pricing] are left out of 273 our discussion. 275 4.1. Application and Service Migration 277 The internet is full of applications and services, utilizing the 278 innovation capabilities of the many protocols defined over the packet 279 level IP service. HTTP provides one convergence point for these 280 services with many web development frameworks based on the semantics 281 provided by the hypertext transfer protocol. In recent years, even 282 services such as video delivery have been migrating from the 283 traditional RTP-over-UDP delivery to the various HTTP-level streaming 284 solutions, such as DASH [DASH] and others. Nonetheless, many non- 285 HTTP services exist, all of which need consideration when migrating 286 from the IP-based internet to an ICN-based one. 288 The configuration options presented in Section 3.3.1 and 289 Section 3.3.2 aim at providing some level of backward compatibility 290 to this existing ecosystem. Alternatively, introducing ICN as an 291 overlay (Section 3.2) as well as within-a-slice (Section 3.4) aims at 292 introducing the full capabilities of ICN through new service 293 interfaces as well as operations in the network. The overlay and 294 within-a-slice approaches of deployment are likely to be more 295 disruptive at the application and service level, however more new 296 services are expected to be introduced based on such an approach. 298 4.2. Content Delivery Network Migration 300 A significant number of services and applications are devoted to 301 content delivery in some form, either as video delivery services, 302 social media platforms, and many others. Content delivery networks 303 (CDNs) are deployed to assist these services through localizing the 304 content requests and therefore reducing latency and possibly increase 305 utilization of available bandwidth. Similar to the previous sub- 306 section, the deployment configurations presented in Section 3.3.1 and 307 Section 3.3.2 aim at providing a migration path for existing CDNs. 308 This is also highlighted in the BIER WG use case draft 309 [I-D.ietf-bier-use-cases], specifically with potential benefits in 310 terms of utilizing multicast in the delivery of content. We return 311 to this benefit in the trial experiences in Section 5. 313 4.3. Edge Network Migration 315 Edge networks often see the deployment of novel network level 316 technology, e.g., in the space of the Internet of Things (IoT). Such 317 IoT deployments have for many years relied, and often still do, on 318 proprietary protocols for reasons such as increased efficiency, lack 319 of standardization incentives and others. Utilizing the deployment 320 configuration in Section 3.3.2, application gateways can integrate 321 such edge deployments into IP-based services, e.g., utilizing CoAP 322 [RFC7252] based machine-to-machine (M2M) platforms such as oneM2M 323 [oneM2M] or others. 325 Another area of increased edge network innovation is that mobile 326 (access) networks, particularly in the context of the 5th generation 327 of mobile networks (often called "5G"). With the proliferation of 328 SDN-based transport for access networks, the deployment configuration 329 in Section 3.4 provides a suitable migration path for integration 330 non-IP-based edge networks into the overall system through virtue of 331 realizing the relevant (ICN) protocols in an access network slice. 333 4.4. Core Network Migration 335 Migrating the core network of the Internet requires not only 336 significant infrastructure renewal but also the fulfillment of the 337 significant performance requirements, particularly in terms of 338 throughput. For those parts of the core network that would see a 339 migration to an SDN-based transport, such as proposed by major 340 operators such as AT&T, the deployment configuration in Section 3.4 341 could see the introduction of native ICN solutions within slices 342 provided by the SDN-enabled transport network. For ICN solutions 343 that natively work on top of SDN, Section 3.3.1 provides an 344 additional migration, preserving the IP-based services and 345 applications at the edge of the network, while realizing the core 346 network routing through an ICN solution (possibly itself realized in 347 a slice of the SDN transport network). 349 5. Deployment Trial Experiences 351 In this section, we will outline trial experiences, often conducted 352 within international collaborative project efforts. Our focus here 353 is on the realization of the various deployment configurations in 354 Section 3. While a body of work exists at the simulation or 355 emulation level, we specifically exclude these studies from our 356 presentation to retain the focus on real experiences. We recognize 357 that this section is unlikely to be comprehensive. We will therefore 358 continue to solicit input from ICNRG members for other deployment 359 experiences to complete this section. 361 5.1. FP7 Pursuit Efforts 363 Although the FP7 PURSUIT [IEEE_Communications] efforts were generally 364 positioned as a wholesale replacement of IP (Section 3.1), the 365 project realized its experimental test bed as an L2 VPN-based overlay 366 between several European, US as well as Asian sites, i.e., following 367 the deployment configuration presented in Section 3.2. Software- 368 based forwarders were utilized for the ICN message exchange, while 369 native ICN applications, e.g., for video transmissions, were 370 showcased. At the height of the project efforts, about 70+ nodes 371 were active in the (overlay) network with presentations given at 372 several conferences as well as to the ICNRG. 374 5.2. H2020 POINT and RIFE Efforts 376 The efforts in the H2020 POINT+RIFE projects follow the deployment 377 configuration in Section 3.3.1, although utilizing an overlay 378 deployment to provide multi-national connectivity. However, pure 379 SDN-based deployments do exist at various project partner sites, 380 e.g., at Essex University, without any overlaying being realized. 382 Edge-based network attachment points (NAPs) provide the IP/HTTP-level 383 protocol mapping onto ICN protocol exchanges, while the SDN underlay 384 (or the VPN-based L2 underlay) is used as a transport network. 386 The multicast as well as service endpoint surrogate benefits in HTTP- 387 based scenarios, such as for HTTP-level streaming video delivery, 388 have been demonstrated in the deployed POINT test bed with 80+ nodes 389 being utilized. Demonstrations of this capability have been given to 390 the ICNRG in 2015 and 2016, respectively, while public demonstrations 391 were provided at events such as Mobile World Congress in 2016 392 [MWC_Demo]. The trial has also been accepted by the ETSI MEC group 393 as a proof-of-concept with a demonstration at the ETSI MEC World 394 Congress in Munich in September 2016." 396 While the mentioned demonstrations all use the overlay international 397 deployment, both H2020 efforts plan pure ICN underlay trials in the 398 summer and fall of 2017. One such trial will involve real end users 399 located in the Primetel network in Cyprus with the use case centered 400 on IPTV and HLS video dissemination. Another trial is planned for 401 fall 2017 in the community network of "guifi.net" in the Barcelona 402 region, where the solution will be deployed in 40 households, 403 providing general Internet connectivity to the residents. Standard 404 IPTV STBs as well as HLS video players will be utilized in accordance 405 with the aim of this deployment configuration, namely to provide 406 application and service migration. 408 5.3. H2020 FLAME Efforts 410 Starting in January 2017, the H2020 FLAME efforts aims at providing 411 an experimental ground for the aforementioned POINT/RIFE solution in 412 initially two city-scale locations, namely in Bristol and Barcelona. 413 This trial will again follow the deployment configuration in 414 Section 3.3.1 as per POINT/RIFE approach. Currently, experiments are 415 ongoing,conducted by the city/university joint venture Bristol-is- 416 Open (BIO), to ensure the readiness of the city-scale SDN transport 417 network for such experiments. At the time of initial publication of 418 this draft in March 2017, the deployment of the ICN underlay onto the 419 SDN transport network will be finalized with the aim of running the 420 third trial of the aforementioned ETSI MEC PoC in the network during 421 April/May of 2017. This third trial will showcase operational 422 benefits provided by the ICN underlay for the scenario of a location- 423 based game. These benefits aim at reduced network utilization 424 through improved video delivery performance (multicast of all 425 captured videos to the service surrogates deployed in the city at six 426 locations) as well as reduced latency through the playout of the 427 video originating from the local NAP instead of a remote server. 429 Ensuring the technology readiness and the early trialing of the ICN 430 capabilities lays the ground for the goal of the H2020 FLAME efforts 431 to conduct 23 large-scale experiments in the area of Future Media 432 Internet (FMI) throughout 2018 and 2019. Standard media service 433 functions as well as applications will ultimately utilize the ICN 434 underlay in the delivery of their experience. The platform, which 435 includes the ICN capabilities, will utilize concepts of SFC, 436 integrated with NFV and SDN capabilities of the infrastructure. The 437 ultimate goal of these platform efforts is the full integration of 438 ICN into the overall media function platform for the provisioning of 439 advanced (media-centric) internet services. 441 5.4. FP7 SAIL Trial 443 The Network of Information (NetInf) is the approach to Information- 444 Centric Networking developed by the EU FP7 SAIL project 445 (http://www.sail-project.eu/). NetInf provides both name-based 446 forwarding with CCNx-like semantics and name resolution (for 447 indirection and late-binding). The NetInf architecture supports 448 different deployment options through its convergence layer 449 abstraction. In its first prototypes and trials, NetInf was deployed 450 mostly in an HTTP embedding and in a UDP overlay following the 451 deployment configuration in Section 3.2. Reference [SAIL_NetInf] 452 describes several trials including a stadium environment large crowd 453 scenario and a multi-site testbed, leveraging NetInf's Routing Hint 454 approach for routing scalability. 456 5.5. NDN Testbed 458 The Named Data Networking (NDN) is one of the research projects 459 funded by the National Science Foundation (NSF) of the USA as part of 460 the Future Internet Architecture Program. The original NDN proposal 461 was positioned as a wholesale replacement of IP (Section 3.1). 462 However, in several trials, NDN generally follows the overlay 463 deployment configuration of Section 3.2 to connect institutions over 464 the public Internet across several continents. The use cases covered 465 in the trials include real-time video-conferencing, geo-locating, and 466 interfacing to consumer applications. Typical trials involve several 467 hundred NDN enabled nodes (https://named-data.net/ndn-testbed/). 469 5.6. CableLabs Content Delivery System 471 The work in [White] proposes a deployment configuration based on 472 Section 3.3.1. The use case is ICN for content distribution within 473 CDN server farms (which can be quite large and complex) to leverage 474 ICNs superior in-network caching properties. This "island of ICN" 475 based CDN is then used to service standard HTTP/IP-based content 476 retrieval request coming from the general Internet. This approach 477 acknowledges that whole scale replacement (see Section 3.1) of 478 existing HTTP/IP end user applications and related Web infrastructure 479 is a difficult proposition. [White] does not yet provide results but 480 indicated that experiments will be forthcoming. 482 6. Deployment Issues Requiring Further Standardization 484 The ICN Research Challenges [RFC7927] describes key ICN principles 485 and technical research topics. As the title suggests, [RFC7927] is 486 research oriented without a specific focus on deployment or 487 standardization issues. This section will address this open area by 488 identifying key protocol functionality that that we deem relevant for 489 further standardization effort in IETF. The focus is specifically on 490 identifying protocols that will facilitate future interoperable ICN 491 deployments correlating to the scenarios identified in the deployment 492 migration paths in Section 4. The identified list of required 493 protocol functionality is not exhaustive. 495 6.1. Protocols for Application and Service Migration 497 End user applications and services need a standardized approach to 498 trigger ICN transactions. For example, in Internet and Web 499 applications today, there are established socket APIs, communication 500 paradigms such as REST, common libraries, and best practices. We see 501 a need to study application requirements in an ICN environment 502 further and, at the same time, develop new APIs and best practices 503 that can take advantage of ICN communication characteristics. 505 6.2. Protocols for Content Delivery Network Migration 507 A key issue in CDNs is to quickly find a location of a copy of the 508 object requested by an end user. In ICN, a Named Data Object (NDO) 509 is typically defined by its name. There already exists [RFC6920] 510 that is suitable for static naming of ICN data objects. Other ways 511 of encoding and representing ICN names have been described in 512 [I-D.irtf-icnrg-ccnxmessages] and [I-D.mosko-icnrg-ccnxurischeme]. 513 Naming dynamically generated data requires different approaches (for 514 example, hash digest based names would normally not work), and there 515 is lack of established conventions and standards. 517 Another CDN issue for ICN is related to multicast distribution of 518 content. Existing CDNs have started using multicast mechanisms for 519 certain cases such as for broadcast streaming TV. However, as 520 discussed in Section 5.2, certain ICN approaches provide substantial 521 improvements over IP multicast, such as the implicit support for 522 multicast retrieval of content in all ICN flavours. 524 Caching is an implicit feature in many ICN architectures that can 525 improve performance and availability in several scenarios. The ICN 526 in-network caching can augment managed CDN and improve its 527 performance. The details of the interplay between ICN caching and 528 managed CDN need further consideration. 530 6.3. Protocols for Edge and Core Network Migration 532 ICN provides the potential to redesign current edge and core network 533 computing approaches. Leveraging ICN's inherent security and its 534 ability to make name data and dynamic computation results available 535 independent of location, can enable a secure, yet light-weight 536 insertion of traffic into the network without relying on redirection 537 of DNS requests. For this, gateways that translate from commonly 538 used protocols in the general Internet to ICN message exchanges in 539 the ICN domain could be used for the migration of application and 540 services within deployments at the network edge but also in core 541 networks. This is similar to existing approaches for IoT scenarios 542 where a gateway translates CoAP request/responses to other message 543 formats. For example, [RFC8075] specifies gateway mapping between 544 CoAP and HTTP protocols. However, as mentioned previously, ICN will 545 allow us to evolve the role of gateways as ICN message security 546 should be preserved through the protocol translation function of a 547 gateway and thus offer a substantial gain. Another area is 548 integration of ICN into networks that support virtualized 549 infrastructure in the form of NFV/SDN. Further work is required to 550 validate this idea and document best practices. 552 6.4. Summary of ICN Protocol Gaps and Potential IETF Efforts 554 Without claiming completeness, Table 1 maps the open the open ICN 555 deployment protocol issues identified in this document to potential 556 IETF groups that could address some aspects of them. An example of a 557 specific gap that the group could potentially address is identified 558 in parenthesis beside the group name. 560 +--------------+----------------------------------------------------+ 561 | ICN Protocol | Potential IETF Group | 562 | Gaps | | 563 +--------------+----------------------------------------------------+ 564 | 1-Support of | HTTPBIS and CORE WG | 565 | REST APIs | (HTTP/CoAP support of ICN semantics) | 566 | | | 567 | 2-Naming | New BoF/WG | 568 | | (Dynamic naming of ICN data objects) | 569 | | | 570 | 3-Multicast | BIER or new BoF/WG | 571 | distribution | (Multicast enhancements for ICN) | 572 | | | 573 | 4-In-network | New BoF/WG | 574 | caching | (Cache placement and sharing) | 575 | | | 576 | 5-NFV/SDN | SFC or New BoF/WG | 577 | Support | (Integration of ICN with NFV/SDN) | 578 | | | 579 | 6-ICN | New BoF/WG | 580 | mapping | (Mapping of HTTP and other protocols onto ICN | 581 | | message exchanges while preserving ICN message | 582 | | security) | 583 | | | 584 +--------------+----------------------------------------------------+ 586 Table 1: Mapping of ICN Protocol Gaps to Potential IETF Groups 588 7. Conclusion 590 This documents describes a set of technical features in ICN that 591 warrant future specification work. For initial and incremental 592 deployment it can be useful to address some of these features and 593 corresponding specification work items in existing IETF working 594 groups. In this document, we have proposed a corresponding mapping 595 of topics to WGs. The fundamental protocols specifications may still 596 be best addressed by a specific WG. 598 8. IANA Considerations 600 This document requests no IANA actions. 602 9. Security Considerations 604 TBD. 606 10. Acknowledgments 608 The authors want to thank Xavier de Foy for his very useful reviews 609 and comments to the document. 611 11. Informative References 613 [C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking 614 over OpenFlow", Open Networking Summit, April, 2012, 615 . 618 [CCNx_UDP] 619 PARC, , "CCNx Over UDP", 2015, 620 . 623 [CONET] Veltri, L. and et al., "CONET Project: Supporting 624 Information-Centric Functionality in Software Defined 625 Networks", Workshop on Software Defined Networks, , 2012, 626 . 629 [DASH] DASH, , "DASH Industry Forum", 2017, . 631 [Hybrid_ICN] 632 Cisco, , "Hybrid ICN: Cisco Announces Important Steps 633 toward Adoption of Information-Centric Networking", 2017, 634 . 637 [I-D.ietf-bier-use-cases] 638 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 639 Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., 640 Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases", 641 draft-ietf-bier-use-cases-04 (work in progress), January 642 2017. 644 [I-D.irtf-icnrg-ccnxmessages] 645 marc.mosko@parc.com, m., Solis, I., and c. cwood@parc.com, 646 "CCNx Messages in TLV Format", draft-irtf-icnrg- 647 ccnxmessages-03 (work in progress), June 2016. 649 [I-D.kutscher-icnrg-netinf-proto] 650 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 651 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 652 progress), February 2013. 654 [I-D.mosko-icnrg-ccnxurischeme] 655 marc.mosko@parc.com, m. and c. cwood@parc.com, "The CCNx 656 URI Scheme", draft-mosko-icnrg-ccnxurischeme-01 (work in 657 progress), April 2016. 659 [I-D.paik-icn-deployment-considerations] 660 Paik, E., Yun, W., Kwon, T., and h. 661 hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for 662 Information-Centric Networking", draft-paik-icn- 663 deployment-considerations-00 (work in progress), July 664 2013. 666 [IEEE_Communications] 667 Trossen, D. and G. Parisis, "Designing and Realizing an 668 Information-Centric Internet", Information-Centric 669 Networking, IEEE Communications Magazine Special Issue, 670 2012. 672 [Internet_Pricing] 673 Trossen, D. and G. KBiczok, "Not Paying the Truck Driver: 674 Differentiated Pricing for the Future Internet", ReArch 675 Workshop in conjunction with ACM Context, December, 2010. 677 [Jacobson] 678 Jacobson, V. and et al., "Networking Named Content", 679 Proceedings of ACM Context, , 2009. 681 [MWC_Demo] 682 InterDigital, , "InterDigital Demo at Mobile World 683 Congress (MWC)", 2016, . 686 [oneM2M] OneM2M, , "oneM2M Service Layer Standards for M2M and 687 IoT", 2017, . 689 [POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better 690 IP?", European Conference on Networks and Communications 691 (EuCNC), , 2015. 693 [Reed] Reed, M. and et al., "Stateless Multicast Switching in 694 Software Defined Networks", ICC 2016, Kuala Lumpur, 695 Malaysia, 2016. 697 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 698 Keranen, A., and P. Hallam-Baker, "Naming Things with 699 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 700 . 702 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 703 Application Protocol (CoAP)", RFC 7252, 704 DOI 10.17487/RFC7252, June 2014, 705 . 707 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 708 Chaining (SFC) Architecture", RFC 7665, 709 DOI 10.17487/RFC7665, October 2015, 710 . 712 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 713 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 714 "Information-Centric Networking (ICN) Research 715 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 716 . 718 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 719 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 720 the Constrained Application Protocol (CoAP)", RFC 8075, 721 DOI 10.17487/RFC8075, February 2017, 722 . 724 [SAIL_NetInf] 725 FP7, , "SAIL Prototyping and Evaluation", 2013, 726 . 729 [Tateson] Tateson, J. and et al., "Final Evaluation Report on 730 Deployment Incentives and Business Models", 2010, 731 . 734 [Techno_Economic] 735 Trossen, D. and A. Kostopolous, "Techno-Economics Aspects 736 of Information-Centric Networking", Journal for 737 Information Policy, Volume 2, 2012. 739 [White] White, G. and G. Rutz, "Content Delivery with Content 740 Centric Networking, CableLabs White Paper", 2010, 741 . 745 Authors' Addresses 746 Akbar Rahman 747 InterDigital Communications, LLC 748 1000 Sherbrooke Street West, 10th floor 749 Montreal H3A 3G4 750 Canada 752 Email: Akbar.Rahman@InterDigital.com 753 URI: http://www.InterDigital.com/ 755 Dirk Trossen 756 InterDigital Communications, LLC 757 64 Great Eastern Street, 1st Floor 758 London EC2A 3QR 759 United Kingdom 761 Email: Dirk.Trossen@InterDigital.com 762 URI: http://www.InterDigital.com/ 764 Dirk Kutscher 765 Huawei German Research Center 766 Riesstrasse 25 767 Munich 80992 768 Germany 770 Email: ietf@dkutscher.net 771 URI: http://www.Huawei.com/