<?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-ietf-dmm-srv6mob-arch-00"
     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-ietf-dmm-srv6mob-arch-00"/>

    <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="2024"/>

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

    <section anchor="coexist" numbered="true" toc="default">
      <name>Co-existence and Incremental Deployability</name>

      <t>Mobile networks are composed of radio, mobile packet core, and IP
      networks (access and backbone), with separate standard organizations and
      communities. Therefore, in the steady state, it is difficult to innovate
      to a new architecture and requires coexistence and incremental
      deployment.</t>

      <t><xref target="RFC9433"/> 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,
      mobile session information is transformed to routing information, and
      operated in L3VPN scheme.</t>
    </section>

    <section title="Security Considerations">
      <t>The deployment of this architecture is targeted in an administrative
      domain, and the functionality aimes to be domain specific.</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"/>

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

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.mhkk-dmm-srv6mup-architecture.xml"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ali-teas-spring-ns-building-blocks.xml"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/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>
