Page 43 - 5G Basics - Core Network Aspects

Core network aspects 1

Appendix I

ICN: naming, routing and caching
(This appendix does not form an integral part of this Recommendation.)

I.1 Naming
There are two main naming schemes in ICN literature: hierarchical naming (HN) and flat naming (FLN).
HN has a hierarchical naming structure similar to a current web uniform resource identifier (URI) in IP
networks. There are two reasons to have such a structure. One is to aggregate the names of data objects
under publisher's prefix just as network prefixes are aggregated in IP networks. The other one is to have IP
compatibility so that it can be deployed incrementally in the current IP networks. Content centric networking
[b-Jacobson] adopted this approach. FLN names a data object as a fixed-length string which is generated by
a hash function. This naming scheme can achieve persistence of data names for individual data objects.
However, due to its flatness, naming aggregation is relatively less efficient than HN. Network of Information
[b-Dannewitz] adopted this naming scheme.

Other than the naming schemes mentioned above, there is another categorical way to distinguish them:
human-readable naming (HRN) and non-human-readable naming (N-HRN). HRN enables users, to some
extent, to guess the relation between a data object and its name. Since this naming scheme is readable and
has a semantic meaning, it could be remembered and reusable once it is exposed to users. HRN is closely
related to HN above. N-HRN does not provide the name of a data object with a semantic meaning. It is difficult
to be learnt or be reusable even though it is exposed to users previously. Thus, this naming scheme requires
a name resolution process which translates the meaningless name into a semantic name, and vice versa. N-
HRN is closely related to FLN above.

I.2 Routing
ICN routes user requests based on the name of the requested data object. The routing mechanism is
composed of three steps: a name resolution step, a discovery step and a delivery step. The name resolution
step translates the name of the requested data object into its locator, e.g., IP address. The discovery step
routes user request to the data object. The last delivery step routes the requested data object to the
requester. Depending on how the above steps are combined, three routing mechanisms have been
introduced in ICN: route-by-name routing (RBNR), lookup-by-name routing (LBNR) and hybrid routing (HR).

RBNR omits the first name resolution step. The name of a data object is directly used, without being
translated into a locator, to route user request to the data object. Therefore, ICN network elements need to
hold routing information based on the names of data objects. Since the number of data objects is far more
than that of hosts, maintaining such routing information causes scalability problem. However, this approach
reduces overall latency and simplifies the routing process due to the omission of the resolution process.
Regarding the delivery step, RBNR needs another ID of either host or location to route back the requested
data object to the requester. Otherwise, an additional routing mechanism, such as bread-crumb approach: a
request leaves behind a trail of breadcrumbs along its routing path, and then response can be routed back
to the requester consuming the trail, is needed.

LBNR uses the first name resolution step to translate the name of the requested data object into its locator.
Then, the second discovery step is carried out based on the translated locator information. Since the locator
information includes IP address, the discovery step can depend on the current IP-based infrastructures. One
challenge issue of LBNR is to construct a scalable resolution system which maps the names of data objects to
their corresponding locator information. The delivery step can be implemented in the same way as IP
networks. The locator of requester is included in the request message, and then the requested data object is
delivered to the requester based on the information.
HR combines both RBNR and LBNR to benefit from their advantages. For instance, intra-domain routing
where scalability issue is not a serious problem can adopt RBNR to reduce overall latency by omitting the
resolution process. Then, inter-domain routing where scalability is a critical issue can be supported by LBNR.

33