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,
              <https://www.rfc-editor.org/info/rfc2119>.




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, <https://www.rfc-editor.org/info/rfc8402>.

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,
              <https://www.rfc-editor.org/info/rfc5213>.

   [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]