idnits 2.17.1 draft-irtf-icnrg-deployment-guidelines-04.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 (September 5, 2018) is 2053 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'NGMN' is defined on line 1260, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-07 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-08 == Outdated reference: A later version (-12) exists of draft-irtf-icnrg-icn-lte-4g-01 == 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 (-05) exists of draft-mendes-icnrg-dabber-01 == Outdated reference: A later version (-07) exists of draft-moiseenko-icnrg-flowclass-02 == Outdated reference: A later version (-04) exists of draft-ravi-icnrg-5gc-icn-02 Summary: 0 errors (**), 0 flaws (~~), 10 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: March 9, 2019 D. Kutscher 6 R. Ravindran 7 Huawei 8 September 5, 2018 10 Deployment Considerations for Information-Centric Networking (ICN) 11 draft-irtf-icnrg-deployment-guidelines-04 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 March 9, 2019. 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 . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . 12 82 5.1.4. ICN2020 Efforts . . . . . . . . . . . . . . . . . . . 12 83 5.1.5. UMOBILE Efforts . . . . . . . . . . . . . . . . . . . 12 84 5.2. ICN-as-an-Underlay . . . . . . . . . . . . . . . . . . . 14 85 5.2.1. H2020 POINT and RIFE Efforts . . . . . . . . . . . . 14 86 5.2.2. H2020 FLAME Efforts . . . . . . . . . . . . . . . . . 14 87 5.2.3. CableLabs Content Delivery System . . . . . . . . . . 15 88 5.2.4. NDN IoT Trials . . . . . . . . . . . . . . . . . . . 15 89 5.2.5. NREN ICN Testbed . . . . . . . . . . . . . . . . . . 16 90 5.2.6. Doctor Testbed . . . . . . . . . . . . . . . . . . . 16 91 5.3. Composite-ICN Approach . . . . . . . . . . . . . . . . . 16 92 5.3.1. Hybrid ICN Trials . . . . . . . . . . . . . . . . . . 16 94 5.4. Summary of Deployment Trials . . . . . . . . . . . . . . 17 95 6. Deployment Issues Requiring Further Standardization . . . . . 17 96 6.1. Protocols for Application and Service Migration . . . . . 18 97 6.2. Protocols for Content Delivery Network Migration . . . . 18 98 6.3. Protocols for Edge and Core Network Migration . . . . . . 18 99 6.4. Summary of ICN Protocol Gaps and Potential Protocol 100 Efforts . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 104 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 105 11. Informative References . . . . . . . . . . . . . . . . . . . 22 106 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 109 1. Introduction 111 The ICNRG charter identifies deployment guidelines as an important 112 topic area for the ICN community. Specifically, the charter states 113 that defining concrete migration paths for ICN deployments which 114 avoid forklift upgrades, and defining practical ICN interworking 115 configurations with the existing Internet paradigm, are key topic 116 areas that require further investigation [ICNRGCharter]. Also, it is 117 well understood that results and conclusions from any mid to large- 118 scale ICN experiments in the live Internet will also provide useful 119 guidance for deployments. 121 However, so far outside of some preliminary investigations such as 122 [I-D.paik-icn-deployment-considerations], there has not been much 123 progress on this topic. This document attempts to fill some of these 124 gaps by defining clear deployment configurations for ICN, and 125 associated migration pathways for these configurations. Also, 126 selected deployment trial experiences of ICN technology are 127 summarized. Finally, recommendations are made for potential future 128 IETF standardization of key protocol functionality that will 129 facilitate interoperable ICN deployments going forward. 131 2. Terminology 133 This document assumes readers are, in general, familiar with the 134 terms and concepts that are defined in [RFC7927] and 135 [I-D.irtf-icnrg-terminology]. In addition, this document defines the 136 following terminology: 138 Deployment - In the context of this document, deployment refers to 139 the final stage of the process of setting up an ICN network that 140 is (1) ready for useful work (e.g. transmission of end user video 141 and text) in a live environment, and (2) integrated and 142 interoperable with the Internet. We consider the Internet in its 143 widest sense where it encompasses various access networks (e.g. 144 WiFi, Mobile radio network), service edge networks (e.g. for edge 145 computing), transport networks, Content Distribution Networks 146 (CDNs), core networks (e.g. Mobile core network), and back-end 147 processing networks (e.g. Data Centres). However, through out 148 the document we typically limit the discussion to edge networks, 149 core networks and CDNs for simplicity. 151 Information-Centric Networking (ICN) - A data-centric network 152 architecture where accessing data by name is the essential network 153 primitive. See [I-D.irtf-icnrg-terminology] for further 154 information. 156 Network Function Virtualization (NFV): A networking approach where 157 network functions (e.g. firewalls, load balancers) are modularized 158 as software logic that can run on general purpose hardware, and 159 thus are specifically decoupled from the previous generation of 160 proprietary and dedicated hardware. See 161 [I-D.irtf-nfvrg-gaps-network-virtualization] for further 162 information. 164 Software-Defined Networking (SDN) - A networking approach where 165 the control and data plane for switches are separated, allowing 166 for realizing capabilities such as traffic isolation and 167 programmable forwarding actions. See [RFC7426] for further 168 information. 170 3. Deployment Configurations 172 In this section, we present various deployment options for ICN. 173 These are presented as "configurations" that allow for studying these 174 options further. While this document will outline experiences with 175 various of these configurations (in Section 5), we will not provide 176 an in-depth technical or commercial evaluation for any of them - for 177 this we refer to existing literature in this space such as [Tateson]. 179 3.1. Clean-slate ICN 181 ICN has often been described as a "clean-slate" approach with the 182 goal to renew or replace the complete IP infrastructure of the 183 Internet (e.g., existing applications which are typically tied 184 directly to the TCP/IP protocol stack, IP routers, etc.). As such, 185 existing routing hardware as well as ancillary services are not taken 186 for granted. For instance, a Clean-slate ICN deployment would see 187 existing IP routers being replaced by ICN-specific forwarding and 188 routing elements, such as NFD (Named Data Networking Forwarding 189 Daemon) [NFD], CCN routers [Jacobson] or PURSUIT forwarding nodes 190 [IEEE_Communications]. 192 While such clean-slate replacement could be seen as exclusive for ICN 193 deployments, some ICN approaches (e.g., [POINT]) also rely on the 194 deployment of general infrastructure upgrades, here SDN switches. 195 Such SDN infrastructure upgrades, while being possibly utilized for a 196 Clean-slate ICN deployment would not necessary be used exclusively 197 for such deployments. Different proposals have been made for various 198 ICN approaches to enable the operation over an SDN transport 199 [Reed][CONET][C_FLOW]. 201 3.2. ICN-as-an-Overlay 203 Similar to other significant changes to the Internet routing fabric, 204 particularly the transition from IPv4 to IPv6 or the introduction of 205 IP multicast, this deployment configuration foresees the creation of 206 an ICN overlay. Note that this overlay approach is sometimes, 207 informally, also referred to as a tunneling approach. The overlay 208 approach can be implemented directly such as ICN-over-UDP as 209 described in [CCNx_UDP]. Alternatively, the overlay can be 210 accomplished via ICN-in-L2-in-IP as in [IEEE_Communications] which 211 describes a recursive layering process. Another approach used in the 212 Network of Information (NetInf) is to define a convergence layer to 213 map NetInf semantics to HTTP [I-D.kutscher-icnrg-netinf-proto]. 214 Finally, [Overlay_ICN] describes an incremental approach to deploying 215 an ICN architecture based on segregating ICN user and control plane 216 traffic which is particularly well-suited to being overlaid on SDN 217 based networks. 219 Regardless of the flavor, however, the overlay approach results in 220 islands of ICN deployments over existing IP-based infrastructure. 221 Furthermore, these ICN islands are typically connected to each other 222 via ICN/IP tunnels. In certain scenarios this requires 223 interoperability between existing IP routing protocols (e.g. OSPF, 224 RIP, ISIS) and ICN based ones. ICN-as-an-Overlay can be deployed 225 over IP infrastructure in either edge or core networks. This overlay 226 approach is thus very attractive for ICN experimentation and testing 227 as it allows rapid and easy deployment of ICN over existing IP 228 networks. 230 3.3. ICN-as-an-Underlay 232 Proposals such as [POINT] and [White] outline the deployment option 233 of using an ICN underlay that would integrate with existing 234 (external) IP-based networks by deploying application layer gateways 235 at appropriate locations. The main reasons for such a configuration 236 option is the introduction of ICN technology in given islands (e.g., 237 inside a CDN or edge IoT network) to reap the benefits of native ICN 238 in terms of underlying multicast delivery, mobility support, fast 239 indirection due to location independence, in-network computing and 240 possibly more. The underlay approach thus results in islands of 241 native ICN deployments which are connected to the rest of the 242 Internet through protocol conversion gateways or proxies. Routing 243 domains are strictly separated. Outside of the ICN island, normal IP 244 routing protocols apply. Within the ICN island, ICN based routing 245 schemes apply. The gateways transfer the semantic content of the 246 messages (i.e., IP packet payload) between the two routing domains. 248 3.3.1. Edge Network 250 Native ICN networks may be located at the edge of the network which 251 allows the possibility of introducing new network architectures and 252 protocols, and in this context ICN is an attractive option for newer 253 deployments such as IoT [I-D.irtf-icnrg-icniot]. The integration 254 with the current IP protocol suite takes place at an application 255 gateway/proxy at the edge network boundary, e.g., translating 256 incoming CoAP request/response transactions [RFC7252] into ICN 257 message exchanges or vice versa. Furthermore, ICN will allow 258 enhancement of the role of gateways/proxies as ICN message security 259 should be preserved through the protocol translation function of a 260 gateway/proxy and thus offer a substantial gain. 262 The work in [VSER] positions ICN as an edge service gateway driven by 263 a generalized ICN based service orchestration system with its own 264 compute and network virtualization controllers to manage an ICN 265 infrastructure. The platform also offers service discovery 266 capabilities to enable user applications to discover appropriate ICN 267 service gateways. To exemplify a use case scenario, the [VSER] 268 platform shows the realization of a multi-party audio/video 269 conferencing service over such a edge cloud deployment of ICN routers 270 realized over commodity hardware platforms. This platform has also 271 been extended to offer seamless mobility and mobility as a service 272 [VSER-Mob] features. 274 3.3.2. Core Network 276 In this sub-option, a core network would utilize edge-based protocol 277 mapping onto the native ICN underlay. For instance, [POINT] proposes 278 to map HTTP transactions, or some other IP based transactions such as 279 CoAP, directly onto an ICN-based message exchange. This mapping is 280 realized at the network attachment point, such as realized in access 281 points or customer premise equipment, which in turn provides a 282 standard IP interface to existing user devices. Towards peering 283 networks, such network attachment point turns into a modified border 284 gateway/proxy, preserving the perception of an IP-based core network 285 towards any peering network. 287 The work in [White] proposes a similar deployment configuration. 288 Here, the target is the use of ICN for content distribution within 289 CDN server farms, i.e., the protocol mapping is realized at the 290 ingress of the server farm where the HTTP-based retrieval request is 291 served, while the response is delivered through a suitable egress 292 node translation. 294 3.4. ICN-as-a-Slice 296 The objective of Network slicing [NGMN]is to multiplex a general pool 297 of compute, storage and bandwidth resources among multiple service 298 networks with exclusive SLA requirements on transport level QoS and 299 security. This is enabled through NFV and SDN technology functions 300 that enables functional decomposition hence modularity, independent 301 scalability of control and/or the user-plane functions, agility and 302 service driven programmability. Network slicing is often associated 303 with 5G but is clearly not limited to such systems. However, from a 304 5G perspective, the definition of slicing includes access network 305 enabling dynamic slicing of air interface spectrum resources among 306 various services hence naturally extending itself to end points and 307 also cloud resources, across multiple domains, to offer end-to-end 308 guarantees. These slices once instantiated could include a mix of 309 connectivity services like LTE-as-a-service or OTT services like VoD 310 or other IoT services through composition of a group of virtual and/ 311 or physical network functions at control, user and service plane 312 level. Such a framework can also be used to realize ICN slices with 313 its own control, service and forwarding plane over which one or more 314 end-user services can be delivered. 316 The 5G next generation architecture [fiveG-23501] provides the 317 flexibility to deploy the ICN-as-a-Slice over either the edge (RAN) 318 or Mobile core network, or the ICN-as-a-Slice may be deployed end-to- 319 end. Further discussions on extending the architecture presented in 320 [fiveG-23501] and the corresponding procedures in [fiveG-23502] to 321 support ICN has been provided in [I-D.ravi-icnrg-5gc-icn]. Such a 322 generalized network slicing framework should be able to offer service 323 slices to be realized using both IP and ICN. Coupled with the view 324 of ICN functions as being "chained service functions" [RFC7665], an 325 ICN deployment within such a slice could also be realized within the 326 emerging orchestration plane that is targeted for adoption in future 327 (e.g., 5G Mobile) network deployments. Finally, it should be noted 328 that ICN is not creating the network slice, but instead that the 329 slice is created to run an 5G-ICN instance [Ravindran]. 331 At the level of the specific technologies involved, such as ONAP 332 [ONAP] that can be used to orchestrate slices, the 5G-ICN slice 333 requires compatibility for instance at the level of the forwarding/ 334 data plane depending on if it is realized as an overlay or using 335 programmable data planes. With SDN emerging for new network 336 deployments, some ICN approaches will need to integrate with SDN as a 337 data plane forwarding function, as briefly discussed in Section 3.1. 338 Further cross domain ICN slices can also be realized using frameworks 339 such as [ONAP]. 341 3.5. Composite-ICN Approach 343 Some deployments do not clearly correspond to any of the previously 344 defined basic configurations of (1) Clean-slate ICN; (2) ICN-as-an- 345 Overlay; (3) ICN-as-an-Underlay; and (4) ICN-as-a-Slice. Or, a 346 deployment may contain a composite mixture of the properties of these 347 basic configurations. For example, the Hybrid ICN [H-ICN_1] approach 348 carries ICN names in existing IPv6 headers and does not have distinct 349 gateways or tunnels connecting ICN islands, or any other distinct 350 feature identified in the previous basic configurations. So we 351 categorize Hybrid ICN, and other approaches that do not clearly 352 correspond to one of the other basic configurations, as a Composite- 353 ICN approach. 355 4. Deployment Migration Paths 357 After outlining the various ICN deployment configurations in 358 Section 3, we now focus on the various migration paths that will have 359 importance to the various stakeholders that are usually involved in 360 the deployment of a technology at (ultimately) large scale. We can 361 identify these stakeholders as: 363 o Application providers 365 o ISPs and service providers, both as core as well as access network 366 providers, and also ICN network providers 368 o CDN providers (due to the strong relation of the ICN proposition 369 to content delivery) 371 o End device manufacturers and users 373 Note that our presentation purely focuses on technological aspects of 374 such migration. Economic or regulatory aspects, such as studied in 375 [Tateson], [Techno_Economic] and [Internet_Pricing] are left out of 376 our discussion. 378 4.1. Application and Service Migration 380 The internet is full of applications and services, utilizing the 381 innovation capabilities of the many protocols defined over the packet 382 level IP service. HTTP provides one convergence point for these 383 services with many Web development frameworks based on the semantics 384 provided by the hypertext transfer protocol. In recent years, even 385 services such as video delivery have been migrating from the 386 traditional RTP-over-UDP delivery to the various HTTP-level streaming 387 solutions, such as DASH [DASH] and others. Nonetheless, many non- 388 HTTP services exist, all of which need consideration when migrating 389 from the IP-based internet to an ICN-based one. 391 The underlay deployment configuration options presented in 392 Section 3.3.2 and Section 3.3.1 aim at providing some level of 393 backward compatibility to this existing ecosystem through a proxy 394 based message flow mapping mechanism (e.g., mapping of existing 395 HTTP/TCP/IP message flows to HTTP/TCP/IP/ICN message flows). A 396 related approach of mapping TCP/IP to TCP/ICN message flows is 397 described in [Moiseenko]. Another approach described in [Marchal] 398 uses HTTP/NDN gateways and focuses in particular on the right 399 strategy to map HTTP over NDN to guarantee a high level of 400 compatibility with HTTP while enabling an efficient caching of Data 401 in the ICN island. 403 Alternatively, ICN as an overlay (Section 3.2), as well as ICN-as- 404 a-Slice (Section 3.4), allow for the introduction of the full 405 capabilities of ICN through new application/service interfaces as 406 well as operations in the network. With that, these approaches of 407 deployment are likely to aim at introducing new application/services 408 capitalizing on those ICN capabilities. 410 Finally, [I-D.irtf-icnrg-icn-lte-4g] outlines a dual-stack end user 411 device approach that is applicable for all deployment configurations. 412 Specifically, [I-D.irtf-icnrg-icn-lte-4g] introduces middleware 413 layers (called the Transport Convergence Layer, TCL) in the device 414 that will dynamically adapt existing applications to either an 415 underlying ICN protocol stack or standard IP protocol stack. This 416 involves end device signalling with the network to determine which 417 protocol stack instance and associated middleware adaptation layers 418 to utilize for a given application transaction. 420 4.2. Content Delivery Network Migration 422 A significant number of services and applications are devoted to 423 content delivery in some form, either as video delivery services, 424 social media platforms, and many others. Content delivery networks 425 (CDNs) are deployed to assist these services through localizing the 426 content requests and therefore reducing latency and possibly increase 427 utilization of available bandwidth as well as reducing the load on 428 origin servers. Similar to the previous sub-section, the underlay 429 deployment configurations presented in Section 3.3.2 and 430 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.1.5. UMOBILE Efforts 553 UMOBILE (universal mobile-centric and opportunistic communications 554 architecture) is one of the ICN research projects under the H2020 555 framework program (http://www.umobile-project.eu/). The UMOBILE 556 architecture integrates the principles of Delay Tolerant Networking 557 (DTN) and ICN in a common framework to support edge computation and 558 mobile opportunistic wireless environments (e.g., post-disaster 559 scenarios and remote areas). The UMOBILE architecture [UMOBILE-2] 560 was developed on top of the NDN framework by following the overlay 561 deployment configuration of Section 3.2. UMOBILE aims to advance 562 networking technologies and architectures. In particular, extending 563 Internet functionally - by combining ICN and DTN technologies; 564 geographically - by allowing for inter-networking over remote and 565 isolated areas; and social aspects - by allowing low-cost access and 566 free user-to-user networking. 568 One of the innovative aspects of UMOBILE was the extension of the NDN 569 framework to encompass push network services (e.g., mobility 570 management, intermittent connectivity support) and user services 571 (e.g., pervasive content management) as close as possible to the end- 572 users to optimise bandwidth utilization and resource management. 573 Another innovation was the evolution of the NDN framework to operate 574 in wireless networks, namely in emergency scenarios [UMOBILE-3], 575 using secure, reliable wireless services able to operate even with 576 intermittent connectivity. To achieve such a goal, the NDN framework 577 was leveraged with a messaging system based on a new application, 578 called Oi! [UMOBILE-4], which uses two methods of push communication 579 based on a new branch of NDN Android, called NDN-OPP [UMOBILE-5] that 580 supports intermittent wireless networking. NDN-OPP implements a new 581 data-centric wireless routing protocol, DABBER [UMOBILE-6] 582 [I-D.mendes-icnrg-dabber], which was designed based on data 583 reachability metrics that take into consideration availability and 584 centrality of adjacent wireless nodes, as well as the availability of 585 different data sources. The contextual-awareness about the operation 586 of the wireless network is obtained in a self-learning approach, by a 587 software-based agent, the Contextual Manager, running within the 588 wireless node [UMOBILE-7]. 590 During the project time (Feb 2015 - Apr 2018), the consortium 591 completed some couple of significant ICN deployment trails. One of 592 that was related to the post disaster scenario. In this trial 593 [UMOBILE-8], a special DTN face was created to provide reachability 594 to remote area where there is no typical Internet connection. 595 Another trail was the ICN deployment over the Guifi.net community 596 network. This trial focused on the evaluation of ICN edge computing 597 platform, called PiCasso [UMOBILE-9] which is a part of UMOBILE 598 project. In this trial, ten(10) raspberry Pis were deployed across 599 the Sants area of Barcelona to create an ICN overlay network on top 600 of the existing IP routing protocol (e.g., qMp routing). Through the 601 evaluation of this trail, it shows that ICN plays a key role in 602 improving the quality of service delivery as well as reducing the 603 traffic consumption in the intermittent connectivity environment 604 (e.g., wireless community network). A third trial was focused on 605 displaying the capability of the UMOBILE architecture to reach 606 disconnected areas and assist responsible authorities in challenged 607 events, corresponding to an infrastructure scenario. This trial was 608 conducted in April 2018 in Italy, with the patronage of the Civil 609 Protection Department of Umbria Region. In an outdoor demonstration, 610 it was shown how to overcome a low or missing connectivity, thus 611 allowing users to communicate, especially in emergency situations as 612 the one simulated during the demo. The demonstration encompasses 613 seven (7) end-user devices, one (1) access-point, and one (1) 614 gateway. An extended demonstration to the Portuguese Civil 615 protection authority in March 2018, included also an UAV carrying a 616 UMOBILE raspberry Pi that served as relay and carrier of information. 618 5.2. ICN-as-an-Underlay 620 5.2.1. H2020 POINT and RIFE Efforts 622 POINT and RIFE are two more ICN related research projects funded by 623 the EU as part of the H2020 effort. The efforts in the H2020 624 POINT+RIFE projects follow the underlay deployment configuration in 625 Section 3.3.2, although this is mixed with utilizing an overlay 626 deployment to provide multi-national connectivity. However, underlay 627 SDN-based deployments do exist at various project partner sites, 628 e.g., at Essex University, without any overlaying being realized. 629 Edge-based network attachment points (NAPs) provide the IP/HTTP-level 630 protocol mapping onto ICN protocol exchanges, while the SDN underlay 631 (or the VPN-based L2 underlay) is used as a transport network. 633 The multicast as well as service endpoint surrogate benefits in HTTP- 634 based scenarios, such as for HTTP-level streaming video delivery, 635 have been demonstrated in the deployed POINT test bed with 80+ nodes 636 being utilized. Demonstrations of this capability have been given to 637 the ICNRG in 2016, and public demonstrations were also provided at 638 events such as Mobile World Congress in 2016 [MWC_Demo]. The trial 639 has also been accepted by the ETSI MEC group as a proof-of-concept 640 with a demonstration at the ETSI MEC World Congress in 2016. 642 While the afore-mentioned demonstrations all use the overlay 643 deployment, H2020 also has performed ICN underlay trials. One such 644 trial involved commercial end users located in the Primetel network 645 in Cyprus with the use case centered on IPTV and HLS video 646 dissemination. Another trial was performed in the community network 647 of "guifi.net" in the Barcelona region, where the solution was 648 deployed in 40 households, providing general Internet connectivity to 649 the residents. Standard IPTV STBs as well as HLS video players were 650 utilized in accordance with the aim of this deployment configuration, 651 namely to provide application and service migration. 653 5.2.2. H2020 FLAME Efforts 655 The H2020 FLAME efforts concentrate on providing an experimental 656 ground for the aforementioned POINT/RIFE solution in initially two 657 city-scale locations, namely in Bristol and Barcelona. This trial 658 followed the underlay deployment configuration in Section 3.3.2 as 659 per POINT/RIFE approach. Experiments were conducted with the city/ 660 university joint venture Bristol-is-Open (BIO), to ensure the 661 readiness of the city-scale SDN transport network for such 662 experiments. Another trial was for the ETSI MEC PoC. This trial 663 showcased operational benefits provided by the ICN underlay for the 664 scenario of a location-based game. These benefits aim at reduced 665 network utilization through improved video delivery performance 666 (multicast of all captured videos to the service surrogates deployed 667 in the city at six locations) as well as reduced latency through the 668 playout of the video originating from the local NAP instead of a 669 remote server. 671 Ensuring the technology readiness and the early trialing of the ICN 672 capabilities lays the ground for the goal of the H2020 FLAME efforts 673 to conduct 23 large-scale experiments in the area of Future Media 674 Internet (FMI) throughout 2018 and 2019. Standard media service 675 functions as well as applications will ultimately utilize the ICN 676 underlay in the delivery of their experience. The platform, which 677 includes the ICN capabilities, will utilize concepts of SFC, 678 integrated with NFV and SDN capabilities of the infrastructure. The 679 ultimate goal of these platform efforts is the full integration of 680 ICN into the overall media function platform for the provisioning of 681 advanced (media-centric) internet services. 683 5.2.3. CableLabs Content Delivery System 685 The work in [White] proposes an underlay deployment configuration 686 based on Section 3.3.2. The use case is ICN for content distribution 687 within CDN server farms (which can be quite large and complex) to 688 leverage ICN's superior in-network caching properties. This "island 689 of ICN" based CDN is then used to service standard HTTP/IP-based 690 content retrieval request coming from the general Internet. This 691 approach acknowledges that whole scale replacement (see Section 3.1) 692 of existing HTTP/IP end user applications and related Web 693 infrastructure is a difficult proposition. [White] does not yet 694 provide results but indicated that experiments will be forthcoming. 696 5.2.4. NDN IoT Trials 698 [Baccelli] summarizes the trial of an NDN system adapted specifically 699 for a wireless IoT scenario. The trial was run with 60 nodes 700 distributed over several multi-story buildings in a university campus 701 environment. The NDN protocols were optimized to run directly over 702 6LoWPAN wireless link layers. The performance of the NDN based IoT 703 system was then compared to an equivalent system running standard IP 704 based IoT protocols. It was found that the NDN based IoT system was 705 superior in several respects including in terms of energy 706 consumption, and for RAM and ROM footprints [Baccelli] 707 [Anastasiades]. 709 5.2.5. NREN ICN Testbed 711 The National Research and Education Network (NREN) ICN Testbed is a 712 project sponsored by Cisco, Internet2, and the U.S. Research and 713 Education community. Participants include universities and US 714 federal government entities that connect via a nation-wide VPN-based 715 L2 underlay. The testbed uses the CCN approach and is based on the 716 [CICN] open source software. There are approximately 15 nodes spread 717 across the USA which connect to the testbed. The project's current 718 focus is to advance data-intensive science and network research by 719 improving data movement, searchability, and accessibility. 721 5.2.6. Doctor Testbed 723 The Doctor project is a French research project meaning "Deployment 724 and Securisation of new Functionalities in Virtualized Networking 725 Environments". The project aims to run NDN over virtualized NFV 726 infrastructure [Doctor] (based on Docker technology) and focuses on 727 the Management and Orchestration (MANO) aspects to build an 728 operational NDN network regarding essential criteria such as 729 security, performance and interoperability. 731 The data-plane relies on a HTTP/NDN gateway [Marchal] that processes 732 HTTP traffic and transports it in an optimized way over NDN to 733 benefit from the properties of the NDN-island. The testbed carries 734 real Web traffic of users, and has been currently evaluated with the 735 top-1000 most popular Web sites. The users only need to set the 736 gateway as the Web proxy. The control-plane relies on a central 737 manager which uses machine learning based detection methods [Mai-1] 738 from the date gathered by distributed probes and applies orchestrated 739 counter-measures against NDN attacks [Nguyen-1] [Nguyen-2] [Mai-2] or 740 performance issues. A remediation can be, for example, the scale-up 741 of a bottleneck component, or the deployment of a security function 742 like a firewall or a signature verification module. The end target 743 of the project is to have a future complete testbed where the 744 developed concepts will be implemented, monitored and validated. 746 5.3. Composite-ICN Approach 748 5.3.1. Hybrid ICN Trials 750 Hybrid ICN [H-ICN_1] [H-ICN_2] is an approach where the ICN names are 751 mapped to IPv6 addresses, and other ICN information is carried as 752 payload inside the IP packet. This allows standard (ICN-unaware) IP 753 routers to forward packets based on IPv6 info, but enables ICN-aware 754 routers to apply ICN semantics. The intent is to enable rapid hybrid 755 deployments and seamless interconnection of IP and Hybrid ICN 756 domains. Hybrid ICN uses [CICN] open source software. Initial tests 757 have been done with 150 clients consuming DASH (HTTP) videos which 758 showed good scalability properties at the Server Side using the 759 Hybrid ICN transport [H-ICN_3] [H-ICN_2]. 761 5.4. Summary of Deployment Trials 763 In summary, there have been significant trials over the years with 764 all the major ICN protocol flavors (e.g., CCN, NDN, POINT) using both 765 the ICN-as-an-Overlay and ICN-as-an-Underlay deployment 766 configurations. The major limitations of the trials include the fact 767 that only a limited number of applications have been tested. 768 However, the tested applications include both native ICN and existing 769 IP based applications (e.g. video-conferencing and IPTV). Another 770 limitation of the trials is that all of them involve less than 1000 771 users maximum. 773 The ICN-as-a-Slice configuration still has not be trialled primarily 774 due to the fact that 5G standards are still in flux and not expected 775 to be stable before the 2019 time frame. The Clean-slate ICN 776 approach has obviously never been trialled as complete replacement of 777 Internet infrastructure (e.g., existing applications, TCP/IP protocol 778 stack, IP routers, etc.) is no longer considered a viable 779 alternative. 781 Finally, Hybrid ICN is a Composite-ICN approach that offers an 782 interesting alternative as it allows ICN semantics to be embedded in 783 standard IPv6 packets and so the packets can be routed through either 784 IP routers or Hybrid ICN routers. Note that some other trials such 785 as the Doctor testbed (Section 5.2.6) could also be characterized as 786 a Composite-ICN approach because it contains both ICN gateways (as in 787 ICN-as-an-Underlay) and virtualized infrastructure (as in ICN-as- 788 a-Slice). However, for the Doctor testbed we have chosen to 789 characterize it as an ICN-as-an-Underlay configuration because that 790 is a dominant characteristic. 792 6. Deployment Issues Requiring Further Standardization 794 The ICN Research Challenges [RFC7927] describes key ICN principles 795 and technical research topics. As the title suggests, [RFC7927] is 796 research oriented without a specific focus on deployment or 797 standardization issues. This section addresses this open area by 798 identifying key protocol functionality that that may be relevant for 799 further standardization effort in IETF. The focus is specifically on 800 identifying protocols that will facilitate future interoperable ICN 801 deployments correlating to the scenarios identified in the deployment 802 migration paths in Section 4. The identified list of potential 803 protocol functionality is not exhaustive. 805 6.1. Protocols for Application and Service Migration 807 End user applications and services need a standardized approach to 808 trigger ICN transactions. For example, in Internet and Web 809 applications today, there are established socket APIs, communication 810 paradigms such as REST, common libraries, and best practices. We see 811 a need to study application requirements in an ICN environment 812 further and, at the same time, develop new APIs and best practices 813 that can take advantage of ICN communication characteristics. 815 6.2. Protocols for Content Delivery Network Migration 817 A key issue in CDNs is to quickly find a location of a copy of the 818 object requested by an end user. In ICN, a Named Data Object (NDO) 819 is typically defined by its name. There already exists [RFC6920] 820 that is suitable for static naming of ICN data objects. Other ways 821 of encoding and representing ICN names have been described in 822 [I-D.irtf-icnrg-ccnxmessages] and [I-D.mosko-icnrg-ccnxurischeme]. 823 Naming dynamically generated data requires different approaches (for 824 example, hash digest based names would normally not work), and there 825 is lack of established conventions and standards. 827 Another CDN issue for ICN is related to multicast distribution of 828 content. Existing CDNs have started using multicast mechanisms for 829 certain cases such as for broadcast streaming TV. However, as 830 discussed in Section 5.2.1, certain ICN approaches provide 831 substantial improvements over IP multicast, such as the implicit 832 support for multicast retrieval of content in all ICN flavours. 834 Caching is an implicit feature in many ICN architectures that can 835 improve performance and availability in several scenarios. The ICN 836 in-network caching can augment managed CDN and improve its 837 performance. The details of the interplay between ICN caching and 838 managed CDN need further consideration. 840 6.3. Protocols for Edge and Core Network Migration 842 ICN provides the potential to redesign current edge and core network 843 computing approaches. Leveraging ICN's inherent security and its 844 ability to make name data and dynamic computation results available 845 independent of location, can enable a secure, yet light-weight 846 insertion of traffic into the network without relying on redirection 847 of DNS requests. For this, proxies that translate from commonly used 848 protocols in the general Internet to ICN message exchanges in the ICN 849 domain could be used for the migration of application and services 850 within deployments at the network edge but also in core networks. 851 This is similar to existing approaches for IoT scenarios where a 852 proxy translates CoAP request/responses to other message formats. 854 For example, [RFC8075] specifies proxy mapping between CoAP and HTTP 855 protocols. However, as mentioned previously, ICN will allow us to 856 evolve the role of gateways/proxies as ICN message security should be 857 preserved through the protocol translation function of a thus offer a 858 substantial gain. 860 Interaction and interoperability between existing IP routing 861 protocols (e.g., OSPF, RIP, ISIS) and ICN routing approaches(e.g., 862 NFD, CCN routers) are expected especially in the overlay approach. 863 Another important topic is integration of ICN into networks that 864 support virtualized infrastructure in the form of NFV/SDN and most 865 likely utilizing Service Function Chaining (SFC) as a key protocol. 866 Further work is required to validate this idea and document best 867 practices. 869 There are several existing approaches to supporting QoS in IP 870 networks including Differentiated Services (DiffServ), Integrated 871 Services (IntServ) and Resource Reservation Protocol (RSVP). Some 872 initial ideas for QoS support in ICN networks are outlined in 873 [I-D.moiseenko-icnrg-flowclass] which proposes a flow classification 874 based approach to enable functions such ICN rate control and cache 875 control. Also [I-D.anilj-icnrg-icn-qos] proposes how to use DiffServ 876 DSCP codes to support QoS for ICN based data path delivery. Further 877 work is required to identify the best approaches and alternatives for 878 support of QoS in ICN networks . 880 Operations and Maintenance (OAM) is a crucial area that has not yet 881 been fully addressed by the ICN research community, but which is 882 obviously critical for future deployments of ICN. Potential areas 883 that need investigation include whether the YANG data modelling 884 approach and associated NETCONF/RESTCONF protocols need any specific 885 updates for ICN support. Another open area is how to measure and 886 benchmark performance of ICN networks comparable to the sophisticated 887 techniques that exist for standard IP networks, virtualized networks 888 and data centers. It should be noted that some initial progress has 889 been made in the area of ICN network path traceroute facility with 890 approaches such as CCNinfo [I-D.asaeda-icnrg-ccninfo] [Contrace]. 892 6.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts 894 Without claiming completeness, Table 1 maps the open ICN issues 895 identified in this document to potential protocol efforts that could 896 address some aspects of the gap. 898 +--------------+----------------------------------------------------+ 899 | ICN Gap | Potential Protocol Effort | 900 +--------------+----------------------------------------------------+ 901 | 1-Support of | HTTP/CoAP support of ICN semantics | 902 | REST APIs | | 903 | | | 904 | 2-Naming | Dynamic naming of ICN data objects | 905 | | | 906 | 3-Routing | Interactions between IP and ICN routing protocols | 907 | | | 908 | 4-Multicast | Multicast enhancements for ICN | 909 | distribution | | 910 | | | 911 | 5-In-network | ICN Cache placement and sharing | 912 | caching | | 913 | | | 914 | 6-NFV/SDN | Integration of ICN with NFV/SDN and including | 915 | support | possible impacts to SFC | 916 | | | 917 | 7-ICN | Mapping of HTTP and other protocols onto ICN | 918 | mapping | message exchanges (and vice-versa) while | 919 | | preserving ICN message security | 920 | | | 921 | 8-QoS | Support of ICN QoS via mechanisms such as DiffServ | 922 | support | and flow classification | 923 | | | 924 | 9-OAM | YANG models, NETCONF/RESTCONF protocols, | 925 | support | and network performance measurements | 926 | | | 927 +--------------+----------------------------------------------------+ 929 Table 1: Mapping of ICN Gaps to Potential Protocol Efforts 931 7. Conclusion 933 This document provides high level deployment considerations for the 934 ICN community. Specifically, the major configurations of possible 935 ICN deployments are identified as (1) Clean-slate ICN replacement of 936 existing Internet infrastructure; (2) ICN-as-an-Overlay; (3) ICN-as- 937 an-Underlay; (4) ICN-as-a-Slice; and (5) Composite-ICN. Existing ICN 938 trial systems primarily fall under the ICN-as-an-Overlay, ICN-as-an- 939 Underlay and Composite-ICN configurations. 941 In terms of deployment migration paths, ICN-as-an-Underlay offers a 942 clear migration path for CDN, edge and core networks to go to an ICN 943 paradigm (e.g., for an IoT deployment). ICN-as-an-Overlay is 944 probably the easiest configuration to deploy rapidly as it leaves the 945 underlying IP infrastructure essentially untouched. However its 946 applicability for general deployment must be considered on a case by 947 case basis (e.g., based on if it can run all required applications or 948 other similar criteria). ICN-as-a-Slice is an attractive deployment 949 option for future 5G systems (i.e., for 5G radio and core networks) 950 which will naturally support network slicing, but this still has to 951 be validated through actual trial experiences. Composite-ICN, by its 952 nature, can combine some of the best characteristics of the other 953 configurations, but its applicability for general deployment must be 954 considered on a case by case basis. 956 For the crucial issue of existing application and service migration 957 to ICN, various mapping schemes are possible to mitigate impacts. 958 For example, HTTP/TCP/IP flows may be mapped to/from ICN message 959 flows at proxies in the ICN-as-an-Underlay configurations leaving the 960 massive number of existing end point applications/services untouched 961 or minimally impacted. Also dual stack end user devices that include 962 middleware to allow applications to communicate in both ICN mode and 963 standard IP mode are an attractive proposition for gradual and 964 geographically discontinuous introduction for all deployment 965 configurations. 967 There has been significant trial experience with all the major ICN 968 protocol flavors (e.g., CCN, NDN, POINT). However, only a limited 969 number of applications have been tested so far, and the maximum 970 number of users in any given trial has been less than 1000 users. It 971 is recommended that future ICN deployments scale their users 972 gradually and closely monitor network performance as they go above 973 1000 users. 975 Finally, this document describes a set of technical features in ICN 976 that warrant potential future IETF specification work. This will aid 977 initial and incremental deployments to proceed in an interoperable 978 manner. The fundamental details of the potential protocol 979 specification effort, however, are best left for future study by the 980 appropriate IETF WGs and/or BoFs. 982 8. IANA Considerations 984 This document requests no IANA actions. 986 9. Security Considerations 988 ICN was purposefully designed from the start to have certain 989 intrinsic security properties. The most well known of which are 990 authentication of delivered content and (optional) encryption of the 991 content. [RFC7945] has an extensive discussion of various aspects of 992 ICN security including many which are relevant to deployments. 993 Specifically, [RFC7945] points out that ICN access control, privacy, 994 security of in-network caches, and protection against various network 995 attacks (e.g. DoS) have not yet been fully developed due to the lack 996 of a sufficient mass of deployments. [RFC7945] also points out 997 relevant advances occurring in the ICN research community that hold 998 promise to address each of the identified security gaps. Lastly, 999 [RFC7945] points out that as secure communications in the existing 1000 Internet (e.g. HTTPS) becomes the norm, that major gaps in ICN 1001 security will inevitably slow down the adoption of ICN. 1003 In addition to the security findings of [RFC7945], this document has 1004 highlighted that all anticipated ICN deployment configurations will 1005 involve co-existence with existing Internet infrastructure and 1006 applications. Thus even the basic authentication and encryption 1007 properties of ICN content will need to account for interworking with 1008 non-ICN content to preserve end-to-end security. For example, in the 1009 edge network underlay deployment configuration described in 1010 Section 3.3.1, the gateway/proxy that translates HTTP or CoAP 1011 request/responses into ICN message exchanges will need to support a 1012 security model to preserve end-to-end security. 1014 Finally, the Doctor project discussed in Section 5.2.6 is an example 1015 of an early deployment that is looking at specific attacks against 1016 ICN infrastructure. In this case, looking at Interest Flooding 1017 Attacks [Nguyen-2] and Content Poisoning Attacks [Nguyen-1] [Mai-2] 1018 and evaluation of potential counter-measures based on MANO 1019 orchestrated actions on the virtualized infrastructure [Mai-1] . 1021 10. Acknowledgments 1023 The authors want to thank Alex Afanasyev, Mayutan Arumaithurai, 1024 Hitoshi Asaeda, Giovanna Carofiglio, Xavier de Foy, Guillaume Doyen, 1025 Hannu Flinck, Anil Jangam, Michael Kowal, Adisorn Lertsinsrubtavee, 1026 Paulo Mendes, Luca Muscariello, Dave Oran, Thomas Schmidt, Jan 1027 Seedorf, Eve Schooler, Samar Shailendra, Milan Stolic, Prakash 1028 Suthar, Atsushi Tagami, and Lixia Zhang for their very useful 1029 reviews, comments and input to the document. 1031 11. Informative References 1033 [Anastasiades] 1034 Anastasiades, C., "Information-centric communication in 1035 mobile and wireless networks", PhD Dissertation, 2016, 1036 . 1038 [Baccelli] 1039 Baccelli, E. and et al., "Information Centric Networking 1040 in the IoT: Experiments with NDN in the Wild", ACM 1041 20164, Paris, France, 2014, 1042 . 1045 [C_FLOW] Suh, J. and et al., "C_FLOW: Content-Oriented Networking 1046 over OpenFlow", Open Networking Summit, April, 2012, 1047 . 1050 [CCNx_UDP] 1051 PARC, "CCNx Over UDP", 2015, 1052 . 1055 [CICN] CICN, "Community Information-Centric Networking (CICN)", 1056 2017, . 1058 [CONET] Veltri, L. and et al., "CONET Project: Supporting 1059 Information-Centric Functionality in Software Defined 1060 Networks", Workshop on Software Defined Networks, , 2012, 1061 . 1064 [Contrace] 1065 Asaeda, H. and et al., "Contrace: A Tool for Measuring and 1066 Tracing Content-Centric Networks", IEEE Communications 1067 Magazine, Vol.53, No.3 , 2015. 1069 [CUTEi] Asaeda, H. and N. Choi, "Container-Based Unified Testbed 1070 for Information Centric Networking", IEEE Network, Vol.28, 1071 No.6 , 2014. 1073 [DASH] DASH, "DASH Industry Forum", 2017, . 1075 [Doctor] Doctor, "Deployment and Securisation of new 1076 Functionalities in Virtualized Networking Environments 1077 (Doctor)", 2017, 1078 . 1080 [fiveG-23501] 1081 3gpp-23.501, "Technical Specification Group Services and 1082 System Aspects; System Architecture for the 5G System 1083 (Rel.15)", 3GPP , 2017. 1085 [fiveG-23502] 1086 3gpp-23.502, "Technical Specification Group Services and 1087 System Aspects; Procedures for the 5G System (Rel.15)", 1088 3GPP , 2017. 1090 [H-ICN_1] Cisco, "Hybrid ICN: Cisco Announces Important Steps toward 1091 Adoption of Information-Centric Networking", 2017, 1092 . 1095 [H-ICN_2] Cisco, "Mobile Video Delivery with Hybrid ICN: IP- 1096 Integrated ICN Solution for 5G", 2017, 1097 . 1101 [H-ICN_3] Muscariello, L. and et al., "Hybrid Information-Centric 1102 Networking: ICN inside the Internet Protocol", 2018, 1103 . 1107 [H-ICN_4] MSardara, M. and et al., "(h)ICN Socket Library for HTTP: 1108 Leveraging (h)ICN socket library for carrying HTTP 1109 messages", 2018, . 1113 [I-D.anilj-icnrg-icn-qos] 1114 Jangam, A., suthar, P., and M. Stolic, "Supporting QoS 1115 aware Data Delivery in Information Centric Networks", 1116 draft-anilj-icnrg-icn-qos-00 (work in progress), July 1117 2018. 1119 [I-D.asaeda-icnrg-ccninfo] 1120 Asaeda, H. and X. Shao, "CCNinfo: Discovering Content and 1121 Network Information in Content-Centric Networks", draft- 1122 asaeda-icnrg-ccninfo-01 (work in progress), June 2018. 1124 [I-D.ietf-bier-use-cases] 1125 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 1126 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 1127 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-07 1128 (work in progress), July 2018. 1130 [I-D.irtf-icnrg-ccnxmessages] 1131 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 1132 Format", draft-irtf-icnrg-ccnxmessages-08 (work in 1133 progress), July 2018. 1135 [I-D.irtf-icnrg-icn-lte-4g] 1136 suthar, P., Stolic, M., Jangam, A., Trossen, D., and R. 1137 Ravindran, "Native Deployment of ICN in LTE, 4G Mobile 1138 Networks", draft-irtf-icnrg-icn-lte-4g-01 (work in 1139 progress), July 2018. 1141 [I-D.irtf-icnrg-icniot] 1142 Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., 1143 Raychadhuri, D., Baccelli, E., Burke, J., Wang, G., 1144 Ahlgren, B., and O. Schelen, "Design Considerations for 1145 Applying ICN to IoT", draft-irtf-icnrg-icniot-01 (work in 1146 progress), February 2018. 1148 [I-D.irtf-icnrg-terminology] 1149 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 1150 D., and C. Tschudin, "Information-Centric Networking 1151 (ICN): CCN and NDN Terminology", draft-irtf-icnrg- 1152 terminology-00 (work in progress), December 2017. 1154 [I-D.irtf-nfvrg-gaps-network-virtualization] 1155 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 1156 Aranda, P., and P. Lynch, "Network Virtualization Research 1157 Challenges", draft-irtf-nfvrg-gaps-network- 1158 virtualization-10 (work in progress), September 2018. 1160 [I-D.kutscher-icnrg-netinf-proto] 1161 Kutscher, D., Farrell, S., and E. Davies, "The NetInf 1162 Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in 1163 progress), February 2013. 1165 [I-D.mendes-icnrg-dabber] 1166 Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos, 1167 S., and C. Sarros, "Information-centric Routing for 1168 Opportunistic Wireless Networks", draft-mendes-icnrg- 1169 dabber-01 (work in progress), August 2018. 1171 [I-D.moiseenko-icnrg-flowclass] 1172 Moiseenko, I. and D. Oran, "Flow Classification in 1173 Information Centric Networking", draft-moiseenko-icnrg- 1174 flowclass-02 (work in progress), July 2018. 1176 [I-D.mosko-icnrg-ccnxurischeme] 1177 marc.mosko@parc.com, m. and c. cwood@parc.com, "The CCNx 1178 URI Scheme", draft-mosko-icnrg-ccnxurischeme-01 (work in 1179 progress), April 2016. 1181 [I-D.paik-icn-deployment-considerations] 1182 Paik, E., Yun, W., Kwon, T., and h. 1183 hgchoi@mmlab.snu.ac.kr, "Deployment Considerations for 1184 Information-Centric Networking", draft-paik-icn- 1185 deployment-considerations-00 (work in progress), July 1186 2013. 1188 [I-D.ravi-icnrg-5gc-icn] 1189 Ravindran, R., suthar, P., Trossen, D., and G. White, 1190 "Enabling ICN in 3GPP's 5G NextGen Core Architecture", 1191 draft-ravi-icnrg-5gc-icn-02 (work in progress), July 2018. 1193 [ICN2020] ICN2020, "ICN2020 Deliverables", 2017, 1194 . 1197 [ICNRGCharter] 1198 NDN, "Information-Centric Networking Research Group 1199 Charter", 2013, 1200 . 1202 [IEEE_Communications] 1203 Trossen, D. and G. Parisis, "Designing and Realizing an 1204 Information-Centric Internet", Information-Centric 1205 Networking, IEEE Communications Magazine Special Issue, 1206 2012. 1208 [Internet_Pricing] 1209 Trossen, D. and G. KBiczok, "Not Paying the Truck Driver: 1210 Differentiated Pricing for the Future Internet", ReArch 1211 Workshop in conjunction with ACM Context, December, 2010. 1213 [Jacobson] 1214 Jacobson, V. and et al., "Networking Named Content", 1215 Proceedings of ACM Context, , 2009. 1217 [Jangam] Jangam, A. and et al., "Porting and Simulation of Named- 1218 data Link State Routing Protocol into ndnSIM", ACM 1219 DIVANet'17, Miami Beach, USA, 2017, 1220 . 1222 [Mai-1] Mai, H., Aouadj, M., Doyen, G., Kondo, D., Marchal, X., 1223 Cholez, T., Montes de Oca, E., and W. Mallouli, 1224 "Implementation of Content Poisoning Attack Detection and 1225 Reaction in Virtualized NDN Networks", 21st Conference on 1226 Innovation in Clouds, Internet and Networks, ICIN 2018 1227 (demo paper) IEEE, 2018, 1228 . 1231 [Mai-2] Mai, H., Nguyen, T., Doyen, G., Cogranne, R., Mallouli, 1232 W., Montes de Oca, E., and O. Festor, "Towards a Security 1233 Monitoring Plane for Named Data Networking: Application to 1234 Content Poisoning Attack", Proceedings of the 2018 IEEE/ 1235 IFIP Symposium on Network Operations and Management (NOMS) 1236 IEEE, 2018. 1238 [Marchal] Marchal, X., El Aoun, M., Mathieu, B., Cholez, T., Doyen, 1239 G., Mallouli, W., and O. Festor, "Leveraging NFV for the 1240 Deployment of NDN: Application to HTTP Traffic Transport", 1241 Proceedings of the 2018 IEEE/IFIP Symposium on Network 1242 Operations and Management (NOMS), 2018, 1243 . 1246 [Moiseenko] 1247 Moiseenko, I. and D. Oran, "TCP/ICN : Carrying TCP over 1248 Content Centric and Named Data Networks", 2016, 1249 . 1252 [MWC_Demo] 1253 InterDigital, "InterDigital Demo at Mobile World Congress 1254 (MWC)", 2016, . 1257 [NFD] NDN, "NFD - Named Data Networking Forwarding Daemon", 1258 2017, . 1260 [NGMN] NGMN, "NGMN 5g Initiative White Paper", 2015, 1261 . 1264 [Nguyen-1] 1265 Nguyen, T., Marchal, X., Doyen, G., Cholez, T., and R. 1266 Cogranne, "Content Poisoning in Named Data Networking: 1267 Comprehensive Characterization of real Deployment", 1268 Proceedings of the 15th IEEE/IFIP International Symposium 1269 on Integrated Network Management, 2017. 1271 [Nguyen-2] 1272 Nguyen, T., Cogranne, R., and G. Doyen, "An Optimal 1273 Statistical Test for Robust Detection against Interest 1274 Flooding Attacks in CCN", Proceedings of the 14th IEEE/ 1275 IFIP International Symposium on Integrated Network 1276 Management, 2015. 1278 [ONAP] ONAP, "Open Network Automation Platform", 2017, 1279 . 1281 [oneM2M] OneM2M, "oneM2M Service Layer Standards for M2M and IoT", 1282 2017, . 1284 [Overlay_ICN] 1285 Shailendra, S. and et al., "A Novel Overlay Architecture 1286 for Information Centric Networking", 2016, 1287 1289 . 1291 [POINT] Trossen, D. and et al., "POINT: IP Over ICN - The Better 1292 IP?", European Conference on Networks and Communications 1293 (EuCNC), , 2015. 1295 [Ravindran] 1296 Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 1297 G. Wang, "5G-ICN : Delivering ICN Services over 5G using 1298 Network Slicing", IEEE Communication Magazine, May, 2016, 1299 . 1301 [Reed] Reed, M. and et al., "Stateless Multicast Switching in 1302 Software Defined Networks", ICC 2016, Kuala Lumpur, 1303 Malaysia, 2016. 1305 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1306 Keranen, A., and P. Hallam-Baker, "Naming Things with 1307 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1308 . 1310 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1311 Application Protocol (CoAP)", RFC 7252, 1312 DOI 10.17487/RFC7252, June 2014, 1313 . 1315 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1316 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1317 Defined Networking (SDN): Layers and Architecture 1318 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1319 2015, . 1321 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1322 Chaining (SFC) Architecture", RFC 7665, 1323 DOI 10.17487/RFC7665, October 2015, 1324 . 1326 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 1327 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 1328 "Information-Centric Networking (ICN) Research 1329 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 1330 . 1332 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 1333 and G. Boggia, "Information-Centric Networking: Evaluation 1334 and Security Considerations", RFC 7945, 1335 DOI 10.17487/RFC7945, September 2016, 1336 . 1338 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1339 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 1340 the Constrained Application Protocol (CoAP)", RFC 8075, 1341 DOI 10.17487/RFC8075, February 2017, 1342 . 1344 [SAIL_NetInf] 1345 FP7, "SAIL Prototyping and Evaluation", 2013, 1346 . 1349 [Tateson] Tateson, J. and et al., "Final Evaluation Report on 1350 Deployment Incentives and Business Models", 2010, 1351 . 1354 [Techno_Economic] 1355 Trossen, D. and A. Kostopolous, "Techno-Economics Aspects 1356 of Information-Centric Networking", Journal for 1357 Information Policy, Volume 2, 2012. 1359 [UMOBILE-2] 1360 Sarros, C., Diamantopoulos, S., Rene, S., Psaras, I., 1361 Lertsinsrubtavee, A., Molina-Jimenez, C., Mendes, P., 1362 Sofia, R., Sathiaseelan, A., Pavlou, G., Crowcroft, J., 1363 and V. Tsaoussidis, "Connecting the Edges: A Universal, 1364 Mobile-Centric, and Opportunistic Communications 1365 Architecture", IEEE Communications Magazine, vol. 56, 1366 February 2018. 1368 [UMOBILE-3] 1369 Tavares, M., Aponte, O., and P. Mendes, "Named-data 1370 Emergency Network Services", Proc. of ACM MOBISYS, Munich, 1371 Germany, June 2018. 1373 [UMOBILE-4] 1374 Lopes, L., Sofia, R., Mendes, P., and W. Moreira, "Oi! - 1375 Opportunistic Data Transmission Based on Wi-Fi Direct", 1376 Proc. of IEEE INFOCOM, San Francisco, USA, April 2016. 1378 [UMOBILE-5] 1379 Dynerowicz, S. and P. Mendes, "Named-Data Networking in 1380 Opportunistic Networks", Proc. of ACM ICN, Berlin, 1381 Germany, September 2017. 1383 [UMOBILE-6] 1384 Mendes, P., Sofia, R., Tsaoussidis, V., Diamantopoulos, 1385 S., and C. Sarros, "Information-centric Routing for 1386 Opportunistic Wireless Networks", Proc. of ACM ICN, 1387 Boston, USA, September 2018. 1389 [UMOBILE-7] 1390 Sofia, R., "The UMOBILE Contextual Manager Service. 1391 Technical Report. Technical Report Senception 001, 2018 1392 (base for UMOBILE deliverable D4.5 - Report on Data 1393 Collection and Inference Models", 2018. 1395 [UMOBILE-8] 1396 Sarros, C., Lertsinsrubtavee, A., Molina-Jimenez, C., 1397 Prasopoulos, K., Diamantopoulos, S., Vardalis, D., and A. 1398 Sathiaseelan, "ICN-based edge service deployment in 1399 challenged networks", Proceedings of the 4th ACM 1400 Conference on Information-Centric Networking (ICN '17). 1401 ACM, New York, NY, USA, 2017 . 1403 [UMOBILE-9] 1404 Lertsinsrubtavee, A., Selimi, M., Sathiaseelan, A., Cerda- 1405 Alabern, L., Navarro, L., and J. Crowcroft, "Information- 1406 Centric Multi-Access Edge Computing Platform for Community 1407 Mesh Networks", Proceedings of the 1st ACM SIGCAS 1408 Conference on Computing and Sustainable Societies (COMPASS 1409 '18). ACM, New York, NY, USA, 2018 . 1411 [VSER] Ravindran, R., Liu, X., Chakraborti, A., Zhang, X., and G. 1412 Wang, "Towards software defined ICN based edge-cloud 1413 services", CloudNetworking(CloudNet), IEEE Internation 1414 Conference on, IEEE Internation Conference on 1415 CloudNetworking(CloudNet), 2013. 1417 [VSER-Mob] 1418 Azgin, A., Ravindran, R., Chakraborti, A., and G. Wang, 1419 "Seamless Mobility as a Service in Information-centric 1420 Networks", ACM ICN Sigcomm, IC5G Workshop, 2016. 1422 [White] White, G. and G. Rutz, "Content Delivery with Content 1423 Centric Networking, CableLabs White Paper", 2010, 1424 . 1428 Appendix A. Change Log 1430 [Note to RFC Editor: Please remove this section before publication.] 1432 Changes from draft-irtf-rev-03 to draft-irtf-rev-04: 1434 o Added text from Paulo Mendes and Adisorn Lertsinsrubtavee on 1435 UMOBILE Trial Experiences. 1437 o Incorporated off-line editorial comments from Hitoshi Asaeda and 1438 Anil Jangam. 1440 Changes from draft-irtf-rev-02 to draft-irtf-rev-03: 1442 o Editorial update of description and references of Doctor testbed 1443 as per comments from Guillaume Doyen. 1445 o Ran IETF spell checker tool and corrected various spelling errors. 1447 Changes from draft-irtf-rev-01 to draft-irtf-rev-02: 1449 o Updated description of Doctor testbed as per comments from 1450 Guillaume Doyen. Also referenced Doctor testbed from the Security 1451 Considerations section. 1453 o Added "Composite-ICN" configuration to cover the Hybrid ICN and 1454 similar configurations which do not clearly fit in one of the 1455 other basic configurations. 1457 o Updated description of the ICN-as-a-Slice configuration to clarify 1458 that it may also apply to non-5G systems. 1460 Changes from draft-irtf-rev-00 to draft-irtf-rev-01: 1462 o Added text from Michael Kowal describing NREN ICN Testbed. 1464 o Added text from Guillaume Doyen describing Doctor Project. 1466 o Updated text on Hybrid ICN based on input from Luca Muscariello. 1468 Changes from draft-rahman-rev-05 to draft-irtf-rev-00: 1470 o Changed draft status from individual draft-rahman-icnrg- 1471 deployment-guidelines-05 to RG adopted draft-irtf-icnrg- 1472 deployment-guidelines-00. 1474 Changes from rev-04 to rev-05: 1476 o Added this Change Log in Appendix A. 1478 o Removed references to Hybrid ICN from section 3.2 (ICN-as-an- 1479 Overlay definition). Instead, consolidated all Hybrid ICN info in 1480 the Deployment Trial Experiences under a new subsection 5.3 (Other 1481 Configurations). 1483 o Updated ICN2020 description in Section 5.1.4 with text received 1484 from Mayutan Arumaithurai and Hitoshi Asaeda. 1486 o Clarified in ICN-as-a-Slice description (section 3.4) that it may 1487 be deployed on either the Edge (RAN) or Core Network, or the ICN- 1488 as-a-Slice may be deployed end-to-end through the entire Mobile 1489 network. 1491 o Added several new references in various sections. 1493 o Various minor editorial updates. 1495 Authors' Addresses 1497 Akbar Rahman 1498 InterDigital Inc. 1499 1000 Sherbrooke Street West, 10th floor 1500 Montreal H3A 3G4 1501 Canada 1503 Email: Akbar.Rahman@InterDigital.com 1504 URI: http://www.InterDigital.com/ 1506 Dirk Trossen 1507 InterDigital Inc. 1508 64 Great Eastern Street, 1st Floor 1509 London EC2A 3QR 1510 United Kingdom 1512 Email: Dirk.Trossen@InterDigital.com 1513 URI: http://www.InterDigital.com/ 1515 Dirk Kutscher 1516 Huawei German Research Center 1517 Riesstrasse 25 1518 Munich 80992 1519 Germany 1521 Email: ietf@dkutscher.net 1522 URI: http://www.Huawei.com/ 1524 Ravi Ravindran 1525 Huawei Research Center 1526 2330 Central Expressway 1527 Santa Clara 95050 1528 USA 1530 Email: ravi.ravindran@huawei.com 1531 URI: http://www.Huawei.com/