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

4 ITU-T Focus Group IMT-2020 Deliverables

POINT iP Over IcN – the better IP

RIFE architecture for an Internet For Everybody
SDN Software Defined Networking

SDO Standard Development Organization
Snap Source Network Attachment Point

TCP Transmission Control Protocol
UDP User Datagram Protocol
URI Universal Resource Identifier

VLAN Virtual LAN
VM Virtual Machine

VSER Virtual Service Edge Router
WLDR Wireless Loss Detection and Recovery

3 Introduction

3.1 ICN Background

Information Centric Networking (ICN) is a different approach to addressing and framing data than today’s
Internet Protocol (IP) semantics. In IP, one uses a source and destination address to identify the two
endpoints of a packet. The destination is almost always a unicast address and in a small number of cases an
anycast address; the use of IP multicast is very limited. Inside the network, the payload of an IP packet is
usually an arbitrarily framed byte stream (TCP) or datagrams (UDP). TCP/IP assigns an ephemeral name to
each packet: source IP, source port, destination IP, destination port, byte offset, byte length. These names
are not reusable, nor cacheable beyond use for retransmission of lost packets. ICN’s approach is to assign a
re-usable name to each packet or small group of packets. This allows object re-use and peer-to-peer
messaging via name without needing to resolve endpoint identifiers beforehand. ICN also bundles object
authenticity with the network packets, such as via Merkel signing of a group of packets in a manifest, so
provenance stays with the objects even if cached.

There are several ICN architectures in active use today. The most widely known is Content Centric Networking
(CCNx) and its offshoot Named Data Networking (NDN). NDN forked from CCNx around 2012. While there
are several important protocol differences between NDN and CCNx, they are close enough in function that
we will only describe CCNx.
Because ICN does not require resolving endpoint identifiers before using a name, it opens new possibilities
in machine-to-machine and IoT applications. Today, IP-based applications must use specialized rendezvous
mechanisms, such as link broadcast, multicast, dynamic DNS, multicast DNS, or SIP. This is because they must
resolve an IP address for a desired name. ICN technologies remove the IP abstraction so the network can
operate at the name level. This can make the network more responsive to application demands with less
infrastructure.
Within a IMT-2020 5G RAN, ICN could serve as the object transport for intra-RAN data. For example, the state
of a Slice could be stored and transported as ICN objects, so as services move between enodeB sites its state
follows in the named ICN objects.

In the ICN technology CCNx, the name combines both a locator and identifier in to one routable hierarchical
structure. One could think of it as routing on URIs, where each name segment can be arbitrary binary data
not restricted to the URI syntax. At one end of the spectrum are pre-generated content names, such as for a
movie. A movie service could name content with a prefix like
/movie_service/superman/h264/768kbps/32kbps/English to indicate a codec and encoding rate. Names can
identify things beyond static content. A simple example would be a dynamic web service, such as

260