ICN Research Group R. RavindranInternet-Draft A. ChakrabortiIntended status: Informational A. AzginExpires: September 6, 2018 Huawei Technologies March 5, 2018Forwarding Label support in CCN Protocoldraft-ravi-icnrg-ccn-forwarding-label-02Abstract 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 ofBCP 78 andBCP 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 athttps://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 2018Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 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 Contents1. AI/NI Namespace Split in CCN . . . . . . . . . . . . . . . .22. Forwarding Label Object Proposal . . . . . . . . . . . . . .52.1. FLO Naming . . . . . . . . . . . . . . . . . . . . . . .52.2. FLO Insertion . . . . . . . . . . . . . . . . . . . . . .52.3. FLO Swapping . . . . . . . . . . . . . . . . . . . . . .62.4. FLO Termination . . . . . . . . . . . . . . . . . . . . .63. FLO Message Format . . . . . . . . . . . . . . . . . . . . .64. FLO Processing Rules . . . . . . . . . . . . . . . . . . . .75. PIT Processing Implications . . . . . . . . . . . . . . . . .86. Caching Implications . . . . . . . . . . . . . . . . . . . .87. Multiple Domain Scenario . . . . . . . . . . . . . . . . . .98. FLO Security . . . . . . . . . . . . . . . . . . . . . . . .99. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . .109.1. Handling Producer Mobility . . . . . . . . . . . . . . .109.2. Handling Consumer Mobility . . . . . . . . . . . . . . .119.3. Manifests . . . . . . . . . . . . . . . . . . . . . . . .129.4. Supporting Conversational Sessions . . . . . . . . . . .159.5. Interest Routing Optimization . . . . . . . . . . . . . .159.6. Routing Scalability . . . . . . . . . . . . . . . . . . .1510. Security Considerations . . . . . . . . . . . . . . . . . . .1511. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .1612. Informative References . . . . . . . . . . . . . . . . . . .16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .181. 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 20182. 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 20182.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) Definition4. 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, nameRavindran, 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 20187. 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 atRavindran, 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 contentRavindran, 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 theRavindran, 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 inSection 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 inSection 8.Ravindran, et al. Expires September 6, 2018 [Page 15]
Internet-Draft Forwarding label support in CCN March 201811. 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.comRavindran, et al. Expires September 6, 2018 [Page 18]
draft-ravi-icnrg-ccn-forwarding-label-02
Expired Internet-Draft (individual)
| Document | Document type | Expired Internet-Draft (individual) Expired & archived This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process. | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors | Ravi Ravindran,Asit Chakraborti,Aytac Azgin Email authors | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Other formats |