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

From: Ravi Ravindran <[email-masked]>
Date: Tue, 18 Jul 2017 04:32:14 +0000

Also the associated forwarding label draft, changes to this have been minor which I briefly touched upon during the interim.

Regards,
Ravi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2017 6:16 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-01.txt

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

Name:		draft-ravi-icnrg-ccn-forwarding-label
Revision:	01
Title:		Forwarding-Label support in CCN Protocol
Document date:	2017-07-17
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.org/internet-drafts/draft-ravi-icnrg-ccn-forwarding-label-01.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-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ravi-icnrg-ccn-forwarding-label-01

Abstract:
   The objective of this proposal is to enable ID and Locator namespace
   split in the CCN protocol that has several applications such as
   towards Interest routing optimization, seamless mobility and
   providing mobility as a service, conversational session support,
   handling indirections in manifests, and routing scalability.  We
   enable this through the notion of a 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, a router or a
   host.  FLO can be inserted within the Interest message by the
   applications or by the network.  FLO can be interpreted by the
   network in multiple ways, for instance, to terminate the message or
   to swap it with a new FLO based on the service context.  Furthermore,
   depending on the application and trust context, FLO can be subjected
   to policy based actions by the forwarders, such as invoking security
   verification or enabling other service-centric 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