idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-03.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 (October 22, 2018) is 2013 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 899, but not defined -- Looks like a reference, but probably isn't: '2' on line 179 -- Looks like a reference, but probably isn't: '1' on line 179 -- Looks like a reference, but probably isn't: '0' on line 180 == 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 682, but not defined == Missing Reference: 'N9' is mentioned on line 520, but not defined == Missing Reference: 'N6' is mentioned on line 683, but not defined == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-00 == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-deployment-options-00 == Outdated reference: A later version (-02) exists of draft-camarillo-dmm-srv6-mobile-pocs-00 == Outdated reference: A later version (-02) exists of draft-camarilloelmalky-springdmm-srv6-mob-usecases-00 == 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-00 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-00 Summary: 0 errors (**), 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: April 25, 2019 M. Kohno 6 P. Camarillo 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 October 22, 2018 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-03 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. It also provides a 27 mechanism for end-to-end network slicing. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 65 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Predefined SRv6 Functions . . . . . . . . . . . . . . . . 4 68 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 4. A 3GPP Reference Architecture . . . . . . . . . . . . . . . . 6 70 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7 72 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 73 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8 74 5.1.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 9 75 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 77 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10 78 5.2.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 11 79 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 80 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 81 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15 82 5.3.3. Extensions to the interworking mechanisms . . . . . . 17 83 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18 84 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18 85 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 19 87 6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19 88 6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20 89 6.6. T.M.Tmap . . . . . . . . . . . . . . . . . . . . . . . . 20 90 6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 21 91 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22 92 8. Network Slicing Considerations . . . . . . . . . . . . . . . 22 93 9. Control Plane Considerations . . . . . . . . . . . . . . . . 22 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 97 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 100 14.2. Informative References . . . . . . . . . . . . . . . . . 24 101 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 26 102 Appendix B. Changes from revision 02 to revision 03 . . . . . . 26 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 105 1. Introduction 107 In mobile networks, mobility management systems provide connectivity 108 while mobile nodes move. While the control-plane of the system 109 signals movements of a mobile node, the user-plane establishes a 110 tunnel between the mobile node and its anchor node over IP-based 111 backhaul and core networks. 113 This document shows the applicability of SRv6 (Segment Routing IPv6) 114 to those mobile networks. SRv6 provides source routing to networks 115 so that operators can explicitly indicate a route for the packets to 116 and from the mobile node. SRv6 endpoint nodes serve as the anchors 117 of mobile user-plane. 119 2. Conventions and Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 2.1. Terminology 127 o AMBR: Aggregate Maximum Bit Rate 128 o APN: Access Point Name (commonly used to identify a network or 129 class of service) 130 o BSID: SR Binding SID [RFC8402] 131 o CNF: Cloud-native Network Function 132 o gNB: gNodeB 133 o NH: The IPv6 next-header field. 134 o NFV: Network Function Virtualization 135 o PDU: Packet Data Unit 136 o Session: TBD... 137 o SID: A Segment Identifier which represents a specific segment in a 138 segment routing domain. 139 o SRH: The Segment Routing Header. 140 [I-D.ietf-6man-segment-routing-header] 141 o TEID: Tunnel Endpoint Identifier 142 o UE: User Equipment 143 o UPF: User Plane Function 144 o VNF: Virtual Network Function 146 2.2. Conventions 148 o NH=SRH means that NH is 43 with routing type 4. 149 o Multiple SRHs may be present inside each packet, but they must 150 follow each other. The next-header field of each SRH, except the 151 last one, must be NH-SRH (43 type 4). 152 o For simplicity, no other extension headers are shown except the 153 SRH. 154 o The SID type used in this document is IPv6 address (also called 155 SRv6 Segment or SRv6 SID). 156 o gNB::1 is an IPv6 address (SID) assigned to the gNB. 157 o U1::1 is an IPv6 address (SID) assigned to UPF1. 158 o U2::1 is an IPv6 address (SID) assigned to UPF2. 159 o U2:: is some other IPv6 address (SID) assigned to UPF2. 160 o A SID list is represented as where S1 is the first 161 SID to visit, S2 is the second SID to visit and S3 is the last SID 162 to visit along the SR path. 163 o (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 165 * IPv6 header with source and destination addresses SA and DA 166 respectively, and next-header SRH, with SID list 167 with SegmentsLeft = SL 168 * The payload of the packet is not represented. 169 o Note the difference between the <> and () symbols: 170 represents a SID list where S1 is the first SID and S3 is the last 171 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 172 the SRH format where the rightmost SID in the SRH is the first SID 173 and the leftmost SID in the SRH is the last SID. When referring 174 to an SR policy in a high-level use-case, it is simpler to use the 175 notation. When referring to an illustration of the 176 detailed behavior, the (S3, S2, S1; SL) notation is more 177 convenient. 178 o SRH[SL] represents the SID pointed by the SL field in the first 179 SRH. In our example, SRH[2] represents S1, SRH[1] represents S2 180 and SRH[0] represents S3. 181 o SRH[SL] can be different from the DA of the IPv6 header. 183 2.3. Predefined SRv6 Functions 185 The following functions are defined in 186 [I-D.filsfils-spring-srv6-network-programming]. 188 o End.DT4 means to decapsulate and forward using a specific IPv4 189 table lookup. 191 o End.DT6 means to decapsulate and forward using a specific IPv6 192 table lookup. 193 o End.DX4 means to decapsulate and forward through a particular link 194 configured with the SID. 195 o End.DX6 means to decapsulate and forward through a particular link 196 configured with the 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.filsfils-spring-srv6-network-programming]). Applied to 232 mobility, SRv6 can provide the user-plane functions needed for 233 mobility management. SRv6 takes advantage of underlying transport 234 awareness 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.filsfils-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 session is mapped 1-for-1 326 with a specific GTP tunnel (TEID). This 1-for-1 mapping is 327 replicated here to replace GTP encapsulation with the SRv6 328 encapsulation, while not changing anything else. 330 The traditional mode minimizes the changes required to the mobile 331 system; it is a good starting point for forming a common basis. 333 Our example topology is shown in Figure 2. In traditional mode the 334 gNB and the UPFs are SR-aware. In the descriptions of the uplink and 335 downlink packet flow, A is an IPv6 address of the UE, and Z is an 336 IPv6 address reachable within the Data Network DN. A new SRv6 337 function End.MAP, defined in Section 6.2, is used. 339 ________ 340 SRv6 SRv6 / \ 341 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 342 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 343 +--+ +-----+ +------+ +------+ \________/ 344 SRv6 node SRv6 node SRv6 node 346 Figure 2: Traditional mode - example topology 348 5.1.1. Packet flow - Uplink 350 The uplink packet flow is as follows: 352 UE_out : (A,Z) 353 gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Red 354 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 355 UPF2_out: (A,Z) -> End.DT4 or End.DT6 357 When the UE packet arrives at the gNB, the gNB performs a 358 T.Encaps.Red operation. Since there is only one SID, there is no 359 need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA 360 U1::1. U1::1 represents an anchoring SID specific for that session 361 at UPF1. gNB obtains the SID U1::1 from the existing control plane 362 (N2 interface). 364 When the packet arrives at UPF1, the SID U1::1 identifies a local 365 End.MAP function. End.MAP replaces U1::1 by U2::1, that belongs to 366 the next UPF (U2). 368 When the packet arrives at UPF2, the SID U2::1 corresponds to an 369 End.DT function. UPF2 decapsulates the packet, performs a lookup in 370 a specific table and forwards the packet toward the data network 371 (DN). 373 5.1.2. Packet flow - Downlink 375 The downlink packet flow is as follows: 377 UPF2_in : (Z,A) 378 UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red 379 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 380 gNB_out : (Z,A) -> End.DX4 or End.DX6 382 When the packet arrives at the UPF2, the UPF2 maps that flow into a 383 UE session. This UE session is associated with the segment endpoint 384 . UPF2 performs a T.Encaps.Red operation, encapsulating the 385 packet into a new IPv6 header with no SRH since there is only one 386 SID. 388 Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 389 function. This function maps the SID to the next anchoring point and 390 replaces U1::1 by gNB::1, that belongs to the next hop. 392 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4 393 or End.DX6 function. The gNB decapsulates the packet, removing the 394 IPv6 header and all its extensions headers, and forwards the traffic 395 toward the UE. 397 5.1.3. IPv6 user-traffic 399 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 400 However based on local policy, a service provider MAY choose to do 401 SRH insertion. The main benefit is a lower overhead. In such case, 402 the functions used are T.Insert.Red at gNB, End.MAP at UPF1 and End.T 403 at UPF2 on Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at 404 gNB on Downlink. 406 5.2. Enhanced Mode 408 Enhanced mode improves scalability, traffic steering and service 409 programming [I-D.xuclad-spring-sr-service-programming], thanks to the 410 use of multiple SIDs, instead of a single SID as done in the 411 Traditional mode. 413 The main difference is that the SR policy MAY include SIDs for 414 traffic engineering and service programming in addition to the UPFs 415 SIDs. 417 The gNB control-plane (N2 interface) is unchanged, specifically a 418 single IPv6 address is given to the gNB. 420 o The gNB MAY resolve the IP address into a SID list using a 421 mechanism like PCEP, DNS-lookup, small augment for LISP control- 422 plane, etc. 424 Note that the SIDs MAY use the arguments Args.Mob.Session if required 425 by the UPFs. 427 Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the 428 gNB and the UPF are SR-aware. The Figure shows two service segments, 429 S1 and C1. S1 represents a VNF in the network, and C1 represents a 430 constraint path on a router requiring Traffic Engineering. S1 and C1 431 belong to the underlay and don't have an N4 interface, so they are 432 not considered UPFs. 434 +----+ SRv6 _______ 435 SRv6 --| C1 |--[N3] / \ 436 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 437 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 438 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 439 SRv6 node \ +----+ / SRv6 node 440 -| S1 |- 441 +----+ 442 SRv6 node 443 CNF 445 Figure 3: Enhanced mode - Example topology 447 5.2.1. Packet flow - Uplink 449 The uplink packet flow is as follows: 451 UE_out : (A,Z) 452 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red 453 S1_out : (gNB, C1)(U2::1, C1; SL=1 (A,Z) 454 C1_out : (gNB, U2::1)(A,Z) -> PSP 455 UPF2_out: (A,Z) -> End.DT4 or End.DT6 457 UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's 458 control plane associates that session from the UE(A) with the IPv6 459 address B and GTP TEID T. gNB's control plane does a lookup on B to 460 find the related SID list . 462 When gNB transmits the packet, it contains all the segments of the SR 463 policy. The SR policy can include segments for traffic engineering 464 (C1) and for service programming (S1). 466 Nodes S1 and C1 perform their related Endpoint functionality and 467 forward the packet. 469 When the packet arrives at UPF2, the active segment (U2::1) is an 470 End.DT4/6 which performs the decapsulation (removing the IPv6 header 471 with all its extension headers) and forwards toward the data network. 473 5.2.2. Packet flow - Downlink 475 The downlink packet flow is as follows: 477 UPF2_in : (Z,A) -> UPF2 maps the flow w/ 478 SID list 479 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red 480 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 481 S1_out : (U2::1, gNB)(Z,A) -> PSP 482 gNB_out : (Z,A) -> End.DX4 or End.DX6 484 When the packet arrives at the UPF2, the UPF2 maps that particular 485 flow into a UE session. This UE session is associated with the 486 policy . The UPF2 performs a T.Encaps.Red operation, 487 encapsulating the packet into a new IPv6 header with its 488 corresponding SRH. 490 The nodes C1 and S1 perform their related Endpoint processing. 492 Once the packet arrives at the gNB, the IPv6 DA corresponds to an 493 End.DX4 or End.DX6 (depending on the underlying traffic). The gNB 494 decapsulates the packet, removing the IPv6 header and all its 495 extensions headers and forwards the traffic toward the UE. 497 5.2.3. IPv6 user-traffic 499 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 500 However based on local policy, a service provider MAY choose to do 501 SRH insertion. The main benefit is a lower overhead. In such case, 502 the functions used are T.Insert.Red at gNB and End.T at UPF2 on 503 Uplink, T.Insert.Red at UPF2 and End.X at gNB on Downlink. 505 5.3. Enhanced mode with unchanged gNB GTP behavior 507 This section describes two mechanisms for interworking with legacy 508 gNBs that still use GTP: one for IPv4, the other for IPv6. 510 In the interworking scenarios as illustrated in Figure 4, gNB does 511 not support SRv6. gNB supports GTP encapsulation over IPv4 or IPv6. 512 To achieve interworking, a SR Gateway (SRGW-UPF1) entity is added. 513 The SRGW maps the GTP traffic into SRv6. 515 The SRGW is not an anchor point, and maintains very little state. 516 For this reason, both IPv4 and IPv6 methods scale to millions of UEs. 518 _______ 519 IP GTP SRv6 / \ 520 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 521 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 522 +--+ +-----+ +------+ +------+ \_______/ 523 SR Gateway SRv6 node 525 Figure 4: Example topology for interworking 527 5.3.1. Interworking with IPv6 GTP 529 In this interworking mode the gNB uses GTP over IPv6 via the N3 530 interface 532 Key points: 534 o The gNB is unchanged (control-plane or user-plane) and 535 encapsulates into GTP (N3 interface is not modified). 536 o The 5G Control-Plane (N2 interface) is unmodified; one IPv6 537 address is needed (i.e. a BSID at the SRGW). 538 o The SRGW removes GTP, finds the SID list related to DA, and adds 539 SRH with the SID list. 540 o There is no state for the downlink at the SRGW. 541 o There is simple state in the uplink at the SRGW; using Enhanced 542 mode results in fewer SR policies on this node. A SR policy can 543 be shared across UEs. 544 o When a packet from the UE leaves the gNB, it is SR-routed. This 545 simplifies network slicing [I-D.hegdeppsenak-isis-sr-flex-algo]. 546 o In the uplink, the IPv6 DA BSID steers traffic into an SR policy 547 when it arrives at the SRGW-UPF1. 549 An example topology is shown in Figure 5. In this mode the gNB is an 550 unmodified gNB using IPv6/GTP. The UPFs are SR-aware. As before, 551 the SRGW maps IPv6/GTP traffic to SRv6. 553 S1 and C1 are two service segments. S1 represents a VNF in the 554 network, and C1 represents a router configured for Traffic 555 Engineering. 557 +----+ 558 IPv6/GTP -| S1 |- ___ 559 +--+ +-----+ [N3] / +----+ \ / 560 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 561 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 562 GTP \ +------+ / +----+ +------+ \___ 563 -| UPF1 |- SRv6 SRv6 564 +------+ TE 565 SR Gateway 567 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 569 5.3.1.1. Packet flow - Uplink 571 The uplink packet flow is as follows: 573 UE_out : (A,Z) 574 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 575 (IPv6/GTP) 576 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 577 SID at the SRGW 578 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 579 C1_out : (SRGW, U2::1)(A,Z) -> PSP 580 UPF2_out: (A,Z) -> End.DT4 or End.DT6 582 The UE sends a packet destined to Z toward the gNB on a specific 583 bearer for that session. The gNB, which is unmodified, encapsulates 584 the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the 585 GTP TEID T are the ones received in the N2 interface. 587 The IPv6 address that was signalled over the N2 interface for that UE 588 session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the 589 SRGW. Hence the packet is routed to the SRGW. 591 When the packet arrives at the SRGW, the SRGW identifies B as an 592 End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes 593 the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own 594 SRH containing the SIDs bound to the SR policy associated with this 595 BindingSID. There is one instance of the End.M.GTP6.D SID per PDU 596 type. 598 S1 and C1 perform their related Endpoint functionality and forward 599 the packet. 601 When the packet arrives at UPF2, the active segment is (U2::1) which 602 is bound to End.DT4/6. UPF2 then decapsulates (removing the outer 603 IPv6 header with all its extension headers) and forwards the packet 604 toward the data network. 606 5.3.1.2. Packet flow - Downlink 608 The downlink packet flow is as follows: 610 UPF2_in : (Z,A) -> UPF2 maps the flow with 611 612 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red 613 C1_out : (U2::1, S1)(gNB, S1; SL=2)(Z,A) 614 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 615 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 616 gNB_out : (Z,A) 618 When a packet destined to A arrives at the UPF2, the UPF2 performs a 619 lookup in the table associated to A and finds the SID list . The UPF2 performs a T.Encaps.Red operation, 621 encapsulating the packet into a new IPv6 header with its 622 corresponding SRH. 624 C1 and S1 perform their related Endpoint processing. 626 Once the packet arrives at the SRGW, the SRGW identifies the active 627 SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header 628 and all its extensions headers. The SRGW generates new IPv6, UDP and 629 GTP headers. The new IPv6 DA is the gNB which is the last SID in the 630 received SRH. The TEID in the generated GTP header is an argument of 631 the received End.M.GTP6.E SID. The SRGW pushes the headers to the 632 packet and forwards the packet toward the gNB. There is one instance 633 of the End.M.GTP6.E SID per PDU type. 635 Once the packet arrives at the gNB, the packet is a regular IPv6/GTP 636 packet. The gNB looks for the specific radio bearer for that TEID 637 and forward it on the bearer. This gNB behavior is not modified from 638 current and previous generations. 640 5.3.1.3. Scalability 642 For the downlink traffic, the SRGW is stateless. All the state is in 643 the SRH inserted by the UPF2. The UPF2 must have the UE states since 644 it is the UE's session anchor point. 646 For the uplink traffic, the state at the SRGW does not necessarily 647 need to be unique per UE session; the state state can be shared among 648 UEs. This enables much more scalable SRGW deployments compared to a 649 solution holding millions of states, one or more per UE. 651 5.3.1.4. IPv6 user-traffic 653 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 654 However based on local policy, a service provider MAY choose to do 655 SRH insertion. The main benefit is lower overhead. 657 5.3.2. Interworking with IPv4 GTP 659 In this interworking mode the gNB uses GTP over IPv4 in the N3 660 interface 662 Key points: 664 o The gNB is unchanged and encapsulates packets into GTP (the N3 665 interface is not modified). 666 o In the uplink, traffic is classified by SRGW's Uplink Classifier 667 and steered into an SR policy. The SRGW is a UPF1 functionality 668 and can coexist with UPF1's Uplink Classifier functionality. 669 o SRGW removes GTP, finds the SID list related to DA, and adds a SRH 670 with the SID list. 672 An example topology is shown in Figure 6. In this mode the gNB is an 673 unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, 674 the SRGW maps the IPv4/GTP traffic to SRv6. 676 S1 and C1 are two service segment endpoints. S1 represents a VNF in 677 the network, and C1 represents a router configured for Traffic 678 Engineering. 680 +----+ 681 IPv4/GTP -| S1 |- ___ 682 +--+ +-----+ [N3] / +----+ \ / 683 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 684 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 685 GTP \ +------+ / +----+ +------+ \___ 686 -| UPF1 |- SRv6 SRv6 687 +------+ TE 688 SR Gateway 690 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 692 5.3.2.1. Packet flow - Uplink 694 The uplink packet flow is as follows: 696 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 697 unchanged IPv4/GTP 698 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.Tmap function 699 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 700 C1_out : (SRGW, U2::1) (A,Z) -> PSP 701 UPF2_out: (A,Z) -> End.DT4 or End.DT6 703 The UE sends a packet destined to Z toward the gNB on a specific 704 bearer for that session. The gNB, which is unmodified, encapsulates 705 the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and 706 the GTP TEID are the ones received at the N2 interface. 708 When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink 709 Classifier rule for incoming traffic from the gNB, that steers the 710 traffic into an SR policy by using the function T.M.TMap. The SRGW 711 removes the IPv4, UDP and GTP headers and pushes an IPv6 header with 712 its own SRH containing the SIDs related to the SR policy associated 713 with this traffic. The SRGW forwards according to the new IPv6 DA. 715 S1 and C1 perform their related Endpoint functionality and forward 716 the packet. 718 When the packet arrives at UPF2, the active segment is (U2::1) which 719 is bound to End.DT4/6 which performs the decapsulation (removing the 720 outer IPv6 header with all its extension headers) and forwards toward 721 the data network. 723 5.3.2.2. Packet flow - Downlink 725 The downlink packet flow is as follows: 727 UPF2_in : (Z,A) -> UPF2 maps flow with SID 728 729 UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red 730 C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) 731 S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) 732 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 733 gNB_out : (Z,A) 735 When a packet destined to A arrives at the UPF2, the UPF2 performs a 736 lookup in the table associated to A and finds the SID list . The UPF2 performs a T.Encaps.Red operation, 738 encapsulating the packet into a new IPv6 header with its 739 corresponding SRH. 741 The nodes C1 and S1 perform their related Endpoint processing. 743 Once the packet arrives at the SRGW, the SRGW identifies the active 744 SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header 745 and all its extensions headers. The SRGW generates an IPv4, UDP and 746 GTP headers. The IPv4 SA and DA are received as SID arguments. The 747 TEID in the generated GTP header is also the arguments of the 748 received End.M.GTP4.E SID. The SRGW pushes the headers to the packet 749 and forwards the packet toward the gNB. 751 When the packet arrives at the gNB, the packet is a regular IPv4/GTP 752 packet. The gNB looks for the specific radio bearer for that TEID 753 and forward it on the bearer. This gNB behavior is not modified from 754 current and previous generations. 756 5.3.2.3. Scalability 758 For the downlink traffic, the SRGW is stateless. All the state is in 759 the SRH inserted by the UPF. The UPF must have this UE-base state 760 anyway (since it is its anchor point). 762 For the uplink traffic, the state at the SRGW is dedicated on a per 763 UE/session basis according to an Uplink Classifier. There is state 764 for steering the different sessions on a SR policies. However, SR 765 policies are shared among several UE/sessions. 767 5.3.2.4. IPv6 user-traffic 769 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 770 Based on local policy, a service provider MAY choose to do SRH 771 insertion. The main benefit is a lower overhead. 773 5.3.3. Extensions to the interworking mechanisms 775 In this section we presented two mechanisms for interworking with 776 gNBs that do not support SRv6. These mechanism are done to support 777 GTP over IPv4 and GTP over IPv6. 779 Even though we have presented these methods as an extension to the 780 "Enhanced mode", it is straightforward in its applicability to the 781 "Traditional mode". 783 Furthermore, although these mechanisms are designed for interworking 784 with legacy RAN at the N3 interface, these methods could also be 785 applied for interworking with a non-SRv6 capable UPF at the N9 786 interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). 788 6. SRv6 SID Mobility Functions 790 6.1. Args.Mob.Session 792 Args.Mob.Session provide per-session information for charging, 793 buffering and lawful intercept (among others) required by some mobile 794 nodes. The Args.Mob.Session argument format is used in combination 795 with End.Map, End.DT and End.DX functions. 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | QFI |R|U| PDU Session ID | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 |PDU Sess(cont')| 803 +-+-+-+-+-+-+-+-+ 805 Args.Mob.Session format 807 o QFI: QoS Flow Identifier [TS.38415] 808 o R: Reflective QoS Indication [TS.23501]. This parameter indicates 809 the activaton of reflective QoS towards the UE for the transfered 810 packet. Reflective QoS enables the UE to map UL User Plane 811 traffic to QoS Flows without SMF provided QoS rules. 812 o U: Unused and for future use. MUST be 0 on transmission and 813 ignored on receipt. 814 o PDU Session ID: Identifier of PDU Session. The GTP-U equivalent 815 is TEID. 817 Since the SRv6 function is likely NOT to be instantiated per PDU 818 session, Args.Mob.Session helps the UPF to perform the functions 819 which require per QFI and/or per PDU Session granularity. 821 6.2. End.MAP 823 The "Endpoint function with SID mapping" function (End.MAP for short) 824 is used in several scenarios. Particularly in mobility, End.MAP is 825 used in the UPFs for the PDU Session anchor functionality. 827 When a SR node N receives a packet destined to S and S is a local 828 End.MAP SID, N does the following: 830 1. look up the IPv6 DA in the mapping table 831 2. update the IPv6 DA with the new mapped SID ;; Note 1 832 3. IF segment_list > 1 833 4. insert a new SRH 834 5. forward according to the new mapped SID 835 6. ELSE 836 7. Drop the packet 838 Note 1: The SID in the SRH is NOT modified. 840 6.3. End.M.GTP6.D 842 The "Endpoint function with IPv6/GTP decapsulation into SR policy" 843 function (End.M.GTP6.D for short) is used in interworking scenario 844 for the uplink toward from the legacy gNB using IPv6/GTP. Suppose, 845 for example, this SID is associated with an SR policy 846 and an IPv6 Source Address A. 848 When the SR Gateway node N receives a packet destined to S and S is a 849 local End.M.GTP6.D SID, N does: 851 1. IF NH=UDP & UDP_PORT = GTP THEN 852 2. pop the IP, UDP and GTP headers 853 3. push a new IPv6 header with its own SRH 854 4. set the outer IPv6 SA to A 855 5. set the outer IPv6 DA to S1 856 6. forward according to the S1 segment of the SRv6 Policy 857 7. ELSE 858 8. Drop the packet 860 6.4. End.M.GTP6.E 862 The "Endpoint function with encapsulation for IPv6/GTP tunnel" 863 function (End.M.GTP6.E for short) is used in interworking scenario 864 for the downlink toward the legacy gNB using IPv6/GTP. 866 The End.M.GTP6.E function has a 32-bit argument space which is used 867 to provide the GTP TEID. 869 When the SR Gateway node N receives a packet destined to S, and S is 870 a local End.M.GTP6.E SID, N does the following: 872 1. IF NH=SRH & SL = 1 THEN ;; Note 1 873 2. decrement SL 874 3. store SRH[SL] in variable new_DA 875 4. store TEID in variable new_TEID ;; Note 2 876 5. pop IP header and all its extension headers 877 6. push new IPv6 header and GTP-U header 878 7. set IPv6 DA to new_DA 879 8. set GTP_TEID to new_TEID 880 9. lookup the new_DA and forward the packet accordingly 881 10. ELSE 882 11. Drop the packet 884 Note 1: An End.M.GTP6.E SID MUST always be the penultimate SID. 886 Note 2: TEID is extracted from the argument space of the current SID. 888 6.5. End.M.GTP4.E 890 The "Endpoint function with encapsulation for IPv4/GTP tunnel" 891 function (End.M.GTP4.E for short) is used in the downlink when doing 892 interworking with legacy gNB using IPv4/GTP. 894 When the SR Gateway node N receives a packet destined to S and S is a 895 local End.M.GTP4.E SID, N does: 897 1. IF NH=SRH & SL > 0 THEN 898 2. decrement SL 899 3. update the IPv6 DA with SRH[SL] 900 4. pop the SRH 901 5. push UDP/GTP headers with tunnel ID from S 902 6. push outer IPv4 header with SA, DA from S 903 7. ELSE 904 8. Drop the packet 906 S has the following format: 908 +----------------------+-------+-------+-------+ 909 | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | 910 +----------------------+-------+-------+-------+ 911 128-a-b-c a b c 913 End.M.GTP4.E SID Encoding 915 6.6. T.M.Tmap 917 The "Transit with tunnel decapsulation and map to an SRv6 policy" 918 function (T.M.Tmap for short) is used in the direction from legacy 919 user-plane to SRv6 user-plane network. 921 When the SR Gateway node N receives a packet destined to a IW- 922 IPv4-Prefix, N does: 924 1. IF Payload == UDP/GTP THEN 925 2. pop the outer IPv4 header and UDP/GTP headers 926 3. copy IPv4 DA, SA, TUN-ID to form SID B 927 4. encapsulate the packet into a new IPv6 header 928 5. set the IPv6 DA = B 929 6. forward along the shortest path to B 930 7. ELSE 931 8. Drop the packet 933 B has the following format: 935 +----------------------+-------+-------+-------+ 936 | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | 937 +----------------------+-------+-------+-------+ 938 128-a-b-c a b c 940 End.M.GTP4.E SID Encoding 942 The SID B is an SRv6 BindingSID instantiated at the first UPF (U1). 943 A static format is used for this Binding SIDs in order to remove 944 state from the SRGW. 946 6.7. End.Limit: Rate Limiting function 948 The mobile user-plane requires a rate-limit feature. For this 949 purpose, we define a new function "End.Limit". The "End.Limit" 950 function encodes in its arguments the rate limiting parameter that 951 should be applied to this packet. Multiple flows of packets should 952 have the same group identifier in the SID when those flows are in an 953 same AMBR group. The encoding format of the rate limit segment SID 954 is as follows: 956 +----------------------+----------+-----------+ 957 | LOC+FUNC rate-limit | group-id | limit-rate| 958 +----------------------+----------+-----------+ 959 128-i-j i j 961 End.Limit: Rate limiting function argument format 963 If the j bit length is zero, the node should not do rate limiting 964 unless static configuration or control-plane sets the limit rate 965 associated to the SID. 967 7. SRv6 supported 3GPP PDU session types 969 The 3GPP [TS.23501] defines the following PDU session types: 971 o IPv4 972 o IPv6 973 o IPv4v6 974 o Ethernet 975 o Unstructured 977 SRv6 supports all the 3GPP PDU session types without any protocol 978 overhead by using the corresponding SRv6 functions (End.DX4, End.DT4 979 for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; 980 End.DT46 for IPv4v6 PDU sessions; End.DX2, End.DT2M for L2 PDU 981 sessions; End.DX2 for Unstructured PDU sessions). 983 8. Network Slicing Considerations 985 A mobile network may be required to implement "network slices", which 986 logically separate network resources. User-plane functions 987 represented as SRv6 segments would be part of a slice. 989 [I-D.filsfils-spring-segment-routing-policy] describes a solution to 990 build basic network slices with SR. Depending on the requirements, 991 these slices can be further refined by adopting the mechanisms from: 993 o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo] 994 o Inter-Domain policies 995 [I-D.ietf-spring-segment-routing-central-epe] 997 Furthermore, these can be combined with ODN/AS 998 [I-D.filsfils-spring-segment-routing-policy] for automated slice 999 provisioning and traffic steering. 1001 Further details on how these tools can be used to create end to end 1002 network slices are documented in 1003 [I-D.ali-spring-network-slicing-building-blocks]. 1005 9. Control Plane Considerations 1007 This document focuses on user-plane behavior and its independence 1008 from the control plane. 1010 The control plane could be the current 3GPP-defined control plane 1011 with slight modifications to the N4 interface [TS.29244]. 1013 Alternatively, SRv6 could be used in conjunction with a new mobility 1014 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 1015 hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA 1016 [I-D.gundavelli-dmm-mfa] or in conjunction with FPC 1017 [I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes 1018 and its applicability to SRv6 is out of the scope of this document. 1020 Section 11 allocates SRv6 endpoint function types for the new 1021 functions defined in this document. Control-plane protocols are 1022 expected to use these function type codes to signal each function. 1024 SRv6's network programming nature allows a flexible and dynamic UPF 1025 placement. 1027 10. Security Considerations 1029 TBD 1031 11. IANA Considerations 1033 IANA is requested to allocate, within the "SRv6 Endpoint Types" sub- 1034 registry belonging to the top-level "Segment-routing with IPv6 1035 dataplane (SRv6) Parameters" registry 1036 [I-D.filsfils-spring-srv6-network-programming], the following values: 1038 +-------------+-----+-------------------+-----------+ 1039 | Value/Range | Hex | Endpoint function | Reference | 1040 +-------------+-----+-------------------+-----------+ 1041 | TBA | TBA | End.MAP | [This.ID] | 1042 | TBA | TBA | End.M.GTP6.D | [This.ID] | 1043 | TBA | TBA | End.M.GTP6.E | [This.ID] | 1044 | TBA | TBA | End.M.GTP4.E | [This.ID] | 1045 | TBA | TBA | End.Limit | [This.ID] | 1046 +-------------+-----+-------------------+-----------+ 1048 Table 1: SRv6 Mobile User-plane Endpoint Types 1050 12. Acknowledgements 1052 The authors would like to thank Daisuke Yokota, Bart Peirens, 1053 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1054 Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi 1055 Shekhar and Aeneas Dodd-Noble for their useful comments of this work. 1057 13. Contributors 1059 Kentaro Ebisawa 1060 Ponto Networks 1061 Japan 1062 Email: ebiken@pontonetworks.com 1064 14. References 1066 14.1. Normative References 1068 [I-D.filsfils-spring-segment-routing-policy] 1069 Filsfils, C., Sivabalan, S., Hegde, S., 1070 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 1071 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 1072 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 1073 J., Clad, F., and K. Raza, "Segment Routing Policy 1074 Architecture", draft-filsfils-spring-segment-routing- 1075 policy-06 (work in progress), May 2018. 1077 [I-D.filsfils-spring-srv6-network-programming] 1078 Filsfils, C., Camarillo, P., Leddy, J., 1079 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 1080 Network Programming", draft-filsfils-spring-srv6-network- 1081 programming-05 (work in progress), July 2018. 1083 [I-D.ietf-6man-segment-routing-header] 1084 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1085 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1086 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 1087 progress), June 2018. 1089 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1090 Requirement Levels", BCP 14, RFC 2119, 1091 DOI 10.17487/RFC2119, March 1997, 1092 . 1094 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1095 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1096 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1097 July 2018, . 1099 14.2. Informative References 1101 [I-D.ali-spring-network-slicing-building-blocks] 1102 Ali, Z., Filsfils, C., and P. Camarillo, "Building blocks 1103 for Slicing in Segment Routing Network", draft-ali-spring- 1104 network-slicing-building-blocks-00 (work in progress), 1105 July 2018. 1107 [I-D.auge-dmm-hicn-mobility-deployment-options] 1108 Auge, J., Carofiglio, G., Muscariello, L., and M. 1109 Papalini, "Anchorless mobility management through hICN 1110 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1111 mobility-deployment-options-00 (work in progress), June 1112 2018. 1114 [I-D.camarillo-dmm-srv6-mobile-pocs] 1115 Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A., 1116 Matsushima, S., and d. daniel.voyer@bell.ca, "Segment 1117 Routing IPv6 for mobile user-plane PoCs", draft-camarillo- 1118 dmm-srv6-mobile-pocs-00 (work in progress), July 2018. 1120 [I-D.camarilloelmalky-springdmm-srv6-mob-usecases] 1121 Camarillo, P., Filsfils, C., Elmalky, H., Allan, D., 1122 Matsushima, S., daniel.voyer@bell.ca, d., Cui, A., and B. 1123 Peirens, "SRv6 Mobility Use-Cases", draft- 1124 camarilloelmalky-springdmm-srv6-mob-usecases-00 (work in 1125 progress), July 2018. 1127 [I-D.gundavelli-dmm-mfa] 1128 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 1129 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01 1130 (work in progress), September 2018. 1132 [I-D.hegdeppsenak-isis-sr-flex-algo] 1133 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 1134 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 1135 isis-sr-flex-algo-02 (work in progress), February 2018. 1137 [I-D.ietf-dmm-fpc-cpdp] 1138 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1139 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1140 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 1141 (work in progress), June 2018. 1143 [I-D.ietf-spring-segment-routing-central-epe] 1144 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1145 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1146 Engineering", draft-ietf-spring-segment-routing-central- 1147 epe-10 (work in progress), December 2017. 1149 [I-D.rodrigueznatal-lisp-srv6] 1150 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1151 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1152 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00 1153 (work in progress), July 2018. 1155 [I-D.xuclad-spring-sr-service-programming] 1156 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1157 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1158 Henderickx, W., and S. Salsano, "Service Programming with 1159 Segment Routing", draft-xuclad-spring-sr-service- 1160 programming-00 (work in progress), July 2018. 1162 [TS.23501] 1163 3GPP, "System Architecture for the 5G System", 3GPP TS 1164 23.501 15.0.0, November 2017. 1166 [TS.29244] 1167 3GPP, "Interface between the Control Plane and the User 1168 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1170 [TS.29281] 1171 3GPP, "General Packet Radio System (GPRS) Tunnelling 1172 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1173 December 2017. 1175 [TS.38415] 1176 3GPP, "Draft Specification for 5GS container (TS 38.415)", 1177 3GPP R3-174510 0.0.0, August 2017. 1179 Appendix A. Implementations 1181 This document introduces new SRv6 functions. These functions have an 1182 open-source P4 implementation available in 1183 . 1185 There are also implementations in M-CORD NGIC and Open Air Interface 1186 (OAI). Further details can be found in 1187 [I-D.camarillo-dmm-srv6-mobile-pocs]. 1189 Appendix B. Changes from revision 02 to revision 03 1191 This section lists the changes between draft-ietf-dmm-srv6-mobile- 1192 uplane revisions ...-02 and ...-03. 1194 o Added new terminology section for abbreviations. 1195 o Added new terminology section for predefined SRv6 functions. 1196 o Made terminology section for conventions used in the document. 1197 o Renamed "Basic" mode to be called "Traditional" mode. 1198 o Renamed "Aggregate" mode to be called "Enhanced" mode. 1199 o Added new Args.Mob.Session format to supply QFI, RQI indication 1200 and PDU Session ID. 1201 o Modified End.MAP function to define the SID argument format and 1202 support more than one SID 1204 o Added missing references. 1205 o Editorial updates to improve readability. 1207 Authors' Addresses 1209 Satoru Matsushima 1210 SoftBank 1211 Tokyo 1212 Japan 1214 Email: satoru.matsushima@g.softbank.co.jp 1216 Clarence Filsfils 1217 Cisco Systems, Inc. 1218 Belgium 1220 Email: cf@cisco.com 1222 Miya Kohno 1223 Cisco Systems, Inc. 1224 Japan 1226 Email: mkohno@cisco.com 1228 Pablo Camarillo Garvia 1229 Cisco Systems, Inc. 1230 Spain 1232 Email: pcamaril@cisco.com 1234 Daniel Voyer 1235 Bell Canada 1236 Canada 1238 Email: daniel.voyer@bell.ca 1239 Charles E. Perkins 1240 Futurewei Inc. 1241 2330 Central Expressway 1242 Santa Clara, CA 95050 1243 USA 1245 Phone: +1-408-330-4586 1246 Email: charliep@computer.org