idnits 2.17.1 draft-padma-ideas-use-cases-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 67 has weird spacing: '...Privacy with ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2479 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pillay-Esnault, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational D. Farinacci 5 Expires: January 4, 2018 lispers.net 6 C. Jacquenet 7 Orange 8 U. Chunduri, Ed. 9 Huawei 10 T. Herbert 11 Quantonium 12 D. Lake 13 Dell 14 M. Menth 15 U of Tuebingen 16 D. Raychaudhuri 17 Rutgers University 18 D. Meyer 19 July 3, 2017 21 Use Cases for Identity Enabled Networks 22 draft-padma-ideas-use-cases-01 24 Abstract 26 This document describes few deployment use cases for Identity enabled 27 networks using a GeneRic Identity Services infrastructure. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 4, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 65 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 66 4. Use Cases for IDEAS/GRIDS . . . . . . . . . . . . . . . . . . 4 67 4.1. Privacy with Access Control . . . . . . . . . . . . . . 5 68 4.2. Identity Services with global GRIDS . . . . . . . . . . . 6 69 4.3. Identity Services with local GRIDS . . . . . . . . . . . 7 70 4.4. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.5. Discovery of devices . . . . . . . . . . . . . . . . . . 8 72 4.6. Ad-hoc Networks Mobility across Hetnet . . . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 11 81 A.1. Network Simplification . . . . . . . . . . . . . . . . . 11 82 A.1.1. Proximity Services and Scopes . . . . . . . . . . . . 11 83 A.1.2. Ease of troubleshooting and Management . . . . . . . 12 84 A.1.3. Application of Common policies . . . . . . . . . . . 12 85 A.2. Mobile Networks . . . . . . . . . . . . . . . . . . . . . 12 86 A.2.1. Mobility within a single provider network . . . . . . 12 87 A.2.2. Mobility across CNs . . . . . . . . . . . . . . . . . 15 88 A.2.3. Mobility of a Subnet . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The problem statement document for IDentity Enabled networkS (IDEAS) 94 advocates a standardized Identity and mapping services 95 infrastructure, secured access to that infrastructure with data 96 integrity, different Identity(IDy) services and allowing for 97 different Locator/Identifier data-plane solutions [IDEAS-PS]. 99 This infrastructure is called GeneRic Identity Services (GRIDS). The 100 GRIDS infrastructure (GRIDS-ARCH-TBD) is envisioned to support 101 functionalities such as traditional mapping and resolution of 102 Identifiers (IDfs), as well as secured Identity registration, 103 subscription, privacy for Identity/Identifier data, discovery of 104 Identifiers, updates to the system with data integrity. In addition, 105 it is designed to allow flexible deployment with different scopes 106 (local sub-domains/global). 108 This memo describes and focuses on few deployment use cases for 109 Identity-based protocols that will benefit from such an 110 infrastructure. The definition of and the need for Identity in IDEAS 111 are described in a companion document [IDEAS-IDENTITY]. 113 2. Specification of Requirements 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Definition of Terms 121 This document makes use of the terms that have been defined in the 122 problem statement draft of IDEAS [IDEAS-PS]. They are included here 123 for reader's convenience. In case of any discrepancies between the 124 two drafts, the problem statement draft overrides. 126 o Entity : An entity is a communication endpoint. It can be a 127 device, a node, or a virtual machine (VM), that needs to be 128 identified. An entity may have one or multiple identifiers (long- 129 lived or ephemeral) simultaneously. An entity is reached by 130 resolving one or more of its long-lived identifiers to its current 131 locator(s). 133 o Identifier (IDf): denotes information to unambiguously identify an 134 entity within a given scope (e.g. HIP HIT, LISP EID). There is 135 no constraint on the format, obfuscation or routability of an IDy. 136 The IDy may or may not be present in the packet whose format is 137 defined by IDf-based protocols (HIP/LISP). 139 o Identifier-based (IDf-based): When an entity is only reachable 140 through one or more communication access then a protocol or a 141 solution is said to be IDf-based, if it uses an ID-LOC decoupling 142 and a mapping system (MS) as base components of the architecture. 143 Examples of IDf-based protocols are HIP, LISP and ILA. 145 o Identity (IDy): the essence of "being" of a specific entity. An 146 identity is not to be confused with an identifier: while an 147 identifier may be used to refer to an entity, an identifier's 148 lifecycle is not necessarily tied to the lifecycle of the entity 149 it is referencing. On the other hand, the identity's lifecycle is 150 inherently tied to the lifecycle of the entity itself. 152 o IDentity Enabled Networks (IDEAS): IDEAS are networks that support 153 the identifier/locator decoupling. Reaching an entity is achieved 154 by the resolution of identifier(s) to locator(s). 156 o GeneRic Identity Services (GRIDS): GRIDS is a set of services to 157 manage the lifecycle of IDy/IDfs, to map and resolve Identifiers 158 and locators, and to associate metadata (META) with entities and 159 entity collections. It is a distributed infrastructure that 160 stores the IDy/IDf, the associated LOC(s), and metadata (META) in 161 the form of tuples (IDy/IDf, LOC, and META). 163 o Locator (LOC): denotes information that is topology-dependent and 164 which is used to forward packets to a given entity attached to a 165 network (IPv4/IPv6 Address). An entity can be reached using one 166 or multiple locators; these locators may have a limited validity 167 lifetime. 169 o Metadata (META): is data associated with an Identity. The 170 metadata may contain information such as the nature of the entity 171 for example. 173 o User Equipment (UE): A user equipment is an entity per definition 174 in [IDEAS-PS] 176 4. Use Cases for IDEAS/GRIDS 178 There are several benefits of various Locator/Identifier separator 179 protocols that they bring to IP networking. These include but not 180 limited to mobility with session continuity, global routable address 181 space reduction, traffic engineering to name a few. The goal of this 182 section is not to re-list all those deployment use cases of existing 183 IDf/LOC protocols but specify what and how IDEAS/GRIDS can enhance 184 the existing use cases and solve new problems in different areas. 186 This section details specific deployment use cases of IDEAS based 187 upon GRIDS infrastructure. 189 4.1. Privacy with Access Control 191 For privacy or security reasons, an entity may only want a designated 192 list of authorized entities to look up its locators and access it. 193 To this end, the entity can specify an access control list in the 194 GRIDS and let the GRIDS enforce the access control when entering the 195 locator resolution phase. For example, when Alice wants to 196 communicate with Bob, she has to look for the Bob's IDf in the GRIDS 197 to get his locator. The GRIDS verifies Alice's IDf and checks the 198 IDf against Bob's access control list. If Alice is authorized, the 199 GRIDS returns Bob's up-to-date locators; otherwise the GRIDS returns 200 an error or a honeypot LOC to analyze further (Figure 1). 202 GRIDS 203 +---------------------+ 204 set ACL | | lookup 205 +-------+ set LOC |---------------------| Alice +-----+ 206 | Alice |-------->| Alice's IDy| ACL |<-------| Bob | 207 +-------+ |---------------------| +-----+ 208 | yes| no| | access ^ ^ 209 | | | | denied | | 210 | | --|---------- | 211 | v | | 212 |---------------------| Alice's LOC | 213 | Alice's IDf| LOC |-------------- 214 |---------------------| 215 | | 216 +---------------------+ 218 Figure 1: Authorizing access to LOC information 220 An access restriction policy can also be possible at the GRIDS level 221 for a group/class of devices identified through the metadata of the 222 entity. A specific example is restricting access for location 223 resolution of a vehicular entity except for the authorized 224 manufacturer or dealers. 226 The GRIDS Infrastructure supports the ability to verify policies 227 associated to an Identity through an Identifier used in the data 228 plane. This reverse lookup provision can then trigger the execution 229 of various actions (e.g., discarding traffic or redirecting) on the 230 data plane nodes (routers/gateways/firewalls), according to the 231 policies defined in IDEAS. 233 Receiver of the data traffic can also control anonymization through a 234 specific policy specified by the GRIDS logic with its Identity. For 235 example sender of the data traffic can be provided with one of the 236 receiver's ephemeral Identifiers to use for communication, during LOC 237 resolution response (here sender assumes to be doing LOC resolution 238 through receiver's long-lived Identifier). Mechanisms like this can 239 provide anonymization of the data traffic from eavesdroppers/outside 240 observers. 242 4.2. Identity Services with global GRIDS 244 IDf-based protocols currently rely upon a customized mapping 245 infrastructure and they do not interoperate with each other. 246 Therefore, it would be difficult to deploy multiple IDf-based 247 protocols in the same network due to the overhead generated by the 248 operation of various mapping functions or it is difficult to deploy a 249 global scope with greater flexibility. Hence, only one ID protocol 250 is usually deployed even though there exists the need to deploy 251 specific solutions to address various contexts. 253 +------------------------------------------------------+ 254 | +--------------------------------------------------+ | 255 | | GRIDS | | 256 | | +-------------+ +---------------+ +-----------+ | | 257 | | |IDy | | IDf,Discovery,| | Other | | | 258 | | |Registration | | Mapping | | ID-aware | | | 259 | | |Lifecycle | | Resolution | | Services | | | 260 | | +-------------+ +---------------+ +-----------+ | | 261 | | | | 262 | | Common Service Plane | | 263 | +--------------------------------------------------+ | 264 | ^ | 265 | |CP | 266 | | | 267 | +--------------------------------------------------+ | 268 | | Flexible Data Plane | | 269 | | +--------+ +-----------+ +--------+ +----------+ | | 270 | | | LISP | | ILA | | HIP | | New Svcs | | | 271 | | |(Encap) | |(Translate)| |(Secure)| |(ID-Aware)| | | 272 | | +--------+ +-----------+ +--------+ +----------+ | | 273 | +--------------------------------------------------+ | 274 +------------------------------------------------------+ 276 Figure 2: The GRIDS Structure 278 The above diagram Figure 2 shows a unified mapping system, besides 279 the legacy mapping and resolution services. Other services Identity 280 can potentially bring to the IDf/LOC protocols (access restrictions 281 for resolution, discovery with metadata or grouping services) are 282 also supported by the mapping system. Access security and 283 registration services improve overall security of the GRIDS as these 284 can provide authentication of the entity through a singular Identity. 285 This process can also establish the entity type through metadata 286 which is needed for some of the IDy services. 288 Control Plane (CP) options i.e., usage of existing LOC/IDf protocols 289 or a new GRIDS-CP or usage of both, to realize services provided by 290 GRIDS is discussed in [IDEAS-PS]. 292 4.3. Identity Services with local GRIDS 294 The IoT landscape is comprised of a large variety of devices and 295 protocols. IoT solutions cover a wide-range of protocols at varying 296 stages of maturity, the latter may be at Layer-2/Layer-3 and usually 297 within a single domain. 299 While the number of IoT use-cases is vast and diverse, there is a 300 number of commonalities in network communications between classes of 301 application. Some of the categories below can benefit from local 302 GRIDS instance which can provide local authentication and security 303 features. 305 Low-compute capability end devices generating small amounts of 306 traffic with a long/short period, terminating on a central 307 application service with no-loop/loop latency dependencies. These 308 devices usually offload processing to a central service to which they 309 connect. The central service may be an application hosting 310 environment or a distributed/devolved solution (such as an Edge or 311 FOG solution). In both cases, local GRIDS instances could be 312 deployed for this functionality. Such devices will benefit from 313 offloading the secure registration and access restriction policies 314 placed at GRIDS. 316 Local GRIDS instance with standardized interfaces can also be 317 deployed in enterprise networks to provide security and location 318 based services. Here the policies applied on the Identity/Identifier 319 can be more flexible with proprietary rules structure. These can be 320 added on top of the minimal and standardized framework and interfaces 321 to meet enterprise needs. 323 4.4. Mobility 325 One of the key benefits of any ID-Based protocols is its ability to 326 provide mobility. Decoupling Identifier from location provides 327 inherent support for mobility with session continuity and hence this 328 document doesn't describe basic mobility use case further. But it is 329 important to note availability of a global GRIDS Infrastructure would 330 enable such mobility for entities connected to various IP networks 331 securely. Other key attributes such as mapping and ID services 332 system scalability, support of low latency and secure query (GRIDS- 333 ARCH-TBD) are some of the aspects which can determine the adoption 334 and deployment of this essential service. 336 Some use cases specific to mobile networks, where the need for both 337 Local and Global GRIDS are specified in the Appendix. 339 4.5. Discovery of devices 341 One of the services of the common mapping and ID services 342 infrastructure is to allow discovery of the entities. Results of 343 such discovery can be used to apply additional application services. 344 Most of these services need secured and authenticated registration to 345 the GRIDS (to verify for example the entity 'type' it is claiming) 346 with an immutable and unique Identity [IDEAS-IDENTITY] by the GRIDS 347 provider. Some of these use cases require geographical co-ordinates 348 too be part of LOC. Examples: 350 a. A specific mobile entity type as defined in the metadata of the 351 IDy (if the entity allows it to be searchable) in a particular 352 geographical area. This operation should give the long-lived IDf 353 of the entities in that area, thus enabling communication among 354 those entities. 356 b. Another example of discovery is asset tracking with extremely low 357 cost services like bike sharing service. There is a need to 358 track the exact location of individual bikes with low cost in 359 long time span. In this case, there must be a module with a 360 secured and long-lived identifier of the bike and which can set 361 up communications whenever needed. The information associated 362 with the identifier should be maintained with efficient 363 resolution capability for tracking the labeled asset [ASSET1] 364 [ASSET2]. 366 4.6. Ad-hoc Networks Mobility across Hetnet 368 Today, the cost of reestablishing both the session and any security 369 association is prohibitive in real-time applications with mobility. 370 The local and proximity services on the GRIDS could be leveraged to 371 provide the session continuity and security features. 373 Furthermore, there are opportunities for a dynamic and adhoc network 374 to be formed between groups of vehicles on the highway, and these 375 networks should be able to quickly peer along the edge with different 376 networks encountered during mobility. Essential components of 377 publicly sharable Metadata associated with entity's IDy/IDf at GRIDS 378 would enable these peerings. But the specifics of how this can be 379 used (TBD) and can only be expanded after IDEAS architecture is 380 evolved. 382 5. Security Considerations 384 While access restriction policies can protect the entities from 385 unwanted communication from unauthorized entities, how policy is 386 specified, located and shared may cause new security threats. This 387 aspect has to be considered during requirements and architecture. 389 6. IANA Considerations 391 This document has no actions for IANA. 393 7. Contributors 395 The following individuals (by first name alphabetical order) have 396 contributed to this document: 398 Shreyasee Mukherjee 400 Parishad Karimi 402 Da Bin 404 Liu Binyang. 406 Jim Guichard 408 Albert Cabellos` 410 This present document is based on an extract of the first version 411 of the draft. The authors and their affiliations on the original 412 document are: D. Farinacci (lispers.net), D. Meyer (Brocade), D. 413 Lake (Cisco Systems), T. Herbert (Facebook), M. Menth 414 (University of Tuebingen), Dipenkar Raychaudhuri (Rutgers 415 University), Julius Mueller (ATT) and Padma Pillay-Esnault 416 (Huawei). 418 8. Acknowledgments 420 The authors would like to thank Kevin Smith, Alex Clemm and Yingzhen 421 Qu for their review and input on this document. 423 9. References 425 9.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 9.2. Informative References 434 [ASSET1] OFO, , . 436 [ASSET2] ITU, , . 438 [IDEAS-IDENTITY] 439 Chunduri, U., Clemm, A., and M. Menth, "Identity Use Cases 440 in IDEAS", July 2017, . 443 [IDEAS-PS] 444 Pillay-Esnault, P., Boucadair, M., Jacquenet, C., 445 Fioccola, G., and A. Nennker, "Problem Statement for 446 Identity Enabled Networks", March 2017, 447 . 450 [LISP-PRED] 451 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 452 RLOCs", November 2016, . 455 Appendix A. Appendix 457 This section contains few more use cases GRIDS or Identity can bring 458 to IDEAS. Some of the use cases would be integrated based on the TBD 459 architecture of IDEAS. 461 A.1. Network Simplification 463 Whilst the term IoT encompasses a wide range of applications ranging 464 from short, low data-rate communications through to latency-sensitive 465 haptic control loops, the ability to reduce network overhead through 466 the simplification and potential removal of addresses at specific 467 points on the network has several benefits. 469 A.1.1. Proximity Services and Scopes 471 In a system generating small amounts of data, the relative size of 472 the addressing which can be considered to be network operator 473 overhead compared to the size of the data payload which is customer 474 data can be very high to the point where the addressing and control 475 data vastly outsizes the customer data. In a traditional IT network, 476 this is not often the case; the address and management data is very- 477 much smaller than the payload and is thus an acceptable tax on the 478 overall communication. Small data IoT applications require a 479 solution to address the imbalance which now exists between the 480 payload and the overhead. 482 It is possible to imagine local services within a scope that require 483 only a small ID within a scope and can communicate with a local GRIDS 484 to resolve its mapping and location services if it is only 485 communicating with local devices such as local networked sensors. 486 Such an example could sensors be in a factory. 488 A.1.2. Ease of troubleshooting and Management 490 Trouble-shooting a complex, multi-layer network where data is handed 491 from one encapsulation to another is complex. It is already seen in 492 solutions such as SIP that having embedded naming structures vastly 493 improves the ability to determine a data-path in a trouble-shooting 494 instance. Similarly, an IDf-based solution would apply from the data 495 producer to the consumer and can also be used to improve data- 496 traceability thereby resulting in lower operational costs. 498 The presence of a GRIDS can improve on managing the data paths as 499 they are stored in their mappings. Such improvement can be 500 especially beneficial if GRIDS capabilities interact with a SDN-based 501 computation logic, whose service-inferredpolicy-based decision making 502 process may choose to redirect traffic onto alternate paths as a 503 function of the nature of the service, the load status of the primary 504 path, etc. Application of such dynamics can be critical for specific 505 IoTservices, such as e-health services. Data analytics on the GRIDS 506 may also be logging events for easier postmortem if there are issues. 508 A.1.3. Application of Common policies 510 A Mapping System can contribute to enforce a set of common policies 511 for a given connectivity service by providing a global, consistent 512 identification and resolution service to any participating device 513 involved in the forwarding of the corresponding traffic. 515 A.2. Mobile Networks 517 For Seamless and global mobility of an entity, GRIDS can potentially 518 offer various services that can include not only traditial mapping 519 and resolution services based on Identifier, but protecting and 520 honoring the entity's privacy restrictions on who can acces entity's 521 LOC information for example. 523 Other services and Optimizations such as "late binding", in which 524 identity of in-transit packets can be bound to a locator closer to 525 the edge of the network to account for highly mobile vehicular 526 scenarios can be further developed based on the GRIDS. 528 A.2.1. Mobility within a single provider network 530 Figure 4 provides an example of the topology of a single mobile 531 carrier network. The goal of this section is not to specify specific 532 mobile technology arechitecture but represent the need for a 533 standardized mapping and ID services solution, which are relevant in 534 these domains. 536 UE.A, UE.B, and UE.C are devices connected to the mobile network and 537 are themselves mobile. UE.A and UE.B are currently connected to base 538 station Base1 and UE.C is currently connected to Base2. The base 539 stations are connected to the radio access network (RAN) of the 540 provider. The RAN is connected to the Internet through a transport 541 network via providers core network (CN). Regardless of which mobile 542 technology is used and CN is vritualized with separated control plane 543 (5G) GRIDS instance can be deployed for all ID services. 545 Host1 Host1 and Host2 are hosts in the Internet that are 546 communicating with the UEs. In this example we assume that ID 547 functionality is handled within the network and is transparent to the 548 UEs or hosts. 550 +-------+ 551 | UE.A |-----+ 552 +-------+ | 553 | 554 +-------+ +-----+ +-----+ 555 | UE.B |--|Base1|-----+ __________ +--|Host1| 556 +-------+ +-----+ __|___ / \ | +-----+ 557 / \ +-----+ ( )--+ 558 ( RAN )--| CN |-- ( Internet ) 559 \_______/ +-----+ ( )--+ 560 +-----+ | \__________/ | +-----+ 561 |Base2|------+ +--|Host2| 562 +-----+ +-----+ 563 | 564 +-------+ | 565 | UE.C |-----+ 566 +-------+ 568 The role of the CN is to leverage the GRIDS, that maps destination 569 addresses on ingress packets into the network to deliver packets to 570 the destination. The GRIDS Infrastructure maintain a list of ID-to- 571 LOC mappings. Hosts on the Internet only know the identifier of the 572 mobile nodes. Depending on the dataplane solution packets forwarded 573 from the Internet may be routed to a CN that is able to retrieve the 574 mapping ID to the destination LOC to facilitate delivery. 576 Consider that Host1 sends a packet to UE.A. The destination address 577 of the packet is the identifier address of UE.A. The packet is sent 578 by Host1 and is forwarded across the Internet to the provider's 579 network based on the identifier address. A CN receives the packet. 580 The destination address of a packet (identifier) is looked up in the 581 mapping table (local GRIDS). The return result is the LOC for UE.A. 582 The CN modifies the packet so that the destination address is the LOC 583 for UE.A (either by encapsulation or address translation). The 584 packet is then forwarded to Base1. At Base1 the destination is 585 changed back to the identifier address and forwarded to the UE. 587 In the case that two UEs need to communicate the process is similar. 588 Consider that UE.A sends a packet to UE.C. Again, UE.A only knows 589 the identifier address of UE.C. UE.A sends a packet into the network 590 and it is forwarded to a CN. The CN maps the destination address of 591 UE.C to its locator and forwards the packet to Base2 which translates 592 the destination back to an identifier address. 594 In order to reduce latency and improve performance, a mapping cache 595 may be implemented at or near the base stations. A mapping cache 596 would maintain a subset of mappings in the network that are being 597 used for communications by the attached UEs to other devices in the 598 network. A protocol would be run between the base stations and CNs 599 to populate and invalidate entries in the cache. 601 Now consider that UE.B changes locations so that it is now attached 602 to Base2 (figure 5). 604 +-------+ 605 | UE.A |-----+ 606 +-------+ | 607 | 608 +-----+ +-----+ 609 |Base1|----+ __________ +--|Host1| 610 +-----+ __|___ / \ | +-----+ 611 | / \ +-----+ ( )--+ 612 | ( RAN )--| CN |-- ( Internet ) 613 V \_______/ +-----+ ( )--+ 614 +-------+ +-----+ | \__________/ | +-----+ 615 | UE.B |--|Base2|-----+ +--|Host2| 616 +-------+ +-----+ +-----+ 617 | 618 +-------+ | 619 | UE.C |-----+ 620 +-------+ 622 The CNs are updated to reflect UE.B's new location. As updating 623 location is not instantaneous across all the mapping gateways in the 624 network, it is possible that a packet is forwarded to an old 625 destination. Several possible solutions exist today: 627 1. Predictive routing. Pre-populating the (ID,LOC) tuple in the 628 GRIDS itself so that multiple packets may get delivered ahead of 629 the move as described in [LISP-PRED]. A predictive algorithm can 630 be used to forward packets ahead of the move with minimum 631 duplication. 633 2. Late binding. This method refers to rebinding of identifiers to 634 addresses after a packet enters the network. This capability 635 makes it possible for routers in the network to redirect packets 636 whose end-point address might have changed due to fast mobility 637 or rapid changes in radio link association or multicast group 638 membership. This type of dynamic rerouting can help to improve 639 network efficiency and reduce packet drops. Late binding 640 generally requires in-network elements such as routers and base 641 stations to be able to store data packets temporarily and access 642 the ID to address mapping (name resolution) service. 644 3. Traditional Redirection. For instance, Base1 may receive packets 645 for a UE.B after it has moved to Base2. A "care of address" 646 could be set on Base1 for some period after the move. When Base1 647 receives a packet for UE.B it can map the destination address to 648 reflect UE.B's new location and forward the packet. This doesn't 649 need any local GRIDS instance and in some form done currently. 651 Some of the above additional services can be done through local GRIDS 652 instance in the control plane of the operator network, thus not 653 needing any anchor based solution and avoid "Traditional Redirection" 654 for example. 656 A.2.2. Mobility across CNs 658 The role of GRIDS and applicability depends on the mobility scenarios 659 specific to the mobile technology i.e., for intra RAN mobility local 660 GRIDS instance can be used for an anchor free transport network. For 661 seamless mobility across CN's of a same provider needs a global GRIDS 662 Infrastructure as host can be located any where and the LOC of UE 663 changes. This is one of the open issues of the current mobile 664 networks. 666 A.2.3. Mobility of a Subnet 668 Figure 8 presents a topology where UE.A, UE.B, and UE.C are connected 669 to a subnet and the whole subnet may itself be mobile (for instance a 670 Wi-Fi network on a bus). To treat the subnet as an aggregate 671 devices, the subnet identification is reflected in the identifier 672 address. A single mapping entry then could then represent this 673 subnet where the identifier is the prefix for the subnet and the 674 locator reflects the location of the subnet (Base1 in this case) 676 +------+ 677 | UE.A |--+ 678 +------+ | 679 +------+ | +-----+ +-----+ 680 | UE.B |--+--|Base1|-----+ ________ +--|Host1| 681 +------+ | +-----+ __|___ / \ | +-----+ 682 +------+ | / \ +-----+ ( )--+ 683 | UE.C |--+ ( RAN )--| CN |-- ( Internet ) 684 +------+ \_______/ +-----+ ( )--+ 685 +-----+ | \________/ | +-----+ 686 |Base2|-----+ +--|Host2| 687 +-----+ +-----+ 689 When the subnet moves the mappings to the identifier, the prefix for 690 the subnet is updated in the CNs (figure 9). Note that a UE could 691 also move out of its subnet and attach to the network on its own, for 692 instance a UE might switch from using Wi-Fi to using a mobile 693 network. This will work if a specific mapping for UEs is allowed in 694 the mapping database, and that mapping is preferred over the 695 aggregate mapping since it has a longer identifier prefix. 697 | +-----+ +-----+ 698 | |Base1|----+ ________ +--|Host1| 699 V +-----+ __|___ / \ | +-----+ 700 +-------+ / \ +-----+ ( )--+ 701 | UE.A |--+ ( RAN )--| CN |-- ( Internet ) 702 +-------+ | \_______/ +-----+ ( )--+ 703 +-------+ | +-----+ | \________/ | +-----+ 704 | UE.B |--+--|Base2|-----+ +--|Host2| 705 +-------+ | +-----+ +-----+ 706 +-------+ | 707 | UE.C |--+ 708 +-------+ 710 Similar to the case of a UE moving between carrier networks, a subnet 711 can move between carrier networks if the networks share identifier 712 locator mappings that include identifier prefixes. Also, subnet 713 mobility can modify community management and therefore impact GRIDS 714 service operation: if UE.A, UE.B, and UE.C have subscribed to 715 different services where, for example, UE.A exchanges information 716 with UE.B but not with UE.C, whereas, UE.C exchanges information with 717 UE.B but not UE.A, the mobile subnet may support different "closed 718 user groups" that may be serviced by different GRIDS. When the 719 subnet moves, other GRIDS may be invoked to make sure communication 720 within the said closed user groups is not disrupted. 722 Authors' Addresses 724 Padma Pillay-Esnault (editor) 725 Huawei 726 2330 Central Expressway 727 Santa Clara, CA 95050 728 USA 730 Email: padma.ietf@gmail.com 732 Dino Farinacci 733 lispers.net 734 San Jose California 735 USA 737 Email: farinacci@gmail.com 739 Christian Jacquenet 740 Orange 741 Rennes 35000 742 France 744 Email: christian.jacquenet@orange.com 746 Uma Chunduri (editor) 747 Huawei 748 2330 Central Expressway 749 Santa Clara, CA 95050 750 USA 752 Email: uma.chunduri@huawei.com 754 Tom Herbert 755 Quantonium 757 Email: tom@herbertland.com 758 David Lake 759 Dell 761 Email: d.lake@surrey.ac.uk 763 Michael Menth 764 U of Tuebingen 766 Email: menth@uni-tuebingen.de 768 Dipenkar (Ray) Raychaudhuri 769 Rutgers University 771 Email: ray@winlab.rutgers.edu 773 Dave Meyer 775 Email: dmm@1-4-5.net