idnits 2.17.00 (12 Aug 2021) /tmp/idnits46730/draft-farinacci-lisp-mobile-network-14.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 : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (March 20, 2022) is 55 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1700' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'RFC8060' is defined on line 795, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 -- No information found for draft-ietf-lisp-eid-anonymity - is the name correct? -- No information found for draft-ietf-lisp-eid-mobility - is the name correct? -- No information found for draft-ietf-lisp-introduction - is the name correct? -- No information found for draft-ietf-lisp-mn - is the name correct? == Outdated reference: A later version (-10) exists of draft-ietf-lisp-predictive-rlocs-09 -- No information found for draft-ietf-lisp-rfc6830bis - is the name correct? -- No information found for draft-ietf-lisp-rfc6833bis - is the name correct? -- No information found for draft-ietf-lisp-sec - is the name correct? -- No information found for draft-ietf-lisp-signal-free-multicast - is the name correct? == Outdated reference: A later version (-10) exists of draft-ietf-lisp-te-09 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental P. Pillay-Esnault 5 Expires: September 21, 2022 Independent 6 U. Chunduri 7 Intel Corporation 8 March 20, 2022 10 LISP for the Mobile Network 11 draft-farinacci-lisp-mobile-network-14 13 Abstract 15 This specification describes how the LISP architecture and protocols 16 can be used in a LTE/5G mobile network to support session survivable 17 EID mobility. A recommendation is provided to SDOs on how to 18 integrate LISP into the mobile network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 21, 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 56 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. Addressing and Routing . . . . . . . . . . . . . . . . . . . 14 58 5. gNB/eNodeB LISP Functionality . . . . . . . . . . . . . . . . 14 59 6. UPF/pGW LISP Functionality . . . . . . . . . . . . . . . . . 15 60 7. Compatible Data-Plane using GTP . . . . . . . . . . . . . . . 16 61 8. Roaming and Packet Loss . . . . . . . . . . . . . . . . . . . 16 62 9. Mobile Network LISP Mapping System . . . . . . . . . . . . . 16 63 10. LISP Over the 5G N3/N6/N9 Interfaces . . . . . . . . . . . . 17 64 11. Multicast Considerations . . . . . . . . . . . . . . . . . . 18 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 67 14. SDO Recommendations . . . . . . . . . . . . . . . . . . . . . 19 68 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 70 15.2. Informative References . . . . . . . . . . . . . . . . . 20 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 23 72 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 24 73 B.1. Changes to draft-farinacci-lisp-mobile-network-14 . . . . 24 74 B.2. Changes to draft-farinacci-lisp-mobile-network-13 . . . . 24 75 B.3. Changes to draft-farinacci-lisp-mobile-network-12 . . . . 24 76 B.4. Changes to draft-farinacci-lisp-mobile-network-11 . . . . 24 77 B.5. Changes to draft-farinacci-lisp-mobile-network-10 . . . . 24 78 B.6. Changes to draft-farinacci-lisp-mobile-network-09 . . . . 24 79 B.7. Changes to draft-farinacci-lisp-mobile-network-08 . . . . 25 80 B.8. Changes to draft-farinacci-lisp-mobile-network-07 . . . . 25 81 B.9. Changes to draft-farinacci-lisp-mobile-network-06 . . . . 25 82 B.10. Changes to draft-farinacci-lisp-mobile-network-05 . . . . 25 83 B.11. Changes to draft-farinacci-lisp-mobile-network-04 . . . . 25 84 B.12. Changes to draft-farinacci-lisp-mobile-network-03 . . . . 25 85 B.13. Changes to draft-farinacci-lisp-mobile-network-02 . . . . 25 86 B.14. Changes to draft-farinacci-lisp-mobile-network-01 . . . . 26 87 B.15. Changes to draft-farinacci-lisp-mobile-network-00 . . . . 26 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 90 1. Introduction 92 The LISP architecture and protocols [I-D.ietf-lisp-rfc6830bis] 93 introduces two new numbering spaces, Endpoint Identifiers (EIDs) and 94 Routing Locators (RLOCs) which provide an architecture to build 95 overlays on top of the underlying Internet. Mapping EIDs to RLOC- 96 sets is accomplished with a Mapping Database System. By using a 97 level of indirection for routing and addressing, separating an 98 address identifier from its location can allow flexible and scalable 99 mobility. By assigning EIDs to mobile devices and RLOCs to the 100 network nodes that support such mobile devices, LISP can provide 101 seamless mobility. 103 For a reading audience unfamiliar with LISP, a brief tutorial level 104 document is available at [I-D.ietf-lisp-introduction]. 106 This specification will describe how LISP can be used to provide 107 layer-3 mobility within and across an LTE [LTE401-3GPP] [LTE402-3GPP] 108 and 5G [ARCH5G-3GPP] [PROC5G-3GPP] mobile network. 110 The following are the design requirements: 112 1. Layer-3 address mobility is provided within a mobile network RAN 113 supported by a UPF/pGW region (intra-UPF/pGW) as well as across 114 UPF/pGW regions (inter-UPF/pGW). 116 2. UE nodes can get layer-3 address mobility when roaming off the 117 mobile network to support Fixed Mobile Convergence [FMC]. 119 3. Transport layer session survivability exists while roaming 120 within, across, and off of the mobile network. 122 4. No address management is required when UEs roam. EID addresses 123 are assigned to UEs at subscription time. EIDs can be reassigned 124 when UE ownership changes. 126 5. The design will make efficient use of radio resources thereby not 127 adding extra headers to packets that traverse the RAN. 129 6. The design can support IPv4 unicast and multicast packet delivery 130 and will support IPv6 unicast and multicast packet delivery. 132 7. The design will allow use of both the GTP [GTPv1-3GPP] 133 [GTPv2-3GPP] and LISP [I-D.ietf-lisp-rfc6830bis] data-planes 134 while using the LISP control-plane and mapping system. 136 8. The design can be used for either 4G/LTE and 5G mobile networks 137 and may be able to support interworking between the different 138 mobile networks. 140 9. The LISP architecture provides a level of indirection for routing 141 and addressing. From a mobile operator's perspective, these 142 mechanisms provide advantages and efficiencies for the URLLC, 143 FMC, and mMTC use cases. See Section 2 for definitions and 144 references of these use cases. 146 The goal of this specification is take advantage of LISP's non- 147 disruptive incremental deployment benefits. This can be achieved by 148 changing the fewest number of components in the mobile network. The 149 proposal suggests adding LISP functionality only to gNB/eNodeB and 150 UPF/pGW nodes. There are no hardware or software changes to the UE 151 devices or the RF-based RAN to realize this architecture. The LISP 152 mapping database system is deployed as an addition to the mobile 153 network and does not require any coordination with existing 154 management and provisioning systems. 156 Similar ID Oriented Networking (ION) mechanisms for the 5G 157 [ARCH5G-3GPP] [PROC5G-3GPP] mobile network are also being considered 158 in other standards organizations such as ETSI [ETSI-NGP] and ITU 159 [ITU-IMT2020]. The NGMN Alliance describes Locator/ID separation as 160 an enabler to meet Key Performance Indicator Requirements [NGMN]. 162 2. Definition of Terms 164 xTR: Is a LISP node in the network that runs the LISP control-plane 165 and data-plane protocols according to [I-D.ietf-lisp-rfc6830bis] 166 and [I-D.ietf-lisp-rfc6833bis]. A formal definition of an xTR can 167 be found in [I-D.ietf-lisp-rfc6830bis]. In this specification, a 168 LISP xTR is a node that runs the LISP control-plane with the GTP 169 data-plane. 171 EID: Is an Endpoint Identifier. EIDs are assigned to UEs and other 172 Internet nodes in LISP sites. A formal definition of an EID can 173 be found in [I-D.ietf-lisp-rfc6830bis]. 175 UE EID: A UE can be assigned an IPv4 and/or an IPv6 address either 176 statically, or dynamically as is the procedure in the mobile 177 network today. These IP addresses are known as LISP EIDs and are 178 registered to the LISP mapping system. These EIDs are used as the 179 source address in packets that the UE originates. 181 RLOC: Is an Routing Locator. RLOCs are assigned to gNB/eNodeBs and 182 UPF/pGWs and other LISP xTRs in LISP sites. A formal definition 183 of an RLOC can be found in [I-D.ietf-lisp-rfc6830bis]. 185 Mapping System: Is the LISP mapping database system that stores EID- 186 to-RLOC mappings. The mapping system is centralized for use and 187 distributed to scale and secure deployment. LISP Map-Register 188 messages are used to publish mappings and LISP Map-Requests 189 messages are used to lookup mappings. LISP Map-Reply messages are 190 used to return mappings. EID-records are used as lookup keys, and 191 RLOC-records are returned as a result of the lookup. Details can 192 be found in [RFC6833]. 194 LISP Control-Plane: In this specification, a LISP xTR runs the LISP 195 control-plane which originates, consumes, and processes Map- 196 Request, Map-Register, Map-Reply, and Map-Notify messages. 198 RAN: Radio Access Network where UE nodes connect to gNB/eNodeB nodes 199 via radios to get access to the Internet. 201 EPC: Evolved Packet Core [EPS-3GPP] system is the part of the mobile 202 network that allows the RAN to connect to a data packet network. 203 The EPC is a term used for the 4G/LTE mobile network. 205 NGC: Next Generation Core [EPS-3GPP] system is the part of the 5G 206 mobile network that allows the RAN to connect to a data packet 207 network. The NGC is roughly equivalent to the 4G EPC. 209 GTP: GTP [GTPv1-3GPP] [GTPv2-3GPP] is the UDP tunneling mechanism 210 used in the LTE/4G and 5G mobile network. 212 UE: User Equipment as defined by [GPRS-3GPP] which is typically a 213 mobile phone. The UE is connected to the network across the RAN 214 to gNB/eNodeB nodes. 216 eNodeB: Is the device defined by [GPRS-3GPP] which borders the RAN 217 and connects UEs to the EPC in a 4G/LTE mobile network. The 218 eNodeB nodes are termination point for a GTP tunnel and are LISP 219 xTRs. The equivalent term in the 5G mobile network is "(R)AN" and 220 "5G-NR", or simply "gNB". In this document, the two terms are 221 used interchangeably. 223 pGW: Is the PDN-Gateway as defined by [GPRS-3GPP] which connects the 224 EPC in a 4G/LTE mobile network to the Internet. The pGW nodes are 225 termination point for a GTP tunnel and is a LISP xTR. The 226 equivalent user/data-plane term in the 5G mobile network is the 227 "UPF", which also has the capability to chain network functions. 228 In this document, the two terms are used interchangeably to mean 229 the border point from the EPC/NGC to the Internet. 231 URLLC: Ultra-Reliable and Low-Latency provided by the 5G mobile 232 network for the shortest path between UEs [NGMN]. 234 FMC: Fixed Mobile Convergence [FMC] is a term used that allows a UE 235 device to move to and from the mobile network. By assigning a 236 fixed EID to a UE device, LISP supports transport layer continuity 237 between the mobile network and a fixed infrastructure such as a 238 WiFi network. 240 mMTC: Massive Machine-Type Services [mMTC] is a term used to refer 241 to using the mobile network for large-scale deployment of Internet 242 of Things (IoT) applications. 244 3. Design Overview 246 LISP will provide layer-3 address mobility based on the procedures in 247 [I-D.ietf-lisp-eid-mobility] where the EID and RLOCs are not co- 248 located. In this design, the EID is assigned to the UE device and 249 the RLOC(s) are assigned to gNB/eNodeB nodes. So any packets going 250 to a UE are always encapsulated to the gNB/eNodeB that associates 251 with the UE. For data flow from the UE to any EIDs (or destinations 252 to non-LISP sites) that are outside of the NGC/EPC, use the RLOCs of 253 the UPF/pGW nodes so the UPF/pGW can send packets into the Internet 254 core (unencapsulated). 256 The following procedures are used to incorporate LISP in the NGC/EPC: 258 o UEs are assigned EIDs. They usually never change. They identify 259 the mobile device and are used for transport connections. If 260 privacy for EIDs is desired, refer to details in 261 [I-D.ietf-lisp-eid-anonymity]. 263 o gNB/eNodeB nodes are LISP xTRs. They have GTP, and optionally 264 LISP, tunnels to the UPF/pGW nodes. The gNB/eNodeB is the RLOC 265 for all EIDs assigned to UE devices that are attached to the gNB/ 266 eNodeB. 268 o UPF/pGW nodes are LISP xTRs. They have GTP, and optionally LISP, 269 tunnels to the gNB/eNodeB nodes. The UPF/pGW is the RLOC for all 270 traffic destined for the Internet. 272 o The LISP mapping system runs in the NGC/EPC. It maps EIDs to 273 RLOC-sets. 275 o Traffic from a UE to UE within a UPF/pGW region can be 276 encapsulated from gNB/eNodeB to another gNB/eNodeB or via the UPF/ 277 pGW, acting as an RTR [I-D.ietf-lisp-rfc6830bis], to provide data- 278 plane policy. 280 o Traffic from a UE to UE across a UPF/pGW region have these options 281 for data flow: 283 1. Encapsulation by a gNB/eNodeB in one region to a gNB/eNodeB in 284 another region. 286 2. Encapsulation by a gNB/eNodeB in one region to a UPF/pGW in 287 the same region and then the UPF/pGW reencapsulates to a gNB/ 288 eNodeB in another region. 290 3. Encapsulation by a gNB/eNodeB in one region to a UPF/pGW in 291 another region and then the UPF/pGW reencapsulates to a gNB/ 292 eNodeB in its same region 294 4. Encapsulation by the gNB/eNodeB to a LISP xTR outside of the 295 mobile network. An xTR outside of the mobile network could be 296 a router in a data-center, a router at the edge of a WAN at a 297 remote branch, or a WiFi access-point, and even a gNB/eNodeB 298 in another carrier's mobile network. All these deployment 299 options are to be considered for future architectures. 301 o Note when encapsulation happens between a gNB/eNodeB and a UPF/ 302 pGW, GTP is used as the data-plane and when encapsulation between 303 two gNB/eNodeBs occur, LISP can be used as the data-plane when 304 there is no X2 interface [X2-3GPP] between the gNB/eNodeB nodes. 306 o The UPF/pGW nodes register their RLOCs for a default EID-prefix to 307 the LISP mapping system. This is done so gNB/eNodeB nodes can 308 find UPF/pGW nodes to encapsulate to. 310 o The gNB/eNodeB nodes register EIDs to the mapping system for the 311 UE nodes. The registration occurs when gNB/eNodeB nodes discover 312 the layer-3 addresses of the UEs that connect to them. The gNB/ 313 eNodeB nodes register multiple RLOCs associated with the EIDs to 314 get multi-homing and path diversity benefits from the NGC/EPC 315 network. 317 o When a UE moves off a gNB/eNodeB, the gNB/eNodeB node deregisters 318 itself as an RLOC for the EID associated with the UE. 320 o Optionally, and for further study for future architectures, the 321 gNB/eNodeB or UPF/pGW could encapsulate to an xTR that is outside 322 of the NGC/EPC network. They could encapsulate to a LISP CPE 323 router at a branch office, a LISP top-of-rack router in a data 324 center, a LISP wifi access-point, LISP border routers at a hub 325 site, and even a LISP router running in a VM or container on a 326 server. 328 The following diagram illustrates the LTE mobile network topology and 329 structure [LTE401-3GPP] [LTE402-3GPP]: 331 (--------------------------------------------) 332 ( ) 333 ( Internet ) 334 ( ) 335 (--------------------------------------------) 336 | | 337 | | 338 (---------|---------) (---------|---------) 339 ( UPF-pGW ) ( UPF-pGW ) 340 ( ) ( ) 341 ( NGC/EPC ) ( NGC/EPC ) 342 ( ) ( ) 343 ( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB ) 344 (---/--\-----/--\---) (---/--\-----/--\---) 345 / \ / \ / \ / \ 346 / \ / \ / \ / \ 347 / \ / \ 348 / RAN \ / RAN \ 349 / \ / \ 350 ( UE UE UE ) ( UE UE UE ) 352 LTE/5G Mobile Network Architecture 354 The following diagram illustrates how LISP is used on the mobile 355 network: 357 (1) IPv6 EIDs are assigned to UEs. 358 (2) RLOCs assigned to gNB/eNodeB nodes are [a1,a2], [b1,b2], [c1,c2], [d1,d2] 359 on their uplink interfaces. 360 (3) RLOCs assigned to UPF/pGW nodes are [p1,p2], [p3,p4]. 361 (4) RLOCs can be IPv4 or IPv6 addresses or mixed RLOC-sets. 363 (--------------------------------------------) 364 ( ) 365 ( Internet ) 366 ( ) 367 (--------------------------------------------) 368 | | 369 | | 370 (---------|---------) (---------|---------) 371 ( UPF-pGW ) ( UPF-pGW ) 372 ( p1 p2 ) ( p3 p4 ) 373 ( ) ( ) 374 ( NGC/EPC ) ( NGC/EPC ) 375 ( ) ( ) 376 ( a1 a2 b1 b2 ) ( c1 c2 d1 d2 ) 377 ( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB ) 378 (---/--\-----/--\---) (---/--\-----/--\---) 379 / \ / \ / \ / \ 380 / \ / \ / \ / \ 381 / \ / \ 382 / RAN \ / RAN \ 383 / \ / \ 384 ( UE UE UE ) ( UE UE UE ) 385 EIDs: a::1 b::1 c::1 x::1 y::1 z::1 387 Mobile Network with EID/RLOC Assignment 389 The following table lists the EID-to-RLOC entries that reside in the LISP 390 Mapping System when the above UEs are are attached to the 4 gNB/eNodeBs: 392 EID-Record RLOC-Record Commentary Footnote 393 0::/0 [p1,p2,p3 p4] gNB/eNodeBs encap to p1-p4 for Internet (1) 394 destinations which are non-EIDs 396 a::1/128 [a1,a2] UPF/pGWs load-split traffic to [a1,a2] for (2) 397 UE a::1 and it can move to [b1,b2] 399 b::1/128 [a1,a2] gNB/eNodeB tracks both UEs a::1 and b::1, (3) 400 it can do local routing between the UEs 402 c::1/128 [b1,b2] UE c::1 can roam to [c1,c2] or [d1,d2], (4) 403 may use UPF/pGW [p1,p2] after move 405 x::1/128 [c1,c2] UE x::1 can talk directly to UE y::1, (5) 406 gNB/eNodeBs encap to each other 408 y::1/128 [d1,d2] UE can talk to Internet when [d1,d2], (6) 409 encap to UPF/pGW [p3,p4] or use backup [p1,p2] 411 z::1/128 [d1,d2] UE z::1 can talk to a::1 directly (7) 412 where [d1,d2] encaps to [a1,a2] 414 (1) For packets that flow from UE nodes to destinations that are not 415 in LISP sites, the gNB/eNodeB node uses one of the RLOCs p1, p2, p3, 416 or p4 as the destination address in the outer encapsulated header. 417 Encapsulated packets are then routed by the NGC/EPC core to the UPF/ 418 pGW nodes. In turn, the UPF/pGW nodes, then route packets into the 419 Internet core. 421 (2) Packets that arrive to UPF/pGW nodes from the Internet destined 422 to UE nodes are encapsulated to one of the gNB/eNodeB RLOCs a1, a2, 423 b1, b2. When UE, with EID a::1 is attached to the leftmost gNB/ 424 eNodeB, the EID a::1 is registered to the mapping system with RLOCs 425 a1 and a2. When UE with EID c::1 is attached to the rightmost gNB/ 426 eNodeB (in the left region), the EID c::1 is registered to the 427 mapping system with RLOCs b1 and b2. 429 (3) If UE with EID a::1 and UE with EID b::1 are attached to the same 430 gNB/eNodeB node, the gNB/eNodeB node tracks what radio interface to 431 use to route packets from one UE to the other. 433 (4) If UE with EID c::1 roams away from gNB/eNodeB with RLOCs b1 and 434 b2, to the gNB/eNodeB with RLOCs c1 and c2 (in the rightmost region), 435 packets destined toward the Internet, can use any UPF/pGW. Any 436 packets that flow back from the Internet can use any UPF/pGW. In 437 either case, the UPF/pGW is informed by the mapping system that the 438 UE with EID c::1 has new RLOCs and should now encapsulate to either 439 RLOC c1 or c2. 441 (5) When UE with EID x::1 is attached to gNB/eNodeB with RLOCs c1 and 442 c2 and UE with EID y::1 is attached to gNB/eNodeB with RLOCs d1 and 443 d2, they can talk directly, on the shortest path to each gNB/eNodeB, 444 when each encapsulates packets to each other's RLOCs. 446 (6) When packets from UE with EID y::1 are destined for the Internet, 447 the gNB/eNodeB with RLOCs d1 and d2 that the UE is attached to can 448 use any exit UPF/pGWs RLOCs p1, p2, p3, or p4. 450 (7) UE with EID z::1 can talk directory to UE with EID a::1 by each 451 gNB/eNodeB they are attached to encapsulsates to each other's RLOCs. 452 In case (5), the two gNB/eNodeB's were in the same region. In this 453 case, the gNB/eNodeBs are in different regions. 455 The following abbreviated diagram shows a topology that illustrates 456 how a UE roams with LISP across UPF/pGW regions: 458 (--------------------------------------------) 459 ( ) 460 ( Internet ) 461 ( ) 462 (--------------------------------------------) 463 | | 464 | | 465 (---------|---------) (---------|---------) 466 ( UPF-pGW ) ( UPF-pGW ) 467 ( p1 p2 ) ( p3 p4 ) 468 ( ) ( ) 469 ( NGC/EPC ) ( NGC/EPC ) 470 ( ) ( ) 471 ( a1 a2 b1 b2 ) ( c1 c2 d1 d2 ) 472 ( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB ) 473 (---/--\-----/--\---) (---/--\-----/--\---) 474 / \ / \ / \ / \ 475 / \ / \ / \ / \ 476 / \ / \ 477 / RAN \ / RAN \ 478 / \ / \ 479 ( UE ------------------------------> UE ) 480 a::1 a::1 482 UE EID Mobility 484 The contents of the LISP mapping database before UE moves: 486 EID-Record RLOC-Record Commentary 487 0::/0 [p1,p2,p3,p4] gNB/eNodeB [a1,a2] encaps to p1-p4 for Internet 488 destinations when a::1 on gNB/eNodeB [a1,a2] 490 a::1/128 [a1,a2] Before UE moves to other UPF/pGW region 492 The contents of the LISP mapping database after UE moves: 494 EID-Record RLOC-Record Commentary 495 0::/0 [p1,p2,p3,p4] gNB/eNodeB [d1,d2] encaps to p1-p4 for Internet 496 destinations when a::1 moves to gNB/eNodeB 497 [d1,d2] 499 a::1/128 [d1,d2] After UE moves to new UPF/pGW region 500 4. Addressing and Routing 502 UE based EID addresses will be IPv6 addresses. It will be determined 503 at a future time what length the IPv6 prefix will be to cover all UEs 504 in a mobile network. This coarse IPv6 prefix is called an EID-prefix 505 where more-specific EID-prefixes will be allocated out of it for each 506 UPF/pGW node. Each UPF/pGW node is responsible for advertising the 507 more-specific EID-prefix into the Internet routing system so they can 508 attract packets from non-EIDs nodes to UE EIDs. 510 An RLOC address will either be an IPv4 or IPv6 address depending on 511 the support for single or dual-stack address-family in the NGC/EPC 512 network. An RLOC-set in the mapping system can have a mixed address- 513 family locator set. There is no requirement for the NGC/EPC to 514 change to support one address-family or the other. And there is no 515 requirement for the NGC/EPC network to support IPv4 multicast or IPv6 516 multicast. The LISP overlay will support both. 518 The only requirement for RLOC addresses is that they are routable in 519 the NGC/EPC and the Internet. 521 The requirements of the LISP and GTP data-plane overlay is to support 522 a layer-3 overlay network only. There is no architectural 523 requirement to support layer-2 overlays. However, operators may want 524 to provide a layer-2 LAN service over their mobile network. Details 525 about how LISP supports layer-2 overlays can be found in 526 [I-D.ietf-lisp-eid-mobility]. 528 5. gNB/eNodeB LISP Functionality 530 The gNB/eNodeB node runs as a LISP xTR for control-plane 531 functionality and runs GTP for data-plane functionality. Optionally, 532 the LISP data-plane can be used to establish dynamic tunnels from one 533 gNB/eNodeB node to another gNB/eNodeB node. 535 The gNB/eNodeB LISP xTR will follow the procedures of 536 [I-D.ietf-lisp-eid-mobility] to discover UE based EIDs, track them by 537 monitoring liveness, registering them when appear, and deregistering 538 them when they move away. Since the gNB/eNodeB node is an xTR, it is 539 acting as a layer-3 router and the GTP tunnel from the gNB/eNodeB 540 node to the UPF/pGW node is realizing a layer-3 overlay. This will 541 provide scaling benefits since broadcast and link-local multicast 542 packets won't have to travel across the NGC/EPC to the UPF/pGW node. 544 A day in the life of a UE originated packet: 546 1. The UE node originates an IP packet over the RAN. 548 2. The gNB/eNodeB receives an IPv4/IPv6 packet, it extracts the 549 source address from the packet, learns the UE based EID, stores 550 its RAN location locally and registers the EID to the mapping 551 system. 553 3. The gNB/eNodeB extracts the destination address, looks up the 554 address in the mapping system. The lookup returns the RLOC of a 555 UPF/pGW node if the destination is not an EID or an RLOC gNB/ 556 eNodeB node if the destination is a UE based EID. 558 4. The gNB/eNodeB node encapsulates the packet to the RLOC using GTP 559 or optionally the LISP data-plane. 561 It is important to note that in [I-D.ietf-lisp-eid-mobility], EID 562 discovery occurs when a LISP xTR receives an IP or ARP/ND packet. 563 However, if there are other methods to discover the EID of a device, 564 like in UE call setup, the learning and registration referenced in 565 Paragraph 2 can happen before any packet is sent. 567 6. UPF/pGW LISP Functionality 569 The UPF/pGW node runs as a LISP xTR for control-plane functionality 570 and runs GTP for data-plane functionality. Optionally, the LISP 571 data-plane can be used to establish dynamic tunnels from one UPF/pGW 572 node to another UPF/pGW or gNB/eNodeB node. 574 The UPF/pGW LISP xTR does not follow the EID mobility procedures of 575 [I-D.ietf-lisp-eid-mobility] since it is not responsible for 576 discovering UE based EIDs. A UPF/pGW LISP xTR simply follows the 577 procedures of a PxTR in [I-D.ietf-lisp-rfc6830bis] and for 578 interworking to non-EID sites in [RFC6832]. 580 A day in the life of a UPF/pGW received packet: 582 1. The UPF/pGW node receives a IP packet from the Internet core. 584 2. The UPF/pGW node extracts the destination address from the packet 585 and looks it up in the LISP mapping system. The lookup returns 586 an RLOC of a gNB/eNodeB node. Optionally, the RLOC could be 587 another UPF/pGW node. 589 3. The UPF/pGW node encapsulates the packet to the RLOC using GTP or 590 optionally the LISP data-plane. 592 7. Compatible Data-Plane using GTP 594 Since GTP is a UDP based encapsulating tunnel protocol, it has the 595 same benefits as LISP encapsulation. At this time, there appears to 596 be no urgent need to not continue to use GTP for tunnels between a 597 gNB/eNodeB nodes and between a gNB/eNodeB node and a UPF/pGW node. 599 There are differences between GTP tunneling and LISP tunneling. GTP 600 tunnels are setup at call initiation time. LISP tunnels are 601 dynamically encapsulating, used on demand, and don't need setup or 602 teardown. The two tunneling mechanisms are a hard state versus soft 603 state tradeoff. 605 This specification recommends for early phases of deployment, to use 606 GTP as the data-plane so a transition for it to use the LISP control- 607 plane can be achieved more easily. At later phases, the LISP data- 608 plane may be considered so a more dynamic way of using tunnels can be 609 achieved to support URLLC. 611 This specification recommends the use of procedures from 612 [I-D.ietf-lisp-eid-mobility] and NOT the use of LISP-MN 613 [I-D.ietf-lisp-mn]. Using LISP-MN states that a LISP xTR resides on 614 the mobile UE. This is to be avoided so extra encapsulation header 615 overhead is NOT sent on the RAN. The LISP data-plane or control- 616 plane will not run on the UE. 618 8. Roaming and Packet Loss 620 Using LISP for the data-plane has some advantages in terms of 621 providing near-zero packet loss. In the current mobile network, 622 packets are queued on the gNB/eNodeB node the UE is roaming to or 623 rerouted on the gNB/eNodeB node the UE has left. In the LISP 624 architecture, packets can be sent to multiple "roamed-from" and 625 "roamed-to" nodes while the UE is moving or is off the RAN. See 626 mechanisms in [I-D.ietf-lisp-predictive-rlocs] for details. 628 9. Mobile Network LISP Mapping System 630 The LISP mapping system stores and maintains EID-to-RLOC mappings. 631 There are two mapping database transport systems that are available 632 for scale, LISP-ALT [RFC6836] and LISP-DDT [RFC8111]. The mapping 633 system will store EIDs assigned to UE nodes and the associated RLOCs 634 assigned to gNB/eNodeB nodes and UPF/pGW nodes. The RLOC addresses 635 are routable addresses by the NGC/EPC network. 637 This specification recommends the use of LISP-DDT. 639 10. LISP Over the 5G N3/N6/N9 Interfaces 641 So far in this specification we have described how LISP runs on the 642 gNB and UPF nodes in the mobile network. In the 5G architecture 643 [ARCH5G-3GPP] definition, some key components are Access and Mobility 644 Management Function (AMF) and the Session Management Function (SMF). 645 These two components provide control plane functionality to off-load 646 session anchoring by distributing state and packet flow among 647 multiple nodes in the NGC. These functions control the data-plane 648 anchors deployed in Branch Point Uplink Classifier (BP/ULCL) in UPF 649 data-plane nodes. 651 Here is an illustration where a BP/ULCL-UPF node would appear in the 652 mobile network: 654 (--------------------------------------------) 655 ( Internet ) 656 +-> (--------------------------------------------) 657 | | 658 N6 | 659 | (---------|---------) 660 +-> ( UPF ) <-+ 661 NGC ( [p1,p2] ) | 662 ( ) N9 663 +-> ( BP/ULCL ) | 664 | ( UPF [p3,p4] ) <-+ 665 N3 ( ) 666 | ( [a1] [a2] ) 667 +-> ( gNB gNB ) 668 (---/--\-----/--\---) 669 / \ / \ 670 / \ 671 / RAN \ 672 / \ 673 ( UE UE UE ) 674 a::1 a::2 a::3 676 The BP/ULCL-UPF node is configured as an LISP RTR and uses the 677 Traffic Engineering features of LISP specified in [I-D.ietf-lisp-te]. 678 In LISP-TE an Explicit Locator Path (ELP) can be stored in the RLOC- 679 record for any given EID thereby allowing packet flow from a UE to 680 the Internet to traverse through the BP/UCLC-UPF node. A UE 681 originated packet is encapsulated by the gNB to the BP/ULCL-UPF which 682 decapsulates and reencapsulates to the UPF at the Internet border. 683 This allows LISP to run over the 5G N3 and N9 interface with one 684 mapping entry. And if the ELP contained an xTR outside of the mobile 685 network, LISP could also run over the N6 interface. 687 The contents of the LISP mapping database: 689 EID-Record RLOC-Record Commentary 690 0::/0 [ELP{a1,p3,p1}, 4 RLOC-records, 2 with paths through the BP-UPF 691 ELP{a1,p4,p2}, and 2 directly to the border UPF from UEs 692 p1, p2] connected to gNB with RLOC a1 694 a::1/128 [a1,a2] The UPF or BP-UPF can encap directly for UE with 695 EID a::1 to either gNB with optimized latency 697 a::2/128 [ELP{p1,p3,a2}, The UPF can encap to either RLOC p3 or p4 to 698 ELP{p1,p4,a2}] forward traffic through the BP-UPF on its way 699 toward gNB with RLOC a1 701 a::3/128 [ELP{p1,p3,a2}, The UPF can encap to the BP-UPF or directly 702 a2] to gNB with RLOC a2 to reach UE with EID a::3 704 11. Multicast Considerations 706 Since the mobile network runs the LISP control-plane, and the mapping 707 system is available to support EIDs for unicast packet flow, it can 708 also support multicast packet flow. Support for multicast can be 709 provided by the LISP/GTP overlay with no changes to the NGC/EPC 710 network. 712 Multicast (S-EID,G) entries can be stored and maintained in the same 713 mapping database that is used to store UE based EIDs. Both Internet 714 connected nodes, as well as UE nodes, can source multicast packets. 715 The protocol procedures from [I-D.ietf-lisp-signal-free-multicast] 716 are followed to make multicast delivery available. Both multicast 717 packet flow and UE mobility can occur at the same time. 719 A day in the life of a 1-to-many multicast packet: 721 1. A UE node joins an (S,G) multicast flow by using IGMPv2 or 722 IGMPv3. 724 2. The gNB/eNodeB node records which UE on the RAN should get 725 packets sourced by S and destined for group G. 727 3. The gNB/eNodeB node registers the (S,G) entry to the mapping 728 system with its RLOC according to the receiver site procedures in 729 [I-D.ietf-lisp-signal-free-multicast]. The gNB/eNodeB does this 730 to show interest in joining the multicast flow. 732 4. When other UE nodes join the same (S,G), their associated gNB/ 733 eNodeB nodes will follow the procedures in steps 1 through 3. 735 5. The (S,G) entry stored in the mapping database has an RLOC-set 736 which contains a replication list of all the gNB/eNodeB RLOCs 737 that registered. 739 6. A multicast packet from source S to destination group G arrives 740 at the UPF/pGW. The UPF/pGW node looks up (S,G), gets returned 741 the replication list of all joined gNB/eNodeB nodes and 742 replicates the multicast packet by encapsulating the packet to 743 each of them. 745 7. Each gNB/eNodeB node decapsulates the packet and delivers the 746 multicast packet to one or more IGMP-joined UEs on the RAN. 748 12. Security Considerations 750 For control-plane authentication and authorization procedures, this 751 specification recommends the mechanisms in 752 [I-D.ietf-lisp-rfc6833bis], LISP-SEC [I-D.ietf-lisp-sec] and LISP- 753 ECDSA [I-D.farinacci-lisp-ecdsa-auth]. 755 For data-plane privacy procedures, this specification recommends the 756 mechanisms in [RFC8061] When the LISP data-plane is used. Otherwise, 757 the NGC/EPC must provide data-plane encryption support. 759 13. IANA Considerations 761 There are no specific requests for IANA. 763 14. SDO Recommendations 765 The authors request other Standards Development Organizations to 766 consider LISP as a technology for device mobility. It is recommended 767 to start with this specification as a basis for design and develop 768 more deployment details in the appropriate Standards Organizations. 769 The authors are willing to facilitate this activity. 771 15. References 773 15.1. Normative References 775 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 776 DOI 10.17487/RFC1700, October 1994, 777 . 779 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 780 "Interworking between Locator/ID Separation Protocol 781 (LISP) and Non-LISP Sites", RFC 6832, 782 DOI 10.17487/RFC6832, January 2013, 783 . 785 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 786 Protocol (LISP) Map-Server Interface", RFC 6833, 787 DOI 10.17487/RFC6833, January 2013, 788 . 790 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 791 "Locator/ID Separation Protocol Alternative Logical 792 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 793 January 2013, . 795 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 796 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 797 February 2017, . 799 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 800 (LISP) Data-Plane Confidentiality", RFC 8061, 801 DOI 10.17487/RFC8061, February 2017, 802 . 804 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 805 Smirnov, "Locator/ID Separation Protocol Delegated 806 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 807 May 2017, . 809 15.2. Informative References 811 [ARCH5G-3GPP] 812 "System Architecture for the 5G System", TS.23.501 813 https://portal.3gpp.org/desktopmodules/Specifications/ 814 SpecificationDetails.aspx?specificationId=3144, December 815 2016. 817 [EPS-3GPP] 818 "Non-Access-Stratum (NAS) Protocol for Evolved Packet 819 System (EPS); Stage 3", TS.23.501 820 https://portal.3gpp.org/desktopmodules/specifications/ 821 specificationdetails.aspx?specificationid=1072, December 822 2017. 824 [ETSI-NGP] 825 "NGP Evolved Architecture for mobility using Identity 826 Oriented Networks", NGP-004, version 1.1.1 827 https://portal.etsi.org/webapp/WorkProgram/ 828 Report_WorkItem.asp?WKI_ID=50531, January 2018. 830 [FMC] "[TS23316] 3rd Generation Partnership Project; Technical 831 Specification Group Services and System Aspects; Wireless 832 and wireline convergence access support for the 5G System 833 (5GS) (Release 16), 3GPP TS23.316", November 2018. 835 [GPRS-3GPP] 836 "General Packet Radio Service (GPRS) for Evolved Universal 837 Terrestrial Radio Access Network (E-UTRAN) Access", 838 TS23.401 Release 8 839 https://portal.3gpp.org/desktopmodules/specifications/ 840 specificationdetails.aspx?specificationid=849, January 841 2015. 843 [GTPv1-3GPP] 844 "General Packet Radio System (GPRS) Tunnelling Protocol 845 User Plane (GTPv1-U)", TS.29.281 846 https://portal.3gpp.org/desktopmodules/Specifications/ 847 SpecificationDetails.aspx?specificationId=1699, January 848 2015. 850 [GTPv2-3GPP] 851 "3GPP Evolved Packet System (EPS); Evolved General Packet 852 Radio Service (GPRS) Tunnelling Protocol for Control plane 853 (GTPv2-C); Stage 3", TS.29.274 854 https://portal.3gpp.org/desktopmodules/Specifications/ 855 SpecificationDetails.aspx?specificationId=1692, January 856 2015. 858 [I-D.farinacci-lisp-ecdsa-auth] 859 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 860 Authentication and Authorization", draft-farinacci-lisp- 861 ecdsa-auth-03 (work in progress), September 2018. 863 [I-D.ietf-lisp-eid-anonymity] 864 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 865 EID Anonymity", draft-ietf-lisp-eid-anonymity-11 (work in 866 progress), September 2021. 868 [I-D.ietf-lisp-eid-mobility] 869 Comeras, M. P., Ashtaputre, V., Maino, F., Moreno, V., and 870 D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified 871 Control Plane", draft-ietf-lisp-eid-mobility-09 (work in 872 progress), January 2022. 874 [I-D.ietf-lisp-introduction] 875 Cabellos, A. and D. S. (Ed.), "An Architectural 876 Introduction to the Locator/ID Separation Protocol 877 (LISP)", draft-ietf-lisp-introduction-15 (work in 878 progress), September 2021. 880 [I-D.ietf-lisp-mn] 881 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 882 Mobile Node", draft-ietf-lisp-mn-11 (work in progress), 883 January 2022. 885 [I-D.ietf-lisp-predictive-rlocs] 886 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 887 RLOCs", draft-ietf-lisp-predictive-rlocs-09 (work in 888 progress), October 2021. 890 [I-D.ietf-lisp-rfc6830bis] 891 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 892 Cabellos, "The Locator/ID Separation Protocol (LISP)", 893 draft-ietf-lisp-rfc6830bis-36 (work in progress), November 894 2020. 896 [I-D.ietf-lisp-rfc6833bis] 897 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 898 "Locator/ID Separation Protocol (LISP) Control-Plane", 899 draft-ietf-lisp-rfc6833bis-30 (work in progress), November 900 2020. 902 [I-D.ietf-lisp-sec] 903 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 904 "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-25 (work 905 in progress), December 2021. 907 [I-D.ietf-lisp-signal-free-multicast] 908 Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 909 Separation Protocol (LISP) Multicast", draft-ietf-lisp- 910 signal-free-multicast-09 (work in progress), March 2018. 912 [I-D.ietf-lisp-te] 913 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 914 Engineering Use-Cases", draft-ietf-lisp-te-09 (work in 915 progress), September 2021. 917 [ITU-IMT2020] 918 "Focus Group on IMT-2020", 919 https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC- 920 M.687-2-199702-I!!PDF-E.pdf. 922 [LTE401-3GPP] 923 "General Packet Radio Service (GPRS) enhancements for 924 Evolved Universal Terrestrial Radio Access Network 925 (E-UTRAN) access", TS.23.401 926 https://portal.3gpp.org/desktopmodules/Specifications/ 927 SpecificationDetails.aspx?specificationId=849, January 928 2015. 930 [LTE402-3GPP] 931 "Architecture enhancements for non-3GPP accesses", 932 TS.23.402 933 https://portal.3gpp.org/desktopmodules/Specifications/ 934 SpecificationDetails.aspx?specificationId=850, January 935 2015. 937 [mMTC] "NGMN KPIs and Deployment Scenarios for Consideration for 938 IMT2020", https://www.ngmn.org/uploads/media/151204_NGMN_ 939 KPIs_and_Deployment_Scenarios_for_Consideration_for_IMT_20 940 20_-_LS_Annex_V1_approved.pdf, December 2015. 942 [NGMN] "5G End-to-End Architecture Framework", NGMN 943 https://www.ngmn.org/uploads/ 944 media/201117-NGMN_E2EArchFramework_v4.31.pdf, November 945 2020. 947 [PROC5G-3GPP] 948 "Procedures for the 5G System", TS.23.502 949 https://portal.3gpp.org/desktopmodules/Specifications/ 950 SpecificationDetails.aspx?specificationId=3145, December 951 2016. 953 [X2-3GPP] "Evolved Universal Terrestrial Radio Access Network 954 (E-UTRAN); X2 Application Protocol (X2AP)", TS.36.423 955 https://portal.3gpp.org/desktopmodules/Specifications/ 956 SpecificationDetails.aspx?specificationId=2452, June 2017. 958 Appendix A. Acknowledgments 960 The authors would like to thank Gerry Foster and Peter Ashwood Smith 961 for their expertise with 3GPP mobile networks and for their early 962 review and contributions. The authors would also like to thank Fabio 963 Maino, Malcolm Smith, and Marc Portoles for their expertise in both 964 5G and LISP as well as for their early review comments. 966 The authors would like to give a special thank you to Ryosuke 967 Kurebayashi from NTT Docomo and Kalyani Bogineni from Verizon for 968 their operational and practical commentary. 970 Appendix B. Document Change Log 972 B.1. Changes to draft-farinacci-lisp-mobile-network-14 974 o Posted March 2022. 976 o Update references and document timer. 978 B.2. Changes to draft-farinacci-lisp-mobile-network-13 980 o Posted September 2021. 982 o Updated Uma's affliation. 984 B.3. Changes to draft-farinacci-lisp-mobile-network-12 986 o Posted September 2021. 988 o Update references and document timer. 990 B.4. Changes to draft-farinacci-lisp-mobile-network-11 992 o Posted March 2021. 994 o Changes to reflect editorial comments from Dirk von-Hugo. 996 o Updated ITU and 5G references (manually). 998 B.5. Changes to draft-farinacci-lisp-mobile-network-10 1000 o Posted March 2021. 1002 o Update references and document timer. 1004 B.6. Changes to draft-farinacci-lisp-mobile-network-09 1006 o Posted September 2020. 1008 o Update references and document timer. 1010 B.7. Changes to draft-farinacci-lisp-mobile-network-08 1012 o Posted March 2020. 1014 o Change author affliations. 1016 B.8. Changes to draft-farinacci-lisp-mobile-network-07 1018 o Posted March 2020. 1020 o Update references and document timer. 1022 B.9. Changes to draft-farinacci-lisp-mobile-network-06 1024 o Posted September 2019. 1026 o Update references and document timer. 1028 B.10. Changes to draft-farinacci-lisp-mobile-network-05 1030 o Posted March 2019. 1032 o Update references and document timer. 1034 B.11. Changes to draft-farinacci-lisp-mobile-network-04 1036 o Posted September 2018. 1038 o Update document timer. 1040 B.12. Changes to draft-farinacci-lisp-mobile-network-03 1042 o Posted March 2018. 1044 o Make the spec more 5G user-friendly. That is, the design has 1045 always worked for either 4G or 5G but we make it more clear about 1046 5G by using some basic 5G node terminlogy. 1048 o Add a section how LISP can work on the N3, N6, and N9 5G spec 1049 interfaces. 1051 o Describe how LISP-TE can allow BP-UPF offload functionality. 1053 B.13. Changes to draft-farinacci-lisp-mobile-network-02 1055 o Posted mid September 2017. 1057 o Editorial fixes from draft -01. 1059 B.14. Changes to draft-farinacci-lisp-mobile-network-01 1061 o Posted September 2017. 1063 o Explain each EID case illustrated in the "Mobile Network with EID/ 1064 RLOC Assignment" diagram. 1066 o Make a reference to mMTC as a 3GPP use-case for 5G. 1068 o Add to the requirements section how mobile operators believe that 1069 using Locator/ID separation mechanisms provide for more efficient 1070 mobile netwowks. 1072 o Indicate that L2-overlays is not recommended by this specification 1073 as the LISP mobile network architeture but how operators may want 1074 to deploy a layer-2 overlay service. 1076 B.15. Changes to draft-farinacci-lisp-mobile-network-00 1078 o Initial draft posted August 2017. 1080 Authors' Addresses 1082 Dino Farinacci 1083 lispers.net 1084 San Jose, CA 1085 USA 1087 Email: farinacci@gmail.com 1089 Padma Pillay-Esnault 1090 Independent 1091 Santa Clara, CA 1092 USA 1094 Email: padma.ietf@gmail.com 1096 Uma Chunduri 1097 Intel Corporation 1098 Santa Clara, CA 1099 USA 1101 Email: umac.ietf@gmail.com