idnits 2.17.1 draft-farinacci-lisp-mobile-network-04.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 11, 2018) is 2052 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC1700' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC8060' is defined on line 784, 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-02 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-02 == 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-02 == Outdated reference: A later version (-14) exists of draft-ietf-lisp-predictive-rlocs-02 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-16 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-13 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-te-02 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 15, 2019 U. Chunduri 6 Huawei Technologies 7 September 11, 2018 9 LISP for the Mobile Network 10 draft-farinacci-lisp-mobile-network-04 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 15, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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-04 . . . . 23 73 B.2. Changes to draft-farinacci-lisp-mobile-network-03 . . . . 23 74 B.3. Changes to draft-farinacci-lisp-mobile-network-02 . . . . 23 75 B.4. Changes to draft-farinacci-lisp-mobile-network-01 . . . . 23 76 B.5. Changes to draft-farinacci-lisp-mobile-network-00 . . . . 24 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 79 1. Introduction 81 The LISP architecture and protocols [RFC6830] introduces two new 82 numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators 83 (RLOCs) which provide an architecture to build overlays on top of the 84 underlying Internet. Mapping EIDs to RLOC-sets is accomplished with 85 a Mapping Database System. By using a level of indirection for 86 routing and addressing, separating an address identifier from its 87 location can allow flexible and scalable mobility. By assigning EIDs 88 to mobile devices and RLOCs to the network nodes that support such 89 mobile devices, LISP can provide seamless mobility. 91 For a reading audience unfamiliar with LISP, a brief tutorial level 92 document is available at [I-D.ietf-lisp-introduction]. 94 This specification will describe how LISP can be used to provide 95 layer-3 mobility within and across an LTE [LTE401-3GPP] [LTE402-3GPP] 96 and 5G [ARCH5G-3GPP] [PROC5G-3GPP] mobile network. 98 The following are the design requirements: 100 1. Layer-3 address mobility is provided within a mobile network RAN 101 supported by a UPF/pGW region (intra-UPF/pGW) as well as across 102 UPF/pGW regions (inter-UPF/pGW). 104 2. UE nodes can get layer-3 address mobility when roaming off the 105 mobile network to support Fixed Mobile Convergence [FMC]. 107 3. Transport layer session survivability exists while roaming 108 within, across, and off of the mobile network. 110 4. No address management is required when UEs roam. EID addresses 111 are assigned to UEs at subscription time. EIDs can be reassigned 112 when UE ownership changes. 114 5. The design will make efficient use of radio resources thereby not 115 adding extra headers to packets that traverse the RAN. 117 6. The design can support IPv4 unicast and multicast packet delivery 118 and will support IPv6 unicast and multicast packet delivery. 120 7. The design will allow use of both the GTP [GTPv1-3GPP] 121 [GTPv2-3GPP] and LISP [I-D.ietf-lisp-rfc6830bis] data-planes 122 while using the LISP control-plane and mapping system. 124 8. The design can be used for either 4G/LTE and 5G mobile networks 125 and may be able to support interworking between the different 126 mobile networks. 128 9. The LISP architecture provides a level of indirection for routing 129 and addressing. From a mobile operator's perspective, these 130 mechanisms provide advantages and efficiencies for the URLLC, 131 FMC, and mMTC use cases. See Section 2 for definitions and 132 references of these use cases. 134 The goal of this specification is take advantage of LISP's non- 135 disruptive incremental deployment benefits. This can be achieved by 136 changing the fewest number of components in the mobile network. The 137 proposal suggests adding LISP functionality only to gNB/eNodeB and 138 UPF/pGW nodes. There are no hardware or software changes to the UE 139 devices or the RF-based RAN to realize this architecture. The LISP 140 mapping database system is deployed as an addition to the mobile 141 network and does not require any coordination with existing 142 management and provisioning systems. 144 Similar ID Oriented Networking (ION) mechanisms for the 5G 145 [ARCH5G-3GPP] [PROC5G-3GPP] mobile network are also being considered 146 in other standards organizations such as ETSI [ETSI-NGP] and ITU 147 [ITU-IMT2020]. The NGMN Alliance describes Locator/ID separation an 148 enabler to meet Key Performance Indicator Requirements [NGMN]. 150 2. Definition of Terms 152 xTR: Is a LISP node in the network that runs the LISP control-plane 153 and data-plane protocols according to [I-D.ietf-lisp-rfc6830bis] 154 and [I-D.ietf-lisp-rfc6833bis]. A formal definition of an xTR can 155 be found in [RFC6830]. In this specification, a LISP xTR is a 156 node that runs the LISP control-plane with the GTP data-plane. 158 EID: Is an Endpoint Identifier. EIDs are assigned to UEs and other 159 Internet nodes in LISP sites. A formal definition of an EID can 160 be found in [RFC6830]. 162 UE EID: A UE can be assigned an IPv4 and/or an IPv6 address either 163 statically, or dynamically as is the procedure in the mobile 164 network today. These IP addresses are known as LISP EIDs and are 165 registered to the LISP mapping system. These EIDs are used as the 166 source address in packets that the UE originates. 168 RLOC: Is an Routing Locator. RLOCs are assigned to gNB/eNodeBs and 169 UPF/pGWs and other LISP xTRs in LISP sites. A formal definition 170 of an RLOC can be found in [RFC6830]. 172 Mapping System: Is the LISP mapping database system that stores EID- 173 to-RLOC mappings. The mapping system is centralized for use and 174 distributed to scale and secure deployment. LISP Map-Register 175 messages are used to publish mappings and LISP Map-Requests 176 messages are used to lookup mappings. LISP Map-Reply messages are 177 used to return mappings. EID-records are used as lookup keys, and 178 RLOC-records are returned as a result of the lookup. Details can 179 be found in [RFC6833]. 181 LISP Control-Plane: In this specification, a LISP xTR runs the LISP 182 control-plane which originates, consumes, and processes Map- 183 Request, Map-Register, Map-Reply, and Map-Notify messages. 185 RAN: Radio Access Network where UE nodes connect to gNB/eNodeB nodes 186 via radios to get access to the Internet. 188 EPC: Evolved Packet Core [EPS-3GPP] system is the part of the mobile 189 network that allows the RAN to connect to a data packet network. 190 The EPC is a term used for the 4G/LTE mobile network. 192 NGC: Next Generation Core [EPS-3GPP] system is the part of the 5G 193 mobile network that allows the RAN to connect to a data packet 194 network. The NGC is roughly equivalent to the 4G EPC. 196 GTP: GTP [GTPv1-3GPP] [GTPv2-3GPP] is the UDP tunneling mechanism 197 used in the LTE/4G and 5G mobile network. 199 UE: User Equipment as defined by [GPRS-3GPP] which is typically a 200 mobile phone. The UE is connected to the network across the RAN 201 to gNB/eNodeB nodes. 203 eNodeB: Is the device defined by [GPRS-3GPP] which borders the RAN 204 and connects UEs to the EPC in a 4G/LTE mobile network. The 205 eNodeB nodes are termination point for a GTP tunnel and are LISP 206 xTRs. The equivalent term in the 5G mobile network is "(R)AN" and 207 "5G-NR", or simply "gNB". In this document, the two terms are 208 used interchangeably. 210 pGW: Is the PDN-Gateway as defined by [GPRS-3GPP] connects the EPC 211 in a 4G/LTE mobile network to the Internet. The pGW nodes are 212 termination point for a GTP tunnel and is a LISP xTR. The 213 equivalent user/data-plane term in the 5G mobile network is the 214 "UPF", which also has the capability to chain network functions. 215 In this document, the two terms are used interchangeably to mean 216 the border point from the EPC/NGC to the Internet. 218 URLLC: Ultra-Reliable and Low-Latency provided by the 5G mobile 219 network for the shortest path between UEs [NGMN]. 221 FMC: Fixed Mobile Convergence [FMC] is a term used that allows a UE 222 device to move to and from the mobile network. By assigning a 223 fixed EID to a UE device, LISP supports transport layer continuity 224 between the mobile network and a fixed infrastructure such as a 225 WiFi network. 227 mMTC: Massive Machine-Type Services [mMTC] is a term used to refer 228 to using the mobile network for large-scale deployment of Internet 229 of Things (IoT) applications. 231 3. Design Overview 233 LISP will provide layer-3 address mobility based on the procedures in 234 [I-D.ietf-lisp-eid-mobility] where the EID and RLOCs are not co- 235 located. In this design, the EID is assigned to the UE device and 236 the RLOC(s) are assigned to gNB/eNodeB nodes. So any packets going 237 to a UE are always encapsulated to the gNB/eNodeB that associates 238 with the UE. For data flow from the UE to any EIDs (or destinations 239 to non-LISP sites) that are outside of the NGC/EPC, use the RLOCs of 240 the UPF/pGW nodes so the UPF/pGW can send packets into the Internet 241 core (unencapsulated). 243 The following procedures are used to incorporate LISP in the NGC/EPC: 245 o UEs are assigned EIDs. They usually never change. They identify 246 the mobile device and are used for transport connections. If 247 privacy for EIDs is desired, refer to details in 248 [I-D.ietf-lisp-eid-anonymity]. 250 o gNB/eNodeB nodes are LISP xTRs. They have GTP, and optionally 251 LISP, tunnels to the UPF/pGW nodes. The gNB/eNodeB is the RLOC 252 for all EIDs assigned to UE devices that are attached to the gNB/ 253 eNodeB. 255 o UPF/pGW nodes are LISP xTRs. They have GTP, and optionally LISP, 256 tunnels to the gNB/eNodeB nodes. The UPF/pGW is the RLOC for all 257 traffic destined for the Internet. 259 o The LISP mapping system runs in the NGC/EPC. It maps EIDs to 260 RLOC-sets. 262 o Traffic from a UE to UE within a UPF/pGW region can be 263 encapsulated from gNB/eNodeB to another gNB/eNodeB or via the UPF/ 264 pGW, acting as an RTR [RFC6830], to provide data-plane policy. 266 o Traffic from a UE to UE across a UPF/pGW region have these options 267 for data flow: 269 1. Encapsulation by a gNB/eNodeB in one region to a gNB/eNodeB in 270 another region. 272 2. Encapsulation by a gNB/eNodeB in one region to a UPF/pGW in 273 the same region and then the UPF/pGW reencapsulates to a gNB/ 274 eNodeB in another region. 276 3. Encapsulation by a gNB/eNodeB in one region to a UPF/pGW in 277 another region and then the UPF/pGW reencapsulates to a gNB/ 278 eNodeB in its same region 280 4. Encapsulation by the gNB/eNodeB to a LISP xTR outside of the 281 mobile network. An xTR outside of the mobile network could be 282 a router in a data-center, a router at the edge of a WAN at a 283 remote branch, or a WiFi access-point, and even a gNB/eNodeB 284 in another carrier's mobile network. All these deployment 285 options are to be considered for future architectures. 287 o Note when encapsulation happens between a gNB/eNodeB and a UPF/ 288 pGW, GTP is used as the data-plane and when encapsulation between 289 two gNB/eNodeBs occur, LISP can be used as the data-plane when 290 there is no X2 interface [X2-3GPP] between the gNB/eNodeB nodes. 292 o The UPF/pGW nodes register their RLOCs for a default EID-prefix to 293 the LISP mapping system. This is done so gNB/eNodeB nodes can 294 find UPF/pGW nodes to encapsulate to. 296 o The gNB/eNodeB nodes register EIDs to the mapping system for the 297 UE nodes. The registration occurs when gNB/eNodeB nodes discover 298 the layer-3 addresses of the UEs that connect to them. The gNB/ 299 eNodeB nodes register multiple RLOCs associated with the EIDs to 300 get multi-homing and path diversity benefits from the NGC/EPC 301 network. 303 o When a UE moves off a gNB/eNodeB, the gNB/eNodeB node deregisters 304 itself as an RLOC for the EID associated with the UE. 306 o Optionally, and for further study for future architectures, the 307 gNB/eNodeB or UPF/pGW could encapsulate to an xTR that is outside 308 of the NGC/EPC network. They could encapsulate to a LISP CPE 309 router at a branch office, a LISP top-of-rack router in a data 310 center, a LISP wifi access-point, LISP border routers at a hub 311 site, and even a LISP router running in a VM or container on a 312 server. 314 The following diagram illustrates the LTE mobile network topology and 315 structure [LTE401-3GPP] [LTE402-3GPP]: 317 (--------------------------------------------) 318 ( ) 319 ( Internet ) 320 ( ) 321 (--------------------------------------------) 322 | | 323 | | 324 (---------|---------) (---------|---------) 325 ( UPF-pGW ) ( UPF-pGW ) 326 ( ) ( ) 327 ( NGC/EPC ) ( NGC/EPC ) 328 ( ) ( ) 329 ( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB ) 330 (---/--\-----/--\---) (---/--\-----/--\---) 331 / \ / \ / \ / \ 332 / \ / \ / \ / \ 333 / \ / \ 334 / RAN \ / RAN \ 335 / \ / \ 336 ( UE UE UE ) ( UE UE UE ) 338 LTE/5G Mobile Network Architecture 340 The following diagram illustrates how LISP is used on the mobile 341 network: 343 (1) IPv6 EIDs are assigned to UEs. 344 (2) RLOCs assigned to gNB/eNodeB nodes are [a1,a2], [b1,b2], [c1,c2], [d1,d2] 345 on their uplink interfaces. 346 (3) RLOCs assigned to UPF/pGW nodes are [p1,p2], [p3,p4]. 347 (4) RLOCs can be IPv4 or IPv6 addresses or mixed RLOC-sets. 349 (--------------------------------------------) 350 ( ) 351 ( Internet ) 352 ( ) 353 (--------------------------------------------) 354 | | 355 | | 356 (---------|---------) (---------|---------) 357 ( UPF-pGW ) ( UPF-pGW ) 358 ( p1 p2 ) ( p3 p4 ) 359 ( ) ( ) 360 ( NGC/EPC ) ( NGC/EPC ) 361 ( ) ( ) 362 ( a1 a2 b1 b2 ) ( c1 c2 d1 d2 ) 363 ( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB ) 364 (---/--\-----/--\---) (---/--\-----/--\---) 365 / \ / \ / \ / \ 366 / \ / \ / \ / \ 367 / \ / \ 368 / RAN \ / RAN \ 369 / \ / \ 370 ( UE UE UE ) ( UE UE UE ) 371 EIDs: a::1 b::1 c::1 x::1 y::1 z::1 373 Mobile Network with EID/RLOC Assignment 375 The following table lists the EID-to-RLOC entries that reside in the LISP 376 Mapping System when the above UEs are are attached to the 4 gNB/eNodeBs: 378 EID-Record RLOC-Record Commentary Footnote 379 0::/0 [p1,p2,p3 p4] gNB/eNodeBs encap to p1-p4 for Internet (1) 380 destinations which are non-EIDs 382 a::1/128 [a1,a2] UPF/pGWs load-split traffic to [a1,a2] for (2) 383 UE a::1 and it can move to [b1,b2] 385 b::1/128 [a1,a2] gNB/eNodeB tracks both UEs a::1 and b::1, (3) 386 it can do local routing between the UEs 388 c::1/128 [b1,b2] UE c::1 can roam to [c1,c2] or [d1,d2], (4) 389 may use UPF/pGW [p1,p2] after move 391 x::1/128 [c1,c2] UE x::1 can talk directly to UE y::1, (5) 392 gNB/eNodeBs encap to each other 394 y::1/128 [d1,d2] UE can talk to Internet when [d1,d2], (6) 395 encap to UPF/pGW [p3,p4] or use backup [p1,p2] 397 z::1/128 [d1,d2] UE z::1 can talk to a::1 directly (7) 398 where [d1,d2] encaps to [a1,a2] 400 (1) For packets that flow from UE nodes to destinations that are not 401 in LISP sites, the gNB/eNodeB node use one of the RLOCs p1, p2, p3, 402 or p4 as the destination address in the outer encapsulated header. 403 Encapsulated packets are then routed by the NGC/EPC core to the UPF/ 404 pGW nodes. In turn, the UPF/pGW nodes, then route packets into the 405 Internet core. 407 (2) Packets that arrive to UPF/pGW nodes from the Internet destined 408 to UE nodes are encapsulated to one of the gNB/eNodeB RLOCs a1, a2, 409 b1, b2. When UE, with EID a::1 is attached to the leftmost gNB/ 410 eNodeB, the EID a::1 is registered to the mapping system with RLOCs 411 a1 and a2. When UE with EID c::1 is attached to the rightmost gNB/ 412 eNodeB (in the left region), the EID c::1 is registered to the 413 mapping system with RLOCs b1 and b2. 415 (3) If UE with EID a::1 and UE with EID b::1 are attached to the same 416 gNB/eNodeB node, the gNB/eNodeB node tracks what radio interface to 417 use to route packets from one UE to the other. 419 (4) If UE with EID c::1 roams away from gNB/eNodeB with RLOCs b1 and 420 b2, to the gNB/eNodeB with RLOCs c1 and c2 (in the rightmost region), 421 packets destined toward the Internet, can use any UPF/pGW. Any 422 packets that flow back from the Internet can use any UPF/pGW. In 423 either case, the UPF/pGW is informed by the mapping system that the 424 UE with EID c::1 has new RLOCs and should now encapsulate to either 425 RLOC c1 or c2. 427 (5) When UE with EID x::1 is attached to gNB/eNodeB with RLOCs c1 and 428 c2 and UE with EID y::1 is attached to gNB/eNodeB with RLOCs d1 and 429 d2, they can talk directly, on the shortest path to each gNB/eNodeB, 430 when each encapsulate packets to each other's RLOCs. 432 (6) When packets from UE with EID y::1 are destined for the Internet, 433 the gNB/eNodeB with RLOCs d1 and d2 that the UE is attached to can 434 use any exit UPF/pGWs RLOCs p1, p2, p3, or p4. 436 (7) UE with EID z::1 can talk directory to UE with EID a::1 by each 437 gNB/eNodeB they are attached to encapsulsates to each other's RLOCs. 438 In case (5), the two gNB/eNodeB's were in the same region. In this 439 case, the gNB/eNodeBs are in different regions. 441 The following abbreviated diagram shows a topology that illustrates 442 how a UE roams with LISP across UPF/pGW regions: 444 (--------------------------------------------) 445 ( ) 446 ( Internet ) 447 ( ) 448 (--------------------------------------------) 449 | | 450 | | 451 (---------|---------) (---------|---------) 452 ( UPF-pGW ) ( UPF-pGW ) 453 ( p1 p2 ) ( p3 p4 ) 454 ( ) ( ) 455 ( NGC/EPC ) ( NGC/EPC ) 456 ( ) ( ) 457 ( a1 a2 b1 b2 ) ( c1 c2 d1 d2 ) 458 ( gNB-eNB gNB-eNB ) ( gNB-eNB gNB-eNB ) 459 (---/--\-----/--\---) (---/--\-----/--\---) 460 / \ / \ / \ / \ 461 / \ / \ / \ / \ 462 / \ / \ 463 / RAN \ / RAN \ 464 / \ / \ 465 ( UE ------------------------------> UE ) 466 a::1 a::1 468 UE EID Mobility 470 The contents of the LISP mapping database before UE moves: 472 EID-Record RLOC-Record Commentary 473 0::/0 [p1,p2,p3,p4] gNB/eNodeB [a1,a2] encaps to p1-p4 for Internet 474 destinations when a::1 on gNB/eNodeB [a1,a2] 476 a::1/128 [a1,a2] Before UE moves to other UPF/pGW region 478 The contents of the LISP mapping database after UE moves: 480 EID-Record RLOC-Record Commentary 481 0::/0 [p1,p2,p3,p4] gNB/eNodeB [d1,d2] encaps to p1-p4 for Internet 482 destinations when a::1 moves to gNB/eNodeB 483 [d1,d2] 485 a::1/128 [d1,d2] After UE moves to new UPF/pGW region 486 4. Addressing and Routing 488 UE based EID addresses will be IPv6 addresses. It will be determined 489 at a future time what length the IPv6 prefix will be to cover all UEs 490 in a mobile network. This coarse IPv6 prefix is called an EID-prefix 491 where more-specific EID-prefixes will be allocated out of it for each 492 UPF/pGW node. Each UPF/pGW node is responsible for advertising the 493 more-specific EID-prefix into the Internet routing system so they can 494 attract packets from non-EIDs nodes to UE EIDs. 496 An RLOC address will either be an IPv4 or IPv6 address depending on 497 the support for single or dual-stack address-family in the NGC/EPC 498 network. An RLOC-set in the mapping system can have a mixed address- 499 family locator set. There is no requirement for the NGC/EPC to 500 change to support one address-family or the other. And there is no 501 requirement for the NGC/EPC network to support IPv4 multicast or IPv6 502 multicast. The LISP overlay will support both. 504 The only requirement for RLOC addresses is that they are routable in 505 the NGC/EPC and the Internet core network. 507 The requirements of the LISP and GTP data-plane overlay is to support 508 a layer-3 overlay network only. There is no architectural 509 requirement to support layer-2 overlays. However, operators may want 510 to provide a layer-2 LAN service over their mobile network. Details 511 about how LISP supports layer-2 overlays can be found in 512 [I-D.ietf-lisp-eid-mobility]. 514 5. gNB/eNodeB LISP Functionality 516 The gNB/eNodeB node runs as a LISP xTR for control-plane 517 functionality and runs GTP for data-plane functionality. Optionally, 518 the LISP data-plane can be used to establish dynamic tunnels from one 519 gNB/eNodeB node to another gNB/eNodeB node. 521 The gNB/eNodeB LISP xTR will follow the procedures of 522 [I-D.ietf-lisp-eid-mobility] to discover UE based EIDs, track them by 523 monitoring liveness, registering them when appear, and deregistering 524 them when they move away. Since the gNB/eNodeB node is an xTR, it is 525 acting as a layer-3 router and the GTP tunnel from the gNB/eNodeB 526 node to the UPF/pGW node is realizing a layer-3 overlay. This will 527 provide scaling benefits since broadcast and link-local multicast 528 packets won't have to travel across the NGC/EPC to the UPF/pGW node. 530 A day in the life of a UE originated packet: 532 1. The UE node originates an IP packet over the RAN. 534 2. The gNB/eNodeB receives the packet, extracts the source address 535 from the packet, learns the UE based EID, stores its RAN location 536 locally and registers the EID to the mapping system. 538 3. The gNB/eNodeB extracts the destination address, looks up the 539 address in the mapping system. The lookup returns the RLOC of a 540 UPF/pGW node if the destination is not an EID or an RLOC gNB/ 541 eNodeB node if the destination is a UE based EID. 543 4. The gNB/eNodeB node encapsulates the packet to the RLOC using GTP 544 or optionally the LISP data-plane. 546 It is important to note that in [I-D.ietf-lisp-eid-mobility], EID 547 discovery occurs when a LISP xTR receives an IP or ARP/ND packet. 548 However, if there are other methods to discover the EID of a device, 549 like in UE call setup, the learning and registration referenced in 550 Paragraph 2 can happen before any packet is sent. 552 6. UPF/pGW LISP Functionality 554 The UPF/pGW node runs as a LISP xTR for control-plane functionality 555 and runs GTP for data-plane functionality. Optionally, the LISP 556 data-plane can be used to establish dynamic tunnels from one UPF/pGW 557 node to another UPF/pGW or gNB/eNodeB node. 559 The UPF/pGW LISP xTR does not follow the EID mobility procedures of 560 [I-D.ietf-lisp-eid-mobility] since it is not responsible for 561 discovering UE based EIDs. A UPF/pGW LISP xTR simply follows the 562 procedures of a PxTR in [RFC6830] and for interworking to non-EID 563 sites in [RFC6832]. 565 A day in the life of a UPF/pGW received packet: 567 1. The UPF/pGW node receives a IP packet from the Internet core. 569 2. The UPF/pGW node extracts the destination address from the packet 570 and looks it up in the LISP mapping system. The lookup returns 571 an RLOC of a gNB/eNodeB node. Optionally, the RLOC could be 572 another UPF/pGW node. 574 3. The UPF/pGW node encapsulates the packet to the RLOC using GTP or 575 optionally the LISP data-plane. 577 7. Compatible Data-Plane using GTP 579 Since GTP is a UDP based encapsulating tunnel protocol, it has the 580 same benefits as LISP encapsulation. At this time, there appears to 581 be no urgent need to not continue to use GTP for tunnels between a 582 gNB/eNodeB nodes and between a gNB/eNodeB node and a UPF/pGW node. 584 There are differences between GTP tunneling and LISP tunneling. GTP 585 tunnels are setup at call initiation time. LISP tunnels are 586 dynamically encapsulating, used on demand, and don't need setup or 587 teardown. The two tunneling mechanisms are a hard state versus soft 588 state tradeoff. 590 This specification recommends for early phases of deployment, to use 591 GTP as the data-plane so a transition for it to use the LISP control- 592 plane can be achieved more easily. At later phases, the LISP data- 593 plane may be considered so a more dynamic way of using tunnels can be 594 achieved to support URLLC. 596 This specification recommends the use of procedures from 597 [I-D.ietf-lisp-eid-mobility] and NOT the use of LISP-MN 598 [I-D.ietf-lisp-mn]. Using LISP-MN states that a LISP xTR reside on 599 the mobile UE. This is to be avoided so extra encapsulation header 600 overhead is NOT sent on the RAN. The LISP data-plane or control- 601 plane will not run on the UE. 603 8. Roaming and Packet Loss 605 Using LISP for the data-plane has some advantages in terms of 606 providing near-zero packet loss. In the current mobile network, 607 packets are queued on the gNB/eNodeB node the UE is roaming to or 608 rerouted on the gNB/eNodeB node the UE has left. In the LISP 609 architecture, packets can be sent to multiple "roamed-from" and 610 "roamed-to" nodes while the UE is moving or is off the RAN. See 611 mechanisms in [I-D.ietf-lisp-predictive-rlocs] for details. 613 9. Mobile Network LISP Mapping System 615 The LISP mapping system stores and maintains EID-to-RLOC mappings. 616 There are two mapping database transport systems that are available 617 for scale, LISP-ALT [RFC6836] and LISP-DDT [RFC8111]. The mapping 618 system will store EIDs assigned to UE nodes and the associated RLOCs 619 assigned to gNB/eNodeB nodes and UPF/pGW nodes. The RLOC addresses 620 are routable addresses by the NGC/EPC network. 622 This specification recommends the use of LISP-DDT. 624 10. LISP Over the 5G N3/N6/N9 Interfaces 626 So far in this specification we have described how LISP runs on the 627 gNB and UPF nodes in the mobile network. In the 5G architecture 628 [ARCH5G-3GPP] definition, some key components are Access and Mobility 629 Management Function (AMF) and the Session Management Function (SMF). 630 These two components provide control plane functionality to off-load 631 session anchoring by distributing state and packet flow among 632 multiple nodes in the NGC. These functions can be deployed in Branch 633 Point Uplink Classifier (BP/ULCL) in data-plane nodes. 635 Here is an illustration where a B/ULCL-UPF node would appear in the 636 mobile network: 638 (--------------------------------------------) 639 ( Internet ) 640 +-> (--------------------------------------------) 641 | | 642 N6 | 643 | (---------|---------) 644 +-> ( UPF ) <-+ 645 NGC ( [p1,p2] ) | 646 ( ) N9 647 +-> ( BP/ULCL ) | 648 | ( UPF [p3,p4] ) <-+ 649 N3 ( ) 650 | ( [a1] [a2] ) 651 +-> ( gNB gNB ) 652 (---/--\-----/--\---) 653 / \ / \ 654 / \ 655 / RAN \ 656 / \ 657 ( UE UE UE ) 658 a::1 a::2 a::3 660 The BP/ULCL-UPF node is configured as an LISP RTR and uses the 661 Traffic Engineering features of LISP specified in [I-D.ietf-lisp-te]. 662 In LISP-TE an Explicit Locator Path (ELP) can be stored in the RLOC- 663 record for any given EID thereby allowing packet flow from a UE to 664 the Internet to traverse through the BP/UCLC-UPF node. A UE 665 originated packet is encapsulated by the gNB to the BP/ULCL-UPF which 666 decapsulates and reencapsulates to the UPF at the Internet border. 667 This allows LISP to run over the 5G N3 and N9 interface with one 668 mapping entry. And if the ELP contained an xTR outside of the mobile 669 network, LISP could also run over the N6 interface. 671 The contents of the LISP mapping database: 673 EID-Record RLOC-Record Commentary 674 0::/0 [ELP{a1,p3,p1}, 4 RLOC-records, 2 with paths through the BP-UPF 675 ELP{a1,p4,p2}, and 2 directly to the border UPF from UEs 676 p1, p2] connected to gNB with RLOC a1 678 a::1/128 [a1,a2] The UPF or BP-UPF can encap directly for UE with 679 EID a::1 to either gNB with optimized latency 681 a::2/128 [ELP{p1,p3,a2}, The UPF can encap to either RLOC p3 or p4 to 682 ELP{p1,p4,a2}] forward traffic through the BP-UPF on its way 683 toward gNB with RLOC a1 685 a::3/128 [ELP{p1,p3,a2}, The UPF can encap to the BP-UPF or directly 686 a2] to gNB with RLOC a2 to reach UE with EID a::3 688 11. Multicast Considerations 690 Since the mobile network runs the LISP control-plane, and the mapping 691 system is available to support EIDs for unicast packet flow, it can 692 also support multicast packet flow. Support for multicast can be 693 provided by the LISP/GTP overlay with no changes to the NGC/EPC 694 network. 696 Multicast (S-EID,G) entries can be stored and maintained in the same 697 mapping database that is used to store UE based EIDs. Both Internet 698 connected nodes, as well as UE nodes, can source multicast packets. 699 The protocol procedures from [I-D.ietf-lisp-signal-free-multicast] 700 are followed to make multicast delivery available. Both multicast 701 packet flow and UE mobility can occur at the same time. 703 A day in the life of a 1-to-many multicast packet: 705 1. A UE node joins an (S,G) multicast flow by using IGMPv2 or 706 IGMPv3. 708 2. The gNB/eNodeB node records which UE on the RAN should get 709 packets sourced by S and destined for group G. 711 3. The gNB/eNodeB node registers the (S,G) entry to the mapping 712 system with its RLOC according to the receiver site procedures in 713 [I-D.ietf-lisp-signal-free-multicast]. The gNB/eNodeB does this 714 to show interest in joining the multicast flow. 716 4. When other UE nodes join the same (S,G), their associated gNB/ 717 eNodeB nodes will follow the procedures in steps 1 through 3. 719 5. The (S,G) entry stored in the mapping database has an RLOC-set 720 which contains a replication list of all the gNB/eNodeB RLOCs 721 that registered. 723 6. A multicast packet from source S to destination group G arrives 724 at the UPF/pGW. The UPF/pGW node looks up (S,G), gets returned 725 the replication list of all joined gNB/eNodeB nodes and 726 replicates the multicast packet by encapsulating the packet to 727 each of them. 729 7. Each gNB/eNodeB node decapsulates the packet and delivers the 730 multicast packet to one or more IGMP-joined UEs on the RAN. 732 12. Security Considerations 734 For control-plane authentication and authorization procedures, this 735 specification recommends the mechanisms in 736 [I-D.ietf-lisp-rfc6833bis], LISP-SEC [I-D.ietf-lisp-sec] AND LISP- 737 ECDSA [I-D.farinacci-lisp-ecdsa-auth]. 739 For data-plane privacy procedures, this specification recommends the 740 mechanisms in [RFC8061] When the LISP data-plane is used. otherwise, 741 the NGC/EPC must provide data-plane encryption support. 743 13. IANA Considerations 745 There are no specific requests for IANA. 747 14. SDO Recommendations 749 The authors request other Standards Development Organizations to 750 consider LISP as a technology for device mobility. It is recommended 751 to start with this specification as a basis for design and develop 752 more deployment details in the appropriate Standards Organizations. 753 The authors are willing to facilitate this activity. 755 15. References 757 15.1. Normative References 759 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 760 DOI 10.17487/RFC1700, October 1994, 761 . 763 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 764 Locator/ID Separation Protocol (LISP)", RFC 6830, 765 DOI 10.17487/RFC6830, January 2013, 766 . 768 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 769 "Interworking between Locator/ID Separation Protocol 770 (LISP) and Non-LISP Sites", RFC 6832, 771 DOI 10.17487/RFC6832, January 2013, 772 . 774 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 775 Protocol (LISP) Map-Server Interface", RFC 6833, 776 DOI 10.17487/RFC6833, January 2013, 777 . 779 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 780 "Locator/ID Separation Protocol Alternative Logical 781 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 782 January 2013, . 784 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 785 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 786 February 2017, . 788 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 789 (LISP) Data-Plane Confidentiality", RFC 8061, 790 DOI 10.17487/RFC8061, February 2017, 791 . 793 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 794 Smirnov, "Locator/ID Separation Protocol Delegated 795 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 796 May 2017, . 798 15.2. Informative References 800 [ARCH5G-3GPP] 801 3GPP, "System Architecture for the 5G System", TS.23.501 802 https://portal.3gpp.org/desktopmodules/Specifications/ 803 SpecificationDetails.aspx?specificationId=3144, December 804 2016. 806 [EPS-3GPP] 807 3GPP, "Non-Access-Stratum (NAS) Protocol for Evolved 808 Packet System (EPS); Stage 3", TS.23.501 809 https://portal.3gpp.org/desktopmodules/specifications/ 810 specificationdetails.aspx?specificationid=1072, December 811 2017. 813 [ETSI-NGP] 814 ETSI-NGP, "NGP Evolved Architecture for mobility using 815 Identity Oriented Networks", NGP-004, version 0.0.3 816 https://portal.etsi.org/webapp/WorkProgram/ 817 Report_WorkItem.asp?WKI_ID=50531, May 2017. 819 [FMC] ipv6.com, "FIXED MOBILE CONVERGENCE", 820 https://www.ipv6.com/mobile/fixed-mobile-convergence/, 821 November 2006. 823 [GPRS-3GPP] 824 3GPP, "General Packet Radio Service (GPRS) for Evolved 825 Universal Terrestrial Radio Access Network (E-UTRAN) 826 Access", TS23.401 Release 8 827 https://portal.3gpp.org/desktopmodules/specifications/ 828 specificationdetails.aspx?specificationid=849, January 829 2015. 831 [GTPv1-3GPP] 832 3GPP, "General Packet Radio System (GPRS) Tunnelling 833 Protocol User Plane (GTPv1-U)", TS.29.281 834 https://portal.3gpp.org/desktopmodules/Specifications/ 835 SpecificationDetails.aspx?specificationId=1699, January 836 2015. 838 [GTPv2-3GPP] 839 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 840 Packet Radio Service (GPRS) Tunnelling Protocol for 841 Control plane (GTPv2-C); Stage 3", TS.29.274 842 https://portal.3gpp.org/desktopmodules/Specifications/ 843 SpecificationDetails.aspx?specificationId=1692, January 844 2015. 846 [I-D.farinacci-lisp-ecdsa-auth] 847 Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA 848 Authentication and Authorization", draft-farinacci-lisp- 849 ecdsa-auth-03 (work in progress), September 2018. 851 [I-D.ietf-lisp-eid-anonymity] 852 Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP 853 EID Anonymity", draft-ietf-lisp-eid-anonymity-02 (work in 854 progress), April 2018. 856 [I-D.ietf-lisp-eid-mobility] 857 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 858 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 859 Unified Control Plane", draft-ietf-lisp-eid-mobility-02 860 (work in progress), May 2018. 862 [I-D.ietf-lisp-introduction] 863 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 864 Introduction to the Locator/ID Separation Protocol 865 (LISP)", draft-ietf-lisp-introduction-13 (work in 866 progress), April 2015. 868 [I-D.ietf-lisp-mn] 869 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 870 Mobile Node", draft-ietf-lisp-mn-02 (work in progress), 871 April 2018. 873 [I-D.ietf-lisp-predictive-rlocs] 874 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 875 RLOCs", draft-ietf-lisp-predictive-rlocs-02 (work in 876 progress), May 2018. 878 [I-D.ietf-lisp-rfc6830bis] 879 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 880 Cabellos-Aparicio, "The Locator/ID Separation Protocol 881 (LISP)", draft-ietf-lisp-rfc6830bis-16 (work in progress), 882 August 2018. 884 [I-D.ietf-lisp-rfc6833bis] 885 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 886 "Locator/ID Separation Protocol (LISP) Control-Plane", 887 draft-ietf-lisp-rfc6833bis-13 (work in progress), August 888 2018. 890 [I-D.ietf-lisp-sec] 891 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 892 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 893 (work in progress), April 2018. 895 [I-D.ietf-lisp-signal-free-multicast] 896 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 897 draft-ietf-lisp-signal-free-multicast-09 (work in 898 progress), March 2018. 900 [I-D.ietf-lisp-te] 901 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 902 Engineering Use-Cases", draft-ietf-lisp-te-02 (work in 903 progress), April 2018. 905 [ITU-IMT2020] 906 ITU-FG, "Focus Group on IMT-2020", 907 https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC- 908 M.687-2-199702-I!!PDF-E.pdf. 910 [LTE401-3GPP] 911 3GPP, "General Packet Radio Service (GPRS) enhancements 912 for Evolved Universal Terrestrial Radio Access Network 913 (E-UTRAN) access", TS.23.401 914 https://portal.3gpp.org/desktopmodules/Specifications/ 915 SpecificationDetails.aspx?specificationId=849, January 916 2015. 918 [LTE402-3GPP] 919 3GPP, "Architecture enhancements for non-3GPP accesses", 920 TS.23.402 921 https://portal.3gpp.org/desktopmodules/Specifications/ 922 SpecificationDetails.aspx?specificationId=850, January 923 2015. 925 [mMTC] NGMN Alliance, "NGMN KPIs and Deployment Scenarios for 926 Consideration for IMT2020", https://www.ngmn.org/uploads/ 927 media/151204_NGMN_KPIs_and_Deployment_Scenarios_for_Consid 928 eration_for_IMT_2020_-_LS_Annex_V1_approved.pdf, December 929 2015. 931 [NGMN] NGMN Alliance, "5G End-to-End Architecture Framework", 932 NGMN https://www.ngmn.org/uploads/ 933 media/170511_NGMN_E2EArchFramework_v0.6.5.pdf, March 2016. 935 [PROC5G-3GPP] 936 3GPP, "Procedures for the 5G System", TS.23.502 937 https://portal.3gpp.org/desktopmodules/Specifications/ 938 SpecificationDetails.aspx?specificationId=3145, December 939 2016. 941 [X2-3GPP] 3GPP, "Evolved Universal Terrestrial Radio Access Network 942 (E-UTRAN); X2 Application Protocol (X2AP)", TS.36.423 943 https://portal.3gpp.org/desktopmodules/Specifications/ 944 SpecificationDetails.aspx?specificationId=2452, June 2017. 946 Appendix A. Acknowledgments 948 The authors would like to thank Gerry Foster and Peter Ashwood Smith 949 for their expertise with 3GPP mobile networks and for their early 950 review and contributions. The authors would also like to thank Fabio 951 Maino, Malcolm Smith, and Marc Portoles for their expertise in both 952 5G and LISP as well as for their early review comments. 954 The authors would like to give a special thank you to Ryosuke 955 Kurebayashi from NTT Docomo and Kalyani Bogineni from Verizon for 956 their operational and practical commentary. 958 Appendix B. Document Change Log 960 B.1. Changes to draft-farinacci-lisp-mobile-network-04 962 o Posted September 2018. 964 o Update document timer. 966 B.2. Changes to draft-farinacci-lisp-mobile-network-03 968 o Posted March 2018. 970 o Make the spec more 5G user-friendly. That is, the design has 971 always worked for either 4G or 5G but we make it more clear about 972 5G by using some basic 5G node terminlogy. 974 o Add a section how LISP can work on the N3, N6, and N9 5G spec 975 interfaces. 977 o Describe how LISP-TE can allow BP-UPF offload functionality. 979 B.3. Changes to draft-farinacci-lisp-mobile-network-02 981 o Posted mid September 2017. 983 o Editorial fixes from draft -01. 985 B.4. Changes to draft-farinacci-lisp-mobile-network-01 987 o Posted September 2017. 989 o Explain each EID case illustrated in the "Mobile Network with EID/ 990 RLOC Assignment" diagram. 992 o Make a reference to mMTC as a 3GPP use-case for 5G. 994 o Add to the requirements section how mobile operators believe that 995 using Locator/ID separation mechanisms provide for more efficient 996 mobile netwowks. 998 o Indicate that L2-overlays is not recommended by this specification 999 as the LISP mobile network architeture but how operators may want 1000 to deploy a layer-2 overlay service. 1002 B.5. Changes to draft-farinacci-lisp-mobile-network-00 1004 o Initial draft posted August 2017. 1006 Authors' Addresses 1008 Dino Farinacci 1009 lispers.net 1010 San Jose, CA 1011 USA 1013 Email: farinacci@gmail.com 1015 Padma Pillay-Esnault 1016 Huawei Technologies 1017 Santa Clara, CA 1018 USA 1020 Email: padma@huawei.com 1022 Uma Chunduri 1023 Huawei Technologies 1024 Santa Clara, CA 1025 USA 1027 Email: uma.chunduri@huawei.com