idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 7, 2021) is 1105 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 175, but not defined == Missing Reference: 'N11' is mentioned on line 246, but not defined == Missing Reference: 'N2' is mentioned on line 247, but not defined == Missing Reference: 'N4' is mentioned on line 251, but not defined == Missing Reference: 'N3' is mentioned on line 668, but not defined == Missing Reference: 'N9' is mentioned on line 511, but not defined == Missing Reference: 'N6' is mentioned on line 669, but not defined == Missing Reference: 'NET-PGM' is mentioned on line 1082, but not defined -- Looks like a reference, but probably isn't: '0' on line 1028 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-03 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-10 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group S. Matsushima, Ed. 3 Internet-Draft SoftBank 4 Intended status: Standards Track C. Filsfils 5 Expires: October 9, 2021 M. Kohno 6 P. Camarillo, Ed. 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 April 7, 2021 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-11 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 October 9, 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 Endpoint Behaviors . . . . . . . . . . . 4 67 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 5 69 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . 11 76 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 77 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 78 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14 79 5.3.3. Extensions to the interworking mechanisms . . . . . . 17 80 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17 81 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 18 82 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19 83 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 85 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 21 86 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 22 87 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 23 88 6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25 89 6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26 90 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 26 91 8. Network Slicing Considerations . . . . . . . . . . . . . . . 26 92 9. Control Plane Considerations . . . . . . . . . . . . . . . . 27 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 99 14.2. Informative References . . . . . . . . . . . . . . . . . 29 100 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 31 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 103 1. Introduction 105 In mobile networks, mobility management systems provide connectivity 106 over a wireless link to stationary and non-stationary nodes. The 107 user-plane establishes a tunnel between the mobile node and its 108 anchor node over IP-based backhaul and core networks. 110 This document shows the applicability of SRv6 (Segment Routing IPv6) 111 to mobile networks. 113 Segment Routing [RFC8402] is a source routing architecture: a node 114 steers a packet through an ordered list of instructions called 115 "segments". A segment can represent any instruction, topological or 116 service based. 118 SRv6 applied to mobile networks enables a source-routing based mobile 119 architecture, where operators can explicitly indicate a route for the 120 packets to and from the mobile node. The SRv6 Endpoint nodes serve 121 as mobile user-plane anchors. 123 2. Conventions and Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2.1. Terminology 131 o CNF: Cloud-native Network Function 132 o NFV: Network Function Virtualization 133 o PDU: Packet Data Unit 134 o PDU Session: Context of an UE connects to a mobile network. 135 o UE: User Equipment 136 o UPF: User Plane Function 137 o VNF: Virtual Network Function (including CNFs) 139 The following terms used within this document are defined in 140 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 141 SID, Active Segment, SR Policy, Prefix SID, Adjacency SID and Binding 142 SID. 144 The following terms used within this document are defined in 145 [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint 146 Node and Reduced SRH. 148 The following terms used within this document are defined in 149 [RFC8986]: NH, SL, FIB, SA, DA, SRv6 SID behavior, SRv6 Segment 150 Endpoint Behavior. 152 2.2. Conventions 154 An SR Policy is resolved to a SID list. A SID list is represented as 155 where S1 is the first SID to visit, S2 is the second SID 156 to visit and S3 is the last SID to visit along the SR path. 158 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 160 - Source Address is SA, Destination Address is DA, and next-header is 161 SRH 162 - SRH with SID list with Segments Left = SL 163 - Note the difference between the <> and () symbols: 164 represents a SID list where S1 is the first SID and S3 is the last 165 SID to traverse. (S3, S2, S1; SL) represents the same SID list but 166 encoded in the SRH format where the rightmost SID in the SRH is the 167 first SID and the leftmost SID in the SRH is the last SID. When 168 referring to an SR policy in a high-level use-case, it is simpler 169 to use the notation. When referring to an 170 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 171 notation is more convenient. 172 - The payload of the packet is omitted. 174 SRH[n]: A shorter representation of Segment List[n], as defined in 175 [RFC8754]. SRH[SL] can be different from the DA of the IPv6 header. 177 o gNB::1 is an IPv6 address (SID) assigned to the gNB. 178 o U1::1 is an IPv6 address (SID) assigned to UPF1. 179 o U2::1 is an IPv6 address (SID) assigned to UPF2. 180 o U2:: is some other IPv6 address (SID) assigned to UPF2. 182 2.3. Predefined SRv6 Endpoint Behaviors 184 The following SRv6 Endpoint Behaviors are defined in [RFC8986]. 186 o End.DT4: Decapsulation and Specific IPv4 Table Lookup 187 o End.DT6: Decapsulation and Specific IPv6 Table Lookup 188 o End.DT46: Decapsulation and Specific IP Table Lookup 189 o End.DX4: Decapsulation and IPv4 Cross-Connect 190 o End.DX6: Decapsulation and IPv6 Cross-Connect 191 o End.DX2: Decapsulation and L2 Cross-Connect 192 o End.T: Endpoint with specific IPv6 Table Lookup 194 This document defines new SRv6 Segment Endpoint Behaviors in 195 Section 6. 197 3. Motivation 199 Mobile networks are becoming more challenging to operate. On one 200 hand, traffic is constantly growing, and latency requirements are 201 tighter; on the other-hand, there are new use-cases like distributed 202 NFVi that are also challenging network operations. 204 The current architecture of mobile networks does not take into 205 account the underlying transport. The user-plane is rigidly 206 fragmented into radio access, core and service networks, connected by 207 tunneling according to user-plane roles such as access and anchor 208 nodes. These factors have made it difficult for the operator to 209 optimize and operate the data-path. 211 In the meantime, applications have shifted to use IPv6, and network 212 operators have started adopting IPv6 as their IP transport. SRv6, 213 the IPv6 dataplane instantiation of Segment Routing [RFC8402], 214 integrates both the application data-path and the underlying 215 transport layer into a single protocol, allowing operators to 216 optimize the network in a simplified manner and removing forwarding 217 state from the network. It is also suitable for virtualized 218 environments, like VNF/CNF to VNF/CNF networking. SRv6 has been 219 deployed in dozens of networks 220 [I-D.matsushima-spring-srv6-deployment-status]. 222 SRv6 defines the network-programming concept [RFC8986]. Applied to 223 mobility, SRv6 can provide the user-plane behaviors needed for 224 mobility management. SRv6 takes advantage of the underlying 225 transport awareness and flexibility together with the ability to also 226 include services to optimize the end-to-end mobile dataplane. 228 The use-cases for SRv6 mobility are discussed in 229 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]. 231 4. 3GPP Reference Architecture 233 This section presents a reference architecture and possible 234 deployment scenarios. 236 Figure 1 shows a reference diagram from the 5G packet core 237 architecture [TS.23501]. 239 The user plane described in this document does not depend on any 240 specific architecture. The 5G packet core architecture as shown is 241 based on the latest 3GPP standards at the time of writing this draft. 243 +-----+ 244 | AMF | 245 /+-----+ 246 / | [N11] 247 [N2] / +-----+ 248 +------/ | SMF | 249 / +-----+ 250 / / \ 251 / / \ [N4] 252 / / \ ________ 253 / / \ / \ 254 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 255 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 256 +--+ +-----+ +------+ +------+ \________/ 258 Figure 1: 3GPP 5G Reference Architecture 260 o UE: User Endpoint 261 o gNB: gNodeB with N3 interface towards packet core (and N2 for 262 control plane) 263 o UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane) 264 o UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane) 265 o SMF: Session Management Function 266 o AMF: Access and Mobility Management Function 267 o DN: Data Network e.g. operator services, Internet access 269 This reference diagram does not depict a UPF that is only connected 270 to N9 interfaces, although the mechanisms defined in this document 271 also work in such case. 273 Each session from a UE gets assigned to a UPF. Sometimes multiple 274 UPFs may be used, providing richer service functions. A UE gets its 275 IP address from the DHCP block of its UPF. The UPF advertises that 276 IP address block toward the Internet, ensuring that return traffic is 277 routed to the right UPF. 279 5. User-plane behaviors 281 This section introduces an SRv6 based mobile user-plane. 283 In order to simplify the adoption of SRv6, we present two different 284 "modes" that vary with respect to the use of SRv6. The first one is 285 the "Traditional mode", which inherits the current 3GPP mobile user- 286 plane. In this mode GTP-U protocol [TS.29281] is replaced by SRv6, 287 however the N3, N9 and N6 interfaces are still point-to-point 288 interfaces with no intermediate waypoints as in the current mobile 289 network architecture. 291 The second mode is the "Enhanced mode". This is an evolution from 292 the "Traditional mode". In this mode the N3, N9 or N6 interfaces 293 have intermediate waypoints -SIDs- that are used for Traffic 294 Engineering or VNF purposes. This results in optimal end-to-end 295 policies across the mobile network with transport and services 296 awareness. 298 In both, the Traditional and the Enhanced modes, we assume that the 299 gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6 300 interfaces are SRv6). 302 In addition to those two modes, we introduce two mechanisms for 303 interworking with legacy access networks (those where the N3 304 interface is unmodified). In this document we introduce them as a 305 variant to the Enhanced mode, however they are equally applicable to 306 the Traditional mode. 308 One of these mechanisms is designed to interwork with legacy gNBs 309 using GTP/IPv4. The second mechanism is designed to interwork with 310 legacy gNBs using GTP/IPv6. 312 This document uses SRv6 Segment Endpoint Behaviors defined in 313 [RFC8986] as well as new SRv6 Segment Endpoint Behaviors designed for 314 the mobile user plane that are defined in this document in Section 6. 316 5.1. Traditional mode 318 In the traditional mode, the existing mobile UPFs remain unchanged 319 with the sole exception of the use of SRv6 as the data plane instead 320 of GTP-U. There is no impact to the rest of the mobile system. 322 In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 323 with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored 324 here to replace GTP encapsulation with the SRv6 encapsulation, while 325 not changing anything else. There will be a unique SRv6 SID 326 associated with each PDU Session. 328 The traditional mode minimizes the changes required to the mobile 329 system; hence it is a good starting point for forming a common 330 ground. 332 Our example topology is shown in Figure 2. In traditional mode the 333 gNB and the UPFs are SR-aware. In the descriptions of the uplink and 334 downlink packet flow, A is an IPv6 address of the UE, and Z is an 335 IPv6 address reachable within the Data Network DN. A new SRv6 336 Endpoint Behavior, End.MAP, defined in Section 6.2, is used. 338 ________ 339 SRv6 SRv6 / \ 340 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 341 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 342 +--+ +-----+ +------+ +------+ \________/ 343 SRv6 node SRv6 node SRv6 node 345 Figure 2: Traditional mode - example topology 347 5.1.1. Packet flow - Uplink 349 The uplink packet flow is as follows: 351 UE_out : (A,Z) 352 gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red 353 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 354 UPF2_out: (A,Z) -> End.DT4 or End.DT6 356 When the UE packet arrives at the gNB, the gNB performs a 357 H.Encaps.Red operation. Since there is only one SID, there is no 358 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 359 U1::1. U1::1 represents an anchoring SID specific for that session 360 at UPF1. gNB obtains the SID U1::1 from the existing control plane 361 (N2 interface). 363 When the packet arrives at UPF1, the SID U1::1 is associated with the 364 End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1, 365 that belongs to the next UPF (U2). 367 When the packet arrives at UPF2, the SID U2::1 corresponds to an 368 End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates 369 the packet, performs a lookup in a specific table associated with 370 that mobile network and forwards the packet toward the data network 371 (DN). 373 5.1.2. Packet flow - Downlink 375 The downlink packet flow is as follows: 377 UPF2_in : (Z,A) 378 UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red 379 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 380 gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2 382 When the packet arrives at the UPF2, the UPF2 maps that flow into a 383 PDU Session. This PDU Session is associated with the segment 384 endpoint . UPF2 performs a H.Encaps.Red operation, 385 encapsulating the packet into a new IPv6 header with no SRH since 386 there is only one SID. 388 Upon packet arrival on UPF1, the SID U1::2 is a local SID associated 389 with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next 390 anchoring point and replaces U1::2 by gNB::1, that belongs to the 391 next hop. 393 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4, 394 End.DX6 or End.DX2 behavior (depending on the PDU Session Type). The 395 gNB decapsulates the packet, removing the IPv6 header and all its 396 extensions headers, and forwards the traffic toward the UE. 398 5.2. Enhanced Mode 400 Enhanced mode improves scalability, provides traffic engineering 401 capabilities and allows service programming 402 [I-D.ietf-spring-sr-service-programming], thanks to the use of 403 multiple SIDs in the SID list (instead of a direct connectivity in 404 between UPFs with no intermediate waypoints as in Traditional Mode). 406 Thus, the main difference is that the SR policy MAY include SIDs for 407 traffic engineering and service programming in addition to the 408 anchoring SIDs at UPFs. 410 Additionally in this mode the operator may choose to aggregate 411 several devices under the same SID list (e.g., stationary residential 412 meters connected to the same cell) to improve scalability. 414 The gNB control-plane (N2 interface) is unchanged, specifically a 415 single IPv6 address is provided to the gNB. 417 The gNB MAY resolve the IP address received via the control plane 418 into a SID list using a mechanism like PCEP, DNS-lookup, LISP 419 control-plane or others. The resolution mechanism is out of the 420 scope of this document. 422 Note that the SIDs MAY use the arguments Args.Mob.Session if required 423 by the UPFs. 425 Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 426 gNB and the UPF are SR-aware. The Figure shows two service segments, 427 S1 and C1. S1 represents a VNF in the network, and C1 represents an 428 intermediate router used for Traffic Engineering purposes to enforce 429 a low-latency path in the network. Note that both S1 and C1 are not 430 required to have an N4 interface. 432 +----+ SRv6 _______ 433 SRv6 --| C1 |--[N3] / \ 434 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 435 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 436 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 437 SRv6 node \ +----+ / SRv6 node 438 -| S1 |- 439 +----+ 440 SRv6 node 441 VNF 443 Figure 3: Enhanced mode - Example topology 445 5.2.1. Packet flow - Uplink 447 The uplink packet flow is as follows: 449 UE_out : (A,Z) 450 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)->H.Encaps.Red 451 S1_out : (gNB, C1)(U2::1, C1; SL=1)(A,Z) 452 C1_out : (gNB, U2::1)(A,Z) ->End with PSP 453 UPF2_out: (A,Z) ->End.DT4,End.DT6,End.DT2U 455 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 456 control plane associates that session from the UE(A) with the IPv6 457 address B. gNB's control plane does a lookup on B to find the 458 related SID list . 460 When gNB transmits the packet, it contains all the segments of the SR 461 policy. The SR policy includes segments for traffic engineering (C1) 462 and for service programming (S1). 464 Nodes S1 and C1 perform their related Endpoint functionality and 465 forward the packet. 467 When the packet arrives at UPF2, the active segment (U2::1) is an 468 End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing 469 the IPv6 header with all its extension headers) and forwards toward 470 the data network. 472 5.2.2. Packet flow - Downlink 474 The downlink packet flow is as follows: 476 UPF2_in : (Z,A) ->UPF2 maps the flow w/ 477 SID list 478 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) ->H.Encaps.Red 479 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 480 S1_out : (U2::1, gNB)(Z,A) ->End with PSP 481 gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 483 When the packet arrives at the UPF2, the UPF2 maps that particular 484 flow into a UE PDU Session. This UE PDU Session is associated with 485 the policy . The UPF2 performs a H.Encaps.Red 486 operation, encapsulating the packet into a new IPv6 header with its 487 corresponding SRH. 489 The nodes C1 and S1 perform their related Endpoint processing. 491 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 492 End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the 493 underlying traffic). The gNB decapsulates the packet, removing the 494 IPv6 header and forwards the traffic toward the UE. 496 5.3. Enhanced mode with unchanged gNB GTP behavior 498 This section describes three mechanisms for interworking with legacy 499 gNBs that still use GTP: one for IPv4, and two other for IPv6. 501 In the interworking scenarios as illustrated in Figure 4, the gNB 502 does not support SRv6. The gNB supports GTP encapsulation over IPv4 503 or IPv6. To achieve interworking, a SR Gateway (SRGW-UPF1) entity is 504 added. The SRGW maps the GTP traffic into SRv6. 506 The SRGW is not an anchor point and maintains very little state. For 507 this reason, both IPv4 and IPv6 methods scale to millions of UEs. 509 _______ 510 IP GTP SRv6 / \ 511 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 512 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 513 +--+ +-----+ +------+ +------+ \_______/ 514 SR Gateway SRv6 node 516 Figure 4: Example topology for interworking 518 Both of the mechanisms described in this section are applicable to 519 either the Traditional Mode or the Enhanced Mode. 521 5.3.1. Interworking with IPv6 GTP 523 In this interworking mode the gNB at the N3 interface uses GTP over 524 IPv6. 526 Key points: 528 o The gNB is unchanged (control-plane or user-plane) and 529 encapsulates into GTP (N3 interface is not modified). 530 o The 5G Control-Plane (N2 interface) is unmodified; one IPv6 531 address is needed (i.e. a BSID at the SRGW). 532 o The SRGW removes GTP, finds the SID list related to the IPv6 DA, 533 and adds SRH with the SID list. 534 o There is no state for the downlink at the SRGW. 535 o There is simple state in the uplink at the SRGW; using Enhanced 536 mode results in fewer SR policies on this node. An SR policy is 537 shared across UEs. 538 o When a packet from the UE leaves the gNB, it is SR-routed. This 539 simplifies network slicing [I-D.ietf-lsr-flex-algo]. 540 o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic 541 into an SR policy when it arrives at the SRGW-UPF1. 543 An example topology is shown in Figure 5. 545 S1 and C1 are two service segments. S1 represents a VNF in the 546 network, and C1 represents a router configured for Traffic 547 Engineering. 549 +----+ 550 IPv6/GTP -| S1 |- ___ 551 +--+ +-----+ [N3] / +----+ \ / 552 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 553 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 554 GTP \ +------+ / +----+ +------+ \___ 555 -| UPF1 |- SRv6 SRv6 556 +------+ TE 557 SR Gateway 559 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 561 5.3.1.1. Packet flow - Uplink 563 The uplink packet flow is as follows: 565 UE_out : (A,Z) 566 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 567 (IPv6/GTP) 568 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 569 SID at the SRGW 570 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 571 C1_out : (SRGW, U2::1)(A,Z) -> End with PSP 572 UPF2_out: (A,Z) -> End.DT4 or End.DT6 574 The UE sends a packet destined to Z toward the gNB on a specific 575 bearer for that session. The gNB, which is unmodified, encapsulates 576 the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the 577 GTP TEID T are the ones received in the N2 interface. 579 The IPv6 address that was signaled over the N2 interface for that UE 580 PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 581 SRGW. Hence the packet is routed to the SRGW. 583 When the packet arrives at the SRGW, the SRGW identifies B as an 584 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 585 the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own 586 SRH containing the SIDs bound to the SR policy associated with this 587 BindingSID. There is one instance of the End.M.GTP6.D SID per PDU 588 type. 590 S1 and C1 perform their related Endpoint functionality and forward 591 the packet. 593 When the packet arrives at UPF2, the active segment is (U2::1) which 594 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 595 IPv6 header with all its extension headers) and forwards the packet 596 toward the data network. 598 5.3.1.2. Packet flow - Downlink 600 The downlink packet flow is as follows: 602 UPF2_in : (Z,A) -> UPF2 maps the flow with 603 604 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red 605 C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) 606 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 607 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 608 gNB_out : (Z,A) 610 When a packet destined to A arrives at the UPF2, the UPF2 performs a 611 lookup in the table associated to A and finds the SID list . The UPF2 performs an H.Encaps.Red operation, 613 encapsulating the packet into a new IPv6 header with its 614 corresponding SRH. 616 C1 and S1 perform their related Endpoint processing. 618 Once the packet arrives at the SRGW, the SRGW identifies the active 619 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 620 and all its extensions headers. The SRGW generates new IPv6, UDP and 621 GTP headers. The new IPv6 DA is the gNB which is the last SID in the 622 received SRH. The TEID in the generated GTP header is an argument of 623 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 624 packet and forwards the packet toward the gNB. There is one instance 625 of the End.M.GTP6.E SID per PDU type. 627 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 628 packet. The gNB looks for the specific radio bearer for that TEID 629 and forward it on the bearer. This gNB behavior is not modified from 630 current and previous generations. 632 5.3.1.3. Scalability 634 For the downlink traffic, the SRGW is stateless. All the state is in 635 the SRH inserted by the UPF2. The UPF2 must have the UE states since 636 it is the UE's session anchor point. 638 For the uplink traffic, the state at the SRGW does not necessarily 639 need to be unique per PDU Session; the SR policy can be shared among 640 UEs. This enables more scalable SRGW deployments compared to a 641 solution holding millions of states, one or more per UE. 643 5.3.2. Interworking with IPv4 GTP 645 In this interworking mode the gNB uses GTP over IPv4 in the N3 646 interface 648 Key points: 650 o The gNB is unchanged and encapsulates packets into GTP (the N3 651 interface is not modified). 652 o In the uplink, traffic is classified by SRGW's Uplink Classifier 653 and steered into an SR policy. The SRGW is a UPF1 functionality 654 and can coexist with UPF1's Uplink Classifier functionality. 655 o SRGW removes GTP, finds the SID list related to DA, and adds a SRH 656 with the SID list. 658 An example topology is shown in Figure 6. In this mode the gNB is an 659 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 660 the SRGW maps the IPv4/GTP traffic to SRv6. 662 S1 and C1 are two service segment endpoints. S1 represents a VNF in 663 the network, and C1 represents a router configured for Traffic 664 Engineering. 666 +----+ 667 IPv4/GTP -| S1 |- ___ 668 +--+ +-----+ [N3] / +----+ \ / 669 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 670 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 671 GTP \ +------+ / +----+ +------+ \___ 672 -| UPF1 |- SRv6 SRv6 673 +------+ TE 674 SR Gateway 676 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 678 5.3.2.1. Packet flow - Uplink 680 The uplink packet flow is as follows: 682 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 683 unchanged IPv4/GTP 684 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function 685 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 686 C1_out : (SRGW, U2::1) (A,Z) -> PSP 687 UPF2_out: (A,Z) -> End.DT4 or End.DT6 689 The UE sends a packet destined to Z toward the gNB on a specific 690 bearer for that session. The gNB, which is unmodified, encapsulates 691 the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and 692 the GTP TEID are the ones received at the N2 interface. 694 When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink 695 Classifier rule for incoming traffic from the gNB, that steers the 696 traffic into an SR policy by using the function H.M.GTP4.D. The SRGW 697 removes the IPv4, UDP and GTP headers and pushes an IPv6 header with 698 its own SRH containing the SIDs related to the SR policy associated 699 with this traffic. The SRGW forwards according to the new IPv6 DA. 701 S1 and C1 perform their related Endpoint functionality and forward 702 the packet. 704 When the packet arrives at UPF2, the active segment is (U2::1) which 705 is bound to End.DT4/6 which performs the decapsulation (removing the 706 outer IPv6 header with all its extension headers) and forwards toward 707 the data network. 709 5.3.2.2. Packet flow - Downlink 711 The downlink packet flow is as follows: 713 UPF2_in : (Z,A) -> UPF2 maps flow with SID 714 715 UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red 716 C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) 717 S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) 718 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 719 gNB_out : (Z,A) 721 When a packet destined to A arrives at the UPF2, the UPF2 performs a 722 lookup in the table associated to A and finds the SID list . The UPF2 performs a H.Encaps.Red operation, 724 encapsulating the packet into a new IPv6 header with its 725 corresponding SRH. 727 The nodes C1 and S1 perform their related Endpoint processing. 729 Once the packet arrives at the SRGW, the SRGW identifies the active 730 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 731 and all its extensions headers. The SRGW generates an IPv4, UDP and 732 GTP headers. The IPv4 SA and DA are received as SID arguments. The 733 TEID in the generated GTP header is also the arguments of the 734 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 735 and forwards the packet toward the gNB. 737 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 738 packet. The gNB looks for the specific radio bearer for that TEID 739 and forward it on the bearer. This gNB behavior is not modified from 740 current and previous generations. 742 5.3.2.3. Scalability 744 For the downlink traffic, the SRGW is stateless. All the state is in 745 the SRH inserted by the UPF. The UPF must have this UE-base state 746 anyway (since it is its anchor point). 748 For the uplink traffic, the state at the SRGW is dedicated on a per 749 UE/session basis according to an Uplink Classifier. There is state 750 for steering the different sessions in the form of a SR Policy. 751 However, SR policies are shared among several UE/sessions. 753 5.3.3. Extensions to the interworking mechanisms 755 In this section we presented three mechanisms for interworking with 756 gNBs and UPFs that do not support SRv6. These mechanisms are used to 757 support GTP over IPv4 and IPv6. 759 Even though we have presented these methods as an extension to the 760 "Enhanced mode", it is straightforward in its applicability to the 761 "Traditional mode". 763 Furthermore, although these mechanisms are designed for interworking 764 with legacy RAN at the N3 interface, these methods could also be 765 applied for interworking with a non-SRv6 capable UPF at the N9 766 interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). 768 5.4. SRv6 Drop-in Interworking 770 In this section we introduce another mode useful for legacy gNB and 771 UPFs that still operate with GTP-U. This mode provides an 772 SRv6-enabled user plane in between two GTP-U tunnel endpoints. 774 In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and 775 vice-versa. 777 Unlike other interworking modes, in this mode both of the mobility 778 overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or 779 N9 interface to realize an intermediate SR policy. 781 +----+ 782 -| S1 |- 783 +-----+ / +----+ \ 784 | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ 785 +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | 786 GTP[N3]\ +--------+ / +----+ +--------+ +-----+ 787 -| SRGW-A |- SRv6 SR Gateway-B GTP 788 +--------+ TE 789 SR Gateway-A 791 Figure 7: Example topology for SRv6 Drop-in mode 793 The packet flow of Figure 7 is as follows: 795 gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) 796 GW-A_out: (SRGW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an 797 End.M.GTP6.D.Di 798 SID at SRGW-A 799 S1_out : (SRGW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) 800 C1_out : (SRGW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) 801 GW-B_out: (SRGW-B, U::1)(GTP: TEID T)(A,Z) ->U1b::TEID is an 802 End.M.GTP6.E 803 SID at SRGW-B 804 UPF_out : (A,Z) 806 When a packet destined to Z to the gNB, which is unmodified, it 807 performs encapsulation into a new IP, UDP and GTP headers. The IPv6 808 DA, U::1, and the GTP TEID are the ones received at the N2 interface. 810 The IPv6 address that was signaled over the N2 interface for that PDU 811 Session, U::1, is now the IPv6 DA. U2b:: is an SRv6 Binding SID at 812 SRGW-A. Hence the packet is routed to the SRGW. 814 When the packet arrives at SRGW-A, the SRGW identifies U2b:: as an 815 End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW 816 removes the IPv6, UDP and GTP headers, and pushes an IPv6 header with 817 its own SRH containing the SIDs bound to the SR policy associated 818 with this Binding SID. There is one instance of the End.M.GTP6.D.Di 819 SID per PDU type. 821 S1 and C1 perform their related Endpoint functionality and forward 822 the packet. 824 Once the packet arrives at SRGW-B, the SRGW identifies the active SID 825 as an End.M.GTP6.E function. The SRGW removes the IPv6 header and 826 all its extensions headers. The SRGW generates new IPv6, UDP and GTP 827 headers. The new IPv6 DA is U::1 which is the last SID in the 828 received SRH. The TEID in the generated GTP header is an argument of 829 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 830 packet and forwards the packet toward UPF2b. There is one instance 831 of the End.M.GTP6.E SID per PDU type. 833 Once the packet arrives at UPF2b, the packet is a regular IPv6/GTP 834 packet. The UPF looks for the specific rule for that TEID to forward 835 the packet. This UPF behavior is not modified from current and 836 previous generations. 838 6. SRv6 Segment Endpoint Mobility Behaviors 839 6.1. Args.Mob.Session 841 Args.Mob.Session provide per-session information for charging, 842 buffering and lawful intercept (among others) required by some mobile 843 nodes. The Args.Mob.Session argument format is used in combination 844 with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 845 behaviors. Note that proposed format is applicable for 5G networks, 846 while similar formats could be used for legacy networks. 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | QFI |R|U| PDU Session ID | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 |PDU Sess(cont')| 854 +-+-+-+-+-+-+-+-+ 856 Args.Mob.Session format 858 o QFI: QoS Flow Identifier [TS.38415] 859 o R: Reflective QoS Indication [TS.23501]. This parameter indicates 860 the activation of reflective QoS towards the UE for the 861 transferred packet. Reflective QoS enables the UE to map UL User 862 Plane traffic to QoS Flows without SMF provided QoS rules. 863 o U: Unused and for future use. MUST be 0 on transmission and 864 ignored on receipt. 865 o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 866 is TEID. 868 Arg.Mob.Session is required in case that one SID aggregates multiple 869 PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated 870 per PDU session, Args.Mob.Session helps the UPF to perform the 871 behaviors which require per QFI and/or per PDU Session granularity. 873 6.2. End.MAP 875 The "Endpoint behavior with SID mapping" behavior (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 N receives a packet whose IPv6 DA is S and S is a local End.MAP 880 SID, N does: 882 S01. If (IPv6 Hop Limit <= 1) { 883 S02. Send an ICMP Time Exceeded message to the Source Address, 884 Code 0 (Hop limit exceeded in transit), 885 interrupt packet processing and discard the packet. 886 S03. } 887 S04. Decrement IPv6 Hop Limit by 1 888 S05. Lookup the IPv6 DA in the mapping table 889 S06. Update the IPv6 DA with the new mapped SID 890 S07. Submit the packet to the egress IPv6 FIB lookup for 891 transmission to the new destination 893 Notes: 894 The SIDs in the SRH are not modified. 896 6.3. End.M.GTP6.D 898 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy" 899 behavior (End.M.GTP6.D for short) is used in interworking scenario 900 for the uplink toward from the legacy gNB using IPv6/GTP. Suppose, 901 for example, this SID is associated with an SR policy B and an IPv6 902 Source Address A. 904 When the SR Gateway node N receives a packet destined to S and S is a 905 local End.M.GTP6.D SID, N does: 907 S01. When an SRH is processed { 908 S02. If (Segments Left != 0) { 909 S03. Send an ICMP Parameter Problem to the Source Address, 910 Code 0 (Erroneous header field encountered), 911 Pointer set to the Segments Left field, 912 interrupt packet processing and discard the packet. 913 S04. } 914 S05. Proceed to process the next header in the packet 915 S06. } 917 When processing the Upper-layer header of a packet matching a FIB 918 entry locally instantiated as an End.M.GTP6.D SID, N does: 920 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 921 S02. Copy the GTP TEID to buffer memory 922 S03. Pop the IPv6, UDP and GTP Headers 923 S04. Push a new IPv6 header with its own SRH containing B 924 S05. Set the outer IPv6 SA to A 925 S06. Set the outer IPv6 DA to the first SID of B 926 S07. Set the outer Payload Length, Traffic Class, Flow Label, 927 Hop Limit and Next-Header fields 928 S08. Write in the last SID of the SRH the Args.Mob.Session 929 based on the information of buffer memory 930 S09. Submit the packet to the egress IPv6 FIB lookup and 931 transmission to the new destination 932 S10. } Else { 933 S11. Process as per [NET-PGM] Section 4.1.1 934 S12. } 936 Notes: 937 The NH is set based on the SID parameter. There is one instantiation 938 of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already 939 known in advance. For the IPv4v6 PDU Session Type, in addition we 940 inspect the first nibble of the PDU to know the NH value. 942 The prefix of last segment (S3 in above example) SHOULD be followed 943 by an Arg.Mob.Session argument space which is used to provide the 944 session identifiers. 946 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 947 gateway. 949 6.4. End.M.GTP6.D.Di 951 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for 952 Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6 953 drop-in interworking scenario described in Section 5.4. The 954 difference between End.M.GTP6.D as another variant of IPv6/GTP 955 decapsulation function is that the original IPv6 DA of GTP packet is 956 preserved as the last SID in SRH. 958 Any SID instance of this behavior is associated with an SR Policy B 959 and an IPv6 Source Address A. 961 When the SR Gateway node N receives a packet destined to S and S is a 962 local End.M.GTP6.D.Di SID, N does: 964 S01. When an SRH is processed { 965 S02. If (Segments Left != 0) { 966 S03. Send an ICMP Parameter Problem to the Source Address, 967 Code 0 (Erroneous header field encountered), 968 Pointer set to the Segments Left field, 969 interrupt packet processing and discard the packet. 970 S04. } 971 S05. Proceed to process the next header in the packet 972 S06. } 974 When processing the Upper-layer header of a packet matching a FIB 975 entry locally instantiated as an End.M.GTP6.Di SID, N does: 977 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 978 S02. Copy S to buffer memory 979 S03. Pop the IPv6, UDP and GTP Headers 980 S04. Push a new IPv6 header with its own SRH containing B 981 S05. Set the outer IPv6 SA to A 982 S06. Set the outer IPv6 DA to the first SID of B 983 S07. Set the outer Payload Length, Traffic Class, Flow Label, 984 Hop Limit and Next-Header fields 985 S08. Write S to the SRH 986 S09. Submit the packet to the egress IPv6 FIB lookup and 987 transmission to the new destination 988 S10. } Else { 989 S11. Process as per [NET-PGM] Section 4.1.1 990 S12. } 992 Notes: 993 The NH is set based on the SID parameter. There is one instantiation 994 of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already 995 known in advance. For the IPv4v6 PDU Session Type, in addition we 996 inspect the first nibble of the PDU to know the NH value. 998 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 999 gateway. 1001 6.5. End.M.GTP6.E 1003 The "Endpoint behavior with encapsulation for IPv6/GTP tunnel" 1004 behavior (End.M.GTP6.E for short) is used in interworking scenario 1005 for the downlink toward the legacy gNB using IPv6/GTP. 1007 The prefix of End.M.GTP6.E SID MUST be followed by the 1008 Arg.Mob.Session argument space which is used to provide the session 1009 identifiers. 1011 When the SR Gateway node N receives a packet destined to S, and S is 1012 a local End.M.GTP6.E SID, N does the following: 1014 S01. When an SRH is processed { 1015 S02. If (Segments Left != 1) { 1016 S03. Send an ICMP Parameter Problem to the Source Address, 1017 Code 0 (Erroneous header field encountered), 1018 Pointer set to the Segments Left field, 1019 interrupt packet processing and discard the packet. 1020 S04. } 1021 S05. Proceed to process the next header in the packet 1022 S06. } 1024 When processing the Upper-layer header of a packet matching a FIB 1025 entry locally instantiated as an End.M.GTP6.E SID, N does: 1027 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1028 S02. Copy SRH[0] to buffer memory 1029 S03. Pop the IPv6 header and all its extension headers 1030 S04. Push a new IPv6 header with a UDP/GTP Header 1031 S05. Set the outer IPv6 SA to A 1032 S06. Set the outer IPv6 DA to the first SID of B 1033 S07. Set the outer Payload Length, Traffic Class, Flow Label, 1034 Hop Limit and Next-Header fields 1035 S08. Set the GTP TEID (from buffer memory) 1036 S09. Submit the packet to the egress IPv6 FIB lookup and 1037 transmission to the new destination 1038 S10. } Else { 1039 S11. Process as per [NET-PGM] Section 4.1.1 1040 S12. } 1042 Notes: 1043 An End.M.GTP6.E SID MUST always be the penultimate SID. 1044 The TEID is extracted from the argument space of the current SID. 1046 The source address A SHOULD be an End.M.GTP6.D SID instantiated at an 1047 SR gateway. 1049 6.6. End.M.GTP4.E 1051 The "Endpoint behavior with encapsulation for IPv4/GTP tunnel" 1052 behavior (End.M.GTP4.E for short) is used in the downlink when doing 1053 interworking with legacy gNB using IPv4/GTP. 1055 When the SR Gateway node N receives a packet destined to S and S is a 1056 local End.M.GTP4.E SID, N does: 1058 S01. When an SRH is processed { 1059 S02. If (Segments Left != 0) { 1060 S03. Send an ICMP Parameter Problem to the Source Address, 1061 Code 0 (Erroneous header field encountered), 1062 Pointer set to the Segments Left field, 1063 interrupt packet processing and discard the packet. 1064 S04. } 1065 S05. Proceed to process the next header in the packet 1066 S06. } 1068 When processing the Upper-layer header of a packet matching a FIB 1069 entry locally instantiated as an End.M.GTP4.E SID, N does: 1071 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1072 S02. Sotre the IPv6 DA and SA in buffer memory 1073 S03. Pop the IPv6 header and all its extension headers 1074 S04. Push a new IPv4 header with a UDP/GTP Header 1075 S05. Set the outer IPv4 SA and DA (from buffer memory) 1076 S06. Set the outer Total Length, DSCP, Time To Live and 1077 Next-Header fields 1078 S07. Set the GTP TEID (from buffer memory) 1079 S08. Submit the packet to the egress IPv6 FIB lookup and 1080 transmission to the new destination 1081 S09. } Else { 1082 S10. Process as per [NET-PGM] Section 4.1.1 1083 S11. } 1085 Notes: 1086 The End.M.GTP4.E SID in S has the following format: 1088 0 127 1089 +-----------------------+-------+----------------+---------+ 1090 | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | 1091 +-----------------------+-------+----------------+---------+ 1092 128-a-b-c a b c 1094 End.M.GTP4.E SID Encoding 1096 S' has the following format: 1098 0 127 1099 +----------------------+--------+--------------------------+ 1100 | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | 1101 +----------------------+--------+--------------------------+ 1102 128-a-b a b 1104 IPv6 SA Encoding for End.M.GTP4.E 1106 6.7. H.M.GTP4.D 1108 The "SR Policy Headend with tunnel decapsulation and map to an SRv6 1109 policy" behavior (H.M.GTP4.D for short) is used in the direction from 1110 legacy IPv4 user-plane to SRv6 user-plane network. 1112 When the SR Gateway node N receives a packet destined to a IW- 1113 IPv4-Prefix, N does: 1115 S01. IF Payload == UDP/GTP THEN 1116 S02. Pop the outer IPv4 header and UDP/GTP headers 1117 S03. Copy IPv4 DA, TEID to form SID B 1118 S04. Copy IPv4 SA to form IPv6 SA B' 1119 S05. Encapsulate the packet into a new IPv6 header ;;Ref1 1120 S06. Set the IPv6 DA = B 1121 S07. Forward along the shortest path to B 1122 S08. ELSE 1123 S09. Drop the packet 1125 Ref1: The NH value is identified by inspecting the first nibble of 1126 the inner payload. 1128 The SID B has the following format: 1130 0 127 1131 +-----------------------+-------+----------------+---------+ 1132 |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | 1133 +-----------------------+-------+----------------+---------+ 1134 128-a-b-c a b c 1136 H.M.GTP4.D SID Encoding 1138 The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 1139 (U1) to bind a SR policy [I-D.ietf-spring-segment-routing-policy]. 1141 The prefix of B' SHOULD be an End.M.GTP4.E SID with its format 1142 instantiated at an SR gateway with the IPv4 SA of the receiving 1143 packet. 1145 6.8. End.Limit: Rate Limiting behavior 1147 The mobile user-plane requires a rate-limit feature. For this 1148 purpose, we define a new behavior "End.Limit". The "End.Limit" 1149 behavior encodes in its arguments the rate limiting parameter that 1150 should be applied to this packet. Multiple flows of packets should 1151 have the same group identifier in the SID when those flows are in an 1152 same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of 1153 the rate limit segment SID is as follows: 1155 +----------------------+----------+-----------+ 1156 | LOC+FUNC rate-limit | group-id | limit-rate| 1157 +----------------------+----------+-----------+ 1158 128-i-j i j 1160 End.Limit: Rate limiting behavior argument format 1162 If the limit-rate bits are set to zero, the node should not do rate 1163 limiting unless static configuration or control-plane sets the limit 1164 rate associated to the SID. 1166 7. SRv6 supported 3GPP PDU session types 1168 The 3GPP [TS.23501] defines the following PDU session types: 1170 o IPv4 1171 o IPv6 1172 o IPv4v6 1173 o Ethernet 1174 o Unstructured 1176 SRv6 supports the 3GPP PDU session types without any protocol 1177 overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4 1178 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 1179 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU 1180 sessions). 1182 8. Network Slicing Considerations 1184 A mobile network may be required to implement "network slices", which 1185 logically separate network resources. User-plane behaviors 1186 represented as SRv6 segments would be part of a slice. 1188 [I-D.ietf-spring-segment-routing-policy] describes a solution to 1189 build basic network slices with SR. Depending on the requirements, 1190 these slices can be further refined by adopting the mechanisms from: 1192 o IGP Flex-Algo [I-D.ietf-lsr-flex-algo] 1193 o Inter-Domain policies 1194 [I-D.ietf-spring-segment-routing-central-epe] 1196 Furthermore, these can be combined with ODN/AS 1197 [I-D.ietf-spring-segment-routing-policy] for automated slice 1198 provisioning and traffic steering. 1200 Further details on how these tools can be used to create end to end 1201 network slices are documented in 1202 [I-D.ali-spring-network-slicing-building-blocks]. 1204 9. Control Plane Considerations 1206 This document focuses on user-plane behavior and its independence 1207 from the control plane. 1209 The control plane could be the current 3GPP-defined control plane 1210 with slight modifications to the N4 interface [TS.29244]. 1212 Alternatively, SRv6 could be used in conjunction with a new mobility 1213 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 1214 hICN [I-D.auge-dmm-hicn-mobility-deployment-options] or in 1215 conjunction with FPC [I-D.ietf-dmm-fpc-cpdp]. The analysis of new 1216 mobility control-planes and its applicability to an SRv6 user-plane 1217 is out of the scope of this document. 1219 Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for 1220 the new behaviors defined in this document. 1222 10. Security Considerations 1224 The security considerations for Segment Routing are discussed in 1225 [RFC8402]. More specifically for SRv6 the security considerations 1226 and the mechanisms for securing an SR domain are discussed in 1227 [RFC8754]. Together, they describe the required security mechanisms 1228 that allow establishment of an SR domain of trust to operate 1229 SRv6-based services for internal traffic while preventing any 1230 external traffic from accessing or exploiting the SRv6-based 1231 services. 1233 The technology described in this document is applied to a mobile 1234 network that is within the SR Domain. 1236 This document introduces new SRv6 Endpoint Behaviors. Those 1237 behaviors do not need any especial security consideration given that 1238 it is deployed within that SR Domain. 1240 11. IANA Considerations 1242 The following values have been allocated within the "SRv6 Endpoint 1243 Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment 1244 Routing Parameters" registry: 1246 +-------+--------+-------------------+-----------+ 1247 | Value | Hex | Endpoint behavior | Reference | 1248 +-------+--------+-------------------+-----------+ 1249 | 40 | 0x0028 | End.MAP | [This.ID] | 1250 | 41 | 0x0029 | End.Limit | [This.ID] | 1251 | 69 | 0x0045 | End.M.GTP6.D | [This.ID] | 1252 | 70 | 0x0046 | End.M.GTP6.Di | [This.ID] | 1253 | 71 | 0x0047 | End.M.GTP6.E | [This.ID] | 1254 | 72 | 0x0048 | End.M.GTP4.E | [This.ID] | 1255 +-------+--------+-------------------+-----------+ 1257 Table 1: SRv6 Mobile User-plane Endpoint Behavior Types 1259 12. Acknowledgements 1261 The authors would like to thank Daisuke Yokota, Bart Peirens, 1262 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1263 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1264 Shekhar, Aeneas Dodd-Noble and Carlos Jesus Bernardos for their 1265 useful comments of this work. 1267 13. Contributors 1269 Kentaro Ebisawa 1270 Toyota Motor Corporation 1271 Japan 1273 Email: ebisawa@toyota-tokyo.tech 1275 Tetsuya Murakami 1276 Arrcus, Inc. 1277 United States of America 1279 Email: tetsuya.ietf@gmail.com 1281 14. References 1283 14.1. Normative References 1285 [I-D.ietf-spring-segment-routing-policy] 1286 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1287 P. Mattes, "Segment Routing Policy Architecture", draft- 1288 ietf-spring-segment-routing-policy-09 (work in progress), 1289 November 2020. 1291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1292 Requirement Levels", BCP 14, RFC 2119, 1293 DOI 10.17487/RFC2119, March 1997, 1294 . 1296 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1297 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1298 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1299 July 2018, . 1301 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1302 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1303 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1304 . 1306 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1307 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1308 (SRv6) Network Programming", RFC 8986, 1309 DOI 10.17487/RFC8986, February 2021, 1310 . 1312 [TS.23501] 1313 3GPP, "System Architecture for the 5G System", 3GPP TS 1314 23.501 15.0.0, November 2017. 1316 14.2. Informative References 1318 [I-D.ali-spring-network-slicing-building-blocks] 1319 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 1320 "Building blocks for Slicing in Segment Routing Network", 1321 draft-ali-spring-network-slicing-building-blocks-03 (work 1322 in progress), November 2020. 1324 [I-D.auge-dmm-hicn-mobility-deployment-options] 1325 Auge, J., Carofiglio, G., Muscariello, L., and M. 1326 Papalini, "Anchorless mobility management through hICN 1327 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1328 mobility-deployment-options-04 (work in progress), July 1329 2020. 1331 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1332 Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S., 1333 Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- 1334 Cases", draft-camarilloelmalky-springdmm-srv6-mob- 1335 usecases-02 (work in progress), August 2019. 1337 [I-D.ietf-dmm-fpc-cpdp] 1338 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1339 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1340 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-14 1341 (work in progress), September 2020. 1343 [I-D.ietf-lsr-flex-algo] 1344 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1345 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1346 algo-13 (work in progress), October 2020. 1348 [I-D.ietf-spring-segment-routing-central-epe] 1349 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1350 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1351 Engineering", draft-ietf-spring-segment-routing-central- 1352 epe-10 (work in progress), December 2017. 1354 [I-D.ietf-spring-sr-service-programming] 1355 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1356 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1357 Henderickx, W., and S. Salsano, "Service Programming with 1358 Segment Routing", draft-ietf-spring-sr-service- 1359 programming-03 (work in progress), September 2020. 1361 [I-D.matsushima-spring-srv6-deployment-status] 1362 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 1363 Rajaraman, "SRv6 Implementation and Deployment Status", 1364 draft-matsushima-spring-srv6-deployment-status-10 (work in 1365 progress), December 2020. 1367 [I-D.rodrigueznatal-lisp-srv6] 1368 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1369 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1370 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-04 1371 (work in progress), July 2020. 1373 [TS.29244] 1374 3GPP, "Interface between the Control Plane and the User 1375 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1377 [TS.29281] 1378 3GPP, "General Packet Radio System (GPRS) Tunnelling 1379 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1380 December 2017. 1382 [TS.38415] 1383 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1384 3GPP R3-174510 0.0.0, August 2017. 1386 Appendix A. Implementations 1388 This document introduces new SRv6 Endpoint Behaviors. These 1389 behaviors have an open-source P4 implementation available in 1390 . 1392 Additionally, a full implementation of this document is available in 1393 Linux Foundation FD.io VPP project since release 20.05. More 1394 information available here: . 1397 There are also experimental implementations in M-CORD NGIC and Open 1398 Air Interface (OAI). 1400 Authors' Addresses 1402 Satoru Matsushima (editor) 1403 SoftBank 1404 Japan 1406 Email: satoru.matsushima@g.softbank.co.jp 1408 Clarence Filsfils 1409 Cisco Systems, Inc. 1410 Belgium 1412 Email: cf@cisco.com 1414 Miya Kohno 1415 Cisco Systems, Inc. 1416 Japan 1418 Email: mkohno@cisco.com 1419 Pablo Camarillo Garvia (editor) 1420 Cisco Systems, Inc. 1421 Spain 1423 Email: pcamaril@cisco.com 1425 Daniel Voyer 1426 Bell Canada 1427 Canada 1429 Email: daniel.voyer@bell.ca 1431 Charles E. Perkins 1432 Futurewei Inc. 1433 2330 Central Expressway 1434 Santa Clara, CA 95050 1435 USA 1437 Phone: +1-408-330-4586 1438 Email: charliep@computer.org