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