idnits 2.17.1 draft-kohno-dmm-srv6mob-arch-00.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 1, 2019) is 1636 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'N11' is mentioned on line 198, but not defined == Missing Reference: 'N2' is mentioned on line 199, but not defined == Missing Reference: 'N4' is mentioned on line 203, but not defined == Missing Reference: 'N3' is mentioned on line 206, but not defined == Missing Reference: 'N9' is mentioned on line 206, but not defined == Missing Reference: 'N6' is mentioned on line 206, but not defined == Unused Reference: 'I-D.hegdeppsenak-isis-sr-flex-algo' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-srv6-interop' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-fpc-cpdp' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC5213' is defined on line 431, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-05 == Outdated reference: A later version (-04) exists of draft-ali-spring-network-slicing-building-blocks-01 == Outdated reference: A later version (-09) exists of draft-clt-dmm-tn-aware-mobility-04 == 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 (~~), 20 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 4, 2020 Z. Ali 6 Cisco Systems, Inc. 7 November 1, 2019 9 Architecture Discussion on SRv6 Mobile User plane 10 draft-kohno-dmm-srv6mob-arch-00 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, rather than from the viewpoint of individual layer. 29 One important value propositions of SRv6 mobile user plane is the 30 possible optimization across the existing multiple layers. 32 This document discusses the architectural implications of applying 33 SRv6 mobile user plane, especially regarding the possible 34 optimization of existing layers. Then it takes 5G requirements and 35 use cases as an example, and describes how these use cases are simply 36 and effectively realized with the inter-layer optimization capability 37 of SRv6 mobile user plane. Thus it show that SRv6 mobile use plane 38 is a right architectural choice for the 5G era. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 4, 2020. 57 Copyright Notice 59 Copyright (c) 2019 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Architecture Consideration and Necessity of Inter-layer 76 Optimization . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. SRv6 mobile user plane and the 5G use cases . . . . . . . . . 5 79 4.1. Network Slicing . . . . . . . . . . . . . . . . . . . . . 5 80 4.2. Edge Computing . . . . . . . . . . . . . . . . . . . . . 6 81 4.3. URLLC (Ultra-Reliable Low-Latency Communication) support 7 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 8.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 Layer separation is a powerful concept in system architecture. In 93 the area of mobility, by separating GTP-U that is the overlay tunnel, 94 and the IP transport network that is the underlay, the operation of 95 the mobile network and the transport network can be separated, 96 allowing them to evolve independently. 98 However, evolving individually at each layer promotes local 99 optimization and may result in non-optimal solutions overall in the 100 long run. 102 The well-known aphorism of David J.Wheeler says: 104 "All problems in computer science can be solved by adding another 105 level of indirection." 107 But, as a corollary, it also says: 109 "...that usually will create another problem." 111 In other words, excessive layer separation is not good for an overall 112 architecture. 114 Existing practices have reasonable grounds, so it is usually 115 recommended to follow them. But when a drastic architectural 116 transition is required, for example, in the 5G era where various SLAs 117 and completely new data intensive services are assumed, it is 118 necessary to reconsider the architecture holistically, rather than 119 from the viewpoint of individual layer. 121 SRv6 mobile user plane has been proposed as an alternative way to 122 complement or replace GTP-U both in IETF 123 [I-D.ietf-dmm-srv6-mobile-uplane] and 3GPP [TR.29892]. 125 SRv6 has also an advantage if it is used as a mobile user plane, 126 because of its flexibility through Service Programming functions and 127 the use of metadata, in addition to the simple and stateless traffic 128 steering capability. 130 The 3GPP data plane entities such as UPFs and service functions can 131 be implemented either as virtual or physical appliances. The fact 132 that SRv6 has been supported on various platforms including custom 133 ASICs, commercially available NPUs, programmable switches, Smart 134 NICs, Linux Kernel, virtual forwarders on server and container 135 networking, will make the deployment flexible. 137 Also, the declarative programming nature of SRv6 will provide the 138 necessary distinction to clarify basic reachability vs constraint 139 path vs service path, whereas existing practices depended on the 140 layer separation - service overlay and underlay. In other words, one 141 of the most important value propositions of SRv6 mobile user plane is 142 the possibility to perform cross-layer optimizations. 144 This document discusses the architectural implications of applying 145 SRv6 mobile user plane, especially regarding the possible 146 optimization of existing layers. Then it takes 5G requirements and 147 use cases as an example, and describes how these use cases are simply 148 and effectively realized with the inter-layer optimization capability 149 of SRv6 mobile user plane. Thus it show that SRv6 mobile use plane 150 is a right architectural choice for the 5G era. 152 2. Architecture Consideration and Necessity of Inter-layer Optimization 154 Historically, Mobile and Transport Network have been designed, 155 standardized and operated separately. GTP-U has been defined as the 156 mobile user plane. This is an overlay tunnel that runs over the 157 Transport Network. Therefore, the underlying network cannot be 158 directly controlled. 160 5G requires variety of tight-SLA characteristics and flexible traffic 161 steering towards various service functions. While 3GPP has been 162 focused on the mobility overlay, how to map the overlay requirements 163 into the transport network is out of the scope. 165 IETF has discussed mobile end-to-end slicing in different WGs 166 [I-D.rokui-5g-transport-slice], [I-D.clt-dmm-tn-aware-mobility]. 167 However, all these proposals are based on the current assumption that 168 the underlying network is separated from the overlay and agnostic. 170 The evolution of architecture requires a review of conventional 171 domain boundaries and practices. This way, inefficiencies caused by 172 traditional practices can be reduced. For example, now that "CUPS" 173 separated the Control Plane and User Plane, UPF, which is dedicated 174 to forwarding, can be considered as an entity on the IP Transport 175 Network. 177 And, as a matter of fact, layer reduction for efficiency has been 178 done in other domains. Some data centers adopted native IP CLOS, 179 avoiding using VXLAN for simplicity. Also, broadband subscriber 180 managements were simplified by using IPoE instead of PPPoE / L2TP. 182 In the context of mobile operators, SRv6 provides end-to-end simpler 183 network operations thus decreasing the OPEX. SRv6 has a potential to 184 perform inter-layer optimizations and/or eliminate overlay tunnels, 185 though it does not mandate to do so. 187 Note that SRv6 can also be applied to the mobility overlay, in which 188 case it also has benefits as the tunnels are removed. 190 3. Terminology 192 The terminology used in this document leverages and conforms to 193 [I-D.ietf-dmm-srv6-mobile-uplane]. 195 +-----+ 196 | AMF | 197 +-----+ 198 / | [N11] 199 [N2] / +-----+ 200 +------/ | SMF | 201 / +-----+ 202 / / \ 203 / / \ [N4] 204 / / \ ________ 205 / / \ / \ 206 +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ 207 |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / 208 +--+ +-----+ TN +------+ TN +------+ \________/ 210 Figure 1: Reference Architecture 212 - UE : User Equipment 213 - gNB : gNodeB 214 - UPF : User Plane Function 215 - SMF : Session Management Function 216 - AMF : Access and Mobility Management Function 217 - 3GPP data plane entities : 3GPP entities responsible for data plane 218 forwarding, i.e. gNB and UPF 219 - TN : Transport Network - IP network where 3GPP data plane entities 220 connected 221 - DN : Data Network e.g. operator services, Internet access 222 - CUPS : Control Plane and User Plane Separation 224 4. SRv6 mobile user plane and the 5G use cases 226 4.1. Network Slicing 228 The SRv6 mobile user plane proposal specifies the Traditional mode 229 and the Enhanced mode. The Traditional mode inherits the existing 230 mobile user plane and minimize the impact to the existing the 3GPP 231 architecture. The Enhanced mode can encode any required SID(s) for 232 constraint path steering and service steering purpose, which enable 233 efficient end-to-end network slicing. 235 How to build network slicing using the Segment Routing based 236 technology is described in 237 [I-D.ali-spring-network-slicing-building-blocks] 238 In the typical GTP-U over IP/MPLS/SR configuration, 3GPP data plane 239 entity such as UPF is a CE to the transport networks PE. This 240 results in the following facts: 242 - A certain Extra ID such as VLAN-ID is needed for segregating 243 traffic and mapping it onto a designated slice. 244 - PE and the PE-CE connection is a single point of failure, so some 245 form of PE redundancy (using routing protocols, MC-LAG, etc.) is 246 required, which makes systems inefficient and complex. 248 In the past, this was unavoidable. But nowadays 3GPP dataa plane 249 entities are implemented on servers or dedicated platforms which have 250 virtualized infrastructure, and it is getting common that routing 251 instances are implemented in such servers/platforms. 253 Furthermore, as stated in the introduction section, SRv6 have been 254 implemented in various forms, it is natural for such servers/ 255 platforms to be SRv6 aware. 257 If the routing administrative domain must be separated between the 258 3GPP data plane entities and IP network, then BSID (BSID) may be 259 used. With BSID, Topology information is abstracted and not exposed 260 to the 3GPP data plane entities. 262 The BSID is bound to an SR policy, instantiation of which may involve 263 a list of SIDs. Any packets received with active segment = BSID are 264 steered onto the bound SR Policy, as defined in [RFC8402]. 266 4.2. Edge Computing 268 Edge computing, where the computing workload is placed closer to 269 users, is recognized as one of the key pillars to meet 5G's demanding 270 key performance indicators (KPIs), especially with regard to low 271 latency and bandwidth efficiency. The computing workload includes 272 network services, security, analytics, content cache and various 273 applications. UPF can also be viewed as a distributed network 274 service. 276 SRv6's flexible traffic steering capabilities and the Network 277 Programming concept of freely describing instructions and meta data 278 are per se suitable for providing Edge Computing. 280 In addition, since SRv6 can be a common data plane regardless of the 281 domains such as access, WAN, mobility and data center, Service 282 Placement and Service Chain that used to be concentrated in Data 283 Center can be expanded over a wide area. 285 Furthermore, with SRv6, session and QoS information can be exposed in 286 IP header. It does not affect performance, thanks to the longest 287 match mechanism in the IP routing. Only the services/applications 288 who need the information for granular processing are to lookup. This 289 also allows services/applications to be placed in between N9 paths if 290 needed. 292 The draft implementation of Firewall using SRv6 meta data is 293 discussed in [I-D.guichard-spring-srv6-simplified-firewall] 295 4.3. URLLC (Ultra-Reliable Low-Latency Communication) support 297 3GPP [TR.23725] investigates the key issues for meeting the URLLC 298 requirements on latency, jitter and reliability in the 5G System. 299 The solutions provided in such document are focused at improving the 300 overlay protocol (GTP-U) and limit to provide a few hints into how to 301 map such tight-SLA into the transport network. These hints are based 302 on static configuration or static mapping for steering the overlay 303 packet into the right transport SLA. Such solutions do not scale and 304 hinder network economics. 306 Some of the issues can be solved more simply without GTP-U tunnel. 307 SRv6 mobile user plane can exposes session and QoS flow information 308 in IP header as discussed in the previous section. This would make 309 routing and forwarding path optimized for URLLC, much simpler than 310 the case with GTP-U tunnel. 312 Another issue that deserves special mention is the ultra-reliability 313 issue. In 3GPP, in order to support ultra-reliability, redundant 314 user planes paths based on dual connectivity has been proposed. The 315 proposal has two main options. 317 - Dual Connectivity based end-to-end Redundant User Plane Paths 318 - Support of redundant transmission on N3/N9 interfaces 320 In the case of the former, UE and hosts have RHF(Redundancy Handling 321 Function). In sending, RFH is to replicate the traffic onto two 322 GTP-U tunnels, and in receiving, RHF is to merge the traffic. 324 In the case of the latter, the 3GPP data plane entities are to 325 replicate and merge the packets with the same sequence for specific 326 QoS flow, which requires further enhancements. 328 SRv6 mobile user plane has some advantages for URLLC traffic. First, 329 it can be used to enforce a low-latency path in the network by means 330 of scalable Traffic Engineering. Additionally, SRv6 provides an 331 automated reliability protection mechanism known as TI-LFA. This is 332 a sub-50ms FRR mechanism that provides protection regardless of the 333 topology through the optimal backup path. 335 With the case that dual live-live path is required, the problem is 336 not only the complexity but that the replication point and the 337 merging point would be the single point of failure. The SRv6 mobile 338 user plane also has an advantage in this respect, because any 339 endpoints or 3GPP data plane nodes themselves can be the replication/ 340 merging point when they are SRv6 aware. 342 5. Security Considerations 344 TBD 346 6. IANA Considerations 348 NA 350 7. Acknowledgements 352 TBD 354 8. References 356 8.1. Normative References 358 [I-D.hegdeppsenak-isis-sr-flex-algo] 359 Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS 360 Segment Routing Flexible Algorithm", draft-hegdeppsenak- 361 isis-sr-flex-algo-02 (work in progress), February 2018. 363 [I-D.ietf-6man-segment-routing-header] 364 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 365 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 366 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 367 progress), October 2019. 369 [I-D.ietf-dmm-srv6-mobile-uplane] 370 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 371 Voyer, D., and C. Perkins, "Segment Routing IPv6 for 372 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-06 373 (work in progress), September 2019. 375 [I-D.ietf-spring-srv6-network-programming] 376 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 377 Matsushima, S., and Z. Li, "SRv6 Network Programming", 378 draft-ietf-spring-srv6-network-programming-05 (work in 379 progress), October 2019. 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, 383 DOI 10.17487/RFC2119, March 1997, 384 . 386 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 387 Decraene, B., Litkowski, S., and R. Shakir, "Segment 388 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 389 July 2018, . 391 8.2. Informative References 393 [I-D.ali-spring-network-slicing-building-blocks] 394 Ali, Z., Filsfils, C., Camarillo, P., and d. 395 daniel.voyer@bell.ca, "Building blocks for Slicing in 396 Segment Routing Network", draft-ali-spring-network- 397 slicing-building-blocks-01 (work in progress), March 2019. 399 [I-D.clt-dmm-tn-aware-mobility] 400 Chunduri, U., Li, R., Bhaskaran, S., Tantsura, J., 401 Contreras, L., Muley, P., and J. Kaippallimalil, 402 "Transport Network aware Mobility for 5G", draft-clt-dmm- 403 tn-aware-mobility-04 (work in progress), July 2019. 405 [I-D.filsfils-spring-srv6-interop] 406 Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., 407 Salsano, S., Bonaventure, O., Horn, J., and J. Liste, 408 "SRv6 interoperability report", draft-filsfils-spring- 409 srv6-interop-02 (work in progress), March 2019. 411 [I-D.guichard-spring-srv6-simplified-firewall] 412 Guichard, J., Filsfils, C., daniel.bernier@bell.ca, d., 413 Li, Z., Clad, F., Camarillo, P., and A. Abdelsalam, 414 "Simplifying Firewall Rules with Network Programming and 415 SRH Metadata", draft-guichard-spring-srv6-simplified- 416 firewall-01 (work in progress), September 2019. 418 [I-D.ietf-dmm-fpc-cpdp] 419 Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., 420 Moses, D., and C. Perkins, "Protocol for Forwarding Policy 421 Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 422 (work in progress), June 2018. 424 [I-D.rokui-5g-transport-slice] 425 Rokui, R., Homma, S., Lopez, D., Foy, X., Contreras, L., 426 Ordonez-Lucena, J., Martinez-Julia, P., Boucadair, M., 427 Eardley, P., Makhijani, K., and H. Flinck, "5G Transport 428 Slice Connectivity Interface", draft-rokui-5g-transport- 429 slice-00 (work in progress), July 2019. 431 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 432 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 433 RFC 5213, DOI 10.17487/RFC5213, August 2008, 434 . 436 [TR.23725] 437 3GPP, "Study on enhancement of Ultra-Reliable Low-Latency 438 Communication (URLLC) support in the 5G Core network 439 (5GC)", 3GPP TR 23.725 16.2.0, June 2019. 441 [TR.29892] 442 3GPP, "Study on User Plane Protocol in 5GC", 3GPP TR 443 29.892 16.1.0, April 2019. 445 [TS.23501] 446 3GPP, "System Architecture for the 5G System", 3GPP TS 447 23.501 15.0.0, November 2017. 449 [TS.29244] 450 3GPP, "Interface between the Control Plane and the User 451 Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. 453 [TS.29281] 454 3GPP, "General Packet Radio System (GPRS) Tunnelling 455 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, 456 December 2017. 458 Authors' Addresses 460 Miya Kohno 461 Cisco Systems, Inc. 462 Japan 464 Email: mkohno@cisco.com 466 Francois Clad 467 Cisco Systems, Inc. 468 France 470 Email: fclad@cisco.com 471 Pablo Camarillo Garvia 472 Cisco Systems, Inc. 473 Spain 475 Email: pcamaril@cisco.com 477 Zafar Ali 478 Cisco Systems, Inc. 479 Canada 481 Email: zali@cisco.com