Page 274 - ITU-T Focus Group IMT-2020 Deliverables

4 ITU-T Focus Group IMT-2020 Deliverables

roam in a single domain. Here ID binds to applications and Locators binds to the ICN network entities. In
addition, ID/Locator name space split in ICN also enables features such as multi-homing of not only end
devices but also the ability to host content and services anywhere in the ICN network to meet application
requirements. In addition to the mobility benefit, this demo also addresses the question of enabling ICN in a
5G environment as a slice over a generic infrastructure pool and the ability to orchestrate ICN services over
well known compute and network virtualization platforms, i.e. OpenStack and ONOS.

6.2 Towards ICN Standardization
We try to address the following standardization gaps identified in Phase-1 of the focus group output
document (ITU 2015) towards the use of ICN in IMT-2020 networks:

6.2.1 Gap E.1 ICN as a protocol for IMT-2020 Network:
This gap deals with the deployment of ICN. This PoC shows the feasibility of an overlay deployment over IP
over a generic infrastructure. We demonstrate this by realizing a video conferencing service over a generic
infrastructure over which other ICN services can also be realized. The ICN transport is based on Virtual Service
Edge Router (VSER) platform (Chakraborti and al. 2015) (Ravindran, et al. 2013) running over COTS hardware.
It runs CCN as host processes, managed in a centralized manner using application-driven ICN Service and
Network Controller. Towards network slicing, and dynamic realization of network functions, these host
processes can also be virtualized using Container or Virtual Machines. From a deployment perspective, VSER
is an ideal platform for edge deployment such as for the central office that can take advantage of most of the
features offered by ICN, which include mobility, multi-homing, multicasting and in-network computing
depending on the points of ICN enablement in the service delivery chain. Feasibility of handling mobility over
ICN is also considering the use of edge cloud resources to realize eNodeB functions, collocated with the
CloudRAN implementation. This allows ICN to interface with heterogeneous RAT stacks such as LTE or Wifi.
6.2.2 Gap E.8: ICN Mobility and Routing

Another challenge raised was the support for ICN mobility and routing scalability. This is also important
considering that IMT-2020 mobility requirements (NGMN 2015) has more demanding requirements for
mobility such as to support for in-session user experience even at 1000km/h. Current mobility support in
architectures like LTE is supported over tunnels terminating at specialized gateway functions in the network.
This increases network cost, complexity and flexibility of network deployment and its management. ICN
addresses the basic architectural issue in IP by allowing applications to bind to names, where ICN manages
its resolution to a location in the network either through in-network routing or through the use of a name
resolution system. With ICN, IP is a transport over which ICN PDUs are exchanged. Towards mobility, this
prototype takes advantage of ID/Locator split that ICN naturally supports to offer flexibility to the mobile
entities to move between administrative domains and also handling in-session mobility when they roam in a
single domain. This removes the need for gateways or anchor nodes in the network. The demo is developed
in the context of ICN/CCN. The demo shows seamless mobility of an end user generating live video being
consumed by one or more participants with session interruption of ~100ms after each handover. Centralized
orchestration applying SDN/NFV principles in ICN provides resource and topology abstraction to applications
to inter-connect service resources to the user requests in an efficient manner exploiting compute, storage
and connectivity resources of an ICN transport. Specifically, scalability of centralized routing within a domain
is addressed by conducting routing in the domain using locators and limiting name to locator binding only to
the edges of the network, departing from the standard SDN method of setting per-flow rules at every hop.
Further the caching of the name to locator binding in the network edge reduces the need to resolve popular
Interest flow in a centralized manner.
6.2.3 Gap E. 12: Operations and management (SDN/NFV)

SDN and NFV based ICN transport is very powerful as it achieves the objectives of realizing application driven
networking. SDN virtualizes ICN resources i.e. ICN router’s connectivity, compute, cache resources to
applications to request, expand or shrink resources dedicated to it on the ICN forwarders. NFV allows the
management of the service functions in the forwarders, while interacting with the SDN controller on its
status. Through this prototype, we demonstrate the use of centralized programmability of the CCN transport

268