<?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.29 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-xiong-idr-cats-sr-policy-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="BGP SR Policy Extensions for CATS ">BGP SR Policy Extensions for Computing-Aware Traffic Steering (CATS)</title>
    <seriesInfo name="Internet-Draft" value="draft-xiong-idr-cats-sr-policy-00"/>
    <author initials="Q." surname="Xiong" fullname="Quan Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
    <author initials="H." surname="Fu" fullname="Huakai Fu">
      <organization>ZTE Corporation</organization>
      <address>
        <email>fu.huakai@zte.com.cn</email>
      </address>
    </author>
    <author initials="Z." surname="Du" fullname="Zongpeng Du">
      <organization>China Mobile</organization>
      <address>
        <email>duzongpeng@chinamobile.com</email>
      </address>
    </author>
    <author initials="C." surname="Lin" fullname="Changwang Lin">
      <organization>New H3C Technologies</organization>
      <address>
        <email>linchangwang.04414@h3c.com</email>
      </address>
    </author>
    <date year="2025" month="October" day="15"/>
    <workgroup>idr</workgroup>
    <abstract>
      <?line 42?>

<t>An SR (Segment Routing) Policy is a set of candidate paths, each consisting of one or more segment lists.
The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites
offering the service. This document proposes the BGP SR policy extensions for distributing CATS services.</t>
    </abstract>
  </front>
  <middle>
    <?line 48?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Segment routing (SR) <xref target="RFC8402"/> is a source routing paradigm that explicitly indicates the forwarding path for packets 
at the ingress node.  The ingress node steers packets into a specific path according to the Segment Routing Policy 
(SR Policy) as defined in <xref target="RFC9256"/>. In order to distribute SR policies to the headend, <xref target="RFC9830"/> specifies a mechanism 
by using BGP.</t>
      <t>The CATS (Computing-Aware Traffic Steering) as per <xref target="I-D.ietf-cats-framework"/> can steer traffic between clients of a 
service and sites offering the service. Segment Routing (SR) can be used as an encapsulation solution for CATS data 
plane from an Ingress CATS-Router to an Egress CATS-Router while using an anycast IP address as the Computing-aware 
Service ID (CS-ID) associated with a service. And the CATS Service Contact Instance ID (CSCI-ID) is representing a 
specific service contact instance which serves the service request. This document proposes the BGP SR policy extensions 
for distributing CATS services.</t>
    </section>
    <section anchor="conventions">
      <name>Conventions Used in This Document</name>
      <section anchor="abbreviations">
        <name>Abbreviations</name>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
   capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="cats-sr-policy">
      <name>BGP SR Policy for CATS</name>
      <t>As per <xref target="I-D.ietf-cats-framework"/>, a standalone C-PS can be a functional component of a centralized controller.
And C-PS will collect the metric information from C-SMA and C-NMA and also determine the best paths 
to forward traffic. When the SR is used as the data plane encapsulation for CATS from an Ingress CATS-Router
to an Egress CATS-Router, the C-PS or the controller may distribute SR policies to the CATS Ingress CATS-Router.</t>
      <t>The Figure 1 shows an example of BGP SR Policy for CATS service from CATS-Forwarder 1 as ingress node to 
CATS-Forwarder 2 as egress node. The SR policy is configured with policy color 100 and NLRI is mapping to the 
CATS service which is refereed as CS-ID 1. Two service sites with service contact instances represented with
CSCI-ID 1 and CSCI-ID 2 are connected to the CATS-Forwarder 2 from the interfaces with Endpoint SID End.DX-1 and End.DX-2. 
The SR policy may be distributed to carry the identifiers of CATS services.</t>
      <artwork><![CDATA[
                             +------+
                     :<------| C-PS |
                     :       |      |<------+             Service Site 1                   
BGP SR Policy:       :       +------+       |    End.DX-1   +---------+     
NLRI: CS-ID 1        :          ^           |           +---|CS-ID 1  |     
Policy Color: 100    :          |           |           |   |CSCI-ID 1|     
Endpoint SID:        :          |  +----------------+   |   +---------+     
   End.DX-1/End.DX-2 :          |  |    C-SMA       |---| Service Site 2    
                     :          |  +----------------+   |   +---------+     
                     :          |  |CATS-Forwarder 2|   +---|CS-ID 1  |     
                     :          |  +----------------+       |CSCI-ID 2|     
          +--------+ :          |            |   End.DX-2   +---------+     
          | Client | :  Network |  +----------------------+                 
          +--------+ :  metrics |  | +-------+            |     
               |     :          +----| C-NMA |            |     
               |     :             | +-------+            |     
          +----------------+       |    |                 |     
          |CATS-Forwarder 1|<-----------+                 |     
          |                |-------|                      |         
          +----------------+       |       Underlay       |         
                                   |     Infrastructure   |   
                                   |                      |    
                                   +----------------------+    

                Figure 1: Example of BGP SR Policy for CATS

]]></artwork>
    </section>
    <section anchor="cs-id">
      <name>CATS Service Identifier in SR Policy</name>
      <t>As per <xref target="I-D.ietf-cats-framework"/>, CS-ID is representing a service in CATS, which the clients use to access it. 
CSCI-ID is representing a specific service contact instance. As defined in <xref target="RFC9830"/>, the SR policy with CS-ID 
and CSCI-ID encoding structure is shown in Figure 2 as follows:</t>
      <artwork><![CDATA[
   SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
   Attributes:
      Tunnel Encapsulation Attribute (23)
         Tunnel Type: SR Policy (15)
             Binding SID
             SRv6 Binding SID
             Preference
             Priority
             Policy Name
             Policy Candidate Path Name
             Explicit NULL Label Policy (ENLP)
             CS-ID
                 CSCI-ID
                 CSCI-ID
                 ...
             Segment List
                 Weight
                 Segment
                 Segment
                 ...
             ...

         Figure 2: SR policy with CS-ID and CSCI-ID Encoding
]]></artwork>
      <section anchor="cs-id-sub-tlv">
        <name>CS-ID Sub-TLV</name>
        <t>The format of CS-ID Sub-TLV is shown in Figure 3 as follows:</t>
        <artwork><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           CS-ID                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           sub-sub-TLVs                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 3: CS-ID sub-TLV 
]]></artwork>
        <t>where:</t>
        <ul spacing="normal">
          <li>
            <t>Type: TBD.</t>
          </li>
          <li>
            <t>Length: variable.</t>
          </li>
          <li>
            <t>Flags: 1 octet of flags.  None are defined at this stage.  Flags
SHOULD be set to zero on transmission and MUST be ignored on
receipt.</t>
          </li>
          <li>
            <t>RESERVED: 1 octet of reserved bits.  SHOULD be set to zero on
transmission and MUST be ignored on receipt.</t>
          </li>
          <li>
            <t>CS-ID: indicates the identifier associated with the CATS service. 
It is 4 octets which carry a 32-bit unsigned non-zero number in SR 
    networks and 16 octets which carry a 128-bit unsigned non-zero number
    in SRv6 networks.</t>
          </li>
        </ul>
      </section>
      <section anchor="csci-id-sub-sub-tlv">
        <name>CSCI-ID Sub-sub-TLV</name>
        <t>The format of CSCI-ID Sub-sub-TLV is shown in Figure 4 as follows:</t>
        <artwork><![CDATA[
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                           CSCI-ID                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: CSCI-ID sub-sub-TLV 
]]></artwork>
        <t>where:</t>
        <ul spacing="normal">
          <li>
            <t>Type: TBD.</t>
          </li>
          <li>
            <t>Length: variable.</t>
          </li>
          <li>
            <t>Flags: 1 octet of flags.  None are defined at this stage.  Flags
SHOULD be set to zero on transmission and MUST be ignored on
receipt.</t>
          </li>
          <li>
            <t>RESERVED: 1 octet of reserved bits.  SHOULD be set to zero on
transmission and MUST be ignored on receipt.</t>
          </li>
          <li>
            <t>CSCI-ID: indicates the identifier for a specific service contact instance.
It is 4 octets which carry a 32-bit unsigned non-zero number in SR networks and
    16 octets which carry a 128-bit unsigned non-zero number in SRv6 networks.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>To be discussed in future versions of this document.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="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>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>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>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="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>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>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="RFC9830">
          <front>
            <title>Advertising Segment Routing Policies in BGP</title>
            <author fullname="S. Previdi" initials="S." surname="Previdi"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="K. Talaulikar" initials="K." role="editor" surname="Talaulikar"/>
            <author fullname="P. Mattes" initials="P." surname="Mattes"/>
            <author fullname="D. Jain" initials="D." surname="Jain"/>
            <date month="September" year="2025"/>
            <abstract>
              <t>A Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP.</t>
              <t>This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs.</t>
              <t>Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9830"/>
          <seriesInfo name="DOI" value="10.17487/RFC9830"/>
        </reference>
        <reference anchor="I-D.ietf-cats-framework">
          <front>
            <title>A Framework for Computing-Aware Traffic Steering (CATS)</title>
            <author fullname="Cheng Li" initials="C." surname="Li">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Zongpeng Du" initials="Z." surname="Du">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization>Orange</organization>
            </author>
            <author fullname="Luis M. Contreras" initials="L. M." surname="Contreras">
              <organization>Telefonica</organization>
            </author>
            <author fullname="John Drake" initials="J." surname="Drake">
              <organization>Independent</organization>
            </author>
            <date day="15" month="September" year="2025"/>
            <abstract>
              <t>   This document describes a framework for Computing-Aware Traffic
   Steering (CATS).  Specifically, the document identifies a set of CATS
   components, describes their interactions, and provides illustrative
   workflows of the control and data planes.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-cats-framework-15"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC768">
          <front>
            <title>User Datagram Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="August" year="1980"/>
          </front>
          <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/>
          <seriesInfo name="DOI" value="10.17487/RFC0768"/>
        </reference>
        <reference anchor="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>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">
          <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>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="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>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>Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.</t>
              <t>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>
      </references>
    </references>
    <?line 230?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1aW3PayBJ+p4r/MBW/xMcWx2DHcaitUyEYn1CFHS/gvT2c
qkEaYCpCYjWSiWMnv32/nosQILCdTaXOw2p3y9JMT3dP99eXGdbzvGrltsmO
q5Ug9iM+E00WJHycep9kHE08GSSez1PlqcSbx6H077yjo2oFQ02m0qBaUdlo
JpUCcXo3x+JuZ3hRraQyDfHx7r/XbNBn13oh63xKRUSUio3jhLXj2TxLJYS0
FjwRbAixY+mzQSpEgmH2st0aDvarFT4aJQI6/qdaYY+wxIJqZTFpMuhdrWBp
lk7jpEmvHjO7+znjEfuNNkfs4gTEfww70CaZxwlPMUHjYsZl2GTaCLU/seTt
51TU/HhW8yOGh2iWPN9n/COX7CJ7AstxVptq8gLHVW5/QOZcwADnS37tqYw4
u4xHMhQFZkH22RK/9YlipgmI6yrL9pRHkwX+Yz0Z5UyvxIK9P26zofCnURzG
EylUgXkoI9+tqx2dnNRP3k6PfcO8WoniZIa93YomLelftM9Ojhru/U3j1Wn+
fnZ8pN+73nlNinRsADVOoNkiTj5q78hovM7v9emZe23U629yMfXXJ/n7m7NT
vRw79TzGRypNuJ/SdysimLwciMlMRCnrxxpq+w44UjHOlEhZPGY+jwIZ8FSw
OU+n6pAJ7k+ZD1BJRYuIJo4EbMZmMYCqLM8Q06pWrQynQiMPgH0E0vskC3GD
L5bauZFIF0JEzA8lmCoSRpolt9IXDJoxJVNySzwem7BIp8LN19hwip0gcjOt
0TyJ57ESStPYSDFRy8RqpATQPZEjraxR3rKkDRlrzmQQENiqlT3WjdIkDjKf
sMzu92Th8wtRODMnxsywe3+f3d9bVHz5Yu0dZwk25YjmPOGBnMygLU+h4ByK
Im/AOfAHMGL3AXVhzMCsSKda/Tn3PwoYCxGeaiLMJkIpFsUBrMKGa0PG5ipf
hw3EpNBc+JKcoBlz34+NHEwS0zXwOOxUKy/zDLTPOOwvxjISAbiaPRP6v3yp
wWrATEC+jpcGF7lTJG3QSJoKHogoOLTrETGwmdVOkOlmgkJRqhmkj+5Ypkgf
eFh76zkAhLpzaHR/vyUaIfeJGEXuX0cpKwfpuh01OkjKSGAnMByUwpeIfD5X
WagzJsASZvrFJXaGECWp85AjGMdJPKNFXetlovBIgDE3ZjqbE4spsqM1Hih4
dOdzlbLuNeNBoKm5wdzSjlzbkRBu9to9h5UHXvecTKliXwKnAVtIws9yxy1Y
JHVecUvbqJHITlBZpTzKebW7mhsiJBFzKAFLaf3IwA6fztK+ZSEdC+wIuYqm
bbQ4ykT8mQmVfluGqFaekCP2aEO3pC0tuVEmALS4cyfufs9f0uhMsbfHWrqe
S+1mZbI3RvtQWCZipgHWQ8nJ+ERnH2bC+aO4YwBooNiLy5vB8MWh+cuuPuj3
fufnm26/c07vg/etXi9/MRSaDwY+3PQsDb0tV7c/XF52rs4NA4yytaHL1u/4
A6QbRh+uh90PV63eC9pzumJiwgsQOKIMBNDBpamBeCCUD3saO71rX2tO9RMT
81TiEHsmZ6LE4X0xFZEWieqDrGg+4bc7xudzwRNiw8NQs0HkyJSHKF4QpKbx
IkJOSYR11GrTlAcUvLPS2mkHtR5NEIeEdMAv4CGVxbZ3PXDRzNHeRLos8BBg
nc1BEKUmX/h4S3goP8MAhOMkDkOR1KhUB4bJQoa0CsO+yeozAQD6LG8OKBtQ
3Le9wWVLW6btXdk3bB5ZFrZOZkjGevkIAWBqOhANl9hK4tJajf0Kk5pM36f4
c7mIRnSyMalmNS/l1tuRgbS00hR0aNIC7RZ86H1pCjbjd4/UCS24RGCNuTpw
IScZAFjXIDBp9ROfzZH24IQtOHA5w9iWuF4YS0GnOhlkpZRClWpljapBVKJY
godTUcgtMC72Oda62WxpZ+BuqFE/OtJOvOr1u0Q8A8ILhdjIy/U0SU8nTJQb
YZymkzKrQ/IizilNVdLytqXQQtq1qkGaScq0ecKY/Wro0Mb6CPgEbcEnK6bQ
ZjRNCVwz5r5ToRMF8xiDbABu+Kid/+YZEfajQX5ctRxhAoG1hIWW6/MkuTMy
Asqu6BISXZZX07RGxdevX20a3f4cePo52ELW/MnMPxjkPmwjs38f7B+76mCF
yFXDAVwDA28+1coKTB1T9/dglamWldsyn84pqhXCVNPBY11VPP8ryH5Ys8lD
vuzBcrOx0ybYNjVuV7k9bOFG7w85rhy3IiJyJqvclhsq7OuhdKcFS/zbIWqN
mxZs0qcd025dcUoj57b5/B3dHuP2sB5JjtOmF75VNz2Xx/Mmt4Ml8Raf6o/c
uLt3inDRDTNewO0KTTTqZ6luZYGyWzdTGpXx6UEZgy22eli31YGLbKqkG1t9
Cgf2DB22u2VJv5vDOkzqLs9ssWEJhw0Su3hT/Br903eC5yaCeiHy9y4uWx9D
3o3QeCH146xNZd0MP2N9+fCTGOwCaVlBcZ1Hk3Ue6ziKZUn/u7d6UurmRY16
3OV6NKzKk8GT+1STNzZPVq4XAHOSe2g7Ct2O2SMuekF9jvR96mlkSrXUJY4S
ho8d1HAkLLkn0Of8Q9eB2oqvWwWjebVS7D/Qh8b6emKJB+mafbC09tet2BgN
Jdq/Zm5o+GdpxkHrostMWfzp3NxxZVJNqTs1FJ4ub4d5w6JvXlkrtS2Iajrv
DzM0QyHoih1yTsdeNo73C0Cx1EN9UbxU52X91f4anN7RFRB2irK4NjPo357u
mL42LSEsvjEh40Smd+vDRoUrgKZ8pp1fDl7THVEJYcdeXLGrGxw2e3yELbqd
da561+t7064tiUDr5mfN1Gq1dfvYu5Ye/Fqy4FchJ9OyCbvuWTOb0vVIYcxh
slmO7yK6OxbdDrD6UsCQDbKRN+z94o445jCou93idFkwHG8LBna0sRtW2o02
SsaOHYs6po/ZCXvFTtlrdsbePGdMMznw/uY/movJ9RRXRkH67oloAkPn33BG
yCcq/+53Bp3+L51z/f0ddflaYjD3GH/tfr7+IF0UUKMMctSP0GXzcRh1hxOr
DSse2RZ0i9O0H/9iNncO352byHPDxtlNdssTyUehqC1XaK/jpMJiHFp11Ixp
pIaGlG5v6Ejr6pK+S6coSvmEbtH1Uqe8vTAbCf2zCUrjZ5HEDOk+TXik7G+A
OqL1tRxdf02imI775ucvehLhCzlPC9o5FK4oSJU1ucXKkUxJ0W2iHdsnaFAi
Whu9ufZjw/I4vXG9m9+/5Le8Tn43pdxzYjagbDNhjuicHTc8bINlkYI24BXF
kaf1j7LZKG9wihCJzEFB6a3UT8vZ1htnO/kWGWoRKJuOcY2ttoA21Zo8PFjG
RVnC3SAqS7sn/6Rdxv6f0q7x2q7nu6W63cnupJlrU0jA/6S8H5XytOl3JD06
oT3lOPMdU18x3RXB862Zb0u6o0PmQPgZHQLolyuFXZv/OUPhXKnsjOevzOiT
5jC2N7B+puyvXONMH79uRWJ+MIMHV34Esr+7dFtXrU1Zkke8VI6GuPnxfcT9
j9XKX6nzt02eIwAA

-->

</rfc>
