idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-08.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 9 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 (June 23, 2020) is 1402 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SL' is mentioned on line 179, but not defined -- Looks like a reference, but probably isn't: '2' on line 177 -- Looks like a reference, but probably isn't: '1' on line 177 -- Looks like a reference, but probably isn't: '0' on line 976 == Missing Reference: 'WHITEPAPER-5G-UP' is mentioned on line 253, but not defined == Missing Reference: 'N11' is mentioned on line 258, but not defined == Missing Reference: 'N2' is mentioned on line 259, but not defined == Missing Reference: 'N4' is mentioned on line 263, but not defined == Missing Reference: 'N3' is mentioned on line 661, but not defined == Missing Reference: 'N9' is mentioned on line 506, but not defined == Missing Reference: 'N6' is mentioned on line 662, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-02 == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-deployment-options-03 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-13 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-07 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-02 == Outdated reference: A later version (-04) exists of draft-rodrigueznatal-lisp-srv6-03 Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group S. Matsushima 3 Internet-Draft SoftBank 4 Intended status: Standards Track C. Filsfils 5 Expires: December 25, 2020 M. Kohno 6 P. Camarillo 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 June 23, 2020 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-08 17 Abstract 19 This document shows the applicability of SRv6 (Segment Routing IPv6) 20 to the user-plane of mobile networks. The network programming nature 21 of SRv6 accomplish mobile user-plane functions in a simple manner. 22 The statelessness of SRv6 and its ability to control both service 23 layer path and underlying transport can be beneficial to the mobile 24 user-plane, providing flexibility, end-to-end network slicing and SLA 25 control for various applications. This document describes the SRv6 26 mobile user plane. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 25, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 64 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Predefined SRv6 Functions . . . . . . . . . . . . . . . . 4 67 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. A 3GPP Reference Architecture . . . . . . . . . . . . . . . . 6 69 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7 70 5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7 71 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 72 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8 73 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 74 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 75 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10 76 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 77 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 11 78 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14 79 5.3.3. SRv6 Drop-in Interworking . . . . . . . . . . . . . . 16 80 5.3.4. Extensions to the interworking mechanisms . . . . . . 18 81 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18 82 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18 83 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 85 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 20 86 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 21 87 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 22 88 6.7. T.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 23 89 6.8. End.Limit: Rate Limiting function . . . . . . . . . . . . 23 90 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 24 91 8. Network Slicing Considerations . . . . . . . . . . . . . . . 24 92 9. Control Plane Considerations . . . . . . . . . . . . . . . . 25 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 26 99 14.2. Informative References . . . . . . . . . . . . . . . . . 27 100 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 28 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 103 1. Introduction 105 In mobile networks, mobility management systems provide connectivity 106 while mobile nodes move. While the control-plane of the system 107 signals movements of a mobile node, the user-plane establishes a 108 tunnel between the mobile node and its anchor node over IP-based 109 backhaul and core networks. 111 This document shows the applicability of SRv6 (Segment Routing IPv6) 112 to those mobile networks. SRv6 provides source routing to networks 113 so that operators can explicitly indicate a route for the packets to 114 and from the mobile node. SRv6 endpoint nodes serve as the anchors 115 of mobile user-plane. 117 2. Conventions and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2.1. Terminology 125 o AMBR: Aggregate Maximum Bit Rate 126 o Anchor: An topological endpoint of an UE 127 o APN: Access Point Name (commonly used to identify a network or 128 class of service) 129 o BSID: SR Binding SID [RFC8402] 130 o CNF: Cloud-native Network Function 131 o gNB: gNodeB 132 o NH: The IPv6 next-header field. 133 o NFV: Network Function Virtualization 134 o PDU: Packet Data Unit 135 o Session: Context of an UE connects to a mobile network. 136 o SID: A Segment Identifier which represents a specific segment in a 137 segment routing domain. 138 o SRH: The Segment Routing Header. 139 [I-D.ietf-6man-segment-routing-header] 140 o TEID: Tunnel Endpoint Identifier 141 o UE: User Equipment 142 o UPF: User Plane Function 143 o VNF: Virtual Network Function 145 2.2. Conventions 147 o NH=SRH means that NH is 43 with routing type 4. 148 o Multiple SRHs may be present inside each packet, but they must 149 follow each other. The next-header field of each SRH, except the 150 last one, must be NH-SRH (43 type 4). 151 o For simplicity, no other extension headers are shown except the 152 SRH. 153 o The SID type used in this document is SRv6 SID. 154 o gNB::1 is an IPv6 address (SID) assigned to the gNB. 155 o U1::1 is an IPv6 address (SID) assigned to UPF1. 156 o U2::1 is an IPv6 address (SID) assigned to UPF2. 157 o U2:: is some other IPv6 address (SID) assigned to UPF2. 158 o A SID list is represented as where S1 is the first 159 SID to visit, S2 is the second SID to visit and S3 is the last SID 160 to visit along the SR path. 161 o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 163 * IPv6 header with source and destination addresses SA and DA 164 respectively, and next-header SRH, with SID list 165 with SegmentsLeft = SL 166 * The payload of the packet is not represented. 167 o Note the difference between the <> and () symbols: 168 represents a SID list where S1 is the first SID and S3 is the last 169 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 170 the SRH format where the rightmost SID in the SRH is the first SID 171 and the leftmost SID in the SRH is the last SID. When referring 172 to an SR policy in a high-level use-case, it is simpler to use the 173 notation. When referring to an illustration of the 174 detailed behavior, the (S3, S2, S1; SL) notation is more 175 convenient. 176 o SRH[SL] represents the SID pointed by the SL field in the first 177 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 178 and SRH[0] represents S3. 179 o SRH[SL] can be different from the DA of the IPv6 header. 181 2.3. Predefined SRv6 Functions 183 The following functions are defined in 184 [I-D.ietf-spring-srv6-network-programming]. 186 o End.DT4 means to decapsulate and forward using a specific IPv4 187 table lookup. 189 o End.DT6 means to decapsulate and forward using a specific IPv6 190 table lookup. 191 o End.DX4 means to decapsulate the packet and forward through a 192 particular outgoing interface -or set of OIFs- configured with the 193 SID. 194 o End.DX6 means to decapsulate and forward through a particular 195 outgoing interface -or set of OIFs- configured with the SID. 196 o End.DX2 means to decapsulate the L2 frame and forward through a 197 particular outgoing interface -or set of OIFs- configured with the 198 SID. 199 o End.T means to forward using a specific IPv6 table lookup. 200 o End.X means to forward through a link configured with the SID. 201 o T.Encaps.Red means encapsulation without pushing SRH (resulting in 202 "Reduced" packet size). 203 o PSP means Penultimate Segment Pop. The packet is subsequently 204 forwarded without the popped SRH. 206 New SRv6 functions are defined in Section 6 to support the needs of 207 the mobile user plane. 209 3. Motivation 211 Mobility networks are becoming more challenging to operate. On one 212 hand, traffic is constantly growing, and latency requirements are 213 more strict; on the other-hand, there are new use-cases like NFV that 214 are also challenging network management. 216 The current architecture of mobile networks does not take into 217 account the underlying transport. The user-plane is rigidly 218 fragmented into radio access, core and service networks, connected by 219 tunneling according to user-plane roles such as access and anchor 220 nodes. These factors have made it difficult for the operator to 221 optimize and operate the data-path. 223 In the meantime, applications have shifted to use IPv6, and network 224 operators have started adopting IPv6 as their IP transport. SRv6, 225 the IPv6 dataplane instantiation of Segment Routing [RFC8402], 226 integrates both the application data-path and the underlying 227 transport layer into a single protocol, allowing operators to 228 optimize the network in a simplified manner and removing forwarding 229 state from the network. It is also suitable for virtualized 230 environments, VNF/CNF to VNF/CNF networking. 232 SRv6 specifies network-programming (see 233 [I-D.ietf-spring-srv6-network-programming]). Applied to mobility, 234 SRv6 can provide the user-plane functions needed for mobility 235 management. SRv6 takes advantage of underlying transport awareness 236 and flexibility to improve mobility user-plane functions. 238 The use-cases for SRv6 mobility are discussed in 239 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]. 241 4. A 3GPP Reference Architecture 243 This section presents a reference architecture and possible 244 deployment scenarios. 246 Figure 1 shows a reference diagram from the 5G packet core 247 architecture [TS.23501]. 249 The user plane described in this document does not depend on any 250 specific architecture. The 5G packet core architecture as shown is 251 based on the latest 3GPP standards at the time of writing this draft. 252 Other architectures can be seen in [I-D.gundavelli-dmm-mfa] and 253 [WHITEPAPER-5G-UP]. 255 +-----+ 256 | AMF | 257 +-----+ 258 / | [N11] 259 [N2] / +-----+ 260 +------/ | SMF | 261 / +-----+ 262 / / \ 263 / / \ [N4] 264 / / \ ________ 265 / / \ / \ 266 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 267 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 268 +--+ +-----+ +------+ +------+ \________/ 270 Figure 1: 3GPP 5G Reference Architecture 272 o gNB: gNodeB 273 o UPF1: UPF with Interfaces N3 and N9 274 o UPF2: UPF with Interfaces N9 and N6 275 o SMF: Session Management Function 276 o AMF: Access and Mobility Management Function 277 o DN: Data Network e.g. operator services, Internet access 279 This reference diagram does not depict a UPF that is only connected 280 to N9 interfaces, although the description in this document also work 281 for such UPFs. 283 Each session from an UE gets assigned to a UPF. Sometimes multiple 284 UPFs may be used, providing richer service functions. A UE gets its 285 IP address from the DHCP block of its UPF. The UPF advertises that 286 IP address block toward the Internet, ensuring that return traffic is 287 routed to the right UPF. 289 5. User-plane behaviors 291 This section describes some mobile user-plane behaviors using SRv6. 293 In order to simplify the adoption of SRv6, we present two different 294 "modes" that vary with respect to the use of SRv6. The first one is 295 the "Traditional mode", which inherits the current 3GPP mobile user- 296 plane. In this mode there is no change to mobility networks 297 architecture, except that GTP-U [TS.29281] is replaced by SRv6. 299 The second mode is the "Enhanced mode". In this mode the SR policy 300 contains SIDs for Traffic Engineering and VNFs, which results in 301 effective end-to-end network slices. 303 In both, the Traditional and the Enhanced modes, we assume that the 304 gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6 305 interfaces are SRv6). 307 We introduce two mechanisms for interworking with legacy access 308 networks (N3 interface is unmodified). In this document we introduce 309 them applied to the Enhanced mode, although they could be used in 310 combination with the Traditional mode as well. 312 One of these mechanisms is designed to interwork with legacy gNBs 313 using GTP/IPv4. The second method is designed to interwork with 314 legacy gNBs using GTP/IPv6. 316 This document uses SRv6 functions defined in 317 [I-D.ietf-spring-srv6-network-programming] as well as new SRv6 318 functions designed for the mobile user plane. The new SRv6 functions 319 are detailed in Section 6. 321 5.1. Traditional mode 323 In the traditional mode, the existing mobile UPFs remain unchanged 324 except for the use of SRv6 as the data plane instead of GTP-U. There 325 is no impact to the rest of mobile system. 327 In existing 3GPP mobile networks, an UE PDU Session is mapped 1-for-1 328 with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored 329 here to replace GTP encapsulation with the SRv6 encapsulation, while 330 not changing anything else. There will be a unique SRv6 SID 331 associated with each UE PDU Session. 333 The traditional mode minimizes the changes required to the mobile 334 system; it is a good starting point for forming a common basis. 336 Our example topology is shown in Figure 2. In traditional mode the 337 gNB and the UPFs are SR-aware. In the descriptions of the uplink and 338 downlink packet flow, A is an IPv6 address of the UE, and Z is an 339 IPv6 address reachable within the Data Network DN. A new SRv6 340 function End.MAP, defined in Section 6.2, is used. 342 ________ 343 SRv6 SRv6 / \ 344 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 345 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 346 +--+ +-----+ +------+ +------+ \________/ 347 SRv6 node SRv6 node SRv6 node 349 Figure 2: Traditional mode - example topology 351 5.1.1. Packet flow - Uplink 353 The uplink packet flow is as follows: 355 UE_out : (A,Z) 356 gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Red 357 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 358 UPF2_out: (A,Z) -> End.DT4 or End.DT6 360 When the UE packet arrives at the gNB, the gNB performs a 361 T.Encaps.Red operation. Since there is only one SID, there is no 362 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 363 U1::1. U1::1 represents an anchoring SID specific for that session 364 at UPF1. gNB obtains the SID U1::1 from the existing control plane 365 (N2 interface). 367 When the packet arrives at UPF1, the SID U1::1 identifies a local 368 End.MAP function. End.MAP replaces U1::1 by U2::1, that belongs to 369 the next UPF (U2). 371 When the packet arrives at UPF2, the SID U2::1 corresponds to an 372 End.DT function. UPF2 decapsulates the packet, performs a lookup in 373 a specific table associated with that mobile network and forwards the 374 packet toward the data network (DN). 376 5.1.2. Packet flow - Downlink 378 The downlink packet flow is as follows: 380 UPF2_in : (Z,A) 381 UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red 382 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 383 gNB_out : (Z,A) -> End.DX4 or End.DX6 385 When the packet arrives at the UPF2, the UPF2 maps that flow into a 386 UE PDU Session. This UE PDU Session is associated with the segment 387 endpoint . UPF2 performs a T.Encaps.Red operation, 388 encapsulating the packet into a new IPv6 header with no SRH since 389 there is only one SID. 391 Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 392 function. This function maps the SID to the next anchoring point and 393 replaces U1::1 by gNB::1, that belongs to the next hop. 395 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4 396 or End.DX6 function. The gNB decapsulates the packet, removing the 397 IPv6 header and all its extensions headers, and forwards the traffic 398 toward the UE. 400 5.2. Enhanced Mode 402 Enhanced mode improves scalability, traffic steering and service 403 programming [I-D.ietf-spring-sr-service-programming], thanks to the 404 use of multiple SIDs, instead of a single SID as done in the 405 Traditional mode. 407 The main difference is that the SR policy MAY include SIDs for 408 traffic engineering and service programming in addition to the UPFs 409 SIDs. 411 The gNB control-plane (N2 interface) is unchanged, specifically a 412 single IPv6 address is given to the gNB. 414 o The gNB MAY resolve the IP address into a SID list using a 415 mechanism like PCEP, DNS-lookup, small augment for LISP control- 416 plane, etc. 418 Note that the SIDs MAY use the arguments Args.Mob.Session if required 419 by the UPFs. 421 Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 422 gNB and the UPF are SR-aware. The Figure shows two service segments, 423 S1 and C1. S1 represents a VNF in the network, and C1 represents a 424 constraint path on a router requiring Traffic Engineering. S1 and C1 425 belong to the underlay and don't have an N4 interface, so they are 426 not considered UPFs. 428 +----+ SRv6 _______ 429 SRv6 --| C1 |--[N3] / \ 430 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 431 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 432 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 433 SRv6 node \ +----+ / SRv6 node 434 -| S1 |- 435 +----+ 436 SRv6 node 437 CNF 439 Figure 3: Enhanced mode - Example topology 441 5.2.1. Packet flow - Uplink 443 The uplink packet flow is as follows: 445 UE_out : (A,Z) 446 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red 447 S1_out : (gNB, C1)(U2::1, C1; SL=1 (A,Z) 448 C1_out : (gNB, U2::1)(A,Z) -> PSP 449 UPF2_out: (A,Z) -> End.DT4 or End.DT6 451 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 452 control plane associates that session from the UE(A) with the IPv6 453 address B and GTP TEID T. gNB's control plane does a lookup on B to 454 find the related SID list . 456 When gNB transmits the packet, it contains all the segments of the SR 457 policy. The SR policy can include segments for traffic engineering 458 (C1) and for service programming (S1). 460 Nodes S1 and C1 perform their related Endpoint functionality and 461 forward the packet. 463 When the packet arrives at UPF2, the active segment (U2::1) is an 464 End.DT4/6 which performs the decapsulation (removing the IPv6 header 465 with all its extension headers) and forwards toward the data network. 467 5.2.2. Packet flow - Downlink 469 The downlink packet flow is as follows: 471 UPF2_in : (Z,A) -> UPF2 maps the flow w/ 472 SID list 473 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red 474 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 475 S1_out : (U2::1, gNB)(Z,A) -> PSP 476 gNB_out : (Z,A) -> End.DX4 or End.DX6 478 When the packet arrives at the UPF2, the UPF2 maps that particular 479 flow into a UE PDU Session. This UE PDU Session is associated with 480 the policy . The UPF2 performs a T.Encaps.Red 481 operation, encapsulating the packet into a new IPv6 header with its 482 corresponding SRH. 484 The nodes C1 and S1 perform their related Endpoint processing. 486 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 487 End.DX4 or End.DX6 (depending on the underlying traffic). The gNB 488 decapsulates the packet, removing the IPv6 header and all its 489 extensions headers and forwards the traffic toward the UE. 491 5.3. Enhanced mode with unchanged gNB GTP behavior 493 This section describes two mechanisms for interworking with legacy 494 gNBs that still use GTP: one for IPv4, the other for IPv6. 496 In the interworking scenarios as illustrated in Figure 4, gNB does 497 not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6. 498 To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added. 499 The SRGW maps the GTP traffic into SRv6. 501 The SRGW is not an anchor point and maintains very little state. For 502 this reason, both IPv4 and IPv6 methods scale to millions of UEs. 504 _______ 505 IP GTP SRv6 / \ 506 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 507 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 508 +--+ +-----+ +------+ +------+ \_______/ 509 SR Gateway SRv6 node 511 Figure 4: Example topology for interworking 513 5.3.1. Interworking with IPv6 GTP 515 In this interworking mode the gNB uses GTP over IPv6 via the N3 516 interface 518 Key points: 520 o The gNB is unchanged (control-plane or user-plane) and 521 encapsulates into GTP (N3 interface is not modified). 522 o The 5G Control-Plane (N2 interface) is unmodified; one IPv6 523 address is needed (i.e. a BSID at the SRGW). 524 o The SRGW removes GTP, finds the SID list related to DA, and adds 525 SRH with the SID list. 526 o There is no state for the downlink at the SRGW. 527 o There is simple state in the uplink at the SRGW; using Enhanced 528 mode results in fewer SR policies on this node. A SR policy can 529 be shared across UEs. 530 o When a packet from the UE leaves the gNB, it is SR-routed. This 531 simplifies network slicing [I-D.ietf-lsr-flex-algo]. 532 o In the uplink, the IPv6 DA BSID steers traffic into an SR policy 533 when it arrives at the SRGW-UPF1. 535 An example topology is shown in Figure 5. In this mode the gNB is an 536 unmodified gNB using IPv6/GTP. The UPFs are SR-aware. As before, 537 the SRGW maps IPv6/GTP traffic to SRv6. 539 S1 and C1 are two service segments. S1 represents a VNF in the 540 network, and C1 represents a router configured for Traffic 541 Engineering. 543 +----+ 544 IPv6/GTP -| S1 |- ___ 545 +--+ +-----+ [N3] / +----+ \ / 546 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 547 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 548 GTP \ +------+ / +----+ +------+ \___ 549 -| UPF1 |- SRv6 SRv6 550 +------+ TE 551 SR Gateway 553 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 555 5.3.1.1. Packet flow - Uplink 557 The uplink packet flow is as follows: 559 UE_out : (A,Z) 560 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 561 (IPv6/GTP) 562 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 563 SID at the SRGW 564 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 565 C1_out : (SRGW, U2::1)(A,Z) -> PSP 566 UPF2_out: (A,Z) -> End.DT4 or End.DT6 567 The UE sends a packet destined to Z toward the gNB on a specific 568 bearer for that session. The gNB, which is unmodified, encapsulates 569 the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the 570 GTP TEID T are the ones received in the N2 interface. 572 The IPv6 address that was signaled over the N2 interface for that UE 573 PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 574 SRGW. Hence the packet is routed to the SRGW. 576 When the packet arrives at the SRGW, the SRGW identifies B as an 577 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 578 the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own 579 SRH containing the SIDs bound to the SR policy associated with this 580 BindingSID. There is one instance of the End.M.GTP6.D SID per PDU 581 type. 583 S1 and C1 perform their related Endpoint functionality and forward 584 the packet. 586 When the packet arrives at UPF2, the active segment is (U2::1) which 587 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 588 IPv6 header with all its extension headers) and forwards the packet 589 toward the data network. 591 5.3.1.2. Packet flow - Downlink 593 The downlink packet flow is as follows: 595 UPF2_in : (Z,A) -> UPF2 maps the flow with 596 597 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red 598 C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) 599 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 600 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 601 gNB_out : (Z,A) 603 When a packet destined to A arrives at the UPF2, the UPF2 performs a 604 lookup in the table associated to A and finds the SID list . The UPF2 performs a T.Encaps.Red operation, 606 encapsulating the packet into a new IPv6 header with its 607 corresponding SRH. 609 C1 and S1 perform their related Endpoint processing. 611 Once the packet arrives at the SRGW, the SRGW identifies the active 612 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 613 and all its extensions headers. The SRGW generates new IPv6, UDP and 614 GTP headers. The new IPv6 DA is the gNB which is the last SID in the 615 received SRH. The TEID in the generated GTP header is an argument of 616 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 617 packet and forwards the packet toward the gNB. There is one instance 618 of the End.M.GTP6.E SID per PDU type. 620 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 621 packet. The gNB looks for the specific radio bearer for that TEID 622 and forward it on the bearer. This gNB behavior is not modified from 623 current and previous generations. 625 5.3.1.3. Scalability 627 For the downlink traffic, the SRGW is stateless. All the state is in 628 the SRH inserted by the UPF2. The UPF2 must have the UE states since 629 it is the UE's session anchor point. 631 For the uplink traffic, the state at the SRGW does not necessarily 632 need to be unique per UE PDU Session; the state state can be shared 633 among UEs. This enables much more scalable SRGW deployments compared 634 to a solution holding millions of states, one or more per UE. 636 5.3.2. Interworking with IPv4 GTP 638 In this interworking mode the gNB uses GTP over IPv4 in the N3 639 interface 641 Key points: 643 o The gNB is unchanged and encapsulates packets into GTP (the N3 644 interface is not modified). 645 o In the uplink, traffic is classified by SRGW's Uplink Classifier 646 and steered into an SR policy. The SRGW is a UPF1 functionality 647 and can coexist with UPF1's Uplink Classifier functionality. 648 o SRGW removes GTP, finds the SID list related to DA, and adds a SRH 649 with the SID list. 651 An example topology is shown in Figure 6. In this mode the gNB is an 652 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 653 the SRGW maps the IPv4/GTP traffic to SRv6. 655 S1 and C1 are two service segment endpoints. S1 represents a VNF in 656 the network, and C1 represents a router configured for Traffic 657 Engineering. 659 +----+ 660 IPv4/GTP -| S1 |- ___ 661 +--+ +-----+ [N3] / +----+ \ / 662 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 663 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 664 GTP \ +------+ / +----+ +------+ \___ 665 -| UPF1 |- SRv6 SRv6 666 +------+ TE 667 SR Gateway 669 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 671 5.3.2.1. Packet flow - Uplink 673 The uplink packet flow is as follows: 675 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 676 unchanged IPv4/GTP 677 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.GTP4.D function 678 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 679 C1_out : (SRGW, U2::1) (A,Z) -> PSP 680 UPF2_out: (A,Z) -> End.DT4 or End.DT6 682 The UE sends a packet destined to Z toward the gNB on a specific 683 bearer for that session. The gNB, which is unmodified, encapsulates 684 the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and 685 the GTP TEID are the ones received at the N2 interface. 687 When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink 688 Classifier rule for incoming traffic from the gNB, that steers the 689 traffic into an SR policy by using the function T.M.GTP4.D. The SRGW 690 removes the IPv4, UDP and GTP headers and pushes an IPv6 header with 691 its own SRH containing the SIDs related to the SR policy associated 692 with this traffic. The SRGW forwards according to the new IPv6 DA. 694 S1 and C1 perform their related Endpoint functionality and forward 695 the packet. 697 When the packet arrives at UPF2, the active segment is (U2::1) which 698 is bound to End.DT4/6 which performs the decapsulation (removing the 699 outer IPv6 header with all its extension headers) and forwards toward 700 the data network. 702 5.3.2.2. Packet flow - Downlink 704 The downlink packet flow is as follows: 706 UPF2_in : (Z,A) -> UPF2 maps flow with SID 707 708 UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red 709 C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) 710 S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) 711 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 712 gNB_out : (Z,A) 714 When a packet destined to A arrives at the UPF2, the UPF2 performs a 715 lookup in the table associated to A and finds the SID list . The UPF2 performs a T.Encaps.Red operation, 717 encapsulating the packet into a new IPv6 header with its 718 corresponding SRH. 720 The nodes C1 and S1 perform their related Endpoint processing. 722 Once the packet arrives at the SRGW, the SRGW identifies the active 723 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 724 and all its extensions headers. The SRGW generates an IPv4, UDP and 725 GTP headers. The IPv4 SA and DA are received as SID arguments. The 726 TEID in the generated GTP header is also the arguments of the 727 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 728 and forwards the packet toward the gNB. 730 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 731 packet. The gNB looks for the specific radio bearer for that TEID 732 and forward it on the bearer. This gNB behavior is not modified from 733 current and previous generations. 735 5.3.2.3. Scalability 737 For the downlink traffic, the SRGW is stateless. All the state is in 738 the SRH inserted by the UPF. The UPF must have this UE-base state 739 anyway (since it is its anchor point). 741 For the uplink traffic, the state at the SRGW is dedicated on a per 742 UE/session basis according to an Uplink Classifier. There is state 743 for steering the different sessions in the form of a SR Policy. 744 However, SR policies are shared among several UE/sessions. 746 5.3.3. SRv6 Drop-in Interworking 748 SRv6 drop-in interworking mode provides SRv6 user plane in between 749 GTP-U tunnel endpoints. This mode employs two SRGWs to do GTP-U 750 traffic to SRv6 mapping on one SRGW, and vice versa. 752 Unlike other interworking modes, both of the mobility overlay 753 endpoints use GTP-U. Two SRGWs are deployed in either N3 or N9 754 interface to realize an intermediate SR policy. 756 The SRGW behaviors for this mode are equivalent with other modes 757 except in IPv6 GTP case on the GTP-U to SRv6 direction. Due to that 758 only one exception, it is enough that this section focuses to 759 describe IPv6 GTP case on one direction with an illustration. 761 +----+ 762 -| S1 |- 763 +-----------+ / +----+ \ 764 | UPF2a/gNB |- SRv6 / SRv6 \ +----+ +------+ +-------+ 765 +-----------+ \ [N9]/ VNF -| C1 |---| UPF1b|------| UPF2b | 766 GTP \ +------+ / +----+ +------+ +-------+ 767 -| UPF1a|- SRv6 SR Gateway-B GTP 768 +------+ TE 769 SR Gateway-A 771 Figure 7: Example topology for SRv6 Drop-in 773 5.3.3.1. Packet flow 775 The packet flow of Figure 7 is as follows: 777 UPF2a/gNB_out: (UPF2a/gNB, U2b::)(GTP: TEID T)(A,Z) 778 SRGW-A_out : (SRGW-A, S1)(U2b::, U1b::TEID, C1; SL=3)(A,Z) -> U2b:: is an 779 End.M.GTP6.D.Di 780 SID at SRGW-A 781 S1_out : (SRGW-A, C1)(U2b::, U1b::TEID, C1; SL=2)(A,Z) 782 C1_out : (SRGW-A, U1b::TEID)(U2b::, U1b::TEID, C1; SL=1)(A,Z) 783 SRGW-B_out : (SRGW-B, U2b::)(GTP: TEID T)(A,Z) -> U1b::TEID is an 784 End.M.GTP6.E 785 SID at SRGW-B 786 UPF2b_out : (A,Z) 788 When a packet destined to Z arrives at the UPF2a, or gNB, which is 789 unmodified, performs encapsulates the packet into a new IPv6, UDP and 790 GTP headers. The IPv6 DA, U2b::, and the GTP TEID are the ones 791 received at the N2 interface. 793 The IPv6 address that was signalled over the N2 interface for that UE 794 PDU Session, U2b::, is now the IPv6 DA. U2b:: is an SRv6 Binding SID 795 at SRGW-A. Hence the packet is routed to the SRGW. 797 When the packet arrives at SRGW-A, the SRGW identifies U2b:: as an 798 End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW 799 removes the IPv6, UDP and GTP headers, and pushes an IPv6 header with 800 its own SRH containing the SIDs bound to the SR policy associated 801 with this Binding SID. There is one instance of the End.M.GTP6.D.Di 802 SID per PDU type. 804 S1 and C1 perform their related Endpoint functionality and forward 805 the packet. 807 Once the packet arrives at SRGW-B, the SRGW identifies the active SID 808 as an End.M.GTP6.E function. The SRGW removes the IPv6 header and 809 all its extensions headers. The SRGW generates new IPv6, UDP and GTP 810 headers. The new IPv6 DA is U2b:: which is the last SID in the 811 received SRH. The TEID in the generated GTP header is an argument of 812 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 813 packet and forwards the packet toward UPF2b. There is one instance 814 of the End.M.GTP6.E SID per PDU type. 816 Once the packet arrives at UPF2b, the packet is a regular IPv6/GTP 817 packet. The UPF looks for the specific rule for that TEID to forward 818 the packet. This UPF behavior is not modified from current and 819 previous generations. 821 5.3.4. Extensions to the interworking mechanisms 823 In this section we presented three mechanisms for interworking with 824 gNBs and UPFs that do not support SRv6. These mechanisms are used to 825 support GTP over IPv4 and IPv6. 827 Even though we have presented these methods as an extension to the 828 "Enhanced mode", it is straightforward in its applicability to the 829 "Traditional mode". 831 Furthermore, although these mechanisms are designed for interworking 832 with legacy RAN at the N3 interface, these methods could also be 833 applied for interworking with a non-SRv6 capable UPF at the N9 834 interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). 836 6. SRv6 SID Mobility Functions 838 6.1. Args.Mob.Session 840 Args.Mob.Session provide per-session information for charging, 841 buffering and lawful intercept (among others) required by some mobile 842 nodes. The Args.Mob.Session argument format is used in combination 843 with End.Map, End.DT and End.DX functions. Note that proposed format 844 is applicable for 5G networks, while similar formats could be 845 proposed for legacy networks. 847 0 1 2 3 848 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | QFI |R|U| PDU Session ID | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 |PDU Sess(cont')| 853 +-+-+-+-+-+-+-+-+ 855 Args.Mob.Session format 857 o QFI: QoS Flow Identifier [TS.38415] 858 o R: Reflective QoS Indication [TS.23501]. This parameter indicates 859 the activaton of reflective QoS towards the UE for the transfered 860 packet. Reflective QoS enables the UE to map UL User Plane 861 traffic to QoS Flows without SMF provided QoS rules. 862 o U: Unused and for future use. MUST be 0 on transmission and 863 ignored on receipt. 864 o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 865 is TEID. 867 Arg.Mob.Session is required in case that one SID aggregates multiple 868 PDU Session. Since the SRv6 function is likely NOT to be 869 instantiated per PDU session, Args.Mob.Session helps the UPF to 870 perform the functions which require per QFI and/or per PDU Session 871 granularity. 873 6.2. End.MAP 875 The "Endpoint function with SID mapping" function (End.MAP for short) 876 is used in several scenarios. Particularly in mobility, End.MAP is 877 used in the UPFs for the PDU Session anchor functionality. 879 When a SR node N receives a packet destined to S and S is a local 880 End.MAP SID, N does the following: 882 1. Lookup the IPv6 DA in the mapping table 883 2. update the IPv6 DA with the new mapped SID ;; Ref1 884 3. IF segment_list > 1 885 4. insert a new SRH 886 5. forward according to the new mapped SID 888 Ref1: The SIDs in the SRH are NOT modified. 890 6.3. End.M.GTP6.D 892 The "Endpoint function with IPv6/GTP decapsulation into SR policy" 893 function (End.M.GTP6.D for short) is used in interworking scenario 894 for the uplink toward from the legacy gNB using IPv6/GTP. Suppose, 895 for example, this SID is associated with an SR policy 896 and an IPv6 Source Address A. 898 When the SR Gateway node N receives a packet destined to S and S is a 899 local End.M.GTP6.D SID, N does: 901 1. IF NH=UDP & UDP_DST_PORT = GTP THEN 902 2. copy TEID to form SID S3 903 3. pop the IPv6, UDP and GTP headers 904 4. push a new IPv6 header with a SR policy in SRH 905 5. set the outer IPv6 SA to A 906 6. set the outer IPv6 DA to S1 907 7. set the outer IPv6 NH ;; Ref1 908 8. forward according to the S1 segment of the SRv6 Policy 909 9. ELSE 910 10. Drop the packet 912 Ref1: The NH is set based on the SID parameter. There is one 913 instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the 914 NH is already known in advance. For the IPv4v6 PDU Session Type, in 915 addition we inspect the first nibble of the PDU to know the NH value. 917 The prefix of last segment(S3 in above example) SHOULD be followed by 918 an Arg.Mob.Session argument space which is used to provide the 919 session identifiers. 921 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 922 gateway. 924 6.4. End.M.GTP6.D.Di 926 The "Endpoint function with IPv6/GTP decapsulation into SR policy for 927 Drop-in Mode" function (End.M.GTP6.D.Di for short) is used in SRv6 928 drop-in interworking scenario described in Section 5.3.3. The 929 difference between End.M.GTP6.D as another variant of IPv6/GTP 930 decapsulation function is that the original IPv6 DA of GTP packet is 931 preserved as the last SID in SRH. Suppose, for example, this SID is 932 associated with an SR policy and an IPv6 Source Address 933 A. 935 When the SR Gateway node N receives a packet destined to S and S is a 936 local End.M.GTP6.D.Di SID, N does: 938 1. IF NH=UDP & UDP_DST_PORT = GTP THEN 939 2. preserve S and copy TEID to form SID S3 940 3. pop the IPv6, UDP and GTP headers 941 4. push a new IPv6 header with a SR policy in SRH 942 5. set the outer IPv6 SA to A 943 6. set the outer IPv6 DA to S1 944 7. set the outer IPv6 NH ;; Ref1 945 8. forward according to the S1 segment of the SRv6 Policy 946 9. ELSE 947 10. Drop the packet 949 Ref1: The NH is set based on the SID parameter. There is one 950 instantiation of the End.M.GTP6.D.Di SID per PDU Session Type, hence 951 the NH is already known in advance. For the IPv4v6 PDU Session Type, 952 in addition we inspect the first nibble of the PDU to know the NH 953 value. 955 The prefix of last segment(S3 in above example) SHOULD be followed by 956 an Arg.Mob.Session argument space which is used to provide the 957 session identifiers. 959 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 960 gateway. 962 6.5. End.M.GTP6.E 964 The "Endpoint function with encapsulation for IPv6/GTP tunnel" 965 function (End.M.GTP6.E for short) is used in interworking scenario 966 for the downlink toward the legacy gNB using IPv6/GTP. 968 The prefix of End.M.GTP6.E SID MUST be followed by the 969 Arg.Mob.Session argument space which is used to provide the session 970 identifiers. 972 When the SR Gateway node N receives a packet destined to S, and S is 973 a local End.M.GTP6.E SID, N does the following: 975 1. IF NH=SRH & SL = 1 THEN ;; Ref1 976 2. store SRH[0] in variable new_DA 977 3. store TEID in variable new_TEID from IPv6 DA ;; Ref2 978 4. pop IP header and all its extension headers 979 5. push new IPv6 header and GTP-U header 980 6. set IPv6 DA to new_DA 981 7. set IPv6 SA to A 982 8. set GTP_TEID to new_TEID 983 9. lookup the new_DA and forward the packet accordingly 984 10. ELSE 985 11. Drop the packet 986 Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID. 988 Ref2: TEID is extracted from the argument space of the current SID. 990 The source address A SHOULD be an End.M.GTP6.D SID instantiated at an 991 SR gateway. 993 6.6. End.M.GTP4.E 995 The "Endpoint function with encapsulation for IPv4/GTP tunnel" 996 function (End.M.GTP4.E for short) is used in the downlink when doing 997 interworking with legacy gNB using IPv4/GTP. 999 When the SR Gateway node N receives a packet destined to S and S is a 1000 local End.M.GTP4.E SID, N does: 1002 1. IF (NH=SRH and SL = 0) or ENH=4 THEN 1003 2. store IPv6 DA in buffer S 1004 3. store IPv6 SA in buffer S' 1005 4. pop the IPv6 header and its extension headers 1006 5. push UDP/GTP headers with GTP TEID from S 1007 6. push outer IPv4 header with SA, DA from S' and S 1008 7. ELSE 1009 8. Drop the packet 1011 The End.M.GTP4.E SID in S has the following format: 1013 0 127 1014 +-----------------------+-------+----------------+---------+ 1015 | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | 1016 +-----------------------+-------+----------------+---------+ 1017 128-a-b-c a b c 1019 End.M.GTP4.E SID Encoding 1021 S' has the following format: 1023 0 127 1024 +----------------------+--------+--------------------------+ 1025 | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | 1026 +----------------------+--------+--------------------------+ 1027 128-a-b a b 1029 IPv6 SA Encoding for End.M.GTP4.E 1031 6.7. T.M.GTP4.D 1033 The "Transit with tunnel decapsulation and map to an SRv6 policy" 1034 function (T.M.GTP4.D for short) is used in the direction from legacy 1035 IPv4 user-plane to SRv6 user-plane network. 1037 When the SR Gateway node N receives a packet destined to a IW- 1038 IPv4-Prefix, N does: 1040 1. IF Payload == UDP/GTP THEN 1041 2. pop the outer IPv4 header and UDP/GTP headers 1042 3. copy IPv4 DA, TEID to form SID B 1043 4. copy IPv4 SA to form IPv6 SA B' 1044 5. encapsulate the packet into a new IPv6 header ;;Ref1 1045 6. set the IPv6 DA = B 1046 7. forward along the shortest path to B 1047 8. ELSE 1048 9. Drop the packet 1050 Ref1: The NH value is identified by inspecting the first nibble of 1051 the inner payload. 1053 The SID B has the following format: 1055 0 127 1056 +-----------------------+-------+----------------+---------+ 1057 |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | 1058 +-----------------------+-------+----------------+---------+ 1059 128-a-b-c a b c 1061 T.M.GTP4.D SID Encoding 1063 The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 1064 (U1) to bind a SR policy [I-D.ietf-spring-segment-routing-policy]. 1066 The prefix of B' SHOULD be an End.M.GTP4.E SID with its format 1067 instantiated at an SR gateway with the IPv4 SA of the receiving 1068 packet. 1070 6.8. End.Limit: Rate Limiting function 1072 The mobile user-plane requires a rate-limit feature. For this 1073 purpose, we define a new function "End.Limit". The "End.Limit" 1074 function encodes in its arguments the rate limiting parameter that 1075 should be applied to this packet. Multiple flows of packets should 1076 have the same group identifier in the SID when those flows are in an 1077 same AMBR group. The encoding format of the rate limit segment SID 1078 is as follows: 1080 +----------------------+----------+-----------+ 1081 | LOC+FUNC rate-limit | group-id | limit-rate| 1082 +----------------------+----------+-----------+ 1083 128-i-j i j 1085 End.Limit: Rate limiting function argument format 1087 If the limit-rate bits are set to zero, the node should not do rate 1088 limiting unless static configuration or control-plane sets the limit 1089 rate associated to the SID. 1091 7. SRv6 supported 3GPP PDU session types 1093 The 3GPP [TS.23501] defines the following PDU session types: 1095 o IPv4 1096 o IPv6 1097 o IPv4v6 1098 o Ethernet 1099 o Unstructured 1101 SRv6 supports the 3GPP PDU session types without any protocol 1102 overhead by using the corresponding SRv6 functions (End.DX4, End.DT4 1103 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 1104 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 PDU sessions). 1105 Unstructured PDUs are not supported. 1107 8. Network Slicing Considerations 1109 A mobile network may be required to implement "network slices", which 1110 logically separate network resources. User-plane functions 1111 represented as SRv6 segments would be part of a slice. 1113 [I-D.ietf-spring-segment-routing-policy] describes a solution to 1114 build basic network slices with SR. Depending on the requirements, 1115 these slices can be further refined by adopting the mechanisms from: 1117 o IGP Flex-Algo [I-D.ietf-lsr-flex-algo] 1118 o Inter-Domain policies 1119 [I-D.ietf-spring-segment-routing-central-epe] 1121 Furthermore, these can be combined with ODN/AS 1122 [I-D.ietf-spring-segment-routing-policy] for automated slice 1123 provisioning and traffic steering. 1125 Further details on how these tools can be used to create end to end 1126 network slices are documented in 1127 [I-D.ali-spring-network-slicing-building-blocks]. 1129 9. Control Plane Considerations 1131 This document focuses on user-plane behavior and its independence 1132 from the control plane. 1134 The control plane could be the current 3GPP-defined control plane 1135 with slight modifications to the N4 interface [TS.29244]. 1137 Alternatively, SRv6 could be used in conjunction with a new mobility 1138 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 1139 hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA 1140 [I-D.gundavelli-dmm-mfa] or in conjunction with FPC 1141 [I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes 1142 and its applicability to SRv6 is out of the scope of this document. 1144 Section 11 allocates SRv6 endpoint function types for the new 1145 functions defined in this document. Control-plane protocols are 1146 expected to use these function type codes to signal each function. 1148 SRv6's network programming nature allows a flexible and dynamic UPF 1149 placement. 1151 10. Security Considerations 1153 TBD 1155 11. IANA Considerations 1157 IANA is requested to allocate, within the "SRv6 Endpoint Types" sub- 1158 registry belonging to the top-level "Segment-routing with IPv6 1159 dataplane (SRv6) Parameters" registry 1160 [I-D.ietf-spring-srv6-network-programming], the following values: 1162 +-------------+-----+-------------------+-----------+ 1163 | Value/Range | Hex | Endpoint function | Reference | 1164 +-------------+-----+-------------------+-----------+ 1165 | TBA | TBA | End.MAP | [This.ID] | 1166 | TBA | TBA | End.M.GTP6.D | [This.ID] | 1167 | TBA | TBA | End.M.GTP6.E | [This.ID] | 1168 | TBA | TBA | End.M.GTP4.E | [This.ID] | 1169 | TBA | TBA | End.Limit | [This.ID] | 1170 +-------------+-----+-------------------+-----------+ 1172 Table 1: SRv6 Mobile User-plane Endpoint Types 1174 12. Acknowledgements 1176 The authors would like to thank Daisuke Yokota, Bart Peirens, 1177 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1178 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1179 Shekhar and Aeneas Dodd-Noble for their useful comments of this work. 1181 13. Contributors 1183 Kentaro Ebisawa 1184 Toyota Motor Corporation 1185 Japan 1187 Email: ebisawa@toyota-tokyo.tech 1189 14. References 1191 14.1. Normative References 1193 [I-D.ietf-6man-segment-routing-header] 1194 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1195 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1196 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 1197 progress), October 2019. 1199 [I-D.ietf-spring-segment-routing-policy] 1200 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 1201 P. Mattes, "Segment Routing Policy Architecture", draft- 1202 ietf-spring-segment-routing-policy-07 (work in progress), 1203 May 2020. 1205 [I-D.ietf-spring-srv6-network-programming] 1206 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1207 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1208 draft-ietf-spring-srv6-network-programming-15 (work in 1209 progress), March 2020. 1211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1212 Requirement Levels", BCP 14, RFC 2119, 1213 DOI 10.17487/RFC2119, March 1997, 1214 . 1216 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1217 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1218 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1219 July 2018, . 1221 14.2. Informative References 1223 [I-D.ali-spring-network-slicing-building-blocks] 1224 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 1225 "Building blocks for Slicing in Segment Routing Network", 1226 draft-ali-spring-network-slicing-building-blocks-02 (work 1227 in progress), November 2019. 1229 [I-D.auge-dmm-hicn-mobility-deployment-options] 1230 Auge, J., Carofiglio, G., Muscariello, L., and M. 1231 Papalini, "Anchorless mobility management through hICN 1232 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1233 mobility-deployment-options-03 (work in progress), January 1234 2020. 1236 [I-D.camarillo-dmm-srv6-mobile-pocs] 1237 Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A., 1238 Matsushima, S., and d. daniel.voyer@bell.ca, "Segment 1239 Routing IPv6 for mobile user-plane PoCs", draft-camarillo- 1240 dmm-srv6-mobile-pocs-02 (work in progress), April 2019. 1242 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1243 Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S., 1244 Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- 1245 Cases", draft-camarilloelmalky-springdmm-srv6-mob- 1246 usecases-02 (work in progress), August 2019. 1248 [I-D.gundavelli-dmm-mfa] 1249 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 1250 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01 1251 (work in progress), September 2018. 1253 [I-D.ietf-dmm-fpc-cpdp] 1254 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1255 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1256 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-13 1257 (work in progress), March 2020. 1259 [I-D.ietf-lsr-flex-algo] 1260 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1261 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1262 algo-07 (work in progress), April 2020. 1264 [I-D.ietf-spring-segment-routing-central-epe] 1265 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1266 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1267 Engineering", draft-ietf-spring-segment-routing-central- 1268 epe-10 (work in progress), December 2017. 1270 [I-D.ietf-spring-sr-service-programming] 1271 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1272 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1273 Henderickx, W., and S. Salsano, "Service Programming with 1274 Segment Routing", draft-ietf-spring-sr-service- 1275 programming-02 (work in progress), March 2020. 1277 [I-D.rodrigueznatal-lisp-srv6] 1278 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1279 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1280 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-03 1281 (work in progress), January 2020. 1283 [TS.23501] 1284 3GPP, "System Architecture for the 5G System", 3GPP TS 1285 23.501 15.0.0, November 2017. 1287 [TS.29244] 1288 3GPP, "Interface between the Control Plane and the User 1289 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1291 [TS.29281] 1292 3GPP, "General Packet Radio System (GPRS) Tunnelling 1293 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1294 December 2017. 1296 [TS.38415] 1297 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1298 3GPP R3-174510 0.0.0, August 2017. 1300 Appendix A. Implementations 1302 This document introduces new SRv6 functions. These functions have an 1303 open-source P4 implementation available in 1304 . 1306 There are also implementations in M-CORD NGIC and Open Air Interface 1307 (OAI). Further details can be found in 1308 [I-D.camarillo-dmm-srv6-mobile-pocs]. 1310 Authors' Addresses 1312 Satoru Matsushima 1313 SoftBank 1314 Tokyo 1315 Japan 1317 Email: satoru.matsushima@g.softbank.co.jp 1318 Clarence Filsfils 1319 Cisco Systems, Inc. 1320 Belgium 1322 Email: cf@cisco.com 1324 Miya Kohno 1325 Cisco Systems, Inc. 1326 Japan 1328 Email: mkohno@cisco.com 1330 Pablo Camarillo Garvia 1331 Cisco Systems, Inc. 1332 Spain 1334 Email: pcamaril@cisco.com 1336 Daniel Voyer 1337 Bell Canada 1338 Canada 1340 Email: daniel.voyer@bell.ca 1342 Charles E. Perkins 1343 Futurewei Inc. 1344 2330 Central Expressway 1345 Santa Clara, CA 95050 1346 USA 1348 Phone: +1-408-330-4586 1349 Email: charliep@computer.org