Enabling Network Identifier (NI) in Information Centric Networks to Support Optimized Forwarding

Document Type Active Internet-Draft (individual)
Last updated 2017-07-17
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
ICN Research Group                                              A. Azgin
Internet-Draft                                              R. Ravindran
Intended status: Informational                       Huawei Technologies
Expires: January 18, 2018                                  July 17, 2017

  Enabling Network Identifier (NI) in Information Centric Networks to
                      Support Optimized Forwarding


   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.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Azgin & Ravindran       Expires January 18, 2018                [Page 1]
Internet-Draft                   ICN-NI                        July 2017

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 18, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Application Identifier (AI) vs. Network Identifier (NI) in
       ICN . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  NI based ICN Forwarding . . . . . . . . . . . . . . . . . . .   7
     3.1.  Label based ICN forwarding  . . . . . . . . . . . . . . .   8
     3.2.  Link-object based ICN forwarding  . . . . . . . . . . . .   9
     3.3.  Link Object vs. Forwarding Label  . . . . . . . . . . . .  10
   4.  Name Resolution System Considerations . . . . . . . . . . . .  12
Show full document text