<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-chen-pce-pce-initiated-ip-tunnel-01" category="std" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.15.0 -->
  <!-- Generated by id2xml 1.5.0 on 2022-10-10T06:32:58Z -->
	<front>
    <title>PCE-initiated IP Tunnel</title>
    <seriesInfo name="Internet-Draft" value="draft-chen-pce-pce-initiated-ip-tunnel-01"/>
    <author initials="X." surname="Chen" fullname="Xia Chen">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>
          <street>Beijing  100095</street>
          <street>China</street>
        </postal>
        <email>jescia.chenxia@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Shi" fullname="Hang Shi">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>
          <street>Beijing  100095</street>
          <street>China</street>
        </postal>
        <email>shihang9@huawei.com</email>
      </address>
    </author>
    <author initials="Z." surname="Li" fullname="Zhenbin Li">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>
          <street>Beijing  100095</street>
          <street>China</street>
        </postal>
        <email>lizhenbin@huawei.com</email>
      </address>
    </author>
    <date year="2022" month="October" day="20"/>
    <abstract>
      <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" format="default"/>.  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>
      <name>Requirements Language</name>
      <t>
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 <xref target="RFC2119" format="default"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   <xref target="I-D.li-spring-tunnel-segment" format="default"/> 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.</t>
      <t>
   <xref target="I-D.li-spring-tunnel-segment" format="default"/> 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" format="default"/>, <xref target="RFC8281" format="default"/> and
   <xref target="RFC8664" format="default"/> 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="sect-2" numbered="true" toc="default">
      <name>Terminology</name>
      <t>
   SR: Segment Routing</t>
      <t>
   SR-TE: Segment Routing Traffic Engineering</t>
      <t>
   This document uses the terms defined in <xref target="RFC5440" format="default"/>: PCC, PCE, PCEP
   Peer.</t>
      <t>
   The following terms are defined in <xref target="RFC8281" format="default"/>:</t>
      <t>
   PCE-initiated LSP: LSP that is instantiated as a result of a request
   from the PCE.</t>
      <t>
   The following terms are defined in this document:</t>
      <t>
   IP Tunnel: Tunnel that uses IP encapsulation.</t>
      <t>
   PCE-initiated IP Tunnel: IP Tunnel that is instantiated as a result
   of a request from the PCE.</t>
      <t>
   The message formats in this document are specified using Routing
   Backus-Naur Format (RBNF) encoding as specified in <xref target="RFC5511" format="default"/>.</t>
    </section>
    <section anchor="sect-3" numbered="true" toc="default">
      <name>Procedures for PCE-initiated IP Tunnel</name>
      <section anchor="sect-3.1" numbered="true" toc="default">
        <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="sect-5.1" format="default"/>).</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="sect-3.2" numbered="true" toc="default">
        <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="sect-5.1" format="default"/>, 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
   MUST NOT 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 MUST only
   initiate the specific tunnel which both PCE and PCC can support.
   Otherwise PCC MUST send the PCErr message.</t>
      </section>
      <section anchor="sect-3.3" numbered="true" toc="default">
        <name>Tunnel Operations</name>
        <section anchor="sect-3.3.1" numbered="true" toc="default">
          <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 MUST include the SRP object (see details in <xref target="sect-5.2" format="default"/>) and
   TUNNEL object (see details in <xref target="sect-5.3" format="default"/>) . The TUNNEL object MUST
   have a PTUNNEL-ID of 0 and MUST include the Tunnel Identifier TLV
   with the TUNNEL-ID 0 and the Tunnel Name TLV.  The TUNNEL object MAY
   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 MUST 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="sect-5.3" format="default"/>) in TUNNEL object for the tunnel.  PCC indicates the
   operational state in the TUNNEL object.</t>
          <t>
   The PCTunneRpt message MUST include the SRP object, with the SRP-ID-
   NUMBER used in the SRP object of the PCTunnelInitiate message.</t>
          <artwork name="" type="" align="left" alt=""><![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="sect-3.3.2" numbered="true" toc="default">
          <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 MUST include the SRP object and TUNNEL object.
   The TUNNEL object MUST have specific PTUNNEL-ID and MUST have
   specific Tunnel Identifier TLV.  The TUNNEL object MUST 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 MUST include the SRP object, with the SRP-ID-
   NUMBER used in the SRP object of the PCTunnelUpd message.</t>
          <artwork name="" type="" align="left" alt=""><![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="sect-3.3.3" numbered="true" toc="default">
          <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
   MUST include the SRP object and TUNNEL object and the 'R' flag in SRP
   object SHOULD be set.  The TUNNEL object MUST have specific PTUNNEL-
   ID and MUST 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 MUST include the SRP object, with the SRP-ID-
   NUMBER used in the SRP object of the PCTunnelInitiate message.</t>
          <artwork name="" type="" align="left" alt=""><![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="sect-4" numbered="true" toc="default">
      <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="sect-4.1" numbered="true" toc="default">
        <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 MUST include the SRP and the TUNNEL objects.
   If the SRP object is missing, the PCC MUST send a PCErr with error-
   type 6 (Mandatory Object missing) and error-value=10 (SRP Object
   missing) (per <xref target="RFC8231" format="default"/>).  If the TUNNEL object is
   missing, the PCC MUST 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 name="" type="" align="left" alt=""><![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" format="default"/> 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 MUST 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 MUST 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="sect-4.2" numbered="true" toc="default">
        <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 MUST include the SRP and the TUNNEL objects.
   If the SRP object is missing, the PCC MUST send a PCErr with error-
   type 6 (Mandatory Object missing) and error-value=10 (SRP Object
   missing) (per <xref target="RFC8231" format="default"/>).  If the TUNNEL object is
   missing, the PCC MUST 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 name="" type="" align="left" alt=""><![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 MUST include Tunnel Identifier
   TLV and any of Tunnel Parameter TLV and Tunnel Attribute TLV.  Tunnel
   Name TLV is not included.</t>
      </section>
      <section anchor="sect-4.3" numbered="true" toc="default">
        <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 MUST
   include the SRP and the TUNNEL objects.  If the SRP object is
   missing, the PCE MUST send a PCErr with error-type 6 (Mandatory
   Object missing) and error-value=10 (SRP Object missing) (per
   <xref target="RFC8231" format="default"/>).  If the TUNNEL object is missing, the
   PCE MUST 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 name="" type="" align="left" alt=""><![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 MUST 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 MUST be included.
   And in the subsequent PCTunnelRpt message Tunnel Name TLV is
   optionally included.</t>
      </section>
    </section>
    <section anchor="sect-5" numbered="true" toc="default">
      <name>PCEP Objects</name>
      <section anchor="sect-5.1" numbered="true" toc="default">
        <name>OPEN Object</name>
        <section anchor="sect-5.1.1" numbered="true" toc="default">
          <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" format="default"/> to exchange PCE-initiated tunnel
   capability of PCEP speakers.</t>
          <dl newline="true" spacing="normal" indent="0">
            <dt>Its format is shown in the following figure:</dt>
            <dd/>
          </dl>
          <figure anchor="ure-pce-initiate-tunnel-capability-tlv">
            <name>PCE-INITIATE-TUNNEL-CAPABILITY TLV</name>
            <artwork name="" type="" align="left" alt=""><![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>
          </figure>
          <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="RFC5512" format="default"/> assigned by IANA.
   This document only use the IP tunnel type.</t>
          <dl newline="true" spacing="normal" indent="0">
            <dt>The assignments used by this document are as follows:</dt>
            <dd/>
          </dl>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      Tunnel Type                             Value
      ---------------                         -----
      Reserved                                  0
      GRE                                       2
      VXLAN                                     8
      NVGRE                                     9
      MPLS in GRE                               11
      VxLAN GPE                                 12
      MPLS in UDP                               13
]]></artwork>
          <t>
   Unassigned bits are considered reserved.  They MUST be set to 0 on
   transmission and MUST be ignored on receipt.</t>
        </section>
      </section>
      <section anchor="sect-5.2" numbered="true" toc="default">
        <name>SRP Object</name>
        <t>
   &lt;SRP&gt; object is defined in <xref target="RFC8231" format="default"/>.  In this
   document &lt;SRP&gt; is used to correlate PCTunnelInitiate and PCTunnelRpt
   or PCErr message.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
'R' Flag in <SRP> object is defined in
[RFC8281].  When PCE requests PCC to create
the IP tunnel 'R' Flag in <SRP> is set to 0.  When PCE requests PCC
to delete the IP tunnel 'R' Flag in <SRP> is set to 1.
]]></artwork>
        <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="sect-5.3" numbered="true" toc="default">
        <name>TUNNEL Object</name>
        <t>
   The TUNNEL object MUST 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>
        <dl newline="true" spacing="normal" indent="0">
          <dt>The format of the TUNNEL object body is shown in following Figure:</dt>
          <dd/>
        </dl>
        <figure anchor="ure-tunnel-object">
          <name>TUNNEL Object</name>
          <artwork name="" type="" align="left" alt=""><![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>
        </figure>
        <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 MUST be set to 0 on
   transmission and MUST be ignored on receipt.</t>
        <t>
   TLVs that may be included in the TUNNEL Object are described in the
   following sections.</t>
        <section anchor="sect-5.3.1" numbered="true" toc="default">
          <name>Tunnel Identifier TLV</name>
          <t>
   The Tunnel Identifier TLV MUST 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>
          <figure anchor="ure-ipv4-tunnel-identifier-tlv">
            <name>IPV4-TUNNEL-Identifier TLV</name>
            <artwork name="" type="" align="left" alt=""><![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>
          </figure>
          <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.  The value of tunnel types
   refer to the registry for "BGP Tunnel Encapsulation Attribute Tunnel Types" <xref target="RFC5512" format="default"/> IANA set up.  This document only use the IP tunnel
   type.</t>
          <dl newline="true" spacing="normal" indent="0">
            <dt>The assignments used by this document are as follows:</dt>
            <dd/>
          </dl>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      Tunnel Type                             Value
      ---------------                         -----
      Reserved                                  0
      GRE                                       2
      VXLAN                                     8
      NVGRE                                     9
      MPLS in GRE                               11
      VxLAN GPE                                 12
      MPLS in UDP                               13
]]></artwork>
          <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>
          <figure anchor="ure-ipv6-tunnel-identifier-tlv">
            <name>IPV6-TUNNEL-Identifier TLV</name>
            <artwork name="" type="" align="left" alt=""><![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>
          </figure>
          <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.  The value of tunnel types
   refer to the registry for "BGP Tunnel Encapsulation Attribute Tunnel Types" <xref target="RFC5512" format="default"/> IANA set up.</t>
          <t>
   This document only use the IP tunnel type.  The assignments used by
   this document are as follows:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      Tunnel Type                             Value
      ---------------                         -----
      Reserved                                  0
      GRE                                       2
      VXLAN                                     8
      NVGRE                                     9
      MPLS in GRE                               11
      MPLS in UDP                               13
]]></artwork>
          <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="sect-5.3.2" numbered="true" toc="default">
          <name>Tunnel Name TLV</name>
          <t>
   The Tunnel Name TLV MUST 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 MUST have a tunnel name that is unique in the PCC.  This
   tunnel name MUST remain constant throughout a tunnel's lifetime.</t>
          <t>
   The TUNNEL-NAME TLV MUST 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 MAY
   be included in subsequent PCTunnelRpt messages for the tunnel.</t>
          <dl newline="true" spacing="normal" indent="0">
            <dt>The format of the TUNNEL-NAME TLV is shown in the following figure:</dt>
            <dd/>
          </dl>
          <figure anchor="ure-tunnel-name-tlv">
            <name>TUNNEL-NAME TLV</name>
            <artwork name="" type="" align="left" alt=""><![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>
          </figure>
          <t>
   The type of the TLV is to be assigned by IANA and it has a variable
   length, which MUST be greater than 0.</t>
        </section>
        <section anchor="sect-5.3.3" numbered="true" toc="default">
          <name>Tunnel Parameter TLV</name>
          <t>
   The Tunnel Parameter TLV and/or Tunnel Attribute TLV(see details in
   following section) MUST 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 MAY 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 MAY 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>
          <dl newline="true" spacing="normal" indent="0">
            <dt>The format of the TUNNEL-PARAMETER TLV is shown in following figure:</dt>
            <dd/>
          </dl>
          <figure anchor="ure-tunnel-parameter-tlv">
            <name>TUNNEL-PARAMETER TLV</name>
            <artwork name="" type="" align="left" alt=""><![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>
          </figure>
          <t>
   The type of the TLV is to be assigned by IANA and it has a variable
   length, which MUST 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.  The value of tunnel types
   refer to the registry for "BGP Tunnel Encapsulation Attribute Tunnel Types" <xref target="RFC5512" format="default"/> IANA set up.  This document only use the IP tunnel
   type.</t>
          <dl newline="true" spacing="normal" indent="0">
            <dt>The assignments used by this document are as follows:</dt>
            <dd/>
          </dl>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      Tunnel Type                             Value
      ---------------                         -----
      Reserved                                  0
      GRE                                       2
      VXLAN                                     8
      NVGRE                                     9
      MPLS in GRE                               11
      VxLAN GPE                                 12
      MPLS in UDP                               13

MPLS in GRE has the same encapsulation with GRE.
]]></artwork>
          <section anchor="sect-5.3.3.1" numbered="true" toc="default">
            <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>
            <figure anchor="ure-gre-encapsulation-tlv">
              <name>GRE Encapsulation TLV</name>
              <artwork name="" type="" align="left" alt=""><![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>
            </figure>
            <t>
   * GRE Key: 4-octet field <xref target="RFC2890" format="default"/>.  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>
            <t>
   Note that the key is optional.  Unless a key value is being used, the
   GRE encapsulation MUST NOT 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>
          </section>
          <section anchor="sect-5.3.3.2" numbered="true" toc="default">
            <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>
            <figure anchor="ure-vxlan-encapsulation-tlv">
              <name>VXLAN Encapsulation TLV</name>
              <artwork name="" type="" align="left" alt=""><![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>
            </figure>
            <t>
   The definition of the fields refer to <xref target="I-D.rosen-idr-tunnel-encaps" format="default"/>.</t>
          </section>
          <section anchor="sect-5.3.3.3" numbered="true" toc="default">
            <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>
            <figure anchor="ure-nvgre-encapsulation-tlv">
              <name>NVGRE Encapsulation TLV</name>
              <artwork name="" type="" align="left" alt=""><![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>
            </figure>
            <t>
   The definition of the fields refer to <xref target="I-D.rosen-idr-tunnel-encaps" format="default"/>.</t>
          </section>
          <section anchor="sect-5.3.3.4" numbered="true" toc="default">
            <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>
            <figure anchor="ure-mpls-in-udp-encapsulation-tlv">
              <name>MPLS-in-UDP Encapsulation TLV</name>
              <artwork name="" type="" align="left" alt=""><![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>
            </figure>
            <t>
   Source Port: UDP source port.</t>
            <t>
   Destination Port: UDP destination port.</t>
          </section>
        </section>
        <section anchor="sect-5.3.4" numbered="true" toc="default">
          <name>Tunnel Attribute TLV</name>
          <t>
   The Tunnel Attribute TLV MAY 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>
          <dl newline="true" spacing="normal" indent="0">
            <dt>The format of the TUNNEL-ATTRIBUTE TLV is shown in following figure:</dt>
            <dd/>
          </dl>
          <figure anchor="ure-tunnel-attribute-tlv-format">
            <name>Tunnel Attribute TLV Format</name>
            <artwork name="" type="" align="left" alt=""><![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>
          </figure>
          <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="sect-5.3.4.1" numbered="true" toc="default">
            <name>Metric Sub-TLV</name>
            <dl newline="true" spacing="normal" indent="0">
              <dt>The following is the structure of the sub-TLV of metric:</dt>
              <dd/>
            </dl>
            <figure anchor="ure-metric-sub-tlv">
              <name>Metric Sub-TLV</name>
              <artwork name="" type="" align="left" alt=""><![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>
            </figure>
            <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="sect-5.3.4.2" numbered="true" toc="default">
            <name>TE Metric Sub-TLV</name>
            <t>
   The following is the structure of the sub-TLV of traffic engineering
   metric:</t>
            <figure anchor="ure-te-metric-sub-tlv">
              <name>TE Metric Sub-TLV</name>
              <artwork name="" type="" align="left" alt=""><![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>
            </figure>
            <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="sect-6" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   TBD.</t>
    </section>
    <section anchor="sect-7" numbered="true" toc="default">
      <name>Security 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://www.ietf.org/archive/id/draft-li-spring-tunnel-segment-02.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-li-spring-tunnel-segment-02.xml">
          <front>
            <title>Tunnel Segment in Segment Routing</title>
            <author fullname="Zhenbin Li" initials="Z." surname="Li"/>
            <author fullname="Nan Wu" initials="N." surname="Wu"/>
            <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="I-D.rosen-idr-tunnel-encaps" target="https://www.ietf.org/archive/id/draft-rosen-idr-tunnel-encaps-03.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draft-rosen-idr-tunnel-encaps-03.xml">
          <front>
            <title>Using the BGP Tunnel Encapsulation Attribute without the BGP Encapsulation SAFI</title>
            <author fullname="Eric C. Rosen"/>
            <author fullname="Keyur Patel"/>
            <author fullname="Gunter Van de Velde"/>
            <date day="6" month="August" year="2015"/>
            <abstract>
              <t>RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide additional information used to create a tunnel and the corresponding encapsulation header, and can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document updates RFC 5512 by deprecating the Encapsulation SAFI (which has never been used),and by specifying semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document also extends the attribute by enabling it to carry additional information needed to create the encapsulation headers additional tunnel types not mentioned in RFC 5512. Finally, this document also extends the attribute by allowing it to specify a remote tunnel endpoint address for each tunnel.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-rosen-idr-tunnel-encaps-03"/>
        </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="RFC5512" target="https://www.rfc-editor.org/info/rfc5512" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5512.xml">
          <front>
            <title>The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute</title>
            <author fullname="P. Mohapatra" initials="P." surname="Mohapatra"/>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <date month="April" year="2009"/>
            <abstract>
              <t>In certain situations, transporting a packet from one Border Gateway Protocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the "encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.</t>
              <t>The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such as Layer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic Routing Encapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using the Encapsulation Subsequent Address Family Identifier (SAFI) and the IPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5512"/>
          
        </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="Edward Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="Ina Minei" initials="I." surname="Minei"/>
            <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="Robert Varga" initials="R." surname="Varga"/>
            <date day="1" 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.

                 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="RFC8281" 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="Siva Sivabalan" initials="S." surname="Sivabalan"/>
            <author fullname="Clarence Filsfils" initials="C." surname="Filsfils"/>
            <author fullname="Jeff Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="Wim Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="Jonathan Hardwick" initials="J." surname="Hardwick"/>
            <date day="1" 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>
            </abstract>
          </front>
          <seriesInfo name="RFC8664" 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="Edward Crabbe" initials="E." surname="Crabbe"/>
            <author fullname="Ina Minei" initials="I." surname="Minei"/>
            <author fullname="Jan Medved" initials="J." surname="Medved"/>
            <author fullname="Robert Varga" initials="R." surname="Varga"/>
            <date day="1" 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.

                 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="RFC8231" value="8231"/>
          <seriesInfo name="DOI" value="10.17487/RFC8231"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
