<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY rfc5213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
  <!ENTITY rfc8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml">
  <!ENTITY rfc8754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8754.xml">
  <!ENTITY rfc8986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8986.xml">
  <!ENTITY I-D.ietf-dmm-srv6-mobile-uplane SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dmm-srv6-mobile-uplane.xml">
  <!ENTITY I-D.hegdeppsenak-isis-sr-flex-algo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hegdeppsenak-isis-sr-flex-algo.xml"> 
  <!ENTITY I-D.ietf-dmm-fpc-cpdp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dmm-fpc-cpdp.xml">
  <!ENTITY I-D.clt-dmm-tn-aware-mobility SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.clt-dmm-tn-aware-mobility.xml">
  <!ENTITY I-D.ali-spring-network-slicing-building-blocks SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ali-spring-network-slicing-building-blocks.xml">
  <!ENTITY I-D.guichard-spring-srv6-simplified-firewall SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.guichard-spring-srv6-simplified-firewall.xml">
  <!ENTITY I-D.filsfils-spring-srv6-interop SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.filsfils-spring-srv6-interop.xml">
  <!ENTITY I-D.filsfils-spring-srv6-stateless-slice-id SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.filsfils-spring-srv6-stateless-slice-id.xml">
  <!ENTITY I-D.auge-dmm-hicn-mobility-deployment-options SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.auge-dmm-hicn-mobility-deployment-options.xml">
  <!ENTITY I-D.auge-dmm-hicn-mobility SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.auge-dmm-hicn-mobility.xml">
  <!ENTITY I-D.mhkk-dmm-srv6mup-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mhkk-dmm-srv6mup-architecture.xml">  
] >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc category="info" docName="draft-kohno-dmm-srv6mob-arch-06" ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>
  <?rfc compact="yes" ?>
  <?rfc subcompact="yes" ?>
  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="SRv6mob-arch">Architecture Discussion on SRv6 Mobile User plane</title>


    <author fullname="Miya Kohno" initials="M." surname="Kohno">
      <organization abbrev="Cisco Systems, Inc.">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>Japan</country>
        </postal>
        <email>mkohno@cisco.com</email>
      </address>
    </author>

    <author fullname="Francois Clad" initials="F." surname="Clad">
      <organization abbrev="Cisco Systems, Inc.">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>France</country>
        </postal>
        <email>fclad@cisco.com</email>
      </address>
    </author>
    
    <author fullname="Pablo Camarillo Garvia" initials="P." surname="Camarillo">
      <organization abbrev="Cisco Systems, Inc.">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>Spain</country>
        </postal>
        <email>pcamaril@cisco.com</email>
      </address>
    </author>

        <author fullname="Zafar Ali" initials="Z." surname="Ali">
      <organization abbrev="Cisco Systems, Inc.">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>Canada</country>
        </postal>
        <email>zali@cisco.com</email>
      </address>
    </author>

<!--
     <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
      <organization abbrev="SoftBank">SoftBank</organization>

      <address>
        <postal>
          <street></street>
          <city>Tokyo</city>
          <region></region>
          <code></code>
          <country>Japan</country>
        </postal>
        <email>satoru.matsushima@g.softbank.co.jp</email>
      </address>
    </author>
    
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization abbrev="Cisco Systems, Inc.">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>Belgium</country>
        </postal>
        <email>cf@cisco.com</email>
      </address>
    </author>
    
    
-->


    <date year="2023" />
    <workgroup>DMM Working Group</workgroup>

    <abstract>

        <t>This document discusses the solution approach and its architectural benefits of translating 
        mobile session information into routing information, applying segment routing capabilities, and 
        operating in a routing paradigm.  </t>
        
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
        <t>The current mobile user plane is defined as an overlay tunnel session to a mobile anchor 
        point (UPF: User Plane Function in 5G context). </t>

        <t>While this approach may be convenient from the standpoint of per-session per-usage charging, 
        it is difficult to cost-effectively and scalably address the high traffic volumes of the 5G/Beyond 
        5G era and more distributed data and computing demands of the future. </t>

        <t>In addition, the requirements for wireless systems, such as IoT and FWA (Fixed Wireless Access) 
        applications, are becoming more diverse, and there are cases where the conventional per-session 
        per-usage charging is not necessarily applicable. </t>
        
        <t>This document discusses the solution approach and its architectural benefits of translating 
        mobile session information into routing information, applying segment routing capabilities, and 
        operating in a routing paradigm.  </t>

<!--

        <t>SRv6 mobile user plane <xref target="I-D.ietf-dmm-srv6-mobile-uplane"/> is 
        standardized in IETF. It accomplishes the mobile user-plane functions in a simple, flexible 
        and scalable manner, by utilizing the network programming nature of SRv6. It leverages 
        common native IPv6 data plane and creates interoperable overlays with underlay optimization. </t>

        <t>This document discusses the solution approach and its architectural benefits of common 
        data plane across domains (e.g., mobile domain, IP infrastructure, data center, applications) 
        and across overlay/underlay. </t>

        <t> This approach is in a sense contrary to proposals that the underlying transport can be anything 
        (L2, IPv4, IPv6, MPLS, SR, SRv6). But it is an approach to make the network as flat as possible, making 
        it suitable for the distributed mobile deployment model. </t>
-->
      
      </section>

    <section title="Problem Definition">
        <t>The current tunnel session based mobile user plane has the following limitations and is getting 
        hard to support new application requirements. </t>

        <t>
          <list style="symbols">
            <t>Non-optimal for any-to-any communication </t>
            <t>Non-optimal for edge/distributed computing  </t>  
            <t>Non-optimal for fixed and mobile convergence (FMC)  </t>  
            <t>No control of the underlay path  </t>                  
          </list>
        </t>

        <t>In addition, the anchor point that terminates tunnel sessions becomes a scaling bottleneck. </t>

<!--
        <t>For residential broadband IP and data center networking, tunnel sessions could be eliminated 
        (e.g. PPPoE -> IPoE, VXLAN/NSH -> SRv6). This indicates that a tunnel session is not necessarily absolute. 
        But such a thing was unlikely to happen in the mobile domain. </t>
-->

        <t>As for FMC, there is currently a coordinated standardization effort between 3GPP WWC <xref target="TS.23316"/>
        and BBF <xref target="BBF407"/>. However, the idea is to anchor even wireline traffic in the mobile packet 
        core, which compromises simplicity and scalability. </t>

        <t>The IP routing paradigm naturally eliminates these tunnel session based shortcomings. 
        Segment Routing enables fast protection, policy, slicing, etc. to provide reliability and SLA differentiation.</t>
        
    </section>
    
<!--   
    <section title="Common data plane across domains and across overlay/underlay">
        <t><xref target="I-D.ietf-dmm-srv6-mobile-uplane"/> defines SRv6 mobile user plane as an 
        alternative or co-existing solution to GTP-U.</t>
        <t> Since SRv6 is a native IPv6 data plane, it can be a common data plane regardless of the 
        domain. </t>
        <t> SRv6 Network Programming <xref target="RFC8986"/> 
        enables the creation of overlays with underlay optimization. In addition, SRv6 can be operated 
        by application developers because of its implementation in the computing stack, e.g. VPP, Linux 
        Kernel, smart NIC, and cloud native platform such as Network Service Mesh. </t>
        <t> Data plane commonality offers significant advantage regarding function, scaling, and cost. 
        In particular, the benefits of the 5G era are shown in <xref target="advantage"/>. </t>
        <t> Note that the interaction with underlay infrastructure is not a mandatory in the data plane 
        commonality. It just gives a design choice to interact with the underlay and optimize it, and 
        it is totally fine to keep ovelray underlay-agnostic, which will allow the coexistence of different 
        capability of nodes. </t>     

    </section>

    <section title="Control Plane Considerations">     
        <t>This document focuses on the commonalization of data plane, and the control plane is out of scope. 
        The actual system characteristics such as scaling and functionality depend heavily on the control 
        plane, though.</t>
        
        <t>The potential of the SRv6 mobile user plane is huge, in the sense that it can realize various 
        functions of mobile management using SRv6 Network Programming. Protocols such as GTP-C, PMIPv6, 
        BGP, LISP, ILNP, hICN, or even others can be applied as a control plane to control mobility.  </t>
            
        <t>For example, if hICN <xref target="I-D.auge-dmm-hicn-mobility"/> was used, anchorless mobility
        can be realised. </t>
        
    </section> 

-->



    <section title="SRv6 mobile user plane and the 5G use cases" anchor="advantage">
    
    	   <t>This section describes the advantages of applying SRv6 mobile user plane for 5G use cases.</t>
    	     
    	   <section title="Network Slicing">

		<t>Network slicing enables network segmentation, isolation, and SLA differentiation in terms of 
		latency and availability. End-to-end slicing will be achieved by mapping and coordinating IP
		network slicing, RAN and mobile packet core slicing. </t>

		<t>But existing mobile user plane which is overlay tunnel does not have underlying IP network 
		awareness, which could lead to the inability in meeting SLAs. Removing the tunnel and treating 
		it with a routing paradigm simplifies the problem.</t>

          <t>Segment Routing has a comprehensive set of slice engineering technologies. How to build 
          network slicing using the Segment Routing based technology is described in 
          <xref target="I-D.ali-spring-network-slicing-building-blocks"/>. </t>

<!--   
		<t>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. But if 3GPP they support SRv6 mobile user plane, they can 
 		directly participate in network slicing, and solves the following issues. </t>
		
          <t>
          <list style="symbols">
            <t>A certain Extra ID such as VLAN-ID is needed for segregating traffic and mapping it 
            onto a designated slice. </t>
            <t>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. </t>
          </list>
          </t>
-->

          <t>Moreover, the stateless slice identifier encoding <xref target="I-D.filsfils-spring-srv6-stateless-slice-id"/> 
          can be applicable to enable per-slice forwarding policy using the IPv6 header. </t>
   
 		
   	   </section>
   	   
   	   <section title="Edge Computing">
          <t>Edge computing, where the computing workloads and datastores are placed closer to users, 
          is recognized as one of the key pillars to meet 5G's demanding requirements, with regard 
          to low latency, bandwidth efficiency, and data localty and privacy.  </t>

          <t>Edge computing is more important than ever. This is because no matter how much 5G 
          improves access speeds, it won't improve end-to-end throughput because it's largely bound 
          to round trip delay. </t>

          <t>Even with existing mobile architectures, it is possible to place UPFs in a multi-tier, or 
          to distribute UPFs, to achieve Edge Computing. However, complicated mechanisms are required to 
          branch traffic or properly use different UPFs. Also, seamless handover needs to be compromised
          when UPFs are distributed. </t>

          <t>Routing paradigm simply supports ubiquitous computing. </t>        

<!--     

          <t>However, the current MEC discussion <xref target="ETSI-MEC"/> focuses on how to properly 
          select the UPF of adequate proximity, and not on how to interact with applications.  </t>

          <t>SRv6 has an advantage in enabling edge computing for the following reasons. </t>

          <t>
          <list style="symbols">
            <t>Programmable and Flexible Traffic Steering : SRv6's flexible traffic steering 
            capabilities and the network programming concept is suitable for flexible placement 
            of computing workload.  </t>
            <t>Common data plane across domains : SRv6/IPv6 can be a common data plane regardless 
            of the domains such as mobile including UE, IP transport, data center, applications.  </t>
            <t>Stateless Service Chaining : It does not require any per-flow state in network 
            fabric.  </t>
            <t>Interaction with Applications : SRv6 can be implemented in the compute stack and
            can be manipulated by applications using socket API. Also, SRv6 can carry meta data, 
            which can be used for interacting with applications. </t>
            <t>Functionality without performance degradation : Various information can be exposed 
            in IP header, but it does not degrade performance thanks to the longest match mechanism 
            in the IP routing. Only who needs the information for granular processing are to 
      	  lookup. </t>
          </list>
          </t>

 		<t>It is even more beneficial if service functions/applications directly support SRv6.  </t>
 
-->

        </section>


        <section title="URLLC (Ultra-Reliable Low-Latency Communication) support">

          <t>3GPP <xref target="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 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. </t>

 		<t>Another issue that deserves special mention is the ultra-reliability issue. In order 
 		to support ultra-reliability with the tunnel session paradigm, redundant user planes paths 
 		based on dual connectivity has been proposed. The proposal has two main options.</t>
 		
          <t>
          <list style="symbols">
            <t>Dual Connectivity based end-to-end Redundant User Plane Paths</t>
            <t>Support of redundant transmission on N3/N9 interfaces</t>
          </list>
          </t>
          
          <t>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. </t>
          
       	<t>In the case of the latter, traffic are to be replicated and merged with the same 
       	sequence for specific QoS flow, which requires further enhancements.</t>
       	
       	<t>And in either cases, the bigger problem is the lack of a reliable way for the redundant
       	sessions to get through the disjoint path: even with the redundant sessions, if it ends up
       	using the same infrastructure at some points, the redundancy is meaningless.</t>

       	<t>These issues can be solved more simply without GTP-U tunnel. </t>
       	
 		<t>In addition, Segment routing has some advantages for URLLC traffic.  First, traffic can be 
 		mapped to a disjoint path or low latency path as needed. Second, Segment routing 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.</t>

<!--  
          <t>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. </t>
   
		<t>Furthermore, SRv6 supports inband telemetry/time stamping for latency monitoring and control.</t>
		
		<t>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.</t>

-->

       </section>

    </section>
         
    <section title="Co-existence and Incremental Deployability">
        <t>The mobile domain is a compound domain that includes Radio Access, and it is difficult to 
        implement a completely new architecture, so co-existence and incremental deployability is required. </t>

        <t> <xref target="I-D.ietf-dmm-srv6-mobile-uplane"/> defines the data plane convergence between 
        GTP-U and SRv6 between GTP-U and SRv6, so that it can co-exist with the current mobile architecture 
        as needed.  </t>

        <t> Further, <xref target="I-D.mhkk-dmm-srv6mup-architecture"/> defines the MUP architecture for 
        Distributed Mobility Management, which can be plugged to the existing mobile service architecture.
        </t>

 <!--  
        <t> In this way, SRv6 Network Programmability allows for proper deployability. </t>
             
        <t>With regard to the architectural migration, the insertion with no modification to the existing 
        3GPP architecture is considered first, and then the tighter integration of data plane is to be 
        achieved. as described in 
        <xref target="I-D.auge-dmm-hicn-mobility-deployment-options"/>. </t>
-->
        
    </section>

    
    <section title="Security Considerations">
      <t>The deployment of this architecture is targeted in a trusted domain. </t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>NA</t>
    </section>

    <section anchor="acknowledge" title="Acknowledgements">
      <t>Authors would like to thank Satoru Matsushima, Shunsuke Homma,Yuji Tochio and Jeffrey Zhang, for 
      their insights and comments.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
        &rfc2119;
        &rfc8402;
        &rfc8754;
        &rfc8986;
        &I-D.ietf-dmm-srv6-mobile-uplane;
        &I-D.hegdeppsenak-isis-sr-flex-algo;
    </references>

    <references title="Informative References">
        &I-D.mhkk-dmm-srv6mup-architecture;      
        &I-D.clt-dmm-tn-aware-mobility;
        &I-D.ali-spring-network-slicing-building-blocks;
        &I-D.filsfils-spring-srv6-stateless-slice-id;
        &I-D.auge-dmm-hicn-mobility-deployment-options;
        &I-D.auge-dmm-hicn-mobility;
        &rfc5213;
        <reference anchor="TS.29281">
            <front>
                <title>General Packet Radio System (GPRS) Tunnelling
                Protocol User Plane (GTPv1-U)</title>
                <author surname="3GPP" fullname="3GPP">
                </author>
                <date month="December" year="2017" />
            </front>
            <seriesInfo name="3GPP TS 29.281" value="15.1.0" />
        </reference>
        <reference anchor="TR.29892">
            <front>
                <title>Study on User Plane Protocol in 5GC</title>
                <author surname="3GPP" fullname="3GPP">
                </author>
                <date month="April" year="2019" />
            </front>
            <seriesInfo name="3GPP TR 29.892" value="16.1.0" />
        </reference>
        <reference anchor="ETSI-MEC">
            <front>
                <title>MEC in 5G Networks</title>
                <author surname="ETSI" fullname="ETSI">
                </author>
                <date month="June" year="2018" />
            </front>
            <seriesInfo name="ETSI White Paper" value="No.28" />
        </reference>
        <reference anchor="TS.29244">
            <front>
                <title>Interface between the Control Plane and the User Plane Nodes</title>
                <author surname="3GPP" fullname="3GPP">
                </author>
                <date month="December" year="2017" />
            </front>
            <seriesInfo name="3GPP TS 29.244" value="15.0.0" />
        </reference>
        <reference anchor="TS.23501">
            <front>
                <title>System Architecture for the 5G System</title>
                <author surname="3GPP" fullname="3GPP">
                </author>
                <date month="November" year="2017" />
            </front>
            <seriesInfo name="3GPP TS 23.501" value="15.0.0" />
        </reference>
        <reference anchor="TR.23725">
            <front>
                <title>Study on enhancement of Ultra-Reliable Low-Latency Communication (URLLC) support in the 
5G Core network (5GC)</title>
                <author surname="3GPP" fullname="3GPP">
                </author>
                <date month="June" year="2019" />
            </front>
            <seriesInfo name="3GPP TR 23.725" value="16.2.0" />
        </reference>
        <reference anchor="TS.23316">
            <front>
                <title>Wireless and wireline convergence access support for the 5G System (5GS) </title>
                <author surname="3GPP" fullname="3GPP">
                </author>
                <date month="September" year="2021" />
            </front>
            <seriesInfo name="3GPP TS 23.316" value="16.7.0" />
        </reference>
        <reference anchor="BBF407">
            <front>
                <title>5G Wireless Wireline Convergence Architecture </title>
                <author surname="BBF" fullname="BBF">
                </author>
                <date month="August" year="2020" />
            </front>
            <seriesInfo name="BBF TR-407" value="Issue:1" />
        </reference>
    </references>
  </back>
</rfc>