idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-12.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 (May 4, 2021) is 1088 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 677, but not defined == Missing Reference: 'N9' is mentioned on line 520, but not defined == Missing Reference: 'N6' is mentioned on line 678, but not defined -- Looks like a reference, but probably isn't: '0' on line 1039 == Missing Reference: 'NET-PGM' is mentioned on line 1093, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-14 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-04 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-11 Summary: 0 errors (**), 0 flaws (~~), 13 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: November 5, 2021 M. Kohno 6 P. Camarillo, Ed. 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 May 4, 2021 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-12 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 accomplishes 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 25 SLA control for various applications. This document describes the 26 SRv6 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 November 5, 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 . . . . . . . . . . . . . . . . . 6 69 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7 70 5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7 71 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 72 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9 73 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 74 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 75 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11 76 5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 11 77 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 78 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 79 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15 80 5.3.3. Extensions to the interworking mechanisms . . . . . . 17 81 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17 82 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19 83 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19 84 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 86 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 21 87 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 22 88 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 23 89 6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25 90 6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26 91 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 26 92 8. Network Slicing Considerations . . . . . . . . . . . . . . . 26 93 9. Control Plane Considerations . . . . . . . . . . . . . . . . 27 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 97 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 100 14.2. Informative References . . . . . . . . . . . . . . . . . 29 101 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 104 1. Introduction 106 In mobile networks, mobility management systems provide connectivity 107 over a wireless link to stationary and non-stationary nodes. The 108 user-plane establishes a tunnel between the mobile node and its 109 anchor node over IP-based backhaul and core networks. 111 This document shows the applicability of SRv6 (Segment Routing IPv6) 112 to mobile networks. 114 Segment Routing [RFC8402] is a source routing architecture: a node 115 steers a packet through an ordered list of instructions called 116 "segments". A segment can represent any instruction, topological or 117 service based. 119 SRv6 applied to mobile networks enables a source-routing based mobile 120 architecture, where operators can explicitly indicate a route for the 121 packets to and from the mobile node. The SRv6 Endpoint nodes serve 122 as mobile user-plane anchors. 124 2. Conventions and Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 2.1. Terminology 132 o CNF: Cloud-native Network Function 133 o NFV: Network Function Virtualization 134 o PDU: Packet Data Unit 135 o PDU Session: Context of a UE connects to a mobile network. 136 o UE: User Equipment 137 o UPF: User Plane Function 138 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 neither S1 nor C1 are 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.2.3. Scalability 498 The Enhanced Mode improves since it allows the aggregation of several 499 UEs under the same SID list. For example, in the case of stationary 500 residential meters that are connected to the same cell, all such 501 devices can share the same SID list. This improves scalability 502 compared to Traditional Mode (unique SID per UE) and compared to 503 GTP-U (dedicated TEID per UE). 505 5.3. Enhanced mode with unchanged gNB GTP behavior 507 This section describes two mechanisms for interworking with legacy 508 gNBs that still use GTP: one for IPv4, and another for IPv6. 510 In the interworking scenarios as illustrated in Figure 4, the gNB 511 does not support SRv6. The gNB supports GTP encapsulation over IPv4 512 or IPv6. To achieve interworking, an SR Gateway (SRGW-UPF1) entity 513 is added. The SRGW maps the GTP traffic into SRv6. 515 The SRGW is not an anchor point and maintains very little state. For 516 this reason, both IPv4 and IPv6 methods scale to millions of UEs. 518 _______ 519 IP GTP SRv6 / \ 520 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 521 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 522 +--+ +-----+ +------+ +------+ \_______/ 523 SR Gateway SRv6 node 525 Figure 4: Example topology for interworking 527 Both of the mechanisms described in this section are applicable to 528 either the Traditional Mode or the Enhanced Mode. 530 5.3.1. Interworking with IPv6 GTP 532 In this interworking mode the gNB at the N3 interface uses GTP over 533 IPv6. 535 Key points: 537 o The gNB is unchanged (control-plane or user-plane) and 538 encapsulates into GTP (N3 interface is not modified). 539 o The 5G Control-Plane towards the gNB (N2 interface) is unmodified; 540 one IPv6 address is needed (i.e. a BSID at the SRGW). 541 o In the uplink, the SRGW removes GTP, finds the SID list related to 542 the IPv6 DA, and adds SRH with the SID list. 543 o There is no state for the downlink at the SRGW. 544 o There is simple state in the uplink at the SRGW; using Enhanced 545 mode results in fewer SR policies on this node. An SR policy is 546 shared across UEs. 547 o When a packet from the UE leaves the gNB, it is SR-routed. This 548 simplifies network slicing [I-D.ietf-lsr-flex-algo]. 549 o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic 550 into an SR policy when it arrives at the SRGW-UPF1. 552 An example topology is shown in Figure 5. 554 S1 and C1 are two service segments. S1 represents a VNF in the 555 network, and C1 represents a router configured for Traffic 556 Engineering. 558 +----+ 559 IPv6/GTP -| S1 |- ___ 560 +--+ +-----+ [N3] / +----+ \ / 561 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 562 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 563 GTP \ +------+ / +----+ +------+ \___ 564 -| UPF1 |- SRv6 SRv6 565 +------+ TE 566 SR Gateway 568 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 570 5.3.1.1. Packet flow - Uplink 572 The uplink packet flow is as follows: 574 UE_out : (A,Z) 575 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 576 (IPv6/GTP) 577 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 578 SID at the SRGW 579 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 580 C1_out : (SRGW, U2::1)(A,Z) -> End with PSP 581 UPF2_out: (A,Z) -> End.DT4 or End.DT6 583 The UE sends a packet destined to Z toward the gNB on a specific 584 bearer for that session. The gNB, which is unmodified, encapsulates 585 the packet into IPv6, UDP, and GTP headers. The IPv6 DA B, and the 586 GTP TEID T are the ones received in the N2 interface. 588 The IPv6 address that was signaled over the N2 interface for that UE 589 PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 590 SRGW. Hence the packet is routed to the SRGW. 592 When the packet arrives at the SRGW, the SRGW identifies B as an 593 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 594 the IPv6, UDP, and GTP headers, and pushes an IPv6 header with its 595 own SRH containing the SIDs bound to the SR policy associated with 596 this BindingSID. There is one instance of the End.M.GTP6.D SID per 597 PDU type. 599 S1 and C1 perform their related Endpoint functionality and forward 600 the packet. 602 When the packet arrives at UPF2, the active segment is (U2::1) which 603 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 604 IPv6 header with all its extension headers) and forwards the packet 605 toward the data network. 607 5.3.1.2. Packet flow - Downlink 609 The downlink packet flow is as follows: 611 UPF2_in : (Z,A) -> UPF2 maps the flow with 612 613 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red 614 C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) 615 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 616 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 617 gNB_out : (Z,A) 619 When a packet destined to A arrives at the UPF2, the UPF2 performs a 620 lookup in the table associated to A and finds the SID list . The UPF2 performs an H.Encaps.Red operation, 622 encapsulating the packet into a new IPv6 header with its 623 corresponding SRH. 625 C1 and S1 perform their related Endpoint processing. 627 Once the packet arrives at the SRGW, the SRGW identifies the active 628 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 629 and all its extensions headers. The SRGW generates new IPv6, UDP, 630 and GTP headers. The new IPv6 DA is the gNB which is the last SID in 631 the received SRH. The TEID in the generated GTP header is an 632 argument of the received End.M.GTP6.E SID. The SRGW pushes the 633 headers to the packet and forwards the packet toward the gNB. There 634 is one instance of the End.M.GTP6.E SID per PDU type. 636 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 637 packet. The gNB looks for the specific radio bearer for that TEID 638 and forward it on the bearer. This gNB behavior is not modified from 639 current and previous generations. 641 5.3.1.3. Scalability 643 For the downlink traffic, the SRGW is stateless. All the state is in 644 the SRH pushed by the UPF2. The UPF2 must have the UE states since 645 it is the UE's session anchor point. 647 For the uplink traffic, the state at the SRGW does not necessarily 648 need to be unique per PDU Session; the SR policy can be shared among 649 UEs. This enables more scalable SRGW deployments compared to a 650 solution holding millions of states, one or more per UE. 652 5.3.2. Interworking with IPv4 GTP 654 In this interworking mode the gNB uses GTP over IPv4 in the N3 655 interface 657 Key points: 659 o The gNB is unchanged and encapsulates packets into GTP (the N3 660 interface is not modified). 661 o In the uplink, traffic is classified by SRGW's Uplink Classifier 662 and steered into an SR policy. The SRGW is a UPF1 functionality 663 and can coexist with UPF1's Uplink Classifier functionality. 664 o SRGW removes GTP, finds the SID list related to DA, and adds an 665 SRH with the SID list. 667 An example topology is shown in Figure 6. In this mode the gNB is an 668 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 669 the SRGW maps the IPv4/GTP traffic to SRv6. 671 S1 and C1 are two service segment endpoints. S1 represents a VNF in 672 the network, and C1 represents a router configured for Traffic 673 Engineering. 675 +----+ 676 IPv4/GTP -| S1 |- ___ 677 +--+ +-----+ [N3] / +----+ \ / 678 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 679 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 680 GTP \ +------+ / +----+ +------+ \___ 681 -| UPF1 |- SRv6 SRv6 682 +------+ TE 683 SR Gateway 685 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 687 5.3.2.1. Packet flow - Uplink 689 The uplink packet flow is as follows: 691 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 692 unchanged IPv4/GTP 693 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function 694 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 695 C1_out : (SRGW, U2::1) (A,Z) -> PSP 696 UPF2_out: (A,Z) -> End.DT4 or End.DT6 698 The UE sends a packet destined to Z toward the gNB on a specific 699 bearer for that session. The gNB, which is unmodified, encapsulates 700 the packet into a new IPv4, UDP, and GTP headers. The IPv4 DA, B, 701 and the GTP TEID are the ones received at the N2 interface. 703 When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink 704 Classifier rule for incoming traffic from the gNB, that steers the 705 traffic into an SR policy by using the function H.M.GTP4.D. The SRGW 706 removes the IPv4, UDP, and GTP headers and pushes an IPv6 header with 707 its own SRH containing the SIDs related to the SR policy associated 708 with this traffic. The SRGW forwards according to the new IPv6 DA. 710 S1 and C1 perform their related Endpoint functionality and forward 711 the packet. 713 When the packet arrives at UPF2, the active segment is (U2::1) which 714 is bound to End.DT4/6 which performs the decapsulation (removing the 715 outer IPv6 header with all its extension headers) and forwards toward 716 the data network. 718 5.3.2.2. Packet flow - Downlink 720 The downlink packet flow is as follows: 722 UPF2_in : (Z,A) -> UPF2 maps flow with SID 723 724 UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red 725 C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) 726 S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) 727 SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 728 gNB_out : (Z,A) 730 When a packet destined to A arrives at the UPF2, the UPF2 performs a 731 lookup in the table associated to A and finds the SID list . The UPF2 performs a H.Encaps.Red operation, 733 encapsulating the packet into a new IPv6 header with its 734 corresponding SRH. 736 The nodes C1 and S1 perform their related Endpoint processing. 738 Once the packet arrives at the SRGW, the SRGW identifies the active 739 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 740 and all its extensions headers. The SRGW generates an IPv4, UDP, and 741 GTP headers. The IPv4 SA and DA are received as SID arguments. The 742 TEID in the generated GTP header is also the arguments of the 743 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 744 and forwards the packet toward the gNB. 746 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 747 packet. The gNB looks for the specific radio bearer for that TEID 748 and forwards it on the bearer. This gNB behavior is not modified 749 from current and previous generations. 751 5.3.2.3. Scalability 753 For the downlink traffic, the SRGW is stateless. All the state is in 754 the SRH pushed by the UPF2. The UPF must have this UE-base state 755 anyway (since it is its anchor point). 757 For the uplink traffic, the state at the SRGW is dedicated on a per 758 UE/session basis according to an Uplink Classifier. There is state 759 for steering the different sessions in the form of an SR Policy. 760 However, SR policies are shared among several UE/sessions. 762 5.3.3. Extensions to the interworking mechanisms 764 In this section we presented two mechanisms for interworking with 765 gNBs and UPFs that do not support SRv6. These mechanisms are used to 766 support GTP over IPv4 and IPv6. 768 Even though we have presented these methods as an extension to the 769 "Enhanced mode", it is straightforward in its applicability to the 770 "Traditional mode". 772 Furthermore, although these mechanisms are designed for interworking 773 with legacy RAN at the N3 interface, these methods could also be 774 applied for interworking with a non-SRv6 capable UPF at the N9 775 interface (e.g., L3-anchor is SRv6 capable but L2-anchor is not). 777 5.4. SRv6 Drop-in Interworking 779 In this section we introduce another mode useful for legacy gNB and 780 UPFs that still operate with GTP-U. This mode provides an 781 SRv6-enabled user plane in between two GTP-U tunnel endpoints. 783 In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and 784 vice-versa. 786 Unlike other interworking modes, in this mode both of the mobility 787 overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or 788 N9 interface to realize an intermediate SR policy. 790 +----+ 791 -| S1 |- 792 +-----+ / +----+ \ 793 | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ 794 +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | 795 GTP[N3]\ +--------+ / +----+ +--------+ +-----+ 796 -| SRGW-A |- SRv6 SR Gateway-B GTP 797 +--------+ TE 798 SR Gateway-A 800 Figure 7: Example topology for SRv6 Drop-in mode 802 The packet flow of Figure 7 is as follows: 804 gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) 805 GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an 806 End.M.GTP6.D.Di 807 SID at SRGW-A 808 S1_out : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) 809 C1_out : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) 810 GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an 811 End.M.GTP6.E 812 SID at SRGW-B 813 UPF_out : (A,Z) 815 When a packet destined to Z is sent to the gNB, which is unmodified 816 (control-plane and user-plane remain GTP-U), gNB performs 817 encapsulation into a new IP, UDP, and GTP headers. The IPv6 DA, 818 U::1, and the GTP TEID are the ones received at the N2 interface. 820 The IPv6 address that was signaled over the N2 interface for that PDU 821 Session, U::1, is now the IPv6 DA. U::1 is an SRv6 Binding SID at 822 SRGW-A. Hence the packet is routed to the SRGW. 824 When the packet arrives at SRGW-A, the SRGW identifies U::1 as an 825 End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW 826 removes the IPv6, UDP, and GTP headers, and pushes an IPv6 header 827 with its own SRH containing the SIDs bound to the SR policy 828 associated with this Binding SID. There is one instance of the 829 End.M.GTP6.D.Di SID per PDU type. 831 S1 and C1 perform their related Endpoint functionality and forward 832 the packet. 834 Once the packet arrives at SRGW-B, the SRGW identifies the active SID 835 as an End.M.GTP6.E function. The SRGW removes the IPv6 header and 836 all its extensions headers. The SRGW generates new IPv6, UDP, and 837 GTP headers. The new IPv6 DA is U::1 which is the last SID in the 838 received SRH. The TEID in the generated GTP header is an argument of 839 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 840 packet and forwards the packet toward UPF. There is one instance of 841 the End.M.GTP6.E SID per PDU type. 843 Once the packet arrives at UPF, the packet is a regular IPv6/GTP 844 packet. The UPF looks for the specific rule for that TEID to forward 845 the packet. This UPF behavior is not modified from current and 846 previous generations. 848 6. SRv6 Segment Endpoint Mobility Behaviors 850 6.1. Args.Mob.Session 852 Args.Mob.Session provide per-session information for charging, 853 buffering and lawful intercept (among others) required by some mobile 854 nodes. The Args.Mob.Session argument format is used in combination 855 with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 856 behaviors. Note that proposed format is applicable for 5G networks, 857 while similar formats could be used for legacy networks. 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | QFI |R|U| PDU Session ID | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 |PDU Sess(cont')| 865 +-+-+-+-+-+-+-+-+ 867 Args.Mob.Session format 869 o QFI: QoS Flow Identifier [TS.38415] 870 o R: Reflective QoS Indication [TS.23501]. This parameter indicates 871 the activation of reflective QoS towards the UE for the 872 transferred packet. Reflective QoS enables the UE to map UL User 873 Plane traffic to QoS Flows without SMF provided QoS rules. 874 o U: Unused and for future use. MUST be 0 on transmission and 875 ignored on receipt. 876 o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 877 is TEID. 879 Arg.Mob.Session is required in case that one SID aggregates multiple 880 PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated 881 per PDU session, Args.Mob.Session helps the UPF to perform the 882 behaviors which require per QFI and/or per PDU Session granularity. 884 6.2. End.MAP 886 The "Endpoint behavior with SID mapping" behavior (End.MAP for short) 887 is used in several scenarios. Particularly in mobility, End.MAP is 888 used in the UPFs for the PDU Session anchor functionality. 890 When node N receives a packet whose IPv6 DA is S and S is a local 891 End.MAP SID, N does: 893 S01. If (IPv6 Hop Limit <= 1) { 894 S02. Send an ICMP Time Exceeded message to the Source Address, 895 Code 0 (Hop limit exceeded in transit), 896 interrupt packet processing, and discard the packet. 897 S03. } 898 S04. Decrement IPv6 Hop Limit by 1 899 S05. Lookup the IPv6 DA in the mapping table 900 S06. Update the IPv6 DA with the new mapped SID 901 S07. Submit the packet to the egress IPv6 FIB lookup for 902 transmission to the new destination 904 Notes: 905 The SIDs in the SRH are not modified. 907 6.3. End.M.GTP6.D 909 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy" 910 behavior (End.M.GTP6.D for short) is used in interworking scenario 911 for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any 912 SID instance of this behavior is associated with an SR Policy B and 913 an IPv6 Source Address A. 915 When the SR Gateway node N receives a packet destined to S and S is a 916 local End.M.GTP6.D SID, N does: 918 S01. When an SRH is processed { 919 S02. If (Segments Left != 0) { 920 S03. Send an ICMP Parameter Problem to the Source Address, 921 Code 0 (Erroneous header field encountered), 922 Pointer set to the Segments Left field, 923 interrupt packet processing, and discard the packet. 924 S04. } 925 S05. Proceed to process the next header in the packet 926 S06. } 928 When processing the Upper-layer header of a packet matching a FIB 929 entry locally instantiated as an End.M.GTP6.D SID, N does: 931 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 932 S02. Copy the GTP TEID to buffer memory 933 S03. Pop the IPv6, UDP, and GTP Headers 934 S04. Push a new IPv6 header with its own SRH containing B 935 S05. Set the outer IPv6 SA to A 936 S06. Set the outer IPv6 DA to the first SID of B 937 S07. Set the outer Payload Length, Traffic Class, Flow Label, 938 Hop Limit, and Next-Header fields 939 S08. Write in the last SID of the SRH the Args.Mob.Session 940 based on the information of buffer memory 941 S09. Submit the packet to the egress IPv6 FIB lookup and 942 transmission to the new destination 943 S10. } Else { 944 S11. Process as per [RFC8986] Section 4.1.1 945 S12. } 947 Notes: 948 The NH is set based on the SID parameter. There is one instantiation 949 of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already 950 known in advance. For the IPv4v6 PDU Session Type, in addition we 951 inspect the first nibble of the PDU to know the NH value. 953 The prefix of last segment (S3 in above example) SHOULD be followed 954 by an Arg.Mob.Session argument space which is used to provide the 955 session identifiers. 957 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 958 gateway. 960 6.4. End.M.GTP6.D.Di 962 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for 963 Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6 964 drop-in interworking scenario described in Section 5.4. The 965 difference between End.M.GTP6.D as another variant of IPv6/GTP 966 decapsulation function is that the original IPv6 DA of GTP packet is 967 preserved as the last SID in SRH. 969 Any SID instance of this behavior is associated with an SR Policy B 970 and an IPv6 Source Address A. 972 When the SR Gateway node N receives a packet destined to S and S is a 973 local End.M.GTP6.D.Di SID, N does: 975 S01. When an SRH is processed { 976 S02. If (Segments Left != 0) { 977 S03. Send an ICMP Parameter Problem to the Source Address, 978 Code 0 (Erroneous header field encountered), 979 Pointer set to the Segments Left field, 980 interrupt packet processing, and discard the packet. 981 S04. } 982 S05. Proceed to process the next header in the packet 983 S06. } 985 When processing the Upper-layer header of a packet matching a FIB 986 entry locally instantiated as an End.M.GTP6.Di SID, N does: 988 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 989 S02. Copy S to buffer memory 990 S03. Pop the IPv6, UDP, and GTP Headers 991 S04. Push a new IPv6 header with its own SRH containing B 992 S05. Set the outer IPv6 SA to A 993 S06. Set the outer IPv6 DA to the first SID of B 994 S07. Set the outer Payload Length, Traffic Class, Flow Label, 995 Hop Limit, and Next-Header fields 996 S08. Write S to the SRH 997 S09. Submit the packet to the egress IPv6 FIB lookup and 998 transmission to the new destination 999 S10. } Else { 1000 S11. Process as per [RFC8986] Section 4.1.1 1001 S12. } 1003 Notes: 1004 The NH is set based on the SID parameter. There is one instantiation 1005 of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already 1006 known in advance. For the IPv4v6 PDU Session Type, in addition we 1007 inspect the first nibble of the PDU to know the NH value. 1009 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 1010 gateway. 1012 6.5. End.M.GTP6.E 1014 The "Endpoint behavior with encapsulation for IPv6/GTP tunnel" 1015 behavior (End.M.GTP6.E for short) is used in interworking scenario 1016 for the downlink toward the legacy gNB using IPv6/GTP. 1018 The prefix of End.M.GTP6.E SID MUST be followed by the 1019 Arg.Mob.Session argument space which is used to provide the session 1020 identifiers. 1022 When the SR Gateway node N receives a packet destined to S, and S is 1023 a local End.M.GTP6.E SID, N does the following: 1025 S01. When an SRH is processed { 1026 S02. If (Segments Left != 1) { 1027 S03. Send an ICMP Parameter Problem to the Source Address, 1028 Code 0 (Erroneous header field encountered), 1029 Pointer set to the Segments Left field, 1030 interrupt packet processing, and discard the packet. 1031 S04. } 1032 S05. Proceed to process the next header in the packet 1033 S06. } 1035 When processing the Upper-layer header of a packet matching a FIB 1036 entry locally instantiated as an End.M.GTP6.E SID, N does: 1038 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1039 S02. Copy SRH[0] to buffer memory 1040 S03. Pop the IPv6 header and all its extension headers 1041 S04. Push a new IPv6 header with a UDP/GTP Header 1042 S05. Set the outer IPv6 SA to A 1043 S06. Set the outer IPv6 DA to the first SID of B 1044 S07. Set the outer Payload Length, Traffic Class, Flow Label, 1045 Hop Limit, and Next-Header fields 1046 S08. Set the GTP TEID (from buffer memory) 1047 S09. Submit the packet to the egress IPv6 FIB lookup and 1048 transmission to the new destination 1049 S10. } Else { 1050 S11. Process as per [RFC8986] Section 4.1.1 1051 S12. } 1053 Notes: 1054 An End.M.GTP6.E SID MUST always be the penultimate SID. 1055 The TEID is extracted from the argument space of the current SID. 1057 The source address A SHOULD be an End.M.GTP6.D SID instantiated at an 1058 SR gateway. 1060 6.6. End.M.GTP4.E 1062 The "Endpoint behavior with encapsulation for IPv4/GTP tunnel" 1063 behavior (End.M.GTP4.E for short) is used in the downlink when doing 1064 interworking with legacy gNB using IPv4/GTP. 1066 When the SR Gateway node N receives a packet destined to S and S is a 1067 local End.M.GTP4.E SID, N does: 1069 S01. When an SRH is processed { 1070 S02. If (Segments Left != 0) { 1071 S03. Send an ICMP Parameter Problem to the Source Address, 1072 Code 0 (Erroneous header field encountered), 1073 Pointer set to the Segments Left field, 1074 interrupt packet processing, and discard the packet. 1075 S04. } 1076 S05. Proceed to process the next header in the packet 1077 S06. } 1079 When processing the Upper-layer header of a packet matching a FIB 1080 entry locally instantiated as an End.M.GTP4.E SID, N does: 1082 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1083 S02. Sotre the IPv6 DA and SA in buffer memory 1084 S03. Pop the IPv6 header and all its extension headers 1085 S04. Push a new IPv4 header with a UDP/GTP Header 1086 S05. Set the outer IPv4 SA and DA (from buffer memory) 1087 S06. Set the outer Total Length, DSCP, Time To Live, and 1088 Next-Header fields 1089 S07. Set the GTP TEID (from buffer memory) 1090 S08. Submit the packet to the egress IPv6 FIB lookup and 1091 transmission to the new destination 1092 S09. } Else { 1093 S10. Process as per [NET-PGM] Section 4.1.1 1094 S11. } 1096 Notes: 1097 The End.M.GTP4.E SID in S has the following format: 1099 0 127 1100 +-----------------------+-------+----------------+---------+ 1101 | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | 1102 +-----------------------+-------+----------------+---------+ 1103 128-a-b-c a b c 1105 End.M.GTP4.E SID Encoding 1107 The IPv6 Source Address has the following format: 1109 0 127 1110 +----------------------+--------+--------------------------+ 1111 | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | 1112 +----------------------+--------+--------------------------+ 1113 128-a-b a b 1115 IPv6 SA Encoding for End.M.GTP4.E 1117 6.7. H.M.GTP4.D 1119 The "SR Policy Headend with tunnel decapsulation and map to an SRv6 1120 policy" behavior (H.M.GTP4.D for short) is used in the direction from 1121 legacy IPv4 user-plane to SRv6 user-plane network. 1123 When the SR Gateway node N receives a packet destined to a IW- 1124 IPv4-Prefix, N does: 1126 S01. IF Payload == UDP/GTP THEN 1127 S02. Pop the outer IPv4 header and UDP/GTP headers 1128 S03. Copy IPv4 DA, TEID to form SID B 1129 S04. Copy IPv4 SA to form IPv6 SA B' 1130 S05. Encapsulate the packet into a new IPv6 header ;;Ref1 1131 S06. Set the IPv6 DA = B 1132 S07. Forward along the shortest path to B 1133 S08. ELSE 1134 S09. Drop the packet 1136 Ref1: The NH value is identified by inspecting the first nibble of 1137 the inner payload. 1139 The SID B has the following format: 1141 0 127 1142 +-----------------------+-------+----------------+---------+ 1143 |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | 1144 +-----------------------+-------+----------------+---------+ 1145 128-a-b-c a b c 1147 H.M.GTP4.D SID Encoding 1149 The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 1150 (U1) to bind an SR policy [I-D.ietf-spring-segment-routing-policy]. 1152 The prefix of B' SHOULD be an End.M.GTP4.E SID with its format 1153 instantiated at an SR gateway with the IPv4 SA of the receiving 1154 packet. 1156 6.8. End.Limit: Rate Limiting behavior 1158 The mobile user-plane requires a rate-limit feature. For this 1159 purpose, we define a new behavior "End.Limit". The "End.Limit" 1160 behavior encodes in its arguments the rate limiting parameter that 1161 should be applied to this packet. Multiple flows of packets should 1162 have the same group identifier in the SID when those flows are in the 1163 same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of 1164 the rate limit segment SID is as follows: 1166 +----------------------+----------+-----------+ 1167 | LOC+FUNC rate-limit | group-id | limit-rate| 1168 +----------------------+----------+-----------+ 1169 128-i-j i j 1171 End.Limit: Rate limiting behavior argument format 1173 If the limit-rate bits are set to zero, the node should not do rate 1174 limiting unless static configuration or control-plane sets the limit 1175 rate associated to the SID. 1177 7. SRv6 supported 3GPP PDU session types 1179 The 3GPP [TS.23501] defines the following PDU session types: 1181 o IPv4 1182 o IPv6 1183 o IPv4v6 1184 o Ethernet 1185 o Unstructured 1187 SRv6 supports the 3GPP PDU session types without any protocol 1188 overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4 1189 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 1190 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU 1191 sessions). 1193 8. Network Slicing Considerations 1195 A mobile network may be required to implement "network slices", which 1196 logically separate network resources. User-plane behaviors 1197 represented as SRv6 segments would be part of a slice. 1199 [I-D.ietf-spring-segment-routing-policy] describes a solution to 1200 build basic network slices with SR. Depending on the requirements, 1201 these slices can be further refined by adopting the mechanisms from: 1203 o IGP Flex-Algo [I-D.ietf-lsr-flex-algo] 1204 o Inter-Domain policies 1205 [I-D.ietf-spring-segment-routing-central-epe] 1207 Furthermore, these can be combined with ODN/AS (On Demand Nexthop/ 1208 Automated Steering) [I-D.ietf-spring-segment-routing-policy] for 1209 automated slice provisioning and traffic steering. 1211 Further details on how these tools can be used to create end to end 1212 network slices are documented in 1213 [I-D.ali-spring-network-slicing-building-blocks]. 1215 9. Control Plane Considerations 1217 This document focuses on user-plane behavior and its independence 1218 from the control plane. 1220 The control plane could be the current 3GPP-defined control plane 1221 with slight modifications to the N4 interface [TS.29244]. 1223 Alternatively, SRv6 could be used in conjunction with a new mobility 1224 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 1225 hICN [I-D.auge-dmm-hicn-mobility-deployment-options] or in 1226 conjunction with FPC [I-D.ietf-dmm-fpc-cpdp]. The analysis of new 1227 mobility control-planes and its applicability to an SRv6 user-plane 1228 is out of the scope of this document. 1230 Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for 1231 the new behaviors defined in this document. 1233 10. Security Considerations 1235 The security considerations for Segment Routing are discussed in 1236 [RFC8402]. More specifically for SRv6 the security considerations 1237 and the mechanisms for securing an SR domain are discussed in 1238 [RFC8754]. Together, they describe the required security mechanisms 1239 that allow establishment of an SR domain of trust to operate 1240 SRv6-based services for internal traffic while preventing any 1241 external traffic from accessing or exploiting the SRv6-based 1242 services. 1244 The technology described in this document is applied to a mobile 1245 network that is within the SR Domain. 1247 This document introduces new SRv6 Endpoint Behaviors. Those 1248 behaviors do not need any special security consideration given that 1249 it is deployed within that SR Domain. 1251 11. IANA Considerations 1253 The following values have been allocated within the "SRv6 Endpoint 1254 Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment 1255 Routing Parameters" registry: 1257 +-------+--------+-------------------+-----------+ 1258 | Value | Hex | Endpoint behavior | Reference | 1259 +-------+--------+-------------------+-----------+ 1260 | 40 | 0x0028 | End.MAP | [This.ID] | 1261 | 41 | 0x0029 | End.Limit | [This.ID] | 1262 | 69 | 0x0045 | End.M.GTP6.D | [This.ID] | 1263 | 70 | 0x0046 | End.M.GTP6.Di | [This.ID] | 1264 | 71 | 0x0047 | End.M.GTP6.E | [This.ID] | 1265 | 72 | 0x0048 | End.M.GTP4.E | [This.ID] | 1266 +-------+--------+-------------------+-----------+ 1268 Table 1: SRv6 Mobile User-plane Endpoint Behavior Types 1270 12. Acknowledgements 1272 The authors would like to thank Daisuke Yokota, Bart Peirens, 1273 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1274 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1275 Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk v. Hugo and 1276 Jeffrey Zhang for their useful comments of this work. 1278 13. Contributors 1280 Kentaro Ebisawa 1281 Toyota Motor Corporation 1282 Japan 1284 Email: ebisawa@toyota-tokyo.tech 1286 Tetsuya Murakami 1287 Arrcus, Inc. 1288 United States of America 1290 Email: tetsuya.ietf@gmail.com 1292 14. References 1294 14.1. Normative References 1296 [I-D.ietf-spring-segment-routing-policy] 1297 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1298 P. Mattes, "Segment Routing Policy Architecture", draft- 1299 ietf-spring-segment-routing-policy-09 (work in progress), 1300 November 2020. 1302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1303 Requirement Levels", BCP 14, RFC 2119, 1304 DOI 10.17487/RFC2119, March 1997, 1305 . 1307 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1308 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1309 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1310 July 2018, . 1312 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1313 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1314 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1315 . 1317 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1318 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1319 (SRv6) Network Programming", RFC 8986, 1320 DOI 10.17487/RFC8986, February 2021, 1321 . 1323 [TS.23501] 1324 3GPP, "System Architecture for the 5G System", 3GPP TS 1325 23.501 15.0.0, November 2017. 1327 14.2. Informative References 1329 [I-D.ali-spring-network-slicing-building-blocks] 1330 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 1331 "Building blocks for Slicing in Segment Routing Network", 1332 draft-ali-spring-network-slicing-building-blocks-04 (work 1333 in progress), February 2021. 1335 [I-D.auge-dmm-hicn-mobility-deployment-options] 1336 Auge, J., Carofiglio, G., Muscariello, L., and M. 1337 Papalini, "Anchorless mobility management through hICN 1338 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1339 mobility-deployment-options-04 (work in progress), July 1340 2020. 1342 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1343 Garvia, P. C., Filsfils, C., Elmalky, H., Matsushima, S., 1344 Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- 1345 Cases", draft-camarilloelmalky-springdmm-srv6-mob- 1346 usecases-02 (work in progress), August 2019. 1348 [I-D.ietf-dmm-fpc-cpdp] 1349 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1350 Moses, D., and C. E. Perkins, "Protocol for Forwarding 1351 Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc- 1352 cpdp-14 (work in progress), September 2020. 1354 [I-D.ietf-lsr-flex-algo] 1355 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1356 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1357 algo-14 (work in progress), February 2021. 1359 [I-D.ietf-spring-segment-routing-central-epe] 1360 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1361 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1362 Engineering", draft-ietf-spring-segment-routing-central- 1363 epe-10 (work in progress), December 2017. 1365 [I-D.ietf-spring-sr-service-programming] 1366 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 1367 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 1368 S. Salsano, "Service Programming with Segment Routing", 1369 draft-ietf-spring-sr-service-programming-04 (work in 1370 progress), March 2021. 1372 [I-D.matsushima-spring-srv6-deployment-status] 1373 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 1374 Rajaraman, "SRv6 Implementation and Deployment Status", 1375 draft-matsushima-spring-srv6-deployment-status-11 (work in 1376 progress), February 2021. 1378 [I-D.rodrigueznatal-lisp-srv6] 1379 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1380 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1381 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-04 1382 (work in progress), July 2020. 1384 [TS.29244] 1385 3GPP, "Interface between the Control Plane and the User 1386 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1388 [TS.29281] 1389 3GPP, "General Packet Radio System (GPRS) Tunnelling 1390 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1391 December 2017. 1393 [TS.38415] 1394 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1395 3GPP R3-174510 0.0.0, August 2017. 1397 Appendix A. Implementations 1399 This document introduces new SRv6 Endpoint Behaviors. These 1400 behaviors have an open-source P4 implementation available in 1401 . 1403 Additionally, a full implementation of this document is available in 1404 Linux Foundation FD.io VPP project since release 20.05. More 1405 information available here: . 1408 There are also experimental implementations in M-CORD NGIC and Open 1409 Air Interface (OAI). 1411 Authors' Addresses 1413 Satoru Matsushima (editor) 1414 SoftBank 1415 Japan 1417 Email: satoru.matsushima@g.softbank.co.jp 1419 Clarence Filsfils 1420 Cisco Systems, Inc. 1421 Belgium 1423 Email: cf@cisco.com 1425 Miya Kohno 1426 Cisco Systems, Inc. 1427 Japan 1429 Email: mkohno@cisco.com 1430 Pablo Camarillo Garvia (editor) 1431 Cisco Systems, Inc. 1432 Spain 1434 Email: pcamaril@cisco.com 1436 Daniel Voyer 1437 Bell Canada 1438 Canada 1440 Email: daniel.voyer@bell.ca 1442 Charles E. Perkins 1443 Futurewei Inc. 1444 2330 Central Expressway 1445 Santa Clara, CA 95050 1446 USA 1448 Phone: +1-408-330-4586 1449 Email: charliep@computer.org