<?xml version="1.0" encoding="US-ASCII"?>
<!-- 
     draft-rfcxml-general-template-standard-00
  
     This template includes examples of the most commonly used features of RFCXML with comments 
     explaining how to customise them. This template can be quickly turned into an I-D by editing 
     the examples provided. Look for [REPLACE], [REPLACE/DELETE], [CHECK] and edit accordingly.
     Note - 'DELETE' means delete the element or attribute, not just the contents.
     
     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>
<!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->
<rfc category="info" docName="draft-kohno-dmm-srv6mob-arch-07"
     ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
     version="3" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude"
     xmlns:ns2="http://www.w3.org/2000/svg"
     xmlns:ns="http://www.w3.org/1999/xlink">
  <!-- [REPLACE] 
       * docName with name of your draft
     [CHECK] 
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN 
-->

  <front>
    <title abbrev="SRv6mob-arch">Architecture Discussion on SRv6 Mobile User
    plane</title>

    <seriesInfo name="Internet-Draft" value="draft-kohno-dmm-srv6mob-arch-07"/>

    <author fullname="Miya Kohno" initials="M." surname="Kohno">
      <organization abbrev="Cisco Systems, Inc.">Cisco Systems,
      Inc.</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <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/>

          <city/>

          <region/>

          <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/>

          <city/>

          <region/>

          <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/>

          <city/>

          <region/>

          <code/>

          <country>Canada</country>
        </postal>

        <email>zali@cisco.com</email>
      </address>
    </author>

    <author fullname="Luay Jalil" initials="L." surname="Jalil">
      <organization abbrev="Verizon">Verizon</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country>United States</country>
        </postal>

        <email>luay.jalil@verizon.com</email>
      </address>
    </author>

    <date year="2023"/>

    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <workgroup>DMM Working Group</workgroup>

    <keyword>Mobile Session IP Routing Paradigm</keyword>

    <!-- Keywords are incorporated into HTML output files for use by search engines. -->

    <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 the
      IP routing paradigm.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>

      <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 well suited for the use cases which
      require frequent mobile handover and 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 in future.</t>

      <t>The requirements for wireless systems, such as IoT and FWA (Fixed
      Wireless Access) applications, are becoming more diverse, and there are
      cases where the frequent mobile handover and per-session per-usage
      charging is not necessarily mandatory.</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 the
      IP 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 anchor="problem" numbered="true" toc="default">
      <name>Problem Definition</name>

      <t>The current tunnel session based mobile user plane has the following
      limitations and is getting hard to support new application
      requirements.</t>

      <ul>
        <li>Less suited for any-to-any communication</li>

        <li>Less suited for edge/distributed computing</li>

        <li>Less suited for fixed and mobile convergence (FMC) /
        wireless-wireline convergence (WWC)</li>

        <li>Limited control of the underlay path</li>
      </ul>

      <t>Mobile session information is a function of M,N (GTP-U start point
      and end point), whereas routing information is a function of N
      (destination). Therefore, for any-to-any communications, session based
      paradigm yields O(N^2), whereas IP routing paradigm yields
      O(N).&nbsp;</t>

      <t>Edge/distributed computing can be seen as a subset of any-to-any
      communication. IP Routing paradigm naturally supports ubiquitous
      computing.</t>

      <t>As for FMC/WWC, 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>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>The IP routing paradigm naturally removes these tunnel session based
      restrictions. Segment Routing enables fast protection, policy,
      multi-tenancy, and 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 anchor="advantage" numbered="true" toc="default">
      <name>SRv6 mobile user plane and the 5G use cases</name>

      <t>This section describes the advantages of applying SRv6 mobile user
      plane for 5G use cases.</t>

      <section anchor="slicing" numbered="true" toc="default">
        <name>Network Slicing</name>

        <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
        IP 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
        technology is described in <xref
        target="I-D.ali-teas-spring-ns-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 anchor="edge" numbered="true" toc="default">
        <name>Edge Computing</name>

        <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, data locality and privacy.</t>

        <t>Edge computing is more important than ever. This is because no
        matter how much 5G New Radio 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. <xref target="TS.23548"/> and <xref target="ETSI-MEC"/>
        describes how to properly select the UPF of adequate proximity.
        However, complicated and signaling-heavy mechanisms are required to
        branch traffic or properly use different UPFs. Also, if the UPF is
        distributed, seamless handover has to be compromised to some
        extent.</t>

        <t>IP 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 anchor="urllc" numbered="true" toc="default">
        <name>URLLC (Ultra-Reliable Low-Latency Communication) support</name>

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

        <ul>
          <li>Dual Connectivity based end-to-end Redundant User Plane
          Path</li>

          <li>Support of redundant transmission on N3/N9 interfaces</li>
        </ul>

        <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 anchor="coexist" numbered="true" toc="default">
      <name>Co-existence and Incremental Deployability</name>

      <t>The mobile domain is a compound domain that includes Radio, Mobile
      Packet Core, IP Network (access, backbone), and it is difficult to
      implement a ompletely new architecture, so co-existence and incremental
      deployability is required.</t>

      <t><xref target="I-D.ietf-dmm-srv6-mobile-uplane"/> defines the user
      plane convergence between GTP-U and SRv6, so that it can co-exist with
      the existing user plane as needed.</t>

      <t><xref target="I-D.mhkk-dmm-srv6mup-architecture"/> defines the MUP
      architecture for Distributed Mobility Management, which can be plugged
      into the existing mobile service architecture. In the architecture, MUP
      controller is to convert mobile session information to routing
      information.</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,
      and should not affect the security of the Internet</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</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">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      <?rfc include='reference.I-D.ietf-dmm-srv6-mobile-uplane.xml'?>

      <?rfc include='reference.I-D.mhkk-dmm-srv6mup-architecture.xml'?>

      <?rfc include='reference.I-D.ali-teas-spring-ns-building-blocks.xml'?>

      <?rfc include='reference.I-D.filsfils-spring-srv6-stateless-slice-id.xml'?>

      <!-- The recommended and simplest way to include a well known reference -->
    </references>

    <references title="Informative References">
      <!--
      <reference anchor="TS.29281">
        <front>
          <title>General Packet Radio System (GPRS) Tunnelling Protocol User
          Plane (GTPv1-U)</title>
          <author fullname="3GPP" surname="3GPP"/>
          <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 fullname="3GPP" surname="3GPP"/>
          <date month="April" year="2019"/>
        </front>
        <seriesInfo name="3GPP TR 29.892" value="16.1.0"/>
      </reference>

      <reference anchor="TS.29244">
        <front>
          <title>Interface between the Control Plane and the User Plane
          Nodes</title>
          <author fullname="3GPP" surname="3GPP"/>
          <date month="December" year="2017"/>
        </front>
        <seriesInfo name="3GPP TS 29.244" value="15.0.0"/>
      </reference>
 -->

      <reference anchor="ETSI-MEC">
        <front>
          <title>MEC in 5G Networks</title>

          <author fullname="ETSI" surname="ETSI"/>

          <date month="June" year="2018"/>
        </front>

        <seriesInfo name="ETSI White Paper" value="No.28"/>
      </reference>

      <reference anchor="TS.23548">
        <front>
          <title>5G system Enhacements for Edge Computing</title>

          <author fullname="3GPP" surname="3GPP"/>

          <date month="September" year="2021"/>
        </front>

        <seriesInfo name="3GPP TS 23.548" value="17.0.0"/>
      </reference>

      <reference anchor="TS.23558">
        <front>
          <title>Architecture for enabling Edge applications</title>

          <author fullname="3GPP" surname="3GPP"/>

          <date month="June" year="2021"/>
        </front>

        <seriesInfo name="3GPP TS 23.558" value="17.0.0"/>
      </reference>

      <reference anchor="TS.23501">
        <front>
          <title>System Architecture for the 5G System</title>

          <author fullname="3GPP" surname="3GPP"/>

          <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 fullname="3GPP" surname="3GPP"/>

          <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 fullname="3GPP" surname="3GPP"/>

          <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 fullname="BBF" surname="BBF"/>

          <date month="August" year="2020"/>
        </front>

        <seriesInfo name="BBF TR-407" value="Issue:1"/>
      </reference>
    </references>
  </back>
</rfc>
