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