idnits 2.17.1 draft-kohno-dmm-srv6mob-arch-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 8, 2021) is 900 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.hegdeppsenak-isis-sr-flex-algo' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'I-D.auge-dmm-hicn-mobility-deployment-options' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 421, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-17 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-stateless-slice-id-04 == Outdated reference: A later version (-06) exists of draft-mhkk-dmm-srv6mup-architecture-00 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group M. Kohno 3 Internet-Draft F. Clad 4 Intended status: Informational P. Camarillo 5 Expires: May 12, 2022 Z. Ali 6 Cisco Systems, Inc. 7 November 8, 2021 9 Architecture Discussion on SRv6 Mobile User plane 10 draft-kohno-dmm-srv6mob-arch-05 12 Abstract 14 SRv6 mobile user plane is standardized in IETF. It accomplishes the 15 mobile user-plane functions in a simple, flexible and scalable 16 manner, by utilizing the network programming nature of SRv6. It 17 leverages common native IPv6 data plane and creates interoperable 18 overlays with underlay optimization. 20 This document discusses the solution approach and its architectural 21 benefits of common data plane across domains and across overlay/ 22 underlay. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 12, 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Problem Definition . . . . . . . . . . . . . . . . . . . . . 3 60 3. Common data plane across domains and across overlay/underlay 3 61 4. Control Plane Considerations . . . . . . . . . . . . . . . . 4 62 5. Incremental Deployability . . . . . . . . . . . . . . . . . . 4 63 6. SRv6 mobile user plane and the 5G use cases . . . . . . . . . 5 64 6.1. Network Slicing . . . . . . . . . . . . . . . . . . . . . 5 65 6.2. Edge Computing . . . . . . . . . . . . . . . . . . . . . 5 66 6.3. URLLC (Ultra-Reliable Low-Latency Communication) support 6 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 Mobile architectures have evolved individually, and the user plane, 78 GTP-U, has been defined as an overlay tunnel that is agnostic to the 79 IP infrastructure. 81 However, the system requirements are changing as digitalization goes 82 into full swing. The continued use of GTP-U as a user plane protocol 83 will lock-in to the existing architectural structure and hinder the 84 innovation. GTP-U will not be able to meet the diverse SLA 85 requirements of the 5G era and beyond with efficiency and 86 scalability. Also it will not be able to meet the demands of new 87 mobile-first data intensive applications, which will be more 88 dynamically distributed. 90 SRv6 mobile user plane [I-D.ietf-dmm-srv6-mobile-uplane] is 91 standardized in IETF. It accomplishes the mobile user-plane 92 functions in a simple, flexible and scalable manner, by utilizing the 93 network programming nature of SRv6. It leverages common native IPv6 94 data plane and creates interoperable overlays with underlay 95 optimization. 97 This document discusses the solution approach and its architectural 98 benefits of common data plane across domains (e.g., mobile domain, IP 99 infrastructure, data center, applications) and across overlay/ 100 underlay. 102 2. Problem Definition 104 The current mobile user plane, GTP-U, defined as an overlay tunnel 105 that is agnostic to the IP infrastructure, has the following 106 limitations that prevent it from supporting new application demands. 108 o Non-optimal for any-to-any communication 109 o No control of the underlay path 110 o Non-optimal for edge/distributed computing 111 o Non-optimal for fixed and mobile path convergence 112 o Lack a way for application/service developers to manipulate and 113 interact 115 In addition, the centralized tunnel terminating gateway becomes a 116 scaling bottleneck and a single point of failure 118 For residential broadband IP and data center networking, tunnel 119 sessions could be eliminated (e.g. PPPoE -> IPoE, VXLAN/NSH -> 120 SRv6). This indicates that a tunnel session is not necessarily 121 absolute. But such a thing was unlikely to happen in the mobile 122 domain. 124 As for FMC, there is currently a coordinated standardization effort 125 between 3GPP WWC [TS.23316] and BBF [BBF407]. However, the idea is 126 to anchor even wireline traffic in the mobile packet core, which 127 compromises simplicity and scalability. 129 3. Common data plane across domains and across overlay/underlay 131 [I-D.ietf-dmm-srv6-mobile-uplane] defines SRv6 mobile user plane as 132 an alternative or co-existing solution to GTP-U. 134 Since SRv6 is a native IPv6 data plane, it can be a common data plane 135 regardless of the domain. 137 SRv6 Network Programming [RFC8986] enables the creation of overlays 138 with underlay optimization. In addition, SRv6 can be operated by 139 application developers because of its implementation in the computing 140 stack, e.g. VPP, Linux Kernel, smart NIC, and cloud native platform 141 such as Network Service Mesh. 143 Data plane commonality offers significant advantage regarding 144 function, scaling, and cost. In particular, the benefits of the 5G 145 era are shown in Section 6. 147 Note that the interaction with underlay infrastructure is not a 148 mandatory in the data plane commonality. It just gives a design 149 choice to interact with the underlay and optimize it, and it is 150 totally fine to keep ovelray underlay-agnostic, which will allow the 151 coexistence of different capability of nodes. 153 4. Control Plane Considerations 155 This document focuses on the commonalization of data plane, and the 156 control plane is out of scope. The actual system characteristics 157 such as scaling and functionality depend heavily on the control 158 plane, though. 160 The potential of the SRv6 mobile user plane is huge, in the sense 161 that it can realize various functions of mobile management using SRv6 162 Network Programming. Protocols such as GTP-C, PMIPv6, BGP, LISP, 163 ILNP, hICN, or even others can be applied as a control plane to 164 control mobility. 166 For example, if hICN [I-D.auge-dmm-hicn-mobility] was used, 167 anchorless mobility can be realised. 169 5. Incremental Deployability 171 The mobile domain is a compound domain that includes Radio Access, 172 and it is difficult to implement a completely new architecture, and 173 incremental deployability is required. 175 [I-D.ietf-dmm-srv6-mobile-uplane] defines the conversion between 176 GTP-U and SRv6, so that it can co-exist with the current mobile 177 architecture as needed. Since the conversion is done statelessly 178 (i.e., all necessary information is retained in the packet), there 179 will not be a scaling bottleneck or a single point of failure. 181 Further, [I-D.mhkk-dmm-srv6mup-architecture] defines the SRv6 MUP 182 architecture for Distributed Mobility Management, which can be 183 plugged to the existing mobile service architecture. 185 In this way, SRv6 Network Programmability allows for proper 186 deployability. 188 6. SRv6 mobile user plane and the 5G use cases 190 This section describes the advantages of the common data plane and of 191 applying SRv6 mobile user plane for 5G use cases. 193 6.1. Network Slicing 195 Network slicing enables network segmentation, isolation, and SLA 196 differentiation in terms of latency and availability. End-to-end 197 slicing will be achieved by mapping and coordinating IP network 198 slicing, RAN and mobile packet core slicing. 200 However, as pointed out in [I-D.clt-dmm-tn-aware-mobility], the 5G 201 System as defined, does not have underlying IP network awareness, 202 which could lead to the inability in meeting SLAs. 204 Segment Routing has a comprehensive set of slice engineering 205 technologies. How to build network slicing using the Segment Routing 206 based technology is described in 207 [I-D.ali-spring-network-slicing-building-blocks]. 209 In the typical GTP-U over IP/MPLS/SR configuration, 3GPP data plane 210 entity such as UPF is a CE to the transport networks PE. But if 3GPP 211 they support SRv6 mobile user plane, they can directly participate in 212 network slicing, and solves the following issues. 214 o A certain Extra ID such as VLAN-ID is needed for segregating 215 traffic and mapping it onto a designated slice. 216 o PE and the PE-CE connection is a single point of failure, so some 217 form of PE redundancy (using routing protocols, MC-LAG, etc.) is 218 required. 220 Moreover, the stateless slice identifier encoding 221 [I-D.filsfils-spring-srv6-stateless-slice-id] can be applicable to 222 enable per-slice forwarding policy using the IPv6 header. 224 6.2. Edge Computing 226 Edge computing, where the computing workloads and datastores are 227 placed closer to users, is recognized as one of the key pillars to 228 meet 5G's demanding requirements, with regard to low latency, 229 bandwidth efficiency, and data privacy. The computing workload 230 includes network services, security, data analytics, content cache 231 and various applications. (UPF itself can also be viewed as a 232 distributed network service function.) 234 Edge computing is more important than ever. This is because no 235 matter how much 5G improves access speeds, it won't improve end-to- 236 end throughput because it's largely bound to round trip delay. It is 237 also important from the viewpoint of "local production for local 238 consumption" and privacy protection. 240 However, the current MEC discussion [ETSI-MEC] focuses on how to 241 properly select the UPF of adequate proximity, and not on how to 242 interact with applications. 244 SRv6 has an advantage in enabling edge computing for the following 245 reasons. 247 o Programmable and Flexible Traffic Steering : SRv6's flexible 248 traffic steering capabilities and the network programming concept 249 is suitable for flexible placement of computing workload. 250 o Common data plane across domains : SRv6/IPv6 can be a common data 251 plane regardless of the domains such as mobile including UE, IP 252 transport, data center, applications. 253 o Stateless Service Chaining : It does not require any per-flow 254 state in network fabric. 255 o Interaction with Applications : SRv6 can be implemented in the 256 compute stack and can be manipulated by applications using socket 257 API. Also, SRv6 can carry meta data, which can be used for 258 interacting with applications. 259 o Functionality without performance degradation : Various 260 information can be exposed in IP header, but it does not degrade 261 performance thanks to the longest match mechanism in the IP 262 routing. Only who needs the information for granular processing 263 are to lookup. 265 It is even more beneficial if service functions/applications directly 266 support SRv6. 268 6.3. URLLC (Ultra-Reliable Low-Latency Communication) support 270 3GPP [TR.23725] investigates the key issues for meeting the URLLC 271 requirements on latency, jitter and reliability in the 5G System. 272 The solutions provided in the document are focused at improving the 273 overlay protocol (GTP-U) and limits to provide a few hints into how 274 to map such tight-SLA into the transport network. These hints are 275 based on static configuration or static mapping for steering the 276 overlay packet into the right transport SLA. Such solutions do not 277 scale and hinder network economics. 279 Some of the issues can be solved more simply without GTP-U tunnel. 280 SRv6 mobile user plane can exposes session and QoS flow information 281 in IP header as discussed in the previous section. This would make 282 routing and forwarding path optimized for URLLC, much simpler than 283 the case with GTP-U tunnel. 285 Another issue that deserves special mention is the ultra-reliability 286 issue. In 3GPP, in order to support ultra-reliability, redundant 287 user planes paths based on dual connectivity has been proposed. The 288 proposal has two main options. 290 o Dual Connectivity based end-to-end Redundant User Plane Paths 291 o Support of redundant transmission on N3/N9 interfaces 293 In the case of the former, UE and hosts have RHF(Redundancy Handling 294 Function). In sending, RFH is to replicate the traffic onto two 295 GTP-U tunnels, and in receiving, RHF is to merge the traffic. 297 In the case of the latter, the 3GPP data plane entities are to 298 replicate and merge the packets with the same sequence for specific 299 QoS flow, which requires further enhancements. 301 And in either cases, the bigger problem is the lack of a reliable way 302 for the redundant sessions to get through the disjoint path: even 303 with the redundant sessions, if it ends up using the same 304 infrastructure at some points, the redundancy is meaningless. 306 SRv6 mobile user plane has some advantages for URLLC traffic. First, 307 with SRv6, Traffic can be mapped to a disjoint path or low latency 308 path as needed, by means of the scalable Traffic Engineering. 310 Additionally, SRv6 provides an automated reliability protection 311 mechanism known as TI-LFA, which is a sub-50ms FRR mechanism that 312 provides protection regardless of the topology through the optimal 313 backup path. It can be provisioned slice-aware. 315 With the case that dual live-live path is required, the problem is 316 not only the complexity but that the replication point and the 317 merging point would be the single point of failure. The SRv6 mobile 318 user plane also has an advantage in this respect, because any 319 endpoints or 3GPP data plane nodes themselves can be the replication/ 320 merging point when they are SRv6 aware. 322 Furthermore, SRv6 supports inband telemetry/time stamping for latency 323 monitoring and control. 325 7. Security Considerations 327 TBD 329 8. IANA Considerations 331 NA 333 9. Acknowledgements 335 Authors would like to thank Satoru Matsushima, Shunsuke Homma,Yuji 336 Tochio and Jeffrey Zhang, for their insights and comments. 338 10. References 340 10.1. Normative References 342 [I-D.hegdeppsenak-isis-sr-flex-algo] 343 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 344 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 345 isis-sr-flex-algo-02 (work in progress), February 2018. 347 [I-D.ietf-dmm-srv6-mobile-uplane] 348 Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., 349 Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for 350 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-17 351 (work in progress), October 2021. 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 359 Decraene, B., Litkowski, S., and R. Shakir, "Segment 360 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 361 July 2018, . 363 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 364 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 365 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 366 . 368 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 369 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 370 (SRv6) Network Programming", RFC 8986, 371 DOI 10.17487/RFC8986, February 2021, 372 . 374 10.2. Informative References 376 [BBF407] BBF, "5G Wireless Wireline Convergence Architecture", BBF 377 TR-407 Issue:1, August 2020. 379 [ETSI-MEC] 380 ETSI, "MEC in 5G Networks", ETSI White Paper No.28, June 381 2018. 383 [I-D.ali-spring-network-slicing-building-blocks] 384 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 385 "Building blocks for Slicing in Segment Routing Network", 386 draft-ali-spring-network-slicing-building-blocks-04 (work 387 in progress), February 2021. 389 [I-D.auge-dmm-hicn-mobility] 390 Auge, J., Carofiglio, G., Muscariello, L., and M. 391 Papalini, "Anchorless mobility through hICN", draft-auge- 392 dmm-hicn-mobility-04 (work in progress), July 2020. 394 [I-D.auge-dmm-hicn-mobility-deployment-options] 395 Auge, J., Carofiglio, G., Muscariello, L., and M. 396 Papalini, "Anchorless mobility management through hICN 397 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 398 mobility-deployment-options-04 (work in progress), July 399 2020. 401 [I-D.clt-dmm-tn-aware-mobility] 402 Chunduri, U., Li, R., Bhaskaran, S., Kaippallimalil, J., 403 Tantsura, J., Contreras, L. M., and P. Muley, "Transport 404 Network aware Mobility for 5G", draft-clt-dmm-tn-aware- 405 mobility-09 (work in progress), February 2021. 407 [I-D.filsfils-spring-srv6-stateless-slice-id] 408 Filsfils, C., Clad, F., Camarillo, P., Raza, K., Voyer, 409 D., and R. Rokui, "Stateless and Scalable Network Slice 410 Identification for SRv6", draft-filsfils-spring-srv6- 411 stateless-slice-id-04 (work in progress), July 2021. 413 [I-D.mhkk-dmm-srv6mup-architecture] 414 Matsushima, S., Horiba, K., Khan, A., Kawakami, Y., 415 Murakami, T., Patel, K., Kohno, M., Kamata, T., and P. 416 Camarillo, "Segment Routing IPv6 Mobile User Plane 417 Architecture for Distributed Mobility Management", draft- 418 mhkk-dmm-srv6mup-architecture-00 (work in progress), 419 October 2021. 421 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 422 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 423 RFC 5213, DOI 10.17487/RFC5213, August 2008, 424 . 426 [TR.23725] 427 3GPP, "Study on enhancement of Ultra-Reliable Low-Latency 428 Communication (URLLC) support in the 5G Core network 429 (5GC)", 3GPP TR 23.725 16.2.0, June 2019. 431 [TR.29892] 432 3GPP, "Study on User Plane Protocol in 5GC", 3GPP TR 433 29.892 16.1.0, April 2019. 435 [TS.23316] 436 3GPP, "Wireless and wireline convergence access support 437 for the 5G System (5GS)", 3GPP TS 23.316 16.7.0, September 438 2021. 440 [TS.23501] 441 3GPP, "System Architecture for the 5G System", 3GPP TS 442 23.501 15.0.0, November 2017. 444 [TS.29244] 445 3GPP, "Interface between the Control Plane and the User 446 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 448 [TS.29281] 449 3GPP, "General Packet Radio System (GPRS) Tunnelling 450 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 451 December 2017. 453 Authors' Addresses 455 Miya Kohno 456 Cisco Systems, Inc. 457 Japan 459 Email: mkohno@cisco.com 461 Francois Clad 462 Cisco Systems, Inc. 463 France 465 Email: fclad@cisco.com 466 Pablo Camarillo Garvia 467 Cisco Systems, Inc. 468 Spain 470 Email: pcamaril@cisco.com 472 Zafar Ali 473 Cisco Systems, Inc. 474 Canada 476 Email: zali@cisco.com