<?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.6.36 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-chen-pce-pce-initiated-ip-tunnel-03" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title abbrev="PCE IP Tunnel">PCE-initiated IP Tunnel</title>
    <seriesInfo name="Internet-Draft" value="draft-chen-pce-pce-initiated-ip-tunnel-03"/>
    <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="2023" month="July" day="10"/>
    <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>SR: Segment Routing</li>
        <li>SR-TE: Segment Routing Traffic Engineering</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>PCE-initiated LSP: LSP that is instantiated as a result of a request
   from the PCE.</li>
      </ul>
      <t>The following terms are defined in this document:</t>
      <ul spacing="normal">
        <li>IP Tunnel: Tunnel that uses IP encapsulation.</li>
        <li>PCE-initiated IP Tunnel: IP Tunnel that is instantiated as a result
   of a request from the PCE.</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 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>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.</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>
        <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>
        <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+z6fAyudMpBmRkWyNY3Mcz9KSPNFZXbiU5Ewm
Jz+aJCj2mOzm9EWKJnaeZZ9ln2zrBjTQF5Ky5SQbi5lJ1N3oQqFQqPpQKKDb
7XYrC7OZ7qr+/mE7jMIsDDI9Vkd9dZFHkZ61guEw0df03Lk7jkdRMIfXxkkw
ydqjqY7ai5Gm/1sq7XDRzqh8e+dJawy3uq0R/PsqTm67Ks3GrTQfzsM0DePo
4nYB1I4OL163WuEi6aosydPs8c7O853HrSDRQVcN4jwLo6vWTZy8vUrifNFV
G/0gm6r9eL7IsyADMupwpuc6yjZab/UtFBwDzSjTSaSz9gGy2mqN4jFQ6ao8
bQfpKAxbi7Crvs/i0bZK4yRL9CSFv27n+McPrVaQZ9M46bZUu6VUGKVd9feO
2of2wiWL4O9hYG7EyVUQhf8mVrrqmzy40aG60KNpFM/iq1CnUEbPg3DWVf/U
UHnQQcn9GAb/OaWynVE8hyKjOI8ylNH+NIwCp+pvOup8GtqavwmiK7mxTs1J
jB2tx2EWJwUj6TScAp3na7Lwj446Ljj4B7A/DCO+dYfWz8J/85tLa21FcTIH
ctegOAp+R+2Dzixsp4sEetCoVqqvsMe5xOD1/uPd3efFxbPnO/biz3t7zsWf
d3ftxfOd3celi1YYTfza4dGzx8+Kl549fbrnPHkCT+DXbrdVMEyzJBiBsl1M
w1TBYMmRRZUu9CicgCBUoFKdqXii9I+ZjnAApCqLcZD18b9pvliALjYNSioC
nKWTW5VNtUr0v/IwIcVXN9NwNFVQawiSjMf5CF6EDvrpp2XCe/++o9QFUHLY
CaPRLB9rqgCYzRfbCvoOBlMURCOtgmisMh0k4/gmwoY0sApj6SaEEZRnRCjS
8BDkqmbxKJhBf0eT8CpPeOzC/7BMf3+/w3Kch+PxTLdaj3AQU2OwXKu1qjFF
21HSkb5RGZgX5FKKbBtBnptr5IlbSjdgrJCxQbFwSfNgFERqqMF6QEOgGxKN
1ajzowMwaMHorRrrBZgkqOp8oBZgncCWLAJuWBRHbbg7jlGOMFrUIomvQxDx
OJxMdALUWXipTq5D4L1DXZLV1h/MUIKZSPOkf3yuBudv+u2LQ3lhGxgorrA2
6BO+6BR/oqIEszTG9kzyGWrK+UH7296pSkfQ0UkYd+4m7uwmVjfBLWkzqni+
oKZLbVY5SXxBWmpcF1RA42N42aiGfVe0Y6xRNtv0dwz/SrC8r3zSSmRcRub7
99tKLp7BBSkvX8MYhuspsDLWkzCCt6fxTYl5dH0FdSPm4/M+0WExwxUNoU8x
3Du/saH5CIx6Mg/Jqt+20AK2QQpdM5iso5YHIJ7KM3UBzngSjtRhdAVS16hX
RMmXIKhJyvoDFRZdRPZMDPr794hN9rexlfSvPpLpA8mOENTQKhgtN1gt0wE8
UaHFmtGV5vgig87tUn9n0yBj2wqD3QzXAPs30Wk+oy4OyBzrNENKkySeGx1a
m5/MlYHhyHZb1zoBZIYkBM90NAoWwAJ1V6euEQ4Bx5GsaBASctvU0KC5TtPg
ChuGHjOtNIJaaIbDGJjGtjtq8gosJ+Cx0yBP1GuioTYHr05fb2G7CK8hUwUB
qwDgxMF3gUo+UoPCCabqGBBNDhyhB9YKsKBCMJiqjZPL84uNbf6vOj2jvweH
/315NDg8wL/Pv+kdH9s/WlLi/Juzy+OD4q/izf2zk5PD0wN+Ge4q71Zr46T3
HTzBEblx1r84OjvtHW/UiwfsANh1HMXJItHcD60xoMQkHHKTX+33//d/dveg
6f8hOAdMF1882/0K7dgNgCquLY5mt3IJvXXbChYLsAhIBTwHOJFFmAVoAVCs
U7QTYEk1CPKP36NkfuiqF8PRYnfvpdzABns3jcy8mySz6p3KyyzEmls11Vhp
evdLkvb57X3nXRu5Ozdf/HUGg021d5/99WULDVo/iQEogbdJyQQ2TYZQz86u
0T0DpkDLal9rtXpohhS/DHIeh+ieYSiANgbDcBZmtyVTD6DG1DC+BTgdjnAo
iLcDomQfeKT1pexM0LXqg8fS6hpmHhs+JWEUCO0HC6l3Q10cv1GbqUYrkwH+
TnkAiR8HZXj/fosH81FZM5GBhWklWgpSrGCIXqO2DSAtsgriucg8jGHcouci
hUQpOOYGJTbWM1B4sDKe3Ikfa6mw6pwMLHm9UcyAzuO2U7iQVBNW9KCJ15RS
XxAUQx6pv4sW4ABhc52yJX4dJmkGIhgC+DA+kT2uIIUI5rfcMnNnee8w9BRz
DDA1LfU9NIVmyAaC4J8L7H6y8mdRoSOmIHr12ordWuE5vg/zrnkeia7Ki/sF
/hFggXjVoApFsKK5p9LCLRTSZoUxaC9D6aS30WiaxGbCuE0VM/ZYxLNwdItU
qNJwrvFtopam2wJ7uK0TUGeswD7U2agDDQEjN9RIwXMa+OYkz/AFGMUpuUoc
065gemN4BHMr8iTUlAPuD0/G4AuD4SxMpzx9aNSGec5AIIgimNuOSCnCxKoe
o7O+C+6agAB1d4+Ln4MxfwvQdxOrIJOzv2VQISv6umZhW3kuxjcK20ZmZ/3D
U3U2/CcMKtANao+REhk40xyxnV575J7DTGFPPX4KvVmlu2jOvNa6w4eMKMIa
whzMGFAZ3nqiA8t0GMBcxHmTcRDbbSxP2Ae8xDDMXJXWqcZ+FEO0HqtY7IuU
xIiEDFwqvAQxbOjhFM9IFO8V1pKgOAN6pBOWKk6t6rEhER4zecizL6nBfb++
eWkOpeuasi9NMRphm2FFb0aC1xLf7DvdFoxGAM7I5MV4nwA8CUwoY7PXapnU
iFMiUtI8izGCAzYFnVapGqlDkK34PxIuzQep+SO/+cgE1oLPo7i2iNhVA5qA
GdcacMfzoCisI3epchGH50N7QCKcUM2JHunwWgt7ll6YIYzLZ2OuD6gliatp
PNm0bSRzhVUWDbrWtc1B8Mg+3/Nr1NN1PVGh7KhAh7qVRYMkXRVko862euSH
C5aSJB+IYYAbtEX4lMi7Uk8SI4ZOi629DNOzhebpbYq3Hyk/xg3D2hl2PEJ8
FQ5sqKVw1dEYJ0+VsHRh74yxQNvNd82dLbe3zGzbGES/qNu11F43InA+6KuY
R2YV86UJgj0UJTXo8vT08Li5tDgDeI4vcRzCfwdrR0qkQNBwfto+OkDF2KEu
qzBo5DvGiBe45gQ1DYkQ/shsHUhlxw58ees0mGssL5IpcdP7zjLjvNMPEngr
44pcNwO6lGgxwE4YzoYLRQ95vopFUK0WMSAi9oFjMJcp6GOSCMCobRo1gVWD
uhWUgzxfRT/UOSGjgSaDaRRksMi2ygOZGsB20pRZSyGQE09kHSYCoAVwzVWE
ygtwECyi25WmgTjf8AWO9AIkIS81vFMnlZK2IZGywqFAvepMlNbEMYlz14uS
TGIzrgODNQXGlFpe6MFdZLhdqCnchKaSKz69PHl1OOC4ptTmiN2CBX8YO3bp
559/pqUE//enNvxTvS0Pal54B8rxru4FeLD/7j5qAFJ1N+lBa3cLBwVH3LnP
4W67XW14u/1S1bEj1Avd+3pn21JvZsYprtYojr9BUXSd4vDr3K34GtRftNuF
cFD9VJt+79TjLdck5KmxCalm01NftSO23buJbXf9hl0uVjes7iYXRz2vc7aX
C1wfNl42pyuesRvbndo1F7bZze6XTFq9B5Z6CucL181+1zGwWPAjLGy94xTY
ZVCPY3Gt38QSzjR2VG9L650hvo9mGKBvBCBuwvC83isy3/ygl2UwIcwzXXWX
3DGp+EIn5Oz2E5D6Egx1YMgYkOiEtwyUc7xi1Qizr+NVNtJ+rp2QC9n1X9GE
O+rwe7LeZuAZ443WG0yU12y8I9bbdrpH/RcxQw/mmH+fxhwfYETWmfbYCO0d
ZzzKnbF8zIzHlLRz63XNr50/fDH4Qk1mwRWtcQ9ogi0lZO1hSIupzaa03ljT
nK5ksFdZa8+kimideEgRssSgle8UPKPZMAFospu/utGswb2/H9Np+tE1nR8D
fD+VyRgURdcprh4srfwOzr49XdWwuptcnC2t4iD0icTtiqhSWA4pBb55bRhB
OMgDmcJ3DDUZ9RRRo+kvreC7hPcrhH37QdENZ4k/VvN4HEq2mYP0KoSrHANi
KAUiA4fZSu7AtpgODmWDsZTsiDAd5WlKyVFYf6ZxCU7P4hskY8ICNDFwg8Vj
cWMAg1OdylpPRZbSGy1ZYFnhySzDNpmJEqgSPdFJQhMUkl7a3Gchywf0wNxB
7UZjHxjDTTIivAyOMQmvrrRdIyytBiS2kYVIpUFtTKpV4EhmY2e5ok9rfjGu
+AdjICvCc+c6dRxzegJHidgzHfVOe9V5UuXdWpdig3qum007Ep4ueRGonbKE
oyuDO9wobyAxXvJO0AVx0jbRafVUbZ5AVUEWwyRIViuEFMVApfx1MMv117s7
ahNr5XKktKbo5gIE5WSTbXUsnz5QCFPnvTW5rXBKMe3lzIryzXUQpYYF/xXR
hjqdoUVFXNi6JZ4ou6aq5icF4CJmg3IwzsIBXDNKrkEpHKyyYzMnkYAdh3eq
ulSvg9hoVmvXyL2Ys7scSCqb6HmMzFGosgz9bBsGjA0RADppWpSJREauUb2d
1fuylMUOFOkDgnVeNFmgl6rb/Vq92Ofx+Q2Nz5e1jsb/vfBW401+5ixMs5et
bzGxp9taXorrrX0uy2PrsKG+X07ih2YuTBFiZLO+jCfetfjB37t6YkYjX241
M+VXyDIC9Vm7au4b1s6XzdVYVu5egyVO6EKx2jqWs5rkiNbLy2HmyHsp6QfT
b8GZzZxYgIUo0lXsoHlmgRTsbePLzAzRDjEyXwJOZKXayQdhGvzMJ4FTwsNr
DRa8LgnRAg4MOuPEhCdkbZ6YmJzcKJ8POVVYFirQoHsJHcgPJQCMOIeQw0ya
cgTCOSbVFusKarPIxdkWGVDmyRaSEC4xmzahXQ02X5L7hw14PHGnUjKNIj8B
PaNH0xidLCaUsxzMMg3nEoAD4clgBbyRo8bk8BuyTKYbcSoPFIY6u9E6Kjpr
DibG7SzrZlJEFowepVfw/SsdoQjY/xe90y+tZNfuWUinlOXITUlxFU86JV0E
owZ5kO546+TE0iSfsTycFNQ/zLK/8Gj4w1X2Fwc6QMehapgb3q6IaoJNA5lo
TXzjrPNWlwBrVjDrIrHsOOIFr2ABzhXi46KxTZC00RlhwkKBVuocYOFEG5cx
dzpu7dTIJQxYn+/XXXbhNihdduJS3HPiJQSP0cj1wLuE/QdiQAy7m2Xojjm3
qjbov7U2bJcZgLOGcbdIeVAsb/aaViDQgnNofx7TqELzFOn65n7cxAAeleZw
zbOBcmhp9arJw0TgF5oINOBZt4OcwVsE9kWNUflTnmuX0KzgmsqI/EAw+0JQ
EddrgKGAWXhe4NkVhbn62gJr46vvl1Xww1Im7obmKkBupR9qHFkV203dLy6I
FwLvuALozuSM80KFiOLM9U2uZUZEsp5l9lJelodWJB7ihFbcqNVy87xvzPOh
mGcnSDbKE8r6qQTLOpxwW61L8ieXWGC3WanQsVE3Nx/Ma3+I0CxdxFEqkbKy
ozcOjLCdiXbRbt6icMnXEVgOfLD0gX7ACmI9b+C7gvIyA9JY0xvU+4IaA3t4
/wa25A18V4Dvr+cNPE4FvN6R2TIH1On36w3cPloS2FjuCioW4MM8gTGrNCrb
PFxXuIFqUc8JuI/XdAHfN5Mum3+P+h2M/91Nf+OCXZPp92KB6xl92m9TnYLw
oK3jpCObh9CeJGlWb6IL82Zi20tWB8vzJTs7LnyOktxorjjNhykavai+9jK5
ZfMss1DDgydl5+bmvP/0SLodN0q4S+jL9wK4WxzaR6dHF0e9i8O2zH32e/3e
q6Pjo4vvTA9Q0EEyGam30jQe2S03du7mMVZsjEUB6x9HeLqDLk3LM+t/nHxv
sxkl5S0SspHnKEuNrQjNZkGzlcbuY+Wt2o4l2KnR9N2ae49r7j0RCrvw9Ina
U38GM/iVeqae3+Ue0qCl3I/5B4mU1/TQZ379/cWrgx/42nt+rKOrbPr1nnPr
3SfjpMQX69sFZeXX/u6JEzfWaBOlp9Zq1IMBjq9lFAwIQF1+ZBWekbyQwp6K
R5nOnN1j7NEAiyySMOVN9KBqMwNY2n6LN588xp066RZv06PNPXDtZAcjOnsb
RuMisbvjlCOYlIRXUwp/zvSEQE6aj3BbWXiN641g22l7TMbxjCKOJ8sNKAuL
XHeQzJPdjt8av3TK0NYYwkRfgWNJeEfgxqu/udukDr0QgmOqHRls8ODH80vw
jIPK5FyVt9fTvo48ZfxVnAmBrBXdwHR4WzVFjCn0V9697K1ztN45bBXqZ/96
g7J413rXrv66f/KvodTALC+5quwp9k49rfa7Cq2/DQ6rw8K7erw2rTd/P+6d
LqX1bG1ap2+qnPm0nq9Niw4DAQvtUvRo7e7emdblQb+B1pN1af3UVcZn0kih
c6e+3nA0ZeM9Kd1lVKgu7Z5O0ApEaQiwEe6Z1UaeXtxaVIAbVmEg7SgOdWcJ
YGA5XKrIzkL0cBXFSCeOeDPVIpO5qwPyf3qE+2RAkQmMwYNSTLl+XaVj90/T
mqcZHi6J0MlitissFQBUiu0TTEkqW5ngLua0vZactlWcOnOVZ8zst7gbG0GL
XQ6QeTInWJvIbGEYmqqj/dYs/SaygvecZLe7kN3l5tJGL1qoTWljrdftQWWT
XC26dKeuBKD4EBm7hs3US5wYNog6bS7GWZuztFPuGNCD8vY+f1FEml7Tabxx
BqMrLjylVBhRVH9iZ5EobpopVgiq+YtDs72To/41axrbbrgZobOriE7AKa1N
koQxihvFJQFfDrwhX10oPac28tpRFiRXOvMySln4HKAxjtvPY3KW92FIFCty
jDrgEqEqj+5qxrnIUJVE2N6fgcVZGdb2XrmQDcO7dRPqagBgGI9vPfhcQOfX
nw90dlM16n5QnuyAvHl2f9D5yy9rK1SKU8xW/b78cjX+Xv27Z/ztCHPz8Z6A
XzkhoG0zkMNiDa+ye65nVpXNLsi6zX/4lna3ysuRQeiSMSqEBYwlnIUTTavl
ElUq1tdtMFDsZ3F+AA1vmJOXmhTzSTUuDWN25sFigSPHjDRnXs+mwyFDjNoj
LsbO1m8vB6kpuCk2zaQaCd3T3smhRMZ76AvcuEMRf5bt8OAMzUZRx3iZ9XPL
qZsckNrNs0hi58fX9CMgZNEPH0ZC9nLzmTvzOds8c/Y/tmF4i2ac1cZt5DyN
M7BDYKklMu5Oc8q7KfPSnu+6Y62kFc65VszbDvCDabRd92S7URB9IevBTJaP
BmO6u/DGZb9cvqn04/ZXUN5MGLpYINUuN4WbB62Wk0DyVJz2rwE8jQWiUTUP
bt34Vmnbqvh7FqpzZof4uUL6cvYNw4Viu3tpv3U5l8Bf6y/H2mq30AqqrMCI
tTCEPWiJnX31eDonmM6RhUqwnyyJyUnhcLhkGdXE0ec2jh4vj/hTaM2No9cK
SN6ml0ez2BgysXYiXJwY4+LQTVxPBQYfRiUmdDrj9Z6c3GVvPG0CF0f9N3sm
aljiqxSj8zXjMwnTlUN0qvRconS7bqs+bZiOetcsDcZ5MtKqJ06h8vvlODmA
2VkYSUiphp1Pw8ny2FBhrlyM+JsOXYIeSezSD1zKdKgcKccJEbvDZq3o+q+n
/JBthHRUsacWyNKdKB7rOt+8ostLdY2dEvgm2VWvTqWX1+d0cIl26VwNOgLC
HvqAD+1BdFYJuo4+JHh6dORAz/haJxZ4qgJ5Gm6UWXivANyCaAnf1hwMhWSw
83FGeh2OcwBCDqqm9MWO70sPOHfBHNGLi6a8a9lNdXTDxpJ9KsyZ9SxEtOFY
avA2DTZgaIeBZvxM+HYZhPab0QyfeZpfg6DXh8/CTgn1CuStAby1rvDpGq7Q
DkByiA9uEH/iBp88vX9Dq+5rtvyRRJo4QXBl08/ZuAZN/nglJ5u7T8UBbN2d
kzv9PqlMPoCTz0pPXMdYqywPetLEyf3rSRVE/r+GkE+efjiEfHpHCPn0wyDk
0w+GkE8/GwjJOOSjIGT2ACE/IYR042EmEawcCWvMN7tLDKwa5loZ4qJxuCrK
tSTEhe+vH+WqC3GdShh+jfgWFnOVvDj7xAwd+kKQXS3w1dKc88Ir5W55osOD
tBij2TSJ8yv6UoWh/kVqFxs6pUVPqxyNHVinZzf8BaeCfWCaMxk5pVO2Byk+
qNVL085W7IAvjizzVl+c0c5N58MrS/wuT2pMy4s6S1cjC8l89pl8y+ZGPC9S
m9dBEgbDmTZo7TeGeZvWNF0ztuT3m1zT/AhUZXqrAFbbYuOMGbiiQZjwXo2d
kjfw0qLLLqGSM4279urSpmsONa2sy2x9kGOpXTpp9il0aHKB7+xBKr+ed6HG
rJd7vobvaewcsKIf7LMb91TXybuAmKmHN312im9A2e/JxRF9a8lkgYGPS/JR
ZnrK3ysqW3DouxkGJwGUe6tpcZa8IrvYsvkXx0LdWDrXmD52ZW/59c0Rj8u6
s7voT3QIHhIJFPISMvh2scvVTQmzpwjQGe0lGGvPvuckIZNU0LB7tvSyORxN
srMy/naXAy9IQy0pc7goirJ6MrzDPG9fm2TadbPU+CHupJfDebgz3cPBbWMk
Uaxu317mnavU0M4VLr3fG4BTvzgcNIc8H3w6/yTeaRzFffovdbf4RG1K828L
XdxL9KgWooho/Iz2fvkkUaUMRFkWUStDtEZOPmOcI0lTYHrn+bzYhyDBJ56C
7dlPAeIO4cL23DEa9dFhm0cEyf42OCRy5DbKcQ5fYlB0u8RQaM/GZM8qKbiZ
bYjd8LpcE3/39tL54V6B/9K3anNvRYT6nsfBH03NXbXXppqldyhTHb/eaz9N
G0BPBjPwnaCnNDRY6aWr8RN/uGVxiCpnP/eDt4b6NpZtxQ1fDWP6QEEiMKCz
mib8YSR4AJmsBWaiV4vgdhYHYwPNJKpFm89NZBU/KFts9dHuTUTs8hXGDNAC
Ywn+ehXlTSP6lGghHXqmf8ySgIYX/OXhSvnM1lSbFPgxQzHijoHEaZxJVCbj
Rrs7PTuYBDdDzgJ6xOOFhIgVIzd2A3NVJvabN0WmOU9GsKhZRAnHmO0nm44M
HazLDcxUQigImP0sQef4XQ8CVWqcyAfbzD4np76lURv6HmqlvnJdFxI2CieW
uNT7rzzMnC+H1DWzdKIL0lleobXSlpq7pcKD3dgD12Gcp7Pb4lQ7d2uQOZaH
UL3fkYT2oQx/LwctMu11WtcmU+FPb5U/2ij/+jaZLPKbdyfvBs4/BZdvTim5
+4k6a7TJ92GP6/3CSW/fJoWBW2hm4X658Kp97FWLPNYh53vlwkVolLscmq+u
kT7zdha7bdPZcGnRC+3lW3esUOGHsfIwVj7LsYL+qB1G7cuD/roDxnnlYdis
ryqSG9CnD4v5qoKP3TX9cpl7VRWHjy7tKpa8BP6YH5Yos8LF3JQCKeuF770A
cjlC7EeXPyJCvO1Ct+01Y8WcP1EbK/YZK2LFaTy3quviey/kSYqOn2wEIAd6
m4Qj3BJ5cWgueH5Em1iKD9Sl+bDtbINsiir2Li4GR68uL6qrhQ9RRVUXVfRb
8wtsXDQd2fBYfr//Rb6V4S1QjCWxLSS0dnjLyLzLqQ9yWRxwim3axM0+EkPZ
tkvJ7k2kRCdgCOsFp1lx5fkt89Fzro9yki6jtxGOSKsGAX/T3NlnRl+dfBsu
FhrPaa7sOvOO8OBdeuW2O8aCoe0JW5Zzvl+z8U8aUfG/RlRwydbpwWx8UrPR
MOKl/0j76kvcLydNI96owy96XJDX+OK4IDvGkBArp9V38H/3ofKyR1UB9zDK
dCLbEB5GAv1+jZFQdOyqsfB7HAnl1pcHAxKqV1tngKhzPcoTPDduX/ZIm29p
Q1dTAWK/9uH/AXnxFhJ4kgAA

-->

</rfc>
