idnits 2.17.1 draft-azgin-icnrg-ni-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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 17, 2017) is 2475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 721, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ravi-icnrg-ccn-forwarding-label-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3220 (Obsoleted by RFC 3344) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group A. Azgin 3 Internet-Draft R. Ravindran 4 Intended status: Informational Huawei Technologies 5 Expires: January 18, 2018 July 17, 2017 7 Enabling Network Identifier (NI) in Information Centric Networks to 8 Support Optimized Forwarding 9 draft-azgin-icnrg-ni-02 11 Abstract 13 The objective of this proposal is to introduce the notion of network 14 identifier (NI) in the ICN architecture. This is in addition to the 15 existing names (i.e., content identifiers, CIs, or application 16 identifiers, AIs, in general) that are currently used for both naming 17 and routing/forwarding purposes. Network identifiers are needed 18 considering the requirements on future networking architectures such 19 as: (i) to support persistent names (or persistently named objects) 20 and large-scale and high-speed mobility of any network entity (i.e, 21 devices, services, and content), (ii) to accommodate different types 22 of Internet of Things (IoT) services, many of which require low- 23 latency performance, and enabling edge computing to support service 24 virtualization, which will require support for large scale migration 25 and replication of named resources, and (iii) to scale the ICN 26 architecture to future Internet scale considering the exponentially 27 increasing named entities. If information on AI-to-NI mappings are 28 not directly accessible to the consumers, for instance, using 29 specific datasets like manifests, these considerations may require 30 enabling a name resolution service, which can be network based or 31 application driven, to support efficient and scalable routing. 32 Current document do not impose any restrictions on the name 33 resolution architecture, regarding its scope. 35 In the current draft, we begin by highlighting the issues associated 36 with ICN networking when utilizing only the AIs, which include 37 persistently named content, services, and devices. Next we discuss 38 the function NI serves, and provide a discussion on the two current 39 NI-based proposals, along with their scope and functionalities. This 40 is with the objective of having a single NI construct for ICN that is 41 flexible enough to adapt to different networking contexts. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on January 18, 2018. 66 Copyright Notice 68 Copyright (c) 2017 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. Application Identifier (AI) vs. Network Identifier (NI) in 85 ICN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 86 3. NI based ICN Forwarding . . . . . . . . . . . . . . . . . . . 7 87 3.1. Label based ICN forwarding . . . . . . . . . . . . . . . 8 88 3.2. Link-object based ICN forwarding . . . . . . . . . . . . 9 89 3.3. Link Object vs. Forwarding Label . . . . . . . . . . . . 10 90 4. Name Resolution System Considerations . . . . . . . . . . . . 12 91 5. Differences with respect to Existing IP-based Proposals . . . 13 92 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 6.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 98 1. Introduction 100 Information centric networking (ICN) is proposed as a future Internet 101 architecture to evolve the current host-centric design of Internet 102 towards a content-oriented one, where the named object becomes the 103 principle entity in networking. In doing so, contents, services, and 104 devices become disentangled from any particular host (or hosts) 105 allowing for efficient use of the distributed in-network caches and 106 compute resources with more flexible and dynamic packet forwarding 107 techniques. ICN is expected to offer a scalable and secure 108 networking solution to address many challenges of the current IP 109 architecture. Towards this, we propose to formalize the notion of 110 network identifier (NI) in ICN protocol, that is separate from 111 content name or application identifier (CI/AI, or simply AI) used to 112 both name resources and route user requests. 114 2. Application Identifier (AI) vs. Network Identifier (NI) in ICN 116 AI represents the names of services, contents, or devices assigned by 117 the application providers or device manufacturers, and which can be 118 validated through appropriate security mechanisms. AIs are 119 specifically used for content request and distribution. ICN should 120 provide flexibility in accommodating a broad set of identifiers, 121 within which the two well-known classes include hierarchical and flat 122 identifiers. While a hierarchical identifier provides contextual 123 richness for the names, a self-certified flat identifier offers a 124 fixed predictable overhead and context-based security features (as 125 they can be hash of the content object or hash of the public key). 126 Today, this identifier set is already in the order of billions (with 127 hundreds of millions domain name registrations across all top-level 128 domain names [VRSGN]). As tens of billions of devices are expected 129 to join the network, this identifier set will be further augmented 130 with the corresponding data objects significantly expanding its size. 131 To decouple applications from the underlying network dynamics, 132 identifiers are expected to be persistent within the scope of the 133 application and its deployment. 135 NI provides a binding for the AI to the network, at a location and in 136 a topology relevant manner. In more specific cases, such as with 137 anycast use of NIs or for multi-source-homing scenarios, binding can 138 target a set of locations rather than a single location. NI is 139 managed by the network provider to name the routers, point of 140 attachments, servers and end devices. In addition to ICN names, in 141 an overlay deployment, NI could assume names associated with the 142 underlay network as well, such as IP or Ethernet addresses, in which 143 case the NIs would be carried within the underlying protocol headers, 144 potentially with further address translations occurring at the ICN- 145 enabled routers, hosts, or devices. The growth in the NI space is 146 proportional to the rate of growth in domain topology, the total 147 number of AS(s), and the end points (if they are managed by the 148 network), whereas the growth of the AI space is proportional to the 149 rate of growth of the named resources within it. Considering the 150 potential use cases for ICN, the growth in AI space can be expected 151 to be much faster than that of NI space. Furthermore, as NI is a 152 routing construct, which can be modified en-route using per-hop name 153 resolution at the domain boundaries, the forwarding table sizes at 154 the core routers can be limited to the number of AS(s) instead of the 155 size for the set of end points. Hence if the objective is to limit 156 the size of the forwarding table and scale control plane, it is 157 desirable to route requests on NIs, with the mapping between AI and 158 NI is achieved in a scalable manner using one of many ways including 159 but not limited to using a network based name resolution system or 160 using a manifest-driven information database system to provide such 161 mappings. 163 Content-centric design used by ICN allows end hosts to make requests 164 using any type of name supported by the applications, including 165 hierarchical (human-readable or hash-based) identifiers (as 166 considered by CCN, NDN[CCN] for both the client application use and 167 the network use-for routing-), or fixed flat identifiers (as 168 considered by MobilityFirst[MFRST] in the network for routing). We 169 refer to an ICN architecture that supports any application naming 170 format (i.e., human-readable or flat) within the network for routing 171 as a non-restricted ICN architecture (as in CCN/NDN), whereas an ICN 172 architecture with a fixed naming format for routing within the 173 network as a restricted ICN architecture (as in MobilityFirst). 175 As packet forwarding in ICN utilizes names or identifiers (associated 176 with contents, hosts, or services) which are typically managed by 177 applications, thereby of 'mostly' persistent nature, using such names 178 in packet forwarding introduces certain challenges in regards to 179 routing scalability and forwarding efficiency [NAMES]. Depending on 180 the application context, it is possible for an application to support 181 the use of non-persistent names, for instance, in the case of real- 182 time multimedia services, with further challenges towards achieving 183 scalable routing and efficient forwarding. We list the most critical 184 challenges with respect to use of names in routing as follows. 186 o Using AI for Routing/Forwarding: Assigning dual functions to an 187 application identifier to include using it as a locator may, in 188 certain scenarios and depending on the ICN implementation, lead to 189 unstable 'routing control and forwarding plane' operations, 190 particularly when replication and mobility of content or end 191 points are taken into consideration. Specifically, if application 192 identifiers are used in routing, we can express the update 193 overhead to be proportional to the multiplication of update-reach 194 (i.e., the level of reachability of the update in terms of the 195 number of routers that need to update their routing/forwarding 196 tables), update-frequency, updated-object-count, which can easily 197 reach unmanageable levels, with shift towards more mobile 198 communications or higher level of content replication. 200 o Applications typically construct names and replicate contents or 201 services to optimize their delivery without any consideration 202 towards network scalability or efficiency. Accordingly, name 203 aggregation may not help with scaling the routing and forwarding 204 as typically considered [RFC7927], and the cost of this would be 205 quite significant in real world scenarios, as discussed in more 206 detail in [NCMP]. Furthermore, it is also observed in [QCMP] 207 that, in certain scenarios (such as content mobility), name-based 208 forwarding approaches can operate more efficiently, if used in 209 conjunction with address-assisted schemes such as DNS or anchor 210 point based approaches like Mobile IP [RFC3220]. Additionally, 211 when names are used for network reachability, more practical 212 problems such as name-suffix hole may arise, as the content 213 requests are forwarded towards non-existent caches [MDHT]. 215 o Routing/Forwarding Scalability: Routing scalability is typically 216 achieved by designing routing state with aggregate-able property, 217 which is the case for the current IP architecture. However, 218 having such feature in a non-restricted ICN architecture would 219 lead to relinquishing the persistency of the names, along with its 220 security binding such as trust, as the names would involve a 221 topological component for scalability, which can also suggest 222 resources to be renamed depending on, for instance, network or 223 business specs or characteristics. Note that, routing on names 224 with aggregate-able property would mean that names need to change 225 as the location for name changes, for instance, with publisher/ 226 producer mobility. As we assume that trust relationships are 227 established based on names, changing names would mean updating 228 security bindings accordingly, dynamically as requests are pushed 229 towards the content source. 231 o When content names or application identifiers use a hierarchical 232 identifier format, we observe scalability problems in control and 233 data plane operations [SFWD]. Such problems are caused by various 234 factors. For instance, the explosive growth observed in 235 namespaces can lead to a similar growth in routing/forwarding 236 information base or table sizes [AFWD][SPIT][WPIT], even when 237 namespace aggregation is enabled, to significantly limit the 238 forwarding efficiency and forwarding capacity. If ICN routing 239 with hierarchical naming is the accepted form of naming, name- 240 aggregation is highly unlikely to achieve any practical 241 scalability. This is because, naming ontology and assignment 242 typically consider application objectives of contextualizing 243 names, service and content placement and replication to better 244 suit the consumers' needs without considering any network 245 objectives on control and data plane efficiency and scalability. 247 o Handling Mobility, Migration, and Replication: The impact of 248 namespace expansion on routing/forwarding performance is typically 249 exacerbated with content mobility, or the use of multi-homing and 250 resource replication due to diminished aggregate-ability [NCMP]. 251 The authors in [QCMP] concludes that, as more than 20% of end 252 hosts make more than 10 network address transitions every day, 253 thereby suggesting that mobility should be considered as the norm 254 rather than the exception. Furthermore, to achieve location 255 independent routing based on AIs, each mobility event associated 256 with a device or a popular content may trigger updates on up to 257 14% of Internet routers. 259 For the above reasons, restructuring the identifier to directly or 260 indirectly contain a globally routable component becomes an important 261 requirement, especially, to handle mobility at the network layer for 262 architectures that do not restrict names or identifiers to any 263 specific format. We can refer to such operation as the Application 264 and Network identifier split (where the NI represents the globally 265 routable component, and the AI represents the persistent name/ 266 identifier) which enables splitting of the namespace to support 267 routable, persistent, and human-friendly names or identifiers. In 268 such a framework, names would be divided accordingly, i.e., based on 269 application binding (offering persistent names) vs. advertised 270 network entities (in routing plane) to provide a more scalable 271 routing architecture. For instance, a persistent name or identifier 272 /Provider/Type/Name, which would be used to create secure content 273 objects, can be published by multiple content distributors, where it 274 would be mapped to different NIs, such as /Distributor/Region/Zone/ 275 Storage, to resolve content names or identifiers to specific 276 infrastructure entities. The fundamental requirements with this form 277 of splitting is no different than that of MobilityFirst [MFRST] or 278 LISP [RFC6830], which is the requirement of a network based name 279 resolution system to map the two namespaces. 281 So far, various approaches have been proposed to support the use of 282 NI in ICN-based networking architectures, depending on how this 283 information is structured and where it is placed within the Interest 284 (which may also determine the structuring of Data packets). Next, we 285 discuss these solutions by specifically focusing on label-based ICN 286 forwarding [FWLDR][FWLRP][MAAS] and ICN-based Map-and-Encap 287 [MPNCP][SNAMP] to provide a general guidance on the use of NI in 288 information centric networks. 290 3. NI based ICN Forwarding 292 AI based routing is a feasible solution within certain contexts such 293 as: (i) when resources are static and routing is limited to local 294 area networks or local domains, such as access networks within the 295 scalability considerations of the control and forwarding plane; (ii) 296 in ad hoc situations where AI can be combined with suitable suffix 297 filters to seek content of interest for the applications; (iii) in 298 infrastructure-less scenarios with limited scalability requirements. 300 On the other hand, the use of NI becomes important in the following 301 situations: (i) when the Interest packet goes outside the local 302 domain, where routing on AI is optionally supported (i.e., as routing 303 scalability and efficiency seeks precedence, forwarders can choose to 304 exclude certain AIs from FIB processing, which may limit the 305 forwarding of requests carrying such AIs); (ii) when the Interest 306 enters a local domain, and the domain has specific knowledge of an NI 307 associated with the resource inside its domain (as the use of NIs 308 would address routing efficiency through exact matching on the NI 309 rather than performing longest prefix matching on AIs). The first 310 situation can limit routability of requests if information on how to 311 reach an AI is not carried in all domains, whereas the second 312 situation, for various reasons, can help with efficient forwarding of 313 requests by routing on NIs rather than on AIs even though it is 314 supported (e.g., NI lookup may be performed on a more performance 315 efficient state table using exact match rather than longest prefix 316 matching). 318 With the above considerations, with respect to end-to-end networking, 319 using NI for routing is not a mandatory feature, but an optional one. 320 However, as significant amount of user traffic fetches resources 321 outside the requesting host's local domain, it becomes crucial to 322 provide architectural support for routing on NIs in an ICN protocol. 323 Here, we consider NI as an implemented feature for communication 324 among static network components (e.g., as router identifiers) or 325 cross domains (e.g., as domain identifiers or global identifiers), 326 and can be designed using locally or globally defined policies, which 327 for the latter case may require globally agreed semantics for trust 328 management to validate bindings between NIs and AIs. 330 So far, two solutions for NI in ICN, overall with the same objectives 331 but serving different purposes, have been proposed. These include 332 the forwarding-label proposal [FWLDR] and the Link Object described 333 in [SNAMP]. We next summarize these proposals and discuss their 334 differences. 336 3.1. Label based ICN forwarding 338 Label-based ICN forwarding provides NI capability by encoding a 339 network address along with (optional) security binding attributes 340 within an Interest packet to guide it towards a content source (which 341 can be the Producer, a content repository or a cache). We refer to 342 this label that provide the NI capability as the forwarding label 343 [FWLDR], which can be offered as part of an ICN network service (such 344 as a name resolution service with ICN APIs to register and resolve 345 names). Security binding attributes are considered optional for 346 forwarding labels as their scope can be limited to use within a 347 domain, and within the boundaries of a domain, with an established 348 trust among forwarding hosts (i.e., network routers) such bindings 349 may not be needed. On the other hand, to ensure cross-domain 350 validity of forwarding labels, in the absence of prior established 351 trust relationships, security binding attributes are considered as 352 mandatory, and enforced at domain boundaries to ensure that end-to- 353 end NI-based packet forwarding is supported. There may be exceptions 354 to the above scenarios depending on how the NIs are utilized and 355 updated. 357 For the forwarding label, we have the following important 358 considerations: (i) forwarding label, if present in the Interest 359 packet, takes precedence (over AI) for routing to ensure consistency 360 in packet forwarding whenever its used is triggered (for instance, to 361 avoid the emergence of loops which can occur as a consequence of 362 alternating between routing on AIs and routing on forwarding labels), 363 (ii) forwarding label is mutable in the sense that it can be swapped 364 or removed by intermediate network elements in the network based on 365 routing considerations within its domain. Note that, to ensure 366 compatibility with future potential use cases, label based ICN 367 forwarding can also utilize dynamic precedence, for instance to 368 prevent routers from unnecessarily dropping requests. Here, 369 forwarding labels are not limited to only the ICN names, but, in an 370 overlay mode, they can also represent names from other transport 371 layers as well, for instance, an IP address or a MAC address. 373 Forwarding label consists of multiple components, one of which is the 374 NI that represents the locator information. If the AI namespace 375 supports the use of an NI to reach a specific destination, forwarding 376 label is embedded within the Interest message at the edge router or 377 the end point within certain trust considerations. For security 378 reasons, edge routers can validate the label, which is inserted by 379 the end hosts, based on the trust context. For instance, if the 380 inserted label cannot be validated, edge router can ignore the label 381 inserted by the end-host and swap it with a new one depending on the 382 feedback from the name resolution system; or if forwarding on labels 383 is not supported, edge router can ignore any such label inserted by 384 an ICN forwarder at the end hosts, by simply removing the inserted 385 label. Such an approach requires no trust relationship among 386 different domains, as each domain is capable of resolving content 387 namespace to a target domain, and swapping the received label with 388 one to which its resolves. 390 Forwarding label support for a namespace can be offered at a global 391 scale (i.e., supported by all the domains) or a local scale 392 (supported by a subset of the existing domains). For instance, some 393 autonomous systems can prioritize forwarding solely based on the 394 content names (or offer limited support for label-based forwarding on 395 specific namespaces). In such case, forwarding labels can include 396 additional service tag (or information on the associated service, for 397 which the use of forwarding label might be supported in certain 398 domains, such as towards mobility service) for routing packets on the 399 supported domains. In doing so, we can strategically forward 400 requests over domains that support such service to provide more 401 deterministic service guarantees. 403 If forwarding label use is supported (or permitted) within a domain, 404 by default, forwarding label is given preference over content 405 identifiers for packet forwarding. In such case, to maximize the 406 forwarding efficiency, additional mapping tables can be implemented 407 at the edge or border ICN routers for quick longest-prefix matching 408 (LPM) lookup on content names to determine a (or the) matching 409 forwarding label(s), which can then be used by the router to perform 410 LPM lookup on the FIB. As forwarding label typically represents a 411 target domain or router, a single LPM lookup on the FIB may suffice 412 to find the outgoing interface for the received Interest. This state 413 can also be software-defined based on application requirements using 414 an SDN based control plane. 416 3.2. Link-object based ICN forwarding 418 ICN-based Map-and-Encap [SNAMP] utilizes link objects, which include 419 information on how to retrieve content objects. For instance, link 420 objects can represent domains that host the content object, or 421 direction towards which the requests need to be forwarded to find a 422 matching content object. Link objects consist of two optional 423 headers: (i) a link header, which includes the potential directives 424 that can be used for forwarding and is signed by the Producer to 425 validate its authenticity during forwarding, and (ii) a delegation 426 header, which is used to represent the link choice utilized by the 427 previous forwarder. Since delegations may change at consecutive hops 428 depending on the view of forwarders' network state and forwarding 429 strategy, delegation header represents a variable component that can 430 be altered during packet forwarding. 432 The role of link objects is mainly for guidance, to provide global 433 routing support on locally defined or routable content identifiers. 434 Hence, if link objects are implemented, they are consulted by the ICN 435 enabled routers only when forwarding lookup on content identifiers 436 returns no match on the forwarding information base. 438 3.3. Link Object vs. Forwarding Label 440 Next we list the major differences between a link object and a 441 forwarding label. 443 o Link objects are set by the end host's forwarding daemon with 444 certain level of trust associated to it, restricting the link 445 component to be immutable during forwarding. Forwarding labels 446 are initially set by the ICN edge routers or the end-host 447 applications and allow mutable operation through late-binding 448 during Interest forwarding. In doing so, forwarding label offers 449 the ability of network based management during Interest 450 forwarding, which allows each domain to perform packet forwarding 451 according to its administrative and service policies. Note that, 452 it is possible for link objects to trigger network based 453 management operations, however their impact would be limited, in 454 the worst case triggering NACKs that may prevent the use of link 455 objects to help with forwarding. 457 o Link objects constrain a network operator from overriding a 458 consumer's intent, which, in some cases, may potentially lead to 459 better performance compared to forwarding over native network 460 service provider paths. Forwarding labels require additional 461 mechanisms to support such feature, for instance, to enable the 462 desired path for the consumer, which may necessitate the use of 463 additional forwarding labels within requests. 465 o For the link objects, security binding is mandatory and trust 466 relationship is established by default, by putting all the trust 467 assessment at the end hosts. On the other hand, security binding 468 is optional for the forwarding label, which allows the use of 469 trust association to bind AI to the NI depending on the context 470 associated with its use. However, without appropriate support in 471 trust management, forwarding label use may introduce problems such 472 as route hijacking, hence contextual management should be capable 473 of addressing such challenges using, for instance, approaches 474 identified in [FWLDR]. 476 o Another difference is related to the processing of forwarding 477 labels and link objects at the ICN routers. A link object is 478 processed only if the router cannot find a matching FIB entry for 479 the content identifier limiting routing flexibility. Furthermore, 480 if no matching FIB entry is found, link objects would trigger 481 additional lookups on the FIB, leading to efficiency issues with 482 frequent occurrences. On the other hand, forwarding label is 483 processed before a content identifier, if its use is enabled, 484 hence presents a more flexible and efficient operation in routing. 486 o Link object can be considered as a hint towards where to find the 487 content, and since it is processed after FIB lookup on the content 488 identifier fails, it typically leads to lower computational and 489 bandwidth efficiency. Forwarding label, on the other hand, can be 490 considered as an enabler for faster packet processing at the ICN 491 routers as it allows bypassing content/application identifier 492 based processing at the supported routers, while at the same 493 offering optimized routing towards a content source. 495 o Link object is considered as an application driven component and 496 network service agnostic, thereby allowing the network to decide 497 on its use. Forwarding label, on the other hand, can be enabled 498 as part of a service, which limits the use of forwarding label to 499 the supported namespaces, while at the same time requiring its use 500 whenever/wherever supported. For instance, within the context of 501 virtualizing the ICN network among multiple services, where 502 compute, storage, and bandwidth resources are shared among these 503 services, ICN service edge routers can apply rules on namespaces 504 to decide on how to dedicate network resources. One example of 505 such service is the mobility service, which can utilize forwarding 506 labels, to provide stricter service quality guarantees for the end 507 hosts. In such case, if the namespace requires mobility support, 508 forwarding label is used in effect to achieve more efficient 509 forwarding. Note that, service use can be triggered with the use 510 of service tags integrated within forwarding labels, once 511 validated to be used with the corresponding namespace(s). 513 o As a link object can encode multiple routing hints, it can direct 514 a request towards multiple identifier locations, giving an ICN 515 router the option to choose any one of them based on the router's 516 forwarding strategy. Even though this selection is shared between 517 consecutive routers, it is not enforced, thereby potentially 518 leading to non-optimal forwarding paths. Forwarding label, on the 519 other hand, is enforced consistently at consecutive hops within a 520 domain whenever/wherever its use is supported and/or enabled. 521 Hence, forwarding label presents the network with the ability to 522 consistently forward packets over optimal paths towards a content 523 source (with respect to routers forwarding the requests towards 524 the same direction, rather than choosing alternating 525 destinations). 527 4. Name Resolution System Considerations 529 To manage the AI to NI mapping, we need a name resolution system 530 (NRS). In addition to exposing APIs to application to register its 531 name to the NRS, it should also scale and work efficiently 532 considering the scale of named resources that need to be published, 533 resolved, removed, and updated at high frequency, for instance, 534 corresponding to high-speed mobility scenarios. 536 The following are the design choices for the NRS: 538 o Hierarchical System: Here, AI to NI mapping is managed by the 539 application providers, but similar to DNS, the service has to sync 540 its name reachability information with high level name resolvers. 541 NDN-DNS (NDNS) is an example of such a system [NDNS], which 542 utilizes a zone-based hierarchy (i.e., root level, top-level 543 domain, etc.) and which is queried iteratively at every component 544 level of the content/application identifier (e.g., /tld/sld would 545 trigger iterative requests of /dns/tld/NS and /dns/sld/NS, at the 546 root and tld levels). NDNS also supports recursive queries to 547 scope the route requests for a content/application identifier. 548 Even though the design of NDNS supports forwarding of Interests on 549 content/application identifiers not present in the FIB, its design 550 is typically suitable in cases when resources are static, rather 551 than for highly dynamic systems such as ICN, where replication and 552 mobility will be the norm. Supporting mobility in NDNS may 553 require frequent updates and requests to setup and identify routes 554 towards mobile entities, which may lead to performance-related 555 problems. Also, such system has to scale to resolve not just the 556 end hosts, which represents the current use, but also the 557 information objects. 559 o Network-Integrated Flat System: Here, resolution service is 560 integrated within the ICN infrastructure, where the router 561 contributes a part of its compute and storage resources to enable 562 this service. This integration allows multiple ways of designing 563 a generic name resolution service, similar to the overlaid or in- 564 network designs considered for Global Name Resolution Service 565 (GNRS) in MobilityFirst [GNS] [ASPC] [GNRS] allowing for good 566 scalability performance with proven handling of dynamic updates, 567 aided by a separation of entity identifiers from network 568 identifiers. In GNRS, flat names are queried to obtain the 569 corresponding self-certifying identifiers, such as the network 570 address, before forwarding an Interest for the flat globally- 571 unique identifier. 573 o Distributed System: Compared to a flat resolution system, this 574 type of architecture preserves the contextual nature of DNS, by 575 using the context in the content identifier (such as the network 576 or host identifier portion of the name) to identify a resolution 577 server corresponding to the context information, such as home 578 controller, which stores the mappings associated with registered 579 names carrying the controller's context information and where the 580 respective AI to NI mapping can be resolved. Such a system 581 removes the need for the home controllers to sync up with high 582 level resolvers, as for successful resolution it is sufficient for 583 each controller to manage the names registered to or under it. 584 For instance, /company/content-id would be mapped with a local 585 resolver, identified with /company/resolver-id, that manages any 586 namespace registered under its domain identifier (/company). In 587 doing so, content mobility can effectively be handled through 588 localized updates (for intra-domain mobility) or remote updates at 589 the home controller (for inter-domain mobility) with minimal 590 signaling overhead, while maintaining global scalability. 592 5. Differences with respect to Existing IP-based Proposals 594 To address persistent identity, routing scalability, multihoming, and 595 mobility limitations of the current IP, various incremental solutions 596 have been proposed, among which identifier/locator split emerged as 597 the key solution to address these challenges [RFC4984]. Here, we 598 specifically focus on three of these solutions: (i) Host Identity 599 Protocol (HIP) [HIP], (ii) Identifier-Locator Network Protocol (ILNP) 600 [ILNP], and Locator/Identifier Seperation Protocol (LISP) [RFC6830]. 601 HIP and ILNP achieve ID/locator separation and binding at the host 602 level whereas LISP achieves that at the network level (i.e., at the 603 network edge using service routers). 605 In HIP, public cryptographic keys are used as host identifiers, which 606 provide the binding to higher layer protocols instead of IP addresses 607 [RFC7401]. ILNP divides IP namespace into two distinct namespaces of 608 identifiers and locators, each of which carrying distinct semantics 609 with identifier representing the non-topological name for the host 610 and locator representing the topologically bound name for the network 611 [RFC6740]. LISP is a map-and-encap type protocol, which achieves id/ 612 locator separation by defining (i) endpoint identifiers, which are 613 used for routing at the access network and which represent the IP 614 address for the host, and (ii) routing locators, which are used for 615 routing at the core and which represent the IP address for the egress 616 routers. 618 These protocols fundamentally differ from ICN's objective to define a 619 new network layer, where name based routing, location independent 620 caching, mobility, multihoming, and multi-path routing are the 621 integral features. More specifically, this draft proposes to enable 622 AI/NI binding as a network service to allow efficient routing of user 623 requests depending on the application context. 625 6. References 627 6.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, 632 . 634 6.2. Informative References 636 [AFWD] Yi, C., Afanasyev, A., Wang, L., Zhang, B., and L. Zhang, 637 "Adaptive Forwarding in Named Data Networking", ACM CCR, 638 Jul 2012. 640 [ASPC] Sharma, A., Tie, X., Uppal, H., Venkataramani, A., 641 Westbrook, D., and A. Yadav, "A Global Name Service for a 642 Highly Mobile Internetwork", ACM SIGGCOM, 2014. 644 [CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 645 Briggs, N., and R. Braynard, "Networking Named Content", 646 ACM CoNEXT, 2009. 648 [FWLDR] Ravindran, R., Chakraborti, A., and A. Azgin, "Forwarding 649 Label Support in CCN Protocol", draft-ravi-icnrg-ccn- 650 forwarding-label-01, July, 2017. 652 [FWLRP] Azgin, A., Ravindran, R., and G. Wang, "A Scalable 653 Mobility-Centric Architecture for Named Data Networking", 654 IEEE ICCCN Scene Workshop, 2014. 656 [GNRS] Hu, Y., Yates, R., and D. Raychaudhuri, "A Hierarchically 657 Aggregated In-Network Global Name Resolution Service for 658 the Mobile Internet". 660 [GNS] Venkataramani, A., Sharma, A., Tie, X., Uppal, H., 661 Westbrook, D., Kurose, J., and D. Raychaudhuri, "Design 662 Requirements for a Global Name Service for a Mobility- 663 Centric, Trustworthy Internetwork", IEEE COMSNETS, 2013. 665 [HIP] Nikander, P., Gurtov, A., and T. Henderson, "Host identity 666 protocol (HIP): Connectivity, mobility, multi-homing, 667 security, and privacy over IPv4 and IPv6 networks", IEEE 668 Communications Surveys and Tutorials, pp: 186-204, 2010. 670 [ILNP] Atkinson, R., "An Overview of the Identifier-Locator 671 Network Protocol (ILNP)", Technical Report, University 672 College London, 2005. 674 [MAAS] Azgin, A., Ravindran, R., Chakraborti, A., and G. Wang, 675 "Seamless Producer Mobility as a Service in Information 676 Centric Networks", ACM ICN IC5G Workshop, 2016. 678 [MDHT] Liu, H., Foy, X., and D. Zhang, "A Multi-level DHT routing 679 Framework with Aggregation", ACM SIGCOMM ICN Workshop, 680 2012. 682 [MFRST] Venkataramani, A., Kurose, J., Raychaudhuri, D., Nagaraja, 683 K., Mao, M., and S. Banerjee, "MobilityFirst: A Mobility- 684 centric and Trustworthy Internet Architecture", ACM 685 SIGCOMM CCR, 2014. 687 [MPNCP] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, 688 "Map-and-Encap for Scaling NDN Routing", NDN Technical 689 Report, ndn-004-02, 2015. 691 [NAMES] Baid, A., Vu, T., and D. Raychaudhuri, "Comparing 692 Alternative Approaches for Networking of Named Objects in 693 the Future Internet", IEEE INFOCOM NOMEN Workshop, 2012. 695 [NCMP] Adhatarao, S., Chen, J., Arumaithurai, M., Fu, X., and K. 696 Ramakrishnan, "Comparison of Naming Schema in ICN", IEEE 697 LANMAN, 2016. 699 [NDNS] Afanasyev, A., "Addressing Operational Challenges in Named 700 Data Networking Through NDNS Distributed Database", 2013. 702 [QCMP] Gao, Z., Venkataramani, A., Kurose, J., and S. Heimlicher, 703 "Towards a Quantitative Comparison of Location-Independent 704 Network Architectures", ACM SIGCOMM, 2014. 706 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 707 DOI 10.17487/RFC2629, June 1999, 708 . 710 [RFC3220] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, 711 2002. 713 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 714 Text on Security Considerations", BCP 72, RFC 3552, 715 DOI 10.17487/RFC3552, July 2003, 716 . 718 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 719 Workshop on Routing and Addressing", RFC 4984, 2007. 721 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 722 IANA Considerations Section in RFCs", RFC 5226, 723 DOI 10.17487/RFC5226, May 2008, 724 . 726 [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network 727 Protocol (ILNP) Architectural Description", RFC 6740, 728 2012. 730 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 731 Locator/ID Separation Protocol (LISP)", RFC 6830, 2013. 733 [RFC7401] Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 734 "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, 735 2015. 737 [RFC7927] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., 738 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisc, 739 "Information-Centric Networking (ICN) Research 740 Challenges", RFC 7927, 2016. 742 [SFWD] Yuan, H., Song, T., and P. Crowley, "Scalable NDN 743 Forwarding: Concepts, Issues and Principles", IEEE ICCCN, 744 2012. 746 [SNAMP] Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang, 747 "SNAMP: Secure Namespace Mapping to Scale NDN Forwarding", 748 IEEE Global Internet Symposium, 2015. 750 [SPIT] Yuan, H. and P. Crowley, "Scalable Pending Interest 751 Table Design: From Principles to Practice", IEEE INFOCOM, 752 2014. 754 [VRSGN] "Verisign Domain Name Industry Brief", July 2016. 756 [WPIT] Varvello, M., Perino, D., and L. Linguaglossa, "On the 757 Design and Implementation of a Wire-speed Pending Interest 758 Table", IEEE INFOCOM NOMEN Workshop, 2013. 760 Appendix A. Additional Stuff 762 This becomes an Appendix. 764 Authors' Addresses 766 Aytac Azgin 767 Huawei Technologies 768 Santa Clara, CA 95050 769 USA 771 Email: aytac.azgin@huawei.com 773 Ravishankar Ravindran 774 Huawei Technologies 775 Santa Clara, CA 95050 776 USA 778 Email: ravi.ravindran@huawei.com