Enabling Network Identifier (NI) in Information Centric Networks to Support Optimized Forwarding
draft-azgin-icnrg-ni-02

Document Type Expired Internet-Draft (individual)
Last updated 2018-04-19 (latest revision 2017-07-17)
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-azgin-icnrg-ni-02.txt

Abstract

The objective of this proposal is to introduce the notion of network identifier (NI) in the ICN architecture. This is in addition to the existing names (i.e., content identifiers, CIs, or application identifiers, AIs, in general) that are currently used for both naming and routing/forwarding purposes. Network identifiers are needed considering the requirements on future networking architectures such as: (i) to support persistent names (or persistently named objects) and large-scale and high-speed mobility of any network entity (i.e, devices, services, and content), (ii) to accommodate different types of Internet of Things (IoT) services, many of which require low- latency performance, and enabling edge computing to support service virtualization, which will require support for large scale migration and replication of named resources, and (iii) to scale the ICN architecture to future Internet scale considering the exponentially increasing named entities. If information on AI-to-NI mappings are not directly accessible to the consumers, for instance, using specific datasets like manifests, these considerations may require enabling a name resolution service, which can be network based or application driven, to support efficient and scalable routing. Current document do not impose any restrictions on the name resolution architecture, regarding its scope. In the current draft, we begin by highlighting the issues associated with ICN networking when utilizing only the AIs, which include persistently named content, services, and devices. Next we discuss the function NI serves, and provide a discussion on the two current NI-based proposals, along with their scope and functionalities. This is with the objective of having a single NI construct for ICN that is flexible enough to adapt to different networking contexts.

Authors

Aytac Azgin (aytac.azgin@huawei.com)
Ravi Ravindran (ravi.ravindran@huawei.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)