[icnrg] FW: New Version Notification for draft-azgin-icnrg-ni-02.txt

[Ravi Ravindran <[e-mail]>]

This is the AI/NI draft we presented during the interim.

Regards,
Ravi

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, July 18, 2017 6:16 AM
To: Ravi Ravindran <[e-mail]>; Aytac Azgin <[e-mail]>; Ravi Ravindran <[e-mail]>
Subject: New Version Notification for draft-azgin-icnrg-ni-02.txt


A new version of I-D, draft-azgin-icnrg-ni-02.txt has been successfully submitted by Aytac Azgin and posted to the IETF repository.

Name:		draft-azgin-icnrg-ni
Revision:	02
Title:		Enabling Network Identifier (NI) in Information Centric Networks to Support Optimized Forwarding
Document date:	2017-07-17
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-azgin-icnrg-ni-02.txt
Status:         https://datatracker.ietf.org/doc/draft-azgin-icnrg-ni/
Htmlized:       https://tools.ietf.org/html/draft-azgin-icnrg-ni-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-azgin-icnrg-ni-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-azgin-icnrg-ni-02

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.


                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat