idnits 2.17.1 draft-ravi-icnrg-ccn-forwarding-label-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 30 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '4' is defined on line 678, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 736, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-06 == Outdated reference: A later version (-01) exists of draft-mosko-icnrg-ccnxmessages-00 -- No information found for draft-wood-icnrg-ccnxmanifests - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group R. Ravindran 3 Internet-Draft A. Chakraborti 4 Intended status: Informational A. Azgin 5 Expires: September 6, 2018 Huawei Technologies 6 March 5, 2018 8 Forwarding Label support in CCN Protocol 9 draft-ravi-icnrg-ccn-forwarding-label-02 11 Abstract 13 The objective of this proposal is to enable application identifier 14 (AI) and network identifier (NI) split in the CCN protocol that has 15 several applications such as towards Interest routing optimization, 16 mobility, conversational session support, handling indirections in 17 manifests, and routing scalability. We enable this through the 18 notion of forwarding label object (FLO), which is an optional hop-by- 19 hop payload in the Interest message with a topological name which 20 identifies a network domain, router or a host. FLO can be inserted 21 by the end user applications or by the network. FLO is processed by 22 the network resulting in either terminating it or swapping it with a 23 new FLO based on the network service context. Furthermore, depending 24 on the application and trust context, a FLO can be subjected to 25 policy based actions by the forwarders such as invoking security 26 verification or enabling other FLO management actions. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. AI/NI Namespace Split in CCN . . . . . . . . . . . . . . . . 2 63 2. Forwarding Label Object Proposal . . . . . . . . . . . . . . 5 64 2.1. FLO Naming . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. FLO Insertion . . . . . . . . . . . . . . . . . . . . . . 5 66 2.3. FLO Swapping . . . . . . . . . . . . . . . . . . . . . . 6 67 2.4. FLO Termination . . . . . . . . . . . . . . . . . . . . . 6 68 3. FLO Message Format . . . . . . . . . . . . . . . . . . . . . 6 69 4. FLO Processing Rules . . . . . . . . . . . . . . . . . . . . 7 70 5. PIT Processing Implications . . . . . . . . . . . . . . . . . 8 71 6. Caching Implications . . . . . . . . . . . . . . . . . . . . 8 72 7. Multiple Domain Scenario . . . . . . . . . . . . . . . . . . 9 73 8. FLO Security . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 10 75 9.1. Handling Producer Mobility . . . . . . . . . . . . . . . 10 76 9.2. Handling Consumer Mobility . . . . . . . . . . . . . . . 11 77 9.3. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.4. Supporting Conversational Sessions . . . . . . . . . . . 15 79 9.5. Interest Routing Optimization . . . . . . . . . . . . . . 15 80 9.6. Routing Scalability . . . . . . . . . . . . . . . . . . . 15 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 12. Informative References . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. AI/NI Namespace Split in CCN 88 In [1], we discuss several reasons to distinguish application 89 identifiers (AI) and network identifiers (NI). In the context of 90 ICN/CCN, we define application identifier (AI) and network identifier 91 (NI) as follows: 93 o Application Identifier (AI) is a persistent secure or non-secure 94 flat-ID or a hierarchical name assigned to a content, device or 95 service. If the AI is secure, then there is a direct relationship 96 between the name and the key of the principal, else a binding is 97 provided by a third party using the certificate mechanism or using 98 the web-of-trust model. Generally this identifier space is 99 managed by services and applications. 101 o Network Identifier (NI) is a topological name assigned to a 102 network entity such as a network, router, host. Generally the NI 103 space is assigned and managed by the network administrators. 105 We discuss here first (i) the motivations behind the need for 106 separation between a persistent AI and an NI in the Interest message, 107 in the context of CCN, and then (ii) a proposal to achieve this. The 108 notion of ID/Locator has been widely studied as part of many host- 109 centric protocols such as HIP [6], ILNP [7], and LISP [8]. Here we 110 distinguish AI/NI from the ID/Locator notion due to the nature of ICN 111 with respect to interdependency between naming and forwarding. 112 Specifically, in the context of information-centric networks, any of 113 these two names can be used contextually in the routing and 114 forwarding plane to resolve content, service or host or even apply 115 computation on the named data objects based on the application 116 requirements. In this context, ICN architectures such as 117 MobilityFirst [23] and NetInf [12] assume an explicit representation 118 of AI and NI in its architecture, considering the use of non- 119 aggregateable flat IDs, whereas CCN/NDN assumes the aggregate-ability 120 of names within its architecture, thereby applying only the AI 121 namespace on routing and forwarding. We have argued in [1] the 122 problems associated with (i) using name prefixes for routing, which 123 include challenges related to scalability, (ii) loss of name 124 aggregate-ability, when data and services are replicated, (iii) 125 mobility handling, or (iv) situations where conversational sessions 126 are required for service level authentication and authorization [2]. 127 These issues have also been argued quantitatively in [14], including 128 the scenario, where there is an explosion in the namespace, when 129 there are many different ways of naming an entity because of the rich 130 context associated with it. Therefore, providing this distinct AI/NI 131 separation in the ICN protocol offers the following advantages, which 132 are also discussed in detail in [1]: 134 o CCN applications request persistent AI of content, service or 135 hosts, while their resolution is handled through per-hop name- 136 based forwarding by a CCN forwarder using any of the 137 unicast/anycast/broadcast mechanisms, with routing scalability 138 being handled using name prefixes. This model can introduce 139 problems when the named entity is mobile, migrated, or replicated, 140 as the names have to be announced in the routing control plane, 141 which can in turn introduce routing convergence issues and 142 scalability challenges. Introducing an AI/NI namespace split in 143 the architecture using a name resolution service shall address the 144 routing challenges due to dynamic entities, while also improving 145 the scalability by limiting the state in the core Internet routers 146 to the set of topological names. 148 o AI and NI namespaces are managed by different entities. For 149 instance, AIs are managed by applications and services, hence 150 their scope is limited to the application layer, while the NI 151 names are assigned to the networked entity, hence managed by a 152 network administrator. In such case, NI maps to network domains 153 or specific network elements, through which the AI is reachable. 154 The relationship between the two is established during the 155 namespace publishing phase, and managed by a separate name 156 resolution service. AI/NI distinction in CCN allows applications 157 to manage its own namespace and not be restricted by the naming 158 rules imposed by the network. 160 o Allowing an AI/NI representation in an Interest message offers 161 many advantages in CCN, especially when centralized control is 162 applied, such as using a service orchestration framework [13] for 163 intelligent service and content placement based on available 164 network resources and satisfying QoS requirements. This enables 165 efficiency and flexibility through service-centric name 166 resolution, routing, mobility and caching services. 168 Considering the above requirements, we propose a forwarding label 169 object (FLO), which includes an NI along with the security 170 encapsulations and provide the flexibility to forward Interests on a 171 name other than the one provided within the original Interest 172 message, with the ability to terminate or swap it in the network. 173 Handling the AI-to-NI mapping requires a control plane infrastructure 174 and appropriate network layer security functions to prevent malicious 175 misuse. Specific control plane or security mechanism of AI/NI 176 mapping is out of the scope of this document as many techniques can 177 be used towards achieving this. This draft presents various 178 considerations towards FLO management such as: FLO 179 insertion/modification/deletion, FLO processing by a CCN forwarder, 180 PIT/CS implications for FLO carrying Interests, FLO Interest packet 181 format, and security/trust considerations. We also discuss the 182 application of FLO in various scenarios to illustrate its 183 capabilities and advantages. 185 2. Forwarding Label Object Proposal 187 Following we discuss various aspects of the FLO related to its 188 semantics and management. 190 2.1. FLO Naming 192 FL objects include NI, service specific metadata, and security 193 attributes for authentication. An NI like an AI can be 194 hierarchically structured or flat, but with the characteristic of 195 having a topological property. The security attributes are optional 196 and may include validation payload and algorithm as discussed in [3]. 198 2.2. FLO Insertion 200 A FLO can be inserted in an Interest message by the application 201 requesting a named entity or by the network. 203 In certain situations, the application may insert the FLO in addition 204 to the AI in the Interest message or this action may also be 205 triggered based on feedback received from the network, for instance, 206 due to failure of routing the Interest message based on the AI, as in 207 [15]. In such situations, forwarders, which process traffic from 208 applications outside the trust domain, require a way to validate the 209 FLO. A possible approach to ensure trust in such situations is 210 discussed in [15] where a trust binding is provided between the AI 211 and the NI as a link object which can be validated by the forwarder. 212 To avoid the possibility of a misuse of a FLO, a default policy of 213 the network may be to ignore it from untrusted applications and to 214 only choose to route by the AI or by applying the next scenario. 216 FLO can also be inserted by the network, in which case FLO insertion 217 is triggered at the ingress (service edge) routers of the network 218 domain. For instance, network may insert a FLO to an incoming 219 Interest message, an action which can be triggered based on several 220 considerations, some of which may include: 1) based on the interface, 221 on which the Interest ingresses; 2) if the Interest message satisfies 222 the flow service profiles that are imposed by the network 223 administrator at the ingress routers; 2) a default behavior by the 224 network, when it chooses to only route on NIs. The service profile 225 matching actions may include matching an Interest name to a set of 226 service prefixes or triggered by certain markings or metadata in the 227 Interest such as context-ID (for example, service, network, trust, 228 and location). FLO inserted within the trust domain may not require 229 security validation. 231 2.3. FLO Swapping 233 A FLO can be swapped with another within the network, in the context 234 of a given service, at designated points, such as the service edge 235 routers. 237 Future considerations can also include the case, where FLO can be 238 potentially stacked based on the semantics of the current FLO. 240 2.4. FLO Termination 242 FL objects are terminated by a forwarder, when the NI in it matches 243 the forwarder's own NI. Here, we assume a forwarder to possibly have 244 many NIs such as domain-IDs, router-IDs or Interface-IDs. For 245 example, a forwarder (in a domain) identified as /att/santaclara can 246 process a FLO with its NI set to this router's domain name or to a 247 forwarder ID such as /att/santaclara/pop-x. Whenever a FLO is 248 terminated by the forwarder, depending on the network service 249 context, the forwarder can attach a new FLO, or conduct additional 250 processing on the request (e.g., re-resolution of the name to a new 251 FLO) based on the Interest parameters. The FLO can also include 252 optional policy metadata based on which FL objects can be swapped 253 within the network. 255 3. FLO Message Format 257 As a FLO is swappable in the network, it is proposed as a hop-by-hop 258 field in the optional body of the fixed header as shown in Figure 1. 259 The optional FLO includes attribute of type FL-Object, which contains 260 a name TLV identifying the NI (Figure 2). NI is a hierarchically 261 structured variable length name as defined in [5]. In addition to 262 the NI, optional FL metadata includes contextual information on the 263 application or the service to aid the network for invoking an 264 appropriate FL processing, such as trust validation of the FLO. 265 Optional security attributes, such as authentication information, can 266 be included depending on the specific use case scenarios, such as 267 secure name delegation information as discussed in [15], or signature 268 of the consumer. 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | CCN Fixed Header | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 / / 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type = FL-Object | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | NI TLV | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 / Optional FLO Metadata / 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 / Optional FLO Security Attributes / 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 / Interest Message Body / 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Figure 1: Interest message with hop-by-hop Optional Forwarding Label TLV 289 +----------------------+------------------+-----------------+ 290 | Forwarding Label | Meaning | Value | 291 +----------------------+------------------+-----------------+ 292 | NI TLV | Identifies an | Name TLV | 293 | | AS-ID/Gateway-ID/| | 294 | | Host-ID/Interface| | 295 | | -ID | | 296 +----------------------+------------------+-----------------+ 298 Figure 2: Network Identifier(NI) Definition 300 4. FLO Processing Rules 302 The following discussion is based on the assumption that all 303 forwarders must process the optional header fields. In the context 304 of CCN packet processing, FLO is only relevant when the decision to 305 forward the Interest message is to be made. In this draft, a default 306 policy applied by all CCN routers is to route using FLO if it exists 307 in the Interest message. Based on this, following considerations 308 apply: 310 o When an Interest with a FLO arrives at a CCN router, if the FLO is 311 trusted and the lookup based on NI in the FLO succeeds, the router 312 first checks if the NI matches any of its network names. If it 313 does, it is treated as a terminating flow. In this case, name 314 based lookup is conducted, which may return another FLO, or 315 results in a next hop forwarding face for the Interest packet. 316 For the non-terminating flow, the NI FIB lookup results in a next 317 hop, towards which the Interest is forwarded. 319 o If NI based on the FLO lookup fails, then the router can try to 320 forward the Interest based on the Interest AI. However if routing 321 based on the Interest AI fails, then the router could raise an 322 error condition and feedback the message to the previous hop with 323 the appropriate error code. 325 o The validation of FLO depends on the trust context, which is 326 indicated by the information inserted in the FLO by the ingress 327 domain router. In trusted networking scenarios, where the 328 applications and the network are managed by the same authority, 329 the ingress and the core routers can bypass the FLO validation. 330 In untrusted networking scenarios, the edge router may only 331 validate the FLO that is inserted by the sender and avoid re- 332 validations by successive forwarders. 334 5. PIT Processing Implications 336 FLO is only a routing directive, hence shouldn't affect the 337 functionality of the PIT in normal situations. However, including 338 FLO in the Interest could raise new questions, which need to be 339 answered. One such case is when there is a strong binding between an 340 AI and the NI either by the application or the network, which may 341 correspond to situations when multiple Interests arrive at a router 342 for the same AI but with different NIs. One possible approach in 343 this case is to treat each such (AI,NI) combination differently, 344 thereby saving them in the PIT, and by requiring the CO to piggyback 345 the NI to ensure proper matching. In the case, when the FLO is 346 swapped by an intermediate router, its PIT should save both the 347 incoming and the outgoing NI, and also the CO should be updated with 348 the appropriate NI to ensure matching of the PIT entries along the 349 previous hops. These considerations are similar to those elaborated 350 in [21] 352 6. Caching Implications 354 The caching function shouldn't be affected by this draft proposal. 355 Even if a FLO is included in the CO as discussed earlier, this is 356 expected to be removed before caching the content, as it only relates 357 to forwarding function. 359 7. Multiple Domain Scenario 361 In wide area network scenarios, Interests can cross multiple domains. 362 If a FLO is only trusted within the domain boundaries, then the FLO 363 is removed before the Interest is forwarded to the next domain, which 364 then upon entry, by the ingress of the next domain, inserts a new FLO 365 with the associated security attributes. However, if trust exists 366 between the neighboring domains to use the FLO inserted by the 367 previous domain (such as one through a trusted third party, and 368 validated based on the FLO security binding), then the intermediate 369 domains can avoid further FLO processing and use the FLO passed on by 370 the previous domains. 372 8. FLO Security 374 FLO security is related to the purpose it is used for and the control 375 plane mechanism used to manage it. Depending on the use case 376 scenario of the FL, appropriate security mechanisms should be applied 377 to secure the control and data planes to avoid exploitation of this 378 feature. 380 Generally, the major threat against the FLO approach is to manipulate 381 the relationship between the name and the FLO. Such manipulations 382 can happen in various scenarios, some of which are listed as follows: 383 (i) a malicious interceptor (who is acting as a publisher) 384 intentionally injects an incorrect mapping into the name resolution 385 system; (ii) a malicious interceptor (between the edge router and the 386 resolution server) manipulates the mapping sent back from the name 387 resolution system, when the edge router queries the mapping system; 388 (iii) a compromised intermediate router maliciously changes the FLO, 389 e.g., with the wrong FLO or an out-dated FLO; (iv) an untrusted 390 application injects an invalid FLO into the Interest message. 392 To achieve network level FLO security, appropriate mechanisms should 393 be applied to provide mapping provenance, mapping integrity and to 394 prevent replay attack to address these issues. The security 395 mechanisms applicable to the above discussed scenarios (i) and (ii) 396 are similar to the ones applied to secure other mapping systems such 397 as LISP [9] and DNS [11]. Scenario (iii) requires new security 398 mechanisms, and one such way is to enable a domain level trust 399 infrastructure so that the mapping between the name and the FLO can 400 be authenticated by the successive routers. 402 In untrusted environments, when a FLO is inserted in the Interest 403 message by the end hosts, appropriate authentication information 404 should also be included in the FLO to allow ingress routers to 405 optionally validate the delegation of the Interest AI to NI [15]. 407 Furthermore, additional security policies can be enabled by the 408 network to handle FL objects outside its trust domain. 410 9. Use Case Scenarios 412 Here we provide the discussions related to using FLOs in different 413 scenarios. 415 9.1. Handling Producer Mobility 417 In the literature, the different techniques to handle producer 418 mobility can be classified into the following two types: 420 o Application-based approach, where the application takes the 421 responsibility for announcing its reachability to the network and 422 triggering a network state change to enable Interest routing 423 towards the mobile producer. Most of the current proposals fall 424 under this category, and these include the following two 425 approaches: 1)The Kite proposal [20] implements an anchor based 426 approach where consumers and producers agree on an anchor point 427 based on external mechanisms and uses application initiated 428 (traced and tracing) Interests to handle the producer mobility; 429 2)The anchor-less proposal [22] is another application-based 430 approach wherein enhanced name-based routing and forwarding is 431 used to track the mobile producer. While these approaches allow 432 consumers and producers to work on a single name space, it raises 433 scalability concerns with increasing number of mobile nodes and 434 number of applications signaling into the network. As these 435 approaches introduce more signaling in the network, the 436 operational efficiency of packet forwarding is negatively affected 437 due to the state changes that have to be applied to ensure 438 optimized Interest routing towards the mobile producer. Another 439 potential security issue with these approaches is that it can be 440 prone to flooding attacks by malicious applications targeting 441 specific application names and impeding their normal operation. 443 o Network-based approach uses the late-binding technique [18][16], 444 wherein the reachability of the mobile node is handled by the 445 network. In this case, applications can explicitly request 446 mobility for a given namespace [16], with the network handling the 447 mobility by tracking its latest location in the network through a 448 name resolution system. At the same time, through coordination of 449 the old and new point-of-attachments (PoA) and in-band signaling 450 one can achieve minimal loss for a given Interest flow. The late- 451 binding technique uses AI/NI split that is only applied at the 452 PoAs, thereby avoiding challenges related to routing convergence 453 in the network due to producer mobility, while offering better 454 scalability when the number of mobile producers increases. Here, 455 the user entity (UE) registers a name prefix that requires 456 mobility with its current point-of-attachment (PoA). The PoA then 457 registers the mapping between the name prefix and the PoA's NI in 458 its local name resolution system. The domain then updates the 459 UE's home domain name resolution system with its current domain 460 LID. When a correspondent node expresses Interest for the name, 461 it is first resolved to the current UE domain by the home domain. 462 When the Interest enters the domain offering mobility service, it 463 is resolved again to the UE's current location. Furthermore PoA- 464 to-PoA signaling can be enabled to offer seamless forwarding of 465 Interests whenever a UE changes its PoA. In addition to 466 correcting the path stretch, the Interests re-routed from the old 467 PoA can be marked and re-routed to the new PoA with the new FL. 468 On the return path, the COs are also marked, this in-band marking 469 is used by the ingress PoA at the consumer's end to re-resolve the 470 mobile prefix to a new forwarding NI that would correct the path 471 stretch. 473 9.2. Handling Consumer Mobility 475 As ICN operates in a PULL mode, consumers operating over unreliable 476 wireless interfaces or during mobility-triggered events (such as 477 handovers) can recover from a lost Interest or Data response by re- 478 expressing it. There are some challenges associated with this 479 approach: (1) without appropriate cross-layer signaling between the 480 MAC and the ICN layer on the transient lower layer interface state or 481 network events such as handover, it is difficult to re-express 482 Interest in a timely manner; alternately ICN or the applications rely 483 on default Interest timeout value supplied by the application which 484 can be very inefficient, particularly for applications with real-time 485 requirements; (2) even in the case of a desired scenario, where 486 cross-layer signaling is enabled and an ICN Interest is re-expressed 487 soon after a loss is identified, the ability to retrieve the content 488 from a nearby cache depends on the engineered cache resources in the 489 ICN network, such as its size in the edge vs. core routers and the 490 cache management algorithms that exploit features such as content 491 popularity to offer the best user experience. In the worst case 492 scenario, these re-expressed Interests can only be satisfied by the 493 producer. Note that, this scenario is mostly true for a large set of 494 unpopular content types or for conversational applications, where 495 caching may be of no significant use. 497 The above concerns can be addressed using FLO to support seamless 498 consumer mobility. The process is similar to producer mobility, but 499 in this situation, FLO is used to redirect Data objects from the 500 previous PoA to the new PoA. The trigger for this redirection 501 requires to identify the set of Interests in the PIT, which have been 502 affected by the consumer mobility. To support this, the PIT state at 503 the PoAs are expanded to save the ID of the UE which is signaled in 504 the Interest. However, this ID is not carried beyond the PoA. In 505 addition, the PIT state is also associated with the attachment state 506 of the consumer device to the current PoA. During the handover, 507 consumer UE signals to the previous PoA information about the new PoA 508 (such as the NI associated with the new PoA), which is then applied 509 to the PIT entries associated with this consumer along with the 510 change of the attachment state. When the Data objects requested by a 511 previously connected consumer, which performed handover to attach to 512 another PoA, arrives at the previous PoA, the NI information in the 513 PIT is used to create the FLO, which is then appended to the Data 514 header and forwarded like an Interest using the FIB. These Data 515 objects are also marked, so that the set of routers along the path 516 towards the new PoA are able to distinguish between these packets and 517 regular Data objects. These Data objects could pass through a path 518 segment that it has already passed through in the reverse direction 519 prior to arriving at the previous PoA. In that case they should not 520 be cached by any router belonging to that path segment, but can be 521 cached in the routers that are part of the path segment receiving 522 this Data object for the first time, by first removing the FLO and 523 subjecting it to the local caching policies. When this Data arrives 524 at the current PoA, it is cached applying prioritized caching 525 policies considering its arrival as a result of a handover, which is 526 then used to respond to a re-expressed Interest. Alternately, the 527 Data objects forwarded from the previous PoA can also include the 528 consumer ID, which can then be used by the current PoA to PUSH it to 529 the consumer UE, similar to how it would be at the previous PoA had 530 the consumer still connected to it. 532 9.3. Manifests 534 The FL objects can also be used to support the retrieval of nameless 535 objects [17]. Using the current manifest proposal [10] a consumer 536 receives a manifest with the ContentObjectHashIDs and their 537 respective NI information. A consuming application uses the NI as a 538 routeable content name, while the ContentObjectHashID is used as a 539 HashID restriction parameter. Multiplexing the Interest name field 540 as an AI and also as an NI has the following consequences: (1) a 541 forwarder cannot distinguish between Interest packets containing AI 542 or NI in the name field, as the protocol doesn't differentiate these 543 two names; (2) it complicates Interest processing where two different 544 Interest processing logic needs to be applied with Interests with or 545 without the hash-id. In this situation, routers should first checks 546 for the presence of ContentObjectHashID and uses it to index the 547 Interest based on it rather than using it as a NI; (3) more 548 complications arise if an Interest packet arrives with two IDs i.e. a 549 ContentObjectHashID as the hash restriction and the ID as the content 550 name, in which case, one of them should seek precedence over the 551 other. 553 The above issues can be avoided through the use of the 554 ContentObjectHashID as the content name and the NI in the FLO. In 555 this case, a forwarder will always index the pending Interest table 556 or the cache as expected on the content name. The routing decision 557 then would be based on the FLO depending on the routing policy in the 558 forwarder. This also avoids the situation of dealing with two IDs in 559 the Interest packet, i.e. the application has to choose either ID or 560 ContentObjectHashID as the content ID. 562 A possible high level forwarding logic for the edge/core router to 563 support nameless objects based on the above discussion is presented 564 in Figure 3. Here edge router can also be a gateway node. 566 Begin 568 if Edge_Router 569 If Interest arrives on a face with a flat AI 570 Then check for the presence of FLO 571 If FLO is present 572 Then use the NI in the FLO for Interest forwarding 573 Else (If there is no FLO) 574 If policy allows, resolve the flat AI with an NRS to obtain a FLO 575 Use the FLO to route the Interest 576 End 577 End 578 End 580 If the Interest arrives with a routeable AI 581 If FLO is present 582 Then use the AI for forwarding and Remove the FLO 583 Else (if there is no FLO) 584 Match Interest AI with name policy for e.g. mobility or interest routing optimization 585 If a name policy for resolution exists 586 Then network resolution service is invoked on the AI, which returns a FLO 587 Use the FLO to direct the Interest to the appropriate next hop 588 End 589 End 590 End 592 End 594 if Core_Router 595 if Interest arrives with a FLO 596 Use the NI for forwarding 597 Else if Interest is with a Routeable AI 598 Use the name for forwarding 599 End 600 End 602 Figure 3: Forwarding logic to support flat and routeable AI at the edge router 604 We discuss security implications of using AI and FLO in the Interest 605 message depending on the ID type. 607 o Case 1 - ContentObjectHashId with FLO: This use case is a 608 straightforward simplification of what is being proposed in [17]. 609 Here, the NI is included within the FLO and the 610 ContentObjectHashId is used as the name, so this shouldn't 611 introduce any new security concerns. This holds good for both 612 application and network based FLO insertion. 614 o Case 2 - Routeable AI with FLO: For UE based FLO insertion, this 615 scenario can cause cache poisoning in the absence of a signature 616 check enforcement in the forwarders. For the case when FLO is 617 managed within a trusted domain, the security implications are 618 discussed in Section 8. 620 9.4. Supporting Conversational Sessions 622 FLO can be used to bind a service AI to a given location in the 623 network, so that the consumer's session is correctly directed to the 624 service instance keeping state of the conversation, e.g. [2]. Using 625 AI-based anycast routing cannot guarantee this, as the name prefix 626 state used for forwarding would treat all possible instances equally. 627 One way to mitigate this, while compromising efficiency, would be to 628 introduce a load balancer, through which all such Interest flows are 629 routed. 631 9.5. Interest Routing Optimization 633 Networks, which host their own or third party contents/services can 634 benefit from the ability to handle Interest routing logic in its 635 domain opportunistically. When an Interest seeking a specific 636 content or service enters a network domain, the ingress router can 637 redirect the Interest to the closest cache point or service location. 639 9.6. Routing Scalability 641 As discussed in [15], NI based routing can address routing 642 scalability, as the number of ASs are many orders less than the 643 number of information objects. This reduces the forwarding table in 644 the DFZ to the order of number of ASs in the Internet. In addition, 645 unlike [15], this proposal offers the feature of swapping FLO and 646 late-binding offering more flexibility and efficiency towards 647 scalability and routing optimization. 649 10. Security Considerations 651 The security implication of having FLO in the Interest message has 652 been discussed in Section 8. 654 11. Conclusions 656 Following the discussion in [1], this draft proposes extensions to 657 the CCN protocol to introduce NI namespace in the Interest message 658 which can offer several benefits which include routing optimization 659 and scalability, off path caching benefits, handling both consumer 660 and producer mobility and service affinity for conversational 661 communications. 663 12. Informative References 665 [1] Azgin, A. and R. Ravindran, "Enabling Network Identifier 666 (NI) in Information Centric Networks to Support Optimized 667 Forwarding", draft-azgin-icnrg-ni-02 (work in progress), 668 July 2017. 670 [2] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange 671 Protocol Version 1.0", draft-wood-icnrg-ccnxkeyexchange-02 672 (work in progress), July 2017. 674 [3] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 675 Format", draft-irtf-icnrg-ccnxmessages-06 (work in 676 progress), October 2017. 678 [4] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 679 Chaining (SFC) Architecture", RFC 7665, 680 DOI 10.17487/RFC7665, October 2015, 681 . 683 [5] CCN Wire format, CCNX1., "http://www.ietf.org/id/ 684 draft-mosko-icnrg-ccnxmessages-00.txt.", 2013. 686 [6] Nikander, P., Gurtov, A., and T. Henderson, "Host identity 687 protocol (HIP): Connectivity, mobility, multi-homing, 688 security, and privacy over IPv4 and IPv6 networks", IEEE 689 Communications Surveys and Tutorials, pp: 186-204, 2010. 691 [7] Atkinson, R., "An Overview of the Identifier-Locator 692 Network Protocol (ILNP)", Technical Report, University 693 College London, 2005. 695 [8] LISP, RFC6380., 696 "https://tools.ietf.org/html/draft-ietf-lisp-sec-07.", 697 2014. 699 [9] LISP-Security, LISP-SEC., 700 "https://tools.ietf.org/html/draft-ietf-lisp-sec-07.", 701 2014. 703 [10] CCNx, Manifest., "http://www.ccnx.org/pubs/ 704 draft-wood-icnrg-ccnxmanifests-00.html.", 2015. 706 [11] DNS-SEC, RFC4033., "DNS Security Introduction and 707 Requirements.", 2005. 709 [12] FP7-ICT-2009-5-257448/D.B.3, "SAIL: Scalable and Adaptable 710 Internet Solutions", 2013, . 713 [13] Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 714 GQ. Wang, "5G-ICN : Delivering ICN Services over 5G using 715 Network Slicing.", IEEE Communication Magazine, May, 2017. 717 [14] Adhatarao, S., Chen, J., Arumaithurai, M., Fu, X., and K. 718 Ramakrishnan, "Comparison of Naming Schema in ICN.", IEEE 719 LANMAN, 2016. 721 [15] Afanasyev, A., "Map-and-Encap for Scaling NDN Routing.", 722 NDN Technical Report ndn-004-02, 2015. 724 [16] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang, 725 "Seamless Producer Mobility as a Service in Information 726 Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 727 2016. 729 [17] Mosko, M., "Nameless Objects.", IETF/ICNRG, Paris 730 Interim 2016, 2016. 732 [18] Azgin, A., Ravindran, R., and G. Wang, "A Scalable 733 Mobility-Centric Architecture for Named Data Networking.", 734 ICCCN (Scene Workshop) , 2014. 736 [19] Cisco System Inc., CISCO., "Cisco visual networking index: 737 Global mobile data traffic forecast update.", 2009-2014. 739 [20] Zhang, Y., Zhang, H., and L. Zhang, "Kite: A Mobility 740 Support Scheme for NDN.", NDN, Technical Report NDN-0020 , 741 2014. 743 [21] CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/ 744 ccnx-mosko-labelforwarding-01.txt.", 2013. 746 [22] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 747 Pau, G., and X. Zeng, "Anchor-less Producer Mobility in 748 ICN.", ICN, Sigcomm, 2015 , 2015. 750 [23] NSF FIA project, MobilityFirst., 751 "http://www.nets-fia.net/", 2010. 753 Authors' Addresses 755 Ravishankar Ravindran 756 Huawei Technologies 757 2330 Central Expressway 758 Santa Clara, CA 95050 759 USA 761 Email: ravi.ravindran@huawei.com 763 Asit Chakraborti 764 Huawei Technologies 765 2330 Central Expressway 766 Santa Clara, CA 95050 767 USA 769 Email: asit.chakraborti@huawei.com 771 Aytac Azgin 772 Huawei Technologies 773 2330 Central Expressway 774 Santa Clara, CA 95050 775 USA 777 Email: aytac.azgin@huawei.com