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]