idnits 2.17.1 draft-ietf-dmm-srv6-mobile-uplane-02.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 (July 2, 2018) is 2126 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 850, but not defined -- Looks like a reference, but probably isn't: '2' on line 169 -- Looks like a reference, but probably isn't: '1' on line 169 -- Looks like a reference, but probably isn't: '0' on line 169 == Missing Reference: 'WHITEPAPER-5G-UP' is mentioned on line 220, but not defined == Missing Reference: 'N11' is mentioned on line 225, but not defined == Missing Reference: 'N2' is mentioned on line 226, but not defined == Missing Reference: 'N4' is mentioned on line 230, but not defined == Missing Reference: 'N3' is mentioned on line 662, but not defined == Missing Reference: 'N9' is mentioned on line 495, but not defined == Missing Reference: 'N6' is mentioned on line 663, but not defined == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 1046, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 == Outdated reference: A later version (-02) exists of draft-xuclad-spring-sr-service-programming-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-xuclad-spring-sr-service-programming-00 -- Duplicate reference: draft-xuclad-spring-sr-service-programming, mentioned in 'I-D.camarillo-dmm-srv6-mobile-pocs', was also mentioned in 'I-D.xuclad-spring-sr-service-programming'. == 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-12 == Outdated reference: A later version (-04) exists of draft-rodrigueznatal-lisp-srv6-00 Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 5 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: January 3, 2019 M. Kohno 6 P. Camarillo 7 Cisco Systems, Inc. 8 D. Voyer 9 Bell Canada 10 C. Perkins 11 Futurewei 12 July 2, 2018 14 Segment Routing IPv6 for Mobile User Plane 15 draft-ietf-dmm-srv6-mobile-uplane-02 17 Abstract 19 This document discusses the applicability of SRv6 (Segment Routing 20 IPv6) to user-plane of mobile networks (N3 and N9 interfaces). The 21 source routing capability and the network programming nature of SRv6, 22 accomplish mobile user-plane functions in a simple manner. The 23 statelessness and the ability to control underlying layer will be 24 even more 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 https://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 January 3, 2019. 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 (https://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) . . . . . . . . . 7 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 . . . . . . 11 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 . . . . . . 17 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. SRv6 supported PDU session types . . . . . . . . . . . . . . 20 94 8. Network Slicing Considerations . . . . . . . . . . . . . . . 21 95 9. Control Plane Considerations . . . . . . . . . . . . . . . . 21 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 98 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 99 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22 100 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 14.1. Normative References . . . . . . . . . . . . . . . . . . 22 102 14.2. Informative References . . . . . . . . . . . . . . . . . 23 103 Appendix A. Implementations . . . . . . . . . . . . . . . . . . 25 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 106 1. Introduction 108 In mobile networks, mobility management systems provide connectivity 109 while mobile nodes move around. While the control-plane of the 110 system signals movements of a mobile node, user-plane establishes 111 tunnel between the mobile node and anchor node over IP based backhaul 112 and core networks. 114 This document discusses the applicability of SRv6 (Segment Routing 115 IPv6) to those mobile networks. SRv6 provides source routing to 116 networks where operators can explicitly indicate a route for the 117 packets from and to the mobile node. SRv6 endpoint nodes perform the 118 roles of anchor of mobile user-plane. 120 2. Conventions and Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 SRH is the abbreviation for the Segment Routing Header. We assume 127 that the SRH may be present multiple times inside each packet. 129 NH is the abbreviation of the IPv6 next-header field. 131 NH=SRH means that the next-header field is 43 with routing type 4. 133 When there are multiple SRHs, they must follow each other: the next- 134 header field of all SRH, except the last one, must be SRH. 136 The effective next-header (ENH) is the next-header field of the IP 137 header when no SRH is present, or is the next-header field of the 138 last SRH. 140 In this version of the document, we assume that there is no other 141 extension header than the SRH. This will be lifted in future 142 versions of the document. 144 SID: A Segment Identifier which represents a specific segment in 145 segment routing domain. The SID type used in this document is IPv6 146 address (also referenced as SRv6 Segment or SRv6 SID). 148 A SID list is represented as where S1 is the first SID 149 to visit, S2 is the second SID to visit and S3 is the last SID to 150 visit along the SR path. 152 (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with: 154 o IPv6 header with source and destination addresses respectively SA 155 and DA and next-header is SRH 156 o SRH with SID list with SegmentsLeft = SL 157 o Note the difference between the <> and () symbols: 158 represents a SID list where S1 is the first SID and S3 is the last 159 SID. (S3, S2, S1; SL) represents the same SID list but encoded in 160 the SRH format where the rightmost SID in the SRH is the first SID 161 and the leftmost SID in the SRH is the last SID. When referring 162 to an SR policy in a high-level use-case, it is simpler to use the 163 notation. When referring to an illustration of the 164 detailed behavior, the (S3, S2, S1; SL) notation is more 165 convenient. 166 o The payload of the packet is omitted. 168 SRH[SL] represents the SID pointed by the SL field in the first SRH. 169 In our example, SRH[2] represents S1, SRH[1] represents S2 and SRH[0] 170 represents S3. 172 FIB is the abbreviation for the forwarding table. A FIB lookup is a 173 lookup in the forwarding table. When a packet is intercepted on a 174 wire, it is possible that SRH[SL] is different from the DA. 176 3. Motivation 178 Every day mobility networks are getting more challenging to operate: 179 on one hand, traffic is constantly growing, and latency requirements 180 are more strict; on the other-hand, there are new use-cases like NFV 181 that are also challenging network management. 183 Problem comes from the fact that the current architecture of mobile 184 networks is agnostic to the underlying transport. Indeed, it rigidly 185 fragments the user-plane into radio access, core and service networks 186 and connects them by tunneling techniques through the user-plane 187 roles such as access and anchor nodes. Such agnosticism and 188 rigidness make it difficult for the operator to optimize and operate 189 the data-path. 191 While the mobile network industry has been trying to solve those 192 problems, applications have shifted to use IPv6, and network 193 operators have started adopting IPv6 as their IP transport as well. 194 SRv6, the IPv6 instantiation of Segment Routing 195 [I-D.ietf-spring-segment-routing], integrates both the application 196 data-path and the underlying transport layer into one single 197 protocol, allowing operators to optimize the network in a simplified 198 manner and removing forwarding state from the network. 200 Further on, SRv6 introduces the notion of network-programming 201 [I-D.filsfils-spring-srv6-network-programming], that applied to 202 mobility fulfils the user-plane functions of mobility management. 203 SRv6 takes advantage of underlying transport awareness and 204 flexibility to deploy mobility user-plane functions in an optimized 205 manner. Those are the motivations to adopt SRv6 for mobile user- 206 plane. 208 4. Reference Architecture 210 This section describes a reference architecture and possible 211 deployment scenarios. 213 Figure 1 shows a reference architecture, based on 5G packet core 214 architecture [TS.23501]. 216 Please note that all the user-plane described in this document does 217 not depend on any specific architecture. This architecture is just 218 used as a reference based on the latest 3GPP standards at the time of 219 writing this draft. Other type of architectures can be seen in 220 [I-D.gundavelli-dmm-mfa] and [WHITEPAPER-5G-UP]. 222 +-----+ 223 | AMF | 224 +-----+ 225 / | [N11] 226 [N2] / +-----+ 227 +------/ | SMF | 228 / +-----+ 229 / / \ 230 / / \ [N4] 231 / / \ ________ 232 / / \ / \ 233 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 234 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 235 +--+ +-----+ +------+ +------+ \________/ 237 Figure 1: Reference Architecture 239 o UE : User Equipment 240 o gNB : gNodeB 241 o UPF : User Plane Function 243 * UPF1: Interfaces N3 and N9 244 * UPF2: Interfaces N9 and N6 245 * Note: For simplicity we don't depict a UPF that is only 246 connected to N9 interfaces, although the techniques described 247 in this document are also valid in such case. 248 o SMF : Session Management Function 249 o AMF : Access and Mobility Management Function 250 o DN : Data Network e.g. operator services, Internet access 252 A session from an UE gets assigned to an UPF. Sometimes more than 253 one UPF may be used for providing a certain kind of richer service 254 functions. UE gets its IP address from the DHCP block of its UPF. 255 The UPF advertises the IP address block towards the Internet ensuring 256 that return traffic is routed to the right UPF. 258 5. User-plane behaviors 260 This section describes the mobile user-plane behaviors using SRv6. 262 In order to simplify the SRv6 adoption, we present two different 263 "modes" that vary with respect the SRv6 SID allocation. The first 264 one is the "Traditional mode", which inherits the traditional mobile 265 user-plane. In this mode there is no change to mobility networks 266 architecture, except for the pure replacement of GTP-U [TS.29281] for 267 SRv6. 269 The second mode is the "Enhanced mode", which aggregates the mobile 270 sessions and allocates SID on a per policy basis. The benefit of the 271 latter is that the SR policy contains SIDs for Traffic Engineering 272 and VNFs. Both of these modes assume both the gNB and UPFs are SR- 273 aware (N3 and N9 interfaces are SRv6). 275 Additionally, we introduce a new "Enhanced mode with unchanged gNB 276 GTP behavior". This mode consists of two mechanisms for interworking 277 with legacy access networks -interface N3 unmodified-. One of these 278 mechanism is designed to interwork with legacy gNBs using GTP/IPv4. 279 The second method is designed to interwork with legacy gNBs using 280 GTP/IPv6. 282 This section makes reference to already existing SRv6 functions 283 defined in [I-D.filsfils-spring-srv6-network-programming] as well as 284 new SRv6 functions designed for the mobile userplane. The new SRv6 285 functions are detailed in the Section 6. 287 5.1. Traditional mode (formerly Basic mode) 289 In the traditional mode, we assume that mobile user-plane functions 290 are the same as existing ones except the use of SRv6 as the data 291 plane instead of GTP-U. No impact to the rest of mobile system 292 should be expected. 294 In the traditional mobile network, an UE session is mapped 1-for-1 295 with a specific GTP tunnel (TEID). This 1-for-1 mapping is 296 replicated here to replace the GTP encaps with the SRv6 encaps, while 297 not changing anything else. 299 This mode minimizes the changes required to the entire system and it 300 is a good starting point for forming the common basis. Note that in 301 this mode the TEID is embedded in each SID. 303 Our reference topology is shown in Figure 2. In this mode we assume 304 that the gNB and the UPFs are SR-aware. 306 ________ 307 SRv6 SRv6 / \ 308 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 309 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 310 +--+ +-----+ +------+ +------+ \________/ 311 SRv6 node SRv6 node SRv6 node 313 Figure 2: Traditional mode - Reference topology 315 5.1.1. Packet flow - Uplink 317 The uplink packet flow is the following: 319 UE_out : (A,Z) 320 gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Reduced 321 UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP 322 UPF2_out: (A,Z) -> End.DT4 or End.DT6 324 The UE packet arrives to the gNB. The gNB performs a 325 T.Encaps.Reduced operations. Since there is only one SID, there is 326 no need to push an SRH. gNB only adds an outer IPv6 header with IPv6 327 DA U1::1. U1::1 represents an anchoring SID specific for that 328 session at UPF1. The SID U1::1 is retrieved through the existing 329 control plane (N2 interface). 331 Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 332 function. This function maps the SID with the next anchoring point 333 and replaces U1::1 by U2::1, that belongs to the next anchoring 334 point. 336 Upon packet arrival on UPF2, the SID U2::1 corresponds to an End.DT 337 function. UPF2 decapsulates the packet, performs a lookup in a 338 specific table and forwards the packet towards the data network. 340 5.1.2. Packet flow - Downlink 342 The downlink packet flow is the following: 344 UPF2_in : (Z,A) 345 UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Reduced 346 UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP 347 gNB_out : (Z,A) -> End.DX4 or End.DX6 349 When the packet arrives to the UPF2, the UPF2 will map that 350 particular flow into a UE session. This UE session is associated 351 with the policy . The UPF2 performs a T.Encaps.Reduced 352 operation, encapsulating the packet into a new IPv6 header with no 353 SRH since there is only one SID. 355 Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP 356 function. This function maps the SID with the next anchoring point 357 and replaces U1::1 by gNB::1, that belongs to the next anchoring 358 point. 360 Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4/ 361 End.DX6 function. The gNB will decapsulates the packet, removing the 362 IPv6 header and all it's extensions headers and will forward the 363 traffic towards the UE. 365 5.1.3. IPv6 user-traffic 367 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 368 However based on local policy, a service provider MAY choose to do 369 SRH insertion. The main benefit is a lower overhead. In such case, 370 the functions used are T.Insert.Red at gNB, End.MAP at UPF1 and End.T 371 at UPF2 on Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at 372 gNB on Downlink. 374 5.2. Enhanced Mode (formerly Aggregate mode) 376 This mode improves the scalability. In addition, it provides key 377 improvements in terms of traffic steering and service programming 378 [I-D.xuclad-spring-sr-service-programming] , thanks to the use of an 379 SR policy of multiple SIDs, instead of single one in the Traditional 380 mode. 382 Key points: 384 o Several UE share the same SR Policy (and it's composing SID) 385 o The SR policy MAY include SIDs for traffic engineering and service 386 programming on top of the UPF anchor. 388 The gNB control-plane (N2 interface) is unchanged, specifically a 389 single IPv6 address is given to the gNB. 391 o The gNB MAY resolve the IP address into a SID list through a 392 mechanism like PCEP, DNS-lookup, small augment for LISP control- 393 plane, etc. 395 Our reference topology is shown in Figure 3. In this mode we assume 396 that the gNB and the UPF are SR-aware. We also assume that we have 397 two services segments, S1 and C1. S1 represents a VNF in the 398 network, and C1 represents a constraint path on a router over which 399 we are going to perform Traffic Engineering. Note that S1 and C1 400 belong to the underlay and don't have an N4 interface. For this 401 reason we don't consider them UPFs. 403 +----+ SRv6 _______ 404 SRv6 --| C1 |--[N3] / \ 405 +--+ +-----+ [N3] / +----+ \ +------+ [N6] / \ 406 |UE|----| gNB |-- SRv6 / SRv6 --| UPF2 |------\ DN / 407 +--+ +-----+ \ [N3]/ TE +------+ \_______/ 408 SRv6 node \ +----+ / SRv6 node 409 -| S1 |- 410 +----+ 411 SRv6 node 412 VNF 414 Figure 3: Enhanced mode - Reference topology 416 5.2.1. Packet flow - Uplink 418 The uplink packet flow is the following: 420 UE_out : (A,Z) 421 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red 422 S1_out : (gNB, C1)(U2::1, C1; SL=1 (A,Z) 423 C1_out : (gNB, U2::1)(A,Z) -> PSP 424 UPF2_out: (A,Z) -> End.DT4 or End.DT6 426 UE sends its packet (A,Z) on a specific bearer session to its gNB. 427 gNB's CP associates that session from the UE(A) with the IPv6 address 428 B and GTP TEID T. gNB's CP does a lookup on B (by reverseDNS, LISP, 429 etc.) to find the related SID list . 431 Once the packet leaves the gNB, it already contains all the segments 432 of the SR policy. This SR policy contains segments for traffic 433 engineering (C1) and for service programming (S1). 435 The nodes S1 and C1 perform their related Endpoint functionality and 436 forward. 438 When the packet arrives to UPF2, the active segment (U2::1) is an 439 End.DT4/6 which performs the decapsulation (removing the IPv6 header 440 with all it's extension headers) and forward towards the data 441 network. 443 Note that in case several APNs are using duplicated IPv4 private 444 address spaces, then the aggregated SR policies are unique per APNs. 446 5.2.2. Packet flow - Downlink 448 The downlink packet flow is the following: 450 UPF2_in : (Z,A) -> UPF2 maps the flow w/ 451 SID list 452 UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red 453 C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A) 454 S1_out : (U2::1, gNB)(Z,A) -> PSP 455 gNB_out : (Z,A) -> End.DX4 or End.DX6 457 When the packet arrives to the UPF2, the UPF2 will map that 458 particular flow into a UE session. This UE session is associated 459 with the policy . The UPF2 performs a T.Encaps.Reduced 460 operation, encapsulating the packet into a new IPv6 header with its 461 corresponding SRH. 463 The nodes C1 and S1 perform their related Endpoint processing. 465 Once the packet arrives to the gNB, the IPv6 DA corresponds to an 466 End.DX4 or End.DX6 (depending on the underlying traffic). The gNB 467 will decapsulate the packet, removing the IPv6 header and all it's 468 extensions headers and will forward the traffic towards the UE. 470 5.2.3. IPv6 user-traffic 472 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 473 However based on local policy, a service provider MAY choose to do 474 SRH insertion. The main benefit is a lower overhead. In such case, 475 the functions used are T.Insert.Red at gNB and End.T at UPF2 on 476 Uplink, T.Insert.Red at UPF2 and End.X at gNB on Downlink. 478 5.3. Enhanced mode with unchanged gNB GTP behavior 480 In this section we introduce two mechanisms for interworking with 481 legacy gNBs that still use GTP. One of the mechanisms is valid for 482 IPv4 while the other for IPv6. 484 In this scenario, it is assumed that gNB does not support SRv6. It 485 just supports GTP encapsulation over IPv4 or IPv6. Hence in order to 486 achieve interworking we are going to add a new SR Gateway (SRGW-UPF1) 487 entity. This SRGW is going to map the GTP traffic into SRv6. Note 488 that the SR GW is not an anchor point. 490 The SRGW maintains very little state on it. For this reason, both of 491 these methods (IPv4 and IPv6) scale to millions of UEs. 493 _______ 494 IP GTP SRv6 / \ 495 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 496 |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / 497 +--+ +-----+ +------+ +------+ \_______/ 498 SR Gateway SRv6 node 500 Figure 4: Reference topology for interworking 502 5.3.1. Interworking with IPv6 GTP 504 In this interworking mode we assume that the gNB is using GTP over 505 IPv6 in the N3 interface 507 Key points: 509 o gNB is unchanged (control-plane or user-plane) and encaps into GTP 510 (N3 interface is not modified). 511 o 5G Control-Plane (N2 interface) is unmodified: 1 IPv6 address 512 (i.e. a BSID at the SRGW) 513 o SRGW removes GTP, finds SID list related to DA, add SRH with the 514 SID list. 515 o There is NO state for the downlink at the SRGW. 516 o There is simple state in the uplink at the SRGW (leveraging the 517 enhanced mode results in few SR policies on this node. A SR 518 policy can be shared across UEs). 519 o As soon as the packet leaves the gNB (uplink), the traffic is SR- 520 routed. This simplifies considerably network slicing 521 [I-D.hegdeppsenak-isis-sr-flex-algo]. 522 o In the uplink, we use the IPv6 DA BSID to steer the traffic into 523 an SR policy when it arrives at the SRGW-UPF1-. 525 Our reference topology is shown in Figure 5. In this mode we assume 526 that the gNB is an unmodified gNB using IPv6/GTP. The UPFs are SR- 527 aware. Also, as explained before, we introduce a new SRGW entity 528 that is going to map the IPv6/GTP traffic to SRv6. 530 We also assume that we have two service segment, S1 and C1. S1 531 represents a VNF in the network, and C1 represents a router over 532 which we are going to perform Traffic Engineering. 534 +----+ 535 IPv6/GTP -| S1 |- ___ 536 +--+ +-----+ [N3] / +----+ \ / 537 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 538 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 539 GTP \ +------+ / +----+ +------+ \___ 540 -| UPF1 |- SRv6 SRv6 541 +------+ TE 542 SR Gateway 544 Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior 546 5.3.1.1. Packet flow - Uplink 548 The uplink packet flow is the following: 550 UE_out : (A,Z) 551 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified 552 (IPv6/GTP) 553 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D 554 SID at the SRGW 555 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 556 C1_out : (SRGW, U2::1)(A,Z) -> PSP 557 UPF2_out: (A,Z) -> End.DT4 or End.DT6 559 The UE sends a packet destined to Z towards the gNB on a specific 560 bearer for that session. The gNB, which is unmodified, encapsulates 561 the packet into a new IPv6, UDP and GTP headers. The IPv6 DA B, and 562 the GTP TEID T are the ones received in the N2 interface. 564 The IPv6 address that was signalled over the N2 interface for that UE 565 session, B, is now the IPv6 DA. B is an SRv6 Binding SID 566 instantiated at the SRGW. Hence the packet, will be routed up to the 567 SRGW. 569 When the packet arrives at the SRGW, the SRGW realises that B is an 570 End.M.GTP6.D BindingSID. Hence, the SRGW will remove the IPv6, UDP 571 and GTP headers, and will push a new IPv6 header with its own SRH 572 containing the SIDs bound to the SR policy associated with this 573 BindingSID. Note that there will be one instance of the End.M.GTP6.D 574 SID per PDU type. 576 The nodes S1 and C1 perform their related Endpoint functionality and 577 forward. 579 When the packet arrives to UPF2, the active segment is (U2::1) which 580 bound to End.DT4/6 which is going to perform the decapsulation 581 (removing the outer IPv6 header with all it's extension headers) and 582 forward towards the data network. 584 5.3.1.2. Packet flow - Downlink 586 The downlink packet flow is the following: 588 UPF2_in : (Z,A) -> UPF2 maps the flow with 589 590 UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red 591 C1_out : (U2::1, S1)(gNB, S1; SL=2)(Z,A) 592 S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A) 593 SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E 594 gNB_out : (Z,A) 596 When a packet destined to A arrives at the UPF2, the UPF2 performs a 597 lookup in the associated table to A and finds the SID list . The UPF2 performs a T.Encaps.Reduced operation, 599 encapsulating the packet into a new IPv6 header with its 600 corresponding SRH. 602 The nodes C1 and S1 perform their related Endpoint processing. 604 Once the packet arrives to the SRGW, the SRGW realizes the active SID 605 is an End.M.GTP6.E function. The SRGW removes the IPv6 header and 606 all it's extensions headers. The SRGW generates an IPv6, UDP and GTP 607 headers. The new IPv6 DA is the gNB which is the last SID in the 608 received SRH. The TEID in the generated GTP header is the arguments 609 of the received End.M.GTP6.E SID. The SRGW pushes the headers to the 610 packet and forwards the packet towards the gNB. Note that there will 611 be one instance of the End.M.GTP6.E SID per PDU type. 613 Once the packet arrives to the gNB, the packet is a regular IPv6/GTP 614 packet. The gNB looks for the specific radio bearer for that TEID 615 and forward it on the bearer. This gNB behavior is not modified from 616 current and previous generations. 618 5.3.1.3. Scalability 620 For the downlink traffic, the SRGW is stateless. All the state is in 621 the SRH imposed by the UPF2. The UPF2 must have the UE states as the 622 session anchor point. 624 For the uplink traffic, the state at the SRGW does not necessarily 625 need to be per UE session basis. A state of SR policy of which state 626 can be shared among UE's. Hence it is possible to deploy SRGW in 627 very scalable way compared to hold millions of states per UE session 628 basis. 630 5.3.1.4. IPv6 user-traffic 632 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 633 However based on local policy, a service provider MAY choose to do 634 SRH insertion. The main benefit is a lower overhead. 636 5.3.2. Interworking with IPv4 GTP 638 In this interworking mode we assume that the gNB is using GTP over 639 IPv4 in the N3 interface 641 Key points: 643 o gNB is unchanged and encaps into GTP (N3 interface is not 644 modified). 645 o In the uplink, traffic is classified at SRGW by UL CL(Uplink 646 Classifier) and steered into an SR policy. The SRGW is a UPF1 647 functionality, hence it can coexist with UPF UL CL functionality. 648 o SRGW removes GTP, finds SID list related to DA, add SRH with SID 649 list. 651 Our reference topology is shown in Figure 6. In this mode we assume 652 that the gNB is an unmodified gNB using IPv4/GTP. The UPFs are SR- 653 aware. Also, as explained before, we introduce a new SRGW entity 654 that is going to map the IPv4/GTP traffic to SRv6. 656 We also assume that we have two service segment, S1 and C1. S1 657 represents a VNF in the network, and C1 represents a router over 658 which we are going to perform Traffic Engineering. 660 +----+ 661 IPv4/GTP -| S1 |- ___ 662 +--+ +-----+ [N3] / +----+ \ / 663 |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / 664 +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN 665 GTP \ +------+ / +----+ +------+ \___ 666 -| UPF1 |- SRv6 SRv6 667 +------+ TE 668 SR Gateway 670 Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior 672 5.3.2.1. Packet flow - Uplink 674 The uplink packet flow is the following: 676 gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 677 unchanged IPv4/GTP 678 SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.Tmap function 679 S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) 680 C1_out : (SRGW, U2::1) (A,Z) -> PSP 681 UPF2_out: (A,Z) -> End.DT4 or End.DT6 683 The UE sends a packet destined to Z towards the gNB on a specific 684 bearer for that session. The gNB, which is unmodified, encapsulates 685 the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and 686 the GTP TEID are the ones received at the N2 interface. 688 When the packet arrives to the SRGW -UPF1-, the SRGW has an UL CL 689 (uplink classifier) rule for incoming traffic from the gNB that 690 steers the traffic into an SR policy by using the function T.M.TMap. 691 The SRGW removes the IPv4, UDP and GTP headers and pushes an IPv6 692 header with its own SRH containing the SIDs related to the SR policy 693 associated with this traffic. The SRGW forwards according to the new 694 IPv6 DA. 696 The nodes S1 and C1 perform their related Endpoint functionality and 697 forward. 699 When the packet arrives at UPF2, the active segment is (U2::1) which 700 is bound to End.DT4/6 which performs the decapsulation (removing the 701 outer IPv6 header with all it's extension headers) and forwards 702 towards the data network. 704 5.3.2.2. Packet flow - Downlink 706 The downlink packet flow is the following: 708 UPF2_in : (Z,A) -> UPF2 maps flow with SID 709 710 UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red 711 C1_out : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A) 712 S1_out : (U2::1, SRGW::SA:DA:TEID)(Z,A) 713 SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E 714 gNB_out : (Z,A) 716 When a packet destined to A arrives to the UPF2, the UPF2 performs a 717 lookup in the associated table to A and finds the SID list . The UPF2 performs a T.Encaps.Reduced operation, 719 encapsulating the packet into a new IPv6 header with its 720 corresponding SRH. 722 The nodes C1 and S1 perform their related Endpoint processing. 724 Once the packet arrives to the SRGW, the SRGW realizes the active SID 725 is an End.M.GTP4.E function. The SRGW removes the IPv6 header and 726 all it's extensions headers. The SRGW generates an IPv4, UDP and GTP 727 headers. The IPv4 SA and DA will the ones received as part of the 728 SID arguments. The TEID in the generated GTP header is also the 729 arguments of the received End.M.GTP4.E SID The SRGW pushes the 730 headers to the packet and forwards the packet towards the gNB. 732 Once the packet arrives to the gNB, the packet is a regular IPv4/GTP 733 packet. The gNB looks for the specific radio bearer for that TEID 734 and forward it on the bearer. This gNB behavior is not modified from 735 current and previous generations. 737 5.3.2.3. Scalability 739 For the downlink traffic, the SRGW is stateless. All the state is in 740 the SRH imposed by the UPF. The UPF must have this UE-base state 741 anyway (it is its anchor point). 743 For the uplink traffic, the state at the SRGW is dedicated on a per 744 UE/session basis. This is an UL CL (uplink classifier). There is 745 state for steering the different sessions on a SR policies. Notice 746 however that the SR policies are shared among several UE/sessions. 748 5.3.2.4. IPv6 user-traffic 750 For IPv6 user-traffic it is RECOMMENDED to perform encapsulation. 751 However based on local policy, a service provider MAY choose to do 752 SRH insertion. The main benefit is a lower overhead. 754 5.3.3. Extensions to the interworking mechanisms 756 In this section we presented two mechanisms for interworking with 757 gNBs that do not support SRv6. These mechanism are done to support 758 GTP over IPv4 and GTP over IPv6. 760 Even though we have presented these methods as an extension to the 761 "Enhanced mode", it is straightforward in its applicability to the 762 "Traditional mode". 764 Furthermore, although these mechanisms are designed for interworking 765 with legacy RAN at the N3 interface, these methods could also be 766 applied for interworking with a non-SRv6 capable UPF at the N9 767 interface (e.g. L3-anchor is SRv6 capable but L2-anchor is not). 769 6. SRv6 SID Mobility Functions 771 6.1. End.MAP: Endpoint function with SID mapping 773 The "Endpoint function with SID mapping" function (End.MAP for short) 774 is used in several scenarios. Particularly in mobility, it is used 775 in the UPFs for the anchor functionality in some of the use-cases. 777 When a SR node N receives a packet destined to S and S is a local 778 End.MAP SID, N does: 780 1. look up the IPv6 DA in the mapping table 781 2. update the IPv6 DA with the new mapped SID ;; Ref1 782 3. forward according to the new mapped SID 783 4. ELSE 784 5. Drop the packet 786 Ref1: Note that the SID in the SRH is NOT modified. 788 6.2. End.M.GTP6.D: Endpoint function with decapsulation from IPv6/GTP 789 tunnel 791 The "Endpoint function with IPv6/GTP decapsulation into SR policy" 792 function (End.M.GTP6.D for short) is used in interworking scenario 793 for the uplink towards from the legacy gNB using IPv6/GTP. This SID 794 is associated with an SR policy and an IPv6 Source 795 Address A. 797 When the SR Gateway node N receives a packet destined to S and S is a 798 local End.M.GTP6.D SID, N does: 800 1. IF NH=UDP & UDP_PORT = GTP THEN 801 2. pop the IP, UDP and GTP headers 802 3. push a new IPv6 header with its own SRH 803 4. set the outer IPv6 SA to A 804 5. set the outer IPv6 DA to S1 805 6. forward according to the first segment of the SRv6 Policy 806 7. ELSE 807 8. Drop the packet 809 6.3. End.M.GTP6.E: Endpoint function with encapsulation for IPv6/GTP 810 tunnel 812 The "Endpoint function with encapsulation for IPv6/GTP tunnel" 813 function (End.M.GTP6.E for short) is used in interworking scenario 814 for the downlink towards the legacy gNB using IPv6/GTP. 816 The End.M.GTP6.E function has a 32-bit argument space. This argument 817 corresponds to the GTP TEID. 819 When the SR Gateway node N receives a packet destined to S and S is a 820 local End.M.GTP6.E SID, N does: 822 1. IF NH=SRH & SL = 1 THEN ;; Ref1 823 2. decrement SL 824 3. store SRH[SL] in variable new_DA 825 4. store TEID in variable new_TEID ;; Ref2 826 5. pop IP header and all it's extension headers 827 6. push new IPv6 header and GTP-U header 828 7. set IPv6 DA to new_DA 829 8. set GTP_TEID to new_TEID 830 9. lookup the new_DA and forward the packet accordingly 831 10. ELSE 832 11. Drop the packet 834 Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID. 836 Ref2: TEID is extracted from the argument space of the current SID. 838 6.4. End.M.GTP4.E: Endpoint function with encapsulation for IPv4/GTP 839 tunnel 841 The "Endpoint function with encapsulation for IPv4/GTP tunnel" 842 function (End.M.GTP4.UP for short) is used in the downlink when doing 843 interworking with legacy gNB using IPv4/GTP. 845 When the SR Gateway node N receives a packet destined to S and S is a 846 local End.M.GTP4.E SID, N does: 848 1. IF NH=SRH & SL > 0 THEN 849 2. decrement SL 850 3. update the IPv6 DA with SRH[SL] 851 4. pop the SRH 852 5. push header of TUN-PROTO with tunnel ID from S ;; Ref1 853 6. push outer IPv4 header with SA, DA from S 854 7. ELSE 855 8. Drop the packet 857 Ref1: TUN-PROTO indicates target tunnel type. 859 Note that S has the following format: 861 +----------------------+-------+-------+-------+ 862 | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | 863 +----------------------+-------+-------+-------+ 864 128-a-b-c a b c 866 End.M.GTP4.E SID Encoding 868 6.5. T.M.Tmap: Transit behavior with IPv4/GTP decapsulation and mapping 869 into an SRv6 Policy 871 The "Transit with tunnel decapsulation and map to an SRv6 policy" 872 function (T.Tmap for short) is used in the direction from legacy 873 user-plane to SRv6 user-plane network. 875 When the SR Gateway node N receives a packet destined to a IW- 876 IPv4-Prefix, N does: 878 1. IF P.PLOAD == TUN-PROTO THEN ;; Ref1 879 2. pop the outer IPv4 header and tunnel headers 880 3. copy IPv4 DA, SA, TUN-ID to form SID B with SRGW-IPv6-Prefix 881 4. encapsulate the packet into a new IPv6 header ;; Ref2, Ref2bis 882 5. set the IPv6 DA = B 883 6. forward along the shortest path to B 884 7. ELSE 885 8. Drop the packet 887 Ref1: TUN-PROTO indicates target tunnel type. 889 Note that B has the following format: 891 +----------------------+-------+-------+-------+ 892 | SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID | 893 +----------------------+-------+-------+-------+ 894 128-a-b-c a b c 896 End.M.GTP4.E SID Encoding 898 Note that the B SID, is going to be an SRv6 BindingSID instantiated 899 at the first UPF (anchor point). A static format is leveraged to 900 instantiate this Binding SIDs in order to remove state from the SRGW. 902 6.6. End.Limit: Rate Limiting function 904 Mobile user-plane requires a rate-limit feature. SID is able to 905 encode limiting rate as an argument in SID. Multiple flows of 906 packets should have same group identifier in SID when those flows are 907 in an same AMBR group. This helps to keep user-plane stateless. 908 That enables SRv6 endpoint nodes which are unaware from the mobile 909 control-plane information. Encoding format of rate limit segment SID 910 is following: 912 +----------------------+----------+-----------+ 913 | LOC+FUNC rate-limit | group-id | limit-rate| 914 +----------------------+----------+-----------+ 915 128-i-j i j 917 End.Limit: Rate limiting function argument format 919 In case of j bit length is zero in SID, the node should not do rate 920 limiting unless static configuration or control-plane sets the limit 921 rate associated to the SID. 923 7. SRv6 supported PDU session types 925 The 3GPP [TS.23501] defines the following PDU session types: 927 o IPv4 928 o IPv6 929 o IPv4v6 930 o Ethernet 931 o Unstructured 933 SRv6 supports all the PDU session types without any protocol overhead 934 by using the corresponding SRv6 functions (End.DX4, End.DT4 for IPv4 935 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions; End.DT46 936 for IPv4v6 PDU sessions; End.DX2, End.DT2M for L2 PDU sessions; 937 End.DX2 for Unstructured PDU sessions). 939 8. Network Slicing Considerations 941 A mobile network may be required to implement "network slices", which 942 logically separate network resources. User-plane functions 943 represented as SRv6 segments would be part of a slice. 945 [I-D.filsfils-spring-segment-routing-policy] describes a solution to 946 build basic network slices with SR. Depending on the requirements, 947 these slices can be further refined by leveraging the mechanisms 948 from: 950 o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo] 951 o Inter-Domain policies 952 [I-D.ietf-spring-segment-routing-central-epe] 954 Furthermore, these can be combined with ODN/AS 955 [I-D.filsfils-spring-segment-routing-policy] for automated slice 956 provisioning and traffic steering. 958 A separate document will explain in detail how each one of these 959 tools is leveraged to build a network slice. 961 9. Control Plane Considerations 963 This documents focuses on the user-plane behavior and it's 964 independent from the control plane. 966 The control plane could be the current 3GPP-defined control plane 967 with slight modifications to the N4 interface [TS.29244]. 969 Alternatively, SRv6 could be used in conjunction with a new mobility 970 control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6], 971 hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA 972 [I-D.gundavelli-dmm-mfa] or in cunjunction with FPC 973 [I-D.ietf-dmm-fpc-cpdp]. The analysis of new mobility control-planes 974 and it's applicability to SRv6 is is out of the scope of this 975 document. 977 Note that the IANA section of this document allocates the SRv6 978 endpoint function types for the new functions defined in this 979 document. All control-plane protocols are expected to leverage these 980 function type-codes to signal each function. 982 It's notable that SRv6's network programming nature allows a flexible 983 and dynamic anchor placement. 985 10. Security Considerations 987 TBD 989 11. IANA Considerations 991 This I-D requests to IANA to allocate, within the "SRv6 Endpoint 992 Types" sub-registry belonging to the top-level "Segment-routing with 993 IPv6 dataplane (SRv6) Parameters" registry 994 [I-D.filsfils-spring-srv6-network-programming], the following 995 allocations: 997 +-------------+-----+-------------------+-----------+ 998 | Value/Range | Hex | Endpoint function | Reference | 999 +-------------+-----+-------------------+-----------+ 1000 | TBA | TBA | End.MAP | [This.ID] | 1001 | TBA | TBA | End.M.GTP6.D | [This.ID] | 1002 | TBA | TBA | End.M.GTP6.E | [This.ID] | 1003 | TBA | TBA | End.M.GTP4.E | [This.ID] | 1004 | TBA | TBA | End.Limit | [This.ID] | 1005 +-------------+-----+-------------------+-----------+ 1007 Table 1: SRv6 Mobile User-plane Endpoint Types 1009 12. Acknowledgements 1011 The authors would like to thank Daisuke Yokota, Bart Peirens, 1012 Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois 1013 Clad, Sridhar Bhaskaran and Arashmid Akhavain for their useful 1014 comments of this work. 1016 13. Contributors 1018 Kentaro Ebisawa 1019 Ponto Networks 1020 Japan 1022 Email: ebiken@pontonetworks.com 1024 14. References 1026 14.1. Normative References 1028 [I-D.filsfils-spring-segment-routing-policy] 1029 Filsfils, C., Sivabalan, S., Hegde, S., 1030 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 1031 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 1032 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 1033 J., Clad, F., and K. Raza, "Segment Routing Policy 1034 Architecture", draft-filsfils-spring-segment-routing- 1035 policy-06 (work in progress), May 2018. 1037 [I-D.filsfils-spring-srv6-network-programming] 1038 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 1039 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 1040 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 1041 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 1042 M. Sharif, "SRv6 Network Programming", draft-filsfils- 1043 spring-srv6-network-programming-04 (work in progress), 1044 March 2018. 1046 [I-D.ietf-6man-segment-routing-header] 1047 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 1048 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 1049 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 1050 progress), June 2018. 1052 [I-D.ietf-spring-segment-routing] 1053 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1054 Litkowski, S., and R. Shakir, "Segment Routing 1055 Architecture", draft-ietf-spring-segment-routing-15 (work 1056 in progress), January 2018. 1058 [I-D.xuclad-spring-sr-service-programming] 1059 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 1060 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 1061 S. Salsano, "Service Programming with Segment Routing", 1062 draft-xuclad-spring-sr-service-programming-00 (work in 1063 progress), July 2018. 1065 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1066 Requirement Levels", BCP 14, RFC 2119, 1067 DOI 10.17487/RFC2119, March 1997, 1068 . 1070 14.2. Informative References 1072 [I-D.auge-dmm-hicn-mobility-deployment-options] 1073 Auge, J., Carofiglio, G., Muscariello, L., and M. 1074 Papalini, "Anchorless mobility management through hICN 1075 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 1076 mobility-deployment-options-00 (work in progress), June 1077 2018. 1079 [I-D.camarillo-dmm-srv6-mobile-pocs] 1080 Camarillo Garvia, P., Filsfils, C., Bertz, L., Akhavain, 1081 A., Matsushima, S., and D. Voyer, "Segment Routing IPv6 1082 for mobile user-plane PoCs", draft-xuclad-spring-sr- 1083 service-programming-00 (work in progress), July 2018. 1085 [I-D.gundavelli-dmm-mfa] 1086 Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility- 1087 aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-00 1088 (work in progress), February 2018. 1090 [I-D.hegdeppsenak-isis-sr-flex-algo] 1091 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 1092 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 1093 isis-sr-flex-algo-02 (work in progress), February 2018. 1095 [I-D.ietf-dmm-fpc-cpdp] 1096 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 1097 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 1098 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 1099 (work in progress), June 2018. 1101 [I-D.ietf-spring-segment-routing-central-epe] 1102 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 1103 Afanasiev, "Segment Routing Centralized BGP Egress Peer 1104 Engineering", draft-ietf-spring-segment-routing-central- 1105 epe-10 (work in progress), December 2017. 1107 [I-D.rodrigueznatal-lisp-srv6] 1108 Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D., 1109 Camarillo, P., and C. Filsfils, "LISP Control Plane for 1110 SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00 1111 (work in progress), July 2018. 1113 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1114 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1115 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1116 . 1118 [TR.29891] 1119 3GPP, "5G System - Phase 1 CT WG4 Aspects", 3GPP TR 1120 29.891 15.0.0, December 2017. 1122 [TS.23501] 1123 3GPP, "System Architecture for the 5G System", 3GPP TS 1124 23.501 15.0.0, November 2017. 1126 [TS.29244] 1127 3GPP, "Interface between the Control Plane and the User 1128 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 1130 [TS.29281] 1131 3GPP, "General Packet Radio System (GPRS) Tunnelling 1132 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 1133 December 2017. 1135 Appendix A. Implementations 1137 This I-D introduces new SRv6 functions. These functions have an 1138 open-source P4 implementation available in 1139 . 1141 Additionally, there are ongoing PoC efforts in M-CORD NGIC and Open 1142 Air Interface (OAI). Progress and results can be found in 1143 [I-D.camarillo-dmm-srv6-mobile-pocs]. 1145 Authors' Addresses 1147 Satoru Matsushima 1148 SoftBank 1149 Tokyo 1150 Japan 1152 Email: satoru.matsushima@g.softbank.co.jp 1154 Clarence Filsfils 1155 Cisco Systems, Inc. 1156 Belgium 1158 Email: cf@cisco.com 1159 Miya Kohno 1160 Cisco Systems, Inc. 1161 Japan 1163 Email: mkohno@cisco.com 1165 Pablo Camarillo Garvia 1166 Cisco Systems, Inc. 1167 Spain 1169 Email: pcamaril@cisco.com 1171 Daniel Voyer 1172 Bell Canada 1173 Canada 1175 Email: daniel.voyer@bell.ca 1177 Charles E. Perkins 1178 Futurewei Inc. 1179 2330 Central Expressway 1180 Santa Clara, CA 95050 1181 USA 1183 Phone: +1-408-330-4586 1184 Email: charliep@computer.org