idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-16.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 (11 August 2021) is 988 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 247, but not defined == Missing Reference: 'N2' is mentioned on line 248, but not defined == Missing Reference: 'N4' is mentioned on line 252, but not defined == Missing Reference: 'N3' is mentioned on line 699, but not defined == Missing Reference: 'N9' is mentioned on line 538, but not defined == Missing Reference: 'N6' is mentioned on line 700, but not defined -- Looks like a reference, but probably isn't: '0' on line 1062 == Missing Reference: 'NET-PGM' is mentioned on line 1113, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-04 == Outdated reference: A later version (-07) exists of draft-kohno-dmm-srv6mob-arch-04 == Outdated reference: A later version (-15) exists of draft-matsushima-spring-srv6-deployment-status-11 == Outdated reference: A later version (-05) exists of draft-murakami-dmm-user-plane-message-encoding-03 Summary: 0 errors (**), 0 flaws (~~), 15 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: 12 February 2022 M. Kohno 6 P. Camarillo, Ed. 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C.E. Perkins 11 Lupin Lodge 12 11 August 2021 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-16 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 12 February 2022. 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 (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Predefined SRv6 Endpoint Behaviors . . . . . . . . . . . 4 66 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 5 68 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7 70 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 71 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9 72 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 73 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 74 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11 75 5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 11 76 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 12 77 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 78 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15 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 . . . . . . . . . . 19 82 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19 83 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 85 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 22 86 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 23 87 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . 27 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 28 99 14.2. Informative References . . . . . . . . . . . . . . . . . 29 100 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 31 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 103 1. Introduction 105 In mobile networks, mobility management systems provide connectivity 106 over a wireless link to stationary and non-stationary nodes. The 107 user-plane establishes a tunnel between the mobile node and its 108 anchor node over IP-based backhaul and core networks. 110 This document shows the applicability of SRv6 (Segment Routing IPv6) 111 to mobile networks. 113 Segment Routing [RFC8402] is a source routing architecture: a node 114 steers a packet through an ordered list of instructions called 115 "segments". A segment can represent any instruction, topological or 116 service based. 118 SRv6 applied to mobile networks enables a source-routing based mobile 119 architecture, where operators can explicitly indicate a route for the 120 packets to and from the mobile node. The SRv6 Endpoint nodes serve 121 as mobile user-plane anchors. 123 2. Conventions and Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2.1. Terminology 131 * CNF: Cloud-native Network Function 132 * NFV: Network Function Virtualization 133 * PDU: Packet Data Unit 134 * PDU Session: Context of a UE connects to a mobile network. 135 * UE: User Equipment 136 * UPF: User Plane Function 137 * 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 161 is 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 166 but encoded in the SRH format where the rightmost SID in the SRH 167 is the first SID and the leftmost SID in the SRH is the last SID. 168 When referring to an SR policy in a high-level use-case, it is 169 simpler 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 * gNB::1 is an IPv6 address (SID) assigned to the gNB. 178 * U1::1 is an IPv6 address (SID) assigned to UPF1. 179 * U2::1 is an IPv6 address (SID) assigned to UPF2. 180 * 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 * End.DT4: Decapsulation and Specific IPv4 Table Lookup 187 * End.DT6: Decapsulation and Specific IPv6 Table Lookup 188 * End.DT46: Decapsulation and Specific IP Table Lookup 189 * End.DX4: Decapsulation and IPv4 Cross-Connect 190 * End.DX6: Decapsulation and IPv6 Cross-Connect 191 * End.DX2: Decapsulation and L2 Cross-Connect 192 * 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], and the 230 architetural benefits are discussed in [I-D.kohno-dmm-srv6mob-arch]. 232 4. 3GPP Reference Architecture 234 This section presents a reference architecture and possible 235 deployment scenarios. 237 Figure 1 shows a reference diagram from the 5G packet core 238 architecture [TS.23501]. 240 The user plane described in this document does not depend on any 241 specific architecture. The 5G packet core architecture as shown is 242 based on the latest 3GPP standards at the time of writing this draft. 244 +-----+ 245 | AMF | 246 /+-----+ 247 / | [N11] 248 [N2] / +-----+ 249 +------/ | SMF | 250 / +-----+ 251 / / \ 252 / / \ [N4] 253 / / \ ________ 254 / / \ / \ 255 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 256 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 257 +--+ +-----+ +------+ +------+ \________/ 259 Figure 1: 3GPP 5G Reference Architecture 261 * UE: User Endpoint 262 * gNB: gNodeB with N3 interface towards packet core (and N2 for 263 control plane) 264 * UPF1: UPF with Interfaces N3 and N9 (and N4 for control plane) 265 * UPF2: UPF with Interfaces N9 and N6 (and N4 for control plane) 266 * SMF: Session Management Function 267 * AMF: Access and Mobility Management Function 268 * DN: Data Network e.g. operator services, Internet access 270 This reference diagram does not depict a UPF that is only connected 271 to N9 interfaces, although the mechanisms defined in this document 272 also work in such case. 274 Each session from a UE gets assigned to a UPF. Sometimes multiple 275 UPFs may be used, providing richer service functions. A UE gets its 276 IP address from the DHCP block of its UPF. The UPF advertises that 277 IP address block toward the Internet, ensuring that return traffic is 278 routed to the right UPF. 280 5. User-plane behaviors 282 This section introduces an SRv6 based mobile user-plane. 284 In order to simplify the adoption of SRv6, we present two different 285 "modes" that vary with respect to the use of SRv6. The first one is 286 the "Traditional mode", which inherits the current 3GPP mobile 287 architecture. In this mode GTP-U protocol [TS.29281] is replaced by 288 SRv6, however the N3, N9 and N6 interfaces are still point-to-point 289 interfaces with no intermediate waypoints as in the current mobile 290 network architecture. 292 The second mode is the "Enhanced mode". This is an evolution from 293 the "Traditional mode". In this mode the N3, N9 or N6 interfaces 294 have intermediate waypoints -SIDs- that are used for Traffic 295 Engineering or VNF purposes. This results in optimal end-to-end 296 policies across the mobile network with transport and services 297 awareness. 299 In both, the Traditional and the Enhanced modes, we assume that the 300 gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6 301 interfaces are SRv6). 303 In addition to those two modes, we introduce two mechanisms for 304 interworking with legacy access networks (those where the N3 305 interface is unmodified). In this document we introduce them as a 306 variant to the Enhanced mode, however they are equally applicable to 307 the Traditional mode. 309 One of these mechanisms is designed to interwork with legacy gNBs 310 using GTP/IPv4. The second mechanism is designed to interwork with 311 legacy gNBs using GTP/IPv6. 313 This document uses SRv6 Segment Endpoint Behaviors defined in 314 [RFC8986] as well as new SRv6 Segment Endpoint Behaviors designed for 315 the mobile user plane that are defined in this document in Section 6. 317 5.1. Traditional mode 319 In the traditional mode, the existing mobile UPFs remain unchanged 320 with the sole exception of the use of SRv6 as the data plane instead 321 of GTP-U. There is no impact to the rest of the mobile system. 323 In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 324 with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored 325 here to replace GTP encapsulation with the SRv6 encapsulation, while 326 not changing anything else. There will be a unique SRv6 SID 327 associated with each PDU Session, and the SID list only contains a 328 single SID. 330 The traditional mode minimizes the changes required to the mobile 331 system; hence it is a good starting point for forming a common 332 ground. 334 The gNB/UPF control-plane (N2/N4 interface) is unchanged, 335 specifically a single IPv6 address is provided to the gNB. The same 336 control plane signalling is used, and the gNB/UPF decides to use SRv6 337 based on signaled GTP-U parameters per local policy. The only 338 information from the GTP-U parameters used for the SRv6 policy is the 339 TEID and the IPv6 Destination Address. 341 Our example topology is shown in Figure 2. In traditional mode the 342 gNB and the UPFs are SR-aware. In the descriptions of the uplink and 343 downlink packet flow, A is an IPv6 address of the UE, and Z is an 344 IPv6 address reachable within the Data Network DN. A new SRv6 345 Endpoint Behavior, End.MAP, defined in Section 6.2, is used. 347 ________ 348 SRv6 SRv6 / \ 349 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 350 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 351 +--+ +-----+ +------+ +------+ \________/ 352 SRv6 node SRv6 node SRv6 node 354 Figure 2: Traditional mode - example topology 356 5.1.1. Packet flow - Uplink 358 The uplink packet flow is as follows: 360 UE_out : (A,Z) 361 gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red 362 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 363 UPF2_out: (A,Z) -> End.DT4 or End.DT6 365 When the UE packet arrives at the gNB, the gNB performs a 366 H.Encaps.Red operation. Since there is only one SID, there is no 367 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 368 U1::1. U1::1 represents an anchoring SID specific for that session 369 at UPF1. gNB obtains the SID U1::1 from the existing control plane 370 (N2 interface). 372 When the packet arrives at UPF1, the SID U1::1 is associated with the 373 End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 by U2::1, 374 that belongs to the next UPF (U2). 376 When the packet arrives at UPF2, the SID U2::1 corresponds to an 377 End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates 378 the packet, performs a lookup in a specific table associated with 379 that mobile network and forwards the packet toward the data network 380 (DN). 382 5.1.2. Packet flow - Downlink 384 The downlink packet flow is as follows: 386 UPF2_in : (Z,A) 387 UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red 388 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 389 gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2 391 When the packet arrives at the UPF2, the UPF2 maps that flow into a 392 PDU Session. This PDU Session is associated with the segment 393 endpoint . UPF2 performs a H.Encaps.Red operation, 394 encapsulating the packet into a new IPv6 header with no SRH since 395 there is only one SID. 397 Upon packet arrival on UPF1, the SID U1::2 is a local SID associated 398 with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next 399 anchoring point and replaces U1::2 by gNB::1, that belongs to the 400 next hop. 402 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4, 403 End.DX6 or End.DX2 behavior (depending on the PDU Session Type). The 404 gNB decapsulates the packet, removing the IPv6 header and all its 405 extensions headers, and forwards the traffic toward the UE. 407 5.2. Enhanced Mode 409 Enhanced mode improves scalability, provides traffic engineering 410 capabilities, and allows service programming 411 [I-D.ietf-spring-sr-service-programming], thanks to the use of 412 multiple SIDs in the SID list (instead of a direct connectivity in 413 between UPFs with no intermediate waypoints as in Traditional Mode). 415 Thus, the main difference is that the SR policy MAY include SIDs for 416 traffic engineering and service programming in addition to the 417 anchoring SIDs at UPFs. 419 Additionally in this mode the operator may choose to aggregate 420 several devices under the same SID list (e.g., stationary residential 421 meters connected to the same cell) to improve scalability. 423 The gNB/UPF control-plane (N2/N4 interface) is unchanged, 424 specifically a single IPv6 address is provided to the gNB. A local 425 policy instructs the gNB to use SRv6. 427 The gNB MAY resolve the IP address received via the control plane 428 into a SID list using a mechanism like PCEP, DNS-lookup, LISP 429 control-plane or others. The resolution mechanism is out of the 430 scope of this document. 432 Note that the SIDs MAY use the arguments Args.Mob.Session if required 433 by the UPFs. 435 Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 436 gNB and the UPF are SR-aware. The Figure shows two service segments, 437 S1 and C1. S1 represents a VNF in the network, and C1 represents an 438 intermediate router used for Traffic Engineering purposes to enforce 439 a low-latency path in the network. Note that neither S1 nor C1 are 440 required to have an N4 interface. 442 +----+ SRv6 _______ 443 SRv6 --| C1 |--[N3] / \ 444 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 445 |UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN / 446 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 447 SRv6 node \ +----+ / SRv6 node 448 -| S1 |- 449 +----+ 450 SRv6 node 451 VNF 453 Figure 3: Enhanced mode - Example topology 455 5.2.1. Packet flow - Uplink 457 The uplink packet flow is as follows: 459 UE_out : (A,Z) 460 gNB_out : (gNB, S1)(U1::1, C1; SL=2)(A,Z)->H.Encaps.Red 461 S1_out : (gNB, C1)(U1::1, C1; SL=1)(A,Z) 462 C1_out : (gNB, U1::1)(A,Z) ->End with PSP 463 UPF1_out: (A,Z) ->End.DT4,End.DT6,End.DT2U 465 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 466 control plane associates that session from the UE(A) with the IPv6 467 address B. gNB's control plane does a lookup on B to find the 468 related SID list . 470 When gNB transmits the packet, it contains all the segments of the SR 471 policy. The SR policy includes segments for traffic engineering (C1) 472 and for service programming (S1). 474 Nodes S1 and C1 perform their related Endpoint functionality and 475 forward the packet. 477 When the packet arrives at UPF1, the active segment (U1::1) is an 478 End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing 479 the IPv6 header with all its extension headers) and forwards toward 480 the data network. 482 5.2.2. Packet flow - Downlink 484 The downlink packet flow is as follows: 486 UPF1_in : (Z,A) ->UPF1 maps the flow w/ 487 SID list 488 UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)->H.Encaps.Red 489 C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A) 490 S1_out : (U1::1, gNB::1)(Z,A) ->End with PSP 491 gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 493 When the packet arrives at the UPF1, the UPF1 maps that particular 494 flow into a UE PDU Session. This UE PDU Session is associated with 495 the policy . The UPF1 performs a H.Encaps.Red 496 operation, encapsulating the packet into a new IPv6 header with its 497 corresponding SRH. 499 The nodes C1 and S1 perform their related Endpoint processing. 501 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 502 End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the 503 underlying traffic). The gNB decapsulates the packet, removing the 504 IPv6 header, and forwards the traffic towards the UE. The SID gNB::1 505 is one example of a SID associated to this service. 507 Note that there are several means to provide the UE session 508 aggregation. The decision on which one to use is a local decision 509 made by the operator. One option is to use the Args.Mob.Session 510 (Section 6.1). Another option comprises the gNB performing an IP 511 lookup on the inner packet by using the End.DT4, End.DT6, and End.DT2 512 behaviors. 514 5.2.3. Scalability 516 The Enhanced Mode improves since it allows the aggregation of several 517 UEs under the same SID list. For example, in the case of stationary 518 residential meters that are connected to the same cell, all such 519 devices can share the same SID list. This improves scalability 520 compared to Traditional Mode (unique SID per UE) and compared to 521 GTP-U (dedicated TEID per UE). 523 5.3. Enhanced mode with unchanged gNB GTP behavior 525 This section describes two mechanisms for interworking with legacy 526 gNBs that still use GTP: one for IPv4, and another for IPv6. 528 In the interworking scenarios as illustrated in Figure 4, the gNB 529 does not support SRv6. The gNB supports GTP encapsulation over IPv4 530 or IPv6. To achieve interworking, an SR Gateway (SRGW) entity is 531 added. The SRGW maps the GTP traffic into SRv6. 533 The SRGW is not an anchor point and maintains very little state. For 534 this reason, both IPv4 and IPv6 methods scale to millions of UEs. 536 _______ 537 IP GTP SRv6 / \ 538 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 539 |UE|------| gNB |------| SRGW |--------| UPF |---------\ DN / 540 +--+ +-----+ +------+ +------+ \_______/ 541 SR Gateway SRv6 node 543 Figure 4: Example topology for interworking 545 Both of the mechanisms described in this section are applicable to 546 either the Traditional Mode or the Enhanced Mode. 548 5.3.1. Interworking with IPv6 GTP 550 In this interworking mode the gNB at the N3 interface uses GTP over 551 IPv6. 553 Key points: 555 * The gNB is unchanged (control-plane or user-plane) and 556 encapsulates into GTP (N3 interface is not modified). 557 * The 5G Control-Plane towards the gNB (N2 interface) is unmodified; 558 one IPv6 address is needed per SLA(i.e. a BSID at the SRGW). The 559 SRv6 SID is different depending on the required SLA. 560 * In the uplink, the SRGW removes GTP, finds the SID list related to 561 the IPv6 DA, and adds SRH with the SID list. 562 * There is no state for the downlink at the SRGW. 563 * There is simple state in the uplink at the SRGW; using Enhanced 564 mode results in fewer SR policies on this node. An SR policy is 565 shared across UEs as long as they belong to the same context 566 (i.e., tenant). A set of many different policies (i.e., different 567 SLAs) increases the amount of state required. 568 * When a packet from the UE leaves the gNB, it is SR-routed. This 569 simplifies network slicing [I-D.ietf-lsr-flex-algo]. 571 * In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic 572 into an SR policy when it arrives at the SRGW. 574 An example topology is shown in Figure 5. 576 S1 and C1 are two service segments. S1 represents a VNF in the 577 network, and C1 represents a router configured for Traffic 578 Engineering. 580 +----+ 581 IPv6/GTP -| S1 |- ___ 582 +--+ +-----+ [N3] / +----+ \ / 583 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 584 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 585 GTP \ +------+ / +----+ +------+ \___ 586 -| SRGW |- SRv6 SRv6 587 +------+ TE 588 SR Gateway 590 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 592 5.3.1.1. Packet flow - Uplink 594 The uplink packet flow is as follows: 596 UE_out : (A,Z) 597 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 598 (IPv6/GTP) 599 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 600 SID at the SRGW 601 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 602 C1_out : (SRGW, U2::1)(A,Z) -> End with PSP 603 UPF2_out: (A,Z) -> End.DT4 or End.DT6 605 The UE sends a packet destined to Z toward the gNB on a specific 606 bearer for that session. The gNB, which is unmodified, encapsulates 607 the packet into IPv6, UDP, and GTP headers. The IPv6 DA B, and the 608 GTP TEID T are the ones received in the N2 interface. 610 The IPv6 address that was signaled over the N2 interface for that UE 611 PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 612 SRGW. Hence the packet is routed to the SRGW. 614 When the packet arrives at the SRGW, the SRGW identifies B as an 615 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 616 the IPv6, UDP, and GTP headers, and pushes an IPv6 header with its 617 own SRH containing the SIDs bound to the SR policy associated with 618 this BindingSID. There at least one instance of the End.M.GTP6.D SID 619 per PDU type. 621 S1 and C1 perform their related Endpoint functionality and forward 622 the packet. 624 When the packet arrives at UPF2, the active segment is (U2::1) which 625 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 626 IPv6 header with all its extension headers) and forwards the packet 627 toward the data network. 629 5.3.1.2. Packet flow - Downlink 631 The downlink packet flow is as follows: 633 UPF2_in : (Z,A) -> UPF2 maps the flow with 634 635 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red 636 C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A) 637 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 638 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 639 gNB_out : (Z,A) 641 When a packet destined to A arrives at the UPF2, the UPF2 performs a 642 lookup in the table associated to A and finds the SID list . The UPF2 performs an H.Encaps.Red operation, 644 encapsulating the packet into a new IPv6 header with its 645 corresponding SRH. 647 C1 and S1 perform their related Endpoint processing. 649 Once the packet arrives at the SRGW, the SRGW identifies the active 650 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 651 and all its extensions headers. The SRGW generates new IPv6, UDP, 652 and GTP headers. The new IPv6 DA is the gNB which is the last SID in 653 the received SRH. The TEID in the generated GTP header is an 654 argument of the received End.M.GTP6.E SID. The SRGW pushes the 655 headers to the packet and forwards the packet toward the gNB. There 656 is one instance of the End.M.GTP6.E SID per PDU type. 658 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 659 packet. The gNB looks for the specific radio bearer for that TEID 660 and forward it on the bearer. This gNB behavior is not modified from 661 current and previous generations. 663 5.3.1.3. Scalability 665 For the downlink traffic, the SRGW is stateless. All the state is in 666 the SRH pushed by the UPF2. The UPF2 must have the UE states since 667 it is the UE's session anchor point. 669 For the uplink traffic, the state at the SRGW does not necessarily 670 need to be unique per PDU Session; the SR policy can be shared among 671 UEs. This enables more scalable SRGW deployments compared to a 672 solution holding millions of states, one or more per UE. 674 5.3.2. Interworking with IPv4 GTP 676 In this interworking mode the gNB uses GTP over IPv4 in the N3 677 interface 679 Key points: 681 * The gNB is unchanged and encapsulates packets into GTP (the N3 682 interface is not modified). 683 * In the uplink, traffic is classified by SRGW's classification 684 engine and steered into an SR policy. The SRGW may be implemented 685 in a UPF or as a separate entity. 686 * SRGW removes GTP, finds the SID list related to DA, and adds an 687 SRH with the SID list. 689 An example topology is shown in Figure 6. In this mode the gNB is an 690 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 691 the SRGW maps the IPv4/GTP traffic to SRv6. 693 S1 and C1 are two service segment endpoints. S1 represents a VNF in 694 the network, and C1 represents a router configured for Traffic 695 Engineering. 697 +----+ 698 IPv4/GTP -| S1 |- ___ 699 +--+ +-----+ [N3] / +----+ \ / 700 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 701 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 702 GTP \ +------+ / +----+ +------+ \___ 703 -| UPF1 |- SRv6 SRv6 704 +------+ TE 705 SR Gateway 707 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 709 5.3.2.1. Packet flow - Uplink 711 The uplink packet flow is as follows: 713 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 714 unchanged IPv4/GTP 715 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function 716 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 717 C1_out : (SRGW, U2::1) (A,Z) -> PSP 718 UPF2_out: (A,Z) -> End.DT4 or End.DT6 720 The UE sends a packet destined to Z toward the gNB on a specific 721 bearer for that session. The gNB, which is unmodified, encapsulates 722 the packet into a new IPv4, UDP, and GTP headers. The IPv4 DA, B, 723 and the GTP TEID are the ones received at the N2 interface. 725 When the packet arrives at the SRGW for UPF1, the SRGW has an 726 classification engine rule for incoming traffic from the gNB, that 727 steers the traffic into an SR policy by using the function 728 H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and 729 pushes an IPv6 header with its own SRH containing the SIDs related to 730 the SR policy associated with this traffic. The SRGW forwards 731 according to the new IPv6 DA. 733 S1 and C1 perform their related Endpoint functionality and forward 734 the packet. 736 When the packet arrives at UPF2, the active segment is (U2::1) which 737 is bound to End.DT4/6 which performs the decapsulation (removing the 738 outer IPv6 header with all its extension headers) and forwards toward 739 the data network. 741 Note that the interworking mechanisms for IPv4/GTP and IPv6/GTP 742 differs. This is due to the fact that in IPv6/GTP we can leverage 743 the remote steering capabilities provided by SRv6. In IPv4 this is 744 not the case, and it would require a significant address consumption. 746 5.3.2.2. Packet flow - Downlink 748 The downlink packet flow is as follows: 750 UPF2_in : (Z,A) -> UPF2 maps flow with SID 751 752 UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red 753 C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) 754 S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) 755 SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 756 gNB_out : (Z,A) 757 When a packet destined to A arrives at the UPF2, the UPF2 performs a 758 lookup in the table associated to A and finds the SID list . The UPF2 performs a H.Encaps.Red operation, 760 encapsulating the packet into a new IPv6 header with its 761 corresponding SRH. 763 The nodes C1 and S1 perform their related Endpoint processing. 765 Once the packet arrives at the SRGW, the SRGW identifies the active 766 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 767 and all its extensions headers. The SRGW generates an IPv4, UDP, and 768 GTP headers. The IPv4 SA and DA are received as SID arguments. The 769 TEID in the generated GTP header is also the arguments of the 770 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 771 and forwards the packet toward the gNB. 773 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 774 packet. The gNB looks for the specific radio bearer for that TEID 775 and forwards it on the bearer. This gNB behavior is not modified 776 from current and previous generations. 778 5.3.2.3. Scalability 780 For the downlink traffic, the SRGW is stateless. All the state is in 781 the SRH pushed by the UPF2. The UPF must have this UE-base state 782 anyway (since it is its anchor point). 784 For the uplink traffic, the state at the SRGW is dedicated on a per 785 UE/session basis according to a classification engine. There is 786 state for steering the different sessions in the form of an SR 787 Policy. However, SR policies are shared among several UE/sessions. 789 5.3.3. Extensions to the interworking mechanisms 791 In this section we presented two mechanisms for interworking with 792 gNBs and UPFs that do not support SRv6. These mechanisms are used to 793 support GTP over IPv4 and IPv6. 795 Even though we have presented these methods as an extension to the 796 "Enhanced mode", it is straightforward in its applicability to the 797 "Traditional mode". 799 5.4. SRv6 Drop-in Interworking 801 In this section we introduce another mode useful for legacy gNB and 802 UPFs that still operate with GTP-U. This mode provides an 803 SRv6-enabled user plane in between two GTP-U tunnel endpoints. 805 In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and 806 vice-versa. 808 Unlike other interworking modes, in this mode both of the mobility 809 overlay endpoints use GTP-U. Two SRGWs are deployed in either N3 or 810 N9 interface to realize an intermediate SR policy. 812 +----+ 813 -| S1 |- 814 +-----+ / +----+ \ 815 | gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+ 816 +-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF | 817 GTP[N3]\ +--------+ / +----+ +--------+ +-----+ 818 -| SRGW-A |- SRv6 SR Gateway-B GTP 819 +--------+ TE 820 SR Gateway-A 822 Figure 7: Example topology for SRv6 Drop-in mode 824 The packet flow of Figure 7 is as follows: 826 gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z) 827 GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an 828 End.M.GTP6.D.Di 829 SID at SRGW-A 830 S1_out : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z) 831 C1_out : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z) 832 GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an 833 End.M.GTP6.E 834 SID at SRGW-B 835 UPF_out : (A,Z) 837 When a packet destined to Z is sent to the gNB, which is unmodified 838 (control-plane and user-plane remain GTP-U), gNB performs 839 encapsulation into a new IP, UDP, and GTP headers. The IPv6 DA, 840 U::1, and the GTP TEID are the ones received at the N2 interface. 842 The IPv6 address that was signaled over the N2 interface for that PDU 843 Session, U::1, is now the IPv6 DA. U::1 is an SRv6 Binding SID at 844 SRGW-A. Hence the packet is routed to the SRGW. 846 When the packet arrives at SRGW-A, the SRGW identifies U::1 as an 847 End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW 848 removes the IPv6, UDP, and GTP headers, and pushes an IPv6 header 849 with its own SRH containing the SIDs bound to the SR policy 850 associated with this Binding SID. There is one instance of the 851 End.M.GTP6.D.Di SID per PDU type. 853 S1 and C1 perform their related Endpoint functionality and forward 854 the packet. 856 Once the packet arrives at SRGW-B, the SRGW identifies the active SID 857 as an End.M.GTP6.E function. The SRGW removes the IPv6 header and 858 all its extensions headers. The SRGW generates new IPv6, UDP, and 859 GTP headers. The new IPv6 DA is U::1 which is the last SID in the 860 received SRH. The TEID in the generated GTP header is an argument of 861 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 862 packet and forwards the packet toward UPF. There is one instance of 863 the End.M.GTP6.E SID per PDU type. 865 Once the packet arrives at UPF, the packet is a regular IPv6/GTP 866 packet. The UPF looks for the specific rule for that TEID to forward 867 the packet. This UPF behavior is not modified from current and 868 previous generations. 870 6. SRv6 Segment Endpoint Mobility Behaviors 872 6.1. Args.Mob.Session 874 Args.Mob.Session provide per-session information for charging, 875 buffering and lawful intercept (among others) required by some mobile 876 nodes. The Args.Mob.Session argument format is used in combination 877 with End.Map, End.DT4/End.DT6/End.DT46 and End.DX4/End.DX6/End.DX2 878 behaviors. Note that proposed format is applicable for 5G networks, 879 while similar formats could be used for legacy networks. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | QFI |R|U| PDU Session ID | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 |PDU Sess(cont')| 887 +-+-+-+-+-+-+-+-+ 889 Figure 8: Args.Mob.Session format 891 * QFI: QoS Flow Identifier [TS.38415] 892 * R: Reflective QoS Indication [TS.23501]. This parameter indicates 893 the activation of reflective QoS towards the UE for the 894 transferred packet. Reflective QoS enables the UE to map UL User 895 Plane traffic to QoS Flows without SMF provided QoS rules. 896 * U: Unused and for future use. MUST be 0 on transmission and 897 ignored on receipt. 898 * PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 899 is TEID. 901 Arg.Mob.Session is required in case that one SID aggregates multiple 902 PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated 903 per PDU session, Args.Mob.Session helps the UPF to perform the 904 behaviors which require per QFI and/or per PDU Session granularity. 906 Note that the encoding of user-plane messages (e.g., Echo Request, 907 Echo Reply, Error Indication and End Marker) is out of the scope of 908 this draft. [I-D.murakami-dmm-user-plane-message-encoding] defines 909 one possible encoding. 911 6.2. End.MAP 913 The "Endpoint behavior with SID mapping" behavior (End.MAP for short) 914 is used in several scenarios. Particularly in mobility, End.MAP is 915 used in the UPFs for the PDU Session anchor functionality. 917 When node N receives a packet whose IPv6 DA is S and S is a local 918 End.MAP SID, N does: 920 S01. If (IPv6 Hop Limit <= 1) { 921 S02. Send an ICMP Time Exceeded message to the Source Address, 922 Code 0 (Hop limit exceeded in transit), 923 interrupt packet processing, and discard the packet. 924 S03. } 925 S04. Decrement IPv6 Hop Limit by 1 926 S05. Lookup the IPv6 DA in the mapping table 927 S06. Update the IPv6 DA with the new mapped SID 928 S07. Submit the packet to the egress IPv6 FIB lookup for 929 transmission to the new destination 931 Notes: The SIDs in the SRH are not modified. 933 6.3. End.M.GTP6.D 935 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy" 936 behavior (End.M.GTP6.D for short) is used in interworking scenario 937 for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any 938 SID instance of this behavior is associated with an SR Policy B and 939 an IPv6 Source Address A. 941 When the SR Gateway node N receives a packet destined to S and S is a 942 local End.M.GTP6.D SID, N does: 944 S01. When an SRH is processed { 945 S02. If (Segments Left != 0) { 946 S03. Send an ICMP Parameter Problem to the Source Address, 947 Code 0 (Erroneous header field encountered), 948 Pointer set to the Segments Left field, 949 interrupt packet processing, and discard the packet. 950 S04. } 951 S05. Proceed to process the next header in the packet 952 S06. } 954 When processing the Upper-layer header of a packet matching a FIB 955 entry locally instantiated as an End.M.GTP6.D SID, N does: 957 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 958 S02. Copy the GTP TEID to buffer memory 959 S03. Pop the IPv6, UDP, and GTP Headers 960 S04. Push a new IPv6 header with its own SRH containing B 961 S05. Set the outer IPv6 SA to A 962 S06. Set the outer IPv6 DA to the first SID of B 963 S07. Set the outer Payload Length, Traffic Class, Flow Label, 964 Hop Limit, and Next-Header fields 965 S08. Write in the last SID of the SRH the Args.Mob.Session 966 based on the information of buffer memory 967 S09. Submit the packet to the egress IPv6 FIB lookup and 968 transmission to the new destination 969 S10. } Else { 970 S11. Process as per [RFC8986] Section 4.1.1 971 S12. } 973 Notes: The NH is set based on the SID parameter. There is one 974 instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the 975 NH is already known in advance. For the IPv4v6 PDU Session Type, in 976 addition we inspect the first nibble of the PDU to know the NH value. 978 The prefix of last segment (S3 in above example) SHOULD be followed 979 by an Arg.Mob.Session argument space which is used to provide the 980 session identifiers. 982 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 983 gateway. 985 6.4. End.M.GTP6.D.Di 987 The "Endpoint behavior with IPv6/GTP decapsulation into SR policy for 988 Drop-in Mode" behavior (End.M.GTP6.D.Di for short) is used in SRv6 989 drop-in interworking scenario described in Section 5.4. The 990 difference between End.M.GTP6.D as another variant of IPv6/GTP 991 decapsulation function is that the original IPv6 DA of GTP packet is 992 preserved as the last SID in SRH. 994 Any SID instance of this behavior is associated with an SR Policy B 995 and an IPv6 Source Address A. 997 When the SR Gateway node N receives a packet destined to S and S is a 998 local End.M.GTP6.D.Di SID, N does: 1000 S01. When an SRH is processed { 1001 S02. If (Segments Left != 0) { 1002 S03. Send an ICMP Parameter Problem to the Source Address, 1003 Code 0 (Erroneous header field encountered), 1004 Pointer set to the Segments Left field, 1005 interrupt packet processing, and discard the packet. 1006 S04. } 1007 S05. Proceed to process the next header in the packet 1008 S06. } 1010 When processing the Upper-layer header of a packet matching a FIB 1011 entry locally instantiated as an End.M.GTP6.Di SID, N does: 1013 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1014 S02. Copy S to buffer memory 1015 S03. Pop the IPv6, UDP, and GTP Headers 1016 S04. Push a new IPv6 header with its own SRH containing B 1017 S05. Set the outer IPv6 SA to A 1018 S06. Set the outer IPv6 DA to the first SID of B 1019 S07. Set the outer Payload Length, Traffic Class, Flow Label, 1020 Hop Limit, and Next-Header fields 1021 S08. Write S to the SRH 1022 S09. Submit the packet to the egress IPv6 FIB lookup and 1023 transmission to the new destination 1024 S10. } Else { 1025 S11. Process as per [RFC8986] Section 4.1.1 1026 S12. } 1028 Notes: The NH is set based on the SID parameter. There is one 1029 instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the 1030 NH is already known in advance. For the IPv4v6 PDU Session Type, in 1031 addition we inspect the first nibble of the PDU to know the NH value. 1033 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 1034 gateway. 1036 6.5. End.M.GTP6.E 1038 The "Endpoint behavior with encapsulation for IPv6/GTP tunnel" 1039 behavior (End.M.GTP6.E for short) is used in interworking scenario 1040 for the downlink toward the legacy gNB using IPv6/GTP. 1042 The prefix of End.M.GTP6.E SID MUST be followed by the 1043 Arg.Mob.Session argument space which is used to provide the session 1044 identifiers. 1046 When the SR Gateway node N receives a packet destined to S, and S is 1047 a local End.M.GTP6.E SID, N does the following: 1049 S01. When an SRH is processed { 1050 S02. If (Segments Left != 1) { 1051 S03. Send an ICMP Parameter Problem to the Source Address, 1052 Code 0 (Erroneous header field encountered), 1053 Pointer set to the Segments Left field, 1054 interrupt packet processing, and discard the packet. 1055 S04. } 1056 S05. Proceed to process the next header in the packet 1057 S06. } 1059 When processing the Upper-layer header of a packet matching a FIB 1060 entry locally instantiated as an End.M.GTP6.E SID, N does: 1062 S01. Copy SRH[0] and S to buffer memory 1063 S02. Pop the IPv6 header and all its extension headers 1064 S03. Push a new IPv6 header with a UDP/GTP Header 1065 S04. Set the outer IPv6 SA to A 1066 S05. Set the outer IPv6 DA from buffer memory 1067 S06. Set the outer Payload Length, Traffic Class, Flow Label, 1068 Hop Limit, and Next-Header fields 1069 S07. Set the GTP TEID (from buffer memory) 1070 S08. Submit the packet to the egress IPv6 FIB lookup and 1071 transmission to the new destination 1072 S09. } 1074 Notes: An End.M.GTP6.E SID MUST always be the penultimate SID. The 1075 TEID is extracted from the argument space of the current SID. 1077 The source address A SHOULD be an End.M.GTP6.D SID instantiated at an 1078 SR gateway. 1080 6.6. End.M.GTP4.E 1082 The "Endpoint behavior with encapsulation for IPv4/GTP tunnel" 1083 behavior (End.M.GTP4.E for short) is used in the downlink when doing 1084 interworking with legacy gNB using IPv4/GTP. 1086 When the SR Gateway node N receives a packet destined to S and S is a 1087 local End.M.GTP4.E SID, N does: 1089 S01. When an SRH is processed { 1090 S02. If (Segments Left != 0) { 1091 S03. Send an ICMP Parameter Problem to the Source Address, 1092 Code 0 (Erroneous header field encountered), 1093 Pointer set to the Segments Left field, 1094 interrupt packet processing, and discard the packet. 1095 S04. } 1096 S05. Proceed to process the next header in the packet 1097 S06. } 1099 When processing the Upper-layer header of a packet matching a FIB 1100 entry locally instantiated as an End.M.GTP4.E SID, N does: 1102 S01. If (Next Header = UDP & UDP_Dest_port = GTP) { 1103 S02. Sotre the IPv6 DA and SA in buffer memory 1104 S03. Pop the IPv6 header and all its extension headers 1105 S04. Push a new IPv4 header with a UDP/GTP Header 1106 S05. Set the outer IPv4 SA and DA (from buffer memory) 1107 S06. Set the outer Total Length, DSCP, Time To Live, and 1108 Next-Header fields 1109 S07. Set the GTP TEID (from buffer memory) 1110 S08. Submit the packet to the egress IPv6 FIB lookup and 1111 transmission to the new destination 1112 S09. } Else { 1113 S10. Process as per [NET-PGM] Section 4.1.1 1114 S11. } 1116 Notes: The End.M.GTP4.E SID in S has the following format: 1118 0 127 1119 +-----------------------+-------+----------------+---------+ 1120 | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | 1121 +-----------------------+-------+----------------+---------+ 1122 128-a-b-c a b c 1124 Figure 9: End.M.GTP4.E SID Encoding 1126 The IPv6 Source Address has the following format: 1128 0 127 1129 +----------------------+--------+--------------------------+ 1130 | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | 1131 +----------------------+--------+--------------------------+ 1132 128-a-b a b 1134 Figure 10: IPv6 SA Encoding for End.M.GTP4.E 1136 6.7. H.M.GTP4.D 1138 The "SR Policy Headend with tunnel decapsulation and map to an SRv6 1139 policy" behavior (H.M.GTP4.D for short) is used in the direction from 1140 legacy IPv4 user-plane to SRv6 user-plane network. 1142 When the SR Gateway node N receives a packet destined to a IW- 1143 IPv4-Prefix, N does: 1145 S01. IF Payload == UDP/GTP THEN 1146 S02. Pop the outer IPv4 header and UDP/GTP headers 1147 S03. Copy IPv4 DA, TEID to form SID B 1148 S04. Copy IPv4 SA to form IPv6 SA B' 1149 S05. Encapsulate the packet into a new IPv6 header ;;Ref1 1150 S06. Set the IPv6 DA = B 1151 S07. Forward along the shortest path to B 1152 S08. ELSE 1153 S09. Drop the packet 1155 Ref1: The NH value is identified by inspecting the first nibble of 1156 the inner payload. 1158 The SID B has the following format: 1160 0 127 1161 +-----------------------+-------+----------------+---------+ 1162 |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | 1163 +-----------------------+-------+----------------+---------+ 1164 128-a-b-c a b c 1166 Figure 11: H.M.GTP4.D SID Encoding 1168 The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 1169 (U1) to bind an SR policy [I-D.ietf-spring-segment-routing-policy]. 1171 The prefix of B' SHOULD be an End.M.GTP4.E SID with its format 1172 instantiated at an SR gateway with the IPv4 SA of the receiving 1173 packet. 1175 6.8. End.Limit: Rate Limiting behavior 1177 The mobile user-plane requires a rate-limit feature. For this 1178 purpose, we define a new behavior "End.Limit". The "End.Limit" 1179 behavior encodes in its arguments the rate limiting parameter that 1180 should be applied to this packet. Multiple flows of packets should 1181 have the same group identifier in the SID when those flows are in the 1182 same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of 1183 the rate limit segment SID is as follows: 1185 +----------------------+----------+-----------+ 1186 | LOC+FUNC rate-limit | group-id | limit-rate| 1187 +----------------------+----------+-----------+ 1188 128-i-j i j 1190 Figure 12: End.Limit: Rate limiting behavior argument format 1192 If the limit-rate bits are set to zero, the node should not do rate 1193 limiting unless static configuration or control-plane sets the limit 1194 rate associated to the SID. 1196 7. SRv6 supported 3GPP PDU session types 1198 The 3GPP [TS.23501] defines the following PDU session types: 1200 * IPv4 1201 * IPv6 1202 * IPv4v6 1203 * Ethernet 1204 * Unstructured 1206 SRv6 supports the 3GPP PDU session types without any protocol 1207 overhead by using the corresponding SRv6 behaviors (End.DX4, End.DT4 1208 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 1209 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 and Unstructured PDU 1210 sessions). 1212 8. Network Slicing Considerations 1214 A mobile network may be required to implement "network slices", which 1215 logically separate network resources. User-plane behaviors 1216 represented as SRv6 segments would be part of a slice. 1218 [I-D.ietf-spring-segment-routing-policy] describes a solution to 1219 build basic network slices with SR. Depending on the requirements, 1220 these slices can be further refined by adopting the mechanisms from: 1222 * IGP Flex-Algo [I-D.ietf-lsr-flex-algo] 1223 * Inter-Domain policies 1224 [I-D.ietf-spring-segment-routing-central-epe] 1226 Furthermore, these can be combined with ODN/AS (On Demand Nexthop/ 1227 Automated Steering) [I-D.ietf-spring-segment-routing-policy] for 1228 automated slice provisioning and traffic steering. 1230 Further details on how these tools can be used to create end to end 1231 network slices are documented in 1232 [I-D.ali-spring-network-slicing-building-blocks]. 1234 9. Control Plane Considerations 1236 This document focuses on user-plane behavior and its independence 1237 from the control plane. While there are benefits in an enhanced 1238 control plane (e.g., to dynamically configure SR policies from a 1239 controller), this document does not impose any change to the existant 1240 mobility control plane. 1242 Section 11 allocates SRv6 Segment Endpoint Behavior codepoints for 1243 the new behaviors defined in this document. 1245 10. Security Considerations 1247 The security considerations for Segment Routing are discussed in 1248 [RFC8402]. More specifically for SRv6 the security considerations 1249 and the mechanisms for securing an SR domain are discussed in 1250 [RFC8754]. Together, they describe the required security mechanisms 1251 that allow establishment of an SR domain of trust to operate 1252 SRv6-based services for internal traffic while preventing any 1253 external traffic from accessing or exploiting the SRv6-based 1254 services. 1256 The technology described in this document is applied to a mobile 1257 network that is within the SR Domain. 1259 This document introduces new SRv6 Endpoint Behaviors. Those 1260 behaviors do not need any special security consideration given that 1261 it is deployed within that SR Domain. 1263 11. IANA Considerations 1265 The following values have been allocated within the "SRv6 Endpoint 1266 Behaviors" [RFC8986] sub-registry belonging to the top-level "Segment 1267 Routing Parameters" registry: 1269 +=======+========+===================+===========+ 1270 | Value | Hex | Endpoint behavior | Reference | 1271 +=======+========+===================+===========+ 1272 | 40 | 0x0028 | End.MAP | [This.ID] | 1273 +-------+--------+-------------------+-----------+ 1274 | 41 | 0x0029 | End.Limit | [This.ID] | 1275 +-------+--------+-------------------+-----------+ 1276 | 69 | 0x0045 | End.M.GTP6.D | [This.ID] | 1277 +-------+--------+-------------------+-----------+ 1278 | 70 | 0x0046 | End.M.GTP6.Di | [This.ID] | 1279 +-------+--------+-------------------+-----------+ 1280 | 71 | 0x0047 | End.M.GTP6.E | [This.ID] | 1281 +-------+--------+-------------------+-----------+ 1282 | 72 | 0x0048 | End.M.GTP4.E | [This.ID] | 1283 +-------+--------+-------------------+-----------+ 1285 Table 1: SRv6 Mobile User-plane Endpoint 1286 Behavior Types 1288 12. Acknowledgements 1290 The authors would like to thank Daisuke Yokota, Bart Peirens, 1291 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1292 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1293 Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk v. Hugo and 1294 Jeffrey Zhang for their useful comments of this work. 1296 13. Contributors 1298 Kentaro Ebisawa Toyota Motor Corporation Japan 1300 Email: ebisawa@toyota-tokyo.tech 1302 Tetsuya Murakami Arrcus, Inc. United States of America 1304 Email: tetsuya.ietf@gmail.com 1306 14. References 1308 14.1. Normative References 1310 [I-D.ietf-spring-segment-routing-policy] 1311 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1312 P. Mattes, "Segment Routing Policy Architecture", Work in 1313 Progress, Internet-Draft, draft-ietf-spring-segment- 1314 routing-policy-13, 28 May 2021, 1315 . 1318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1319 Requirement Levels", BCP 14, RFC 2119, 1320 DOI 10.17487/RFC2119, March 1997, 1321 . 1323 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1324 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1325 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1326 July 2018, . 1328 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1329 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1330 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1331 . 1333 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1334 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1335 (SRv6) Network Programming", RFC 8986, 1336 DOI 10.17487/RFC8986, February 2021, 1337 . 1339 [TS.23501] 3GPP, "System Architecture for the 5G System", 3GPP TS 1340 23.501 15.0.0, November 2017. 1342 14.2. Informative References 1344 [I-D.ali-spring-network-slicing-building-blocks] 1345 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 1346 "Building blocks for Slicing in Segment Routing Network", 1347 Work in Progress, Internet-Draft, draft-ali-spring- 1348 network-slicing-building-blocks-04, 21 February 2021, 1349 . 1352 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1353 Garvia, P. C., Filsfils, C., Elmalky, H., Matsushima, S., 1354 Voyer, D., Cui, A., and B. Peirens, "SRv6 Mobility Use- 1355 Cases", Work in Progress, Internet-Draft, draft- 1356 camarilloelmalky-springdmm-srv6-mob-usecases-02, 15 August 1357 2019, . 1360 [I-D.ietf-lsr-flex-algo] 1361 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 1362 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 1363 Internet-Draft, draft-ietf-lsr-flex-algo-17, 6 July 2021, 1364 . 1367 [I-D.ietf-spring-segment-routing-central-epe] 1368 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1369 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1370 Engineering", Work in Progress, Internet-Draft, draft- 1371 ietf-spring-segment-routing-central-epe-10, 21 December 1372 2017, . 1375 [I-D.ietf-spring-sr-service-programming] 1376 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 1377 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 1378 S. Salsano, "Service Programming with Segment Routing", 1379 Work in Progress, Internet-Draft, draft-ietf-spring-sr- 1380 service-programming-04, 10 March 2021, 1381 . 1384 [I-D.kohno-dmm-srv6mob-arch] 1385 Kohno, M., Clad, F., Camarillo, P., and Z. Ali, 1386 "Architecture Discussion on SRv6 Mobile User plane", Work 1387 in Progress, Internet-Draft, draft-kohno-dmm-srv6mob-arch- 1388 04, 6 May 2021, . 1391 [I-D.matsushima-spring-srv6-deployment-status] 1392 Matsushima, S., Filsfils, C., Ali, Z., Li, Z., and K. 1393 Rajaraman, "SRv6 Implementation and Deployment Status", 1394 Work in Progress, Internet-Draft, draft-matsushima-spring- 1395 srv6-deployment-status-11, 17 February 2021, 1396 . 1399 [I-D.murakami-dmm-user-plane-message-encoding] 1400 Murakami, T., Matsushima, S., Ebisawa, K., Camarillo, P., 1401 and R. Shekhar, "User Plane Message Encoding", Work in 1402 Progress, Internet-Draft, draft-murakami-dmm-user-plane- 1403 message-encoding-03, 7 March 2021, 1404 . 1407 [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling 1408 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1409 December 2017. 1411 [TS.38415] 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1412 3GPP R3-174510 0.0.0, August 2017. 1414 Appendix A. Implementations 1416 This document introduces new SRv6 Endpoint Behaviors. These 1417 behaviors have an open-source P4 implementation available in 1418 https://github.com/ebiken/p4srv6. 1420 Additionally, a full implementation of this document is available in 1421 Linux Foundation FD.io VPP project since release 20.05. More 1422 information available here: https://docs.fd.io/vpp/20.05/d7/d3c/ 1423 srv6_mobile_plugin_doc.html. 1425 There are also experimental implementations in M-CORD NGIC and Open 1426 Air Interface (OAI). 1428 Authors' Addresses 1430 Satoru Matsushima (editor) 1431 SoftBank 1432 Japan 1434 Email: satoru.matsushima@g.softbank.co.jp 1436 Clarence Filsfils 1437 Cisco Systems, Inc. 1438 Belgium 1440 Email: cf@cisco.com 1442 Miya Kohno 1443 Cisco Systems, Inc. 1444 Japan 1446 Email: mkohno@cisco.com 1448 Pablo Camarillo Garvia (editor) 1449 Cisco Systems, Inc. 1450 Spain 1452 Email: pcamaril@cisco.com 1454 Daniel Voyer 1455 Bell Canada 1456 Canada 1457 Email: daniel.voyer@bell.ca 1459 Charles E. Perkins 1460 Lupin Lodge 1461 20600 Aldercroft Heights Rd. 1462 Los Gatos, CA 95033 1463 United States of America 1465 Email: charliep@computer.org