idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-04.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 (March 11, 2019) is 1866 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 881, but not defined -- Looks like a reference, but probably isn't: '2' on line 178 -- Looks like a reference, but probably isn't: '1' on line 178 -- Looks like a reference, but probably isn't: '0' on line 905 == Missing Reference: 'WHITEPAPER-5G-UP' is mentioned on line 254, but not defined == Missing Reference: 'N11' is mentioned on line 259, but not defined == Missing Reference: 'N2' is mentioned on line 260, but not defined == Missing Reference: 'N4' is mentioned on line 264, but not defined == Missing Reference: 'N3' is mentioned on line 687, but not defined == Missing Reference: 'N9' is mentioned on line 525, but not defined == Missing Reference: 'N6' is mentioned on line 688, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-05 ** Downref: Normative reference to an Informational draft: draft-voyer-6man-extension-header-insertion (ref. 'I-D.voyer-6man-extension-header-insertion') == 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-01 == Outdated reference: A later version (-02) exists of draft-camarillo-dmm-srv6-mobile-pocs-01 == Outdated reference: A later version (-02) exists of draft-camarilloelmalky-springdmm-srv6-mob-usecases-01 == 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-01 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-01 Summary: 1 error (**), 0 flaws (~~), 18 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: September 12, 2019 M. Kohno 6 P. Camarillo 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 March 11, 2019 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-04 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 and SLA control for various 25 applications. This document describes the SRv6 mobile user plane 26 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 September 12, 2019. 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.1.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 9 74 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 75 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 76 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11 77 5.2.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 11 78 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 79 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 80 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15 81 5.3.3. Extensions to the interworking mechanisms . . . . . . 17 82 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18 83 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18 84 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 19 86 6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19 87 6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20 88 6.6. T.M.Tmap . . . . . . . . . . . . . . . . . . . . . . . . 20 89 6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 21 90 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22 91 8. Network Slicing Considerations . . . . . . . . . . . . . . . 22 92 9. Control Plane Considerations . . . . . . . . . . . . . . . . 22 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 94 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 95 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 99 14.2. Informative References . . . . . . . . . . . . . . . . . 25 100 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 26 101 Appendix B. Changes from revision 02 to revision 03 . . . . . . 26 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 104 1. Introduction 106 In mobile networks, mobility management systems provide connectivity 107 while mobile nodes move. While the control-plane of the system 108 signals movements of a mobile node, the user-plane establishes a 109 tunnel between the mobile node and its anchor node over IP-based 110 backhaul and core networks. 112 This document shows the applicability of SRv6 (Segment Routing IPv6) 113 to those mobile networks. SRv6 provides source routing to networks 114 so that operators can explicitly indicate a route for the packets to 115 and from the mobile node. SRv6 endpoint nodes serve as the anchors 116 of mobile user-plane. 118 2. Conventions and Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2.1. Terminology 126 o AMBR: Aggregate Maximum Bit Rate 127 o APN: Access Point Name (commonly used to identify a network or 128 class of service) 129 o BSID: SR Binding SID [RFC8402] 130 o CNF: Cloud-native Network Function 131 o gNB: gNodeB 132 o NH: The IPv6 next-header field. 133 o NFV: Network Function Virtualization 134 o PDU: Packet Data Unit 135 o Session: TBD... 136 o SID: A Segment Identifier which represents a specific segment in a 137 segment routing domain. 138 o SRH: The Segment Routing Header. 139 [I-D.ietf-6man-segment-routing-header] 140 o TEID: Tunnel Endpoint Identifier 141 o UE: User Equipment 142 o UPF: User Plane Function 143 o VNF: Virtual Network Function 145 2.2. Conventions 147 o NH=SRH means that NH is 43 with routing type 4. 148 o Multiple SRHs may be present inside each packet, but they must 149 follow each other. The next-header field of each SRH, except the 150 last one, must be NH-SRH (43 type 4). 151 o For simplicity, no other extension headers are shown except the 152 SRH. 153 o The SID type used in this document is IPv6 address (also called 154 SRv6 Segment or SRv6 SID). 155 o gNB::1 is an IPv6 address (SID) assigned to the gNB. 156 o U1::1 is an IPv6 address (SID) assigned to UPF1. 157 o U2::1 is an IPv6 address (SID) assigned to UPF2. 158 o U2:: is some other IPv6 address (SID) assigned to UPF2. 159 o A SID list is represented as where S1 is the first 160 SID to visit, S2 is the second SID to visit and S3 is the last SID 161 to visit along the SR path. 162 o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 164 * IPv6 header with source and destination addresses SA and DA 165 respectively, and next-header SRH, with SID list 166 with SegmentsLeft = SL 167 * The payload of the packet is not represented. 168 o Note the difference between the <> and () symbols: 169 represents a SID list where S1 is the first SID and S3 is the last 170 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 171 the SRH format where the rightmost SID in the SRH is the first SID 172 and the leftmost SID in the SRH is the last SID. When referring 173 to an SR policy in a high-level use-case, it is simpler to use the 174 notation. When referring to an illustration of the 175 detailed behavior, the (S3, S2, S1; SL) notation is more 176 convenient. 177 o SRH[SL] represents the SID pointed by the SL field in the first 178 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 179 and SRH[0] represents S3. 180 o SRH[SL] can be different from the DA of the IPv6 header. 182 2.3. Predefined SRv6 Functions 184 The following functions are defined in 185 [I-D.filsfils-spring-srv6-network-programming]. 187 o End.DT4 means to decapsulate and forward using a specific IPv4 188 table lookup. 190 o End.DT6 means to decapsulate and forward using a specific IPv6 191 table lookup. 192 o End.DX4 means to decapsulate the packet and forward through a 193 particular outgoing interface -or set of OIFs- configured with the 194 SID. 195 o End.DX6 means to decapsulate and forward through a particular 196 outgoing interface -or set of OIFs- configured with the SID. 197 o End.DX2 means to decapsulate the L2 frame and forward through a 198 particular outgoing interface -or set of OIFs- configured with the 199 SID. 200 o End.T means to forward using a specific IPv6 table lookup. 201 o End.X means to forward through a link configured with the SID. 202 o T.Encaps.Red means encapsulation without pushing SRH (resulting in 203 "Reduced" packet size). 204 o PSP means Penultimate Segment Pop. The packet is subsequently 205 forwarded without the popped SRH. 207 New SRv6 functions are defined in Section 6 to support the needs of 208 the mobile user plane. 210 3. Motivation 212 Mobility networks are becoming more challenging to operate. On one 213 hand, traffic is constantly growing, and latency requirements are 214 more strict; on the other-hand, there are new use-cases like NFV that 215 are also challenging network management. 217 The current architecture of mobile networks does not take into 218 account the underlying transport. The user-plane is rigidly 219 fragmented into radio access, core and service networks, connected by 220 tunneling according to user-plane roles such as access and anchor 221 nodes. These factors have made it difficult for the operator to 222 optimize and operate the data-path. 224 In the meantime, applications have shifted to use IPv6, and network 225 operators have started adopting IPv6 as their IP transport. SRv6, 226 the IPv6 dataplane instantiation of Segment Routing [RFC8402], 227 integrates both the application data-path and the underlying 228 transport layer into a single protocol, allowing operators to 229 optimize the network in a simplified manner and removing forwarding 230 state from the network. It is also suitable for virtualized 231 environments, VNF/CNF to VNF/CNF networking. 233 SRv6 specifies network-programming (see 234 [I-D.filsfils-spring-srv6-network-programming]). Applied to 235 mobility, SRv6 can provide the user-plane functions needed for 236 mobility management. SRv6 takes advantage of underlying transport 237 awareness and flexibility to improve mobility user-plane functions. 239 The use-cases for SRv6 mobility are discussed in 240 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]. 242 4. A 3GPP Reference Architecture 244 This section presents a reference architecture and possible 245 deployment scenarios. 247 Figure 1 shows a reference diagram from the 5G packet core 248 architecture [TS.23501]. 250 The user plane described in this document does not depend on any 251 specific architecture. The 5G packet core architecture as shown is 252 based on the latest 3GPP standards at the time of writing this draft. 253 Other architectures can be seen in [I-D.gundavelli-dmm-mfa] and 254 [WHITEPAPER-5G-UP]. 256 +-----+ 257 | AMF | 258 +-----+ 259 / | [N11] 260 [N2] / +-----+ 261 +------/ | SMF | 262 / +-----+ 263 / / \ 264 / / \ [N4] 265 / / \ ________ 266 / / \ / \ 267 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 268 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 269 +--+ +-----+ +------+ +------+ \________/ 271 Figure 1: 3GPP 5G Reference Architecture 273 o gNB: gNodeB 274 o UPF1: UPF with Interfaces N3 and N9 275 o UPF2: UPF with Interfaces N9 and N6 276 o SMF: Session Management Function 277 o AMF: Access and Mobility Management Function 278 o DN: Data Network e.g. operator services, Internet access 280 This reference diagram does not depict a UPF that is only connected 281 to N9 interfaces, although the description in this document also work 282 for such UPFs. 284 Each session from an UE gets assigned to a UPF. Sometimes multiple 285 UPFs may be used, providing richer service functions. A UE gets its 286 IP address from the DHCP block of its UPF. The UPF advertises that 287 IP address block toward the Internet, ensuring that return traffic is 288 routed to the right UPF. 290 5. User-plane behaviors 292 This section describes some mobile user-plane behaviors using SRv6. 294 In order to simplify the adoption of SRv6, we present two different 295 "modes" that vary with respect to the use of SRv6. The first one is 296 the "Traditional mode", which inherits the current 3GPP mobile user- 297 plane. In this mode there is no change to mobility networks 298 architecture, except that GTP-U [TS.29281] is replaced by SRv6. 300 The second mode is the "Enhanced mode". In this mode the SR policy 301 contains SIDs for Traffic Engineering and VNFs, which results in 302 effective end-to-end network slices. 304 In both, the Traditional and the Enhanced modes, we assume that the 305 gNB as well as the UPFs are SR-aware (N3, N9 and -potentially- N6 306 interfaces are SRv6). 308 We introduce two mechanisms for interworking with legacy access 309 networks (N3 interface is unmodified). In these document we 310 introduce them applied to the Enhanced mode, although they could be 311 used in combination with the Traditional mode as well. 313 One of these mechanisms is designed to interwork with legacy gNBs 314 using GTP/IPv4. The second method is designed to interwork with 315 legacy gNBs using GTP/IPv6. 317 This document uses SRv6 functions defined in 318 [I-D.filsfils-spring-srv6-network-programming] as well as new SRv6 319 functions designed for the mobile user plane. The new SRv6 functions 320 are detailed in Section 6. 322 5.1. Traditional mode 324 In the traditional mode, the existing mobile UPFs remain unchanged 325 except for the use of SRv6 as the data plane instead of GTP-U. There 326 is no impact to the rest of mobile system. 328 In existing 3GPP mobile networks, an UE session is mapped 1-for-1 329 with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored 330 here to replace GTP encapsulation with the SRv6 encapsulation, while 331 not changing anything else. There will be a unique SRv6 SID 332 associated with each UE session. 334 The traditional mode minimizes the changes required to the mobile 335 system; it is a good starting point for forming a common basis. 337 Our example topology is shown in Figure 2. In traditional mode the 338 gNB and the UPFs are SR-aware. In the descriptions of the uplink and 339 downlink packet flow, A is an IPv6 address of the UE, and Z is an 340 IPv6 address reachable within the Data Network DN. A new SRv6 341 function End.MAP, defined in Section 6.2, is used. 343 ________ 344 SRv6 SRv6 / \ 345 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 346 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 347 +--+ +-----+ +------+ +------+ \________/ 348 SRv6 node SRv6 node SRv6 node 350 Figure 2: Traditional mode - example topology 352 5.1.1. Packet flow - Uplink 354 The uplink packet flow is as follows: 356 UE_out : (A,Z) 357 gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Red 358 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 359 UPF2_out: (A,Z) -> End.DT4 or End.DT6 361 When the UE packet arrives at the gNB, the gNB performs a 362 T.Encaps.Red operation. Since there is only one SID, there is no 363 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 364 U1::1. U1::1 represents an anchoring SID specific for that session 365 at UPF1. gNB obtains the SID U1::1 from the existing control plane 366 (N2 interface). 368 When the packet arrives at UPF1, the SID U1::1 identifies a local 369 End.MAP function. End.MAP replaces U1::1 by U2::1, that belongs to 370 the next UPF (U2). 372 When the packet arrives at UPF2, the SID U2::1 corresponds to an 373 End.DT function. UPF2 decapsulates the packet, performs a lookup in 374 a specific table associated with that mobile network and forwards the 375 packet toward the data network (DN). 377 5.1.2. Packet flow - Downlink 379 The downlink packet flow is as follows: 381 UPF2_in : (Z,A) 382 UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red 383 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 384 gNB_out : (Z,A) -> End.DX4 or End.DX6 386 When the packet arrives at the UPF2, the UPF2 maps that flow into a 387 UE session. This UE session is associated with the segment endpoint 388 . UPF2 performs a T.Encaps.Red operation, encapsulating the 389 packet into a new IPv6 header with no SRH since there is only one 390 SID. 392 Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 393 function. This function maps the SID to the next anchoring point and 394 replaces U1::1 by gNB::1, that belongs to the next hop. 396 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4 397 or End.DX6 function. The gNB decapsulates the packet, removing the 398 IPv6 header and all its extensions headers, and forwards the traffic 399 toward the UE. 401 5.1.3. IPv6 user-traffic 403 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 404 However based on local policy, a service provider MAY choose to do 405 SRH insertion [I-D.voyer-6man-extension-header-insertion] . The main 406 benefit is a lower overhead (40B less). In such case, the functions 407 used are T.Insert.Red at gNB, End.MAP at UPF1 and End.T at UPF2 on 408 Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at gNB on 409 Downlink. 411 5.2. Enhanced Mode 413 Enhanced mode improves scalability, traffic steering and service 414 programming [I-D.xuclad-spring-sr-service-programming], thanks to the 415 use of multiple SIDs, instead of a single SID as done in the 416 Traditional mode. 418 The main difference is that the SR policy MAY include SIDs for 419 traffic engineering and service programming in addition to the UPFs 420 SIDs. 422 The gNB control-plane (N2 interface) is unchanged, specifically a 423 single IPv6 address is given to the gNB. 425 o The gNB MAY resolve the IP address into a SID list using a 426 mechanism like PCEP, DNS-lookup, small augment for LISP control- 427 plane, etc. 429 Note that the SIDs MAY use the arguments Args.Mob.Session if required 430 by the UPFs. 432 Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 433 gNB and the UPF are SR-aware. The Figure shows two service segments, 434 S1 and C1. S1 represents a VNF in the network, and C1 represents a 435 constraint path on a router requiring Traffic Engineering. S1 and C1 436 belong to the underlay and don't have an N4 interface, so they are 437 not considered UPFs. 439 +----+ SRv6 _______ 440 SRv6 --| C1 |--[N3] / \ 441 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 442 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 443 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 444 SRv6 node \ +----+ / SRv6 node 445 -| S1 |- 446 +----+ 447 SRv6 node 448 CNF 450 Figure 3: Enhanced mode - Example topology 452 5.2.1. Packet flow - Uplink 454 The uplink packet flow is as follows: 456 UE_out : (A,Z) 457 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red 458 S1_out : (gNB, C1)(U2::1, C1; SL=1 (A,Z) 459 C1_out : (gNB, U2::1)(A,Z) -> PSP 460 UPF2_out: (A,Z) -> End.DT4 or End.DT6 462 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 463 control plane associates that session from the UE(A) with the IPv6 464 address B and GTP TEID T. gNB's control plane does a lookup on B to 465 find the related SID list . 467 When gNB transmits the packet, it contains all the segments of the SR 468 policy. The SR policy can include segments for traffic engineering 469 (C1) and for service programming (S1). 471 Nodes S1 and C1 perform their related Endpoint functionality and 472 forward the packet. 474 When the packet arrives at UPF2, the active segment (U2::1) is an 475 End.DT4/6 which performs the decapsulation (removing the IPv6 header 476 with all its extension headers) and forwards toward the data network. 478 5.2.2. Packet flow - Downlink 480 The downlink packet flow is as follows: 482 UPF2_in : (Z,A) -> UPF2 maps the flow w/ 483 SID list 484 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red 485 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 486 S1_out : (U2::1, gNB)(Z,A) -> PSP 487 gNB_out : (Z,A) -> End.DX4 or End.DX6 489 When the packet arrives at the UPF2, the UPF2 maps that particular 490 flow into a UE session. This UE session is associated with the 491 policy . The UPF2 performs a T.Encaps.Red operation, 492 encapsulating the packet into a new IPv6 header with its 493 corresponding SRH. 495 The nodes C1 and S1 perform their related Endpoint processing. 497 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 498 End.DX4 or End.DX6 (depending on the underlying traffic). The gNB 499 decapsulates the packet, removing the IPv6 header and all its 500 extensions headers and forwards the traffic toward the UE. 502 5.2.3. IPv6 user-traffic 504 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 505 However based on local policy, a service provider MAY choose to do 506 SRH insertion. The main benefit is a lower overhead. In such case, 507 the functions used are T.Insert.Red at gNB and End.T at UPF2 on 508 Uplink, T.Insert.Red at UPF2 and End.X at gNB on Downlink. 510 5.3. Enhanced mode with unchanged gNB GTP behavior 512 This section describes two mechanisms for interworking with legacy 513 gNBs that still use GTP: one for IPv4, the other for IPv6. 515 In the interworking scenarios as illustrated in Figure 4, gNB does 516 not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6. 517 To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added. 518 The SRGW maps the GTP traffic into SRv6. 520 The SRGW is not an anchor point, and maintains very little state. 521 For this reason, both IPv4 and IPv6 methods scale to millions of UEs. 523 _______ 524 IP GTP SRv6 / \ 525 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 526 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 527 +--+ +-----+ +------+ +------+ \_______/ 528 SR Gateway SRv6 node 530 Figure 4: Example topology for interworking 532 5.3.1. Interworking with IPv6 GTP 534 In this interworking mode the gNB uses GTP over IPv6 via the N3 535 interface 537 Key points: 539 o The gNB is unchanged (control-plane or user-plane) and 540 encapsulates into GTP (N3 interface is not modified). 541 o The 5G Control-Plane (N2 interface) is unmodified; one IPv6 542 address is needed (i.e. a BSID at the SRGW). 543 o The SRGW removes GTP, finds the SID list related to DA, and adds 544 SRH with the SID list. 545 o There is no state for the downlink at the SRGW. 546 o There is simple state in the uplink at the SRGW; using Enhanced 547 mode results in fewer SR policies on this node. A SR policy can 548 be shared across UEs. 549 o When a packet from the UE leaves the gNB, it is SR-routed. This 550 simplifies network slicing [I-D.hegdeppsenak-isis-sr-flex-algo]. 551 o In the uplink, the IPv6 DA BSID steers traffic into an SR policy 552 when it arrives at the SRGW-UPF1. 554 An example topology is shown in Figure 5. In this mode the gNB is an 555 unmodified gNB using IPv6/GTP. The UPFs are SR-aware. As before, 556 the SRGW maps IPv6/GTP traffic to SRv6. 558 S1 and C1 are two service segments. S1 represents a VNF in the 559 network, and C1 represents a router configured for Traffic 560 Engineering. 562 +----+ 563 IPv6/GTP -| S1 |- ___ 564 +--+ +-----+ [N3] / +----+ \ / 565 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 566 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 567 GTP \ +------+ / +----+ +------+ \___ 568 -| UPF1 |- SRv6 SRv6 569 +------+ TE 570 SR Gateway 572 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 574 5.3.1.1. Packet flow - Uplink 576 The uplink packet flow is as follows: 578 UE_out : (A,Z) 579 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 580 (IPv6/GTP) 581 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 582 SID at the SRGW 583 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 584 C1_out : (SRGW, U2::1)(A,Z) -> PSP 585 UPF2_out: (A,Z) -> End.DT4 or End.DT6 587 The UE sends a packet destined to Z toward the gNB on a specific 588 bearer for that session. The gNB, which is unmodified, encapsulates 589 the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the 590 GTP TEID T are the ones received in the N2 interface. 592 The IPv6 address that was signalled over the N2 interface for that UE 593 session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 594 SRGW. Hence the packet is routed to the SRGW. 596 When the packet arrives at the SRGW, the SRGW identifies B as an 597 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 598 the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own 599 SRH containing the SIDs bound to the SR policy associated with this 600 BindingSID. There is one instance of the End.M.GTP6.D SID per PDU 601 type. 603 S1 and C1 perform their related Endpoint functionality and forward 604 the packet. 606 When the packet arrives at UPF2, the active segment is (U2::1) which 607 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 608 IPv6 header with all its extension headers) and forwards the packet 609 toward the data network. 611 5.3.1.2. Packet flow - Downlink 613 The downlink packet flow is as follows: 615 UPF2_in : (Z,A) -> UPF2 maps the flow with 616 617 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red 618 C1_out : (U2::1, S1)(gNB, S1; SL=2)(Z,A) 619 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 620 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 621 gNB_out : (Z,A) 623 When a packet destined to A arrives at the UPF2, the UPF2 performs a 624 lookup in the table associated to A and finds the SID list . The UPF2 performs a T.Encaps.Red operation, 626 encapsulating the packet into a new IPv6 header with its 627 corresponding SRH. 629 C1 and S1 perform their related Endpoint processing. 631 Once the packet arrives at the SRGW, the SRGW identifies the active 632 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 633 and all its extensions headers. The SRGW generates new IPv6, UDP and 634 GTP headers. The new IPv6 DA is the gNB which is the last SID in the 635 received SRH. The TEID in the generated GTP header is an argument of 636 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 637 packet and forwards the packet toward the gNB. There is one instance 638 of the End.M.GTP6.E SID per PDU type. 640 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 641 packet. The gNB looks for the specific radio bearer for that TEID 642 and forward it on the bearer. This gNB behavior is not modified from 643 current and previous generations. 645 5.3.1.3. Scalability 647 For the downlink traffic, the SRGW is stateless. All the state is in 648 the SRH inserted by the UPF2. The UPF2 must have the UE states since 649 it is the UE's session anchor point. 651 For the uplink traffic, the state at the SRGW does not necessarily 652 need to be unique per UE session; the state state can be shared among 653 UEs. This enables much more scalable SRGW deployments compared to a 654 solution holding millions of states, one or more per UE. 656 5.3.1.4. IPv6 user-traffic 658 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 659 However based on local policy, a service provider MAY choose to do 660 SRH insertion. The main benefit is lower overhead. 662 5.3.2. Interworking with IPv4 GTP 664 In this interworking mode the gNB uses GTP over IPv4 in the N3 665 interface 667 Key points: 669 o The gNB is unchanged and encapsulates packets into GTP (the N3 670 interface is not modified). 671 o In the uplink, traffic is classified by SRGW's Uplink Classifier 672 and steered into an SR policy. The SRGW is a UPF1 functionality 673 and can coexist with UPF1's Uplink Classifier functionality. 674 o SRGW removes GTP, finds the SID list related to DA, and adds a SRH 675 with the SID list. 677 An example topology is shown in Figure 6. In this mode the gNB is an 678 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 679 the SRGW maps the IPv4/GTP traffic to SRv6. 681 S1 and C1 are two service segment endpoints. S1 represents a VNF in 682 the network, and C1 represents a router configured for Traffic 683 Engineering. 685 +----+ 686 IPv4/GTP -| S1 |- ___ 687 +--+ +-----+ [N3] / +----+ \ / 688 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 689 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 690 GTP \ +------+ / +----+ +------+ \___ 691 -| UPF1 |- SRv6 SRv6 692 +------+ TE 693 SR Gateway 695 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 697 5.3.2.1. Packet flow - Uplink 699 The uplink packet flow is as follows: 701 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 702 unchanged IPv4/GTP 703 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.Tmap function 704 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 705 C1_out : (SRGW, U2::1) (A,Z) -> PSP 706 UPF2_out: (A,Z) -> End.DT4 or End.DT6 708 The UE sends a packet destined to Z toward the gNB on a specific 709 bearer for that session. The gNB, which is unmodified, encapsulates 710 the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and 711 the GTP TEID are the ones received at the N2 interface. 713 When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink 714 Classifier rule for incoming traffic from the gNB, that steers the 715 traffic into an SR policy by using the function T.M.TMap. The SRGW 716 removes the IPv4, UDP and GTP headers and pushes an IPv6 header with 717 its own SRH containing the SIDs related to the SR policy associated 718 with this traffic. The SRGW forwards according to the new IPv6 DA. 720 S1 and C1 perform their related Endpoint functionality and forward 721 the packet. 723 When the packet arrives at UPF2, the active segment is (U2::1) which 724 is bound to End.DT4/6 which performs the decapsulation (removing the 725 outer IPv6 header with all its extension headers) and forwards toward 726 the data network. 728 5.3.2.2. Packet flow - Downlink 730 The downlink packet flow is as follows: 732 UPF2_in : (Z,A) -> UPF2 maps flow with SID 733 734 UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red 735 C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) 736 S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) 737 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 738 gNB_out : (Z,A) 740 When a packet destined to A arrives at the UPF2, the UPF2 performs a 741 lookup in the table associated to A and finds the SID list . The UPF2 performs a T.Encaps.Red operation, 743 encapsulating the packet into a new IPv6 header with its 744 corresponding SRH. 746 The nodes C1 and S1 perform their related Endpoint processing. 748 Once the packet arrives at the SRGW, the SRGW identifies the active 749 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 750 and all its extensions headers. The SRGW generates an IPv4, UDP and 751 GTP headers. The IPv4 SA and DA are received as SID arguments. The 752 TEID in the generated GTP header is also the arguments of the 753 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 754 and forwards the packet toward the gNB. 756 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 757 packet. The gNB looks for the specific radio bearer for that TEID 758 and forward it on the bearer. This gNB behavior is not modified from 759 current and previous generations. 761 5.3.2.3. Scalability 763 For the downlink traffic, the SRGW is stateless. All the state is in 764 the SRH inserted by the UPF. The UPF must have this UE-base state 765 anyway (since it is its anchor point). 767 For the uplink traffic, the state at the SRGW is dedicated on a per 768 UE/session basis according to an Uplink Classifier. There is state 769 for steering the different sessions on a SR policies. However, SR 770 policies are shared among several UE/sessions. 772 5.3.2.4. IPv6 user-traffic 774 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 775 Based on local policy, a service provider MAY choose to do SRH 776 insertion. The main benefit is a lower overhead. 778 5.3.3. Extensions to the interworking mechanisms 780 In this section we presented two mechanisms for interworking with 781 gNBs that do not support SRv6. These mechanism are done to support 782 GTP over IPv4 and GTP over IPv6. 784 Even though we have presented these methods as an extension to the 785 "Enhanced mode", it is straightforward in its applicability to the 786 "Traditional mode". 788 Furthermore, although these mechanisms are designed for interworking 789 with legacy RAN at the N3 interface, these methods could also be 790 applied for interworking with a non-SRv6 capable UPF at the N9 791 interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). 793 6. SRv6 SID Mobility Functions 795 6.1. Args.Mob.Session 797 Args.Mob.Session provide per-session information for charging, 798 buffering and lawful intercept (among others) required by some mobile 799 nodes. The Args.Mob.Session argument format is used in combination 800 with End.Map, End.DT and End.DX functions. Note that proposed format 801 is applicable for 5G networks, while similar formats could be 802 proposed for legacy networks. 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | QFI |R|U| PDU Session ID | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 |PDU Sess(cont')| 810 +-+-+-+-+-+-+-+-+ 812 Args.Mob.Session format 814 o QFI: QoS Flow Identifier [TS.38415] 815 o R: Reflective QoS Indication [TS.23501]. This parameter indicates 816 the activaton of reflective QoS towards the UE for the transfered 817 packet. Reflective QoS enables the UE to map UL User Plane 818 traffic to QoS Flows without SMF provided QoS rules. 819 o U: Unused and for future use. MUST be 0 on transmission and 820 ignored on receipt. 821 o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 822 is TEID. 824 Since the SRv6 function is likely NOT to be instantiated per PDU 825 session, Args.Mob.Session helps the UPF to perform the functions 826 which require per QFI and/or per PDU Session granularity. 828 6.2. End.MAP 830 The "Endpoint function with SID mapping" function (End.MAP for short) 831 is used in several scenarios. Particularly in mobility, End.MAP is 832 used in the UPFs for the PDU Session anchor functionality. 834 When a SR node N receives a packet destined to S and S is a local 835 End.MAP SID, N does the following: 837 1. look up the IPv6 DA in the mapping table 838 2. update the IPv6 DA with the new mapped SID ;; Note 1 839 3. IF segment_list > 1 840 4. insert a new SRH 841 5. forward according to the new mapped SID 842 6. ELSE 843 7. Drop the packet 845 Note 1: The SID in the SRH is NOT modified. 847 6.3. End.M.GTP6.D 849 The "Endpoint function with IPv6/GTP decapsulation into SR policy" 850 function (End.M.GTP6.D for short) is used in interworking scenario 851 for the uplink toward from the legacy gNB using IPv6/GTP. Suppose, 852 for example, this SID is associated with an SR policy 853 and an IPv6 Source Address A. 855 When the SR Gateway node N receives a packet destined to S and S is a 856 local End.M.GTP6.D SID, N does: 858 1. IF NH=UDP & UDP_PORT = GTP THEN 859 2. pop the IPv6, UDP and GTP headers 860 3. push a new IPv6 header with its own SRH 861 4. set the outer IPv6 SA to A 862 5. set the outer IPv6 DA to S1 863 6. forward according to the S1 segment of the SRv6 Policy 864 7. ELSE 865 8. Drop the packet 867 6.4. End.M.GTP6.E 869 The "Endpoint function with encapsulation for IPv6/GTP tunnel" 870 function (End.M.GTP6.E for short) is used in interworking scenario 871 for the downlink toward the legacy gNB using IPv6/GTP. 873 The End.M.GTP6.E function has a 32-bit argument space which is used 874 to provide the GTP TEID. 876 When the SR Gateway node N receives a packet destined to S, and S is 877 a local End.M.GTP6.E SID, N does the following: 879 1. IF NH=SRH & SL = 1 THEN ;; Note 1 880 2. decrement SL 881 3. store SRH[SL] in variable new_DA 882 4. store TEID in variable new_TEID ;; Note 2 883 5. pop IP header and all its extension headers 884 6. push new IPv6 header and GTP-U header 885 7. set IPv6 DA to new_DA 886 8. set GTP_TEID to new_TEID 887 9. lookup the new_DA and forward the packet accordingly 888 10. ELSE 889 11. Drop the packet 891 Note 1: An End.M.GTP6.E SID MUST always be the penultimate SID. 893 Note 2: TEID is extracted from the argument space of the current SID. 895 6.5. End.M.GTP4.E 897 The "Endpoint function with encapsulation for IPv4/GTP tunnel" 898 function (End.M.GTP4.E for short) is used in the downlink when doing 899 interworking with legacy gNB using IPv4/GTP. 901 When the SR Gateway node N receives a packet destined to S and S is a 902 local End.M.GTP4.E SID, N does: 904 1. IF NH=SRH & SL = 0 THEN 905 2. store SRH[0] in buffer S 906 3. pop the IPv6 header and its extension headers 907 4. push UDP/GTP headers with GTP TEID from S 908 5. push outer IPv4 header with SA, DA from S 909 6. ELSE 910 7. Drop the packet 912 S has the following format: 914 +----------------------+-------+-------+-------+ 915 | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | 916 +----------------------+-------+-------+-------+ 917 128-a-b-c a b c 919 End.M.GTP4.E SID Encoding 921 6.6. T.M.Tmap 923 The "Transit with tunnel decapsulation and map to an SRv6 policy" 924 function (T.M.Tmap for short) is used in the direction from legacy 925 user-plane to SRv6 user-plane network. 927 When the SR Gateway node N receives a packet destined to a IW- 928 IPv4-Prefix, N does: 930 1. IF Payload == UDP/GTP THEN 931 2. pop the outer IPv4 header and UDP/GTP headers 932 3. copy IPv4 DA, SA, TUN-ID to form SID B 933 4. encapsulate the packet into a new IPv6 header 934 5. set the IPv6 DA = B 935 6. forward along the shortest path to B 936 7. ELSE 937 8. Drop the packet 939 B has the following format: 941 +----------------------+-------+-------+-------+ 942 | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | 943 +----------------------+-------+-------+-------+ 944 128-a-b-c a b c 946 End.M.GTP4.E SID Encoding 948 The SID B is an SRv6 BindingSID instantiated at the first UPF (U1). 949 A static format is used for this Binding SIDs in order to remove 950 state from the SRGW. 952 6.7. End.Limit: Rate Limiting function 954 The mobile user-plane requires a rate-limit feature. For this 955 purpose, we define a new function "End.Limit". The "End.Limit" 956 function encodes in its arguments the rate limiting parameter that 957 should be applied to this packet. Multiple flows of packets should 958 have the same group identifier in the SID when those flows are in an 959 same AMBR group. The encoding format of the rate limit segment SID 960 is as follows: 962 +----------------------+----------+-----------+ 963 | LOC+FUNC rate-limit | group-id | limit-rate| 964 +----------------------+----------+-----------+ 965 128-i-j i j 967 End.Limit: Rate limiting function argument format 969 If the limit-rate bits are set to zero, the node should not do rate 970 limiting unless static configuration or control-plane sets the limit 971 rate associated to the SID. 973 7. SRv6 supported 3GPP PDU session types 975 The 3GPP [TS.23501] defines the following PDU session types: 977 o IPv4 978 o IPv6 979 o IPv4v6 980 o Ethernet 981 o Unstructured 983 SRv6 supports all the 3GPP PDU session types without any protocol 984 overhead by using the corresponding SRv6 functions (End.DX4, End.DT4 985 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 986 End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 PDU sessions; 987 End.DX2 for Unstructured PDU sessions). 989 8. Network Slicing Considerations 991 A mobile network may be required to implement "network slices", which 992 logically separate network resources. User-plane functions 993 represented as SRv6 segments would be part of a slice. 995 [I-D.filsfils-spring-segment-routing-policy] describes a solution to 996 build basic network slices with SR. Depending on the requirements, 997 these slices can be further refined by adopting the mechanisms from: 999 o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo] 1000 o Inter-Domain policies 1001 [I-D.ietf-spring-segment-routing-central-epe] 1003 Furthermore, these can be combined with ODN/AS 1004 [I-D.filsfils-spring-segment-routing-policy] for automated slice 1005 provisioning and traffic steering. 1007 Further details on how these tools can be used to create end to end 1008 network slices are documented in 1009 [I-D.ali-spring-network-slicing-building-blocks]. 1011 9. Control Plane Considerations 1013 This document focuses on user-plane behavior and its independence 1014 from the control plane. 1016 The control plane could be the current 3GPP-defined control plane 1017 with slight modifications to the N4 interface [TS.29244]. 1019 Alternatively, SRv6 could be used in conjunction with a new mobility 1020 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 1021 hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA 1022 [I-D.gundavelli-dmm-mfa] or in conjunction with FPC 1023 [I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes 1024 and its applicability to SRv6 is out of the scope of this document. 1026 Section 11 allocates SRv6 endpoint function types for the new 1027 functions defined in this document. Control-plane protocols are 1028 expected to use these function type codes to signal each function. 1030 SRv6's network programming nature allows a flexible and dynamic UPF 1031 placement. 1033 10. Security Considerations 1035 TBD 1037 11. IANA Considerations 1039 IANA is requested to allocate, within the "SRv6 Endpoint Types" sub- 1040 registry belonging to the top-level "Segment-routing with IPv6 1041 dataplane (SRv6) Parameters" registry 1042 [I-D.filsfils-spring-srv6-network-programming], the following values: 1044 +-------------+-----+-------------------+-----------+ 1045 | Value/Range | Hex | Endpoint function | Reference | 1046 +-------------+-----+-------------------+-----------+ 1047 | TBA | TBA | End.MAP | [This.ID] | 1048 | TBA | TBA | End.M.GTP6.D | [This.ID] | 1049 | TBA | TBA | End.M.GTP6.E | [This.ID] | 1050 | TBA | TBA | End.M.GTP4.E | [This.ID] | 1051 | TBA | TBA | End.Limit | [This.ID] | 1052 +-------------+-----+-------------------+-----------+ 1054 Table 1: SRv6 Mobile User-plane Endpoint Types 1056 12. Acknowledgements 1058 The authors would like to thank Daisuke Yokota, Bart Peirens, 1059 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1060 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1061 Shekhar and Aeneas Dodd-Noble for their useful comments of this work. 1063 13. Contributors 1065 Kentaro Ebisawa 1066 Ponto Networks 1067 Japan 1068 Email: ebiken@pontonetworks.com 1070 14. References 1072 14.1. Normative References 1074 [I-D.filsfils-spring-segment-routing-policy] 1075 Filsfils, C., Sivabalan, S., Hegde, S., 1076 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 1077 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 1078 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 1079 J., Clad, F., and K. Raza, "Segment Routing Policy 1080 Architecture", draft-filsfils-spring-segment-routing- 1081 policy-06 (work in progress), May 2018. 1083 [I-D.filsfils-spring-srv6-network-programming] 1084 Filsfils, C., Camarillo, P., Leddy, J., 1085 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1086 Network Programming", draft-filsfils-spring-srv6-network- 1087 programming-07 (work in progress), February 2019. 1089 [I-D.ietf-6man-segment-routing-header] 1090 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1091 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1092 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 1093 progress), February 2019. 1095 [I-D.voyer-6man-extension-header-insertion] 1096 daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes, 1097 D., Previdi, S., and S. Matsushima, "Insertion of IPv6 1098 Segment Routing Headers in a Controlled Domain", draft- 1099 voyer-6man-extension-header-insertion-05 (work in 1100 progress), January 2019. 1102 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1103 Requirement Levels", BCP 14, RFC 2119, 1104 DOI 10.17487/RFC2119, March 1997, 1105 . 1107 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1108 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1109 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1110 July 2018, . 1112 14.2. Informative References 1114 [I-D.ali-spring-network-slicing-building-blocks] 1115 Ali, Z., Filsfils, C., Camarillo, P., and d. 1116 daniel.voyer@bell.ca, "Building blocks for Slicing in 1117 Segment Routing Network", draft-ali-spring-network- 1118 slicing-building-blocks-01 (work in progress), March 2019. 1120 [I-D.auge-dmm-hicn-mobility-deployment-options] 1121 Auge, J., Carofiglio, G., Muscariello, L., and M. 1122 Papalini, "Anchorless mobility management through hICN 1123 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1124 mobility-deployment-options-01 (work in progress), 1125 December 2018. 1127 [I-D.camarillo-dmm-srv6-mobile-pocs] 1128 Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A., 1129 Matsushima, S., and d. daniel.voyer@bell.ca, "Segment 1130 Routing IPv6 for mobile user-plane PoCs", draft-camarillo- 1131 dmm-srv6-mobile-pocs-01 (work in progress), October 2018. 1133 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1134 Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S., 1135 daniel.voyer@bell.ca, d., Cui, A., and B. Peirens, "SRv6 1136 Mobility Use-Cases", draft-camarilloelmalky-springdmm- 1137 srv6-mob-usecases-01 (work in progress), January 2019. 1139 [I-D.gundavelli-dmm-mfa] 1140 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 1141 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01 1142 (work in progress), September 2018. 1144 [I-D.hegdeppsenak-isis-sr-flex-algo] 1145 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 1146 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 1147 isis-sr-flex-algo-02 (work in progress), February 2018. 1149 [I-D.ietf-dmm-fpc-cpdp] 1150 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1151 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1152 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 1153 (work in progress), June 2018. 1155 [I-D.ietf-spring-segment-routing-central-epe] 1156 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1157 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1158 Engineering", draft-ietf-spring-segment-routing-central- 1159 epe-10 (work in progress), December 2017. 1161 [I-D.rodrigueznatal-lisp-srv6] 1162 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1163 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1164 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-01 1165 (work in progress), January 2019. 1167 [I-D.xuclad-spring-sr-service-programming] 1168 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1169 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1170 Henderickx, W., and S. Salsano, "Service Programming with 1171 Segment Routing", draft-xuclad-spring-sr-service- 1172 programming-01 (work in progress), October 2018. 1174 [TS.23501] 1175 3GPP, "System Architecture for the 5G System", 3GPP TS 1176 23.501 15.0.0, November 2017. 1178 [TS.29244] 1179 3GPP, "Interface between the Control Plane and the User 1180 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1182 [TS.29281] 1183 3GPP, "General Packet Radio System (GPRS) Tunnelling 1184 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1185 December 2017. 1187 [TS.38415] 1188 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1189 3GPP R3-174510 0.0.0, August 2017. 1191 Appendix A. Implementations 1193 This document introduces new SRv6 functions. These functions have an 1194 open-source P4 implementation available in 1195 . 1197 There are also implementations in M-CORD NGIC and Open Air Interface 1198 (OAI). Further details can be found in 1199 [I-D.camarillo-dmm-srv6-mobile-pocs]. 1201 Appendix B. Changes from revision 02 to revision 03 1203 This section lists the changes between draft-ietf-dmm-srv6-mobile- 1204 uplane revisions ...-02 and ...-03. 1206 o Added new terminology section for abbreviations. 1207 o Added new terminology section for predefined SRv6 functions. 1208 o Made terminology section for conventions used in the document. 1210 o Renamed "Basic" mode to be called "Traditional" mode. 1211 o Renamed "Aggregate" mode to be called "Enhanced" mode. 1212 o Added new Args.Mob.Session format to supply QFI, RQI indication 1213 and PDU Session ID. 1214 o Modified End.MAP function to define the SID argument format and 1215 support more than one SID 1216 o Added missing references. 1217 o Editorial updates to improve readability. 1219 Authors' Addresses 1221 Satoru Matsushima 1222 SoftBank 1223 Tokyo 1224 Japan 1226 Email: satoru.matsushima@g.softbank.co.jp 1228 Clarence Filsfils 1229 Cisco Systems, Inc. 1230 Belgium 1232 Email: cf@cisco.com 1234 Miya Kohno 1235 Cisco Systems, Inc. 1236 Japan 1238 Email: mkohno@cisco.com 1240 Pablo Camarillo Garvia 1241 Cisco Systems, Inc. 1242 Spain 1244 Email: pcamaril@cisco.com 1246 Daniel Voyer 1247 Bell Canada 1248 Canada 1250 Email: daniel.voyer@bell.ca 1251 Charles E. Perkins 1252 Futurewei Inc. 1253 2330 Central Expressway 1254 Santa Clara, CA 95050 1255 USA 1257 Phone: +1-408-330-4586 1258 Email: charliep@computer.org