ICN Research Group                                          R. Ravindran
Internet-Draft                                            A. Chakraborti
Intended status: Informational                                  A. Azgin
Expires: January 18, 2018                            Huawei Technologies
                                                           July 17, 2017

                Forwarding-Label support in CCN Protocol


   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

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.

Ravindran, et al.       Expires January 18, 2018                [Page 1]

Internet-Draft       Forwarding-label support in CCN           July 2017

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.  ID-Locator Namespace Split in CCN . . . . . . . . . . . . . .   2
   2.  Forwarding-Label Object Proposal  . . . . . . . . . . . . . .   5
     2.1.  FLO Naming  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  FLO Insertion . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  FLO Swapping  . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  FLO Termination . . . . . . . . . . . . . . . . . . . . .   6
   3.  FLO Message Format  . . . . . . . . . . . . . . . . . . . . .   6
   4.  FLO Processing Rules  . . . . . . . . . . . . . . . . . . . .   7
   5.  Implications on PIT Processing  . . . . . . . . . . . . . . .   8
   6.  Implications on Caching . . . . . . . . . . . . . . . . . . .   8
   7.  Multiple Domain Scenario  . . . . . . . . . . . . . . . . . .   9
   8.  FLO Security  . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Use Case Scenarios  . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Handling Producer Mobility  . . . . . . . . . . . . . . .  10
     9.2.  Manifests . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.3.  Support for Conversational Sessions . . . . . . . . . . .  13
     9.4.  Interest Routing Optimization . . . . . . . . . . . . . .  13
     9.5.  Routing Scalability . . . . . . . . . . . . . . . . . . .  13
   10. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  ID-Locator Namespace Split in CCN

   In the context of ICN/CCN, we define Identifier and Locator as

   o  Identifier (ID) is a persistent secure or non-secure flat-ID or a
      hierarchical name assigned to a content, device or service.  If
      the ID is secure, then there is a direct relationship between the
      ID and the key of the principal.  Otherwise, a binding is provided
      by a third party using the certificate mechanism or the web-of-

Ravindran, et al.       Expires January 18, 2018                [Page 2]

Internet-Draft       Forwarding-label support in CCN           July 2017

      trust model.  Generally the identifier space is managed by
      services and applications.

   o  Locator ID (LID), on the other hand, is a topological name
      assigned to a network entity, which can be a network/domain, a
      router, a host or an interface.  Generally, locator space is
      assigned and managed by the network administrators.  Within the
      context of this document, Locator and Locator ID carry the same
      meaning and refer to a topological identifier.

   We discuss here the motivations behind the need for separating the
   persistent name (ID) and the locator ID (LID) in the Interest message
   within the context of CCN, and present a proposal to achieve this.

   The advantages of ID/Locator split have been extensively studied in
   the literature and it has been part of many host-centric protocols
   such as HIP [6], ILNP [7], and LISP [8].  However, in this document,
   we refer to these terms within the context of Information-centric
   networks, where the network layer uses name(s) to resolve a requested
   content (or service or host) to a given location, while providing
   mechanisms to cache or apply computation on the named (data) objects
   depending on the context (such as the requirements indicated within
   the Interest message).

   Within this ID/Locator split context, ICN architectures such as
   MobilityFirst [23], NetInf [12] assume an explicit representation for
   Identifiers and Locators within their architectures, considering
   their use of non-aggregate-able flat IDs; while the CCN/NDN
   architecture assumes the aggregate-ability of names within its
   architecture, thereby applying its use on routing and forwarding.  We
   have argued in [1], the problems associated with the use of name
   prefixes for routing, which include the challenges related to
   scalability, loss of name aggregate-ability when data and services
   are replicated, handling of mobility, and situations where
   conversational sessions are required for service level authentication
   and authorization [2].  These issues have also been argued
   quantitatively in [14], including the scenario, where there is an
   explosion in the namespace when there are many different ways of
   naming an entity because of the rich context associated with it.
   Therefore, providing the ID-LID separation distinctly in the protocol
   offers the following advantages, which are also discussed in detail
   in [1]:

   o  CCN applications request persistent IDs for contents, services or
      hosts; while their resolution is handled through per-hop name-
      based routing by a CCN forwarder using unicast, anycast, or
      broadcast mechanisms, routing scalability is handled using name
      prefixes.  This model can introduce problems when the named entity

Ravindran, et al.       Expires January 18, 2018                [Page 3]

Internet-Draft       Forwarding-label support in CCN           July 2017

      is mobile, migrated, or replicated; as the names have to be
      announced in the routing control plane, which can in turn
      introduce routing convergence issues and scalability challenges.
      Introducing an ID/Locator namespace split within the architecture,
      which uses a name resolution service, shall address the routing
      challenges due to dynamic entities, while also improving the
      routing scalability (due to limiting the state in the core
      Internet routers to the set of topological names).

   o  ID and Locator namespaces are managed by different entities.  IDs
      are managed by applications and services, hence are relevant in
      the service layer; while Locators are assigned to the networked
      entity, hence are managed by network administrators.  Locators map
      to network domains or specific network elements, through which the
      named entity is locally/globally reachable.  The relationship
      between IDs and Locators is established during namespace
      registration (or namespace publishing) phase, and managed by a
      separate name resolution service.  The distinction between ID and
      Locator in CCN allows an application to manage its own namespace
      and to not be restricted by the naming rules imposed by the

   o  Allowing the representation of IDs and Locators within an Interest
      message offers many advantages in CCN, especially when a
      centralized control is applied, such as using a service
      orchestration framework [13].  This enables efficiency and
      flexibility through service-centric name resolution, routing, and
      mobility, service chaining [4] and routing scalability.

   Considering the above requirements, we propose a Forwarding-label
   object (FLO), which includes a locator along with the encapsulated
   security bindings; and provides the flexibility to forward Interests
   on a name other than the one provided within the original Interest
   message, with the ability to terminate or swap it in the network
   during forwarding.  Note that, to effectively handle the ID/Locator
   mapping, we require a control plane infrastructure and appropriate
   network layer security functions to prevent malicious usage.
   Specific control plane or security mechanisms to support secure ID/
   Locator mapping is out of the scope of this document, as many
   techniques can be used towards achieving this objective.  This draft
   specifically presents various considerations towards the management
   of FLOs, such as: (i) FLO insertion/modification/deletion, (ii)
   processing of FLO by a CCN forwarder, (iii) PIT/CS implications for
   Interests carrying FLOs, (iv) packet format for the FLO Interest, and
   (v) security/trust considerations.  We also provide a discussion on
   the various application scenarios for the use of FLOs.

Ravindran, et al.       Expires January 18, 2018                [Page 4]

Internet-Draft       Forwarding-label support in CCN           July 2017

2.  Forwarding-Label Object Proposal

   In the following, we discuss various aspects to FLO in regards to its
   semantics and management.

2.1.  FLO Naming

   We assume the FLO to consist of three components: LID, service
   specific metadata, and security attributes for authentication.  LIDs
   are hierarchically structured topological names, where the names
   follow the format defined in [3].  Security attributes are optional,
   and may include validation payload and algorithm as discussed in [3].

2.2.  FLO Insertion

   Insertion of FLOs within an Interest message can be done either by
   the application that requests the named entity or by the network
   routers that forward the Interest messages.

   In some specific scenarios, application logic may use --within the
   Interest message-- both an FLO and an ID.  Such action may also be
   triggered by a feedback from the network, for instance, due to a
   routing failure of an Interest using solely IDs, as explained in
   [15].  In such situations, forwarders, which process the traffic
   generated by applications outside their trust domain, would require a
   way to validate the FLOs.  One possible approach to ensure trust in
   such situations is discussed in [15], where a trust binding is
   provided between an ID and a LID as a link object, which can be
   validated by the forwarder.  To avoid the possibility of an FLO
   misuse, a default policy for the network may be to ignore the
   inserted FLOs from untrusted applications and to choose to route only
   by the content IDs.  Another possible policy to implement in this
   case is for the network to insert FLOs, which is explained next.

   Another possibility would be to insert the FLOs by the network, for
   which the FLO insertion would be triggered at the ingress (or
   service) routers of the network domain.  Network-insertion of an FLO
   to an incoming Interest message may be triggered based on several
   considerations, including: (i) the interface, over which the Interest
   message is received; (ii) whether the Interest message satisfies the
   flow service profiles that are imposed by the network administrator
   at the ingress routers; (iii) the default behavior by the network, if
   it chooses to route only on LIDs.  Accordingly, service profile
   matching actions may include matching an Interest name to a set of
   service prefixes that are triggered by certain markings or metadata
   carried within the Interest message, such as the context-IDs.  Here,
   context IDs may refer to service, network, trust, or location related

Ravindran, et al.       Expires January 18, 2018                [Page 5]

Internet-Draft       Forwarding-label support in CCN           July 2017

   metrics or information.  Note that, a FLO that is inserted within the
   trust domain may not require security validation.

2.3.  FLO Swapping

   An FLO can be swapped by another FLO within the network, in the
   context of a given service, at the designated network points, which
   typically include the service edge routers of the network.

   Future considerations also include the case, where FLOs are
   potentially stacked based on the semantics of the current FLO.

2.4.  FLO Termination

   FLOs are terminated by a forwarder, when the LID carried within
   matches the forwarder's own LID.  Here we assume a forwarder to
   possibly have multiple LIDs that correspond to domain-IDs, router-IDs
   or Interface-IDs.  For example, a forwarder (in a domain) identified
   as /company/geoloc can process an FLO, for which the LID is set to
   this router's domain name or to a forwarder ID such as
   /company/geoloc/PoP*. Whenever an FLO is terminated by the forwarder,
   it can attach a new FLO depending on the service context, or conduct
   additional processing (such as re-resolution of the ID to a new FLO)
   based on the Interest parameters (and again depending on the service
   context).  An FLO can also include optional policy metadata, based on
   which FLOs can be swapped in the network.

3.  FLO Message Format

   As the FLOs are swappable in the network, FLO is proposed as an hop-
   by-hop field within the optional body of the fixed header as shown in
   Figure 1.  The optional FLO includes an attribute of type FL-Object,
   which contains a name TLV identifying the LID (Figure 2).  LID (or
   FLO-LID), here, is a hierarchically structured variable length name
   as defined in [5].  In addition to the LID, the optional FLO metadata
   includes contextual information for the application or the service to
   aid the network in invoking an appropriate FLO processing, such as
   trust validation for the FLO.  Optional security attributes, such as
   the authentication information, can be included depending on the
   specific use case scenarios, which may include secure name delegation
   information as discussed in [15], or the signature of the consumer.

Ravindran, et al.       Expires January 18, 2018                [Page 6]

Internet-Draft       Forwarding-label support in CCN           July 2017

     |                   CCN Fixed Header                          |
     |              <Optional Hop-by-Hop TLVs>                     |
     /                                                             /
     |         Type = FL-Object    |      Length                   |
     |                        LID TLV                              |
     /                      Optional FLO Metadata                  /
     /               Optional FLO Security Attributes              /
     /                       Interest Message Body                 /

   Figure 1: Interest message with hop-by-hop Optional Forwarding-Label TLV

    | Forwarding-Label     |     Meaning      |      Value      |
    | LID TLV              | Identifies an    |    Name TLV     |
    |                      | AS-ID/Gateway-ID/|                 |
    |                      | Host-ID/Interface|                 |
    |                      | -ID              |                 |

                   Figure 2: Locator-ID (LID) Definition

4.  FLO Processing Rules

   The following discussion is based on the assumption that all
   forwarders must process the optional header fields.  Within the
   context of CCN packet processing, FLO is only relevant when the
   decision to forward the Interest message is to be made.  In this
   draft, the default policy to be applied by all the CCN routers is to
   route on FLOs, if an FLO exists in the Interest message.  Based on
   this policy, the following considerations may apply:

   o  When an Interest message with an FLO arrives at a CCN router, if
      the FLO is trusted and the lookup based on LID succeeds, the
      router first checks if the LID matches any of the network names
      associated with the receiving router.  If there is match, received
      Interest is treated as one that terminates flow, in which case, a

Ravindran, et al.       Expires January 18, 2018                [Page 7]

Internet-Draft       Forwarding-label support in CCN           July 2017

      name based lookup is conducted.  The lookup at the router may
      return another FLO, or may result in a forwarding face for the
      Interest message towards the next hop.  If there is no match,
      which suggests a non-terminating flow case, the FIB lookup on LID
      would result in a next hop towards which the Interest needs to be

   o  If the lookup based on LID fails, then the router can try to
      forward the Interest based on the Interest ID.  In the case, where
      routing based on the Interest ID fails, then the router can raise
      an error condition and feedback the error message to the previous
      hop with the appropriate error code.

   o  FLO-validation depends on the trust context, which is indicated by
      the information inserted by the ingress domain router within the
      FLO.  In trusted forwarding scenarios, where the applications and
      the network are managed by the same authority, the ingress and the
      core routers can bypass the FLO validation.  In untrusted
      forwarding scenarios, the edge router may only validate the FLO
      that is inserted by the sender and avoid re-validations by the
      successive forwarders.

5.  Implications on PIT Processing

   As FLO is considered as a routing directive, its presence shouldn't
   affect the functionality of the PIT and its processing under normal
   situations.  However, including FLO within the Interest message could
   give rise to new questions, which need to be addressed, based on
   application or network requirements.  One such scenario is when there
   is an implicit binding between the ID and the LID (i.e., multiple
   Interests arrive at a router carrying the same ID but with different
   LIDs).  One possible approach to handle such case is to treat each
   such combination of (ID,LID) differently, thereby saving them both in
   the PIT as separate entries.  However, this also requires the content
   object to piggyback the LID to ensure proper matching with the stored
   PIT entry.  In the case, when the FLO is swapped by the intermediate
   routers, the PIT should save both the incoming and the outgoing FLOs,
   and also the content object should be updated with the appropriate
   FLO to ensure matching of the stored PIT entries along the previous
   hops.  These considerations are similar to those elaborated in [21].

6.  Implications on Caching

   Caching function shouldn't be affected by this draft proposal.  Even
   if the FLOs are included in the content object as discussed earlier,
   routers are expected to remove it before caching the content.

Ravindran, et al.       Expires January 18, 2018                [Page 8]

Internet-Draft       Forwarding-label support in CCN           July 2017

7.  Multiple Domain Scenario

   In wide area networking scenarios, Interest message can cross
   multiple domains.  If an FLO is only trusted within the domain
   boundaries, then the FLO is removed before the Interest message is
   forwarded to the next domain, which then, upon entry, inserts a new
   FLO with the associated security attributes at the ingress of the
   next domain.  However, in the case when there exists trust between
   the domains, such as one through a trusted third party (validated
   based on the FLO security bindings), to use the FLO inserted by the
   previous domain, the intermediate domains can avoid further FLO
   processing and use the FLO passed on by the previous domains.

8.  FLO Security

   FLO security is related to the purpose it is used for and the control
   plane mechanism used to manage it.  Depending on the use case
   scenario for the FLO, appropriate security mechanisms should be
   applied to secure the control and data plane functionalities and
   operations to avoid exploitation of this feature.

   Generally, the major threat against the FLO approach is to manipulate
   the relationship between the name and the FLO.  Such manipulations
   can happen in various scenarios, some of which are listed as follows:
   (i) a malicious interceptor (acting as a publisher) may intentionally
   inject an incorrect mapping into the name resolution system; (ii) a
   malicious interceptor (between the edge router and the resolution
   server) may manipulate the mapping sent back from the name resolution
   system when the edge router queries the mapping system; (iii) a
   compromised intermediate router may maliciously change the FLO, for
   instance, with a wrong FLO or an out-dated FLO; and (iv) an untrusted
   application may inject an invalid FLO into the Interest message.

   To achieve network level FLO security, appropriate mechanisms should
   be applied to provide mapping provenance and mapping integrity and to
   prevent replay attack to address these issues.  The security
   mechanisms applicable to the above discussed scenarios (i) and (ii)
   are similar to ones applied to secure other mapping systems such as
   LISP [9] and DNS [11].  Scenario (iii) requires new security
   mechanisms, one such way is to enable a domain level trust
   infrastructure so that the mapping between the name and the FLO can
   be authenticated by the successive routers.

   In untrusted environments, when an FLO is inserted within the
   Interest message by the end hosts, appropriate authentication
   information should also be included in the FLO to allow ingress
   routers to optionally validate the delegation of the Interest ID to

Ravindran, et al.       Expires January 18, 2018                [Page 9]

Internet-Draft       Forwarding-label support in CCN           July 2017

   LID [15].  Furthermore, additional security policies can be enabled
   by the network to handle FLOs outside its trust domain.

9.  Use Case Scenarios

   Here we provide the discussions related to using FLOs in different

9.1.  Handling Producer Mobility

   In the literature, we can classify the techniques to handle producer
   mobility into two main categories as application-based approaches and
   network-based approaches.

   o  In application-based approach, the application takes the
      responsibility for announcing its reachability to the network and
      triggering a network state change to enable Interest message
      routing towards the mobile producer.  Most of the current
      proposals fall under this category, and these include the
      following two approaches: (i) Kite proposal [20], which implements
      an anchor based approach where consumers and producers agree on an
      anchor point based on external mechanisms and uses application
      initiated (traced and tracing) Interests to handle the producer
      mobility; (ii) Anchor-less proposal [22], which is another
      application-based approach wherein enhanced name-based routing and
      forwarding is used to track the mobile producer.  While these
      approaches allow consumers and producers to work on a single name
      space, their use may raise scalability concerns with increasing
      number of mobile nodes and number of applications signaling into
      the network.  As these approaches introduce additional signaling
      in the network, the operational efficiency of packet forwarding is
      negatively affected due to state changes that have to be applied
      to ensure optimized Interest routing to the mobile producer.
      Another potential issue with these approaches is security, as they
      can be prone to flooding attacks by malicious applications
      targeting specific application names and impeding their normal

   o  In network-based approach, late-binding technique [18][16] is
      used, wherein the reachability of the mobile node is handled by
      the network.  In this case, applications can explicitly request
      mobility for a given name space [16], with the network handling
      the mobility by tracking its latest location in the network
      through a name resolution system.  At the same time, through
      coordination of the old and new point-of-attachments (PoA) and in-
      band signaling, one can achieve minimal loss for a given Interest
      flow.  The late-binding technique uses ID/Locator split that is
      only applied at the PoAs, thereby avoiding challenges related to

Ravindran, et al.       Expires January 18, 2018               [Page 10]

Internet-Draft       Forwarding-label support in CCN           July 2017

      routing convergence in the network due to producer mobility, while
      offering better scalability performance as the number of mobile
      producers increases.  In this approach, a user entity (UE)
      registers a name prefix that requires mobility support with its
      current point-of-attachment (PoA).  The PoA then registers the
      mapping between the name prefix and the PoA's locator in its local
      name resolution system.  The domain then updates the UE's home
      domain name resolution system with its current domain LID.  When a
      correspondent nodes expresses Interest for the name, it is first
      resolved to the current UE domain by the home domain.  When the
      Interest enters the domain offering mobility service, it is
      resolved again to the UE's current location.  Furthermore PoA-to-
      PoA signaling can be enabled to offer seamless forwarding of
      Interests whenever an UE changes its PoA.  In addition to
      correcting the path stretch, the Interests re-routed from the old
      PoA can be marked and re-routed to the new PoA with the new FL.
      On the return path, the content objects are also marked, and this
      in-band marking used by the ingress PoA at the consumer's end
      results in re-resolving the mobile prefix to a new forwarding
      locater that would correct the path stretch.

9.2.  Manifests

   The FLOs can also be used to support the retrieval of nameless
   objects [17].  Using the current manifest proposal [10] a consumer
   receives a manifest with the ContentObjectHashIDs and their
   respective locator information.  A consuming application uses the
   locator as a routable content name, while the ContentObjectHashID is
   used as a HashID restriction parameter.  Multiplexing the Interest
   name field as an ID and also as a LID has the following consequences:
   (i) a forwarder cannot distinguish between Interest messages
   containing ID or LID in the name field, as the protocol does not
   differentiate between these two names; (ii) it complicates Interest
   message processing, where two different Interest processing logics
   need to be applied on Interests (with or without the hash-id).  In
   this situation, routers should first check for the presence of
   ContentObjectHashID and uses it to index the Interest based on it,
   rather than using the locator name; (iii) more complications may
   arise, if an Interest packet arrives with two IDs, for example, a
   ContentObjectHashID as the hash restriction and the ID as the content
   name, in which case, one of them should seek precedence over the

   The above issues can be avoided through the use of
   ContentObjectHashID as the content name and the locator as LID with
   the FLO.  In this case, a forwarder will always index the pending
   Interest table or the cache as expected on the content name.  The
   routing decision would then be based on the FLO, depending on the

Ravindran, et al.       Expires January 18, 2018               [Page 11]

Internet-Draft       Forwarding-label support in CCN           July 2017

   routing policy implemented by the forwarder.  This also avoids the
   situation of dealing with two IDs in the Interest message, where the
   application has to choose either the ID or the ContentObjectHashID as
   the content ID.

   A possible high level forwarding logic for the edge/core router to
   support nameless objects based on the above discussion is presented
   in Figure 3.  Here, edge router can also be a gateway node.


          if Edge_Router
                 If Interest arrives on a face with a flat-ID
                        Then check for the presence of FLO
                          If FLO is present, use the LID in the FLO for Interest forwarding

                        If there no FLO
                          If policy allows, resolve the flat-ID with a NRS to obtain an FLO
                                Use the FLO to route the Interest


                If the Interest arrives with a routeable ID
                  If there is FLO
                        Then use the ID for forwarding and Remove the FLO

                  If there is no FLO
                        Match Interest ID with name policy for e.g. mobility or interest routing optimization
                          If a name policy for resolution exists
                                Then network resolution service is invoked on the ID  which returns an FLO
                                 Use the FLO to direct the Interest to the appropriate next hop

          if Core_Router
                  if Interest arrives with an FLO
                        Use the LID for forwarding
                  Else if Interest is with a Routeable ID
                        Use the name for forwarding

                        Figure 3: Forwarding logic to support flat-ID and routeable ID at the edge router

Ravindran, et al.       Expires January 18, 2018               [Page 12]

Internet-Draft       Forwarding-label support in CCN           July 2017

   We next discuss the security implications of using IDs and FLOs
   within the Interest message, depending on the ID type, as follows:

   o  Case 1 - ContentObjectHashId with FLO: This use case is a
      straightforward simplification of what is being proposed in [17].
      Here, the locator is included within the FLO and the
      ContentObjectHashId is used as the name, so this shouldn't
      introduce any new security concerns.  This holds true for both
      application and network based FLO insertions.

   o  Case 2 - Routable ID with FLO: For UE based FLO insertion, this
      scenario can cause cache poisoning in the absence of signature
      check enforcement at the forwarders.  For the case, when FLO is
      managed within a trusted domain, the security implications are
      discussed in Section 8.

9.3.  Support for Conversational Sessions

   FLO can be used to bind a service ID to a given location in the
   network, so that the consumer's session is correctly directed to the
   service instance keeping state of the conversation.  An example for
   this is discussed in [2].  Using an ID-based anycast routing cannot
   guarantee this as the name prefix state used for forwarding would
   treat all possible instances equally.  One way to mitigate this,
   which may compromise efficiency, would be to introduce a load
   balancer, through which all such Interest flows are routed.

9.4.  Interest Routing Optimization

   A network domain, which hosts its own or third party contents/
   services, can benefit from the ability to handle Interest routing
   logic within its domain opportunistically.  When an Interest message
   seeking a specific content or service enters a network domain, the
   ingress router can redirect the Interest to the closest cache point
   or service location.

9.5.  Routing Scalability

   As discussed in [15], locator-based routing can address the routing
   scalability, as the number of ASs are many orders less than the
   number of information objects.  Doing so would reduce the forwarding
   table in the DFZ to the order of the number of ASs in the Internet.
   In addition, unlike [15], this proposal offers the features of
   swapping FLOs and late-binding, which may lead to more flexibility
   and efficiency towards scalability and routing optimization.

Ravindran, et al.       Expires January 18, 2018               [Page 13]

Internet-Draft       Forwarding-label support in CCN           July 2017

10.  Informative References

   [1]        Azgin, A. and R. Ravindran, "Enabling Network Identifier
              (NI) in Information Centric Networks to Support Optimized
              Forwarding", draft-azgin-icnrg-ni-01 (work in progress),
              May 2017.

   [2]        Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange
              Protocol Version 1.0", draft-wood-icnrg-ccnxkeyexchange-02
              (work in progress), July 2017.

   [3]        Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
              Format", draft-irtf-icnrg-ccnxmessages-04 (work in
              progress), March 2017.

   [4]        Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,

   [5]        CCN Wire format, CCNX1., "http://www.ietf.org/id/
              draft-mosko-icnrg-ccnxmessages-00.txt.", 2013.

   [6]        Nikander, P., Gurtov, A., and T. Henderson, "Host identity
              protocol (HIP): Connectivity, mobility, multi-homing,
              security, and privacy over IPv4 and IPv6 networks", IEEE
              Communications Surveys and Tutorials, pp: 186-204, 2010.

   [7]        Atkinson, R., "An Overview of the Identifier-Locator
              Network Protocol (ILNP)", Technical Report, University
              College London, 2005.

   [8]        LISP, RFC6380., "https://tools.ietf.org/html/draft-ietf-
              lisp-sec-07.", 2014.

   [9]        LISP-Security, LISP-SEC., "https://tools.ietf.org/html/
              draft-ietf-lisp-sec-07.", 2014.

   [10]       CCNx, Manifest., "http://www.ccnx.org/pubs/
              draft-wood-icnrg-ccnxmanifests-00.html.", 2015.

   [11]       DNS-SEC, RFC4033., "DNS Security Introduction and
              Requirements.", 2005.

   [12]       FP7-ICT-2009-5-257448/D.B.3, "SAIL: Scalable and Adaptable
              Internet Solutions", 2013, <http://www.sail-project.eu/wp-

Ravindran, et al.       Expires January 18, 2018               [Page 14]

Internet-Draft       Forwarding-label support in CCN           July 2017

   [13]       Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and
              GQ. Wang, "5G-ICN : Delivering ICN Services over 5G using
              Network Slicing.", IEEE Communication Magazine, May, 2017.

   [14]       Adhatarao, S., Chen, J., Arumaithurai, M., Fu, X., and K.
              Ramakrishnan, "Comparison of Naming Schema in ICN.", IEEE
              LANMAN, 2016.

   [15]       Afanasyev, A., "Map-and-Encap for Scaling NDN Routing.",
              NDN Technical Report ndn-004-02, 2015.

   [16]       Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang,
              "Seamless Producer Mobility as a Service in Information
              Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016,

   [17]       Mosko, M., "Nameless Objects.", IETF/ICNRG, Paris
              Interim 2016, 2016.

   [18]       Azgin, A., Ravindran, R., and G. Wang, "A Scalable
              Mobility-Centric Architecture for Named Data Networking.",
              ICCCN (Scene Workshop) , 2014.

   [19]       Cisco System Inc., CISCO., "Cisco Visual Networking Index:
              Global Mobile Data Traffic Forecast Update", 2016-2021.

   [20]       Zhang, Y., Zhang, H., and L. Zhang, "Kite: A Mobility
              Support Scheme for NDN.", NDN, Technical Report NDN-0020 ,

   [21]       CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/
              ccnx-mosko-labelforwarding-01.txt.", 2013.

   [22]       Auge, J., Carofiglio, G., Grassi, G., Muscariello, L.,
              Pau, G., and X. Zeng, "Anchor-less Producer Mobility in
              ICN.", ICN, Sigcomm, 2015 , 2015.

   [23]       NSF FIA project, MobilityFirst.,
              "http://www.nets-fia.net/", 2010.

Authors' Addresses

Ravindran, et al.       Expires January 18, 2018               [Page 15]

Internet-Draft       Forwarding-label support in CCN           July 2017

   Ravishankar Ravindran
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: ravi.ravindran@huawei.com

   Asit Chakraborti
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: asit.chakraborti@huawei.com

   Aytac Azgin
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: aytac.azgin@huawei.com

Ravindran, et al.       Expires January 18, 2018               [Page 16]