idnits 2.17.1 draft-ravi-icnrg-ccn-forwarding-label-01.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 a Security Considerations 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 8 instances of too long lines in the document, the longest one being 37 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 (July 17, 2017) is 2467 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '6' on line 626 looks like a reference -- Missing reference section? '7' on line 631 looks like a reference -- Missing reference section? '8' on line 635 looks like a reference -- Missing reference section? '23' on line 688 looks like a reference -- Missing reference section? '12' on line 647 looks like a reference -- Missing reference section? '1' on line 605 looks like a reference -- Missing reference section? '2' on line 610 looks like a reference -- Missing reference section? '14' on line 655 looks like a reference -- Missing reference section? '13' on line 651 looks like a reference -- Missing reference section? '4' on line 618 looks like a reference -- Missing reference section? '3' on line 614 looks like a reference -- Missing reference section? '15' on line 659 looks like a reference -- Missing reference section? '5' on line 623 looks like a reference -- Missing reference section? '21' on line 681 looks like a reference -- Missing reference section? '9' on line 638 looks like a reference -- Missing reference section? '11' on line 644 looks like a reference -- Missing reference section? '20' on line 677 looks like a reference -- Missing reference section? '22' on line 684 looks like a reference -- Missing reference section? '18' on line 670 looks like a reference -- Missing reference section? '16' on line 662 looks like a reference -- Missing reference section? '17' on line 667 looks like a reference -- Missing reference section? '10' on line 641 looks like a reference -- Missing reference section? '19' on line 674 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 24 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: January 18, 2018 Huawei Technologies 6 July 17, 2017 8 Forwarding-Label support in CCN Protocol 9 draft-ravi-icnrg-ccn-forwarding-label-01 11 Abstract 13 The objective of this proposal is to enable ID and Locator namespace 14 split in the CCN protocol that has several applications such as 15 towards Interest routing optimization, seamless mobility and 16 providing mobility as a service, conversational session support, 17 handling indirections in manifests, and routing scalability. We 18 enable this through the notion of a forwarding-label object (FLO), 19 which is an optional hop-by-hop payload in the Interest message with 20 a topological name, which identifies a network domain, a router or a 21 host. FLO can be inserted within the Interest message by the 22 applications or by the network. FLO can be interpreted by the 23 network in multiple ways, for instance, to terminate the message or 24 to swap it with a new FLO based on the service context. Furthermore, 25 depending on the application and trust context, FLO can be subjected 26 to policy based actions by the forwarders, such as invoking security 27 verification or enabling other service-centric FLO management 28 actions. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 18, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. ID-Locator Namespace Split in CCN . . . . . . . . . . . . . . 2 65 2. Forwarding-Label Object Proposal . . . . . . . . . . . . . . 5 66 2.1. FLO Naming . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2. FLO Insertion . . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. FLO Swapping . . . . . . . . . . . . . . . . . . . . . . 6 69 2.4. FLO Termination . . . . . . . . . . . . . . . . . . . . . 6 70 3. FLO Message Format . . . . . . . . . . . . . . . . . . . . . 6 71 4. FLO Processing Rules . . . . . . . . . . . . . . . . . . . . 7 72 5. Implications on PIT Processing . . . . . . . . . . . . . . . 8 73 6. Implications on Caching . . . . . . . . . . . . . . . . . . . 8 74 7. Multiple Domain Scenario . . . . . . . . . . . . . . . . . . 9 75 8. FLO Security . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Handling Producer Mobility . . . . . . . . . . . . . . . 10 78 9.2. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 11 79 9.3. Support for Conversational Sessions . . . . . . . . . . . 13 80 9.4. Interest Routing Optimization . . . . . . . . . . . . . . 13 81 9.5. Routing Scalability . . . . . . . . . . . . . . . . . . . 13 82 10. Informative References . . . . . . . . . . . . . . . . . . . 14 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. ID-Locator Namespace Split in CCN 87 In the context of ICN/CCN, we define Identifier and Locator as 88 follows: 90 o Identifier (ID) is a persistent secure or non-secure flat-ID or a 91 hierarchical name assigned to a content, device or service. If 92 the ID is secure, then there is a direct relationship between the 93 ID and the key of the principal. Otherwise, a binding is provided 94 by a third party using the certificate mechanism or the web-of- 95 trust model. Generally the identifier space is managed by 96 services and applications. 98 o Locator ID (LID), on the other hand, is a topological name 99 assigned to a network entity, which can be a network/domain, a 100 router, a host or an interface. Generally, locator space is 101 assigned and managed by the network administrators. Within the 102 context of this document, Locator and Locator ID carry the same 103 meaning and refer to a topological identifier. 105 We discuss here the motivations behind the need for separating the 106 persistent name (ID) and the locator ID (LID) in the Interest message 107 within the context of CCN, and present a proposal to achieve this. 109 The advantages of ID/Locator split have been extensively studied in 110 the literature and it has been part of many host-centric protocols 111 such as HIP [6], ILNP [7], and LISP [8]. However, in this document, 112 we refer to these terms within the context of Information-centric 113 networks, where the network layer uses name(s) to resolve a requested 114 content (or service or host) to a given location, while providing 115 mechanisms to cache or apply computation on the named (data) objects 116 depending on the context (such as the requirements indicated within 117 the Interest message). 119 Within this ID/Locator split context, ICN architectures such as 120 MobilityFirst [23], NetInf [12] assume an explicit representation for 121 Identifiers and Locators within their architectures, considering 122 their use of non-aggregate-able flat IDs; while the CCN/NDN 123 architecture assumes the aggregate-ability of names within its 124 architecture, thereby applying its use on routing and forwarding. We 125 have argued in [1], the problems associated with the use of name 126 prefixes for routing, which include the challenges related to 127 scalability, loss of name aggregate-ability when data and services 128 are replicated, handling of mobility, and situations where 129 conversational sessions are required for service level authentication 130 and authorization [2]. These issues have also been argued 131 quantitatively in [14], including the scenario, where there is an 132 explosion in the namespace when there are many different ways of 133 naming an entity because of the rich context associated with it. 134 Therefore, providing the ID-LID separation distinctly in the protocol 135 offers the following advantages, which are also discussed in detail 136 in [1]: 138 o CCN applications request persistent IDs for contents, services or 139 hosts; while their resolution is handled through per-hop name- 140 based routing by a CCN forwarder using unicast, anycast, or 141 broadcast mechanisms, routing scalability is handled using name 142 prefixes. This model can introduce problems when the named entity 143 is mobile, migrated, or replicated; as the names have to be 144 announced in the routing control plane, which can in turn 145 introduce routing convergence issues and scalability challenges. 146 Introducing an ID/Locator namespace split within the architecture, 147 which uses a name resolution service, shall address the routing 148 challenges due to dynamic entities, while also improving the 149 routing scalability (due to limiting the state in the core 150 Internet routers to the set of topological names). 152 o ID and Locator namespaces are managed by different entities. IDs 153 are managed by applications and services, hence are relevant in 154 the service layer; while Locators are assigned to the networked 155 entity, hence are managed by network administrators. Locators map 156 to network domains or specific network elements, through which the 157 named entity is locally/globally reachable. The relationship 158 between IDs and Locators is established during namespace 159 registration (or namespace publishing) phase, and managed by a 160 separate name resolution service. The distinction between ID and 161 Locator in CCN allows an application to manage its own namespace 162 and to not be restricted by the naming rules imposed by the 163 network. 165 o Allowing the representation of IDs and Locators within an Interest 166 message offers many advantages in CCN, especially when a 167 centralized control is applied, such as using a service 168 orchestration framework [13]. This enables efficiency and 169 flexibility through service-centric name resolution, routing, and 170 mobility, service chaining [4] and routing scalability. 172 Considering the above requirements, we propose a Forwarding-label 173 object (FLO), which includes a locator along with the encapsulated 174 security bindings; and provides the flexibility to forward Interests 175 on a name other than the one provided within the original Interest 176 message, with the ability to terminate or swap it in the network 177 during forwarding. Note that, to effectively handle the ID/Locator 178 mapping, we require a control plane infrastructure and appropriate 179 network layer security functions to prevent malicious usage. 180 Specific control plane or security mechanisms to support secure ID/ 181 Locator mapping is out of the scope of this document, as many 182 techniques can be used towards achieving this objective. This draft 183 specifically presents various considerations towards the management 184 of FLOs, such as: (i) FLO insertion/modification/deletion, (ii) 185 processing of FLO by a CCN forwarder, (iii) PIT/CS implications for 186 Interests carrying FLOs, (iv) packet format for the FLO Interest, and 187 (v) security/trust considerations. We also provide a discussion on 188 the various application scenarios for the use of FLOs. 190 2. Forwarding-Label Object Proposal 192 In the following, we discuss various aspects to FLO in regards to its 193 semantics and management. 195 2.1. FLO Naming 197 We assume the FLO to consist of three components: LID, service 198 specific metadata, and security attributes for authentication. LIDs 199 are hierarchically structured topological names, where the names 200 follow the format defined in [3]. Security attributes are optional, 201 and may include validation payload and algorithm as discussed in [3]. 203 2.2. FLO Insertion 205 Insertion of FLOs within an Interest message can be done either by 206 the application that requests the named entity or by the network 207 routers that forward the Interest messages. 209 In some specific scenarios, application logic may use --within the 210 Interest message-- both an FLO and an ID. Such action may also be 211 triggered by a feedback from the network, for instance, due to a 212 routing failure of an Interest using solely IDs, as explained in 213 [15]. In such situations, forwarders, which process the traffic 214 generated by applications outside their trust domain, would require a 215 way to validate the FLOs. One possible approach to ensure trust in 216 such situations is discussed in [15], where a trust binding is 217 provided between an ID and a LID as a link object, which can be 218 validated by the forwarder. To avoid the possibility of an FLO 219 misuse, a default policy for the network may be to ignore the 220 inserted FLOs from untrusted applications and to choose to route only 221 by the content IDs. Another possible policy to implement in this 222 case is for the network to insert FLOs, which is explained next. 224 Another possibility would be to insert the FLOs by the network, for 225 which the FLO insertion would be triggered at the ingress (or 226 service) routers of the network domain. Network-insertion of an FLO 227 to an incoming Interest message may be triggered based on several 228 considerations, including: (i) the interface, over which the Interest 229 message is received; (ii) whether the Interest message satisfies the 230 flow service profiles that are imposed by the network administrator 231 at the ingress routers; (iii) the default behavior by the network, if 232 it chooses to route only on LIDs. Accordingly, service profile 233 matching actions may include matching an Interest name to a set of 234 service prefixes that are triggered by certain markings or metadata 235 carried within the Interest message, such as the context-IDs. Here, 236 context IDs may refer to service, network, trust, or location related 237 metrics or information. Note that, a FLO that is inserted within the 238 trust domain may not require security validation. 240 2.3. FLO Swapping 242 An FLO can be swapped by another FLO within the network, in the 243 context of a given service, at the designated network points, which 244 typically include the service edge routers of the network. 246 Future considerations also include the case, where FLOs are 247 potentially stacked based on the semantics of the current FLO. 249 2.4. FLO Termination 251 FLOs are terminated by a forwarder, when the LID carried within 252 matches the forwarder's own LID. Here we assume a forwarder to 253 possibly have multiple LIDs that correspond to domain-IDs, router-IDs 254 or Interface-IDs. For example, a forwarder (in a domain) identified 255 as /company/geoloc can process an FLO, for which the LID is set to 256 this router's domain name or to a forwarder ID such as 257 /company/geoloc/PoP*. Whenever an FLO is terminated by the forwarder, 258 it can attach a new FLO depending on the service context, or conduct 259 additional processing (such as re-resolution of the ID to a new FLO) 260 based on the Interest parameters (and again depending on the service 261 context). An FLO can also include optional policy metadata, based on 262 which FLOs can be swapped in the network. 264 3. FLO Message Format 266 As the FLOs are swappable in the network, FLO is proposed as an hop- 267 by-hop field within the optional body of the fixed header as shown in 268 Figure 1. The optional FLO includes an attribute of type FL-Object, 269 which contains a name TLV identifying the LID (Figure 2). LID (or 270 FLO-LID), here, is a hierarchically structured variable length name 271 as defined in [5]. In addition to the LID, the optional FLO metadata 272 includes contextual information for the application or the service to 273 aid the network in invoking an appropriate FLO processing, such as 274 trust validation for the FLO. Optional security attributes, such as 275 the authentication information, can be included depending on the 276 specific use case scenarios, which may include secure name delegation 277 information as discussed in [15], or the signature of the consumer. 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | CCN Fixed Header | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | | 283 / / 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type = FL-Object | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | LID TLV | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 / Optional FLO Metadata / 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 / Optional FLO Security Attributes / 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 / Interest Message Body / 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 1: Interest message with hop-by-hop Optional Forwarding-Label TLV 298 +----------------------+------------------+-----------------+ 299 | Forwarding-Label | Meaning | Value | 300 +----------------------+------------------+-----------------+ 301 | LID TLV | Identifies an | Name TLV | 302 | | AS-ID/Gateway-ID/| | 303 | | Host-ID/Interface| | 304 | | -ID | | 305 +----------------------+------------------+-----------------+ 307 Figure 2: Locator-ID (LID) Definition 309 4. FLO Processing Rules 311 The following discussion is based on the assumption that all 312 forwarders must process the optional header fields. Within the 313 context of CCN packet processing, FLO is only relevant when the 314 decision to forward the Interest message is to be made. In this 315 draft, the default policy to be applied by all the CCN routers is to 316 route on FLOs, if an FLO exists in the Interest message. Based on 317 this policy, the following considerations may apply: 319 o When an Interest message with an FLO arrives at a CCN router, if 320 the FLO is trusted and the lookup based on LID succeeds, the 321 router first checks if the LID matches any of the network names 322 associated with the receiving router. If there is match, received 323 Interest is treated as one that terminates flow, in which case, a 324 name based lookup is conducted. The lookup at the router may 325 return another FLO, or may result in a forwarding face for the 326 Interest message towards the next hop. If there is no match, 327 which suggests a non-terminating flow case, the FIB lookup on LID 328 would result in a next hop towards which the Interest needs to be 329 forwarded. 331 o If the lookup based on LID fails, then the router can try to 332 forward the Interest based on the Interest ID. In the case, where 333 routing based on the Interest ID fails, then the router can raise 334 an error condition and feedback the error message to the previous 335 hop with the appropriate error code. 337 o FLO-validation depends on the trust context, which is indicated by 338 the information inserted by the ingress domain router within the 339 FLO. In trusted forwarding scenarios, where the applications and 340 the network are managed by the same authority, the ingress and the 341 core routers can bypass the FLO validation. In untrusted 342 forwarding scenarios, the edge router may only validate the FLO 343 that is inserted by the sender and avoid re-validations by the 344 successive forwarders. 346 5. Implications on PIT Processing 348 As FLO is considered as a routing directive, its presence shouldn't 349 affect the functionality of the PIT and its processing under normal 350 situations. However, including FLO within the Interest message could 351 give rise to new questions, which need to be addressed, based on 352 application or network requirements. One such scenario is when there 353 is an implicit binding between the ID and the LID (i.e., multiple 354 Interests arrive at a router carrying the same ID but with different 355 LIDs). One possible approach to handle such case is to treat each 356 such combination of (ID,LID) differently, thereby saving them both in 357 the PIT as separate entries. However, this also requires the content 358 object to piggyback the LID to ensure proper matching with the stored 359 PIT entry. In the case, when the FLO is swapped by the intermediate 360 routers, the PIT should save both the incoming and the outgoing FLOs, 361 and also the content object should be updated with the appropriate 362 FLO to ensure matching of the stored PIT entries along the previous 363 hops. These considerations are similar to those elaborated in [21]. 365 6. Implications on Caching 367 Caching function shouldn't be affected by this draft proposal. Even 368 if the FLOs are included in the content object as discussed earlier, 369 routers are expected to remove it before caching the content. 371 7. Multiple Domain Scenario 373 In wide area networking scenarios, Interest message can cross 374 multiple domains. If an FLO is only trusted within the domain 375 boundaries, then the FLO is removed before the Interest message is 376 forwarded to the next domain, which then, upon entry, inserts a new 377 FLO with the associated security attributes at the ingress of the 378 next domain. However, in the case when there exists trust between 379 the domains, such as one through a trusted third party (validated 380 based on the FLO security bindings), to use the FLO inserted by the 381 previous domain, the intermediate domains can avoid further FLO 382 processing and use the FLO passed on by the previous domains. 384 8. FLO Security 386 FLO security is related to the purpose it is used for and the control 387 plane mechanism used to manage it. Depending on the use case 388 scenario for the FLO, appropriate security mechanisms should be 389 applied to secure the control and data plane functionalities and 390 operations to avoid exploitation of this feature. 392 Generally, the major threat against the FLO approach is to manipulate 393 the relationship between the name and the FLO. Such manipulations 394 can happen in various scenarios, some of which are listed as follows: 395 (i) a malicious interceptor (acting as a publisher) may intentionally 396 inject an incorrect mapping into the name resolution system; (ii) a 397 malicious interceptor (between the edge router and the resolution 398 server) may manipulate the mapping sent back from the name resolution 399 system when the edge router queries the mapping system; (iii) a 400 compromised intermediate router may maliciously change the FLO, for 401 instance, with a wrong FLO or an out-dated FLO; and (iv) an untrusted 402 application may inject an invalid FLO into the Interest message. 404 To achieve network level FLO security, appropriate mechanisms should 405 be applied to provide mapping provenance and mapping integrity and to 406 prevent replay attack to address these issues. The security 407 mechanisms applicable to the above discussed scenarios (i) and (ii) 408 are similar to ones applied to secure other mapping systems such as 409 LISP [9] and DNS [11]. Scenario (iii) requires new security 410 mechanisms, one such way is to enable a domain level trust 411 infrastructure so that the mapping between the name and the FLO can 412 be authenticated by the successive routers. 414 In untrusted environments, when an FLO is inserted within the 415 Interest message by the end hosts, appropriate authentication 416 information should also be included in the FLO to allow ingress 417 routers to optionally validate the delegation of the Interest ID to 418 LID [15]. Furthermore, additional security policies can be enabled 419 by the network to handle FLOs outside its trust domain. 421 9. Use Case Scenarios 423 Here we provide the discussions related to using FLOs in different 424 scenarios. 426 9.1. Handling Producer Mobility 428 In the literature, we can classify the techniques to handle producer 429 mobility into two main categories as application-based approaches and 430 network-based approaches. 432 o In application-based approach, the application takes the 433 responsibility for announcing its reachability to the network and 434 triggering a network state change to enable Interest message 435 routing towards the mobile producer. Most of the current 436 proposals fall under this category, and these include the 437 following two approaches: (i) Kite proposal [20], which implements 438 an anchor based approach where consumers and producers agree on an 439 anchor point based on external mechanisms and uses application 440 initiated (traced and tracing) Interests to handle the producer 441 mobility; (ii) Anchor-less proposal [22], which is another 442 application-based approach wherein enhanced name-based routing and 443 forwarding is used to track the mobile producer. While these 444 approaches allow consumers and producers to work on a single name 445 space, their use may raise scalability concerns with increasing 446 number of mobile nodes and number of applications signaling into 447 the network. As these approaches introduce additional signaling 448 in the network, the operational efficiency of packet forwarding is 449 negatively affected due to state changes that have to be applied 450 to ensure optimized Interest routing to the mobile producer. 451 Another potential issue with these approaches is security, as they 452 can be prone to flooding attacks by malicious applications 453 targeting specific application names and impeding their normal 454 operation. 456 o In network-based approach, late-binding technique [18][16] is 457 used, wherein the reachability of the mobile node is handled by 458 the network. In this case, applications can explicitly request 459 mobility for a given name space [16], with the network handling 460 the mobility by tracking its latest location in the network 461 through a name resolution system. At the same time, through 462 coordination of the old and new point-of-attachments (PoA) and in- 463 band signaling, one can achieve minimal loss for a given Interest 464 flow. The late-binding technique uses ID/Locator split that is 465 only applied at the PoAs, thereby avoiding challenges related to 466 routing convergence in the network due to producer mobility, while 467 offering better scalability performance as the number of mobile 468 producers increases. In this approach, a user entity (UE) 469 registers a name prefix that requires mobility support with its 470 current point-of-attachment (PoA). The PoA then registers the 471 mapping between the name prefix and the PoA's locator in its local 472 name resolution system. The domain then updates the UE's home 473 domain name resolution system with its current domain LID. When a 474 correspondent nodes expresses Interest for the name, it is first 475 resolved to the current UE domain by the home domain. When the 476 Interest enters the domain offering mobility service, it is 477 resolved again to the UE's current location. Furthermore PoA-to- 478 PoA signaling can be enabled to offer seamless forwarding of 479 Interests whenever an UE changes its PoA. In addition to 480 correcting the path stretch, the Interests re-routed from the old 481 PoA can be marked and re-routed to the new PoA with the new FL. 482 On the return path, the content objects are also marked, and this 483 in-band marking used by the ingress PoA at the consumer's end 484 results in re-resolving the mobile prefix to a new forwarding 485 locater that would correct the path stretch. 487 9.2. Manifests 489 The FLOs can also be used to support the retrieval of nameless 490 objects [17]. Using the current manifest proposal [10] a consumer 491 receives a manifest with the ContentObjectHashIDs and their 492 respective locator information. A consuming application uses the 493 locator as a routable content name, while the ContentObjectHashID is 494 used as a HashID restriction parameter. Multiplexing the Interest 495 name field as an ID and also as a LID has the following consequences: 496 (i) a forwarder cannot distinguish between Interest messages 497 containing ID or LID in the name field, as the protocol does not 498 differentiate between these two names; (ii) it complicates Interest 499 message processing, where two different Interest processing logics 500 need to be applied on Interests (with or without the hash-id). In 501 this situation, routers should first check for the presence of 502 ContentObjectHashID and uses it to index the Interest based on it, 503 rather than using the locator name; (iii) more complications may 504 arise, if an Interest packet arrives with two IDs, for example, a 505 ContentObjectHashID as the hash restriction and the ID as the content 506 name, in which case, one of them should seek precedence over the 507 other. 509 The above issues can be avoided through the use of 510 ContentObjectHashID as the content name and the locator as LID with 511 the FLO. In this case, a forwarder will always index the pending 512 Interest table or the cache as expected on the content name. The 513 routing decision would then be based on the FLO, depending on the 514 routing policy implemented by the forwarder. This also avoids the 515 situation of dealing with two IDs in the Interest message, where the 516 application has to choose either the ID or the ContentObjectHashID as 517 the content ID. 519 A possible high level forwarding logic for the edge/core router to 520 support nameless objects based on the above discussion is presented 521 in Figure 3. Here, edge router can also be a gateway node. 523 Begin 525 if Edge_Router 526 If Interest arrives on a face with a flat-ID 527 Then check for the presence of FLO 528 If FLO is present, use the LID in the FLO for Interest forwarding 530 If there no FLO 531 If policy allows, resolve the flat-ID with a NRS to obtain an FLO 532 Use the FLO to route the Interest 534 End 536 If the Interest arrives with a routeable ID 537 If there is FLO 538 Then use the ID for forwarding and Remove the FLO 540 If there is no FLO 541 Match Interest ID with name policy for e.g. mobility or interest routing optimization 542 If a name policy for resolution exists 543 Then network resolution service is invoked on the ID which returns an FLO 544 Use the FLO to direct the Interest to the appropriate next hop 545 End 546 End 548 if Core_Router 549 if Interest arrives with an FLO 550 Use the LID for forwarding 551 Else if Interest is with a Routeable ID 552 Use the name for forwarding 553 End 555 Figure 3: Forwarding logic to support flat-ID and routeable ID at the edge router 557 We next discuss the security implications of using IDs and FLOs 558 within the Interest message, depending on the ID type, as follows: 560 o Case 1 - ContentObjectHashId with FLO: This use case is a 561 straightforward simplification of what is being proposed in [17]. 562 Here, the locator is included within the FLO and the 563 ContentObjectHashId is used as the name, so this shouldn't 564 introduce any new security concerns. This holds true for both 565 application and network based FLO insertions. 567 o Case 2 - Routable ID with FLO: For UE based FLO insertion, this 568 scenario can cause cache poisoning in the absence of signature 569 check enforcement at the forwarders. For the case, when FLO is 570 managed within a trusted domain, the security implications are 571 discussed in Section 8. 573 9.3. Support for Conversational Sessions 575 FLO can be used to bind a service ID to a given location in the 576 network, so that the consumer's session is correctly directed to the 577 service instance keeping state of the conversation. An example for 578 this is discussed in [2]. Using an ID-based anycast routing cannot 579 guarantee this as the name prefix state used for forwarding would 580 treat all possible instances equally. One way to mitigate this, 581 which may compromise efficiency, would be to introduce a load 582 balancer, through which all such Interest flows are routed. 584 9.4. Interest Routing Optimization 586 A network domain, which hosts its own or third party contents/ 587 services, can benefit from the ability to handle Interest routing 588 logic within its domain opportunistically. When an Interest message 589 seeking a specific content or service enters a network domain, the 590 ingress router can redirect the Interest to the closest cache point 591 or service location. 593 9.5. Routing Scalability 595 As discussed in [15], locator-based routing can address the routing 596 scalability, as the number of ASs are many orders less than the 597 number of information objects. Doing so would reduce the forwarding 598 table in the DFZ to the order of the number of ASs in the Internet. 599 In addition, unlike [15], this proposal offers the features of 600 swapping FLOs and late-binding, which may lead to more flexibility 601 and efficiency towards scalability and routing optimization. 603 10. Informative References 605 [1] Azgin, A. and R. Ravindran, "Enabling Network Identifier 606 (NI) in Information Centric Networks to Support Optimized 607 Forwarding", draft-azgin-icnrg-ni-01 (work in progress), 608 May 2017. 610 [2] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange 611 Protocol Version 1.0", draft-wood-icnrg-ccnxkeyexchange-02 612 (work in progress), July 2017. 614 [3] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 615 Format", draft-irtf-icnrg-ccnxmessages-04 (work in 616 progress), March 2017. 618 [4] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 619 Chaining (SFC) Architecture", RFC 7665, 620 DOI 10.17487/RFC7665, October 2015, 621 . 623 [5] CCN Wire format, CCNX1., "http://www.ietf.org/id/ 624 draft-mosko-icnrg-ccnxmessages-00.txt.", 2013. 626 [6] Nikander, P., Gurtov, A., and T. Henderson, "Host identity 627 protocol (HIP): Connectivity, mobility, multi-homing, 628 security, and privacy over IPv4 and IPv6 networks", IEEE 629 Communications Surveys and Tutorials, pp: 186-204, 2010. 631 [7] Atkinson, R., "An Overview of the Identifier-Locator 632 Network Protocol (ILNP)", Technical Report, University 633 College London, 2005. 635 [8] LISP, RFC6380., "https://tools.ietf.org/html/draft-ietf- 636 lisp-sec-07.", 2014. 638 [9] LISP-Security, LISP-SEC., "https://tools.ietf.org/html/ 639 draft-ietf-lisp-sec-07.", 2014. 641 [10] CCNx, Manifest., "http://www.ccnx.org/pubs/ 642 draft-wood-icnrg-ccnxmanifests-00.html.", 2015. 644 [11] DNS-SEC, RFC4033., "DNS Security Introduction and 645 Requirements.", 2005. 647 [12] FP7-ICT-2009-5-257448/D.B.3, "SAIL: Scalable and Adaptable 648 Internet Solutions", 2013, . 651 [13] Ravindran, R., Chakraborti, A., Amin, S., Azgin, A., and 652 GQ. Wang, "5G-ICN : Delivering ICN Services over 5G using 653 Network Slicing.", IEEE Communication Magazine, May, 2017. 655 [14] Adhatarao, S., Chen, J., Arumaithurai, M., Fu, X., and K. 656 Ramakrishnan, "Comparison of Naming Schema in ICN.", IEEE 657 LANMAN, 2016. 659 [15] Afanasyev, A., "Map-and-Encap for Scaling NDN Routing.", 660 NDN Technical Report ndn-004-02, 2015. 662 [16] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang, 663 "Seamless Producer Mobility as a Service in Information 664 Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 665 2016. 667 [17] Mosko, M., "Nameless Objects.", IETF/ICNRG, Paris 668 Interim 2016, 2016. 670 [18] Azgin, A., Ravindran, R., and G. Wang, "A Scalable 671 Mobility-Centric Architecture for Named Data Networking.", 672 ICCCN (Scene Workshop) , 2014. 674 [19] Cisco System Inc., CISCO., "Cisco Visual Networking Index: 675 Global Mobile Data Traffic Forecast Update", 2016-2021. 677 [20] Zhang, Y., Zhang, H., and L. Zhang, "Kite: A Mobility 678 Support Scheme for NDN.", NDN, Technical Report NDN-0020 , 679 2014. 681 [21] CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/ 682 ccnx-mosko-labelforwarding-01.txt.", 2013. 684 [22] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 685 Pau, G., and X. Zeng, "Anchor-less Producer Mobility in 686 ICN.", ICN, Sigcomm, 2015 , 2015. 688 [23] NSF FIA project, MobilityFirst., 689 "http://www.nets-fia.net/", 2010. 691 Authors' Addresses 692 Ravishankar Ravindran 693 Huawei Technologies 694 2330 Central Expressway 695 Santa Clara, CA 95050 696 USA 698 Email: ravi.ravindran@huawei.com 700 Asit Chakraborti 701 Huawei Technologies 702 2330 Central Expressway 703 Santa Clara, CA 95050 704 USA 706 Email: asit.chakraborti@huawei.com 708 Aytac Azgin 709 Huawei Technologies 710 2330 Central Expressway 711 Santa Clara, CA 95050 712 USA 714 Email: aytac.azgin@huawei.com