<?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.21 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zhao-spring-srh-extended-srv6-policy-key-01" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 -->
  <front>
    <title abbrev="srh-extended srv6-policy-key">The Correspondence between Packets and SRv6 Tunnels</title>
    <seriesInfo name="Internet-Draft" value="draft-zhao-spring-srh-extended-srv6-policy-key-01"/>
    <author initials="J." surname="Zhao" fullname="Jing Zhao" role="editor">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhaoj501@chinaunicom.cn</email>
      </address>
    </author>
    <author initials="W." surname="Lv" fullname="Wenxiang Lv" role="editor">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>lvwx28@chinaunicom.cn</email>
      </address>
    </author>
    <date year="2025" month="January" day="09"/>
    <workgroup>spring</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 46?>
<t>This paper introduces a new extension header, the SRv6 Policy Key, which addresses the issues of timeliness and accuracy in controller-aware path management within SRv6 networks. By adding a unique path identifier to the message header, this scheme enables network nodes to report path information to the controller. This ensures that the controller maintains a real-time and accurate view of the SR path status, even if the SID is lost during transmission or if the controller cannot monitor it in real time and accurately.</t>
      <t>The approach aims to enhance network availability and operational efficiency, particularly in scenarios involving multi-path tunnel configurations and load balancing.</t>
    </abstract>
  </front>
  <middle>
    <?line 50?>

<section anchor="intro">
      <name>Introduction</name>
      <t>In SRv6 networks, the software-defined network (SDN) controller serves as a core component, responsible for the centralized management and dynamic configuration of network resources. It is crucial for achieving network flexibility and intelligence.
In SR, a path must be identified for several use cases, such as binding bidirectional paths [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement [I-D.gandhi-spring-udp-pm].
Currently, the controller's perception of SRv6 message paths relies solely on theoretical derivation, which is limited in terms of timeliness and accuracy. Specifically, there is an inherent latency in the controller's update of the network state, and the state acquisition mechanism can occasionally malfunction, necessitating a secondary refresh for validation. This poses a significant challenge for scenarios that rely heavily on real-time state information for path computation and decision-making processes.
Using the configuration of multipath tunnels as an example, ideally, it should dynamically adjust traffic routing based on the master-standby relationships and priority levels of the three preconfigured tunnels. This adjustment is crucial for ensuring the high availability and operational efficiency of the network.
However, in practical applications, due to latency in the controller's state sensing, it may fail to promptly react to real-time alterations in network linkages. This delay leads to inaccurate path determinations, impacting the efficacy of operations such as traffic metering and appropriate traffic direction.
Moreover, in scenarios involving load balancing across tunnels, where a single path encompasses multiple parallel sub-paths, traffic distribution strategies based on hashing rules or random device allocation can enhance bandwidth utilization efficiency. However, they also increase the complexity of operational maintenance monitoring. This is because the current mechanisms struggle to track and validate the actual forwarding routes of packets in real-time, thereby complicating the operation and maintenance oversight.
To address these issues, this paper defines a new SRH extension header called "SRv6 Policy Key," which is used to identify the tunnel. This identifier is conveyed through the message header and communicated to the controller by the network node. This process empowers the controller to discern the SR path, thereby enhancing its state-aware capabilities within the Segment Routing domain. As a result, the controller can apprehend the network's real-time status with greater speed and accuracy, significantly aiding in the facilitation of operational maintenance decision-making processes.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>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="RFC8174">RFC2119</xref> when, and only when, they appear in all capitals, as shown here.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>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"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="srv6-policy-key">
      <name>SRv6 Policy KEY</name>
      <section anchor="format-of-an-srv6-policy-key">
        <name>Format of an SRv6 Policy KEY</name>
        <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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header   |  Hdr Ext Len  | Routing Type  | Segments Left |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Last Entry   |     Flags     |              Tag              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Segment List[0] (128-bit IPv6 address)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           ...                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Segment List[n] (128-bit IPv6 address)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SRv6 Policy KEY                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                                                             //
   //         Optional Type Length Value objects (variable)       //
   //                                                             //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    
                Figure 1: Format of an SRv6 Policy KEY       
]]></artwork>
      </section>
      <section anchor="srv6-policy-key-tlv">
        <name>SRv6 Policy KEY TLV</name>
        <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     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Preference                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Policy Color                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Headend                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Endpoint                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          SID List                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 2: SRv6 Policy KEY TLV
]]></artwork>
        <ul spacing="normal">
          <li>
            <t>Type: An 8-bit code point.</t>
          </li>
          <li>
            <t>Length: The length of the variable-length data field in bytes 6.</t>
          </li>
          <li>
            <t>Flags: 8bit, marks list.</t>
          </li>
          <li>
            <t>Preference: 32bit, marks SRv6 Policy Candidate Path.</t>
          </li>
          <li>
            <t>Policy Color: 32bit, a Color of SRv6 Policy.</t>
          </li>
          <li>
            <t>Headend: 128bit, first node of SRv6 Policy.</t>
          </li>
          <li>
            <t>Endpoint: 128bit, destination address of SRv6 Policy.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="functional-description">
      <name>Functional Description</name>
      <section anchor="function1-path-consistency-verification">
        <name>Function1: Path Consistency Verification</name>
        <t>The awareness of actual paths ensures the controller can accurately evaluate the congruence between the factual routes of data transmission and the pre-established ideal paths. 
This procedure encompasses a systematic comparison of network packets'forwarding trajectories against the planned routes, aiming to detect and rectify potential deviations in path.
Consequently, this boosts the network's reliability and operational efficiency.</t>
      </section>
      <section anchor="function2-service-flow-analysis-function">
        <name>Function2: Service flow analysis function</name>
        <t>A network node can document the traversal of SRv6 Policies, Candidate Paths, and Lists, and accumulate statistics in accordance with the service logic at these three hierarchical levels.  In instances of node upgrade or relocation, the impacted services can thus be identified.  Network nodes are capable of gathering traffic statistics based on the SRv6 Policies, Candidate Paths, and Lists that traverse the node, correlating these statistics with the service logic at the three tiers.</t>
      </section>
      <section anchor="function3-controller-path-visualization">
        <name>Function3: Controller path visualization</name>
        <t>The controller gathers the header information from packets processed at each network node and conducts statistical analyses, thereby enriching the visibility and manageability of network path data.</t>
      </section>
    </section>
    <section anchor="use-case">
      <name>Use Case</name>
      <section anchor="case-1-enhancing-real-time-path-recognition">
        <name>Case 1: Enhancing Real-Time Path Recognition</name>
        <t>The controller cannot sense packet paths in real-time. The SRv6 Policy Key addresses this limitation by providing distinctive identifiers for each path, thereby enhancing the controller's ability to identify actual paths in real-time. The accuracy of deducing real paths is impeded by the latency in sensing path information. In light of the challenges posed by delays in link state updates and the necessity for revalidation of initially detected anomalies, coupled with the issue of delayed updates to network device configurations, the SRv6 Policy Key fortifies the controller's capability for instantaneous path recognition. By embedding a unique identifier for each path, the SRv6 Policy Key effectively mitigates the difficulties associated with making path decisions reliant on immediate information. This enhancement ensures the accuracy and efficiency of network control, facilitating superior decision-making based on real-time data. 
This is evident in two scenarios:
- In the architectural design featuring triple-redundant tunnels, achieving a seamless switch-over between the primary and backup tunnels necessitates precise awareness of the state of each path to uphold uninterrupted service delivery.
- Under the policy of single-tunnel multipath, traffic is dynamically distributed based on link conditions and priority levels. This requires accurate path awareness to ensure efficient traffic handling and optimization, thereby maximizing network performance.</t>
      </section>
      <section anchor="case-2-improving-path-visibility">
        <name>Case 2： Improving Path Visibility</name>
        <t>The controller cannot sense the actual paths in real-time. In intricate network load-balancing scenarios, a single path is bifurcated into three concurrent sub-paths to collaboratively bear the traffic load, with allocation executed randomly by devices following designated hash rules. While this mechanism enhances bandwidth utilization, it presents the challenge of not being able to deduce the actual path taken, thereby introducing complexities to Operation &amp; Maintenance (O&amp;M) management and hindering fault diagnosis and resolution. 
Through the SRv6 Policy Key, the controller can attain real-time visibility of paths, thereby overcoming the uncertainty and unpredictability of paths engendered by the original random allocation mechanism.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="RFC2460" target="https://www.rfc-editor.org/info/rfc2460" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2460.xml">
        <front>
          <title>Internet Protocol, Version 6 (IPv6) Specification</title>
          <author fullname="S. Deering" initials="S." surname="Deering"/>
          <author fullname="R. Hinden" initials="R." surname="Hinden"/>
          <date month="December" year="1998"/>
          <abstract>
            <t>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="2460"/>
        <seriesInfo name="DOI" value="10.17487/RFC2460"/>
      </reference>
      <reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8200" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml">
        <front>
          <title>Internet Protocol, Version 6 (IPv6) Specification</title>
          <author fullname="S. Deering" initials="S." surname="Deering"/>
          <author fullname="R. Hinden" initials="R." surname="Hinden"/>
          <date month="July" year="2017"/>
          <abstract>
            <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="86"/>
        <seriesInfo name="RFC" value="8200"/>
        <seriesInfo name="DOI" value="10.17487/RFC8200"/>
      </reference>
      <reference anchor="RFC9386" target="https://www.rfc-editor.org/info/rfc9386" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9386.xml">
        <front>
          <title>IPv6 Deployment Status</title>
          <author fullname="G. Fioccola" initials="G." surname="Fioccola"/>
          <author fullname="P. Volpato" initials="P." surname="Volpato"/>
          <author fullname="J. Palet Martinez" initials="J." surname="Palet Martinez"/>
          <author fullname="G. Mishra" initials="G." surname="Mishra"/>
          <author fullname="C. Xie" initials="C." surname="Xie"/>
          <date month="April" year="2023"/>
          <abstract>
            <t>This document provides an overview of the status of IPv6 deployment in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges, and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC 6036.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9386"/>
        <seriesInfo name="DOI" value="10.17487/RFC9386"/>
      </reference>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <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" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <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>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA91a23IctxF93yr+AyJXWVKysyIpWZZYLjsUSZXoUJeQlFyO
Sg/YGewuxJnBGJhZan37kDzlQ/KUH8ov5HQDmMsuRTsll+LKyi7uzM4AjdOn
L+hGkiRbo1rXudoT5wslDoy1ylWmzFSZKjFV9aVSpXgh0wtVOyHLTJydLu+L
86YsVe62RnI6tWq5J5xdJOpdrfBihovl/aQyuU5XyYVabY0yk5aywByZlbM6
+X4hTeIqq8t50n8xWXsx2d7ZGpmpM7mqldvbGjVVJv03+os/Kf7MjV1BgDrb
GrlmWmjntCnPVxWmOz46f7w12hrpyu6J2jau3t3efri9C7mtkntia3Rp7MXc
mqbCCCzQ1ggT426Gt8ta2VLVySFJTePIpl4Yi3mBmtCl2xNfT/6GxeDKr+9r
jCDCHWPnstTfyxri7ImDhS6leFnq1BT4URVS53uCkHj72fbOn1P6ueFfJ2mJ
B6whnahM18biMtU1FvlI6bcso0hNU9a0bh63J9A3k5NlK843qnynJUTie79G
oHx5+W73wQeL4/+VxhaYbUmaEqePD3bv3d8OXx9AEeHrw7sP7u+xlspZ74X4
L0kSIaeutjKFDs4X2olKVspiubU1WZMq8FKU6lIwjUj5YqFkpuxY1KA08/UF
c0r8Ra3G4nKh04WQWQamO7xMD4E0Db6amah1oXJd4idmu0zTBjOvMBsWSTPm
ubKJvASBIEe9EIUs5VwVqqzFpa6xfD8jeEPcchPxaEWTETGkAKTfNeFFDRur
9UxjKbVhKQrMirF64mOxLl1gdKFKOc0hYhhXlCYj2Y2wqjK2DkNGBIFBGLMT
eiIYPEDUWF62rNeewFoAKv4nRGEgeUJo9HColVhqIE04MbR+WlfLunFjoZbw
FTr8dnwIVEVuXC2yhiwLBihLF+wTZIxP9uZPZVmaWhSmJJ4JXRPsJIjYECRf
TYgd5LRkVVkjSae6YEhUuZDkviJWcgluy6nOwVoexIA/jBJGVrOZTjXcHahR
SVvrtMmlzVnjLgXsVhuHi6XJl7SKoslrnfC6a/aCtICZnjd+RE+b3MhMTGUO
MfDOxLO40FmWq8jrT8i/MIFZXT98wnz+aWt0vMYgT2NnZjWRLsnUDPTM2sXd
Ojt8drsPolN2STZBSkyNJYALeHSQbSy8c3caVBKgiscfv1iZ6+8xaI/MtIxs
BT+i0+EKSftxcoxnGgsTnIjjmvSd2ibVQJUGh0q0Yszi47NcvdM9PWDJKs/1
nILNJKx8DLG9YcFdIwJ1dpLxqA4sg7iicRBdwoDHwjWkfCemumQ7m+pMW5UG
BdNgTrw+Tg4nWtWzpEoVAk3CD7Ee37AsiEBJbRL8EWAH2xFxqFCS7IUh4THg
Q7OFjuGryaqkKt5A+IMGobOs89V4jdU3HQ2YqiqCx9qNtu6ls/A50BlFOjCP
rHehoDqQEQuAL9BLhj46LzIsXehaEYQCUaq4zndNxFmlUiCIwYJ4llweHsLr
dIG15bCp0vu5DfF92I1WH5VJVq/GPBMTlC4x53eNdpqXWqgUdqhdQXYtTApt
sUawwkLms6ZM/ZpKBQLhHSyRnaRTmD2TdgVYZmDYgvW+BEUzRiE4sso4dv1O
z0teHFaBCSFzOffs7syXnZ0lbOFbl9pj3Hk4L3vfe9LrzEIynqb2N9kkgCQt
IynkBYkL15NyHAEFXjp2cx6+ocGw1+g5DW+fJWKWLKocMILlXjtwem5hmry1
PgZMZm/JHGCo5K4QjhsGawoDyAJfAKoDFRIspsymBF7uPdJCV54QoKyxZHs5
bCh3UaH1wioQ0aooNYYMUgao/exsA2s2ztEkrnqh54tf62zX2AT0nphLMu0x
UbCiaM/kh3NH6PYLGSOSKHLw15HV69JRJlDOGc5CrsQMQtGbUFdRwUhJ+Wnt
42cb5/JaRSeOkSPPYVEXsNSIRQZYCUGZcaxBuhNDI6s3U2SOuBsk1kVFSwkI
8fqlX32Li2sdWFRvQYOwMZAZU3iD6miK+EDr34DbUzgKE4G7KmINgxFM1Bp4
iKBhcinkDsiOynkeVgF0gZPk/MhTl3+xZF05xJ2y46TQ1AqEDE1PG+Y7JWvI
y8mjtQRdSPAQs9uGshgwB8lAZgrgtdQpYZ8br2V2FjGCT/HQpc4gEUbOQ+7a
Y9FEtKwBvOBb7kglKZTqVOAG2dc7ImMfczCLkx2gxV7eZxwUq72W8d9UpbKJ
o3jn3rk04plt5gQYJVqg6wUrK3gp/xYU33g7QeTmyER26/PMKmypdM8PBdcM
22WpmfaBOK3gPEtfdFI9XOCiBhXOTcxr6SUX89qQSfq02ecPMWc+O32ykTcL
cjnQ2o311PlGF34aUivR3wfnlXckTKmIYJfeks8w5VKt6J0FMICb2Mx3eWVY
eEH7Dln78dcSxOlqEIIoCY7RwPth7GMqMMK69TcxFjiaYkPXT107xD3jCG5d
BycSsvxUVt6dEZ9Dis9DqDl7xNPgi8FmqGUi9n327GA266kAc5vsWS1UCJth
KTfdWjhq/Fxijts1ZXWVAiL9sD7uRz4KEZopFqSbyZRkbgPQ+5h/XTyjJPWA
FFd2me0h0Yfju/PZN7bLgvbLTtx4+vLs/MbY/xXPnvP306O/vjw+PTqk72dP
9k9O2i/xibMnz1+eHHbfujcPnj99evTs0L+Mu2Lt1tP9b2/4BOTG8xfnx8+f
7Z/c8OsnP23Sxieylm2UMkna0AN84pYkT+5S+CyfRD06eCF27onXtE3d2Xn4
hr892Pn83htykKWfxpTA2V96d1NVStJOlPwXEQWAk0vF4Ijhl2RQFgRlJD8R
pwq5kU8lnTjBtrwB+T8QxNEHgjj6QBBH6yD+6x9A8Ycf/hBw/OmncEFQ4uK9
WI5+HZaj0R9fEzJv9sQX07TaufdluEELHtyMmA1uMmabdzZe9iBeceuKaVo0
B/fXkB7Ku//t4Dri3rv5xVeUyItk58FXX4bt4sAbH30bSPWYU1aycFle9cjP
P/9Mf4QQ22Lzs3PFvd0r7t0NI+zg17vinvhM3Befiwfi4X9zj8f4U/KB/3iU
H8UzRC3xxAcOuhZPMiuOcO9ElXQdvTIVAuk6eGsYnprV4sffVBYYM3LzI6qA
+Wt8Hudy7vjbj0Moz+V8eOM3lqX7xAB1gtzs9fYbcWtn9wG2vbU4fgGahETh
9seRZe0zmUyu+fVj4lL+jnBZM9+PgMudO7+ohus+d+6sj/K8CjkG2x1scY4c
5pXMsW8z07fYszhxa4kNChUzb793lA+Q5YNxobF4pMHnMe+Lxc7etQ43PNx6
3eCj1586P3nVumbx/+aY6eOdrojXgQbxunONfH2quGKZ+euPYmgvrJpR2StV
733kY8kSaHFgcmP/17IIH1DL7DpUPposR2VWGWSbvwdZqJtB4eKjybLxCQ5o
d+9qb9I6nET41ud+KXxQS7FHFgwktSGCLfpub+7tMlTioltOwu1M1lJg/55z
aj9dUeHiPo/BBrwnHmD4MTaT9oLK0c6P35nWnri723uiL/YBNgC+TPICm3D/
Xs8O2jdlsItYNPcP8fOBqXsCwZufnWkL/VBF4KrHI5m657FxqUOZri2abLzo
M+/HoVSNsHbI2x0OcjEBDz8iNNBiaMPsAAbXJ18py/tz/zj3qqikUIa5Qn3I
twC6vtxmxaDteQm1RCyN9SU8NrfNoFMftv48bldsYlUO2m+xao+NXAIgoHft
FrSJozK0l4j2rV1pJSP29cuCUrgVlkn18pTrVaCPG3aHQo3rZq8ABiEoCzCW
iilyTr1G34WscllSW8sLPaZeHj9vuKKa+n4UFz1nK9C5ppoE90aWuivZVp5N
pALstdtuDBXzjHG126i45PqXK9WTNUWTCSJgUdVylptLvCnzFVQuYkdja7Q/
qFCxDtudNBfKrKSqHaYZME7Twoe24fxmmXxP+EpkKJqci9xU3gGLU148fjA2
46IOV464KRMEzc0cWvINXxcr/guN5dp0wXV23xJAVn5MTSHqIaSeO7yCpppb
SZZlCbRQqfXVLV/gplMffi7Hy60XjRs27zD0s0Hvuq2t5Wyxc0mluMARrin3
ljfoc/xqwEKP24PtTYamHlNb1HdHfHXVDaC8FrwAXQ3o3Dox7u6R8UfD5Tr6
UrtGxrq19wA92/ZL9qwMNdBBD8qaoq0Tx7pcRoIo6nYPKOZrpyV1k123GOqf
MDt9DThWOq1OF7GwDAn7HVnfAI5GMbDlEBJar/gSsB1ALwEF+kr58VFbSD2l
guY5FTTZMZ6q1Mx96XADidD4p66NCksObrFfH59w1FqrSg9OcsTGqAcQiwVs
S18XpQ6FJkUte6wE+NzFIjzfVw/e6DBFdPrl74Er35S5PUZCzhi+lAe2qnvD
kR0pOjwVSty9FlfoZW0c8ZiQreZU+o8hvG1/+u4oD8b9KpaJGlmhPRYOUrVh
ILZgVwyHVV2zlYbmgi+3Ib0v5kK0KWTO9peapqJ2QWs33HTwK8XU+CXOBsAi
nULbZ3h04soDOyQR62o9NN50XWney+39Fv5TpnEeLtuRjk/iqGKq1g7j9BoV
m1zYkAZxQTGJqIuNced+ZXgy0+S1qFnGpy+cSTV3MRiXWF33LUJfcg8BCDEB
MOuiUJlea0O3R3a4G8bho58mtKzi8wuD1mrEOcA17vUDIIZrEOm0sRvV/9bP
ds0ItvmYCpAwSwaMS8SXpms40qk4IiQLRlGFmNJYjtHUqBAzJet4EIj6iYmF
IZQZrb/tRXZHRugYgCxyypQcEEwXCTW6BnlOZXVBpwRo9VP4jKZqm+vdkQIy
BUurXMu9uiMLuGh1ThRtqoVBzgt2UKXbNlUvuBGloXvrk8qXJblsFsUTBEP5
LmoSjga1bf+uU0pV9V5jv22ckrVG9NlSyZ3rrvGy1rwP1LC+p+DEsAvdLZWP
QzlO3gJBulMEYFWWxzazQVJbhEjVucFCvqO7/UM8vdMxk77v3/33P/8ujgv2
uHicff6rNrpc7/J73dKrXCjnJICJ2oJdX97ILOna2i0Rx2u9bMr+9KyxvqeI
cUwI4hAm9nXbjjbhlUJAOTVWBjOfUl8ipG2MG8089nbd61urdyplNfrONr24
Cn6OogwevOQ4xNbAslBP3DfEJ+KbhaZeMum0OzcTDN9d3Qfnww0gt+O69sD/
+8SNjk+xeqe+Tc2RZwNsUcsL1VN5PFdJb7bdc+3d9/O2Df2peNrrIt56/unT
2+unx5BjZD6jm0nYAagu56Vx2oVc3pm88V6OyNG1hTdObF61JarpnGLPTfXy
GO6u+9MJYUnkOrCUGM2RrylL74ekpymBYqbTWq6NIAhLWkQXl2GDc00bhHB+
oUeAVm+hdXoGPrDF8pYwi6c9sNhHh+GR4/1n+1f+PPoPl0b56ZotAAA=

-->

</rfc>
