Subject: [icnrg] FW: New Version Notification for draft-ravi-icnrg-ccn-forwarding-label-02.txt

From: Ravi Ravindran <[email-masked]>
Date: Tue, 6 Mar 2018 16:03:24 +0000

Hi All,

This is the revised version of the forwarding label draft. The revisions include :

1. Aligning the terminology with AI/NI as used in our https://tools.ietf.org/html/draft-azgin-icnrg-ni-02

2. Inclusion of another use case of forwarding label towards handling seamless consumer mobility.

Regards,
Ravi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 05, 2018 11:10 AM
To: Asit Chakraborti <[email-masked]>; Ravi Ravindran <[email-masked]>; Aytac Azgin <[email-masked]>; Ravi Ravindran <[email-masked]>
Subject: New Version Notification for draft-ravi-icnrg-ccn-forwarding-label-02.txt

A new version of I-D, draft-ravi-icnrg-ccn-forwarding-label-02.txt
has been successfully submitted by Ravishankar Ravindran and posted to the IETF repository.

Name:		draft-ravi-icnrg-ccn-forwarding-label
Revision:	02
Title:		Forwarding Label support in CCN Protocol
Document date:	2018-03-05
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-ravi-icnrg-ccn-forwarding-label-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ravi-icnrg-ccn-forwarding-label/
Htmlized:       https://tools.ietf.org/html/draft-ravi-icnrg-ccn-forwarding-label-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ravi-icnrg-ccn-forwarding-label-02

Abstract:
   The objective of this proposal is to enable application identifier
   (AI) and network identifier (NI) split in the CCN protocol that has
   several applications such as towards Interest routing optimization,
   mobility, conversational session support, handling indirections in
   manifests, and routing scalability.  We enable this through the
   notion of forwarding label object (FLO), which is an optional hop-by-
   hop payload in the Interest message with a topological name which
   identifies a network domain, router or a host.  FLO can be inserted
   by the end user applications or by the network.  FLO is processed by
   the network resulting in either terminating it or swapping it with a
   new FLO based on the network service context.  Furthermore, depending
   on the application and trust context, a FLO can be subjected to
   policy based actions by the forwarders such as invoking security
   verification or enabling other FLO management actions.

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