<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.2.3) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>

<?rfc comments="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-teas-rfc8776-update-15" category="std" consensus="true" submissionType="IETF" obsoletes="8776" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="TE Common YANG Types">Common YANG Data Types for Traffic Engineering</title>

    <author initials="I." surname="Busi" fullname="Italo Busi">
      <organization>Huawei</organization>
      <address>
        <email>italo.busi@huawei.com</email>
      </address>
    </author>
    <author initials="A." surname="Guo" fullname="Aihua Guo">
      <organization>Futurewei Technologies</organization>
      <address>
        <email>aihuaguo.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="X." surname="Liu" fullname="Xufeng Liu">
      <organization>Alef Edge</organization>
      <address>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="T." surname="Saad" fullname="Tarek Saad">
      <organization>Cisco Systems Inc.</organization>
      <address>
        <email>tsaad.net@gmail.com</email>
      </address>
    </author>
    <author initials="I." surname="Bryskin" fullname="Igor Bryskin">
      <organization>Individual</organization>
      <address>
        <email>i_bryskin@yahoo.com</email>
      </address>
    </author>

    <date year="2025" month="January" day="24"/>

    
    <workgroup>TEAS Working Group</workgroup>
    

    <abstract>


<?line 67?>

<t>This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities.</t>

<t>This document obsoletes RFC 8776.</t>



    </abstract>



  </front>

  <middle>


<?line 73?>

<section anchor="introduction"><name>Introduction</name>

<t>YANG <xref target="RFC6020"/> <xref target="RFC7950"/> is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols such as the Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types.</t>

<t>This document introduces a collection of common data types derived from the built-in YANG data types. The derived data types, identities, and groupings are mainly designed to be the common definitions applicable for modeling Traffic Engineering (TE) features in model(s) defined outside of this document. Nevertheless, these common definitions can be used by any other module per the guidance in <xref section="4.12" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t>

<t>The YANG data model in this document conforms to the Network Management Datastore Architecture defined in <xref target="RFC8342"/>.</t>

<t>This document adds new common data types, identities, and groupings to both the "ietf-te-types" and the "ietf-te-packet-types" YANG modules and obsoletes <xref target="RFC8776"/>. For further details, refer to <xref target="changes-bis"/>.</t>

<section anchor="terminology"><name>Terminology</name>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
<?line -6?></t>

<t>The terminology for describing YANG data models is found in
   <xref target="RFC7950"/>.</t>

</section>
<section anchor="prefixes-in-data-node-names"><name>Prefixes in Data Node Names</name>

<t>Names of data nodes and other data model objects
  are prefixed using the standard prefix associated with the
  corresponding YANG imported modules, as shown in <xref target="tab-prefixes"/>.</t>

<texttable title="Prefixes and corresponding YANG modules" anchor="tab-prefixes">
      <ttcol align='left'>Prefix</ttcol>
      <ttcol align='left'>YANG module</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>yang</c>
      <c>ietf-yang-types</c>
      <c><xref section="3" sectionFormat="of" target="RFC6991"/></c>
      <c>inet</c>
      <c>ietf-inet-types</c>
      <c><xref section="4" sectionFormat="of" target="RFC6991"/></c>
      <c>rt-types</c>
      <c>ietf-routing-types</c>
      <c><xref target="RFC8294"/></c>
      <c>te-types</c>
      <c>ietf-te-types</c>
      <c>RFCXXXX</c>
      <c>te-packet-types</c>
      <c>ietf-te-packet-types</c>
      <c>RFCXXXX</c>
</texttable>

<ul empty="true"><li>
  <t>RFC Editor: Please replace XXXX through this document with the RFC number assigned to this document. Please remove this note.</t>
</li></ul>

</section>
<section anchor="tree-diagrams"><name>Tree Diagrams</name>

<t>Tree diagrams used in this document follow the notation defined in <xref target="RFC8340"/>.</t>

</section>
</section>
<section anchor="acronyms-and-abbreviations"><name>Acronyms and Abbreviations</name>

<dl>
  <dt>APS:</dt>
  <dd>
    <t>Automatic Protection Switching</t>
  </dd>
  <dt>DS-TE:</dt>
  <dd>
    <t>Differentiated Services Traffic Engineering</t>
  </dd>
  <dt>GMPLS:</dt>
  <dd>
    <t>Generalized Multiprotocol Label Switching</t>
  </dd>
  <dt>LER:</dt>
  <dd>
    <t>Label Edge Router</t>
  </dd>
  <dt>LSP:</dt>
  <dd>
    <t>Label Switched Path</t>
  </dd>
  <dt>LSR:</dt>
  <dd>
    <t>Label Switching Router</t>
  </dd>
  <dt>MPLS:</dt>
  <dd>
    <t>Multiprotocol Label Switching</t>
  </dd>
  <dt>NBMA:</dt>
  <dd>
    <t>Non-Broadcast Multi-Access</t>
  </dd>
  <dt>PM:</dt>
  <dd>
    <t>Performance Metrics</t>
  </dd>
  <dt>RSVP:</dt>
  <dd>
    <t>Resource Reservation Protocol</t>
  </dd>
  <dt>SD:</dt>
  <dd>
    <t>Signal Degrade</t>
  </dd>
  <dt>SF:</dt>
  <dd>
    <t>Signal Fail</t>
  </dd>
  <dt>SRLG:</dt>
  <dd>
    <t>Shared Risk Link Group</t>
  </dd>
  <dt>TE:</dt>
  <dd>
    <t>Traffic Engineering</t>
  </dd>
  <dt>WTR:</dt>
  <dd>
    <t>Wait-to-Restore</t>
  </dd>
</dl>

</section>
<section anchor="overview"><name>Overview</name>

<t>This document defines two YANG modules for common TE types: "ietf-te-types" for TE generic types and "ietf-te-packet-types" for packet-specific types. Other technology-specific TE types are outside the scope of this document.</t>

<section anchor="te-types-module-contents"><name>TE Types Module Contents</name>

<t>The "ietf-te-types" module (<xref target="te-yang-code"/>) contains common TE types that are independent and agnostic of any specific technology or control-plane instance.</t>

<section anchor="groupings"><name>Groupings</name>

<t>The "ietf-te-types" module contains the following YANG reusable groupings:</t>

<dl>
  <dt>te-bandwidth:</dt>
  <dd>
    <t>A YANG grouping that defines the generic TE bandwidth. The modeling structure allows augmentation for each technology. For unspecified technologies, the string-encoded "te-bandwidth" type is used.</t>
  </dd>
  <dt>te-label:</dt>
  <dd>
    <t>A YANG grouping that defines the generic TE label. The modeling structure allows augmentation for each technology. For unspecified technologies, "rt-types:generalized-label" is used.</t>
  </dd>
  <dt>performance-metrics-attributes:</dt>
  <dd>
    <t>A YANG grouping that defines one-way and two-way measured Performance Metrics (PM) and indications of anomalies on link(s) or the path as defined in <xref target="RFC7471"/>, <xref target="RFC8570"/>, and <xref target="RFC7823"/>.</t>
  </dd>
  <dt>performance-metrics-throttle-container:</dt>
  <dd>
    <t>A YANG grouping that defines configurable thresholds for advertisement suppression and measurement intervals.</t>
  </dd>
  <dt>explicit-route-hop:</dt>
  <dd>
    <t>A YANG grouping that defines supported explicit routes as defined in <xref target="RFC3209"/> and <xref target="RFC3477"/>.</t>
  </dd>
  <dt>explicit-route-hop-with-srlg:</dt>
  <dd>
    <t>A YANG grouping that augments the 'explicit-route-hop' to specify also Shared Risk Link Group (SRLG) hops.</t>
  </dd>
  <dt>encoding-and-switching-type:</dt>
  <dd>
    <t>This is a common grouping to define the LSP encoding and switching types.</t>
  </dd>
</dl>

</section>
<section anchor="data-types"><name>Data Types</name>

<t>The "ietf-te-types" module contains the following YANG reusable data types:</t>

<dl>
  <dt>te-ds-class:</dt>
  <dd>
    <t>A type representing the Differentiated Services (DS) Class-Type of traffic as defined in <xref target="RFC4124"/>.</t>
  </dd>
  <dt>te-label-direction:</dt>
  <dd>
    <t>An enumerated type for specifying the forward or reverse direction of a label.</t>
  </dd>
  <dt>te-hop-type:</dt>
  <dd>
    <t>An enumerated type for specifying that a hop is loose or strict.</t>
  </dd>
  <dt>te-global-id:</dt>
  <dd>
    <t>A type representing the identifier that uniquely identifies an operator, which can be either a provider or a client. The definition of this type is taken from <xref section="3" sectionFormat="of" target="RFC6370"/> and <xref section="3" sectionFormat="of" target="RFC5003"/>. This attribute type is used solely to provide a globally unique context for TE topologies.</t>
  </dd>
  <dt>te-node-id:</dt>
  <dd>
    <t>A type representing the identifier for a node in a TE topology. The identifier is represented either as 4 octets in dotted-quad notation or as 16 octets in full, mixed, shortened, or shortened-mixed IPv6 address notation.</t>
  </dd>
  <dt/>
  <dd>
    <t>This attribute MAY be mapped to the Router Address TLV described in <xref section="2.4.1" sectionFormat="of" target="RFC3630"/>, the TE Router ID described in <xref section="6.2" sectionFormat="of" target="RFC6827"/>, the Traffic Engineering Router ID TLV described in <xref section="4.3" sectionFormat="of" target="RFC5305"/>, or the TE Router ID TLV described in <xref section="3.2.1" sectionFormat="of" target="RFC6119"/>.</t>
  </dd>
  <dt/>
  <dd>
    <t>The reachability of such a TE node MAY be achieved by a mechanism such as that described in <xref section="6.2" sectionFormat="of" target="RFC6827"/>.</t>
  </dd>
  <dt>te-topology-id:</dt>
  <dd>
    <t>A type representing the identifier for a topology. It is optional to have one or more prefixes at the beginning, separated by colons. The prefixes can be "network-types" as defined in the "ietf-network" module in <xref target="RFC8345"/>, to help the user better understand the topology before further inquiry is made.</t>
  </dd>
  <dt>te-tp-id:</dt>
  <dd>
    <t>A type representing the identifier of a TE interface Link Termination Point (LTP) on a specific TE node where the TE link connects. This attribute is mapped to a local or remote link identifier <xref target="RFC3630"/> <xref target="RFC5305"/>.</t>
  </dd>
  <dt>te-path-disjointness:</dt>
  <dd>
    <t>A type representing the different resource disjointness options for a TE tunnel path as defined in <xref target="RFC4872"/>.</t>
  </dd>
  <dt>admin-groups:</dt>
  <dd>
    <t>A union type for a TE link's classic or extended administrative groups as defined in <xref target="RFC3630"/>, <xref target="RFC5305"/>, and <xref target="RFC7308"/>.</t>
  </dd>
  <dt>srlg:</dt>
  <dd>
    <t>A type representing the Shared Risk Link Group (SRLG) as defined in <xref target="RFC4203"/> and <xref target="RFC5307"/>.</t>
  </dd>
  <dt>te-metric:</dt>
  <dd>
    <t>A type representing the TE metric as defined in <xref target="RFC3785"/>.</t>
  </dd>
  <dt>te-recovery-status:</dt>
  <dd>
    <t>An enumerated type for the different statuses of a recovery action as defined in <xref target="RFC6378"/> and <xref target="RFC4427"/>.</t>
  </dd>
  <dt>te-link-access-type:</dt>
  <dd>
    <t>An enumerated type for the different TE link access types as defined in <xref target="RFC3630"/>.</t>
  </dd>
</dl>

</section>
<section anchor="identities"><name>Identities</name>

<t>The "ietf-te-types" module contains the following YANG reusable identities:</t>

<dl>
  <dt>path-attribute-flags:</dt>
  <dd>
    <t>A base YANG identity for supported LSP path flags as defined in <xref target="RFC3209"/>, <xref target="RFC4090"/>, <xref target="RFC4736"/>, <xref target="RFC5712"/>, <xref target="RFC4920"/>, <xref target="RFC5420"/>, <xref target="RFC7570"/>, <xref target="RFC4875"/>, <xref target="RFC5151"/>, <xref target="RFC5150"/>, <xref target="RFC6001"/>, <xref target="RFC6790"/>, <xref target="RFC7260"/>, <xref target="RFC8001"/>, <xref target="RFC8149"/>, and <xref target="RFC8169"/>.</t>
  </dd>
  <dt>link-protection-type:</dt>
  <dd>
    <t>A base YANG identity for supported link protection types as defined in <xref target="RFC4872"/>.</t>
  </dd>
  <dt>restoration-scheme-type:</dt>
  <dd>
    <t>A base YANG identity for supported LSP restoration schemes as defined in <xref target="RFC4872"/>.</t>
  </dd>
  <dt>protection-external-commands:</dt>
  <dd>
    <t>A base YANG identity for supported protection-related external commands used for troubleshooting purposes, as defined in <xref target="RFC4872"/>, <xref target="RFC6368"/>, <xref target="RFC7271"/> and <xref target="RFC4427"/>.</t>
  </dd>
  <dt>association-type:</dt>
  <dd>
    <t>A base YANG identity for supported LSP association types as defined in <xref target="RFC6780"/>, <xref target="RFC4872"/>, <xref target="RFC4873"/>, and <xref target="RFC8800"/>.</t>
  </dd>
  <dt>objective-function-type:</dt>
  <dd>
    <t>A base YANG identity for supported path objective functions as defined in <xref target="RFC5541"/>.</t>
  </dd>
  <dt>te-tunnel-type:</dt>
  <dd>
    <t>A base YANG identity for supported TE tunnel types as defined in <xref target="RFC3209"/> and <xref target="RFC4875"/>.</t>
  </dd>
  <dt>lsp-encoding-types:</dt>
  <dd>
    <t>A base YANG identity for supported LSP encoding types as defined in <xref target="RFC3471"/>, <xref target="RFC4328"/> and <xref target="RFC6004"/>.</t>
  </dd>
  <dt/>
  <dd>
    <t>Additional technology-specific LSP encoding types can be defined in other technology-specific models.</t>
  </dd>
  <dt>lsp-protection-type:</dt>
  <dd>
    <t>A base YANG identity for supported LSP protection types as defined in <xref target="RFC4872"/> and <xref target="RFC4873"/>.</t>
  </dd>
  <dt>switching-capabilities:</dt>
  <dd>
    <t>A base YANG identity for supported interface switching capabilities as defined in <xref target="RFC3471"/>, <xref target="RFC6002"/>, <xref target="RFC6004"/>, <xref target="RFC7074"/> and <xref target="RFC7138"/>.</t>
  </dd>
  <dt/>
  <dd>
    <t>Additional technology-specific interface switching capabilities can be defined in other technology-specific models.</t>
  </dd>
  <dt>resource-affinities-type:</dt>
  <dd>
    <t>A base YANG identity for supported attribute filters associated with a tunnel that must be satisfied for a link to be acceptable as defined in <xref target="RFC3209"/> and <xref target="RFC2702"/>.</t>
  </dd>
  <dt>path-metric-type:</dt>
  <dd>
    <t>A base YANG identity for supported path metric types as defined in <xref target="RFC3630"/>, <xref target="RFC3785"/>, <xref target="RFC5440"/>, <xref target="RFC7471"/>, <xref target="RFC8233"/>, <xref target="RFC8570"/> and <xref target="I-D.ietf-pce-sid-algo-14"/>.</t>
  </dd>
  <dt/>
  <dd>
    <t>The unit of the path metric value is interpreted in the context of the path metric type. The derived identities SHOULD describe the unit and maximum value of the path metric types they define.</t>
  </dd>
  <dt/>
  <dd>
    <t>For example, the measurement unit is not applicable for the number of hops metric ('path-metric-hop'). Conversely, the bound of the 'path-metric-loss', defined in 'ietf-te-packet-types', is defined in multiples of the basic unit 0.000003% as described in <xref target="RFC7471"/> and <xref target="RFC8570"/>.</t>
  </dd>
  <dt>lsp-provisioning-error-reason:</dt>
  <dd>
    <t>A base YANG identity for indicating LSP provisioning error reasons. No standard LSP provisioning error reasons are defined in this document.</t>
  </dd>
  <dt>path-computation-error-reason:</dt>
  <dd>
    <t>A base YANG identity for indicating path computation error reasons as defined in <xref target="pc-error"/>.</t>
  </dd>
  <dt>protocol-origin-type:</dt>
  <dd>
    <t>A base YANG identity for the type of protocol origin as defined in <xref target="protocol-origin"/>.</t>
  </dd>
  <dt>svec-objective-function-type:</dt>
  <dd>
    <t>A base YANG identity for supported SVEC objective functions as defined in <xref target="RFC5541"/> and <xref target="RFC8685"/>.</t>
  </dd>
  <dt>svec-metric-type:</dt>
  <dd>
    <t>A base YANG identity for supported SVEC objective functions as defined in <xref target="RFC5541"/>.</t>
  </dd>
</dl>

<section anchor="pc-error"><name>Path Computation Errors</name>

<t>The "ietf-te-types" module contains the YANG reusable identities for indicating path computation error reasons as defined in <xref target="RFC5440"/>, <xref target="RFC5441"/>, <xref target="RFC5520"/>, <xref target="RFC5557"/>, <xref target="RFC8306"/>, and <xref target="RFC8685"/>.</t>

<t>It also defines the following additional YANG reusable identities for indicating also the following path computation error reasons:</t>

<dl>
  <dt>path-computation-error-no-topology:</dt>
  <dd>
    <t>A YANG identity for indicating path computation error when there is no topology with the provided topology identifier.</t>
  </dd>
  <dt>path-computation-error-no-dependent-server:</dt>
  <dd>
    <t>A YANG identity for indicating path computation error when one or more dependent path computation servers are unavailable.</t>
  </dd>
  <dt/>
  <dd>
    <t>The dependent path computation server could be a Backward-Recursive Path Computation (BRPC) downstream PCE or a child PCE.</t>
  </dd>
</dl>

<t>The derived identities are defined in the "ietf-te-types" module, instead of an IANA-maintained module, because there are error reasons which are:</t>

<t><list style="numbers" type="1">
  <t>applicable only to the TE YANG models and not to PCEP environments (e.g., path-computation-error-no-topology);</t>
  <t>technology-specific (e.g., No RWA constraints met) which are better defined in technology-specific YANG models;</t>
  <t>match more than one PCEP numbers in order to hide the details of the underlay PCE architecture (e.g., path-computation-error-no-dependent-server).</t>
</list></t>

</section>
<section anchor="protocol-origin"><name>Protocol Origin</name>

<t>The "ietf-te-types" module contains the YANG reusable identities for the type of protocol origin as defined in <xref target="RFC5440"/> and <xref target="RFC9012"/>.</t>

<t>It also defines the following additional YANG reusable identities for the type of protocol origin:</t>

<dl>
  <dt>protocol-origin-api:</dt>
  <dd>
    <t>A YANG identity to be used when the type of protocol origin is an Application Programmable Interface (API).</t>
  </dd>
</dl>

</section>
</section>
</section>
<section anchor="packet-te-types-module-contents"><name>Packet TE Types Module Contents</name>

<t>The "ietf-te-packet-types" module (<xref target="pkt-yang-code"/>) covers the common types and groupings that are specific to packet technology.</t>

<section anchor="groupings-1"><name>Groupings</name>

<t>The "ietf-te-packet-types" module contains the following YANG reusable groupings:</t>

<dl>
  <dt>performance-metrics-attributes-packet:</dt>
  <dd>
    <t>A YANG grouping that contains the generic performance metrics and additional packet-specific metrics.</t>
  </dd>
  <dt>bandwidth-profile-parameters:</dt>
  <dd>
    <t>A YANG grouping that defines common parameters for bandwidth profiles in packet networks.</t>
  </dd>
  <dt>te-packet-path-bandwidth:</dt>
  <dd>
    <t>A YANG grouping that defines the path bandwidth information and could be used in any Packet TE model (e.g., MPLS-TE topology model) for the path bandwidth representation (e.g., the bandwidth of an MPLS-TE LSP).</t>
  </dd>
  <dt/>
  <dd>
    <t>All the path and LSP bandwidth related sections in the "ietf-te-types" generic module, <xref target="te-yang-code"/>, need to be augmented with this grouping for the usage of Packet TE technologies.</t>
  </dd>
  <dt>te-packet-link-bandwidth:</dt>
  <dd>
    <t>A YANG grouping that defines the link bandwidth information and could be used in any Packet TE model (e.g., MPLS-TE topology) for link bandwidth representation.</t>
  </dd>
  <dt/>
  <dd>
    <t>All the link bandwidth related sections in the "ietf-te-types" generic module, <xref target="te-yang-code"/>, need to be augmented with this grouping for the usage of Packet TE technologies.</t>
  </dd>
</dl>

</section>
<section anchor="data-types-1"><name>Data Types</name>

<t>The "ietf-te-packet-types" module contains the following YANG reusable data types:</t>

<dl>
  <dt>te-bandwidth-requested-type:</dt>
  <dd>
    <t>An enumerated type for the different options to request bandwidth for a specific tunnel.</t>
  </dd>
</dl>

</section>
<section anchor="identities-1"><name>Identities</name>

<t>The "ietf-te-packet-types" module contains the following YANG reusable identities:</t>

<dl>
  <dt>backup-protection-type:</dt>
  <dd>
    <t>A base YANG identity for supported protection types that a backup or bypass tunnel can provide as defined in <xref target="RFC4090"/>.</t>
  </dd>
  <dt>bc-model-type:</dt>
  <dd>
    <t>A base YANG identity for supported Diffserv-TE Bandwidth Constraints Models as defined in <xref target="RFC4125"/>, <xref target="RFC4126"/>, and <xref target="RFC4127"/>.</t>
  </dd>
  <dt>bandwidth-profile-type:</dt>
  <dd>
    <t>A base YANG identity for various bandwidth profiles specified in <xref target="MEF_10.3"/>, <xref target="RFC2697"/> and <xref target="RFC2698"/> that may be used to limit bandwidth utilization of packet flows (e.g., MPLS-TE LSPs).</t>
  </dd>
</dl>

</section>
</section>
</section>
<section anchor="te-yang-code"><name>TE Types YANG Module</name>

<t>The "ietf-te-types" module imports from the following modules:</t>

<t><list style="symbols">
  <t>"ietf-yang-types" and "ietf-inet-types" as defined in <xref target="RFC6991"/></t>
  <t>"ietf-routing-types" as defined in <xref target="RFC8294"/></t>
</list></t>

<t>In addition to <xref target="RFC6991"/> and <xref target="RFC8294"/>, this module references the following documents in defining the types and YANG groupings:
<xref target="RFC9522"/>, <xref target="RFC4090"/>, <xref target="RFC4202"/>, <xref target="RFC4328"/>, <xref target="RFC4561"/>, <xref target="RFC4657"/>, <xref target="RFC4736"/>, <xref target="RFC6004"/>, <xref target="RFC6378"/>, <xref target="RFC6511"/>, <xref target="RFC7139"/>, <xref target="RFC7271"/>, <xref target="RFC7308"/>, <xref target="RFC7551"/>, <xref target="RFC7571"/>, <xref target="RFC7579"/>, and <xref target="ITU-T_G.709"/>.</t>

<figure title="TE Types YANG module" anchor="fig-te-yang"><sourcecode type="yang" markers="true" name="ietf-te-types@2024-11-28.yang"><![CDATA[
module ietf-te-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-te-types";
  prefix te-types;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-routing-types {
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types for the Routing Area";
  }

  import ietf-network {
    prefix "nw";
    reference
      "RFC 8345: A YANG Data Model for Network Topologies";
  }

  import ietf-network-topology {
    prefix "nt";
    reference
      "RFC 8345: A YANG Data Model for Network Topologies";
  }

  organization
    "IETF Traffic Engineering Architecture and Signaling (TEAS)
     Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/teas/>
     WG List:  <mailto:teas@ietf.org>

     Editor:   Tarek Saad
               <mailto:tsaad.net@gmail.com>

     Editor:   Rakesh Gandhi
               <mailto:rgandhi@cisco.com>

     Editor:   Vishnu Pavan Beeram
               <mailto:vbeeram@juniper.net>

     Editor:   Xufeng Liu
               <mailto:xufeng.liu.ietf@gmail.com>

     Editor:   Igor Bryskin
               <mailto:i_bryskin@yahoo.com>";
  description
    "This YANG module contains a collection of generally useful
     YANG data type definitions specific to TE.
     
     The model conforms to the Network Management Datastore
     Architecture (NMDA).

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2025 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.";
  revision 2025-01-24 {
    description
      "This revision adds the following new identities:
      - lsp-provisioning-error-reason;
      - association-type-diversity;
      - tunnel-admin-state-auto;
      - lsp-restoration-restore-none;
      - restoration-scheme-rerouting;
      - path-metric-optimization-type;
      - link-path-metric-type;
      - link-metric-type and its derived identities;
      - path-computation-error-reason and its derived identities;
      - protocol-origin-type and its derived identities;
      - svec-objective-function-type and its derived identities;
      - svec-metric-type and its derived identities.

      This revision adds the following new data types:
      - path-type.

      This revision adds the following new groupings:
      - explicit-route-hop-with-srlg;
      - encoding-and-switching-type;
      - te-generic-node-id.

      This revision updates the following identities:
      - objective-function-type;
      - action-exercise;
      - path-metric-type;
      - path-metric-te;
      - path-metric-igp;
      - path-metric-hop;
      - path-metric-delay-average;
      - path-metric-delay-minimum;
      - path-metric-residual-bandwidth;
      - path-metric-optimize-includes;
      - path-metric-optimize-excludes;
      - te-optimization-criterion.

      This revision updates the following data types:
      - te-node-id.

      This revision updates the following groupings:
      - explicit-route-hop:
        - adds the following leaves:
          - node-id-uri;
          - link-tp-id-uri;
        - updates the following leaves:
          - node-id;
          - link-tp-id;
      - record-route-state:
        - adds the following leaves:
          - node-id-uri;
          - link-tp-id-uri;
        - updates the following leaves:
          - node-id;
          - link-tp-id;
      - optimization-metric-entry:
        - updates the following leaves:
          - metric-type;
      - tunnel-constraints;
        - adds the following leaves:
          - network-id;
      - path-constraints-route-objects:
        - updates the following containers:
          - explicit-route-objects-always;
      - generic-path-metric-bounds:
        - updates the following leaves:
          - metric-type;
      - generic-path-optimization
        - adds the following leaves:
          - tiebreaker;
        - deprecate the following containers:
          - tiebreakers.

      This revision obsoletes the following identities:
      - of-minimize-agg-bandwidth-consumption;
      - of-minimize-load-most-loaded-link;
      - of-minimize-cost-path-set;
      - lsp-protection-reroute-extra;
      - lsp-protection-reroute.

      This revision provides also few editorial changes.";
    reference
      "RFC XXXX: Common YANG Data Types for Traffic Engineering";
  }
  // RFC Editor: replace XXXX with actual RFC number, update date
  // information and remove this note

  revision 2020-06-10 {
    description
      "Initial Version of TE types.";
    reference
      "RFC 8776: Common YANG Data Types for Traffic Engineering";
  }

  /**
   * Typedefs
   */

  typedef admin-group {
    type yang:hex-string {
      /* 01:02:03:04 */
      length "1..11";
    }
    description
      "Administrative group / resource class / color representation
       in 'hex-string' type.

       The most significant byte in the hex-string is the farthest
       to the left in the byte sequence.
       
       Leading zero bytes in the configured value may be omitted
       for brevity.";
    reference
      "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                 Version 2
       RFC 5305: IS-IS Extensions for Traffic Engineering
       RFC 7308: Extended Administrative Groups in MPLS Traffic
                 Engineering (MPLS-TE)";
  }

  typedef admin-groups {
    type union {
      type admin-group;
      type extended-admin-group;
    }
    description
      "Derived types for TE administrative groups.";
  }

  typedef extended-admin-group {
    type yang:hex-string;
    description
      "Extended administrative group / resource class / color
       representation in 'hex-string' type.

       The most significant byte in the hex-string is the farthest
       to the left in the byte sequence.
       
       Leading zero bytes in the configured value may be omitted
       for brevity.";
    reference
      "RFC 7308: Extended Administrative Groups in MPLS Traffic
                 Engineering (MPLS-TE)";
  }

  typedef path-attribute-flags {
    type union {
      type identityref {
        base session-attributes-flags;
      }
      type identityref {
        base lsp-attributes-flags;
      }
    }
    description
      "Path attributes flags type.";
  }

  typedef performance-metrics-normality {
    type enumeration {
      enum unknown {
        value 0;
        description
          "Unknown.";
      }
      enum normal {
        value 1;
        description
          "Normal.
          
          Indicates that the anomalous bit is not set.";
      }
      enum abnormal {
        value 2;
        description
          "Abnormal.
          
          Indicates that the anomalous bit is set.";
      }
    }
    description
      "Indicates whether a performance metric is normal (anomalous
       bit not set), abnormal (anomalous bit set), or unknown.";
    reference
      "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
       RFC 7823: Performance-Based Path Selection for Explicitly
                 Routed Label Switched Paths (LSPs) Using TE Metric
                 Extensions
       RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions";
  }

  typedef srlg {
    type uint32;
    description
      "Shared Risk Link Group (SRLG) type.";
    reference
      "RFC 4203: OSPF Extensions in Support of Generalized
                 Multi-Protocol Label Switching (GMPLS)
       RFC 5307: IS-IS Extensions in Support of Generalized
                 Multi-Protocol Label Switching (GMPLS)";
  }

  typedef te-common-status {
    type enumeration {
      enum up {
        description
          "Enabled.";
      }
      enum down {
        description
          "Disabled.";
      }
      enum testing {
        description
          "In some test mode.";
      }
      enum preparing-maintenance {
        description
          "The resource is disabled in the control plane to prepare
           for a graceful shutdown for maintenance purposes.";
        reference
          "RFC 5817: Graceful Shutdown in MPLS and Generalized MPLS
                     Traffic Engineering Networks";
      }
      enum maintenance {
        description
          "The resource is disabled in the data plane for maintenance
           purposes.";
      }
      enum unknown {
        description
          "Status is unknown.";
      }
    }
    description
      "Defines a type representing the common states of a TE
       resource.";
  }

  typedef te-bandwidth {
    type string {
      pattern '0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|'
            + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?'
            + '[pP](\+)?(12[0-7]|'
            + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+'
            + '(,(0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|'
            + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?'
            + '[pP](\+)?(12[0-7]|'
            + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+))*';
    }
    description
      "This is the generic bandwidth type.

       It is a string containing a list of numbers separated by
       commas, where each of these numbers can be non-negative
       decimal, hex integer, or hex float:

       (dec | hex | float)[*(','(dec | hex | float))]

       For the packet-switching type, the string encoding may follow
       the type 'bandwidth-ieee-float32' as defined in RFC 8294
       (e.g., 0x1p10), where the units are in bytes per second.

       Canonically, the string is represented as all lowercase and in
       hex, where the prefix '0x' precedes the hex number.";
    reference
      "RFC 8294: Common YANG Data Types for the Routing Area
       ITU-T G.709: Interfaces for the optical transport network -
                    Edition 6.0 (06/2020)";
  }

  typedef te-ds-class {
    type uint8 {
      range "0..7";
    }
    description
      "The Differentiated Services Class-Type of traffic.";
    reference
      "RFC 4124: Protocol Extensions for Support of Diffserv-aware
                 MPLS Traffic Engineering, Section 4.3.1";
  }

  typedef te-global-id {
    type uint32;
    description
      "An identifier to uniquely identify an operator, which can be
       either a provider or a client.

       The definition of this type is taken from RFCs 6370 and 5003.

       This attribute type is used solely to provide a globally
       unique context for TE topologies.";
    reference
      "RFC 5003: Attachment Individual Identifier (AII) Types for
                 Aggregation
       RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers";
  }

  typedef te-hop-type {
    type enumeration {
      enum loose {
        description
          "A loose hop in an explicit path.";
      }
      enum strict {
        description
          "A strict hop in an explicit path.";
      }
    }
    description
      "Enumerated type for specifying loose or strict paths.";
    reference
      "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                 Section 4.3.3";
  }

  typedef te-link-access-type {
    type enumeration {
      enum point-to-point {
        description
          "The link is point-to-point.";
      }
      enum multi-access {
        description
          "The link is multi-access, including broadcast and NBMA.";
      }
    }
    description
      "Defines a type representing the access type of a TE link.";
    reference
      "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                 Version 2";
  }

  typedef te-label-direction {
    type enumeration {
      enum forward {
        description
          "Label allocated for the forward LSP direction.";
      }
      enum reverse {
        description
          "Label allocated for the reverse LSP direction.";
      }
    }
    description
      "Enumerated type for specifying the forward or reverse
       label.";
  }

  typedef te-link-direction {
    type enumeration {
      enum incoming {
        description
          "The explicit route represents an incoming link on
           a node.";
      }
      enum outgoing {
        description
          "The explicit route represents an outgoing link on
           a node.";
      }
    }
    description
      "Enumerated type for specifying the direction of a link on
       a node.";
  }

  typedef te-metric {
    type uint32;
    description
      "Traffic Engineering (TE)  metric.";
    reference
      "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                 Version 2, Section 2.5.5
       RFC 5305: IS-IS Extensions for Traffic Engineering,
                 Section 3.7";
  }

  typedef te-node-id {
    type union {
      type yang:dotted-quad;
      type inet:ipv6-address-no-zone;
    }
    description
      "A type representing the identifier for a node in a TE
       topology.

       The identifier is represented either as 4 octets in
       dotted-quad notation, or as 16 octets in full, mixed,
       shortened, or shortened-mixed IPv6 address notation.

       This attribute MAY be mapped to the Router Address TLV
       described in Section 2.4.1 of RFC 3630, the TE Router ID
       described in Section 3 of RFC 6827, the Traffic Engineering
       Router ID TLV described in Section 4.3 of RFC 5305, the TE
       Router ID TLV described in Section 3.2.1 of RFC 6119, or the
       IPv6 TE Router ID TLV described in Section 4.1 of RFC 6119.

       The reachability of such a TE node MAY be achieved by a
       mechanism such as that described in Section 6.2 of RFC 6827.";
    reference
      "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                 Version 2, Section 2.4.1
       RFC 5305: IS-IS Extensions for Traffic Engineering,
                 Section 4.3
       RFC 6119: IPv6 Traffic Engineering in IS-IS, Section 3.2.1
       RFC 6827: Automatically Switched Optical Network (ASON)
                 Routing for OSPFv2 Protocols, Section 3";
  }

  typedef te-oper-status {
    type te-common-status;
    description
      "Defines a type representing the operational status of
       a TE resource.";
  }

  typedef te-admin-status {
    type te-common-status;
    description
      "Defines a type representing the administrative status of
       a TE resource.";
  }

  typedef te-path-disjointness {
    type bits {
      bit node {
        position 0;
        description
          "Node disjoint.";
      }
      bit link {
        position 1;
        description
          "Link disjoint.";
      }
      bit srlg {
        position 2;
        description
          "Shared Risk Link Group (SRLG) disjoint.";
      }
    }
    description
      "Type of the resource disjointness for a TE tunnel path.";
    reference
      "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                 Generalized Multi-Protocol Label Switching (GMPLS)
                 Recovery";
  }

  typedef te-recovery-status {
    type enumeration {
      enum normal {
        description
          "Both the recovery span and the working span are fully
           allocated and active, data traffic is being
           transported over (or selected from) the working
           span, and no trigger events are reported.";
      }
      enum recovery-started {
        description
          "The recovery action has been started but not completed.";
      }
      enum recovery-succeeded {
        description
          "The recovery action has succeeded.

           The working span has reported a failure/degrade condition,
           and the user traffic is being transported (or selected)
           on the recovery span.";
      }
      enum recovery-failed {
        description
          "The recovery action has failed.";
      }
      enum reversion-started {
        description
          "The reversion has started.";
      }
      enum reversion-succeeded {
        description
          "The reversion action has succeeded.";
      }
      enum reversion-failed {
        description
          "The reversion has failed.";
      }
      enum recovery-unavailable {
        description
          "The recovery is unavailable, as a result of either an
           operator's lockout command or a failure condition
           detected on the recovery span.";
      }
      enum recovery-admin {
        description
          "The operator has issued a command to switch the user
           traffic to the recovery span.";
      }
      enum wait-to-restore {
        description
          "The recovery domain is recovering from a failure/degrade
           condition on the working span that is being controlled by
           the Wait-to-Restore (WTR) timer.";
      }
    }
    description
      "Defines the status of a recovery action.";
    reference
      "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
       RFC 4427: Recovery (Protection and Restoration) Terminology
                 for Generalized Multi-Protocol Label Switching
                 (GMPLS)";
  }

  typedef te-template-name {
    type string {
      pattern '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*';
    }
    description
      "A type for the name of a TE node template or TE link
       template.";
  }

  typedef te-topology-event-type {
    type enumeration {
      enum add {
        value 0;
        description
          "A TE node or TE link has been added.";
      }
      enum remove {
        value 1;
        description
          "A TE node or TE link has been removed.";
      }
      enum update {
        value 2;
        description
          "A TE node or TE link has been updated.";
      }
    }
    description
      "TE event type for notifications.";
  }

  typedef te-topology-id {
    type union {
      type string {
        length "0";
        // empty string
      }
      type string {
        pattern '([a-zA-Z0-9\-_.]+:)*'
              + '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*';
      }
    }
    description
      "An identifier for a topology.

       It is optional to have one or more prefixes at the beginning,
       separated by colons.
       
       The prefixes can be 'network-types' as defined in the
       'ietf-network' module in RFC 8345, to help the user better
       understand the topology before further inquiry is made.";
    reference
      "RFC 8345: A YANG Data Model for Network Topologies";
  }

  typedef te-tp-id {
    type union {
      type uint32;
      // Unnumbered
      type inet:ip-address;
      // IPv4 or IPv6 address
    }
    description
      "An identifier for a TE link endpoint on a node.

       This attribute is mapped to a local or remote link identifier
       as defined in RFCs 3630 and 5305.";
    reference
      "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                 Version 2
       RFC 5305: IS-IS Extensions for Traffic Engineering";
  }

  typedef path-type {
    type enumeration {
      enum primary-path {
        description
          "Indicates that the TE path is a primary path.";
      }
      enum secondary-path {
        description
          "Indicates that the TE path is a secondary path.";
      }
      enum primary-reverse-path {
        description
          "Indicates that the TE path is a primary reverse path.";
      }
      enum secondary-reverse-path {
        description
          "Indicates that the TE path is a secondary reverse path.";
      }
    }
    description
      "The type of TE path, indicating whether a path is a primary, 
       or a reverse primary, or a secondary, or a reverse secondary 
       path.";
  }

  /* TE features */

  feature p2mp-te {
    description
      "Indicates support for Point-to-Multipoint TE (P2MP-TE).";
    reference
      "RFC 4875: Extensions to Resource Reservation Protocol -
                 Traffic Engineering (RSVP-TE) for
                 Point-to-Multipoint TE Label Switched Paths (LSPs)";
  }

  feature frr-te {
    description
      "Indicates support for TE Fast Reroute (FRR).";
    reference
      "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels";
  }

  feature extended-admin-groups {
    description
      "Indicates support for TE link extended administrative
       groups.";
    reference
      "RFC 7308: Extended Administrative Groups in MPLS Traffic
                 Engineering (MPLS-TE)";
  }

  feature named-path-affinities {
    description
      "Indicates support for named path affinities.";
  }

  feature named-extended-admin-groups {
    description
      "Indicates support for named extended administrative groups.";
  }

  feature named-srlg-groups {
    description
      "Indicates support for named Shared Risk Link Group (SRLG).";
  }

  feature named-path-constraints {
    description
      "Indicates support for named path constraints.";
  }

  feature path-optimization-metric {
    description
      "Indicates support for path optimization metrics.";
  }

  feature path-optimization-objective-function {
    description
      "Indicates support for path optimization objective functions.";
  }

  /*
   * Identities
   */

  identity lsp-provisioning-error-reason {
    description
      "Base identity for LSP provisioning errors.";
  }

  identity session-attributes-flags {
    description
      "Base identity for the RSVP-TE session attributes flags.";
  }

    identity local-protection-desired {
      base session-attributes-flags;
      description
        "Local protection is desired.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                   Section 4.7.1";
    }

    identity se-style-desired {
      base session-attributes-flags;
      description
        "Shared explicit style, to allow the LSP to be established
         and share resources with the old LSP.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
    }

    identity local-recording-desired {
      base session-attributes-flags;
      description
        "Label recording is desired.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                   Section 4.7.1";
    }

    identity bandwidth-protection-desired {
      base session-attributes-flags;
      description
        "Requests FRR bandwidth protection on LSRs, if present.";
      reference
        "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                   Tunnels";
    }

    identity node-protection-desired {
      base session-attributes-flags;
      description
        "Requests FRR node protection on LSRs, if present.";
      reference
        "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                   Tunnels";
    }

    identity path-reevaluation-request {
      base session-attributes-flags;
      description
        "This flag indicates that a path re-evaluation (of the
         current path in use) is requested.
         
         Note that this does not trigger any LSP reroutes but
         instead just signals a request to evaluate whether a
         preferable path exists.";
      reference
        "RFC 4736: Reoptimization of Multiprotocol Label Switching
                  (MPLS) Traffic Engineering (TE) Loosely Routed
                  Label Switched Path (LSP)";
    }

    identity soft-preemption-desired {
      base session-attributes-flags;
      description
        "Soft preemption of LSP resources is desired.";
      reference
        "RFC 5712: MPLS Traffic Engineering Soft Preemption";
    }

  identity lsp-attributes-flags {
    description
      "Base identity for LSP attributes flags.";
  }

    identity end-to-end-rerouting-desired {
      base lsp-attributes-flags;
      description
        "Indicates end-to-end rerouting behavior for an LSP
         undergoing establishment.
         
         This MAY also be used to specify the behavior of end-to-end
         LSP recovery for established LSPs.";
      reference
        "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
                   RSVP-TE
         RFC 5420: Encoding of Attributes for MPLS LSP Establishment
                   Using Resource Reservation Protocol Traffic
                   Engineering (RSVP-TE)
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity boundary-rerouting-desired {
      base lsp-attributes-flags;
      description
        "Indicates boundary rerouting behavior for an LSP undergoing
         establishment.
         
         This MAY also be used to specify segment-based LSP recovery
         through nested crankback for established LSPs.
         
         The boundary Area Border Router (ABR) / Autonomous System
         Border Router (ASBR) can decide to forward the PathErr
         message upstream to either an upstream boundary ABR/ASBR or
         the ingress LSR.
         
         Alternatively, it can try to select another egress boundary
         LSR.";
      reference
        "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
                   RSVP-TE
         RFC 5420: Encoding of Attributes for MPLS LSP Establishment
                   Using Resource Reservation Protocol Traffic
                   Engineering (RSVP-TE)
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity segment-based-rerouting-desired {
      base lsp-attributes-flags;
      description
        "Indicates segment-based rerouting behavior for an LSP
         undergoing establishment.
         
         This MAY also be used to specify segment-based LSP recovery
         for established LSPs.";
      reference
        "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS
                   RSVP-TE
         RFC 5420: Encoding of Attributes for MPLS LSP Establishment
                   Using Resource Reservation Protocol
                   Traffic Engineering (RSVP-TE)
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity lsp-integrity-required {
      base lsp-attributes-flags;
      description
        "Indicates that LSP integrity is required.";
      reference
        "RFC 4875: Extensions to Resource Reservation Protocol -
                   Traffic Engineering (RSVP-TE) for
                   Point-to-Multipoint TE Label Switched Paths (LSPs)
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity contiguous-lsp-desired {
      base lsp-attributes-flags;
      description
        "Indicates that a contiguous LSP is desired.";
      reference
        "RFC 5151: Inter-Domain MPLS and GMPLS Traffic Engineering --
                   Resource Reservation Protocol-Traffic Engineering
                   (RSVP-TE) Extensions
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity lsp-stitching-desired {
      base lsp-attributes-flags;
      description
        "Indicates that LSP stitching is desired.";
      reference
        "RFC 5150: Label Switched Path Stitching with Generalized
                   Multiprotocol Label Switching Traffic Engineering
                   (GMPLS TE)
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity pre-planned-lsp-flag {
      base lsp-attributes-flags;
      description
        "Indicates that the LSP MUST be provisioned in the
         control plane only.";
      reference
        "RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for
                   Multi-Layer and Multi-Region Networks (MLN/MRN)
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity non-php-behavior-flag {
      base lsp-attributes-flags;
      description
        "Indicates that non-PHP (non-Penultimate Hop Popping)
         behavior for the LSP is desired.";
      reference
        "RFC 6511: Non-Penultimate Hop Popping Behavior and
                   Out-of-Band Mapping for RSVP-TE Label Switched
                   Paths
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity oob-mapping-flag {
      base lsp-attributes-flags;
      description
        "Indicates that signaling of the egress binding information
         is out of band (e.g., via the Border Gateway Protocol
         (BGP)).";
      reference
        "RFC 6511: Non-Penultimate Hop Popping Behavior and
                   Out-of-Band Mapping for RSVP-TE Label Switched
                   Paths
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity entropy-label-capability {
      base lsp-attributes-flags;
      description
        "Indicates entropy label capability.";
      reference
        "RFC 6790: The Use of Entropy Labels in MPLS Forwarding
         RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)";
    }

    identity oam-mep-entity-desired {
      base lsp-attributes-flags;
      description
        "OAM Maintenance Entity Group End Point (MEP) entities
         desired.";
      reference
        "RFC 7260: GMPLS RSVP-TE Extensions for Operations,
                   Administration, and Maintenance (OAM)
                   Configuration";
    }

    identity oam-mip-entity-desired {
      base lsp-attributes-flags;
      description
        "OAM Maintenance Entity Group Intermediate Points (MIP)
         entities desired.";
      reference
        "RFC 7260: GMPLS RSVP-TE Extensions for Operations,
                   Administration, and Maintenance (OAM)
                   Configuration";
    }

    identity srlg-collection-desired {
      base lsp-attributes-flags;
      description
        "Shared Risk Link Group (SRLG) collection desired.";
      reference
        "RFC 7570: Label Switched Path (LSP) Attribute in the
                   Explicit Route Object (ERO)
         RFC 8001: RSVP-TE Extensions for Collecting Shared Risk
                   Link Group (SRLG) Information";
    }

    identity loopback-desired {
      base lsp-attributes-flags;
      description
        "This flag indicates that a particular node on the LSP is
         required to enter loopback mode.
         
         This can also be used to specify the loopback state of the
         node.";
      reference
        "RFC 7571: GMPLS RSVP-TE Extensions for Lock Instruct and
                   Loopback";
    }

    identity p2mp-te-tree-eval-request {
      base lsp-attributes-flags;
      description
        "P2MP-TE tree re-evaluation request.";
      reference
        "RFC 8149: RSVP Extensions for Reoptimization of Loosely
                   Routed Point-to-Multipoint Traffic Engineering
                   Label Switched Paths (LSPs)";
    }

    identity rtm-set-desired {
      base lsp-attributes-flags;
      description
        "Residence Time Measurement (RTM) attribute flag requested.";
      reference
        "RFC 8169: Residence Time Measurement in MPLS Networks";
    }

  identity link-protection-type {
    description
      "Base identity for the link protection type.";
  }

    identity link-protection-unprotected {
      base link-protection-type;
      description
        "Unprotected link type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity link-protection-extra-traffic {
      base link-protection-type;
      description
        "Extra-Traffic protected link type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity link-protection-shared {
      base link-protection-type;
      description
        "Shared protected link type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity link-protection-1-for-1 {
      base link-protection-type;
      description
        "One-for-one (1:1) protected link type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity link-protection-1-plus-1 {
      base link-protection-type;
      description
        "One-plus-one (1+1) protected link type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity link-protection-enhanced {
      base link-protection-type;
      description
        "A compound link protection type derived from the underlay
         TE tunnel protection configuration supporting the TE link.";
    }

  identity association-type {
    description
      "Base identity for the tunnel association.";
  }

    identity association-type-recovery {
      base association-type;
      description
        "Association type for recovery, used to associate LSPs of the
         same tunnel for recovery.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery
         RFC 6780: RSVP ASSOCIATION Object Extensions";
    }

    identity association-type-resource-sharing {
      base association-type;
      description
        "Association type for resource sharing, used to enable
         resource sharing during make-before-break.";
      reference
        "RFC 4873: GMPLS Segment Recovery
         RFC 6780: RSVP ASSOCIATION Object Extensions";
    }

    identity association-type-double-sided-bidir {
      base association-type;
      description
        "Association type for double-sided bidirectional LSPs,
         used to associate two LSPs of two tunnels that are
         independently configured on either endpoint.";
      reference
        "RFC 7551: RSVP-TE Extensions for Associated Bidirectional
                   Label Switched Paths (LSPs)";
    }

    identity association-type-single-sided-bidir {
      base association-type;
      description
        "Association type for single-sided bidirectional LSPs,
         used to associate two LSPs of two tunnels, where one
         tunnel is configured on one side/endpoint and the other
         tunnel is dynamically created on the other endpoint.";
      reference
        "RFC 6780: RSVP ASSOCIATION Object Extensions
         RFC 7551: RSVP-TE Extensions for Associated Bidirectional
                   Label Switched Paths (LSPs)";
    }

    identity association-type-diversity {
      base association-type;
      description
        "Association Type diversity used to associate LSPs whose
         paths are to be diverse from each other.";
      reference
        "RFC 8800: Path Computation Element Communication Protocol
                   (PCEP) Extension for Label Switched Path (LSP)
                   Diversity Constraint Signaling";
    }

  identity objective-function-type {
    description
      "Base identity for path objective function types.";
  }

    identity of-minimize-cost-path {
      base objective-function-type;
      description
        "Objective function for minimizing path cost.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity of-minimize-load-path {
      base objective-function-type;
      description
        "Objective function for minimizing the load on one or more
         paths.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity of-maximize-residual-bandwidth {
      base objective-function-type;
      description
        "Objective function for maximizing residual bandwidth.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity of-minimize-agg-bandwidth-consumption {
      base objective-function-type;
      status obsolete;
      description
        "Objective function for minimizing aggregate bandwidth
         consumption.
        
         This identity has been obsoleted: the
         'svec-of-minimize-agg-bandwidth-consumption' identity SHOULD
         be used instead.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity of-minimize-load-most-loaded-link {
      base objective-function-type;
      status obsolete;
      description
        "Objective function for minimizing the load on the link that
         is carrying the highest load.
        
         This identity has been obsoleted: the
         'svec-of-minimize-load-most-loaded-link' identity SHOULD
         be used instead.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity of-minimize-cost-path-set {
      base objective-function-type;
      status obsolete;
      description
        "Objective function for minimizing the cost on a path set.
        
         This identity has been obsoleted: the
         'svec-of-minimize-cost-path-set' identity SHOULD
         be used instead.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

  identity path-computation-method {
    description
      "Base identity for supported path computation mechanisms.";
  }

    identity path-locally-computed {
      base path-computation-method;
      description
        "Indicates a constrained-path LSP in which the
         path is computed by the local LER.";
      reference
        "RFC 9522: Overview and Principles of Internet Traffic
                   Engineering, Section 4.4";
    }

    identity path-externally-queried {
      base path-computation-method;
      description
        "Constrained-path LSP in which the path is obtained by
         querying an external source, such as a PCE server.
         In the case that an LSP is defined to be externally queried,
         it may also have associated explicit definitions (provided
         to the external source to aid computation).
         
         The path that is returned by the external source may
         require further local computation on the device.";
      reference
        "RFC 9522: Overview and Principles of Internet Traffic
                   Engineering
         RFC 4657: Path Computation Element (PCE) Communication
                   Protocol Generic Requirements";
    }

    identity path-explicitly-defined {
      base path-computation-method;
      description
        "Constrained-path LSP in which the path is
         explicitly specified as a collection of strict and/or loose
         hops.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
         RFC 9522: Overview and Principles of Internet Traffic
                   Engineering";
    }

  identity lsp-metric-type {
    description
      "Base identity for the LSP metric specification types.";
  }

    identity lsp-metric-relative {
      base lsp-metric-type;
      description
        "The metric specified for the LSPs to which this identity
         refers is specified as a value relative to the IGP metric
         cost to the LSP's tail end.";
      reference
        "RFC 4657: Path Computation Element (PCE) Communication
                   Protocol Generic Requirements";
    }

    identity lsp-metric-absolute {
      base lsp-metric-type;
      description
        "The metric specified for the LSPs to which this identity
         refers is specified as an absolute value.";
      reference
        "RFC 4657: Path Computation Element (PCE) Communication
                   Protocol Generic Requirements";
    }

    identity lsp-metric-inherited {
      base lsp-metric-type;
      description
        "The metric for the LSPs to which this identity refers is
         not specified explicitly; rather, it is directly inherited
         from the IGP cost.";
      reference
        "RFC 4657: Path Computation Element (PCE) Communication
                   Protocol Generic Requirements";
    }

  identity te-tunnel-type {
    description
      "Base identity from which specific tunnel types are derived.";
  }

    identity te-tunnel-p2p {
      base te-tunnel-type;
      description
        "TE Point-to-Point (P2P) tunnel type.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
    }

    identity te-tunnel-p2mp {
      base te-tunnel-type;
      description
        "TE P2MP tunnel type.";
      reference
        "RFC 4875: Extensions to Resource Reservation Protocol -
                   Traffic Engineering (RSVP-TE) for
                   Point-to-Multipoint TE Label Switched Paths
                   (LSPs)";
    }

  identity tunnel-action-type {
    description
      "Base identity from which specific tunnel action types
       are derived.";
  }

    identity tunnel-action-resetup {
      base tunnel-action-type;
      description
        "TE tunnel action that tears down the tunnel's current LSP
         (if any) and attempts to re-establish a new LSP.";
    }

    identity tunnel-action-reoptimize {
      base tunnel-action-type;
      description
        "TE tunnel action that reoptimizes the placement of the
         tunnel LSP(s).";
    }

    identity tunnel-action-switchpath {
      base tunnel-action-type;
      description
        "TE tunnel action that switches the tunnel's LSP to use the
         specified path.";
    }

  identity te-action-result {
    description
      "Base identity from which specific TE action results
       are derived.";
  }

    identity te-action-success {
      base te-action-result;
      description
        "TE action was successful.";
    }

    identity te-action-fail {
      base te-action-result;
      description
        "TE action failed.";
    }

    identity tunnel-action-inprogress {
      base te-action-result;
      description
        "TE action is in progress.";
    }

  identity tunnel-admin-state-type {
    description
      "Base identity for TE tunnel administrative states.";
  }

    identity tunnel-admin-state-up {
      base tunnel-admin-state-type;
      description
        "Tunnel's administrative state is up.";
    }

    identity tunnel-admin-state-down {
      base tunnel-admin-state-type;
      description
        "Tunnel's administrative state is down.";
    }

    identity tunnel-admin-state-auto {
      base tunnel-admin-state-type;
      description
        "Tunnel administrative auto state. The administrative status
         in state datastore transitions to 'tunnel-admin-up' when the
         tunnel used by the client layer, and to 'tunnel-admin-down'
         when it is not used by the client layer.";
    }

  identity tunnel-state-type {
    description
      "Base identity for TE tunnel states.";
  }

    identity tunnel-state-up {
      base tunnel-state-type;
      description
        "Tunnel's state is up.";
    }

    identity tunnel-state-down {
      base tunnel-state-type;
      description
        "Tunnel's state is down.";
    }

  identity lsp-state-type {
    description
      "Base identity for TE LSP states.";
  }

    identity lsp-path-computing {
      base lsp-state-type;
      description
        "State path computation is in progress.";
    }

    identity lsp-path-computation-ok {
      base lsp-state-type;
      description
        "State path computation was successful.";
    }

    identity lsp-path-computation-failed {
      base lsp-state-type;
      description
        "State path computation failed.";
    }

    identity lsp-state-setting-up {
      base lsp-state-type;
      description
        "State is being set up.";
    }

    identity lsp-state-setup-ok {
      base lsp-state-type;
      description
        "State setup was successful.";
    }

    identity lsp-state-setup-failed {
      base lsp-state-type;
      description
        "State setup failed.";
    }

    identity lsp-state-up {
      base lsp-state-type;
      description
        "State is up.";
    }

    identity lsp-state-tearing-down {
      base lsp-state-type;
      description
        "State is being torn down.";
    }

    identity lsp-state-down {
      base lsp-state-type;
      description
        "State is down.";
    }

  identity path-invalidation-action-type {
    description
      "Base identity for TE path invalidation action types.";
  }

    identity path-invalidation-action-drop {
      base path-invalidation-action-type;
      description
        "Upon invalidation of the TE tunnel path, the tunnel remains
         valid, but any packet mapped over the tunnel is dropped.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                   Section 2.5";
    }

    identity path-invalidation-action-teardown {
      base path-invalidation-action-type;
      description
        "TE path invalidation action teardown.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                   Section 2.5";
    }

  identity lsp-restoration-type {
    description
      "Base identity from which LSP restoration types are derived.";
  }

    identity lsp-restoration-restore-none {
      base lsp-restoration-type;
      description
        "No LSP affected by a failure is restored.";
    }

    identity lsp-restoration-restore-any {
      base lsp-restoration-type;
      description
        "Any LSP affected by a failure is restored.";
    }

    identity lsp-restoration-restore-all {
      base lsp-restoration-type;
      description
        "Affected LSPs are restored after all LSPs of the tunnel are
         broken.";
    }

  identity restoration-scheme-type {
    description
      "Base identity for LSP restoration schemes.";
  }

    identity restoration-scheme-rerouting {
      base restoration-scheme-type;
      description
        "Restoration LSP is computed, signalled and configured after
         the failure detection.
        
         This restoration scheme is also known as
         'Full LSP Re-routing', with the alternate route being
         computed after the failure occurs.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity restoration-scheme-preconfigured {
      base restoration-scheme-type;
      description
        "Restoration LSP is precomputed, presignalled and
         preconfigured prior to the failure.";
    }

    identity restoration-scheme-precomputed {
      base restoration-scheme-type;
      description
        "Restoration LSP is precomputed, but not presignalled nor
         preconfigured, prior to the failure.
        
         This restoration scheme is also known as
         'Full LSP Re-routing', with the alternate route being
         pre-computed and stored for use when the failure occurs.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity restoration-scheme-presignaled {
      base restoration-scheme-type;
      description
        "Restoration LSP is presignaled, but not preconfigured,
         prior to the failure.
         
         This restoration scheme is also known as
         'Pre-planned LSP Re-routing'.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

  identity lsp-protection-type {
    description
      "Base identity from which LSP protection types are derived.";
    reference
      "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                  Generalized Multi-Protocol Label Switching (GMPLS)
                  Recovery";
  }

    identity lsp-protection-unprotected {
      base lsp-protection-type;
      description
        "'Unprotected' LSP protection type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity lsp-protection-reroute-extra {
      base lsp-protection-type;
      status obsolete;
      description
        "'(Full) Rerouting' LSP protection type.
        
         This identity has been obsoleted: the
         'restoration-scheme-rerouting' identity SHOULD be used
         instead.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity lsp-protection-reroute {
      base lsp-protection-type;
      status obsolete;
      description
        "'Rerouting without Extra-Traffic' LSP protection type.
        
         This identity has been obsoleted: the
         'restoration-scheme-rerouting' identity SHOULD be used
         instead.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity lsp-protection-1-for-n {
      base lsp-protection-type;
      description
        "'1:N Protection with Extra-Traffic' LSP protection type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity lsp-protection-1-for-1 {
      base lsp-protection-type;
      description
        "LSP protection '1:1 Protection Type'.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity lsp-protection-unidir-1-plus-1 {
      base lsp-protection-type;
      description
        "'1+1 Unidirectional Protection' LSP protection type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity lsp-protection-bidir-1-plus-1 {
      base lsp-protection-type;
      description
        "'1+1 Bidirectional Protection' LSP protection type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

    identity lsp-protection-extra-traffic {
      base lsp-protection-type;
      description
        "Extra-Traffic LSP protection type.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery";
    }

  identity lsp-protection-state {
    description
      "Base identity of protection states for reporting purposes.";
  }

    identity normal {
      base lsp-protection-state;
      description
        "Normal state.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity signal-fail-of-protection {
      base lsp-protection-state;
      description
        "The protection transport entity has a signal fail condition
         that is of higher priority than the forced switchover
         command.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity lockout-of-protection {
      base lsp-protection-state;
      description
        "A Loss of Protection (LoP) command is active.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity forced-switch {
      base lsp-protection-state;
      description
        "A forced switchover command is active.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity signal-fail {
      base lsp-protection-state;
      description
        "There is a signal fail condition on either the working path
         or the protection path.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity signal-degrade {
      base lsp-protection-state;
      description
        "There is a signal degrade condition on either the working
         path or the protection path.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity manual-switch {
      base lsp-protection-state;
      description
        "A manual switchover command is active.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity wait-to-restore {
      base lsp-protection-state;
      description
        "A Wait-to-Restore (WTR) timer is running.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity do-not-revert {
      base lsp-protection-state;
      description
        "A Do Not Revert (DNR) condition is active because of
         non-revertive behavior.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity failure-of-protocol {
      base lsp-protection-state;
      description
        "LSP protection is not working because of a protocol failure
         condition.";
      reference
        "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection
                   to Match the Operational Expectations of
                   Synchronous Digital Hierarchy, Optical Transport
                   Network, and Ethernet Transport Network Operators
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

  identity protection-external-commands {
    description
      "Base identity from which protection-related external commands
       used for troubleshooting purposes are derived.";
  }

    identity action-freeze {
      base protection-external-commands;
      description
        "A temporary configuration action initiated by an operator
         command that prevents any switchover action from being taken
         and, as such, freezes the current state.";
      reference
        "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection
                   to Match the Operational Expectations of
                   Synchronous Digital Hierarchy, Optical Transport
                   Network, and Ethernet Transport Network Operators
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity clear-freeze {
      base protection-external-commands;
      description
        "An action that clears the active freeze state.";
      reference
        "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection
                   to Match the Operational Expectations of
                   Synchronous Digital Hierarchy, Optical Transport
                   Network, and Ethernet Transport Network Operators
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity action-lockout-of-normal {
      base protection-external-commands;
      description
        "A temporary configuration action initiated by an operator
         command to ensure that the normal traffic is not allowed
         to use the protection transport entity.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity clear-lockout-of-normal {
      base protection-external-commands;
      description
        "An action that clears the active lockout of the
         normal state.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity action-lockout-of-protection {
      base protection-external-commands;
      description
        "A temporary configuration action initiated by an operator
         command to ensure that the protection transport entity is
         temporarily not available to transport a traffic signal
         (either normal or Extra-Traffic).";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity action-forced-switch {
      base protection-external-commands;
      description
        "A switchover action initiated by an operator command to
         switch the Extra-Traffic signal, the normal traffic signal,
         or the null signal to the protection transport entity,
         unless a switchover command of equal or higher priority is
         in effect.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity action-manual-switch {
      base protection-external-commands;
      description
        "A switchover action initiated by an operator command to
         switch the Extra-Traffic signal, the normal traffic signal,
         or the null signal to the protection transport entity,
         unless a fault condition exists on other transport entities
         or a switchover command of equal or higher priority is in
         effect.";
      reference
        "RFC 4872: RSVP-TE Extensions in Support of End-to-End
                   Generalized Multi-Protocol Label Switching (GMPLS)
                   Recovery
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity action-exercise {
      base protection-external-commands;
      description
        "An action that starts testing whether or not Automatic 
        Protection Switching (APS) communication is operating 
        correctly.
        
        It is of lower priority than any other state or command.";
      reference
        "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection
                   to Match the Operational Expectations of
                   Synchronous Digital Hierarchy, Optical Transport
                   Network, and Ethernet Transport Network Operators
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

    identity clear {
      base protection-external-commands;
      description
        "An action that clears the active near-end lockout of a
         protection, forced switchover, manual switchover,
         Wait-to-Restore (WTR) state, or exercise command.";
      reference
        "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection
         RFC 4427: Recovery (Protection and Restoration) Terminology
                   for Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }

  identity switching-capabilities {
    description
      "Base identity for interface switching capabilities.";
    reference
      "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                 Signaling Functional Description";
  }

    identity switching-psc1 {
      base switching-capabilities;
      description
        "Packet-Switch Capable-1 (PSC-1).";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity switching-evpl {
      base switching-capabilities;
      description
        "Ethernet Virtual Private Line (EVPL).";
      reference
        "RFC 6004: Generalized MPLS (GMPLS) Support for Metro
                   Ethernet Forum and G.8011 Ethernet Service
                   Switching";
    }

    identity switching-l2sc {
      base switching-capabilities;
      description
        "Layer-2 Switch Capable (L2SC).";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity switching-tdm {
      base switching-capabilities;
      description
        "Time-Division-Multiplex Capable (TDM).";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity switching-otn {
      base switching-capabilities;
      description
        "OTN-TDM capable.";
      reference
        "RFC 7138: Traffic Engineering Extensions to OSPF for GMPLS
                   Control of Evolving G.709 Optical Transport
                   Networks";
    }

    identity switching-dcsc {
      base switching-capabilities;
      description
        "Data Channel Switching Capable (DCSC).";
      reference
        "RFC 6002: Generalized MPLS (GMPLS) Data Channel
                   Switching Capable (DCSC) and Channel Set Label
                   Extensions";
    }

    identity switching-lsc {
      base switching-capabilities;
      description
        "Lambda-Switch Capable (LSC).";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity switching-fsc {
      base switching-capabilities;
      description
        "Fiber-Switch Capable (FSC).";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

  identity lsp-encoding-types {
    description
      "Base identity for encoding types.";
    reference
      "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                 Signaling Functional Description";
  }

    identity lsp-encoding-packet {
      base lsp-encoding-types;
      description
        "Packet LSP encoding.";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity lsp-encoding-ethernet {
      base lsp-encoding-types;
      description
        "Ethernet LSP encoding.";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity lsp-encoding-pdh {
      base lsp-encoding-types;
      description
        "ANSI/ETSI PDH LSP encoding.";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity lsp-encoding-sdh {
      base lsp-encoding-types;
      description
        "SDH ITU-T G.707 / SONET ANSI T1.105 LSP encoding.";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity lsp-encoding-digital-wrapper {
      base lsp-encoding-types;
      description
        "Digital Wrapper LSP encoding.";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity lsp-encoding-lambda {
      base lsp-encoding-types;
      description
        "Lambda (photonic) LSP encoding.";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity lsp-encoding-fiber {
      base lsp-encoding-types;
      description
        "Fiber LSP encoding.";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity lsp-encoding-fiber-channel {
      base lsp-encoding-types;
      description
        "FiberChannel LSP encoding.";
      reference
        "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Functional Description";
    }

    identity lsp-encoding-oduk {
      base lsp-encoding-types;
      description
        "G.709 ODUk (Digital Path) LSP encoding.";
      reference
        "RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Extensions for G.709 Optical Transport
                   Networks Control";
    }

    identity lsp-encoding-optical-channel {
      base lsp-encoding-types;
      description
        "G.709 Optical Channel LSP encoding.";
      reference
        "RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS)
                   Signaling Extensions for G.709 Optical Transport
                   Networks Control";
    }

    identity lsp-encoding-line {
      base lsp-encoding-types;
      description
        "Line (e.g., 8B/10B) LSP encoding.";
      reference
        "RFC 6004: Generalized MPLS (GMPLS) Support for Metro
                   Ethernet Forum and G.8011 Ethernet Service
                   Switching";
    }

  identity path-signaling-type {
    description
      "Base identity from which specific LSP path setup types
       are derived.";
  }

    identity path-setup-static {
      base path-signaling-type;
      description
        "Static LSP provisioning path setup.";
    }

    identity path-setup-rsvp {
      base path-signaling-type;
      description
        "RSVP-TE signaling path setup.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
    }

    identity path-setup-sr {
      base path-signaling-type;
      description
        "Segment-routing path setup.";
    }

  identity path-scope-type {
    description
      "Base identity from which specific path scope types are
       derived.";
  }

    identity path-scope-segment {
      base path-scope-type;
      description
        "Path scope segment.";
      reference
        "RFC 4873: GMPLS Segment Recovery";
    }

    identity path-scope-end-to-end {
      base path-scope-type;
      description
        "Path scope end to end.";
      reference
        "RFC 4873: GMPLS Segment Recovery";
    }

  identity route-usage-type {
    description
      "Base identity for route usage.";
  }

    identity route-include-object {
      base route-usage-type;
      description
        "'Include route' object.";
    }

    identity route-exclude-object {
      base route-usage-type;
      description
        "'Exclude route' object.";
      reference
        "RFC 4874: Exclude Routes - Extension to Resource ReserVation
                   Protocol-Traffic Engineering (RSVP-TE)";
    }

    identity route-exclude-srlg {
      base route-usage-type;
      description
        "Excludes Shared Risk Link Groups (SRLGs).";
      reference
        "RFC 4874: Exclude Routes - Extension to Resource ReserVation
                   Protocol-Traffic Engineering (RSVP-TE)";
    }

  identity path-metric-optimization-type {
    description
      "Base identity used to define the path metric optimization
       types.";
  }

  identity link-path-metric-type {
    description
      "Base identity used to define the link and the path metric
       types.
      
       The unit of the path metric value is interpreted in the
       context of the path metric type and the derived identities
       SHOULD describe the unit of the path metric types they
       define.";
  }

    identity link-metric-type {
      base link-path-metric-type;
      description
        "Base identity for the link metric types.";
    }

      identity link-metric-te {
        base link-metric-type;
        description
          "Traffic Engineering (TE) Link Metric.";
        reference
          "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                     Version 2, Section 2.5.5
           RFC 5305: IS-IS Extensions for Traffic Engineering,
                     Section 3.7";
      }

      identity link-metric-igp {
        base link-metric-type;
        description
          "Interior Gateway Protocol (IGP) Link Metric.";
        reference
          "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric
                     as a second MPLS Traffic Engineering (TE)
                     Metric";
      }

      identity link-metric-delay-average {
        base link-metric-type;
        description
          "Unidirectional Link Delay, measured in units of
           microseconds.";
        reference
          "RFC 7471: OSPF Traffic Engineering (TE) Metric
                     Extensions, Section 4.1        
           RFC 8570: IS-IS Traffic Engineering (TE) Metric
                     Extensions, Section 4.1";
      }

      identity link-metric-delay-minimum {
        base link-metric-type;
        description
          "Minimum unidirectional Link Delay, measured in units of
           microseconds.";
        reference
          "RFC 7471: OSPF Traffic Engineering (TE) Metric
                     Extensions, Section 4.2
           RFC 8570: IS-IS Traffic Engineering (TE) Metric
                     Extensions, Section 4.2";
      }

      identity link-metric-delay-maximum {
        base link-metric-type;
        description
          "Maximum unidirectional Link Delay, measured in units of
           microseconds.";
        reference
          "RFC 7471: OSPF Traffic Engineering (TE) Metric
                     Extensions, Section 4.2
           RFC 8570: IS-IS Traffic Engineering (TE) Metric
                     Extensions, Section 4.2";
      }

      identity link-metric-residual-bandwidth {
        base link-metric-type;
        description
          "Unidirectional Residual Bandwidth, measured in units of
           bytes per second.
          
           It is defined to be Maximum Bandwidth minus the bandwidth
           currently allocated to LSPs.";
        reference
          "RFC 7471: OSPF Traffic Engineering (TE) Metric
                     Extensions, Section 4.5
           RFC 8570: IS-IS Traffic Engineering (TE) Metric
                     Extensions, Section 4.5";
      }

    identity path-metric-type {
      base link-path-metric-type;
      base path-metric-optimization-type;
      description
        "Base identity for the path metric types.";
    }

      identity path-metric-te {
        base path-metric-type;
        description
          "Traffic Engineering (TE) Path Metric.";
        reference
          "RFC 5440: Path Computation Element (PCE) Communication
                     Protocol (PCEP), Section 7.8";
      }

      identity path-metric-igp {
        base path-metric-type;
        description
          "Interior Gateway Protocol (IGP) Path Metric.";
        reference
          "RFC 5440: Path Computation Element (PCE) Communication
                     Protocol (PCEP), section 7.8";
      }

      identity path-metric-hop {
        base path-metric-type;
        description
          "Hop Count Path Metric.";
        reference
          "RFC 5440: Path Computation Element (PCE) Communication
                     Protocol (PCEP), Section 7.8";
      }

      identity path-metric-delay-average {
        base path-metric-type;
        description
          "The Path Delay Metric, measured in units of
           microseconds.";
        reference
          "RFC 8233: Extensions to the Path Computation Element
                     Communication Protocol (PCEP) to Compute
                     Service-Aware Label Switched Paths (LSPs),
                     Section 3.1.1";
      }

      identity path-metric-delay-minimum {
        base path-metric-type;
        description
          "The Path Min Delay Metric, measured in units of
           microseconds.";
        reference
          "I-D.ietf-pce-sid-algo: Carrying SR-Algorithm information
                                  in PCE-based Networks,
                                  draft-ietf-pce-sid-algo-14,
                                  Sections 3.5.1 and 3.5.2";
      }

      identity path-metric-residual-bandwidth {
        base path-metric-type;
        description
          "The Path Residual Bandwidth, defined as the minimum Link
           Residual Bandwidth all the links along the path.

           The Path Residual Bandwidth can be seen as the path
           metric associated with the Maximum residual Bandwidth Path
           (MBP) objective function.";
        reference
          "RFC 5541: Encoding of Objective Functions in the Path
                     Computation Element Communication Protocol
                     (PCEP)";
      }

    identity path-metric-optimize-includes {
      base path-metric-optimization-type;
      description
        "A metric that optimizes the number of included resources
         specified in a set.";
    }

    identity path-metric-optimize-excludes {
      base path-metric-optimization-type;
      description
        "A metric that optimizes to a maximum the number of excluded
         resources specified in a set.";
    }

  identity path-tiebreaker-type {
    description
      "Base identity for the path tiebreaker type.";
  }

    identity path-tiebreaker-minfill {
      base path-tiebreaker-type;
      description
        "Min-Fill LSP path placement: selects the path with the most
         available bandwidth (load balance LSPs over more links).";
    }

    identity path-tiebreaker-maxfill {
      base path-tiebreaker-type;
      description
        "Max-Fill LSP path placement: selects the path with the least
         available bandwidth (packing more LSPs over few links).";
    }

    identity path-tiebreaker-random {
      base path-tiebreaker-type;
      description
        "Random LSP path placement.";
    }

  identity resource-affinities-type {
    description
      "Base identity for resource class affinities.";
    reference
      "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
       RFC 2702: Requirements for Traffic Engineering Over MPLS";
  }

    identity resource-aff-include-all {
      base resource-affinities-type;
      description
        "The set of attribute filters associated with a
         tunnel, all of which must be present for a link
         to be acceptable.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
         RFC 2702: Requirements for Traffic Engineering Over MPLS";
    }

    identity resource-aff-include-any {
      base resource-affinities-type;
      description
        "The set of attribute filters associated with a
         tunnel, any of which must be present for a link
         to be acceptable.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
         RFC 2702: Requirements for Traffic Engineering Over MPLS";
    }

    identity resource-aff-exclude-any {
      base resource-affinities-type;
      description
        "The set of attribute filters associated with a
         tunnel, any of which renders a link unacceptable.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
         RFC 2702: Requirements for Traffic Engineering Over MPLS";
    }

  identity te-optimization-criterion {
    description
      "Base identity for the TE optimization criteria.";
    reference
      "RFC 9522: Overview and Principles of Internet Traffic
                 Engineering";
  }

    identity not-optimized {
      base te-optimization-criterion;
      description
        "Optimization is not applied.";
    }

    identity cost {
      base te-optimization-criterion;
      description
        "Optimized on cost.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity delay {
      base te-optimization-criterion;
      description
        "Optimized on delay.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

  identity path-computation-srlg-type {
    description
      "Base identity for Shared Risk Link Group (SRLG) path
      computation.";
  }

    identity srlg-ignore {
      base path-computation-srlg-type;
      description
        "Ignores Shared Risk Link Groups (SRLGs) in the path
        computation.";
    }

    identity srlg-strict {
      base path-computation-srlg-type;
      description
        "Includes a strict Shared Risk Link Group (SRLG) check in
        the path computation.";
    }

    identity srlg-preferred {
      base path-computation-srlg-type;
      description
        "Includes a preferred Shared Risk Link Group (SRLG) check in
        the path computation.";
    }

    identity srlg-weighted {
      base path-computation-srlg-type;
      description
        "Includes a weighted Shared Risk Link Group (SRLG) check in
        the path computation.";
    }

  identity path-computation-error-reason {
    description
      "Base identity for path computation error reasons.";
  }

    identity path-computation-error-path-not-found {
      base path-computation-error-reason;
      description
        "Path computation has failed because of an unspecified 
         reason.";
      reference
        "RFC 5440: Path Computation Element (PCE) Communication
                   Protocol (PCEP), Section 7.5";
    }

    identity path-computation-error-no-topology {
      base path-computation-error-reason;
      description
        "Path computation has failed because there is no topology
         with the provided topology-identifier.";
    }

    identity path-computation-error-no-dependent-server {
      base path-computation-error-reason;
      description
        "Path computation has failed because one or more dependent
         path computation servers are unavailable.

         The dependent path computation server could be
         a Backward-Recursive Path Computation (BRPC) downstream
         PCE or a child PCE.";
      reference
        "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC)
                   Procedure to Compute Shortest Constrained
                   Inter-Domain Traffic Engineering Label Switched
                   Paths
         RFC 8685: Path Computation Element Communication Protocol
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture";
    }

    identity path-computation-error-pce-unavailable {
      base path-computation-error-reason;
      description
        "Path computation has failed because PCE is not available.
        
         It corresponds to bit 31 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 5440: Path Computation Element (PCE) Communication
                   Protocol (PCEP)
         
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-no-inclusion-hop {
      base path-computation-error-reason;
      description
        "Path computation has failed because there is no
         node or link provided by one or more inclusion hops.";
    }

    identity path-computation-error-destination-unknown-in-domain {
      base path-computation-error-reason;
      description
        "Path computation has failed because the destination node is
         unknown in indicated destination domain.
        
         It corresponds to bit 19 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 8685: Path Computation Element Communication Protocol
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture
         
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-no-resource {
      base path-computation-error-reason;
      description
        "Path computation has failed because there is no
         available resource in one or more domains.
        
         It corresponds to bit 20 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 8685: Path Computation Element Communication Protocol
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-child-pce-unresponsive {
      base path-computation-error-no-dependent-server;
      description
        "Path computation has failed because child PCE is not
         responsive.
        
         It corresponds to bit 21 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 8685: Path Computation Element Communication Protocol
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-destination-domain-unknown {
      base path-computation-error-reason;
      description
        "Path computation has failed because the destination domain
         was unknown.
        
         It corresponds to bit 22 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 8685: Path Computation Element Communication Protocol
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-p2mp {
      base path-computation-error-reason;
      description
        "Path computation has failed because of P2MP reachability
         problem.
        
         It corresponds to bit 24 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 8306: Extensions to the Path Computation Element
                   Communication Protocol (PCEP) for
                   Point-to-Multipoint Traffic Engineering Label
                   Switched Paths
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-no-gco-migration {
      base path-computation-error-reason;
      description
        "Path computation has failed because of no Global Concurrent
         Optimization (GCO) migration path found.
        
         It corresponds to bit 26 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 5557: Path Computation Element Communication Protocol
                   (PCEP) Requirements and Protocol Extensions in
                   Support of Global Concurrent Optimization
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-no-gco-solution {
      base path-computation-error-reason;
      description
        "Path computation has failed because of no GCO solution
         found.
        
         It corresponds to bit 25 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 5557: Path Computation Element Communication Protocol
                   (PCEP) Requirements and Protocol Extensions in
                   Support of Global Concurrent Optimization
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-pks-expansion {
      base path-computation-error-reason;
      description
        "Path computation has failed because of Path-Key Subobject
         (PKS) expansion failure.
        
         It corresponds to bit 27 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 5520: Preserving Topology Confidentiality in
                   Inter-Domain Path Computation Using a
                   Path-Key-Based Mechanism
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-brpc-chain-unavailable {
      base path-computation-error-no-dependent-server;
      description
        "Path computation has failed because PCE BRPC chain
         unavailable.
        
         It corresponds to bit 28 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC)
                   Procedure to Compute Shortest Constrained
                   Inter-Domain Traffic Engineering Label Switched
                   Paths
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-source-unknown {
      base path-computation-error-reason;
      description
        "Path computation has failed because source node is 
         unknown.
        
         It corresponds to bit 29 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 5440: Path Computation Element (PCE) Communication
                   Protocol (PCEP);
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

    identity path-computation-error-destination-unknown {
      base path-computation-error-reason;
      description
        "Path computation has failed because destination node is
         unknown.
        
         It corresponds to bit 30 of the Flags field of the 
         NO-PATH-VECTOR TLV.";
      reference
        "RFC 5440: Path Computation Element (PCE) Communication
                   Protocol (PCEP);
        
         https://www.iana.org/assignments/pcep
         /pcep.xhtml#no-path-vector-tlv";
    }

  identity protocol-origin-type {
    description
      "Base identity for protocol origin type.";
  }

    identity protocol-origin-api {
      base protocol-origin-type;
      description
        "Protocol origin is via Application Programming Interface
         (API).";
    }

    identity protocol-origin-pcep {
      base protocol-origin-type;
      description
        "Protocol origin is Path Computation Engine Protocol 
         (PCEP).";
      reference
        "RFC 5440: Path Computation Element (PCE) Communication
                   Protocol (PCEP)";
    }

    identity protocol-origin-bgp {
      base protocol-origin-type;
      description
        "Protocol origin is Border Gateway Protocol (BGP).";
      reference
        "RFC 9012: The BGP Tunnel Encapsulation Attribute";
    }

  identity svec-objective-function-type {
    description
      "Base identity for SVEC objective function type.";
    reference
      "RFC 5541: Encoding of Objective Functions in the Path
                 Computation Element Communication Protocol (PCEP)";
  }

    identity svec-of-minimize-agg-bandwidth-consumption {
      base svec-objective-function-type;
      description
        "Objective function for minimizing aggregate bandwidth 
         consumption (MBC).";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity svec-of-minimize-load-most-loaded-link {
      base svec-objective-function-type;
      description
        "Objective function for minimizing the load on the link that 
         is carrying the highest load (MLL).";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity svec-of-minimize-cost-path-set {
      base svec-objective-function-type;
      description
        "Objective function for minimizing the cost on a path set 
         (MCC).";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity svec-of-minimize-common-transit-domain {
      base svec-objective-function-type;
      description
        "Objective function for minimizing the number of common 
         transit domains (MCTD).";
      reference
        "RFC 8685: Path Computation Element Communication Protocol 
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture.";
    }

    identity svec-of-minimize-shared-link {
      base svec-objective-function-type;
      description
        "Objective function for minimizing the number of shared 
         links (MSL).";
      reference
        "RFC 8685: Path Computation Element Communication Protocol 
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture.";
    }

    identity svec-of-minimize-shared-srlg {
      base svec-objective-function-type;
      description
        "Objective function for minimizing the number of shared 
         Shared Risk Link Groups (SRLG) (MSS).";
      reference
        "RFC 8685: Path Computation Element Communication Protocol 
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture.";
    }

    identity svec-of-minimize-shared-nodes {
      base svec-objective-function-type;
      description
        "Objective function for minimizing the number of shared 
         nodes (MSN).";
      reference
        "RFC 8685: Path Computation Element Communication Protocol
                   (PCEP) Extensions for the Hierarchical Path
                   Computation Element (H-PCE) Architecture.";
    }

  identity svec-metric-type {
    description
      "Base identity for SVEC metric type.";
    reference
      "RFC 5541: Encoding of Objective Functions in the Path
                 Computation Element Communication Protocol (PCEP)";
  }

    identity svec-metric-cumulative-te {
      base svec-metric-type;
      description
        "Cumulative TE cost.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity svec-metric-cumulative-igp {
      base svec-metric-type;
      description
        "Cumulative IGP cost.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity svec-metric-cumulative-hop {
      base svec-metric-type;
      description
        "Cumulative Hop path metric.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity svec-metric-aggregate-bandwidth-consumption {
      base svec-metric-type;
      description
        "Aggregate bandwidth consumption.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

    identity svec-metric-load-of-the-most-loaded-link {
      base svec-metric-type;
      description
        "Load of the most loaded link.";
      reference
        "RFC 5541: Encoding of Objective Functions in the Path
                   Computation Element Communication Protocol
                   (PCEP)";
    }

  /**
   * TE bandwidth groupings
   **/

  grouping te-bandwidth {
    description
      "This grouping defines the generic TE bandwidth.

       For some known data-plane technologies, specific modeling
       structures are specified.
       
       The string-encoded 'te-bandwidth' type is used for
       unspecified technologies.

       The modeling structure can be augmented later for other
       technologies.";
    container te-bandwidth {
      description
        "Container that specifies TE bandwidth.

         The choices can be augmented for specific data-plane
         technologies.";
      choice technology {
        default "generic";
        description
          "Data-plane technology type.";
        case generic {
          leaf generic {
            type te-bandwidth;
            description
              "Bandwidth specified in a generic format.";
          }
        }
      }
    }
  }

  /**
   * TE label groupings
   **/

  grouping te-label {
    description
      "This grouping defines the generic TE label.

       The modeling structure can be augmented for each technology.

       For unspecified technologies, 'rt-types:generalized-label'
       is used.";
    container te-label {
      description
        "Container that specifies the TE label.

         The choices can be augmented for specific data-plane
         technologies.";
      choice technology {
        default "generic";
        description
          "Data-plane technology type.";
        case generic {
          leaf generic {
            type rt-types:generalized-label;
            description
              "TE label specified in a generic format.";
          }
        }
      }
      leaf direction {
        type te-label-direction;
        default "forward";
        description
          "Label direction.";
      }
    }
  }

  grouping te-topology-identifier {
    description
      "Augmentation for a TE topology.";
    container te-topology-identifier {
      description
        "TE topology identifier container.";
      leaf provider-id {
        type te-global-id;
        default "0";
        description
          "An identifier to uniquely identify a provider.
           If omitted, it assumes that the topology provider ID
           value = 0 (the default).";
      }
      leaf client-id {
        type te-global-id;
        default "0";
        description
          "An identifier to uniquely identify a client.
           If omitted, it assumes that the topology client ID
           value = 0 (the default).";
      }
      leaf topology-id {
        type te-topology-id;
        default "";
        description
          "When the datastore contains several topologies,
           'topology-id' distinguishes between them.
           
           If omitted, the default (empty) string for this leaf is
           assumed.";
      }
    }
  }

  /**
   * TE performance metrics groupings
   **/

  grouping performance-metrics-one-way-delay-loss {
    description
      "Performance Metrics (PM) information in real time that can
       be applicable to links or connections.
       
       PM defined in this grouping are applicable to generic TE PM
       as well as packet TE PM.";
    reference
      "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
       RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
       RFC 7823: Performance-Based Path Selection for Explicitly
                 Routed Label Switched Paths (LSPs) Using TE Metric
                 Extensions";
    leaf one-way-delay {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      description
        "One-way delay or latency.";
    }
    leaf one-way-delay-normality {
      type te-types:performance-metrics-normality;
      description
        "One-way delay normality.";
    }
  }

  grouping performance-metrics-two-way-delay-loss {
    description
      "Performance Metrics (PM) information in real time that can be
       applicable to links or connections.
       
       PM defined in this grouping are applicable to generic TE PM
       as well as packet TE PM.";
    reference
      "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
       RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
       RFC 7823: Performance-Based Path Selection for Explicitly
                 Routed Label Switched Paths (LSPs) Using TE Metric
                 Extensions";
    leaf two-way-delay {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      description
        "Two-way delay or latency.";
    }
    leaf two-way-delay-normality {
      type te-types:performance-metrics-normality;
      description
        "Two-way delay normality.";
    }
  }

  grouping performance-metrics-one-way-bandwidth {
    description
      "Performance Metrics (PM) information in real time that can be
      applicable to links.
       
       PM defined in this grouping are applicable to generic TE PM
       as well as packet TE PM.";
    reference
      "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
       RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
       RFC 7823: Performance-Based Path Selection for Explicitly
                 Routed Label Switched Paths (LSPs) Using TE Metric
                 Extensions";
    leaf one-way-residual-bandwidth {
      type rt-types:bandwidth-ieee-float32;
      units "bytes per second";
      default "0x0p0";
      description
        "Residual bandwidth that subtracts tunnel reservations from
         Maximum Bandwidth (or link capacity) (RFC 3630) and
         provides an aggregated remainder across QoS classes.";
      reference
        "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                   Version 2";
    }
    leaf one-way-residual-bandwidth-normality {
      type te-types:performance-metrics-normality;
      default "normal";
      description
        "Residual bandwidth normality.";
    }
    leaf one-way-available-bandwidth {
      type rt-types:bandwidth-ieee-float32;
      units "bytes per second";
      default "0x0p0";
      description
        "Available bandwidth that is defined to be residual
         bandwidth minus the measured bandwidth used for the
         actual forwarding of non-RSVP-TE LSP packets.
         
         For a bundled link, available bandwidth is defined to be
         the sum of the component link available bandwidths.";
    }
    leaf one-way-available-bandwidth-normality {
      type te-types:performance-metrics-normality;
      default "normal";
      description
        "Available bandwidth normality.";
    }
    leaf one-way-utilized-bandwidth {
      type rt-types:bandwidth-ieee-float32;
      units "bytes per second";
      default "0x0p0";
      description
        "Bandwidth utilization that represents the actual
         utilization of the link (i.e., as measured in the router).
         For a bundled link, bandwidth utilization is defined to
         be the sum of the component link bandwidth utilizations.";
    }
    leaf one-way-utilized-bandwidth-normality {
      type te-types:performance-metrics-normality;
      default "normal";
      description
        "Bandwidth utilization normality.";
    }
  }

  grouping one-way-performance-metrics {
    description
      "One-way Performance Metrics (PM) throttle grouping.";
    leaf one-way-delay {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      default "0";
      description
        "One-way delay or latency.";
    }
    leaf one-way-residual-bandwidth {
      type rt-types:bandwidth-ieee-float32;
      units "bytes per second";
      default "0x0p0";
      description
        "Residual bandwidth that subtracts tunnel reservations from
         Maximum Bandwidth (or link capacity) (RFC 3630) and
         provides an aggregated remainder across QoS classes.";
      reference
        "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                   Version 2";
    }
    leaf one-way-available-bandwidth {
      type rt-types:bandwidth-ieee-float32;
      units "bytes per second";
      default "0x0p0";
      description
        "Available bandwidth that is defined to be residual
         bandwidth minus the measured bandwidth used for the
         actual forwarding of non-RSVP-TE LSP packets.
         
         For a bundled link, available bandwidth is defined to be
         the sum of the component link available bandwidths.";
    }
    leaf one-way-utilized-bandwidth {
      type rt-types:bandwidth-ieee-float32;
      units "bytes per second";
      default "0x0p0";
      description
        "Bandwidth utilization that represents the actual
         utilization of the link (i.e., as measured in the router).
         For a bundled link, bandwidth utilization is defined to
         be the sum of the component link bandwidth utilizations.";
    }
  }

  grouping two-way-performance-metrics {
    description
      "Two-way Performance Metrics (PM) throttle grouping.";
    leaf two-way-delay {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      default "0";
      description
        "Two-way delay or latency.";
    }
  }

  grouping performance-metrics-thresholds {
    description
      "Grouping for configurable thresholds for measured
       attributes.";
    uses one-way-performance-metrics;
    uses two-way-performance-metrics;
  }

  grouping performance-metrics-attributes {
    description
      "Contains Performance Metrics (PM) attributes.";
    container performance-metrics-one-way {
      description
        "One-way link performance information in real time.";
      reference
        "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
         RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
         RFC 7823: Performance-Based Path Selection for Explicitly
                   Routed Label Switched Paths (LSPs) Using TE Metric
                   Extensions";
      uses performance-metrics-one-way-delay-loss;
      uses performance-metrics-one-way-bandwidth;
    }
    container performance-metrics-two-way {
      description
        "Two-way link performance information in real time.";
      reference
        "RFC 6374: Packet Loss and Delay Measurement for MPLS
                   Networks";
      uses performance-metrics-two-way-delay-loss;
    }
  }

  grouping performance-metrics-throttle-container {
    description
      "Controls Performance Metrics (PM) throttling.";
    container throttle {
      must 'suppression-interval >= measure-interval' {
        error-message "'suppression-interval' cannot be less than "
                    + "'measure-interval'.";
        description
          "Constraint on 'suppression-interval' and
           'measure-interval'.";
      }
      description
        "Link performance information in real time.";
      reference
        "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
         RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
         RFC 7823: Performance-Based Path Selection for Explicitly
                   Routed Label Switched Paths (LSPs) Using TE Metric
                   Extensions";
      leaf one-way-delay-offset {
        type uint32 {
          range "0..16777215";
        }
        units "microseconds";
        default "0";
        description
          "Offset value to be added to the measured delay value.";
      }
      leaf measure-interval {
        type uint32;
        units "seconds";
        default "30";
        description
          "Interval to measure the extended metric values.";
      }
      leaf advertisement-interval {
        type uint32;
        units "seconds";
        default "0";
        description
          "Interval to advertise the extended metric values.";
      }
      leaf suppression-interval {
        type uint32 {
          range "1..max";
        }
        units "seconds";
        default "120";
        description
          "Interval to suppress advertisement of the extended metric
          values.";
        reference
          "RFC 8570: IS-IS Traffic Engineering (TE) Metric
                     Extensions, Section 6";
      }
      container threshold-out {
        uses performance-metrics-thresholds;
        description
          "If the measured parameter falls outside an upper bound
           for all but the minimum-delay metric (or a lower bound
           for the minimum-delay metric only) and the advertised
           value is not already outside that bound, an 'anomalous'
           announcement (anomalous bit set) will be triggered.";
      }
      container threshold-in {
        uses performance-metrics-thresholds;
        description
          "If the measured parameter falls inside an upper bound
           for all but the minimum-delay metric (or a lower bound
           for the minimum-delay metric only) and the advertised
           value is not already inside that bound, a 'normal'
           announcement (anomalous bit cleared) will be triggered.";
      }
      container threshold-accelerated-advertisement {
        description
          "When the difference between the last advertised value and
           the current measured value exceeds this threshold, an
           'anomalous' announcement (anomalous bit set) will be
           triggered.";
        uses performance-metrics-thresholds;
      }
    }
  }

  /**
   * TE tunnel generic groupings
   **/

  grouping explicit-route-hop {
    description
      "The explicit route entry grouping.";
    choice type {
      description
        "The explicit route entry type.";
      case numbered-node-hop {
        container numbered-node-hop {
          must "node-id-uri or node-id" {
            description
              "At least one node identifier needs to be present.";
          }
          leaf node-id-uri {
            type nw:node-id;
            description
              "The identifier of a node in the topology.";
          }
          leaf node-id {
            type te-node-id;
            description
              "The identifier of a node in the TE topology.";
          }
          leaf hop-type {
            type te-hop-type;
            default "strict";
            description
              "Strict or loose hop.";
          }
          description
            "Numbered node route hop.";
          reference
            "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                       Section 4.3, EXPLICIT_ROUTE in RSVP-TE
             RFC 3477: Signalling Unnumbered Links in Resource
                       ReSerVation Protocol - Traffic Engineering
                       (RSVP-TE)";
        }
      }
      case numbered-link-hop {
        container numbered-link-hop {
          leaf link-tp-id {
            type te-tp-id;
            mandatory true;
            description
              "TE Link Termination Point (LTP) identifier.";
          }
          leaf hop-type {
            type te-hop-type;
            default "strict";
            description
              "Strict or loose hop.";
          }
          leaf direction {
            type te-link-direction;
            default "outgoing";
            description
              "Link route object direction.";
          }
          description
            "Numbered link explicit route hop.";
          reference
            "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                       Section 4.3, EXPLICIT_ROUTE in RSVP-TE
             RFC 3477: Signalling Unnumbered Links in Resource
                       ReSerVation Protocol - Traffic Engineering
                       (RSVP-TE)";
        }
      }
      case unnumbered-link-hop {
        container unnumbered-link-hop {
          must "(link-tp-id-uri or link-tp-id) and " +
                "(node-id-uri or node-id)" {
            description
              "At least one node identifier and at least one Link
               Termination Point (LTP) identifier need to be
               present.";
          }
          leaf link-tp-id-uri {
            type nt:tp-id;
            description
              "Link Termination Point (LTP) identifier.";
          }
          leaf link-tp-id {
            type te-tp-id;
            description
              "TE LTP identifier.

               The combination of the TE link ID and the TE node ID
               is used to identify an unnumbered TE link.";
          }
          leaf node-id-uri {
            type nw:node-id;
            description
              "The identifier of a node in the topology.";
          }
          leaf node-id {
            type te-node-id;
            description
              "The identifier of a node in the TE topology.";
          }
          leaf hop-type {
            type te-hop-type;
            default "strict";
            description
              "Strict or loose hop.";
          }
          leaf direction {
            type te-link-direction;
            default "outgoing";
            description
              "Link route object direction.";
          }
          description
            "Unnumbered link explicit route hop.";
          reference
            "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels,
                       Section 4.3, EXPLICIT_ROUTE in RSVP-TE
             RFC 3477: Signalling Unnumbered Links in Resource
                       ReSerVation Protocol - Traffic Engineering
                       (RSVP-TE)";
        }
      }
      case as-number {
        container as-number-hop {
          leaf as-number {
            type inet:as-number;
            mandatory true;
            description
              "The Autonomous System (AS) number.";
          }
          leaf hop-type {
            type te-hop-type;
            default "strict";
            description
              "Strict or loose hop.";
          }
          description
            "AS explicit route hop.";
        }
      }
      case label {
        container label-hop {
          description
            "Label hop type.";
          uses te-label;
        }
        description
          "The label explicit route hop type.";
      }
    }
  }

  grouping explicit-route-hop-with-srlg {
    description
      "Augments the explicit route entry grouping with Shared Risk
      Link Group (SRLG) hop type.";
    uses explicit-route-hop {
      augment "type" {
        case srlg {
          container srlg {
            description
              "Shared Risk Link Group (SRLG) container.";
            leaf srlg {
              type uint32;
              description
                "Shared Risk Link Group (SRLG) value.";
            }
          }
          description
            "An Shared Risk Link Group (SRLG) value to be
            included or excluded.";
        }
        description
          "Augmentation for a generic explicit route for Shared
           Risk Link Group (SRLG) inclusion or exclusion.";
      }
    }
  }

  grouping record-route-state {
    description
      "The Record Route grouping.";
    leaf index {
      type uint32;
      description
        "Record Route hop index.

         The index is used to identify an entry in the list.
         
         The order of entries is defined by the user without relying
         on key values.";
    }
    choice type {
      description
        "The Record Route entry type.";
      case numbered-node-hop {
        container numbered-node-hop {
          must "node-id-uri or node-id" {
            description
              "At least one node identifier need to be present.";
          }
          description
            "Numbered node route hop container.";
          leaf node-id-uri {
            type nw:node-id;
            description
              "The identifier of a node in the topology.";
          }
          leaf node-id {
            type te-node-id;
            description
              "The identifier of a node in the TE topology.";
          }
          leaf-list flags {
            type path-attribute-flags;
            description
              "Path attributes flags.";
            reference
              "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
               RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                         Tunnels
               RFC 4561: Definition of a Record Route Object (RRO)
                         Node-Id Sub-Object";
          }
        }
        description
          "Numbered node route hop.";
      }
      case numbered-link-hop {
        container numbered-link-hop {
          description
            "Numbered link route hop container.";
          leaf link-tp-id {
            type te-tp-id;
            mandatory true;
            description
              "Numbered TE LTP identifier.";
          }
          leaf-list flags {
            type path-attribute-flags;
            description
              "Path attributes flags.";
            reference
              "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
               RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                         Tunnels
               RFC 4561: Definition of a Record Route Object (RRO)
                         Node-Id Sub-Object";
          }
        }
        description
          "Numbered link route hop.";
      }
      case unnumbered-link-hop {
        container unnumbered-link-hop {
          must "(link-tp-id-uri or link-tp-id) and " +
              "(node-id-uri or node-id)" {
            description
              "At least one node identifier and at least one Link
               Termination Point (LTP) identifier need to be
               present.";
          }
          leaf link-tp-id-uri {
            type nt:tp-id;
            description
              "Link Termination Point (LTP) identifier.";
          }
          leaf link-tp-id {
            type te-tp-id;
            description
              "TE LTP identifier.

               The combination of the TE link ID and the TE node ID
               is used to identify an unnumbered TE link.";
          }
          leaf node-id-uri {
            type nw:node-id;
            description
              "The identifier of a node in the topology.";
          }
          leaf node-id {
            type te-node-id;
            description
              "The identifier of a node in the TE topology.";
          }
          leaf-list flags {
            type path-attribute-flags;
            description
              "Path attributes flags.";
            reference
              "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
               RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                         Tunnels
               RFC 4561: Definition of a Record Route Object (RRO)
                         Node-Id Sub-Object";
          }
          description
            "Unnumbered link Record Route hop.";
          reference
            "RFC 3477: Signalling Unnumbered Links in Resource
                       ReSerVation Protocol - Traffic Engineering
                       (RSVP-TE)";
        }
        description
          "Unnumbered link route hop.";
      }
      case label {
        container label-hop {
          description
            "Label route hop type.";
          uses te-label;
          leaf-list flags {
            type path-attribute-flags;
            description
              "Path attributes flags.";
            reference
              "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels
               RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP
                         Tunnels
               RFC 4561: Definition of a Record Route Object (RRO)
                         Node-Id Sub-Object";
          }
        }
        description
          "The label Record Route entry types.";
      }
    }
  }

  grouping label-restriction-info {
    description
      "Label set item information.";
    leaf restriction {
      type enumeration {
        enum inclusive {
          description
            "The label or label range is inclusive.";
        }
        enum exclusive {
          description
            "The label or label range is exclusive.";
        }
      }
      default "inclusive";
      description
        "Indicates whether the list item is inclusive or exclusive.";
    }
    leaf index {
      type uint32;
      description
        "The index of the label restriction list entry.";
    }
    container label-start {
      must "(not(../label-end/te-label/direction) and"
         + " not(te-label/direction))"
         + " or "
         + "(../label-end/te-label/direction = te-label/direction)"
         + " or "
         + "(not(te-label/direction) and"
         + " (../label-end/te-label/direction = 'forward'))"
         + " or "
         + "(not(../label-end/te-label/direction) and"
         + " (te-label/direction = 'forward'))" {
        error-message "'label-start' and 'label-end' must have the "
                    + "same direction.";
      }
      description
        "This is the starting label if a label range is specified.
         This is the label value if a single label is specified,
         in which case the 'label-end' attribute is not set.";
      uses te-label;
    }
    container label-end {
      must "(not(../label-start/te-label/direction) and"
         + " not(te-label/direction))"
         + " or "
         + "(../label-start/te-label/direction = te-label/direction)"
         + " or "
         + "(not(te-label/direction) and"
         + " (../label-start/te-label/direction = 'forward'))"
         + " or "
         + "(not(../label-start/te-label/direction) and"
         + " (te-label/direction = 'forward'))" {
        error-message "'label-start' and 'label-end' must have the "
                    + "same direction.";
      }
      description
        "This is the ending label if a label range is specified.
         This attribute is not set if a single label is specified.";
      uses te-label;
    }
    container label-step {
      description
        "The step increment between labels in the label range.

         The label start/end values MUST be consistent with the sign
         of label step.

         For example:
            'label-start' < 'label-end' enforces 'label-step' > 0
            'label-start' > 'label-end' enforces 'label-step' < 0.";
      choice technology {
        default "generic";
        description
          "Data-plane technology type.";
        case generic {
          leaf generic {
            type int32;
            default "1";
            description
              "Label range step.";
          }
        }
      }
    }
    leaf range-bitmap {
      type yang:hex-string;
      description
        "When there are gaps between 'label-start' and 'label-end',
         this attribute is used to specify the positions
         of the used labels.
         
         This is represented in big endian as 'hex-string'.

         In case the restriction is 'inclusive', the bit-position is
         set if the corresponding mapped label is available.
         In this case, if the range-bitmap is not present, all the
         labels in the range are available.

         In case the restriction is 'exclusive', the bit-position is
         set if the corresponding mapped label is not available.
         In this case, if the range-bitmap is not present, all the
         labels in the range are not available.

         The most significant byte in the hex-string is the farthest
         to the left in the byte sequence.

         Leading zero bytes in the configured value may be omitted
         for brevity.

         Each bit position in the 'range-bitmap' 'hex-string' maps
         to a label in the range derived from 'label-start'.

         For example, assuming that 'label-start' = 16000 and
         'range-bitmap' = 0x01000001, then:
         - bit position (0) is set, and the corresponding mapped
           label from the range is 16000 + (0 * 'label-step') or
           16000 for default 'label-step' = 1.
         - bit position (24) is set, and the corresponding mapped
           label from the range is 16000 + (24 * 'label-step') or
           16024 for default 'label-step' = 1.";
    }
  }

  grouping label-set-info {
    description
      "Grouping for the list of label restrictions specifying what
       labels may or may not be used.";
    container label-restrictions {
      description
        "The label restrictions container.";
      list label-restriction {
        key "index";
        description
          "The absence of the label restrictions container implies
           that all labels are acceptable; otherwise, only restricted
           labels are available.";
        reference
          "RFC 7579: General Network Element Constraint Encoding
                     for GMPLS-Controlled Networks";
        uses label-restriction-info;
      }
    }
  }

  grouping optimization-metric-entry {
    description
      "Optimization metrics configuration grouping.";
    leaf metric-type {
      type identityref {
        base path-metric-optimization-type;
      }
      description
        "Identifies the 'metric-type' that the path computation
         process uses for optimization.";
    }
    leaf weight {
      type uint8;
      default "1";
      description
        "TE path metric normalization weight.";
    }
    container explicit-route-exclude-objects {
      when "../metric-type = "
         + "'te-types:path-metric-optimize-excludes'";
      description
        "Container for the 'exclude route' object list.";
      uses path-route-exclude-objects;
    }
    container explicit-route-include-objects {
      when "../metric-type = "
         + "'te-types:path-metric-optimize-includes'";
      description
        "Container for the 'include route' object list.";
      uses path-route-include-objects;
    }
  }

  grouping common-constraints {
    description
      "Common constraints grouping that can be set on
       a constraint set or directly on the tunnel.";
    uses te-bandwidth {
      description
        "A requested bandwidth to use for path computation.";
    }
    leaf link-protection {
      type identityref {
        base link-protection-type;
      }
      default "te-types:link-protection-unprotected";
      description
        "Link protection type required for the links included
         in the computed path.";
      reference
        "RFC 4202: Routing Extensions in Support of
                   Generalized Multi-Protocol Label Switching
                   (GMPLS)";
    }
    leaf setup-priority {
      type uint8 {
        range "0..7";
      }
      default "7";
      description
        "TE LSP requested setup priority.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
    }
    leaf hold-priority {
      type uint8 {
        range "0..7";
      }
      default "7";
      description
        "TE LSP requested hold priority.";
      reference
        "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels";
    }
    leaf signaling-type {
      type identityref {
        base path-signaling-type;
      }
      default "te-types:path-setup-rsvp";
      description
        "TE tunnel path signaling type.";
    }
  }

  grouping tunnel-constraints {
    description
      "Tunnel constraints grouping that can be set on
       a constraint set or directly on the tunnel.";
    leaf network-id {
      type nw:network-id;
      description
        "The network topology identifier.";
    }
    uses te-topology-identifier;
    uses common-constraints;
  }

  grouping path-constraints-route-objects {
    description
      "List of route entries to be included or excluded when
       performing the path computation.";
    container explicit-route-objects {
      description
        "Container for the explicit route object lists.";
      list route-object-exclude-always {
        key "index";
        ordered-by user;
        description
          "List of route objects to always exclude from the path
           computation.";
        leaf index {
          type uint32;
          description
            "Explicit Route Object index.

             The index is used to identify an entry in the list.
             
             The order of entries is defined by the user without
             relying on key values.";
        }
        uses explicit-route-hop;
      }
      list route-object-include-exclude {
        key "index";
        ordered-by user;
        description
          "List of route objects to include or exclude in the path
           computation.";
        leaf explicit-route-usage {
          type identityref {
            base route-usage-type;
          }
          default "te-types:route-include-object";
          description
            "Indicates whether to include or exclude the
             route object.

             The default is to include it.";
        }
        leaf index {
          type uint32;
          description
            "Route object include-exclude index.

             The index is used to identify an entry in the list.

             The order of entries is defined by the user without
             relying on key values.";
        }
        uses explicit-route-hop-with-srlg;
      }
    }
  }

  grouping path-route-include-objects {
    description
      "List of route objects to be included when performing
       the path computation.";
    list route-object-include-object {
      key "index";
      ordered-by user;
      description
        "List of Explicit Route Objects to be included in the
         path computation.";
      leaf index {
        type uint32;
        description
          "Route object entry index.

             The index is used to identify an entry in the list.
             
             The order of entries is defined by the user without
             relying on key values.";
      }
      uses explicit-route-hop;
    }
  }

  grouping path-route-exclude-objects {
    description
      "List of route objects to be excluded when performing
       the path computation.";
    list route-object-exclude-object {
      key "index";
      ordered-by user;
      description
        "List of Explicit Route Objects to be excluded in the
         path computation.";
      leaf index {
        type uint32;
        description
          "Route object entry index.

             The index is used to identify an entry in the list.
             
             The order of entries is defined by the user without
             relying on key values.";
      }
      uses explicit-route-hop-with-srlg;
    }
  }

  grouping generic-path-metric-bounds {
    description
      "TE path metric bounds grouping.";
    container path-metric-bounds {
      description
        "Top-level container for the list of path metric bounds.";
      list path-metric-bound {
        key "metric-type";
        description
          "List of path metric bounds, which can apply to link and
           path metrics.
          
           TE paths which have at least one path metric which
           exceeds the specified bounds MUST NOT be selected.
          
           TE paths that traverse TE links which have at least one
           link metric which exceeds the specified bounds MUST NOT
           be selected.";
        leaf metric-type {
          type identityref {
            base link-path-metric-type;
          }
          description
            "Identifies an entry in the list of 'metric-type' items
             bound for the TE path.";
        }
        leaf upper-bound {
          type uint64;
          default "0";
          description
            "Upper bound on the specified 'metric-type'.
            
             A zero indicates an unbounded upper limit for the
             specified 'metric-type'.
            
             The unit of is interpreted in the context of the
             'metric-type' identity.";
        }
      }
    }
  }

  grouping generic-path-optimization {
    description
      "TE generic path optimization grouping.";
    container optimizations {
      description
        "The objective function container that includes
         attributes to impose when computing a TE path.";
      choice algorithm {
        description
          "Optimizations algorithm.";
        case metric {
          if-feature "path-optimization-metric";
          /* Optimize by metric */
          list optimization-metric {
            key "metric-type";
            description
              "TE path metric type.";
            uses optimization-metric-entry;
          }
          /* Tiebreakers */
          container tiebreakers {
            status deprecated;
            description
              "Container for the list of tiebreakers.
              
               This container has been deprecated by the tiebreaker
               leaf.";
            list tiebreaker {
              key "tiebreaker-type";
              status deprecated;
              description
                "The list of tiebreaker criteria to apply on an
                 equally favored set of paths, in order to pick
                 the best.";
              leaf tiebreaker-type {
                type identityref {
                  base path-metric-type;
                }
                status deprecated;
                description
                  "Identifies an entry in the list of tiebreakers.";
              }
            }
          }
        }
        case objective-function {
          if-feature "path-optimization-objective-function";
          /* Objective functions */
          container objective-function {
            description
              "The objective function container that includes
               attributes to impose when computing a TE path.";
            leaf objective-function-type {
              type identityref {
                base objective-function-type;
              }
              default "te-types:of-minimize-cost-path";
              description
                "Objective function entry.";
            }
          }
        }
      }
    }
    leaf tiebreaker {
      type identityref {
        base path-tiebreaker-type;
      }
      default "te-types:path-tiebreaker-random";
      description
        "The tiebreaker criteria to apply on an equally favored set
         of paths, in order to pick the best.";
    }
  }

  grouping generic-path-affinities {
    description
      "Path affinities grouping.";
    container path-affinities-values {
      description
        "Path affinities represented as values.";
      list path-affinities-value {
        key "usage";
        description
          "List of named affinity constraints.";
        leaf usage {
          type identityref {
            base resource-affinities-type;
          }
          description
            "Identifies an entry in the list of value affinity
             constraints.";
        }
        leaf value {
          type admin-groups;
          default "";
          description
            "The affinity value.

             The default is empty.";
        }
      }
    }
    container path-affinity-names {
      description
        "Path affinities represented as names.";
      list path-affinity-name {
        key "usage";
        description
          "List of named affinity constraints.";
        leaf usage {
          type identityref {
            base resource-affinities-type;
          }
          description
            "Identifies an entry in the list of named affinity
             constraints.";
        }
        list affinity-name {
          key "name";
          leaf name {
            type string;
            description
              "Identifies a named affinity entry.";
          }
          description
            "List of named affinities.";
        }
      }
    }
  }

  grouping generic-path-srlgs {
    description
      "Path Shared Risk Link Group (SRLG) grouping.";
    container path-srlgs-lists {
      description
        "Path Shared Risk Link Group (SRLG) properties container.";
      list path-srlgs-list {
        key "usage";
        description
          "List of Shared Risk Link Group (SRLG) values to be
          included or excluded.";
        leaf usage {
          type identityref {
            base route-usage-type;
          }
          description
            "Identifies an entry in a list of Shared Risk Link Groups
            (SRLGs) to either include or exclude.";
        }
        leaf-list values {
          type srlg;
          description
            "List of Shared Risk Link Group (SRLG) values.";
        }
      }
    }
    container path-srlgs-names {
      description
        "Container for the list of named Shared Risk Link Groups
        (SRLGs).";
      list path-srlgs-name {
        key "usage";
        description
          "List of named Shared Risk Link Groups (SRLGs) to be
          included or excluded.";
        leaf usage {
          type identityref {
            base route-usage-type;
          }
          description
            "Identifies an entry in a list of named Shared Risk Link
            Groups (SRLGs) to either include or exclude.";
        }
        leaf-list names {
          type string;
          description
            "List of named Shared Risk Link Groups (SRLGs).";
        }
      }
    }
  }

  grouping generic-path-disjointness {
    description
      "Path disjointness grouping.";
    leaf disjointness {
      type te-path-disjointness;
      description
        "The type of resource disjointness.
         When configured for a primary path, the disjointness level
         applies to all secondary LSPs.

         When configured for a secondary path, the disjointness
         level overrides the level configured for the primary path.";
    }
  }

  grouping common-path-constraints-attributes {
    description
      "Common path constraints configuration grouping.";
    uses common-constraints;
    uses generic-path-metric-bounds;
    uses generic-path-affinities;
    uses generic-path-srlgs;
  }

  grouping generic-path-constraints {
    description
      "Global named path constraints configuration grouping.";
    container path-constraints {
      description
        "TE named path constraints container.";
      uses common-path-constraints-attributes;
      uses generic-path-disjointness;
    }
  }

  grouping generic-path-properties {
    description
      "TE generic path properties grouping.";
    container path-properties {
      config false;
      description
        "The TE path properties.";
      list path-metric {
        key "metric-type";
        description
          "TE path metric type.";
        leaf metric-type {
          type identityref {
            base path-metric-type;
          }
          description
            "TE path metric type.";
        }
        leaf accumulative-value {
          type uint64;
          description
            "TE path metric accumulative value.";
        }
      }
      uses generic-path-affinities;
      uses generic-path-srlgs;
      container path-route-objects {
        description
          "Container for the list of route objects either returned by
           the computation engine or actually used by an LSP.";
        list path-route-object {
          key "index";
          ordered-by user;
          description
            "List of route objects either returned by the computation
             engine or actually used by an LSP.";
          leaf index {
            type uint32;
            description
              "Route object entry index.

               The index is used to identify an entry in the list.
               
               The order of entries is defined by the user without
               relying on key values.";
          }
          uses explicit-route-hop;
        }
      }
    }
  }

  grouping encoding-and-switching-type {
    description
      "Common grouping to define the LSP encoding and
       switching types";
    leaf encoding {
      type identityref {
        base te-types:lsp-encoding-types;
      }
      description
        "LSP encoding type.";
      reference
        "RFC 3945: Generalized Multi-Protocol Label Switching (GMPLS)
                   Architecture";
    }
    leaf switching-type {
      type identityref {
        base te-types:switching-capabilities;
      }
      description
        "LSP switching type.";
      reference
        "RFC 3945: Generalized Multi-Protocol Label Switching (GMPLS)
                   Architecture";
    }
  }

  grouping te-generic-node-id {
    description
      "A reusable grouping for a TE generic node identifier.";
    leaf id {
      type union {
        type te-node-id;
        type inet:ip-address;
        type nw:node-id;
      }
      description
        "The identifier of the node.
         
         It can be represented as IP address or dotted quad address
         or as an URI.
         
         The type data node disambiguates the union type.";
    }
    leaf type {
      type enumeration {
        enum ip {
          description
            "IP address representation of the node identifier.";
        }
        enum te-id {
          description
            "TE identifier of the node";
        }
        enum node-id {
          description
            "URI representation of the node identifier.";
        }
      }
      description
        "Type of node identifier representation.";
    }
  }
}
]]></sourcecode></figure>

</section>
<section anchor="pkt-yang-code"><name>Packet TE Types YANG Module</name>

<t>The "ietf-te-packet-types" module imports from the "ietf-te-types" module defined in <xref target="te-yang-code"/> of this document.</t>

<figure title="Packet TE Types YANG module" anchor="fig-pkt-yang"><sourcecode type="yang" markers="true" name="ietf-te-packet-types@2024-11-28.yang"><![CDATA[
module ietf-te-packet-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-te-packet-types";
  prefix te-packet-types;

  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types";
  }

  import ietf-te-types {
    prefix te-types;
    reference
      "RFC XXXX: Common YANG Data Types for Traffic Engineering";
  }
  // RFC Editor: replace XXXX with actual RFC number
  // and remove this note

  organization
    "IETF Traffic Engineering Architecture and Signaling (TEAS)
     Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/teas/>
     WG List:  <mailto:teas@ietf.org>

     Editor:   Tarek Saad
               <mailto:tsaad.net@gmail.com>

     Editor:   Rakesh Gandhi
               <mailto:rgandhi@cisco.com>

     Editor:   Vishnu Pavan Beeram
               <mailto:vbeeram@juniper.net>

     Editor:   Xufeng Liu
               <mailto:xufeng.liu.ietf@gmail.com>

     Editor:   Igor Bryskin
               <mailto:i_bryskin@yahoo.com>";
  description
    "This YANG module contains a collection of generally useful YANG
     data type definitions specific to Packet Traffic Engineering
     (TE).
     
     The model conforms to the Network Management Datastore
     Architecture (NMDA).

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     Copyright (c) 2025 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.";
  revision 2025-01-24 {
    description
      "This revision adds the following new identities:
       - bandwidth-profile-type;
       - link-metric-delay-variation;
       - link-metric-loss;
       - path-metric-delay-variation;
       - path-metric-loss.

      This revision adds the following new groupings:
       - bandwidth-profile-parameters;
       - te-packet-path-bandwidth;
       - te-packet-link-bandwidth.
       
      This revision provides also few editorial changes.";
    reference
      "RFC XXXX: Common YANG Data Types for Traffic Engineering";
  }
  // RFC Editor: replace XXXX with actual RFC number, update date
  // information and remove this note

  revision 2020-06-10 {
    description
      "Latest revision of TE MPLS types.";
    reference
      "RFC 8776: Common YANG Data Types for Traffic Engineering";
  }

  /*
   * Identities
   */

  identity bandwidth-profile-type {
    description
      "Bandwidth Profile Types";
  }

    identity mef-10 {
      base bandwidth-profile-type;
      description
        "MEF 10 Bandwidth Profile";
      reference
        "MEF 10.3: Ethernet Services Attributes Phase 3";
    }

    identity rfc-2697 {
      base bandwidth-profile-type;
      description
        "RFC 2697 Bandwidth Profile";
      reference
        "RFC 2697: A Single Rate Three Color Marker";
    }

    identity rfc-2698 {
      base bandwidth-profile-type;
      description
        "RFC 2698 Bandwidth Profile";
      reference
        "RFC 2698: A Two Rate Three Color Marker";
    }

  // Derived identities from te-types:link-metric-type

    identity link-metric-delay-variation {
      base te-types:link-metric-type;
      description
        "The Unidirectional Delay Variation Metric,
         measured in units of microseconds.";
      reference
        "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions,
                   Section 4.3
         RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions,
                   Section 4.3";
    }

    identity link-metric-loss {
      base te-types:link-metric-type;
      description
        "The Unidirectional Link Loss Metric,
         measured in units of 0.000003%.";
      reference
        "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions,
                   Section 4.4
         RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions,
                   Section 4.4";
    }

  // Derived identities from te-types:link-metric-type

    identity path-metric-delay-variation {
      base te-types:path-metric-type;
      description
        "The Path Delay Variation Metric,
         measured in units of microseconds.";
      reference
        "RFC 8233: Extensions to the Path Computation Element
                   Communication Protocol (PCEP) to Compute
                   Service-Aware Label Switched Paths (LSPs),
                   Section 3.1.2";
    }

    identity path-metric-loss {
      base te-types:path-metric-type;
      description
        "The Path Loss Metric, measured in units of 0.000003%.";
      reference
        "RFC 8233: Extensions to the Path Computation Element
                   Communication Protocol (PCEP) to Compute
                   Service-Aware Label Switched Paths (LSPs),
                   Section 3.1.3";
    }

  /*
   * Typedefs
   */

  typedef te-bandwidth-requested-type {
    type enumeration {
      enum specified-value {
        description
          "Bandwidth value is explicitly specified.";
      }
      enum specified-profile {
        description
          "Bandwidth profile is explicitly specified.";
      }
      enum auto {
        description
          "Bandwidth is automatically computed.";
      }
    }
    description
      "Enumerated type for specifying whether bandwidth is
       explicitly specified or automatically computed.";
  }

  typedef te-class-type {
    type uint8;
    description
      "Diffserv-TE Class-Type.
       Defines a set of Traffic Trunks crossing a link that is
       governed by a specific set of bandwidth constraints.
       
       Class-Type is used for the purposes of link bandwidth
       allocation, constraint-based routing, and admission control.";
    reference
      "RFC 4124: Protocol Extensions for Support of Diffserv-aware
                 MPLS Traffic Engineering";
  }

  typedef bc-type {
    type uint8 {
      range "0..7";
    }
    description
      "Diffserv-TE bandwidth constraints as defined in RFC 4124.";
    reference
      "RFC 4124: Protocol Extensions for Support of Diffserv-aware
                 MPLS Traffic Engineering";
  }

  typedef bandwidth-kbps {
    type uint64;
    units "kilobits per second";
    description
      "Bandwidth values, expressed in kilobits per second.";
  }

  typedef bandwidth-mbps {
    type uint64;
    units "megabits per second";
    description
      "Bandwidth values, expressed in megabits per second.";
  }

  typedef bandwidth-gbps {
    type uint64;
    units "gigabits per second";
    description
      "Bandwidth values, expressed in gigabits per second.";
  }

  identity backup-protection-type {
    description
      "Base identity for the backup protection type.";
  }

  identity backup-protection-link {
    base backup-protection-type;
    description
      "Backup provides link protection only.";
  }

  identity backup-protection-node-link {
    base backup-protection-type;
    description
      "Backup offers node (preferred) or link protection.";
  }

  identity bc-model-type {
    description
      "Base identity for the Diffserv-TE Bandwidth Constraints
       Model type.";
    reference
      "RFC 4124: Protocol Extensions for Support of Diffserv-aware
                 MPLS Traffic Engineering";
  }

  identity bc-model-rdm {
    base bc-model-type;
    description
      "Russian Dolls Bandwidth Constraints Model type.";
    reference
      "RFC 4127: Russian Dolls Bandwidth Constraints Model for
                 Diffserv-aware MPLS Traffic Engineering";
  }

  identity bc-model-mam {
    base bc-model-type;
    description
      "Maximum Allocation Bandwidth Constraints Model type.";
    reference
      "RFC 4125: Maximum Allocation Bandwidth Constraints Model for
                 Diffserv-aware MPLS Traffic Engineering";
  }

  identity bc-model-mar {
    base bc-model-type;
    description
      "Maximum Allocation with Reservation Bandwidth Constraints
       Model type.";
    reference
      "RFC 4126: Max Allocation with Reservation Bandwidth
                 Constraints Model for Diffserv-aware MPLS Traffic
                 Engineering & Performance Comparisons";
  }

  /*
   * Groupings
   */

  grouping performance-metrics-attributes-packet {
    description
      "Contains Performance Metrics (PM) information.";
    uses te-types:performance-metrics-attributes {
      augment "performance-metrics-one-way" {
        leaf one-way-min-delay {
          type uint32 {
            range "0..16777215";
          }
          units "microseconds";
          description
            "One-way minimum delay or latency.";
        }
        leaf one-way-min-delay-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description
            "One-way minimum delay or latency normality.";
        }
        leaf one-way-max-delay {
          type uint32 {
            range "0..16777215";
          }
          units "microseconds";
          description
            "One-way maximum delay or latency.";
        }
        leaf one-way-max-delay-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description
            "One-way maximum delay or latency normality.";
        }
        leaf one-way-delay-variation {
          type uint32 {
            range "0..16777215";
          }
          units "microseconds";
          description
            "One-way delay variation.";
          reference
            "RFC 5481: Packet Delay Variation Applicability
                       Statement, Section 4.2";
        }
        leaf one-way-delay-variation-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description
            "One-way delay variation normality.";
          reference
            "RFC 7471: OSPF Traffic Engineering (TE) Metric
                       Extensions
             RFC 8570: IS-IS Traffic Engineering (TE) Metric
                       Extensions
             RFC 7823: Performance-Based Path Selection for
                       Explicitly Routed Label Switched Paths (LSPs)
                       Using TE Metric Extensions";
        }
        leaf one-way-packet-loss {
          type decimal64 {
            fraction-digits 6;
            range "0..50.331642";
          }
          units "%";
          description
            "One-way packet loss as a percentage of the total traffic
             sent over a configurable interval.
             
             The finest precision is 0.000003%.";
          reference
            "RFC 8570: IS-IS Traffic Engineering (TE) Metric
                       Extensions, Section 4.4";
        }
        leaf one-way-packet-loss-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description
            "Packet loss normality.";
          reference
            "RFC 7471: OSPF Traffic Engineering (TE) Metric
                       Extensions
             RFC 8570: IS-IS Traffic Engineering (TE) Metric
                       Extensions
             RFC 7823: Performance-Based Path Selection for
                       Explicitly Routed Label Switched Paths (LSPs)
                       Using TE Metric Extensions";
        }
        description
          "Performance Metrics (PM) one-way packet-specific
           augmentation for a generic PM grouping.";
      }

      augment "performance-metrics-two-way" {
        leaf two-way-min-delay {
          type uint32 {
            range "0..16777215";
          }
          units "microseconds";
          default "0";
          description
            "Two-way minimum delay or latency.";
        }
        leaf two-way-min-delay-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description
            "Two-way minimum delay or latency normality.";
          reference
            "RFC 7471: OSPF Traffic Engineering (TE) Metric
                       Extensions
             RFC 8570: IS-IS Traffic Engineering (TE) Metric
                       Extensions
             RFC 7823: Performance-Based Path Selection for
                       Explicitly Routed Label Switched Paths (LSPs)
                       Using TE Metric Extensions";
        }
        leaf two-way-max-delay {
          type uint32 {
            range "0..16777215";
          }
          units "microseconds";
          default "0";
          description
            "Two-way maximum delay or latency.";
        }
        leaf two-way-max-delay-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description
            "Two-way maximum delay or latency normality.";
          reference
            "RFC 7471: OSPF Traffic Engineering (TE) Metric
                       Extensions
             RFC 8570: IS-IS Traffic Engineering (TE) Metric
                       Extensions
             RFC 7823: Performance-Based Path Selection for
                       Explicitly Routed Label Switched Paths (LSPs)
                       Using TE Metric Extensions";
        }
        leaf two-way-delay-variation {
          type uint32 {
            range "0..16777215";
          }
          units "microseconds";
          default "0";
          description
            "Two-way delay variation.";
          reference
            "RFC 5481: Packet Delay Variation Applicability
                       Statement, Section 4.2";
        }
        leaf two-way-delay-variation-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description
            "Two-way delay variation normality.";
          reference
            "RFC 7471: OSPF Traffic Engineering (TE) Metric
                       Extensions
             RFC 8570: IS-IS Traffic Engineering (TE) Metric
                       Extensions
             RFC 7823: Performance-Based Path Selection for
                       Explicitly Routed Label Switched Paths (LSPs)
                       Using TE Metric Extensions";
        }
        leaf two-way-packet-loss {
          type decimal64 {
            fraction-digits 6;
            range "0..50.331642";
          }
          units "%";
          default "0";
          description
            "Two-way packet loss as a percentage of the total traffic
             sent over a configurable interval.
             
             The finest precision is 0.000003%.";
        }
        leaf two-way-packet-loss-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description
            "Two-way packet loss normality.";
        }
        description
          "Performance Metrics (PM) two-way packet-specific
           augmentation for a generic PM grouping.";
        reference
          "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions
           RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions
           RFC 7823: Performance-Based Path Selection for Explicitly
                     Routed Label Switched Paths (LSPs) Using TE
                     Metric Extensions";
      }
    }
  }

  grouping one-way-performance-metrics-packet {
    description
      "One-way packet Performance Metrics (PM) throttle grouping.";
    leaf one-way-min-delay {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      default "0";
      description
        "One-way minimum delay or latency.";
    }
    leaf one-way-max-delay {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      default "0";
      description
        "One-way maximum delay or latency.";
    }
    leaf one-way-delay-variation {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      default "0";
      description
        "One-way delay variation.";
    }
    leaf one-way-packet-loss {
      type decimal64 {
        fraction-digits 6;
        range "0..50.331642";
      }
      units "%";
      default "0";
      description
        "One-way packet loss as a percentage of the total traffic
         sent over a configurable interval.
         
         The finest precision is 0.000003%.";
    }
  }

  grouping one-way-performance-metrics-gauge-packet {
    description
      "One-way packet Performance Metrics (PM) throttle grouping.

       This grouping is used to report the same metrics defined in
       the one-way-performance-metrics-packet grouping, using gauges
       instead of uint32 data types and referencing IPPM RFCs
       instead of IGP-TE RFCs.";
    leaf one-way-min-delay {
      type yang:gauge64;
      units "microseconds";
      description
        "One-way minimum delay or latency.";
    }
    leaf one-way-max-delay {
      type yang:gauge64;
      units "microseconds";
      description
        "One-way maximum delay or latency.";
      reference
        "RFC 7679: A One-Way Delay Metric for IP Performance
                   Metrics (IPPM)";
    }
    leaf one-way-delay-variation {
      type yang:gauge64;
      units "microseconds";
      description
        "One-way delay variation.";
      reference
        "RFC 3393: IP Packet Delay Variation Metric for IP
                   Performance Metrics (IPPM)";
    }
    leaf one-way-packet-loss {
      type decimal64 {
        fraction-digits 5;
        range "0..100";
      }
      description
        "The ratio of packets dropped to packets transmitted between
         two endpoints.";
      reference
        "RFC 7680: A One-Way Loss Metric for IP Performance
                   Metrics (IPPM)";
    }
  }

  grouping two-way-performance-metrics-packet {
    description
      "Two-way packet Performance Metrics (PM) throttle grouping.";
    leaf two-way-min-delay {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      default "0";
      description
        "Two-way minimum delay or latency.";
    }
    leaf two-way-max-delay {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      default "0";
      description
        "Two-way maximum delay or latency.";
    }
    leaf two-way-delay-variation {
      type uint32 {
        range "0..16777215";
      }
      units "microseconds";
      default "0";
      description
        "Two-way delay variation.";
    }
    leaf two-way-packet-loss {
      type decimal64 {
        fraction-digits 6;
        range "0..50.331642";
      }
      units "%";
      default "0";
      description
        "Two-way packet loss as a percentage of the total traffic
         sent over a configurable interval.
         
         The finest precision is 0.000003%.";
    }
  }

  grouping two-way-performance-metrics-gauge-packet {
    description
      "Two-way packet Performance Metrics (PM) throttle grouping.

       This grouping is used to report the same metrics defined in
       the two-way-performance-metrics-packet grouping, using gauges
       instead of uint32 data types and referencing IPPM RFCs
       instead of IGP-TE RFCs.";
    leaf two-way-min-delay {
      type yang:gauge64;
      units "microseconds";
      description
        "Two-way minimum delay or latency.";
      reference
        "RFC 2681: A Round-trip Delay Metric for IPPM";
    }
    leaf two-way-max-delay {
      type yang:gauge64;
      units "microseconds";
      description
        "Two-way maximum delay or latency.";
      reference
        "RFC 2681: A Round-trip Delay Metric for IPPM";
    }
    leaf two-way-delay-variation {
      type yang:gauge64;
      units "microseconds";
      description
        "Two-way delay variation.";
      reference
        "RFC 5481: Packet Delay Variation Applicability Statement";
    }
    leaf two-way-packet-loss {
      type decimal64 {
        fraction-digits 5;
        range "0..100";
      }
      description
        "The ratio of packets dropped to packets transmitted between
         two endpoints.";
    }
  }

  grouping performance-metrics-throttle-container-packet {
    description
      "Packet Performance Metrics (PM) threshold grouping.";
    uses te-types:performance-metrics-throttle-container {
      augment "throttle/threshold-out" {
        uses one-way-performance-metrics-packet;
        uses two-way-performance-metrics-packet;
        description
          "Performance Metrics (PM) threshold-out packet
           augmentation for a generic grouping.";
      }
      augment "throttle/threshold-in" {
        uses one-way-performance-metrics-packet;
        uses two-way-performance-metrics-packet;
        description
          "Performance Metrics (PM) threshold-in packet augmentation
           for a generic grouping.";
      }
      augment "throttle/threshold-accelerated-advertisement" {
        uses one-way-performance-metrics-packet;
        uses two-way-performance-metrics-packet;
        description
          "Performance Metrics (PM) accelerated advertisement packet
           augmentation for a generic grouping.";
      }
    }
  }

  grouping bandwidth-profile-parameters {
    description
      "Common parameters to define bandwidth profiles in packet
       networks.";
    leaf cir {
      type uint64;
      units "bits per second";
      description
        "Committed Information Rate (CIR).";
    }
    leaf cbs {
      type uint64;
      units "bytes";
      description
        "Committed Burst Size (CBS).";
    }
    leaf eir {
      type uint64;
      units "bits per second";
      description
        "Excess Information Rate (EIR).";
    }
    leaf ebs {
      type uint64;
      units "bytes";
      description
        "Excess Burst Size (EBS).";
    }
    leaf pir {
      type uint64;
      units "bits per second";
      description
        "Peak Information Rate (PIR).";
    }
    leaf pbs {
      type uint64;
      units "bytes";
      description
        "Peak Burst Size (PBS).";
    }
  }

  grouping te-packet-path-bandwidth {
    description
      "Bandwidth attributes for TE Packet paths.";
    container packet-bandwidth {
      description
        "Bandwidth attributes for TE Packet paths.";
      leaf specification-type {
        type te-bandwidth-requested-type;
        description
          "The bandwidth specification type, either explicitly
           specified or automatically computed.";
      }
      leaf set-bandwidth {
        when "../specification-type = 'specified-value'" {
          description
            "When the bandwidth value is explicitly specified.";
        }
        type bandwidth-kbps;
        description
          "Set the bandwidth value explicitly, e.g., using offline
           calculation.";
      }
      container bandwidth-profile {
        when "../specification-type = 'specified-profile'" {
          description
            "When the bandwidth profile is explicitly specified.";
        }
        description
          "Set the bandwidth profile attributes explicitly.";
        leaf bandwidth-profile-name {
          type string;
          description
            "Name of Bandwidth Profile.";
        }
        leaf bandwidth-profile-type {
          type identityref {
            base bandwidth-profile-type;
          }
          description
            "Type of Bandwidth Profile.";
        }
        uses bandwidth-profile-parameters;
      }
      leaf class-type {
        type te-types:te-ds-class;
        description
          "The Class-Type of traffic transported by the LSP.";
        reference
          "RFC 4124: Protocol Extensions for Support of
                     Diffserv-aware MPLS Traffic Engineering,
                     Section 4.3.1";
      }
      leaf signaled-bandwidth {
        type te-packet-types:bandwidth-kbps;
        config false;
        description
          "The currently signaled bandwidth of the LSP.

           In the case where the bandwidth is specified
           explicitly, then this will match the value of the
           set-bandwidth leaf.

           In the cases where the bandwidth is dynamically
           computed by the system, the current value of the
           bandwidth should be reflected.";
      }
    }
  }

  grouping te-packet-link-bandwidth {
    description
      "Bandwidth attributes for Packet TE links.";
    leaf packet-bandwidth {
      type uint64;
      units "bits per second";
      description
        "Bandwidth value for Packet TE links.";
    }
  }
}
]]></sourcecode></figure>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>This document requests IANA to update the following URIs in the "IETF XML Registry" <xref target="RFC3688"/> to refer to this document:</t>

<figure><artwork><![CDATA[
      URI: urn:ietf:params:xml:ns:yang:ietf-te-types
      Registrant Contact:  The IESG.
      XML: N/A, the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-te-packet-types
      Registrant Contact:  The IESG.
      XML: N/A, the requested URI is an XML namespace.
]]></artwork></figure>

<t>This document requests IANA to register the following YANG modules in the "YANG Module Names" registry <xref target="RFC6020"/> within the "YANG Parameters" registry group.</t>

<figure><artwork><![CDATA[
      name:      ietf-te-types
      Maintained by IANA?  N
      namespace: urn:ietf:params:xml:ns:yang:ietf-te-types
      prefix:    te-types
      reference: RFC XXXX

      name:      ietf-te-packet-types
      Maintained by IANA?  N
      namespace: urn:ietf:params:xml:ns:yang:ietf-te-packet-types
      prefix:    te-packet-types
      reference: RFC XXXX
]]></artwork></figure>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>This section is modeled after the template described in Section 3.7
of <xref target="I-D.ietf-netmod-rfc8407bis"/>.</t>

<t>The "ietf-te-types" and the "ietf-te-packet-types" YANG modules define data models that are
designed to be accessed via YANG-based management protocols, such as
NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have to
use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, and
QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t>

<t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/>
provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.</t>

<t>The YANG modules define a set of identities, types, and
groupings. These nodes are intended to be reused by other YANG
modules. The modules by themselves do not expose any data nodes that
are writable, data nodes that contain read-only state, or RPCs.
As such, there are no additional security issues related to
the YANG module that need to be considered.</t>

<t>Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-related
information (e.g., 'node-example').</t>

</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">

<reference anchor="ITU-T_G.709" target="https://www.itu.int/rec/T-REC-G.709">
  <front>
    <title>Interfaces for the optical transport network</title>
    <author >
      <organization>International Telecommunication Union</organization>
    </author>
    <date year="2020" month="June"/>
  </front>
  <seriesInfo name="ITU-T G.709" value=""/>
</reference>


<reference anchor="RFC6020">
  <front>
    <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
    <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
    <date month="October" year="2010"/>
    <abstract>
      <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6020"/>
  <seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>

<reference anchor="RFC7950">
  <front>
    <title>The YANG 1.1 Data Modeling Language</title>
    <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
    <date month="August" year="2016"/>
    <abstract>
      <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7950"/>
  <seriesInfo name="DOI" value="10.17487/RFC7950"/>
</reference>

<reference anchor="RFC8342">
  <front>
    <title>Network Management Datastore Architecture (NMDA)</title>
    <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
    <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
    <author fullname="P. Shafer" initials="P." surname="Shafer"/>
    <author fullname="K. Watsen" initials="K." surname="Watsen"/>
    <author fullname="R. Wilton" initials="R." surname="Wilton"/>
    <date month="March" year="2018"/>
    <abstract>
      <t>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8342"/>
  <seriesInfo name="DOI" value="10.17487/RFC8342"/>
</reference>

<reference anchor="RFC8776">
  <front>
    <title>Common YANG Data Types for Traffic Engineering</title>
    <author fullname="T. Saad" initials="T." surname="Saad"/>
    <author fullname="R. Gandhi" initials="R." surname="Gandhi"/>
    <author fullname="X. Liu" initials="X." surname="Liu"/>
    <author fullname="V. Beeram" initials="V." surname="Beeram"/>
    <author fullname="I. Bryskin" initials="I." surname="Bryskin"/>
    <date month="June" year="2020"/>
    <abstract>
      <t>This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8776"/>
  <seriesInfo name="DOI" value="10.17487/RFC8776"/>
</reference>

<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>

<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>

<reference anchor="RFC6991">
  <front>
    <title>Common YANG Data Types</title>
    <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
    <date month="July" year="2013"/>
    <abstract>
      <t>This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6991"/>
  <seriesInfo name="DOI" value="10.17487/RFC6991"/>
</reference>

<reference anchor="RFC8294">
  <front>
    <title>Common YANG Data Types for the Routing Area</title>
    <author fullname="X. Liu" initials="X." surname="Liu"/>
    <author fullname="Y. Qu" initials="Y." surname="Qu"/>
    <author fullname="A. Lindem" initials="A." surname="Lindem"/>
    <author fullname="C. Hopps" initials="C." surname="Hopps"/>
    <author fullname="L. Berger" initials="L." surname="Berger"/>
    <date month="December" year="2017"/>
    <abstract>
      <t>This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8294"/>
  <seriesInfo name="DOI" value="10.17487/RFC8294"/>
</reference>

<reference anchor="RFC7471">
  <front>
    <title>OSPF Traffic Engineering (TE) Metric Extensions</title>
    <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
    <author fullname="D. Ward" initials="D." surname="Ward"/>
    <author fullname="J. Drake" initials="J." surname="Drake"/>
    <author fullname="A. Atlas" initials="A." surname="Atlas"/>
    <author fullname="S. Previdi" initials="S." surname="Previdi"/>
    <date month="March" year="2015"/>
    <abstract>
      <t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.</t>
      <t>This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.</t>
      <t>Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7471"/>
  <seriesInfo name="DOI" value="10.17487/RFC7471"/>
</reference>

<reference anchor="RFC8570">
  <front>
    <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
    <author fullname="L. Ginsberg" initials="L." role="editor" surname="Ginsberg"/>
    <author fullname="S. Previdi" initials="S." role="editor" surname="Previdi"/>
    <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
    <author fullname="D. Ward" initials="D." surname="Ward"/>
    <author fullname="J. Drake" initials="J." surname="Drake"/>
    <author fullname="Q. Wu" initials="Q." surname="Wu"/>
    <date month="March" year="2019"/>
    <abstract>
      <t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</t>
      <t>This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</t>
      <t>Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</t>
      <t>This document obsoletes RFC 7810.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8570"/>
  <seriesInfo name="DOI" value="10.17487/RFC8570"/>
</reference>

<reference anchor="RFC3209">
  <front>
    <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
    <author fullname="D. Awduche" initials="D." surname="Awduche"/>
    <author fullname="L. Berger" initials="L." surname="Berger"/>
    <author fullname="D. Gan" initials="D." surname="Gan"/>
    <author fullname="T. Li" initials="T." surname="Li"/>
    <author fullname="V. Srinivasan" initials="V." surname="Srinivasan"/>
    <author fullname="G. Swallow" initials="G." surname="Swallow"/>
    <date month="December" year="2001"/>
    <abstract>
      <t>This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3209"/>
  <seriesInfo name="DOI" value="10.17487/RFC3209"/>
</reference>

<reference anchor="RFC3477">
  <front>
    <title>Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)</title>
    <author fullname="K. Kompella" initials="K." surname="Kompella"/>
    <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
    <date month="January" year="2003"/>
    <abstract>
      <t>Current signalling used by Multi-Protocol Label Switching Traffic Engineering (MPLS TE) does not provide support for unnumbered links. This document defines procedures and extensions to Resource ReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels (RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3477"/>
  <seriesInfo name="DOI" value="10.17487/RFC3477"/>
</reference>

<reference anchor="RFC4124">
  <front>
    <title>Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering</title>
    <author fullname="F. Le Faucheur" initials="F." role="editor" surname="Le Faucheur"/>
    <date month="June" year="2005"/>
    <abstract>
      <t>This document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4124"/>
  <seriesInfo name="DOI" value="10.17487/RFC4124"/>
</reference>

<reference anchor="RFC6370">
  <front>
    <title>MPLS Transport Profile (MPLS-TP) Identifiers</title>
    <author fullname="M. Bocci" initials="M." surname="Bocci"/>
    <author fullname="G. Swallow" initials="G." surname="Swallow"/>
    <author fullname="E. Gray" initials="E." surname="Gray"/>
    <date month="September" year="2011"/>
    <abstract>
      <t>This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions compatible with IP/ MPLS conventions.</t>
      <t>This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6370"/>
  <seriesInfo name="DOI" value="10.17487/RFC6370"/>
</reference>

<reference anchor="RFC5003">
  <front>
    <title>Attachment Individual Identifier (AII) Types for Aggregation</title>
    <author fullname="C. Metz" initials="C." surname="Metz"/>
    <author fullname="L. Martini" initials="L." surname="Martini"/>
    <author fullname="F. Balus" initials="F." surname="Balus"/>
    <author fullname="J. Sugimoto" initials="J." surname="Sugimoto"/>
    <date month="September" year="2007"/>
    <abstract>
      <t>The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and Virtual Private Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5003"/>
  <seriesInfo name="DOI" value="10.17487/RFC5003"/>
</reference>

<reference anchor="RFC3630">
  <front>
    <title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
    <author fullname="D. Katz" initials="D." surname="Katz"/>
    <author fullname="K. Kompella" initials="K." surname="Kompella"/>
    <author fullname="D. Yeung" initials="D." surname="Yeung"/>
    <date month="September" year="2003"/>
    <abstract>
      <t>This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3630"/>
  <seriesInfo name="DOI" value="10.17487/RFC3630"/>
</reference>

<reference anchor="RFC6827">
  <front>
    <title>Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols</title>
    <author fullname="A. Malis" initials="A." role="editor" surname="Malis"/>
    <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/>
    <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
    <date month="January" year="2013"/>
    <abstract>
      <t>The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).</t>
      <t>The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.</t>
      <t>The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.</t>
      <t>Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6827"/>
  <seriesInfo name="DOI" value="10.17487/RFC6827"/>
</reference>

<reference anchor="RFC5305">
  <front>
    <title>IS-IS Extensions for Traffic Engineering</title>
    <author fullname="T. Li" initials="T." surname="Li"/>
    <author fullname="H. Smit" initials="H." surname="Smit"/>
    <date month="October" year="2008"/>
    <abstract>
      <t>This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5305"/>
  <seriesInfo name="DOI" value="10.17487/RFC5305"/>
</reference>

<reference anchor="RFC6119">
  <front>
    <title>IPv6 Traffic Engineering in IS-IS</title>
    <author fullname="J. Harrison" initials="J." surname="Harrison"/>
    <author fullname="J. Berger" initials="J." surname="Berger"/>
    <author fullname="M. Bartlett" initials="M." surname="Bartlett"/>
    <date month="February" year="2011"/>
    <abstract>
      <t>This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6119"/>
  <seriesInfo name="DOI" value="10.17487/RFC6119"/>
</reference>

<reference anchor="RFC8345">
  <front>
    <title>A YANG Data Model for Network Topologies</title>
    <author fullname="A. Clemm" initials="A." surname="Clemm"/>
    <author fullname="J. Medved" initials="J." surname="Medved"/>
    <author fullname="R. Varga" initials="R." surname="Varga"/>
    <author fullname="N. Bahadur" initials="N." surname="Bahadur"/>
    <author fullname="H. Ananthakrishnan" initials="H." surname="Ananthakrishnan"/>
    <author fullname="X. Liu" initials="X." surname="Liu"/>
    <date month="March" year="2018"/>
    <abstract>
      <t>This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8345"/>
  <seriesInfo name="DOI" value="10.17487/RFC8345"/>
</reference>

<reference anchor="RFC4872">
  <front>
    <title>RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery</title>
    <author fullname="J.P. Lang" initials="J.P." role="editor" surname="Lang"/>
    <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
    <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
    <date month="May" year="2007"/>
    <abstract>
      <t>This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4872"/>
  <seriesInfo name="DOI" value="10.17487/RFC4872"/>
</reference>

<reference anchor="RFC7308">
  <front>
    <title>Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)</title>
    <author fullname="E. Osborne" initials="E." surname="Osborne"/>
    <date month="July" year="2014"/>
    <abstract>
      <t>MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).</t>
      <t>This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7308"/>
  <seriesInfo name="DOI" value="10.17487/RFC7308"/>
</reference>

<reference anchor="RFC4203">
  <front>
    <title>OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
    <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
    <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
    <date month="October" year="2005"/>
    <abstract>
      <t>This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4203"/>
  <seriesInfo name="DOI" value="10.17487/RFC4203"/>
</reference>

<reference anchor="RFC5307">
  <front>
    <title>IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
    <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
    <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
    <date month="October" year="2008"/>
    <abstract>
      <t>This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5307"/>
  <seriesInfo name="DOI" value="10.17487/RFC5307"/>
</reference>

<reference anchor="RFC3785">
  <front>
    <title>Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric</title>
    <author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur"/>
    <author fullname="R. Uppili" initials="R." surname="Uppili"/>
    <author fullname="A. Vedrenne" initials="A." surname="Vedrenne"/>
    <author fullname="P. Merckx" initials="P." surname="Merckx"/>
    <author fullname="T. Telkamp" initials="T." surname="Telkamp"/>
    <date month="May" year="2004"/>
    <abstract>
      <t>This document describes a common practice on how the existing metric of Interior Gateway Protocols (IGP) can be used as an alternative metric to the Traffic Engineering (TE) metric for Constraint Based Routing of MultiProtocol Label Switching (MPLS) Traffic Engineering tunnels. This effectively results in the ability to perform Constraint Based Routing with optimization of one metric (e.g., link bandwidth) for some Traffic Engineering tunnels (e.g., Data Trunks) while optimizing another metric (e.g., propagation delay) for some other tunnels with different requirements (e.g., Voice Trunks). No protocol extensions or modifications are required. This text documents current router implementations and deployment practices. 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="87"/>
  <seriesInfo name="RFC" value="3785"/>
  <seriesInfo name="DOI" value="10.17487/RFC3785"/>
</reference>

<reference anchor="RFC6378">
  <front>
    <title>MPLS Transport Profile (MPLS-TP) Linear Protection</title>
    <author fullname="Y. Weingarten" initials="Y." role="editor" surname="Weingarten"/>
    <author fullname="S. Bryant" initials="S." surname="Bryant"/>
    <author fullname="E. Osborne" initials="E." surname="Osborne"/>
    <author fullname="N. Sprecher" initials="N." surname="Sprecher"/>
    <author fullname="A. Fulignoli" initials="A." role="editor" surname="Fulignoli"/>
    <date month="October" year="2011"/>
    <abstract>
      <t>This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.</t>
      <t>This document addresses the functionality described in the MPLS-TP Survivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6378"/>
  <seriesInfo name="DOI" value="10.17487/RFC6378"/>
</reference>

<reference anchor="RFC4090">
  <front>
    <title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title>
    <author fullname="P. Pan" initials="P." role="editor" surname="Pan"/>
    <author fullname="G. Swallow" initials="G." role="editor" surname="Swallow"/>
    <author fullname="A. Atlas" initials="A." role="editor" surname="Atlas"/>
    <date month="May" year="2005"/>
    <abstract>
      <t>This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure.</t>
      <t>Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4090"/>
  <seriesInfo name="DOI" value="10.17487/RFC4090"/>
</reference>

<reference anchor="RFC5712">
  <front>
    <title>MPLS Traffic Engineering Soft Preemption</title>
    <author fullname="M. Meyer" initials="M." role="editor" surname="Meyer"/>
    <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
    <date month="January" year="2010"/>
    <abstract>
      <t>This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5712"/>
  <seriesInfo name="DOI" value="10.17487/RFC5712"/>
</reference>

<reference anchor="RFC4920">
  <front>
    <title>Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE</title>
    <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
    <author fullname="A. Satyanarayana" initials="A." surname="Satyanarayana"/>
    <author fullname="A. Iwata" initials="A." surname="Iwata"/>
    <author fullname="N. Fujita" initials="N." surname="Fujita"/>
    <author fullname="G. Ash" initials="G." surname="Ash"/>
    <date month="July" year="2007"/>
    <abstract>
      <t>In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.</t>
      <t>This document specifies crankback signaling extensions for use in MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3473. These extensions mean that the LSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4920"/>
  <seriesInfo name="DOI" value="10.17487/RFC4920"/>
</reference>

<reference anchor="RFC5420">
  <front>
    <title>Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)</title>
    <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
    <author fullname="D. Papadimitriou" initials="D." surname="Papadimitriou"/>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <author fullname="A. Ayyangar" initials="A." surname="Ayyangar"/>
    <date month="February" year="2009"/>
    <abstract>
      <t>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.</t>
      <t>This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.</t>
      <t>The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.</t>
      <t>This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5420"/>
  <seriesInfo name="DOI" value="10.17487/RFC5420"/>
</reference>

<reference anchor="RFC7570">
  <front>
    <title>Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)</title>
    <author fullname="C. Margaria" initials="C." role="editor" surname="Margaria"/>
    <author fullname="G. Martinelli" initials="G." surname="Martinelli"/>
    <author fullname="S. Balls" initials="S." surname="Balls"/>
    <author fullname="B. Wright" initials="B." surname="Wright"/>
    <date month="July" year="2015"/>
    <abstract>
      <t>RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7570"/>
  <seriesInfo name="DOI" value="10.17487/RFC7570"/>
</reference>

<reference anchor="RFC4875">
  <front>
    <title>Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
    <author fullname="R. Aggarwal" initials="R." role="editor" surname="Aggarwal"/>
    <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
    <author fullname="S. Yasukawa" initials="S." role="editor" surname="Yasukawa"/>
    <date month="May" year="2007"/>
    <abstract>
      <t>This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.</t>
      <t>There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4875"/>
  <seriesInfo name="DOI" value="10.17487/RFC4875"/>
</reference>

<reference anchor="RFC5151">
  <front>
    <title>Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions</title>
    <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
    <author fullname="A. Ayyangar" initials="A." surname="Ayyangar"/>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <date month="February" year="2008"/>
    <abstract>
      <t>This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering (MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance of Label Switched Paths that cross domain boundaries.</t>
      <t>For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains include Autonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5151"/>
  <seriesInfo name="DOI" value="10.17487/RFC5151"/>
</reference>

<reference anchor="RFC5150">
  <front>
    <title>Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)</title>
    <author fullname="A. Ayyangar" initials="A." surname="Ayyangar"/>
    <author fullname="K. Kompella" initials="K." surname="Kompella"/>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <author fullname="A. Farrel" initials="A." surname="Farrel"/>
    <date month="February" year="2008"/>
    <abstract>
      <t>In certain scenarios, there may be a need to combine several Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP. We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP. The constituent LSPs will be referred to as "LSP segments" (S-LSPs).</t>
      <t>This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how the LSPs can be managed using the GMPLS signaling and routing protocols.</t>
      <t>It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5150"/>
  <seriesInfo name="DOI" value="10.17487/RFC5150"/>
</reference>

<reference anchor="RFC6001">
  <front>
    <title>Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)</title>
    <author fullname="D. Papadimitriou" initials="D." surname="Papadimitriou"/>
    <author fullname="M. Vigoureux" initials="M." surname="Vigoureux"/>
    <author fullname="K. Shiomoto" initials="K." surname="Shiomoto"/>
    <author fullname="D. Brungard" initials="D." surname="Brungard"/>
    <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
    <date month="October" year="2010"/>
    <abstract>
      <t>There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).</t>
      <t>This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer / Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6001"/>
  <seriesInfo name="DOI" value="10.17487/RFC6001"/>
</reference>

<reference anchor="RFC6790">
  <front>
    <title>The Use of Entropy Labels in MPLS Forwarding</title>
    <author fullname="K. Kompella" initials="K." surname="Kompella"/>
    <author fullname="J. Drake" initials="J." surname="Drake"/>
    <author fullname="S. Amante" initials="S." surname="Amante"/>
    <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
    <author fullname="L. Yong" initials="L." surname="Yong"/>
    <date month="November" year="2012"/>
    <abstract>
      <t>Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6790"/>
  <seriesInfo name="DOI" value="10.17487/RFC6790"/>
</reference>

<reference anchor="RFC7260">
  <front>
    <title>GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration</title>
    <author fullname="A. Takacs" initials="A." surname="Takacs"/>
    <author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
    <author fullname="J. He" initials="J." surname="He"/>
    <date month="June" year="2014"/>
    <abstract>
      <t>Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7260"/>
  <seriesInfo name="DOI" value="10.17487/RFC7260"/>
</reference>

<reference anchor="RFC8001">
  <front>
    <title>RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information</title>
    <author fullname="F. Zhang" initials="F." role="editor" surname="Zhang"/>
    <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/>
    <author fullname="C. Margaria" initials="C." surname="Margaria"/>
    <author fullname="M. Hartley" initials="M." surname="Hartley"/>
    <author fullname="Z. Ali" initials="Z." surname="Ali"/>
    <date month="January" year="2017"/>
    <abstract>
      <t>This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8001"/>
  <seriesInfo name="DOI" value="10.17487/RFC8001"/>
</reference>

<reference anchor="RFC8149">
  <front>
    <title>RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)</title>
    <author fullname="T. Saad" initials="T." role="editor" surname="Saad"/>
    <author fullname="R. Gandhi" initials="R." role="editor" surname="Gandhi"/>
    <author fullname="Z. Ali" initials="Z." surname="Ali"/>
    <author fullname="R. Venator" initials="R." surname="Venator"/>
    <author fullname="Y. Kamite" initials="Y." surname="Kamite"/>
    <date month="April" year="2017"/>
    <abstract>
      <t>The reoptimization of a Point-to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point-to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8149"/>
  <seriesInfo name="DOI" value="10.17487/RFC8149"/>
</reference>

<reference anchor="RFC8169">
  <front>
    <title>Residence Time Measurement in MPLS Networks</title>
    <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
    <author fullname="S. Ruffini" initials="S." surname="Ruffini"/>
    <author fullname="E. Gray" initials="E." surname="Gray"/>
    <author fullname="J. Drake" initials="J." surname="Drake"/>
    <author fullname="S. Bryant" initials="S." surname="Bryant"/>
    <author fullname="A. Vainshtein" initials="A." surname="Vainshtein"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>This document specifies a new Generic Associated Channel (G-ACh) for Residence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.</t>
      <t>Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a Precision Time Protocol event message.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8169"/>
  <seriesInfo name="DOI" value="10.17487/RFC8169"/>
</reference>

<reference anchor="RFC6368">
  <front>
    <title>Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)</title>
    <author fullname="P. Marques" initials="P." surname="Marques"/>
    <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
    <author fullname="K. Patel" initials="K." surname="Patel"/>
    <author fullname="K. Kumaki" initials="K." surname="Kumaki"/>
    <author fullname="T. Yamagata" initials="T." surname="Yamagata"/>
    <date month="September" year="2011"/>
    <abstract>
      <t>This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6368"/>
  <seriesInfo name="DOI" value="10.17487/RFC6368"/>
</reference>

<reference anchor="RFC7271">
  <front>
    <title>MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators</title>
    <author fullname="J. Ryoo" initials="J." role="editor" surname="Ryoo"/>
    <author fullname="E. Gray" initials="E." role="editor" surname="Gray"/>
    <author fullname="H. van Helvoort" initials="H." surname="van Helvoort"/>
    <author fullname="A. D'Alessandro" initials="A." surname="D'Alessandro"/>
    <author fullname="T. Cheung" initials="T." surname="Cheung"/>
    <author fullname="E. Osborne" initials="E." surname="Osborne"/>
    <date month="June" year="2014"/>
    <abstract>
      <t>This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.</t>
      <t>This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode.</t>
      <t>This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.</t>
      <t>This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7271"/>
  <seriesInfo name="DOI" value="10.17487/RFC7271"/>
</reference>

<reference anchor="RFC6780">
  <front>
    <title>RSVP ASSOCIATION Object Extensions</title>
    <author fullname="L. Berger" initials="L." surname="Berger"/>
    <author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur"/>
    <author fullname="A. Narayanan" initials="A." surname="Narayanan"/>
    <date month="October" year="2012"/>
    <abstract>
      <t>The RSVP ASSOCIATION object was defined in the context of GMPLS-controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6780"/>
  <seriesInfo name="DOI" value="10.17487/RFC6780"/>
</reference>

<reference anchor="RFC4873">
  <front>
    <title>GMPLS Segment Recovery</title>
    <author fullname="L. Berger" initials="L." surname="Berger"/>
    <author fullname="I. Bryskin" initials="I." surname="Bryskin"/>
    <author fullname="D. Papadimitriou" initials="D." surname="Papadimitriou"/>
    <author fullname="A. Farrel" initials="A." surname="Farrel"/>
    <date month="May" year="2007"/>
    <abstract>
      <t>This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4873"/>
  <seriesInfo name="DOI" value="10.17487/RFC4873"/>
</reference>

<reference anchor="RFC8800">
  <front>
    <title>Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling</title>
    <author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
    <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
    <author fullname="C. Barth" initials="C." surname="Barth"/>
    <author fullname="M. Negi" initials="M." surname="Negi"/>
    <date month="July" year="2020"/>
    <abstract>
      <t>This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8800"/>
  <seriesInfo name="DOI" value="10.17487/RFC8800"/>
</reference>

<reference anchor="RFC5541">
  <front>
    <title>Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)</title>
    <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <author fullname="Y. Lee" initials="Y." surname="Lee"/>
    <date month="June" year="2009"/>
    <abstract>
      <t>The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).</t>
      <t>In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.</t>
      <t>This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.</t>
      <t>This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5541"/>
  <seriesInfo name="DOI" value="10.17487/RFC5541"/>
</reference>

<reference anchor="RFC3471">
  <front>
    <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description</title>
    <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
    <date month="January" year="2003"/>
    <abstract>
      <t>This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="3471"/>
  <seriesInfo name="DOI" value="10.17487/RFC3471"/>
</reference>

<reference anchor="RFC4328">
  <front>
    <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control</title>
    <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
    <date month="January" year="2006"/>
    <abstract>
      <t>This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4328"/>
  <seriesInfo name="DOI" value="10.17487/RFC4328"/>
</reference>

<reference anchor="RFC6004">
  <front>
    <title>Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching</title>
    <author fullname="L. Berger" initials="L." surname="Berger"/>
    <author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
    <date month="October" year="2010"/>
    <abstract>
      <t>This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF- and ITU-defined parameters is also covered.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6004"/>
  <seriesInfo name="DOI" value="10.17487/RFC6004"/>
</reference>

<reference anchor="RFC6002">
  <front>
    <title>Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions</title>
    <author fullname="L. Berger" initials="L." surname="Berger"/>
    <author fullname="D. Fedyk" initials="D." surname="Fedyk"/>
    <date month="October" year="2010"/>
    <abstract>
      <t>This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6002"/>
  <seriesInfo name="DOI" value="10.17487/RFC6002"/>
</reference>

<reference anchor="RFC7074">
  <front>
    <title>Revised Definition of the GMPLS Switching Capability and Type Fields</title>
    <author fullname="L. Berger" initials="L." surname="Berger"/>
    <author fullname="J. Meuric" initials="J." surname="Meuric"/>
    <date month="November" year="2013"/>
    <abstract>
      <t>GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7074"/>
  <seriesInfo name="DOI" value="10.17487/RFC7074"/>
</reference>

<reference anchor="RFC7138">
  <front>
    <title>Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks</title>
    <author fullname="D. Ceccarelli" initials="D." role="editor" surname="Ceccarelli"/>
    <author fullname="F. Zhang" initials="F." surname="Zhang"/>
    <author fullname="S. Belotti" initials="S." surname="Belotti"/>
    <author fullname="R. Rao" initials="R." surname="Rao"/>
    <author fullname="J. Drake" initials="J." surname="Drake"/>
    <date month="March" year="2014"/>
    <abstract>
      <t>This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7138"/>
  <seriesInfo name="DOI" value="10.17487/RFC7138"/>
</reference>

<reference anchor="RFC5440">
  <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="RFC8233">
  <front>
    <title>Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)</title>
    <author fullname="D. Dhody" initials="D." surname="Dhody"/>
    <author fullname="Q. Wu" initials="Q." surname="Wu"/>
    <author fullname="V. Manral" initials="V." surname="Manral"/>
    <author fullname="Z. Ali" initials="Z." surname="Ali"/>
    <author fullname="K. Kumaki" initials="K." surname="Kumaki"/>
    <date month="September" year="2017"/>
    <abstract>
      <t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.</t>
      <t>IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. 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. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8233"/>
  <seriesInfo name="DOI" value="10.17487/RFC8233"/>
</reference>

<reference anchor="RFC8685">
  <front>
    <title>Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture</title>
    <author fullname="F. Zhang" initials="F." surname="Zhang"/>
    <author fullname="Q. Zhao" initials="Q." surname="Zhao"/>
    <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/>
    <author fullname="R. Casellas" initials="R." surname="Casellas"/>
    <author fullname="D. King" initials="D." surname="King"/>
    <date month="December" year="2019"/>
    <abstract>
      <t>The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.</t>
      <t>This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8685"/>
  <seriesInfo name="DOI" value="10.17487/RFC8685"/>
</reference>

<reference anchor="RFC5441">
  <front>
    <title>A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths</title>
    <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
    <author fullname="R. Zhang" initials="R." surname="Zhang"/>
    <author fullname="N. Bitar" initials="N." surname="Bitar"/>
    <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
    <date month="April" year="2009"/>
    <abstract>
      <t>The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5441"/>
  <seriesInfo name="DOI" value="10.17487/RFC5441"/>
</reference>

<reference anchor="RFC5520">
  <front>
    <title>Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism</title>
    <author fullname="R. Bradford" initials="R." role="editor" surname="Bradford"/>
    <author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
    <author fullname="A. Farrel" initials="A." surname="Farrel"/>
    <date month="April" year="2009"/>
    <abstract>
      <t>Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.</t>
      <t>This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5520"/>
  <seriesInfo name="DOI" value="10.17487/RFC5520"/>
</reference>

<reference anchor="RFC5557">
  <front>
    <title>Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization</title>
    <author fullname="Y. Lee" initials="Y." surname="Lee"/>
    <author fullname="JL. Le Roux" initials="JL." surname="Le Roux"/>
    <author fullname="D. King" initials="D." surname="King"/>
    <author fullname="E. Oki" initials="E." surname="Oki"/>
    <date month="July" year="2009"/>
    <abstract>
      <t>The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.</t>
      <t>This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5557"/>
  <seriesInfo name="DOI" value="10.17487/RFC5557"/>
</reference>

<reference anchor="RFC8306">
  <front>
    <title>Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths</title>
    <author fullname="Q. Zhao" initials="Q." surname="Zhao"/>
    <author fullname="D. Dhody" initials="D." role="editor" surname="Dhody"/>
    <author fullname="R. Palleti" initials="R." surname="Palleti"/>
    <author fullname="D. King" initials="D." surname="King"/>
    <date month="November" year="2017"/>
    <abstract>
      <t>Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.</t>
      <t>This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.</t>
      <t>This document obsoletes RFC 6006.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8306"/>
  <seriesInfo name="DOI" value="10.17487/RFC8306"/>
</reference>

<reference anchor="RFC9012">
  <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="RFC4202">
  <front>
    <title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
    <author fullname="K. Kompella" initials="K." role="editor" surname="Kompella"/>
    <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
    <date month="October" year="2005"/>
    <abstract>
      <t>This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4202"/>
  <seriesInfo name="DOI" value="10.17487/RFC4202"/>
</reference>

<reference anchor="RFC4561">
  <front>
    <title>Definition of a Record Route Object (RRO) Node-Id Sub-Object</title>
    <author fullname="J.-P. Vasseur" initials="J.-P." role="editor" surname="Vasseur"/>
    <author fullname="Z. Ali" initials="Z." surname="Ali"/>
    <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
    <date month="June" year="2006"/>
    <abstract>
      <t>In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4561"/>
  <seriesInfo name="DOI" value="10.17487/RFC4561"/>
</reference>

<reference anchor="RFC6511">
  <front>
    <title>Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths</title>
    <author fullname="Z. Ali" initials="Z." surname="Ali"/>
    <author fullname="G. Swallow" initials="G." surname="Swallow"/>
    <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
    <date month="February" year="2012"/>
    <abstract>
      <t>There are many deployment scenarios that require an egress Label Switching Router (LSR) to receive binding of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6511"/>
  <seriesInfo name="DOI" value="10.17487/RFC6511"/>
</reference>

<reference anchor="RFC7139">
  <front>
    <title>GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks</title>
    <author fullname="F. Zhang" initials="F." role="editor" surname="Zhang"/>
    <author fullname="G. Zhang" initials="G." surname="Zhang"/>
    <author fullname="S. Belotti" initials="S." surname="Belotti"/>
    <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
    <author fullname="K. Pithewan" initials="K." surname="Pithewan"/>
    <date month="March" year="2014"/>
    <abstract>
      <t>ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.</t>
      <t>This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7139"/>
  <seriesInfo name="DOI" value="10.17487/RFC7139"/>
</reference>

<reference anchor="RFC7551">
  <front>
    <title>RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)</title>
    <author fullname="F. Zhang" initials="F." role="editor" surname="Zhang"/>
    <author fullname="R. Jing" initials="R." surname="Jing"/>
    <author fullname="R. Gandhi" initials="R." role="editor" surname="Gandhi"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. The REVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7551"/>
  <seriesInfo name="DOI" value="10.17487/RFC7551"/>
</reference>

<reference anchor="RFC7571">
  <front>
    <title>GMPLS RSVP-TE Extensions for Lock Instruct and Loopback</title>
    <author fullname="J. Dong" initials="J." surname="Dong"/>
    <author fullname="M. Chen" initials="M." surname="Chen"/>
    <author fullname="Z. Li" initials="Z." surname="Li"/>
    <author fullname="D. Ceccarelli" initials="D." surname="Ceccarelli"/>
    <date month="July" year="2015"/>
    <abstract>
      <t>This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7571"/>
  <seriesInfo name="DOI" value="10.17487/RFC7571"/>
</reference>

<reference anchor="RFC7579">
  <front>
    <title>General Network Element Constraint Encoding for GMPLS-Controlled Networks</title>
    <author fullname="G. Bernstein" initials="G." role="editor" surname="Bernstein"/>
    <author fullname="Y. Lee" initials="Y." role="editor" surname="Lee"/>
    <author fullname="D. Li" initials="D." surname="Li"/>
    <author fullname="W. Imajuku" initials="W." surname="Imajuku"/>
    <author fullname="J. Han" initials="J." surname="Han"/>
    <date month="June" year="2015"/>
    <abstract>
      <t>Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.</t>
      <t>This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7579"/>
  <seriesInfo name="DOI" value="10.17487/RFC7579"/>
</reference>

<reference anchor="RFC8341">
  <front>
    <title>Network Configuration Access Control Model</title>
    <author fullname="A. Bierman" initials="A." surname="Bierman"/>
    <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
    <date month="March" year="2018"/>
    <abstract>
      <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
      <t>This document obsoletes RFC 6536.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="91"/>
  <seriesInfo name="RFC" value="8341"/>
  <seriesInfo name="DOI" value="10.17487/RFC8341"/>
</reference>




    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="MEF_10.3" target="https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_10.pdf">
  <front>
    <title>Ethernet Services Attributes Phase 3</title>
    <author >
      <organization>MEF</organization>
    </author>
    <date year="2013" month="October"/>
  </front>
  <seriesInfo name="MEF 10.3" value=""/>
</reference>


<reference anchor="RFC6241">
  <front>
    <title>Network Configuration Protocol (NETCONF)</title>
    <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
    <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
    <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
    <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
    <date month="June" year="2011"/>
    <abstract>
      <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6241"/>
  <seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>

<reference anchor="RFC8040">
  <front>
    <title>RESTCONF Protocol</title>
    <author fullname="A. Bierman" initials="A." surname="Bierman"/>
    <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
    <author fullname="K. Watsen" initials="K." surname="Watsen"/>
    <date month="January" year="2017"/>
    <abstract>
      <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8040"/>
  <seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>


<reference anchor="I-D.ietf-netmod-rfc8407bis">
   <front>
      <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
      <author fullname="Andy Bierman" initials="A." surname="Bierman">
         <organization>YumaWorks</organization>
      </author>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
         <organization>Orange</organization>
      </author>
      <author fullname="Qin Wu" initials="Q." surname="Wu">
         <organization>Huawei</organization>
      </author>
      <date day="14" month="January" year="2025"/>
      <abstract>
	 <t>   This memo provides guidelines for authors and reviewers of
   specifications containing YANG modules, including IANA-maintained
   modules.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG modules.  This document obsoletes
   RFC 8407.

   Also, this document updates RFC 8126 by providing additional
   guidelines for writing the IANA considerations for RFCs that specify
   IANA-maintained modules.  The document also updates RFC 6020 by
   clarifying how modules and their revisions are handled by IANA.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-22"/>
   
</reference>

<reference anchor="RFC8340">
  <front>
    <title>YANG Tree Diagrams</title>
    <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
    <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
    <date month="March" year="2018"/>
    <abstract>
      <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="215"/>
  <seriesInfo name="RFC" value="8340"/>
  <seriesInfo name="DOI" value="10.17487/RFC8340"/>
</reference>

<reference anchor="RFC7823">
  <front>
    <title>Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions</title>
    <author fullname="A. Atlas" initials="A." surname="Atlas"/>
    <author fullname="J. Drake" initials="J." surname="Drake"/>
    <author fullname="S. Giacalone" initials="S." surname="Giacalone"/>
    <author fullname="S. Previdi" initials="S." surname="Previdi"/>
    <date month="May" year="2016"/>
    <abstract>
      <t>In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7823"/>
  <seriesInfo name="DOI" value="10.17487/RFC7823"/>
</reference>

<reference anchor="RFC4427">
  <front>
    <title>Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)</title>
    <author fullname="E. Mannie" initials="E." role="editor" surname="Mannie"/>
    <author fullname="D. Papadimitriou" initials="D." role="editor" surname="Papadimitriou"/>
    <date month="March" year="2006"/>
    <abstract>
      <t>This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4427"/>
  <seriesInfo name="DOI" value="10.17487/RFC4427"/>
</reference>

<reference anchor="RFC4736">
  <front>
    <title>Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)</title>
    <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/>
    <author fullname="Y. Ikejiri" initials="Y." surname="Ikejiri"/>
    <author fullname="R. Zhang" initials="R." surname="Zhang"/>
    <date month="November" year="2006"/>
    <abstract>
      <t>This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) Label Switched Paths (LSPs) signaled with Resource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end Label Switching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists (compared to the current path) or that the TE LSP must be reoptimized (because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (Interior Gateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4736"/>
  <seriesInfo name="DOI" value="10.17487/RFC4736"/>
</reference>

<reference anchor="RFC2702">
  <front>
    <title>Requirements for Traffic Engineering Over MPLS</title>
    <author fullname="D. Awduche" initials="D." surname="Awduche"/>
    <author fullname="J. Malcolm" initials="J." surname="Malcolm"/>
    <author fullname="J. Agogbua" initials="J." surname="Agogbua"/>
    <author fullname="M. O'Dell" initials="M." surname="O'Dell"/>
    <author fullname="J. McManus" initials="J." surname="McManus"/>
    <date month="September" year="1999"/>
    <abstract>
      <t>This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2702"/>
  <seriesInfo name="DOI" value="10.17487/RFC2702"/>
</reference>


<reference anchor="I-D.ietf-pce-sid-algo-14">
   <front>
      <title>Carrying SR-Algorithm Information in PCE-based Networks.</title>
      <author fullname="Samuel Sidor" initials="S." surname="Sidor">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author fullname="Zoey Rose" initials="Z." surname="Rose">
         <organization>Cisco Systems, Inc.</organization>
      </author>
      <author fullname="Shaofu Peng" initials="S." surname="Peng">
         <organization>ZTE Corporation</organization>
      </author>
      <author fullname="Shuping Peng" initials="S." surname="Peng">
         <organization>Huawei Technologies</organization>
      </author>
      <author fullname="Andrew Stone" initials="A." surname="Stone">
         <organization>Nokia</organization>
      </author>
      <date day="25" month="September" year="2024"/>
      <abstract>
	 <t>   The SR-Algorithm associated with a Segment-ID (SID) defines the path
   computation algorithm used by Interior Gateway Protocols (IGPs).
   This information is available to controllers, such as the Path
   Computation Element (PCE), via topology learning.  This document
   proposes an approach for informing headend routers regarding the SR-
   Algorithm associated with each SID used in PCE-computed paths, as
   well as signaling a specific SR-Algorithm as a constraint to the PCE.


	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-pce-sid-algo-14"/>
   
</reference>

<reference anchor="RFC4125">
  <front>
    <title>Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering</title>
    <author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur"/>
    <author fullname="W. Lai" initials="W." surname="Lai"/>
    <date month="June" year="2005"/>
    <abstract>
      <t>This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. This memo defines an Experimental Protocol for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4125"/>
  <seriesInfo name="DOI" value="10.17487/RFC4125"/>
</reference>

<reference anchor="RFC4126">
  <front>
    <title>Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering &amp; Performance Comparisons</title>
    <author fullname="J. Ash" initials="J." surname="Ash"/>
    <date month="June" year="2005"/>
    <abstract>
      <t>This document complements the Diffserv-aware MPLS Traffic Engineering (DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) Bandwidth Constraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting a Bandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. This memo defines an Experimental Protocol for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4126"/>
  <seriesInfo name="DOI" value="10.17487/RFC4126"/>
</reference>

<reference anchor="RFC4127">
  <front>
    <title>Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering</title>
    <author fullname="F. Le Faucheur" initials="F." role="editor" surname="Le Faucheur"/>
    <date month="June" year="2005"/>
    <abstract>
      <t>This document provides specifications for one Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. This memo defines an Experimental Protocol for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4127"/>
  <seriesInfo name="DOI" value="10.17487/RFC4127"/>
</reference>

<reference anchor="RFC2697">
  <front>
    <title>A Single Rate Three Color Marker</title>
    <author fullname="J. Heinanen" initials="J." surname="Heinanen"/>
    <author fullname="R. Guerin" initials="R." surname="Guerin"/>
    <date month="September" year="1999"/>
    <abstract>
      <t>This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2697"/>
  <seriesInfo name="DOI" value="10.17487/RFC2697"/>
</reference>

<reference anchor="RFC2698">
  <front>
    <title>A Two Rate Three Color Marker</title>
    <author fullname="J. Heinanen" initials="J." surname="Heinanen"/>
    <author fullname="R. Guerin" initials="R." surname="Guerin"/>
    <date month="September" year="1999"/>
    <abstract>
      <t>This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2698"/>
  <seriesInfo name="DOI" value="10.17487/RFC2698"/>
</reference>

<reference anchor="RFC9522">
  <front>
    <title>Overview and Principles of Internet Traffic Engineering</title>
    <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/>
    <date month="January" year="2024"/>
    <abstract>
      <t>This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed.</t>
      <t>This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9522"/>
  <seriesInfo name="DOI" value="10.17487/RFC9522"/>
</reference>

<reference anchor="RFC4657">
  <front>
    <title>Path Computation Element (PCE) Communication Protocol Generic Requirements</title>
    <author fullname="J. Ash" initials="J." role="editor" surname="Ash"/>
    <author fullname="J.L. Le Roux" initials="J.L." role="editor" surname="Le Roux"/>
    <date month="September" year="2006"/>
    <abstract>
      <t>The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4657"/>
  <seriesInfo name="DOI" value="10.17487/RFC4657"/>
</reference>

<reference anchor="RFC3688">
  <front>
    <title>The IETF XML Registry</title>
    <author fullname="M. Mealling" initials="M." surname="Mealling"/>
    <date month="January" year="2004"/>
    <abstract>
      <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="81"/>
  <seriesInfo name="RFC" value="3688"/>
  <seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>

<reference anchor="RFC4252">
  <front>
    <title>The Secure Shell (SSH) Authentication Protocol</title>
    <author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
    <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/>
    <date month="January" year="2006"/>
    <abstract>
      <t>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4252"/>
  <seriesInfo name="DOI" value="10.17487/RFC4252"/>
</reference>

<reference anchor="RFC8446">
  <front>
    <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
    <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
    <date month="August" year="2018"/>
    <abstract>
      <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
      <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8446"/>
  <seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>

<reference anchor="RFC9000">
  <front>
    <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
    <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
    <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
    <date month="May" year="2021"/>
    <abstract>
      <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9000"/>
  <seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>




    </references>

</references>


<?line 5760?>

<section anchor="the-complete-schema-trees"><name>The Complete Schema Trees</name>

<t>This appendix presents the complete tree of the TE and Packet TE types data
model.
See <xref target="RFC8340"/> for an explanation of the symbols used.
The data type of every leaf node is shown near the right end of the corresponding line.</t>

<ul empty="true"><li>
  <t>Editors' Note: The YANG trees have been generated by pyang and have some bugs to be fixed before publication. Please manually fix the YANG tree before sending the document to the RFC EDITOR.</t>
</li></ul>

<section anchor="te-types-schema-tree"><name>TE Types Schema Tree</name>

<figure><artwork type="ascii-art"><![CDATA[
=============== NOTE: '\' line wrapping per RFC 8792 ================

module: ietf-te-types

  grouping te-bandwidth:
    +-- te-bandwidth
       +-- (technology)?
          +--:(generic)
             +-- generic?   te-bandwidth
  grouping te-label:
    +-- te-label
       +-- (technology)?
       |  +--:(generic)
       |     +-- generic?   rt-types:generalized-label
       +-- direction?       te-label-direction
  grouping te-topology-identifier:
    +-- te-topology-identifier
       +-- provider-id?   te-global-id
       +-- client-id?     te-global-id
       +-- topology-id?   te-topology-id
  grouping performance-metrics-one-way-delay-loss:
    +-- one-way-delay?             uint32
    +-- one-way-delay-normality?
            te-types:performance-metrics-normality
  grouping performance-metrics-two-way-delay-loss:
    +-- two-way-delay?             uint32
    +-- two-way-delay-normality?
            te-types:performance-metrics-normality
  grouping performance-metrics-one-way-bandwidth:
    +-- one-way-residual-bandwidth?
    |       rt-types:bandwidth-ieee-float32
    +-- one-way-residual-bandwidth-normality?
    |       te-types:performance-metrics-normality
    +-- one-way-available-bandwidth?
    |       rt-types:bandwidth-ieee-float32
    +-- one-way-available-bandwidth-normality?
    |       te-types:performance-metrics-normality
    +-- one-way-utilized-bandwidth?
    |       rt-types:bandwidth-ieee-float32
    +-- one-way-utilized-bandwidth-normality?
            te-types:performance-metrics-normality
  grouping one-way-performance-metrics:
    +-- one-way-delay?                 uint32
    +-- one-way-residual-bandwidth?
    |       rt-types:bandwidth-ieee-float32
    +-- one-way-available-bandwidth?
    |       rt-types:bandwidth-ieee-float32
    +-- one-way-utilized-bandwidth?
            rt-types:bandwidth-ieee-float32
  grouping two-way-performance-metrics:
    +-- two-way-delay?   uint32
  grouping performance-metrics-thresholds:
    +-- one-way-delay?                 uint32
    +-- one-way-residual-bandwidth?
    |       rt-types:bandwidth-ieee-float32
    +-- one-way-available-bandwidth?
    |       rt-types:bandwidth-ieee-float32
    +-- one-way-utilized-bandwidth?
    |       rt-types:bandwidth-ieee-float32
    +-- two-way-delay?                 uint32
  grouping performance-metrics-attributes:
    +-- performance-metrics-one-way
    |  +-- one-way-delay?                           uint32
    |  +-- one-way-delay-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-residual-bandwidth?
    |  |       rt-types:bandwidth-ieee-float32
    |  +-- one-way-residual-bandwidth-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-available-bandwidth?
    |  |       rt-types:bandwidth-ieee-float32
    |  +-- one-way-available-bandwidth-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-utilized-bandwidth?
    |  |       rt-types:bandwidth-ieee-float32
    |  +-- one-way-utilized-bandwidth-normality?
    |          te-types:performance-metrics-normality
    +-- performance-metrics-two-way
       +-- two-way-delay?             uint32
       +-- two-way-delay-normality?
               te-types:performance-metrics-normality
  grouping performance-metrics-throttle-container:
    +-- throttle
       +-- one-way-delay-offset?                  uint32
       +-- measure-interval?                      uint32
       +-- advertisement-interval?                uint32
       +-- suppression-interval?                  uint32
       +-- threshold-out
       |  +-- one-way-delay?                 uint32
       |  +-- one-way-residual-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- one-way-available-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- one-way-utilized-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- two-way-delay?                 uint32
       +-- threshold-in
       |  +-- one-way-delay?                 uint32
       |  +-- one-way-residual-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- one-way-available-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- one-way-utilized-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- two-way-delay?                 uint32
       +-- threshold-accelerated-advertisement
          +-- one-way-delay?                 uint32
          +-- one-way-residual-bandwidth?
          |       rt-types:bandwidth-ieee-float32
          +-- one-way-available-bandwidth?
          |       rt-types:bandwidth-ieee-float32
          +-- one-way-utilized-bandwidth?
          |       rt-types:bandwidth-ieee-float32
          +-- two-way-delay?                 uint32
  grouping explicit-route-hop:
    +-- (type)?
       +--:(numbered-node-hop)
       |  +-- numbered-node-hop
       |     +-- node-id-uri?   nw:node-id
       |     +-- node-id?       te-node-id
       |     +-- hop-type?      te-hop-type
       +--:(numbered-link-hop)
       |  +-- numbered-link-hop
       |     +-- link-tp-id    te-tp-id
       |     +-- hop-type?     te-hop-type
       |     +-- direction?    te-link-direction
       +--:(unnumbered-link-hop)
       |  +-- unnumbered-link-hop
       |     +-- link-tp-id-uri?   nt:tp-id
       |     +-- link-tp-id?       te-tp-id
       |     +-- node-id-uri?      nw:node-id
       |     +-- node-id?          te-node-id
       |     +-- hop-type?         te-hop-type
       |     +-- direction?        te-link-direction
       +--:(as-number)
       |  +-- as-number-hop
       |     +-- as-number    inet:as-number
       |     +-- hop-type?    te-hop-type
       +--:(label)
          +-- label-hop
             +-- te-label
                +-- (technology)?
                |  +--:(generic)
                |     +-- generic?   rt-types:generalized-label
                +-- direction?       te-label-direction
  grouping explicit-route-hop-with-srlg:
    +-- (type)?
       +--:(numbered-node-hop)
       |  +-- numbered-node-hop
       |     +-- node-id-uri?   nw:node-id
       |     +-- node-id?       te-node-id
       |     +-- hop-type?      te-hop-type
       +--:(numbered-link-hop)
       |  +-- numbered-link-hop
       |     +-- link-tp-id    te-tp-id
       |     +-- hop-type?     te-hop-type
       |     +-- direction?    te-link-direction
       +--:(unnumbered-link-hop)
       |  +-- unnumbered-link-hop
       |     +-- link-tp-id-uri?   nt:tp-id
       |     +-- link-tp-id?       te-tp-id
       |     +-- node-id-uri?      nw:node-id
       |     +-- node-id?          te-node-id
       |     +-- hop-type?         te-hop-type
       |     +-- direction?        te-link-direction
       +--:(as-number)
       |  +-- as-number-hop
       |     +-- as-number    inet:as-number
       |     +-- hop-type?    te-hop-type
       +--:(label)
       |  +-- label-hop
       |     +-- te-label
       |        +-- (technology)?
       |        |  +--:(generic)
       |        |     +-- generic?   rt-types:generalized-label
       |        +-- direction?       te-label-direction
       +--:(srlg)
          +-- srlg
             +-- srlg?   uint32
  grouping record-route-state:
    +-- index?                       uint32
    +-- (type)?
       +--:(numbered-node-hop)
       |  +-- numbered-node-hop
       |     +-- node-id-uri?   nw:node-id
       |     +-- node-id?       te-node-id
       |     +-- flags*         path-attribute-flags
       +--:(numbered-link-hop)
       |  +-- numbered-link-hop
       |     +-- link-tp-id    te-tp-id
       |     +-- flags*        path-attribute-flags
       +--:(unnumbered-link-hop)
       |  +-- unnumbered-link-hop
       |     +-- link-tp-id-uri?   nt:tp-id
       |     +-- link-tp-id?       te-tp-id
       |     +-- node-id-uri?      nw:node-id
       |     +-- node-id?          te-node-id
       |     +-- flags*            path-attribute-flags
       +--:(label)
          +-- label-hop
             +-- te-label
             |  +-- (technology)?
             |  |  +--:(generic)
             |  |     +-- generic?   rt-types:generalized-label
             |  +-- direction?       te-label-direction
             +-- flags*      path-attribute-flags
  grouping label-restriction-info:
    +-- restriction?    enumeration
    +-- index?          uint32
    +-- label-start
    |  +-- te-label
    |     +-- (technology)?
    |     |  +--:(generic)
    |     |     +-- generic?   rt-types:generalized-label
    |     +-- direction?       te-label-direction
    +-- label-end
    |  +-- te-label
    |     +-- (technology)?
    |     |  +--:(generic)
    |     |     +-- generic?   rt-types:generalized-label
    |     +-- direction?       te-label-direction
    +-- label-step
    |  +-- (technology)?
    |     +--:(generic)
    |        +-- generic?   int32
    +-- range-bitmap?   yang:hex-string
  grouping label-set-info:
    +-- label-restrictions
       +-- label-restriction* [index]
          +-- restriction?    enumeration
          +-- index?          uint32
          +-- label-start
          |  +-- te-label
          |     +-- (technology)?
          |     |  +--:(generic)
          |     |     +-- generic?   rt-types:generalized-label
          |     +-- direction?       te-label-direction
          +-- label-end
          |  +-- te-label
          |     +-- (technology)?
          |     |  +--:(generic)
          |     |     +-- generic?   rt-types:generalized-label
          |     +-- direction?       te-label-direction
          +-- label-step
          |  +-- (technology)?
          |     +--:(generic)
          |        +-- generic?   int32
          +-- range-bitmap?   yang:hex-string
  grouping optimization-metric-entry:
    +-- metric-type?                      identityref
    +-- weight?                           uint8
    +-- explicit-route-exclude-objects
    |  +-- route-object-exclude-object* [index]
    |     +-- index?                       uint32
    |     +-- (type)?
    |        +--:(numbered-node-hop)
    |        |  +-- numbered-node-hop
    |        |     +-- node-id-uri?   nw:node-id
    |        |     +-- node-id?       te-node-id
    |        |     +-- hop-type?      te-hop-type
    |        +--:(numbered-link-hop)
    |        |  +-- numbered-link-hop
    |        |     +-- link-tp-id    te-tp-id
    |        |     +-- hop-type?     te-hop-type
    |        |     +-- direction?    te-link-direction
    |        +--:(unnumbered-link-hop)
    |        |  +-- unnumbered-link-hop
    |        |     +-- link-tp-id-uri?   nt:tp-id
    |        |     +-- link-tp-id?       te-tp-id
    |        |     +-- node-id-uri?      nw:node-id
    |        |     +-- node-id?          te-node-id
    |        |     +-- hop-type?         te-hop-type
    |        |     +-- direction?        te-link-direction
    |        +--:(as-number)
    |        |  +-- as-number-hop
    |        |     +-- as-number    inet:as-number
    |        |     +-- hop-type?    te-hop-type
    |        +--:(label)
    |        |  +-- label-hop
    |        |     +-- te-label
    |        |        +-- (technology)?
    |        |        |  +--:(generic)
    |        |        |     +-- generic?   rt-types:generalized-label
    |        |        +-- direction?       te-label-direction
    |        +--:(srlg)
    |           +-- srlg
    |              +-- srlg?   uint32
    +-- explicit-route-include-objects
       +-- route-object-include-object* [index]
          +-- index?                       uint32
          +-- (type)?
             +--:(numbered-node-hop)
             |  +-- numbered-node-hop
             |     +-- node-id-uri?   nw:node-id
             |     +-- node-id?       te-node-id
             |     +-- hop-type?      te-hop-type
             +--:(numbered-link-hop)
             |  +-- numbered-link-hop
             |     +-- link-tp-id    te-tp-id
             |     +-- hop-type?     te-hop-type
             |     +-- direction?    te-link-direction
             +--:(unnumbered-link-hop)
             |  +-- unnumbered-link-hop
             |     +-- link-tp-id-uri?   nt:tp-id
             |     +-- link-tp-id?       te-tp-id
             |     +-- node-id-uri?      nw:node-id
             |     +-- node-id?          te-node-id
             |     +-- hop-type?         te-hop-type
             |     +-- direction?        te-link-direction
             +--:(as-number)
             |  +-- as-number-hop
             |     +-- as-number    inet:as-number
             |     +-- hop-type?    te-hop-type
             +--:(label)
                +-- label-hop
                   +-- te-label
                      +-- (technology)?
                      |  +--:(generic)
                      |     +-- generic?   rt-types:generalized-label
                      +-- direction?       te-label-direction
  grouping common-constraints:
    +-- te-bandwidth
    |  +-- (technology)?
    |     +--:(generic)
    |        +-- generic?   te-bandwidth
    +-- link-protection?   identityref
    +-- setup-priority?    uint8
    +-- hold-priority?     uint8
    +-- signaling-type?    identityref
  grouping tunnel-constraints:
    +-- network-id?               nw:network-id
    +-- te-topology-identifier
    |  +-- provider-id?   te-global-id
    |  +-- client-id?     te-global-id
    |  +-- topology-id?   te-topology-id
    +-- te-bandwidth
    |  +-- (technology)?
    |     +--:(generic)
    |        +-- generic?   te-bandwidth
    +-- link-protection?          identityref
    +-- setup-priority?           uint8
    +-- hold-priority?            uint8
    +-- signaling-type?           identityref
  grouping path-constraints-route-objects:
    +-- explicit-route-objects
       +-- route-object-exclude-always* [index]
       |  +-- index?                       uint32
       |  +-- (type)?
       |     +--:(numbered-node-hop)
       |     |  +-- numbered-node-hop
       |     |     +-- node-id-uri?   nw:node-id
       |     |     +-- node-id?       te-node-id
       |     |     +-- hop-type?      te-hop-type
       |     +--:(numbered-link-hop)
       |     |  +-- numbered-link-hop
       |     |     +-- link-tp-id    te-tp-id
       |     |     +-- hop-type?     te-hop-type
       |     |     +-- direction?    te-link-direction
       |     +--:(unnumbered-link-hop)
       |     |  +-- unnumbered-link-hop
       |     |     +-- link-tp-id-uri?   nt:tp-id
       |     |     +-- link-tp-id?       te-tp-id
       |     |     +-- node-id-uri?      nw:node-id
       |     |     +-- node-id?          te-node-id
       |     |     +-- hop-type?         te-hop-type
       |     |     +-- direction?        te-link-direction
       |     +--:(as-number)
       |     |  +-- as-number-hop
       |     |     +-- as-number    inet:as-number
       |     |     +-- hop-type?    te-hop-type
       |     +--:(label)
       |        +-- label-hop
       |           +-- te-label
       |              +-- (technology)?
       |              |  +--:(generic)
       |              |     +-- generic?   rt-types:generalized-label
       |              +-- direction?       te-label-direction
       +-- route-object-include-exclude* [index]
          +-- explicit-route-usage?        identityref
          +-- index?                       uint32
          +-- (type)?
             +--:(numbered-node-hop)
             |  +-- numbered-node-hop
             |     +-- node-id-uri?   nw:node-id
             |     +-- node-id?       te-node-id
             |     +-- hop-type?      te-hop-type
             +--:(numbered-link-hop)
             |  +-- numbered-link-hop
             |     +-- link-tp-id    te-tp-id
             |     +-- hop-type?     te-hop-type
             |     +-- direction?    te-link-direction
             +--:(unnumbered-link-hop)
             |  +-- unnumbered-link-hop
             |     +-- link-tp-id-uri?   nt:tp-id
             |     +-- link-tp-id?       te-tp-id
             |     +-- node-id-uri?      nw:node-id
             |     +-- node-id?          te-node-id
             |     +-- hop-type?         te-hop-type
             |     +-- direction?        te-link-direction
             +--:(as-number)
             |  +-- as-number-hop
             |     +-- as-number    inet:as-number
             |     +-- hop-type?    te-hop-type
             +--:(label)
             |  +-- label-hop
             |     +-- te-label
             |        +-- (technology)?
             |        |  +--:(generic)
             |        |     +-- generic?   rt-types:generalized-label
             |        +-- direction?       te-label-direction
             +--:(srlg)
                +-- srlg
                   +-- srlg?   uint32
  grouping path-route-include-objects:
    +-- route-object-include-object* [index]
       +-- index?                       uint32
       +-- (type)?
          +--:(numbered-node-hop)
          |  +-- numbered-node-hop
          |     +-- node-id-uri?   nw:node-id
          |     +-- node-id?       te-node-id
          |     +-- hop-type?      te-hop-type
          +--:(numbered-link-hop)
          |  +-- numbered-link-hop
          |     +-- link-tp-id    te-tp-id
          |     +-- hop-type?     te-hop-type
          |     +-- direction?    te-link-direction
          +--:(unnumbered-link-hop)
          |  +-- unnumbered-link-hop
          |     +-- link-tp-id-uri?   nt:tp-id
          |     +-- link-tp-id?       te-tp-id
          |     +-- node-id-uri?      nw:node-id
          |     +-- node-id?          te-node-id
          |     +-- hop-type?         te-hop-type
          |     +-- direction?        te-link-direction
          +--:(as-number)
          |  +-- as-number-hop
          |     +-- as-number    inet:as-number
          |     +-- hop-type?    te-hop-type
          +--:(label)
             +-- label-hop
                +-- te-label
                   +-- (technology)?
                   |  +--:(generic)
                   |     +-- generic?   rt-types:generalized-label
                   +-- direction?       te-label-direction
  grouping path-route-exclude-objects:
    +-- route-object-exclude-object* [index]
       +-- index?                       uint32
       +-- (type)?
          +--:(numbered-node-hop)
          |  +-- numbered-node-hop
          |     +-- node-id-uri?   nw:node-id
          |     +-- node-id?       te-node-id
          |     +-- hop-type?      te-hop-type
          +--:(numbered-link-hop)
          |  +-- numbered-link-hop
          |     +-- link-tp-id    te-tp-id
          |     +-- hop-type?     te-hop-type
          |     +-- direction?    te-link-direction
          +--:(unnumbered-link-hop)
          |  +-- unnumbered-link-hop
          |     +-- link-tp-id-uri?   nt:tp-id
          |     +-- link-tp-id?       te-tp-id
          |     +-- node-id-uri?      nw:node-id
          |     +-- node-id?          te-node-id
          |     +-- hop-type?         te-hop-type
          |     +-- direction?        te-link-direction
          +--:(as-number)
          |  +-- as-number-hop
          |     +-- as-number    inet:as-number
          |     +-- hop-type?    te-hop-type
          +--:(label)
          |  +-- label-hop
          |     +-- te-label
          |        +-- (technology)?
          |        |  +--:(generic)
          |        |     +-- generic?   rt-types:generalized-label
          |        +-- direction?       te-label-direction
          +--:(srlg)
             +-- srlg
                +-- srlg?   uint32
  grouping generic-path-metric-bounds:
    +-- path-metric-bounds
       +-- path-metric-bound* [metric-type]
          +-- metric-type?   identityref
          +-- upper-bound?   uint64
  grouping generic-path-optimization:
    +-- optimizations
    |  +-- (algorithm)?
    |     +--:(metric) {path-optimization-metric}?
    |     |  +-- optimization-metric* [metric-type]
    |     |  |  +-- metric-type?                      identityref
    |     |  |  +-- weight?                           uint8
    |     |  |  +-- explicit-route-exclude-objects
    |     |  |  |  +-- route-object-exclude-object* [index]
    |     |  |  |     +-- index?                       uint32
    |     |  |  |     +-- (type)?
    |     |  |  |        +--:(numbered-node-hop)
    |     |  |  |        |  +-- numbered-node-hop
    |     |  |  |        |     +-- node-id-uri?   nw:node-id
    |     |  |  |        |     +-- node-id?       te-node-id
    |     |  |  |        |     +-- hop-type?      te-hop-type
    |     |  |  |        +--:(numbered-link-hop)
    |     |  |  |        |  +-- numbered-link-hop
    |     |  |  |        |     +-- link-tp-id    te-tp-id
    |     |  |  |        |     +-- hop-type?     te-hop-type
    |     |  |  |        |     +-- direction?    te-link-direction
    |     |  |  |        +--:(unnumbered-link-hop)
    |     |  |  |        |  +-- unnumbered-link-hop
    |     |  |  |        |     +-- link-tp-id-uri?   nt:tp-id
    |     |  |  |        |     +-- link-tp-id?       te-tp-id
    |     |  |  |        |     +-- node-id-uri?      nw:node-id
    |     |  |  |        |     +-- node-id?          te-node-id
    |     |  |  |        |     +-- hop-type?         te-hop-type
    |     |  |  |        |     +-- direction?
    |     |  |  |        |             te-link-direction
    |     |  |  |        +--:(as-number)
    |     |  |  |        |  +-- as-number-hop
    |     |  |  |        |     +-- as-number    inet:as-number
    |     |  |  |        |     +-- hop-type?    te-hop-type
    |     |  |  |        +--:(label)
    |     |  |  |        |  +-- label-hop
    |     |  |  |        |     +-- te-label
    |     |  |  |        |        +-- (technology)?
    |     |  |  |        |        |  +--:(generic)
    |     |  |  |        |        |     +-- generic?
    |     |  |  |        |        |             rt-types:generalized\
                                                               -label
    |     |  |  |        |        +-- direction?
    |     |  |  |        |                te-label-direction
    |     |  |  |        +--:(srlg)
    |     |  |  |           +-- srlg
    |     |  |  |              +-- srlg?   uint32
    |     |  |  +-- explicit-route-include-objects
    |     |  |     +-- route-object-include-object* [index]
    |     |  |        +-- index?                       uint32
    |     |  |        +-- (type)?
    |     |  |           +--:(numbered-node-hop)
    |     |  |           |  +-- numbered-node-hop
    |     |  |           |     +-- node-id-uri?   nw:node-id
    |     |  |           |     +-- node-id?       te-node-id
    |     |  |           |     +-- hop-type?      te-hop-type
    |     |  |           +--:(numbered-link-hop)
    |     |  |           |  +-- numbered-link-hop
    |     |  |           |     +-- link-tp-id    te-tp-id
    |     |  |           |     +-- hop-type?     te-hop-type
    |     |  |           |     +-- direction?    te-link-direction
    |     |  |           +--:(unnumbered-link-hop)
    |     |  |           |  +-- unnumbered-link-hop
    |     |  |           |     +-- link-tp-id-uri?   nt:tp-id
    |     |  |           |     +-- link-tp-id?       te-tp-id
    |     |  |           |     +-- node-id-uri?      nw:node-id
    |     |  |           |     +-- node-id?          te-node-id
    |     |  |           |     +-- hop-type?         te-hop-type
    |     |  |           |     +-- direction?
    |     |  |           |             te-link-direction
    |     |  |           +--:(as-number)
    |     |  |           |  +-- as-number-hop
    |     |  |           |     +-- as-number    inet:as-number
    |     |  |           |     +-- hop-type?    te-hop-type
    |     |  |           +--:(label)
    |     |  |              +-- label-hop
    |     |  |                 +-- te-label
    |     |  |                    +-- (technology)?
    |     |  |                    |  +--:(generic)
    |     |  |                    |     +-- generic?
    |     |  |                    |             rt-types:generalized\
                                                               -label
    |     |  |                    +-- direction?
    |     |  |                            te-label-direction
    |     |  x-- tiebreakers
    |     |     x-- tiebreaker* [tiebreaker-type]
    |     |        x-- tiebreaker-type?   identityref
    |     +--:(objective-function)
    |              {path-optimization-objective-function}?
    |        +-- objective-function
    |           +-- objective-function-type?   identityref
    +-- tiebreaker?      identityref
  grouping generic-path-affinities:
    +-- path-affinities-values
    |  +-- path-affinities-value* [usage]
    |     +-- usage?   identityref
    |     +-- value?   admin-groups
    +-- path-affinity-names
       +-- path-affinity-name* [usage]
          +-- usage?           identityref
          +-- affinity-name* [name]
             +-- name?   string
  grouping generic-path-srlgs:
    +-- path-srlgs-lists
    |  +-- path-srlgs-list* [usage]
    |     +-- usage?    identityref
    |     +-- values*   srlg
    +-- path-srlgs-names
       +-- path-srlgs-name* [usage]
          +-- usage?   identityref
          +-- names*   string
  grouping generic-path-disjointness:
    +-- disjointness?   te-path-disjointness
  grouping common-path-constraints-attributes:
    +-- te-bandwidth
    |  +-- (technology)?
    |     +--:(generic)
    |        +-- generic?   te-bandwidth
    +-- link-protection?          identityref
    +-- setup-priority?           uint8
    +-- hold-priority?            uint8
    +-- signaling-type?           identityref
    +-- path-metric-bounds
    |  +-- path-metric-bound* [metric-type]
    |     +-- metric-type?   identityref
    |     +-- upper-bound?   uint64
    +-- path-affinities-values
    |  +-- path-affinities-value* [usage]
    |     +-- usage?   identityref
    |     +-- value?   admin-groups
    +-- path-affinity-names
    |  +-- path-affinity-name* [usage]
    |     +-- usage?           identityref
    |     +-- affinity-name* [name]
    |        +-- name?   string
    +-- path-srlgs-lists
    |  +-- path-srlgs-list* [usage]
    |     +-- usage?    identityref
    |     +-- values*   srlg
    +-- path-srlgs-names
       +-- path-srlgs-name* [usage]
          +-- usage?   identityref
          +-- names*   string
  grouping generic-path-constraints:
    +-- path-constraints
       +-- te-bandwidth
       |  +-- (technology)?
       |     +--:(generic)
       |        +-- generic?   te-bandwidth
       +-- link-protection?          identityref
       +-- setup-priority?           uint8
       +-- hold-priority?            uint8
       +-- signaling-type?           identityref
       +-- path-metric-bounds
       |  +-- path-metric-bound* [metric-type]
       |     +-- metric-type?   identityref
       |     +-- upper-bound?   uint64
       +-- path-affinities-values
       |  +-- path-affinities-value* [usage]
       |     +-- usage?   identityref
       |     +-- value?   admin-groups
       +-- path-affinity-names
       |  +-- path-affinity-name* [usage]
       |     +-- usage?           identityref
       |     +-- affinity-name* [name]
       |        +-- name?   string
       +-- path-srlgs-lists
       |  +-- path-srlgs-list* [usage]
       |     +-- usage?    identityref
       |     +-- values*   srlg
       +-- path-srlgs-names
       |  +-- path-srlgs-name* [usage]
       |     +-- usage?   identityref
       |     +-- names*   string
       +-- disjointness?             te-path-disjointness
  grouping generic-path-properties:
    +--ro path-properties
       +--ro path-metric* [metric-type]
       |  +--ro metric-type?          identityref
       |  +--ro accumulative-value?   uint64
       +--ro path-affinities-values
       |  +--ro path-affinities-value* [usage]
       |     +--ro usage?   identityref
       |     +--ro value?   admin-groups
       +--ro path-affinity-names
       |  +--ro path-affinity-name* [usage]
       |     +--ro usage?           identityref
       |     +--ro affinity-name* [name]
       |        +--ro name?   string
       +--ro path-srlgs-lists
       |  +--ro path-srlgs-list* [usage]
       |     +--ro usage?    identityref
       |     +--ro values*   srlg
       +--ro path-srlgs-names
       |  +--ro path-srlgs-name* [usage]
       |     +--ro usage?   identityref
       |     +--ro names*   string
       +--ro path-route-objects
          +--ro path-route-object* [index]
             +--ro index?                       uint32
             +--ro (type)?
                +--:(numbered-node-hop)
                |  +--ro numbered-node-hop
                |     +--ro node-id-uri?   nw:node-id
                |     +--ro node-id?       te-node-id
                |     +--ro hop-type?      te-hop-type
                +--:(numbered-link-hop)
                |  +--ro numbered-link-hop
                |     +--ro link-tp-id    te-tp-id
                |     +--ro hop-type?     te-hop-type
                |     +--ro direction?    te-link-direction
                +--:(unnumbered-link-hop)
                |  +--ro unnumbered-link-hop
                |     +--ro link-tp-id-uri?   nt:tp-id
                |     +--ro link-tp-id?       te-tp-id
                |     +--ro node-id-uri?      nw:node-id
                |     +--ro node-id?          te-node-id
                |     +--ro hop-type?         te-hop-type
                |     +--ro direction?        te-link-direction
                +--:(as-number)
                |  +--ro as-number-hop
                |     +--ro as-number    inet:as-number
                |     +--ro hop-type?    te-hop-type
                +--:(label)
                   +--ro label-hop
                      +--ro te-label
                         +--ro (technology)?
                         |  +--:(generic)
                         |     +--ro generic?
                         |             rt-types:generalized-label
                         +--ro direction?       te-label-direction
  grouping encoding-and-switching-type:
    +-- encoding?         identityref
    +-- switching-type?   identityref
  grouping te-generic-node-id:
    +-- id?     union
    +-- type?   enumeration
]]></artwork></figure>

</section>
<section anchor="packet-te-types-schema-tree"><name>Packet TE Types Schema Tree</name>

<figure><artwork type="ascii-art"><![CDATA[
module: ietf-te-packet-types

  grouping performance-metrics-attributes-packet:
    +-- performance-metrics-one-way
    |  +-- one-way-delay?                           uint32
    |  +-- one-way-delay-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-residual-bandwidth?
    |  |       rt-types:bandwidth-ieee-float32
    |  +-- one-way-residual-bandwidth-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-available-bandwidth?
    |  |       rt-types:bandwidth-ieee-float32
    |  +-- one-way-available-bandwidth-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-utilized-bandwidth?
    |  |       rt-types:bandwidth-ieee-float32
    |  +-- one-way-utilized-bandwidth-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-min-delay?                       uint32
    |  +-- one-way-min-delay-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-max-delay?                       uint32
    |  +-- one-way-max-delay-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-delay-variation?                 uint32
    |  +-- one-way-delay-variation-normality?
    |  |       te-types:performance-metrics-normality
    |  +-- one-way-packet-loss?                     decimal64
    |  +-- one-way-packet-loss-normality?
    |          te-types:performance-metrics-normality
    +-- performance-metrics-two-way
       +-- two-way-delay?                       uint32
       +-- two-way-delay-normality?
       |       te-types:performance-metrics-normality
       +-- two-way-min-delay?                   uint32
       +-- two-way-min-delay-normality?
       |       te-types:performance-metrics-normality
       +-- two-way-max-delay?                   uint32
       +-- two-way-max-delay-normality?
       |       te-types:performance-metrics-normality
       +-- two-way-delay-variation?             uint32
       +-- two-way-delay-variation-normality?
       |       te-types:performance-metrics-normality
       +-- two-way-packet-loss?                 decimal64
       +-- two-way-packet-loss-normality?
               te-types:performance-metrics-normality
  grouping one-way-performance-metrics-packet:
    +-- one-way-min-delay?         uint32
    +-- one-way-max-delay?         uint32
    +-- one-way-delay-variation?   uint32
    +-- one-way-packet-loss?       decimal64
  grouping one-way-performance-metrics-gauge-packet:
    +-- one-way-min-delay?         yang:gauge64
    +-- one-way-max-delay?         yang:gauge64
    +-- one-way-delay-variation?   yang:gauge64
    +-- one-way-packet-loss?       decimal64
  grouping two-way-performance-metrics-packet:
    +-- two-way-min-delay?         uint32
    +-- two-way-max-delay?         uint32
    +-- two-way-delay-variation?   uint32
    +-- two-way-packet-loss?       decimal64
  grouping two-way-performance-metrics-gauge-packet:
    +-- two-way-min-delay?         yang:gauge64
    +-- two-way-max-delay?         yang:gauge64
    +-- two-way-delay-variation?   yang:gauge64
    +-- two-way-packet-loss?       decimal64
  grouping performance-metrics-throttle-container-packet:
    +-- throttle
       +-- one-way-delay-offset?                  uint32
       +-- measure-interval?                      uint32
       +-- advertisement-interval?                uint32
       +-- suppression-interval?                  uint32
       +-- threshold-out
       |  +-- one-way-delay?                 uint32
       |  +-- one-way-residual-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- one-way-available-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- one-way-utilized-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- two-way-delay?                 uint32
       |  +-- one-way-min-delay?             uint32
       |  +-- one-way-max-delay?             uint32
       |  +-- one-way-delay-variation?       uint32
       |  +-- one-way-packet-loss?           decimal64
       |  +-- two-way-min-delay?             uint32
       |  +-- two-way-max-delay?             uint32
       |  +-- two-way-delay-variation?       uint32
       |  +-- two-way-packet-loss?           decimal64
       +-- threshold-in
       |  +-- one-way-delay?                 uint32
       |  +-- one-way-residual-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- one-way-available-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- one-way-utilized-bandwidth?
       |  |       rt-types:bandwidth-ieee-float32
       |  +-- two-way-delay?                 uint32
       |  +-- one-way-min-delay?             uint32
       |  +-- one-way-max-delay?             uint32
       |  +-- one-way-delay-variation?       uint32
       |  +-- one-way-packet-loss?           decimal64
       |  +-- two-way-min-delay?             uint32
       |  +-- two-way-max-delay?             uint32
       |  +-- two-way-delay-variation?       uint32
       |  +-- two-way-packet-loss?           decimal64
       +-- threshold-accelerated-advertisement
          +-- one-way-delay?                 uint32
          +-- one-way-residual-bandwidth?
          |       rt-types:bandwidth-ieee-float32
          +-- one-way-available-bandwidth?
          |       rt-types:bandwidth-ieee-float32
          +-- one-way-utilized-bandwidth?
          |       rt-types:bandwidth-ieee-float32
          +-- two-way-delay?                 uint32
          +-- one-way-min-delay?             uint32
          +-- one-way-max-delay?             uint32
          +-- one-way-delay-variation?       uint32
          +-- one-way-packet-loss?           decimal64
          +-- two-way-min-delay?             uint32
          +-- two-way-max-delay?             uint32
          +-- two-way-delay-variation?       uint32
          +-- two-way-packet-loss?           decimal64
  grouping bandwidth-profile-parameters:
    +-- cir?   uint64
    +-- cbs?   uint64
    +-- eir?   uint64
    +-- ebs?   uint64
    +-- pir?   uint64
    +-- pbs?   uint64
  grouping te-packet-path-bandwidth:
    +-- packet-bandwidth
       +-- specification-type?   te-bandwidth-requested-type
       +-- set-bandwidth?        bandwidth-kbps
       +-- bandwidth-profile
       |  +-- bandwidth-profile-name?   string
       |  +-- bandwidth-profile-type?   identityref
       |  +-- cir?                      uint64
       |  +-- cbs?                      uint64
       |  +-- eir?                      uint64
       |  +-- ebs?                      uint64
       |  +-- pir?                      uint64
       |  +-- pbs?                      uint64
       +-- class-type?           te-types:te-ds-class
       +--ro signaled-bandwidth?   te-packet-types:bandwidth-kbps
  grouping te-packet-link-bandwidth:
    +-- packet-bandwidth?   uint64
]]></artwork></figure>

</section>
</section>
<section anchor="changes-bis"><name>Changes from RFC 8776</name>

<t>This version adds new common data types, identities, and groupings to the YANG modules. It also updates some of the existing data types, identities, and groupings in the YANG modules and fixes few bugs in <xref target="RFC8776"/>.</t>

<t>The following new identities have been added to the 'ietf-te-types' module:</t>

<t><list style="symbols">
  <t>lsp-provisioning-error-reason;</t>
  <t>association-type-diversity;</t>
  <t>tunnel-admin-state-auto;</t>
  <t>lsp-restoration-restore-none;</t>
  <t>restoration-scheme-rerouting;</t>
  <t>path-metric-optimization-type;</t>
  <t>link-path-metric-type;</t>
  <t>link-metric-type and its derived identities;</t>
  <t>path-computation-error-reason and its derived identities;</t>
  <t>protocol-origin-type and its derived identities;</t>
  <t>svec-objective-function-type and its derived identities;</t>
  <t>svec-metric-type and its derived identities.</t>
</list></t>

<t>The following new data types have been added to the 'ietf-te-types' module:</t>

<t><list style="symbols">
  <t>path-type;</t>
  <t>te-gen-node-id.</t>
</list></t>

<t>The following new groupings have been added to the 'ietf-te-types' module:</t>

<t><list style="symbols">
  <t>explicit-route-hop-with-srlg;</t>
  <t>encoding-and-switching-type;</t>
  <t>te-generic-node-id.</t>
</list></t>

<t>The following new identities have been added to the 'ietf-te-packet-types' module:</t>

<t><list style="symbols">
  <t>bandwidth-profile-type;</t>
  <t>link-metric-delay-variation;</t>
  <t>link-metric-loss;</t>
  <t>path-metric-delay-variation;</t>
  <t>path-metric-loss.</t>
</list></t>

<t>The following new groupings have been added to the 'ietf-te-packet-types' module:</t>

<t><list style="symbols">
  <t>te-packet-path-bandwidth;</t>
  <t>te-packet-link-bandwidth.</t>
</list></t>

<t>The following identities, already defined in <xref target="RFC8776"/>, have been updated in the 'ietf-te-types' module:</t>

<t><list style="symbols">
  <t>objective-function-type (editorial);</t>
  <t>action-exercise (bug fix);</t>
  <t>path-metric-type:  <vspace blankLines='1'/>
new base identities have been added;</t>
  <t>path-metric-te (bug fix);</t>
  <t>path-metric-igp (bug fix);</t>
  <t>path-metric-hop (bug fix);</t>
  <t>path-metric-delay-average (bug fix);</t>
  <t>path-metric-delay-minimum (bug fix);</t>
  <t>path-metric-residual-bandwidth (bug fix);</t>
  <t>path-metric-optimize-includes (bug fix);</t>
  <t>path-metric-optimize-excludes (bug fix);</t>
  <t>te-optimization-criterion (editorial).</t>
</list></t>

<t>The following data type, already defined in <xref target="RFC8776"/>, has been updated in the 'ietf-te-types' module:</t>

<t><list style="symbols">
  <t>te-node-id;  <vspace blankLines='1'/>
The data type has been changed to be a union.</t>
</list></t>

<t>The following groupings, already defined in <xref target="RFC8776"/>, have been updated in the 'ietf-te-types' module:</t>

<t><list style="symbols">
  <t>explicit-route-hop  <vspace blankLines='1'/>
The following new leaves have been added to the 'explicit-route-hop' grouping:  <list style="symbols">
      <t>node-id-uri;</t>
      <t>link-tp-id-uri;</t>
    </list>
The following leaves, already defined in <xref target="RFC8776"/>, have been updated in the 'explicit-route-hop':  <list style="symbols">
      <t>node-id;</t>
      <t>link-tp-id.      <vspace blankLines='1'/>
The mandatory true statements for the node-id and link-tp-id have been replaced by must statements that requires at least the presence of:      <list style="symbols">
          <t>node-id or node-id-uri;</t>
          <t>link-tp-id or link-tp-id-uri.</t>
        </list></t>
    </list></t>
  <t>explicit-route-hop  <vspace blankLines='1'/>
The following new leaves have been added to the 'explicit-route-hop' grouping:  <list style="symbols">
      <t>node-id-uri;</t>
      <t>link-tp-id-uri;</t>
    </list>
The following leaves, already defined in <xref target="RFC8776"/>, have been updated in the 'explicit-route-hop':  <list style="symbols">
      <t>node-id;</t>
      <t>link-tp-id.      <vspace blankLines='1'/>
The mandatory true statements for the node-id and link-tp-id have been replaced by must statements that requires at least the presence of:      <list style="symbols">
          <t>node-id or node-id-uri;</t>
          <t>link-tp-id or link-tp-id-uri.</t>
        </list></t>
    </list></t>
  <t>optimization-metric-entry:  <vspace blankLines='1'/>
The following leaves, already defined in <xref target="RFC8776"/>, have been updated in the 'optimization-metric-entry':  <list style="symbols">
      <t>metric-type;      <vspace blankLines='1'/>
The base identity has been updated without impacting the set of derived identities that are allowed.</t>
    </list></t>
  <t>tunnel-constraints;  <vspace blankLines='1'/>
The following new leaf have been added to the 'tunnel-constraints' grouping:  <list style="symbols">
      <t>network-id;</t>
    </list></t>
  <t>path-constraints-route-objects:  <vspace blankLines='1'/>
The following container, already defined in <xref target="RFC8776"/>, has been updated in the 'path-constraints-route-objects':  <list style="symbols">
      <t>explicit-route-objects-always;      <vspace blankLines='1'/>
The container has been renamed as 'explicit-route-objects'. This change is not affecting any IETF standard YANG models since this grouping has not yet been used by any YANG model defined in existing IETF RFCs.</t>
    </list></t>
  <t>generic-path-metric-bounds:  <vspace blankLines='1'/>
The following leaves, already defined in <xref target="RFC8776"/>, have been updated in the 'optimization-metric-entry':  <list style="symbols">
      <t>metric-type;      <vspace blankLines='1'/>
The base identity has been updated to:      <list style="symbols">
          <t>increase the set of derived identities that are allowed and;</t>
          <t>remove from this set the 'path-metric-optimize-includes' and the 'path-metric-optimize-excludes' identities (bug fixing)</t>
        </list></t>
    </list></t>
  <t>generic-path-optimization  <vspace blankLines='1'/>
The following new leaf have been added to the 'generic-path-optimization' grouping:  <list style="symbols">
      <t>tiebreaker;</t>
    </list>
The following container, already defined in <xref target="RFC8776"/>, has been deprecated:  <list style="symbols">
      <t>tiebreakers.</t>
    </list></t>
</list></t>

<t>The following identities, already defined in <xref target="RFC8776"/>, have been obsoleted in the 'ietf-te-types' module for bug fixing:</t>

<t><list style="symbols">
  <t>of-minimize-agg-bandwidth-consumption;</t>
  <t>of-minimize-load-most-loaded-link;</t>
  <t>of-minimize-cost-path-set;</t>
  <t>lsp-protection-reroute-extra;</t>
  <t>lsp-protection-reroute.</t>
</list></t>

</section>
<section numbered="false" anchor="acknowledgements"><name>Acknowledgements</name>

<t>The authors would like to thank 
Robert Wilton, Lou Berger, Mahesh Jethanandani and Jeff Haas
for their valuable input to the discussion
about the process to follow to provide tiny updates to a YANG module already published as an RFC.</t>

<t>The authors would like to thank
Mohamed Boucadair
and
Sergio Belotti
for their valuable comments and suggestions on this document.</t>

<t>This document was prepared using kramdown.</t>

</section>

    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
        <name>Contributors</name>
    <contact initials="V. P." surname="Beeram" fullname="Vishnu Pavan Beeram">
      <organization>Juniper Networks</organization>
      <address>
        <email>vbeeram@juniper.net</email>
      </address>
    </contact>
    <contact initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>rgandhi@cisco.com</email>
      </address>
    </contact>
    </section>

  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+y9f1fjyBEo+v+es99Bjz33YjYIbPNzmCS7DDCzvAszXGB2
k5fk5Ai7bSsjS44kw5DN3s/yPsv7ZK+q+rfUkmVjZphZOMkO2FJ1dVV1dXV1
/fB9/9tvekk/jIcH3jQf+PvffvPtN3mYR+zAO0rG4yT2/nr49o13HOSBd30/
YZk3SFLvOg0Gg7DnncTDMGYshffxxeDmJmW3B971ifUyvfftN/2kFwdjANyH
t3M/ZDBezoLMTwe9/b29XX866Qc58yP4T5Z/+01ykyURg98PPPz622+y6c04
zLIwiXOAeOCdnly//vabuyT9MEyT6QTHPbzyfoG/AR/vDX4GswNowyS9P/Cy
vP/tN+EkPfDydJrl3Xb7RbuLaGd5EPf/GURJDEDvEdVJeOD9LU96616WpHnK
Bhn8dj/mv/RgaizOs3/QlKf5KEkPvv3G83z8j+fxOZ7mAM97Nc1C/mmSAoV/
mgZ3THzAxkEYHXghPrdxA8/9OKJvNwB8CdphCF96b6aJAez1NJ+mDN7wrllv
FCdRMgwRdwN4gK8Np8kG0vrHIX7oBP+X6YABxc7CqQH/MGID76Q/ZBbIj/To
RhROZwG9DlL2wbsKgr4B9CjMeol3dZ/lbJx5p3Fvw4KeZ/D4RszyGrinwE3v
VXqfAZcNyKdxP7wN+9Mgsun7zxv+6I/3wShJOESU+ThPw5tp7uLdz2E2iqfe
RXAbxN4rEO9gbAz0f0/jcMJS7y3LUfRsit/e0OM//os/hFMpgb8MPrBs5L0B
oRuFVbRZLxMnHdIbP/bwOTmROEnHQR7eMprG6fV7//qfbzb22i8O+LtiLZ/G
OUsHQU+s33zEvGSSh70ggsUQxNkExNyL+Yz4i4ZgGzQGKDEMl8Tw4jWLGK4F
mGqPPvPex/Bf/gauZKIV87rtbpt/mIGmYFkYD5IDjqpHqApMg3TI8gNvlOeT
7GBz8+7ubiPMQczifDNlvc1r//LkyBcvwEIGKObUz09e/7PT3tiy530CM01h
Xt4VS29DnP5hzhkPv16Mgox5W9XzBZjmbN718uQGON9td7bKE4KHPUSgejZj
NkCB2DzMMpZnm7RskQX/vJqwXjgQVMw2L45fb4rpTPoDnKzv+15wkwGrejn+
fT0KMw/06RQVkddnA9DCmReAaoqAJ8SLZECKCn7ro+5GjQlCFfbhhTAP8XeQ
Jo8UJ2jLzAuFsqanx0mfRahEoyAeggphG971iAGx+jDhW9avB12ADHoAoOcs
7sOLeeLdwJ9jFDj48+beS5BFOOI0QjBsY7ixDgKawGh3o7A34siQyDq2Ha91
fbIG6MSDcDhNuRji8KDTc+b1gklwE0aE1UaZcGqH8S5fH9EmsyGpPQ77/Yjh
X9+h2KeAHtEVPyE6/frr/wUv7YJs//ab+GPvxQ7+ESIn3GT0phmnAZ+TjTa+
si4Q579fsnECf1ykSY/1Qdl7R0EUCc7FSa5Fhha1WL7eOIhhKJrgJE1gF0ui
zMumQMkgIzIKzQV7tDn8hXjWa709uT569/b1GkzrB5xjd7sD04IRLk+u6Bvx
xX57G+ZLosFlR00zm06QwUiIbAw4w0LJUSJvpmEEO78pODQZwBN0N/wxhjUR
xGEGmwNQiUubkBD+9CBNxjQJBYo+dzA3FFxrsjCUXJfB60XBB6LZysebLS1c
AKDC4+geXszCYazWAY4kkcFFHHJuBpNJBKy9iRgxVolRpfwPWIDGAK1ierqV
rQm10PeSaZ4Bcjjx3KTQBgjCLUsBB1h4Ga45XOEOdHqwDd4I2YUFG8T2ovVw
N8SZDKdhP4h7uNpBQq4Evbc3Ol0c+4dT/5hsBh8EFd4ks2+7vXcTZiBEnH+s
qIMQlIU0rRlQ/CQfpjCfa6lHYzWDnZ15h2lvFOaACC4eSQ/CDtfr/tZ2Vw1t
jhH0+xksp7v5NCiyFOhCWK0I69ant1boSevzSdD7wHL5Nc1aqEB6VmsmgSro
Jlxqr0EcBtOUqN9nOdgFgAaYpciBBJ7F1TNkma+J+t13sFGn45AMxHtJ5g/s
3gOywTRXzt9fXa+s83+9t+/o98uT//3+9PLkGH+/+unw7Ez98o144uqnd+/P
jvVv+s2jd+fnJ2+P+cvwqWd99M3K+eFfVzjpVt5dXJ++e3t4tlJmM64ZsVeg
0TFJGW4XQfYNrKAebOCcj6+OLv6//7ezLYjU7XReKGW839nbhj/uRizmoyW4
/vifQL77b2CRsSBFKKigYKdAUxyZCspylNzFHtCYbXzzxx9g6THP3/3hz98g
9WBvRwLmmqa0RgVauCILIpzhhjBIpjFiTO+bu4Xk0QUwMfzIVzAdtt7Cu95b
MBgzPir9iuuIIMdJX0oKlwW9YpKbf4HAk1mKRJxwwH1YvogcCiGdd4K0L76D
GWdJLwyQwHchF2B8u5ekoFImSdxXs1L7ttquFbVoVeXBjS8GlPL3XzE1T/38
1xR38+NLlGMGCgTfugdB9jzza1o6+DFfNfJjrWm2kDy0K794ATsWQgnR9itD
wY+roGyXoaTWwwoKrPw8NND5rxS97ott/qJUAIUXyx/DW3+BH/GOqRyMdwof
q3d+PfC+MynPjd8/rSiZQjlxcFMwceU35NOfyQY66Yd4JPIuIoa2ccomERwa
PBwHxAImPBwVFqqUGHo9no7RQAaBUrtcYctRgMfJLeNfgiXDlKpKGfOOw2AI
hygSfPqgLz7gW1BJVwxgc0/uCAmAJYwpU9n/wJW9Wm7eYS9N4vsxp8wheS1C
bknh94cXV3AOgBMwHA/xhNEj20iIxxVMGDYV7vA4vvKvT+jZ43BAwpvzdaSO
GxWekjfnF2d8kDcshhNjFP4H3jqfRnkobTbvLLiB5WyNd3ZySS/xr/Bw7l2C
ELKUvry6ML7k7wHQiyAf8a8vS1+jKGgACqeZeLx9dX5IT75NYv9VmgT9Huy4
/D3/sAcTJ0JenNNDF3D0xLMamgbnDI5fPfr28upnjvAly5JpCl/CL0A32xzF
J6+O6bkrECo4dx4zEIY+2eZXr80vXsN2SJ9enr3hn49AA/a9yzD74J2F8Qfp
EwKx4lyr4M4v15xUvwQhLLfEB7zQnOCy8+4WeQvGwa/fJeLX36rPZGCc2Ls7
bhbCrLg+4UbFQclcIB/biTdE2QD0tKFcYT/g8+KTTJwlpbn6jhvP0kV0rx+Q
w9M2IY1E2h96ycRhLsoleiIcgedcgcMpIkd3mDQtinMRer4FuwPj6rsH+9Rv
v9GpDSwYNDBtesC4QS6OjX02wYMjWgQw/WAYJxkuSEAOzVA9WTU/j+iLtn/k
g/KKEQhueD2pY77jUoAm2wyUFX5IFK5klO5M2TQjA13ZfwfkOmX+DSB6F/bz
Edch/HH5FJ+aEg40mgWPYfLqTX7IUGY/nPun3IQNEAdg2HSIHOELBXnPAjjd
aRpwO3EaC/KgIjZchOvCCEBp92G7TfBcvmJivkJ8QLsFFe6GmFiEemDuSdFb
jz2hFblDHwy1OuUIr1jTmGhV5I+5KvID5RGaPbkkZv5dcM/t+buEfh/DjjZF
PePQc17r4nyNngZRVqd1kl7YWqKQQHpAlA94YhOeuQlobDSsSgeWve09sEjW
pZmxs9fGvxA63+P29rtbYo9zTRQ38BwsA18INktnT1i5KFDWAQADay/qczUW
9PH4GGb81IVnfvg6kx4YQRZ5FkfFHvFzOvuIx1tQrWhAMX+UTGbjITwKQA35
tkdvZ05CbXXbeBLglKEPtvf2BGXKo/tow/hZGg2r8RASysV7tQxjFW0dLp4g
HVGWVGw+Xgt3pzUPXhHEiPn9iw/I+pncZEma+RaFOjjkPgzSkhqvREyccILd
35OwuAdM7fDaQ4LaT1/lLEP96aOx1H/9zO9FYAEKWpImATsSRAOtI3EEqTKX
WsdXa94Rvu4jirQJiT3axeftTndbsFUqKL8fptxU4wjEQBXYv1Iah5BB0RWc
kujAR3d4IIJvUvSJoKdTgqHVKtSYGAhlRjGoyQgoQMhyZGSUoGsTn8BVmUuY
wyi5CSI/7NfSjXsfQAOmHOo0Dv89ZXCwVV+gneDB/g3oJOm6cKEKDw4LyRgI
pL8tRTRAsEAPoW3OPVvS76MMALkX5MEHFnMPmevMtYXaSCy50rc77fYWdxWi
KEuFa20zHno8YCYg1gI9QI1TBT7lEyWZZB9zaSDlyUTsAZKMeDCeg4ikxug0
TY4AA+Y9p4fxLOCpQKEeEsTM8MTYy1lOZ/c+aFjYev49Dfr6MJLQY51d47nB
NIrWvTGezNfxBA2qLcZfUS7kXz597Z1e3O6iSwqVq4K5oXSDpub54V+Ry2P0
bPSlf4yb996heP/67GfPcqFoZnU3tjc6kmFbu1u0uZDb/URCOT2uenl3o6sk
Yb+7p151eCw1rBpktje07Gy1dxCe2B0tbGogbG109XR2yTUkiIYiAfYFvxm4
x0e4dxxBkygIQsIzIbsVTk/tmjZ86bRBNaOHFFApXnMLqZbL0xxlEe/v6B4O
GD0K0E0ek1oZJ9rrg9LB3dkM6B8DbBA2Ngm4roJpwQELDBIu6uodoS1WxIWC
8mFaClh7M8Vjat8w/avEOESQRRN6BVZ6CsBz5N8UDPuUnFH0lZwgfD3AOUg/
Zxj/exqm9zjnMZz7FCEnc5CQdDiwN5T3oHxL5p5RceBM4EuvdXZ9sYY2WeCZ
ByUSizv0CEoZRJsN1VGMzraSYiNc5TKE3SPBm1baXehGh1420BNGCq058QeX
ejlZNAlhZ8v+hUiCPVS/u/bl7gpfiaO1+a4QHWHEkc6bwjyiasNze39PesqD
PlDMJyNEIjHFa1+98wWSPKsgSriV43kNTPqP4gqQIIR4mYmXt9yeqTDjhBIy
KbJuWHV7W+19gZZhvblpUm+OOSfdxT3LGA4QMBYyt6prxwQ68Kfcs9vbNzgM
1ga6E+B8Dgp+mtWZFjaL+fPcNxx4EgwoL34X6hgYtup9NTE8N2xvmxoKWecH
5MSZaeXYqMhlwV+W3oVKxiqT9FTdqSzDJNU3NGSS0tJRK9MfRMFQCu4NuiK5
Y5u/w335+qyBRjUtCnqr5qghZXS7/UJILNF1b2vXkN+9Ttd48kXXlO1t8689
cbJTi2/HeLKz07H+Mp7cbbeN73b3Xpgwu7vGX/vWk/ud7Rf2ytrv7L4QDCJx
mCgHqCESs+lH0qDfrZEIQ8Ok5G0jpexnvRGcIOcaE3lmgPA4iJmjGjNETZXC
zurjiQto0lhcDBgpiwJ+WuWwPAmL27q0dkABgbyCuZeQxphM0wkcDfilSgWq
irdbu/smb9Ev4F7Q8nJnXtYhGY13a1i3u7dvS2vX+murIFkgegI1flMFe4A/
mMbzCxctTAXDkzDcSO7sYBCDsh1ov5trNL1L1qi1otuBL12+jLKJr8768sDc
mBPqZF8zuOUc2t7q7luogG7YFhYwnAVCaTs6/MKO8YRFaIyZVLqV+aWnmvOC
moM0b3PFYdNcOsG0O8UMBGqKgrYVtSvFhNOAC0D0rvXXtrFo23RBbVgzna39
ZhyaidmC/JLWoo+HtphAzcU0bf8OwghQzEpXy4FaRHh2Gk+zHPHMQMVk5Nbl
9iNtG/z2H02JSU77+swVh5qvu9dWGh03fm5/za9XhN02y4SRzOS2nN7Nt82d
1/badre2ij5cib+KkJkAD7Kw7wfRMPE728bJFWztnHtmmIXobRBN6dhhhkuI
Y5p0mjhew/nZIU1GGJ+I7JAnXH5+w/HJvRt8DMfTsRi4AjQZaveCeDSH13QS
CMaTiHEPgekmJuD8RrgYA0WXu/x2GcZC76kcp7VqMhpdsWsbeClFbrzono9y
Q/EXAkvrhSjJstV1k7+rrjs2eCS0pGBMd6QRt7tpiAAPOjSF9kYbf7b+B5cc
y0GgJcLcFEkMTJ15G6IjnW5o0jRJwZ4IMunSrBJhecWAodxcfSooHkHxOBQ4
rr5NdBRI/bN0D2ed+4t3gkRNMG8mU+6aWgxjEh0DShGLwhKc9PgwhvWGt8V+
kobDsMlWQx4H4WJWV9387fJgNnS5u9yynv9AG+bq55OjOW0YU2x21QmSkFlA
2S2AgDy2fUehBZjpoXh2gizJvF+/U+yZ50BXdYx7oKiUNTL8ZZ6hdqyT2M7O
nqGft9q7BftV0/w05zc95s2nPpQGeg9vOjGCZkOpn+tBzfqLE+VrNK+15lx/
GDCHKKWMK2btpVOBP8Jb39dfac9WnYIABNXtvo+BH/Z95CKImi5QHTlQeoMP
xlXbNA5ugzBCzqhNduar8NE06pN94r2CXQIvj/xL1pumGa6i0rpovbq8OFoD
tXkXZznwbuxdHJ2Iy5dRCJDgTxUC69iJSzq4akGtU7QDC/r8jtk7PXx76GPs
Md339tVTN6wXwEFUcBbB22uIXxvB5yRhnQ1zO6ZASnG7AKciGd2CkY4iMB2/
hRnhMeI2TJOY35y2eGj/bHFde0lDuoxVAQO2r8tfDlF7oBsxROig+9Y02tLF
bBLNAc7AnY85DnLKOCA/b8AFimbCbQ+6uknSPg+3HcmAGRGJKy0B8mtHwT0x
OTBDkGeSoLgg1gxlKzepd3yTAiVb2JaWpmvn2Ru1djWU5It2p7tUJVmD0YFr
/w8moVOX8EMFuWCkZqucaUhXqYdc8GVMGsYhjglDlVLltQ4vTiWjYO2j0dg8
SsoO5NLBUpMPeTFainSWkTKgw8KMIHQZOqVDoxIRGmbG08wOhXLitUBEVH3E
jRimOu7CGlGGFRkwxSmAk8GQpmI0nHiMJq7inNDQhpMqThbYyvDE2iQihoiv
XyEBVTA9AZNUhSC8uCFTl9QCOVIDc4aL0YakB1NZcCLoRu1LMlIWo+S0SPII
caGFMNzTNy68+bdrar0VhlK3G2JLk4lazHiGbzoSMBws1rg7I4qMwKaYHzlM
yNxXmjFhe1ZscZL9chMrRhSuA6FVao0I2NEx7bCcFVnlFEFih7T2NYnMwLIC
v8gTPie/yJXxOPzinCoMYHPJon7pyadM9RmRSotrp3LAklYHKfv3lGUYvzHf
vZe8TwUaCBAGnblLS6tj8n81ufpafI6FG7AbADRd2BNb8sKKcCYOFY3Ym/tJ
gNd93LOHvkcVwONy2NIVGVfEcGRFCZ8LHwwdQ+MIl8IrReUjwxQ8F8ZoYfAf
eMDYjnE/1+kapzvxibw4Ke8Ss7G8DdIwmWau3UCHrhIyMl1ZI9PdfbFnuzJ3
X6ALn3tKg3ulJUDKonAcmjI2zcMo/E8gw7bEtjOg2NqC9gDVmwljRRspNBNh
qfz6nbW+ZxiVPCPIyMvUMiki3kkEffG+Tt9ZMeLZdTpOMcpEOM5FJo6GY6Xe
uF+SWThggsbKMuBZchqmebCn59e5zhKzS2VGUnG9SQcYj/mimDlx56+NMmtn
QDJwtr7Y6ZoXZG3zkna7a94X8Dsc9dfObscQ3V3ppihfNNv3DPy2X/210zFc
H3udLePyml8jqr8ouEJfSZvXzns7e/ZfxvWxUYNArKT/Az+Uz/XtN1JqrCyo
XzHbjCQDLVzkUmej8xI/xIIJ2QRt7JVpGh/gawdkeGUHH8fRQZwd4GsHtmjS
myK1TX74kifRcWkt5YD9ynP2xTv4xUv+Saoz0nim1gpmOaHoVJVH4aP/VhzM
SFuzB8Mvlj2YnZdmjycD5WvHxKVQW/9FBhai0B+mLFCIFFGROek2Eivx3Uo9
AlvbO8q4orFJp9PYMuH3WsV+zhpdORZKaOSPhkaC1TqESuYwV7BcjTMg0spS
xkXE85lEdvfh1ZpAyqpsw0cjc6CXixF+eeP9wm4O4Nc/yroTaO5g2YgPLKWr
pQ1AbPNuuImFdzb/LAG/8c7CLIcX/4ilRvLkAL/+UT7/Z5H36qn0QK9U3cX4
UTDKxVxckBzlUBzASsVPXKAqC7c4ADoqtbhAFkvjOCBVlsRxwStXr3FAdBSt
+TPnN79MmhhSRYGHZkKtshCLVQ9EagwGU2dsMBV1cgoFDqzEf9OHcH0iqtF4
4h+V0TNXSr542RL51tvz40NukyjIOkF9FRPTV9f5v5hmjr/LBHX8nfLS1S8C
hniOX2Hq3/T7Kicd/yykqa+uCyir54d/XeUb26pMVl9tnqwuoBRT1r3OttdC
/YIJ62v8V0xXX3NmqwsgdJHaLGddEfIomdyn4XCUe63eGtbh2fGEEsKLdxl3
C9JPPl/ltTdQ51VxlGcTLcINj06UBBcj4slR2deDXrI+Bneif0eectHTDDiL
UFT85CaMg5RsZix1RGfFJBUA8C/YW1C4VIUTun2dYLRuTmeSaZpNgxgdzZxc
2ZSusOBvTS6wknsszniufibXBXGB+y0u2W2IBvWrq2NY4PzZjAllirjRgd3T
Iek9SQdNxdXMO2PDIELfIL9BzRQdIn5hAZJBzx9Lm1E80JI6msqRMab1s0Dc
R2+BtS6ACNJEktkZ5tJHGgUpXfSjTPHscHssrEOUDno+I41Eo+Eom/AZPr72
EijAVD53mGcsGmiCUNqCF9GEsQANGMYbXDFhBjXhhVLmtzt+d1vutiWdJbWW
eofqbdgGNlbfsI6x/EXfq70ff6mfK8a9+f2QSJffGw+JODAe00yVd3yQ+OSl
PZwZkMh/xzyTmBmPOWIWUybsMOMxM/AAnQZjYSEQhuaoFHNZiF8pfm98xTMM
88xxd1QcveqiviEIxz17szfrbsvngNBs0nrNeI0kzXIKWeSiAJk5oZlnPgms
LuvQmGNNNqAptswXXjmZ71SJIq+pWMTSubIqmGOuKRkfy1Kww1iFYBdesr6q
+iIcTiq+AUpVfAOmR3DvB7CqwcqofQbzDcbTccUzsHapbqB2BNavWNTLvWja
L6+t4nPsY+k5YJ218EEzwvbEXbXzcNApsTr/bU5ozSRWfUmyUJb9iAEzMuMp
fE4g5E/T8KX9DSkxyuIpfOlXYFkHvxK2paR7YFGK+ZC2/9JnZImSkD5Y2en9
wYJju5ew2CaN6/aXCxFOHMetKYhNSUEW7BFVjBrMQyWzF4crCLCA6AfRXXBv
LkmpSs0lTPGCTUafg4rWOCbnFqEl6O4b2LjhWG+xoo/XP1jytimRNJzqTVMX
I2uyiwy4ukX9FwyHxu0KMnk6Jjvwpfv5KAn6/jjJcvoNKziA0Fc828PHiJSZ
ctcZ9qHOw+DcZx9BvmY+VkkCVaCQYhkGsMlzAzrEzA5ec22j3peE1vW8NZUN
/97mplWfySrMxCOr4SwNyOgqTOtCYql4qQBRvH4slmHi0zdt+bbf3vU77Tpb
/hTdBTD0z/pkIiu5zKAJVrVbmCY0pe+/J4Df0zt9NuBnq+83+dc5/9Azchbl
RMiAJOfxiH30eTEU+R3C9dqdg3b3oL110N4mePyLiMVDIPZKZ2Oj05GT+62a
NoeOXEdvU6dlUn4kfIB5uGnh8lYtVIxJ1liuegWbVHhi4ESPVbfoyAwn45v7
nMkrXWOKoVjEAebWZrmCIVw3ERvk8i2CkOF9Ji+eI55Uv5yxgFJE/gNrhx5W
V8iyaAjY5Dw8XFxfJfz4riBQ4ARKW34/Q1Iw2t5ZronXvzzB3NJM3sG+u7p4
XfKteUo+u+o7hIxZpQfe6ZV/emWCqaxybryKNyQH/CUMfyzw+g3Paw15PIQE
5sDLmo24pluzxNwhx5klyDwDV4kvPx3ph19aX8hEXL/8RI0kH4tDVq4X54k7
lXfDibtr1LrF+LIalZO6TOLK1aUoXwhkeV5dn16QXTm5MwVa3rTDHPQ3Hr+K
z3jhITOyjIAqyf+tMSi0DGaBqVknFPur3xeZwyRUblI44uOoqDvVpjBpIuNQ
LMrgh0CtDzF6f42pcMloG8ahA1lC+D1/WYmIQSsCzpEpw+40gP2W3t0wPzN/
P+VR3TKmBIWb18WiGAqdCwQWXiV6wU0Vgt0GCB6Ktx+EohO9GhHRMO9GLBcV
eUohjXzyNLWWGlKhhkML0qytayK0bOT4t1Q6zWZyhR7Y3usc0PZZvdXywmbG
VmlvifvdLavgo/8qyEQRSu+KydsoVE0n4ngW3TtUCVV46btKWWZei0JYvPdU
zxY2IY6RSx+5ccRkK7njN5+mc/Gi987WW3CE3erW7F31ZSgMNVHFI6xKIXhk
mCt4TcEjpND8NmqKOsjCq3ReVJT39FpUm3TNIhlWvnAYScsf1UnlnPk86FbU
xmiqFSemTqjSACcxhsz1K/VLv6BYq+Ach1k9IGxqYx0yqmGd4l3ZmNErdMda
CRQsmUlAhRwpyYPFpEAaDMGrIAk7Ce8yBfpmzmgKfOIlNKkmF47ELM7y0MZh
CifRwTTystE0J3JR0XoDH1nZwJiGQ7wJL5K2/Q5I2xsJ9kqClRYInlytsrnw
oUPi8Me1vmXjliqaLpmS5KnlZCzQxcLZQSMbLccmX4XSFV8mWFitanOvtfRl
OxF3VRsRAE8O1ExWVjKsa04Kt7Vjhttay7h4AgcLEQtneKvtv338yz9a7Vbr
7xvtH9Z++Nvk4h+tv/9h7Yf2D//lH639d9Vm/h+81Q581frb3/uBPzj0X//j
1/b6zm9/a3e3d/eDw94RO/kHQFr7ofyegt7qdP/W9vf+4YL9t3bnH3/v/7f9
w9/78D8A9F/C0Rius77/23//3v9D+eXWeutLntDa2vers4+KsmSlmbKhuV48
X/FqZoGUAOGppOQgL4JTCEqYzL4ya5cpAFRZBaMIKJeNKsfya/qMqRdFQYQY
9pCYDelco97vs14INtM6HuQogGOIzjNYqvj3IEqC/MBAtwWPe/+l7/7Lv137
2/et1fVVxxdr/zBefK3SKnhmilWe06zJq4tv4MGOu1v1SVImLK1qx2rIGJ6h
YMSt7mohFlaG82n8eThw+2Nn0mmvrRtFzTB1XXbrESdO7OyRMWCJeaHkHYGR
SY2LZHa9Pv2aBRKDjKJUAHuW9vBkFegWCPgDlDKHF0F5q+2Pq/h7j/WFwxkp
yvk4y504b9iilkHdjGq+Xlmys1fx50SEG+9utL1We3cTPamVxo2smFqyJPe1
PkzRx+yttDc29hq4HXFPqiqx6qyuOsvo7HSBssp4K/jJDBtQBecHd0Vjgf+Y
LgRzV143wmy2NjpVpFJVUuezug9jq3JqUqqbel9dNVVNor56asFj1KyOKtA2
87ByKq0NLJJqw1msWKoCMLNoaj3XEZ8DbJgGKpXi3HSPPZG3QuRsHZ6erulV
5mD64XCYktY17BSKbd7Ck5gUCbGyLnjGhPQgXawZY7lPYUZF3oZHA16Dt4El
dSgepdq9eGeiy0+jD6vSWOO1fZuNIJ5tPETNuj+pL0RcKD1M8GcJAVbYOfCw
VwO2uih42vFjGgQT+q7pljhbdwiAuba3qnhYrDvYkJcTLGuJXRrol6YWO6/A
mRXeruQnVXsRyM07hPku5udjTAhy40b1zcDFjy01lmqmG0UYVflTROlT3rRU
stqu1N2Q07JKdwP6c/cCdhfo0WqQG7kEgfKqhq/kuqwF/oABJYgZAy6+ps1Z
6fLlCjdet7x2yc3LBpDgZNzQk4HrwC7YrwWV0usVMFot9tuiMnclewDcMFkW
IgrYPIg8jG3FEvOFga1By7wTXuK57KDKZS18zp9SN2iLr7uxs7FjGQbzXcrW
7Thb0l4uE1DEWc28d6KLSaOuu32bitliB+HkdtcXJdqxjMd/dHRwXXDAIvXp
9UlQ1gMvWJ5zVqzXx2BH5fr1WaXr1duLlbCvMnUbVrI3jvBGhkWpnr0U3XI1
+3oAW/JlrOBeWc9eC251VfpCVXsp4hKheUCosvaEWKfzQhbG14dZJHZ9lXyj
N6cJqihKC5TJV+83KZdfKJYvSf25tBBQ45G00LZsCy0gI7EPBKMc8wDS0Kjr
NtdtEEAoo0Ud5XWpi7J3wl8hM7Fah1fv3q45EJTeEJwTkuq2q075mTF6lQrF
E7PrUqZ4Y1OzJc0yY/mhPKSiLmKkZKBmQsI40+Ws8zseD89CLMqiqJYK/Vv4
3qCHTu1O/A64b9mnkyTjXocmV//UY1QO5jKzcAQyS1wjNAkAoCvOWSOYt6jW
CE1u8OsvVKuHrvOeSd+YebNj8cTVOGGWC21/r6vO0dWXqCdxH0+j8I9jtZZ6
RTa/xdU/l6JDQJUEFhoRNDwUlIMwqhj2SvZIVq0KskkQq2zEO5HkzD+kNiBR
IURAn7Ko6BPlrKyLjAihTcGauGHm5kxTkD4meBNH9lpoqlBQAuOtv9dMFKx3
ER3ZeB0AhcMhvA+7Xixc5qAPCHDNWVKTlTBofLVoN3QYBTg1RvdvBAcMJooE
wcQujNJugsK012Os/zAkFBDTasCf6yIX8WlJH1g2gyCMpinb7PM+nuie5N5y
eweVAkEdY4p8tXhpstGW+CQuS9ps8iCCD6MNhzDDrxDybWc+YZDpn8QB/nKT
YeZnuBzIyfHZI85LQ3NeM6kn+GSU7pybWXQ3rl6nDGpsnpKBVkU1LI9KthtA
XhCsYhe33gdMUhZtHfhVgJBsLdHW232Wc02zmFSSgdF0nhJTomeYZVNaeRJZ
bFVIO4VaYEU9ORBZ/83xvBO9ckWC7NwM6ScYGcGPrPQRmaV4SVLSGBayitaS
rJbqoTOHUhoiqCWy749pyvBioduv1/rl+hI2hHBsXDzO45jlN6PCDCy35plh
L2DZngZ3I2DyYEUA3aDaOiRgH5ADteN7LaOPNcrBpc5aXhO9sMil4LAa0OJp
bn44AMwI8MoZ7F6Yf40lf5pFhmz+0Ppb4P/n0P9/2v6Lv/v/3PjHH9Zam6WP
mkQsHNqV3QgH6TMnC1ui5/ErNLSJtSNGfFdp06uWb2QvzHO3EfQtFdo8qPdQ
Ya4R1qYDgK3Vr5QUVBq3ib1fPy6HXD2ySFgqjdwokrd2ZA7ZMXLdMeCEG3ha
NrDkgaxIUZHmYHf4m+lbLAq3zjBqm7Fym5seCFl+L54vUa8ClloqpYVyAMui
uEj/MP+SakJG++690MuwFAe0YFdDBcXV3VB9qX65HpXbHa5a7Q6LcTSmg23V
LC61arQ9lDWjKlseKhALtj6cEf+yeLkqU3wnTQTXumogAX0f8yAdHf1r+sel
d9x84/Tidht5a3qHFxInudxZ3OeXwNS/kW5Pqn3M87VoVFBK4VUZOSR5AMdW
e+cLSWRzcl9VvGh69Z6G4wBMU6rr28DgcyRTAOvobQoBFPBmhFZQPNoyh1UQ
6weWsxVXrEuftbwqbjj7ZaOhqVCPyIywMxlvIGCvm60bjHSX4uzXtXKmJa1w
kF/zKroSx3X7KY27gmIgr5KFEakBC7DoWKaShMUH3qQ7nvja+qhP3BHlaGl1
XcgQErKJuQKCgVoX3XP09a3NdgzulOJqpNfxksprqerz3Nh2xRw6NYrwNq5V
hGVVIF6TdGPRUxJukKYL0Q2Geo3RL5c8995rvb68nEms9gtQn9Zr5YgkdLAW
gpKciLtSUrOF5sF3H3daqiK8lR372VMxJRHwrNPn1w6669v8RCAwosC7ArNR
M+KSiM/Hre8tXIcG3j08cPDaG4i6sYulTx5EdQOOe8xS2ZFCBEnzUXnjTQOS
6q7QcOBypallIOHoYlXcAAjm91bRdU+Xi1ClvGtrzNWhismOdkVwd3O1AmLq
jao05vnGpGAJoQcFxFJGso2AOXe0g83SKDBmmJqu3GYJ104zZOWMrGyjpDw1
1aMBDEvDkRq2vFhU81Z+b8Ms4lGgRIZFou4jtlwKCG2hYtFoCDow4rXWHTEP
Z8DribIMe1+G2cjKqaSKlyN+7cQNhUy340oiCm98DHJW04pLDS+whQtmuUJD
BokC/pRlxmoa8Cgr6JI3mMg8sJbsPgNyScH/zq4uMdQYexpRkEIDOs1rWTmp
NFNOKObuk5CGXIFfCFVoh0wZQ2+nLDPK24gshS7k+MAH5VlMN/GgXTRlvh7a
a/HIB2MmvWmaqmZ4YHtOM7bGL2pEuxSzeoLx69uE6pDRYZPKJTNezkFen2Ov
G96tnSib4VW28brsZPevqSi+EkT8ko6TBogvsGb6YGm8PiGe0uUgIc4+gl2Y
NeH53tYuXprYxsWAX3lMmt94cMN7rdrZc4bpGNG9KHbgguA4itFJbK1m10oG
OawwxniltSVvXgDc08CRKpyBcheaSzXv7HW6B5UZYR4NdqEGK0zZMtYeZi9R
q/um9hHjATr4j6rwW0Hk2koybgJrW1eP46lxwCIYBbdhIvyecUHjkFOZB7Er
u0F06VXPGL+SWsAYTqppZ3SXEWHqwsUuRsRLcYWSAYXzX1wwIlqGyULNZpqs
uBdd0LJHaRB/wK5CRv+DgiNTp/9X5vwLhWx8R6K2jSOcyMRamMyhwXAJGedy
YlLOOQIvPFLvoqk+mXtuF00B3z2qUVK5/DX2xbsJayBpY5KC8d7xEumtk8t3
NfqDKl9y/+IjSrccpV62DYk2JrgU2c4YNSrzb6g8jSnEBpR8BMgNR15Mu5zX
UwLqlPMqTJieLSYde694A1ERnt06fHW55m1SJG+cjLFyz9U9DGd2rii+cYWv
4LUVpq73qTyHTAHCNYtycpKaHr8xqHvsuTadiPazuHnKEBf9qcbz1eUmjuJZ
fkPKTYiHFH0PtlTFhA8jvHMk/wvmh4P4IaZ5SsmqPEwLSyjR4IwDk+NaauXy
WXEUfp624rBW1ONqD3vxfq7tsZEKed4RuWC7D0Z1lxZPRrBRVKksSAp/0cls
2fJMZyQktRpGHq8aWtLLuUNa7BZpkXukJ8NbjAgMh1PYdX3k4CPoKnHQ1gNx
Rs91TursdERZEv+Yh0nay97JN9/N4lqx8Ovy28wfLRSOInufm6nIryyXvTMe
i6fIRjXK3AytIM2VAkj+3PqSel69S6I2WdFiphCiJ6RzJynzsWYappAiq8h7
tWwOSlc7NRa7Yfqephzy5RUK4mF7rgaM3m23YeUWa9XJWNiqgjrVrPbPgnuy
2WUA7iUb4vqVJe281vnZ283zy7dPh5NYcmsymvjSNnscVuIoFz9deC36hcVI
nDF6Bn9KJrA/TbC5iUkTy1KUcjDXGsZGqgfe2+rhvFdyjMCZzOV576a5nwz8
V8TOYKJ6ZEufss0u99aLm+qT4XWS3PhjPpHHYXOmzGCRnicPkOjYpsRZ1d/A
mBWGlU4prQPvS2QFtNswIBDicP0GRrkL7l0Ga+vVm4u1tWeZWEgmsB1NMrkX
JV96wUTmky/VV0pj8GInnh6jCcv28IIHnTTvM8YTMDksopUOtXnN/Sv2FvqZ
V1sw9sds4vM/l2fnvDs8B9HTNVBP+HA8quUE5JLsfdhqTmB6ViCFgtpQh+51
d4F23PpwZMZSUrpM/664lzUDpBKRoWki34LZuLJgsTkmL6MfOC4XilQOPzGV
ydYfsz6W7uPkxq399MKciaT8V0ZvCsjSjWuXR/D6RHGjVe4c9HzktV9QNftk
TVYw7khMAC/O9EydI5Znf6r3zboYj2SCzqjlsaT2YjrNw940ClKR1BMbZpox
K+WOQY82rhqFJi+cXePbQ7d03dWXAkSVjr3StXihJFSNkHRmLLqzBEY5xfi9
KTnH3fv6mcCn5tTEQ5j9PGX8Sr8ijmABVolgZg9BFwIGxBgNSLHf2RaxOEUK
lG/bxeW424fBuwM4/U4Nz7wzg5xd9E3zMXYbW94CuMTWk0go7zocM++cBdk0
5R2zW5fX52tGugotEx1x0YTYu0js6hGkaVOsh166YKdmtDpmx0wQaR6QSCHS
RjxOuSNKzZDTWPxRJroDuRlEf28AI6ysrgu1TtYHV/BYUg2PYhWPJjSkDni+
zO1+MBVPCJxcbr9LimZ8n30wKcV+/bukYccHBeF3Hk7EdzEjUJgv2uocdNZ+
r/ScRNNsWQQlWJyif/i9UpTFIzzZLGGdH1KNHox1cO6GnuxjTlUveEV++CgK
TCPIqDml3+6ZRyuZJSELkxXL/ha39yDLkl4YPGBrFwgZgCo39uJgqtpUgbrF
52ZRVj+us/Ul6HVl3UuodI7IyhZ9hnUfxGxMCF+qkBfOj7t7+21hfh9eXb07
Oj28Pn33Vp44i62uGrKP3ybSXmhVH1giG8WFpRhCs5NR6ybrMGg/6vWnKe+j
8YH5PLXep27HzRi6JY9tVzzS4xPStZ9MYWo+2u59/ybsh+kjUNYcxKNBuD4J
IlofpgOovILgzKBXEfzOl408v1u9H+BwzyaYnxfn0b3ZvhKQEVFoMnO/0Xl6
p9oLIucJwF+ZE1reGbDEKox9eXRWmYMsi1Wy+Qrs78brQv2hf8RiFFoBOPym
KrIgi1dQKJ8TQv8+DsaiNmkP1p1R/CqZl+1NF1lhbT41aemHVOmsdP/xACGh
cpUabsVmdzdKMpPP1PuBShfyTDMOgHHjgzdRQhY1cTTst4Ez5PY8AvtmKvrq
nkTczYD9eKaxqJpTHw/WujjCOwXFJe4cq3KvOkEcKzocqYRYHT1XZQOVE1IX
MIV4RmopCdXqhO64X3D1tC8IRwV6swz4MirUgI6PhvuiSBxu5Lvb2dnu2PGC
Gv5rmW8re94hk5zsWYqA1FzWGMSMkqD/KYnJXcaBUpaiaFFxyX1NpA4+clKn
6GScBlG5t9+j0JwPi6SRA+tEyK+JvFKSg+FQU5YKBkxF/tV8VJbFCG+weVT+
cIkPRFsnpslvzNXA07iFMY+y1CZQTliVapPo9Q8Kp7PV7Jb1/EaEWdVwr356
9/7s2AAjb3tEeuHXKDCk+rBnPf2GIXRWDe/PIiymelT3AXhYMA8KeCmXpqpB
yigcjvD2Ct97LBly0up3Lj/KDsHbricgN4gPr+lG+zn2W38kabBm/nuRAjsP
vadHwAoxo6Q/nxks3I+6Lo1GWPUEqTaHCQWqJhHdC1RKrtcKNBuHiwW6WI6o
wiOSL0TfR1tIZKkyhcyNDA/AUiZnJ03y1F7sdLsH3rtb7MHJ7ujkfJGGcS+c
RLyFMgX8xCxvmv9ltsvcnlFYAIsjpTER9N9TeHtJ9DyaRUNFueQmp8fsosuI
C2l66njIUfS4/25d9YwJPBBYDxMV4ChqvHwqupQj+tzjFOsQXl6dURRQUZP3
xORNX0mYU49digKhaqOB9gioCi26lSec90W3TdN9K8pkF+ZAR/Cwb8r/Wk2K
KNFKVqtOWT5NYy1qRdBj60pAhMCooqFcMM11J7bcPsMOsJ9DXAtOme3dnb0a
jwEqqTVbqzkHUL7xN6LJ9CWnBAKZVW1DcjfCkD4uMJ90URgT0qiI8CNcoQFX
UyooDbsv8aadwI3NJOW9PA0oo2TS5Gw5dzmcAuuWLhp1ZR14WbEFb6VwDqLC
mSBrTztVa+pf6XFTFvEycuU4HwOzmTFurIAG65s4EuGleBjmi7XAB9jDHL4s
yAevjq3QFIro9I2cuHUa4yVTxKir2IY4jNAB2+Qu5LOuV4PeAVpy0/zJcgRM
VIkh8eZLom0Yw+YROiKsFiVuA5JqQhqTwhJBmqxaO7700gA3OKopgBs9Oeyx
h7fE3ACi7tBxNTR0cX4GVihCYNQmKdx5tR3Ok1NWajl5AUN6jjz8IrCgUufp
wSfdSYH9NmKzuH+igzJFlsBF92LNxOjT1qUzZzZ+8NS65xdzTuWLScx2nxZd
t1uatpx2wUL3JdViGxi3JgqrRlJs4YMl3vJpieUlnGezvYAXZY6yIMWCZnex
EQADe6qslGYXnmiFA6x1tsbbleXYLyQnScA4allcAQvWg0FlVm6cPUURNF3c
D5c0Sw2fN7OZREGPq8JS5Ix4G7BvZWuNJ8CbEDnuaJY0AQ5fYK+YJKprTuno
aIX/qE3HqnzuUNVaxrBf1IOkHjAXKHNoc8q8woWac5nN6aWKs3CdTUaBzJ3s
95Vlg2lUx1E1AnZpWtbwhRZgswQpxJBungq6JARCcsVJqNWyINBQDUbZAqcV
Q3jLTURrjiqOwSsVXgHBWXSQa8WFEPVOmzTgjTEmqcpPghmONB9uwRS0wfJw
K2JG4AnGBnl6nI1iDS0UxmIy2NCSdyKjZofCAwXAVi30ppNVDOQpJpgJiSIn
tXAj9aIQlXeENQR45l4JGFLPbAxEgLm5jWZ5FbRZ6+PhK6PZUqhfBPML2Vzy
PkvSHzC8S6gL5U4WJjCvY1JLXaqHrv1h5ThPG4UZ07uiWZUuB+o1bjU2oqR8
8X5zGSg13gSdKBVbYC4NrZmbox4EbGAqwlZaEgvgodoo4qVg7YKwxp9OlsIc
bs3PxREThWUxg6MxBweWRPmG9MaDCRU9Kmuhh3AcdqF41s6q4S9t8Fq1R+st
jG+DKOzzBbfYSZRrQVHbWkOzzqH115UuJPppUmR8LcIzSPJ+ghrSRE8UQLF7
kK+b+Rgpw1JhpmlBr69Tx2isvT0Jeh9YLrugUUds43WkP0xi8jmq7Hc3dmbc
3zjpCMLvkL2H0L1WMsRwT4E81ipMdVvXxd0yoq63BDSHN7GIgugI7McYFVlW
C0VsZ3DkbcLrdQ8GPBMNrFHdeJnuTmm0WcrZhSCuiQfjdyiK2j8KglHxgL0I
ghIx8suLJiKEEeCMBRRwFCM/Sp1NrVjWmzT5wKqVs4lT1hux8SLGaVEEOaBq
ZewYVNeGtelWgd8M0hn9kmW0gYwKWRe1qdDIwJOVkTxBVDVPZkBTKQ+8J3hY
GyJZJgF1zsOYhQ8xqrvA1PGrr6ecf94lTJ9PfnVdt4cJRHlmoAHVG6EN3nhf
hblwYTCRTXq9adqoeu1TTIarXm4OYZhg6p/i4CPJDg0ixQd7kpgSZMzFRmaS
Yv0wcZUrWFOjS6om54ysepypob2B3gNrirF1Z2FNcd09x6eyQrA2pV4l2IqJ
a09UWehUls6Y3+m64Sx+VNGSQ1iiZciPxaxaSXqoKF3oOqVFifpK+G37OBau
AmMbloXMd5ddWdMu9eE0Ww7JbIpVeIUaFbEpk3bGulg1itisukj6lUhfNTVF
0yhe1mYOes4Xn77aws1iTTT/wmXtJHb11jRPNHqd/VqKRZcR6AaA5rHoXwXr
H4/pittkFGDtWKva0bMMfH4Z4HWDXG7GORVp5+AtBd8IVpIV2IDbvw/6lsoI
zU3fAu2A3B2T3Ji7/rVYSnU7P1YXqKzNtIDQ/qHjvY+tMhCaqL9Pgb15BBK/
eqZw0wKCcxPYrh/49dKzipr8br/xASoZmPTh9/WiPJIs9jWZppMkq/GPxljj
1+VBLqI10wVPcHhMy2wu7W7t7es2n3FGbAESD8KI8R6p/vXFGlYlZkFqrDKD
ysTs7e7egaKy1zJ2EXTCGJ6CNe+apeMwTqJk6C4gi4RrznYnCCEK1auHOyno
4hlTTA3uPZgBlDBmrBZFVcPODAQC5PRAd3Q/LBBVZpuBaFGidcqdJRTRMgqE
CytJsfQdD6REwhvv95LxOGiUP/I7lYAo6X1IeD+HZXL/0DtLMmKbQYDWWXKx
JllCLivKLH5mThVzuGSLEORlMKW0VJ650ZwbhrJcinrkV60VOtCoO4c6Dotf
y2pIBvYie8lYuVZU+DML3Szss2Ea9Gc4ZxbjogQ9g5EG+rwk1zMj52Ik6Cys
5bQ8zcgBPmvGhbhxF4SUwiWCNJbBj18EyEsBsvXL9eWal4dj4AxegU3jGNB9
ZkkVS/qJHyc5cATQdbXWmJshx4n3NsHysgSwdfwW23srJacWiXfDesGU2lQZ
iMfkEcc3+SO8wdgz9yoNP34JLK1yAvxgHhb8FyJdQloWmm9YwkgOKhCxTlSC
5416OWFbmQdxT//kiXce5KJChWoBFWBjygm8xhtC2WKnf67u494oTWLsbXsc
DsMc3vspBBhpb3S/DuByLAGrsXQCEU1IeFrKCW7pooaEmJn4XiCXpMW6FF+E
FOoQVsurRrVdfLEnZs19QsalunU7Fon6NaJojASsEKUsHsrOT6kCdDZKEsuD
1CjMU2b9pYyVElDr5jdTG2J+LPAqvS/UtZeZeViLJ5CRlWADCokoeya4h2OC
yhEbqGF4p2GDyExDJKKIcg8+MHN9AIh1jyccjNY9PlGeSyrzfJu6wJ4Xq3r3
i1msZpfwCNiyfEmPrWRlGoSLl9juxYDPQva7EDKhTw2nodNf/1RUK7ZfwFZi
upW2QFdeEAkbKIii5K5YL03k3tc5sb/U658vXAq5qntMIZyl9cTYrn6Lc107
PUvHp9BRlRcbT1dP1d2cWYWoJBZhdM9V2S2c2LDlDMUTq1cDpfK4n9KA0BLe
SSG6wCHr2rtJT/FnMX40Ma67AnqQ+JZPGVUSa8ipMRWBEQqrHSbBBWzdtd2K
rwwowu8dY7aD8KCLOPiaFWB1kokjrKgSuDy3IHLs31Mu08Xb47BQzoJRxtmz
rJd+PqGs1zn1n2XdkPVBgCWdtPeVfQyzPKOmHvyiyQYSssxGY4HVAhQzYDyv
ls+/WthHlvbC7PEO+2DEplgDDuZPYeYjRsKVpGRoHE7zBLux94xQcoNyBkcO
L6541Ieu/44RPfy8Dg/o93tJystlOgPVT2UkEB7WioFA6Djjwi86oadzxP48
eyXUu1/igqDz2Sc8/aEU+Aw7pOpjYGCgrsdeL0fcrJevmk0d7773JJleR6FW
q/45sq329iKTL/u9YBLchBFtg/Pl9odYJnwQYK9Opc1MaDOyALe2UassZe9S
zeFUFw4QoGM9iar7D02FSdYrBpy7STRjcVxQPRafI+0d4YsR8zsgDldHfqfJ
YXGJZGlKmHrSsNtJ0Xe0EGmUpv05TPMpBeOHt9TbMMTu1Cc/X5w1oc9uu71d
oA8uXUEFZTWhgJ6zPE2cdFG4vE7S6ZgW6JuN/Xano7+5wvL45ugmWeX8m9Av
6mbFUPuF6HeGVfr8rmfLltc6614dfZGClffHy6DLdThm/nF4G6LlLMokR+yj
JtD18fkXSZ8kLzrkFqLPu+u3PpCAq+ao0S1UZwt2RFe9arvq0buri9d8r0JC
OOlwlMSwBiM6xNwm0S0CebOx134xn61WUx5c06TfW85COw7ywDsaBVQyR7Nb
ydPxUbMFB5qqW6OpzGHqtUxhaFJXCj9QVSSYbj3XoHG1oamWpajGN/3AL+mp
L1RNDZZDldfhDajvIlFeP32iWNlPTPQ+83nNh7nsRfmuVY/vCVuH1nxFob1y
lJlNkUbmIaXKyfeeOPer6MGknfRAiih76yugyaTvirWeixyHb69ON0+ur069
i+OfvgaaZA+nyRVQ4vT6vX9NlsOet+ldvXt7cu0hrbzrzkanvfM1UKrP/Vn+
XYrFPIsOm7mpJt1jvwhwXwGFIjIsHkoYbp54rckIZhKHvbWvgTQDtC4eShky
Ub4aavg9YSIvgyrS3P4KiJP0p65a3nPRRBzhjt9/gDOJUDTYg2jutbS91d1/
BAIZ51Q6ny5w4pRH16ZU5cCXJXQ2xgtK31dD3Ch0lh2eT+2Tl5FtDDfWvf1X
m532q7mF9Sm7Hu3S2plk1hJ6elFejOjZPZ0s0NRL9uKe8vrxpcIjDoxnWYQc
jMjY4Z4/mf7L0ayppmqgk2a3zgrvcyEjb+/VSy40PkmnPJPQpQu/+YnMhtgo
TBbDrCFuAYFeMpm7VLRD7vh4CEwXmFToNZM5wiTj83DSQ6E689yucBHgmgV3
bB1w36gniNmgYo+BGONhH3iVuiTkmQynbFhdrin+up4sFXScZsFwkWrhvCYg
vV1dIZxGCONeNO0zP7n5F+sVeVtEYgZ9Vk85MP7eqsdh1tVjFlUrl4jCycc6
FGp5tI1Kg799iW9nnq+1SLlZ5c+zu576Lte/alXZlC5ZGpVKts9HFTGtzLsa
BVid+TLMPuBt4QfvDUCaZF7r6vLsTdYwBPcz08le4KIbr2jOuEifB8oABKx5
63Pdl1x07jUhq0k4GqFogwvo6pu4PRgdhMhblNm4FdCRf6qPsTTSNA5l+oA1
Ld4um+LtcpZOUizAicFyZppBD2xL9tH5Os1JoiT2EDkHMwxQ1Obk077h06lC
iW9O8KmO5eBEqO6ugaR2UFmati5OzFgqZV2qOGCiWVZqVWgZSJlouTCqwAmv
Zl3rA7vd0iI+J1jG4nUuX2km7W613XeSBLB8MelcuZ73M0tpvXfXzVYsGzvW
4zjgzlZ758A7vfJPr4onHgcW7mYvut3L1saenucs4ofDyTKof4pLBEunvwly
dhfc6wbFrdM3FwsxYW8faPKep8HPAn9e7F9v/vDqZljwva9Cr5ycrXifA29O
0j6Lgns/ANMF9p5lELdQupNoeYyDrMOCCzJq8wB6CZVGKZpxHPbShE8+a0j5
PXIk0YV75RqoJbgWYS342xsd+XVJ/Pd39tpS/Jc64rw8w06b4+l4GTw7F6Cm
XwXvup+MZ925eRZ8XBrPBKhnnj0az7AZRx8zS27AMroL+2Yr76UpyEsxiPdK
DtKAcTf3aKbj7RXnntn1w1ZZPPid211kh4LRJkVHjQiCEE95qLKaqgVF1ISI
7inluUcJMDk1K/vMclM2Tx5LbnYccuM8usxtuGrPRdXhZyEbt2SK19q4FnZl
Q6AS+QVsXHK7zGVe7WxvA0/pvSOjV+xJxMj30ro4ArBHZqZIBWu1JQavXKxp
/u5t7NfrBZMALjN0AQLNshOfEp2yReg0SpZCp58AzFEyhQk8JYosJDn11vYi
iwwWOs2OtnxBm8fZ+fe7W1tFN3wuh3cQt4KQFrGLZEWYHJT7kseTV0D+4R3e
sJj3dDBbRCXDgMqLbG32wbMzy+Yuc67K5n4I58D4fmTunfrHGyHLB/4ECAfW
hh9Ew+TAOwrS9B618tWlfwifpGE+GsOYA0xIrVkK1g+gCJzzkQp9dYtZRXvr
pw/7Q+6X8PI7241eF3zMgJE7cFxD3xX+NsO8MxnVwLx7CF9dhp20wwJubElx
QqPdNmRK71LnUum6wqZtCcaLim1+Q8+Ufmpw8HpBjDZghq16BBqF4sCetBqC
LEt6PNtZNRCUtmNahnxRBNM6fwVLmrvsqeaTiM5oqrt3tsFkPJHBscnAe6dA
yUCPTPg4y4PrH5fid2uhCgBcNzW1/4T1pq5isoIx+BBL71AZdJhhKEfKRH74
GKOUgExi4D4yiRz3ZqKmuEbk2gVdTXUXOs55sY+fbl4JoCgPzfYkBRZm4rea
boNJ2lPMQ3aTsuADSxe4nFPGtoZiNvmooKoxJKiBQVhqf+xCbAYZYSvxX4ei
ASihNImCHkn8ARAhgsWjV7xe0+MkM3drXQpGK8ZWlAR9+DsKYKWKDspYBGCM
uaakktZmiZE54eDjkiYcfFxkwhFssDNnjIHtqHdoinrGA3Y3/4RTAJsUk7oW
mO8lh1OebV2zaloTPh7GYrrMWeT+Wd4A9qIAK0koWLOSFeaN4VBzxbe7e5gn
dMn+PQ1TmmXlLYP3DlmD/vLK23GDDuqSvNxzvIpcM/iCGy4oGUrozkGR3eB1
PYg4HPCy0jZqpnzz/uPrtLvDyzzSYzzNctyjsRssblYDKr0R2UYCd+UEvR6b
5A3T1xbnxkP50ZwjpTb1n40j8f3vmiMyWuGJcgSo2acX+V3uNP7S6K6onjPb
XALSkV8ont8KuT6xwhs8ASqYoaVf7HRhNojobQi7Gx6lLgD3HqYLZ+pGU9QC
wQk67GRjylUqGOvKS9OuGLhVSYQZQvXOnK6syjmZRKHRa9lR+AMMnuUiABNC
egPcBtK3nIPNA4819qHG0QiAXBKPQCQC/EVTyTbzenoECu1awLxyh3HxKK41
63huDFZ5vCAkwmFc7qhRje8MBp4StJnxZpIbtkOhjHMl1hkeAp0RqQthLQ/g
cALkgOsJ3Rux3gerYJk6OswxhwkJdFpSccuYhob9KWZyx8LhqNzRfRkTUaAf
Yx7V6xNol8BpDI5/826vxTE9AuVxUNVtKSswoI9xPxwkU3cQcxXWM0h8UUQT
2yViMw6sWGh06kDHsnaSWD4UHKWJel7OzUrNvcpOtXhWkChO/DyZUPmoT0zT
XDb0ihNPomDMV3keKCujT7fn/CGfzwnYkM7yJzjn22cTtITj3M/AfCulOj66
LMVUMo98JAoVY+KlZcOx5F04wGiXjhfbg309MqBVwYCPphFiYjpyvFdB78Nd
kPb9S9abphkaCyUZbb26vDha8/rJXQz7AgvGBgSQQl7psjcKATr82WwtgKly
6Bz86MR/RZcjZQyqFkSP9amos7oLAy2ZpFhPEdPDAOUALxGcb5Ol7h8nY3jE
eRyxb8zcGOAtWuHAs7+LAY6Vq31ui6oYOYprQ9YrpHS5uQy61k8+qZtDfBuL
ywH55l5MeAllSOQnXkgod/L8YiwKCcMgxWnO611mE7z+I69DmHtbHRmC/ToK
hgA+ZFFffmS8/fadf3F4/ZP/88nR9btL7/rs58+m641njF9HeT7JDjY37+7u
NsIgDjaSdLgZZJihRQftTeDTxHie/t74OMrH0XegD4lPtyACwJw8ul1EpZIv
impmWQEMn3ofMeYYJ31Ss+TqUFvIzb2lfhXaHqDtCPaZNfM+1Wvln0zjDzFo
RyCF3+e65JOTwTPw4QSwSm8LDPHEEcb9kIekma9wvOdZQp0Xj7iEvjwF+lSX
p7qLeAorU28XCq0wtq0iksNsHkHstp8F0SmIT0cOyToUJgNnH1l7jUTSYbUv
QT6VvSrMCOtMJxGcSwof06J4lsJlSKG5ZXM9I3fuz7xfc2TMAzC8I1CbSwa7
zzL4xGVw0h1/aiMZ+H/RPb9AX1VvxMtMms4WMJBhQx7PJWfbjylnW+3dBwfO
1ofNDqz+UPrnIgljKgvPq//iX9VeAScEO7b2KQoggBj2En8cDkUjrU8ujHHi
vYmSG6xHlMQiVcaYr3VH2Xpz9G7N08iSc4u8wHPJ6+5jnvZ3dvaWqhete3J+
uyzE12rs4pY/3eylRGOLsk9YNLMkmn4+yTx650kEjJnOL3I7zyL3BYjc5EPm
s4+TgBfv+PT7Mg7xv9g9EPGGB34bU21d/K+rNU9jJ5rEzyWFe48qhV10c2KM
V0oF2a/lZdIRdmokygcR9bVyS47lfS9J8/sMYQbONyXdxF3BOcNyeWE2fooi
dpNOeljOj04bc/rLH+fsi6devFHxCCtj5vYNU3Mp239cZ/rXe1n0dKRUxCh+
nvOwcAUKt7VnSeT8h+DH9Es/ztXOy6coEY4Ljk8sFo2uNOa69XtMT/FXIxpa
MGR9siQNQcstEKknIXgcwow8n8JwwSQsCpwDoVlyVsAA1MttGHiHGPSqDWQ4
Xo7HqMJPZS8y0w47vDitzV4pYIW0fhTEy7JFm48WGct4ROn5bGLbnFo3w8ch
1qsk7TNXsYBXbxrR5UW70z2g0Bp4QcS1Y3htMMmmEafRoYzLr1pAGawxXyV0
+jKhc5GQV1BFjtRQc0FVhasvIzC4+SnT4r8jUJIoMuCZ4ZgdGQyHOqEYNpM4
m44njtN/HSlnhVOXyYYkFSjQIWM4TNkQe8jphDaDCiZWrfNXjTrtPN1w7Dpu
YNqij/mN9Bvr+xRC8Qk5QemGmDuZxLryIGW5GhOE1d2Tyfj4ELVRBgOeXmyd
nzXq//dlMghTJvj2nZV65jw6YygPBPuQqhrO1o5zfvQVrwzsA4u0xLL0Ye4O
83l0Buh0bo6OSX6BmQygQHZcHzfhx0L3el4NVR//Yq8uEr/IuIwi5j+LItPs
4kiYRON1KVrnV42U1e+DR45Kz5+VR7XpO2vIvKtn5knm4QG9WOPis3KPIwRM
evtoTHpSPLI5tFDxbXXSMOrgfXGnCzHz3nRM5zSQu7zobS9SaIYsHilQmDL8
NWWtVhAsLJ3JF6fYKZyefwckK8e+L04yrOBHFva4WLvvq6GcOnE3P/w3J+Wh
4zhvAP8a6UkHd9iVAZ9G5/fmxDyj0/hAVT7yOGQyYL9oSm5+/z39/T0qdS0o
Q7TxAFV+1fD995v8afmxZ4ps3c56PQoz/RavZMeLKw2x8RfsruawZkLfa9iF
s2TMPH7n0g/ywJ9EAXbDYL1RjFfsIcvWdYejMVg62I1JQcjydEo2Ak8cVJmr
+q5E/UJlRvKUWvEik4Czq+YUV3mvC5gLdeYwI+fMlFgTM3Mu1yQ1HD2Nlqyq
F0ypGxBKE6zWlOyPBDMH1PsWXMlAbMyB17SpkxmVCla/hf4kiXtWyQeOfW+U
hFgjrYQyIqtYoJlkHsldyHsCov7WSL6llh/BNMq9FSEl+rXqGorHDgm5t403
GhdXvxS+X00IEQsG7m94cxWLzi/t7yuQIsR0scNChTk5Fq+daWFJ67P0629q
6brXb0RX7w3WLn/woeuWoCwi59S/POiNDEYVl37Vslr3VtOctyg8GOregXxG
qwqEWKnuxWLNfu6FImrmlCb/vFBoErhQqjk0x7JR8rykVSPwVmX0Tczl8qYB
ffXISwehYVgMwGlCaB4Jo6AZqDoWsrk8HXn+dYv1kAtZoPwDAQqoBOJeAzVD
VNbi0jA94y0F1pgfUVrknKYwhIvWQwqThC9dVG43oe9hbOKRJ1j3+N9TFin0
7qn6CcfC6nbgnQ68ZBzmsDDXvTDHSmLTMa1tWOq4wNVE5eve6bEFgLfO+pPX
9lo8j4UQXyvzWBCjF4UYvfZZScFxWJAQ/OWHksEQOxchjK9dpGhCiV9GjJvR
qGOzHLMphYRmXsawiHokscDtxJrNqjH+KixcDLwZTsNsBBS5Yfkd46DHNgkr
6WlQxGsxOHbdrwkrUzjDYJciqlgRPZ5gQr9eX1gb/4SlpA6xzio/1GQzzQDj
HXEQyvwkZv5dcC8Kl0dJltXpnQtj1HMxauvifM0sB446O2VI83DMuFjB1qim
i1skD0LBaFCQW34jkJBaiUW1bofBfnGuymLTqcm0VtDYt4EaNsvFuYIRZN4d
iyL8F8u2YqU6/H6Gq695TxLD+anGnLPZSBWIvf3u1oFn0F9EgJLn9opK2Mq9
4OQjUiLMo3tLxgQsbN3Yr6uILwKQgTKV7U80jpJyJNSWLOnFTkt9Gsb5VtfU
AGkQDxkou42Nzu7e3l63s+NQIbyu/YpZyV4/VeFB51iIynRYDgHOWHHv3vQb
u1H2Y6QtRW7byOdMWDeuFaRemgsv9ZaNVtE0cA2Y3yWfZMmaNXOel+zXuWQt
WfpsS/aaY9Fsydri/6hL1sbrAUtWqplGHrSlrFjHgn1eoV/iCpWiU9eGxD6C
65uFkDHmD6IkgHX8srA+i73hzDUqzyEf25P2rLWreodovLj7ZHqTpwEV1ucx
pDxfKuCOb2xYb9Cg3GquJesY9QKQqhAN6ZbsY7uGqXrG2+LEhhl8OqQR21pg
RBCe5AJURZn3v5MrXpne8rZUFn9eSsdc1S+3zvoo83Z5ek3wkn+1ADMrtF5h
Bip/6qmJ56GjZwPJZ6ndoWSCwUb9iu58qLou6S/lDYHVRRsUYy9HUgr3kbgF
ipPYFwXFRX8GVJlm3R/zdPmaXDs307gfiaundWcXiuJkDBCIMxwu5VUWpp4A
0+Bcz9uLl4Fl8zL6M8mqi7PNhHWah9xB+cRkVWs/jiHf6UlaUyZ6CnAh5KJl
cNl8QXCa+NsKN9jGOu7NZrcw/DrFPStd25ghbTdOnCx5MxcMmyFvTnD1Elfm
1mcSODd7GlqFcjYOzOpsQXlorLQJ81Ga5DksAjnShtN6+HT2fdmHucRj+rMR
9PUaQc8mxO/EhHjefp/09lu6nRT+ljl3Luk7WXTn+vSeqaY7VzNvVSNP7gik
apRE/VpKvpEgBtzjOgiH05T7ZPT7FCQuZEy7ZmSipmYxKJqszhgxH6vh/Mum
U9Qo1E3xSN7XVUqLYyr6drvG5TbriluaIbxmsjF6lbOtwab5MN/WUrxby/Vv
LcnD5fJxCVFrdjXZ/J1i1NZvTURGyPvMqAjx2DJFZndrbxvTMMh/eoZ2Glaj
kv2eaVlT8CeyCruEOakr+yo3oG35DmkB3UXq29c0nbHA0ySqWeACnrkPGOEr
cq9QrKFWe6vZdIIbM1VhD7GEwS2Q/M9/kppQfbZq7hW8WscYXsPu6itOIKvo
Tscq+zfYBjSj8IjYW3GS3fsDACmNaIUpVYUuqNI7lF9agYlt53te7Vi/1cvu
2bOa+0xqznHdnAwGVjZzpXVTb99YMXC1Ns68MUbvOII85Ef0rezztjT2QYab
QvRcZSBQUWor5v2yNJe6aWw1msepHBLwFmgQ/gz5hPMReV80gaxyBkH/lqV5
mJEqXu485p6GwmWRiTjV5hxi2NnYGAcf6yWwbrad7tzzlSjbTJDHnML8TSgl
UtT1kp9DHbm3AmPp6x5Vuw4+WHsbN+J9UD4muas3b2X2NyHiwF6qkyANABBm
HQQRbMgwaBb2GfX6muAh+gZLflqzowDTKIKjKY8QpGTU6VgczYTItXiv2+Su
EkTlq0kc3ZM7ix+uJYNtCFwJyd43EWxU/XuFPB3SaVTs/+qtBnEyDqJkmq1a
MHBLn8Y9kVuqHqIaWaDo1rw7bBKOp+g0HA5BRhwReW7WmTURPhXn4Lz0xTJO
4G7xzVvlvvTmPOuBNgPKPIBv2A44Yim6Sn1bs/w6m0E68DQcCI1iBo16UQA2
qqaKoETRnCM3jSgbq3jNH2Ufe4xhGTcMzFBIo4jbBqEW98YibqPgINt8Ujwr
XFW4v2UEyaxIVSbMNJ/cZGaSqTt1hak3uGPNg9mn92XPksysMLLD6/pQO4EW
0iYoaYLn44tqAHZOrCl3tY+JM80KfRf2/WkaonNJ/LliP1qfSHGY4z5PRWtk
dUkdKh5zkUqMRuXVKRXCYDBxKuBBtIzvDsQjL5tjiRQ28MJ+kwLZ2ApEb4qd
EzOQnuVj5sq1qEIOuOzb8mZjJ78voSdsJd6SdmUO7K94E1t0TCZwBkAM6rCs
BLXyVogrnztfA2VgTmtKXh/N20B9vTgb9SONqe2NrXXv5C8XZ6dHp9f/vHz3
HpgBbBFjFF4nHLb39g68q3AYw1aIyuV9LNchVTehLNxL0ZapcvhLdsXSnwtV
GXyXkVgJoiVwXHMazr+5FQo6mRooFNdjQgDpq3xSs0Doy4KAgcbvB3mC+i6d
loWzNomLnAzXLB3LIqbUXwIO0NcXa8a6+vKXTnV6mYkmMcCVYWYhC6trCGQa
zoMuEZqvS15txpl6VkK7wYon32Zh+3te+p9k6U/jhot/xoPSnmhpBSBtCv0J
t95XvD+UUV9puS2RteWZIjh2YD6ATClhMluTkE1TurbmP01NnAKVnFZOfuBS
lTNX6BJU4WJKfJaevr4wcbAymwXp+RXyjcReuFswURcndnqsDn/wEXG3kC2I
P7KGAvBHpybGhvhKeM9m6HyYfVVm6Fe3lxp7zfNuakD6tLtpkPmiWJ5zD1Vf
VxjPztfxh1eHiVl+oB5ZmgUNS/twmidxMkbPzdV9lrOx1zq8WhP2/pe/2KtX
zeHVrIVSwehCiQ+TybzGQ4nB1Ujw+z98oVQjQ4bGsFJ1C2OCVQ7D65HEszzH
4lB1BSPK7jH/LsTayEYh0ZqyEZm4M6nxmHkIzywEKmHoeqCyHGgJdyJQtQfP
kyVSvBV8zbImiZN2OVSbleXvZsils5SpRN1VyIL/8Gsyx2BVd3wzUZmJTPH2
1BIDxx81ayiuKOFqDeWyl6k5PN6jYbmej/x39+KrKUxRrk0i3b4FkaOym4So
hUUF0rpxvUQuCxuXWIGdPEn7QhizPMhrq4PiOr2kN3hEQEWIIsZVf3SGJiqc
qsLFDdi4NAhSubQQH6DCfuYLNpT14jOrzEcBEO8JAQYkvoQljYwI0pt7ggBD
pLTq8RYyZdG9vQMD2T+w++Jtqgyrms+tbk3/63GqN/epz+1yrdRUz8eiBx2L
fFw33oCaIrnwo44DKvTUpwfnwJQCkIwIWHq/pOIr7P5FLf/SxoNQttsv2gfe
axTfS8bFqgwJEwoEsErb26sfZme3c+Ado2YJpcMgsNc7L4MJNvzlO3ezOv7z
FsXitI8NIn3+SiUrG+xJs28yHsP93tTP2nCZf2JH/lvDO1PwFD2vqudVVS3F
lavqaXi2n/3axs+zX/vZr/1swD1vNWqYz7HVzONFLx6d5/Ghfxn+6+r9tkiL
2Tvu8p2ilf5K/KlyjT6v1a9mrc7l5a5w9DgSE5xOOy6iYOfQ5QJPVhgkdY47
LqOYsxLinYmR3GR77gyYBf8dgyWG8cCFO0j8WHogb1nTJaMpkYgFJzIowkwD
q/Kv0pDCz7mcIRWwGfcp6h5I4aifd3v1TuM+NqSAVXc3YtjIQDklBSOM+Rru
21tW9CQ+zK+qfaYyCZ8TwOA24USiWHJiFlRjlgepEQYujhxxkrc2Njb5Iyzu
b0p1t6mui+nkYaYK/gGOIfie49G14nNAnMJHs4bz/uQ5ADeAW4GSC/sGOKyK
IhWrjea0KBkdCBfGtlZtIdPTYCylVXqrCoFVzuBRcMszqqpTPbNgzOpKvFcL
Z0h+d6rQgCgoFeeFqLgLi9XRvATPLRoGf15kVyAATEyM5OcmBDMWAEycu1HY
G3H7AOGYNFDbp8zXAFVqzNC1v1esHgBXv3aIBJ9y9VQN+GnXTw0WD1hBcxHz
K1lDMOCiK8gl5jPW0GKrIMuZYV9Xb1r0HOyQIstfJhERENUlyphe+apQNM4g
OcC1xy/qvPP3V9d4KYVtwGDnQ+B0s09KCE5CBhTYMiUQNrEHeE1bdjCeROzA
5qktDn+0hIGh9YWdUVY1MVa9P3vtOhB/bgDij177y+6W4goe0Mmxc0WtGSJP
fJttuP9mSSw3h/F9/ybMx8GkYHfdw1cHI/bR520MZhhgMiMOSwfD/4fBRLdR
qNUc5haVl5aodLPx1cjvqydJRqeezBZhcZXdF2un8k6c6xFV14kXZroJh6RW
sIQayJye9qq9Hk5jvX2axiVAXFV27ipvBwFU9SWudtsHoXR4maYU4EwSrtKA
CxM5A4SpKmxt2DgQoRCRdQnHYqTQbWKG65QJapcXs/ULlyIq+2wM2HDayqJf
3rQpX/RTT704aEHNUidAVJzY1ClAVX2fK7+llhe5Rw1A1kdAKVO6eemEiA1y
+R7ByNi/p+iXsMc8YwHR5j8sTTxe6Ey8JAtBqWTRcXCPml70IjFgoJfhJmW3
WKPSAn6CDbkwMVQzisNeNYm5ai0E5FJmT0duvBYt+6D8brGmXZqM7aVfubWs
8zYovMdxkBcUxp+8zm673S6kzxYw/ZPX/tjutPGnQ3IYm/uVb0+21V6jLZ6h
gAh3v0siLaXLp0qz0pMFKBy5PwBQ73trt1rzjNaB+MOfRKZIlW9tbjDPjRqc
u9uPgXR3uwHW8FAt1tZ52u3LAbRn+nCscmfKjaCsE0PxSPPsngIWQWQUxmJ1
j3l9tjEV76daPhUt4kqepqyJ1eZAyNkaC/EvjWAaBhhZtUKOiyb2CQ4d3GSU
bl7l5zAw8UJYXCGzfYi0wFArCkqR1u/12CRHvfeSd6O8C1G/YpK/Au0SrKyw
Z5hzqC61sbez9+LAe8PbxcnSVUaTU1UYSfZQdR8mSEreYEksX9SYwuKJ5UpY
wmx3uxQbeSMT4MRYlEyUfWS5T7NGmN8ZL6k+TaqGH33qji109DGXxqPogwuk
NWWIetySC128auFrRXvPOGSdyqs5voetGqis6jZh1Ki5p/vTGuyZpEkPS7UQ
xam3qYGK0+N3x8LhKC9MFF1++4bBWbaPK7vWGV2kZYFmwQM+UrXvrxC3LIJg
fZ4SYmiFO7R0V+AAbjLqT8VT+qquSF3mjIKerc6akm5NKZXiqniXX8isypwV
igMtHFVpaOd0GhJBRAU/EhEE9IWIIN6djwiF6dTtWiDfY1g9PaWNZlSxxKc9
82ldRVW3aCEL2JhZYLzBv0uFbwQUbyIu6+keyA6xn6cJ8CFoYrAvs9yqOoxd
AzMeh11czs5lStEasLrzYpLWTMVUeLNSH4k1riSm+N40Fn+w/ixx4aXuNLK8
tDBQIUx1rWXRykrGvRuCq8xsJAlV38lHDYribXfb3QO68UKuG9d+AO9qOpkk
Kdoyzr3sjW6d6p0DGUJf3S+bBemqtsIW7YJrLr6BUE0nQMYwSctF80nNmgzT
teb2nI45waO9BnoYb0q14BEankSjSfXxea9jXZOnOj+ffe6IxSefekaxDtjj
fBE7wn67yWrlr5GwpdntpAGRRF0g0j5qPNvX5i5KTe81VcycRJ9CMfOAKW59
WjFTKo5LfdfgLlM87GrCW9TPckdwdPk194zyhvbSRV5ipPGQ2DkLBoDzBl4c
1nRSGdmRlBnhyi4iG0JNW1Sb4nwp25iOk1vBVCmZKE1NiUJqkmFJZMWjnDmS
sqiC6C64t+Ja3Ic6ysTB2vf3lHHT4LhnU1ROEP0ufEhpCKrjPVLN2iFcFFTC
WrhsV7LqyHCrjjqQZVXtsBNHVhP+PCyzCX8cAOfMcCpAEPlOFVlO+GMWuHTn
N5YVZFlapOkpefYpxUXaynrxSRLPJzCFmU/pXrAsPxXbC/7QFmO8Xc5FLgQH
FvcZlx2/0lBUHaEqTtrY7mISEoOibqmWmIYWwcO8SpKWtwAvTa1VlLJlrsMn
ufR09nMjT071WbD5zmYsLHNnoxOx3sUU5rW7WbWeEAxVwuFSElUqoupUxGfh
1Nil6XDeGxyrnEOVMLtFuUp5WWIsxe9r2UR0H5LaDWSWyFa4pOYVWcsAW4LI
2mh9cpFV03kW2U8osiXF6xReEQrhm+4/Kvpbf2iz3bjihXJJV93SoxJ85RkL
ZhCxW340LBwI5K1TGYfieaA0bsmsM9yjTS54ziqHXlfBezH1Zr6XzZ1LVYWN
d60gCFuGBI0zAZYit6zENRMFesZ6XdcnZjpSSnKKQo/evrvmB+uIfHYNMOEX
DClgkmYqI6sSQQsGEcJEthmCFgwT2ZLp67yUwZ9GFi/3ZRrCMsvsrTRh9QWN
S2ug6NiXNhiDXcwh4JIqpV2Qv9ZQpSrjZQk3FObudsFcdXU3qM320YXMpYNF
s82aU0E1FiZ3yAMmQmXrU14ewQVAvFx6FI7D3NFzD38WGhTVMTY/QPpTwHvO
0knKct30DbUM+yi7FhReL7BMCFNtqP5sbWvevM1QtjJgjZa89V6NzjWfa3Rn
zjdKTAMYTGPumDfrsgfq9GLKq5HVg1vmeIIlpshu4fs6tat3yLAIDQyiIbpd
R2M7MrCi54k1I/VqOfRPKBprJYQDf8CCHPuLrJToL5a9vRY2v/fEiBgHJIFi
QXT9DF/UZUhFLVO319RMWQqAqesdyV2yd1zVNXi1JoM5XofsJmXBB1DqhckZ
3DeeKcwMK/ZM0bCB9YQLep5s07KvTypJY8CipVVc2yJkUCM7CjCyESRQ4yTt
LQ22BAT1aLnWFKKjXyrOXfBVP+Dk7WwazapOde2kjAdvgB4LA/I4kskBSzZw
APDYv6dBBN8Pgtsk5dc90ooBwyWMha0KcCZhr5wOz08cNywr5rRLwnkFEpQJ
NXsj5j+lWAlHMTz8+a380Wwqz6Bzs/3bFM0yNQp4VdUIM34ljaV0r6907xza
q/x2WZOVlHv1ap+FzOwU8oW2Ev6z6IbCf3grrxL+FULZRCRv3Oxxy2VJKssO
0mTgU8MWjK/oJVlOxkBZjuoVQpmbhcQ5J0INQ85d+q7ZtWRBCzS+lzTeS+G0
lIxnXk9aurxKEbrUnkGPagVYVnezzTnMMcdk3/puqjwTWj8668ysH/VF2sgM
Q644gBlGD/tiyY2gj8nFoUpHZboQmOeQHAdjHJXDvTfveMvnt4XvKkRRABP9
Rzy8iT5BYkqFlVk1weJprUReMdegD5rBJ5Gws+vVsml6WKM4VEl3Xr1y1q0I
G0+aHGmqJPTeR24/VDwJRp108mGeRdMhmvaUFhBNhFNJZkFo/NgWQh5WUXpa
0KiQmjRjmoWJFrnk2uIa0s/J97DqNqvxGR7dq7P1fX3F11lbAI1BBTqara76
0SZpMsGmZ6wmIL4w7MNXW4OSt1m5ltbMircPW51zXHLPuSoDtSbdEy8YvUSG
bA0JwEK69i7fedftJ5xJRfNAEcK6e62fzzz8WmCr4CLVaJ+o9gzwFTyTsIKo
NaK9zI2kAh2TtV+dbLtnbkMpk+EBEl4QHEUNxx7TdCOYwbcH7g79MPsX1t6L
MeNi1iZhPexOPHHB08XeSkM2OUPhu8lAmSrWEKbj7Rd+AFd5jbx4+CQNxwHI
BQ69LtptGijS/Z0BBI9mIuQQ85t4G2J8H9t32waqezz9hntEAwC/O0xuWZrC
ahFlOeR9ogmV7tKNedQf+USQZikI0/Ba1DBaZCGIa28d8Toj66guPFR8W32P
W/mUNoIqHyFF+XKmnDcM9X0TJTdBJFbevDQobCWOIWtCmauHLBlAJq1ruGw/
X7nqG3sPDLNsjqsg461ZBCsP4AmSY8vijDVQFvIeQoOquW5/6EX7rEuPJVz6
LuO+dxaaxaN/0OtNx9MoIF9ilR/AeV/bEANzAEffinJFsQaKoV414E9B2CoC
vqu5XW3u2fFRwnpIWT5NeRiNRQ2dFRQInyhWfEQjI+jl3BVIwT03FNMDu44t
UkqETfwdh+BSKHBdMHATY2TWJIsTK5ya55tmdWxrXQOVujN78zirZURaOS8A
Hxpt1STYtaAUZsWaN7QYmcih9oO472cyjczSaTWmhM6VScRsaaaYfCQBW/FH
agBe7dEyL9ULzb3+Ohkwm/hqJvSRy/nvDCE0US3oz8oMrBfbOwdzJOXJBLwS
0/HnMIVnMBMRTELL9pOZWk6ezEMcDaEXTIKbMLKVawMC2Wx7MhQqpX4xX24S
hcrUzpZXgD2cUW8i3cRH2PmGnVOo317o8lPM4prGhcvK6krYuktcOPGDfj81
T0zVxb1nVkEr1s/G5YhAKsodnaoMt4Ir/PTCE1hRbluClWO8f0+DvvzYAIJE
o2P6+8vTyrJK4rTXD3JR0hsM1WB8AzY3hWHlI0m+coqfvBgsy39tTdbG9YuN
uSoqWNXfq6TA4ogYNi9XRK+1ntzsqhvBWXW9JnLu8vQh05olceIIX2x0YI9Y
OtXC//4P/Hz7za8H3ndwCvCBbFhQzANtFrE/IWEQcub99fDtG2+c9KcRW/n2
G+4m6CEB4MSMMRB/WsHmJSue8Q0et/60ErJ84Esd+GO33d32Ox2/u7+Bw6yQ
6vjOuwh6H1ju2aOd02jer99NPuSElI9g6Q0UYwV5Qi/zAVYEjhQxkIIVpXLu
bETUc9I2AEvj11/F5Pk4v3H2oP2QgDGNnRxwaCQX1Vz79hs5lAMPLhQEDMNk
kdmdjQ4Rn/xX8CygBIbdAb59MAnSYJwdfBxHB3F2QBXdnLMjAMDQQfjRK3z3
kithPm+OEw1voKNexS+EIJR2Dto3dl+86Bx4wrggZmDJPc6cFdMTYA4naVsY
TH5cO+Bf4KdqQNoNHNXbFSKet7lJ9bZP+mGepAco9BESGKHyaorcIqaHeIV2
8RYWaErZOKF6mLwmGeMzS9JhEIvIGo7qyunJ9WsXItbOSCCvVKJ06/rkUO2n
vyTpB/yQ3IscfToy9YQduvLLG+8XdnMAv/5xlOeT7GBzExV1niKj0w0k8wYg
tnk33MxZkG3+WQJ+4+EhAl784zgIozw5wK9/lM//WVngkkKwEwQp++BdBYEd
lY4/CkYG327A3vjjED/ZgKOHC9Jl8IFlI+8NTHwUVgJDcsL3P/bCrJdUgfo5
zEbxFNTBLexir4C6wbgS4O0Nff/jv2C7mgBxAE8XyL9MB3AwAvJMKyF9pEc2
onBKFK6f7ekQpPFVep8BJyshhv+84U/8eB+MEj5dzu+S9uYVUw31Kk/RGWW3
R5EojpGIgpXyXDeYRvSWwIH2c76zq3LzqjhqD88FUsdWtkEAUV2TZoP4hxfU
6wt3aZKOM1kdT5aDOg/iYMgrQuGKzYBKcmVbq6L19vz4cE0fBREyHrAASD/z
VjHSf3Wd/4sR//j75cn/fn96eXKMv1/9dHh2pn4RMMRzVz+9e392rH/T7x+9
Oz8/eXvMQWCig/WRgLJ6fvjXVV6qbfXdxfXpu7eHZ6v85GnofqqgJXPvdNh4
IO0vztcbvpO8OrrwOtteC9VNt9N5scZ/3e/sba9REBsfjup20Z8CCBD2Ht3j
LEjpkiUCugeTMA+iDEvvedkouYs9LN6pCXmUTO5Tqs3U6q15sL/ueEJPYaVf
WYAOFkhGNU6kZWCgHkzhKJxm0hrBzW8DuAeDE1w0xuDEfEu5IeKVSwZWI3eC
hhRj1acyNYCzuEDAT7B3D5zhSWzWuRpWJetkG0sQLqrTiGDW8aw+wY5FZORO
pmk2xQKOecLJlU25ayFPNLk8OHazmE5ZKJzSAYVc4PcCl+w2RPfCq6tj0AH8
WR3/BbgBVlj4RbXc7kk6aCquZt4ZG8L2AccmgBbqkqaXDF1s/NxNzx8LcZEP
tKQazxEQY1qFC8Spupm1LoAI0mSQBoipHZBGAZWo8eTGWRzr7u5uIx30fEZK
i0bDUTbhM3x87SVQgDsIEEKYZywaaIJ4oFkisPRxwrAdAprS/4EVKgkvlDK/
DVbcdq2bekT1W8U7YNmLipug05I7JFrM7uTJGQ7Cug6krwsgocN6EEbF+0uf
p+oIry3op+Devw3SkOSo6rEoMY92vuX4rQFhPoYgDHdWoxnKQ+2MCZIJCDol
tXDURh6hoV5zP0OzVc/oI6Ab3wlKM16KgXpJvAGgygUmBMb3RlhmRzu+nojV
tu5NJ31sDYz/ESCMFiI15pwpu22/vet32nWye4aH4Vy/BasNDifoGyn0R3ET
Zn9vb3dhwtC8vid433unan3wDzaF3S0cThUrpW5qr1RxsQv+hsOsNwYYs4FB
K+HTmrE+3UfU85PXHkAqjV/vxuJvbWwdeCfoDwcrD5R1eotqyTvU160XI8Rr
yzjfFuaBCrG7+2JvGTOhfR1hzTkX+d6BdwhHBKpjf4nSfD1KQSEfJRFIxjmd
p2fOY3+J89hfcB77OI/ru6ThJGCtHouaw1rriwO6VU3OuIwrTb9G7xcoUgmz
wR3n+zhUvQ9AAR3jQN7PaqBzAmZWRB/DcYtiCcKYMgzJmhqHvTThwQpZA2ft
3vYeHLrfXV24D5lonouRjWJjJhL6R5szW8b3pJl29toH3umVf3q1zFGq5bW4
Az8elyhy5wyHaMif9gbVod76H5+LOdufhDnbj7EOa4ynKg5XXrRXc5hCoj7N
6tvvbm0Vq/jlEoUj4zZZFEB2Eh13fECgV2g+2Lo4OrmguDcOyN27UGxr/uEd
njXNmxmY2QWl3rcwRGqtnuFbG52NbvV6LJqzy+aWuQAfvuy+Kq4UtaQy8tAA
67OBbeLl/EOriKyvylVaZl71HQxdVKhc+XKoSVUkhjYIRPsqfccd3Tt77vxW
MaQwR+YbVL4077DBNE/mGwmbd8BLeH7okWtNlpOt6IDotqlPBO0xjgF5gSa+
Vfme1zG7MYZV+LgmSFd5dWj9VpKRXhRkWVkqzBLdLsyPw8EAvTvY7PKIQKAw
6qMjNa+kLAyRLCz3pet0ilU/UMdmPBmTinvwrE49uyHGXorgi0D7IwUwTRAz
M6V0bjUwU/EiKmhzmmJuKGkWwkDBVG8DARPpYtLj+Kjv+hR0A/hzFxOmXmWZ
zFNNk2jGOW+7090+0BrF0FOInq4m7CkyB6hGHJqCjpazToWS3Te9CkZr2XeU
ya2RX1MKnDxB76NxVSbn/kTJo9Tlh5tJVqKSiqnjO9LKhzBKbvA3rDnCDYaV
mhVTUI3ZOq5gvLTmpHFAc69ZjeW4CZZjNgyWh6UD2iwsh02wHIbLxNIBzcbS
cIP0PlABbat+eb0bJNNxO0qbcDjFouSNByUFJAYVx3IXXrUUkQhw31xUqJGO
dwaN0aEIhaXhlAwGWPiDIgxaE1rxYNqtURtbG8sqBHs+XSYtyBtTSWnB0X1I
9KZzTldWVgDLk1BQZUqk/bHNG5NENSy5nMI2FcTecRJFmZsac1Fh78BrDnKQ
lOumeAUSLUqQcbAYQc6Dj+EYLMBDtdcvgSo7B96ccB+XNOmySEPe9Uu61quZ
00LraZdo1mwwB6mcJK0joAOG6TL5n94FL5wZYDMmPOgFaYhXoW53u2xtZR/F
dJFPDUucjc1sEHENUx+vK+72TazORdeh1sX5mrMjuiodz0/mtUhoEzCYDunm
esX1QhIz/y64txrJ8qop/AusTsIdOxWZCVvdYtS4Njk7u3t7e93OTl3YtLBq
DCeN/XR1IN07jqFH9VNArjmW1Ewd1HevonpB1fR80X0od020lubqxQLeokgD
/3pZk/LUaM2mF3x86twTWmkx7snpPTXuVUxqTu5VOlSfGA/5NBWehTQJZ2c5
sVHsbO93DmRIUtHBe4gJoj0eIV+sYKF/rnKg7Ziah2pfd3cB8j4xGSoQtUJ0
6snb/Laikrz/f3vP2hzHbeR3Vuk/IHalKNpcWpZkSabKp5IV2WEqUniSXLmr
Sz7M7g6XE+3ubGZm+YjI/35oAINn4zVcxlS8+0XU4NXd6G40Gg20soWtKpkH
FcMGePrs4aNDfZEc/ci8Nfxpi7IPisPNrb5/6VdjN5OmIeett5dfmHMLzv7t
Y5cUTuvjMgw/O/xEpN6kolP75LEtxydNwTdm02oGQvrkuU/Ov3tw8OjRt08e
P4wL+u9zGVFYMwx4uFcA1s8EIslnMqtlV3fFHN4CRiwxCDpnN695lh5+qxdu
ebD4ObrfT3g7m/keWZbgCY/DqFr0+IARJSAPm+XXfexwzSK7jw3uiLI51uZ2
q2A+KwXjO9Pw7ihqQ55HvQ/egEjsFYoeaSqz/dWr4zfurXLtYDGyz+jOa3yf
IQruwD4j9wnsDxzyYfsPB+07ohBiSG21xOelJUxm+9V3g4NlbMgu0UH7rslY
3i5xK2Ofg4zdlT37UEn7zPbyHrLfMUnf7uX/cwT8Tu/lh0r9Z7XHT5iZOyb/
q+g2+yYbu84YZUMbO48yGh4EbYAzPMrZ6SZdrWjqw6Mb4kpFKg9PDwGVEnr2
R3qIEI6MnyZanjo/o5w2dddpD6yY76cEjvw8hkvIaFFPioWMFUxl4ZHFycd9
1xhK7s7nLqEU291gKHkNzTuEmM+YxPBB11X/mhpaT4NrqY3r72+C4A3Wzaw1
U/szfa3M1jQzukqUt6pvtCfg2CVUCZb2/FtTsmgrllIOHmUW0Glxp7IPqJOg
OvtR9ukY7K1NwFOtJNWy7cpiChMmxEa+otCKq6R8JYS2R8d0vaTrDtr86Odj
iEqD4jzVyp56YWBpLz1GhPHfpiQ3DlzcmeO9fvXk6fdw2xC6+ittzLeZYtGF
Jf7oWGdHdJGWLApTuTdcxW6aLP6dt/dZt0ffU9MHUMY33QZdUFqgohulyw1V
9Xeoqv72wQNESftvGbErLjxrD0BD9UNTr1ZchfSfqNZdtuIdiXHZnZelblJT
u5mUy+mqtvJg+Jnv2QOd+bQrThvgPef1vH5XM8gktHYeQ03CwOnMHTAzkk9g
rjGU7qRJmOzwxlC6yyZhzL+I4fNZmYQbcKX8SiZhSNOkmoTD9c0tmIQJqvPX
NwljqnVT5kXGMbX/jQfw7L8E98hyOqJ0XGGG1/GbIep242gONy43gea/x2SM
H9b4cEw/pFGHMbeoou+2KYhqSzS6RWi1kXz5PkFlHsdVZdme1vOpJwVI0I3t
QqSmQQbq9JW+kUON6nVnxOjwTNLRLfZzq0VcA2st8h3eOrhihg1zO+DtxmOY
4oSplp8TXaplvxLrpDBotBmyFJNJOedX3kfF9AwSgbRcadx5ammgEwP0jXEU
qj9CT76F1IXMFiQrq0f+x/aLCS2RHCDRWPKnOi0zZFLZeX2tfCNiefLc5vVn
bFsIZXukvcvGHoi6/+ro3R5q90/G9iLigeWyK6NrpILgx3VDLeP31b9g7B/f
42OXt0OH1xcTeMfcJcJrHxHKTRJBDK9T4LWPAqvbocBxWXxE8D/24b/aJP5s
cB37Ywd7JGsB+tRiSDbVtUntAh573+91b2ux3NJoOiY2ljOMD6Psofq8FeJU
uHBuxUs6B16YSdCzH051PWQMx7rf7zPZlPgpbPqjJxrH9MjhFCQ8U/wXBwff
IOj/QHatF3F2jUUrdLDPEtJ1BsapD+QYZ/0MEPOdigRSvy87dHA1MiX2weyg
39zWJydzymwGDpSyE5YYytg2SNAUgzrr1SD6irY3onD6a0BJ8RQuFfsBNMlS
A7n5xtyV3E18zCiRlZLyLfRB9zLOW4zBGJjw+58aLLE0aLEnd82xg8EvIhVF
MiLM5kt6EdeUfvfJI4mt3CPRP6YtfxwpUZdpbw2B204EqLBtJDijVB4pO6OW
P24m9ZkJk5Dyl/h8AP4AmfFM48G3Xk3KMhZA6jJMnfY01RNOHHrVF5pQMEz0
ybqhpGNiLQDRxFN4T4HeViqxI64qJsDA5/AuuiXYVavUhNFQ15gd1zi07nk1
nxO6/ExOWT9cufLRzSXLWHaAfgHAWh9k00uqNvhKZ2poser1fNZe0uV4wZ8z
F3Tyg6atxKf1ej7lKYVOIBrK+6aZ3xIyH5QeZAmp1C7QmbUJ8RtBm7ND7afs
QkB50+L0KWj6vDhowpqbpMfRJcuXJefo5duX7IEMqsv5Q38tT4aj5ykQ9lvL
a9Otongx23yY/Jd3R22fXY/nNfmfN38m78oZPOsPt7U+vaCK69GTZ8+ur7kj
nuo2/viiNthhnxCnJzft9pCkZLVhePatxLDw1v8rng7lkJ9tHL1+/7M8+qAA
HpK337zkgiDNVBiTveK3ZCjI7DqaRCZDpU/CbQPHyRadvYYNXzbW/Gn8puZR
z5oE1kT7hWjeXNIJ/R2d0CcPHj6gEwovshiNjuVSqzVh+uDAnmLA4ZD/iU7m
G3i7pejzLQIaLwh5q7dmFBjAJjyfEBvbLpJL76GWFCEAMTbRGwUcG8CEH6uB
otEzypewkK8b8NB7dEArFnr6J3sYCPxbJz3v0CVkNWdP5+uZStTzpE/v7dDl
hMr90egPLEvFaFl2tJtRczJ59vjB03HVXl8fOMm3GPxfyDwjnqRcBrsK3xU7
WGNwtvzVSPawFoWOGgDchU+XLvDVsdfgzqqC9SJebVyotDMrYVa1+6Rd05Ub
8pq8ff3h1V/e/iTU2JOHj7+lXA8wvnv9Xi959uAxlYcDkGfIBNz3RE4LyCBQ
39uBrCYs4TjksJE2IJkXl5Ss9/le6/37P4ruHj/87uH19T75QA00McDjx0/g
C0u++d+/HL0S379/8IAOvMdgEoOxDCqLNct4AClZwFzn2ypJ9T7pzisjSfZL
RiOmnRpqXfJXk+6/ffnqzZ4Q+2ePgAD3duSrcjBVi7Lg7+k2JexTJp0gNlsg
IcVIBfvEhvS0hOsZknyQQ5VncGcnzyqXersei7c9IXtNcVZUc3aSjfbSE5xA
JmnOzIwisAnt860B3hj7yAdJ1RvW+/ycVlBb5t3opxcermtZHh84Vl9OJZNB
/kku9TVzVPC0SmK8gz4JEhucm2SLtpyfASg1ZJgAY7IGPlleqrSKnKfv7cBw
51RogQj7dnG/26YQFNMRSwfUwuHbPrhC3h2/gqdQX7aMrdnCAtnFGkAEco2w
FE+UV9peK1RtS9cOyGDLH6Kl7NuZxOOD0u1Cj/lEKBKR2+eNwJJVA3aE9pKO
Ukq143fTHqCWDzc6ZSZfnlCI2qxUbpYst6sEd2IosQPyE7BGeVFQNUUJAHPC
qteL3s5tdViYqS4Iv2qqs2JyORKY39vRU4IIId1lbyGK7nd5wp3RaMQeQ+Ta
le39aiimSvL9hM5yQXdZZan0K2RmokhcEJFSsZUJmVmbDvIfiL0KNQyBkZWZ
yCMIYP4ZZ5UQ0vGe1hdq4hHoIX6+sGSbE6rfGPiiv/ZyMQbFBIx6wIVCZfyC
bMdnJV2xmU3NM0D2yaKWkEuK2SQsR1S5nKo8T/q0gJ+IEeW/RD6Wdpe8rTu6
EkkBBPyEahyXdMvE05GJjcqKWcdSnbFpG69nrWA0uvCx81eKITzZO573qo0c
U6BB8RVLnrKapQzUh+xbtSWHFAqlvSSeA2dpZP5w9OEv7xgOX36pLHNtJmX6
xqKdVNWIqrh7Oz+YP8gd9vqQ7P5tl1GEii6ddHH6yy+vPP3+IbEa/bAjlMWh
aRLtWJsquc05ZOv916OR8bXfssD3+105OV3W83p2ufdC29/RssP74gBqz9zu
QzNR8oKbGHrPOhxzuOZiwMC+RMe/8ox/hY3f9G6Cmco+7I4j8ze8EB97YEay
xAK+q1cMrJFKcmqggpTrA4olsKHFgkqzeT0u5vT/erXJvKKtRSV/NW0w0Zv2
ZScSPGBGG0MkhULEKOtpw388LgmvqW6xvTCYI+3mWwxgM9bFBNgoCwJs9nKr
APe0QQSvL6IqsJpSzaPqcECuBCCN6+2qyrIcnczrApsGtz8bxatcFM0BpEm1
KYiRDjcM8rqruPhvCGK3v82xUSBYIUk6AxK6aVbbOCf45okk95cSWhrQGZJw
saArHoTy252R3P4C2tkgT+JDt4ruAa3bA5owPehEYU0RxTRAN10lc0EOnaO9
3grwIZa7AfRpi8LNwQ8w+A2gjy8Qfed5wPs4XoiXYRkm2UNYZd9algNqZtCq
ppJFmQ6dKYE1nEV2iAy7aInsT6P+FoNH8N2GRlSev7nbsF2vWPoIiEUIjIrM
gB5Zau53MtYWt41Pt5BsFnf79or+JjoP2AKD+05dhZBZqZbbSblzk+KNATYd
FnlzRZLnimSjTNLn6sadh43pYX1nm3F9mMMIslyVo9N6pVT9fRhYOXeYZ4dn
WaZAM28prb5ncYtTwfUBsZJqOlo3FYC4PD8UX7xVNd+PtyodilHqhazaf8ER
YJELIQT6Cu5QrKRbUTDESOzvGEgIRKqq6ebqeFIew8WlUFgvo0ggVUJoyKno
Dj2oqLraXHjqWvObN8V5s5xH1jhpC2olMcLZBJUFOCllMXygBlN3KL9EcPDx
KfNx7lnizR2fGgSqyPbRGoU+Z7GOos9rbICe5b41QMj047p6aQQxCaO2mc+2
GmqrobYa6o5pqCuPhlKd2hpK7rBDx0l6575zJTJYQxkgpGkohT+oIltBwzdX
N8NX3HsJkRHNVCg5drKvlFu1nJYXPleY5a/8vBThybyYtV9JXNhtGuk7HLHS
X00jmrBFQfstazprGlPItRmr5ipq1VzFrJqrwTrDACFDZyikdLp5KCYVBO+s
D8DiXquTWikJrYSBoOX49ioSS3fwIajyafi2/AohvaKVS/QrjSAWuWVRNqED
C6SHxAqVcjn9z0Ck7cqVjokPZB+8LrDmzLN3FUbjqlsUKyhlAaqn5cWIX0ty
+RCuNZj85/CnLu9u6Vfk/xg3/t1SATE2VjUDzGyPq1iaaDOL6ZQQV+g1Ajpl
OIfYIOTpFJftfxPIStEwsA0jFMbGRQXjrAyRqVddtaj+xe898qMVOkddc6mk
R3w1twvGT7uUJ1udlxCpFzskfSbrW3vp8mIyX9MlvR7/gxK41RUMr8ALrHqm
5KoJTLVSda5TtqpOeq/Fam0DPHYrshcIW6/+Bh4bFmkQ2dJ70DMtRS96hrWI
DB4waaOgeiHN2/CbCHqNYRtFn0kcRBI1jIMtUPM4zidkAKuQAdwyZBpSp8Jy
E9gT4DoLkJFjLoMYhmFp0LYCNnTmhgAZBjHprP69tpI7nM90upFzAQcqdbUz
KaUcDfI7sdwNeoFWZjgd0MWgWrqLAUEWA7Oez4xLXQxUC8txoWHtd19Iwgad
GDr5k1wZngZ+h4bdIO7fxdBz3AY4erbrwB487N8Ig+qFNG8xMBEMeUYMFAP+
ET+SPi+Jv4XPV2K3SPGYeNoE/SZ2myQ/sd0ow1tM+kaYz1j2iy8GyMgJ/uMg
hmFpcPxCssznHVIVvCdfqkr4/EsnRuAUzEZv2FmYAirzRGzCXvmCkCy4bAyv
EQYuiWzMYeD0LIUKruYp+LF9Slt26xWtV9VwnYthaW5MWIyIUW5V4E89UOwV
H5kDqXBiqkUo5VDqiOfNTAFlP5BsWahT03dHRNA1dkdEVIvdEen36JE7Indl
jsUvcarFLzrjaD1k4tHRVRgj+FG12R/p1ovGC5b5EzN7+j1wMT8vLlvH7LnK
NnvkpBlmjzZjwVMb4toF+NlNhtnjaRA7x8kxezD0sNMSBD38xCTV7AmD6oU0
2+zREIwcCCkUo8dCOWaPv0X4iCjP7ImwChnALUOmIXUq0KNyNQGBA/MssyeI
YVganCN0InvxHKSrCt7jdFUlfKgu/4uaPW41MsDsQYDKO2bHd6FCLfu2oZaS
X7fFTPGbvXypZtvd63b32iO43b1ud6832r2irkxkGG+Eg+w/EuegDxeIdrDH
HRbzoIAaEvngxkyp/tzIKbMMj59iZj/qydRCJDL8mJnLAL4GxBeABO2fp/rz
9H6m0o9r/AR1n6Hr8xT9EC2fouKT9Humcs/U7NlqPVun5yv0odrcr8ojejxX
iWdpcK/6DnseY27HJJ9jisNxA97GAa5GTatawQIerRoKFSBbrbrVqjZOW636
29OqAYs4aA4n2cIphvAGrOAbmMA++9dr/IYtXwE5T0Uh4sjGkJ5Mf3vDKdNV
rFNK9bYWkGY7VaxYNb8bZb1aUXZjPfagP3nsBV2PktNea9G+GhFq94v5DA4P
ThfuYQeHcI98cjoWaF67cb5YlB5GB9nmCqUG8rMJZPeQE8Vnt02L6JNNrjKX
bKstyVvB8dZu1J9eo5/CYASg1SC43PtakJTVP61xMErQ2zgpYjBIGiy0LkIa
JMjOC2A0qjARtSTM8swMP3EikYc4ecJRiAkECkQkJrQORCem8i25IeuSG3Iv
ucE0x2prA2SxAhr5iDOALwrSC31aRGQa9dIl34mUxLHBoia9oCARlL5ZwM2u
cJsrzAqLNiGmUZbcqP9hJtzfsD1xzi+LTvnsTSJBoBhD2AGhVh1iGZW+Slo9
K1BUb4HYG1jQqN6EZDperbZkuL2hWvvsDR31JHtD/q5S7Q29Bcm1N/yNE+wN
pHGGveEhjX9B9ZLGu5wiACbaG1HUkjBTjXPtDZM4SfaGTZ4UeyNIoKi9EWwd
tTeQ1ln2hr99mr2BtM+zN5AOAgrZqq0NkMUKAXtDHyFubyDQ59gbMeqlS77H
3iBmvYC9QdzKXnvD/cXtDfd3FbM30CYkYm/4GvW/f6e94f5S2dv5xeyNC5iv
qhw3ZQGZqcxCYpfTpVz9B/OYEKSR140kZ+XwPrcUqrNydLJeMjDdSzD0h3h7
3JbX7nVD4tZyusereYH/2sBR6CxPwKrhBINMfUuWocRy3qkCnofU8IWhNeh0
sHgn+56mDILyUpxnP4MqxXRRLUcM1BaF55LlJnO9iUaxCQlxIel/flei3R/8
83dTwNgqQz9Dh+4dXIPKYOjaBGbfqMJvO5e0qixK1BhV2XMP0iC3RsBpqcqi
hPQTkHX9VZw006r9R01N6mWpP9mvfxWB4k7tHfeKghOLjb0LvQ1n947ucdtf
eUr97uoEt73Gyx63/eeljRBgMG2EibBnRjRrzKuNDFZ0tNFW3djqBr2mY5fo
IDoyTQIKg/h1hj1XIbVBcjUHSVceJF1/kFwVQoJahOQpEpKhS0iaOiFRjUJy
lApJ0iskTbUgsFm2TqKCwaEKTFmKmiFxTUMCyoak6RsP6HGKmlrHhcRLx4Du
yZ1aVwPJItuaUb+YXWPoLqoKVvCQtWbMNDWxirRx+0L/2bKkBq2KnyvjKPMW
xWSyXqznBduiSM525K0HIyJxvmr+iWnqtKmh9WJyZw2OSh5aJw26MDVl/WT5
o3W9EtiD6ZVBt0IiEik0xiTRHDBA2RRpzJh0v0T2A6JXMf1VsFs/snbeHR7Z
DL3IQ4QFEbvLo1MwcqHHpk3arR68Vexqj9Uq9X6Pg7Xn/guKNX4FxoIk5bJP
EPgQ7HqrrGs/Pd7xmz865tHrP17cw3eAvM3CF4FIkL/IUBYjQ7mMDJ0s0TJl
wnz3g4i+SPovCVlgJN8UCiEeFS7Pexeyt+CjF7JW5OULorRb/PkL4nGi+2rK
zg3veaB2/8t+K4N4OSQcxV4uJzXkgx3RXd2oPa+6yWm/fdLeAxCVFL+i/iCj
tbvo6elHe2NRSIv2nrMQp/VSf+mz71B78VLL6P6lliD4w2VCtlo7zayeZd3I
NhvO3ybabdO4bdO4bQb8XzGN282Bh81KkKP93Cyb3g5gxcVgwPqmtwIY7/ms
aKrCcppFAbOa3gp4QitCgmKcctNyUtHmYgftb32XsgaixMWaIfkDB5DU6jko
I36AvPKxGaBC8hEAyicbGwEqKBuxqfPKxUZAC8qFKRP+lhtNTxnItuzYKAF1
7Unvi/BHMHm6MWmemggNdcolYTYr1rMyBz/2DDVrpZ3ZBbAM1kdwDdZPxTiQ
8tnBNaBWPNni43MZEEBPzU1ghs9lAD+U1gEsg/VT5zIX47S0sS7a2+yx2+yx
dyJRaZqJH26DWxfBNp7FP9jGsyo76/FVVLV4h4oYTME2OShFDA3cxNjm+N2K
zlZ0biY620zMdzQTMwZPEvvZbVLYjwyQKDJMosgAibLbZKCUJVEkW6Kk3avm
ftXUJ9UcLPumoBZw2WihbJOqQWIoJ+MW+VqidUu07gqtu7Lq6qcRAjd2iC5h
12PuWDEa+NauKAFOqklhxLzrYXJU4v+5LlvQKfpR19c8CE6Tpp6kquXHsRlx
5dDV0n4u3fHQC2/1cNCaNmnIzwymuTJmM7V6mdd7mdf7Kq/3VWLvDM950bZO
0KH05NA/pu2IVdJaNbUIWDSUKiHEOpI6dDgCYV52CJzAvEoItBM08uoUUna1
5KSpF+TdT6/Is6dPn5BPX07499G4aq+h5ofTqiV0YYTNHd0hTluyLM9FSDuZ
Fl3Bjura/Z6DKvibDi0hbklX0xW3JP/78u3PhB/EtQfkqCPFvK3JekU7oXC0
9aIk9QmrWV5UbQfIpvVfLZ3+WY2T6gIQpOCO17zap0+/o6gCptfXBxy7kpzU
83l9DsMBZmoYclqclWRclgzvctrjsdsfIjLAdsWQh9DdiMxbiHGtzyqgF5yM
lk1TN1QjFG29fM7rUJ6oJ5XSH6NpxQjcXYoK4tV+Hg7G0t+OinVXP1dDQGLA
mh+Lir8hDmFZiip6cQsnoyWtBcFCFCJRRQ9zNW4JAUT9SCzGV6tol2mfGcWr
rqXrQ0PRmWqE1EekjLNad3wknTQJzZu6qyf1fFQ31axaJg7anpUT5OJTTus0
JD3spDh4EDsxmmlU5wfp/SG6Z0wlGUOGDKWYF1AEQggMOPUD/5uLm64gLZjx
dQ3hVMsOQmqAuYOICN5QrwENbzwhARx9Vstzu9hcFxCQDE06p/I3vaQMfVIt
gaFNJbmvQcw19bRXt0Em8knc/XJaUc1UFfO9Xhny0vKibCZ070XuU10NmnsP
ITGLUYHPdEUDuo4L2sDPQVgP4QGq2SpYToUhWM65hELRFLPwSLwm1e/VYr0I
1nS3j8HqQpfL1yjatNri3Su3NsSX6svDpKmoUQ/GgDaXCJNJxZfEY20+i6nI
u+eCJQAAOazqlFs0TNbGVIPzQCMEYimltyYVrmrVIDdVxrykI/j1hdvTroS/
lxDjmYLn8qMZavkchYCPfiM6IBA6gGFAHYhvAqYFZfqCctkl6Zp1SZgxBP4Z
atfVDRtJ9MWWZi2EVkHWlKt5MaGgjS/JYt12eifdadER2K5VDRiNHWBOa0C/
cKJBFzowSg8VTBJ2QodH6GthA7VMgh9sWWHLCgYr+BMi39aEeEfU5sW2+NU8
6Kvupau7wVik80yqxQrWdtiy0kZt2cHuzrWbOd2LhmpmwLCcHhh7IO3iI86f
QkJOvPLhduTKB9GzoZnbFV/qLBQYecJ7k0UvPPCuBjOetUtk5bJmTYKmBm5K
cBZRcWkdGe0HOyBs/8+XUEL/WtYd3AQq+cwWy0ty9PrDTyBHVDibqdyEl3O6
pa9AZjroQLovYHDo45LyA8e+5eIIXanGOtmkN4CNRCnYChYJvPX6WUpOVxva
hVIP9sZlpvyA9jNUUFMuaooPc/SwyYC+FKf57MZdpkb99XqLcVcHprceKbn3
kEnSyTdMmr3doUKtXh3BlccgeZ2WdD2YwIyhI2GbwIE7rnrc1vMyal2y9U8R
vt+CnfDtBcxVMZtp7mnQLevFStvH6nXndTEdLeq2Y3+JCzxIvQlU4Tfjyk5z
Tak74cLnBKxCVVmwCqPZp0N5Y+qHL06KeVt+cc2dlS8nH5f1+byczvhi3VO4
WNO1pmnJeb2ew5L/seSMUiw/kns772raV0f+Ws27erlP/lyvyY9lM4PZflOc
lu0p+VMJdUF1LSvG7n8qT07IH4uCjiCMiqphdwfhjI3OwooubIIVp1U7WbOY
l3s7xRhWPG4q1JOyZT5PPv3wl8iLSZmEKrne4Um/F7rPUjLGaj2eV+0pV8zF
EjTeQQLC93be1KdMn/9YryfFtKgaCthyem/nPUW6qinu87rrKhQz8OcyKwiI
0K5ns7Jlb0yTesl1xrSerKHGgfQJ91/IOQWTSsSK6qApVefA7x+bYjGtz2GX
9f9Q7DYxhZoDAA==

-->

</rfc>

