idnits 2.17.1 draft-kohno-dmm-srv6mob-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 8, 2020) is 1481 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 354, but no explicit reference was found in the text == Unused Reference: 'I-D.hegdeppsenak-isis-sr-flex-algo' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-srv6-interop' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-fpc-cpdp' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 440, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-07 == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-02 == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-deployment-options-03 == Outdated reference: A later version (-09) exists of draft-clt-dmm-tn-aware-mobility-05 == Outdated reference: A later version (-09) exists of draft-filsfils-spring-srv6-stateless-slice-id-00 == Outdated reference: A later version (-02) exists of draft-guichard-spring-srv6-simplified-firewall-01 == Outdated reference: A later version (-14) exists of draft-ietf-dmm-fpc-cpdp-12 Summary: 0 errors (**), 0 flaws (~~), 22 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: September 9, 2020 Z. Ali 6 Cisco Systems, Inc. 7 March 8, 2020 9 Architecture Discussion on SRv6 Mobile User plane 10 draft-kohno-dmm-srv6mob-arch-01 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 September 9, 2020. 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 6 80 5. Incremental Deployment . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 10 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 SRv6's flexible traffic steering capabilities and the Network 262 Programming concept of freely describing Instructions and meta data 263 are per se suitable for providing Edge Computing. 265 In addition, since SRv6 can be a common data plane regardless of the 266 domains such as access, WAN, mobility and data center, Service 267 Placement and Service Chain that used to be concentrated in Data 268 Center can be expanded over a wide area. 270 Furthermore, with SRv6, session and QoS information can be exposed in 271 IP header. It does not affect performance, thanks to the longest 272 match mechanism in the IP routing. Only the services/applications 273 who need the information for granular processing are to lookup. This 274 also allows services/applications to be placed in between N9 paths if 275 needed. 277 The draft implementation of Firewall using SRv6 meta data is 278 discussed in [I-D.guichard-spring-srv6-simplified-firewall] 280 4.3. URLLC (Ultra-Reliable Low-Latency Communication) support 282 3GPP [TR.23725] investigates the key issues for meeting the URLLC 283 requirements on latency, jitter and reliability in the 5G System. 284 The solutions provided in the document are focused at improving the 285 overlay protocol (GTP-U) and limits to provide a few hints into how 286 to map such tight-SLA into the transport network. These hints are 287 based on static configuration or static mapping for steering the 288 overlay packet into the right transport SLA. Such solutions do not 289 scale and hinder network economics. 291 Some of the issues can be solved more simply without GTP-U tunnel. 292 SRv6 mobile user plane can exposes session and QoS flow information 293 in IP header as discussed in the previous section. This would make 294 routing and forwarding path optimized for URLLC, much simpler than 295 the case with GTP-U tunnel. 297 Another issue that deserves special mention is the ultra-reliability 298 issue. In 3GPP, in order to support ultra-reliability, redundant 299 user planes paths based on dual connectivity has been proposed. The 300 proposal has two main options. 302 - Dual Connectivity based end-to-end Redundant User Plane Paths 303 - Support of redundant transmission on N3/N9 interfaces 305 In the case of the former, UE and hosts have RHF(Redundancy Handling 306 Function). In sending, RFH is to replicate the traffic onto two 307 GTP-U tunnels, and in receiving, RHF is to merge the traffic. 309 In the case of the latter, the 3GPP data plane entities are to 310 replicate and merge the packets with the same sequence for specific 311 QoS flow, which requires further enhancements. 313 SRv6 mobile user plane has some advantages for URLLC traffic. First, 314 it can be used to enforce a low-latency path in the network by means 315 of scalable Traffic Engineering. Additionally, SRv6 provides an 316 automated reliability protection mechanism known as TI-LFA, which is 317 a sub-50ms FRR mechanism that provides protection regardless of the 318 topology through the optimal backup path. It can be provisioned 319 slice-aware. 321 With the case that dual live-live path is required, the problem is 322 not only the complexity but that the replication point and the 323 merging point would be the single point of failure. The SRv6 mobile 324 user plane also has an advantage in this respect, because any 325 endpoints or 3GPP data plane nodes themselves can be the replication/ 326 merging point when they are SRv6 aware. 328 5. Incremental Deployment 330 Incremental deployment should be considered. In the case of hcin 331 mobility [I-D.auge-dmm-hicn-mobility-deployment-options], the 332 insertion with no modification to the existing 3GPP architecture is 333 considered first, and then the tighter integration of data plane is 334 to be achieved. The same shall apply in the case of SRv6 mobile user 335 plane. 337 6. Security Considerations 339 TBD 341 7. IANA Considerations 343 NA 345 8. Acknowledgements 347 Authors would like to thank Satoru Matsushima and Shunsuke Homma for 348 their insights and comments. 350 9. References 352 9.1. Normative References 354 [I-D.filsfils-spring-srv6-network-programming] 355 Filsfils, C., Camarillo, P., Leddy, J., 356 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 357 Network Programming", draft-filsfils-spring-srv6-network- 358 programming-07 (work in progress), February 2019. 360 [I-D.hegdeppsenak-isis-sr-flex-algo] 361 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 362 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 363 isis-sr-flex-algo-02 (work in progress), February 2018. 365 [I-D.ietf-dmm-srv6-mobile-uplane] 366 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 367 Voyer, D., and C. Perkins, "Segment Routing IPv6 for 368 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-07 369 (work in progress), November 2019. 371 [I-D.ietf-spring-segment-routing] 372 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 373 Litkowski, S., and R. Shakir, "Segment Routing 374 Architecture", draft-ietf-spring-segment-routing-15 (work 375 in progress), January 2018. 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, 379 DOI 10.17487/RFC2119, March 1997, 380 . 382 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 383 Decraene, B., Litkowski, S., and R. Shakir, "Segment 384 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 385 July 2018, . 387 9.2. Informative References 389 [I-D.ali-spring-network-slicing-building-blocks] 390 Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, 391 "Building blocks for Slicing in Segment Routing Network", 392 draft-ali-spring-network-slicing-building-blocks-02 (work 393 in progress), November 2019. 395 [I-D.auge-dmm-hicn-mobility-deployment-options] 396 Auge, J., Carofiglio, G., Muscariello, L., and M. 397 Papalini, "Anchorless mobility management through hICN 398 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 399 mobility-deployment-options-03 (work in progress), January 400 2020. 402 [I-D.clt-dmm-tn-aware-mobility] 403 Chunduri, U., Li, R., Bhaskaran, S., Kaippallimalil, J., 404 Tantsura, J., Contreras, L., and P. Muley, "Transport 405 Network aware Mobility for 5G", draft-clt-dmm-tn-aware- 406 mobility-05 (work in progress), November 2019. 408 [I-D.filsfils-spring-srv6-interop] 409 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 410 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 411 "SRv6 interoperability report", draft-filsfils-spring- 412 srv6-interop-02 (work in progress), March 2019. 414 [I-D.filsfils-spring-srv6-stateless-slice-id] 415 Filsfils, C., Clad, F., Camarillo, P., and K. Raza, 416 "Stateless and Scalable Network Slice Identification for 417 SRv6", draft-filsfils-spring-srv6-stateless-slice-id-00 418 (work in progress), January 2020. 420 [I-D.guichard-spring-srv6-simplified-firewall] 421 Guichard, J., Filsfils, C., daniel.bernier@bell.ca, d., 422 Li, Z., Clad, F., Camarillo, P., and A. Abdelsalam, 423 "Simplifying Firewall Rules with Network Programming and 424 SRH Metadata", draft-guichard-spring-srv6-simplified- 425 firewall-01 (work in progress), September 2019. 427 [I-D.ietf-dmm-fpc-cpdp] 428 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 429 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 430 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 431 (work in progress), June 2018. 433 [I-D.rokui-5g-transport-slice] 434 Rokui, R., Homma, S., Lopez, D., Foy, X., Contreras, L., 435 Ordonez-Lucena, J., Martinez-Julia, P., Boucadair, M., 436 Eardley, P., Makhijani, K., and H. Flinck, "5G Transport 437 Slice Connectivity Interface", draft-rokui-5g-transport- 438 slice-00 (work in progress), July 2019. 440 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 441 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 442 RFC 5213, DOI 10.17487/RFC5213, August 2008, 443 . 445 [TR.23725] 446 3GPP, "Study on enhancement of Ultra-Reliable Low-Latency 447 Communication (URLLC) support in the 5G Core network 448 (5GC)", 3GPP TR 23.725 16.2.0, June 2019. 450 [TR.29892] 451 3GPP, "Study on User Plane Protocol in 5GC", 3GPP TR 452 29.892 16.1.0, April 2019. 454 [TS.23501] 455 3GPP, "System Architecture for the 5G System", 3GPP TS 456 23.501 15.0.0, November 2017. 458 [TS.29244] 459 3GPP, "Interface between the Control Plane and the User 460 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 462 [TS.29281] 463 3GPP, "General Packet Radio System (GPRS) Tunnelling 464 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 465 December 2017. 467 Authors' Addresses 469 Miya Kohno 470 Cisco Systems, Inc. 471 Japan 473 Email: mkohno@cisco.com 474 Francois Clad 475 Cisco Systems, Inc. 476 France 478 Email: fclad@cisco.com 480 Pablo Camarillo Garvia 481 Cisco Systems, Inc. 482 Spain 484 Email: pcamaril@cisco.com 486 Zafar Ali 487 Cisco Systems, Inc. 488 Canada 490 Email: zali@cisco.com