idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-21.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 (9 May 2022) is 717 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 174, 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 711, but not defined == Missing Reference: 'N9' is mentioned on line 543, but not defined == Missing Reference: 'N6' is mentioned on line 712, but not defined -- Looks like a reference, but probably isn't: '0' on line 1071 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-19 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-05 == Outdated reference: A later version (-07) exists of draft-kohno-dmm-srv6mob-arch-05 == Outdated reference: A later version (-06) exists of draft-mhkk-dmm-srv6mup-architecture-03 Summary: 0 errors (**), 0 flaws (~~), 12 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: 10 November 2022 M. Kohno 6 P. Camarillo, Ed. 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C.E. Perkins 11 Lupin Lodge 12 9 May 2022 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-21 17 Abstract 19 This document specifies the applicability of SRv6 (Segment Routing 20 IPv6) to the user-plane of mobile networks. The network programming 21 nature of SRv6 accomplishes mobile user-plane functions in a simple 22 manner. The statelessness of SRv6 and its ability to control both 23 service layer path and underlying transport can be beneficial to the 24 mobile user-plane, providing flexibility, end-to-end network slicing, 25 and SLA control for various applications. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 10 November 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Predefined SRv6 Endpoint Behaviors . . . . . . . . . . . 4 65 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 5 67 5. User-plane modes . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7 69 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 70 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9 71 5.2. Enhanced mode . . . . . . . . . . . . . . . . . . . . . . 9 72 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 73 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11 74 5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 12 75 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 12 76 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 77 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15 78 5.3.3. Extensions to the interworking mechanisms . . . . . . 18 79 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 18 80 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19 81 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 20 82 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 21 84 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 22 85 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 23 86 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 24 87 6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25 88 6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26 89 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 27 90 8. Network Slicing Considerations . . . . . . . . . . . . . . . 27 91 9. Control Plane Considerations . . . . . . . . . . . . . . . . 27 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 95 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 29 98 14.2. Informative References . . . . . . . . . . . . . . . . . 30 99 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 32 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 102 1. Introduction 104 In mobile networks, mobility systems provide connectivity over a 105 wireless link to stationary and non-stationary nodes. The user-plane 106 establishes a tunnel between the mobile node and its anchor node over 107 IP-based backhaul and core networks. 109 This document specifies the applicability of SRv6 (Segment Routing 110 IPv6) to mobile networks. 112 Segment Routing [RFC8402] is a source routing architecture: a node 113 steers a packet through an ordered list of instructions called 114 "segments". A segment can represent any instruction, topological or 115 service based. 117 SRv6 applied to mobile networks enables a source-routing based mobile 118 architecture, where operators can explicitly indicate a route for the 119 packets to and from the mobile node. The SRv6 Endpoint nodes serve 120 as mobile user-plane anchors. 122 2. Conventions and Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2.1. Terminology 130 * CNF: Cloud-native Network Function 131 * NFV: Network Function Virtualization 132 * PDU: Packet Data Unit 133 * PDU Session: Context of a UE connects to a mobile network. 134 * UE: User Equipment 135 * UPF: User Plane Function 136 * VNF: Virtual Network Function (including CNFs) 138 The following terms used within this document are defined in 139 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 140 SID, Active Segment, SR Policy, Prefix SID, Adjacency SID and Binding 141 SID. 143 The following terms used within this document are defined in 144 [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint 145 Node and Reduced SRH. 147 The following terms used within this document are defined in 148 [RFC8986]: NH, SL, FIB, SA, DA, SRv6 SID behavior, SRv6 Segment 149 Endpoint Behavior. 151 2.2. Conventions 153 An SR Policy is resolved to a SID list. A SID list is represented as 154 where S1 is the first SID to visit, S2 is the second SID 155 to visit, and S3 is the last SID to visit along the SR path. 157 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 159 * Source Address is SA, Destination Address is DA, and next-header 160 is SRH 161 * SRH with SID list with Segments Left = SL 162 * Note the difference between the <> and () symbols: 163 represents a SID list where S1 is the first SID and S3 is the last 164 SID to traverse. (S3, S2, S1; SL) represents the same SID list 165 but encoded in the SRH format where the rightmost SID in the SRH 166 is the first SID and the leftmost SID in the SRH is the last SID. 167 When referring to an SR policy in a high-level use-case, it is 168 simpler to use the notation. When referring to an 169 illustration of the detailed packet behavior, the (S3, S2, S1; SL) 170 notation is more convenient. 171 * The payload of the packet is omitted. 173 SRH[n]: A shorter representation of Segment List[n], as defined in 174 [RFC8754]. SRH[SL] can be different from the DA of the IPv6 header. 176 * gNB::1 is an IPv6 address (SID) assigned to the gNB. 177 * U1::1 is an IPv6 address (SID) assigned to UPF1. 178 * U2::1 is an IPv6 address (SID) assigned to UPF2. 179 * U2:: is the Locator of UPF2. 181 2.3. Predefined SRv6 Endpoint Behaviors 183 The following SRv6 Endpoint Behaviors are defined in [RFC8986]. 185 * End.DT4: Decapsulation and Specific IPv4 Table Lookup 186 * End.DT6: Decapsulation and Specific IPv6 Table Lookup 187 * End.DT46: Decapsulation and Specific IP Table Lookup 188 * End.DX4: Decapsulation and IPv4 Cross-Connect 189 * End.DX6: Decapsulation and IPv6 Cross-Connect 190 * End.DX2: Decapsulation and L2 Cross-Connect 191 * End.T: Endpoint with specific IPv6 Table Lookup 193 This document defines new SRv6 Segment Endpoint Behaviors in 194 Section 6. 196 3. Motivation 198 Mobile networks are becoming more challenging to operate. On one 199 hand, traffic is constantly growing, and latency requirements are 200 tighter; on the other-hand, there are new use-cases like distributed 201 NFVi that are also challenging network operations. 203 The current architecture of mobile networks does not take into 204 account the underlying transport. The user-plane is rigidly 205 fragmented into radio access, core and service networks, connected by 206 tunneling according to user-plane roles such as access and anchor 207 nodes. These factors have made it difficult for the operator to 208 optimize and operate the data-path. 210 In the meantime, applications have shifted to use IPv6, and network 211 operators have started adopting IPv6 as their IP transport. SRv6, 212 the IPv6 dataplane instantiation of Segment Routing [RFC8402], 213 integrates both the application data-path and the underlying 214 transport layer into a single protocol, allowing operators to 215 optimize the network in a simplified manner and removing forwarding 216 state from the network. It is also suitable for virtualized 217 environments, like VNF/CNF to VNF/CNF networking. SRv6 has been 218 deployed in dozens of networks 219 [I-D.matsushima-spring-srv6-deployment-status]. 221 SRv6 defines the network-programming concept [RFC8986]. Applied to 222 mobility, SRv6 can provide the user-plane behaviors needed for 223 mobility management. SRv6 takes advantage of the underlying 224 transport awareness and flexibility together with the ability to also 225 include services to optimize the end-to-end mobile dataplane. 227 The use-cases for SRv6 mobility are discussed in 228 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases], and the 229 architetural benefits are discussed in [I-D.kohno-dmm-srv6mob-arch]. 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 * UE: User Endpoint 261 * gNB: gNodeB with N3 interface towards packet core (and N2 for 262 control plane) 263 * UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane) 264 * UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane) 265 * SMF: Session Management Function 266 * AMF: Access and Mobility Management Function 267 * 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 modes 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 286 architecture. In this mode GTP-U protocol [TS.29281] is replaced by 287 SRv6, 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 transparent to 3GPP functionalities. 295 This results in optimal end-to-end policies across the mobile network 296 with transport and services 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 Note that the modes discussed throughout this section (with the 317 exception of Section 5.4) only have informational purpose to 318 implementors as well as operators deploying this technology. Indeed, 319 it is expected that the operator defines his own operational model 320 that best suits their needs. 322 5.1. Traditional mode 324 In the traditional mode, the existing mobile UPFs remain unchanged 325 with the sole exception of the use of SRv6 as the data plane instead 326 of GTP-U. There is no impact to the rest of the mobile system. 328 In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 329 with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored 330 here to replace GTP encapsulation with the SRv6 encapsulation, while 331 not changing anything else. There will be a unique SRv6 SID 332 associated with each PDU Session, and the SID list only contains a 333 single SID. 335 The traditional mode minimizes the changes required to the mobile 336 system; hence it is a good starting point for forming a common 337 ground. 339 The gNB/UPF control-plane (N2/N4 interface) is unchanged, 340 specifically a single IPv6 address is provided to the gNB. The same 341 control plane signalling is used, and the gNB/UPF decides to use SRv6 342 based on signaled GTP-U parameters per local policy. The only 343 information from the GTP-U parameters used for the SRv6 policy is the 344 TEID, QFI, and the IPv6 Destination Address. 346 Our example topology is shown in Figure 2. The gNB and the UPFs are 347 SR-aware. In the descriptions of the uplink and downlink packet 348 flow, A is an IPv6 address of the UE, and Z is an IPv6 address 349 reachable within the Data Network DN. A new SRv6 Endpoint Behavior, 350 End.MAP, defined in Section 6.2, is used. 352 ________ 353 SRv6 SRv6 / \ 354 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 355 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 356 +--+ +-----+ +------+ +------+ \________/ 357 SRv6 node SRv6 node SRv6 node 359 Figure 2: Traditional mode - example topology 361 5.1.1. Packet flow - Uplink 363 The uplink packet flow is as follows: 365 UE_out : (A,Z) 366 gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red 367 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 368 UPF2_out: (A,Z) -> End.DT4 or End.DT6 370 When the UE packet arrives at the gNB, the gNB performs a 371 H.Encaps.Red operation. Since there is only one SID, there is no 372 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 373 U1::1. gNB obtains the SID U1::1 from the existing control plane (N2 374 interface). U1::1 represents an anchoring SID specific for that 375 session at UPF1. 377 When the packet arrives at UPF1, the SID U1::1 is associated with the 378 End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1, 379 that belongs to the next UPF (U2). 381 When the packet arrives at UPF2, the SID U2::1 corresponds to an 382 End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates 383 the packet, performs a lookup in a specific table associated with 384 that mobile network and forwards the packet toward the data network 385 (DN). 387 5.1.2. Packet flow - Downlink 389 The downlink packet flow is as follows: 391 UPF2_in : (Z,A) 392 UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red 393 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 394 gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2 396 When the packet arrives at the UPF2, the UPF2 maps that flow into a 397 PDU Session. This PDU Session is associated with the segment 398 endpoint . UPF2 performs a H.Encaps.Red operation, 399 encapsulating the packet into a new IPv6 header with no SRH since 400 there is only one SID. 402 Upon packet arrival on UPF1, the SID U1::2 is a local SID associated 403 with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next 404 anchoring point and replaces U1::2 by gNB::1, that belongs to the 405 next hop. 407 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4, 408 End.DX6 or End.DX2 behavior (depending on the PDU Session Type). The 409 gNB decapsulates the packet, removing the IPv6 header and all its 410 extensions headers, and forwards the traffic toward the UE. 412 5.2. Enhanced mode 414 Enhanced mode improves scalability, provides traffic engineering 415 capabilities, and allows service programming 416 [I-D.ietf-spring-sr-service-programming], thanks to the use of 417 multiple SIDs in the SID list (instead of a direct connectivity in 418 between UPFs with no intermediate waypoints as in Traditional Mode). 420 Thus, the main difference is that the SR policy MAY include SIDs for 421 traffic engineering and service programming in addition to the 422 anchoring SIDs at UPFs. 424 Additionally in this mode the operator may choose to aggregate 425 several devices under the same SID list (e.g., stationary residential 426 meters connected to the same cell) to improve scalability. 428 The gNB/UPF control-plane (N2/N4 interface) is unchanged, 429 specifically a single IPv6 address is provided to the gNB. A local 430 policy instructs the gNB to use SRv6. 432 The gNB MAY resolve the IP address received via the control plane 433 into a SID list using a mechanism like PCEP, DNS-lookup, LISP 434 control-plane or others. The resolution mechanism is out of the 435 scope of this document. 437 Note that the SIDs MAY use the arguments Args.Mob.Session if required 438 by the UPFs. 440 Figure 3 shows an Enhanced mode topology. The gNB and the UPF are 441 SR-aware. The Figure shows two service segments, S1 and C1. S1 442 represents a VNF in the network, and C1 represents an intermediate 443 router used for Traffic Engineering purposes to enforce a low-latency 444 path in the network. Note that neither S1 nor C1 are required to 445 have an N4 interface. 447 +----+ SRv6 _______ 448 SRv6 --| C1 |--[N3] / \ 449 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 450 |UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN / 451 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 452 SRv6 node \ +----+ / SRv6 node 453 -| S1 |- 454 +----+ 455 SRv6 node 456 VNF 458 Figure 3: Enhanced mode - Example topology 460 5.2.1. Packet flow - Uplink 462 The uplink packet flow is as follows: 464 UE_out : (A,Z) 465 gNB_out : (gNB, S1)(U1::1, C1; SL=2)(A,Z)->H.Encaps.Red 466 S1_out : (gNB, C1)(U1::1, C1; SL=1)(A,Z) 467 C1_out : (gNB, U1::1)(A,Z) ->End with PSP 468 UPF1_out: (A,Z) ->End.DT4,End.DT6,End.DT2U 470 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 471 control plane associates that session from the UE(A) with the IPv6 472 address B. gNB's control plane does a lookup on B to find the 473 related SID list . 475 When gNB transmits the packet, it contains all the segments of the SR 476 policy. The SR policy includes segments for traffic engineering (C1) 477 and for service programming (S1). 479 Nodes S1 and C1 perform their related Endpoint functionality and 480 forward the packet. 482 When the packet arrives at UPF1, the active segment (U1::1) is an 483 End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing 484 the IPv6 header with all its extension headers) and forwards toward 485 the data network. 487 5.2.2. Packet flow - Downlink 489 The downlink packet flow is as follows: 491 UPF1_in : (Z,A) ->UPF1 maps the flow w/ 492 SID list 493 UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)->H.Encaps.Red 494 C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A) 495 S1_out : (U1::1, gNB::1)(Z,A) ->End with PSP 496 gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 498 When the packet arrives at the UPF1, the UPF1 maps that particular 499 flow into a UE PDU Session. This UE PDU Session is associated with 500 the policy . The UPF1 performs a H.Encaps.Red 501 operation, encapsulating the packet into a new IPv6 header with its 502 corresponding SRH. 504 The nodes C1 and S1 perform their related Endpoint processing. 506 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 507 End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the 508 underlying traffic). The gNB decapsulates the packet, removing the 509 IPv6 header, and forwards the traffic towards the UE. The SID gNB::1 510 is one example of a SID associated to this service. 512 Note that there are several means to provide the UE session 513 aggregation. The decision on which one to use is a local decision 514 made by the operator. One option is to use the Args.Mob.Session 515 (Section 6.1). Another option comprises the gNB performing an IP 516 lookup on the inner packet by using the End.DT4, End.DT6, and End.DT2 517 behaviors. 519 5.2.3. Scalability 521 The Enhanced Mode improves since it allows the aggregation of several 522 UEs under the same SID list. For example, in the case of stationary 523 residential meters that are connected to the same cell, all such 524 devices can share the same SID list. This improves scalability 525 compared to Traditional Mode (unique SID per UE) and compared to 526 GTP-U (dedicated TEID per UE). 528 5.3. Enhanced mode with unchanged gNB GTP behavior 530 This section describes two mechanisms for interworking with legacy 531 gNBs that still use GTP: one for IPv4, and another for IPv6. 533 In the interworking scenarios as illustrated in Figure 4, the gNB 534 does not support SRv6. The gNB supports GTP encapsulation over IPv4 535 or IPv6. To achieve interworking, an SR Gateway (SRGW) entity is 536 added. The SRGW maps the GTP traffic into SRv6. 538 The SRGW is not an anchor point and maintains very little state. For 539 this reason, both IPv4 and IPv6 methods scale to millions of UEs. 541 _______ 542 IP GTP SRv6 / \ 543 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 544 |UE|------| gNB |------| SRGW |--------| UPF |---------\ DN / 545 +--+ +-----+ +------+ +------+ \_______/ 546 SR Gateway SRv6 node 548 Figure 4: Example topology for interworking 550 Both of the mechanisms described in this section are applicable to 551 either the Traditional Mode or the Enhanced Mode. 553 5.3.1. Interworking with IPv6 GTP 555 In this interworking mode the gNB at the N3 interface uses GTP over 556 IPv6. 558 Key points: 560 * The gNB is unchanged (control-plane or user-plane) and 561 encapsulates into GTP (N3 interface is not modified). 562 * The 5G Control-Plane towards the gNB (N2 interface) is unmodified, 563 though multiple UPF addresses need to be used - one IPv6 address 564 (i.e. a BSID at the SRGW) is needed per . 565 The SRv6 SID is different depending on the required combination. 568 * In the uplink, the SRGW removes GTP, finds the SID list related to 569 the IPv6 DA, and adds SRH with the SID list. 570 * There is no state for the downlink at the SRGW. 571 * There is simple state in the uplink at the SRGW; using Enhanced 572 mode results in fewer SR policies on this node. An SR policy is 573 shared across UEs as long as they belong to the same context 574 (i.e., tenant). A set of many different policies (i.e., different 575 SLAs) increases the amount of state required. 576 * When a packet from the UE leaves the gNB, it is SR-routed. This 577 simplifies network slicing [I-D.ietf-lsr-flex-algo]. 578 * In the uplink, the SRv6 BSID steers traffic into an SR policy when 579 it arrives at the SRGW. 581 An example topology is shown in Figure 5. 583 S1 and C1 are two service segments. S1 represents a VNF in the 584 network, and C1 represents a router configured for Traffic 585 Engineering. 587 +----+ 588 IPv6/GTP -| S1 |- ___ 589 +--+ +-----+ [N3] / +----+ \ / 590 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 591 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 592 GTP \ +------+ / +----+ +------+ \___ 593 -| SRGW |- SRv6 SRv6 594 +------+ TE 595 SR Gateway 597 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 599 5.3.1.1. Packet flow - Uplink 601 The uplink packet flow is as follows: 603 UE_out : (A,Z) 604 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 605 (IPv6/GTP) 606 SRGW_out: (SRGW, S1)(U2::T, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 607 SID at the SRGW 608 S1_out : (SRGW, C1)(U2::T, C1; SL=1)(A,Z) 609 C1_out : (SRGW, U2::T)(A,Z) -> End with PSP 610 UPF2_out: (A,Z) -> End.DT4 or End.DT6 612 The UE sends a packet destined to Z toward the gNB on a specific 613 bearer for that session. The gNB, which is unmodified, encapsulates 614 the packet into IPv6, UDP, and GTP headers. The IPv6 DA B, and the 615 GTP TEID T are the ones received in the N2 interface. 617 The IPv6 address that was signaled over the N2 interface for that UE 618 PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 619 SRGW. Hence the packet is routed to the SRGW. 621 When the packet arrives at the SRGW, the SRGW identifies B as an 622 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 623 the IPv6, UDP, and GTP headers, and pushes an IPv6 header with its 624 own SRH containing the SIDs bound to the SR policy associated with 625 this BindingSID. There at least one instance of the End.M.GTP6.D SID 626 per PDU type. 628 S1 and C1 perform their related Endpoint functionality and forward 629 the packet. 631 When the packet arrives at UPF2, the active segment is (U2::T) which 632 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 633 IPv6 header with all its extension headers) and forwards the packet 634 toward the data network. 636 5.3.1.2. Packet flow - Downlink 638 The downlink packet flow is as follows: 640 UPF2_in : (Z,A) -> UPF2 maps the flow with 641 642 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red 643 C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) 644 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 645 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 646 gNB_out : (Z,A) 648 When a packet destined to A arrives at the UPF2, the UPF2 performs a 649 lookup in the table associated to A and finds the SID list . The UPF2 performs an H.Encaps.Red operation, 651 encapsulating the packet into a new IPv6 header with its 652 corresponding SRH. 654 C1 and S1 perform their related Endpoint processing. 656 Once the packet arrives at the SRGW, the SRGW identifies the active 657 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 658 and all its extensions headers. The SRGW generates new IPv6, UDP, 659 and GTP headers. The new IPv6 DA is the gNB which is the last SID in 660 the received SRH. The TEID in the generated GTP header is an 661 argument of the received End.M.GTP6.E SID. The SRGW pushes the 662 headers to the packet and forwards the packet toward the gNB. There 663 is one instance of the End.M.GTP6.E SID per PDU type. 665 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 666 packet. The gNB looks for the specific radio bearer for that TEID 667 and forward it on the bearer. This gNB behavior is not modified from 668 current and previous generations. 670 5.3.1.3. Scalability 672 For the downlink traffic, the SRGW is stateless. All the state is in 673 the SRH pushed by the UPF2. The UPF2 must have the UE states since 674 it is the UE's session anchor point. 676 For the uplink traffic, the state at the SRGW does not necessarily 677 need to be unique per PDU Session; the SR policy can be shared among 678 UEs. This enables more scalable SRGW deployments compared to a 679 solution holding millions of states, one or more per UE. 681 5.3.2. Interworking with IPv4 GTP 683 In this interworking mode the gNB uses GTP over IPv4 in the N3 684 interface 686 Key points: 688 * The gNB is unchanged and encapsulates packets into GTP (the N3 689 interface is not modified). 690 * N2 signaling is not changed, though multiple UPF addresses need to 691 be provided - one for each PDU Session Type. 692 * In the uplink, traffic is classified by SRGW's classification 693 engine and steered into an SR policy. The SRGW may be implemented 694 in a UPF or as a separate entity. How the classification engine 695 rules are set up is outside the scope of this document, though one 696 example is using BGP signaling from a Mobile User Plane Controller 697 [I-D.mhkk-dmm-srv6mup-architecture]. 698 * SRGW removes GTP, finds the SID list related to DA, and adds an 699 SRH with the SID list. 701 An example topology is shown in Figure 6. In this mode the gNB is an 702 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 703 the SRGW maps the IPv4/GTP traffic to SRv6. 705 S1 and C1 are two service segment endpoints. S1 represents a VNF in 706 the network, and C1 represents a router configured for Traffic 707 Engineering. 709 +----+ 710 IPv4/GTP -| S1 |- ___ 711 +--+ +-----+ [N3] / +----+ \ / 712 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 713 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 714 GTP \ +------+ / +----+ +------+ \___ 715 -| UPF1 |- SRv6 SRv6 716 +------+ TE 717 SR Gateway 719 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 721 5.3.2.1. Packet flow - Uplink 723 The uplink packet flow is as follows: 725 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 726 unchanged IPv4/GTP 727 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function 728 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 729 C1_out : (SRGW, U2::1) (A,Z) -> PSP 730 UPF2_out: (A,Z) -> End.DT4 or End.DT6 732 The UE sends a packet destined to Z toward the gNB on a specific 733 bearer for that session. The gNB, which is unmodified, encapsulates 734 the packet into a new IPv4, UDP, and GTP headers. The IPv4 DA, B, 735 and the GTP TEID are the ones received at the N2 interface. 737 When the packet arrives at the SRGW for UPF1, the SRGW has an 738 classification engine rule for incoming traffic from the gNB, that 739 steers the traffic into an SR policy by using the function 740 H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and 741 pushes an IPv6 header with its own SRH containing the SIDs related to 742 the SR policy associated with this traffic. The SRGW forwards 743 according to the new IPv6 DA. 745 S1 and C1 perform their related Endpoint functionality and forward 746 the packet. 748 When the packet arrives at UPF2, the active segment is (U2::1) which 749 is bound to End.DT4/6 which performs the decapsulation (removing the 750 outer IPv6 header with all its extension headers) and forwards toward 751 the data network. 753 Note that the interworking mechanisms for IPv4/GTP and IPv6/GTP 754 differs. This is due to the fact that in IPv6/GTP we can leverage 755 the remote steering capabilities provided by the Segment Routing 756 BSID. In IPv4 this construct is not available, and building a 757 similar mechanism would require a significant address consumption. 759 5.3.2.2. Packet flow - Downlink 761 The downlink packet flow is as follows: 763 UPF2_in : (Z,A) -> UPF2 maps flow with SID 764 765 UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red 766 C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) 767 S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) 768 SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 769 gNB_out : (Z,A) 771 When a packet destined to A arrives at the UPF2, the UPF2 performs a 772 lookup in the table associated to A and finds the SID list . The UPF2 performs a H.Encaps.Red operation, 774 encapsulating the packet into a new IPv6 header with its 775 corresponding SRH. 777 The nodes C1 and S1 perform their related Endpoint processing. 779 Once the packet arrives at the SRGW, the SRGW identifies the active 780 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 781 and all its extensions headers. The SRGW generates an IPv4, UDP, and 782 GTP headers. The IPv4 SA and DA are received as SID arguments. The 783 TEID in the generated GTP header is also the arguments of the 784 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 785 and forwards the packet toward the gNB. 787 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 788 packet. The gNB looks for the specific radio bearer for that TEID 789 and forwards it on the bearer. This gNB behavior is not modified 790 from current and previous generations. 792 5.3.2.3. Scalability 794 For the downlink traffic, the SRGW is stateless. All the state is in 795 the SRH pushed by the UPF2. The UPF must have this UE-base state 796 anyway (since it is its anchor point). 798 For the uplink traffic, the state at the SRGW is dedicated on a per 799 UE/session basis according to a classification engine. There is 800 state for steering the different sessions in the form of an SR 801 Policy. However, SR policies are shared among several UE/sessions. 803 5.3.3. Extensions to the interworking mechanisms 805 In this section we presented two mechanisms for interworking with 806 gNBs and UPFs that do not support SRv6. These mechanisms are used to 807 support GTP over IPv4 and IPv6. 809 Even though we have presented these methods as an extension to the 810 "Enhanced mode", it is straightforward in its applicability to the 811 "Traditional mode". 813 5.4. SRv6 Drop-in Interworking 815 In this section we introduce another mode useful for legacy gNB and 816 UPFs that still operate with GTP-U. This mode provides an 817 SRv6-enabled user plane in between two GTP-U tunnel endpoints. 819 In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and 820 vice-versa. 822 Unlike other interworking modes, in this mode both of the mobility 823 overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or 824 N9 interface to realize an intermediate SR policy. 826 +----+ 827 -| S1 |- 828 +-----+ / +----+ \ 829 | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ 830 +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | 831 GTP[N3]\ +--------+ / +----+ +--------+ +-----+ 832 -| SRGW-A |- SRv6 SR Gateway-B GTP 833 +--------+ TE 834 SR Gateway-A 836 Figure 7: Example topology for SRv6 Drop-in mode 838 The packet flow of Figure 7 is as follows: 840 gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) 841 GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an 842 End.M.GTP6.D.Di 843 SID at SRGW-A 844 S1_out : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) 845 C1_out : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) 846 GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an 847 End.M.GTP6.E 848 SID at SRGW-B 849 UPF_out : (A,Z) 851 When a packet destined to Z is sent to the gNB, which is unmodified 852 (control-plane and user-plane remain GTP-U), gNB performs 853 encapsulation into a new IP, UDP, and GTP headers. The IPv6 DA, 854 U::1, and the GTP TEID are the ones received at the N2 interface. 856 The IPv6 address that was signaled over the N2 interface for that PDU 857 Session, U::1, is now the IPv6 DA. U::1 is an SRv6 Binding SID at 858 SRGW-A. Hence the packet is routed to the SRGW. 860 When the packet arrives at SRGW-A, the SRGW identifies U::1 as an 861 End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW 862 removes the IPv6, UDP, and GTP headers, and pushes an IPv6 header 863 with its own SRH containing the SIDs bound to the SR policy 864 associated with this Binding SID. There is one instance of the 865 End.M.GTP6.D.Di SID per PDU type. 867 S1 and C1 perform their related Endpoint functionality and forward 868 the packet. 870 Once the packet arrives at SRGW-B, the SRGW identifies the active SID 871 as an End.M.GTP6.E function. The SRGW removes the IPv6 header and 872 all its extensions headers. The SRGW generates new IPv6, UDP, and 873 GTP headers. The new IPv6 DA is U::1 which is the last SID in the 874 received SRH. The TEID in the generated GTP header is an argument of 875 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 876 packet and forwards the packet toward UPF. There is one instance of 877 the End.M.GTP6.E SID per PDU type. 879 Once the packet arrives at UPF, the packet is a regular IPv6/GTP 880 packet. The UPF looks for the specific rule for that TEID to forward 881 the packet. This UPF behavior is not modified from current and 882 previous generations. 884 6. SRv6 Segment Endpoint Mobility Behaviors 885 6.1. Args.Mob.Session 887 Args.Mob.Session provide per-session information for charging, 888 buffering and lawful intercept (among others) required by some mobile 889 nodes. The Args.Mob.Session argument format is used in combination 890 with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 891 behaviors. Note that proposed format is applicable for 5G networks, 892 while similar formats could be used for legacy networks. 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | QFI |R|U| PDU Session ID | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 |PDU Sess(cont')| 900 +-+-+-+-+-+-+-+-+ 902 Figure 8: Args.Mob.Session format 904 * QFI: QoS Flow Identifier [TS.38415] 905 * R: Reflective QoS Indication [TS.23501]. This parameter indicates 906 the activation of reflective QoS towards the UE for the 907 transferred packet. Reflective QoS enables the UE to map UL User 908 Plane traffic to QoS Flows without SMF provided QoS rules. 909 * U: Unused and for future use. MUST be 0 on transmission and 910 ignored on receipt. 911 * PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 912 is TEID. 914 Arg.Mob.Session is required in case that one SID aggregates multiple 915 PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated 916 per PDU session, Args.Mob.Session helps the UPF to perform the 917 behaviors which require per QFI and/or per PDU Session granularity. 919 Note that the encoding of user-plane messages (e.g., Echo Request, 920 Echo Reply, Error Indication and End Marker) is out of the scope of 921 this draft. [I-D.murakami-dmm-user-plane-message-encoding] defines 922 one possible encoding. 924 6.2. End.MAP 926 The "Endpoint behavior with SID mapping" behavior (End.MAP for short) 927 is used in several scenarios. Particularly in mobility, End.MAP is 928 used by the intermediate UPFs. 930 When node N receives a packet whose IPv6 DA is D and D is a local 931 End.MAP SID, N does: 933 S01. If (IPv6 Hop Limit <= 1) { 934 S02. Send an ICMP Time Exceeded message to the Source Address, 935 Code 0 (Hop limit exceeded in transit), 936 interrupt packet processing, and discard the packet. 937 S03. } 938 S04. Decrement IPv6 Hop Limit by 1 939 S05. Update the IPv6 DA with the new mapped SID 940 S06. Submit the packet to the egress IPv6 FIB lookup for 941 transmission to the new destination 943 Notes: The SIDs in the SRH are not modified. 945 6.3. End.M.GTP6.D 947 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy" 948 behavior (End.M.GTP6.D for short) is used in interworking scenario 949 for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any 950 SID instance of this behavior is associated with an SR Policy B and 951 an IPv6 Source Address S. 953 When the SR Gateway node N receives a packet destined to D and D is a 954 local End.M.GTP6.D SID, N does: 956 S01. When an SRH is processed { 957 S02. If (Segments Left != 0) { 958 S03. Send an ICMP Parameter Problem to the Source Address, 959 Code 0 (Erroneous header field encountered), 960 Pointer set to the Segments Left field, 961 interrupt packet processing, and discard the packet. 962 S04. } 963 S05. Proceed to process the next header in the packet 964 S06. } 966 When processing the Upper-layer header of a packet matching a FIB 967 entry locally instantiated as an End.M.GTP6.D SID, N does: 969 S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) { 970 S02. Copy the GTP TEID and QFI to buffer memory 971 S03. Pop the IPv6, UDP, and GTP Headers 972 S04. Push a new IPv6 header with its own SRH containing B 973 S05. Set the outer IPv6 SA to S 974 S06. Set the outer IPv6 DA to the first SID of B 975 S07. Set the outer Payload Length, Traffic Class, Flow Label, 976 Hop Limit, and Next-Header (NH) fields 977 S08. Write in the SRH[0] the Args.Mob.Session based on 978 the information of buffer memory 979 S09. Submit the packet to the egress IPv6 FIB lookup and 980 transmission to the new destination 981 S10. } Else { 982 S11. Process as per [RFC8986] Section 4.1.1 983 S12. } 985 Notes: S07. The NH is set based on the SID parameter. There is one 986 instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the 987 NH is already known in advance. For the IPv4v6 PDU Session Type, in 988 addition we inspect the first nibble of the PDU to know the NH value. 990 The last segment (S3 in above example) SHOULD be followed by an 991 Arg.Mob.Session argument space which is used to provide the session 992 identifiers. 994 6.4. End.M.GTP6.D.Di 996 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for 997 Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6 998 drop-in interworking scenario described in Section 5.4. The 999 difference between End.M.GTP6.D as another variant of IPv6/GTP 1000 decapsulation function is that the original IPv6 DA of GTP packet is 1001 preserved as the last SID in SRH. 1003 Any SID instance of this behavior is associated with an SR Policy B 1004 and an IPv6 Source Address S. 1006 When the SR Gateway node N receives a packet destined to D and D is a 1007 local End.M.GTP6.D.Di SID, N does: 1009 S01. When an SRH is processed { 1010 S02. If (Segments Left != 0) { 1011 S03. Send an ICMP Parameter Problem to the Source Address, 1012 Code 0 (Erroneous header field encountered), 1013 Pointer set to the Segments Left field, 1014 interrupt packet processing, and discard the packet. 1015 S04. } 1016 S05. Proceed to process the next header in the packet 1017 S06. } 1019 When processing the Upper-layer header of a packet matching a FIB 1020 entry locally instantiated as an End.M.GTP6.Di SID, N does: 1022 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1023 S02. Copy D to buffer memory 1024 S03. Pop the IPv6, UDP, and GTP Headers 1025 S04. Push a new IPv6 header with its own SRH containing B 1026 S05. Set the outer IPv6 SA to S 1027 S06. Set the outer IPv6 DA to the first SID of B 1028 S07. Set the outer Payload Length, Traffic Class, Flow Label, 1029 Hop Limit, and Next-Header fields 1030 S08. Preprend D to the SRH (as SRH[0]) and set SL accordingly 1031 S09. Submit the packet to the egress IPv6 FIB lookup and 1032 transmission to the new destination 1033 S10. } Else { 1034 S11. Process as per [RFC8986] Section 4.1.1 1035 S12. } 1037 Notes: S07. The NH is set based on the SID parameter. There is one 1038 instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the 1039 NH is already known in advance. For the IPv4v6 PDU Session Type, in 1040 addition we inspect the first nibble of the PDU to know the NH value. 1042 S SHOULD be an End.M.GTP6.E SID instantiated at the SR gateway. 1044 6.5. End.M.GTP6.E 1046 The "Endpoint behavior with encapsulation for IPv6/GTP tunnel" 1047 behavior (End.M.GTP6.E for short) is used among others in the 1048 interworking scenario for the downlink toward the legacy gNB using 1049 IPv6/GTP. 1051 The prefix of End.M.GTP6.E SID MUST be followed by the 1052 Arg.Mob.Session argument space which is used to provide the session 1053 identifiers. 1055 When the SR Gateway node N receives a packet destined to D, and D is 1056 a local End.M.GTP6.E SID, N does the following: 1058 S01. When an SRH is processed { 1059 S02. If (Segments Left != 1) { 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.GTP6.E SID, N does: 1071 S01. Copy SRH[0] and D to buffer memory 1072 S02. Pop the IPv6 header and all its extension headers 1073 S03. Push a new IPv6 header with a UDP/GTP Header 1074 S04. Set the outer IPv6 SA to S 1075 S05. Set the outer IPv6 DA from buffer memory 1076 S06. Set the outer Payload Length, Traffic Class, Flow Label, 1077 Hop Limit, and 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 1082 Notes: An End.M.GTP6.E SID MUST always be the penultimate SID. The 1083 TEID is extracted from the argument space of the current SID. 1085 The source address S SHOULD be an End.M.GTP6.D SID instantiated at an 1086 SR gateway. 1088 6.6. End.M.GTP4.E 1090 The "Endpoint behavior with encapsulation for IPv4/GTP tunnel" 1091 behavior (End.M.GTP4.E for short) is used in the downlink when doing 1092 interworking with legacy gNB using IPv4/GTP. 1094 When the SR Gateway node N receives a packet destined to S and S is a 1095 local End.M.GTP4.E SID, N does: 1097 S01. When an SRH is processed { 1098 S02. If (Segments Left != 0) { 1099 S03. Send an ICMP Parameter Problem to the Source Address, 1100 Code 0 (Erroneous header field encountered), 1101 Pointer set to the Segments Left field, 1102 interrupt packet processing, and discard the packet. 1103 S04. } 1104 S05. Proceed to process the next header in the packet 1105 S06. } 1106 When processing the Upper-layer header of a packet matching a FIB 1107 entry locally instantiated as an End.M.GTP4.E SID, N does: 1109 S01. Store the IPv6 DA and SA in buffer memory 1110 S02. Pop the IPv6 header and all its extension headers 1111 S03. Push a new IPv4 header with a UDP/GTP Header 1112 S04. Set the outer IPv4 SA and DA (from buffer memory) 1113 S05. Set the outer Total Length, DSCP, Time To Live, and 1114 Next-Header fields 1115 S06. Set the GTP TEID (from buffer memory) 1116 S07. Submit the packet to the egress IPv6 FIB lookup and 1117 transmission to the new destination 1119 Notes: The End.M.GTP4.E SID in S has the following format: 1121 0 127 1122 +-----------------------+-------+----------------+---------+ 1123 | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | 1124 +-----------------------+-------+----------------+---------+ 1125 128-a-b-c a b c 1127 Figure 9: End.M.GTP4.E SID Encoding 1129 The IPv6 Source Address has the following format: 1131 0 127 1132 +----------------------+--------+--------------------------+ 1133 | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | 1134 +----------------------+--------+--------------------------+ 1135 128-a-b a b 1137 Figure 10: IPv6 SA Encoding for End.M.GTP4.E 1139 6.7. H.M.GTP4.D 1141 The "SR Policy Headend with tunnel decapsulation and map to an SRv6 1142 policy" behavior (H.M.GTP4.D for short) is used in the direction from 1143 legacy IPv4 user-plane to SRv6 user-plane network. 1145 When the SR Gateway node N receives a packet destined to a IW- 1146 IPv4-Prefix, N does: 1148 S01. IF Payload == UDP/GTP THEN 1149 S02. Pop the outer IPv4 header and UDP/GTP headers 1150 S03. Copy IPv4 DA, TEID to form SID B 1151 S04. Copy IPv4 SA to form IPv6 SA B' 1152 S05. Encapsulate the packet into a new IPv6 header ;;Ref1 1153 S06. Set the IPv6 DA = B 1154 S07. Forward along the shortest path to B 1155 S08. ELSE 1156 S09. Drop the packet 1158 Ref1: The NH value is identified by inspecting the first nibble of 1159 the inner payload. 1161 The SID B has the following format: 1163 0 127 1164 +-----------------------+-------+----------------+---------+ 1165 |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | 1166 +-----------------------+-------+----------------+---------+ 1167 128-a-b-c a b c 1169 Figure 11: H.M.GTP4.D SID Encoding 1171 The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 1172 (U1) to bind an SR policy [I-D.ietf-spring-segment-routing-policy]. 1174 6.8. End.Limit: Rate Limiting behavior 1176 The mobile user-plane requires a rate-limit feature. For this 1177 purpose, we define a new behavior "End.Limit". The "End.Limit" 1178 behavior encodes in its arguments the rate limiting parameter that 1179 should be applied to this packet. Multiple flows of packets should 1180 have the same group identifier in the SID when those flows are in the 1181 same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of 1182 the rate limit segment SID is as follows: 1184 +----------------------+----------+-----------+ 1185 | LOC+FUNC rate-limit | group-id | limit-rate| 1186 +----------------------+----------+-----------+ 1187 128-i-j i j 1189 Figure 12: End.Limit: Rate limiting behavior argument format 1191 If the limit-rate bits are set to zero, the node should not do rate 1192 limiting unless static configuration or control-plane sets the limit 1193 rate associated to the SID. 1195 7. SRv6 supported 3GPP PDU session types 1197 The 3GPP [TS.23501] defines the following PDU session types: 1199 * IPv4 1200 * IPv6 1201 * IPv4v6 1202 * Ethernet 1203 * Unstructured 1205 SRv6 supports the 3GPP PDU session types without any protocol 1206 overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4 1207 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 1208 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU 1209 sessions). 1211 8. Network Slicing Considerations 1213 A mobile network may be required to implement "network slices", which 1214 logically separate network resources. User-plane behaviors 1215 represented as SRv6 segments would be part of a slice. 1217 [I-D.ietf-spring-segment-routing-policy] describes a solution to 1218 build basic network slices with SR. Depending on the requirements, 1219 these slices can be further refined by adopting the mechanisms from: 1221 * IGP Flex-Algo [I-D.ietf-lsr-flex-algo] 1222 * Inter-Domain policies 1223 [I-D.ietf-spring-segment-routing-central-epe] 1225 Furthermore, these can be combined with ODN/AS (On Demand Nexthop/ 1226 Automated Steering) [I-D.ietf-spring-segment-routing-policy] for 1227 automated slice provisioning and traffic steering. 1229 Further details on how these tools can be used to create end to end 1230 network slices are documented in 1231 [I-D.ali-spring-network-slicing-building-blocks]. 1233 9. Control Plane Considerations 1235 This document focuses on user-plane behavior and its independence 1236 from the control plane. While the SRv6 mobile user-plane behaviors 1237 may be utilized in emerging architectures, such as 1238 [I-D.gundavelli-dmm-mfa], [I-D.mhkk-dmm-srv6mup-architecture] for 1239 example, require control plane support for the user-plane, this 1240 document does not impose any change to the existent mobility control 1241 plane. 1243 Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for 1244 the new behaviors defined in this document. 1246 10. Security Considerations 1248 The security considerations for Segment Routing are discussed in 1249 [RFC8402]. More specifically for SRv6 the security considerations 1250 and the mechanisms for securing an SR domain are discussed in 1251 [RFC8754]. Together, they describe the required security mechanisms 1252 that allow establishment of an SR domain of trust to operate 1253 SRv6-based services for internal traffic while preventing any 1254 external traffic from accessing or exploiting the SRv6-based 1255 services. 1257 The technology described in this document is applied to a mobile 1258 network that is within the SR Domain. 1260 This document introduces new SRv6 Endpoint Behaviors. Those 1261 behaviors do not need any special security consideration given that 1262 it is deployed within that SR Domain. 1264 11. IANA Considerations 1266 The following values have been allocated within the "SRv6 Endpoint 1267 Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment 1268 Routing Parameters" registry: 1270 +=======+========+===================+===========+ 1271 | Value | Hex | Endpoint behavior | Reference | 1272 +=======+========+===================+===========+ 1273 | 40 | 0x0028 | End.MAP | [This.ID] | 1274 +-------+--------+-------------------+-----------+ 1275 | 41 | 0x0029 | End.Limit | [This.ID] | 1276 +-------+--------+-------------------+-----------+ 1277 | 69 | 0x0045 | End.M.GTP6.D | [This.ID] | 1278 +-------+--------+-------------------+-----------+ 1279 | 70 | 0x0046 | End.M.GTP6.Di | [This.ID] | 1280 +-------+--------+-------------------+-----------+ 1281 | 71 | 0x0047 | End.M.GTP6.E | [This.ID] | 1282 +-------+--------+-------------------+-----------+ 1283 | 72 | 0x0048 | End.M.GTP4.E | [This.ID] | 1284 +-------+--------+-------------------+-----------+ 1286 Table 1: SRv6 Mobile User-plane Endpoint 1287 Behavior Types 1289 12. Acknowledgements 1291 The authors would like to thank Daisuke Yokota, Bart Peirens, 1292 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1293 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1294 Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk v. Hugo and 1295 Jeffrey Zhang for their useful comments of this work. 1297 13. Contributors 1299 Kentaro Ebisawa Toyota Motor Corporation Japan 1301 Email: ebisawa@toyota-tokyo.tech 1303 Tetsuya Murakami Arrcus, Inc. United States of America 1305 Email: tetsuya.ietf@gmail.com 1307 14. References 1309 14.1. Normative References 1311 [I-D.ietf-spring-segment-routing-policy] 1312 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1313 P. Mattes, "Segment Routing Policy Architecture", Work in 1314 Progress, Internet-Draft, draft-ietf-spring-segment- 1315 routing-policy-22, 22 March 2022, 1316 . 1319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1320 Requirement Levels", BCP 14, RFC 2119, 1321 DOI 10.17487/RFC2119, March 1997, 1322 . 1324 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1325 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1326 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1327 July 2018, . 1329 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1330 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1331 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1332 . 1334 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1335 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1336 (SRv6) Network Programming", RFC 8986, 1337 DOI 10.17487/RFC8986, February 2021, 1338 . 1340 [TS.23501] 3GPP, "System Architecture for the 5G System", 3GPP TS 1341 23.501 15.0.0, November 2017. 1343 14.2. Informative References 1345 [I-D.ali-spring-network-slicing-building-blocks] 1346 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 1347 "Building blocks for Slicing in Segment Routing Network", 1348 Work in Progress, Internet-Draft, draft-ali-spring- 1349 network-slicing-building-blocks-04, 21 February 2021, 1350 . 1353 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1354 Garvia, P. C., Filsfils, C., Elmalky, H., Matsushima, S., 1355 Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- 1356 Cases", Work in Progress, Internet-Draft, draft- 1357 camarilloelmalky-springdmm-srv6-mob-usecases-02, 15 August 1358 2019, . 1361 [I-D.gundavelli-dmm-mfa] 1362 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 1363 aware Floating Anchor (MFA)", Work in Progress, Internet- 1364 Draft, draft-gundavelli-dmm-mfa-01, 19 September 2018, 1365 . 1368 [I-D.ietf-lsr-flex-algo] 1369 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1370 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 1371 Internet-Draft, draft-ietf-lsr-flex-algo-19, 7 April 2022, 1372 . 1375 [I-D.ietf-spring-segment-routing-central-epe] 1376 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1377 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1378 Engineering", Work in Progress, Internet-Draft, draft- 1379 ietf-spring-segment-routing-central-epe-10, 21 December 1380 2017, . 1383 [I-D.ietf-spring-sr-service-programming] 1384 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 1385 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 1386 S. Salsano, "Service Programming with Segment Routing", 1387 Work in Progress, Internet-Draft, draft-ietf-spring-sr- 1388 service-programming-05, 10 September 2021, 1389 . 1392 [I-D.kohno-dmm-srv6mob-arch] 1393 Kohno, M., Clad, F., Camarillo, P., and Z. Ali, 1394 "Architecture Discussion on SRv6 Mobile User plane", Work 1395 in Progress, Internet-Draft, draft-kohno-dmm-srv6mob-arch- 1396 05, 8 November 2021, 1397 . 1400 [I-D.matsushima-spring-srv6-deployment-status] 1401 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman, 1402 K., and A. Dhamija, "SRv6 Implementation and Deployment 1403 Status", Work in Progress, Internet-Draft, draft- 1404 matsushima-spring-srv6-deployment-status-15, 5 April 2022, 1405 . 1408 [I-D.mhkk-dmm-srv6mup-architecture] 1409 Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., 1410 Murakami, T., Patel, K., Kohno, M., Kamata, T., Garvia, P. 1411 C., Voyer, D., Zadok, S., Meilik, I., Agrawal, A., 1412 Perumal, K., and J. Horn, "Segment Routing IPv6 Mobile 1413 User Plane Architecture for Distributed Mobility 1414 Management", Work in Progress, Internet-Draft, draft-mhkk- 1415 dmm-srv6mup-architecture-03, 20 March 2022, 1416 . 1419 [I-D.murakami-dmm-user-plane-message-encoding] 1420 Murakami, T., Matsushima, S., Ebisawa, K., Camarillo, P., 1421 and R. Shekhar, "User Plane Message Encoding", Work in 1422 Progress, Internet-Draft, draft-murakami-dmm-user-plane- 1423 message-encoding-05, 5 March 2022, 1424 . 1427 [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling 1428 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1429 December 2017. 1431 [TS.38415] 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1432 3GPP R3-174510 0.0.0, August 2017. 1434 Appendix A. Implementations 1436 This document introduces new SRv6 Endpoint Behaviors. These 1437 behaviors have an open-source P4 implementation available in 1438 https://github.com/ebiken/p4srv6. 1440 Additionally, a full implementation of this document is available in 1441 Linux Foundation FD.io VPP project since release 20.05. More 1442 information available here: https://docs.fd.io/vpp/20.05/d7/d3c/ 1443 srv6_mobile_plugin_doc.html. 1445 There are also experimental implementations in M-CORD NGIC and Open 1446 Air Interface (OAI). 1448 Authors' Addresses 1450 Satoru Matsushima (editor) 1451 SoftBank 1452 Japan 1453 Email: satoru.matsushima@g.softbank.co.jp 1455 Clarence Filsfils 1456 Cisco Systems, Inc. 1457 Belgium 1458 Email: cf@cisco.com 1460 Miya Kohno 1461 Cisco Systems, Inc. 1462 Japan 1463 Email: mkohno@cisco.com 1465 Pablo Camarillo Garvia (editor) 1466 Cisco Systems, Inc. 1467 Spain 1468 Email: pcamaril@cisco.com 1470 Daniel Voyer 1471 Bell Canada 1472 Canada 1473 Email: daniel.voyer@bell.ca 1474 Charles E. Perkins 1475 Lupin Lodge 1476 20600 Aldercroft Heights Rd. 1477 Los Gatos, CA 95033 1478 United States of America 1479 Email: charliep@computer.org