idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-06.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 (September 26, 2019) is 1673 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 177, but not defined -- Looks like a reference, but probably isn't: '2' on line 175 -- Looks like a reference, but probably isn't: '1' on line 175 -- Looks like a reference, but probably isn't: '0' on line 871 == Missing Reference: 'WHITEPAPER-5G-UP' is mentioned on line 251, but not defined == Missing Reference: 'N11' is mentioned on line 256, but not defined == Missing Reference: 'N2' is mentioned on line 257, but not defined == Missing Reference: 'N4' is mentioned on line 261, but not defined == Missing Reference: 'N3' is mentioned on line 665, but not defined == Missing Reference: 'N9' is mentioned on line 504, but not defined == Missing Reference: 'N6' is mentioned on line 666, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-23 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-02 == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-01 == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-deployment-options-02 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-12 == Outdated reference: A later version (-04) exists of draft-rodrigueznatal-lisp-srv6-02 Summary: 0 errors (**), 0 flaws (~~), 16 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group S. Matsushima 3 Internet-Draft SoftBank 4 Intended status: Standards Track C. Filsfils 5 Expires: March 29, 2020 M. Kohno 6 P. Camarillo 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 September 26, 2019 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-06 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 behavior and defines the SID functions for that. 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 March 29, 2020. 45 Copyright Notice 47 Copyright (c) 2019 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 Functions . . . . . . . . . . . . . . . . 4 67 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. A 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 . . . . . . . . . . . . . . . 8 73 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 74 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 75 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10 76 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 77 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 11 78 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14 79 5.3.3. Extensions to the interworking mechanisms . . . . . . 17 80 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 17 81 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 17 82 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 18 84 6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19 85 6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20 86 6.6. T.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 20 87 6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 21 88 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22 89 8. Network Slicing Considerations . . . . . . . . . . . . . . . 22 90 9. Control Plane Considerations . . . . . . . . . . . . . . . . 22 91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 94 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 97 14.2. Informative References . . . . . . . . . . . . . . . . . 24 98 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 26 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 101 1. Introduction 103 In mobile networks, mobility management systems provide connectivity 104 while mobile nodes move. While the control-plane of the system 105 signals movements of a mobile node, the user-plane establishes a 106 tunnel between the mobile node and its anchor node over IP-based 107 backhaul and core networks. 109 This document shows the applicability of SRv6 (Segment Routing IPv6) 110 to those mobile networks. SRv6 provides source routing to networks 111 so that operators can explicitly indicate a route for the packets to 112 and from the mobile node. SRv6 endpoint nodes serve as the anchors 113 of mobile user-plane. 115 2. Conventions and Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2.1. Terminology 123 o AMBR: Aggregate Maximum Bit Rate 124 o APN: Access Point Name (commonly used to identify a network or 125 class of service) 126 o BSID: SR Binding SID [RFC8402] 127 o CNF: Cloud-native Network Function 128 o gNB: gNodeB 129 o NH: The IPv6 next-header field. 130 o NFV: Network Function Virtualization 131 o PDU: Packet Data Unit 132 o Session: TBD... 133 o SID: A Segment Identifier which represents a specific segment in a 134 segment routing domain. 135 o SRH: The Segment Routing Header. 136 [I-D.ietf-6man-segment-routing-header] 137 o TEID: Tunnel Endpoint Identifier 138 o UE: User Equipment 139 o UPF: User Plane Function 140 o VNF: Virtual Network Function 142 2.2. Conventions 144 o NH=SRH means that NH is 43 with routing type 4. 145 o Multiple SRHs may be present inside each packet, but they must 146 follow each other. The next-header field of each SRH, except the 147 last one, must be NH-SRH (43 type 4). 148 o For simplicity, no other extension headers are shown except the 149 SRH. 150 o The SID type used in this document is IPv6 address (also called 151 SRv6 Segment or SRv6 SID). 152 o gNB::1 is an IPv6 address (SID) assigned to the gNB. 153 o U1::1 is an IPv6 address (SID) assigned to UPF1. 154 o U2::1 is an IPv6 address (SID) assigned to UPF2. 155 o U2:: is some other IPv6 address (SID) assigned to UPF2. 156 o A SID list is represented as where S1 is the first 157 SID to visit, S2 is the second SID to visit and S3 is the last SID 158 to visit along the SR path. 159 o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 161 * IPv6 header with source and destination addresses SA and DA 162 respectively, and next-header SRH, with SID list 163 with SegmentsLeft = SL 164 * The payload of the packet is not represented. 165 o Note the difference between the <> and () symbols: 166 represents a SID list where S1 is the first SID and S3 is the last 167 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 168 the SRH format where the rightmost SID in the SRH is the first SID 169 and the leftmost SID in the SRH is the last SID. When referring 170 to an SR policy in a high-level use-case, it is simpler to use the 171 notation. When referring to an illustration of the 172 detailed behavior, the (S3, S2, S1; SL) notation is more 173 convenient. 174 o SRH[SL] represents the SID pointed by the SL field in the first 175 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 176 and SRH[0] represents S3. 177 o SRH[SL] can be different from the DA of the IPv6 header. 179 2.3. Predefined SRv6 Functions 181 The following functions are defined in 182 [I-D.ietf-spring-srv6-network-programming]. 184 o End.DT4 means to decapsulate and forward using a specific IPv4 185 table lookup. 186 o End.DT6 means to decapsulate and forward using a specific IPv6 187 table lookup. 189 o End.DX4 means to decapsulate the packet and forward through a 190 particular outgoing interface -or set of OIFs- configured with the 191 SID. 192 o End.DX6 means to decapsulate and forward through a particular 193 outgoing interface -or set of OIFs- configured with the SID. 194 o End.DX2 means to decapsulate the L2 frame and forward through a 195 particular outgoing interface -or set of OIFs- configured with the 196 SID. 197 o End.T means to forward using a specific IPv6 table lookup. 198 o End.X means to forward through a link configured with the SID. 199 o T.Encaps.Red means encapsulation without pushing SRH (resulting in 200 "Reduced" packet size). 201 o PSP means Penultimate Segment Pop. The packet is subsequently 202 forwarded without the popped SRH. 204 New SRv6 functions are defined in Section 6 to support the needs of 205 the mobile user plane. 207 3. Motivation 209 Mobility networks are becoming more challenging to operate. On one 210 hand, traffic is constantly growing, and latency requirements are 211 more strict; on the other-hand, there are new use-cases like NFV that 212 are also challenging network management. 214 The current architecture of mobile networks does not take into 215 account the underlying transport. The user-plane is rigidly 216 fragmented into radio access, core and service networks, connected by 217 tunneling according to user-plane roles such as access and anchor 218 nodes. These factors have made it difficult for the operator to 219 optimize and operate the data-path. 221 In the meantime, applications have shifted to use IPv6, and network 222 operators have started adopting IPv6 as their IP transport. SRv6, 223 the IPv6 dataplane instantiation of Segment Routing [RFC8402], 224 integrates both the application data-path and the underlying 225 transport layer into a single protocol, allowing operators to 226 optimize the network in a simplified manner and removing forwarding 227 state from the network. It is also suitable for virtualized 228 environments, VNF/CNF to VNF/CNF networking. 230 SRv6 specifies network-programming (see 231 [I-D.ietf-spring-srv6-network-programming]). Applied to mobility, 232 SRv6 can provide the user-plane functions needed for mobility 233 management. SRv6 takes advantage of underlying transport awareness 234 and flexibility to improve mobility user-plane functions. 236 The use-cases for SRv6 mobility are discussed in 237 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]. 239 4. A 3GPP Reference Architecture 241 This section presents a reference architecture and possible 242 deployment scenarios. 244 Figure 1 shows a reference diagram from the 5G packet core 245 architecture [TS.23501]. 247 The user plane described in this document does not depend on any 248 specific architecture. The 5G packet core architecture as shown is 249 based on the latest 3GPP standards at the time of writing this draft. 250 Other architectures can be seen in [I-D.gundavelli-dmm-mfa] and 251 [WHITEPAPER-5G-UP]. 253 +-----+ 254 | AMF | 255 +-----+ 256 / | [N11] 257 [N2] / +-----+ 258 +------/ | SMF | 259 / +-----+ 260 / / \ 261 / / \ [N4] 262 / / \ ________ 263 / / \ / \ 264 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 265 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 266 +--+ +-----+ +------+ +------+ \________/ 268 Figure 1: 3GPP 5G Reference Architecture 270 o gNB: gNodeB 271 o UPF1: UPF with Interfaces N3 and N9 272 o UPF2: UPF with Interfaces N9 and N6 273 o SMF: Session Management Function 274 o AMF: Access and Mobility Management Function 275 o DN: Data Network e.g. operator services, Internet access 277 This reference diagram does not depict a UPF that is only connected 278 to N9 interfaces, although the description in this document also work 279 for such UPFs. 281 Each session from an UE gets assigned to a UPF. Sometimes multiple 282 UPFs may be used, providing richer service functions. A UE gets its 283 IP address from the DHCP block of its UPF. The UPF advertises that 284 IP address block toward the Internet, ensuring that return traffic is 285 routed to the right UPF. 287 5. User-plane behaviors 289 This section describes some mobile user-plane behaviors using SRv6. 291 In order to simplify the adoption of SRv6, we present two different 292 "modes" that vary with respect to the use of SRv6. The first one is 293 the "Traditional mode", which inherits the current 3GPP mobile user- 294 plane. In this mode there is no change to mobility networks 295 architecture, except that GTP-U [TS.29281] is replaced by SRv6. 297 The second mode is the "Enhanced mode". In this mode the SR policy 298 contains SIDs for Traffic Engineering and VNFs, which results in 299 effective end-to-end network slices. 301 In both, the Traditional and the Enhanced modes, we assume that the 302 gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6 303 interfaces are SRv6). 305 We introduce two mechanisms for interworking with legacy access 306 networks (N3 interface is unmodified). In these document we 307 introduce them applied to the Enhanced mode, although they could be 308 used in combination with the Traditional mode as well. 310 One of these mechanisms is designed to interwork with legacy gNBs 311 using GTP/IPv4. The second method is designed to interwork with 312 legacy gNBs using GTP/IPv6. 314 This document uses SRv6 functions defined in 315 [I-D.ietf-spring-srv6-network-programming] as well as new SRv6 316 functions designed for the mobile user plane. The new SRv6 functions 317 are detailed in Section 6. 319 5.1. Traditional mode 321 In the traditional mode, the existing mobile UPFs remain unchanged 322 except for the use of SRv6 as the data plane instead of GTP-U. There 323 is no impact to the rest of mobile system. 325 In existing 3GPP mobile networks, an UE 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 UE PDU Session. 331 The traditional mode minimizes the changes required to the mobile 332 system; it is a good starting point for forming a common basis. 334 Our example topology is shown in Figure 2. In traditional mode the 335 gNB and the UPFs are SR-aware. In the descriptions of the uplink and 336 downlink packet flow, A is an IPv6 address of the UE, and Z is an 337 IPv6 address reachable within the Data Network DN. A new SRv6 338 function End.MAP, defined in Section 6.2, is used. 340 ________ 341 SRv6 SRv6 / \ 342 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 343 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 344 +--+ +-----+ +------+ +------+ \________/ 345 SRv6 node SRv6 node SRv6 node 347 Figure 2: Traditional mode - example topology 349 5.1.1. Packet flow - Uplink 351 The uplink packet flow is as follows: 353 UE_out : (A,Z) 354 gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Red 355 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 356 UPF2_out: (A,Z) -> End.DT4 or End.DT6 358 When the UE packet arrives at the gNB, the gNB performs a 359 T.Encaps.Red operation. Since there is only one SID, there is no 360 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 361 U1::1. U1::1 represents an anchoring SID specific for that session 362 at UPF1. gNB obtains the SID U1::1 from the existing control plane 363 (N2 interface). 365 When the packet arrives at UPF1, the SID U1::1 identifies a local 366 End.MAP function. End.MAP replaces U1::1 by U2::1, that belongs to 367 the next UPF (U2). 369 When the packet arrives at UPF2, the SID U2::1 corresponds to an 370 End.DT function. UPF2 decapsulates the packet, performs a lookup in 371 a specific table associated with that mobile network and forwards the 372 packet toward the data network (DN). 374 5.1.2. Packet flow - Downlink 376 The downlink packet flow is as follows: 378 UPF2_in : (Z,A) 379 UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red 380 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 381 gNB_out : (Z,A) -> End.DX4 or End.DX6 383 When the packet arrives at the UPF2, the UPF2 maps that flow into a 384 UE PDU Session. This UE PDU Session is associated with the segment 385 endpoint . UPF2 performs a T.Encaps.Red operation, 386 encapsulating the packet into a new IPv6 header with no SRH since 387 there is only one SID. 389 Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 390 function. This function maps the SID to the next anchoring point and 391 replaces U1::1 by gNB::1, that belongs to the next hop. 393 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4 394 or End.DX6 function. The gNB decapsulates the packet, removing the 395 IPv6 header and all its extensions headers, and forwards the traffic 396 toward the UE. 398 5.2. Enhanced Mode 400 Enhanced mode improves scalability, traffic steering and service 401 programming [I-D.xuclad-spring-sr-service-programming], thanks to the 402 use of multiple SIDs, instead of a single SID as done in the 403 Traditional mode. 405 The main difference is that the SR policy MAY include SIDs for 406 traffic engineering and service programming in addition to the UPFs 407 SIDs. 409 The gNB control-plane (N2 interface) is unchanged, specifically a 410 single IPv6 address is given to the gNB. 412 o The gNB MAY resolve the IP address into a SID list using a 413 mechanism like PCEP, DNS-lookup, small augment for LISP control- 414 plane, etc. 416 Note that the SIDs MAY use the arguments Args.Mob.Session if required 417 by the UPFs. 419 Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 420 gNB and the UPF are SR-aware. The Figure shows two service segments, 421 S1 and C1. S1 represents a VNF in the network, and C1 represents a 422 constraint path on a router requiring Traffic Engineering. S1 and C1 423 belong to the underlay and don't have an N4 interface, so they are 424 not considered UPFs. 426 +----+ SRv6 _______ 427 SRv6 --| C1 |--[N3] / \ 428 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 429 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 430 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 431 SRv6 node \ +----+ / SRv6 node 432 -| S1 |- 433 +----+ 434 SRv6 node 435 CNF 437 Figure 3: Enhanced mode - Example topology 439 5.2.1. Packet flow - Uplink 441 The uplink packet flow is as follows: 443 UE_out : (A,Z) 444 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red 445 S1_out : (gNB, C1)(U2::1, C1; SL=1 (A,Z) 446 C1_out : (gNB, U2::1)(A,Z) -> PSP 447 UPF2_out: (A,Z) -> End.DT4 or End.DT6 449 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 450 control plane associates that session from the UE(A) with the IPv6 451 address B and GTP TEID T. gNB's control plane does a lookup on B to 452 find the related SID list . 454 When gNB transmits the packet, it contains all the segments of the SR 455 policy. The SR policy can include segments for traffic engineering 456 (C1) and for service programming (S1). 458 Nodes S1 and C1 perform their related Endpoint functionality and 459 forward the packet. 461 When the packet arrives at UPF2, the active segment (U2::1) is an 462 End.DT4/6 which performs the decapsulation (removing the IPv6 header 463 with all its extension headers) and forwards toward the data network. 465 5.2.2. Packet flow - Downlink 467 The downlink packet flow is as follows: 469 UPF2_in : (Z,A) -> UPF2 maps the flow w/ 470 SID list 471 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red 472 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 473 S1_out : (U2::1, gNB)(Z,A) -> PSP 474 gNB_out : (Z,A) -> End.DX4 or End.DX6 476 When the packet arrives at the UPF2, the UPF2 maps that particular 477 flow into a UE PDU Session. This UE PDU Session is associated with 478 the policy . The UPF2 performs a T.Encaps.Red 479 operation, encapsulating the packet into a new IPv6 header with its 480 corresponding SRH. 482 The nodes C1 and S1 perform their related Endpoint processing. 484 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 485 End.DX4 or End.DX6 (depending on the underlying traffic). The gNB 486 decapsulates the packet, removing the IPv6 header and all its 487 extensions headers and forwards the traffic toward the UE. 489 5.3. Enhanced mode with unchanged gNB GTP behavior 491 This section describes two mechanisms for interworking with legacy 492 gNBs that still use GTP: one for IPv4, the other for IPv6. 494 In the interworking scenarios as illustrated in Figure 4, gNB does 495 not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6. 496 To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added. 497 The SRGW maps the GTP traffic into SRv6. 499 The SRGW is not an anchor point, and maintains very little state. 500 For this reason, both IPv4 and IPv6 methods scale to millions of UEs. 502 _______ 503 IP GTP SRv6 / \ 504 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 505 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 506 +--+ +-----+ +------+ +------+ \_______/ 507 SR Gateway SRv6 node 509 Figure 4: Example topology for interworking 511 5.3.1. Interworking with IPv6 GTP 513 In this interworking mode the gNB uses GTP over IPv6 via the N3 514 interface 516 Key points: 518 o The gNB is unchanged (control-plane or user-plane) and 519 encapsulates into GTP (N3 interface is not modified). 520 o The 5G Control-Plane (N2 interface) is unmodified; one IPv6 521 address is needed (i.e. a BSID at the SRGW). 522 o The SRGW removes GTP, finds the SID list related to DA, and adds 523 SRH with the SID list. 524 o There is no state for the downlink at the SRGW. 525 o There is simple state in the uplink at the SRGW; using Enhanced 526 mode results in fewer SR policies on this node. A SR policy can 527 be shared across UEs. 528 o When a packet from the UE leaves the gNB, it is SR-routed. This 529 simplifies network slicing [I-D.hegdeppsenak-isis-sr-flex-algo]. 530 o In the uplink, the IPv6 DA BSID steers traffic into an SR policy 531 when it arrives at the SRGW-UPF1. 533 An example topology is shown in Figure 5. In this mode the gNB is an 534 unmodified gNB using IPv6/GTP. The UPFs are SR-aware. As before, 535 the SRGW maps IPv6/GTP traffic to SRv6. 537 S1 and C1 are two service segments. S1 represents a VNF in the 538 network, and C1 represents a router configured for Traffic 539 Engineering. 541 +----+ 542 IPv6/GTP -| S1 |- ___ 543 +--+ +-----+ [N3] / +----+ \ / 544 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 545 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 546 GTP \ +------+ / +----+ +------+ \___ 547 -| UPF1 |- SRv6 SRv6 548 +------+ TE 549 SR Gateway 551 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 553 5.3.1.1. Packet flow - Uplink 555 The uplink packet flow is as follows: 557 UE_out : (A,Z) 558 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 559 (IPv6/GTP) 560 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 561 SID at the SRGW 562 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 563 C1_out : (SRGW, U2::1)(A,Z) -> PSP 564 UPF2_out: (A,Z) -> End.DT4 or End.DT6 565 The UE sends a packet destined to Z toward the gNB on a specific 566 bearer for that session. The gNB, which is unmodified, encapsulates 567 the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the 568 GTP TEID T are the ones received in the N2 interface. 570 The IPv6 address that was signalled over the N2 interface for that UE 571 PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 572 SRGW. Hence the packet is routed to the SRGW. 574 When the packet arrives at the SRGW, the SRGW identifies B as an 575 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 576 the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own 577 SRH containing the SIDs bound to the SR policy associated with this 578 BindingSID. There is one instance of the End.M.GTP6.D SID per PDU 579 type. 581 S1 and C1 perform their related Endpoint functionality and forward 582 the packet. 584 When the packet arrives at UPF2, the active segment is (U2::1) which 585 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 586 IPv6 header with all its extension headers) and forwards the packet 587 toward the data network. 589 5.3.1.2. Packet flow - Downlink 591 The downlink packet flow is as follows: 593 UPF2_in : (Z,A) -> UPF2 maps the flow with 594 595 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red 596 C1_out : (U2::1, S1)(gNB, S1; SL=2)(Z,A) 597 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 598 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 599 gNB_out : (Z,A) 601 When a packet destined to A arrives at the UPF2, the UPF2 performs a 602 lookup in the table associated to A and finds the SID list . The UPF2 performs a T.Encaps.Red operation, 604 encapsulating the packet into a new IPv6 header with its 605 corresponding SRH. 607 C1 and S1 perform their related Endpoint processing. 609 Once the packet arrives at the SRGW, the SRGW identifies the active 610 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 611 and all its extensions headers. The SRGW generates new IPv6, UDP and 612 GTP headers. The new IPv6 DA is the gNB which is the last SID in the 613 received SRH. The TEID in the generated GTP header is an argument of 614 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 615 packet and forwards the packet toward the gNB. There is one instance 616 of the End.M.GTP6.E SID per PDU type. 618 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 619 packet. The gNB looks for the specific radio bearer for that TEID 620 and forward it on the bearer. This gNB behavior is not modified from 621 current and previous generations. 623 5.3.1.3. Scalability 625 For the downlink traffic, the SRGW is stateless. All the state is in 626 the SRH inserted by the UPF2. The UPF2 must have the UE states since 627 it is the UE's session anchor point. 629 For the uplink traffic, the state at the SRGW does not necessarily 630 need to be unique per UE PDU Session; the state state can be shared 631 among UEs. This enables much more scalable SRGW deployments compared 632 to a solution holding millions of states, one or more per UE. 634 5.3.1.4. IPv6 user-traffic 636 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 637 However based on local policy, a service provider MAY choose to do 638 SRH insertion. The main benefit is lower overhead. 640 5.3.2. Interworking with IPv4 GTP 642 In this interworking mode the gNB uses GTP over IPv4 in the N3 643 interface 645 Key points: 647 o The gNB is unchanged and encapsulates packets into GTP (the N3 648 interface is not modified). 649 o In the uplink, traffic is classified by SRGW's Uplink Classifier 650 and steered into an SR policy. The SRGW is a UPF1 functionality 651 and can coexist with UPF1's Uplink Classifier functionality. 652 o SRGW removes GTP, finds the SID list related to DA, and adds a SRH 653 with the SID list. 655 An example topology is shown in Figure 6. In this mode the gNB is an 656 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 657 the SRGW maps the IPv4/GTP traffic to SRv6. 659 S1 and C1 are two service segment endpoints. S1 represents a VNF in 660 the network, and C1 represents a router configured for Traffic 661 Engineering. 663 +----+ 664 IPv4/GTP -| S1 |- ___ 665 +--+ +-----+ [N3] / +----+ \ / 666 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 667 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 668 GTP \ +------+ / +----+ +------+ \___ 669 -| UPF1 |- SRv6 SRv6 670 +------+ TE 671 SR Gateway 673 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 675 5.3.2.1. Packet flow - Uplink 677 The uplink packet flow is as follows: 679 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 680 unchanged IPv4/GTP 681 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.GTP4.D function 682 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 683 C1_out : (SRGW, U2::1) (A,Z) -> PSP 684 UPF2_out: (A,Z) -> End.DT4 or End.DT6 686 The UE sends a packet destined to Z toward the gNB on a specific 687 bearer for that session. The gNB, which is unmodified, encapsulates 688 the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and 689 the GTP TEID are the ones received at the N2 interface. 691 When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink 692 Classifier rule for incoming traffic from the gNB, that steers the 693 traffic into an SR policy by using the function T.M.GTP4.D. The SRGW 694 removes the IPv4, UDP and GTP headers and pushes an IPv6 header with 695 its own SRH containing the SIDs related to the SR policy associated 696 with this traffic. The SRGW forwards according to the new IPv6 DA. 698 S1 and C1 perform their related Endpoint functionality and forward 699 the packet. 701 When the packet arrives at UPF2, the active segment is (U2::1) which 702 is bound to End.DT4/6 which performs the decapsulation (removing the 703 outer IPv6 header with all its extension headers) and forwards toward 704 the data network. 706 5.3.2.2. Packet flow - Downlink 708 The downlink packet flow is as follows: 710 UPF2_in : (Z,A) -> UPF2 maps flow with SID 711 712 UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red 713 C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) 714 S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) 715 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 716 gNB_out : (Z,A) 718 When a packet destined to A arrives at the UPF2, the UPF2 performs a 719 lookup in the table associated to A and finds the SID list . The UPF2 performs a T.Encaps.Red operation, 721 encapsulating the packet into a new IPv6 header with its 722 corresponding SRH. 724 The nodes C1 and S1 perform their related Endpoint processing. 726 Once the packet arrives at the SRGW, the SRGW identifies the active 727 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 728 and all its extensions headers. The SRGW generates an IPv4, UDP and 729 GTP headers. The IPv4 SA and DA are received as SID arguments. The 730 TEID in the generated GTP header is also the arguments of the 731 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 732 and forwards the packet toward the gNB. 734 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 735 packet. The gNB looks for the specific radio bearer for that TEID 736 and forward it on the bearer. This gNB behavior is not modified from 737 current and previous generations. 739 5.3.2.3. Scalability 741 For the downlink traffic, the SRGW is stateless. All the state is in 742 the SRH inserted by the UPF. The UPF must have this UE-base state 743 anyway (since it is its anchor point). 745 For the uplink traffic, the state at the SRGW is dedicated on a per 746 UE/session basis according to an Uplink Classifier. There is state 747 for steering the different sessions on a SR policies. However, SR 748 policies are shared among several UE/sessions. 750 5.3.2.4. IPv6 user-traffic 752 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 753 Based on local policy, a service provider MAY choose to do SRH 754 insertion. The main benefit is a lower overhead. 756 5.3.3. Extensions to the interworking mechanisms 758 In this section we presented two mechanisms for interworking with 759 gNBs that do not support SRv6. These mechanism are done to support 760 GTP over IPv4 and GTP over 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 6. SRv6 SID Mobility Functions 773 6.1. Args.Mob.Session 775 Args.Mob.Session provide per-session information for charging, 776 buffering and lawful intercept (among others) required by some mobile 777 nodes. The Args.Mob.Session argument format is used in combination 778 with End.Map, End.DT and End.DX functions. Note that proposed format 779 is applicable for 5G networks, while similar formats could be 780 proposed for legacy networks. 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | QFI |R|U| PDU Session ID | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 |PDU Sess(cont')| 788 +-+-+-+-+-+-+-+-+ 790 Args.Mob.Session format 792 o QFI: QoS Flow Identifier [TS.38415] 793 o R: Reflective QoS Indication [TS.23501]. This parameter indicates 794 the activaton of reflective QoS towards the UE for the transfered 795 packet. Reflective QoS enables the UE to map UL User Plane 796 traffic to QoS Flows without SMF provided QoS rules. 798 o U: Unused and for future use. MUST be 0 on transmission and 799 ignored on receipt. 800 o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 801 is TEID. 803 Since the SRv6 function is likely NOT to be instantiated per PDU 804 session, Args.Mob.Session helps the UPF to perform the functions 805 which require per QFI and/or per PDU Session granularity. 807 6.2. End.MAP 809 The "Endpoint function with SID mapping" function (End.MAP for short) 810 is used in several scenarios. Particularly in mobility, End.MAP is 811 used in the UPFs for the PDU Session anchor functionality. 813 When a SR node N receives a packet destined to S and S is a local 814 End.MAP SID, N does the following: 816 1. Lookup the IPv6 DA in the mapping table 817 2. update the IPv6 DA with the new mapped SID ;; Ref1 818 3. IF segment_list > 1 819 4. insert a new SRH 820 5. forward according to the new mapped SID 822 Ref1: The SIDs in the SRH are NOT modified. 824 6.3. End.M.GTP6.D 826 The "Endpoint function with IPv6/GTP decapsulation into SR policy" 827 function (End.M.GTP6.D for short) is used in interworking scenario 828 for the uplink toward from the legacy gNB using IPv6/GTP. Suppose, 829 for example, this SID is associated with an SR policy 830 and an IPv6 Source Address A. 832 When the SR Gateway node N receives a packet destined to S and S is a 833 local End.M.GTP6.D SID, N does: 835 1. IF NH=UDP & UDP_DST_PORT = GTP THEN 836 2. copy TEID to form SID S3 837 3. pop the IPv6, UDP and GTP headers 838 4. push a new IPv6 header with a SR policy in SRH 839 5. set the outer IPv6 SA to A 840 6. set the outer IPv6 DA to S1 841 7. set the outer IPv6 NH ;; Ref1 842 8. forward according to the S1 segment of the SRv6 Policy 843 9. ELSE 844 10. Drop the packet 845 Ref1: The NH is set based on the SID parameter. There is one 846 instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the 847 NH is already known in advance. For the IPv4v6 PDU Session Type, in 848 addition we inspect the first nibble of the PDU to know the NH value. 850 The prefix of last segment(S3 in above example) SHOULD be followed by 851 an Arg.Mob.Session argument space which is used to provide the 852 session identifiers. 854 The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR 855 gateway. 857 6.4. End.M.GTP6.E 859 The "Endpoint function with encapsulation for IPv6/GTP tunnel" 860 function (End.M.GTP6.E for short) is used in interworking scenario 861 for the downlink toward the legacy gNB using IPv6/GTP. 863 The prefix of End.M.GTP6.E SID MUST be followed by the 864 Arg.Mob.Session argument space which is used to provide the session 865 identifiers. 867 When the SR Gateway node N receives a packet destined to S, and S is 868 a local End.M.GTP6.E SID, N does the following: 870 1. IF NH=SRH & SL = 1 THEN ;; Ref1 871 2. store SRH[0] in variable new_DA 872 3. store TEID in variable new_TEID from IPv6 DA ;; Ref2 873 4. pop IP header and all its extension headers 874 5. push new IPv6 header and GTP-U header 875 6. set IPv6 DA to new_DA 876 7. set IPv6 SA to A 877 8. set GTP_TEID to new_TEID 878 9. lookup the new_DA and forward the packet accordingly 879 10. ELSE 880 11. Drop the packet 882 Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID. 884 Ref2: TEID is extracted from the argument space of the current SID. 886 The source address A SHOULD be an End.M.GTP6.D SID instantiated at an 887 SR gateway. 889 6.5. End.M.GTP4.E 891 The "Endpoint function with encapsulation for IPv4/GTP tunnel" 892 function (End.M.GTP4.E for short) is used in the downlink when doing 893 interworking with legacy gNB using IPv4/GTP. 895 When the SR Gateway node N receives a packet destined to S and S is a 896 local End.M.GTP4.E SID, N does: 898 1. IF (NH=SRH and SL = 0) or ENH=4 THEN 899 2. store IPv6 DA in buffer S 900 3. store IPv6 SA in buffer S' 901 4. pop the IPv6 header and its extension headers 902 5. push UDP/GTP headers with GTP TEID from S 903 6. push outer IPv4 header with SA, DA from S' and S 904 7. ELSE 905 8. Drop the packet 907 The End.M.GTP4.E SID in S has the following format: 909 0 127 910 +-----------------------+-------+----------------+---------+ 911 | SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded | 912 +-----------------------+-------+----------------+---------+ 913 128-a-b-c a b c 915 End.M.GTP4.E SID Encoding 917 S' has the following format: 919 0 127 920 +----------------------+--------+--------------------------+ 921 | Source UPF Prefix |IPv4 SA | any bit pattern(ignored) | 922 +----------------------+--------+--------------------------+ 923 128-a-b a b 925 IPv6 SA Encoding for End.M.GTP4.E 927 6.6. T.M.GTP4.D 929 The "Transit with tunnel decapsulation and map to an SRv6 policy" 930 function (T.M.GTP4.D for short) is used in the direction from legacy 931 user-plane to SRv6 user-plane network. 933 When the SR Gateway node N receives a packet destined to a IW- 934 IPv4-Prefix, N does: 936 1. IF Payload == UDP/GTP THEN 937 2. pop the outer IPv4 header and UDP/GTP headers 938 3. copy IPv4 DA, TEID to form SID B 939 4. copy IPv4 SA to form IPv6 SA B' 940 5. encapsulate the packet into a new IPv6 header ;;Ref1 941 6. set the IPv6 DA = B 942 7. forward along the shortest path to B 943 8. ELSE 944 9. Drop the packet 946 Ref1: The NH value is identified by inspecting the first nibble of 947 the inner payload. 949 The SID B has the following format: 951 0 127 952 +-----------------------+-------+----------------+---------+ 953 |Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded | 954 +-----------------------+-------+----------------+---------+ 955 128-a-b-c a b c 957 T.M.GTP4.D SID Encoding 959 The SID B MAY be an SRv6 Binding SID instantiated at the first UPF 960 (U1) to bind a SR policy [I-D.ietf-spring-segment-routing-policy]. 962 The prefix of B' SHOULD be an End.M.GTP4.E SID with its format 963 instantiated at an SR gateway with the IPv4 SA of the receiving 964 packet. 966 6.7. End.Limit: Rate Limiting function 968 The mobile user-plane requires a rate-limit feature. For this 969 purpose, we define a new function "End.Limit". The "End.Limit" 970 function encodes in its arguments the rate limiting parameter that 971 should be applied to this packet. Multiple flows of packets should 972 have the same group identifier in the SID when those flows are in an 973 same AMBR group. The encoding format of the rate limit segment SID 974 is as follows: 976 +----------------------+----------+-----------+ 977 | LOC+FUNC rate-limit | group-id | limit-rate| 978 +----------------------+----------+-----------+ 979 128-i-j i j 981 End.Limit: Rate limiting function argument format 983 If the limit-rate bits are set to zero, the node should not do rate 984 limiting unless static configuration or control-plane sets the limit 985 rate associated to the SID. 987 7. SRv6 supported 3GPP PDU session types 989 The 3GPP [TS.23501] defines the following PDU session types: 991 o IPv4 992 o IPv6 993 o IPv4v6 994 o Ethernet 995 o Unstructured 997 SRv6 supports all the 3GPP PDU session types without any protocol 998 overhead by using the corresponding SRv6 functions (End.DX4, End.DT4 999 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 1000 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 PDU sessions; 1001 End.DX2 for Unstructured PDU sessions). 1003 8. Network Slicing Considerations 1005 A mobile network may be required to implement "network slices", which 1006 logically separate network resources. User-plane functions 1007 represented as SRv6 segments would be part of a slice. 1009 [I-D.ietf-spring-segment-routing-policy] describes a solution to 1010 build basic network slices with SR. Depending on the requirements, 1011 these slices can be further refined by adopting the mechanisms from: 1013 o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo] 1014 o Inter-Domain policies 1015 [I-D.ietf-spring-segment-routing-central-epe] 1017 Furthermore, these can be combined with ODN/AS 1018 [I-D.ietf-spring-segment-routing-policy] for automated slice 1019 provisioning and traffic steering. 1021 Further details on how these tools can be used to create end to end 1022 network slices are documented in 1023 [I-D.ali-spring-network-slicing-building-blocks]. 1025 9. Control Plane Considerations 1027 This document focuses on user-plane behavior and its independence 1028 from the control plane. 1030 The control plane could be the current 3GPP-defined control plane 1031 with slight modifications to the N4 interface [TS.29244]. 1033 Alternatively, SRv6 could be used in conjunction with a new mobility 1034 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 1035 hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA 1036 [I-D.gundavelli-dmm-mfa] or in conjunction with FPC 1037 [I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes 1038 and its applicability to SRv6 is out of the scope of this document. 1040 Section 11 allocates SRv6 endpoint function types for the new 1041 functions defined in this document. Control-plane protocols are 1042 expected to use these function type codes to signal each function. 1044 SRv6's network programming nature allows a flexible and dynamic UPF 1045 placement. 1047 10. Security Considerations 1049 TBD 1051 11. IANA Considerations 1053 IANA is requested to allocate, within the "SRv6 Endpoint Types" sub- 1054 registry belonging to the top-level "Segment-routing with IPv6 1055 dataplane (SRv6) Parameters" registry 1056 [I-D.ietf-spring-srv6-network-programming], the following values: 1058 +-------------+-----+-------------------+-----------+ 1059 | Value/Range | Hex | Endpoint function | Reference | 1060 +-------------+-----+-------------------+-----------+ 1061 | TBA | TBA | End.MAP | [This.ID] | 1062 | TBA | TBA | End.M.GTP6.D | [This.ID] | 1063 | TBA | TBA | End.M.GTP6.E | [This.ID] | 1064 | TBA | TBA | End.M.GTP4.E | [This.ID] | 1065 | TBA | TBA | End.Limit | [This.ID] | 1066 +-------------+-----+-------------------+-----------+ 1068 Table 1: SRv6 Mobile User-plane Endpoint Types 1070 12. Acknowledgements 1072 The authors would like to thank Daisuke Yokota, Bart Peirens, 1073 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1074 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1075 Shekhar and Aeneas Dodd-Noble for their useful comments of this work. 1077 13. Contributors 1079 Kentaro Ebisawa 1080 Toyota Motor Corporation 1081 Japan 1083 Email: ebisawa@toyota-tokyo.tech 1085 14. References 1087 14.1. Normative References 1089 [I-D.ietf-6man-segment-routing-header] 1090 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 1091 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 1092 Routing Header (SRH)", draft-ietf-6man-segment-routing- 1093 header-23 (work in progress), September 2019. 1095 [I-D.ietf-spring-segment-routing-policy] 1096 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 1097 bogdanov@google.com, b., and P. Mattes, "Segment Routing 1098 Policy Architecture", draft-ietf-spring-segment-routing- 1099 policy-03 (work in progress), May 2019. 1101 [I-D.ietf-spring-srv6-network-programming] 1102 Filsfils, C., Camarillo, P., Leddy, J., 1103 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1104 Network Programming", draft-ietf-spring-srv6-network- 1105 programming-02 (work in progress), September 2019. 1107 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1108 Requirement Levels", BCP 14, RFC 2119, 1109 DOI 10.17487/RFC2119, March 1997, 1110 . 1112 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1113 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1114 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1115 July 2018, . 1117 14.2. Informative References 1119 [I-D.ali-spring-network-slicing-building-blocks] 1120 Ali, Z., Filsfils, C., Camarillo, P., and d. 1121 daniel.voyer@bell.ca, "Building blocks for Slicing in 1122 Segment Routing Network", draft-ali-spring-network- 1123 slicing-building-blocks-01 (work in progress), March 2019. 1125 [I-D.auge-dmm-hicn-mobility-deployment-options] 1126 Auge, J., Carofiglio, G., Muscariello, L., and M. 1127 Papalini, "Anchorless mobility management through hICN 1128 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1129 mobility-deployment-options-02 (work in progress), July 1130 2019. 1132 [I-D.camarillo-dmm-srv6-mobile-pocs] 1133 Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A., 1134 Matsushima, S., and d. daniel.voyer@bell.ca, "Segment 1135 Routing IPv6 for mobile user-plane PoCs", draft-camarillo- 1136 dmm-srv6-mobile-pocs-02 (work in progress), April 2019. 1138 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1139 Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S., 1140 daniel.voyer@bell.ca, d., Cui, A., and B. Peirens, "SRv6 1141 Mobility Use-Cases", draft-camarilloelmalky-springdmm- 1142 srv6-mob-usecases-02 (work in progress), August 2019. 1144 [I-D.gundavelli-dmm-mfa] 1145 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 1146 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01 1147 (work in progress), September 2018. 1149 [I-D.hegdeppsenak-isis-sr-flex-algo] 1150 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 1151 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 1152 isis-sr-flex-algo-02 (work in progress), February 2018. 1154 [I-D.ietf-dmm-fpc-cpdp] 1155 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1156 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1157 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 1158 (work in progress), June 2018. 1160 [I-D.ietf-spring-segment-routing-central-epe] 1161 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1162 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1163 Engineering", draft-ietf-spring-segment-routing-central- 1164 epe-10 (work in progress), December 2017. 1166 [I-D.rodrigueznatal-lisp-srv6] 1167 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1168 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1169 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-02 1170 (work in progress), July 2019. 1172 [I-D.xuclad-spring-sr-service-programming] 1173 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1174 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1175 Henderickx, W., and S. Salsano, "Service Programming with 1176 Segment Routing", draft-xuclad-spring-sr-service- 1177 programming-02 (work in progress), April 2019. 1179 [TS.23501] 1180 3GPP, "System Architecture for the 5G System", 3GPP TS 1181 23.501 15.0.0, November 2017. 1183 [TS.29244] 1184 3GPP, "Interface between the Control Plane and the User 1185 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1187 [TS.29281] 1188 3GPP, "General Packet Radio System (GPRS) Tunnelling 1189 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1190 December 2017. 1192 [TS.38415] 1193 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1194 3GPP R3-174510 0.0.0, August 2017. 1196 Appendix A. Implementations 1198 This document introduces new SRv6 functions. These functions have an 1199 open-source P4 implementation available in 1200 . 1202 There are also implementations in M-CORD NGIC and Open Air Interface 1203 (OAI). Further details can be found in 1204 [I-D.camarillo-dmm-srv6-mobile-pocs]. 1206 Authors' Addresses 1208 Satoru Matsushima 1209 SoftBank 1210 Tokyo 1211 Japan 1213 Email: satoru.matsushima@g.softbank.co.jp 1214 Clarence Filsfils 1215 Cisco Systems, Inc. 1216 Belgium 1218 Email: cf@cisco.com 1220 Miya Kohno 1221 Cisco Systems, Inc. 1222 Japan 1224 Email: mkohno@cisco.com 1226 Pablo Camarillo Garvia 1227 Cisco Systems, Inc. 1228 Spain 1230 Email: pcamaril@cisco.com 1232 Daniel Voyer 1233 Bell Canada 1234 Canada 1236 Email: daniel.voyer@bell.ca 1238 Charles E. Perkins 1239 Futurewei Inc. 1240 2330 Central Expressway 1241 Santa Clara, CA 95050 1242 USA 1244 Phone: +1-408-330-4586 1245 Email: charliep@computer.org