idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-13.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 21, 2021) is 1061 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 684, but not defined == Missing Reference: 'N9' is mentioned on line 527, but not defined == Missing Reference: 'N6' is mentioned on line 685, but not defined -- Looks like a reference, but probably isn't: '0' on line 1044 == Missing Reference: 'NET-PGM' is mentioned on line 1096, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-15 == 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 22, 2021 M. Kohno 6 P. Camarillo, Ed. 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Lupin Lodge 12 May 21, 2021 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-13 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 22, 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 . . . . . . 12 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 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. 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, and the SID list only contains a 327 single SID. 329 The traditional mode minimizes the changes required to the mobile 330 system; hence it is a good starting point for forming a common 331 ground. 333 The gNB/UPF control-plane (N2/N4 interface) is unchanged, 334 specifically a single IPv6 address is provided to the gNB. The same 335 control plane signalling is used, and the gNB/UPF decides to use SRv6 336 based on signaled GTP-U parameters per local policy. 338 Our example topology is shown in Figure 2. In traditional mode the 339 gNB and the UPFs are SR-aware. In the descriptions of the uplink and 340 downlink packet flow, A is an IPv6 address of the UE, and Z is an 341 IPv6 address reachable within the Data Network DN. A new SRv6 342 Endpoint Behavior, End.MAP, defined in Section 6.2, is used. 344 ________ 345 SRv6 SRv6 / \ 346 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 347 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 348 +--+ +-----+ +------+ +------+ \________/ 349 SRv6 node SRv6 node SRv6 node 351 Figure 2: Traditional mode - example topology 353 5.1.1. Packet flow - Uplink 355 The uplink packet flow is as follows: 357 UE_out : (A,Z) 358 gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red 359 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 360 UPF2_out: (A,Z) -> End.DT4 or End.DT6 362 When the UE packet arrives at the gNB, the gNB performs a 363 H.Encaps.Red operation. Since there is only one SID, there is no 364 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 365 U1::1. U1::1 represents an anchoring SID specific for that session 366 at UPF1. gNB obtains the SID U1::1 from the existing control plane 367 (N2 interface). 369 When the packet arrives at UPF1, the SID U1::1 is associated with the 370 End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1, 371 that belongs to the next UPF (U2). 373 When the packet arrives at UPF2, the SID U2::1 corresponds to an 374 End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates 375 the packet, performs a lookup in a specific table associated with 376 that mobile network and forwards the packet toward the data network 377 (DN). 379 5.1.2. Packet flow - Downlink 381 The downlink packet flow is as follows: 383 UPF2_in : (Z,A) 384 UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red 385 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 386 gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2 388 When the packet arrives at the UPF2, the UPF2 maps that flow into a 389 PDU Session. This PDU Session is associated with the segment 390 endpoint . UPF2 performs a H.Encaps.Red operation, 391 encapsulating the packet into a new IPv6 header with no SRH since 392 there is only one SID. 394 Upon packet arrival on UPF1, the SID U1::2 is a local SID associated 395 with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next 396 anchoring point and replaces U1::2 by gNB::1, that belongs to the 397 next hop. 399 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4, 400 End.DX6 or End.DX2 behavior (depending on the PDU Session Type). The 401 gNB decapsulates the packet, removing the IPv6 header and all its 402 extensions headers, and forwards the traffic toward the UE. 404 5.2. Enhanced Mode 406 Enhanced mode improves scalability, provides traffic engineering 407 capabilities, and allows service programming 408 [I-D.ietf-spring-sr-service-programming], thanks to the use of 409 multiple SIDs in the SID list (instead of a direct connectivity in 410 between UPFs with no intermediate waypoints as in Traditional Mode). 412 Thus, the main difference is that the SR policy MAY include SIDs for 413 traffic engineering and service programming in addition to the 414 anchoring SIDs at UPFs. 416 Additionally in this mode the operator may choose to aggregate 417 several devices under the same SID list (e.g., stationary residential 418 meters connected to the same cell) to improve scalability. 420 The gNB control-plane (N2 interface) is unchanged, specifically a 421 single IPv6 address is provided to the gNB. A local policy instructs 422 the gNB to use SRv6. 424 The gNB MAY resolve the IP address received via the control plane 425 into a SID list using a mechanism like PCEP, DNS-lookup, LISP 426 control-plane or others. The resolution mechanism is out of the 427 scope of this document. 429 Note that the SIDs MAY use the arguments Args.Mob.Session if required 430 by the UPFs. 432 Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 433 gNB and the UPF are SR-aware. The Figure shows two service segments, 434 S1 and C1. S1 represents a VNF in the network, and C1 represents an 435 intermediate router used for Traffic Engineering purposes to enforce 436 a low-latency path in the network. Note that neither S1 nor C1 are 437 required to have an N4 interface. 439 +----+ SRv6 _______ 440 SRv6 --| C1 |--[N3] / \ 441 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 442 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 443 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 444 SRv6 node \ +----+ / SRv6 node 445 -| S1 |- 446 +----+ 447 SRv6 node 448 VNF 450 Figure 3: Enhanced mode - Example topology 452 5.2.1. Packet flow - Uplink 454 The uplink packet flow is as follows: 456 UE_out : (A,Z) 457 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)->H.Encaps.Red 458 S1_out : (gNB, C1)(U2::1, C1; SL=1)(A,Z) 459 C1_out : (gNB, U2::1)(A,Z) ->End with PSP 460 UPF2_out: (A,Z) ->End.DT4,End.DT6,End.DT2U 462 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 463 control plane associates that session from the UE(A) with the IPv6 464 address B. gNB's control plane does a lookup on B to find the 465 related SID list . 467 When gNB transmits the packet, it contains all the segments of the SR 468 policy. The SR policy includes segments for traffic engineering (C1) 469 and for service programming (S1). 471 Nodes S1 and C1 perform their related Endpoint functionality and 472 forward the packet. 474 When the packet arrives at UPF2, the active segment (U2::1) is an 475 End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing 476 the IPv6 header with all its extension headers) and forwards toward 477 the data network. 479 5.2.2. Packet flow - Downlink 481 The downlink packet flow is as follows: 483 UPF2_in : (Z,A) ->UPF2 maps the flow w/ 484 SID list 485 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) ->H.Encaps.Red 486 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 487 S1_out : (U2::1, gNB)(Z,A) ->End with PSP 488 gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 490 When the packet arrives at the UPF2, the UPF2 maps that particular 491 flow into a UE PDU Session. This UE PDU Session is associated with 492 the policy . The UPF2 performs a H.Encaps.Red 493 operation, encapsulating the packet into a new IPv6 header with its 494 corresponding SRH. 496 The nodes C1 and S1 perform their related Endpoint processing. 498 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 499 End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the 500 underlying traffic). The gNB decapsulates the packet, removing the 501 IPv6 header and forwards the traffic toward the UE. 503 5.2.3. Scalability 505 The Enhanced Mode improves since it allows the aggregation of several 506 UEs under the same SID list. For example, in the case of stationary 507 residential meters that are connected to the same cell, all such 508 devices can share the same SID list. This improves scalability 509 compared to Traditional Mode (unique SID per UE) and compared to 510 GTP-U (dedicated TEID per UE). 512 5.3. Enhanced mode with unchanged gNB GTP behavior 514 This section describes two mechanisms for interworking with legacy 515 gNBs that still use GTP: one for IPv4, and another for IPv6. 517 In the interworking scenarios as illustrated in Figure 4, the gNB 518 does not support SRv6. The gNB supports GTP encapsulation over IPv4 519 or IPv6. To achieve interworking, an SR Gateway (SRGW) entity is 520 added. The SRGW maps the GTP traffic into SRv6. 522 The SRGW is not an anchor point and maintains very little state. For 523 this reason, both IPv4 and IPv6 methods scale to millions of UEs. 525 _______ 526 IP GTP SRv6 / \ 527 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 528 |UE|------| gNB |------| SRGW |--------| UPF |---------\ DN / 529 +--+ +-----+ +------+ +------+ \_______/ 530 SR Gateway SRv6 node 532 Figure 4: Example topology for interworking 534 Both of the mechanisms described in this section are applicable to 535 either the Traditional Mode or the Enhanced Mode. 537 5.3.1. Interworking with IPv6 GTP 539 In this interworking mode the gNB at the N3 interface uses GTP over 540 IPv6. 542 Key points: 544 o The gNB is unchanged (control-plane or user-plane) and 545 encapsulates into GTP (N3 interface is not modified). 546 o The 5G Control-Plane towards the gNB (N2 interface) is unmodified; 547 one IPv6 address is needed (i.e. a BSID at the SRGW). 548 o In the uplink, the SRGW removes GTP, finds the SID list related to 549 the IPv6 DA, and adds SRH with the SID list. 550 o There is no state for the downlink at the SRGW. 551 o There is simple state in the uplink at the SRGW; using Enhanced 552 mode results in fewer SR policies on this node. An SR policy is 553 shared across UEs. 554 o When a packet from the UE leaves the gNB, it is SR-routed. This 555 simplifies network slicing [I-D.ietf-lsr-flex-algo]. 556 o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic 557 into an SR policy when it arrives at the SRGW. 559 An example topology is shown in Figure 5. 561 S1 and C1 are two service segments. S1 represents a VNF in the 562 network, and C1 represents a router configured for Traffic 563 Engineering. 565 +----+ 566 IPv6/GTP -| S1 |- ___ 567 +--+ +-----+ [N3] / +----+ \ / 568 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 569 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 570 GTP \ +------+ / +----+ +------+ \___ 571 -| SRGW |- SRv6 SRv6 572 +------+ TE 573 SR Gateway 575 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 577 5.3.1.1. Packet flow - Uplink 579 The uplink packet flow is as follows: 581 UE_out : (A,Z) 582 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 583 (IPv6/GTP) 584 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 585 SID at the SRGW 586 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 587 C1_out : (SRGW, U2::1)(A,Z) -> End with PSP 588 UPF2_out: (A,Z) -> End.DT4 or End.DT6 590 The UE sends a packet destined to Z toward the gNB on a specific 591 bearer for that session. The gNB, which is unmodified, encapsulates 592 the packet into IPv6, UDP, and GTP headers. The IPv6 DA B, and the 593 GTP TEID T are the ones received in the N2 interface. 595 The IPv6 address that was signaled over the N2 interface for that UE 596 PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 597 SRGW. Hence the packet is routed to the SRGW. 599 When the packet arrives at the SRGW, the SRGW identifies B as an 600 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 601 the IPv6, UDP, and GTP headers, and pushes an IPv6 header with its 602 own SRH containing the SIDs bound to the SR policy associated with 603 this BindingSID. There is one instance of the End.M.GTP6.D SID per 604 PDU type. 606 S1 and C1 perform their related Endpoint functionality and forward 607 the packet. 609 When the packet arrives at UPF2, the active segment is (U2::1) which 610 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 611 IPv6 header with all its extension headers) and forwards the packet 612 toward the data network. 614 5.3.1.2. Packet flow - Downlink 616 The downlink packet flow is as follows: 618 UPF2_in : (Z,A) -> UPF2 maps the flow with 619 620 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red 621 C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) 622 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 623 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 624 gNB_out : (Z,A) 626 When a packet destined to A arrives at the UPF2, the UPF2 performs a 627 lookup in the table associated to A and finds the SID list . The UPF2 performs an H.Encaps.Red operation, 629 encapsulating the packet into a new IPv6 header with its 630 corresponding SRH. 632 C1 and S1 perform their related Endpoint processing. 634 Once the packet arrives at the SRGW, the SRGW identifies the active 635 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 636 and all its extensions headers. The SRGW generates new IPv6, UDP, 637 and GTP headers. The new IPv6 DA is the gNB which is the last SID in 638 the received SRH. The TEID in the generated GTP header is an 639 argument of the received End.M.GTP6.E SID. The SRGW pushes the 640 headers to the packet and forwards the packet toward the gNB. There 641 is one instance of the End.M.GTP6.E SID per PDU type. 643 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 644 packet. The gNB looks for the specific radio bearer for that TEID 645 and forward it on the bearer. This gNB behavior is not modified from 646 current and previous generations. 648 5.3.1.3. Scalability 650 For the downlink traffic, the SRGW is stateless. All the state is in 651 the SRH pushed by the UPF2. The UPF2 must have the UE states since 652 it is the UE's session anchor point. 654 For the uplink traffic, the state at the SRGW does not necessarily 655 need to be unique per PDU Session; the SR policy can be shared among 656 UEs. This enables more scalable SRGW deployments compared to a 657 solution holding millions of states, one or more per UE. 659 5.3.2. Interworking with IPv4 GTP 661 In this interworking mode the gNB uses GTP over IPv4 in the N3 662 interface 664 Key points: 666 o The gNB is unchanged and encapsulates packets into GTP (the N3 667 interface is not modified). 668 o In the uplink, traffic is classified by SRGW's Uplink Classifier 669 and steered into an SR policy. The SRGW is a UPF1 functionality 670 and can coexist with UPF1's Uplink Classifier functionality. 671 o SRGW removes GTP, finds the SID list related to DA, and adds an 672 SRH with the SID list. 674 An example topology is shown in Figure 6. In this mode the gNB is an 675 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 676 the SRGW maps the IPv4/GTP traffic to SRv6. 678 S1 and C1 are two service segment endpoints. S1 represents a VNF in 679 the network, and C1 represents a router configured for Traffic 680 Engineering. 682 +----+ 683 IPv4/GTP -| S1 |- ___ 684 +--+ +-----+ [N3] / +----+ \ / 685 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 686 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 687 GTP \ +------+ / +----+ +------+ \___ 688 -| UPF1 |- SRv6 SRv6 689 +------+ TE 690 SR Gateway 692 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 694 5.3.2.1. Packet flow - Uplink 696 The uplink packet flow is as follows: 698 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 699 unchanged IPv4/GTP 700 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function 701 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 702 C1_out : (SRGW, U2::1) (A,Z) -> PSP 703 UPF2_out: (A,Z) -> End.DT4 or End.DT6 704 The UE sends a packet destined to Z toward the gNB on a specific 705 bearer for that session. The gNB, which is unmodified, encapsulates 706 the packet into a new IPv4, UDP, and GTP headers. The IPv4 DA, B, 707 and the GTP TEID are the ones received at the N2 interface. 709 When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink 710 Classifier rule for incoming traffic from the gNB, that steers the 711 traffic into an SR policy by using the function H.M.GTP4.D. The SRGW 712 removes the IPv4, UDP, and GTP headers and pushes an IPv6 header with 713 its own SRH containing the SIDs related to the SR policy associated 714 with this traffic. The SRGW forwards according to the new IPv6 DA. 716 S1 and C1 perform their related Endpoint functionality and forward 717 the packet. 719 When the packet arrives at UPF2, the active segment is (U2::1) which 720 is bound to End.DT4/6 which performs the decapsulation (removing the 721 outer IPv6 header with all its extension headers) and forwards toward 722 the data network. 724 5.3.2.2. Packet flow - Downlink 726 The downlink packet flow is as follows: 728 UPF2_in : (Z,A) -> UPF2 maps flow with SID 729 730 UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red 731 C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) 732 S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) 733 SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 734 gNB_out : (Z,A) 736 When a packet destined to A arrives at the UPF2, the UPF2 performs a 737 lookup in the table associated to A and finds the SID list . The UPF2 performs a H.Encaps.Red operation, 739 encapsulating the packet into a new IPv6 header with its 740 corresponding SRH. 742 The nodes C1 and S1 perform their related Endpoint processing. 744 Once the packet arrives at the SRGW, the SRGW identifies the active 745 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 746 and all its extensions headers. The SRGW generates an IPv4, UDP, and 747 GTP headers. The IPv4 SA and DA are received as SID arguments. The 748 TEID in the generated GTP header is also the arguments of the 749 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 750 and forwards the packet toward the gNB. 752 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 753 packet. The gNB looks for the specific radio bearer for that TEID 754 and forwards it on the bearer. This gNB behavior is not modified 755 from current and previous generations. 757 5.3.2.3. Scalability 759 For the downlink traffic, the SRGW is stateless. All the state is in 760 the SRH pushed by the UPF2. The UPF must have this UE-base state 761 anyway (since it is its anchor point). 763 For the uplink traffic, the state at the SRGW is dedicated on a per 764 UE/session basis according to an Uplink Classifier. There is state 765 for steering the different sessions in the form of an SR Policy. 766 However, SR policies are shared among several UE/sessions. 768 5.3.3. Extensions to the interworking mechanisms 770 In this section we presented two mechanisms for interworking with 771 gNBs and UPFs that do not support SRv6. These mechanisms are used to 772 support GTP over IPv4 and IPv6. 774 Even though we have presented these methods as an extension to the 775 "Enhanced mode", it is straightforward in its applicability to the 776 "Traditional mode". 778 Furthermore, although these mechanisms are designed for interworking 779 with legacy RAN at the N3 interface, these methods could also be 780 applied for interworking with a non-SRv6 capable UPF at the N9 781 interface. 783 5.4. SRv6 Drop-in Interworking 785 In this section we introduce another mode useful for legacy gNB and 786 UPFs that still operate with GTP-U. This mode provides an 787 SRv6-enabled user plane in between two GTP-U tunnel endpoints. 789 In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and 790 vice-versa. 792 Unlike other interworking modes, in this mode both of the mobility 793 overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or 794 N9 interface to realize an intermediate SR policy. 796 +----+ 797 -| S1 |- 798 +-----+ / +----+ \ 799 | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ 800 +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | 801 GTP[N3]\ +--------+ / +----+ +--------+ +-----+ 802 -| SRGW-A |- SRv6 SR Gateway-B GTP 803 +--------+ TE 804 SR Gateway-A 806 Figure 7: Example topology for SRv6 Drop-in mode 808 The packet flow of Figure 7 is as follows: 810 gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) 811 GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an 812 End.M.GTP6.D.Di 813 SID at SRGW-A 814 S1_out : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) 815 C1_out : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) 816 GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an 817 End.M.GTP6.E 818 SID at SRGW-B 819 UPF_out : (A,Z) 821 When a packet destined to Z is sent to the gNB, which is unmodified 822 (control-plane and user-plane remain GTP-U), gNB performs 823 encapsulation into a new IP, UDP, and GTP headers. The IPv6 DA, 824 U::1, and the GTP TEID are the ones received at the N2 interface. 826 The IPv6 address that was signaled over the N2 interface for that PDU 827 Session, U::1, is now the IPv6 DA. U::1 is an SRv6 Binding SID at 828 SRGW-A. Hence the packet is routed to the SRGW. 830 When the packet arrives at SRGW-A, the SRGW identifies U::1 as an 831 End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW 832 removes the IPv6, UDP, and GTP headers, and pushes an IPv6 header 833 with its own SRH containing the SIDs bound to the SR policy 834 associated with this Binding SID. There is one instance of the 835 End.M.GTP6.D.Di SID per PDU type. 837 S1 and C1 perform their related Endpoint functionality and forward 838 the packet. 840 Once the packet arrives at SRGW-B, the SRGW identifies the active SID 841 as an End.M.GTP6.E function. The SRGW removes the IPv6 header and 842 all its extensions headers. The SRGW generates new IPv6, UDP, and 843 GTP headers. The new IPv6 DA is U::1 which is the last SID in the 844 received SRH. The TEID in the generated GTP header is an argument of 845 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 846 packet and forwards the packet toward UPF. There is one instance of 847 the End.M.GTP6.E SID per PDU type. 849 Once the packet arrives at UPF, the packet is a regular IPv6/GTP 850 packet. The UPF looks for the specific rule for that TEID to forward 851 the packet. This UPF behavior is not modified from current and 852 previous generations. 854 6. SRv6 Segment Endpoint Mobility Behaviors 856 6.1. Args.Mob.Session 858 Args.Mob.Session provide per-session information for charging, 859 buffering and lawful intercept (among others) required by some mobile 860 nodes. The Args.Mob.Session argument format is used in combination 861 with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 862 behaviors. Note that proposed format is applicable for 5G networks, 863 while similar formats could be used for legacy networks. 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | QFI |R|U| PDU Session ID | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 |PDU Sess(cont')| 871 +-+-+-+-+-+-+-+-+ 873 Args.Mob.Session format 875 o QFI: QoS Flow Identifier [TS.38415] 876 o R: Reflective QoS Indication [TS.23501]. This parameter indicates 877 the activation of reflective QoS towards the UE for the 878 transferred packet. Reflective QoS enables the UE to map UL User 879 Plane traffic to QoS Flows without SMF provided QoS rules. 880 o U: Unused and for future use. MUST be 0 on transmission and 881 ignored on receipt. 882 o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 883 is TEID. 885 Arg.Mob.Session is required in case that one SID aggregates multiple 886 PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated 887 per PDU session, Args.Mob.Session helps the UPF to perform the 888 behaviors which require per QFI and/or per PDU Session granularity. 890 6.2. End.MAP 892 The "Endpoint behavior with SID mapping" behavior (End.MAP for short) 893 is used in several scenarios. Particularly in mobility, End.MAP is 894 used in the UPFs for the PDU Session anchor functionality. 896 When node N receives a packet whose IPv6 DA is S and S is a local 897 End.MAP SID, N does: 899 S01. If (IPv6 Hop Limit <= 1) { 900 S02. Send an ICMP Time Exceeded message to the Source Address, 901 Code 0 (Hop limit exceeded in transit), 902 interrupt packet processing, and discard the packet. 903 S03. } 904 S04. Decrement IPv6 Hop Limit by 1 905 S05. Lookup the IPv6 DA in the mapping table 906 S06. Update the IPv6 DA with the new mapped SID 907 S07. Submit the packet to the egress IPv6 FIB lookup for 908 transmission to the new destination 910 Notes: 911 The SIDs in the SRH are not modified. 913 6.3. End.M.GTP6.D 915 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy" 916 behavior (End.M.GTP6.D for short) is used in interworking scenario 917 for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any 918 SID instance of this behavior is associated with an SR Policy B and 919 an IPv6 Source Address A. 921 When the SR Gateway node N receives a packet destined to S and S is a 922 local End.M.GTP6.D SID, N does: 924 S01. When an SRH is processed { 925 S02. If (Segments Left != 0) { 926 S03. Send an ICMP Parameter Problem to the Source Address, 927 Code 0 (Erroneous header field encountered), 928 Pointer set to the Segments Left field, 929 interrupt packet processing, and discard the packet. 930 S04. } 931 S05. Proceed to process the next header in the packet 932 S06. } 934 When processing the Upper-layer header of a packet matching a FIB 935 entry locally instantiated as an End.M.GTP6.D SID, N does: 937 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 938 S02. Copy the GTP TEID to buffer memory 939 S03. Pop the IPv6, UDP, and GTP Headers 940 S04. Push a new IPv6 header with its own SRH containing B 941 S05. Set the outer IPv6 SA to A 942 S06. Set the outer IPv6 DA to the first SID of B 943 S07. Set the outer Payload Length, Traffic Class, Flow Label, 944 Hop Limit, and Next-Header fields 945 S08. Write in the last SID of the SRH the Args.Mob.Session 946 based on the information of buffer memory 947 S09. Submit the packet to the egress IPv6 FIB lookup and 948 transmission to the new destination 949 S10. } Else { 950 S11. Process as per [RFC8986] Section 4.1.1 951 S12. } 953 Notes: 954 The NH is set based on the SID parameter. There is one instantiation 955 of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already 956 known in advance. For the IPv4v6 PDU Session Type, in addition we 957 inspect the first nibble of the PDU to know the NH value. 959 The prefix of last segment (S3 in above example) SHOULD be followed 960 by an Arg.Mob.Session argument space which is used to provide the 961 session identifiers. 963 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 964 gateway. 966 6.4. End.M.GTP6.D.Di 968 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for 969 Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6 970 drop-in interworking scenario described in Section 5.4. The 971 difference between End.M.GTP6.D as another variant of IPv6/GTP 972 decapsulation function is that the original IPv6 DA of GTP packet is 973 preserved as the last SID in SRH. 975 Any SID instance of this behavior is associated with an SR Policy B 976 and an IPv6 Source Address A. 978 When the SR Gateway node N receives a packet destined to S and S is a 979 local End.M.GTP6.D.Di SID, N does: 981 S01. When an SRH is processed { 982 S02. If (Segments Left != 0) { 983 S03. Send an ICMP Parameter Problem to the Source Address, 984 Code 0 (Erroneous header field encountered), 985 Pointer set to the Segments Left field, 986 interrupt packet processing, and discard the packet. 987 S04. } 988 S05. Proceed to process the next header in the packet 989 S06. } 991 When processing the Upper-layer header of a packet matching a FIB 992 entry locally instantiated as an End.M.GTP6.Di SID, N does: 994 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 995 S02. Copy S to buffer memory 996 S03. Pop the IPv6, UDP, and GTP Headers 997 S04. Push a new IPv6 header with its own SRH containing B 998 S05. Set the outer IPv6 SA to A 999 S06. Set the outer IPv6 DA to the first SID of B 1000 S07. Set the outer Payload Length, Traffic Class, Flow Label, 1001 Hop Limit, and Next-Header fields 1002 S08. Write S to the SRH 1003 S09. Submit the packet to the egress IPv6 FIB lookup and 1004 transmission to the new destination 1005 S10. } Else { 1006 S11. Process as per [RFC8986] Section 4.1.1 1007 S12. } 1009 Notes: 1010 The NH is set based on the SID parameter. There is one instantiation 1011 of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already 1012 known in advance. For the IPv4v6 PDU Session Type, in addition we 1013 inspect the first nibble of the PDU to know the NH value. 1015 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 1016 gateway. 1018 6.5. End.M.GTP6.E 1020 The "Endpoint behavior with encapsulation for IPv6/GTP tunnel" 1021 behavior (End.M.GTP6.E for short) is used in interworking scenario 1022 for the downlink toward the legacy gNB using IPv6/GTP. 1024 The prefix of End.M.GTP6.E SID MUST be followed by the 1025 Arg.Mob.Session argument space which is used to provide the session 1026 identifiers. 1028 When the SR Gateway node N receives a packet destined to S, and S is 1029 a local End.M.GTP6.E SID, N does the following: 1031 S01. When an SRH is processed { 1032 S02. If (Segments Left != 1) { 1033 S03. Send an ICMP Parameter Problem to the Source Address, 1034 Code 0 (Erroneous header field encountered), 1035 Pointer set to the Segments Left field, 1036 interrupt packet processing, and discard the packet. 1037 S04. } 1038 S05. Proceed to process the next header in the packet 1039 S06. } 1041 When processing the Upper-layer header of a packet matching a FIB 1042 entry locally instantiated as an End.M.GTP6.E SID, N does: 1044 S01. Copy SRH[0] and S to buffer memory 1045 S02. Pop the IPv6 header and all its extension headers 1046 S03. Push a new IPv6 header with a UDP/GTP Header 1047 S04. Set the outer IPv6 SA to A 1048 S05. Set the outer IPv6 DA from buffer memory 1049 S06. Set the outer Payload Length, Traffic Class, Flow Label, 1050 Hop Limit, and Next-Header fields 1051 S07. Set the GTP TEID (from buffer memory) 1052 S08. Submit the packet to the egress IPv6 FIB lookup and 1053 transmission to the new destination 1054 S09. } 1056 Notes: 1057 An End.M.GTP6.E SID MUST always be the penultimate SID. 1058 The TEID is extracted from the argument space of the current SID. 1060 The source address A SHOULD be an End.M.GTP6.D SID instantiated at an 1061 SR gateway. 1063 6.6. End.M.GTP4.E 1065 The "Endpoint behavior with encapsulation for IPv4/GTP tunnel" 1066 behavior (End.M.GTP4.E for short) is used in the downlink when doing 1067 interworking with legacy gNB using IPv4/GTP. 1069 When the SR Gateway node N receives a packet destined to S and S is a 1070 local End.M.GTP4.E SID, N does: 1072 S01. When an SRH is processed { 1073 S02. If (Segments Left != 0) { 1074 S03. Send an ICMP Parameter Problem to the Source Address, 1075 Code 0 (Erroneous header field encountered), 1076 Pointer set to the Segments Left field, 1077 interrupt packet processing, and discard the packet. 1078 S04. } 1079 S05. Proceed to process the next header in the packet 1080 S06. } 1082 When processing the Upper-layer header of a packet matching a FIB 1083 entry locally instantiated as an End.M.GTP4.E SID, N does: 1085 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1086 S02. Sotre the IPv6 DA and SA in buffer memory 1087 S03. Pop the IPv6 header and all its extension headers 1088 S04. Push a new IPv4 header with a UDP/GTP Header 1089 S05. Set the outer IPv4 SA and DA (from buffer memory) 1090 S06. Set the outer Total Length, DSCP, Time To Live, and 1091 Next-Header fields 1092 S07. Set the GTP TEID (from buffer memory) 1093 S08. Submit the packet to the egress IPv6 FIB lookup and 1094 transmission to the new destination 1095 S09. } Else { 1096 S10. Process as per [NET-PGM] Section 4.1.1 1097 S11. } 1099 Notes: 1100 The End.M.GTP4.E SID in S has the following format: 1102 0 127 1103 +-----------------------+-------+----------------+---------+ 1104 | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | 1105 +-----------------------+-------+----------------+---------+ 1106 128-a-b-c a b c 1108 End.M.GTP4.E SID Encoding 1110 The IPv6 Source Address has the following format: 1112 0 127 1113 +----------------------+--------+--------------------------+ 1114 | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | 1115 +----------------------+--------+--------------------------+ 1116 128-a-b a b 1118 IPv6 SA Encoding for End.M.GTP4.E 1120 6.7. H.M.GTP4.D 1122 The "SR Policy Headend with tunnel decapsulation and map to an SRv6 1123 policy" behavior (H.M.GTP4.D for short) is used in the direction from 1124 legacy IPv4 user-plane to SRv6 user-plane network. 1126 When the SR Gateway node N receives a packet destined to a IW- 1127 IPv4-Prefix, N does: 1129 S01. IF Payload == UDP/GTP THEN 1130 S02. Pop the outer IPv4 header and UDP/GTP headers 1131 S03. Copy IPv4 DA, TEID to form SID B 1132 S04. Copy IPv4 SA to form IPv6 SA B' 1133 S05. Encapsulate the packet into a new IPv6 header ;;Ref1 1134 S06. Set the IPv6 DA = B 1135 S07. Forward along the shortest path to B 1136 S08. ELSE 1137 S09. Drop the packet 1139 Ref1: The NH value is identified by inspecting the first nibble of 1140 the inner payload. 1142 The SID B has the following format: 1144 0 127 1145 +-----------------------+-------+----------------+---------+ 1146 |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | 1147 +-----------------------+-------+----------------+---------+ 1148 128-a-b-c a b c 1150 H.M.GTP4.D SID Encoding 1152 The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 1153 (U1) to bind an SR policy [I-D.ietf-spring-segment-routing-policy]. 1155 The prefix of B' SHOULD be an End.M.GTP4.E SID with its format 1156 instantiated at an SR gateway with the IPv4 SA of the receiving 1157 packet. 1159 6.8. End.Limit: Rate Limiting behavior 1161 The mobile user-plane requires a rate-limit feature. For this 1162 purpose, we define a new behavior "End.Limit". The "End.Limit" 1163 behavior encodes in its arguments the rate limiting parameter that 1164 should be applied to this packet. Multiple flows of packets should 1165 have the same group identifier in the SID when those flows are in the 1166 same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of 1167 the rate limit segment SID is as follows: 1169 +----------------------+----------+-----------+ 1170 | LOC+FUNC rate-limit | group-id | limit-rate| 1171 +----------------------+----------+-----------+ 1172 128-i-j i j 1174 End.Limit: Rate limiting behavior argument format 1176 If the limit-rate bits are set to zero, the node should not do rate 1177 limiting unless static configuration or control-plane sets the limit 1178 rate associated to the SID. 1180 7. SRv6 supported 3GPP PDU session types 1182 The 3GPP [TS.23501] defines the following PDU session types: 1184 o IPv4 1185 o IPv6 1186 o IPv4v6 1187 o Ethernet 1188 o Unstructured 1190 SRv6 supports the 3GPP PDU session types without any protocol 1191 overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4 1192 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 1193 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU 1194 sessions). 1196 8. Network Slicing Considerations 1198 A mobile network may be required to implement "network slices", which 1199 logically separate network resources. User-plane behaviors 1200 represented as SRv6 segments would be part of a slice. 1202 [I-D.ietf-spring-segment-routing-policy] describes a solution to 1203 build basic network slices with SR. Depending on the requirements, 1204 these slices can be further refined by adopting the mechanisms from: 1206 o IGP Flex-Algo [I-D.ietf-lsr-flex-algo] 1207 o Inter-Domain policies 1208 [I-D.ietf-spring-segment-routing-central-epe] 1210 Furthermore, these can be combined with ODN/AS (On Demand Nexthop/ 1211 Automated Steering) [I-D.ietf-spring-segment-routing-policy] for 1212 automated slice provisioning and traffic steering. 1214 Further details on how these tools can be used to create end to end 1215 network slices are documented in 1216 [I-D.ali-spring-network-slicing-building-blocks]. 1218 9. Control Plane Considerations 1220 This document focuses on user-plane behavior and its independence 1221 from the control plane. 1223 The control plane could be the current 3GPP-defined control plane 1224 with slight modifications to the N4 interface [TS.29244]. 1226 Alternatively, SRv6 could be used in conjunction with a new mobility 1227 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 1228 hICN [I-D.auge-dmm-hicn-mobility-deployment-options] or in 1229 conjunction with FPC [I-D.ietf-dmm-fpc-cpdp]. The analysis of new 1230 mobility control-planes and its applicability to an SRv6 user-plane 1231 is out of the scope of this document. 1233 Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for 1234 the new behaviors defined in this document. 1236 10. Security Considerations 1238 The security considerations for Segment Routing are discussed in 1239 [RFC8402]. More specifically for SRv6 the security considerations 1240 and the mechanisms for securing an SR domain are discussed in 1241 [RFC8754]. Together, they describe the required security mechanisms 1242 that allow establishment of an SR domain of trust to operate 1243 SRv6-based services for internal traffic while preventing any 1244 external traffic from accessing or exploiting the SRv6-based 1245 services. 1247 The technology described in this document is applied to a mobile 1248 network that is within the SR Domain. 1250 This document introduces new SRv6 Endpoint Behaviors. Those 1251 behaviors do not need any special security consideration given that 1252 it is deployed within that SR Domain. 1254 11. IANA Considerations 1256 The following values have been allocated within the "SRv6 Endpoint 1257 Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment 1258 Routing Parameters" registry: 1260 +-------+--------+-------------------+-----------+ 1261 | Value | Hex | Endpoint behavior | Reference | 1262 +-------+--------+-------------------+-----------+ 1263 | 40 | 0x0028 | End.MAP | [This.ID] | 1264 | 41 | 0x0029 | End.Limit | [This.ID] | 1265 | 69 | 0x0045 | End.M.GTP6.D | [This.ID] | 1266 | 70 | 0x0046 | End.M.GTP6.Di | [This.ID] | 1267 | 71 | 0x0047 | End.M.GTP6.E | [This.ID] | 1268 | 72 | 0x0048 | End.M.GTP4.E | [This.ID] | 1269 +-------+--------+-------------------+-----------+ 1271 Table 1: SRv6 Mobile User-plane Endpoint Behavior Types 1273 12. Acknowledgements 1275 The authors would like to thank Daisuke Yokota, Bart Peirens, 1276 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1277 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1278 Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk v. Hugo and 1279 Jeffrey Zhang for their useful comments of this work. 1281 13. Contributors 1283 Kentaro Ebisawa 1284 Toyota Motor Corporation 1285 Japan 1287 Email: ebisawa@toyota-tokyo.tech 1289 Tetsuya Murakami 1290 Arrcus, Inc. 1291 United States of America 1293 Email: tetsuya.ietf@gmail.com 1295 14. References 1297 14.1. Normative References 1299 [I-D.ietf-spring-segment-routing-policy] 1300 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1301 P. Mattes, "Segment Routing Policy Architecture", draft- 1302 ietf-spring-segment-routing-policy-11 (work in progress), 1303 April 2021. 1305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1306 Requirement Levels", BCP 14, RFC 2119, 1307 DOI 10.17487/RFC2119, March 1997, 1308 . 1310 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1311 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1312 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1313 July 2018, . 1315 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1316 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1317 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1318 . 1320 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1321 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1322 (SRv6) Network Programming", RFC 8986, 1323 DOI 10.17487/RFC8986, February 2021, 1324 . 1326 [TS.23501] 1327 3GPP, "System Architecture for the 5G System", 3GPP TS 1328 23.501 15.0.0, November 2017. 1330 14.2. Informative References 1332 [I-D.ali-spring-network-slicing-building-blocks] 1333 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 1334 "Building blocks for Slicing in Segment Routing Network", 1335 draft-ali-spring-network-slicing-building-blocks-04 (work 1336 in progress), February 2021. 1338 [I-D.auge-dmm-hicn-mobility-deployment-options] 1339 Auge, J., Carofiglio, G., Muscariello, L., and M. 1340 Papalini, "Anchorless mobility management through hICN 1341 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1342 mobility-deployment-options-04 (work in progress), July 1343 2020. 1345 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1346 Garvia, P. C., Filsfils, C., Elmalky, H., Matsushima, S., 1347 Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- 1348 Cases", draft-camarilloelmalky-springdmm-srv6-mob- 1349 usecases-02 (work in progress), August 2019. 1351 [I-D.ietf-dmm-fpc-cpdp] 1352 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1353 Moses, D., and C. E. Perkins, "Protocol for Forwarding 1354 Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc- 1355 cpdp-14 (work in progress), September 2020. 1357 [I-D.ietf-lsr-flex-algo] 1358 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1359 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1360 algo-15 (work in progress), April 2021. 1362 [I-D.ietf-spring-segment-routing-central-epe] 1363 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1364 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1365 Engineering", draft-ietf-spring-segment-routing-central- 1366 epe-10 (work in progress), December 2017. 1368 [I-D.ietf-spring-sr-service-programming] 1369 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 1370 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 1371 S. Salsano, "Service Programming with Segment Routing", 1372 draft-ietf-spring-sr-service-programming-04 (work in 1373 progress), March 2021. 1375 [I-D.matsushima-spring-srv6-deployment-status] 1376 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 1377 Rajaraman, "SRv6 Implementation and Deployment Status", 1378 draft-matsushima-spring-srv6-deployment-status-11 (work in 1379 progress), February 2021. 1381 [I-D.rodrigueznatal-lisp-srv6] 1382 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1383 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1384 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-04 1385 (work in progress), July 2020. 1387 [TS.29244] 1388 3GPP, "Interface between the Control Plane and the User 1389 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1391 [TS.29281] 1392 3GPP, "General Packet Radio System (GPRS) Tunnelling 1393 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1394 December 2017. 1396 [TS.38415] 1397 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1398 3GPP R3-174510 0.0.0, August 2017. 1400 Appendix A. Implementations 1402 This document introduces new SRv6 Endpoint Behaviors. These 1403 behaviors have an open-source P4 implementation available in 1404 . 1406 Additionally, a full implementation of this document is available in 1407 Linux Foundation FD.io VPP project since release 20.05. More 1408 information available here: . 1411 There are also experimental implementations in M-CORD NGIC and Open 1412 Air Interface (OAI). 1414 Authors' Addresses 1416 Satoru Matsushima (editor) 1417 SoftBank 1418 Japan 1420 Email: satoru.matsushima@g.softbank.co.jp 1422 Clarence Filsfils 1423 Cisco Systems, Inc. 1424 Belgium 1426 Email: cf@cisco.com 1428 Miya Kohno 1429 Cisco Systems, Inc. 1430 Japan 1432 Email: mkohno@cisco.com 1433 Pablo Camarillo Garvia (editor) 1434 Cisco Systems, Inc. 1435 Spain 1437 Email: pcamaril@cisco.com 1439 Daniel Voyer 1440 Bell Canada 1441 Canada 1443 Email: daniel.voyer@bell.ca 1445 Charles E. Perkins 1446 Lupin Lodge 1447 20600 Aldercroft Heights Rd. 1448 Los Gatos, CA 95033 1449 USA 1451 Email: charliep@computer.org