<?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.4 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-chen-pce-pce-initiated-ip-tunnel-04" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.19.0 -->
  <front>
    <title abbrev="PCE IP Tunnel">PCE-initiated IP Tunnel</title>
    <seriesInfo name="Internet-Draft" value="draft-chen-pce-pce-initiated-ip-tunnel-04"/>
    <author initials="X." surname="Chen" fullname="Xia Chen">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>jescia.chenxia@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Shi" fullname="Hang Shi" role="editor">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>shihang9@huawei.com</email>
      </address>
    </author>
    <author initials="Z." surname="Li" fullname="Zhenbin Li">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>lizhenbin@huawei.com</email>
      </address>
    </author>
    <date year="2024" month="January" day="11"/>
    <area>Routing</area>
    <workgroup>Path Computation Element</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 54?>

<t>This document specifies a set of extensions to PCEP to support PCE-initiated IP Tunnel to satisfy the requirement which is introduced in <xref target="I-D.li-spring-tunnel-segment"/>.  The extensions include the setup, maintenance and teardown of PCE-initiated IP Tunnels, without the need for local configuration on the PCC.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Path Computation Element Working Group mailing list (pce@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/pce/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/VMatrix1900/draft-pce-initiated-ip-tunnel"/>.</t>
    </note>
  </front>
  <middle>
    <?line 58?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="I-D.li-spring-tunnel-segment"/> introduces a new type of segment, Tunnel Segment, for the segment routing.  Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. The tunnel segment can be allocated for MPLS RSVP-TE tunnel, SR-TE tunnel or IP tunnel. IP tunnel is also useful in SD-WAN scenario.</t>
      <t><xref target="I-D.li-spring-tunnel-segment"/> introduces two ways to set up the tunnel which is used as tunnel segment: one is to configure tunnel on the device, the other is PCE-initiated tunnel.</t>
      <t><xref target="RFC8231"/>, <xref target="RFC8281"/> and <xref target="RFC8664"/> has defined how to set up the PCE initiated RSVP-TE LSP and SR-TE LSP.  This document specifies a set of extensions to PCEP to support PCE-initiated IP Tunnel. The extensions include the setup, maintenance and teardown of PCE-initiated IP Tunnels, without the need for local configuration on the PCC.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <ul spacing="normal">
        <li>
          <t>SR: Segment Routing</t>
        </li>
        <li>
          <t>SR-TE: Segment Routing Traffic Engineering</t>
        </li>
      </ul>
      <t>This document uses the terms defined in <xref target="RFC5440"/>: PCC, PCE, PCEP
   Peer.</t>
      <t>The following terms are defined in <xref target="RFC8281"/>:</t>
      <ul spacing="normal">
        <li>
          <t>PCE-initiated LSP: LSP that is instantiated as a result of a request
   from the PCE.</t>
        </li>
      </ul>
      <t>The following terms are defined in this document:</t>
      <ul spacing="normal">
        <li>
          <t>IP Tunnel: Tunnel that uses IP encapsulation.</t>
        </li>
        <li>
          <t>PCE-initiated IP Tunnel: IP Tunnel that is instantiated as a result
   of a request from the PCE.</t>
        </li>
      </ul>
      <t>The message formats in this document are specified using Routing
   Backus-Naur Format (RBNF) encoding as specified in <xref target="RFC5511"/>.</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 BCP14 <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="procedures-for-pce-initiated-ip-tunnel">
      <name>Procedures for PCE-initiated IP Tunnel</name>
      <section anchor="overview-of-procedures">
        <name>Overview of Procedures</name>
        <t>A PCC or PCE indicates its ability to support PCE Initiated dynamic
   tunnel during the PCEP Initialization Phase via "PCE Initiated Tunnel
   Capability" TLV (see details in <xref target="tunnel-cap"/>).</t>
        <t>In this document, the procedure is only about PCE Initiated dynamic IP
   Tunnel.  The decision of when to instantiate or delete a PCE-initiated
   IP Tunnel is out of the scope of this document.</t>
        <t>This section introduces the procedure to support PCE provisioned IP
   Tunnel as follows:</t>
        <t>Firstly both the PCC and the PCE negotiate the PCE Initiated Tunnel
   Capability for tunnel types during the PCE session initiation phase.
   On the PCEP session with PCE Initiated Tunnel Capability PCE
   communicates with PCC to set up, maintain and tear down PCE-initiated
   IP Tunnels.</t>
        <t>The procedure about tunnel state synchronization, PCC local policy
   and timeout process, the session failure process, etc. will be
   specified in the future version.</t>
      </section>
      <section anchor="capability-advertisement">
        <name>Capability Advertisement</name>
        <t>During PCEP session establishment, both the PCC and the PCE must
   announce their support of PCEP extensions defined in this document.
   A PCEP Speaker (PCE or PCC) includes the "PCE Initiated Tunnel
   Capability" TLV, described in <xref target="tunnel-cap"/>, in the OPEN Object to
   advertise its support for PCEP extensions for PCE Initiated IP Tunnel
   Capability.</t>
        <t>The PCE Initiated Tunnel Capability TLV includes the tunnel types
   that are supported by PCEP Speaker.  Each tunnel type is indicated by
   one bit.</t>
        <t>The presence of the PCE Initiated Tunnel Capability TLV in PCE's OPEN
   message indicates that the PCE can support the instantiation of PCE-
   initiated Tunnels and the types of the tunnels which PCE can
   initiate.</t>
        <t>The presence of such Capability TLV in PCC's OPEN Object indicates
   that the PCC can support to instantiate the tunnel according to the
   PCE's indication and the types of the tunnels which PCC can setup
   automatically according to the PCE's request.</t>
        <t>If PCE has such capability TLV and PCC has no such capability TLV PCE
   <bcp14>MUST NOT</bcp14> send the PCE messages for procedure of PCE initiated IP
   Tunnel.  And if PCC receives such messages it should send PCErr
   message to PCE.</t>
        <t>If both PCE and PCC have such capability TLV they only negotiate the
   types of the tunnels both PCE and PCC can support.  PCE <bcp14>MUST</bcp14> only
   initiate the specific tunnel which both PCE and PCC can support.
   Otherwise PCC <bcp14>MUST</bcp14> send the PCErr message.</t>
      </section>
      <section anchor="tunnel-operations">
        <name>Tunnel Operations</name>
        <section anchor="pce-ip-tunnel-instantiation">
          <name>PCE IP Tunnel Instantiation</name>
          <t>To instantiate a tunnel, the PCE sends a Path Computation Tunnel
   Initiate (PCTunnelInitiate) message to the PCC.  The PCTunnelInitiate
   message <bcp14>MUST</bcp14> include the SRP object (see details in <xref target="srp"/>) and
   TUNNEL object (see details in <xref target="tunnel-obj"/>) . The TUNNEL object <bcp14>MUST</bcp14>
   have a PTUNNEL-ID of 0 and <bcp14>MUST</bcp14> include the Tunnel Identifier TLV
   with the TUNNEL-ID 0 and the Tunnel Name TLV.  The TUNNEL object <bcp14>MAY</bcp14>
   have the Tunnel Parameter TLV.</t>
          <t>The PCC creates the different type of tunnel using the end point
   address carried in Tunnel Identifier TLV and sends the Path
   Computation Tunnel State Report (PCTunneRpt) message to PCE.  The
   PCTunneRpt message <bcp14>MUST</bcp14> include the SRP object and TUNNEL object.
   PCC assigns a unique PTUNNEL-ID carried via TUNNEL object and a
   unique TUNNEL-ID carried via Tunnel Identifier TLV(see details in
   <xref target="tunnel-obj"/>) in TUNNEL object for the tunnel.  PCC indicates the
   operational state in the TUNNEL object.</t>
          <t>The PCTunneRpt message <bcp14>MUST</bcp14> include the SRP object, with the SRP-ID-
   NUMBER used in the SRP object of the PCTunnelInitiate message.</t>
          <artwork><![CDATA[
                  +-+-+                    +-+-+
                  |PCE|                    |PCC|
                  +-+-+                    +-+-+
                    |                        |
1) add new tunnel   |-- PCTunnelInitiate --> |
                    |    PTUNNEL-ID=0,       |
                    |     TUNNEL-ID=0        |
                    |         R=0            |
                    |            .           |
                    |                        |
                    |<---- PCTunneRpt  ------| 2) Tunnel Status Report sent
                    |    PTUNNEL-ID=1,       |
                    |     TUNNEL-ID=1        |
                    |           Up           |
                    |                        |
]]></artwork>
        </section>
        <section anchor="pce-ip-tunnel-update">
          <name>PCE IP Tunnel Update</name>
          <t>To update the parameters used to create a tunnel, the PCE sends a
   Path Computation Tunnel Update (PCTunnelUpd) message to the PCC.  The
   PCTunnelUpd message <bcp14>MUST</bcp14> include the SRP object and TUNNEL object.
   The TUNNEL object <bcp14>MUST</bcp14> have specific PTUNNEL-ID and <bcp14>MUST</bcp14> have
   specific Tunnel Identifier TLV.  The TUNNEL object <bcp14>MUST</bcp14> carry any of
   the Tunnel Parameter TLV and Tunnel Attribute TLV.</t>
          <t>The PCC updates the encapsulation parameters and/or attributes of the
   tunnel and PCC sends the PCTunneRpt message to PCE to report updated
   state.</t>
          <t>The PCTunneRpt message <bcp14>MUST</bcp14> include the SRP object, with the SRP-ID-
   NUMBER used in the SRP object of the PCTunnelUpd message.</t>
          <artwork><![CDATA[
                  +-+-+                    +-+-+
                  |PCE|                    |PCC|
                  +-+-+                    +-+-+
                    |                        |
1) update tunnel    |----  PCTunnelUpd ----> |
   parameter        |    PTUNNEL-ID=1,       |
                    |     TUNNEL-ID=1        |
                    |            .           |
                    |                        |
                    |<---- PCTunneRpt  ------| 2) Tunnel Status Report sent
                    |    PTUNNEL-ID=1,       |
                    |     TUNNEL-ID=1        |
                    |           Up           |
                    |                        |
]]></artwork>
        </section>
        <section anchor="pce-ip-tunnel-deletion">
          <name>PCE IP Tunnel Deletion</name>
          <t>To delete a tunnel, the PCE sends a Path Computation Tunnel Initiate
   (PCTunnelInitiate) message to the PCC.  The PCTunnelInitiate message
   <bcp14>MUST</bcp14> include the SRP object and TUNNEL object and the 'R' flag in SRP
   object <bcp14>SHOULD</bcp14> be set.  The TUNNEL object <bcp14>MUST</bcp14> have specific PTUNNEL-
   ID and <bcp14>MUST</bcp14> have specific Tunnel Identifier TLV.</t>
          <t>The PCC delete the tunnel specified by PTUNNEL-ID and PCC sends the
   PCTunneRpt message to PCE to report updated state.</t>
          <t>The PCTunneRpt message <bcp14>MUST</bcp14> include the SRP object, with the SRP-ID-
   NUMBER used in the SRP object of the PCTunnelInitiate message.</t>
          <artwork><![CDATA[
                  +-+-+                    +-+-+
                  |PCE|                    |PCC|
                  +-+-+                    +-+-+
                    |                        |
1) delete tunnel    |-- PCTunnelInitiate --> |
                    |    PTUNNEL-ID=1,       |
                    |     TUNNEL-ID=1        |
                    |         R=1            |
                    |            .           |
                    |                        |
                    |<---- PCTunneRpt  ------| 2) Tunnel Status Report sent
                    |    PTUNNEL-ID=1,       |
                    |     TUNNEL-ID=1        |
                    |           DOWN         |
                    |                        |
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="pcep-messages">
      <name>PCEP Messages</name>
      <t>To initiate a tunnel, a PCE sends a PCTunnelInitiate message to a
   PCC.</t>
      <t>To report the state of a tunnel, a PCC sends a PCTunnelRpt message to
   a PCE.</t>
      <t>To modify the parameters of a tunnel, a PCE sends a PCTunnelUpd
   message to a PCC.</t>
      <t>The message format, objects and TLVs are discussed separately below
   for the creation and the deletion cases.</t>
      <section anchor="pctunnelinitiate-message">
        <name>PCTunnelInitiate Message</name>
        <t>A Path Computation Tunnel Initiate message which is also referred to
   as PCTunnelInitiate message is a PCEP message sent by a PCE to a PCC
   to trigger tunnel instantiation or deletion.</t>
        <t>The Message-Type field of the PCEP common header for the
   PCTunnelInitiate message is to be assigned by IANA.  The
   PCTunnelInitiate message <bcp14>MUST</bcp14> include the SRP and the TUNNEL objects.
   If the SRP object is missing, the PCC <bcp14>MUST</bcp14> send a PCErr with error-
   type 6 (Mandatory Object missing) and error-value=10 (SRP Object
   missing) (per <xref target="RFC8231"/>).  If the TUNNEL object is
   missing, the PCC <bcp14>MUST</bcp14> send a PCErr with error-type 6 (Mandatory
   Object missing) and error-value which means TUNNEL Object missing.</t>
        <t>Tunnel instantiation is done by sending an Tunnel Initiate Message
   with an TUNNEL object with the reserved PTUNNEL-ID 0.  Tunnel
   deletion is done by sending an Tunnel Initiate Message with an TUNNEL
   object carrying the PTUNNEL-ID of the tunnel to be removed and an SRP
   object with the R flag set.</t>
        <t>The format of a PCTunnelInitiate message for tunnel instantiation is
   as follows:</t>
        <artwork><![CDATA[
   <PCTunnelInitiate Message> ::= <Common Header>
                                  <PCE-initiated-tunnel-list>
Where:
   <PCE-initiated-tunnel-list> ::= <PCE-initiated-tunnel-request>
                                   [<PCE-initiated-tunnel-request>]
   <PCE-initiated-tunnel-request> ::= (<PCE-initiated-tunnel-instantiation>
                                       |<PCE-initiated-tunnel-deletion>)
   <PCE-initiated-tunnel-instantiation> ::= <SRP>
                                            <TUNNEL>
   <PCE-initiated-tunnel-deletion> ::= <SRP>
                                       <TUNNEL>
]]></artwork>
        <t>The SRP object defined in <xref target="RFC8231"/> can be used in
   this document to correlate tunnel initiate requests and update
   requests sent by the PCE with the error reports and tunnel state
   reports sent by the PCC.  Every request from the PCE sends a new SRP-
   ID-NUMBER.  This number is unique per PCEP session and is incremented
   each time an operation (initiation, update, etc) is requested from
   the PCE.  The value of the SRP-ID-NUMBER <bcp14>MUST</bcp14> be echoed back by the
   PCC in PCErr and PCTunnelRpt messages to allow for correlation
   between requests made by the PCE and errors or state reports
   generated by the PCC.  Procedure of PCE-initiated IP Tunnel share the
   same number space of the SRP-ID-NUMBER with procedure of stateful
   PCE.</t>
        <t>The &lt;TUNNEL&gt; object is an new object introduced in this document.
   &lt;TUNNEL&gt; object in PCTunnelInitiate message <bcp14>MUST</bcp14> include Tunnel
   Identifier TLV and Tunnel Name TLV.  Tunnel Parameter TLV is
   optionally included.</t>
        <t>The Tunnel Initiate message for tunnel instantiation has the TUNNEL
   object with the TUNNEL-ID in Tunnel Identifier TLV 0.  The Tunnel
   Initiate message for tunnel deletion has the TUNNEL object carrying
   the TUNNEL-ID of the TUNNEL to be removed.</t>
      </section>
      <section anchor="pctunnelupd-message">
        <name>PCTunnelUpd Message</name>
        <t>A Path Computation Tunnel Update Request message (also referred to as
   PCTunnelUpd message) is a PCEP message sent by a PCE to a PCC to
   update the encapsulation parameters and/or attributes of a tunnel.  A
   PCTunnelUpd message can carry more than one Tunnel Update Request.</t>
        <t>The Message-Type field of the PCEP common header for the PCUpd
   message is to be assigned by IANA.</t>
        <t>The PCTunnelUpd message <bcp14>MUST</bcp14> include the SRP and the TUNNEL objects.
   If the SRP object is missing, the PCC <bcp14>MUST</bcp14> send a PCErr with error-
   type 6 (Mandatory Object missing) and error-value=10 (SRP Object
   missing) (per <xref target="RFC8231"/>).  If the TUNNEL object is
   missing, the PCC <bcp14>MUST</bcp14> send a PCErr with error-type 6 (Mandatory
   Object missing) and error-value which means TUNNEL Object missing.</t>
        <t>The format of a PCTunnelUpd message for tunnel parameter update is as
   follows:</t>
        <artwork><![CDATA[
      <PCETunnelUpd Message> ::= <Common Header>
                                 <tunnel-update-request-list>
   Where:
      <tunnel-update-request-list> ::= <tunnel-update-request>
                                       [<tunnel-update-request-list>]
      <tunnel-update-request> ::= <SRP>
                                  <TUNNEL>
]]></artwork>
        <t>&lt;TUNNEL&gt; object in PCTunnelUpd message <bcp14>MUST</bcp14> include Tunnel Identifier
   TLV and any of Tunnel Parameter TLV and Tunnel Attribute TLV.  Tunnel
   Name TLV is not included.</t>
      </section>
      <section anchor="pctunnelrpt-message">
        <name>PCTunnelRpt Message</name>
        <t>A Path Computation Tunnel State Report message which is also referred
   to as PCTunnelRpt message is a PCEP message sent by a PCC to a PCE to
   report the current state of a tunnel.  A PCTunnelRpt message can
   carry more than one Tunnel State Reports.  A PCC sends an Tunnel
   State Report in response to a Tunnel Initiate Request for creation or
   a Tunnel Update Request from a PCE.</t>
        <t>The Message-Type field of the PCEP common header for the PCTunnelRpt
   message is to be assigned by IANA.  The PCTunnelRpt message <bcp14>MUST</bcp14>
   include the SRP and the TUNNEL objects.  If the SRP object is
   missing, the PCE <bcp14>MUST</bcp14> send a PCErr with error-type 6 (Mandatory
   Object missing) and error-value=10 (SRP Object missing) (per
   <xref target="RFC8231"/>).  If the TUNNEL object is missing, the
   PCE <bcp14>MUST</bcp14> send a PCErr with error-type 6 (Mandatory Object missing)
   and error-value which means TUNNEL Object missing.</t>
        <t>The format of a PCTunnelRpt message for tunnel instantiation is as
   follows:</t>
        <artwork><![CDATA[
      <PCTunnelRpt Message> ::= <Common Header>
                                <tunnel-state-report-list>
   Where:
      <tunnel-state-report-list> ::= <tunnel-state-report>
                                     [<tunnel-state-report-list>]
      <tunnel-state-report> ::= <SRP>
                                <TUNNEL>
]]></artwork>
        <t>&lt;TUNNEL&gt; object in PCTunnelRpt message <bcp14>MUST</bcp14> include Tunnel Identifier
   TLV.</t>
        <t>Tunnel Parameter TLV and Tunnel Attribute TLV is optionally included
   in PCTunnelRpt message.  In the first PCTunnelRpt message in response
   to the PCTunnelInitiate message Tunnel Name TLV <bcp14>MUST</bcp14> be included.
   And in the subsequent PCTunnelRpt message Tunnel Name TLV is
   optionally included.</t>
      </section>
    </section>
    <section anchor="pcep-objects">
      <name>PCEP Objects</name>
      <section anchor="tunnel-cap">
        <name>OPEN Object</name>
        <section anchor="pce-initiated-tunnel-capability-tlv">
          <name>PCE Initiated Tunnel Capability TLV</name>
          <t>The PCE-INITIATE-TUNNEL-CAPABILITY TLV is an optional TLV associated
   with the OPEN Object <xref target="RFC5440"/> to exchange PCE-initiated tunnel
   capability of PCEP speakers.</t>
          <t>Its format is shown in the following figure:</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=[TBD]      |            Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Tunnel Types                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>The type of the TLV is to be assigned by IANA and it has a fixed
   length of 4 octets.</t>
          <t>The value comprises a single field - Tunnel Types (32 bits):</t>
          <t>Each bit indicates one kind of tunnel.  Each bit from right to left
   successively represents the value of tunnel type which is 0 to 31.
   The value of tunnel types refer to the registry for "BGP Tunnel
   Encapsulation Attribute Tunnel Types" <xref target="RFC9012"/> assigned by IANA.
   This document only use the IP tunnel type.</t>
          <t>The assignments used by this document are as follows:</t>
          <table anchor="tunnel-type">
            <name>Tunnel Type</name>
            <thead>
              <tr>
                <th align="right">Tunnel Type</th>
                <th align="left">Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="right">Reserved</td>
                <td align="left">0</td>
              </tr>
              <tr>
                <td align="right">GRE</td>
                <td align="left">2</td>
              </tr>
              <tr>
                <td align="right">VXLAN</td>
                <td align="left">8</td>
              </tr>
              <tr>
                <td align="right">NVGRE</td>
                <td align="left">9</td>
              </tr>
              <tr>
                <td align="right">MPLS in GRE</td>
                <td align="left">11</td>
              </tr>
              <tr>
                <td align="right">MPLS in UDP</td>
                <td align="left">13</td>
              </tr>
            </tbody>
          </table>
          <t>Unassigned bits are considered reserved.  They <bcp14>MUST</bcp14> be set to 0 on
   transmission and <bcp14>MUST</bcp14> be ignored on receipt.</t>
        </section>
      </section>
      <section anchor="srp">
        <name>SRP Object</name>
        <t>&lt;SRP&gt; object is defined in <xref target="RFC8231"/>.  In this
   document &lt;SRP&gt; is used to correlate PCTunnelInitiate and PCTunnelRpt
   or PCErr message.</t>
        <t>'R' Flag in &lt;SRP&gt; object is defined in
   <xref target="RFC8281"/>.  When PCE requests PCC to create
   the IP tunnel 'R' Flag in &lt;SRP&gt; is set to 0.  When PCE requests PCC
   to delete the IP tunnel 'R' Flag in &lt;SRP&gt; is set to 1.</t>
        <t>Other flags must be set to 0 and if PCC receive the PCTunnelInitiate
   message with other reserved flags in &lt;SRP&gt; set to 1 PCC will send
   the PCErr message.</t>
        <t>In procedure of PCE-initiated IP tunnel &lt;SRP&gt; object carries no
   optional TLVs.</t>
      </section>
      <section anchor="tunnel-obj">
        <name>TUNNEL Object</name>
        <t>The TUNNEL object <bcp14>MUST</bcp14> be present within PCTunnelInitiate,
   PCTunnelRpt and PCTunnelUpd messages.  The TUNNEL object contains a
   set of fields used to specify the target tunnel, the flags to
   indicate the state of the tunnel or operation to be performed on the
   tunnel and TLVs.</t>
        <t>TUNNEL Object-Class is to be assigned by IANA.</t>
        <t>TUNNEL Object-Type is 1.</t>
        <t>The format of the TUNNEL object body is shown in following Figure:</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                PTUNNEL-ID                     |  Flag   |    O|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        TLVs                                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        <t>PTUNNEL-ID (24 bits): A PCEP-specific identifier for the tunnel.  A
   PCC creates a unique PTUNNEL-ID for each tunnel that is constant for
   the lifetime of a PCEP session.  The PCC will advertise the same
   PTUNNEL-ID on all PCEP sessions.  The mapping of the Tunnel Name to
   PTUNNEL-ID is communicated to the PCE by sending a PCTunnelRpt
   message containing the TUNNEL-NAME TLV.  All subsequent PCEP messages
   then address the tunnel by the PTUNNEL-ID.  The values of 0 and
   0xFFFFFF are reserved.</t>
        <t>Flags (8 bits):</t>
        <t>O(Operational - 3 bits): On PCTunnelRpt messages, the O Field
   represents the operational status of the tunnel.</t>
        <t>The following values are defined:</t>
        <t>0 - DOWN: The tunnel can't carry the traffic.</t>
        <t>1 - UP: The tunnel can carry the traffic.</t>
        <t>2-7 - Reserved: these values are reserved for future use.</t>
        <t>Unassigned bits are considered reserved.  They <bcp14>MUST</bcp14> be set to 0 on
   transmission and <bcp14>MUST</bcp14> be ignored on receipt.</t>
        <t>TLVs that may be included in the TUNNEL Object are described in the
   following sections.</t>
        <section anchor="tunnel-identifier-tlv">
          <name>Tunnel Identifier TLV</name>
          <t>The Tunnel Identifier TLV <bcp14>MUST</bcp14> be included in the TUNNEL object in
   PCTunnelInitiate, PCTunnelRpt and PCTunnelUpd messages for PCE-
   initiated IP Tunnels.  If the TLV is missing, the PCE will generate
   an error with error-type 6 (mandatory object missing) and error-value
   which means Tunnel Identifier TLV missing and close the session.
   There are two Tunnel Identifier TLVs, one for IPv4 and one for IPv6.</t>
          <t>The format of the IPV4-TUNNEL-Identifier TLV is shown in the
   following figure:</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=[TBD]          |           Length=12           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Tunnel Source Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   IPv4 Tunnel Destination Address             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tunnel Type         |           Tunnel ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>The type of the TLV is to be assigned by IANA and it has a fixed
   length of 12 octets.  The value contains the following fields:</t>
          <t>IPv4 Tunnel Source Address: contains the source IPv4 address of the
   ingress node of the tunnel.</t>
          <t>IPv4 Tunnel Destination Address: contains the destination IPv4
   address of the egress node of the tunnel.</t>
          <t>Tunnel Type: contains the type of tunnel (see <xref target="tunnel-type"/>).</t>
          <t>Tunnel ID: Tunnel ID remains constant over the life time of a tunnel.
   A PCC creates a unique Tunnel ID for each tunnel.  Each tunnel type
   has individual identifier space.  The Tunnel ID is allocated on id
   space of the tunnel type and is unique in the same id space.</t>
          <t>The PCC will advertise the same Tunnel ID on all PCEP sessions.  The
   mapping of the Tunnel Name to Tunnel ID is communicated to the PCE by
   sending a PCTunnelRpt message containing the TUNNEL-NAME TLV.  The
   values of 0 and 0xFFFF are reserved.</t>
          <t>The format of the IPV6-TUNNEL-Identifier TLV is shown in following
   figure:</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=[TBD]          |           Length=36           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                  IPv6 tunnel source address                   |
   +                          (16 octets)                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                  IPv6 tunnel destination address              |
   +                          (16 octets)                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Tunnel Type       |           Tunnel ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>The type of the TLV is to be assigned by IANA and it has a fixed
   length of 36 octets.  The value contains the following fields:</t>
          <t>IPv6 Tunnel Source Address: contains the source IPv6 address of the
   ingress node of the tunnel.</t>
          <t>IPv6 Tunnel Destination Address: contains the destination IPv6
   address of the egress node of the tunnel.</t>
          <t>Tunnel Type: contains the type of tunnel (see <xref target="tunnel-type"/>).</t>
          <t>Tunnel ID: Tunnel ID remains constant over the life time of a tunnel.
   A PCC creates a unique Tunnel ID for each TUNNEL.  Each tunnel type
   has individual identifier space.  The tunnel ID is allocated on id
   space of the tunnel type and is unique in the same id space.</t>
          <t>The PCC will advertise the same Tunnel ID on all PCEP sessions.  The
   mapping of the Tunnel Name to Tunnel ID is communicated to the PCE by
   sending a PCTunnelRpt message containing the TUNNEL-NAME TLV.  The
   values of 0 and 0xFFFF are reserved.</t>
        </section>
        <section anchor="tunnel-name-tlv">
          <name>Tunnel Name TLV</name>
          <t>The Tunnel Name TLV <bcp14>MUST</bcp14> be included in the TUNNEL object in
   PCTunnelInitiate messages for PCE-initiated IP Tunnels.  If the TLV
   is missing, the PCE will generate an error with error-type 6
   (mandatory object missing) and error-value which means Tunnel Name
   TLV missing and close the session.</t>
          <t>Each tunnel <bcp14>MUST</bcp14> have a tunnel name that is unique in the PCC.  This
   tunnel name <bcp14>MUST</bcp14> remain constant throughout a tunnel's lifetime.</t>
          <t>The TUNNEL-NAME TLV <bcp14>MUST</bcp14> be included in the PCTunnelRpt message when
   a tunnel is first reported to a PCE in response to the
   PCTunnelInitiate message to create the tunnel.  The tunnel name <bcp14>MAY</bcp14>
   be included in subsequent PCTunnelRpt messages for the tunnel.</t>
          <t>The format of the TUNNEL-NAME TLV is shown in the following figure:</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=[TBD]          |       Length (variable)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                      Tunnel Name                            //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>The type of the TLV is to be assigned by IANA and it has a variable
   length, which <bcp14>MUST</bcp14> be greater than 0.</t>
        </section>
        <section anchor="tunnel-parameter-tlv">
          <name>Tunnel Parameter TLV</name>
          <t>The Tunnel Parameter TLV and/or Tunnel Attribute TLV(see details in
   following section) <bcp14>MUST</bcp14> be included in the TUNNEL object in
   PCTunnelUpd messages for PCE-initiated IP Tunnels.  If both of the
   TLVs are missing, the PCE will generate an error with error-type 6
   (mandatory object missing) and error-value which means Tunnel
   Parameter TLV and Tunnel Attribute TLV missing and close the session.</t>
          <t>The Tunnel Parameter TLV <bcp14>MAY</bcp14> be included in the TUNNEL object in
   PCTunnelInitiate and PCTunnelRpt messages for PCE-initiated IP
   Tunnels.</t>
          <t>Tunnel Parameter TLV specifies information needed to construct the
   encapsulation header when sending packets through that tunnel.</t>
          <t>The tunnel with different type has different encapsulation mode and
   each tunnel with same type <bcp14>MAY</bcp14> has different encapsulation
   parameters.  When PCE initiate setup of the tunnel PCE can specify
   the encapsulation parameter of the tunnel and PCC will setup the
   tunnel and encapsulate the packet according to the parameters.</t>
          <t>After the tunnel has been triggered to instantiate PCE can send
   PCTunnelUpd message to modify the encapsulation parameter.</t>
          <t>The format of the TUNNEL-PARAMETER TLV is shown in following figure:</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=[TBD]          |           Length=variable     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Tunnel Type       |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   //                   Tunnel Encapsulation Parameter            //
   +                          (variable)                           +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>The type of the TLV is to be assigned by IANA and it has a variable
   length, which <bcp14>MUST</bcp14> be greater than 0.  The minimum value of length is
   4 without any parameter.  The value contains the following fields:</t>
          <t>Tunnel Type: contains the type of tunnel (see <xref target="tunnel-type"/>).</t>
          <section anchor="gre">
            <name>GRE</name>
            <t>When the tunnel type of the TLV is GRE, the following is the
   structure of the value field of Tunnel Encapsulation Parameter:</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      GRE Key (4 octets)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <ul spacing="normal">
              <li>
                <t>GRE Key: 4-octet field <xref target="RFC2890"/>.  The actual method by which the
   key is obtained by PCE is beyond the scope of this document.  The key
   is inserted into the GRE encapsulation header of the payload packets
   sent by ingress router to the egress router.  It is intended to be
   used for identifying extra context information about the received
   payload.</t>
              </li>
            </ul>
            <t>Note that the key is optional.  Unless a key value is being used, the
   GRE encapsulation <bcp14>MUST NOT</bcp14> be present.  If GRE tunnel didn't use the
   GRE key the PCTunnelInitiate message needn't carry the TUNNEL-
   PARAMETER TLV.  If GRE tunnel firstly use the GRE key the
   PCTunnelInitiate message need carry the TUNNEL-PARAMETER TLV.  Then
   if the GRE tunnel quit using the GRE key the PCTunnelUpd message can
   carry the TUNNEL-PARAMETER TLV without GRE key to delete the
   parameter previously set.</t>
            <t>MPLS in GRE has the same encapsulation with GRE.</t>
          </section>
          <section anchor="vxlan">
            <name>VXLAN</name>
            <t>When the tunnel type of the TLV is VXLAN, the following is the
   structure of the value field of Tunnel Encapsulation Parameter:</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V|M|R|R|R|R|R|R|          VN-ID (3 Octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAC Address (4 Octets)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MAC Address (2 Octets)     |   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <t>The definition of the fields refer to <xref target="RFC9012"/>.</t>
          </section>
          <section anchor="nvgre">
            <name>NVGRE</name>
            <t>When the tunnel type of the TLV is NVGRE, the following is the
   structure of the value field of Tunnel Encapsulation Parameter:</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V|M|R|R|R|R|R|R|          VN-ID (3 Octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 MAC Address (4 Octets)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MAC Address (2 Octets)     |   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <t>The definition of the fields refer to <xref target="RFC9012"/>.</t>
          </section>
          <section anchor="mpls-in-udp">
            <name>MPLS-in-UDP</name>
            <t>When the tunnel type of the TLV is MPLS-in-UDP, the following is the
   structure of the value field of Tunnel Encapsulation Parameter:</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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Source Port (2 Octets)      |  Destination Port (2 Octets) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <t>Source Port: UDP source port.</t>
            <t>Destination Port: UDP destination port.</t>
          </section>
        </section>
        <section anchor="tunnel-attribute-tlv">
          <name>Tunnel Attribute TLV</name>
          <t>The Tunnel Attribute TLV <bcp14>MAY</bcp14> be included in the TUNNEL object in
   PCTunnelInitiate, PCTunnelUpd, PCTunnelRpt messages for PCE-initiated
   IP Tunnels.</t>
          <t>Tunnel Attribute TLV specifies some of the information of the tunnel
   such as metric or TE metric which are carried in sub-TLVs.</t>
          <t>The format of the TUNNEL-ATTRIBUTE TLV is shown in following figure:</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=[TBD]          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                       sub-TLVs                              //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <t>The type of the TLV is to be assigned by IANA and it has a variable
   length.  The minimum value of length is 0 without any parameter.  The
   value contains the following fields:</t>
          <t>sub-TLVs: Each sub-TLV has the Type (two octets), Length (two octets),
   Value.  The length is the length of the value of the sub-TLV.
   Unknown sub-TLVs are to be ignored and skipped upon receipt.</t>
          <t>This document defines the following sub-TLVs.</t>
          <section anchor="metric-sub-tlv">
            <name>Metric Sub-TLV</name>
            <t>The following is the structure of the sub-TLV of metric:</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=[TBD]          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Metric Value                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <t>The type of the sub-TLV is to be assigned by IANA and it has a fixed
   length of 4 octets.</t>
            <t>The value comprises a single field - Metric Value (32 bits): value of
   metric.</t>
          </section>
          <section anchor="te-metric-sub-tlv">
            <name>TE Metric Sub-TLV</name>
            <t>The following is the structure of the sub-TLV of traffic engineering
   metric:</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=[TBD]          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     TE Metric Value                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
            <t>The type of the sub-TLV is to be assigned by IANA and it has a fixed
   length of 4 octets.</t>
            <t>The value comprises a single field - TE Metric Value (32 bits): value
   of traffic engineering metric.</t>
          </section>
        </section>
      </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>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="I-D.li-spring-tunnel-segment" target="https://datatracker.ietf.org/doc/html/draft-li-spring-tunnel-segment-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.li-spring-tunnel-segment.xml">
          <front>
            <title>Tunnel Segment in Segment Routing</title>
            <author fullname="Zhenbin Li" initials="Z." surname="Li">
              <organization>Huawei</organization>
            </author>
            <author fullname="Cheng Li" initials="C." surname="Li">
              <organization>Huawei</organization>
            </author>
            <author fullname="Nan Wu" initials="N." surname="Wu">
              <organization>Huawei</organization>
            </author>
            <date day="14" month="April" year="2021"/>
            <abstract>
              <t>This document introduces a new type of segment, Tunnel Segment, for the segment routing (SR). Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. Forwarding mechanisms and requirements of control plane and data models for tunnel segments are also defined.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-li-spring-tunnel-segment-02"/>
        </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="RFC2890" target="https://www.rfc-editor.org/info/rfc2890" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2890.xml">
          <front>
            <title>Key and Sequence Number Extensions to GRE</title>
            <author fullname="G. Dommety" initials="G." surname="Dommety"/>
            <date month="September" year="2000"/>
            <abstract>
              <t>This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2890"/>
          <seriesInfo name="DOI" value="10.17487/RFC2890"/>
        </reference>
        <reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5440" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title>
            <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
            <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/>
            <date month="March" year="2009"/>
            <abstract>
              <t>This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5440"/>
          <seriesInfo name="DOI" value="10.17487/RFC5440"/>
        </reference>
        <reference anchor="RFC5511" target="https://www.rfc-editor.org/info/rfc5511" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml">
          <front>
            <title>Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications</title>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <date month="April" year="2009"/>
            <abstract>
              <t>Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.</t>
              <t>There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.</t>
              <t>Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.</t>
              <t>This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5511"/>
          <seriesInfo name="DOI" value="10.17487/RFC5511"/>
        </reference>
        <reference anchor="RFC9012" target="https://www.rfc-editor.org/info/rfc9012" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9012.xml">
          <front>
            <title>The BGP Tunnel Encapsulation Attribute</title>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="G. Van de Velde" initials="G." surname="Van de Velde"/>
            <author fullname="S. Sangli" initials="S." surname="Sangli"/>
            <author fullname="J. Scudder" initials="J." surname="Scudder"/>
            <date month="April" year="2021"/>
            <abstract>
              <t>This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.</t>
              <t>This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9012"/>
          <seriesInfo name="DOI" value="10.17487/RFC9012"/>
        </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>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC8281" target="https://www.rfc-editor.org/info/rfc8281" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <date month="December" year="2017"/>
            <abstract>
              <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
              <t>The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8281"/>
          <seriesInfo name="DOI" value="10.17487/RFC8281"/>
        </reference>
        <reference anchor="RFC8664" target="https://www.rfc-editor.org/info/rfc8664" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing</title>
            <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Hardwick" initials="J." surname="Hardwick"/>
            <date month="December" year="2019"/>
            <abstract>
              <t>Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.</t>
              <t>This document updates RFC 8408.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8664"/>
          <seriesInfo name="DOI" value="10.17487/RFC8664"/>
        </reference>
        <reference anchor="RFC8231" target="https://www.rfc-editor.org/info/rfc8231" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml">
          <front>
            <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title>
            <author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="I. Minei" initials="I." surname="Minei"/>
            <author fullname="J. Medved" initials="J." surname="Medved"/>
            <author fullname="R. Varga" initials="R." surname="Varga"/>
            <date month="September" year="2017"/>
            <abstract>
              <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t>
              <t>Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8231"/>
          <seriesInfo name="DOI" value="10.17487/RFC8231"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1d63YbN5L+z6fAyudMpBmRkWyNY3Mcz8qSPNFZXbi6OJPJ
yY8mCUo9Jrs5jW4pmth5ln2WfbKtG9BAXyjKlpNsLGYmUXejC4VCoepDoYDu
drudPM6nuq8GO3vdOInzOMr1WO0P1FmRJHraiYbDTF/Rc+/uOB0l0QxeG2fR
JO+OLnXSnY80/d9R6cbzbk7luxtbnTHc6ndG8O+LNLvpK5OPO6YYzmJj4jQ5
u5kDtf29s9edTjzP+irPCpM/3th4vvG4E2U66quTtMjj5KJznWZvL7K0mPfV
yiDKL9VOOpsXeZQDGbU31TOd5Cudt/oGCo6BZpLrLNF5dxdZ7XRG6Rio9FVh
upEZxXFnHvfV93k6WlcmzfJMTwz8dTPDP37odKIiv0yzfkd1O0rFiemrv/fU
DrQXLlkEf48jeyPNLqIk/jex0lffFNG1jtWZHl0m6TS9iLWBMnoWxdO++qeG
yqMeSu7HOPrPSyrbG6UzKDJKiyRHGe1cxknkVf1NT51exq7mb6LkQm4sU3OW
YkfrcZynWcmIuYwvgc7zJVn4R08dlBz8A9gfxgnfukPrp/G/+c2FtXaSNJsB
uStQHAW//e5ubxp3zTyDHrSqZfQF9jiXOHm983hz83l58ez5hrv489aWd/Hn
zU138Xxj83HlohMnk7B2ePTs8bPypWdPn255T57AE/h1u10VDU2eRSNQtrPL
2CgYLAWyqMxcj+IJCEJFyuhcpROlf8x1ggPAqDzFQTbA/5piPgddbBuUVAQ4
M5MblV9qlel/FXFGiq+uL+PRpYJaY5BkOi5G8CJ00E8/LRLe+/c9pc6AksdO
nIymxVhTBcBsMV9X0HcwmJIoGWkVJWOV6ygbp9cJNqSFVRhL1zGMoCInQomG
hyBXNU1H0RT6O5nEF0XGYxf+h2UGOzs9luMsHo+nutN5hIOYGoPlOp3bGlO2
HSWd6GuVg3lBLqXIuhXkqb1GnrildAPGChkbFAuXtA9GUaKGGqwHNAS6IdNY
jTrd3wWDFo3eqrGeg0mCqk5P1BysE9iSecQNS9KkC3fHKcoRRouaZ+lVDCIe
x5OJzoA6C8/o7CoG3nvUJXlj/dEUJZiLNA8HB6fq5PTNoHu2Jy+sAwPlFdYG
fcIXvfJPVJRoalJsz6SYoqac7na/3T5SZgQdncVp727izq9TdR3dkDajihdz
arrU5pSTxBeZSuP6oAIaH8PLVjXcu6IdY42yWae/U/hXhuVD5ZNWIuMyMt+/
X1dy8QwuSHn5GsYwXF8CK2M9iRN4+zK9rjCPrq+kbsV8cDogOixmuKIh9CmG
e+83NjQfgVHPZjFZ9ZsOWsAuSKFvB5Nz1PIAxFN7ps7AGU/ikdpLLkDqGvWK
KIUSBDUxrD9QYdlFZM/EoL9/j9hkZx1bSf8aIJkBkOwJQQ2tgtFyjdUyHcAT
NVqsGX1pTigy6Nw+9Xd+GeVsW2Gw2+EaYf9m2hRT6uKIzLE2OVKaZOnM6tDS
/OS+DCxHrtv6zgkgMyQheKaTUTQHFqi7ek2N8Ah4juSWBiEhv00tDZppY6IL
bBh6TFNrBLXQDocxMI1t99TkFVhOwGNHUZGp10RDrZ68Onq9hu0ivIZMlQSc
AoATB98FKvlInZRO0KgDQDQFcIQeWCvAggrBoFErh+enZyvr/F91dEx/n+z9
9/n+yd4u/n36zfbBgfujIyVOvzk+P9gt/yrf3Dk+PNw72uWX4a4KbnVWDre/
gyc4IleOB2f7x0fbByvN4gE7AHYdR3E2zzT3Q2cMKDGLh9zkVzuD//2fzS1o
+n8IzgHTxRfPNr9CO3YNoIprS5PpjVxCb910ovkcLAJSAc8BTmQe5xFaABTr
JdoJsKQaBPnH71EyP/TVi+Fovrn1Um5gg4ObVmbBTZJZ/U7tZRZiw62Gapw0
g/sVSYf8bn8XXFu5ezdf/HUKg011N5/99WUHDdogSwEogbcxZALbJkOoZ8dX
6J4BU6Blda91OttohhS/DHIex+ieYSiANkbDeBrnNxVTD6DG1jC+ATgdj3Ao
iLcDomQfeKQNpOxU0LUagMfS6gpmHishJWEUCO1Ec6l3RZ0dvFGrRqOVyQF/
Gx5A4sdBGd6/X+PBvF/RTPazc9tMNBWkWdEQ3UZjI0BcZBbEdZF9GMPANeRH
JqSUKAnP5KDUxnoKSg+WJpA98eSsFdZekJElzzdKGdQFHPdKN2I04cUAngSt
qfQHwTFkk/q8bAQOEjbZhq3x6zgzOUhhCADE+kX2uoIWEpjjcsvsncU9xPBT
TDJAVVPpf2gKzZItDME/56gCZOmPk1JPbEH07I0V+7XCc3wf5l6zIhF9lRd3
Sgwk4AIxq0UWiqBFe0+Z0jWU0madsYgvR+mYm2R0maV20rhOFTP+mKfTeHSD
VKjSeKbxbaJmzLpAH27rBFQaK3APdT7qQUPA0A01UggcB745KXJ8AUayIXeJ
49oXzPYYHsH8irwJNWWX+yOQMfjDaDiNzSWPlFZtmBUMBqIkgfntiJQizpzq
MUIb+ACvDQxQd29z8VMw6G8B/q5iFWR2dtYsMmRFX9Y0rKvAzYSGYd3K7Hiw
d6SOh/+EQQW6Qe2xUiIjZ5sj9jNoj9zzmCltasBPqTe36S6atKC1/vAhQ4rQ
hnAHMwZUhjeB6MA47UUwH/HeZCzEthvLE/4BTzGMc1+ltdHYj2KIlmMVi31h
SIxIyEKm0lMQw5YeTvOsRPFeaS3FjOLgQzpxpWLjVI8NifCYy0OegUkN/vvN
zTMFlG5qyo40xWqEa4YTvR0JQUtCs+91WzQaAUAjk5fifQLxJDChjM1eqmVS
I06LSEmLPMUoDtgU9FuVaqQOQbfiA0m4NCek5o/C5iMTWAs+T9LGImJXLXAC
ZnxrwB3Pg6K0jtylykcdgRvdBhLxhGrO9EjHV1rYc/TiHKFcMR1zfUAty3xN
4wmnayOZK6yybNCVbmwOAkh2+4Ffo55u6okaZU8FetStLBok6asgG3W21aMw
ZLCQJPlADAVcoy3Cp0Tel3qWWTH0OmztZZgezzVPcQ3efqTCODcMa2/Y8QgJ
VThy4ZbSVSdjnEDVQtOlvbPGAm0337V31vzesjNuaxDDon7XUnv9qMDpyUCl
PDLruM9kCPhQlNSg86OjvYP20uIM4Dm+xLGI8B2sHSmRAkHD+Wl3fxcVY4O6
rMagle8Yo17gmjPUNCRC+CN3dSCVDTfw5a2jaKaxvEimws32d44Z751BlMFb
OVfkuxnQpUyLAfZCcS5kKHrIc1Ysgmo1TwERsQ8cg7k0oI9ZJgCjsWnUBFYN
6lZQDvJ8Nf1Qp4SMTjQZTKsgJ/N8rTqQqQFsJ22ZpRQCOQlE1mMiAFoA11wk
qLwAB8Ei+l1pG4hzjlDgSC9CEvJSyztNUqloGxKpKhwKNKjORmptLJM4970o
ySS14zqyWFNgTKXlpR7cRYbrpZrCTWgqueKj88NXeycc25TaPLE7sBAOY88u
/fzzz7ScEP7+1IV/6rflQcML70A53jW9AA923t1HDUCq6SY96Gyu4aDgqDv3
OdztdusN73ZfqiZ2hHqpe19vrDvq7cx4xdUSxfF3UhZdpjj8encrvgT1F91u
KRxUP9Wl3zv1eM03CYWxNsFoNj3NVXti27yb2DaXb9j5/PaGNd3k4qjnTc72
fI5rxNbLFnTFM3Zru41bd2Gb3e5+yaQ1e2Cpp3S+cN3udz0DiwU/wsI2O06B
XRb1eBbX+U0s4U1jR822tNkZ4vtohgH6JgDiJgzPm70i880PtvMcJoRFruvu
kjvGiC/0ws5+PwGpL8FQR5aMBYleiMtCOc8r1o0w+zpeaSPt59oJuZBd/xVN
uKcOvyfrbQeeNd5ovcFEBc3GO2K9XacH1H8RM/Rgjvn3aczxLkZkvWmPi9De
ccaj/BnLx8x4bEk3t17W/Lr5wxcnX6jJNLqgde4TmmBLCVl/GNKCarspbTbW
NKerGOzbrHVgUkW0XjykDFli0Cp0CoHRbJkAtNnNX91oNuDe34/ptP3om86P
Ab6fymSclEWXKa4eLK38do+/PbqtYU03uThbWsVB6EOJ25VRpbgaUopC89oy
gnCQRzKF71lqMuopokbTX1rF9wnv1AiH9oOiG94yf6pm6TiWjDMP6dUI1zkG
xFAJREYes7X8gXUxHRzKBmMpGRKxGRXGUIIU1p9rXILT0/QaydiwAE0M/GDx
WNwYwGCjjaz11GQpvdGRBZZbPJlj2CU0URJVpic6y2iCQtIz7X0Ws3xAD+wd
1G409pE13CQjwsvgGLP44kK7NcLKakDmGlmKVBrUxcRaBY5kOvaWKwa05pfi
qn80BrIiPH+u08QxpyhwlIg90/720XZ9nlR7t9GluKCe72ZNT8LTFS8CtVOm
cHJhcYcf5Y0kxkveCbogzbo2Oq2eqtVDqCrKU5gEyWqFkKIYqJS/iqaF/npz
Q61irVyOlNYWXZ2DoLyMsrWe4zMECrHx3luS2xqnFNNezKwo30xHibEshK+I
NjTpDC0q4sLWDfFEGTZ1NT8sARcxG1WDcQ4O4JpRdgVK4WGVDZc9iQTcOLxT
1ZV6PcRGs1q3Rh7EnP3lQFLZTM9SZI5ClVXo59pwwtgQAaCXqkXZSGTkWtXb
W72vSlnsQJk+IFjnRZsFeqn6/a/Vix0en9/Q+HzZ6GjC34tgNd7maE5jk7/s
fIvJPf3O4lJcb+NzWR5bhg31/WISP7RzYYsQI6vNZQLxLsUP/t41E7Ma+XKt
namwQpYRqM/SVXPfsHa+bK/GsXL3GhxxQheK1daznPVER7ReQR4zR97DlDRK
wQVnNvViAQ6iSFexg+aZBVJwt60vszNEN8TIfAk4kZVqLx+EafCzkAROCfeu
NFjwpkREBzgw6IwTE56QdXliYvNyk2I25HRhWahAgx4kdCA/lAAw4jxCDjNp
yhGIZ5hYW64rqNUyF2ddZECZJ2tIQrjEjNqMdja4nEnuHzbg6cSfSsk0ivwE
9IweXaboZDGpnOVgl2k4lwAcCE8Ga+CNHDUmiF+TZbLdiFN5oDDU+bXWSdlZ
MzAxfmc5N2MQWTB6lF7B9y90giJg/1/2zqCykt24b8FcUqYjN8XgKp50iplH
oxZ5kO4E6+TE0qSYsjy8NNQ/TPO/8Gj4w0X+Fw86QMehatgbwc6IeoJNC5lk
SXzjrfPWlwAbVjCbIrHsONI5r2ABzhXi47KxbZC01RlhwkKJVpocYOlEW5cx
N3p+7dTIBQw4nx/WXXXhLihddeJSPHDiFQSP0cjlwLuE/U/EgFh2V6vQHfNu
VWPQf21p2C4zAG8N426R8qhc3txuW4FAC86h/VlKowrNU6Kbm/txEwN4VJnD
tc8GqqGl21dNHiYCv9BEoAXP+h3kDd4ysC9qjMpveK5dQbOCa2oj8gPB7AtB
RVyvBYYCZuF5iWdvKczVNxZYGl99v6iCHxYycTc0VwNyt/qh1pFVs93U/eKC
eCHwjiuA/kzOOi9UiCTNfd/kW2ZEJMtZ5iDlZXFoReIhXmjFj1otNs871jzv
iXn2gmSjIqOsn1qwrMcJt/W6JH9ygQX2m2WEjou6+flgQftjhGZmniZGImVV
R28dGGE7G+2iHb1l4YqvI7AchWDpA/2AE8Ry3iB0BdVlBqSxpDdo9gUNBnbv
/g1sxRuErgDfX84bBJwKeL0js1UOqNPv1xv4fbQgsLHYFdQswId5AmtWaVR2
ebje4gbqRQMn4D9e0gV83066av4D6ncw/nc3/a0Ldm2mP4gFLmf0ab9NfQrC
g7aJk55sIEJ7kpm82USX5s3GthesDlbnS252XPocJbnRXLEphgaNXtJce5Xc
onmWXajhwWPYufk57z89km7HjRL+EvrivQD+Fofu/tH+2f722V5X5j4724Pt
V/sH+2ff2R6goINkMlJvGZOO3JYbN3cLGCs3x6KA9Y8jPOFBV6blufM/Xr63
3YxieIuEbOTZz421FbHdMGi30ri9rLxd27MEGw2avtlw73HDvSdCYROePlFb
6s9gBr9Sz9Tzu9xDGrSU+zH/IJHqmh76zK+/P3u1+wNfB88PdHKRX3695d16
98k4qfDF+nZGWfmNv3vixI81ukTpS2c1msEAx9dyCgZEoC4/sgpPSV5IYUul
o1zn3u4x9miAReZZbHgjPaja1AKWbtji1SePcaeOWeNterS5B6697GBEZ2/j
ZFwmdve8cgSTsvjiksKfUz0hkGOKEW4ri69wvRFsO22PyTmeUcbxZLkBZeGQ
6waSebLZC1sTljYMba0hzPQFOJaMdwSuvPqbv01qLwgheKbak8EKD348wwTP
OahNzlV1iz3t6ygM46/yXAhkrewGpsNbqyliTKG/6g7mYJ2j885jq1Q/99cb
lMW7zrtu/df/U3gNpU7s8pKvyoFibzTT6r6r0frbyV59WARXj5em9ebvB9tH
C2k9W5rW0Zs6ZyGt50vTogNBwEL7FANam5t3pnW+O2ih9WRZWj/1lfWZNFLo
7KmvVzxNWXlPSneelKpLO6gztAKJiQE2wj272sjTixuHCnDDKgykDcWh7jwD
DCwHTJXZWYgeLpIU6aQJb6aa5zJ39UD+T49wnwwoMoExeFCJKTevq/TcHmpa
87TDwycRe1nMboWlBoAqsX2CKVltKxPcxZy215LTdhun3lzlGTP7Le7GRtDi
lgNknswJ1jYyWxqGtupovzVLv42s4D0v2e0uZDe5ubTRixZqDW2sDbo9qm2S
a0SX/tSVABQfJOPWsJl6hRPLBlGnzcU4a/OWdqodA3pQ3d4XLopI0xs6jTfO
YHTFh6eUCiOKGk7sHBLFTTPlCkE9f3Fot3dy1L9hTWPdDzcjdPYV0Qs4mcYk
SRijuFFcEvDl0Bvy1aXSc2ojrx3lUXah8yCjlIXPARrruMM8Jm95H4ZEuSLH
qAMuEary6K5nnIsMVUWE3Z0pWJxbw9rBK2eyYXizaUJdDwAM0/FNAJ9L6Pz6
84HOfqpG0w/Kkx2QN4/vDzp/+WVjhUpxitltvy+/vB1/3/67Z/ztCXP18ZaA
XzkhoOsykONyDa+2e27brirbXZBNm//wLe1vlZdjg9AlY1QIC1hLOI0nmlbL
JapUrq+7YKDYz/L8ABreMCevNCnl02p8GtbszKL5HEeOHWnevJ5Nh0eGGHVH
XIy9rd9BDlJbcFNsmk01ErpH24d7EhnfRl/gxx3K+LNshwdnaDeKesbLrp87
Tv3kAOM2zyKJjR9f04+AkEM/fBgJ2cvVZ/7M53j12Nv/2IXhLZpx3Bi3kfM0
jsEOgaWWyLg/zanupiwqe76bjraSVnhnWzFvG8APptH2/dPtRlHyhawHM1k+
HozpbsIb54Nq+bbSj7tfQXk7YehjAaN9bko3D1otJ4EURpz2rwE8rQWiUTWL
bvz4VmXbqvh7Fqp3Zof4uVL6cvYNw4Vyu3tlv3U1lyBc66/G2hq30AqqrMGI
pTCEO2yJnX39iDovmM6RhVqwnyyJzUnhcLhkGTXE0Wcujp4ujvhTaM2PozcK
SN6ml0fT1BoysXYiXJwY4+LQddpMBQYfRiUmdELj1Zac3uVuPG0DF/uDN1s2
aljhqxKjCzXjMwnTVUN0qvJconSbfqs+bZiOetcuDaZFNtJqW5xC7ffLcbIL
s7M4kZBSAzufhpPFsaHSXPkY8TcdugQ9kthlGLiU6VA1Uo4TInaH7VrRD183
/JBthHRUuacWyNKdJB3rJt98S5dX6hp7JfBNsqtBnUovrs/r4ArtyrkadASE
O/QBH7rD6JwS9D19yPAE6cSDnumVzhzwVCXytNwou/BeA7gl0Qq+bTgYCslg
5+OM9CoeFwCEPFRN6Yu90Jfucu6CPaYXF01517Kf6uiHjSX7VJiz61mIaOOx
1BBsGmzB0B4D7fiZ8O0iCB02ox0+8zS/AUEvD5+FnQrqFcjbAHgbXeHTJVyh
G4DkEB/cIP7EDT55ev+GVt3XbPkjibRxguDKpZ+zcY3a/PGtnKxuPhUHsHZ3
Tu70+6Qy+QBOPis98R1jo7I86EkbJ/evJ3UQ+f8aQj55+uEQ8ukdIeTTD4OQ
Tz8YQj79bCAk45CPgpD5A4T8hBDSj4fZRLBqJKw13+wuMbB6mOvWEBeNw9ui
XAtCXPj+8lGuphDXkYThl4hvYTFfycuzT+zQoa8EudWCUC3tOS+8Uu6XJzo8
SMsxml9maXFBX6uw1L8wbrGhV1n0dMrR2oFNenbNX3Eq2QemOZORUzple5Di
g1qDNO38lh3w5ZFlweqLN9q56Xx4ZYXfxUmNprqos3A1spTMZ5/Jt2huxPMi
tXoVZXE0nGqL1n5jmLdtTdM3Ywt+v8k1zY9AVba3SmC1LjbOmoELGoQZ79XY
qHiDIC266hJqOdO4a68pbbrhUNPauszaBzmWxqWTdp9ChyaX+M4dpPLreRdq
zHK550v4ntbOASv6wT67dU91k7xLiGkCvBmyU34Hyn1TLk3oe0s2Cwx8XFaM
cttT4V5R2YJD382wOAmg3FtNi7PkFdnFVs2/OBbqxsq5xvTBK3crrG+GeFzW
nf1Ff6JD8JBIoJAXkMG3y12ufkqYO0WAzmivwFh39j0nCdmkgpbds5WX7eFo
kp2V8/e7PHhBGupI2cNFUZT1k+E95nn72iTXvpulxg9xJ70czsOd6R8O7hoj
iWJN+/by4Fyllnbe4tIH2yfg1M/2TtpDng8+nX8S77SO4j79l7pbfKIxpfm3
hS7uJXrUCFFENGFG+6B6kqhSFqIsiqhVIVorJ58xzpGkKTC9s2JW7kOQ4BNP
wbbc5wBxh3Bpe+4YjfrosM0jgmR/O9kjcuQ2qnGOUGJQdL3CUOzOxmTPKim4
uWuI2/C6WBN/9/bS++Fegf/SN2p165YI9T2Pgz/amvtqq0s1S+9Qpjp+wdd9
njaCnoym4DtBT2losNJLV+Nn/nDL4hBVzn3uB28N9U0q24pbvhrG9IGCRGBA
ZzVN+ONE8AAy2QjMRK/m0c00jcYWmklUizaf28gqflS23Oqj/ZuI2OVLjDmg
BcYS/PUqyptG9CnRQjr0TP+YZxENL/grwJXyma1LbVPgxwzFiDsGEkdpLlGZ
nBvt7/TsYRLcFDmL6BGPFxIiVozcuA3MdZm4b96UmeY8GcGidhElHmO2n2w6
snSwLj8wUwuhIGAOswS943cDCFSrcSIfbLP7nLz6FkZt6JuotfqqdZ1J2Cie
OOJS77+KOPe+HNLUzMqJLkhncYXOSjtq/paKAHZjD1zFaWGmN+Wpdv7WIHss
D6H6sCMJ7UMZ/l4OWmTa67SsTabCn94qf7RR/vVtMlnkN+8O3514/5Rcvjmi
5O4n6rjVJt+HPW72C4fbOy4pDNxCOwv3y0VQ7eOgWuSxCTnfKxc+QqPc5dh+
dY30mbezuG2b3oZLh15oL9+yY4UKP4yVh7HyWY4V9EfdOOme7w6WHTDeKw/D
ZnlVkdyAAX1YLFQVfOyv6VfL3KuqeHz0aVex5CXwx/ywRJUVLuanFEjZIHwf
BJCrEeIwuvwREeJ1H7qtLxkr5vyJxlhxyFgZKzbpzKmuj++DkCcpOn6yEYAc
6G0Wj3BL5NmeveD5EW1iKT9QZ4ph19sG2RZV3D47O9l/dX5WXy18iCqqpqhi
2JpfYOOi7ciWx/L7/S/y3RreAsVYENtCQkuHt6zM+5z6IJflAafYplXc7CMx
lHW3lOzfREp0AoawXnKal1eB37IfPef6KCfpPHmb4Ih0ahDxN829fWb01cm3
8Xyu8Zzm2q6z4AgP3qVXbbtnLBjaHrJlOeX7DRv/pBE1/2tFBZdsnR7Mxic1
Gy0jXvqPtK+5xP1y0jbirTr8oscFBY0vjwtyYwwJsXI6fQf/dx8qL3tUFXAP
o0xnsg3hYSTQ79cYCWXH3jYWfo8jodr66mBAQs1q6w0QdapHRYbnxu3IHmn7
LW3oaipA7Dc+/D94GAnufJIAAA==

-->

</rfc>
