idnits 2.17.1 draft-irtf-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 (February 12, 2018) is 2258 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'NGMN' is defined on line 1040, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-06 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-06 == Outdated reference: A later version (-03) exists of draft-irtf-icnrg-icniot-00 == Outdated reference: A later version (-08) exists of draft-irtf-icnrg-terminology-00 == Outdated reference: A later version (-10) exists of draft-irtf-nfvrg-gaps-network-virtualization-08 == Outdated reference: A later version (-04) exists of draft-ravi-icnrg-5gc-icn-00 Summary: 0 errors (**), 0 flaws (~~), 8 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: August 16, 2018 D. Kutscher 6 R. Ravindran 7 Huawei 8 February 12, 2018 10 Deployment Considerations for Information-Centric Networking (ICN) 11 draft-irtf-icnrg-deployment-guidelines-00 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 key 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 https://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 August 16, 2018. 45 Copyright Notice 47 Copyright (c) 2018 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 (https://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. Clean-slate ICN . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. ICN-as-an-Overlay . . . . . . . . . . . . . . . . . . . . 5 67 3.3. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 5 68 3.3.1. Edge Network . . . . . . . . . . . . . . . . . . . . 6 69 3.3.2. Core Network . . . . . . . . . . . . . . . . . . . . 6 70 3.4. ICN-as-a-Slice . . . . . . . . . . . . . . . . . . . . . 7 71 4. Deployment Migration Paths . . . . . . . . . . . . . . . . . 8 72 4.1. Application and Service Migration . . . . . . . . . . . . 8 73 4.2. Content Delivery Network Migration . . . . . . . . . . . 9 74 4.3. Edge Network Migration . . . . . . . . . . . . . . . . . 9 75 4.4. Core Network Migration . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 11 80 5.1.3. NDN Testbed . . . . . . . . . . . . . . . . . . . . . 11 81 5.1.4. ICN2020 Efforts . . . . . . . . . . . . . . . . . . . 11 82 5.2. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 12 83 5.2.1. H2020 POINT and RIFE Efforts . . . . . . . . . . . . 12 84 5.2.2. H2020 FLAME Efforts . . . . . . . . . . . . . . . . . 12 85 5.2.3. CableLabs Content Delivery System . . . . . . . . . . 13 86 5.2.4. NDN IoT Trials . . . . . . . . . . . . . . . . . . . 13 87 5.3. Other Configurations . . . . . . . . . . . . . . . . . . 13 88 5.3.1. Hybrid ICN Trials . . . . . . . . . . . . . . . . . . 14 89 5.4. Summary of Deployment Trials . . . . . . . . . . . . . . 14 90 6. Deployment Issues Requiring Further Standardization . . . . . 14 91 6.1. Protocols for Application and Service Migration . . . . . 15 92 6.2. Protocols for Content Delivery Network Migration . . . . 15 93 6.3. Protocols for Edge and Core Network Migration . . . . . . 15 94 6.4. Summary of ICN Protocol Gaps and Potential Protocol 95 Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 100 11. Informative References . . . . . . . . . . . . . . . . . . . 19 101 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 104 1. Introduction 106 The ICNRG charter identifies deployment guidelines as an important 107 topic area for the ICN community. Specifically, the charter states 108 that defining concrete migration paths for ICN deployments which 109 avoid forklift upgrades, and defining practical ICN interworking 110 configurations with the existing Internet paradigm, are key topic 111 areas that require further investigation [ICNRGCharter]. Also, it is 112 well understood that results and conclusions from any mid to large- 113 scale ICN experiments in the live Internet will also provide useful 114 guidance for deployments. 116 However, so far outside of some preliminary investigations such as 117 [I-D.paik-icn-deployment-considerations], there has not been much 118 progress on this topic. This document attempts to fill some of these 119 gaps by defining clear deployment configurations for ICN, and 120 associated migration pathways for these configurations. Also, 121 selected deployment trial experiences of ICN technology are 122 summarized. Finally, recommendations are made for potential future 123 IETF standardization of key protocol functionality that will 124 facilitate interoperable ICN deployments going forward. 126 2. Terminology 128 This document assumes readers are, in general, familiar with the 129 terms and concepts that are defined in [RFC7927] and 130 [I-D.irtf-icnrg-terminology]. In addition, this document defines the 131 following terminology: 133 Deployment - In the context of this document, deployment refers to 134 the final stage of the process of setting up an ICN network that 135 is (1) ready for useful work (e.g. transmission of end user video 136 and text) in a live environment, and (2) integrated and 137 interoperable with the Internet. We consider the Internet in its 138 widest sense where it encompasses various access networks (e.g. 139 WiFi, Mobile radio network), service edge networks (e.g. for edge 140 computing), transport networks, Content Distribution Networks 141 (CDNs), core networks (e.g. Mobile core network), and back-end 142 processing networks (e.g. Data Centres). However, through out 143 the document we typically limit the discussion to edge networks, 144 core networks and CDNs for simplicity. 146 Information-Centric Networking (ICN) - A data-centric network 147 architecture where accessing data by name is the essential network 148 primitive. See [I-D.irtf-icnrg-terminology] for further 149 information. 151 Network Function Virtualization (NFV): A networking approach where 152 network functions (e.g. firewalls, load balancers) are modularized 153 as software logic that can run on general purpose hardware, and 154 thus are specifically decoupled from the previous generation of 155 proprietary and dedicated hardware. See 156 [I-D.irtf-nfvrg-gaps-network-virtualization] for further 157 information. 159 Software-Defined Networking (SDN) - A networking approach where 160 the control and data plane for switches are separated, allowing 161 for realizing capabilities such as traffic isolation and 162 programmable forwarding actions. See [RFC7426] for further 163 information. 165 3. Deployment Configurations 167 In this section, we present various deployment options for ICN. 168 These are presented as "configurations" that allow for studying these 169 options further. While this document will outline experiences with 170 various of these configurations (in Section 5), we will not provide 171 an in-depth technical or commercial evaluation for any of them - for 172 this we refer to existing literature in this space such as [Tateson]. 174 3.1. Clean-slate ICN 176 ICN has often been described as a "clean-slate" approach with the 177 goal to renew or replace the complete IP infrastructure of the 178 Internet (e.g., existing applications which are typically tied 179 directly to the TCP/IP protocol stack, IP routers, etc.). As such, 180 existing routing hardware as well as ancillary services are not taken 181 for granted. For instance, a Clean-slate ICN deployment would see 182 existing IP routers being replaced by ICN-specific forwarding and 183 routing elements, such as NFD (Named Data Networking Forwarding 184 Daemon) [NFD], CCN routers [Jacobson] or PURSUIT forwarding nodes 185 [IEEE_Communications]. 187 While such clean-slate replacement could be seen as exclusive for ICN 188 deployments, some ICN approaches (e.g., [POINT]) also rely on the 189 deployment of general infrastructure upgrades, here SDN switches. 190 Such SDN infrastructure upgrades, while being possibly utilized for a 191 Clean-slate ICN deployment would not necessary be used exclusively 192 for such deployments. Different proposals have been made for various 193 ICN approaches to enable the operation over an SDN transport 194 [Reed][CONET][C_FLOW]. 196 3.2. ICN-as-an-Overlay 198 Similar to other significant changes to the Internet routing fabric, 199 particularly the transition from IPv4 to IPv6 or the introduction of 200 IP multicast, this deployment configuration foresees the creation of 201 an ICN overlay. Note that this overlay approach is sometimes, 202 informally, also referred to as a tunneling approach. The overlay 203 approach can be implemented directly such as ICN-over-UDP as 204 described in [CCNx_UDP]. Alternatively, the overlay can be 205 accomplished via ICN-in-L2-in-IP as in [IEEE_Communications] which 206 describes a recursive layering process. Another approach used in the 207 Network of Information (NetInf) is to define a convergence layer to 208 map NetInf semantics to HTTP [I-D.kutscher-icnrg-netinf-proto]. 209 Finally, [Overlay_ICN] describes an incremental approach to deploying 210 an ICN architecture based on segregating ICN user and control plane 211 traffic which is particularly well-suited to being overlaid on SDN 212 based networks. 214 Regardless of the flavor, however, the overlay approach results in 215 islands of ICN deployments over existing IP-based infrastructure. 216 Furthermore, these ICN islands are typically connected to each other 217 via ICN/IP tunnels. In certain scenarios this requires 218 interoperability between existing IP routing protocols (e.g. OSPF, 219 RIP, ISIS) and ICN based ones. ICN-as-an-Overlay can be deployed 220 over IP infrastructure in either edge or core networks. This overlay 221 approach is thus very attractive for ICN experimentation and testing 222 as it allows rapid and easy deployment of ICN over existing IP 223 networks. 225 3.3. ICN-as-an-Underlay 227 Proposals such as [POINT] and [White] outline the deployment option 228 of using an ICN underlay that would integrate with existing 229 (external) IP-based networks by deploying application layer gateways 230 at appropriate locations. The main reasons for such a configuration 231 option is the introduction of ICN technology in given islands (e.g., 232 inside a CDN or edge IoT network) to reap the benefits of native ICN 233 in terms of underlying multicast delivery, mobility support, fast 234 indirection due to location independence, in-network computing and 235 possibly more. The underlay approach thus results in islands of 236 native ICN deployments which are connected to the rest of the 237 Internet through protocol conversion gateways or proxies. Routing 238 domains are strictly separated. Outside of the ICN island, normal IP 239 routing protocols apply. Within the ICN island, ICN based routing 240 schemes apply. The gateways transfer the semantic content of the 241 messages (i.e., IP packet payload) between the two routing domains. 243 3.3.1. Edge Network 245 Native ICN networks may be located at the edge of the network which 246 allows the possibility of introducing new network architectures and 247 protocols, and in this context ICN is an attractive option for newer 248 deployments such as IoT [I-D.irtf-icnrg-icniot]. The integration 249 with the current IP protocol suite takes place at an application 250 gateway/proxy at the edge network boundary, e.g., translating 251 incoming CoAP request/response transactions [RFC7252] into ICN 252 message exchanges or vice versa. Furthermore, ICN will allow 253 enhancement of the role of gateways/proxies as ICN message security 254 should be preserved through the protocol translation function of a 255 gateway/proxy and thus offer a substantial gain. 257 The work in [VSER] positions ICN as an edge service gateway driven by 258 a generalized ICN based service orchestration system with its own 259 compute and network virtualization controllers to manage an ICN 260 infrastructure. The platform also offers service discovery 261 capabilities to enable user applications to discover appropriate ICN 262 service gateways. To exemplify a use case scenario, the [VSER] 263 platform shows the realization of a multi-party audio/video 264 conferencing service over such a edge cloud deployment of ICN routers 265 realized over commodity hardware platforms. This platform has also 266 been extended to offer seamless mobility and mobility as a service 267 [VSER-Mob] features. 269 3.3.2. Core Network 271 In this sub-option, a core network would utilize edge-based protocol 272 mapping onto the native ICN underlay. For instance, [POINT] proposes 273 to map HTTP transactions, or some other IP based transactions such as 274 CoAP, directly onto an ICN-based message exchange. This mapping is 275 realized at the network attachment point, such as realized in access 276 points or customer premise equipment, which in turn provides a 277 standard IP interface to existing user devices. Towards peering 278 networks, such network attachment point turns into a modified border 279 gateway/proxy, preserving the perception of an IP-based core network 280 towards any peering network. 282 The work in [White] proposes a similar deployment configuration. 283 Here, the target is the use of ICN for content distribution within 284 CDN server farms, i.e., the protocol mapping is realized at the 285 ingress of the server farm where the HTTP-based retrieval request is 286 served, while the response is delivered through a suitable egress 287 node translation. 289 3.4. ICN-as-a-Slice 291 The objective of Network slicing [NGMN]is to multiplex a general pool 292 of compute, storage and bandwidth resources among multiple services 293 with exclusive SLA requirements on transport level QoS and security. 294 From a 5G perspective, this also includes slicing the air interface 295 spectrum resources among different applications. These services 296 could include both connectivity services like LTE-as-a-service or OTT 297 services like VoD or other IoT services through composition of a 298 group of virtual and/or physical network functions. Such a framework 299 can also be used to realize ICN slices with its own control, service 300 and forwarding plane over which one or more end-user services can be 301 delivered. 303 5G next generation architecture [fiveG-23501] provides the 304 flexibility to deploy the ICN-as-a-Slice over either the edge (RAN) 305 or Mobile core network, or the ICN-as-a-Slice may be deployed end-to- 306 end. Further discussions on extending the architecture presented in 307 [fiveG-23501] and the corresponding procedures in [fiveG-23502] to 308 support ICN has been provided in [I-D.ravi-icnrg-5gc-icn]. Such a 309 generalized network slicing framework should be able to offer service 310 slices to be realized using both IP and ICN. Network slicing will 311 rely heavily on network softwarization and programmability using SDN/ 312 NFV technologies for efficient utilization of available resources 313 without compromising on the slice requirements. Coupled with the 314 view of ICN functions as being "chained service functions" [RFC7665], 315 an ICN deployment within such a slice could also be realized within 316 the emerging orchestration plane that is targeted for adoption in 317 future (e.g., 5G Mobile) network deployments. Finally, it should be 318 noted that ICN is not creating the network slice, but instead that 319 the slice is created to run an 5G-ICN instance [Ravindran]. 321 At the level of the specific technologies involved, such as ONAP 322 [ONAP] that can be used to orchestrate slices, the 5G-ICN slice 323 requires compatibility for instance at the level of the forwarding/ 324 data plane depending on if it is realized as an overlay or using 325 programmable data planes. With SDN emerging for new network 326 deployments, some ICN approaches will need to integrate with SDN as a 327 data plane forwarding function, as briefly discussed in Section 3.1. 328 Further cross domain ICN slices can also be realized using frameworks 329 such as [ONAP]. 331 4. Deployment Migration Paths 333 After outlining the various ICN deployment configurations in 334 Section 3, we now focus on the various migration paths that will have 335 importance to the various stakeholders that are usually involved in 336 the deployment of a technology at (ultimately) large scale. We can 337 identify these stakeholders as: 339 o Application providers 341 o ISPs and service providers, both as core as well as access network 342 providers, and also ICN network providers 344 o CDN providers (due to the strong relation of the ICN proposition 345 to content delivery) 347 o End device manufacturers and users 349 Note that our presentation purely focuses on technological aspects of 350 such migration. Economic or regulatory aspects, such as studied in 351 [Tateson], [Techno_Economic] and [Internet_Pricing] are left out of 352 our discussion. 354 4.1. Application and Service Migration 356 The internet is full of applications and services, utilizing the 357 innovation capabilities of the many protocols defined over the packet 358 level IP service. HTTP provides one convergence point for these 359 services with many web development frameworks based on the semantics 360 provided by the hypertext transfer protocol. In recent years, even 361 services such as video delivery have been migrating from the 362 traditional RTP-over-UDP delivery to the various HTTP-level streaming 363 solutions, such as DASH [DASH] and others. Nonetheless, many non- 364 HTTP services exist, all of which need consideration when migrating 365 from the IP-based internet to an ICN-based one. 367 The underlay deployment configuration options presented in 368 Section 3.3.2 and Section 3.3.1 aim at providing some level of 369 backward compatibility to this existing ecosystem through a proxy 370 based message flow mapping mechanism (e.g., mapping of existing 371 HTTP/TCP/IP message flows to HTTP/TCP/IP/ICN message flows). A 372 related approach of mapping TCP/IP to TCP/ICN message flows is 373 described in [Moiseenko] 375 Alternatively, ICN as an overlay (Section 3.2), as well as ICN-as- 376 a-Slice (Section 3.4), allow for the introduction of the full 377 capabilities of ICN through new application/service interfaces as 378 well as operations in the network. With that, these approaches of 379 deployment are likely to aim at introducing new application/services 380 capitalizing on those ICN capabilities. 382 Finally, [I-D.suthar-icnrg-icn-lte-4g] outlines a dual-stack end user 383 device approach that is applicable for all deployment configurations. 384 Specifically, [I-D.suthar-icnrg-icn-lte-4g] introduces middleware 385 layers (called the Transport Convergence Layer, TCL) in the device 386 that will dynamically adapt existing applications to either an 387 underlying ICN protocol stack or standard IP protocol stack. This 388 involves end device signalling with the network to determine which 389 protocol stack instance and associated middleware adaptation layers 390 to utilize for a given application transaction. 392 4.2. Content Delivery Network Migration 394 A significant number of services and applications are devoted to 395 content delivery in some form, either as video delivery services, 396 social media platforms, and many others. Content delivery networks 397 (CDNs) are deployed to assist these services through localizing the 398 content requests and therefore reducing latency and possibly increase 399 utilization of available bandwidth as well as reducing the load on 400 origin servers. Similar to the previous sub-section, the underlay 401 deployment configurations presented in Section 3.3.2 and 402 Section 3.3.1 aim at providing a migration path for existing CDNs. 403 This is also highlighted in the BIER WG use case document 404 [I-D.ietf-bier-use-cases], specifically with potential benefits in 405 terms of utilizing multicast in the delivery of content but also 406 reducing load on origin as well as delegation server. We return to 407 this benefit in the trial experiences in Section 5. 409 4.3. Edge Network Migration 411 Edge networks often see the deployment of novel network level 412 technology, e.g., in the space of IoT. Such IoT deployments have for 413 many years relied, and often still do, on proprietary protocols for 414 reasons such as increased efficiency, lack of standardization 415 incentives and others. Utilizing the underlay deployment 416 configuration in Section 3.3.1, application gateways/proxies can 417 integrate such edge deployments into IP-based services, e.g., 418 utilizing CoAP [RFC7252] based machine-to-machine (M2M) platforms 419 such as oneM2M [oneM2M] or others. 421 Another area of increased edge network innovation is that of Mobile 422 (access) networks, particularly in the context of the 5G Mobile 423 networks. With the proliferation of network softwarization (using 424 technologies like service orchestration frameworks leveraging NFV and 425 SDN concepts) access networks and other network segments, the ICN-as- 426 a-Slice deployment configuration in Section 3.4 provides a suitable 427 migration path for integration non-IP-based edge networks into the 428 overall system through virtue of realizing the relevant (ICN) 429 protocols in an access network slice. 431 4.4. Core Network Migration 433 Migrating core networks (e.g., of the Internet or Mobile core 434 network) requires not only significant infrastructure renewal but 435 also the fulfillment of the significant performance requirements, 436 particularly in terms of throughput. For those parts of the core 437 network that would see a migration to an SDN-based optical transport 438 the ICN-as-a-Slice deployment configuration in Section 3.4 could see 439 the introduction of native ICN solutions within slices provided by 440 the SDN-enabled transport network or as virtual network functions, 441 allowing for isolating the ICN traffic while addressing the specific 442 ICN performance benefits and constraints within such isolated slice. 443 For ICN solutions that natively work on top of SDN, the underlay 444 deployment configuration in Section 3.3.2 provides an additional 445 migration path, preserving the IP-based services and applications at 446 the edge of the network, while realizing the core network routing 447 through an ICN solution (possibly itself realized in a slice of the 448 SDN transport network). 450 5. Deployment Trial Experiences 452 In this section, we will outline trial experiences, often conducted 453 within international collaborative project efforts. Our focus here 454 is on the realization of the various deployment configurations in 455 Section 3, and we therefore categorize the trial experiences 456 according to these deployment configurations. While a large body of 457 work exists at the simulation or emulation level, we specifically 458 exclude these studies from our presentation to retain the focus on 459 real life experiences. 461 5.1. ICN-as-an-Overlay 463 5.1.1. FP7 PURSUIT Efforts 465 Although the FP7 PURSUIT [IEEE_Communications] efforts were generally 466 positioned as a Clean-slate ICN replacement of IP (Section 3.1), the 467 project realized its experimental test bed as an L2 VPN-based overlay 468 between several European, US as well as Asian sites, i.e., following 469 the overlay deployment configuration presented in Section 3.2. 470 Software-based forwarders were utilized for the ICN message exchange, 471 while native ICN applications, e.g., for video transmissions, were 472 showcased. At the height of the project efforts, about 70+ nodes 473 were active in the (overlay) network with presentations given at 474 several conferences as well as to the ICNRG. 476 5.1.2. FP7 SAIL Trial 478 The Network of Information (NetInf) is the approach to Information- 479 Centric Networking developed by the European Union (EU) FP7 SAIL 480 project (http://www.sail-project.eu/). NetInf provides both name- 481 based forwarding with CCNx-like semantics and name resolution (for 482 indirection and late-binding). The NetInf architecture supports 483 different deployment options through its convergence layer 484 abstraction. In its first prototypes and trials, NetInf was deployed 485 mostly in an HTTP embedding and in a UDP overlay following the 486 overlay deployment configuration in Section 3.2. Reference 487 [SAIL_NetInf] describes several trials including a stadium 488 environment large crowd scenario and a multi-site testbed, leveraging 489 NetInf's Routing Hint approach for routing scalability. 491 5.1.3. NDN Testbed 493 The Named Data Networking (NDN) is one of the research projects 494 funded by the National Science Foundation (NSF) of the USA as part of 495 the Future Internet Architecture Program. The original NDN proposal 496 was positioned as a Clean-slate ICN replacement of IP (Section 3.1). 497 However, in several trials, NDN generally follows the overlay 498 deployment configuration of Section 3.2 to connect institutions over 499 the public Internet across several continents. The use cases covered 500 in the trials include real-time video-conferencing, geo-locating, and 501 interfacing to consumer applications. Typical trials involve up to 502 100 NDN enabled nodes (https://named-data.net/ndn-testbed/) [Jangam]. 504 5.1.4. ICN2020 Efforts 506 ICN2020 is an ICN related research project funded by the EU and Japan 507 as part of the H2020 research and innovation program and NICT 508 (http://www.icn2020.org/). ICN2020 has a specific focus to advance 509 ICN towards real-world deployments through innovative applications 510 and global scale experimentation. Both NDN and CCN approaches are 511 within the scope of the project. 513 ICN2020 was kicked off in July 2016 and at the end of the first year 514 released a set of public technical reports [ICN2020]. The report 515 titled "Deliverable D4.1: 1st yearly report on Testbed and 516 Experiments (WP4)" contains a detailed description of the progress 517 made in both local testbeds as well as federated testbeds. The plan 518 for the federated testbed includes integrating the NDN testbed, the 519 CUTEi testbed [RFC7945] [CUTEi] and the GEANT testbed 520 (https://www.geant.org/) to create an overlay deployment 521 configuration of Section 3.2 over the public Internet. 523 5.2. ICN-as-an-Underlay 525 5.2.1. H2020 POINT and RIFE Efforts 527 POINT and RIFE are two more ICN related research projects funded by 528 the EU as part of the H2020 effort. The efforts in the H2020 529 POINT+RIFE projects follow the underlay deployment configuration in 530 Section 3.3.2, although this is mixed with utilizing an overlay 531 deployment to provide multi-national connectivity. However, underlay 532 SDN-based deployments do exist at various project partner sites, 533 e.g., at Essex University, without any overlaying being realized. 534 Edge-based network attachment points (NAPs) provide the IP/HTTP-level 535 protocol mapping onto ICN protocol exchanges, while the SDN underlay 536 (or the VPN-based L2 underlay) is used as a transport network. 538 The multicast as well as service endpoint surrogate benefits in HTTP- 539 based scenarios, such as for HTTP-level streaming video delivery, 540 have been demonstrated in the deployed POINT test bed with 80+ nodes 541 being utilized. Demonstrations of this capability have been given to 542 the ICNRG in 2016, and public demonstrations were also provided at 543 events such as Mobile World Congress in 2016 [MWC_Demo]. The trial 544 has also been accepted by the ETSI MEC group as a proof-of-concept 545 with a demonstration at the ETSI MEC World Congress in 2016. 547 While the afore-mentioned demonstrations all use the overlay 548 deployment, H2020 also has performed ICN underlay trials. One such 549 trial involved commercial end users located in the Primetel network 550 in Cyprus with the use case centered on IPTV and HLS video 551 dissemination. Another trial was performed in the community network 552 of "guifi.net" in the Barcelona region, where the solution was 553 deployed in 40 households, providing general Internet connectivity to 554 the residents. Standard IPTV STBs as well as HLS video players were 555 utilized in accordance with the aim of this deployment configuration, 556 namely to provide application and service migration. 558 5.2.2. H2020 FLAME Efforts 560 The H2020 FLAME efforts concentrate on providing an experimental 561 ground for the aforementioned POINT/RIFE solution in initially two 562 city-scale locations, namely in Bristol and Barcelona. This trial 563 followed the underlay deployment configuration in Section 3.3.2 as 564 per POINT/RIFE approach. Experiments were conducted with the city/ 565 university joint venture Bristol-is-Open (BIO), to ensure the 566 readiness of the city-scale SDN transport network for such 567 experiments. Another trial was for the ETSI MEC PoC. This trial 568 showcased operational benefits provided by the ICN underlay for the 569 scenario of a location-based game. These benefits aim at reduced 570 network utilization through improved video delivery performance 571 (multicast of all captured videos to the service surrogates deployed 572 in the city at six locations) as well as reduced latency through the 573 playout of the video originating from the local NAP instead of a 574 remote server. 576 Ensuring the technology readiness and the early trialing of the ICN 577 capabilities lays the ground for the goal of the H2020 FLAME efforts 578 to conduct 23 large-scale experiments in the area of Future Media 579 Internet (FMI) throughout 2018 and 2019. Standard media service 580 functions as well as applications will ultimately utilize the ICN 581 underlay in the delivery of their experience. The platform, which 582 includes the ICN capabilities, will utilize concepts of SFC, 583 integrated with NFV and SDN capabilities of the infrastructure. The 584 ultimate goal of these platform efforts is the full integration of 585 ICN into the overall media function platform for the provisioning of 586 advanced (media-centric) internet services. 588 5.2.3. CableLabs Content Delivery System 590 The work in [White] proposes an underlay deployment configuration 591 based on Section 3.3.2. The use case is ICN for content distribution 592 within CDN server farms (which can be quite large and complex) to 593 leverage ICN's superior in-network caching properties. This "island 594 of ICN" based CDN is then used to service standard HTTP/IP-based 595 content retrieval request coming from the general Internet. This 596 approach acknowledges that whole scale replacement (see Section 3.1) 597 of existing HTTP/IP end user applications and related Web 598 infrastructure is a difficult proposition. [White] does not yet 599 provide results but indicated that experiments will be forthcoming. 601 5.2.4. NDN IoT Trials 603 [Baccelli] summarizes the trial of an NDN system adapted specifically 604 for a wireless IoT scenario. The trial was run with 60 nodes 605 distributed over several multi-story buildings in a university campus 606 environment. The NDN protocols were optimized to run directly over 607 6LoWPAN wireless link layers. The performance of the NDN based IoT 608 system was then compared to an equivalent system running standard IP 609 based IoT protocols. It was found that the NDN based IoT system was 610 superior in several respects including in terms of energy 611 consumption, and for RAM and ROM footprints [Baccelli] 612 [Anastasiades]. 614 5.3. Other Configurations 616 This section records deployment trial experiences from systems that 617 do not directly correspond to one of the basic configurations defined 618 in Section 3. 620 5.3.1. Hybrid ICN Trials 622 Hybrid ICN [Hybrid_ICN-1] [Hybrid_ICN-2] is an approach where the ICN 623 names are mapped to IPv6 addresses, and other ICN information is 624 carried as payload inside the IP packet. This allows standard (ICN- 625 unaware) IP routers to forward packets based on IPv6 info, but 626 enables ICN-aware routers to apply ICN semantics. A related open 627 source effort was kicked off in 2017 (https://wiki.fd.io/view/Cicn). 628 The intent of the trials are to show the routing performance 629 efficiency of the Hybrid ICN router (called the Vector Packet 630 Processor) over existing IP routers. Results have not yet been 631 published but are expected in the near future. 633 5.4. Summary of Deployment Trials 635 In summary, there have been significant trials over the years with 636 all the major ICN protocol flavors (e.g., CCN, NDN, POINT) using both 637 the ICN-as-an-Overlay and ICN-as-an-Underlay deployment 638 configurations. The major limitations of the trials include the fact 639 that only a limited number of applications have been tested. 640 However, the tested applications include both native ICN and existing 641 IP based applications (e.g. video-conferencing and IPTV). Another 642 limitation of the trials is that all of them involve less than 1000 643 users maximum. 645 The ICN-as-a-Slice configuration still has not be trialled primarily 646 due to the fact that 5G standards are still in flux and not expected 647 to be stable before the mid-2018 time frame. The Clean-slate ICN 648 approach has obviously never been trialled as complete replacement of 649 Internet infrastructure (e.g., existing applications, TCP/IP protocol 650 stack, IP routers, etc.) is no longer considered a viable 651 alternative. Finally, the Hybrid ICN approach offers an intersting 652 alternative as it allows ICN semantics to be embedded in standard 653 IPv6 packets and so the packets can be routed through either IP 654 routers or Hybrid ICN routers. Detailed performance results are 655 still pending for this alternative. 657 6. Deployment Issues Requiring Further Standardization 659 The ICN Research Challenges [RFC7927] describes key ICN principles 660 and technical research topics. As the title suggests, [RFC7927] is 661 research oriented without a specific focus on deployment or 662 standardization issues. This section addresses this open area by 663 identifying key protocol functionality that that may be relevant for 664 further standardization effort in IETF. The focus is specifically on 665 identifying protocols that will facilitate future interoperable ICN 666 deployments correlating to the scenarios identified in the deployment 667 migration paths in Section 4. The identified list of potential 668 protocol functionality is not exhaustive. 670 6.1. Protocols for Application and Service Migration 672 End user applications and services need a standardized approach to 673 trigger ICN transactions. For example, in Internet and Web 674 applications today, there are established socket APIs, communication 675 paradigms such as REST, common libraries, and best practices. We see 676 a need to study application requirements in an ICN environment 677 further and, at the same time, develop new APIs and best practices 678 that can take advantage of ICN communication characteristics. 680 6.2. Protocols for Content Delivery Network Migration 682 A key issue in CDNs is to quickly find a location of a copy of the 683 object requested by an end user. In ICN, a Named Data Object (NDO) 684 is typically defined by its name. There already exists [RFC6920] 685 that is suitable for static naming of ICN data objects. Other ways 686 of encoding and representing ICN names have been described in 687 [I-D.irtf-icnrg-ccnxmessages] and [I-D.mosko-icnrg-ccnxurischeme]. 688 Naming dynamically generated data requires different approaches (for 689 example, hash digest based names would normally not work), and there 690 is lack of established conventions and standards. 692 Another CDN issue for ICN is related to multicast distribution of 693 content. Existing CDNs have started using multicast mechanisms for 694 certain cases such as for broadcast streaming TV. However, as 695 discussed in Section 5.2.1, certain ICN approaches provide 696 substantial improvements over IP multicast, such as the implicit 697 support for multicast retrieval of content in all ICN flavours. 699 Caching is an implicit feature in many ICN architectures that can 700 improve performance and availability in several scenarios. The ICN 701 in-network caching can augment managed CDN and improve its 702 performance. The details of the interplay between ICN caching and 703 managed CDN need further consideration. 705 6.3. Protocols for Edge and Core Network Migration 707 ICN provides the potential to redesign current edge and core network 708 computing approaches. Leveraging ICN's inherent security and its 709 ability to make name data and dynamic computation results available 710 independent of location, can enable a secure, yet light-weight 711 insertion of traffic into the network without relying on redirection 712 of DNS requests. For this, proxies that translate from commonly used 713 protocols in the general Internet to ICN message exchanges in the ICN 714 domain could be used for the migration of application and services 715 within deployments at the network edge but also in core networks. 716 This is similar to existing approaches for IoT scenarios where a 717 proxy translates CoAP request/responses to other message formats. 718 For example, [RFC8075] specifies proxy mapping between CoAP and HTTP 719 protocols. However, as mentioned previously, ICN will allow us to 720 evolve the role of gateways/proxies as ICN message security should be 721 preserved through the protocol translation function of a thus offer a 722 substantial gain. 724 Interaction and interoperability between existing IP routing 725 protocols (e.g., OSPF, RIP, ISIS) and ICN routing approaches(e.g., 726 NFD, CCN routers) are expected especially in the overlay approach. 727 Another important topic is integration of ICN into networks that 728 support virtualized infrastructure in the form of NFV/SDN and most 729 likely utilizing Service Function Chaining (SFC) as a key protocol. 730 Further work is required to validate this idea and document best 731 practices. 733 Operations and Maintenance (OAM) is a crucial area that has not yet 734 been fully addressed by the ICN research community, but which is 735 obviously critical for future deployments of ICN. Potential areas 736 that need investigation include whether the YANG data modelling 737 approach and associated NETCONF/RESTCONF protocols need any specific 738 updates for ICN support. Another open area is how to measure and 739 benchmark performance of ICN networks comparable to the sophisticated 740 techniques that exist for standard IP networks, virtualized networks 741 and data centers. It should be noted that some initial progress has 742 been made in the area of ICN network path traceroute facility with 743 approaches such as CONTRACE [I-D.asaeda-icnrg-contrace] [Contrace]. 745 6.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts 747 Without claiming completeness, Table 1 maps the open the open ICN 748 issues identified in this document to potential protocol efforts that 749 could address some aspects of the gap. 751 +--------------+----------------------------------------------------+ 752 | ICN Gap | Potential Protocol Effort | 753 +--------------+----------------------------------------------------+ 754 | 1-Support of | HTTP/CoAP support of ICN semantics | 755 | REST APIs | | 756 | | | 757 | 2-Naming | Dynamic naming of ICN data objects | 758 | | | 759 | 3-Routing | Interactions between IP and ICN routing protocols | 760 | | | 761 | 4-Multicast | Multicast enhancements for ICN | 762 | distribution | | 763 | | | 764 | 5-In-network | ICN Cache placement and sharing | 765 | caching | | 766 | | | 767 | 6-NFV/SDN | Integration of ICN with NFV/SDN and including | 768 | support | possible impacts to SFC | 769 | | | 770 | 7-ICN | Mapping of HTTP and other protocols onto ICN | 771 | mapping | message exchanges (and vice-versa) while | 772 | | preserving ICN message security | 773 | | | 774 | 8-OAM | YANG models, NETCONF/RESTCONF protocols, | 775 | support | and network performance measurements | 776 | | | 777 +--------------+----------------------------------------------------+ 779 Table 1: Mapping of ICN Gaps to Potential Protocol Efforts 781 7. Conclusion 783 This document provides high level deployment considerations for the 784 ICN community. Specifically, the major configurations of possible 785 ICN deployments are identified as (1) Clean-slate ICN replacement of 786 existing Internet infrastructure; (2) ICN-as-an-Overlay; (3) ICN-as- 787 an-Underlay; and (4) ICN-as-a-Slice. Existing ICN trial systems 788 primarily fall under either the ICN-as-an-Overlay or ICN-as-an- 789 Underlay configuration. 791 In terms of deployment migration paths, ICN-as-an-Underlay offers a 792 clear migration path for CDN, edge and core networks to go to an ICN 793 paradigm (e.g., for an IoT deployment). ICN-as-an-Overlay is 794 probably the easiest configuration to deploy as it leaves the 795 underlying IP infrastructure essentially untouched. However its 796 applicability for general deployment must be considered on a case by 797 case basis (e.g., based on if it can run all required applications or 798 other similar criteria). ICN-as-a-Slice is an attractive deployment 799 option for future 5G systems (i.e., for 5G radio and core networks) 800 which will naturally support network slicing, but this still has to 801 be validated through actual trial experiences. 803 For the crucial issue of existing application and service migration 804 to ICN, various mapping schemes are possible to mitigate impacts. 805 For example, HTTP/TCP/IP flows may be mapped to/from ICN message 806 flows at proxies in the ICN-as-an-Underlay configurations leaving the 807 massive number of existing end point applications/services untouched 808 or minimally impacted. Also dual stack end user devices that include 809 middleware to allow applications to communicate in both ICN mode and 810 standard IP mode are an attractive proposition for gradual and 811 geographically discontinuous introduction for all deployment 812 configurations. 814 There has been significant trial experience with all the major ICN 815 protocol flavors (e.g., CCN, NDN, POINT). However, only a limited 816 number of applications have been tested so far, and the maximum 817 number of users in any given trial has been less than 1000 users. It 818 is recommended that future ICN deployments scale their users 819 gradually and closely monitor network performance as they go above 820 1000 users. 822 Finally, this document describes a set of technical features in ICN 823 that warrant potential future IETF specification work. This will aid 824 initial and incremental deployments to proceed in an interoperable 825 manner. The fundamental details of the potential protocol 826 specification effort, however, are best left for future study by the 827 appropriate IETF WGs and/or BoFs. 829 8. IANA Considerations 831 This document requests no IANA actions. 833 9. Security Considerations 835 ICN was purposefully designed from the start to have certain 836 intrinsic security properties. The most well known of which are 837 authentication of delivered content and (optional) encryption of the 838 content. [RFC7945] has an extensive discussion of various aspects of 839 ICN security including many which are relevant to deployments. 840 Specifically, [RFC7945] points out that ICN access control, privacy, 841 security of in-network caches, and protection against various network 842 attacks (e.g. DoS) have not yet been fully developed due to the lack 843 of real deployments. [RFC7945] also points out relevant advances 844 occurring in the ICN research community that hold promise to address 845 each of the identified security gaps. Lastly, [RFC7945] points out 846 that as secure communications in the existing Internet (e.g. HTTPS) 847 becomes the norm, that major gaps in ICN security will inevitably 848 slow down the adoption of ICN. 850 In addition to the security findings of [RFC7945], this document has 851 highlighted that all anticipated ICN deployment configurations will 852 involve co-existence with existing Internet infrastructure and 853 applications. Thus even the basic authentication and encryption 854 properties of ICN content will need to account for interworking with 855 non-ICN content to preserve end-to-end security. For example, in the 856 edge network underlay deployment configuration described in 857 Section 3.3.1, the gateway/proxy that translates HTTP or CoAP 858 request/responses into ICN message exchanges will need to support a 859 model to preserve end-to-end security. 861 10. Acknowledgments 863 The authors want to thank Alex Afanasyev, Mayutan Arumaithurai, 864 Hitoshi Asaeda, Giovanna Carofiglio, Xavier de Foy, Hannu Flinck, 865 Anil Jangam, Luca Muscariello, Dave Oran, Thomas Schmidt, Jan 866 Seedorf, Eve Schooler, Samar Shailendra, Milan Stolic, Prakash 867 Suthar, Atsushi Tagami, and Lixia Zhang for their very useful 868 reviews, comments and input to the document. 870 11. Informative References 872 [Anastasiades] 873 Anastasiades, C., "Information-centric communication in 874 mobile and wireless networks", PhD Dissertation, 2016, 875 . 877 [Baccelli] 878 Baccelli, E. and et al., "Information Centric Networking 879 in the IoT: Experiments with NDN in the Wild", ACM 880 20164, Paris, France, 2014, 881 . 884 [C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking 885 over OpenFlow", Open Networking Summit, April, 2012, 886 . 889 [CCNx_UDP] 890 PARC, "CCNx Over UDP", 2015, 891 . 894 [CONET] Veltri, L. and et al., "CONET Project: Supporting 895 Information-Centric Functionality in Software Defined 896 Networks", Workshop on Software Defined Networks, , 2012, 897 . 900 [Contrace] 901 Asaeda, H. and et al., "Contrace: A Tool for Measuring and 902 Tracing Content-Centric Networks", IEEE Communications 903 Magazine, Vol.53, No.3 , 2015. 905 [CUTEi] Asaeda, H. and N. Choi, "Container-Based Unified Testbed 906 for Information Centric Networking", IEEE Network, Vol.28, 907 No.6 , 2014. 909 [DASH] DASH, "DASH Industry Forum", 2017, . 911 [fiveG-23501] 912 3gpp-23.501, "Technical Specification Group Services and 913 System Aspects; System Architecture for the 5G System 914 (Rel.15)", 3GPP , 2017. 916 [fiveG-23502] 917 3gpp-23.502, "Technical Specification Group Services and 918 System Aspects; Procedures for the 5G System (Rel.15)", 919 3GPP , 2017. 921 [Hybrid_ICN-1] 922 Cisco, "Hybrid ICN: Cisco Announces Important Steps toward 923 Adoption of Information-Centric Networking", 2017, 924 . 927 [Hybrid_ICN-2] 928 Cisco, "Mobile Video Delivery with Hybrid ICN: IP- 929 Integrated ICN Solution for 5G", 2017, 930 . 934 [I-D.asaeda-icnrg-contrace] 935 Asaeda, H., Shao, X., and T. Turletti, "Contrace: 936 Traceroute Facility for Content-Centric Network", draft- 937 asaeda-icnrg-contrace-04 (work in progress), October 2017. 939 [I-D.ietf-bier-use-cases] 940 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 941 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 942 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-06 943 (work in progress), January 2018. 945 [I-D.irtf-icnrg-ccnxmessages] 946 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 947 Format", draft-irtf-icnrg-ccnxmessages-06 (work in 948 progress), October 2017. 950 [I-D.irtf-icnrg-icniot] 951 Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., 952 Raychadhuri, D., Baccelli, E., Burke, J., Wang, G., 953 Ahlgren, B., and O. Schelen, "Design Considerations for 954 Applying ICN to IoT", draft-irtf-icnrg-icniot-00 (work in 955 progress), January 2018. 957 [I-D.irtf-icnrg-terminology] 958 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 959 D., and C. Tschudin, "Information-Centric Networking 960 (ICN): CCN and NDN Terminology", draft-irtf-icnrg- 961 terminology-00 (work in progress), December 2017. 963 [I-D.irtf-nfvrg-gaps-network-virtualization] 964 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 965 Aranda, P., and P. Lynch, "Network Virtualization Research 966 Challenges", draft-irtf-nfvrg-gaps-network- 967 virtualization-08 (work in progress), November 2017. 969 [I-D.kutscher-icnrg-netinf-proto] 970 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 971 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 972 progress), February 2013. 974 [I-D.mosko-icnrg-ccnxurischeme] 975 marc.mosko@parc.com, m. and c. cwood@parc.com, "The CCNx 976 URI Scheme", draft-mosko-icnrg-ccnxurischeme-01 (work in 977 progress), April 2016. 979 [I-D.paik-icn-deployment-considerations] 980 Paik, E., Yun, W., Kwon, T., and h. 981 hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for 982 Information-Centric Networking", draft-paik-icn- 983 deployment-considerations-00 (work in progress), July 984 2013. 986 [I-D.ravi-icnrg-5gc-icn] 987 Ravindran, R., suthar, P., and G. Wang, "Enabling ICN in 988 3GPP's 5G NextGen Core Architecture", draft-ravi-icnrg- 989 5gc-icn-00 (work in progress), October 2017. 991 [I-D.suthar-icnrg-icn-lte-4g] 992 suthar, P., Stolic, M., Jangam, A., and D. Trossen, 993 "Native Deployment of ICN in LTE, 4G Mobile Networks", 994 draft-suthar-icnrg-icn-lte-4g-04 (work in progress), 995 November 2017. 997 [ICN2020] ICN2020, "ICN2020 Deliverables", 2017, 998 . 1001 [ICNRGCharter] 1002 NDN, "Information-Centric Networking Research Group 1003 Charter", 2013, 1004 . 1006 [IEEE_Communications] 1007 Trossen, D. and G. Parisis, "Designing and Realizing an 1008 Information-Centric Internet", Information-Centric 1009 Networking, IEEE Communications Magazine Special Issue, 1010 2012. 1012 [Internet_Pricing] 1013 Trossen, D. and G. KBiczok, "Not Paying the Truck Driver: 1014 Differentiated Pricing for the Future Internet", ReArch 1015 Workshop in conjunction with ACM Context, December, 2010. 1017 [Jacobson] 1018 Jacobson, V. and et al., "Networking Named Content", 1019 Proceedings of ACM Context, , 2009. 1021 [Jangam] Jangam, A. and et al., "Porting and Simulation of Named- 1022 data Link State Routing Protocol into ndnSIM", ACM 1023 DIVANet'17, Miami Beach, USA, 2017, 1024 . 1026 [Moiseenko] 1027 Moiseenko, I. and D. Oran, "TCP/ICN : Carrying TCP over 1028 Content Centric and Named Data Networks", 2016, 1029 . 1032 [MWC_Demo] 1033 InterDigital, "InterDigital Demo at Mobile World Congress 1034 (MWC)", 2016, . 1037 [NFD] NDN, "NFD - Named Data Networking Forwarding Daemon", 1038 2017, . 1040 [NGMN] NGMN, "NGMN 5g Initiative White Paper", 2015, 1041 . 1044 [ONAP] ONAP, "Open Network Automation Platform", 2017, 1045 . 1047 [oneM2M] OneM2M, "oneM2M Service Layer Standards for M2M and IoT", 1048 2017, . 1050 [Overlay_ICN] 1051 Shailendra, S. and et al., "A Novel Overlay Architecture 1052 for Information Centric Networking", 2016, 1053 1055 . 1057 [POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better 1058 IP?", European Conference on Networks and Communications 1059 (EuCNC), , 2015. 1061 [Ravindran] 1062 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 1063 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 1064 Network Slicing", IEEE Communication Magazine, May, 2016, 1065 . 1067 [Reed] Reed, M. and et al., "Stateless Multicast Switching in 1068 Software Defined Networks", ICC 2016, Kuala Lumpur, 1069 Malaysia, 2016. 1071 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1072 Keranen, A., and P. Hallam-Baker, "Naming Things with 1073 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1074 . 1076 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1077 Application Protocol (CoAP)", RFC 7252, 1078 DOI 10.17487/RFC7252, June 2014, 1079 . 1081 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1082 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1083 Defined Networking (SDN): Layers and Architecture 1084 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1085 2015, . 1087 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1088 Chaining (SFC) Architecture", RFC 7665, 1089 DOI 10.17487/RFC7665, October 2015, 1090 . 1092 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1093 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1094 "Information-Centric Networking (ICN) Research 1095 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1096 . 1098 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1099 and G. Boggia, "Information-Centric Networking: Evaluation 1100 and Security Considerations", RFC 7945, 1101 DOI 10.17487/RFC7945, September 2016, 1102 . 1104 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1105 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1106 the Constrained Application Protocol (CoAP)", RFC 8075, 1107 DOI 10.17487/RFC8075, February 2017, 1108 . 1110 [SAIL_NetInf] 1111 FP7, "SAIL Prototyping and Evaluation", 2013, 1112 . 1115 [Tateson] Tateson, J. and et al., "Final Evaluation Report on 1116 Deployment Incentives and Business Models", 2010, 1117 . 1120 [Techno_Economic] 1121 Trossen, D. and A. Kostopolous, "Techno-Economics Aspects 1122 of Information-Centric Networking", Journal for 1123 Information Policy, Volume 2, 2012. 1125 [VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G. 1126 Wang, "Towards software defined ICN based edge-cloud 1127 services", CloudNetworking(CloudNet), IEEE Internation 1128 Conference on, IEEE Internation Conference on 1129 CloudNetworking(CloudNet), 2013. 1131 [VSER-Mob] 1132 Azgin, A., Ravindran, R., Chakraborti, A., and G. Wang, 1133 "Seamless Mobility as a Service in Information-centric 1134 Networks", ACM ICN Sigcomm, IC5G Workshop, 2016. 1136 [White] White, G. and G. Rutz, "Content Delivery with Content 1137 Centric Networking, CableLabs White Paper", 2010, 1138 . 1142 Appendix A. Change Log 1144 [Note to RFC Editor: Please remove this section before publication.] 1146 Changes from draft-rahman-rev-05 to draft-irtf-rev-00: 1148 o Changed draft status from individual draft-rahman-icnrg- 1149 deployment-guidelines-05 to RG adopted draft-irtf-icnrg- 1150 deployment-guidelines-00. 1152 Changes from rev-04 to rev-05: 1154 o Added this Change Log in Appendix A. 1156 o Removed references to Hybrid ICN from section 3.2 (ICN-as-an- 1157 Overlay definition). Instead, consolidated all Hybrid ICN info in 1158 the Deployment Trial Experiences under a new subsection 5.3 (Other 1159 Configurations). 1161 o Updated ICN2020 description in Section 5.1.4 with text received 1162 from Mayutan Arumaithurai and Hitoshi Asaeda. 1164 o Clarified in ICN-as-a-Slice description (section 3.4) that it may 1165 be deployed on either the Edge (RAN) or Core Network, or the ICN- 1166 as-a-Slice may be deployed end-to-end through the entire Mobile 1167 network. 1169 o Added several new references in various sections. 1171 o Various minor editorial updates. 1173 Authors' Addresses 1175 Akbar Rahman 1176 InterDigital Inc. 1177 1000 Sherbrooke Street West, 10th floor 1178 Montreal H3A 3G4 1179 Canada 1181 Email: Akbar.Rahman@InterDigital.com 1182 URI: http://www.InterDigital.com/ 1184 Dirk Trossen 1185 InterDigital Inc. 1186 64 Great Eastern Street, 1st Floor 1187 London EC2A 3QR 1188 United Kingdom 1190 Email: Dirk.Trossen@InterDigital.com 1191 URI: http://www.InterDigital.com/ 1193 Dirk Kutscher 1194 Huawei German Research Center 1195 Riesstrasse 25 1196 Munich 80992 1197 Germany 1199 Email: ietf@dkutscher.net 1200 URI: http://www.Huawei.com/ 1202 Ravi Ravindran 1203 Huawei Research Center 1204 2330 Central Expressway 1205 Santa Clara 95050 1206 USA 1208 Email: ravi.ravindran@huawei.com 1209 URI: http://www.Huawei.com/