idnits 2.17.1 draft-kohno-dmm-srv6mob-arch-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 : ---------------------------------------------------------------------------- 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 (September 4, 2020) is 1330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N11' is mentioned on line 194, but not defined == Missing Reference: 'N2' is mentioned on line 195, but not defined == Missing Reference: 'N4' is mentioned on line 199, but not defined == Missing Reference: 'N3' is mentioned on line 202, but not defined == Missing Reference: 'N9' is mentioned on line 202, but not defined == Missing Reference: 'N6' is mentioned on line 202, but not defined == Unused Reference: 'I-D.filsfils-spring-srv6-network-programming' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'I-D.hegdeppsenak-isis-sr-flex-algo' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-srv6-interop' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'I-D.guichard-spring-srv6-simplified-firewall' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-fpc-cpdp' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 454, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-09 == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-02 == Outdated reference: A later version (-09) exists of draft-clt-dmm-tn-aware-mobility-06 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-stateless-slice-id-01 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-13 Summary: 0 errors (**), 0 flaws (~~), 21 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: March 8, 2021 Z. Ali 6 Cisco Systems, Inc. 7 September 4, 2020 9 Architecture Discussion on SRv6 Mobile User plane 10 draft-kohno-dmm-srv6mob-arch-02 12 Abstract 14 Layer separation is a powerful concept in system architecture. In 15 the area of mobility, by separating GTP-U that is the overlay tunnel, 16 and the IP transport network that is the underlay, the operation of 17 the mobile network and the transport network can be separated, 18 allowing them to evolve independently. 20 However, evolving individually at each layer promotes local 21 optimization and may result in non-optimal solutions overall in the 22 long run. 24 When a drastic architectural transition is required, for example, in 25 the 5G era where various SLAs and completely new data intensive 26 services are assumed, it is necessary to reconsider the architecture 27 holistically, not from the viewpoint of individual part. 29 One of important value propositions of SRv6 mobile user plane is to 30 create overlay with underlay optimization. 32 This document discusses the architecture implication of applying SRv6 33 mobile user plane. Then it takes 5G use cases as an example, and 34 describes how these use cases are simply and effectively realized. 35 Thus it shows that SRv6 mobile use plane is a right architectural 36 choice for 5G era. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on March 8, 2021. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Architecture Consideration and Necessity of Inter-layer 74 Optimization . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. SRv6 mobile user plane and the 5G use cases . . . . . . . . . 5 77 4.1. Network Slicing . . . . . . . . . . . . . . . . . . . . . 5 78 4.2. Edge Computing . . . . . . . . . . . . . . . . . . . . . 6 79 4.3. URLLC (Ultra-Reliable Low-Latency Communication) support 7 80 5. Incremental Deployment . . . . . . . . . . . . . . . . . . . 8 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 86 9.2. Informative References . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 Layer separation is a powerful concept in system architecture. In 92 the area of mobility, by separating GTP-U that is the overlay tunnel, 93 and the IP transport network that is the underlay, the operation of 94 the mobile network and the transport network can be separated, 95 allowing them to evolve independently. 97 However, evolving individually at each layer promotes local 98 optimization and may result in non-optimal solutions overall in the 99 long run. 101 The well-known aphorism of David J.Wheeler says: 103 "All problems in computer science can be solved by adding another 104 level of indirection." 106 But, as a corollary, it also says: "...that usually will create 107 another problem." In other words, excessive use of tunnels is not 108 good for an overall architecture. 110 Existing practices have reasonable grounds, so it is usually 111 recommended to follow them. But when a drastic architectural 112 transition is required, for example, in the 5G era where various SLAs 113 and completely new data intensive services are assumed, it is 114 necessary to reconsider the architecture holistically, rather than 115 from the viewpoint of individual part. 117 SRv6 mobile user plane has been proposed as an alternative way to 118 complement or replace GTP-U both in IETF 119 [I-D.ietf-dmm-srv6-mobile-uplane] and 3GPP [TR.29892]. In the 3GPP 120 CT4, the scope of the study was narrow (N9 only) and it was concluded 121 not to accept as a candidate protocol for the user plane in 5GC based 122 on Rel-16 stage 2 requirements. However, the future is still open 123 given the heterogeneous access evolution and stringent data 124 intensiveness. 126 SRv6 has also an advantage if it is used as a mobile user plane, 127 because of its flexibility through Service Programming functions and 128 the use of metadata, in addition to the simple and stateless traffic 129 steering capability. 131 The 3GPP data plane entities such as UPFs and service functions can 132 be implemented either as virtual or physical appliances. The fact 133 that SRv6 has been supported on various platforms including custom 134 ASICs, commercially available NPUs, programmable switches, Smart 135 NICs, Linux Kernel, virtual forwarders on server and container 136 networking, will make the deployment flexible. 138 Also, the declarative programming nature of SRv6 will provide the 139 necessary distinction to clarify basic reachability vs constraint 140 path vs service path, whereas existing practices depended on the 141 layer separation - service overlay and underlay. In other words, one 142 of the most important value propositions of SRv6 mobile user plane is 143 the possibility to perform cross-layer optimizations. 145 This document discusses the architecture implication of applying SRv6 146 mobile user plane. Then it takes 5G use cases as an example, and 147 describes how these use cases are simply and effectively realized. 148 Thus it shows that SRv6 mobile use plane is a right architectural 149 choice for 5G era. 151 2. Architecture Consideration and Necessity of Inter-layer Optimization 153 Historically, Mobile and Transport Network have been designed, 154 standardized and operated separately. GTP-U has been defined as the 155 mobile user plane. This is an overlay tunnel that runs over the 156 Transport Network. Therefore, the underlying network cannot be 157 directly controlled. 159 5G requires variety of SLA characteristics and flexible traffic 160 steering towards various service functions. How to map the transport 161 slice to mobile end-to-end slice has been being discussed in multiple 162 WGs in IETF [I-D.rokui-5g-transport-slice], 163 [I-D.clt-dmm-tn-aware-mobility]. 165 They are based on the current assumption that underlying network is 166 separated and agnostic. But it could be effective if the underlying 167 network can be more interactive. 169 The evolution of architecture requires a review of conventional 170 domain boundaries and practices. This way, inefficiencies caused by 171 traditional practices can be reduced. For example, now that "CUPS" 172 separated the Control Plane and User Plane, UPF, which is dedicated 173 to forwarding, can be considered as an entity on the IP Transport 174 Network. 176 And, as a matter of fact, layer reduction for efficiency has been 177 done in other domains. Some data centers adopted native IP CLOS, 178 avoiding using VXLAN for simplicity. Also broadband subscriber 179 managements were simplified by using IPoE instead of PPPoE / L2TP. 181 In the context of mobile operators, SRv6 provides end-to-end simpler 182 network operations thus decreasing the OPEX. SRv6 can also be 183 applied to the mobility overlay, in which case it also has benefits 184 as the tunnels are removed. 186 3. Terminology 188 The terminology used in this document leverages and conforms to 189 [I-D.ietf-dmm-srv6-mobile-uplane]. 191 +-----+ 192 | AMF | 193 +-----+ 194 / | [N11] 195 [N2] / +-----+ 196 +------/ | SMF | 197 / +-----+ 198 / / \ 199 / / \ [N4] 200 / / \ ________ 201 / / \ / \ 202 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 203 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 204 +--+ +-----+ TN +------+ TN +------+ \________/ 206 Figure 1: Reference Architecture 208 - UE : User Equipment 209 - gNB : gNodeB 210 - UPF : User Plane Function 211 - SMF : Session Management Function 212 - AMF : Access and Mobility Management Function 213 - 3GPP data plane entities : 3GPP entities responsible for data plane 214 forwarding, i.e. gNB and UPF 215 - TN : Transport Network - IP network where 3GPP data plane entities 216 connected 217 - DN : Data Network e.g. operator services, Internet access 218 - CUPS : Control Plane and User Plane Separation 219 - VNF : Virtual Network Function 220 - CNF : Cloud native Network Function 222 4. SRv6 mobile user plane and the 5G use cases 224 4.1. Network Slicing 226 SRv6 network programming realizes network slicing. How to build 227 network slicing using the Segment Routing based technology is 228 described in [I-D.ali-spring-network-slicing-building-blocks] 230 Also, the stateless slice identifier 231 [I-D.filsfils-spring-srv6-stateless-slice-id] has been proposed to 232 enable per-slice forwarding policy and bandwidth manipulation. 234 In the typical GTP-U over IP/MPLS/SR configuration, 3GPP data plane 235 entity such as UPF is a CE to the transport networks PE. This 236 results in the following facts: 238 - A certain Extra ID such as VLAN-ID is needed for segregating 239 traffic and mapping it onto a designated slice. 240 - PE and the PE-CE connection is a single point of failure, so some 241 form of PE redundancy (using routing protocols, MC-LAG, etc.) is 242 required, which makes systems inefficient and complex. 244 Another possibility would be that 3GPP user plane entities are 245 deployed as VNF/CNF in a DC. In this case, slice in the DC network 246 and other networks are to be inter-connected via DCI. 248 In either case, it would improve the scalability, QoS and efficiency, 249 if the user plane entities directly support SRv6. 251 4.2. Edge Computing 253 Edge computing, where the computing workload is placed closer to 254 users, is recognized as one of the key pillars to meet 5G's demanding 255 key performance indicators (KPIs), especially with regard to low 256 latency and bandwidth efficiency. The computing workload includes 257 network services, security, analytics, content cache and various 258 applications. (UPF can also be viewed as a distributed network 259 service function.) 261 Edge computing is more important than ever. This is because no 262 matter how much 5G improves access speeds, it won't improve end-to- 263 end throughput because it's largely bound to round trip delay. 265 However, the current MEC discussion [ETSI-MEC] focuses on how to 266 properly select the UPF of adequate proximity, and not on how to 267 interact with applications. 269 SRv6 has an advantage in enabling edge computing for the following 270 reasons. 272 - Programmable and Flexible Traffic Steering : SRv6's flexible 273 traffic steering capabilities and the network programming concept 274 is suitable for flexible placement of computing workload. 275 - Common data plane across domain : SRv6/IPv6 can be a common data 276 plane regardless of the domains such as access, WAN, mobile, cloud, 277 distributed data center, and computing workload. 278 - Stateless Service Chaining : It does not require any per-flow state 279 in network fabric. 280 - Interaction with Applications : SRv6 can carry meta data, which can 281 be used for interacting with applications. 282 - Functionality without performance degradation : Various information 283 can be exposed in IP header, but it does not degrade performance 284 thanks to the longest match mechanism in the IP routing. Only who 285 needs the information for granular processing are to lookup. 287 It is even more beneficial if service functions/applications directly 288 support SRv6. 290 4.3. URLLC (Ultra-Reliable Low-Latency Communication) support 292 3GPP [TR.23725] investigates the key issues for meeting the URLLC 293 requirements on latency, jitter and reliability in the 5G System. 294 The solutions provided in the document are focused at improving the 295 overlay protocol (GTP-U) and limits to provide a few hints into how 296 to map such tight-SLA into the transport network. These hints are 297 based on static configuration or static mapping for steering the 298 overlay packet into the right transport SLA. Such solutions do not 299 scale and hinder network economics. 301 Some of the issues can be solved more simply without GTP-U tunnel. 302 SRv6 mobile user plane can exposes session and QoS flow information 303 in IP header as discussed in the previous section. This would make 304 routing and forwarding path optimized for URLLC, much simpler than 305 the case with GTP-U tunnel. 307 Another issue that deserves special mention is the ultra-reliability 308 issue. In 3GPP, in order to support ultra-reliability, redundant 309 user planes paths based on dual connectivity has been proposed. The 310 proposal has two main options. 312 - Dual Connectivity based end-to-end Redundant User Plane Paths 313 - Support of redundant transmission on N3/N9 interfaces 315 In the case of the former, UE and hosts have RHF(Redundancy Handling 316 Function). In sending, RFH is to replicate the traffic onto two 317 GTP-U tunnels, and in receiving, RHF is to merge the traffic. 319 In the case of the latter, the 3GPP data plane entities are to 320 replicate and merge the packets with the same sequence for specific 321 QoS flow, which requires further enhancements. 323 SRv6 mobile user plane has some advantages for URLLC traffic. First, 324 it can be used to enforce a low-latency path in the network by means 325 of scalable Traffic Engineering. Additionally, SRv6 provides an 326 automated reliability protection mechanism known as TI-LFA, which is 327 a sub-50ms FRR mechanism that provides protection regardless of the 328 topology through the optimal backup path. It can be provisioned 329 slice-aware. 331 With the case that dual live-live path is required, the problem is 332 not only the complexity but that the replication point and the 333 merging point would be the single point of failure. The SRv6 mobile 334 user plane also has an advantage in this respect, because any 335 endpoints or 3GPP data plane nodes themselves can be the replication/ 336 merging point when they are SRv6 aware. 338 5. Incremental Deployment 340 Incremental deployment should be considered. In the case of hcin 341 mobility [I-D.auge-dmm-hicn-mobility-deployment-options], the 342 insertion with no modification to the existing 3GPP architecture is 343 considered first, and then the tighter integration of data plane is 344 to be achieved. The same shall apply in the case of SRv6 mobile user 345 plane. 347 6. Security Considerations 349 TBD 351 7. IANA Considerations 353 NA 355 8. Acknowledgements 357 Authors would like to thank Satoru Matsushima and Shunsuke Homma for 358 their insights and comments. 360 9. References 362 9.1. Normative References 364 [I-D.filsfils-spring-srv6-network-programming] 365 Filsfils, C., Camarillo, P., Leddy, J., 366 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 367 Network Programming", draft-filsfils-spring-srv6-network- 368 programming-07 (work in progress), February 2019. 370 [I-D.hegdeppsenak-isis-sr-flex-algo] 371 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 372 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 373 isis-sr-flex-algo-02 (work in progress), February 2018. 375 [I-D.ietf-dmm-srv6-mobile-uplane] 376 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 377 Voyer, D., and C. Perkins, "Segment Routing IPv6 for 378 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-09 379 (work in progress), July 2020. 381 [I-D.ietf-spring-segment-routing] 382 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 383 Litkowski, S., and R. Shakir, "Segment Routing 384 Architecture", draft-ietf-spring-segment-routing-15 (work 385 in progress), January 2018. 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, 389 DOI 10.17487/RFC2119, March 1997, 390 . 392 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 393 Decraene, B., Litkowski, S., and R. Shakir, "Segment 394 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 395 July 2018, . 397 9.2. Informative References 399 [ETSI-MEC] 400 ETSI, "MEC in 5G Networks", ETSI White Paper No.28, June 401 2018. 403 [I-D.ali-spring-network-slicing-building-blocks] 404 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 405 "Building blocks for Slicing in Segment Routing Network", 406 draft-ali-spring-network-slicing-building-blocks-02 (work 407 in progress), November 2019. 409 [I-D.auge-dmm-hicn-mobility-deployment-options] 410 Auge, J., Carofiglio, G., Muscariello, L., and M. 411 Papalini, "Anchorless mobility management through hICN 412 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 413 mobility-deployment-options-04 (work in progress), July 414 2020. 416 [I-D.clt-dmm-tn-aware-mobility] 417 Chunduri, U., Li, R., Bhaskaran, S., Kaippallimalil, J., 418 Tantsura, J., Contreras, L., and P. Muley, "Transport 419 Network aware Mobility for 5G", draft-clt-dmm-tn-aware- 420 mobility-06 (work in progress), March 2020. 422 [I-D.filsfils-spring-srv6-interop] 423 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 424 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 425 "SRv6 interoperability report", draft-filsfils-spring- 426 srv6-interop-02 (work in progress), March 2019. 428 [I-D.filsfils-spring-srv6-stateless-slice-id] 429 Filsfils, C., Clad, F., Camarillo, P., and K. Raza, 430 "Stateless and Scalable Network Slice Identification for 431 SRv6", draft-filsfils-spring-srv6-stateless-slice-id-01 432 (work in progress), July 2020. 434 [I-D.guichard-spring-srv6-simplified-firewall] 435 Guichard, J., Filsfils, C., daniel.bernier@bell.ca, d., 436 Li, Z., Clad, F., Camarillo, P., and A. Abdelsalam, 437 "Simplifying Firewall Rules with Network Programming and 438 SRH Metadata", draft-guichard-spring-srv6-simplified- 439 firewall-02 (work in progress), April 2020. 441 [I-D.ietf-dmm-fpc-cpdp] 442 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 443 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 444 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-13 445 (work in progress), March 2020. 447 [I-D.rokui-5g-transport-slice] 448 Rokui, R., Homma, S., Lopez, D., Foy, X., Contreras, L., 449 Ordonez-Lucena, J., Martinez-Julia, P., Boucadair, M., 450 Eardley, P., Makhijani, K., and H. Flinck, "5G Transport 451 Slice Connectivity Interface", draft-rokui-5g-transport- 452 slice-00 (work in progress), July 2019. 454 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 455 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 456 RFC 5213, DOI 10.17487/RFC5213, August 2008, 457 . 459 [TR.23725] 460 3GPP, "Study on enhancement of Ultra-Reliable Low-Latency 461 Communication (URLLC) support in the 5G Core network 462 (5GC)", 3GPP TR 23.725 16.2.0, June 2019. 464 [TR.29892] 465 3GPP, "Study on User Plane Protocol in 5GC", 3GPP TR 466 29.892 16.1.0, April 2019. 468 [TS.23501] 469 3GPP, "System Architecture for the 5G System", 3GPP TS 470 23.501 15.0.0, November 2017. 472 [TS.29244] 473 3GPP, "Interface between the Control Plane and the User 474 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 476 [TS.29281] 477 3GPP, "General Packet Radio System (GPRS) Tunnelling 478 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 479 December 2017. 481 Authors' Addresses 483 Miya Kohno 484 Cisco Systems, Inc. 485 Japan 487 Email: mkohno@cisco.com 489 Francois Clad 490 Cisco Systems, Inc. 491 France 493 Email: fclad@cisco.com 495 Pablo Camarillo Garvia 496 Cisco Systems, Inc. 497 Spain 499 Email: pcamaril@cisco.com 501 Zafar Ali 502 Cisco Systems, Inc. 503 Canada 505 Email: zali@cisco.com