[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

ICN Research Group                                          R. Ravindran
Internet-Draft                                            A. Chakraborti
Intended status: Informational                                  A. Azgin
Expires: September 6, 2018                           Huawei Technologies
                                                           March 5, 2018


                Forwarding Label support in CCN Protocol
                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.

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 https://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 September 6, 2018.








Ravindran, et al.       Expires September 6, 2018               [Page 1]


Internet-Draft       Forwarding label support in CCN          March 2018


Copyright Notice

   Copyright (c) 2018 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
   (https://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.  AI/NI 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.  PIT Processing Implications . . . . . . . . . . . . . . . . .   8
   6.  Caching Implications  . . . . . . . . . . . . . . . . . . . .   8
   7.  Multiple Domain Scenario  . . . . . . . . . . . . . . . . . .   9
   8.  FLO Security  . . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Use Case Scenarios  . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Handling Producer Mobility  . . . . . . . . . . . . . . .  10
     9.2.  Handling Consumer Mobility  . . . . . . . . . . . . . . .  11
     9.3.  Manifests . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.4.  Supporting Conversational Sessions  . . . . . . . . . . .  15
     9.5.  Interest Routing Optimization . . . . . . . . . . . . . .  15
     9.6.  Routing Scalability . . . . . . . . . . . . . . . . . . .  15
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  16
   12. Informative References  . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  AI/NI Namespace Split in CCN

   In [1], we discuss several reasons to distinguish application
   identifiers (AI) and network identifiers (NI).  In the context of
   ICN/CCN, we define application identifier (AI) and network identifier
   (NI) as follows:




Ravindran, et al.       Expires September 6, 2018               [Page 2]


Internet-Draft       Forwarding label support in CCN          March 2018


   o  Application Identifier (AI) is a persistent secure or non-secure
      flat-ID or a hierarchical name assigned to a content, device or
      service.  If the AI is secure, then there is a direct relationship
      between the name and the key of the principal, else a binding is
      provided by a third party using the certificate mechanism or using
      the web-of-trust model.  Generally this identifier space is
      managed by services and applications.

   o  Network Identifier (NI) is a topological name assigned to a
      network entity such as a network, router, host.  Generally the NI
      space is assigned and managed by the network administrators.

   We discuss here first (i) the motivations behind the need for
   separation between a persistent AI and an NI in the Interest message,
   in the context of CCN, and then (ii) a proposal to achieve this.  The
   notion of ID/Locator has been widely studied as part of many host-
   centric protocols such as HIP [6], ILNP [7], and LISP [8].  Here we
   distinguish AI/NI from the ID/Locator notion due to the nature of ICN
   with respect to interdependency between naming and forwarding.
   Specifically, in the context of information-centric networks, any of
   these two names can be used contextually in the routing and
   forwarding plane to resolve content, service or host or even apply
   computation on the named data objects based on the application
   requirements.  In this context, ICN architectures such as
   MobilityFirst [23] and NetInf [12] assume an explicit representation
   of AI and NI in its architecture, considering the use of non-
   aggregateable flat IDs, whereas CCN/NDN assumes the aggregate-ability
   of names within its architecture, thereby applying only the AI
   namespace on routing and forwarding.  We have argued in [1] the
   problems associated with (i) using name prefixes for routing, which
   include challenges related to scalability, (ii) loss of name
   aggregate-ability, when data and services are replicated, (iii)
   mobility handling, or (iv) 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 this distinct AI/NI
   separation in the ICN protocol offers the following advantages, which
   are also discussed in detail in [1]:

   o  CCN applications request persistent AI of content, service or
      hosts, while their resolution is handled through per-hop name-
      based forwarding by a CCN forwarder using any of the
      unicast/anycast/broadcast mechanisms, with routing scalability
      being handled using name prefixes.  This model can introduce
      problems when the named entity is mobile, migrated, or replicated,
      as the names have to be announced in the routing control plane,



Ravindran, et al.       Expires September 6, 2018               [Page 3]


Internet-Draft       Forwarding label support in CCN          March 2018


      which can in turn introduce routing convergence issues and
      scalability challenges.  Introducing an AI/NI namespace split in
      the architecture using a name resolution service shall address the
      routing challenges due to dynamic entities, while also improving
      the scalability by limiting the state in the core Internet routers
      to the set of topological names.

   o  AI and NI namespaces are managed by different entities.  For
      instance, AIs are managed by applications and services, hence
      their scope is limited to the application layer, while the NI
      names are assigned to the networked entity, hence managed by a
      network administrator.  In such case, NI maps to network domains
      or specific network elements, through which the AI is reachable.
      The relationship between the two is established during the
      namespace publishing phase, and managed by a separate name
      resolution service.  AI/NI distinction in CCN allows applications
      to manage its own namespace and not be restricted by the naming
      rules imposed by the network.

   o  Allowing an AI/NI representation in an Interest message offers
      many advantages in CCN, especially when centralized control is
      applied, such as using a service orchestration framework [13] for
      intelligent service and content placement based on available
      network resources and satisfying QoS requirements.  This enables
      efficiency and flexibility through service-centric name
      resolution, routing, mobility and caching services.

   Considering the above requirements, we propose a forwarding label
   object (FLO), which includes an NI along with the security
   encapsulations and provide 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.
   Handling the AI-to-NI mapping requires a control plane infrastructure
   and appropriate network layer security functions to prevent malicious
   misuse.  Specific control plane or security mechanism of AI/NI
   mapping is out of the scope of this document as many techniques can
   be used towards achieving this.  This draft presents various
   considerations towards FLO management such as: FLO
   insertion/modification/deletion, FLO processing by a CCN forwarder,
   PIT/CS implications for FLO carrying Interests, FLO Interest packet
   format, and security/trust considerations.  We also discuss the
   application of FLO in various scenarios to illustrate its
   capabilities and advantages.








Ravindran, et al.       Expires September 6, 2018               [Page 4]


Internet-Draft       Forwarding label support in CCN          March 2018


2.  Forwarding Label Object Proposal

   Following we discuss various aspects of the FLO related to its
   semantics and management.

2.1.  FLO Naming

   FL objects include NI, service specific metadata, and security
   attributes for authentication.  An NI like an AI can be
   hierarchically structured or flat, but with the characteristic of
   having a topological property.  The security attributes are optional
   and may include validation payload and algorithm as discussed in [3].

2.2.  FLO Insertion

   A FLO can be inserted in an Interest message by the application
   requesting a named entity or by the network.

   In certain situations, the application may insert the FLO in addition
   to the AI in the Interest message or this action may also be
   triggered based on feedback received from the network, for instance,
   due to failure of routing the Interest message based on the AI, as in
   [15].  In such situations, forwarders, which process traffic from
   applications outside the trust domain, require a way to validate the
   FLO.  A possible approach to ensure trust in such situations is
   discussed in [15] where a trust binding is provided between the AI
   and the NI as a link object which can be validated by the forwarder.
   To avoid the possibility of a misuse of a FLO, a default policy of
   the network may be to ignore it from untrusted applications and to
   only choose to route by the AI or by applying the next scenario.

   FLO can also be inserted by the network, in which case FLO insertion
   is triggered at the ingress (service edge) routers of the network
   domain.  For instance, network may insert a FLO to an incoming
   Interest message, an action which can be triggered based on several
   considerations, some of which may include: 1) based on the interface,
   on which the Interest ingresses; 2) if the Interest message satisfies
   the flow service profiles that are imposed by the network
   administrator at the ingress routers; 2) a default behavior by the
   network, when it chooses to only route on NIs.  The service profile
   matching actions may include matching an Interest name to a set of
   service prefixes or triggered by certain markings or metadata in the
   Interest such as context-ID (for example, service, network, trust,
   and location).  FLO inserted within the trust domain may not require
   security validation.






Ravindran, et al.       Expires September 6, 2018               [Page 5]


Internet-Draft       Forwarding label support in CCN          March 2018


2.3.  FLO Swapping

   A FLO can be swapped with another within the network, in the context
   of a given service, at designated points, such as the service edge
   routers.

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

2.4.  FLO Termination

   FL objects are terminated by a forwarder, when the NI in it matches
   the forwarder's own NI.  Here, we assume a forwarder to possibly have
   many NIs such as domain-IDs, router-IDs or Interface-IDs.  For
   example, a forwarder (in a domain) identified as /att/santaclara can
   process a FLO with its NI set to this router's domain name or to a
   forwarder ID such as /att/santaclara/pop-x.  Whenever a FLO is
   terminated by the forwarder, depending on the network service
   context, the forwarder can attach a new FLO, or conduct additional
   processing on the request (e.g., re-resolution of the name to a new
   FLO) based on the Interest parameters.  The FLO can also include
   optional policy metadata based on which FL objects can be swapped
   within the network.

3.  FLO Message Format

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













Ravindran, et al.       Expires September 6, 2018               [Page 6]


Internet-Draft       Forwarding label support in CCN          March 2018


                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                      CCN Fixed Header                       |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                 <Optional Hop-by-Hop TLVs>                  |
                       /                                                             /
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |         Type = FL-Object    |           Length              |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                            NI  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      |
                     +----------------------+------------------+-----------------+
                     |      NI  TLV         | Identifies an    |    Name TLV     |
                     |                      | AS-ID/Gateway-ID/|                 |
                     |                      | Host-ID/Interface|                 |
                     |                      | -ID              |                 |
                     +----------------------+------------------+-----------------+


                                  Figure 2: Network Identifier(NI) Definition


4.  FLO Processing Rules

   The following discussion is based on the assumption that all
   forwarders must process the optional header fields.  In 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, a default
   policy applied by all CCN routers is to route using FLO if it exists
   in the Interest message.  Based on this, following considerations
   apply:

   o  When an Interest with a FLO arrives at a CCN router, if the FLO is
      trusted and the lookup based on NI in the FLO succeeds, the router
      first checks if the NI matches any of its network names.  If it
      does, it is treated as a terminating flow.  In this case, name



Ravindran, et al.       Expires September 6, 2018               [Page 7]


Internet-Draft       Forwarding label support in CCN          March 2018


      based lookup is conducted, which may return another FLO, or
      results in a next hop forwarding face for the Interest packet.
      For the non-terminating flow, the NI FIB lookup results in a next
      hop, towards which the Interest is forwarded.

   o  If NI based on the FLO lookup fails, then the router can try to
      forward the Interest based on the Interest AI.  However if routing
      based on the Interest AI fails, then the router could raise an
      error condition and feedback the message to the previous hop with
      the appropriate error code.

   o  The validation of FLO depends on the trust context, which is
      indicated by the information inserted in the FLO by the ingress
      domain router.  In trusted networking 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 networking scenarios, the edge router may only
      validate the FLO that is inserted by the sender and avoid re-
      validations by successive forwarders.

5.  PIT Processing Implications

   FLO is only a routing directive, hence shouldn't affect the
   functionality of the PIT in normal situations.  However, including
   FLO in the Interest could raise new questions, which need to be
   answered.  One such case is when there is a strong binding between an
   AI and the NI either by the application or the network, which may
   correspond to situations when multiple Interests arrive at a router
   for the same AI but with different NIs.  One possible approach in
   this case is to treat each such (AI,NI) combination differently,
   thereby saving them in the PIT, and by requiring the CO to piggyback
   the NI to ensure proper matching.  In the case, when the FLO is
   swapped by an intermediate router, its PIT should save both the
   incoming and the outgoing NI, and also the CO should be updated with
   the appropriate NI to ensure matching of the PIT entries along the
   previous hops.  These considerations are similar to those elaborated
   in [21]

6.  Caching Implications

   The caching function shouldn't be affected by this draft proposal.
   Even if a FLO is included in the CO as discussed earlier, this is
   expected to be removed before caching the content, as it only relates
   to forwarding function.







Ravindran, et al.       Expires September 6, 2018               [Page 8]


Internet-Draft       Forwarding label support in CCN          March 2018


7.  Multiple Domain Scenario

   In wide area network scenarios, Interests can cross multiple domains.
   If a FLO is only trusted within the domain boundaries, then the FLO
   is removed before the Interest is forwarded to the next domain, which
   then upon entry, by the ingress of the next domain, inserts a new FLO
   with the associated security attributes.  However, if trust exists
   between the neighboring domains to use the FLO inserted by the
   previous domain (such as one through a trusted third party, and
   validated based on the FLO security binding), then 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 of the FL, appropriate security mechanisms should be applied
   to secure the control and data planes 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 (who is acting as a publisher)
   intentionally injects an incorrect mapping into the name resolution
   system; (ii) a malicious interceptor (between the edge router and the
   resolution server) manipulates the mapping sent back from the name
   resolution system, when the edge router queries the mapping system;
   (iii) a compromised intermediate router maliciously changes the FLO,
   e.g., with the wrong FLO or an out-dated FLO; (iv) an untrusted
   application injects an invalid FLO into the Interest message.

   To achieve network level FLO security, appropriate mechanisms should
   be applied to provide mapping provenance, 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 the ones applied to secure other mapping systems such
   as LISP [9] and DNS [11].  Scenario (iii) requires new security
   mechanisms, and 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 a FLO is inserted in 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 AI to NI [15].




Ravindran, et al.       Expires September 6, 2018               [Page 9]


Internet-Draft       Forwarding label support in CCN          March 2018


   Furthermore, additional security policies can be enabled by the
   network to handle FL objects outside its trust domain.

9.  Use Case Scenarios

   Here we provide the discussions related to using FLOs in different
   scenarios.

9.1.  Handling Producer Mobility

   In the literature, the different techniques to handle producer
   mobility can be classified into the following two types:

   o  Application-based approach, where the application takes the
      responsibility for announcing its reachability to the network and
      triggering a network state change to enable Interest routing
      towards the mobile producer.  Most of the current proposals fall
      under this category, and these include the following two
      approaches: 1)The Kite proposal [20] 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;
      2)The anchor-less proposal [22] 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, it raises
      scalability concerns with increasing number of mobile nodes and
      number of applications signaling into the network.  As these
      approaches introduce more signaling in the network, the
      operational efficiency of packet forwarding is negatively affected
      due to the state changes that have to be applied to ensure
      optimized Interest routing towards the mobile producer.  Another
      potential security issue with these approaches is that it can be
      prone to flooding attacks by malicious applications targeting
      specific application names and impeding their normal operation.

   o  Network-based approach uses the late-binding technique [18][16],
      wherein the reachability of the mobile node is handled by the
      network.  In this case, applications can explicitly request
      mobility for a given namespace [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 AI/NI split that is only applied at the
      PoAs, thereby avoiding challenges related to routing convergence
      in the network due to producer mobility, while offering better
      scalability when the number of mobile producers increases.  Here,



Ravindran, et al.       Expires September 6, 2018              [Page 10]


Internet-Draft       Forwarding label support in CCN          March 2018


      the user entity (UE) registers a name prefix that requires
      mobility with its current point-of-attachment (PoA).  The PoA then
      registers the mapping between the name prefix and the PoA's NI 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 node 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 a 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 COs are also marked, this in-band marking
      is used by the ingress PoA at the consumer's end to re-resolve the
      mobile prefix to a new forwarding NI that would correct the path
      stretch.

9.2.  Handling Consumer Mobility

   As ICN operates in a PULL mode, consumers operating over unreliable
   wireless interfaces or during mobility-triggered events (such as
   handovers) can recover from a lost Interest or Data response by re-
   expressing it.  There are some challenges associated with this
   approach: (1) without appropriate cross-layer signaling between the
   MAC and the ICN layer on the transient lower layer interface state or
   network events such as handover, it is difficult to re-express
   Interest in a timely manner; alternately ICN or the applications rely
   on default Interest timeout value supplied by the application which
   can be very inefficient, particularly for applications with real-time
   requirements; (2) even in the case of a desired scenario, where
   cross-layer signaling is enabled and an ICN Interest is re-expressed
   soon after a loss is identified, the ability to retrieve the content
   from a nearby cache depends on the engineered cache resources in the
   ICN network, such as its size in the edge vs. core routers and the
   cache management algorithms that exploit features such as content
   popularity to offer the best user experience.  In the worst case
   scenario, these re-expressed Interests can only be satisfied by the
   producer.  Note that, this scenario is mostly true for a large set of
   unpopular content types or for conversational applications, where
   caching may be of no significant use.

   The above concerns can be addressed using FLO to support seamless
   consumer mobility.  The process is similar to producer mobility, but
   in this situation, FLO is used to redirect Data objects from the
   previous PoA to the new PoA.  The trigger for this redirection
   requires to identify the set of Interests in the PIT, which have been
   affected by the consumer mobility.  To support this, the PIT state at



Ravindran, et al.       Expires September 6, 2018              [Page 11]


Internet-Draft       Forwarding label support in CCN          March 2018


   the PoAs are expanded to save the ID of the UE which is signaled in
   the Interest.  However, this ID is not carried beyond the PoA.  In
   addition, the PIT state is also associated with the attachment state
   of the consumer device to the current PoA.  During the handover,
   consumer UE signals to the previous PoA information about the new PoA
   (such as the NI associated with the new PoA), which is then applied
   to the PIT entries associated with this consumer along with the
   change of the attachment state.  When the Data objects requested by a
   previously connected consumer, which performed handover to attach to
   another PoA, arrives at the previous PoA, the NI information in the
   PIT is used to create the FLO, which is then appended to the Data
   header and forwarded like an Interest using the FIB.  These Data
   objects are also marked, so that the set of routers along the path
   towards the new PoA are able to distinguish between these packets and
   regular Data objects.  These Data objects could pass through a path
   segment that it has already passed through in the reverse direction
   prior to arriving at the previous PoA.  In that case they should not
   be cached by any router belonging to that path segment, but can be
   cached in the routers that are part of the path segment receiving
   this Data object for the first time, by first removing the FLO and
   subjecting it to the local caching policies.  When this Data arrives
   at the current PoA, it is cached applying prioritized caching
   policies considering its arrival as a result of a handover, which is
   then used to respond to a re-expressed Interest.  Alternately, the
   Data objects forwarded from the previous PoA can also include the
   consumer ID, which can then be used by the current PoA to PUSH it to
   the consumer UE, similar to how it would be at the previous PoA had
   the consumer still connected to it.

9.3.  Manifests

   The FL objects 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 NI information.  A consuming application uses the NI as a
   routeable content name, while the ContentObjectHashID is used as a
   HashID restriction parameter.  Multiplexing the Interest name field
   as an AI and also as an NI has the following consequences: (1) a
   forwarder cannot distinguish between Interest packets containing AI
   or NI in the name field, as the protocol doesn't differentiate these
   two names; (2) it complicates Interest processing where two different
   Interest processing logic needs to be applied with Interests with or
   without the hash-id.  In this situation, routers should first checks
   for the presence of ContentObjectHashID and uses it to index the
   Interest based on it rather than using it as a NI; (3) more
   complications arise if an Interest packet arrives with two IDs i.e. a
   ContentObjectHashID as the hash restriction and the ID as the content




Ravindran, et al.       Expires September 6, 2018              [Page 12]


Internet-Draft       Forwarding label support in CCN          March 2018


   name, in which case, one of them should seek precedence over the
   other.

   The above issues can be avoided through the use of the
   ContentObjectHashID as the content name and the NI in 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
   then would be based on the FLO depending on the routing policy in the
   forwarder.  This also avoids the situation of dealing with two IDs in
   the Interest packet, i.e. the application has to choose either ID or
   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.




































Ravindran, et al.       Expires September 6, 2018              [Page 13]


Internet-Draft       Forwarding label support in CCN          March 2018


  Begin

  if Edge_Router
    If Interest arrives on a face with a flat AI
      Then check for the presence of FLO
      If FLO is present
        Then use the NI in the FLO for Interest forwarding
      Else (If there is no FLO)
        If policy allows, resolve the flat AI with an NRS to obtain a FLO
          Use the FLO to route the Interest
        End
      End
    End

    If the Interest arrives with a routeable AI
      If FLO is present
        Then use the AI for forwarding and Remove the FLO
      Else (if there is no FLO)
        Match Interest AI 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 AI, which returns a FLO
          Use the FLO to direct the Interest to the appropriate next hop
        End
      End
    End

  End

  if Core_Router
    if Interest arrives with a FLO
      Use the NI for forwarding
    Else if Interest is with a Routeable AI
      Use the name for forwarding
    End
  End

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





   We discuss security implications of using AI and FLO in the Interest
   message depending on the ID type.

   o  Case 1 - ContentObjectHashId with FLO: This use case is a
      straightforward simplification of what is being proposed in [17].
      Here, the NI is included within the FLO and the



Ravindran, et al.       Expires September 6, 2018              [Page 14]


Internet-Draft       Forwarding label support in CCN          March 2018


      ContentObjectHashId is used as the name, so this shouldn't
      introduce any new security concerns.  This holds good for both
      application and network based FLO insertion.

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

9.4.  Supporting Conversational Sessions

   FLO can be used to bind a service AI 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, e.g. [2].  Using
   AI-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, while compromising efficiency, would be to
   introduce a load balancer, through which all such Interest flows are
   routed.

9.5.  Interest Routing Optimization

   Networks, which host their own or third party contents/services can
   benefit from the ability to handle Interest routing logic in its
   domain opportunistically.  When an Interest 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.6.  Routing Scalability

   As discussed in [15], NI based routing can address routing
   scalability, as the number of ASs are many orders less than the
   number of information objects.  This reduces the forwarding table in
   the DFZ to the order of number of ASs in the Internet.  In addition,
   unlike [15], this proposal offers the feature of swapping FLO and
   late-binding offering more flexibility and efficiency towards
   scalability and routing optimization.

10.  Security Considerations

   The security implication of having FLO in the Interest message has
   been discussed in Section 8.








Ravindran, et al.       Expires September 6, 2018              [Page 15]


Internet-Draft       Forwarding label support in CCN          March 2018


11.  Conclusions

   Following the discussion in [1], this draft proposes extensions to
   the CCN protocol to introduce NI namespace in the Interest message
   which can offer several benefits which include routing optimization
   and scalability, off path caching benefits, handling both consumer
   and producer mobility and service affinity for conversational
   communications.

12.  Informative References

   [1]        Azgin, A. and R. Ravindran, "Enabling Network Identifier
              (NI) in Information Centric Networks to Support Optimized
              Forwarding", draft-azgin-icnrg-ni-02 (work in progress),
              July 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-06 (work in
              progress), October 2017.

   [4]        Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <https://www.rfc-editor.org/info/rfc7665>.

   [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.



Ravindran, et al.       Expires September 6, 2018              [Page 16]


Internet-Draft       Forwarding label support in CCN          March 2018


   [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-
              content/uploads/2013/01/SAIL-DB3-v1.1-final-public.pdf>.

   [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,
              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.", 2009-2014.

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

   [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.





Ravindran, et al.       Expires September 6, 2018              [Page 17]


Internet-Draft       Forwarding label support in CCN          March 2018


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

Authors' Addresses

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

   Email: ravi.ravindran@huawei.com


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

   Email: asit.chakraborti@huawei.com


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

   Email: aytac.azgin@huawei.com





















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


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/