RFC 8763: Deployment Considerations for Information-Centric Networking (ICN)

4.1. Clean-Slate ICN

ICN has often been described as a "clean-slate" approach with the goal to renew or replace the complete IP infrastructure of the Internet. As such, existing routing hardware and ancillary services, such as existing applications that are typically tied directly to the TCP/IP stack, are not taken for granted. For instance, a Clean-slate ICN deployment would see existing IP routers being replaced by ICN-specific forwarding and routing elements, such as NFD [NFD], CCNx routers [Jacobson], or Publish-Subscribe Internet Technology (PURSUIT) forwarding nodes [IEEE_Communications].¶

While such clean-slate replacement could be seen as exclusive for ICN deployments, some ICN approaches (e.g., [POINT]) also rely on the deployment of general infrastructure upgrades, in this case, SDN switches. Different proposals have been made for various ICN approaches to enable the operation over an SDN transport [Reed] [CONET] [C_FLOW].¶

4.2. ICN-as-an-Overlay

Similar to other significant changes to the Internet routing fabric, particularly the transition from IPv4 to IPv6 or the introduction of IP multicast, this deployment configuration foresees the creation of an ICN overlay. Note that this overlay approach is sometimes, informally, also referred to as a tunneling approach. The overlay approach can be implemented directly (e.g., ICN-over-UDP), as described in [CCNx_UDP]. Alternatively, the overlay can be accomplished via ICN-in-L2-in-IP as in [IEEE_Communications], which describes a recursive layering process. Another approach used in the Network of Information (NetInf) is to define a convergence layer to map NetInf semantics to HTTP [NetInf]. Finally, [Overlay_ICN] describes an incremental approach to deploying an ICN architecture particularly well suited to SDN-based networks by also segregating ICN user- and control-plane traffic.¶

However, regardless of the flavor, the overlay approach results in islands of ICN deployments over existing IP-based infrastructure. Furthermore, these ICN islands are typically connected to each other via ICN/IP tunnels. In certain scenarios, this requires interoperability between existing IP routing protocols (e.g., OSPF, RIP, or IS-IS) and ICN-based ones. ICN-as-an-Overlay can be deployed over the IP infrastructure in either edge or core networks. This overlay approach is thus very attractive for ICN experimentation and testing, as it allows rapid and easy deployment of ICN over existing IP networks.¶

4.3. ICN-as-an-Underlay

Proposals, such as [POINT] and [White], outline the deployment option of using an ICN underlay that would integrate with existing (external) IP-based networks by deploying application-layer gateways at appropriate locations. The main reasons for such a configuration option is the introduction of ICN technology in given islands (e.g., inside a CDN or edge IoT network) to reap the benefits of native ICN, in terms of underlying multicast delivery, mobility support, fast indirection due to location independence, in-network computing, and possibly more. The underlay approach thus results in islands of native ICN deployments that are connected to the rest of the Internet through protocol conversion gateways or proxies. Routing domains are strictly separated. Outside of the ICN island, normal IP routing protocols apply. Within the ICN island, ICN-based routing schemes apply. The gateways transfer the semantic content of the messages (i.e., IP packet payload) between the two routing domains.¶

4.4. ICN-as-a-Slice

The objective of network slicing [NGMN-5G] is to multiplex a general pool of compute, storage, and bandwidth resources among multiple service networks with exclusive SLA requirements on transport and compute-level QoS and security. This is enabled through NFV and SDN technology functions that enable functional decomposition (hence, modularity, independent scalability of control, and/or the user-plane functions), agility, and service-driven programmability. Network slicing is often associated with 5G but is clearly not limited to such systems. However, from a 5G perspective, the definition of slicing includes access networks enabling dynamic slicing of the spectrum resources among various services, hence naturally extending itself to end points and cloud resources across multiple domains, to offer end-to-end guarantees. Once instantiated, these slices could include a mix of connectivity services (e.g., LTE-as-a-service), Over-the-Top (OTT) services (e.g., VoD), or other IoT services through composition of a group of virtual and/or physical network functions at the control-, user-, and service-plane levels. Such a framework can also be used to realize ICN slices with its own control and forwarding plane, over which one or more end-user services can be delivered [NGMN-Network-Slicing].¶

The 5G next generation architecture [fiveG-23501] provides the flexibility to deploy the ICN-as-a-Slice over either the edge (RAN) or mobile core network; otherwise, the ICN-as-a-Slice may be deployed end to end. Further discussions on extending the architecture presented in [fiveG-23501] and the corresponding procedures in [fiveG-23502] to support ICN has been provided in [ICN-5GC]. The document elaborates on two possible approaches to enable ICN: (1) as an edge service using the local data network (LDN) feature in 5G using User Plane Function (UPF) classification functions to fast handover to the ICN forwarder and (2) as a native deployment using the non-IP Protocol Data Unit (PDU) support that would allow new network layer PDU to be handed over to ICN UPFs collocated with the Generation NodeB (gNB) functions without invoking any IP functions. While the former deployment would still rely on 3GPP-based mobility functions, the later would allow mobility to be handled natively by ICN. However, both these deployment modes should benefit from other ICN features, such as in-network caching and computing. Associated with this ICN user-plane enablement, control-plane extensions are also proposed leveraging 5th Generation Core Network (5GC)'s interface to other application functions (AFs) to allow new network service-level programmability. Such a generalized network slicing framework should be able to offer service slices over both IP and ICN. Coupled with the view of ICN functions as being "service function chaining" [RFC7665], an ICN deployment within such a slice could also be realized within the emerging control plane that is targeted for adoption in future (e.g., 5G mobile) network deployments. Finally, it should be noted that ICN is not creating the network slice but instead that the slice is created to run a 5G-ICN instance [Ravindran].¶

At the level of the specific technologies involved, such as ONAP [ONAP] (which can be used to orchestrate slices), the 5G-ICN slice requires compatibility, for instance, at the level of the forwarding/data plane depending on if it is realized as an overlay or using programmable data planes. With SDN emerging for new network deployments, some ICN approaches will need to integrate as a data-plane forwarding function with SDN, as briefly discussed in Section 4.1. Further cross-domain ICN slices can also be realized using frameworks, such as [ONAP].¶

4.5. Composite-ICN Approach

Some deployments do not clearly correspond to any of the previously defined basic configurations of (1) Clean-slate ICN, (2) ICN-as-an-Overlay, (3) ICN-as-an-Underlay, and (4) ICN-as-a-Slice. Or, a deployment may contain a composite mixture of the properties of these basic configurations. For example, the Hybrid ICN [H-ICN_1] approach carries ICN names in existing IPv6 headers and does not have distinct gateways or tunnels connecting ICN islands or any other distinct feature identified in the previous basic configurations. So we categorize Hybrid ICN and other approaches that do not clearly correspond to one of the other basic configurations as a Composite-ICN approach.¶

5.1. Application and Service Migration

The Internet supports a multitude of applications and services using the many protocols defined over the packet-level IP service. HTTP provides one convergence point for these services with many web development frameworks based on the semantics provided by it. In recent years, even services such as video delivery have been migrating from the traditional RTP-over-UDP delivery to the various HTTP-level streaming solutions, such as DASH [DASH] and others. Nonetheless, many non-HTTP services exist, all of which need consideration when migrating from the IP-based Internet to an ICN-based one.¶

The underlay deployment configuration option presented in Section 4.3 aims at providing some level of compatibility to the existing ecosystem through a proxy-based message flow mapping mechanism (e.g., mapping of existing HTTP/TCP/IP message flows to HTTP/ICN message flows). A related approach of mapping TCP/IP to TCP/ICN message flows is described in [Moiseenko]. Another approach described in [Marchal] uses HTTP/NDN gateways and focuses, in particular, on the right strategy to map HTTP to NDN to guarantee a high level of compatibility with HTTP while enabling an efficient caching of data in the ICN island. The choice of approach is a design decision based on how to configure the protocol stack. For example, the approach described in [Moiseenko] carries the TCP layer into the ICN underlay, while the [Marchal] approach terminates both HTTP and TCP at the edge of the ICN underlay and maps these functionalities onto existing ICN functionalities.¶

Alternatively, ICN-as-an-Overlay (Section 4.2) and ICN-as-a-Slice (Section 4.4) allow for the introduction of the full capabilities of ICN through new application/service interfaces, as well as operations in the network. With that, these approaches of deployment are likely to aim at introducing new application/services capitalizing on those ICN capabilities, such as in-network multicast and/or caching.¶

Finally, [ICN-LTE-4G] outlines a dual-stack end-user device approach that is applicable for all deployment configurations. Specifically, it introduces middleware layers (called the TCL) in the device that will dynamically adapt existing applications to either an underlying ICN protocol stack or standard IP protocol stack. This involves end device signaling with the network to determine which protocol stack instance and associated middleware adaptation layers to utilize for a given application transaction.¶

5.2. Content Delivery Network Migration

A significant number of services and applications are devoted to content delivery in some form, e.g., as video delivery, social media platforms, and many others. CDNs are deployed to assist these services through localizing the content requests and therefore reducing latency and possibly increasing utilization of available bandwidth, as well as reducing the load on origin servers. Similar to the previous subsection, the underlay deployment configuration presented in Section 4.3 aims at providing a migration path for existing CDNs. This is also highlighted in a BIER use-case document [BIER], specifically with potential benefits in terms of utilizing multicast in the delivery of content but also reducing load on origin and delegation servers. We return to this benefit in the trial experiences in Section 6.¶

5.3. Edge Network Migration

Edge networks often see the deployment of novel network-level technology, e.g., in the space of IoT. For many years, such IoT deployments have relied, and often still do, on proprietary protocols for reasons, such as increased efficiency, lack of standardization incentives, and others. Utilizing the underlay deployment configuration in Section 4.3.1, application gateways/proxies can integrate such edge deployments into IP-based services, e.g., utilizing CoAP-based [RFC7252] M2M platforms, such as oneM2M [oneM2M] or others.¶

Another area of increased edge network innovation is that of mobile (access) networks, particularly in the context of the 5G mobile networks. Network softwarization (using technologies like service orchestration frameworks leveraging NFV and SDN concepts) are now common in access networks and other network segments. Therefore, the ICN-as-a-Slice deployment configuration in Section 4.4 provides a suitable migration path for the integration of non-IP-based edge networks into the overall system by virtue of realizing the relevant (ICN) protocols in an access network slice.¶

With the advent of SDN and NFV capabilities, so-called campus or site-specific deployments could see the introduction of ICN islands at the edge for scenarios such as gaming or deployments based on Augmented Reality (AR) / Virtual Reality (VR), e.g., smart cities or theme parks.¶

5.4. Core Network Migration

Migrating core networks of the Internet or mobile networks requires not only significant infrastructure renewal but also the fulfillment of the key performance requirements, particularly in terms of throughput. For those parts of the core network that would migrate to an SDN-based optical transport, the ICN-as-a-Slice deployment configuration in Section 4.4 would allow the introduction of native ICN solutions within slices. This would allow for isolating the ICN traffic while addressing the specific ICN performance benefits (such as in-network multicast or caching) and constraints (such as the need for specific network elements within such isolated slices). For ICN solutions that natively work on top of SDN, the underlay deployment configuration in Section 4.3.2 provides an additional migration path, preserving the IP-based services and applications at the edge of the network while realizing the core network routing through an ICN solution (possibly itself realized in a slice of the SDN transport network).¶

6.1. ICN-as-an-Overlay

6.2. ICN-as-an-Underlay

6.3. Composite-ICN Approach

Hybrid ICN [H-ICN_1] [H-ICN_2] is an approach where the ICN names are mapped to IPv6 addresses and other ICN information is carried as payload inside the IP packet. This allows standard (ICN-unaware) IP routers to forward packets based on IPv6 info but enables ICN-aware routers to apply ICN semantics. The intent is to enable rapid hybrid deployments and seamless interconnection of IP and Hybrid ICN domains. Hybrid ICN uses [CICN] open-source software. Initial tests have been done with 150 clients consuming DASH videos, which showed good scalability properties at the server side using the Hybrid ICN transport [H-ICN_3] [H-ICN_2].¶

6.4. Summary of Deployment Trials

In summary, there have been significant trials over the years with all the major ICN protocol flavors (e.g., CCNx, NDN, and POINT) using both the ICN-as-an-Overlay and ICN-as-an-Underlay deployment configurations. The major limitations of the trials include the fact that only a limited number of applications have been tested. However, the tested applications include both native ICN and existing IP-based applications (e.g., videoconferencing and IPTV). Another limitation of the trials is that all of them involve less than 1k users.¶

Huawei and China Unicom have just started trials of the ICN-as-a-Slice configuration to demonstrate ICN features of security, mobility, and bandwidth efficiency over a wired infrastructure using videoconferencing as the application scenario [Chakraborti]; also, this prototype has been extended to demonstrate this over a 5G-NR access.¶

The Clean-slate ICN approach has obviously never been in trials, as complete replacement of Internet infrastructure (e.g., existing applications, TCP/IP protocol stack, IP routers, etc.) is no longer considered a viable alternative.¶

Finally, Hybrid ICN is a Composite-ICN approach that offers an interesting alternative, as it allows ICN semantics to be embedded in standard IPv6 packets so the packets can be routed through either IP routers or Hybrid ICN routers. Note that some other trials, such as the DOCTOR testbed (Section 6.2.6), could also be characterized as a Composite-ICN approach, because it contains both ICN gateways (as in ICN-as-an-Underlay) and virtualized infrastructure (as in ICN-as-a-Slice). However, for the DOCTOR testbed, we have chosen to characterize it as an ICN-as-an-Underlay configuration because that is a dominant characteristic.¶

7.1. Protocols for Application and Service Migration

End-user applications and services need a standardized approach to trigger ICN transactions. For example, in Internet and web applications today, there are established socket APIs, communication paradigms (such as REST), common libraries, and best practices. We see a need to study application requirements in an ICN environment further and, at the same time, develop new APIs and best practices that can take advantage of ICN communication characteristics.¶

7.2. Protocols for Content Delivery Network Migration

A key issue in CDNs is to quickly find a location of a copy of the object requested by an end user. In ICN, a Named Data Object (NDO) is typically defined by its name. [RFC6920] defines a mechanism that is suitable for static naming of ICN data objects. Other ways of encoding and representing ICN names have been described in [RFC8609] and [RFC8569]. Naming dynamically generated data requires different approaches(e.g., hash-digest-based names would normally not work), and there is a lack of established conventions and standards.¶

Another CDN issue for ICN is related to multicast distribution of content. Existing CDNs have started using multicast mechanisms for certain cases, such as for broadcasting streaming TV. However, as discussed in Section 6.2.1, certain ICN approaches provide substantial improvements over IP multicast, such as the implicit support for multicast retrieval of content in all ICN flavors.¶

Caching is an implicit feature in many ICN architectures that can improve performance and availability in several scenarios. The ICN in-network caching can augment managed CDN and improve its performance. The details of the interplay between ICN caching and managed CDN need further consideration.¶

7.3. Protocols for Edge and Core Network Migration

ICN provides the potential to redesign current edge and core network computing approaches. Leveraging ICN's inherent security and its ability to make name data and dynamic computation results available independent of location can enable a lightweight insertion of traffic into the network without relying on redirection of DNS requests. For this, proxies that translate from commonly used protocols in the general Internet to ICN message exchanges in the ICN domain could be used for the migration of application and services within deployments at the network edge but also in core networks. This is similar to existing approaches for IoT scenarios where a proxy translates CoAP request/responses to other message formats. For example, [RFC8075] specifies proxy mapping between CoAP and HTTP protocols. Also, [RFC8613] is an example of how to pass end-to-end encrypted content between HTTP and CoAP by an application-layer security mechanism. Further work is required to identify if an approach like [RFC8613], or some other approach, is suitable to preserve ICN message security through future protocol translation functions of gateways/proxies.¶

Interaction and interoperability between existing IP routing protocols (e.g., OSPF, RIP, or IS-IS) and ICN routing approaches (e.g., NFD and CCNx routers) are expected, especially in the overlay approach. Another important topic is the integration of ICN into networks that support virtualized infrastructure in the form of NFV/SDN and most likely utilize SFC as a key protocol. Further work is required to validate this idea and document best practices.¶

There are several existing approaches to supporting QoS in IP networks, including Diffserv, IntServ, and RSVP. Some initial ideas for QoS support in ICN networks are outlined in [FLOW-CLASS], which proposes an approach based on flow classification to enable functions, such ICN rate control and cache control. Also, [ICN-QoS] proposes how to use Diffserv Differentiated Services Code Point (DSCP) codes to support QoS for ICN-based data path delivery. Further work is required to identify the best approaches for support of QoS in ICN networks.¶

OAM is a crucial area that has not yet been fully addressed by the ICN research community but which is obviously critical for future deployments of ICN. Potential areas that need investigation include whether the YANG data modeling approach and associated NETCONF/RESTCONF protocols need any specific updates for ICN support. Another open area is how to measure and benchmark performance of ICN networks comparable to the sophisticated techniques that exist for standard IP networks, virtualized networks, and data centers. It should be noted that some initial progress has been made in the area of ICN network path traceroute facility with approaches, such as CCNxinfo [CNNinfo] [Contrace].¶

7.4. Summary of ICN Protocol Gaps and Potential Protocol Efforts

Without claiming completeness, Table 1 maps the open ICN issues identified in this document to potential protocol efforts that could address some aspects of the gap.¶