DMM Working Group M. Kohno Internet-Draft F. Clad Intended status: Informational P. Camarillo Expires: September 9, 2020 Z. Ali Cisco Systems, Inc. March 8, 2020 Architecture Discussion on SRv6 Mobile User plane draft-kohno-dmm-srv6mob-arch-01 Abstract Layer separation is a powerful concept in system architecture. In the area of mobility, by separating GTP-U that is the overlay tunnel, and the IP transport network that is the underlay, the operation of the mobile network and the transport network can be separated, allowing them to evolve independently. However, evolving individually at each layer promotes local optimization and may result in non-optimal solutions overall in the long run. When a drastic architectural transition is required, for example, in the 5G era where various SLAs and completely new data intensive services are assumed, it is necessary to reconsider the architecture holistically, not from the viewpoint of individual part. One of important value propositions of SRv6 mobile user plane is to create overlay with underlay optimization. This document discusses the architecture implication of applying SRv6 mobile user plane. Then it takes 5G use cases as an example, and describes how these use cases are simply and effectively realized. Thus it shows that SRv6 mobile use plane is a right architectural choice for 5G era. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Kohno, et al. Expires September 9, 2020 [Page 1] Internet-Draft SRv6mob-arch March 2020 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 9, 2020. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Architecture Consideration and Necessity of Inter-layer Optimization . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. SRv6 mobile user plane and the 5G use cases . . . . . . . . . 5 4.1. Network Slicing . . . . . . . . . . . . . . . . . . . . . 5 4.2. Edge Computing . . . . . . . . . . . . . . . . . . . . . 6 4.3. URLLC (Ultra-Reliable Low-Latency Communication) support 6 5. Incremental Deployment . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Layer separation is a powerful concept in system architecture. In the area of mobility, by separating GTP-U that is the overlay tunnel, and the IP transport network that is the underlay, the operation of the mobile network and the transport network can be separated, allowing them to evolve independently. Kohno, et al. Expires September 9, 2020 [Page 2] Internet-Draft SRv6mob-arch March 2020 However, evolving individually at each layer promotes local optimization and may result in non-optimal solutions overall in the long run. The well-known aphorism of David J.Wheeler says: "All problems in computer science can be solved by adding another level of indirection." But, as a corollary, it also says: "...that usually will create another problem." In other words, excessive use of tunnels is not good for an overall architecture. Existing practices have reasonable grounds, so it is usually recommended to follow them. But when a drastic architectural transition is required, for example, in the 5G era where various SLAs and completely new data intensive services are assumed, it is necessary to reconsider the architecture holistically, rather than from the viewpoint of individual part. SRv6 mobile user plane has been proposed as an alternative way to complement or replace GTP-U both in IETF [I-D.ietf-dmm-srv6-mobile-uplane] and 3GPP [TR.29892]. In the 3GPP CT4, the scope of the study was narrow (N9 only) and it was concluded not to accept as a candidate protocol for the user plane in 5GC based on Rel-16 stage 2 requirements. However, the future is still open given the heterogeneous access evolution and stringent data intensiveness. SRv6 has also an advantage if it is used as a mobile user plane, because of its flexibility through Service Programming functions and the use of metadata, in addition to the simple and stateless traffic steering capability. The 3GPP data plane entities such as UPFs and service functions can be implemented either as virtual or physical appliances. The fact that SRv6 has been supported on various platforms including custom ASICs, commercially available NPUs, programmable switches, Smart NICs, Linux Kernel, virtual forwarders on server and container networking, will make the deployment flexible. Also, the declarative programming nature of SRv6 will provide the necessary distinction to clarify basic reachability vs constraint path vs service path, whereas existing practices depended on the layer separation - service overlay and underlay. In other words, one of the most important value propositions of SRv6 mobile user plane is the possibility to perform cross-layer optimizations. Kohno, et al. Expires September 9, 2020 [Page 3] Internet-Draft SRv6mob-arch March 2020 This document discusses the architecture implication of applying SRv6 mobile user plane. Then it takes 5G use cases as an example, and describes how these use cases are simply and effectively realized. Thus it shows that SRv6 mobile use plane is a right architectural choice for 5G era. 2. Architecture Consideration and Necessity of Inter-layer Optimization Historically, Mobile and Transport Network have been designed, standardized and operated separately. GTP-U has been defined as the mobile user plane. This is an overlay tunnel that runs over the Transport Network. Therefore, the underlying network cannot be directly controlled. 5G requires variety of SLA characteristics and flexible traffic steering towards various service functions. How to map the transport slice to mobile end-to-end slice has been being discussed in multiple WGs in IETF [I-D.rokui-5g-transport-slice], [I-D.clt-dmm-tn-aware-mobility]. They are based on the current assumption that underlying network is separated and agnostic. But it could be effective if the underlying network can be more interactive. The evolution of architecture requires a review of conventional domain boundaries and practices. This way, inefficiencies caused by traditional practices can be reduced. For example, now that "CUPS" separated the Control Plane and User Plane, UPF, which is dedicated to forwarding, can be considered as an entity on the IP Transport Network. And, as a matter of fact, layer reduction for efficiency has been done in other domains. Some data centers adopted native IP CLOS, avoiding using VXLAN for simplicity. Also broadband subscriber managements were simplified by using IPoE instead of PPPoE / L2TP. In the context of mobile operators, SRv6 provides end-to-end simpler network operations thus decreasing the OPEX. SRv6 can also be applied to the mobility overlay, in which case it also has benefits as the tunnels are removed. 3. Terminology The terminology used in this document leverages and conforms to [I-D.ietf-dmm-srv6-mobile-uplane]. Kohno, et al. Expires September 9, 2020 [Page 4] Internet-Draft SRv6mob-arch March 2020 +-----+ | AMF | +-----+ / | [N11] [N2] / +-----+ +------/ | SMF | / +-----+ / / \ / / \ [N4] / / \ ________ / / \ / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / +--+ +-----+ TN +------+ TN +------+ \________/ Figure 1: Reference Architecture - UE : User Equipment - gNB : gNodeB - UPF : User Plane Function - SMF : Session Management Function - AMF : Access and Mobility Management Function - 3GPP data plane entities : 3GPP entities responsible for data plane forwarding, i.e. gNB and UPF - TN : Transport Network - IP network where 3GPP data plane entities connected - DN : Data Network e.g. operator services, Internet access - CUPS : Control Plane and User Plane Separation - VNF : Virtual Network Function - CNF : Cloud native Network Function 4. SRv6 mobile user plane and the 5G use cases 4.1. Network Slicing SRv6 network programming realizes network slicing. How to build network slicing using the Segment Routing based technology is described in [I-D.ali-spring-network-slicing-building-blocks] Also, the stateless slice identifier [I-D.filsfils-spring-srv6-stateless-slice-id] has been proposed to enable per-slice forwarding policy and bandwidth manipulation. In the typical GTP-U over IP/MPLS/SR configuration, 3GPP data plane entity such as UPF is a CE to the transport networks PE. This results in the following facts: Kohno, et al. Expires September 9, 2020 [Page 5] Internet-Draft SRv6mob-arch March 2020 - A certain Extra ID such as VLAN-ID is needed for segregating traffic and mapping it onto a designated slice. - PE and the PE-CE connection is a single point of failure, so some form of PE redundancy (using routing protocols, MC-LAG, etc.) is required, which makes systems inefficient and complex. Another possibility would be that 3GPP user plane entities are deployed as VNF/CNF in a DC. In this case, slice in the DC network and other networks are to be inter-connected via DCI. In either case, it would improve the scalability, QoS and efficiency, if the user plane entities directly support SRv6. 4.2. Edge Computing Edge computing, where the computing workload is placed closer to users, is recognized as one of the key pillars to meet 5G's demanding key performance indicators (KPIs), especially with regard to low latency and bandwidth efficiency. The computing workload includes network services, security, analytics, content cache and various applications. UPF can also be viewed as a distributed network service function. SRv6's flexible traffic steering capabilities and the Network Programming concept of freely describing Instructions and meta data are per se suitable for providing Edge Computing. In addition, since SRv6 can be a common data plane regardless of the domains such as access, WAN, mobility and data center, Service Placement and Service Chain that used to be concentrated in Data Center can be expanded over a wide area. Furthermore, with SRv6, session and QoS information can be exposed in IP header. It does not affect performance, thanks to the longest match mechanism in the IP routing. Only the services/applications who need the information for granular processing are to lookup. This also allows services/applications to be placed in between N9 paths if needed. The draft implementation of Firewall using SRv6 meta data is discussed in [I-D.guichard-spring-srv6-simplified-firewall] 4.3. URLLC (Ultra-Reliable Low-Latency Communication) support 3GPP [TR.23725] investigates the key issues for meeting the URLLC requirements on latency, jitter and reliability in the 5G System. The solutions provided in the document are focused at improving the overlay protocol (GTP-U) and limits to provide a few hints into how Kohno, et al. Expires September 9, 2020 [Page 6] Internet-Draft SRv6mob-arch March 2020 to map such tight-SLA into the transport network. These hints are based on static configuration or static mapping for steering the overlay packet into the right transport SLA. Such solutions do not scale and hinder network economics. Some of the issues can be solved more simply without GTP-U tunnel. SRv6 mobile user plane can exposes session and QoS flow information in IP header as discussed in the previous section. This would make routing and forwarding path optimized for URLLC, much simpler than the case with GTP-U tunnel. Another issue that deserves special mention is the ultra-reliability issue. In 3GPP, in order to support ultra-reliability, redundant user planes paths based on dual connectivity has been proposed. The proposal has two main options. - Dual Connectivity based end-to-end Redundant User Plane Paths - Support of redundant transmission on N3/N9 interfaces In the case of the former, UE and hosts have RHF(Redundancy Handling Function). In sending, RFH is to replicate the traffic onto two GTP-U tunnels, and in receiving, RHF is to merge the traffic. In the case of the latter, the 3GPP data plane entities are to replicate and merge the packets with the same sequence for specific QoS flow, which requires further enhancements. SRv6 mobile user plane has some advantages for URLLC traffic. First, it can be used to enforce a low-latency path in the network by means of scalable Traffic Engineering. Additionally, SRv6 provides an automated reliability protection mechanism known as TI-LFA, which is a sub-50ms FRR mechanism that provides protection regardless of the topology through the optimal backup path. It can be provisioned slice-aware. With the case that dual live-live path is required, the problem is not only the complexity but that the replication point and the merging point would be the single point of failure. The SRv6 mobile user plane also has an advantage in this respect, because any endpoints or 3GPP data plane nodes themselves can be the replication/ merging point when they are SRv6 aware. 5. Incremental Deployment Incremental deployment should be considered. In the case of hcin mobility [I-D.auge-dmm-hicn-mobility-deployment-options], the insertion with no modification to the existing 3GPP architecture is considered first, and then the tighter integration of data plane is Kohno, et al. Expires September 9, 2020 [Page 7] Internet-Draft SRv6mob-arch March 2020 to be achieved. The same shall apply in the case of SRv6 mobile user plane. 6. Security Considerations TBD 7. IANA Considerations NA 8. Acknowledgements Authors would like to thank Satoru Matsushima and Shunsuke Homma for their insights and comments. 9. References 9.1. Normative References [I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-filsfils-spring-srv6-network- programming-07 (work in progress), February 2019. [I-D.hegdeppsenak-isis-sr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS Segment Routing Flexible Algorithm", draft-hegdeppsenak- isis-sr-flex-algo-02 (work in progress), February 2018. [I-D.ietf-dmm-srv6-mobile-uplane] Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., Voyer, D., and C. Perkins, "Segment Routing IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-07 (work in progress), November 2019. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Kohno, et al. Expires September 9, 2020 [Page 8] Internet-Draft SRv6mob-arch March 2020 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 9.2. Informative References [I-D.ali-spring-network-slicing-building-blocks] Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer, "Building blocks for Slicing in Segment Routing Network", draft-ali-spring-network-slicing-building-blocks-02 (work in progress), November 2019. [I-D.auge-dmm-hicn-mobility-deployment-options] Auge, J., Carofiglio, G., Muscariello, L., and M. Papalini, "Anchorless mobility management through hICN (hICN-AMM): Deployment options", draft-auge-dmm-hicn- mobility-deployment-options-03 (work in progress), January 2020. [I-D.clt-dmm-tn-aware-mobility] Chunduri, U., Li, R., Bhaskaran, S., Kaippallimalil, J., Tantsura, J., Contreras, L., and P. Muley, "Transport Network aware Mobility for 5G", draft-clt-dmm-tn-aware- mobility-05 (work in progress), November 2019. [I-D.filsfils-spring-srv6-interop] Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., Salsano, S., Bonaventure, O., Horn, J., and J. Liste, "SRv6 interoperability report", draft-filsfils-spring- srv6-interop-02 (work in progress), March 2019. [I-D.filsfils-spring-srv6-stateless-slice-id] Filsfils, C., Clad, F., Camarillo, P., and K. Raza, "Stateless and Scalable Network Slice Identification for SRv6", draft-filsfils-spring-srv6-stateless-slice-id-00 (work in progress), January 2020. [I-D.guichard-spring-srv6-simplified-firewall] Guichard, J., Filsfils, C., daniel.bernier@bell.ca, d., Li, Z., Clad, F., Camarillo, P., and A. Abdelsalam, "Simplifying Firewall Rules with Network Programming and SRH Metadata", draft-guichard-spring-srv6-simplified- firewall-01 (work in progress), September 2019. Kohno, et al. Expires September 9, 2020 [Page 9] Internet-Draft SRv6mob-arch March 2020 [I-D.ietf-dmm-fpc-cpdp] Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Moses, D., and C. Perkins, "Protocol for Forwarding Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12 (work in progress), June 2018. [I-D.rokui-5g-transport-slice] Rokui, R., Homma, S., Lopez, D., Foy, X., Contreras, L., Ordonez-Lucena, J., Martinez-Julia, P., Boucadair, M., Eardley, P., Makhijani, K., and H. Flinck, "5G Transport Slice Connectivity Interface", draft-rokui-5g-transport- slice-00 (work in progress), July 2019. [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, . [TR.23725] 3GPP, "Study on enhancement of Ultra-Reliable Low-Latency Communication (URLLC) support in the 5G Core network (5GC)", 3GPP TR 23.725 16.2.0, June 2019. [TR.29892] 3GPP, "Study on User Plane Protocol in 5GC", 3GPP TR 29.892 16.1.0, April 2019. [TS.23501] 3GPP, "System Architecture for the 5G System", 3GPP TS 23.501 15.0.0, November 2017. [TS.29244] 3GPP, "Interface between the Control Plane and the User Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017. [TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0, December 2017. Authors' Addresses Miya Kohno Cisco Systems, Inc. Japan Email: mkohno@cisco.com Kohno, et al. Expires September 9, 2020 [Page 10] Internet-Draft SRv6mob-arch March 2020 Francois Clad Cisco Systems, Inc. France Email: fclad@cisco.com Pablo Camarillo Garvia Cisco Systems, Inc. Spain Email: pcamaril@cisco.com Zafar Ali Cisco Systems, Inc. Canada Email: zali@cisco.com Kohno, et al. Expires September 9, 2020 [Page 11]