<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.43 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dmm-srv6mob-arch-04" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="SRv6mob-arch">Architecture Discussion on SRv6 Mobile User plane</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dmm-srv6mob-arch-04"/>
    <author initials="T." surname="Kamata" fullname="Teppei Kamata">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <country>Japan</country>
        </postal>
        <email>tkamata@cisco.com</email>
      </address>
    </author>
    <author initials="J." surname="Horn" fullname="Jakub Horn">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <country>Czech Republic</country>
        </postal>
        <email>jakuhorn@cisco.com</email>
      </address>
    </author>
    <author initials="L." surname="Jalil" fullname="Luay Jalil">
      <organization>Verizon</organization>
      <address>
        <postal>
          <country>USA</country>
        </postal>
        <email>luay.jalil@verizon.com</email>
      </address>
    </author>
    <author initials="W." surname="Cheng" fullname="Weiqiang Cheng">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="M." surname="Kohno" fullname="Miya Kohno">
      <organization>Keio University</organization>
      <address>
        <postal>
          <country>Japan</country>
        </postal>
        <email>miya_kohno@keio.jp</email>
      </address>
    </author>
    <date year="2026" month="September" day="01"/>
    <area>Internet</area>
    <workgroup>DMM Working Group</workgroup>
    <abstract>
      <?line 123?>

<t>This document describes the solution approach and its architectural
benefits of transforming mobile session information into routing
information, leveraging segment routing capabilities, and operating
within the IP routing paradigm.</t>
    </abstract>
  </front>
  <middle>
    <?line 130?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The existing mobile user plane is currently defined as an overlay
tunnel session to a mobile anchor point (UPF: User Plane Function in
5G context).</t>
      <t>While this approach may be suited for use cases requiring frequent
mobile handover and functionality tied to session initiation/
termination, it proves challenging to cost-effectively and scalably
address the high traffic volumes of the 5G/Beyond 5G era and the
increasingly distributed data and computing demands in the future.</t>
      <t>The requirements for wireless systems are becoming more diverse, and
there are cases , such as some IoT and FWA (Fixed Wireless Access)
systems, where the frequent mobile handover is not necessarily
mandatory.</t>
      <t>This document describes the solution approach and its architectural
benefits of transforming mobile session information into routing
information, leveraging segment routing capabilities, and operating
within the IP routing paradigm.</t>
      <t>And this document clarifies the motivation for the MUP initiatives :
<xref target="RFC9433"/><xref target="I-D.mhkk-dmm-mup-architecture"/></t>
    </section>
    <section anchor="problem-definition">
      <name>Problem Definition</name>
      <t>The current tunnel session based mobile user plane has the following
limitations and is getting hard to support new application
requirements.</t>
      <ul spacing="normal">
        <li>
          <t>Less suited for any-to-any communication</t>
        </li>
        <li>
          <t>Less suited for edge/distributed computing</t>
        </li>
        <li>
          <t>Less suited for fixed and mobile convergence (FMC) /
wireless-wireline convergence (WWC)</t>
        </li>
        <li>
          <t>Limited control of the underlay path</t>
        </li>
      </ul>
      <t>The scalability comparison in this document refers to the amount of connectivity state needed to represent optimized any-to-any communication, rather than to the computational complexity of all mobile control-plane procedures. In the existing 3GPP architecture, the mobile control plane remains responsible for establishing and maintaining PDU sessions, including the selection of the relevant user-plane functions and GTP-U tunnel endpoints. The conventional anchor-based architecture can maintain one session per endpoint, but traffic between endpoints is generally carried through the selected anchor. If optimized any-to-any connectivity among N endpoints is instead represented using a separate tunnel or forwarding state for each communicating endpoint pair, the amount of such state can grow as N(N-1), or O(N^2).</t>
      <t>In the MUP architecture, the 3GPP session-management functions continue to manage the lifecycle and policy of mobile sessions. Relevant session information is learned by the MUP control plane and transformed into destination-based routing information. A route describing reachability to a destination can be shared by traffic from multiple sources, and transit nodes do not need to maintain GTP-U tunnel state for every communicating endpoint pair. Consequently, optimized any-to-any reachability can be represented by O(N) destination-based entries at a forwarding node, before route aggregation, rather than by O(N^2) pairwise entries.</t>
      <t>This comparison does not imply that all per-session state is eliminated. The 3GPP session-management functions continue to maintain the session lifecycle and policy information required by the mobile service. Rather, the scalability benefit described here comes from representing optimized any-to-any reachability using destination-based routing information that can be shared by multiple sources, instead of maintaining separate GTP-U tunnel or forwarding state for every communicating endpoint pair.</t>
      <t>Edge/distributed computing can be seen as a subset of any-to-any
communication. IP Routing paradigm naturally supports ubiquitous
computing.</t>
      <t>As for FMC/WWC, there is currently a coordinated standardization
effort between 3GPP WWC <xref target="TS.23316"/> and BBF <xref target="BBF407"/>. However, the
idea is to anchor even wireline traffic in the mobile packet core,
which compromises simplicity and scalability.</t>
      <t>In addition, the anchor point that terminates tunnel sessions becomes
a scaling bottleneck.</t>
      <t>The IP routing paradigm naturally removes these tunnel session based
restrictions. Segment Routing enables fast protection, policy,
multi-tenancy, and provide reliability and SLA differentiation.</t>
    </section>
    <section anchor="srv6-mup-and-the-5gbeyond-5g-use-cases">
      <name>SRv6 MUP and the 5G/Beyond 5G use cases</name>
      <t>This section describes the advantages of applying the SRv6 Mobile
User Plane approach for 5G/Beyond 5G use cases. These advantage comes
from the fact that it transforms mobile session information into
routing information, leverages Segment Routing, and operates within
the IP Routing Paradigm. Another advantage, not mentioned here, is
the ability to minimize overhead through SRv6 SID Compression.</t>
      <t>In particular, the adoption of the SRv6 uSID (NEXT-C-SID) flavor <xref target="RFC9800"/> significantly reduces encapsulation overhead and enhances packet efficiency. Since uSID allows multiple segments to be compressed into a single IPv6 Destination Address (DA), it optimizes forwarding performance and minimizes the MTU impact even when long Segment Lists are required. This efficiency is a critical enabler for the use cases described below.</t>
      <section anchor="network-slicing">
        <name>Network Slicing</name>
        <t>Network slicing enables network segmentation, isolation, and SLA
differentiation such as latency and availability. End-to-end slicing
will be achieved by mapping and coordinating IP network slicing, RAN
and mobile packet core slicing.</t>
        <t>But existing mobile user plane which is overlay tunnel does not have
underlying IP network awareness, which could lead to the inability in
meeting SLAs. Removing the tunnel and treating it with a IP routing
paradigm simplifies the problem.</t>
        <t>Segment Routing has a comprehensive set of slice engineering
technologies. How to build network slicing using the Segment Routing
technology is described in
<xref target="I-D.ali-teas-spring-ns-building-blocks"/>.</t>
        <t>Moreover, the stateless slice identifier encoding
<xref target="I-D.filsfils-spring-srv6-stateless-slice-id"/> can be applicable to
enable per-slice forwarding policy using the IPv6 header.</t>
        <t>The use of uSID facilitates efficient path steering for slice-specific policies. By compressing multiple service and topological SIDs into a compact header, it reduces the risk of fragmentation and MTU-related issues associated with deep SID stacks. This supports scalable deployment of strict SLAs—such as guaranteed latency and path isolation—across the transport network without compromising packet throughput.</t>
      </section>
      <section anchor="edge-computing">
        <name>Edge Computing</name>
        <t>Edge computing, where the computing workloads and datastores are
placed closer to users, is recognized as one of the key pillars to
meet demanding requirements of 5G/Beyond 5G era, with regard to low
latency, bandwidth efficiency, data locality and privacy.</t>
        <t>Edge computing is more important than ever. This is because no matter
how much New Radio improves access speeds, it won't improve
throughput, latency and user experiences because they are largely
bound to end-to-end round trip delay.</t>
        <t>Even with existing mobile architectures, it is possible to place UPFs
in a multi-tier, or to distribute UPFs, to achieve Edge Computing.
<xref target="TS.23548"/> and <xref target="ETSI-MEC"/> describes how to properly select the
UPF of adequate proximity. However, complicated and signaling-heavy
mechanisms are required to branch traffic or properly use different
UPFs. Also, if the UPF is distributed, seamless handover has to be
compromised.</t>
        <t>When it comes to IP routing paradigum, ubiquitous computing is
innately supported. uSID is particularly beneficial here, as edge computing frequently involves a high volume of small packets, such as those generated by IoT devices. Traditional SRv6 headers with long Segment Lists can impose a disproportionately high overhead on these small payloads. uSID minimizes this overhead, thereby maximizing effective throughput and ensuring efficient utilization of bandwidth-constrained links in distributed edge environments.</t>
      </section>
      <section anchor="urllc-ultra-reliable-low-latency-communication-support">
        <name>URLLC (Ultra-Reliable Low-Latency Communication) support</name>
        <t>3GPP <xref target="TR.23725"/> investigates the key issues for meeting the URLLC
requirements on latency, jitter and reliability in the 5G System. The
solutions provided in the document are focused at improving the
overlay protocol (GTP-U) and limits to provide a few hints into how
to map such tight-SLA into the transport network. These hints are
based on static configuration or static mapping for steering the
overlay packet into the right transport SLA. Such solutions do not
scale and hinder network economics.</t>
        <t>Another issue that deserves special mention is the ultra-reliability
issue. In order to support ultra-reliability with the tunnel session
paradigm, redundant user planes paths based on dual connectivity has
been proposed. The proposal has two main options.</t>
        <ul spacing="normal">
          <li>
            <t>Dual Connectivity based end-to-end Redundant User Plane Path</t>
          </li>
          <li>
            <t>Support of redundant transmission on N3/N9 interfaces</t>
          </li>
        </ul>
        <t>In the case of the former, UE and hosts have RHF(Redundancy Handling
Function). In sending, RFH is to replicate the traffic onto two GTP-U
tunnels, and in receiving, RHF is to merge the traffic.</t>
        <t>In the case of the latter, traffic are to be replicated and merged
with the same sequence for specific QoS flow, which requires further
enhancements.</t>
        <t>And in either cases, the bigger problem is the lack of a reliable way
for the redundant sessions to get through the disjoint path: even
with the redundant sessions, if it ends up using the same
infrastructure at some points, the redundancy is meaningless.</t>
        <t>These issues can be solved more simply without GTP-U tunnel.</t>
        <t>Segment routing has some advantages for URLLC traffic.
First, traffic can be mapped to a disjoint path or low latency path
as needed. Second, Segment routing provides an automated reliability
protection mechanism known as TI-LFA, which is a sub-50ms FRR
mechanism that provides protection regardless of the topology through
the optimal backup path. It can be provisioned slice-aware.</t>
        <t>uSID further strengthens URLLC support by minimizing serialization delays and optimizing hardware processing at intermediate nodes. By shortening the overall packet length and reducing the number of required hardware lookups, uSID helps minimize jitter and provides more predictable end-to-end latency.</t>
      </section>
    </section>
    <section anchor="co-existence-and-incremental-deployability">
      <name>Co-existence and Incremental Deployability</name>
      <t>Mobile networks are composed of radio, mobile packet core, and IP
networks (access and backbone), with separate standard organizations
and communities. Therefore, in the steady state, it is difficult to
innovate to a new architecture and requires coexistence and
incremental deployment.</t>
      <t><xref target="RFC9433"/> defines the user plane convergence between GTP-U and
SRv6, so that it can co-exist with the existing user plane as needed.</t>
      <t><xref target="I-D.mhkk-dmm-mup-architecture"/> defines the MUP architecture
for Distributed Mobility Management, which can be plugged into the
existing mobile service architecture. In the architecture, mobile
session information is transformed to routing information, and
operated in L3VPN scheme.</t>
    </section>
    <section anchor="sec-security">
      <name>Security Considerations</name>
      <t>The deployment of this architecture is targeted in an administrative
domain, and the functionality is domain specific.</t>
    </section>
    <section anchor="sec-iana">
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC9433">
          <front>
            <title>Segment Routing over IPv6 for the Mobile User Plane</title>
            <author fullname="S. Matsushima" initials="S." role="editor" surname="Matsushima"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="M. Kohno" initials="M." surname="Kohno"/>
            <author fullname="P. Camarillo" initials="P." role="editor" surname="Camarillo"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <date month="July" year="2023"/>
            <abstract>
              <t>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>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>
          </front>
          <seriesInfo name="RFC" value="9433"/>
          <seriesInfo name="DOI" value="10.17487/RFC9433"/>
        </reference>
        <reference anchor="RFC9800">
          <front>
            <title>Compressed SRv6 Segment List Encoding</title>
            <author fullname="W. Cheng" initials="W." role="editor" surname="Cheng"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="Z. Li" initials="Z." surname="Li"/>
            <author fullname="B. Decraene" initials="B." surname="Decraene"/>
            <author fullname="F. Clad" initials="F." role="editor" surname="Clad"/>
            <date month="June" year="2025"/>
            <abstract>
              <t>Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists.</t>
              <t>This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9800"/>
          <seriesInfo name="DOI" value="10.17487/RFC9800"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.ali-teas-spring-ns-building-blocks">
          <front>
            <title>Building blocks for Network Slice Realization in Segment Routing Network</title>
            <author fullname="Zafar Ali" initials="Z." surname="Ali">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Pablo Camarillo" initials="P." surname="Camarillo">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Daniel Voyer" initials="D." surname="Voyer">
              <organization>Bell Canada</organization>
            </author>
            <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
              <organization>Softbank</organization>
            </author>
            <author fullname="Reza Rokui" initials="R." surname="Rokui">
              <organization>Ciena</organization>
            </author>
            <author fullname="Amit Dhamija" initials="" surname="Dhamija">
              <organization>Rakuten</organization>
            </author>
            <author fullname="Praveen Maheshwari" initials="P." surname="Maheshwari">
              <organization>Airtel</organization>
            </author>
            <date day="7" month="September" year="2022"/>
            <abstract>
              <t>   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"/>
        </reference>
        <reference anchor="I-D.filsfils-spring-srv6-stateless-slice-id">
          <front>
            <title>Stateless and Scalable Network Slice Identification for SRv6</title>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Francois Clad" initials="F." surname="Clad">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Pablo Camarillo" initials="P." surname="Camarillo">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Syed Kamran Raza" initials="S. K." surname="Raza">
              <organization>Cisco Systems, Inc.</organization>
            </author>
            <author fullname="Daniel Voyer" initials="D." surname="Voyer">
              <organization>Bell Canada</organization>
            </author>
            <author fullname="Reza Rokui" initials="R." surname="Rokui">
              <organization>Ciena</organization>
            </author>
            <date day="22" month="July" year="2024"/>
            <abstract>
              <t>   This document defines a stateless and scalable solution to achieve
   network slicing with SRv6.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-filsfils-spring-srv6-stateless-slice-id-10"/>
        </reference>
        <reference anchor="I-D.mhkk-dmm-mup-architecture">
          <front>
            <title>Mobile User Plane Architecture for Distributed Mobility Management</title>
            <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
              <organization>SoftBank</organization>
            </author>
            <author fullname="Katsuhiro Horiba" initials="K." surname="Horiba">
         </author>
            <author fullname="Yuya Kawakami" initials="Y." surname="Kawakami">
              <organization>SoftBank</organization>
            </author>
            <author fullname="Tetsuya Murakami" initials="T." surname="Murakami">
              <organization>Arrcus, Inc</organization>
            </author>
            <author fullname="Keyur Patel" initials="K." surname="Patel">
              <organization>Arrcus, Inc</organization>
            </author>
            <author fullname="Jakub Horn" initials="J." surname="Horn">
              <organization>Cisco Systems</organization>
            </author>
            <date day="2" month="March" year="2025"/>
            <abstract>
              <t>   This document defines the Mobile User Plane (MUP) architecture for
   Distributed Mobility Management.  The requirements for Distributed
   Mobility Management described in [RFC7333] can be satisfied by
   routing fashion.

   In MUP Architecture, session information between the entities of the
   mobile user plane is turned to routing information so that mobile
   user plane can be integrated into dataplane.

   MUP architecture is designed to be pluggable user plane part of
   existing mobile service architectures, enabled by auto-discovery for
   the use plane.  Segment Routing provides network programmability for
   a scalable option with it.

   While MUP architecture itself is independent from a specific
   dataplane protocol, several dataplane options are available for the
   architecture.  This document describes IPv6 dataplane in Segment
   Routing case (SRv6 MUP) due to the DMM requirement, and is suitable
   for mobile services which require a large IP address space.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-mhkk-dmm-mup-architecture-02"/>
        </reference>
        <reference anchor="BBF407">
          <front>
            <title>5G Wireless Wireline Convergence Architecture</title>
            <author>
              <organization>BBF</organization>
            </author>
            <date year="2020" month="August"/>
          </front>
          <seriesInfo name="BBF TR-407" value="Issue:1"/>
        </reference>
        <reference anchor="ETSI-MEC">
          <front>
            <title>MEC in 5G Networks</title>
            <author>
              <organization>ETSI</organization>
            </author>
            <date year="2018" month="June"/>
          </front>
          <seriesInfo name="ETSI White Paper" value="No.28"/>
        </reference>
        <reference anchor="TR.23725">
          <front>
            <title>Study on enhancement of Ultra-Reliable Low-Latency Communication (URLLC) support in the 5G Core network (5GC)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2019" month="June"/>
          </front>
          <seriesInfo name="3GPP TR 23.725" value="16.2.0"/>
        </reference>
        <reference anchor="TS.23316">
          <front>
            <title>Wireless and wireline convergence access support for the 5G System (5GS)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2021" month="September"/>
          </front>
          <seriesInfo name="3GPP TS 23.316" value="16.7.0"/>
        </reference>
        <reference anchor="TS.23548">
          <front>
            <title>5G system Enhacements for Edge Computing</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2021" month="September"/>
          </front>
          <seriesInfo name="3GPP TS 23.548" value="17.0.0"/>
        </reference>
      </references>
    </references>
    <?line 325?>

<!-- # Title of Appendix A -->

<section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Authors would like to thank Satoru Matsushima, Shunsuke Homma, Yuji
Tochio and Jeffrey Zhang, for their insights and comments.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="F." surname="Clad" fullname="Francois Clad">
        <organization>Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <country>France</country>
          </postal>
          <email>fclad.ietf@gmail.com</email>
        </address>
      </contact>
      <contact initials="P." surname="Camarillo" fullname="Pablo Camarillo Garvia">
        <organization>Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <country>Spain</country>
          </postal>
          <email>pcamaril@cisco.com</email>
        </address>
      </contact>
      <contact initials="Z." surname="Ali" fullname="Zafar Ali">
        <organization>Cisco Systems, Inc.</organization>
        <address>
          <postal>
            <country>USA</country>
          </postal>
          <email>zali@cisco.com</email>
        </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+Vb7XIbuXL9j6dA7B+Rqji0LNu7XlWSWq1k2dq1FUUf18lN
JbfAGZCENRzwDmZE0ypX5SHyhHmSnO4GZoY0vetblfKfVO0HOcQAjf44fboB
ZVmm7o/0cxUaUxV/MaWv7JFu6tYqt6z5U2gODw5+OjhUS3ek/73x+UgHXze1
nQZ8Wi/ow38oFdrJwoXgfHWzXmKO81c3Z8rU1hzpR+dVY+vKNo/Uaoavp+/e
6fe+vnPVTL+ufbt8pHLTHGlXTb16XJgGrz/WfuEa3Xhd2kZ/XJSH9TTXU1eW
uplbnbd1batG02Dtax0sjy1scLUt+LFSjWtKTHVc53PX2Lxpa6tPXchbFlPj
n+ur+x/0Oz9xpdW3wdZ6WZrKKjOZ1BZqoZ8XfpIZzKAKn1dmgfmK2kybzNlm
mhWLRRbqflB28Fw9vrPrla8L2oMpCm2CrqwtbKGUaZu5r+mH2i6tafQUoptq
reUHpTOl9ePak9S2cA1+fazbKveLBW3WTbVZLkuXm0lpaaSrAk1Gm6ff2sYv
TONyKNI1zpRBO/yD16GrvMELIv+NXS6t078ZDDZ46msY5QR68fp6HRq7gF3P
q3yMn+zCuBJecMdjf85p0Bji4Kfct1VTr4/0r2Zpqu8k+q/mrp3oN76uvknu
DxgOvVa7BT/5ZPO5vrLLdgLBvtMO3rZmjW2Urkw7+JOt3Sdf9VKXGDL+QEN+
vpfftiW/vT7+TuK+t+6vziBOT+a2mnVKn7vKxLjp5c5pyCq+8HNOYxY85AvF
00/faQPv3Nro3/y88kn436zz+rZy0G1wzbqXf4Ghf7mjoT/fYcz4w/JLN1e5
x1c3wep1CvDBo6AntvQrxHWJ/xG+BUhBYQ5ZCQkk0MN32vxZbfAMP52Upvim
iJnmGDkmbPt5Rk+2Tccz2r9VfJb+cqxPACM1INx3El5ihO+f69emvnffBkrL
XN7aHdzXS+O+Fyr92UxNrY9L901yf0Jk75aZw1qrir0F/pkcrHuAtDG1yHu5
jY6G4VdnJz89f/bsKH58eXBwpBRl0q1JBo92TXOenY4hWNZYE7KwrOG7WRWy
SevKgj7DTPldOIojkYcD/ZtGUg7MQCEaW9qAp1CpzVyRhi/md3ecKxftkvNk
SsdHGiN++eXs+cGPNFbrmLJfvNbvkchpMvngKqtPfIWYnZHcGzmdX4yplT9H
K2Be/iqE4vDg8CA7eMlPkOkdmAI0kl7AWH1zlZEc+jyE1h49xS+vbq7Ps3ev
TjZkw3cok0S8sA0S/V34mgD0+oYET19mBz98RQIarN/TphAUSwt0ufDjQ5L3
5mp8+OzHwxcbUlw3bbEmCmOrOYUk+7Of6tuyqU12BY2RT+u3fpW9xepVvob+
Fou2grM3xH72bq/evj3Z16FdLkHnaEtErLCtEw+eVMne9N6L1yf7X9vgs9eX
l5sb/OnrG6TB2Is+fDamzeinP4wPxwe0v2vs79nTHzb215kftFSvkgvkAxcw
eU6/J/mJSsUNSOCR6NffLvrh0+zgp98V/ZpEJzlJ9B970V88f7ntvEEkeAXb
iGkCy/eqmJEbL5Zt4zib/p+KRnLopxAMoo3HY6WyLNNmEuAQACt1Mwd4gcS2
7CpgyjmSFhCAlBZ82bJXAA5rb0CLSO0OYg+i1ZRqYis7pcfwNExbBcIUSnOS
6CGfUOsObPgziDlYPm958MMIzB7GNDNOk3bGYsVxOke2xYxAXQsAJWE8YsLw
HCvXzKO3nl92byxNbQo3W8R9L1xRANPVY6BvU/uizWlN0oLV9qMLzUDqtmP+
hO+xtCjX0NEUTscM3qBcgLClWaumrSpbdlvF5kyaCIEIY+qlx54RYJdnR1JV
XPLcZ0g8USMKPkK0wX5s9iEwwh5vN2SgzgAL8MQJNNpC+wV7D8SEXrAu8Puv
rSPg1VP6CGlVlABYUJCgrLJpXBC43qzhnZgH0vY2opxGvz9RKM9gxmgWlF2Q
4R7r5HNTliB1tBLezH1oMjudwhuQRaAgWiTkpgTUrBWSTE0BSXaZu9mcHGQ6
RfK8h3MtrPgMB+iTX+za41UoATblWfADfCNHuQjvnpHuYSImVVLNyag8hQ5M
s8CDkFBr2lIiGIt5RTuDsFslLJGwJKe20C1mEyfAt4LpoGVXU5gRj2iQqBtl
bkshgQk82Ny5v2Fpzt4f670z9xESdmh1zKC0r0LK/Suei2WMptLbpoLVK98A
celVYjRrRZszYCvr8f+nuD1mRxjuFmy0dlMXd7vw8DsRLqH9u9vLzpHJY4/U
w0NkRJ8/Pzz8Lvn4/FkRPlzWHplyoU8p2l2PEqnFsBXvE7hEsQM55kaE7Ki/
Kt3CNSyuZDFsbGYb3vTc1BKLMXlVdpWYKAswdGECNP1WUl2HBaZaZ43PqHeQ
D9P6jqEWSefJMJy6KNoxeMruTNLGHQ4z7t7ZOxCGJ8g8KaKynZl57/17cAZM
TgqwsUDyZQKAtioYSWH6Zi66FhBxjFMkHqwe2AW3/IGJayDN0UQoL1thPVih
YlSiCZiHxp4LDa3tEsDE/GjZQKRPvMPd+htpOCtCFvObKq0jCjMCpfytRArB
SlgZADlQFW0zE39APOa2gJuFMVIQz9PlHU7aQ1ccRf8ezhP9qqayoSLMD0t4
kiNWx2bFNielC3OakA2GYQ3+pe+Xp7fJYRGGANayLRjESdewnOShaA8y5b2B
esibo/QpdYjnvr65zG5TINiq4ASHfXGYkOGrqBtJgJnEyHCDAIaqkxC0tYcc
wEM35UjDQ7u8MQEFtbbqF5QIqoAnJTJEbuqaU9ocUELpptsb25cEgeanXzP6
wGHgR9DNxeZC0DlqoaL3HkzQBlY2liHUgpNFlVDg+HqFoGZMZP9jGxEiD/wL
P6Y14PyuHm25MacZeZ30Nav9irLOxd5F9nR/RMv8897Ffx4SZVDRpwgAv/Qk
drCo4QzJxMykQOjNSk7mqtaSj8sAfrF0yO7rnLlMASIDRGI338wTMP1Vcpqd
qSMgR5iauNNk3Ym56dec9VMqsoWkG2S3JvKQ6EQpTQymH+tjfmxTMqTfa9J1
ghDmZIO5WJtEpoC7UaboY9PaL/SiLRu3pO35ts5T4mLhwIUqj5kAQTFJC6Z0
rrwRGgPLAwzXv2f6MZWzQRhBuR7t9tKNTcU9DP0RG4FD7O9Qm6WWFMSmrtPQ
N2kziDI7JdIjSjSzWW1nO9BPZoe7scArB/oZpyX/Y1oywOrCW+ExDvBIRqel
AY6I7yz5iOgH71nKjRDYFgIif6u/RuVLyMvcOz136JQxp3Yu2bl0fe9yC4/m
rUv8DPNR5E4d8yo0UzpsHRtm/+lMQhr+Y0MKinyTq4sav/DeLx02oRWF6iAP
dEC14aZfhas/dFqlXn2VTXRiEmZTyQQ4m1AnjbJkpwq1kW7HxASvtpighlZa
wfjIj4JuJw7Wa3wbVLcgMUYh+OAlT8A52Hb1VhFnIKGnnZK3aT7moo1/ErqE
aob4V0o17IeYST88pK7E58/sUNQgeniQVtXnz2P9xq9IXSOpXApraFXCHSkB
8VvVty0S2kSXjZ63NPkd1JMjFEdqNXeSK8AbFo6qjkCB5HJOUF2dxR40ZvRH
veUkaDmJDEtP9ppU0xF53qCwQWofG5ThWUn3E980qPRsfheLqB0MfWAXkBIu
ELFysDsZMigs+YhE71hfxzoh2dpW1J6C9UzgarMRSjKKgTtS7OJZg3EVvkpM
oyiFpomvuBRL9Pz67THqtym3NGNFO2ZmL6d7lCClwtwsPbtyOmJZiKxos8Iy
BWU54BHXTsTR14lIDQ4P1aDM70ox8szdKzLohcHkgiaK0YSLCJNHK7qmz5Lh
j8o1tQNCunINO9iywrBAw69Sn6lYnyVLXab6TB8D3Sk5dFKPGO8Xwv4iLgKK
Ak8xyMVwQ4ZEbqHMCaYSZ2MVXp+fclOsll2Jd8PpGpe3qP+ifxcErD1p5Tdb
enXv4tW/3mQnGT7v62lp7qF2KQJfHhwgeoObVaghgU4Ne27RUt8bhYpZBswv
kybBSCGxoxpSgFqKXUctVPixowKH1zVU54UBFotyGQUmUjTQjhK1QaxRZ4N0
C8lPB+TkODZO9k6P97n7klJIGMI0rMQ25dYn0f2oVHHTdze3lHjJbQR65vhP
SbQ22fwtMFs6HykRkhdSLu62RxAGuKwBK4CFGKN1V2v3/ac+FfLxASz2+HHq
hutrAi0Ulyo9CPKgi/nUWo4KS12n4Mv4MQa12grqrgtTxoY2jTP3xnW4qF9V
BeUZS3gZxVjRlYEJtYvnDqqR/IkYTWVTlx3oAfy+2pR6pK+OL9SgIB6gdhqD
/f+CuuV32oqC7lBvbCImyOxI09zcWyWF8XpLEAMPADIHbiZJkmjLggh2kQpU
iB+jDfG7sJalgAaZpwOpE2LFVYXdWtky/I0CH4bvIV91kC9JqOvALKVXgg1v
A/qcM744PXwv0DFTTP58GqS5jWgtdS0V0H5e+dLPiEtSKuWYoaOmbfVHssQR
v7liPwn7be+SUIE0fv74OAuJXKl3sKS/75hfOsSKYiPhwP+gAKpSc08vx+m/
8QwMCBSJUX/UiO0qiQahx7zSMNaFvfZ7Z8wggLJ1zM8UjNAtIxGyBVmfQTxF
c8PdFWxHVM5BLCKFpc0JD2UVtsAv6w6u2H97SGNuLA7jl2wxQgYsGhKqcQkA
2BHpGL8SxnJzwYU7EnSKDNRFO08IyMqQypmWOTpygwOF4HPHT9gnC2uXnB6g
VpgrAlZHCmPrmerAZenX6QhMeAf7///8138n0Ji18GlUTZh7iB+spQ57MN7k
tY9dbE68sT8nXklSwf16nib8iBEh5jRwU8HDrcMeZs49Wx52hnsKTYuU3hTS
dqG+d2jgnozbClCSE+EuPQELlE8AQ9yfmkO5R5b7JIcV1F6JafLOrvUSCGi4
a8bYEHvnUjQPOuV4Y7s1PxIzUHko/Uo6K47aQxWJWVauwIA+hYykWY/oMh0/
Q3jcm3w93lYBCc7Nd2AMlGyEuFZchkRTO+aqhpy9orqvAalVc+DFgqx6YVeo
2grnaQY5sUiHgkvYObAzrnz1900aoHojjTbcgLHaflzS+Vo8F5dlocQ1Z02o
cGbLtZr4lqOBKqOUa2p5VrsllAt4p61KAUDK2UoLw26NiIhdLuFzTpBBs531
7eVZUCgYjI5U2FF0eTZ8X3/xsBEXHpLfttxurGIl8+L5y1jJPDykY2086Mnu
XFAYalpSEoqtNC5vsAaT3wLuQrUixnyk1u56UAZxV5Squtg+JtbFpUUGYLhf
w/NQAFcuLDY5CAM/3Snpj4uoiklCkAU6FkByAAOOy+BHdD2D/JtEI/TvC9IR
JDcLRvDuhIV788TKVF9gFXzuBiO5JtbyGPFl1dMuRoPic8N5YR0qr/oylSgV
AzIZtOOvZWohANnKyJEhj92MhXQ6VFIOv/clO7Oco8n5GSPbgjsqjDehP5UC
JkFP0hmNbSE6oyosgTehJu0kdmiZNwtWC+PfxRIpYVFQUolCuiV7YH80A++X
xeo4M7cpqJxJ4q0ZwqIuhjw1EiB6K9bqTMbImT4xQ0xniwMwjZQ8tHUcEdMb
1FbGKp5U04FRlqPghC/xyS0c8I4PCYcdC9a8re5d7at0wkKAzRci9N633qDo
rk4oxW0DBFq8qIG4gg2J4c+k/I5AHLMcpeJE0tiHaV21icWV7mD2gyPUYzUM
K9/+voZcd+CaUqUDwZCq5SIN7M5QKPym+MIt+oSMURaV+CmV5D73pd7jztE+
L88HWiGiBJfiRk+BwXPpmRMfAIoo7tAtxTuhgnmTUYXOP+/Mqqkalmko00k/
LDYMAQkw6RShWEdr1+l54vFMbhLT2diGpOZu7ZrEGUgAwVDTcde9U5x0ehWR
C2E+kAvR0nEApNoKCJIHPrGUkpgtKwU7EBWsyXIO4oiP9TH3h4i4sXsNLKn4
ZT4kQiUimT2dC34xWEJ2wOVjK6Bj7CNmX1WRznOkAAnMc4LuFFu0fJI1OAQB
RqoJ9cA42EPqzMo3Ai4CmpU0X7XU4nI0eUpTnQynSi3oLj9edSIN+iSXdPqX
QfuyVcRwLzlbKF4nJ3Evnj25+InMiCIYyTF0xx9UjyauwwcJSEW3r8RsnqCM
Cit99eZsL8mAMH6Dnyk1qXQjY5+1HyyzIlR8Z29iN6+2Maklz5UMxe4EXXBs
xAsh8dTAUaM5t+5eZnpzFmda0OHocJbxzj2UTHFG3VIUrNJP6ESJx7M0X6E6
d+B7pnKeILWE7nj+v/hrPQVzS/VjRBoAUVuT96rBFbIQj+GxDevYtbnil9po
4mYzW6ciMDk02AozfBPhCVGzMmuVuga9Ubv2IzY06wmzoJMLH2KbuZkfcQ+j
39uXU3D+R+K2dAekXQ4qJdID3VaowZzrVs4eEZV8cUMO90Ybc0rXY2FNxd2Z
EKS+CjahdepqU0ouhK8GOeJIxcCwtz6ojOtBZczLD1qJpBxJN503nLk6NL3h
47KEcMKSzKaOCAXppnEisXyW3v2pATVcEd3IstvSROTmG03xfqvdSCyq78bq
jrTpu8qvuKt/c569PTse9R0NbvNnLw5A7M6urnqeJ2jYLTeYVcoJZmjR62Nt
uU4uwQ1E7oIBWibwL5iYNogw7U5DeOYgjUcpbLlRAgNITSy+TcWgrWYNtSSi
xhO2EvUQbiInJTXAOhEKZvEhtkebNIZubdAacrYvtbJpBJYWtnB87YBOC7mi
DnOihFVyTEpJPXvTJUsVszrK5TSsahcTiM1oGClyt2zpPTQBB+Ydzm25DH1v
dUATOqWzt6KsL1APc2AOMDk6DtWqQO+MqxSbmovndBWLy/VSn3JxnbxDxb+W
idlQ2DzRWM+ZBWJTQTbadcYhM1+q7tW9WK3Rc7LyBMbcjzVnd3KVTmzobiQc
SwwUVLwORnSscbGjXvOx5igxHj4Ri9dBUp1FxQTRcvprIeLv/p7BncKL7+AM
ryyIbSJW5n5DQ3JZLWqobz9Am4P7R/ECYUjd09QNHN6VSSdPAiI0MzF0+hOr
rv9PDp9HC/X5vysrBxP38a/UH15+2pBu+xoBw/fpgDSz2Sm5v+tOZ7t+ZAzI
skV6KDqypbYL366bNFinuxuzeYdB3lBfuVswvDbQ31HbPPQgTcaTDc5mb5/9
6fJCh3wO0ePpkM1RUzRrPohHuNTxqtbD42DzLMRfP0u7bbPDJDc1h75CUlGD
IK5G4FpQaFIlQgWNKjwRp1F3FLV5N5PvODGzSllbZDw/vjjeLZ+DGT7Hk6uF
Xfh4yYfbyey1KD+4osUMNBfdiaUYU+of/g4fH+sbuqxMmzlGhgHx+aiPdZb9
Ey97nBPel1QoMSlQD0cRmGzxj4+mpgz2ERY/lj9m0StpSLs7Kw1pU93pa7q+
2MJbmtCGOYAcqWjeoozDoDeIW3z/t/aDUzceWvSsll9R3NUok/6MCcCdIoFw
NR1uE28P6Q5oJCr/C6HmJ7q8OAAA

-->

</rfc>
