idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-10.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 (February 19, 2021) is 1161 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 248, but not defined == Missing Reference: 'N2' is mentioned on line 249, but not defined == Missing Reference: 'N4' is mentioned on line 253, but not defined == Missing Reference: 'N3' is mentioned on line 671, but not defined == Missing Reference: 'N9' is mentioned on line 514, but not defined == Missing Reference: 'N6' is mentioned on line 672, but not defined == Missing Reference: 'NET-PGM' is mentioned on line 1085, but not defined -- Looks like a reference, but probably isn't: '0' on line 1031 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-03 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-10 Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group S. Matsushima, Ed. 3 Internet-Draft SoftBank 4 Intended status: Standards Track C. Filsfils 5 Expires: August 23, 2021 M. Kohno 6 P. Camarillo, Ed. 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 February 19, 2021 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-10 17 Abstract 19 This document shows the applicability of SRv6 (Segment Routing IPv6) 20 to the user-plane of mobile networks. The network programming nature 21 of SRv6 accomplish mobile user-plane functions in a simple manner. 22 The statelessness of SRv6 and its ability to control both service 23 layer path and underlying transport can be beneficial to the mobile 24 user-plane, providing flexibility, end-to-end network slicing and SLA 25 control for various applications. This document describes the SRv6 26 mobile user plane. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 23, 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.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 77 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 78 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14 79 5.3.3. Extensions to the interworking mechanisms . . . . . . 17 80 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17 81 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 18 82 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19 83 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 85 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 21 86 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 22 87 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 23 88 6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25 89 6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26 90 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 26 91 8. Network Slicing Considerations . . . . . . . . . . . . . . . 26 92 9. Control Plane Considerations . . . . . . . . . . . . . . . . 27 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 29 99 14.2. Informative References . . . . . . . . . . . . . . . . . 29 100 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 31 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 103 1. Introduction 105 In mobile networks, mobility management systems provide connectivity 106 over a wireless link to stationary and non-stationary nodes. The 107 user-plane establishes a tunnel between the mobile node and its 108 anchor node over IP-based backhaul and core networks. 110 This document shows the applicability of SRv6 (Segment Routing IPv6) 111 to mobile networks. 113 Segment Routing [RFC8402] is a source routing architecture: a node 114 steers a packet through an ordered list of instructions called 115 "segments". A segment can represent any instruction, topological or 116 service based. 118 SRv6 applied to mobile networks enables a source-routing based mobile 119 architecture, where operators can explicitly indicate a route for the 120 packets to and from the mobile node. The SRv6 Endpoint nodes serve 121 as mobile user-plane anchors. 123 2. Conventions and Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2.1. Terminology 131 o CNF: Cloud-native Network Function 132 o NFV: Network Function Virtualization 133 o PDU: Packet Data Unit 134 o PDU Session: Context of an UE connects to a mobile network. 135 o UE: User Equipment 136 o UPF: User Plane Function 137 o VNF: Virtual Network Function (including CNFs) 139 The following terms used within this document are defined in 140 [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6 141 SID, Active Segment, SR Policy, Prefix SID, Adjacency SID and Binding 142 SID. 144 The following terms used within this document are defined in 145 [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint 146 Node and Reduced SRH. 148 The following terms used within this document are defined in 149 [I-D.ietf-spring-srv6-network-programming]: NH, SL, FIB, SA, DA, SRv6 150 SID behavior, SRv6 Segment 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 185 [I-D.ietf-spring-srv6-network-programming]. 187 o End.DT4: Decapsulation and Specific IPv4 Table Lookup 188 o End.DT6: Decapsulation and Specific IPv6 Table Lookup 189 o End.DT46: Decapsulation and Specific IP Table Lookup 190 o End.DX4: Decapsulation and IPv4 Cross-Connect 191 o End.DX6: Decapsulation and IPv6 Cross-Connect 192 o End.DX2: Decapsulation and L2 Cross-Connect 193 o End.T: Endpoint with specific IPv6 Table Lookup 195 This document defines new SRv6 Segment Endpoint Behaviors in 196 Section 6. 198 3. Motivation 200 Mobile networks are becoming more challenging to operate. On one 201 hand, traffic is constantly growing, and latency requirements are 202 tighter; on the other-hand, there are new use-cases like distributed 203 NFVi that are also challenging network operations. 205 The current architecture of mobile networks does not take into 206 account the underlying transport. The user-plane is rigidly 207 fragmented into radio access, core and service networks, connected by 208 tunneling according to user-plane roles such as access and anchor 209 nodes. These factors have made it difficult for the operator to 210 optimize and operate the data-path. 212 In the meantime, applications have shifted to use IPv6, and network 213 operators have started adopting IPv6 as their IP transport. SRv6, 214 the IPv6 dataplane instantiation of Segment Routing [RFC8402], 215 integrates both the application data-path and the underlying 216 transport layer into a single protocol, allowing operators to 217 optimize the network in a simplified manner and removing forwarding 218 state from the network. It is also suitable for virtualized 219 environments, like VNF/CNF to VNF/CNF networking. SRv6 has been 220 deployed in dozens of networks 221 [I-D.matsushima-spring-srv6-deployment-status]. 223 SRv6 defines the network-programming concept 224 [I-D.ietf-spring-srv6-network-programming]. Applied to mobility, 225 SRv6 can provide the user-plane behaviors needed for mobility 226 management. SRv6 takes advantage of the underlying transport 227 awareness and flexibility together with the ability to also include 228 services to optimize the end-to-end mobile dataplane. 230 The use-cases for SRv6 mobility are discussed in 231 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]. 233 4. 3GPP Reference Architecture 235 This section presents a reference architecture and possible 236 deployment scenarios. 238 Figure 1 shows a reference diagram from the 5G packet core 239 architecture [TS.23501]. 241 The user plane described in this document does not depend on any 242 specific architecture. The 5G packet core architecture as shown is 243 based on the latest 3GPP standards at the time of writing this draft. 245 +-----+ 246 | AMF | 247 /+-----+ 248 / | [N11] 249 [N2] / +-----+ 250 +------/ | SMF | 251 / +-----+ 252 / / \ 253 / / \ [N4] 254 / / \ ________ 255 / / \ / \ 256 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 257 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 258 +--+ +-----+ +------+ +------+ \________/ 260 Figure 1: 3GPP 5G Reference Architecture 262 o UE: User Endpoint 263 o gNB: gNodeB with N3 interface towards packet core (and N2 for 264 control plane) 265 o UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane) 266 o UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane) 267 o SMF: Session Management Function 268 o AMF: Access and Mobility Management Function 269 o DN: Data Network e.g. operator services, Internet access 271 This reference diagram does not depict a UPF that is only connected 272 to N9 interfaces, although the mechanisms defined in this document 273 also work in such case. 275 Each session from a UE gets assigned to a UPF. Sometimes multiple 276 UPFs may be used, providing richer service functions. A UE gets its 277 IP address from the DHCP block of its UPF. The UPF advertises that 278 IP address block toward the Internet, ensuring that return traffic is 279 routed to the right UPF. 281 5. User-plane behaviors 283 This section introduces an SRv6 based mobile user-plane. 285 In order to simplify the adoption of SRv6, we present two different 286 "modes" that vary with respect to the use of SRv6. The first one is 287 the "Traditional mode", which inherits the current 3GPP mobile user- 288 plane. In this mode GTP-U protocol [TS.29281] is replaced by SRv6, 289 however the N3, N9 and N6 interfaces are still point-to-point 290 interfaces with no intermediate waypoints as in the current mobile 291 network architecture. 293 The second mode is the "Enhanced mode". This is an evolution from 294 the "Traditional mode". In this mode the N3, N9 or N6 interfaces 295 have intermediate waypoints -SIDs- that are used for Traffic 296 Engineering or VNF purposes. This results in optimal end-to-end 297 policies across the mobile network with transport and services 298 awareness. 300 In both, the Traditional and the Enhanced modes, we assume that the 301 gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6 302 interfaces are SRv6). 304 In addition to those two modes, we introduce two mechanisms for 305 interworking with legacy access networks (those where the N3 306 interface is unmodified). In this document we introduce them as a 307 variant to the Enhanced mode, however they are equally applicable to 308 the Traditional mode. 310 One of these mechanisms is designed to interwork with legacy gNBs 311 using GTP/IPv4. The second mechanism is designed to interwork with 312 legacy gNBs using GTP/IPv6. 314 This document uses SRv6 Segment Endpoint Behaviors defined in 315 [I-D.ietf-spring-srv6-network-programming] as well as new SRv6 316 Segment Endpoint Behaviors designed for the mobile user plane that 317 are defined in this document in Section 6. 319 5.1. Traditional mode 321 In the traditional mode, the existing mobile UPFs remain unchanged 322 with the sole exception of the use of SRv6 as the data plane instead 323 of GTP-U. There is no impact to the rest of the mobile system. 325 In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 326 with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored 327 here to replace GTP encapsulation with the SRv6 encapsulation, while 328 not changing anything else. There will be a unique SRv6 SID 329 associated with each PDU Session. 331 The traditional mode minimizes the changes required to the mobile 332 system; hence it is a good starting point for forming a common 333 ground. 335 Our example topology is shown in Figure 2. In traditional mode the 336 gNB and the UPFs are SR-aware. In the descriptions of the uplink and 337 downlink packet flow, A is an IPv6 address of the UE, and Z is an 338 IPv6 address reachable within the Data Network DN. A new SRv6 339 Endpoint Behavior, End.MAP, defined in Section 6.2, is used. 341 ________ 342 SRv6 SRv6 / \ 343 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 344 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 345 +--+ +-----+ +------+ +------+ \________/ 346 SRv6 node SRv6 node SRv6 node 348 Figure 2: Traditional mode - example topology 350 5.1.1. Packet flow - Uplink 352 The uplink packet flow is as follows: 354 UE_out : (A,Z) 355 gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red 356 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 357 UPF2_out: (A,Z) -> End.DT4 or End.DT6 359 When the UE packet arrives at the gNB, the gNB performs a 360 H.Encaps.Red operation. Since there is only one SID, there is no 361 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 362 U1::1. U1::1 represents an anchoring SID specific for that session 363 at UPF1. gNB obtains the SID U1::1 from the existing control plane 364 (N2 interface). 366 When the packet arrives at UPF1, the SID U1::1 is associated with the 367 End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1, 368 that belongs to the next UPF (U2). 370 When the packet arrives at UPF2, the SID U2::1 corresponds to an 371 End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates 372 the packet, performs a lookup in a specific table associated with 373 that mobile network and forwards the packet toward the data network 374 (DN). 376 5.1.2. Packet flow - Downlink 378 The downlink packet flow is as follows: 380 UPF2_in : (Z,A) 381 UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red 382 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 383 gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2 385 When the packet arrives at the UPF2, the UPF2 maps that flow into a 386 PDU Session. This PDU Session is associated with the segment 387 endpoint . UPF2 performs a H.Encaps.Red operation, 388 encapsulating the packet into a new IPv6 header with no SRH since 389 there is only one SID. 391 Upon packet arrival on UPF1, the SID U1::2 is a local SID associated 392 with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next 393 anchoring point and replaces U1::2 by gNB::1, that belongs to the 394 next hop. 396 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4, 397 End.DX6 or End.DX2 behavior (depending on the PDU Session Type). The 398 gNB decapsulates the packet, removing the IPv6 header and all its 399 extensions headers, and forwards the traffic toward the UE. 401 5.2. Enhanced Mode 403 Enhanced mode improves scalability, provides traffic engineering 404 capabilities and allows service programming 405 [I-D.ietf-spring-sr-service-programming], thanks to the use of 406 multiple SIDs in the SID list (instead of a direct connectivity in 407 between UPFs with no intermediate waypoints as in Traditional Mode). 409 Thus, the main difference is that the SR policy MAY include SIDs for 410 traffic engineering and service programming in addition to the 411 anchoring SIDs at UPFs. 413 Additionally in this mode the operator may choose to aggregate 414 several devices under the same SID list (e.g., stationary residential 415 meters connected to the same cell) to improve scalability. 417 The gNB control-plane (N2 interface) is unchanged, specifically a 418 single IPv6 address is provided to the gNB. 420 The gNB MAY resolve the IP address received via the control plane 421 into a SID list using a mechanism like PCEP, DNS-lookup, LISP 422 control-plane or others. The resolution mechanism is out of the 423 scope of this document. 425 Note that the SIDs MAY use the arguments Args.Mob.Session if required 426 by the UPFs. 428 Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 429 gNB and the UPF are SR-aware. The Figure shows two service segments, 430 S1 and C1. S1 represents a VNF in the network, and C1 represents an 431 intermediate router used for Traffic Engineering purposes to enforce 432 a low-latency path in the network. Note that both S1 and C1 are not 433 required to have an N4 interface. 435 +----+ SRv6 _______ 436 SRv6 --| C1 |--[N3] / \ 437 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 438 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 439 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 440 SRv6 node \ +----+ / SRv6 node 441 -| S1 |- 442 +----+ 443 SRv6 node 444 VNF 446 Figure 3: Enhanced mode - Example topology 448 5.2.1. Packet flow - Uplink 450 The uplink packet flow is as follows: 452 UE_out : (A,Z) 453 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)->H.Encaps.Red 454 S1_out : (gNB, C1)(U2::1, C1; SL=1)(A,Z) 455 C1_out : (gNB, U2::1)(A,Z) ->End with PSP 456 UPF2_out: (A,Z) ->End.DT4,End.DT6,End.DT2U 458 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 459 control plane associates that session from the UE(A) with the IPv6 460 address B. gNB's control plane does a lookup on B to find the 461 related SID list . 463 When gNB transmits the packet, it contains all the segments of the SR 464 policy. The SR policy includes segments for traffic engineering (C1) 465 and for service programming (S1). 467 Nodes S1 and C1 perform their related Endpoint functionality and 468 forward the packet. 470 When the packet arrives at UPF2, the active segment (U2::1) is an 471 End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing 472 the IPv6 header with all its extension headers) and forwards toward 473 the data network. 475 5.2.2. Packet flow - Downlink 477 The downlink packet flow is as follows: 479 UPF2_in : (Z,A) ->UPF2 maps the flow w/ 480 SID list 481 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) ->H.Encaps.Red 482 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 483 S1_out : (U2::1, gNB)(Z,A) ->End with PSP 484 gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 486 When the packet arrives at the UPF2, the UPF2 maps that particular 487 flow into a UE PDU Session. This UE PDU Session is associated with 488 the policy . The UPF2 performs a H.Encaps.Red 489 operation, encapsulating the packet into a new IPv6 header with its 490 corresponding SRH. 492 The nodes C1 and S1 perform their related Endpoint processing. 494 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 495 End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the 496 underlying traffic). The gNB decapsulates the packet, removing the 497 IPv6 header and forwards the traffic toward the UE. 499 5.3. Enhanced mode with unchanged gNB GTP behavior 501 This section describes three mechanisms for interworking with legacy 502 gNBs that still use GTP: one for IPv4, and two other for IPv6. 504 In the interworking scenarios as illustrated in Figure 4, the gNB 505 does not support SRv6. The gNB supports GTP encapsulation over IPv4 506 or IPv6. To achieve interworking, a SR Gateway (SRGW-UPF1) entity is 507 added. The SRGW maps the GTP traffic into SRv6. 509 The SRGW is not an anchor point and maintains very little state. For 510 this reason, both IPv4 and IPv6 methods scale to millions of UEs. 512 _______ 513 IP GTP SRv6 / \ 514 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 515 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 516 +--+ +-----+ +------+ +------+ \_______/ 517 SR Gateway SRv6 node 519 Figure 4: Example topology for interworking 521 Both of the mechanisms described in this section are applicable to 522 either the Traditional Mode or the Enhanced Mode. 524 5.3.1. Interworking with IPv6 GTP 526 In this interworking mode the gNB at the N3 interface uses GTP over 527 IPv6. 529 Key points: 531 o The gNB is unchanged (control-plane or user-plane) and 532 encapsulates into GTP (N3 interface is not modified). 533 o The 5G Control-Plane (N2 interface) is unmodified; one IPv6 534 address is needed (i.e. a BSID at the SRGW). 535 o The SRGW removes GTP, finds the SID list related to the IPv6 DA, 536 and adds SRH with the SID list. 537 o There is no state for the downlink at the SRGW. 538 o There is simple state in the uplink at the SRGW; using Enhanced 539 mode results in fewer SR policies on this node. An SR policy is 540 shared across UEs. 541 o When a packet from the UE leaves the gNB, it is SR-routed. This 542 simplifies network slicing [I-D.ietf-lsr-flex-algo]. 543 o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic 544 into an SR policy when it arrives at the SRGW-UPF1. 546 An example topology is shown in Figure 5. 548 S1 and C1 are two service segments. S1 represents a VNF in the 549 network, and C1 represents a router configured for Traffic 550 Engineering. 552 +----+ 553 IPv6/GTP -| S1 |- ___ 554 +--+ +-----+ [N3] / +----+ \ / 555 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 556 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 557 GTP \ +------+ / +----+ +------+ \___ 558 -| UPF1 |- SRv6 SRv6 559 +------+ TE 560 SR Gateway 562 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 564 5.3.1.1. Packet flow - Uplink 566 The uplink packet flow is as follows: 568 UE_out : (A,Z) 569 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 570 (IPv6/GTP) 571 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 572 SID at the SRGW 573 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 574 C1_out : (SRGW, U2::1)(A,Z) -> End with PSP 575 UPF2_out: (A,Z) -> End.DT4 or End.DT6 577 The UE sends a packet destined to Z toward the gNB on a specific 578 bearer for that session. The gNB, which is unmodified, encapsulates 579 the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the 580 GTP TEID T are the ones received in the N2 interface. 582 The IPv6 address that was signaled over the N2 interface for that UE 583 PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 584 SRGW. Hence the packet is routed to the SRGW. 586 When the packet arrives at the SRGW, the SRGW identifies B as an 587 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 588 the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own 589 SRH containing the SIDs bound to the SR policy associated with this 590 BindingSID. There is one instance of the End.M.GTP6.D SID per PDU 591 type. 593 S1 and C1 perform their related Endpoint functionality and forward 594 the packet. 596 When the packet arrives at UPF2, the active segment is (U2::1) which 597 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 598 IPv6 header with all its extension headers) and forwards the packet 599 toward the data network. 601 5.3.1.2. Packet flow - Downlink 603 The downlink packet flow is as follows: 605 UPF2_in : (Z,A) -> UPF2 maps the flow with 606 607 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red 608 C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) 609 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 610 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 611 gNB_out : (Z,A) 613 When a packet destined to A arrives at the UPF2, the UPF2 performs a 614 lookup in the table associated to A and finds the SID list . The UPF2 performs an H.Encaps.Red operation, 616 encapsulating the packet into a new IPv6 header with its 617 corresponding SRH. 619 C1 and S1 perform their related Endpoint processing. 621 Once the packet arrives at the SRGW, the SRGW identifies the active 622 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 623 and all its extensions headers. The SRGW generates new IPv6, UDP and 624 GTP headers. The new IPv6 DA is the gNB which is the last SID in the 625 received SRH. The TEID in the generated GTP header is an argument of 626 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 627 packet and forwards the packet toward the gNB. There is one instance 628 of the End.M.GTP6.E SID per PDU type. 630 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 631 packet. The gNB looks for the specific radio bearer for that TEID 632 and forward it on the bearer. This gNB behavior is not modified from 633 current and previous generations. 635 5.3.1.3. Scalability 637 For the downlink traffic, the SRGW is stateless. All the state is in 638 the SRH inserted by the UPF2. The UPF2 must have the UE states since 639 it is the UE's session anchor point. 641 For the uplink traffic, the state at the SRGW does not necessarily 642 need to be unique per PDU Session; the SR policy can be shared among 643 UEs. This enables more scalable SRGW deployments compared to a 644 solution holding millions of states, one or more per UE. 646 5.3.2. Interworking with IPv4 GTP 648 In this interworking mode the gNB uses GTP over IPv4 in the N3 649 interface 651 Key points: 653 o The gNB is unchanged and encapsulates packets into GTP (the N3 654 interface is not modified). 655 o In the uplink, traffic is classified by SRGW's Uplink Classifier 656 and steered into an SR policy. The SRGW is a UPF1 functionality 657 and can coexist with UPF1's Uplink Classifier functionality. 658 o SRGW removes GTP, finds the SID list related to DA, and adds a SRH 659 with the SID list. 661 An example topology is shown in Figure 6. In this mode the gNB is an 662 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 663 the SRGW maps the IPv4/GTP traffic to SRv6. 665 S1 and C1 are two service segment endpoints. S1 represents a VNF in 666 the network, and C1 represents a router configured for Traffic 667 Engineering. 669 +----+ 670 IPv4/GTP -| S1 |- ___ 671 +--+ +-----+ [N3] / +----+ \ / 672 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 673 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 674 GTP \ +------+ / +----+ +------+ \___ 675 -| UPF1 |- SRv6 SRv6 676 +------+ TE 677 SR Gateway 679 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 681 5.3.2.1. Packet flow - Uplink 683 The uplink packet flow is as follows: 685 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 686 unchanged IPv4/GTP 687 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function 688 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 689 C1_out : (SRGW, U2::1) (A,Z) -> PSP 690 UPF2_out: (A,Z) -> End.DT4 or End.DT6 692 The UE sends a packet destined to Z toward the gNB on a specific 693 bearer for that session. The gNB, which is unmodified, encapsulates 694 the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and 695 the GTP TEID are the ones received at the N2 interface. 697 When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink 698 Classifier rule for incoming traffic from the gNB, that steers the 699 traffic into an SR policy by using the function H.M.GTP4.D. The SRGW 700 removes the IPv4, UDP and GTP headers and pushes an IPv6 header with 701 its own SRH containing the SIDs related to the SR policy associated 702 with this traffic. The SRGW forwards according to the new IPv6 DA. 704 S1 and C1 perform their related Endpoint functionality and forward 705 the packet. 707 When the packet arrives at UPF2, the active segment is (U2::1) which 708 is bound to End.DT4/6 which performs the decapsulation (removing the 709 outer IPv6 header with all its extension headers) and forwards toward 710 the data network. 712 5.3.2.2. Packet flow - Downlink 714 The downlink packet flow is as follows: 716 UPF2_in : (Z,A) -> UPF2 maps flow with SID 717 718 UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red 719 C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) 720 S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) 721 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 722 gNB_out : (Z,A) 724 When a packet destined to A arrives at the UPF2, the UPF2 performs a 725 lookup in the table associated to A and finds the SID list . The UPF2 performs a H.Encaps.Red operation, 727 encapsulating the packet into a new IPv6 header with its 728 corresponding SRH. 730 The nodes C1 and S1 perform their related Endpoint processing. 732 Once the packet arrives at the SRGW, the SRGW identifies the active 733 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 734 and all its extensions headers. The SRGW generates an IPv4, UDP and 735 GTP headers. The IPv4 SA and DA are received as SID arguments. The 736 TEID in the generated GTP header is also the arguments of the 737 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 738 and forwards the packet toward the gNB. 740 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 741 packet. The gNB looks for the specific radio bearer for that TEID 742 and forward it on the bearer. This gNB behavior is not modified from 743 current and previous generations. 745 5.3.2.3. Scalability 747 For the downlink traffic, the SRGW is stateless. All the state is in 748 the SRH inserted by the UPF. The UPF must have this UE-base state 749 anyway (since it is its anchor point). 751 For the uplink traffic, the state at the SRGW is dedicated on a per 752 UE/session basis according to an Uplink Classifier. There is state 753 for steering the different sessions in the form of a SR Policy. 754 However, SR policies are shared among several UE/sessions. 756 5.3.3. Extensions to the interworking mechanisms 758 In this section we presented three mechanisms for interworking with 759 gNBs and UPFs that do not support SRv6. These mechanisms are used to 760 support GTP over IPv4 and IPv6. 762 Even though we have presented these methods as an extension to the 763 "Enhanced mode", it is straightforward in its applicability to the 764 "Traditional mode". 766 Furthermore, although these mechanisms are designed for interworking 767 with legacy RAN at the N3 interface, these methods could also be 768 applied for interworking with a non-SRv6 capable UPF at the N9 769 interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). 771 5.4. SRv6 Drop-in Interworking 773 In this section we introduce another mode useful for legacy gNB and 774 UPFs that still operate with GTP-U. This mode provides an 775 SRv6-enabled user plane in between two GTP-U tunnel endpoints. 777 In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and 778 vice-versa. 780 Unlike other interworking modes, in this mode both of the mobility 781 overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or 782 N9 interface to realize an intermediate SR policy. 784 +----+ 785 -| S1 |- 786 +-----+ / +----+ \ 787 | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ 788 +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | 789 GTP[N3]\ +--------+ / +----+ +--------+ +-----+ 790 -| SRGW-A |- SRv6 SR Gateway-B GTP 791 +--------+ TE 792 SR Gateway-A 794 Figure 7: Example topology for SRv6 Drop-in mode 796 The packet flow of Figure 7 is as follows: 798 gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) 799 GW-A_out: (SRGW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an 800 End.M.GTP6.D.Di 801 SID at SRGW-A 802 S1_out : (SRGW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) 803 C1_out : (SRGW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) 804 GW-B_out: (SRGW-B, U::1)(GTP: TEID T)(A,Z) ->U1b::TEID is an 805 End.M.GTP6.E 806 SID at SRGW-B 807 UPF_out : (A,Z) 809 When a packet destined to Z to the gNB, which is unmodified, it 810 performs encapsulation into a new IP, UDP and GTP headers. The IPv6 811 DA, U::1, and the GTP TEID are the ones received at the N2 interface. 813 The IPv6 address that was signaled over the N2 interface for that PDU 814 Session, U::1, is now the IPv6 DA. U2b:: is an SRv6 Binding SID at 815 SRGW-A. Hence the packet is routed to the SRGW. 817 When the packet arrives at SRGW-A, the SRGW identifies U2b:: as an 818 End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW 819 removes the IPv6, UDP and GTP headers, and pushes an IPv6 header with 820 its own SRH containing the SIDs bound to the SR policy associated 821 with this Binding SID. There is one instance of the End.M.GTP6.D.Di 822 SID per PDU type. 824 S1 and C1 perform their related Endpoint functionality and forward 825 the packet. 827 Once the packet arrives at SRGW-B, the SRGW identifies the active SID 828 as an End.M.GTP6.E function. The SRGW removes the IPv6 header and 829 all its extensions headers. The SRGW generates new IPv6, UDP and GTP 830 headers. The new IPv6 DA is U::1 which is the last SID in the 831 received SRH. The TEID in the generated GTP header is an argument of 832 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 833 packet and forwards the packet toward UPF2b. There is one instance 834 of the End.M.GTP6.E SID per PDU type. 836 Once the packet arrives at UPF2b, the packet is a regular IPv6/GTP 837 packet. The UPF looks for the specific rule for that TEID to forward 838 the packet. This UPF behavior is not modified from current and 839 previous generations. 841 6. SRv6 Segment Endpoint Mobility Behaviors 842 6.1. Args.Mob.Session 844 Args.Mob.Session provide per-session information for charging, 845 buffering and lawful intercept (among others) required by some mobile 846 nodes. The Args.Mob.Session argument format is used in combination 847 with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 848 behaviors. Note that proposed format is applicable for 5G networks, 849 while similar formats could be used for legacy networks. 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | QFI |R|U| PDU Session ID | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 |PDU Sess(cont')| 857 +-+-+-+-+-+-+-+-+ 859 Args.Mob.Session format 861 o QFI: QoS Flow Identifier [TS.38415] 862 o R: Reflective QoS Indication [TS.23501]. This parameter indicates 863 the activation of reflective QoS towards the UE for the 864 transferred packet. Reflective QoS enables the UE to map UL User 865 Plane traffic to QoS Flows without SMF provided QoS rules. 866 o U: Unused and for future use. MUST be 0 on transmission and 867 ignored on receipt. 868 o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 869 is TEID. 871 Arg.Mob.Session is required in case that one SID aggregates multiple 872 PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated 873 per PDU session, Args.Mob.Session helps the UPF to perform the 874 behaviors which require per QFI and/or per PDU Session granularity. 876 6.2. End.MAP 878 The "Endpoint behavior with SID mapping" behavior (End.MAP for short) 879 is used in several scenarios. Particularly in mobility, End.MAP is 880 used in the UPFs for the PDU Session anchor functionality. 882 When N receives a packet whose IPv6 DA is S and S is a local End.MAP 883 SID, N does: 885 S01. If (IPv6 Hop Limit <= 1) { 886 S02. Send an ICMP Time Exceeded message to the Source Address, 887 Code 0 (Hop limit exceeded in transit), 888 interrupt packet processing and discard the packet. 889 S03. } 890 S04. Decrement IPv6 Hop Limit by 1 891 S05. Lookup the IPv6 DA in the mapping table 892 S06. Update the IPv6 DA with the new mapped SID 893 S07. Submit the packet to the egress IPv6 FIB lookup for 894 transmission to the new destination 896 Notes: 897 The SIDs in the SRH are not modified. 899 6.3. End.M.GTP6.D 901 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy" 902 behavior (End.M.GTP6.D for short) is used in interworking scenario 903 for the uplink toward from the legacy gNB using IPv6/GTP. Suppose, 904 for example, this SID is associated with an SR policy B and an IPv6 905 Source Address A. 907 When the SR Gateway node N receives a packet destined to S and S is a 908 local End.M.GTP6.D SID, N does: 910 S01. When an SRH is processed { 911 S02. If (Segments Left != 0) { 912 S03. Send an ICMP Parameter Problem to the Source Address, 913 Code 0 (Erroneous header field encountered), 914 Pointer set to the Segments Left field, 915 interrupt packet processing and discard the packet. 916 S04. } 917 S05. Proceed to process the next header in the packet 918 S06. } 920 When processing the Upper-layer header of a packet matching a FIB 921 entry locally instantiated as an End.M.GTP6.D SID, N does: 923 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 924 S02. Copy the GTP TEID to buffer memory 925 S03. Pop the IPv6, UDP and GTP Headers 926 S04. Push a new IPv6 header with its own SRH containing B 927 S05. Set the outer IPv6 SA to A 928 S06. Set the outer IPv6 DA to the first SID of B 929 S07. Set the outer Payload Length, Traffic Class, Flow Label, 930 Hop Limit and Next-Header fields 931 S08. Write in the last SID of the SRH the Args.Mob.Session 932 based on the information of buffer memory 933 S09. Submit the packet to the egress IPv6 FIB lookup and 934 transmission to the new destination 935 S10. } Else { 936 S11. Process as per [NET-PGM] Section 4.1.1 937 S12. } 939 Notes: 940 The NH is set based on the SID parameter. There is one instantiation 941 of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already 942 known in advance. For the IPv4v6 PDU Session Type, in addition we 943 inspect the first nibble of the PDU to know the NH value. 945 The prefix of last segment (S3 in above example) SHOULD be followed 946 by an Arg.Mob.Session argument space which is used to provide the 947 session identifiers. 949 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 950 gateway. 952 6.4. End.M.GTP6.D.Di 954 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for 955 Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6 956 drop-in interworking scenario described in Section 5.4. The 957 difference between End.M.GTP6.D as another variant of IPv6/GTP 958 decapsulation function is that the original IPv6 DA of GTP packet is 959 preserved as the last SID in SRH. 961 Any SID instance of this behavior is associated with an SR Policy B 962 and an IPv6 Source Address A. 964 When the SR Gateway node N receives a packet destined to S and S is a 965 local End.M.GTP6.D.Di SID, N does: 967 S01. When an SRH is processed { 968 S02. If (Segments Left != 0) { 969 S03. Send an ICMP Parameter Problem to the Source Address, 970 Code 0 (Erroneous header field encountered), 971 Pointer set to the Segments Left field, 972 interrupt packet processing and discard the packet. 973 S04. } 974 S05. Proceed to process the next header in the packet 975 S06. } 977 When processing the Upper-layer header of a packet matching a FIB 978 entry locally instantiated as an End.M.GTP6.Di SID, N does: 980 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 981 S02. Copy S to buffer memory 982 S03. Pop the IPv6, UDP and GTP Headers 983 S04. Push a new IPv6 header with its own SRH containing B 984 S05. Set the outer IPv6 SA to A 985 S06. Set the outer IPv6 DA to the first SID of B 986 S07. Set the outer Payload Length, Traffic Class, Flow Label, 987 Hop Limit and Next-Header fields 988 S08. Write S to the SRH 989 S09. Submit the packet to the egress IPv6 FIB lookup and 990 transmission to the new destination 991 S10. } Else { 992 S11. Process as per [NET-PGM] Section 4.1.1 993 S12. } 995 Notes: 996 The NH is set based on the SID parameter. There is one instantiation 997 of the End.M.GTP6.D SID per PDU Session Type, hence the NH is already 998 known in advance. For the IPv4v6 PDU Session Type, in addition we 999 inspect the first nibble of the PDU to know the NH value. 1001 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 1002 gateway. 1004 6.5. End.M.GTP6.E 1006 The "Endpoint behavior with encapsulation for IPv6/GTP tunnel" 1007 behavior (End.M.GTP6.E for short) is used in interworking scenario 1008 for the downlink toward the legacy gNB using IPv6/GTP. 1010 The prefix of End.M.GTP6.E SID MUST be followed by the 1011 Arg.Mob.Session argument space which is used to provide the session 1012 identifiers. 1014 When the SR Gateway node N receives a packet destined to S, and S is 1015 a local End.M.GTP6.E SID, N does the following: 1017 S01. When an SRH is processed { 1018 S02. If (Segments Left != 1) { 1019 S03. Send an ICMP Parameter Problem to the Source Address, 1020 Code 0 (Erroneous header field encountered), 1021 Pointer set to the Segments Left field, 1022 interrupt packet processing and discard the packet. 1023 S04. } 1024 S05. Proceed to process the next header in the packet 1025 S06. } 1027 When processing the Upper-layer header of a packet matching a FIB 1028 entry locally instantiated as an End.M.GTP6.E SID, N does: 1030 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1031 S02. Copy SRH[0] to buffer memory 1032 S03. Pop the IPv6 header and all its extension headers 1033 S04. Push a new IPv6 header with a UDP/GTP Header 1034 S05. Set the outer IPv6 SA to A 1035 S06. Set the outer IPv6 DA to the first SID of B 1036 S07. Set the outer Payload Length, Traffic Class, Flow Label, 1037 Hop Limit and Next-Header fields 1038 S08. Set the GTP TEID (from buffer memory) 1039 S09. Submit the packet to the egress IPv6 FIB lookup and 1040 transmission to the new destination 1041 S10. } Else { 1042 S11. Process as per [NET-PGM] Section 4.1.1 1043 S12. } 1045 Notes: 1046 An End.M.GTP6.E SID MUST always be the penultimate SID. 1047 The TEID is extracted from the argument space of the current SID. 1049 The source address A SHOULD be an End.M.GTP6.D SID instantiated at an 1050 SR gateway. 1052 6.6. End.M.GTP4.E 1054 The "Endpoint behavior with encapsulation for IPv4/GTP tunnel" 1055 behavior (End.M.GTP4.E for short) is used in the downlink when doing 1056 interworking with legacy gNB using IPv4/GTP. 1058 When the SR Gateway node N receives a packet destined to S and S is a 1059 local End.M.GTP4.E SID, N does: 1061 S01. When an SRH is processed { 1062 S02. If (Segments Left != 0) { 1063 S03. Send an ICMP Parameter Problem to the Source Address, 1064 Code 0 (Erroneous header field encountered), 1065 Pointer set to the Segments Left field, 1066 interrupt packet processing and discard the packet. 1067 S04. } 1068 S05. Proceed to process the next header in the packet 1069 S06. } 1071 When processing the Upper-layer header of a packet matching a FIB 1072 entry locally instantiated as an End.M.GTP4.E SID, N does: 1074 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1075 S02. Sotre the IPv6 DA and SA in buffer memory 1076 S03. Pop the IPv6 header and all its extension headers 1077 S04. Push a new IPv4 header with a UDP/GTP Header 1078 S05. Set the outer IPv4 SA and DA (from buffer memory) 1079 S06. Set the outer Total Length, DSCP, Time To Live and 1080 Next-Header fields 1081 S07. Set the GTP TEID (from buffer memory) 1082 S08. Submit the packet to the egress IPv6 FIB lookup and 1083 transmission to the new destination 1084 S09. } Else { 1085 S10. Process as per [NET-PGM] Section 4.1.1 1086 S11. } 1088 Notes: 1089 The End.M.GTP4.E SID in S has the following format: 1091 0 127 1092 +-----------------------+-------+----------------+---------+ 1093 | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | 1094 +-----------------------+-------+----------------+---------+ 1095 128-a-b-c a b c 1097 End.M.GTP4.E SID Encoding 1099 S' has the following format: 1101 0 127 1102 +----------------------+--------+--------------------------+ 1103 | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | 1104 +----------------------+--------+--------------------------+ 1105 128-a-b a b 1107 IPv6 SA Encoding for End.M.GTP4.E 1109 6.7. H.M.GTP4.D 1111 The "SR Policy Headend with tunnel decapsulation and map to an SRv6 1112 policy" behavior (H.M.GTP4.D for short) is used in the direction from 1113 legacy IPv4 user-plane to SRv6 user-plane network. 1115 When the SR Gateway node N receives a packet destined to a IW- 1116 IPv4-Prefix, N does: 1118 S01. IF Payload == UDP/GTP THEN 1119 S02. Pop the outer IPv4 header and UDP/GTP headers 1120 S03. Copy IPv4 DA, TEID to form SID B 1121 S04. Copy IPv4 SA to form IPv6 SA B' 1122 S05. Encapsulate the packet into a new IPv6 header ;;Ref1 1123 S06. Set the IPv6 DA = B 1124 S07. Forward along the shortest path to B 1125 S08. ELSE 1126 S09. Drop the packet 1128 Ref1: The NH value is identified by inspecting the first nibble of 1129 the inner payload. 1131 The SID B has the following format: 1133 0 127 1134 +-----------------------+-------+----------------+---------+ 1135 |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | 1136 +-----------------------+-------+----------------+---------+ 1137 128-a-b-c a b c 1139 H.M.GTP4.D SID Encoding 1141 The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 1142 (U1) to bind a SR policy [I-D.ietf-spring-segment-routing-policy]. 1144 The prefix of B' SHOULD be an End.M.GTP4.E SID with its format 1145 instantiated at an SR gateway with the IPv4 SA of the receiving 1146 packet. 1148 6.8. End.Limit: Rate Limiting behavior 1150 The mobile user-plane requires a rate-limit feature. For this 1151 purpose, we define a new behavior "End.Limit". The "End.Limit" 1152 behavior encodes in its arguments the rate limiting parameter that 1153 should be applied to this packet. Multiple flows of packets should 1154 have the same group identifier in the SID when those flows are in an 1155 same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of 1156 the rate limit segment SID is as follows: 1158 +----------------------+----------+-----------+ 1159 | LOC+FUNC rate-limit | group-id | limit-rate| 1160 +----------------------+----------+-----------+ 1161 128-i-j i j 1163 End.Limit: Rate limiting behavior argument format 1165 If the limit-rate bits are set to zero, the node should not do rate 1166 limiting unless static configuration or control-plane sets the limit 1167 rate associated to the SID. 1169 7. SRv6 supported 3GPP PDU session types 1171 The 3GPP [TS.23501] defines the following PDU session types: 1173 o IPv4 1174 o IPv6 1175 o IPv4v6 1176 o Ethernet 1177 o Unstructured 1179 SRv6 supports the 3GPP PDU session types without any protocol 1180 overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4 1181 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 1182 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU 1183 sessions). 1185 8. Network Slicing Considerations 1187 A mobile network may be required to implement "network slices", which 1188 logically separate network resources. User-plane behaviors 1189 represented as SRv6 segments would be part of a slice. 1191 [I-D.ietf-spring-segment-routing-policy] describes a solution to 1192 build basic network slices with SR. Depending on the requirements, 1193 these slices can be further refined by adopting the mechanisms from: 1195 o IGP Flex-Algo [I-D.ietf-lsr-flex-algo] 1196 o Inter-Domain policies 1197 [I-D.ietf-spring-segment-routing-central-epe] 1199 Furthermore, these can be combined with ODN/AS 1200 [I-D.ietf-spring-segment-routing-policy] for automated slice 1201 provisioning and traffic steering. 1203 Further details on how these tools can be used to create end to end 1204 network slices are documented in 1205 [I-D.ali-spring-network-slicing-building-blocks]. 1207 9. Control Plane Considerations 1209 This document focuses on user-plane behavior and its independence 1210 from the control plane. 1212 The control plane could be the current 3GPP-defined control plane 1213 with slight modifications to the N4 interface [TS.29244]. 1215 Alternatively, SRv6 could be used in conjunction with a new mobility 1216 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 1217 hICN [I-D.auge-dmm-hicn-mobility-deployment-options] or in 1218 conjunction with FPC [I-D.ietf-dmm-fpc-cpdp]. The analysis of new 1219 mobility control-planes and its applicability to an SRv6 user-plane 1220 is out of the scope of this document. 1222 Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for 1223 the new behaviors defined in this document. 1225 10. Security Considerations 1227 The security considerations for Segment Routing are discussed in 1228 [RFC8402]. More specifically for SRv6 the security considerations 1229 and the mechanisms for securing an SR domain are discussed in 1230 [RFC8754]. Together, they describe the required security mechanisms 1231 that allow establishment of an SR domain of trust to operate 1232 SRv6-based services for internal traffic while preventing any 1233 external traffic from accessing or exploiting the SRv6-based 1234 services. 1236 The technology described in this document is applied to a mobile 1237 network that is within the SR Domain. 1239 This document introduces new SRv6 Endpoint Behaviors. Those 1240 behaviors do not need any especial security consideration given that 1241 it is deployed within that SR Domain. 1243 11. IANA Considerations 1245 IANA is requested to allocate, within the "SRv6 Endpoint Behaviors" 1246 sub-registry belonging to the top-level "Segment Routing Parameters" 1247 registry [I-D.ietf-spring-srv6-network-programming], the following 1248 values: 1250 +-------+-----+-------------------+-----------+ 1251 | Value | Hex | Endpoint behavior | Reference | 1252 +-------+-----+-------------------+-----------+ 1253 | TBA | TBA | End.MAP | [This.ID] | 1254 | TBA | TBA | End.M.GTP6.D | [This.ID] | 1255 | TBA | TBA | End.M.GTP6.Di | [This.ID] | 1256 | TBA | TBA | End.M.GTP6.E | [This.ID] | 1257 | TBA | TBA | End.M.GTP4.E | [This.ID] | 1258 | TBA | TBA | End.Limit | [This.ID] | 1259 +-------+-----+-------------------+-----------+ 1261 Table 1: SRv6 Mobile User-plane Endpoint Behavior Types 1263 12. Acknowledgements 1265 The authors would like to thank Daisuke Yokota, Bart Peirens, 1266 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1267 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1268 Shekhar, Aeneas Dodd-Noble and Carlos Jesus Bernardos for their 1269 useful comments of this work. 1271 13. Contributors 1273 Kentaro Ebisawa 1274 Toyota Motor Corporation 1275 Japan 1277 Email: ebisawa@toyota-tokyo.tech 1279 Tetsuya Murakami 1280 Arrcus, Inc. 1281 United States of America 1283 Email: tetsuya.ietf@gmail.com 1285 14. References 1286 14.1. Normative References 1288 [I-D.ietf-spring-segment-routing-policy] 1289 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1290 P. Mattes, "Segment Routing Policy Architecture", draft- 1291 ietf-spring-segment-routing-policy-09 (work in progress), 1292 November 2020. 1294 [I-D.ietf-spring-srv6-network-programming] 1295 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1296 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1297 draft-ietf-spring-srv6-network-programming-28 (work in 1298 progress), December 2020. 1300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1301 Requirement Levels", BCP 14, RFC 2119, 1302 DOI 10.17487/RFC2119, March 1997, 1303 . 1305 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1306 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1307 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1308 July 2018, . 1310 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1311 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1312 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1313 . 1315 [TS.23501] 1316 3GPP, "System Architecture for the 5G System", 3GPP TS 1317 23.501 15.0.0, November 2017. 1319 14.2. Informative References 1321 [I-D.ali-spring-network-slicing-building-blocks] 1322 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 1323 "Building blocks for Slicing in Segment Routing Network", 1324 draft-ali-spring-network-slicing-building-blocks-03 (work 1325 in progress), November 2020. 1327 [I-D.auge-dmm-hicn-mobility-deployment-options] 1328 Auge, J., Carofiglio, G., Muscariello, L., and M. 1329 Papalini, "Anchorless mobility management through hICN 1330 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1331 mobility-deployment-options-04 (work in progress), July 1332 2020. 1334 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1335 Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S., 1336 Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- 1337 Cases", draft-camarilloelmalky-springdmm-srv6-mob- 1338 usecases-02 (work in progress), August 2019. 1340 [I-D.ietf-dmm-fpc-cpdp] 1341 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1342 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1343 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-14 1344 (work in progress), September 2020. 1346 [I-D.ietf-lsr-flex-algo] 1347 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1348 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 1349 algo-13 (work in progress), October 2020. 1351 [I-D.ietf-spring-segment-routing-central-epe] 1352 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1353 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1354 Engineering", draft-ietf-spring-segment-routing-central- 1355 epe-10 (work in progress), December 2017. 1357 [I-D.ietf-spring-sr-service-programming] 1358 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1359 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1360 Henderickx, W., and S. Salsano, "Service Programming with 1361 Segment Routing", draft-ietf-spring-sr-service- 1362 programming-03 (work in progress), September 2020. 1364 [I-D.matsushima-spring-srv6-deployment-status] 1365 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 1366 Rajaraman, "SRv6 Implementation and Deployment Status", 1367 draft-matsushima-spring-srv6-deployment-status-10 (work in 1368 progress), December 2020. 1370 [I-D.rodrigueznatal-lisp-srv6] 1371 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1372 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1373 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-04 1374 (work in progress), July 2020. 1376 [TS.29244] 1377 3GPP, "Interface between the Control Plane and the User 1378 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1380 [TS.29281] 1381 3GPP, "General Packet Radio System (GPRS) Tunnelling 1382 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1383 December 2017. 1385 [TS.38415] 1386 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1387 3GPP R3-174510 0.0.0, August 2017. 1389 Appendix A. Implementations 1391 This document introduces new SRv6 Endpoint Behaviors. These 1392 behaviors have an open-source P4 implementation available in 1393 . 1395 Additionally, a full implementation of this document is available in 1396 Linux Foundation FD.io VPP project since release 20.05. More 1397 information available here: . 1400 There are also experimental implementations in M-CORD NGIC and Open 1401 Air Interface (OAI). 1403 Authors' Addresses 1405 Satoru Matsushima (editor) 1406 SoftBank 1407 Japan 1409 Email: satoru.matsushima@g.softbank.co.jp 1411 Clarence Filsfils 1412 Cisco Systems, Inc. 1413 Belgium 1415 Email: cf@cisco.com 1417 Miya Kohno 1418 Cisco Systems, Inc. 1419 Japan 1421 Email: mkohno@cisco.com 1422 Pablo Camarillo Garvia (editor) 1423 Cisco Systems, Inc. 1424 Spain 1426 Email: pcamaril@cisco.com 1428 Daniel Voyer 1429 Bell Canada 1430 Canada 1432 Email: daniel.voyer@bell.ca 1434 Charles E. Perkins 1435 Futurewei Inc. 1436 2330 Central Expressway 1437 Santa Clara, CA 95050 1438 USA 1440 Phone: +1-408-330-4586 1441 Email: charliep@computer.org