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