<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="info" consensus="true" docName="draft-ietf-dmm-srv6-mobile-uplane-24" number="9433" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2023-07-21T16:03:11" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane-24" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9433" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SRv6 Mobile User Plane">Segment Routing over IPv6 for the Mobile User Plane</title>
    <seriesInfo name="RFC" value="9433" stream="IETF"/>
    <author fullname="Satoru Matsushima" initials="S." surname="Matsushima" role="editor">
      <organization abbrev="SoftBank" showOnFrontPage="true">SoftBank</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <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." showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Belgium</country>
        </postal>
        <email>cf@cisco.com</email>
      </address>
    </author>
    <author fullname="Miya Kohno" initials="M." surname="Kohno">
      <organization abbrev="Cisco Systems, Inc." showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Japan</country>
        </postal>
        <email>mkohno@cisco.com</email>
      </address>
    </author>
    <author fullname="Pablo Camarillo Garvia" initials="P." surname="Camarillo" role="editor">
      <organization abbrev="Cisco Systems, Inc." showOnFrontPage="true">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Spain</country>
        </postal>
        <email>pcamaril@cisco.com</email>
      </address>
    </author>
    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization abbrev="Bell Canada" showOnFrontPage="true">Bell Canada</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>Canada</country>
        </postal>
        <email>daniel.voyer@bell.ca</email>
      </address>
    </author>
    <date month="07" year="2023"/>
    <area>int</area>
    <workgroup>dmm</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
        This document discusses the applicability of Segment Routing over IPv6
        (SRv6) to the user plane of mobile networks. The network programming
        nature of SRv6 accomplishes mobile user-plane functions in a simple
        manner.  The statelessness of SRv6 and its ability to control both
        service layer path and underlying transport can be beneficial to the
        mobile user plane, providing flexibility, end-to-end network slicing,
        and Service Level Agreement (SLA) control for various
        applications. </t>
      <t indent="0" pn="section-abstract-2">
        This document discusses how SRv6 could be used as the user plane of
        mobile networks. This document also specifies the SRv6
        Endpoint Behaviors required for mobility use cases.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.  
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9433" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-terminology">Conventions and Terminology</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions">Conventions</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-predefined-srv6-endpoint-be">Predefined SRv6 Endpoint Behaviors</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-motivation">Motivation</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-3gpp-reference-architecture">3GPP Reference Architecture</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-user-plane-modes">User-Plane Modes</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-traditional-mode">Traditional Mode</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-flow-uplink">Packet Flow - Uplink</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-flow-downlink">Packet Flow - Downlink</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-enhanced-mode">Enhanced Mode</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-flow-uplink-2">Packet Flow - Uplink</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-flow-downlink-2">Packet Flow - Downlink</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-scalability">Scalability</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-enhanced-mode-with-unchange">Enhanced Mode with Unchanged gNB GTP-U Behavior</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interworking-with-ipv6-gtp-">Interworking with IPv6 GTP-U</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interworking-with-ipv4-gtp-">Interworking with IPv4 GTP-U</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derivedContent="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extensions-to-the-interwork">Extensions to the Interworking Mechanisms</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-srv6-drop-in-interworking">SRv6 Drop-In Interworking</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-srv6-segment-endpoint-mobil">SRv6 Segment Endpoint Mobility Behaviors</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-argsmobsession">Args.Mob.Session</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endmap">End.MAP</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endmgtp6d">End.M.GTP6.D</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endmgtp6ddi">End.M.GTP6.D.Di</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endmgtp6e">End.M.GTP6.E</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endmgtp4e">End.M.GTP4.E</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.7">
                <t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent="6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hmgtp4d">H.M.GTP4.D</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.8">
                <t indent="0" pn="section-toc.1-1.6.2.8.1"><xref derivedContent="6.8" format="counter" sectionFormat="of" target="section-6.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-endlimit">End.Limit</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-srv6-supported-3gpp-pdu-ses">SRv6-Supported 3GPP PDU Session Types</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-network-slicing-considerati">Network Slicing Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-control-plane-consideration">Control Plane Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">In mobile networks, mobility systems provide connectivity over a
      wireless link to stationary and non-stationary nodes.  The user plane
      establishes a tunnel between the mobile node and its anchor node over
      IP-based backhaul and core networks. </t>
      <t indent="0" pn="section-1-2">This document specifies the applicability of SRv6 <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/> <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/> to mobile networks. </t>
      <t indent="0" pn="section-1-3">Segment Routing (SR) <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> is a
      source-routing architecture: a node steers a packet through an ordered
      list of instructions called "segments". A segment can represent any
      instruction, topological or service based.</t>
      <t indent="0" pn="section-1-4">SRv6 applied to mobile networks enables a mobile architecture based
      on source routing, where operators can explicitly indicate a route for
      the packets to and from the mobile node.  The SRv6 Endpoint nodes serve
      as mobile user-plane anchors.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-conventions-and-terminology">Conventions and Terminology</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      </t>
      <section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <dl spacing="normal" newline="false" indent="3" pn="section-2.1-1">
          <dt pn="section-2.1-1.1">CNF:</dt>
          <dd pn="section-2.1-1.2">Cloud-native Network Function</dd>
          <dt pn="section-2.1-1.3">NFV:</dt>
          <dd pn="section-2.1-1.4">Network Function Virtualization </dd>
          <dt pn="section-2.1-1.5">PDU:</dt>
          <dd pn="section-2.1-1.6">Packet Data Unit</dd>
          <dt pn="section-2.1-1.7">PDU Session:</dt>
          <dd pn="section-2.1-1.8">Context of a UE connected to a mobile
          network</dd>
          <dt pn="section-2.1-1.9">UE:</dt>
          <dd pn="section-2.1-1.10">User Equipment</dd>
          <dt pn="section-2.1-1.11">gNB:</dt>
          <dd pn="section-2.1-1.12">gNodeB <xref target="TS.23501" format="default" sectionFormat="of" derivedContent="TS.23501"/></dd>
          <dt pn="section-2.1-1.13">UPF:</dt>
          <dd pn="section-2.1-1.14">User Plane Function </dd>
          <dt pn="section-2.1-1.15">VNF:</dt>
          <dd pn="section-2.1-1.16">Virtual Network Function</dd>
          <dt pn="section-2.1-1.17">DN:</dt>
          <dd pn="section-2.1-1.18">Data Network</dd>
          <dt pn="section-2.1-1.19">Uplink:</dt>
          <dd pn="section-2.1-1.20">from the UE towards the DN</dd>
          <dt pn="section-2.1-1.21">Downlink:</dt>
          <dd pn="section-2.1-1.22">from the DN towards the UE</dd>
        </dl>
        <t indent="0" pn="section-2.1-2">The following terms used within this document are defined in <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>: Segment Routing, SR domain,
        Segment ID (SID), SRv6, SRv6 SID, Active Segment, SR Policy, and Binding SID (BSID).</t>
        <t indent="0" pn="section-2.1-3">The following terms used within this document are defined in <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>: Segment Routing Header (SRH) and Reduced
        SRH.</t>
        <t indent="0" pn="section-2.1-4">The following terms used within this document are defined in <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>: NH (next header), SL (the Segments
        Left field of the SRH), FIB (Forwarding Information Base), SA (Source
        Address), DA (Destination Address), and SRv6
        Endpoint Behavior.</t>
      </section>
      <section anchor="conventions" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-conventions">Conventions</name>
        <t indent="0" pn="section-2.2-1">An SR Policy is resolved to a SID list. A SID list is represented as &lt;S1, S2, S3&gt; where S1 is the first SID to visit, S2 is the second SID to visit, and S3 is the last SID to visit along the SR path.</t>
        <t indent="0" pn="section-2.2-2">(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet where:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-3">
          <li pn="section-2.2-3.1">Source Address is SA, Destination Address is DA, and
             next header is SRH</li>
          <li pn="section-2.2-3.2">
            <t indent="0" pn="section-2.2-3.2.1">SRH with SID list &lt;S1, S2, S3&gt; with Segments Left =
	     SL</t>
            <t indent="0" pn="section-2.2-3.2.2">Note the difference between the &lt;&gt; and ()
	     symbols. &lt;S1, S2, S3&gt; represents a SID list where S1 is the
	     first SID and S3 is the last SID to traverse.  (S3, S2, S1; SL)
	     represents the same SID list but encoded in the SRH format where
	     the rightmost SID in the SRH is the first SID and the leftmost
	     SID in the SRH is the last SID.  When referring to an SR Policy
	     in a high-level use case, it is simpler to use the &lt;S1, S2,
	     S3&gt; notation. When referring to an illustration of the
	     detailed packet behavior, the (S3, S2, S1; SL) notation is more
	     convenient.</t>
          </li>
          <li pn="section-2.2-3.3">The payload of the packet is omitted.</li>
        </ul>
        <t indent="0" pn="section-2.2-4">(SA1,DA1) (SA2, DA2) represents an IPv6 packet where:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-5">
          <li pn="section-2.2-5.1">Source Address is SA1, Destination Address is DA1, and
                next header is IP.</li>
          <li pn="section-2.2-5.2">Source Address is SA2, and Destination Address is DA2.</li>
        </ul>
        <t indent="0" pn="section-2.2-6">Throughout the document, the representation SRH[n] is used as a
        shorter representation of Segment List[n], as defined in <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>.</t>
        <t indent="0" pn="section-2.2-7">This document uses the following conventions throughout the
        different examples:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.2-8">
          <li pn="section-2.2-8.1">gNB::1 is an IPv6 address (SID) assigned to the gNB.</li>
          <li pn="section-2.2-8.2">U1::1 is an IPv6 address (SID) assigned to UPF1.</li>
          <li pn="section-2.2-8.3">U2::1 is an IPv6 address (SID) assigned to UPF2.</li>
          <li pn="section-2.2-8.4">U2:: is the Locator of UPF2.</li>
        </ul>
      </section>
      <section anchor="srv6-funcs" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-predefined-srv6-endpoint-be">Predefined SRv6 Endpoint Behaviors</name>
        <t indent="0" pn="section-2.3-1">
	    The following SRv6 Endpoint Behaviors are used throughout this document. They are defined in
	    <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>.
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-2.3-2">
          <li pn="section-2.3-2.1">End.DT4: Decapsulation and Specific IPv4 Table Lookup</li>
          <li pn="section-2.3-2.2">End.DT6: Decapsulation and Specific IPv6 Table Lookup</li>
          <li pn="section-2.3-2.3">End.DT46: Decapsulation and Specific IP Table Lookup</li>
          <li pn="section-2.3-2.4">End.DX4: Decapsulation and IPv4 Cross-Connect</li>
          <li pn="section-2.3-2.5">End.DX6: Decapsulation and IPv6 Cross-Connect</li>
          <li pn="section-2.3-2.6">End.DX2: Decapsulation and L2 Cross-Connect</li>
          <li pn="section-2.3-2.7">End.T: Endpoint with specific IPv6 Table Lookup</li>
        </ul>
        <t indent="0" pn="section-2.3-3">
	    This document defines new SRv6 Endpoint Behaviors in <xref target="srv6_functions" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t>
      </section>
    </section>
    <section anchor="motivations" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-motivation">Motivation</name>
      <t indent="0" pn="section-3-1"> Mobile networks are becoming more challenging to operate.  On one
      hand, traffic is constantly growing, and latency requirements are
      tighter; on the other hand, there are new use cases like distributed NFV
      Infrastructure that are also challenging network operations. On top of
      this, the number of devices connected is steadily growing, causing
      scalability problems in mobile entities as the state to maintain keeps
      increasing.</t>
      <t indent="0" pn="section-3-2"> The current architecture of mobile networks does not take into
      account the underlying transport. The user plane is rigidly fragmented
      into radio access, core, and service networks that connected by tunneling
      according to user-plane roles such as access and anchor nodes. These
      factors have made it difficult for the operator to optimize and operate
      the data path.
      </t>
      <t indent="0" pn="section-3-3"> In the meantime,
	applications have shifted to use IPv6, and network operators
	have started adopting IPv6 as their IP transport.
        SRv6, the IPv6 data plane instantiation of Segment Routing
	<xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>, integrates both
	the application data path and the underlying transport layer into
	a single protocol, allowing operators to optimize the network in a
	simplified manner and removing forwarding state from the network. It is also
  suitable for virtualized environments, like VNF/CNF-to-VNF/CNF networking. SRv6 has been deployed in dozens of networks <xref target="I-D.matsushima-spring-srv6-deployment-status" format="default" sectionFormat="of" derivedContent="SRV6-DEPLOY-STAT"/>.</t>
      <t indent="0" pn="section-3-4"> SRv6 defines the network programming concept <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>.
  Applied to mobility, SRv6 can provide the user-plane behaviors needed
  for mobility management.  SRv6 takes advantage of the underlying transport
  awareness and flexibility together with the ability to also include services to optimize the end-to-end mobile data plane.</t>
      <t indent="0" pn="section-3-5">The use cases for SRv6 mobility are discussed in <xref target="I-D.camarilloelmalky-springdmm-srv6-mob-usecases" format="default" sectionFormat="of" derivedContent="SRV6-MOB-USECASES"/>, and the architectural benefits are discussed in <xref target="I-D.kohno-dmm-srv6mob-arch" format="default" sectionFormat="of" derivedContent="SRV6-MOB-ARCH-DISCUSS"/>. </t>
    </section>
    <section anchor="scenarios" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-3gpp-reference-architecture">3GPP Reference Architecture</name>
      <t indent="0" pn="section-4-1"> This section presents the 3GPP reference architecture and possible deployment
        scenarios.</t>
      <t indent="0" pn="section-4-2"> <xref target="fig_5g-ref-arch" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows a reference diagram from
        the 5G packet core architecture <xref target="TS.23501" format="default" sectionFormat="of" derivedContent="TS.23501"/>.</t>
      <t indent="0" pn="section-4-3"> The user plane described in this document does not depend on any
	specific architecture.  The 5G packet core architecture as shown is
	based on the 3GPP standards.</t>
      <figure anchor="fig_5g-ref-arch" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-3gpp-5g-reference-architect">3GPP 5G Reference Architecture</name>
        <artwork align="center" name="" type="" alt="" pn="section-4-4.1">
                                +-----+
                                | AMF |
                               /+-----+
                              /    | [N11]
                       [N2]  /  +-----+
                     +------/   | SMF |
                    /           +-----+
                   /              / \
                  /              /   \  [N4]
                 /              /     \                    ________
                /              /       \                  /        \
+--+      +-----+ [N3] +------+  [N9]  +------+  [N6]    /          \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \    DN    /
+--+      +-----+      +------+        +------+           \________/
</artwork>
      </figure>
      <dl spacing="normal" newline="false" indent="3" pn="section-4-5">
        <dt pn="section-4-5.1">UE:</dt>
        <dd pn="section-4-5.2">User Equipment</dd>
        <dt pn="section-4-5.3">gNB:</dt>
        <dd pn="section-4-5.4">gNodeB with N3 interface towards packet core (and N2 for control
	plane)</dd>
        <dt pn="section-4-5.5">UPF1:</dt>
        <dd pn="section-4-5.6">UPF with Interfaces N3 and N9 (and N4 for control plane)</dd>
        <dt pn="section-4-5.7">UPF2:</dt>
        <dd pn="section-4-5.8">UPF with Interfaces N9 and N6 (and N4 for control plane)</dd>
        <dt pn="section-4-5.9">SMF:</dt>
        <dd pn="section-4-5.10">Session Management Function</dd>
        <dt pn="section-4-5.11">AMF:</dt>
        <dd pn="section-4-5.12">Access and Mobility Management Function</dd>
        <dt pn="section-4-5.13">DN:</dt>
        <dd pn="section-4-5.14">Data Network, e.g., operator services and Internet access </dd>
      </dl>
      <t indent="0" pn="section-4-6"> This reference diagram does not depict a UPF that is only connected
	to N9 interfaces, although the mechanisms defined in this document
	also work in such a case.</t>
      <t indent="0" pn="section-4-7"> Each session from a UE gets assigned to a UPF. Sometimes multiple
      UPFs may be used, providing richer service functions.  A UE gets its
      IPv4 address, or IPv6 prefix, from the DHCP block of its UPF. The UPF
      advertises that IP address block toward the Internet, ensuring that
      return traffic is routed to the right UPF. </t>
    </section>
    <section anchor="uplane-functions" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-user-plane-modes">User-Plane Modes</name>
      <t indent="0" pn="section-5-1">This section introduces an SRv6-based mobile user plane. It presents
      two different "modes" that vary with respect to the use of SRv6.</t>
      <t indent="0" pn="section-5-2">The first mode is the "Traditional mode", which inherits the current
      3GPP mobile architecture. In this mode, the <xref target="TS.29281" format="default" sectionFormat="of" derivedContent="TS.29281">GTP-U protocol</xref> is replaced by SRv6. However, the
      N3, N9, and N6 interfaces are still point-to-point interfaces with no
      intermediate waypoints as in the current mobile network
      architecture.</t>
      <t indent="0" pn="section-5-3"> The second mode is the "Enhanced mode".  This is an evolution from
      the "Traditional mode". In this mode, the N3, N9, or N6 interfaces have
      intermediate waypoints (SIDs) that are used for traffic engineering or
      VNF purposes transparent to 3GPP functionalities. This results in
      optimal end-to-end policies across the mobile network with transport and
      services awareness.</t>
      <t indent="0" pn="section-5-4">In both the Traditional and the Enhanced modes, this document assumes
      that the gNB as well as the UPFs are SR-aware (N3, N9, and potentially
      N6 interfaces are SRv6).</t>
      <t indent="0" pn="section-5-5">In addition to those two modes, this document introduces three
      mechanisms for interworking with legacy access networks (those where the
      N3 interface is unmodified). In this document, they are introduced as a
      variant to the Enhanced mode, but they are equally applicable to the
      Traditional mode.</t>
      <t indent="0" pn="section-5-6">One of these mechanisms is designed to interwork with legacy gNBs
      using GTP-U/IPv4. The second mechanism is designed to interwork with
      legacy gNBs using GTP-U/IPv6. The third mechanism is another mode that
      allows deploying SRv6 when legacy gNBs and UPFs still run GTP-U.</t>
      <t indent="0" pn="section-5-7"> This document uses the SRv6 Endpoint Behaviors defined in
      <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/> as well as the new SRv6
      Endpoint Behaviors designed for the mobile user plane that are
      defined in <xref target="srv6_functions" format="default" sectionFormat="of" derivedContent="Section 6"/> of this
      document.
      </t>
      <section anchor="traditional_mode" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-traditional-mode">Traditional Mode</name>
        <t indent="0" pn="section-5.1-1"> In the Traditional mode, the existing mobile UPFs remain unchanged
        with the sole exception of the use of SRv6 as the data plane instead
        of GTP-U.  There is no impact to the rest of the mobile system.</t>
        <t indent="0" pn="section-5.1-2"> In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1
        with a specific GTP-U tunnel (Tunnel Endpoint Identifier (TEID)). This
        1-for-1 mapping is mirrored here to replace GTP-U encapsulation with
        the SRv6 encapsulation, while not changing anything else. There will
        be a unique SRv6 SID associated with each PDU Session, and the SID
        list only contains a single SID.</t>
        <t indent="0" pn="section-5.1-3"> The Traditional mode minimizes the required changes to the mobile
        system; hence, it is a good starting point for forming common
        ground.</t>
        <t indent="0" pn="section-5.1-4"> The gNB/UPF control plane (N2/N4 interface) is unchanged;
        specifically, a single IPv6 address is provided to the gNB. The same
        control plane signaling is used, and the gNB/UPF decides to use SRv6
        based on signaled GTP-U parameters per local policy. The only
        information from the GTP-U parameters used for the SRv6 policy is the
        TEID, QFI (QoS Flow Identifier), and the IPv6 Destination Address.</t>
        <t indent="0" pn="section-5.1-5"> Our example topology is shown in <xref target="fig_traditional" format="default" sectionFormat="of" derivedContent="Figure 2"/>.  The gNB and the UPFs are SR-aware.  In the
        descriptions of the uplink and downlink packet flow, A is an IPv6
        address of the UE, and Z is an IPv6 address reachable within the DN.
        End.MAP, a new SRv6 Endpoint Behavior defined in <xref target="end-map-function" format="default" sectionFormat="of" derivedContent="Section 6.2"/>, is used.</t>
        <figure anchor="fig_traditional" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-traditional-mode-example-to">Traditional Mode - Example Topology</name>
          <artwork align="center" name="" type="" alt="" pn="section-5.1-6.1">
                                                           ________
                  SRv6           SRv6                     /        \
+--+      +-----+ [N3] +------+  [N9]  +------+  [N6]    /          \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \    DN    /
+--+      +-----+      +------+        +------+           \________/
         SRv6 node     SRv6 node       SRv6 node
</artwork>
        </figure>
        <section anchor="traditional_up" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-packet-flow-uplink">Packet Flow - Uplink</name>
          <t indent="0" pn="section-5.1.1-1"> The uplink packet flow is as follows:</t>
          <artwork align="center" name="" type="" alt="" pn="section-5.1.1-2">
UE_out  : (A,Z)
gNB_out : (gNB, U1::1) (A,Z)     -&gt; H.Encaps.Red &lt;U1::1&gt;
UPF1_out: (gNB, U2::1) (A,Z)     -&gt; End.MAP
UPF2_out: (A,Z)                  -&gt; End.DT4 or End.DT6
</artwork>
          <t indent="0" pn="section-5.1.1-3"> When the UE packet arrives at the gNB, the gNB performs an
          H.Encaps.Red operation. Since there is only one SID, there is no
          need to push an SRH (reduced SRH). gNB only adds an outer IPv6
          header with IPv6 DA U1::1. gNB obtains the SID U1::1 from the
          existing control plane (N2 interface). U1::1 represents an anchoring
          SID specific for that session at UPF1.</t>
          <t indent="0" pn="section-5.1.1-4"> When the packet arrives at UPF1, the SID U1::1 is associated
          with the End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 with
          U2::1, which belongs to the next UPF (U2).</t>
          <t indent="0" pn="section-5.1.1-5"> When the packet arrives at UPF2, the SID U2::1 corresponds to an
          End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates
          the packet, performs a lookup in a specific table associated with
          that mobile network, and forwards the packet toward the DN.</t>
        </section>
        <section anchor="traditional_dn" numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-packet-flow-downlink">Packet Flow - Downlink</name>
          <t indent="0" pn="section-5.1.2-1">The downlink packet flow is as follows:</t>
          <artwork align="center" name="" type="" alt="" pn="section-5.1.2-2">
UPF2_in : (Z,A)
UPF2_out: (U2::, U1::2) (Z,A)    -&gt; H.Encaps.Red &lt;U1::2&gt;
UPF1_out: (U2::, gNB::1) (Z,A)   -&gt; End.MAP
gNB_out : (Z,A)                  -&gt; End.DX4, End.DX6, End.DX2
</artwork>
          <t indent="0" pn="section-5.1.2-3"> When the packet arrives at the UPF2, the UPF2 maps that flow
          into a PDU Session. This PDU Session is associated with the segment
          endpoint &lt;U1::2&gt;.  UPF2 performs an H.Encaps.Red operation,
          encapsulating the packet into a new IPv6 header with no SRH since
          there is only one SID.</t>
          <t indent="0" pn="section-5.1.2-4"> Upon packet arrival on UPF1, the SID U1::2 is a local SID
          associated with the End.MAP SRv6 Endpoint Behavior. It maps the SID
          to the next anchoring point and replaces U1::2 with gNB::1, which
          belongs to the next hop.</t>
          <t indent="0" pn="section-5.1.2-5"> Upon packet arrival on gNB, the SID gNB::1 corresponds to an
          End.DX4, End.DX6, or End.DX2 behavior (depending on the PDU Session
          Type). The gNB decapsulates the packet, removing the IPv6 header and
          all its extensions headers, and forwards the traffic toward the
          UE.</t>
        </section>
      </section>
      <section anchor="enhanced_mode" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-enhanced-mode">Enhanced Mode</name>
        <t indent="0" pn="section-5.2-1"> Enhanced mode improves scalability, provides traffic engineering
        capabilities, and allows service programming <xref target="I-D.ietf-spring-sr-service-programming" format="default" sectionFormat="of" derivedContent="SR-SERV-PROG"/>,
        thanks to the use of multiple SIDs in the SID list (instead of a
        direct connectivity in between UPFs with no intermediate waypoints as
        in Traditional mode).</t>
        <t indent="0" pn="section-5.2-2">Thus, the main difference is that the SR Policy <bcp14>MAY</bcp14>
        include SIDs for traffic engineering and service programming in
        addition to the anchoring SIDs at UPFs.</t>
        <t indent="0" pn="section-5.2-3">Additionally, in this mode, the operator may choose to aggregate
        several devices under the same SID list (e.g., stationary residential
        meters (water and energy) connected to the same cell) to improve
        scalability.</t>
        <t indent="0" pn="section-5.2-4">The gNB/UPF control plane (N2/N4 interface) is unchanged;
        specifically, a single IPv6 address is provided to the gNB. A local
        policy instructs the gNB to use SRv6.</t>
        <t indent="0" pn="section-5.2-5"> The gNB resolves the IP address received via the control plane
        into a SID list. The resolution mechanism is out of the scope of this
        document.</t>
        <t indent="0" pn="section-5.2-6"> Note that the SIDs <bcp14>MAY</bcp14> use the argument <xref target="arguments-for-mobility" format="default" sectionFormat="of" derivedContent="Section 6.1">Args.Mob.Session
          </xref> if required by the UPFs.</t>
        <t indent="0" pn="section-5.2-7"> <xref target="fig_enhanced" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows an Enhanced
        mode topology.  The gNB and the UPF are SR-aware.  The figure
	shows two service segments,
        S1 and C1.  S1 represents a VNF in the network, and C1
        represents an intermediate router used for traffic engineering
        purposes to enforce a low-latency path in the network.  Note that
        neither S1 nor C1 are required to have an N4 interface.</t>
        <figure anchor="fig_enhanced" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-enhanced-mode-example-topol">Enhanced Mode - Example Topology</name>
          <artwork align="center" name="" type="" alt="" pn="section-5.2-8.1">
                                 +----+  SRv6               _______
                 SRv6          --| C1 |--[N3]              /       \
+--+    +-----+  [N3]         /  +----+  \  +------+ [N6] /         \
|UE|----| gNB |--       SRv6 /    SRv6    --| UPF1 |------\   DN    /
+--+    +-----+  \      [N3]/      TE       +------+       \_______/
       SRv6 node  \ +----+ /               SRv6 node
                   -| S1 |-
                    +----+
                   SRv6 node
                     VNF
</artwork>
        </figure>
        <section anchor="enhanced_uplink" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.1">
          <name slugifiedName="name-packet-flow-uplink-2">Packet Flow - Uplink</name>
          <t indent="0" pn="section-5.2.1-1">The uplink packet flow is as follows:</t>
          <artwork align="center" name="" type="" alt="" pn="section-5.2.1-2">
UE_out  : (A,Z)
gNB_out : (gNB, S1)(U1::1, C1; SL=2)(A,Z)-&gt;H.Encaps.Red&lt;S1,C1,U1::1&gt;
S1_out  : (gNB, C1)(U1::1, C1; SL=1)(A,Z)
C1_out  : (gNB, U1::1)(A,Z)              -&gt;End with PSP
UPF1_out: (A,Z)                          -&gt;End.DT4,End.DT6,End.DT2U
</artwork>
          <t indent="0" pn="section-5.2.1-3"> UE sends its packet (A,Z) on a specific bearer to its
          gNB.  gNB's control plane associates that session from the UE(A)
          with the IPv6 address B.  gNB resolves B into a SID list  &lt;S1,
          C1, U1::1&gt;. </t>
          <t indent="0" pn="section-5.2.1-4"> When gNB transmits the packet, it contains all the segments of
          the SR Policy. The SR Policy includes segments for traffic
          engineering (C1) and for service programming (S1). </t>
          <t indent="0" pn="section-5.2.1-5"> Nodes S1 and C1 perform their related Endpoint functionality and
          forward the packet. The "End with PSP" functionality refers to the
          Endpoint Behavior with Penultimate Segment Popping as defined in
          <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/>.</t>
          <t indent="0" pn="section-5.2.1-6"> When the packet arrives at UPF1, the active segment (U1::1) is an End.DT4/End.DT6/End.DT2U, which performs the
          decapsulation (removing the IPv6 header with all its extension
          headers) and forwards toward the DN.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2">
          <name slugifiedName="name-packet-flow-downlink-2">Packet Flow - Downlink</name>
          <t indent="0" pn="section-5.2.2-1">The downlink packet flow is as follows:</t>
          <artwork align="center" name="" type="" alt="" pn="section-5.2.2-2">
UPF1_in : (Z,A)                             -&gt;UPF1 maps the flow w/
                                              SID list &lt;C1,S1, gNB&gt;
UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)-&gt;H.Encaps.Red
C1_out  : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A)
S1_out  : (U1::1, gNB::1)(Z,A)              -&gt;End with PSP
gNB_out : (Z,A)                             -&gt;End.DX4/End.DX6/End.DX2
</artwork>
          <t indent="0" pn="section-5.2.2-3">When the packet arrives at the UPF1, the UPF1 maps that
          particular flow into a UE PDU Session. This UE PDU Session is
          associated with the policy &lt;C1, S1, gNB&gt;. The UPF1 performs a
          H.Encaps.Red operation, encapsulating the packet into a new IPv6
          header with its corresponding SRH.</t>
          <t indent="0" pn="section-5.2.2-4">The nodes C1 and S1 perform their related Endpoint processing.</t>
          <t indent="0" pn="section-5.2.2-5">Once the packet arrives at the gNB, the IPv6 DA corresponds to an
          End.DX4, End.DX6, or End.DX2 behavior at the gNB (depending on the
          underlying traffic).  The gNB decapsulates the packet, removing the
          IPv6 header, and forwards the traffic towards the UE. The SID gNB::1
          is one example of a SID associated to this service.</t>
          <t indent="0" pn="section-5.2.2-6">Note that there are several means to provide the UE session
          aggregation. The decision about which one to use is a local decision
          made by the operator. One option is to use <xref target="arguments-for-mobility" format="default" sectionFormat="of" derivedContent="Section 6.1">Args.Mob.Session
            </xref>. Another option comprises the gNB performing an IP lookup on
          the inner packet by using the End.DT4, End.DT6, and End.DT2U
          behaviors.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3">
          <name slugifiedName="name-scalability">Scalability</name>
          <t indent="0" pn="section-5.2.3-1">The Enhanced mode improves scalability since it allows the
          aggregation of several UEs under the same SID list. For example, in
          the case of stationary residential meters that are connected to the
          same cell, all such devices can share the same SID list.  This
          improves scalability compared to Traditional mode (unique SID per
          UE) and compared to GTP-U (TEID per UE).</t>
        </section>
      </section>
      <section anchor="enhanced_gtp" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-enhanced-mode-with-unchange">Enhanced Mode with Unchanged gNB GTP-U Behavior</name>
        <t indent="0" pn="section-5.3-1"> This section describes two mechanisms for interworking with legacy
        gNBs that still use GTP-U: one for IPv4 and another for IPv6.</t>
        <t indent="0" pn="section-5.3-2"> In the interworking scenarios illustrated in <xref target="fig_interworking" format="default" sectionFormat="of" derivedContent="Figure 4"/>, the gNB does not support
        SRv6.  The gNB supports GTP-U encapsulation over IPv4 or IPv6.  To
        achieve interworking, an SR Gateway (SRGW) entity is added. The SRGW
        is a new entity that maps the GTP-U traffic into SRv6. It is deployed
        at the boundary of the SR domain and performs the mapping
        functionality for inbound and outbound traffic.</t>
        <t indent="0" pn="section-5.3-3"> The SRGW is not an anchor point and maintains very little state.
	    For this reason,
	    both IPv4 and IPv6 methods scale to millions of UEs.</t>
        <figure anchor="fig_interworking" align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-example-topology-for-interw">Example Topology for Interworking</name>
          <artwork align="center" name="" type="" alt="" pn="section-5.3-4.1">
                                                          _______
                 IP GTP-U        SRv6                    /       \
+--+      +-----+ [N3] +------+  [N9]  +------+  [N6]   /         \
|UE|------| gNB |------| SRGW |--------| UPF  |---------\   DN    /
+--+      +-----+      +------+        +------+          \_______/
                      SR Gateway       SRv6 node
</artwork>
        </figure>
        <t indent="0" pn="section-5.3-5">Both of the mechanisms described in this section are applicable to the Traditional mode and the Enhanced mode.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3.1">
          <name slugifiedName="name-interworking-with-ipv6-gtp-">Interworking with IPv6 GTP-U</name>
          <t indent="0" pn="section-5.3.1-1">In this interworking mode, the gNB at the N3 interface uses GTP-U
	      over IPv6.</t>
          <t indent="0" pn="section-5.3.1-2">Key points:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3.1-3">
            <li pn="section-5.3.1-3.1"> The gNB is unchanged (control plane or user plane) and
            encapsulates into GTP-U (N3 interface is not modified).</li>
            <li pn="section-5.3.1-3.2">
            The 5G control plane towards the gNB (N2 interface) is unmodified,
            though multiple UPF addresses need to be used. One IPv6 address
            (i.e., a BSID at the SRGW) is needed per &lt;SLA, PDU Session
            Type&gt;. The SRv6 SID is different depending on the required
            &lt;SLA, PDU Session Type&gt; combination.</li>
            <li pn="section-5.3.1-3.3"> In the uplink, the SRGW removes the GTP-U header, finds the
            SID list related to the IPv6 DA, and adds SRH with the SID
            list.</li>
            <li pn="section-5.3.1-3.4"> There is no state for the downlink at the SRGW.</li>
            <li pn="section-5.3.1-3.5"> There is simple state in the uplink at the SRGW; using
            Enhanced mode results in fewer SR Policies on this node.  An SR
            Policy is shared across UEs as long as they belong to the same
            context (i.e., tenant). A set of many different policies (i.e.,
            different SLAs) increases the amount of state required.</li>
            <li pn="section-5.3.1-3.6"> When a packet from the UE leaves the gNB, it is SR-routed.

		This simplifies network slicing
		<xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/>.</li>
            <li pn="section-5.3.1-3.7"> In the uplink, the SRv6 BSID steers traffic
		into an SR Policy when it arrives at the SRGW.</li>
          </ul>
          <t indent="0" pn="section-5.3.1-4"> An example topology is shown in
	      <xref target="fig_interworking_ipv6" format="default" sectionFormat="of" derivedContent="Figure 5"/>.</t>
          <t indent="0" pn="section-5.3.1-5"> S1 and C1 are two service segments.
	      S1 represents a VNF in the network, and C1 represents a router
	      configured for traffic engineering.</t>
          <figure anchor="fig_interworking_ipv6" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-enhanced-mode-with-unchanged">Enhanced Mode with Unchanged gNB IPv6/GTP-U Behavior</name>
            <artwork align="center" name="" type="" alt="" pn="section-5.3.1-6.1">
                               +----+
             IPv6/GTP-U       -| S1 |-                            ___
+--+  +-----+ [N3]           / +----+ \                          /
|UE|--| gNB |-         SRv6 /   SRv6   \ +----+   +------+ [N6] /
+--+  +-----+ \        [N9]/     VNF    -| C1 |---| UPF2 |------\  DN
        GTP-U  \ +------+ /              +----+   +------+       \___
                -| SRGW |-                SRv6      SRv6
                 +------+                  TE
                SR Gateway
</artwork>
          </figure>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-5.3.1.1">
            <name slugifiedName="name-packet-flow-uplink-3">Packet Flow - Uplink</name>
            <t indent="0" pn="section-5.3.1.1-1">The uplink packet flow is as follows:</t>
            <artwork align="center" name="" type="" alt="" pn="section-5.3.1.1-2">
UE_out  : (A,Z)
gNB_out : (gNB, B)(GTP: TEID T)(A,Z)       -&gt; Interface N3 unmodified
                                              (IPv6/GTP)
SRGW_out: (SRGW, S1)(U2::T, C1; SL=2)(A,Z) -&gt; B is an End.M.GTP6.D
                                              SID at the SRGW
S1_out  : (SRGW, C1)(U2::T, C1; SL=1)(A,Z)
C1_out  : (SRGW, U2::T)(A,Z)               -&gt; End with PSP
UPF2_out: (A,Z)                            -&gt; End.DT4 or End.DT6
</artwork>
            <t indent="0" pn="section-5.3.1.1-3"> The UE sends a packet destined to Z toward the gNB on a
            specific bearer for that session. The gNB, which is unmodified,
            encapsulates the packet into IPv6, UDP, and GTP-U headers.  The
            IPv6 DA B and the GTP-U TEID T are the ones received in the N2
            interface.</t>
            <t indent="0" pn="section-5.3.1.1-4"> The IPv6 address that was signaled over the N2 interface for
            that UE PDU Session, B, is now the IPv6 DA. B is an SRv6
            Binding SID at the SRGW.  Hence, the packet is routed to the
            SRGW.</t>
            <t indent="0" pn="section-5.3.1.1-5"> When the packet arrives at the SRGW, the SRGW identifies B as
            an End.M.GTP6.D Binding SID (see <xref target="End-M-GTP6-D" format="default" sectionFormat="of" derivedContent="Section 6.3"/>).  Hence, the SRGW removes the IPv6, UDP, and
            GTP-U headers and pushes an IPv6 header with its own SRH
            containing the SIDs bound to the SR Policy associated with this
            Binding SID.  There is at least one instance of the End.M.GTP6.D SID
            per PDU type.</t>
            <t indent="0" pn="section-5.3.1.1-6"> S1 and C1 perform their related Endpoint functionality and
            forward the packet.</t>
            <t indent="0" pn="section-5.3.1.1-7"> When the packet arrives at UPF2, the active segment is (U2::T),
            which is bound to End.DT4/6.  UPF2 then decapsulates (removing the
            outer IPv6 header with all its extension headers) and forwards the
            packet toward the DN.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-5.3.1.2">
            <name slugifiedName="name-packet-flow-downlink-3">Packet Flow - Downlink</name>
            <t indent="0" pn="section-5.3.1.2-1">The downlink packet flow is as follows:</t>
            <artwork align="center" name="" type="" alt="" pn="section-5.3.1.2-2">
UPF2_in : (Z,A)                           -&gt; UPF2 maps the flow with
                                             &lt;C1, S1, SRGW::TEID,gNB&gt;
UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -&gt; H.Encaps.Red
C1_out  : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A)
S1_out  : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A)
SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A)   -&gt; SRGW/96 is End.M.GTP6.E
gNB_out : (Z,A)
</artwork>
            <t indent="0" pn="section-5.3.1.2-3"> When a packet destined to A arrives at the UPF2, the UPF2
		performs a lookup in the table associated to A and finds the
		SID list &lt;C1, S1, SRGW::TEID, gNB&gt;. The UPF2 performs
		an H.Encaps.Red operation, encapsulating the packet into
		a new IPv6 header with its corresponding SRH.</t>
            <t indent="0" pn="section-5.3.1.2-4"> C1 and S1 perform their related Endpoint processing.</t>
            <t indent="0" pn="section-5.3.1.2-5"> Once the packet arrives at the SRGW, the SRGW identifies the
		active SID as an End.M.GTP6.E function. The SRGW removes
		the IPv6 header and all its extensions headers. The SRGW
		generates new IPv6, UDP, and GTP-U headers. The new IPv6 DA
		is the gNB, which is the last SID in the received SRH.
		The TEID in the generated GTP-U header is also an argument of the
		received End.M.GTP6.E SID. The SRGW pushes the headers to
		the packet and forwards the packet toward the gNB.  There
		is one instance of the End.M.GTP6.E SID per PDU type.</t>
            <t indent="0" pn="section-5.3.1.2-6"> Once the packet arrives at the gNB, the packet is a regular
		IPv6/GTP-U packet. The gNB looks for the specific radio bearer
		for that TEID and forwards it on the bearer. This gNB behavior
		is not modified from current and previous generations.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-5.3.1.3">
            <name slugifiedName="name-scalability-2">Scalability</name>
            <t indent="0" pn="section-5.3.1.3-1"> For downlink traffic, the SRGW is stateless. All the state
            is in the SRH pushed by the UPF2.  The UPF2 must have the UE
            state since it is the UE's session anchor point.</t>
            <t indent="0" pn="section-5.3.1.3-2"> For uplink traffic, the state at the SRGW does not
            necessarily need to be unique per PDU Session; the SR Policy can
            be shared among UEs.  This enables more scalable SRGW deployments
            compared to a solution holding millions of states, one or more per
            UE.</t>
          </section>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3.2">
          <name slugifiedName="name-interworking-with-ipv4-gtp-">Interworking with IPv4 GTP-U</name>
          <t indent="0" pn="section-5.3.2-1"> In this interworking mode, the gNB uses GTP over IPv4 in the N3
          interface.</t>
          <t indent="0" pn="section-5.3.2-2"> Key points:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.3.2-3">
            <li pn="section-5.3.2-3.1"> The gNB is unchanged and encapsulates packets into GTP-U (the
            N3 interface is not modified).</li>
            <li pn="section-5.3.2-3.2">N2 signaling is not changed, though multiple UPF addresses
            need to be provided -- one for each PDU Session Type.</li>
            <li pn="section-5.3.2-3.3"> In the uplink, traffic is classified by SRGW's classification
            engine and steered into an SR Policy.  The SRGW may be implemented
            in a UPF or as a separate entity. How the classification engine
            rules are set up is outside the scope of this document, though one
            example is using BGP signaling from a Mobile User Plane (MUP) Controller
            <xref target="I-D.mhkk-dmm-srv6mup-architecture" format="default" sectionFormat="of" derivedContent="MUP-SR-ARCH"/>.</li>
            <li pn="section-5.3.2-3.4"> SRGW removes the GTP-U header, finds the SID list related to DA,
            and adds an SRH with the SID list.</li>
          </ul>
          <t indent="0" pn="section-5.3.2-4"> An example topology is shown in <xref target="fig_interworking_ipv4" format="default" sectionFormat="of" derivedContent="Figure 6"/>. In this mode, the
          gNB is an unmodified gNB using IPv4/GTP.  The UPFs are SR-aware.  As
          before, the SRGW maps the IPv4/GTP-U traffic to SRv6.</t>
          <t indent="0" pn="section-5.3.2-5"> S1 and C1 are two service segment endpoints.  S1 represents a
          VNF in the network, and C1 represents a router configured for
          traffic engineering.</t>
          <figure anchor="fig_interworking_ipv4" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-enhanced-mode-with-unchanged-">Enhanced Mode with Unchanged gNB IPv4/GTP-U Behavior</name>
            <artwork align="center" name="" type="" alt="" pn="section-5.3.2-6.1">
                               +----+
             IPv4/GTP-U       -| S1 |-                            ___
+--+  +-----+ [N3]           / +----+ \                          /
|UE|--| gNB |-         SRv6 /   SRv6   \ +----+   +------+ [N6] /
+--+  +-----+ \        [N9]/     VNF    -| C1 |---| UPF2 |------\  DN
        GTP-U  \ +------+ /              +----+   +------+       \___
                -| UPF1 |-                SRv6      SRv6
                 +------+                  TE
                SR Gateway
</artwork>
          </figure>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-5.3.2.1">
            <name slugifiedName="name-packet-flow-uplink-4">Packet Flow - Uplink</name>
            <t indent="0" pn="section-5.3.2.1-1">The uplink packet flow is as follows:</t>
            <artwork align="center" name="" type="" alt="" pn="section-5.3.2.1-2">
gNB_out : (gNB, B)(GTP: TEID T)(A,Z)          -&gt; Interface N3
                                                 unchanged IPv4/GTP
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z)    -&gt; H.M.GTP4.D function
S1_out  : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out  : (SRGW, U2::1) (A,Z)                 -&gt; PSP
UPF2_out: (A,Z)                               -&gt; End.DT4 or End.DT6
</artwork>
            <t indent="0" pn="section-5.3.2.1-3"> The UE sends a packet destined to Z toward the gNB on a
            specific bearer for that session. The gNB, which is unmodified,
            encapsulates the packet into a new IPv4, UDP, and GTP-U headers.
            The IPv4 DA, B, and the GTP-UTEID are the ones received at the N2
            interface.</t>
            <t indent="0" pn="section-5.3.2.1-4"> When the packet arrives at the SRGW for UPF1, the SRGW has a
            classification engine rule for incoming traffic from the gNB that
            steers the traffic into an SR Policy by using the function
            H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and
            pushes an IPv6 header with its own SRH containing the SIDs related
            to the SR Policy associated with this traffic.  The SRGW forwards
            according to the new IPv6 DA.</t>
            <t indent="0" pn="section-5.3.2.1-5"> S1 and C1 perform their related Endpoint functionality and
            forward the packet.</t>
            <t indent="0" pn="section-5.3.2.1-6"> When the packet arrives at UPF2, the active segment is (U2::1),
            which is bound to End.DT4/6, which performs the decapsulation
            (removing the outer IPv6 header with all its extension headers)
            and forwards toward the DN.</t>
            <t indent="0" pn="section-5.3.2.1-7">Note that the interworking mechanisms for IPv4/GTP-U and IPv6/GTP-U
    differ. This is due to the fact that IPv6/GTP-U can leverage the remote
    steering capabilities provided by the Segment Routing BSID. In IPv4, this
    construct is not available, and building a similar mechanism would require
    a significant address consumption.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-5.3.2.2">
            <name slugifiedName="name-packet-flow-downlink-4">Packet Flow - Downlink</name>
            <t indent="0" pn="section-5.3.2.2-1">The downlink packet flow is as follows:</t>
            <artwork align="center" name="" type="" alt="" pn="section-5.3.2.2-2">
UPF2_in : (Z,A)                            -&gt; UPF2 maps flow with SID
                                            &lt;C1, S1,GW::SA:DA:TEID&gt;
UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) -&gt;H.Encaps.Red
C1_out  : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out  : (U2::1, GW::SA:DA:TEID)(Z,A)
SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A)       -&gt; End.M.GTP4.E
gNB_out : (Z,A)
</artwork>
            <t indent="0" pn="section-5.3.2.2-3">When a packet destined to A arrives at the UPF2, the UPF2
            performs a lookup in the table associated to A and finds the SID
            list &lt;C1, S1, SRGW::SA:DA:TEID&gt;. The UPF2 performs an
            H.Encaps.Red operation, encapsulating the packet into a new IPv6
            header with its corresponding SRH.</t>
            <t indent="0" pn="section-5.3.2.2-4">The nodes C1 and S1 perform their related Endpoint
            processing.</t>
            <t indent="0" pn="section-5.3.2.2-5">Once the packet arrives at the SRGW, the SRGW identifies the
            active SID as an End.M.GTP4.E function. The SRGW removes the IPv6
            header and all its extensions headers. The SRGW generates IPv4,
            UDP, and GTP-U headers. The IPv4 SA and DA are received as SID
            arguments.  The TEID in the generated GTP-U header is the
            argument of the received End.M.GTP4.E SID.  The SRGW pushes the
            headers to the packet and forwards the packet toward the gNB.</t>
            <t indent="0" pn="section-5.3.2.2-6"> When the packet arrives at the gNB, the packet is a regular
            IPv4/GTP-U packet. The gNB looks for the specific radio bearer for
            that TEID and forwards it on the bearer. This gNB behavior is not
            modified from current and previous generations.</t>
          </section>
          <section numbered="true" toc="exclude" removeInRFC="false" pn="section-5.3.2.3">
            <name slugifiedName="name-scalability-3">Scalability</name>
            <t indent="0" pn="section-5.3.2.3-1">For downlink traffic, the SRGW is stateless. All the state
            is in the SRH pushed by the UPF2. The UPF must have this UE-base
            state anyway (since it is its anchor point).</t>
            <t indent="0" pn="section-5.3.2.3-2">For uplink traffic, the state at the SRGW is dedicated on a
            per-UE/session basis according to a classification engine.  There
            is state for steering the different sessions in the form of an SR
            Policy. However, SR Policies are shared among several
            UE/sessions.</t>
          </section>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3.3">
          <name slugifiedName="name-extensions-to-the-interwork">Extensions to the Interworking Mechanisms</name>
          <t indent="0" pn="section-5.3.3-1">This section presents two mechanisms for interworking with gNBs
          and UPFs that do not support SRv6. These mechanisms are used to
          support GTP-U over IPv4 and IPv6.</t>
          <t indent="0" pn="section-5.3.3-2"> Even though these methods are presented as an extension to the
          Enhanced mode, they are also applicable to the Traditional mode.
          </t>
        </section>
      </section>
      <section anchor="drop_in" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-srv6-drop-in-interworking">SRv6 Drop-In Interworking</name>
        <t indent="0" pn="section-5.4-1">This section introduces another mode useful for legacy gNB and UPFs
        that still operate with GTP-U.  This mode provides an SRv6-enabled
        user plane in between two GTP-U tunnel endpoints.</t>
        <t indent="0" pn="section-5.4-2">This mode employs two SRGWs that map GTP-U traffic to SRv6 and
        vice versa.</t>
        <t indent="0" pn="section-5.4-3">Unlike other interworking modes, in this mode, both of the mobility
        overlay endpoints use GTP-U.  Two SRGWs are deployed in either an N3 or
        N9 interface to realize an intermediate SR Policy.</t>
        <figure anchor="fig_drop_in" align="left" suppress-title="false" pn="figure-7">
          <name slugifiedName="name-example-topology-for-srv6-d">Example Topology for SRv6 Drop-In Mode</name>
          <artwork align="center" name="" type="" alt="" pn="section-5.4-4.1">
                            +----+
                           -| S1 |-
+-----+                   / +----+ \
| gNB |-            SRv6 /   SRv6   \ +----+   +--------+    +-----+
+-----+  \              /     VNF    -| C1 |---| SRGW-B |----| UPF |
   GTP[N3]\ +--------+ /              +----+   +--------+    +-----+
           -| SRGW-A |-                SRv6   SR Gateway-B     GTP
            +--------+                  TE
           SR Gateway-A
</artwork>
        </figure>
        <t indent="0" pn="section-5.4-5">The packet flow of <xref target="fig_drop_in" format="default" sectionFormat="of" derivedContent="Figure 7"/> is
        as follows:</t>
        <artwork align="center" name="" type="" alt="" pn="section-5.4-6">
gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z)
GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)-&gt;U::1 is an
                                                      End.M.GTP6.D.Di
                                                      SID at SRGW-A
S1_out  : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z)
C1_out  : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z)
GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z)            -&gt;SGB::TEID is an
                                                      End.M.GTP6.E
                                                      SID at SRGW-B
UPF_out : (A,Z)
</artwork>
        <t indent="0" pn="section-5.4-7">When a packet destined to Z is sent to the gNB, which is unmodified
        (control plane and user plane remain GTP-U), gNB performs
        encapsulation into new IP, UDP, and GTP-U headers.  The IPv6 DA, U::1,
        and GTP-U TEID are the ones received at the N2 interface.</t>
        <t indent="0" pn="section-5.4-8">The IPv6 address that was signaled over the N2 interface for that
        PDU Session, U::1, is now the IPv6 DA.  U::1 is an SRv6 Binding
        SID at SRGW-A.  Hence, the packet is routed to the SRGW.</t>
        <t indent="0" pn="section-5.4-9">When the packet arrives at SRGW-A, the SRGW identifies U::1 as an
        End.M.GTP6.D.Di Binding SID (see <xref target="End-M-GTP6-D-Di" format="default" sectionFormat="of" derivedContent="Section 6.4"/>).  Hence, the SRGW removes the IPv6, UDP, and GTP-U
        headers and pushes an IPv6 header with its own SRH containing the
        SIDs bound to the SR Policy associated with this Binding SID. There is
        one instance of the End.M.GTP6.D.Di SID per PDU type.</t>
        <t indent="0" pn="section-5.4-10">S1 and C1 perform their related Endpoint functionality and forward
          the packet.</t>
        <t indent="0" pn="section-5.4-11">Once the packet arrives at SRGW-B, the SRGW identifies the active
        SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header and
        all its extensions headers. The SRGW generates new IPv6, UDP, and GTP
        headers. The new IPv6 DA is U::1, which is the last SID in the
        received SRH. The TEID in the generated GTP-U header is an argument of
        the received End.M.GTP6.E SID. The SRGW pushes the headers to the
        packet and forwards the packet toward UPF.  There is one instance of
        the End.M.GTP6.E SID per PDU type.</t>
        <t indent="0" pn="section-5.4-12">Once the packet arrives at UPF, the packet is a regular IPv6/GTP
        packet. The UPF looks for the specific rule for that TEID to forward
        the packet. This UPF behavior is not modified from current and
        previous generations.</t>
      </section>
    </section>
    <section anchor="srv6_functions" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-srv6-segment-endpoint-mobil">SRv6 Segment Endpoint Mobility Behaviors</name>
      <t indent="0" pn="section-6-1">This section introduces new SRv6 Endpoint Behaviors for the
      mobile user plane. The behaviors described in this document are
      compatible with the NEXT and REPLACE flavors defined in <xref target="I-D.ietf-spring-srv6-srh-compression" format="default" sectionFormat="of" derivedContent="SRV6-SRH-COMPRESSION"/>.</t>
      <section anchor="arguments-for-mobility" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-argsmobsession">Args.Mob.Session</name>
        <t indent="0" pn="section-6.1-1">Args.Mob.Session provides per-session information for charging,
        buffering, or other purposes required by some mobile nodes.  The
        Args.Mob.Session argument format is used in combination with the End.Map,
        End.DT4/End.DT6/End.DT46, and End.DX4/End.DX6/End.DX2 behaviors. Note
        that proposed format is applicable for 5G networks, while similar
        formats could be used for legacy networks.
        </t>
        <figure align="left" suppress-title="false" pn="figure-8">
          <name slugifiedName="name-argsmobsession-format">Args.Mob.Session Format</name>
          <artwork align="center" name="" type="" alt="" pn="section-6.1-2.1">
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   QFI     |R|U|                PDU Session ID                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDU Sess(cont')|
+-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <dl spacing="normal" newline="false" indent="3" pn="section-6.1-3">
          <dt pn="section-6.1-3.1">QFI:</dt>
          <dd pn="section-6.1-3.2">QoS Flow Identifier <xref target="TS.38415" format="default" sectionFormat="of" derivedContent="TS.38415"/>.</dd>
          <dt pn="section-6.1-3.3">R:</dt>
          <dd pn="section-6.1-3.4">Reflective QoS Indication <xref target="TS.23501" format="default" sectionFormat="of" derivedContent="TS.23501"/>. This parameter indicates the activation of
	  reflective QoS towards the UE for the transferred packet. Reflective
	  QoS enables the UE to map uplink user-plane traffic to QoS flows without
	  SMF-provided QoS rules.</dd>
          <dt pn="section-6.1-3.5">U:</dt>
          <dd pn="section-6.1-3.6">Unused and for future use. <bcp14>MUST</bcp14> be 0 on
	  transmission and ignored on receipt.</dd>
          <dt pn="section-6.1-3.7">PDU Session ID:</dt>
          <dd pn="section-6.1-3.8">Identifier of PDU Session. The GTP-U equivalent is TEID.</dd>
        </dl>
        <t indent="0" pn="section-6.1-4">Args.Mob.Session is required in case one SID aggregates
        multiple PDU Sessions. Since the SRv6 SID is likely NOT to be
        instantiated per PDU Session, Args.Mob.Session helps the UPF to
        perform the behaviors that require granularity per QFI and/or per PDU Session.</t>
        <t indent="0" pn="section-6.1-5">Note that the encoding of user-plane messages (e.g., Echo Request,
        Echo Reply, Error Indication, and End Marker) is out of the scope of
        this document. <xref target="I-D.murakami-dmm-user-plane-message-encoding" format="default" sectionFormat="of" derivedContent="SRV6-UP-MSG-ENCODING"/> defines one
        possible encoding method.</t>
      </section>
      <section anchor="end-map-function" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-endmap">End.MAP</name>
        <t indent="0" pn="section-6.2-1">End.MAP (Endpoint Behavior with SID mapping)
	   is used in several scenarios. Particularly in mobility,
      End.MAP is used by the intermediate UPFs.</t>
        <t indent="0" pn="section-6.2-2">When node N receives a packet whose IPv6 DA is D and D is a local End.MAP SID, N does the following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.2-3">
S01. If (IPv6 Hop Limit &lt;= 1) {
S02.    Send an ICMP Time Exceeded message to the Source Address with
           Code 0 (Hop limit exceeded in transit),
           interrupt packet processing, and discard the packet.
S03. }
S04. Decrement IPv6 Hop Limit by 1
S05. Update the IPv6 DA with the new mapped SID
S06. Submit the packet to the egress IPv6 FIB lookup for
        transmission to the new destination
</sourcecode>
        <t indent="0" pn="section-6.2-4">Note: The SRH is not modified (neither the SID nor the SL
        value).</t>
      </section>
      <section anchor="End-M-GTP6-D" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-endmgtp6d">End.M.GTP6.D</name>
        <t indent="0" pn="section-6.3-1">End.M.GTP6.D (Endpoint Behavior with IPv6/GTP-U decapsulation into SR
        Policy) is used in the interworking
        scenario for the uplink towards SRGW from the legacy gNB using
        IPv6/GTP.  Any SID instance of this behavior is associated with an SR
        Policy B and an IPv6 Source Address S.
        </t>
        <t indent="0" pn="section-6.3-2">When the SR Gateway node N receives a packet destined to D, and D
        is a local End.M.GTP6.D SID, N does the following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.3-3">
S01. When an SRH is processed {
S02.   If (Segments Left != 0) {
S03.      Send an ICMP Parameter Problem to the Source Address with
             Code 0 (Erroneous header field encountered) and
             Pointer set to the Segments Left field,
             interrupt packet processing, and discard the packet.
S04.   }
S05.   Proceed to process the next header in the packet
S06. }
</sourcecode>
        <t indent="0" pn="section-6.3-4">When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.M.GTP6.D SID, N does the following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.3-5">
S01. If (Next Header (NH) == UDP &amp; UDP_Dest_port == GTP) {
S02.    Copy the GTP-U TEID and QFI to buffer memory
S03.    Pop the IPv6, UDP, and GTP-U headers
S04.    Push a new IPv6 header with its own SRH containing B
S05.    Set the outer IPv6 SA to S
S06.    Set the outer IPv6 DA to the first SID of B
S07.    Set the outer Payload Length, Traffic Class, Flow Label,
           Hop Limit, and Next Header (NH) fields
S08.    Write in the SRH[0] the Args.Mob.Session based on
           the information in buffer memory
S09.    Submit the packet to the egress IPv6 FIB lookup for
           transmission to the new destination
S10. } Else {
S11.    Process as per [RFC8986], Section 4.1.1
S12. }
</sourcecode>
        <t indent="0" pn="section-6.3-6">Notes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.3-7">
          <li pn="section-6.3-7.1">In line S07, the NH is set based on the SID parameter. There is one
          instantiation of the End.M.GTP6.D SID per PDU Session Type;
          hence, the NH is already known in advance. In addition, for the IPv4v6 PDU
          Session Type, the router inspects the first nibble of the
          PDU to know the NH value.</li>
          <li pn="section-6.3-7.2">The last segment <bcp14>SHOULD</bcp14> be
        followed by an Args.Mob.Session argument space, which is used to
        provide the session identifiers, as shown in line S08.</li>
        </ul>
      </section>
      <section anchor="End-M-GTP6-D-Di" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-endmgtp6ddi">End.M.GTP6.D.Di</name>
        <t indent="0" pn="section-6.4-1">End.M.GTP6.D.Di (Endpoint Behavior with IPv6/GTP-U decapsulation into SR Policy
        for Drop-in Mode) is used in the SRv6
        drop-in interworking scenario described in <xref target="drop_in" format="default" sectionFormat="of" derivedContent="Section 5.4"/>. The difference between End.M.GTP6.D as another
        variant of the IPv6/GTP decapsulation function is that the original IPv6
        DA of the GTP-U packet is preserved as the last SID in SRH.</t>
        <t indent="0" pn="section-6.4-2">Any SID instance of this behavior is associated with an SR Policy B
        and an IPv6 Source Address S.</t>
        <t indent="0" pn="section-6.4-3">When the SR Gateway node N receives a packet destined to D, and
        D is a local End.M.GTP6.D.Di SID, N does the following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.4-4">
S01. When an SRH is processed {
S02.   If (Segments Left != 0) {
S03.      Send an ICMP Parameter Problem to the Source Address with
             Code 0 (Erroneous header field encountered) and
             Pointer set to the Segments Left field,
             interrupt packet processing, and discard the packet.
S04.   }
S05.   Proceed to process the next header in the packet
S06. }
</sourcecode>
        <t indent="0" pn="section-6.4-5">When processing the Upper-Layer header of a packet matching a FIB
        entry locally instantiated as an End.M.GTP6.Di SID, N does the
        following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.4-6">
S01. If (Next Header = UDP &amp; UDP_Dest_port = GTP) {
S02.    Copy D to buffer memory
S03.    Pop the IPv6, UDP, and GTP-U headers
S04.    Push a new IPv6 header with its own SRH containing B
S05.    Set the outer IPv6 SA to S
S06.    Set the outer IPv6 DA to the first SID of B
S07.    Set the outer Payload Length, Traffic Class, Flow Label,
           Hop Limit, and Next Header fields
S08.    Prepend D to the SRH (as SRH[0]) and set SL accordingly
S09.    Submit the packet to the egress IPv6 FIB lookup for
           transmission to the new destination
S10. } Else {
S11.    Process as per [RFC8986], Section 4.1.1
S12. }
</sourcecode>
        <t indent="0" pn="section-6.4-7">Notes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.4-8">
          <li pn="section-6.4-8.1">In line S07, the NH is set based on the SID parameter. There is one
        instantiation of the End.M.GTP6.Di SID per PDU Session Type; hence,
        the NH is already known in advance. In addition, for the IPv4v6 PDU Session Type,
        the router inspects the first nibble of the PDU to know
        the NH value.</li>
          <li pn="section-6.4-8.2">S <bcp14>SHOULD</bcp14> be an End.M.GTP6.E SID instantiated
	at the SR Gateway.</li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-endmgtp6e">End.M.GTP6.E</name>
        <t indent="0" pn="section-6.5-1">End.M.GTP6.E (Endpoint Behavior with encapsulation for IPv6/GTP-U tunnel"
        behavior) is used among others in the
        interworking scenario for the downlink toward the legacy gNB using
        IPv6/GTP.</t>
        <t indent="0" pn="section-6.5-2">The prefix of End.M.GTP6.E SID <bcp14>MUST</bcp14> be followed by
        the Args.Mob.Session argument space, which is used to provide the
        session identifiers.</t>
        <t indent="0" pn="section-6.5-3">When the SR Gateway node N receives a packet destined to D, and
        D is a local End.M.GTP6.E SID, N does the following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.5-4">
S01. When an SRH is processed {
S02.   If (Segments Left != 1) {
S03.      Send an ICMP Parameter Problem to the Source Address with
             Code 0 (Erroneous header field encountered) and
             Pointer set to the Segments Left field,
             interrupt packet processing, and discard the packet.
S04.   }
S05.   Proceed to process the next header in the packet
S06. }
</sourcecode>
        <t indent="0" pn="section-6.5-5">When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.M.GTP6.E SID, N does the following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.5-6">
S01.    Copy SRH[0] and D to buffer memory
S02.    Pop the IPv6 header and all its extension headers
S03.    Push a new IPv6 header with a UDP/GTP-U header
S04.    Set the outer IPv6 SA to S
S05.    Set the outer IPv6 DA from buffer memory
S06.    Set the outer Payload Length, Traffic Class, Flow Label,
           Hop Limit, and Next Header fields
S07.    Set the GTP-U TEID (from buffer memory)
S08.    Submit the packet to the egress IPv6 FIB lookup for
           transmission to the new destination
</sourcecode>
        <t indent="0" pn="section-6.5-7">Notes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-8">
          <li pn="section-6.5-8.1">An End.M.GTP6.E SID <bcp14>MUST</bcp14> always be the penultimate SID.
        The TEID is extracted from the argument space of the current
        SID.</li>
          <li pn="section-6.5-8.2"> The source address S <bcp14>SHOULD</bcp14> be an End.M.GTP6.D SID instantiated at the egress SR Gateway.</li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.6">
        <name slugifiedName="name-endmgtp4e">End.M.GTP4.E</name>
        <t indent="0" pn="section-6.6-1">End.M.GTP4.E (Endpoint Behavior with encapsulation for IPv4/GTP-U
        tunnel) is used in the downlink when doing interworking with legacy
        gNB using IPv4/GTP.</t>
        <t indent="0" pn="section-6.6-2">When the SR Gateway node N receives a packet destined to S, and S
	    is a local End.M.GTP4.E SID, N does the following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.6-3">
S01. When an SRH is processed {
S02.   If (Segments Left != 0) {
S03.      Send an ICMP Parameter Problem to the Source Address with
             Code 0 (Erroneous header field encountered) and
             Pointer set to the Segments Left field,
             interrupt packet processing, and discard the packet.
S04.   }
S05.   Proceed to process the next header in the packet
S06. }
</sourcecode>
        <t indent="0" pn="section-6.6-4">When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.M.GTP4.E SID, N does the following:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-6.6-5">
S01.    Store the IPv6 DA and SA in buffer memory
S02.    Pop the IPv6 header and all its extension headers
S03.    Push a new IPv4 header with a UDP/GTP-U header
S04.    Set the outer IPv4 SA and DA (from buffer memory)
S05.    Set the outer Total Length, DSCP, Time To Live, and
           Next Header fields
S06.    Set the GTP-U TEID (from buffer memory)
S07.    Submit the packet to the egress IPv4 FIB lookup for
           transmission to the new destination
</sourcecode>
        <t indent="0" pn="section-6.6-6">Notes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.6-7">
          <li pn="section-6.6-7.1">
            <t indent="0" pn="section-6.6-7.1.1">The End.M.GTP4.E SID in S has the following format:</t>
            <figure align="left" suppress-title="false" pn="figure-9">
              <name slugifiedName="name-endmgtp4e-sid-encoding">End.M.GTP4.E SID Encoding</name>
              <artwork align="center" name="" type="" alt="" pn="section-6.6-7.1.2.1">
0                                                         127
+-----------------------+-------+----------------+---------+
|  SRGW-IPv6-LOC-FUNC   |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
       128-a-b-c            a            b           c
</artwork>
            </figure>
          </li>
          <li pn="section-6.6-7.2">
            <t indent="0" pn="section-6.6-7.2.1">The IPv6 Source Address has the following format:</t>
            <figure align="left" suppress-title="false" pn="figure-10">
              <name slugifiedName="name-ipv6-sa-encoding-for-endmgt">IPv6 SA Encoding for End.M.GTP4.E</name>
              <artwork align="center" name="" type="" alt="" pn="section-6.6-7.2.2.1">
0                                                         127
+----------------------+--------+--------------------------+
|  Source UPF Prefix   |IPv4 SA | any bit pattern(ignored) |
+----------------------+--------+--------------------------+
         128-a-b            a                  b
</artwork>
            </figure>
          </li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.7">
        <name slugifiedName="name-hmgtp4d">H.M.GTP4.D</name>
        <t indent="0" pn="section-6.7-1">H.M.GTP4.D (SR Policy Headend with tunnel decapsulation and map to an SRv6
        policy) is used in the direction
        from the legacy IPv4 user plane to the SRv6 user-plane network.</t>
        <t indent="0" pn="section-6.7-2">When the SR Gateway node N receives a packet destined to a
        SRGW-IPv4-Prefix, N does the following:</t>
        <artwork align="left" name="" type="" alt="" pn="section-6.7-3">
S01. IF Payload == UDP/GTP-U THEN
S02.    Pop the outer IPv4 header and UDP/GTP-U headers
S03.    Copy IPv4 DA and TEID to form SID B
S04.    Copy IPv4 SA to form IPv6 SA B'
S05.    Encapsulate the packet into a new IPv6 header
S06.    Set the IPv6 DA = B
S07.    Forward along the shortest path to B
S08. ELSE
S09.    Drop the packet
</artwork>
        <t indent="0" pn="section-6.7-4">The SID B has the following format:</t>
        <figure align="left" suppress-title="false" pn="figure-11">
          <name slugifiedName="name-hmgtp4d-sid-encoding">H.M.GTP4.D SID Encoding</name>
          <artwork align="center" name="" type="" alt="" pn="section-6.7-5.1">
0                                                         127
+-----------------------+-------+----------------+---------+
|Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
       128-a-b-c            a            b           c
</artwork>
        </figure>
        <t indent="0" pn="section-6.7-6"> The SID B <bcp14>MAY</bcp14> be an SRv6 Binding SID instantiated at the first
        UPF (U1) to bind an SR Policy <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="RFC9256"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-6.8">
        <name slugifiedName="name-endlimit">End.Limit</name>
        <t indent="0" pn="section-6.8-1"> The mobile user plane requires a rate-limit feature. For this
        purpose, this document defines a new behavior, called "End.Limit".
        The "End.Limit" behavior encodes in its arguments the rate-limiting
        parameter that should be applied to this packet.  Multiple flows of
        packets should have the same group identifier in the SID when those
        flows are in the same AMBR (Aggregate Maximum Bit Rate) group.  The
        encoding format of the rate-limit segment SID is as follows:</t>
        <figure align="left" suppress-title="false" pn="figure-12">
          <name slugifiedName="name-endlimit-rate-limiting-beha">End.Limit: Rate-Limiting Behavior Argument Format</name>
          <artwork align="center" name="" type="" alt="" pn="section-6.8-2.1">
+----------------------+----------+-----------+
| LOC+FUNC rate-limit  | group-id | limit-rate|
+----------------------+----------+-----------+
      128-i-j                i          j
</artwork>
        </figure>
        <t indent="0" pn="section-6.8-3"> If the limit-rate bits are set to zero, the node should
            not do rate limiting unless static configuration or
            control plane sets the limit rate associated to the SID.</t>
      </section>
    </section>
    <section anchor="pdu_sessions" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-srv6-supported-3gpp-pdu-ses">SRv6-Supported 3GPP PDU Session Types</name>
      <t indent="0" pn="section-7-1">The 3GPP <xref target="TS.23501" format="default" sectionFormat="of" derivedContent="TS.23501"/> defines the
      following PDU Session Types:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-2">
        <li pn="section-7-2.1">IPv4</li>
        <li pn="section-7-2.2">IPv6</li>
        <li pn="section-7-2.3">IPv4v6</li>
        <li pn="section-7-2.4">Ethernet</li>
        <li pn="section-7-2.5">Unstructured</li>
      </ul>
      <t indent="0" pn="section-7-3"> SRv6 supports the 3GPP PDU Session Types without any protocol
	    overhead by using the corresponding SRv6 behaviors:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-4">
        <li pn="section-7-4.1">End.DX4 and End.DT4 for IPv4 PDU Sessions</li>
        <li pn="section-7-4.2">End.DX6, End.DT6, and End.T for IPv6 PDU Sessions</li>
        <li pn="section-7-4.3">End.DT46 for IPv4v6 PDU Sessions</li>
        <li pn="section-7-4.4">End.DX2 for L2 and Unstructured PDU Sessions</li>
      </ul>
    </section>
    <section anchor="netslice" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-network-slicing-considerati">Network Slicing Considerations</name>
      <t indent="0" pn="section-8-1">A mobile network may be required to implement "network slices",
	    which logically separate network resources within the same SR domain.</t>
      <t indent="0" pn="section-8-2"><xref target="RFC9256" format="default" sectionFormat="of" derivedContent="RFC9256"/>
	    describes a solution to build basic network slices with SR.
	    Depending on the requirements, these slices can be further
	    refined by adopting the mechanisms from:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8-3">
        <li pn="section-8-3.1">IGP Flex-Algo
		<xref target="RFC9350" format="default" sectionFormat="of" derivedContent="RFC9350"/></li>
        <li pn="section-8-3.2">Inter-Domain policies
	       <xref target="RFC9087" format="default" sectionFormat="of" derivedContent="RFC9087"/></li>
      </ul>
      <t indent="0" pn="section-8-4">Furthermore, these can be combined with ODN/AS (On-Demand Next Hop / Automated Steering)
	    <xref target="RFC9256" format="default" sectionFormat="of" derivedContent="RFC9256"/> for
	    automated slice provisioning and traffic steering.</t>
      <t indent="0" pn="section-8-5">Further details on how these tools can be used to create
          end-to-end network slices are documented in
          <xref target="I-D.ali-teas-spring-ns-building-blocks" format="default" sectionFormat="of" derivedContent="NETWORK-SLICE"/>.</t>
    </section>
    <section anchor="c-plane" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-control-plane-consideration">Control Plane Considerations</name>
      <t indent="0" pn="section-9-1">This document focuses on user-plane behavior and its independence
      from the control plane.  While the SRv6 mobile user-plane behaviors may
      be utilized in emerging architectures (for example, those described in
      <xref target="I-D.gundavelli-dmm-mfa" format="default" sectionFormat="of" derivedContent="MFA"/> and <xref target="I-D.mhkk-dmm-srv6mup-architecture" format="default" sectionFormat="of" derivedContent="MUP-SR-ARCH"/>), this
      document does not impose any change to the existent mobility control
      plane.
      </t>
      <t indent="0" pn="section-9-2"> <xref target="IANA" format="default" sectionFormat="of" derivedContent="Section 11"/> allocates SRv6
      Endpoint Behavior codepoints for the new behaviors defined in this
      document.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-10-1"> The security considerations for Segment Routing are discussed in
      <xref target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/>.  More specifically, for SRv6,
      the security considerations and the mechanisms for securing an SR domain
      are discussed in <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>.  Together,
      they describe the required security mechanisms that allow establishment
      of an SR domain of trust to operate SRv6-based services for internal
      traffic while preventing any external traffic from accessing or
      exploiting the SRv6-based services.</t>
      <t indent="0" pn="section-10-2">The technology described in this document is applied to a mobile
      network that is within the SR domain. It's important to note the
      resemblance between the SR domain and the 3GPP Packet Core Domain.</t>
      <t indent="0" pn="section-10-3">This document introduces new SRv6 Endpoint Behaviors. Those behaviors
      operate on control plane information, including information within the
      received SRH payload on which the behaviors operate. Altering the
      behaviors requires that an attacker alter the SR domain as defined in
      <xref target="RFC8754" format="default" sectionFormat="of" derivedContent="RFC8754"/>.  Those behaviors do not need
      any special security consideration given that they are deployed within that
      SR domain.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-11-1">The following values have been allocated in the "SRv6 Endpoint
      Behaviors" <xref target="RFC8986" format="default" sectionFormat="of" derivedContent="RFC8986"/> subregistry
      within the top-level "Segment Routing Parameters" registry:</t>
      <table anchor="endpoint_opcodes" align="center" pn="table-1">
        <name slugifiedName="name-srv6-mobile-user-plane-endp">SRv6 Mobile User-Plane Endpoint Behavior Types</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="center" colspan="1" rowspan="1">Hex</th>
            <th align="center" colspan="1" rowspan="1">Endpoint Behavior</th>
            <th align="center" colspan="1" rowspan="1">Reference</th>
            <th align="center" colspan="1" rowspan="1">Change Controller</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">40</td>
            <td align="center" colspan="1" rowspan="1">0x0028</td>
            <td align="center" colspan="1" rowspan="1">End.MAP</td>
            <td align="center" colspan="1" rowspan="1">RFC 9433</td>
            <td align="center" colspan="1" rowspan="1">IETF</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">41</td>
            <td align="center" colspan="1" rowspan="1">0x0029</td>
            <td align="center" colspan="1" rowspan="1">End.Limit</td>
            <td align="center" colspan="1" rowspan="1">RFC 9433</td>
            <td align="center" colspan="1" rowspan="1">IETF</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">69</td>
            <td align="center" colspan="1" rowspan="1">0x0045</td>
            <td align="center" colspan="1" rowspan="1">End.M.GTP6.D</td>
            <td align="center" colspan="1" rowspan="1">RFC 9433</td>
            <td align="center" colspan="1" rowspan="1">IETF</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">70</td>
            <td align="center" colspan="1" rowspan="1">0x0046</td>
            <td align="center" colspan="1" rowspan="1">End.M.GTP6.Di</td>
            <td align="center" colspan="1" rowspan="1">RFC 9433</td>
            <td align="center" colspan="1" rowspan="1">IETF</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">71</td>
            <td align="center" colspan="1" rowspan="1">0x0047</td>
            <td align="center" colspan="1" rowspan="1">End.M.GTP6.E</td>
            <td align="center" colspan="1" rowspan="1">RFC 9433</td>
            <td align="center" colspan="1" rowspan="1">IETF</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">72</td>
            <td align="center" colspan="1" rowspan="1">0x0048</td>
            <td align="center" colspan="1" rowspan="1">End.M.GTP4.E</td>
            <td align="center" colspan="1" rowspan="1">RFC 9433</td>
            <td align="center" colspan="1" rowspan="1">IETF</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-spring-sr-service-programming" to="SR-SERV-PROG"/>
    <displayreference target="I-D.camarilloelmalky-springdmm-srv6-mob-usecases" to="SRV6-MOB-USECASES"/>
    <displayreference target="I-D.ali-teas-spring-ns-building-blocks" to="NETWORK-SLICE"/>
    <displayreference target="I-D.mhkk-dmm-srv6mup-architecture" to="MUP-SR-ARCH"/>
    <displayreference target="I-D.matsushima-spring-srv6-deployment-status" to="SRV6-DEPLOY-STAT"/>
    <displayreference target="I-D.kohno-dmm-srv6mob-arch" to="SRV6-MOB-ARCH-DISCUSS"/>
    <displayreference target="I-D.gundavelli-dmm-mfa" to="MFA"/>
    <displayreference target="I-D.murakami-dmm-user-plane-message-encoding" to="SRV6-UP-MSG-ENCODING"/>
    <displayreference target="I-D.ietf-spring-srv6-srh-compression" to="SRV6-SRH-COMPRESSION"/>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" quoteTitle="true" derivedAnchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
            <author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
            <author fullname="R. Shakir" initials="R." surname="Shakir"/>
            <date month="July" year="2018"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t indent="0">SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
              <t indent="0">SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC8754" target="https://www.rfc-editor.org/info/rfc8754" quoteTitle="true" derivedAnchor="RFC8754">
          <front>
            <title>IPv6 Segment Routing Header (SRH)</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="D. Dukes" initials="D." role="editor" surname="Dukes"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8754"/>
          <seriesInfo name="DOI" value="10.17487/RFC8754"/>
        </reference>
        <reference anchor="RFC8986" target="https://www.rfc-editor.org/info/rfc8986" quoteTitle="true" derivedAnchor="RFC8986">
          <front>
            <title>Segment Routing over IPv6 (SRv6) Network Programming</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="J. Leddy" initials="J." surname="Leddy"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="S. Matsushima" initials="S." surname="Matsushima"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <date month="February" year="2021"/>
            <abstract>
              <t indent="0">The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.</t>
              <t indent="0">Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t indent="0">This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8986"/>
          <seriesInfo name="DOI" value="10.17487/RFC8986"/>
        </reference>
        <reference anchor="RFC9256" target="https://www.rfc-editor.org/info/rfc9256" quoteTitle="true" derivedAnchor="RFC9256">
          <front>
            <title>Segment Routing Policy Architecture</title>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
            <author fullname="P. Mattes" initials="P." surname="Mattes"/>
            <date month="July" year="2022"/>
            <abstract>
              <t indent="0">Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.</t>
              <t indent="0">This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9256"/>
          <seriesInfo name="DOI" value="10.17487/RFC9256"/>
        </reference>
        <reference anchor="TS.23501" quoteTitle="true" derivedAnchor="TS.23501">
          <front>
            <title>System architecture for the 5G System (5GS)</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
            <date month="June" year="2023"/>
          </front>
          <seriesInfo name="3GPP TS" value="23.501"/>
          <refcontent>Version 17.9.0</refcontent>
        </reference>
      </references>
      <references pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.gundavelli-dmm-mfa" target="https://datatracker.ietf.org/doc/html/draft-gundavelli-dmm-mfa-01" quoteTitle="true" derivedAnchor="MFA">
          <front>
            <title>Mobility-aware Floating Anchor (MFA)</title>
            <author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <author fullname="Marco Liebsch" initials="M." surname="Liebsch">
              <organization showOnFrontPage="true">NEC</organization>
            </author>
            <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
              <organization showOnFrontPage="true">SoftBank</organization>
            </author>
            <date day="19" month="September" year="2018"/>
            <abstract>
              <t indent="0">IP mobility protocols are designed to allow a mobile node to remain reachable while moving around in the network. The currently deployed mobility management protocols are anchor-based approaches, where a mobile node's IP sessions are anchored on a central node. The mobile node's IP traffic enters and exits from this anchor node and it remains as the control point for all subscriber services. This architecture based on fixed IP anchors comes with some complexity and there is some interest from the mobile operators to eliminate the use of fixed anchors, and other residual elements such as the overlay tunneling that come with it. This document describes a new approach for realizing a mobile user- plane that does not require fixed IP anchors. The architectural- basis for this approach is the separation of control and user plane, and the use of programmability constructs of the user-plane for traffic steering. This approach is referred to as, Mobility-aware Floating Anchor (MFA).</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-gundavelli-dmm-mfa-01"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.mhkk-dmm-srv6mup-architecture" target="https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-srv6mup-architecture-05" quoteTitle="true" derivedAnchor="MUP-SR-ARCH">
          <front>
            <title>Mobile User Plane Architecture using Segment Routing for Distributed Mobility Management</title>
            <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
              <organization showOnFrontPage="true">SoftBank</organization>
            </author>
            <author fullname="Katsuhiro Horiba" initials="K." surname="Horiba">
              <organization showOnFrontPage="true">SoftBank</organization>
            </author>
            <author fullname="Ashiq Khan" initials="A." surname="Khan">
              <organization showOnFrontPage="true">SoftBank</organization>
            </author>
            <author fullname="Yuya Kawakami" initials="Y." surname="Kawakami">
              <organization showOnFrontPage="true">SoftBank</organization>
            </author>
            <author fullname="Tetsuya Murakami" initials="T." surname="Murakami">
              <organization showOnFrontPage="true">Arrcus, Inc.</organization>
            </author>
            <author fullname="Keyur Patel" initials="K." surname="Patel">
              <organization showOnFrontPage="true">Arrcus, Inc.</organization>
            </author>
            <author fullname="Miya Kohno" initials="M." surname="Kohno">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Teppei Kamata" initials="T." surname="Kamata">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Pablo Camarillo" initials="P." surname="Camarillo">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Jakub Horn" initials="J." surname="Horn">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Daniel Voyer" initials="D." surname="Voyer">
              <organization showOnFrontPage="true">Bell Canada</organization>
            </author>
            <author fullname="Shay Zadok" initials="S." surname="Zadok">
              <organization showOnFrontPage="true">Broadcom</organization>
            </author>
            <author fullname="Israel Meilik" initials="I." surname="Meilik">
              <organization showOnFrontPage="true">Broadcom</organization>
            </author>
            <author fullname="Ashutosh Agrawal" initials="A." surname="Agrawal">
              <organization showOnFrontPage="true">Intel</organization>
            </author>
            <author fullname="Kumaresh Perumal" initials="K." surname="Perumal">
              <organization showOnFrontPage="true">Intel</organization>
            </author>
            <date day="13" month="March" year="2023"/>
            <abstract>
              <t indent="0">This document defines the Mobile User Plane (MUP) architecture using Segment Routing (SR) for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. Mobile services are deployed over several parts of IP networks. An SR network can accommodate a part of those networks, or all those networks. IPv6 dataplane option (SRv6) is suitable for both cases especially for the latter case thanks to the large address space, so this document illustrates the MUP deployment cases with IPv6 dataplane. MUP Architecture can incorporate existing session based mobile networks. By leveraging Segment Routing, mobile user plane can be integrated into the dataplane. In that routing paradigm, session information between the entities of the mobile user plane is turned to routing information.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-mhkk-dmm-srv6mup-architecture-05"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ali-teas-spring-ns-building-blocks" target="https://datatracker.ietf.org/doc/html/draft-ali-teas-spring-ns-building-blocks-03" quoteTitle="true" derivedAnchor="NETWORK-SLICE">
          <front>
            <title>Building blocks for Network Slice Realization in Segment Routing Network</title>
            <author fullname="Zafar Ali" initials="Z." surname="Ali">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Pablo Camarillo" initials="P." surname="Camarillo">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Daniel Voyer" initials="D." surname="Voyer">
              <organization showOnFrontPage="true">Bell Canada</organization>
            </author>
            <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
              <organization showOnFrontPage="true">Softbank</organization>
            </author>
            <author fullname="Reza Rokui" initials="R." surname="Rokui">
              <organization showOnFrontPage="true">Ciena</organization>
            </author>
            <author fullname="Amit Dhamija" initials="A." surname="Dhamija">
              <organization showOnFrontPage="true">Rakuten</organization>
            </author>
            <author fullname="Praveen Maheshwari" initials="P." surname="Maheshwari">
              <organization showOnFrontPage="true">Airtel</organization>
            </author>
            <date day="7" month="September" year="2022"/>
            <abstract>
              <t indent="0">This document describes how to realize the IETF network slice using the Segment Routing based technology. It explains how the building blocks specified for the Segment Routing can be used for this purpose.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ali-teas-spring-ns-building-blocks-03"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC9087" target="https://www.rfc-editor.org/info/rfc9087" quoteTitle="true" derivedAnchor="RFC9087">
          <front>
            <title>Segment Routing Centralized BGP Egress Peer Engineering</title>
            <author fullname="C. Filsfils" initials="C." role="editor" surname="Filsfils"/>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="G. Dawra" initials="G." role="editor" surname="Dawra"/>
            <author fullname="E. Aries" initials="E." surname="Aries"/>
            <author fullname="D. Afanasiev" initials="D." surname="Afanasiev"/>
            <date month="August" year="2021"/>
            <abstract>
              <t indent="0">Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.</t>
              <t indent="0">The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.</t>
              <t indent="0">This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based BGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9087"/>
          <seriesInfo name="DOI" value="10.17487/RFC9087"/>
        </reference>
        <reference anchor="RFC9350" target="https://www.rfc-editor.org/info/rfc9350" quoteTitle="true" derivedAnchor="RFC9350">
          <front>
            <title>IGP Flexible Algorithm</title>
            <author fullname="P. Psenak" initials="P." role="editor" surname="Psenak"/>
            <author fullname="S. Hegde" initials="S." surname="Hegde"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." surname="Talaulikar"/>
            <author fullname="A. Gulko" initials="A." surname="Gulko"/>
            <date month="February" year="2023"/>
            <abstract>
              <t indent="0">IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9350"/>
          <seriesInfo name="DOI" value="10.17487/RFC9350"/>
        </reference>
        <reference anchor="I-D.ietf-spring-sr-service-programming" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-07" quoteTitle="true" derivedAnchor="SR-SERV-PROG">
          <front>
            <title>Service Programming with Segment Routing</title>
            <author initials="F." surname="Clad" fullname="Francois Clad" role="editor">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="X." surname="Xu" fullname="Xiaohu Xu" role="editor">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="D." surname="Bernier" fullname="Daniel Bernier">
              <organization showOnFrontPage="true">Bell Canada</organization>
            </author>
            <author initials="C." surname="Li" fullname="Cheng Li">
              <organization showOnFrontPage="true">Huawei</organization>
            </author>
            <author initials="B." surname="Decraene" fullname="Bruno Decraene">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <author initials="S." surname="Ma" fullname="Shaowen Ma">
              <organization showOnFrontPage="true">Mellanox</organization>
            </author>
            <author initials="C." surname="Yadlapalli" fullname="Chaitanya Yadlapalli">
              <organization showOnFrontPage="true">AT&amp;T</organization>
            </author>
            <author initials="W." surname="Henderickx" fullname="Wim Henderickx">
              <organization showOnFrontPage="true">Nokia</organization>
            </author>
            <author initials="S." surname="Salsano" fullname="Stefano Salsano">
              <organization showOnFrontPage="true">Universita di Roma "Tor Vergata"</organization>
            </author>
            <date month="February" day="15" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-sr-service-programming-07"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.matsushima-spring-srv6-deployment-status" target="https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status-15" quoteTitle="true" derivedAnchor="SRV6-DEPLOY-STAT">
          <front>
            <title>SRv6 Implementation and Deployment Status</title>
            <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
              <organization showOnFrontPage="true">Softbank</organization>
            </author>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Zafar Ali" initials="Z." surname="Ali">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author fullname="Zhenbin Li" initials="Z." surname="Li">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author fullname="Kalyani Rajaraman" initials="K." surname="Rajaraman">
              <organization showOnFrontPage="true">Arrcus</organization>
            </author>
            <author fullname="Amit Dhamija" initials="A." surname="Dhamija">
              <organization showOnFrontPage="true">Rakuten</organization>
            </author>
            <date day="5" month="April" year="2022"/>
            <abstract>
              <t indent="0">This draft provides an overview of IPv6 Segment Routing (SRv6) deployment status. It lists various SRv6 features that have been deployed in the production networks. It also provides an overview of SRv6 implementation and interoperability testing status.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-matsushima-spring-srv6-deployment-status-15"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.kohno-dmm-srv6mob-arch" target="https://datatracker.ietf.org/doc/html/draft-kohno-dmm-srv6mob-arch-06" quoteTitle="true" derivedAnchor="SRV6-MOB-ARCH-DISCUSS">
          <front>
            <title>Architecture Discussion on SRv6 Mobile User plane</title>
            <author initials="M." surname="Kohno" fullname="Miya Kohno">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="F." surname="Clad" fullname="Francois Clad">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="P." surname="Camarillo" fullname="Pablo Camarillo">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="Z." surname="Ali" fullname="Zafar Ali">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <date month="March" day="9" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kohno-dmm-srv6mob-arch-06"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.camarilloelmalky-springdmm-srv6-mob-usecases" target="https://datatracker.ietf.org/doc/html/draft-camarilloelmalky-springdmm-srv6-mob-usecases-02" quoteTitle="true" derivedAnchor="SRV6-MOB-USECASES">
          <front>
            <title>SRv6 Mobility Use-Cases</title>
            <author initials="P." surname="Camarillo" fullname="Pablo Camarillo" role="editor">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author initials="H." surname="Elmalky" fullname="Hani Elmalky" role="editor">
              <organization showOnFrontPage="true">Individual</organization>
            </author>
            <author initials="S." surname="Matsushima" fullname="Satoru Matsushima">
              <organization showOnFrontPage="true">SoftBank</organization>
            </author>
            <author initials="D." surname="Voyer" fullname="Daniel Voyer">
              <organization showOnFrontPage="true">Bell Canada</organization>
            </author>
            <author initials="A." surname="Cui" fullname="Anna Cui">
              <organization showOnFrontPage="true">AT&amp;T</organization>
            </author>
            <author initials="B." surname="Peirens" fullname="Bart Peirens">
              <organization showOnFrontPage="true">Proximus</organization>
            </author>
            <date month="August" day="15" year="2019"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-camarilloelmalky-springdmm-srv6-mob-usecases-02"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-spring-srv6-srh-compression" target="https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-05" quoteTitle="true" derivedAnchor="SRV6-SRH-COMPRESSION">
          <front>
            <title>Compressed SRv6 Segment List Encoding in SRH</title>
            <author initials="W." surname="Cheng" fullname="Weiqiang Cheng" role="editor">
              <organization showOnFrontPage="true">China Mobile</organization>
            </author>
            <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <author initials="Z." surname="Li" fullname="Zhenbin Li">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <author initials="B." surname="Decraene" fullname="Bruno Decraene">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <author initials="F." surname="Clad" fullname="Francois Clad" role="editor">
              <organization showOnFrontPage="true">Cisco Systems</organization>
            </author>
            <date month="June" day="20" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-compression-05"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.murakami-dmm-user-plane-message-encoding" target="https://datatracker.ietf.org/doc/html/draft-murakami-dmm-user-plane-message-encoding-05" quoteTitle="true" derivedAnchor="SRV6-UP-MSG-ENCODING">
          <front>
            <title>User Plane Message Encoding</title>
            <author fullname="Tetsuya Murakami" initials="T." surname="Murakami">
              <organization showOnFrontPage="true">Arrcus, Inc</organization>
            </author>
            <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
              <organization showOnFrontPage="true">SoftBank</organization>
            </author>
            <author fullname="Kentaro Ebisawa" initials="K." surname="Ebisawa">
              <organization showOnFrontPage="true">Toyota Motor Corporation</organization>
            </author>
            <author fullname="Pablo Camarillo" initials="P." surname="Camarillo">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Ravi Shekhar" initials="R." surname="Shekhar">
              <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
            </author>
            <date day="5" month="March" year="2022"/>
            <abstract>
              <t indent="0">This document defines the encoding of User Plane messages into Segment Routing Header (SRH). The SRH carries the User Plane messages over SRv6 Network.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-murakami-dmm-user-plane-message-encoding-05"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="TS.29281" quoteTitle="true" derivedAnchor="TS.29281">
          <front>
            <title>General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
            <date month="September" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="29.281"/>
          <refcontent>Version 17.4.0</refcontent>
        </reference>
        <reference anchor="TS.38415" quoteTitle="true" derivedAnchor="TS.38415">
          <front>
            <title>PDU session user plane protocol</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
            <date month="April" year="2022"/>
          </front>
          <seriesInfo name="3GPP TS" value="38.415"/>
          <refcontent>Version 17.0.0</refcontent>
        </reference>
      </references>
    </references>
    <section anchor="acknowledge" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Daisuke Yokota"/>,
      <contact fullname="Bart Peirens"/>, <contact fullname="Ryokichi       Onishi"/>, <contact fullname="Kentaro Ebisawa"/>, <contact fullname="Peter Bosch"/>, <contact fullname="Darren Dukes"/>, <contact fullname="Francois Clad"/>, <contact fullname="Sri Gundavelli"/>,
      <contact fullname="Sridhar Bhaskaran"/>, <contact fullname="Arashmid       Akhavain"/>, <contact fullname="Ravi Shekhar"/>, <contact fullname="Aeneas Dodd-Noble"/>, <contact fullname="Carlos Jesus       Bernardos"/>, <contact fullname="Dirk von Hugo"/>, and <contact fullname="Jeffrey Zhang"/> for their useful comments of this work.</t>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <contact fullname="Kentaro Ebisawa">
        <organization showOnFrontPage="true">Toyota Motor Corporation</organization>
        <address>
          <postal>
            <country>Japan</country>
          </postal>
          <email>ebisawa@toyota-tokyo.tech</email>
        </address>
      </contact>
      <contact fullname="Tetsuya Murakami">
        <organization showOnFrontPage="true">Arrcus, Inc.</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <country>United States of America</country>
          </postal>
          <email>tetsuya.ietf@gmail.com</email>
        </address>
      </contact>
      <contact fullname="Charles E. Perkins">
        <organization showOnFrontPage="true">Lupin Lodge</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <country>United States of America</country>
          </postal>
          <email>charliep@computer.org</email>
        </address>
      </contact>
      <contact fullname="Jakub Horn">
        <organization showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <country>United States of America</country>
          </postal>
          <email>jakuhorn@cisco.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Satoru Matsushima" initials="S." surname="Matsushima" role="editor">
        <organization abbrev="SoftBank" showOnFrontPage="true">SoftBank</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <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." showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>Belgium</country>
          </postal>
          <email>cf@cisco.com</email>
        </address>
      </author>
      <author fullname="Miya Kohno" initials="M." surname="Kohno">
        <organization abbrev="Cisco Systems, Inc." showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>Japan</country>
          </postal>
          <email>mkohno@cisco.com</email>
        </address>
      </author>
      <author fullname="Pablo Camarillo Garvia" initials="P." surname="Camarillo" role="editor">
        <organization abbrev="Cisco Systems, Inc." showOnFrontPage="true">Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>Spain</country>
          </postal>
          <email>pcamaril@cisco.com</email>
        </address>
      </author>
      <author fullname="Daniel Voyer" initials="D." surname="Voyer">
        <organization abbrev="Bell Canada" showOnFrontPage="true">Bell Canada</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>Canada</country>
          </postal>
          <email>daniel.voyer@bell.ca</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
