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