idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5213]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2243 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 844, but not defined -- Looks like a reference, but probably isn't: '2' on line 166 -- Looks like a reference, but probably isn't: '1' on line 166 -- Looks like a reference, but probably isn't: '0' on line 166 == Missing Reference: 'WHITEPAPER-5G-UP' is mentioned on line 937, but not defined == Missing Reference: 'N11' is mentioned on line 222, but not defined == Missing Reference: 'N2' is mentioned on line 223, but not defined == Missing Reference: 'N4' is mentioned on line 227, but not defined == Missing Reference: 'N3' is mentioned on line 656, but not defined == Missing Reference: 'N9' is mentioned on line 491, but not defined == Missing Reference: 'N6' is mentioned on line 657, but not defined == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-03 == Outdated reference: A later version (-01) exists of draft-gundavelli-dmm-mfa-00 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-09 Summary: 1 error (**), 0 flaws (~~), 12 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 6, 2018 M. Kohno 6 P. Camarillo 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 March 5, 2018 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-01 17 Abstract 19 This document discusses the applicability of SRv6 (Segment Routing 20 IPv6) to user-plane of mobile networks. The source routing 21 capability and the network programming nature of SRv6, accomplish 22 mobile user-plane functions in a simple manner. The statelessness 23 and the ability to control underlying layer will be even more 24 beneficial to the mobile user-plane, in terms of providing 25 flexibility and SLA control for various applications. It also 26 simplifies the network architecture by eliminating the necessity of 27 tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS, 28 and so on. In addition, Segment Routing provides an enhanced method 29 for network slicing, which is briefly introduced by this document. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 6, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 67 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Reference Architecture . . . . . . . . . . . . . . . . . . . 5 69 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 6 70 5.1. Traditional mode (formerly Basic mode) . . . . . . . . . 6 71 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 7 72 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 8 73 5.1.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 8 74 5.2. Enhanced Mode (formerly Aggregate mode) . . . . . . . . . 8 75 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 9 76 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 10 77 5.2.3. IPv6 user-traffic . . . . . . . . . . . . . . . . . . 10 78 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 10 79 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 11 80 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 14 81 5.3.3. Extensions to the interworking mechanisms . . . . . . 16 82 6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 17 83 6.1. End.MAP: Endpoint function with SID mapping . . . . . . . 17 84 6.2. End.M.GTP6.D: Endpoint function with decapsulation from 85 IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 17 86 6.3. End.M.GTP6.E: Endpoint function with encapsulation for 87 IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18 88 6.4. End.M.GTP4.E: Endpoint function with encapsulation for 89 IPv4/GTP tunnel . . . . . . . . . . . . . . . . . . . . . 18 90 6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation 91 and mapping into an SRv6 Policy . . . . . . . . . . . . . 19 92 6.6. End.Limit: Rate Limiting function . . . . . . . . . . . . 20 93 7. Network Slicing Considerations . . . . . . . . . . . . . . . 20 94 8. Control Plane Considerations . . . . . . . . . . . . . . . . 20 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 100 12.2. Informative References . . . . . . . . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Introduction 105 In mobile networks, mobility management systems provide connectivity 106 while mobile nodes move around. While the control-plane of the 107 system signals movements of a mobile node, user-plane establishes 108 tunnel between the mobile node and anchor node over IP based backhaul 109 and core networks. 111 This document discusses the applicability of SRv6 (Segment Routing 112 IPv6) to those mobile networks. SRv6 provides source routing to 113 networks where operators can explicitly indicate a route for the 114 packets from and to the mobile node. SRv6 endpoint nodes perform the 115 roles of anchor of mobile user-plane. 117 2. Conventions and Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 SRH is the abbreviation for the Segment Routing Header. We assume 124 that the SRH may be present multiple times inside each packet. 126 NH is the abbreviation of the IPv6 next-header field. 128 NH=SRH means that the next-header field is 43 with routing type 4. 130 When there are multiple SRHs, they must follow each other: the next- 131 header field of all SRH, except the last one, must be SRH. 133 The effective next-header (ENH) is the next-header field of the IP 134 header when no SRH is present, or is the next-header field of the 135 last SRH. 137 In this version of the document, we assume that there is no other 138 extension header than the SRH. This will be lifted in future 139 versions of the document. 141 SID: A Segment Identifier which represents a specific segment in 142 segment routing domain. The SID type used in this document is IPv6 143 address (also referenced as SRv6 Segment or SRv6 SID). 145 A SID list is represented as where S1 is the first SID 146 to visit, S2 is the second SID to visit and S3 is the last SID to 147 visit along the SR path. 149 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 151 o IPv6 header with source and destination addresses respectively SA 152 and DA and next-header is SRH 153 o SRH with SID list with SegmentsLeft = SL 154 o Note the difference between the <> and () symbols: 155 represents a SID list where S1 is the first SID and S3 is the last 156 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 157 the SRH format where the rightmost SID in the SRH is the first SID 158 and the leftmost SID in the SRH is the last SID. When referring 159 to an SR policy in a high-level use-case, it is simpler to use the 160 notation. When referring to an illustration of the 161 detailed behavior, the (S3, S2, S1; SL) notation is more 162 convenient. 163 o The payload of the packet is omitted. 165 SRH[SL] represents the SID pointed by the SL field in the first SRH. 166 In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0] 167 represents S3. 169 FIB is the abbreviation for the forwarding table. A FIB lookup is a 170 lookup in the forwarding table. When a packet is intercepted on a 171 wire, it is possible that SRH[SL] is different from the DA. 173 3. Motivation 175 Every day mobility networks are getting more challenging to operate: 176 on one hand, traffic is constantly growing, and latency requirements 177 are more strict; on the other-hand, there are new use-cases like NFV 178 that are also challenging network management. 180 Problem comes from the fact that the current architecture of mobile 181 networks is agnostic to the underlying transport. Indeed, it rigidly 182 fragments the user-plane into radio access, core and service networks 183 and connects them by tunneling techniques through the user-plane 184 roles such as access and anchor nodes. Such agnosticism and 185 rigidness make it difficult for the operator to optimize and operate 186 the data-path. 188 While the mobile network industry has been trying to solve those 189 problems, applications have shifted to use IPv6, and network 190 operators have started adopting IPv6 as their IP transport as well. 191 SRv6, the IPv6 instantiation of Segment Routing 192 [I-D.ietf-spring-segment-routing], integrates both the application 193 data-path and the underlying transport layer into one single 194 protocol, allowing operators to optimize the network in a simplified 195 manner and removing state from the network. 197 Further on, SRv6 introduces the notion of network-programming 198 [I-D.filsfils-spring-srv6-network-programming], that applied to 199 mobility fulfils the user-plane functions of mobility management. 200 SRv6 takes advantage of underlying transport awareness and 201 flexibility to deploy mobility user-plane functions in an optimized 202 manner. Those are the motivations to adopt SRv6 for mobile user- 203 plane. 205 4. Reference Architecture 207 This section describes a reference architecture and possible 208 deployment scenarios. 210 Figure 1 shows a reference architecture, based on 5G packet core 211 architecture [TS.23501]. 213 Please note that all the user-plane described in this document does 214 not depend on any specific architecture. This architecture is just 215 used as a reference based on the latest 3GPP standards at the time of 216 writing this draft. Other type of architectures can be seen in 217 [I-D.gundavelli-dmm-mfa] and [WHITEPAPER-5G-UP]. 219 +-----+ 220 | AMF | 221 +-----+ 222 / | [N11] 223 [N2] / +-----+ 224 +------/ | SMF | 225 / +-----+ 226 / / \ 227 / / \ [N4] 228 / / \ ________ 229 / / \ / \ 230 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 231 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 232 +--+ +-----+ +------+ +------+ \________/ 234 Figure 1: Reference Architecture 236 o UE : User Equipment 237 o gNB : gNodeB 238 o UPF : User Plane Function 240 * UPF1: Interfaces N3 and N9 241 * UPF2: Interfaces N9 and N6 242 * Note: For simplicity we don't depict a UPF that is only 243 connected to N9 interfaces, although the techniques described 244 in this document are also valid in such case. 245 o SMF : Session Management Function 246 o AMF : Access and Mobility Management Function 247 o DN : Data Network e.g. operator services, Internet access 249 A session from an UE gets assigned to an UPF. Sometimes more than 250 one UPF may be used for providing a certain kind of richer service 251 functions. UE gets its IP address from the DHCP block of its UPF. 252 The UPF advertises the IP address block towards the Internet ensuring 253 that return traffic is routed to the right UPF. 255 5. User-plane behaviors 257 This section describes the mobile user-plane behaviors using SRv6. 259 In order to simplify the SRv6 adoption, we present two different 260 "modes" that vary with respect the SRv6 SID allocation. The first 261 one is the "Traditional mode", which inherits the traditional mobile 262 user-plane. In this mode there is no change to mobility networks 263 architecture, except for the pure replacement of GTP-U [TS.29281] for 264 SRv6. 266 The second mode is the "Enhanced mode", which aggregates the mobile 267 sessions and allocates SID on a per policy basis. The benefit of the 268 latter is that the SR policy contains SIDs for Traffic Engineering 269 and VNFs. Both of these modes assume both the gNB and UPFs are SR- 270 aware (N3 and N9 interfaces are SRv6). 272 Additionally, we introduce a new "Enhanced mode with unchanged gNB 273 GTP behavior". This mode consists of two mechanisms for interworking 274 with legacy access networks -interface N3 unmodified-. One of these 275 mechanism is designed to interwork with legacy gNBs using GTP/IPv4. 276 The second method is designed to interwork with legacy gNBs using 277 GTP/IPv6. 279 This section makes reference to already existing SRv6 functions 280 defined in [I-D.filsfils-spring-srv6-network-programming] as well as 281 new SRv6 functions designed for the mobile userplane. The new SRv6 282 functions are detailed in the Section 6. 284 5.1. Traditional mode (formerly Basic mode) 286 In the traditional mode, we assume that mobile user-plane functions 287 are the same as existing ones except the use of SRv6 as the data 288 plane instead of GTP-U. No impact to the rest of mobile system 289 should be expected. 291 In the traditional mobile network, an UE session is mapped 1-for-1 292 with a specific GTP tunnel (TEID). This 1-for-1 mapping is 293 replicated here to replace the GTP encaps with the SRv6 encaps, while 294 not changing anything else. 296 This mode minimizes the changes required to the entire system and it 297 is a good starting point for forming the common basis. Note that in 298 this mode the TEID is embedded in each SID. 300 Our reference topology is shown in Figure 2. In this mode we assume 301 that the gNB and the UPFs are SR-aware. 303 ________ 304 SRv6 SRv6 / \ 305 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 306 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 307 +--+ +-----+ +------+ +------+ \________/ 308 SRv6 node SRv6 node SRv6 node 310 Figure 2: Traditional mode - Reference topology 312 5.1.1. Packet flow - Uplink 314 The uplink packet flow is the following: 316 UE_out : (A,Z) 317 gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Reduced 318 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 319 UPF2_out: (A,Z) -> End.DT4 or End.DT6 321 The UE packet arrives to the gNB. The gNB performs a 322 T.Encaps.Reduced operations. Since there is only one SID, there is 323 no need to push an SRH. gNB only adds an outer IPv6 header with IPv6 324 DA U1::1. U1::1 represents an anchoring SID specific for that 325 session at UPF1. The SID U1::1 is retrieved through the existing 326 control plane (N2 interface). 328 Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 329 function. This function maps the SID with the next anchoring point 330 and replaces U1::1 by U2::1, that belongs to the next anchoring 331 point. 333 Upon packet arrival on UPF2, the SID U2::1 corresponds to an End.DT 334 function. UPF2 decapsulates the packet, performs a lookup in a 335 specific table and forwards the packet towards the data network. 337 5.1.2. Packet flow - Downlink 339 The downlink packet flow is the following: 341 UPF2_in : (Z,A) 342 UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Reduced 343 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 344 gNB_out : (Z,A) -> End.DX4 or End.DX6 346 When the packet arrives to the UPF2, the UPF2 will map that 347 particular flow into a UE session. This UE session is associated 348 with the policy . The UPF2 performs a T.Encaps.Reduced 349 operation, encapsulating the packet into a new IPv6 header with no 350 SRH since there is only one SID. 352 Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 353 function. This function maps the SID with the next anchoring point 354 and replaces U1::1 by gNB::1, that belongs to the next anchoring 355 point. 357 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4/ 358 End.DX6 function. The gNB will decapsulates the packet, removing the 359 IPv6 header and all it's extensions headers and will forward the 360 traffic towards the UE. 362 5.1.3. IPv6 user-traffic 364 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 365 However based on local policy, a service provider MAY choose to do 366 SRH insertion. The main benefit is a lower overhead. In such case, 367 the functions used are T.Insert.Red at gNB, End.MAP at UPF1 and End.T 368 at UPF2 on Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at 369 gNB on Downlink. 371 5.2. Enhanced Mode (formerly Aggregate mode) 373 This mode improves the scalability. In addition, it provides key 374 improvements in terms of traffic steering and service chaining, 375 thanks to the use of an SR policy of multiple SIDs, instead of single 376 one in the Traditional mode. 378 Key points: 380 o Several UE share the same SR Policy (and it's composing SID) 381 o The SR policy MAY include SIDs for traffic engineering and service 382 chaining on top of the UPF anchor. 384 The gNB control-plane (N2 interface) is unchanged, specifically a 385 single IPv6 address is given to the gNB. 387 o The gNB MAY resolve the IP address into a SID list through a 388 mechanism like PCEP, DNS-lookup, small augment for LISP control- 389 plane, etc. 391 Our reference topology is shown in Figure 3. In this mode we assume 392 that the gNB and the UPF are SR-aware. We also assume that we have 393 two services segments, S1 and C1. S1 represents a VNF in the 394 network, and C1 represents a constraint path on a router over which 395 we are going to perform Traffic Engineering. Note that S1 and C1 396 belong to the underlay and don't have an N4 interface. For this 397 reason we don't consider them UPFs. 399 +----+ SRv6 _______ 400 SRv6 --| C1 |--[N3] / \ 401 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 402 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 403 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 404 SRv6 node \ +----+ / SRv6 node 405 -| S1 |- 406 +----+ 407 SRv6 node 408 NFV 410 Figure 3: Enhanced mode - Reference topology 412 5.2.1. Packet flow - Uplink 414 The uplink packet flow is the following: 416 UE_out : (A,Z) 417 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red 418 S1_out : (gNB, C1)(U2::1, C1; SL=1 (A,Z) 419 C1_out : (gNB, U2::1)(A,Z) -> PSP 420 UPF2_out: (A,Z) -> End.DT4 or End.DT6 422 UE sends its packet (A,Z) on a specific bearer session to its gNB. 423 gNB's CP associates that session from the UE(A) with the IPv6 address 424 B and GTP TEID T. gNB's CP does a lookup on B (by reverseDNS, LISP, 425 etc.) to find the related SID list . 427 Once the packet leaves the gNB, it already contains all the segments 428 of the SR policy. This SR policy contains segments for traffic 429 engineering (C1) and for service chaining (S1). 431 The nodes S1 and C1 perform their related Endpoint functionality and 432 forward. 434 When the packet arrives to UPF2, the active segment (U2::1) is an 435 End.DT4/6 which performs the decapsulation (removing the IPv6 header 436 with all it's extension headers) and forward towards the data 437 network. 439 Note that in case several APNs are using duplicated IPv4 private 440 address spaces, then the aggregated SR policies are unique per APNs. 442 5.2.2. Packet flow - Downlink 444 The downlink packet flow is the following: 446 UPF2_in : (Z,A) -> UPF2 maps the flow w/ 447 SID list 448 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red 449 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 450 S1_out : (U2::1, gNB)(Z,A) -> PSP 451 gNB_out : (Z,A) -> End.DX4 or End.DX6 453 When the packet arrives to the UPF2, the UPF2 will map that 454 particular flow into a UE session. This UE session is associated 455 with the policy . The UPF2 performs a T.Encaps.Reduced 456 operation, encapsulating the packet into a new IPv6 header with its 457 corresponding SRH. 459 The nodes C1 and S1 perform their related Endpoint processing. 461 Once the packet arrives to the gNB, the IPv6 DA corresponds to an 462 End.DX4 or End.DX6 (depending on the underlying traffic). The gNB 463 will decapsulate the packet, removing the IPv6 header and all it's 464 extensions headers and will forward the traffic towards the UE. 466 5.2.3. IPv6 user-traffic 468 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 469 However based on local policy, a service provider MAY choose to do 470 SRH insertion. The main benefit is a lower overhead. In such case, 471 the functions used are T.Insert.Red at gNB and End.T at UPF2 on 472 Uplink, T.Insert.Red at UPF2 and End.X at gNB on Downlink. 474 5.3. Enhanced mode with unchanged gNB GTP behavior 476 In this section we introduce two mechanisms for interworking with 477 legacy gNBs that still use GTP. One of the mechanisms is valid for 478 IPv4 while the other for IPv6. 480 In this scenario, it is assumed that gNB does not support SRv6. It 481 just supports GTP encapsulation over IPv4 or IPv6. Hence in order to 482 achieve interworking we are going to add a new SR Gateway (SRGW-UPF1) 483 entity. This SRGW is going to map the GTP traffic into SRv6. Note 484 that the SR GW is not an anchor point. 486 The SRGW maintains very little state on it. For this reason, both of 487 these methods (IPv4 and IPv6) scale to millions of UEs. 489 _______ 490 IP GTP SRv6 / \ 491 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 492 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 493 +--+ +-----+ +------+ +------+ \_______/ 494 SR Gateway SRv6 node 496 Figure 4: Reference topology for interworking 498 5.3.1. Interworking with IPv6 GTP 500 In this interworking mode we assume that the gNB is using GTP over 501 IPv6 in the N3 interface 503 Key points: 505 o gNB is unchanged (control-plane or user-plane) and encaps into GTP 506 (N3 interface is not modified). 507 o 5G Control-Plane (N2 interface) is unmodified: 1 IPv6 address 508 (i.e. a BSID at the SRGW) 509 o SRGW removes GTP, finds SID list related to DA, add SRH with the 510 SID list. 511 o There is NO state for the downlink at the SRGW. 512 o There is simple state in the uplink at the SRGW (leveraging the 513 enhanced mode results in few SR policies on this node. A SR 514 policy can be shared across UEs). 515 o As soon as the packet leaves the gNB (uplink), the traffic is SR- 516 routed. This simplifies considerably network slicing 517 [I-D.hegdeppsenak-isis-sr-flex-algo]. 518 o In the uplink, we use the IPv6 DA BSID to steer the traffic into 519 an SR policy when it arrives at the SRGW-UPF1-. 521 Our reference topology is shown in Figure 5. In this mode we assume 522 that the gNB is an unmodified gNB using IPv6/GTP. The UPFs are SR- 523 aware. Also, as explained before, we introduce a new SRGW entity 524 that is going to map the IPv6/GTP traffic to SRv6. 526 We also assume that we have two service segment, S1 and C1. S1 527 represents a VNF in the network, and C1 represents a router over 528 which we are going to perform Traffic Engineering. 530 +----+ 531 IPv6/GTP -| S1 |- ___ 532 +--+ +-----+ [N3] / +----+ \ / 533 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 534 +--+ +-----+ \ [N9]/ NFV -| C1 |---| UPF2 |------\ DN 535 GTP \ +------+ / +----+ +------+ \___ 536 -| UPF1 |- SRv6 SRv6 537 +------+ TE 538 SR Gateway 540 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 542 5.3.1.1. Packet flow - Uplink 544 The uplink packet flow is the following: 546 UE_out : (A,Z) 547 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 548 (IPv6/GTP) 549 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 550 SID at the SRGW 551 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 552 C1_out : (SRGW, U2::1)(A,Z) -> PSP 553 UPF2_out: (A,Z) -> End.DT4 or End.DT6 555 The UE sends a packet destined to Z towards the gNB on a specific 556 bearer for that session. The gNB, which is unmodified, encapsulates 557 the packet into a new IPv6, UDP and GTP headers. The IPv6 DA B, and 558 the GTP TEID T are the ones received in the N2 interface. 560 The IPv6 address that was signalled over the N2 interface for that UE 561 session, B, is now the IPv6 DA. B is an SRv6 Binding SID 562 instantiated at the SRGW. Hence the packet, will be routed up to the 563 SRGW. 565 When the packet arrives at the SRGW, the SRGW realises that B is an 566 End.M.GTP6.D BindingSID. Hence, the SRGW will remove the IPv6, UDP 567 and GTP headers, and will push a new IPv6 header with its own SRH 568 containing the SIDs bound to the SR policy associated with this 569 BindingSID. 571 The nodes S1 and C1 perform their related Endpoint functionality and 572 forward. 574 When the packet arrives to UPF2, the active segment is (U2::1) which 575 bound to End.DT4/6 which is going to perform the decapsulation 576 (removing the outer IPv6 header with all it's extension headers) and 577 forward towards the data network. 579 5.3.1.2. Packet flow - Downlink 581 The downlink packet flow is the following: 583 UPF2_in : (Z,A) -> UPF2 maps the flow with 584 585 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red 586 C1_out : (U2::1, S1)(gNB, S1; SL=2)(Z,A) 587 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 588 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 589 gNB_out : (Z,A) 591 When a packet destined to A arrives at the UPF2, the UPF2 performs a 592 lookup in the associated table to A and finds the SID list . The UPF2 performs a T.Encaps.Reduced operation, 594 encapsulating the packet into a new IPv6 header with its 595 corresponding SRH. 597 The nodes C1 and S1 perform their related Endpoint processing. 599 Once the packet arrives to the SRGW, the SRGW realizes the active SID 600 is an End.M.GTP6.E function. The SRGW removes the IPv6 header and 601 all it's extensions headers. The SRGW generates an IPv6, UDP and GTP 602 headers. The new IPv6 DA is the gNB which is the last SID in the 603 received SRH. The TEID in the generated GTP header is the arguments 604 of the received End.M.GTP6.E SID. The SRGW pushes the headers to the 605 packet and forwards the packet towards the gNB. 607 Once the packet arrives to the gNB, the packet is a regular IPv6/GTP 608 packet. The gNB looks for the specific radio bearer for that TEID 609 and forward it on the bearer. This gNB behavior is not modified from 610 current and previous generations. 612 5.3.1.3. Scalability 614 For the downlink traffic, the SRGW is stateless. All the state is in 615 the SRH imposed by the UPF2. The UPF2 must have the UE states as the 616 session anchor point. 618 For the uplink traffic, the state at the SRGW does not necessarily 619 need to be per UE session basis. A state of SR policy of which state 620 can be shared among UE's. Hence it is possible to deploy SRGW in 621 very scalable way compared to hold millions of states per UE session 622 basis. 624 5.3.1.4. IPv6 user-traffic 626 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 627 However based on local policy, a service provider MAY choose to do 628 SRH insertion. The main benefit is a lower overhead. 630 5.3.2. Interworking with IPv4 GTP 632 In this interworking mode we assume that the gNB is using GTP over 633 IPv4 in the N3 interface 635 Key points: 637 o gNB is unchanged and encaps into GTP (N3 interface is not 638 modified). 639 o In the uplink, traffic is classified at SRGW by UL CL(Uplink 640 Classifier) and steered into an SR policy. The SRGW is a UPF1 641 functionality, hence it can coexist with UPF UL CL functionality. 642 o SRGW removes GTP, finds SID list related to DA, add SRH with SID 643 list. 645 Our reference topology is shown in Figure 6. In this mode we assume 646 that the gNB is an unmodified gNB using IPv4/GTP. The UPFs are SR- 647 aware. Also, as explained before, we introduce a new SRGW entity 648 that is going to map the IPv4/GTP traffic to SRv6. 650 We also assume that we have two service segment, S1 and C1. S1 651 represents a VNF in the network, and C1 represents a router over 652 which we are going to perform Traffic Engineering. 654 +----+ 655 IPv4/GTP -| S1 |- ___ 656 +--+ +-----+ [N3] / +----+ \ / 657 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 658 +--+ +-----+ \ [N9]/ NFV -| C1 |---| UPF2 |------\ DN 659 GTP \ +------+ / +----+ +------+ \___ 660 -| UPF1 |- SRv6 SRv6 661 +------+ TE 662 SR Gateway 664 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 666 5.3.2.1. Packet flow - Uplink 668 The uplink packet flow is the following: 670 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 671 unchanged IPv4/GTP 672 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.Tmap function 673 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 674 C1_out : (SRGW, U2::1) (A,Z) -> PSP 675 UPF2_out: (A,Z) -> End.DT4 or End.DT6 677 The UE sends a packet destined to Z towards the gNB on a specific 678 bearer for that session. The gNB, which is unmodified, encapsulates 679 the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and 680 the GTP TEID are the ones received at the N2 interface. 682 When the packet arrives to the SRGW -UPF1-, the SRGW has an UL CL 683 (uplink classifier) rule for incoming traffic from the gNB that 684 steers the traffic into an SR policy by using the function T.M.TMap. 685 The SRGW removes the IPv4, UDP and GTP headers and pushes an IPv6 686 header with its own SRH containing the SIDs related to the SR policy 687 associated with this traffic. The SRGW forwards according to the new 688 IPv6 DA. 690 The nodes S1 and C1 perform their related Endpoint functionality and 691 forward. 693 When the packet arrives at UPF2, the active segment is (U2::1) which 694 is bound to End.DT4/6 which performs the decapsulation (removing the 695 outer IPv6 header with all it's extension headers) and forwards 696 towards the data network. 698 5.3.2.2. Packet flow - Downlink 700 The downlink packet flow is the following: 702 UPF2_in : (Z,A) -> UPF2 maps flow with SID 703 704 UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red 705 C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) 706 S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) 707 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 708 gNB_out : (Z,A) 710 When a packet destined to A arrives to the UPF2, the UPF2 performs a 711 lookup in the associated table to A and finds the SID list . The UPF2 performs a T.Encaps.Reduced operation, 713 encapsulating the packet into a new IPv6 header with its 714 corresponding SRH. 716 The nodes C1 and S1 perform their related Endpoint processing. 718 Once the packet arrives to the SRGW, the SRGW realizes the active SID 719 is an End.M.GTP4.E function. The SRGW removes the IPv6 header and 720 all it's extensions headers. The SRGW generates an IPv4, UDP and GTP 721 headers. The IPv4 SA and DA will the ones received as part of the 722 SID arguments. The TEID in the generated GTP header is also the 723 arguments of the received End.M.GTP4.E SID The SRGW pushes the 724 headers to the packet and forwards the packet towards the gNB. 726 Once the packet arrives to the gNB, the packet is a regular IPv4/GTP 727 packet. The gNB looks for the specific radio bearer for that TEID 728 and forward it on the bearer. This gNB behavior is not modified from 729 current and previous generations. 731 5.3.2.3. Scalability 733 For the downlink traffic, the SRGW is stateless. All the state is in 734 the SRH imposed by the UPF. The UPF must have this UE-base state 735 anyway (it is its anchor point). 737 For the uplink traffic, the state at the SRGW is dedicated on a per 738 UE/session basis. This is an UL CL (uplink classifier). There is 739 state for steering the different sessions on a SR policies. Notice 740 however that the SR policies are shared among several UE/sessions. 742 5.3.2.4. IPv6 user-traffic 744 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 745 However based on local policy, a service provider MAY choose to do 746 SRH insertion. The main benefit is a lower overhead. 748 5.3.3. Extensions to the interworking mechanisms 750 In this section we presented two mechanisms for interworking with 751 gNBs that do not support SRv6. These mechanism are done to support 752 GTP over IPv4 and GTP over IPv6. 754 Even though we have presented these methods as an extension to the 755 "Enhanced mode", it is straightforward in its applicability to the 756 "Traditional mode". 758 Furthermore, although these mechanisms are designed for interworking 759 with legacy RAN at the N3 interface, these methods could also be 760 applied for interworking with a non-SRv6 capable UPF at the N9 761 interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). 763 6. SRv6 SID Mobility Functions 765 6.1. End.MAP: Endpoint function with SID mapping 767 The "Endpoint function with SID mapping" function (End.MAP for short) 768 is used in several scenarios. Particularly in mobility, it is used 769 in the UPFs for the anchor functionality in some of the use-cases. 771 When a SR node N receives a packet destined to S and S is a local 772 End.MAP SID, N does: 774 1. look up the IPv6 DA in the mapping table 775 2. update the IPv6 DA with the new mapped SID ;; Ref1 776 5. forward according to the new mapped SID 777 8. ELSE 778 9. Drop the packet 780 Ref1: Note that the SID in the SRH is NOT modified. 782 6.2. End.M.GTP6.D: Endpoint function with decapsulation from IPv6/GTP 783 tunnel 785 The "Endpoint function with IPv6/GTP decapsulation into SR policy" 786 function (End.M.GTP6.D for short) is used in interworking scenario 787 for the uplink towards from the legacy gNB using IPv6/GTP. This SID 788 is associated with an SR policy and an IPv6 Source 789 Address A. 791 When the SR Gateway node N receives a packet destined to S and S is a 792 local End.M.GTP6.D SID, N does: 794 1. IF NH=UDP & UDP_PORT = GTP THEN 795 2. pop the IP, UDP and GTP headers 796 3. push a new IPv6 header with its own SRH 797 4. set the outer IPv6 SA to A 798 5. set the outer IPv6 DA to S1 799 6. forward according to the first segment of the SRv6 Policy 800 7. ELSE 801 8. Drop the packet 803 6.3. End.M.GTP6.E: Endpoint function with encapsulation for IPv6/GTP 804 tunnel 806 The "Endpoint function with encapsulation for IPv6/GTP tunnel" 807 function (End.M.GTP6.E for short) is used in interworking scenario 808 for the downlink towards the legacy gNB using IPv6/GTP. 810 The End.M.GTP6.E function has a 32-bit argument space. This argument 811 corresponds to the GTP TEID. 813 When the SR Gateway node N receives a packet destined to S and S is a 814 local End.M.GTP6.E SID, N does: 816 1. IF NH=SRH & SL = 1 THEN ;; Ref1 817 2. decrement SL 818 3. store SRH[SL] in variable new_DA 819 4. store TEID in variable new_TEID ;; Ref2 820 5. pop IP header and all it's extension headers 821 6. push new IPv6 header and GTP-U header 822 7. set IPv6 DA to new_DA 823 8. set GTP_TEID to new_TEID 824 9. lookup the new_DA and forward the packet accordingly 825 10. ELSE 826 11. Drop the packet 828 Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID. 830 Ref2: TEID is extracted from the argument space of the current SID. 832 6.4. End.M.GTP4.E: Endpoint function with encapsulation for IPv4/GTP 833 tunnel 835 The "Endpoint function with encapsulation for IPv4/GTP tunnel" 836 function (End.M.GTP4.UP for short) is used in the downlink when doing 837 interworking with legacy gNB using IPv4/GTP. 839 When the SR Gateway node N receives a packet destined to S and S is a 840 local End.M.GTP4.E SID, N does: 842 1. IF NH=SRH & SL > 0 THEN 843 2. decrement SL 844 3. update the IPv6 DA with SRH[SL] 845 4. pop the SRH 846 4. push header of TUN-PROTO with tunnel ID from S ;; Ref1 847 5. push outer IPv4 header with SA, DA from S 848 6. ELSE 849 7. Drop the packet 850 Ref1: TUN-PROTO indicates target tunnel type. 852 Note that S has the following format: 854 +----------------------+-------+-------+-------+ 855 | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | 856 +----------------------+-------+-------+-------+ 857 128-a-b-c a b c 859 End.M.GTP4.E SID Encoding 861 6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation and mapping 862 into an SRv6 Policy 864 The "Transit with tunnel decapsulation and map to an SRv6 policy" 865 function (T.Tmap for short) is used in the direction from legacy 866 user-plane to SRv6 user-plane network. 868 When the SR Gateway node N receives a packet destined to a IW- 869 IPv4-Prefix, N does: 871 1. IF P.PLOAD == TUN-PROTO THEN ;; Ref1 872 2. pop the outer IPv4 header and tunnel headers 873 3. copy IPv4 DA, SA, TUN-ID to form SID B with SRGW-IPv6-Prefix 874 4. encapsulate the packet into a new IPv6 header ;; Ref2, Ref2bis 875 5. set the IPv6 DA = B 876 6. forward along the shortest path to B 877 7. ELSE 878 8. Drop the packet 880 Ref1: TUN-PROTO indicates target tunnel type. 882 Note that B has the following format: 884 +----------------------+-------+-------+-------+ 885 | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | 886 +----------------------+-------+-------+-------+ 887 128-a-b-c a b c 889 End.M.GTP4.E SID Encoding 891 Note that the B SID, is going to be an SRv6 BindingSID instantiated 892 at the first UPF (anchor point). A static format is leveraged to 893 instantiate this Binding SIDs in order to remove state from the SRGW. 895 6.6. End.Limit: Rate Limiting function 897 Mobile user-plane requires a rate-limit feature. SID is able to 898 encode limiting rate as an argument in SID. Multiple flows of 899 packets should have same group identifier in SID when those flows are 900 in an same AMBR group. This helps to keep user-plane stateless. 901 That enables SRv6 endpoint nodes which are unaware from the mobile 902 control-plane information. Encoding format of rate limit segment SID 903 is following: 905 +----------------------+----------+-----------+ 906 | LOC+FUNC rate-limit | group-id | limit-rate| 907 +----------------------+----------+-----------+ 908 128-i-j i j 910 End.Limit: Rate limiting function argument format 912 In case of j bit length is zero in SID, the node should not do rate 913 limiting unless static configuration or control-plane sets the limit 914 rate associated to the SID. 916 7. Network Slicing Considerations 918 A mobile network may be required to implement "network slices", which 919 logically separate network resources. User-plane functions 920 represented as SRv6 segments would be part of a slice. 922 A simple way to represent slice would be to apply L2/L3 VPN described 923 in [I-D.filsfils-spring-srv6-network-programming]. Segment Routing 924 with [I-D.hegdeppsenak-isis-sr-flex-algo] provides even more advanced 925 separation based on metrics like link-delay. Thus, a service 926 provider would be able to have network slices per required SLA. 928 The SRv6 SID and quite a few SR extended capability would be a 929 powerful tool for providing logical separation/integration within a 930 network. Details are for further study. 932 8. Control Plane Considerations 934 This documents focuses on the dataplane behavior. The control planes 935 could be based on the existing 3GPP based signalling for N4 interface 936 [TS.29244], [I-D.ietf-dmm-fpc-cpdp], control-plane protocols 937 described in [WHITEPAPER-5G-UP], etc. and to be discussed further. 939 Note that the IANA section of this document allocates the SRv6 940 endpoint function types for the new functions defined in this 941 document. All control-plane protocols are expected to leverage these 942 function type-codes to signal each function. 944 It's notable that SRv6's network programming nature allows a flexible 945 and dynamic anchor placement. 947 9. Security Considerations 949 TBD 951 10. IANA Considerations 953 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 954 Types" sub-registry belonging to the top-level "Segment-routing with 955 IPv6 dataplane (SRv6) Parameters" registry 956 [I-D.filsfils-spring-srv6-network-programming], the following 957 allocations: 959 +-------------+-----+-------------------+-----------+ 960 | Value/Range | Hex | Endpoint function | Reference | 961 +-------------+-----+-------------------+-----------+ 962 | TBA | TBA | End.MAP | [This.ID] | 963 | TBA | TBA | End.M.GTP6.D | [This.ID] | 964 | TBA | TBA | End.M.GTP6.E | [This.ID] | 965 | TBA | TBA | End.M.GTP4.E | [This.ID] | 966 | TBA | TBA | End.Limit | [This.ID] | 967 +-------------+-----+-------------------+-----------+ 969 Table 1: SRv6 Mobile User-plane Endpoint Types 971 11. Acknowledgements 973 The authors would like to thank Daisuke Yokota, Bart Peirens, 974 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch and Darren Dukes for 975 their useful comments of this work. 977 12. References 979 12.1. Normative References 981 [I-D.filsfils-spring-srv6-network-programming] 982 Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., 983 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 984 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 985 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., 986 Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., 987 Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. 988 Camarillo, "SRv6 Network Programming", draft-filsfils- 989 spring-srv6-network-programming-03 (work in progress), 990 December 2017. 992 [I-D.ietf-spring-segment-routing] 993 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 994 Litkowski, S., and R. Shakir, "Segment Routing 995 Architecture", draft-ietf-spring-segment-routing-15 (work 996 in progress), January 2018. 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, 1000 DOI 10.17487/RFC2119, March 1997, . 1003 12.2. Informative References 1005 [I-D.gundavelli-dmm-mfa] 1006 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 1007 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-00 1008 (work in progress), February 2018. 1010 [I-D.hegdeppsenak-isis-sr-flex-algo] 1011 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 1012 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 1013 isis-sr-flex-algo-02 (work in progress), February 2018. 1015 [I-D.ietf-dmm-fpc-cpdp] 1016 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1017 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1018 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09 1019 (work in progress), October 2017. 1021 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1022 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1023 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1024 . 1026 [TS.23501] 1027 3GPP, , "System Architecture for the 5G System", 3GPP TS 1028 23.501 15.0.0, November 2017. 1030 [TS.29244] 1031 3GPP, , "Interface between the Control Plane and the User 1032 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1034 [TS.29281] 1035 3GPP, , "General Packet Radio System (GPRS) Tunnelling 1036 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1037 December 2017. 1039 Authors' Addresses 1041 Satoru Matsushima 1042 SoftBank 1043 Tokyo 1044 Japan 1046 Email: satoru.matsushima@g.softbank.co.jp 1048 Clarence Filsfils 1049 Cisco Systems, Inc. 1050 Belgium 1052 Email: cf@cisco.com 1054 Miya Kohno 1055 Cisco Systems, Inc. 1056 Japan 1058 Email: mkohno@cisco.com 1060 Pablo Camarillo Garvia 1061 Cisco Systems, Inc. 1062 Spain 1064 Email: pcamaril@cisco.com 1066 Daniel Voyer 1067 Bell Canada 1068 Canada 1070 Email: daniel.voyer@bell.ca 1072 Charles E. Perkins 1073 Futurewei Inc. 1074 2330 Central Expressway 1075 Santa Clara, CA 95050 1076 USA 1078 Phone: +1-408-330-4586 1079 Email: charliep@computer.org