<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-teas-yang-te-types-14" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.40.1 -->
  <front>
    <title abbrev="TE Common YANG Types">Traffic Engineering Common YANG Types</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-teas-yang-te-types-14"/>
    <author initials="T." surname="Saad" fullname="Tarek Saad">
      <organization>Juniper Networks</organization>
      <address>
        <email>tsaad@juniper.net</email>
      </address>
    </author>
    <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
      <organization>Cisco Systems Inc</organization>
      <address>
        <email>rgandhi@cisco.com</email>
      </address>
    </author>
    <author initials="X." surname="Liu" fullname="Xufeng Liu">
      <organization>Volta Networks</organization>
      <address>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="V.P." surname="Beeram" fullname="Vishnu Pavan Beeram">
      <organization>Juniper Networks</organization>
      <address>
        <email>vbeeram@juniper.net</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="2019" month="December" day="10"/>
    <workgroup>TEAS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <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>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>YANG <xref target="RFC6020" format="default"/> and <xref target="RFC7950" format="default"/> is a data modeling language used to model
configuration data, state data, Remote Procedure Calls, and
notifications for network management protocols such as NETCONF <xref target="RFC6241" format="default"/>.
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 types and groupings 
are designed to be the common types applicable for modeling Traffic Engineering (TE) features
in model(s) defined outside of this document.</t>
      <section anchor="terminology" numbered="true" toc="default">
        <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" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
        <t>The terminology for describing YANG data models is found in <xref target="RFC7950" format="default"/>.</t>
      </section>
      <section anchor="prefixes-in-data-node-names" numbered="true" toc="default">
        <name>Prefixes in Data Node Names</name>
        <t>In this document, 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 Table 1.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        +-----------------+----------------------+---------------+
        | Prefix          | YANG module          | Reference     |
        +-----------------+----------------------+---------------+
        | yang            | ietf-yang-types      | [RFC6991]     |
        | inet            | ietf-inet-types      | [RFC6991]     |
        | rt-types        | ietf-routing-types   | [RFC8294]     |
        | te-types        | ietf-te-types        | this document |
        | te-packet-types | ietf-te-packet-types | this document |
        +-----------------+----------------------+---------------+

            Table 1: Prefixes and corresponding YANG modules
]]></artwork>
      </section>
    </section>
    <section anchor="acronyms-and-abbreviations" numbered="true" toc="default">
      <name>Acronyms and Abbreviations</name>
      <ul empty="true" spacing="normal">
        <li>GMPLS: Generalized Multiprotocol Label Switching</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>LSP: Label Switched Path</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>LSR: Label Switching Router</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>LER: Label Edge Router</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>MPLS: Multiprotocol Label Switching</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>RSVP: Resource Reservation Protocol</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>TE: Traffic Engineering</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>DS-TE: Differentiated Services Traffic Engineering</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>SRLG: Shared Link Risk Group</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>NBMA: Non-Broadcast Multiple-access Network</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>APS: Automatic Protection Switching</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>SD: Signal Degrade</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>SF: Signal Fail</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>WTR: Wait to Restore</li>
      </ul>
      <ul empty="true" spacing="normal">
        <li>PM: Performance Metrics</li>
      </ul>
    </section>
    <section anchor="overview" numbered="true" toc="default">
      <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-contents" numbered="true" toc="default">
        <name>TE Types Module Contents</name>
        <t>The ietf-te-types module contains common TE types that are independent and
agnostic of any specific technology or control plane instance.</t>
        <t>The ietf-te-types module contains the following YANG reusable types and groupings:</t>
        <t>te-bandwidth:</t>
        <ul empty="true" spacing="normal">
          <li>A YANG grouping that defines the generic TE bandwidth.
  The modeling structure allows augmentation for each technology.
  For un-specified technologies, the string encoded te-bandwidth
  type is used.</li>
        </ul>
        <t>te-label:</t>
        <ul empty="true" spacing="normal">
          <li>A YANG grouping that defines the generic TE label.
  The modeling structure allows augmentation for each technology.
  For un-specified technologies, rt-types:generalized-label
  is used.</li>
        </ul>
        <t>performance-metrics-attributes:</t>
        <ul empty="true" spacing="normal">
          <li>A YANG grouping that defines one-way and two-way measured performance metrics and anomalous indication on link(s) or the path as defined in <xref target="RFC7471" format="default"/>, <xref target="RFC8570" format="default"/>, and <xref target="RFC7823" format="default"/>.</li>
        </ul>
        <t>performance-metrics-throttle-container:</t>
        <ul empty="true" spacing="normal">
          <li>A YANG grouping that defines configurable thresholds for advertisement suppression and measurement intervals.</li>
        </ul>
        <t>te-ds-class:</t>
        <ul empty="true" spacing="normal">
          <li>A type representing the Differentiated-Services (DS) Class-Type of traffic as defined in <xref target="RFC4124" format="default"/>.</li>
        </ul>
        <t>te-label-direction:</t>
        <ul empty="true" spacing="normal">
          <li>An enumerated type for specifying the forward or reverse direction
  of a label.</li>
        </ul>
        <t>te-hop-type:</t>
        <ul empty="true" spacing="normal">
          <li>An enumerated type for specifying hop as loose or strict.</li>
        </ul>
        <t>te-global-id:</t>
        <ul empty="true" spacing="normal">
          <li>A type representing the identifier that uniquely identify an operator, which can be
  either a provider or a client.
  The definition of this type is taken from <xref target="RFC6370" format="default"/> and <xref target="RFC5003" format="default"/>.
  This attribute type is used solely to provide a globally
  unique context for TE topologies.</li>
        </ul>
        <t>te-node-id:</t>
        <ul empty="true" spacing="normal">
          <li>A type representing the identifier for a node in a TE topology.
  The identifier is represented as 4 octets in dotted-quad notation.
  This attribute MAY be mapped to the Router Address described
  in Section 2.4.1 of <xref target="RFC3630" format="default"/>, the TE Router ID described in
  Section 3 of <xref target="RFC6827" format="default"/>, the Traffic Engineering Router ID
  described in Section 4.3 of <xref target="RFC5305" format="default"/>, or the TE Router ID
  described in Section 3.2.1 of <xref target="RFC6119" format="default"/>.
  The reachability of such a TE node MAY be achieved by a
  mechanism such as Section 6.2 of <xref target="RFC6827" format="default"/>.</li>
        </ul>
        <t>te-topology-id:</t>
        <ul empty="true" spacing="normal">
          <li>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 the network-types,
  defined in ietf-network <xref target="RFC8345" format="default"/>, to help user to understand the
  topology better before further inquiry.</li>
        </ul>
        <t>te-tp-id:</t>
        <ul empty="true" spacing="normal">
          <li>A type representing the identifier of a TE interface link termination endpoint (TP) on a specific TE node where the TE link connects.  This attribute is mapped to local or remote link identifier in <xref target="RFC3630" format="default"/> and <xref target="RFC5305" format="default"/>.</li>
        </ul>
        <t>te-path-disjointness:</t>
        <ul empty="true" spacing="normal">
          <li>A type representing the different resource disjointness options for a TE tunnel path as defined in <xref target="RFC4872" format="default"/>.</li>
        </ul>
        <t>admin-groups:</t>
        <ul empty="true" spacing="normal">
          <li>A union type for TE link's classic or extended administrative groups as defined in
  <xref target="RFC3630" format="default"/> and <xref target="RFC5305" format="default"/>.</li>
        </ul>
        <t>srlg:</t>
        <ul empty="true" spacing="normal">
          <li>A type representing the Shared Risk Link Group (SRLG) as defined in <xref target="RFC4203" format="default"/> and <xref target="RFC5307" format="default"/>.</li>
        </ul>
        <t>te-metric:</t>
        <ul empty="true" spacing="normal">
          <li>A type representing the TE metric as defined in <xref target="RFC3785" format="default"/>.</li>
        </ul>
        <t>te-recovery-status:</t>
        <ul empty="true" spacing="normal">
          <li>An enumerated type for the different status of a recovery action as defined in <xref target="RFC4427" format="default"/> and <xref target="RFC6378" format="default"/>.</li>
        </ul>
        <t>path-attribute-flags:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported LSP path flags as defined in <xref target="RFC3209" format="default"/>, <xref target="RFC4090" format="default"/>, <xref target="RFC4736" format="default"/>, <xref target="RFC5712" format="default"/>, <xref target="RFC4920" format="default"/>, <xref target="RFC5420" format="default"/>, <xref target="RFC7570" format="default"/>, <xref target="RFC4875" format="default"/>, <xref target="RFC5151" format="default"/>, <xref target="RFC5150" format="default"/>, <xref target="RFC6001" format="default"/>, <xref target="RFC6790" format="default"/>, <xref target="RFC7260" format="default"/>, <xref target="RFC8001" format="default"/>, <xref target="RFC8149" format="default"/>, and <xref target="RFC8169" format="default"/>.</li>
        </ul>
        <t>link-protection-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported link protection types as defined in <xref target="RFC4872" format="default"/>, <xref target="RFC4427" format="default"/></li>
        </ul>
        <t>restoration-scheme-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported LSP restoration schemes as defined in <xref target="RFC4872" format="default"/>.</li>
        </ul>
        <t>protection-external-commands:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported protection external commands for trouble shooting  purposes as defined in <xref target="RFC4427" format="default"/>.</li>
        </ul>
        <t>association-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported Label Switched Path (LSP) association types as defined
  in <xref target="RFC6780" format="default"/>, <xref target="RFC4872" format="default"/>, <xref target="RFC4873" format="default"/>.</li>
        </ul>
        <t>objective-function-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported path computation objective functions as defined in
  <xref target="RFC5541" format="default"/>.</li>
        </ul>
        <t>te-tunnel-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported TE tunnel types as defined in <xref target="RFC3209" format="default"/> and <xref target="RFC4875" format="default"/>.</li>
        </ul>
        <t>lsp-encoding-types:</t>
        <ul empty="true" spacing="normal">
          <li>base YANG identity for supported LSP encoding types as defined in <xref target="RFC3471" format="default"/>.</li>
        </ul>
        <t>lsp-protection-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported LSP protection types as defined in <xref target="RFC4872" format="default"/> and <xref target="RFC4873" format="default"/>.</li>
        </ul>
        <t>switching-capabilities:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported interface switching capabilities as defined in <xref target="RFC3471" format="default"/>.</li>
        </ul>
        <t>resource-affinities-type:</t>
        <ul empty="true" spacing="normal">
          <li>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="RFC2702" format="default"/> and <xref target="RFC3209" format="default"/>.</li>
        </ul>
        <t>path-metric-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported path metric types as defined in <xref target="RFC3785" format="default"/> and <xref target="RFC7471" format="default"/>.</li>
        </ul>
        <t>explicit-route-hop:</t>
        <ul empty="true" spacing="normal">
          <li>A YANG grouping that defines supported explicit routes as defined in <xref target="RFC3209" format="default"/> and <xref target="RFC3477" format="default"/>.</li>
        </ul>
        <t>te-link-access-type:</t>
        <ul empty="true" spacing="normal">
          <li>An enumerated type for the different TE link access types as defined in <xref target="RFC3630" format="default"/>.</li>
        </ul>
      </section>
      <section anchor="packet-te-types-module-contents" numbered="true" toc="default">
        <name>Packet TE Types Module Contents</name>
        <t>The ietf-te-packet-types module covers the common types and groupings that are specific to packet technology.</t>
        <t>The ietf-te-packet-types module contains the following YANG reusable types and groupings:</t>
        <t>backup-protection-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported protection types that a backup or bypass tunnel can provide as defined in <xref target="RFC4090" format="default"/>.</li>
        </ul>
        <t>te-class-type:</t>
        <ul empty="true" spacing="normal">
          <li>A type that represents the Diffserv-TE class-type as defined in <xref target="RFC4124" format="default"/>.</li>
        </ul>
        <t>bc-type:</t>
        <ul empty="true" spacing="normal">
          <li>A type that represents the Diffserv-TE Bandwidth Constraint (BC) as defined in <xref target="RFC4124" format="default"/>.</li>
        </ul>
        <t>bc-model-type:</t>
        <ul empty="true" spacing="normal">
          <li>A base YANG identity for supported Diffserv-TE bandwidth constraint models as defined in <xref target="RFC4125" format="default"/>, <xref target="RFC4126" format="default"/> and <xref target="RFC4127" format="default"/>.</li>
        </ul>
        <t>te-bandwidth-requested-type:</t>
        <ul empty="true" spacing="normal">
          <li>An enumerated type for the different options to request bandwidth for a specific tunnel.</li>
        </ul>
        <t>performance-metrics-attributes-packet:</t>
        <ul empty="true" spacing="normal">
          <li>A YANG grouping that contains the generic performance metrics and additional packet specific metrics.</li>
        </ul>
      </section>
    </section>
    <section anchor="te-types-yang-module" numbered="true" toc="default">
      <name>TE Types YANG Module</name>
      <t>The ietf-te-types module imports from the following modules:</t>
      <ul spacing="normal">
        <li>ietf-yang-types and ietf-inet-types defined in <xref target="RFC6991" format="default"/></li>
        <li>ietf-routing-types defined in <xref target="RFC8294" format="default"/></li>
      </ul>
      <t>In addition to the references cross-referenced in <xref target="te-types-contents" format="default"> </xref>, this model also references the following RFCs in defining the types and YANG grouping of the YANG module:
<xref target="RFC3272" format="default"/>,
<xref target="RFC4202" format="default"/>,
<xref target="RFC4328" format="default"/>, 
<xref target="RFC4657" format="default"/>,
<xref target="RFC5817" format="default"/>,
<xref target="RFC6004" format="default"/>,
<xref target="RFC6511" format="default"/>,
<xref target="RFC6205" format="default"/>,
<xref target="RFC7139" format="default"/>,
<xref target="RFC7308" format="default"/>,
<xref target="RFC7551" format="default"/>,
<xref target="RFC7571" format="default"/>,
<xref target="RFC7579" format="default"/>, <xref target="RFC4090" format="default"/>, <xref target="RFC4561" format="default"/> and
<xref target="RFC7951" format="default"/>, <xref target="G709" format="default"/>.</t>
      <figure anchor="fig-basic-types">
        <name>TE basic types YANG module</name>
        <sourcecode name="ietf-te-types@2019-11-18.yang" type="" markers="true"><![CDATA[
module ietf-te-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-te-types";

  /* Replace with IANA when assigned */
  prefix "te-types";

  import ietf-inet-types {
    prefix inet;
    reference "RFC6991: Common YANG Data Types";
  }

  import ietf-yang-types {
    prefix "yang";
    reference "RFC6991: Common YANG Data Types";
  }

  import ietf-routing-types {
    prefix "rt-types";
    reference "RFC8294: Common YANG Data Types for the Routing Area";
  }

  organization
    "IETF Traffic Engineering Architecture and Signaling (TEAS)
     Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/teas/>
     WG List:  <mailto:teas@ietf.org>

     Editor:   Tarek Saad
               <mailto:tsaad@juniper.net>

     Editor:   Rakesh Gandhi
               <mailto:rgandhi@cisco.com>

     Editor:   Vishnu Pavan Beeram
               <mailto:vbeeram@juniper.net>

     Editor:   Himanshu Shah
               <mailto:hshah@ciena.com>

     Editor:   Xufeng Liu
               <mailto:xufeng.liu.ietf@gmail.com>

     Editor:   Igor Bryskin
               <mailto:i_bryskin@yahoo.com>

     Editor:   Young Lee
               <mailto:leeyoung@huawei.com>";

  description
    "This module contains a collection of generally useful TE
     specific YANG data type definitions. The model fully conforms
     to the Network Management Datastore Architecture (NMDA).

     Copyright (c) 2018 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 Simplified 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; see
     the RFC itself for full legal notices.";

  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

  // RFC Ed.: update the date below with the date of RFC publication
  // and remove this note.

  revision "2019-11-18" {
    description "Latest revision of TE types";
    reference
      "RFC XXXX: A YANG Data Model for Common Traffic Engineering
       Types";
  }

  /**
   * 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 (MSB) is the farthest to the left
       in the byte sequence. Leading zero bytes in the configured
       value may be omitted for brevity.";

    reference "RFC3630 and RFC5305";
  }

  typedef admin-groups {
    type union {
      type admin-group;
      type extended-admin-group;
    }
    description "TE administrative group derived type";
  }

  typedef extended-admin-group {
    type yang:hex-string;
    description
      "Extended administrative group/Resource class/Color
       representation in hex-string type.
       The MSB is the farthest to the left in the byte sequence.
       Leading zero bytes in the configured value may be omitted
       for brevity.";
    reference "RFC7308";
  }

  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 anomalous bit is not set";
      }
      enum "abnormal" {
        value 2;
        description
          "Abnormal. Indicate 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
      "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
       RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
       RFC7823: Performance-Based Path Selection for Explicitly
       Routed Label Switched Paths (LSPs) Using TE Metric
       Extensions";
  }

  typedef srlg {
    type uint32;
    description "SRLG type";
    reference "RFC4203 and RFC5307";
  }

  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
          "Resource is disabled in the control plane to prepare for
           graceful shutdown for maintenance purposes.";
        reference
          "RFC5817: Graceful Shutdown in MPLS and Generalized MPLS
           Traffic Engineering Networks";
      }
      enum maintenance {
        description
          "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 that is a string containing
       a list of numbers separated by commas, with each of these
       number can be non-negative decimal, hex integer, or hex float:
       (dec | hex | float)[*(','(dec | hex | float))]

       For packet switching type, the string encoding follows the
       type bandwidth-ieee-float32 defined in RFC 8294 (e.g. 0x1p10),
       where the units are in bytes per second.

       For OTN switching type, a list of integers can be used, such
       as '0,2,3,1', indicating 2 odu0's and 1 odu3.
       For DWDM, a list of pairs of slot number and width can be
       used, such as '0,2,3,3', indicating a frequency slot 0 with
       slot width 2 and a frequency slot 3 with slot width 3.
       Canonically, the string is represented as all lowercase and in
       hex where the prefix '0x' precedes the hex number";
    reference "RFC 8294, G709";
  } // te-bandwidth

  typedef te-ds-class {
    type uint8 {
      range '0..7';
    }
    description
      "The Differentiated Class-Type of traffic.";
    reference "RFC4124: 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 RFC6370 and RFC5003.
       This attribute type is used solely to provide a globally
       unique context for TE topologies.";
  }

  typedef te-hop-type {
    type enumeration {
      enum loose {
        description
          "loose hop in an explicit path";
      }
      enum strict {
        description
          "strict hop in an explicit path";
      }
    }
    description
     "enumerated type for specifying loose or strict
      paths";
    reference "RFC3209: section-4.3.2";
  }

  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
      "RFC3630: 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
          "explicit route represents an incoming link on a node";
      }
      enum outgoing {
        description
          "explicit route represents an outgoing link on a node";
      }
    }
    description
     "enumerated type for specifying direction of link on a node";
  }

  typedef te-metric {
    type uint32;
    description "TE metric";
    reference "RFC3785";
  }

  typedef te-node-id {
    type yang:dotted-quad;
    description
      "A type representing the identifier for a node in a TE
       topology.
       The identifier is represented as 4 octets in dotted-quad
       notation.
       This attribute MAY be mapped to the Router Address described
       in Section 2.4.1 of [RFC3630], the TE Router ID described in
       Section 3 of [RFC6827], the Traffic Engineering Router ID
       described in Section 4.3 of [RFC5305], or the TE Router ID
       described in Section 3.2.1 of [RFC6119].
       The reachability of such a TE node MAY be achieved by a
       mechanism such as Section 6.2 of [RFC6827].";
  }

  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 "SRLG (Shared Risk Link Group) disjoint.";
      }
    }
    description
      "Type of the resource disjointness for a TE tunnel path.";
    reference
      "RFC4872: RSVP-TE Extensions in Support of End-to-End
       Generalized Multi-Protocol Label Switching (GMPLS)
       Recovery";
  } // te-path-disjointness

  typedef te-recovery-status {
    type enumeration {
      enum normal {
        description
          "Both the recovery and working spans 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 -- either as a result of an
           operator Lockout command or a failure condition detected
           on the recovery span.";
      }
      enum recovery-admin {
        description
          "The operator has issued a command switching 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
      "RFC4427: Recovery (Protection and Restoration) Terminology
       for Generalized Multi-Protocol Label Switching (GMPLS).
       RFC6378: MPLS Transport Profile (MPLS-TP) Linear Protection";
  }

  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";
  } // te-topology-event-type

  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 the network-types,
       defined in ietf-network.yang, to help user to understand the
       topology better before further inquiry.";
    reference "RFC8345";
  }

  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 local or remote link identifier in
       RFC3630 and RFC5305.";
  }

  /* TE features */
  feature p2mp-te {
    description
      "Indicates support for P2MP-TE";
    reference "RFC4875";
  }

  feature frr-te {
    description
      "Indicates support for TE FastReroute (FRR)";
    reference "RFC4090";
  }

  feature extended-admin-groups {
    description
      "Indicates support for TE link extended admin
      groups.";
    reference "RFC7308";
  }

  feature named-path-affinities {
    description
      "Indicates support for named path affinities";
  }

  feature named-extended-admin-groups {
    description
      "Indicates support for named extended admin groups";
  }

  feature named-srlg-groups {
    description
      "Indicates support for named SRLG groups";
  }

  feature named-path-constraints {
    description
      "Indicates support for named path constraints";
  }

  feature path-optimization-metric {
    description
      "Indicates support for path optimization metric";
  }

  feature path-optimization-objective-function {
    description
      "Indicates support for path optimization objective function";
  }

  /*
   * Identities
   */
  identity session-attributes-flags {
    description
      "Base identity for the RSVP-TE session attributes flags";
  }
  identity local-protection-desired {
    base session-attributes-flags;
    description "Fastreroute local protection is desired.";
    reference "RFC3209";
  }
  identity se-style-desired {
    base session-attributes-flags;
    description
      "Shared explicit style to allow the LSP to be
       established sharing resources with the old LSP.";
    reference "RFC3209";
  }
  identity local-recording-desired {
    base session-attributes-flags;
    description "Local recording desired";
    reference "RFC3209";
  }
  identity bandwidth-protection-desired {
    base session-attributes-flags;
    description
      "Request FRR bandwidth protection on LSRs if
      present.";
    reference "RFC4090";
  }
  identity node-protection-desired {
    base session-attributes-flags;
    description
      "Request FRR node protection on LSRs if
      present.";
    reference "RFC4090";
  }
  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 Reroute but instead just signals a
       request to evaluate whether a preferable path exists.";
    reference "RFC4736";
  }
  identity soft-preemption-desired {
    base session-attributes-flags;
    description
      "Soft-preemption of LSP resources is desired";
    reference "RFC5712";
  }

  identity lsp-attributes-flags {
    description "Base identity for per hop attribute flags";
  }
  identity end-to-end-rerouting-desired {
    base lsp-attributes-flags;
    description
      "Indicates end-to-end re-routing behavior for an
       LSP under establishment.  This MAY also be used for
       specifying the behavior of end-to-end LSP recovery for
       established LSPs.";
    reference "RFC4920, RFC5420, RFC7570";
  }
  identity boundary-rerouting-desired {
    base lsp-attributes-flags;
    description
      "Indicates boundary re-routing behavior for an LSP under
       establishment. This MAY also be used for specifying the
       segment-based LSP recovery through nested crankback for
       established LSPs.  The boundary ABR/ASBR can either decide
       to forward the PathErr message upstream to an upstream boundary
       ABR/ASBR or to the ingress LSR.
       Alternatively, it can try to select another egress boundary
       LSR.";
    reference "RFC4920, RFC5420, RFC7570";
  }
  identity segment-based-rerouting-desired {
    base lsp-attributes-flags;
    description
      "Indicates segment-based re-routing behavior for an LSP under
       establishment. This MAY also be used to specify the segment-
       based LSP recovery for established LSPs.";
    reference "RFC4920, RFC5420, RFC7570";
  }
  identity lsp-integrity-required {
    base lsp-attributes-flags;
    description "Indicates LSP integrity is required";
    reference "RFC4875, RFC7570";

  }
  identity contiguous-lsp-desired {
    base lsp-attributes-flags;
    description "Indicates contiguous LSP is desired";
    reference "RFC5151, RFC7570";
  }
  identity lsp-stitching-desired {
    base lsp-attributes-flags;
    description "Indicates LSP stitching is desired";
    reference "RFC5150, RFC7570";
  }
  identity pre-planned-lsp-flag {
    base lsp-attributes-flags;
    description
      "Indicates the LSP MUST be provisioned in the
       control plane only.";
    reference "RFC6001, RFC7570";
  }
  identity non-php-behavior-flag {
    base lsp-attributes-flags;
    description
      "Indicates non-php behavior for the LSP is desired";
    reference "RFC6511, RFC7570";
  }
  identity oob-mapping-flag {
    base lsp-attributes-flags;
    description
      "Indicates signaling of the egress binding information
       is out-of-band , (e.g., via Border Gateway Protocol (BGP))";
    reference "RFC6511, RFC7570";
  }
  identity entropy-label-capability {
    base lsp-attributes-flags;
    description "Indicates entropy label capability";
    reference "RFC6790, RFC7570";
  }
  identity oam-mep-entity-desired {
    base lsp-attributes-flags;
    description
      "OAM Maintenance Entity Group End Point (MEP) entities desired";
    reference "RFC7260";
  }
  identity oam-mip-entity-desired {
    base lsp-attributes-flags;
    description
      "OAM Maintenance Entity Group Intermediate Points (MIP)
       entities desired";
    reference "RFC7260";
  }
  identity srlg-collection-desired {
    base lsp-attributes-flags;
    description "SRLG collection desired";
    reference "RFC8001, RFC7570";
  }
  identity loopback-desired {
    base lsp-attributes-flags;
    description
      "This flag indicates a particular node on the LSP is
       required to enter loopback mode.  This can also be
       used for specifying the loopback state of the node.";
    reference "RFC7571";
  }
  identity p2mp-te-tree-eval-request {
    base lsp-attributes-flags;
    description "P2MP-TE tree re-evaluation request";
    reference "RFC8149";
  }
  identity rtm-set-desired {
    base lsp-attributes-flags;
    description
      "Residence Time Measurement (RTM) attribute flag requested";
    reference "RFC8169";
  }

  identity link-protection-type {
    description "Base identity for link protection type.";
  }
  identity link-protection-unprotected {
    base link-protection-type;
    description "Unprotected link type";
    reference "RFC4872";
  }
  identity link-protection-extra-traffic {
    base link-protection-type;
    description "Extra-traffic protected link type";
    reference "RFC4427.";
  }
  identity link-protection-shared {
    base link-protection-type;
    description "Shared protected link type";
    reference "RFC4872";
  }
  identity link-protection-1-for-1 {
    base link-protection-type;
    description "One for one protected link type";
    reference "RFC4872";
  }
  identity link-protection-1-plus-1 {
    base link-protection-type;
    description "One plus one protected link type";
    reference "RFC4872";
  }
  identity link-protection-enhanced {
    base link-protection-type;
    description "Enhanced protection protected link type";
    reference "RFC4872";
  }

  identity association-type {
    description "Base identity for tunnel association";
  }
  identity association-type-recovery {
    base association-type;
    description
      "Association Type Recovery used to associate LSPs of
       same tunnel for recovery";
    reference "RFC6780, RFC4872";
  }
  identity association-type-resource-sharing {
    base association-type;
    description
      "Association Type Resource Sharing used to enable resource
       sharing during make-before-break.";
    reference "RFC6780, RFC4873";
  }
  identity association-type-double-sided-bidir {
    base association-type;
    description
      "Association Type Double Sided bidirectional used to associate
       two LSPs of two tunnels that are independently configured on
       either endpoint";
    reference "RFC7551";
  }
  identity association-type-single-sided-bidir {
    base association-type;
    description
      "Association Type Single Sided bidirectional used to associate
       two LSPs of two tunnels, where a tunnel is configured on one
       side/endpoint, and the other tunnel is dynamically created on
       the other endpoint";
    reference "RFC6780,RFC7551";
  }

  identity objective-function-type {
    description "Base objective function type";
  }
  identity of-minimize-cost-path {
    base objective-function-type;
    description
        "Minimize cost of path objective function";
    reference "RFC5541";
  }
  identity of-minimize-load-path {
    base objective-function-type;
    description
        "Minimize the load on path(s) objective
         function";
    reference "RFC5541";
  }
  identity of-maximize-residual-bandwidth {
    base objective-function-type;
    description
        "Maximize the residual bandwidth objective
         function";
    reference "RFC5541";
  }
  identity of-minimize-agg-bandwidth-consumption {
    base objective-function-type;
    description
        "minimize the aggregate bandwidth consumption
         objective function";
    reference "RFC5541";
  }
  identity of-minimize-load-most-loaded-link {
    base objective-function-type;
    description
        "Minimize the load on the most loaded link
         objective function";
    reference "RFC5541";
  }
  identity of-minimize-cost-path-set {
    base objective-function-type;
    description
        "Minimize the cost on a path set objective
         function";
    reference "RFC5541";
  }

  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 "RFC3272 section 5.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 "RFC4657, RFC3272";
  }
  identity path-explicitly-defined {
    base path-computation-method;
    description
     "constrained-path LSP in which the path is
      explicitly specified as a collection of strict or/and loose
      hops";
    reference "RFC3209 and RFC3272";
  }

  identity lsp-metric-type {
    description
      "Base identity for types of LSP metric specification";
  }
  identity lsp-metric-relative {
    base lsp-metric-type;
    description
      "The metric specified for the LSPs to which this identity refers
      is specified as a relative value to the IGP metric cost to the
      LSP's tail-end.";
    reference "RFC4657";
  }
  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 "RFC4657";
  }
  identity lsp-metric-inherited {
    base lsp-metric-type;
    description
      "The metric for the LSPs to which this identity refers is
      not specified explicitly - but rather inherited from the IGP
      cost directly";
    reference "RFC4657";
  }

  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 tunnel type.";
    reference "RFC3209";
  }
  identity te-tunnel-p2mp {
    base te-tunnel-type;
    description
      "TE point-to-multipoint tunnel type.";
    reference "RFC4875";
  }

  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 resetup. Tears 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 reoptimize.
       Reoptimizes placement of the tunnel LSP(s)";
  }
  identity tunnel-action-switchpath {
    base tunnel-action-type;
    description
      "TE tunnel action switchpath
       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 successful.";
  }
  identity te-action-fail {
    base te-action-result;
    description "TE action failed.";
  }
  identity tunnel-action-inprogress {
    base te-action-result;
    description "TE action inprogress.";
  }

  identity tunnel-admin-state-type {
    description
      "Base identity for TE tunnel admin states";
  }
  identity tunnel-admin-state-up {
    base tunnel-admin-state-type;
    description "Tunnel administratively state up";
  }
  identity tunnel-admin-state-down {
    base tunnel-admin-state-type;
    description "Tunnel administratively state down";
  }

  identity tunnel-state-type {
    description
      "Base identity for TE tunnel states";
  }
  identity tunnel-state-up {
    base tunnel-state-type;
    description "Tunnel state up";
  }
  identity tunnel-state-down {
    base tunnel-state-type;
    description "Tunnel state down";
  }

  identity lsp-state-type {
    description
      "Base identity for TE LSP states";
  }
  identity lsp-path-computing {
    base lsp-state-type;
    description
      "State path compute in progress";
  }
  identity lsp-path-computation-ok {
    base lsp-state-type;
    description
      "State path compute successful";
  }
  identity lsp-path-computation-failed {
    base lsp-state-type;
    description
      "State path compute failed";
  }
  identity lsp-state-setting-up {
    base lsp-state-type;
    description
      "State setting up";
  }
  identity lsp-state-setup-ok {
    base lsp-state-type;
    description
      "State setup successful";
  }
  identity lsp-state-setup-failed {
    base lsp-state-type;
    description
      "State setup failed";
  }
  identity lsp-state-up {
    base lsp-state-type;
    description "State up";
  }
  identity lsp-state-tearing-down {
    base lsp-state-type;
    description
      "State tearing down";
  }
  identity lsp-state-down {
    base lsp-state-type;
    description "State 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
      "TE path invalidation action to drop";
    reference "RFC3209 section 2.5";
  }
  identity path-invalidation-action-teardown {
    base path-invalidation-action-type;
    description
      "TE path invalidation action teardown";
    reference "RFC3209 section 2.5";
  }

  identity lsp-restoration-type {
    description
      "Base identity from which LSP restoration types are
       derived.";
  }
  identity lsp-restoration-restore-any {
    base lsp-restoration-type;
    description
      "Restores when any of the LSPs is affected by a failure";
  }
  identity lsp-restoration-restore-all {
    base lsp-restoration-type;
    description
      "Restores when all the tunnel LSPs are affected by failure";
  }

  identity restoration-scheme-type {
    description
      "Base identity for LSP restoration schemes";
  }
  identity restoration-scheme-preconfigured {
    base restoration-scheme-type;
    description
      "Restoration LSP is preconfigured prior to the failure";
    reference "RFC4427";
  }
  identity restoration-scheme-precomputed {
    base restoration-scheme-type;
    description
      "Restoration LSP is precomputed prior to the failure";
    reference "RFC4427";
  }
  identity restoration-scheme-presignaled {
    base restoration-scheme-type;
    description
      "Restoration LSP is presignaled prior to the failure";
    reference "RFC4427";
  }

  identity lsp-protection-type {
    description
      "Base identity from which LSP protection types are
      derived.";
    reference "RFC4872";
  }
  identity lsp-protection-unprotected {
    base lsp-protection-type;
    description
      "LSP protection 'Unprotected'";
    reference "RFC4872";
  }
  identity lsp-protection-reroute-extra {
    base lsp-protection-type;
    description
      "LSP protection '(Full) Rerouting'";
    reference "RFC4872";
  }
  identity lsp-protection-reroute {
    base lsp-protection-type;
    description
      "LSP protection 'Rerouting without Extra-Traffic'";
    reference "RFC4872";
  }
  identity lsp-protection-1-for-n {
    base lsp-protection-type;
    description
      "LSP protection '1:N Protection with Extra-Traffic'";
    reference "RFC4872";
  }
  identity lsp-protection-unidir-1-for-1 {
    base lsp-protection-type;
    description
      "LSP protection '1:1 Unidirectional Protection'";
    reference "RFC4872";
  }
  identity lsp-protection-bidir-1-for-1 {
    base lsp-protection-type;
    description
      "LSP protection '1:1 Bidirectional Protection'";
    reference "RFC4872";
  }
  identity lsp-protection-unidir-1-plus-1 {
    base lsp-protection-type;
    description
      "LSP protection '1+1 Unidirectional Protection'";
    reference "RFC4872";
  }
  identity lsp-protection-bidir-1-plus-1 {
    base lsp-protection-type;
    description
      "LSP protection '1+1 Bidirectional Protection'";
    reference "RFC4872";
  }
  identity lsp-protection-extra-traffic {
    base lsp-protection-type;
    description
      "LSP protection 'Extra-Traffic'";
    reference
      "RFC4427.";
  }

  identity lsp-protection-state {
    description
      "Base identity of protection states for reporting
       purposes.";
  }
  identity normal {
    base lsp-protection-state;
    description "Normal state.";
  }
  identity signal-fail-of-protection {
    base lsp-protection-state;
    description
        "There is a signal fail condition on the protection
         transport entity which has higher priority than the
         forced switch command.";
    reference
        "RFC4427";
  }
  identity lockout-of-protection {
    base lsp-protection-state;
    description
        "A Loss of Protection (LoP) command is active.";
    reference
        "RFC4427";
  }
  identity forced-switch {
    base lsp-protection-state;
    description
        "A forced switch command is active.";
    reference
        "RFC4427";
  }
  identity signal-fail {
    base lsp-protection-state;
    description
        "There is a signal fail condition on either the working
        or the protection path.";
    reference
        "RFC4427";
  }
  identity signal-degrade {
    base lsp-protection-state;
    description
        "There is an signal degrade condition on either the working
         or the protection path.";
    reference
        "RFC4427";
  }
  identity manual-switch {
    base lsp-protection-state;
    description
        "A manual switch command is active.";
    reference
        "RFC4427";
  }
  identity wait-to-restore {
    base lsp-protection-state;
    description
        "A wait time to restore (WTR) is running.";
    reference
        "RFC4427";
  }
  identity do-not-revert {
    base lsp-protection-state;
    description
        "A DNR condition is active because of a non-revertive
         behavior.";
    reference
        "RFC4427";
  }
  identity failure-of-protocol {
    base lsp-protection-state;
    description
        "The protection is not working because of a failure of
         protocol condition.";
    reference
        "RFC4427";
  }

  identity protection-external-commands {
    description
      "Base identity from which protection external commands
       for trouble shooting purposes are derived.";
  }
  identity action-freeze {
    base protection-external-commands;
    description
      "A temporary configuration action initiated by an operator
       command to prevent any switch action to be taken and as such
       freezes the current state.";
    reference
      "RFC4427";
  }
  identity clear-freeze {
    base protection-external-commands;
    description
      "An action that clears the active freeze state.";
    reference
      "RFC4427";
  }
  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
      "RFC4427";
  }
  identity clear-lockout-of-normal {
    base protection-external-commands;
    description
      "An action that clears the active lockout of normal state.";
    reference
      "RFC4427";
  }
  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
        "RFC4427";
  }
  identity action-forced-switch {
    base protection-external-commands;
    description
        "A switch 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 an
         equal or higher priority switch command is in effect.";
    reference
        "RFC4427";
  }
  identity action-manual-switch {
    base protection-external-commands;
    description
        "A switch 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 an
         equal or higher priority switch command is in effect.";
    reference
        "RFC4427";
  }
  identity action-exercise {
    base protection-external-commands;
    description
        "An action to start testing if the APS communication is
         operating correctly. It is lower priority than any other
         state or command.";
    reference
        "RFC4427";
  }
  identity clear {
    base protection-external-commands;
    description
        "An action that clears the active near-end lockout of
         protection, forced switch, manual switch, WTR state,
         or exercise command.";
    reference
        "RFC4427";
  }

  identity switching-capabilities {
    description
      "Base identity for interface switching capabilities";
    reference "RFC3471";
  }
  identity switching-psc1 {
    base switching-capabilities;
    description
      "Packet-Switch Capable-1 (PSC-1)";
    reference "RFC3471";
  }
  identity switching-evpl {
    base switching-capabilities;
    description
      "Ethernet Virtual Private Line (EVPL)";
    reference "RFC6004";
  }
  identity switching-l2sc {
    base switching-capabilities;
    description
      "Layer-2 Switch Capable (L2SC)";
    reference "RFC3471";
  }
  identity switching-tdm {
    base switching-capabilities;
    description
      "Time-Division-Multiplex Capable (TDM)";
    reference "RFC3471";
  }
  identity switching-otn {
    base switching-capabilities;
    description
      "OTN-TDM capable";
    reference "RFC7138";
  }
  identity switching-dcsc {
    base switching-capabilities;
    description
      "Data Channel Switching Capable (DCSC)";
    reference "RFC6002";
  }
  identity switching-lsc {
    base switching-capabilities;
    description
      "Lambda-Switch Capable (LSC)";
    reference "RFC3471";
  }
  identity switching-fsc {
    base switching-capabilities;
    description
      "Fiber-Switch Capable (FSC)";
    reference "RFC3471";
  }

  identity lsp-encoding-types {
    description
      "Base identity for encoding types";
    reference "RFC3471";
  }
  identity lsp-encoding-packet {
    base lsp-encoding-types;
    description
      "Packet LSP encoding";
    reference "RFC3471";
  }
  identity lsp-encoding-ethernet {
    base lsp-encoding-types;
    description
      "Ethernet LSP encoding";
    reference "RFC3471";
  }
  identity lsp-encoding-pdh {
    base lsp-encoding-types;
    description
      "ANSI/ETSI LSP encoding";
    reference "RFC3471";
  }
  identity lsp-encoding-sdh {
    base lsp-encoding-types;
    description
      "SDH ITU-T G.707 / SONET ANSI T1.105 LSP encoding";
    reference "RFC3471";
  }
  identity lsp-encoding-digital-wrapper {
    base lsp-encoding-types;
    description
      "Digital Wrapper LSP encoding";
    reference "RFC3471";
  }
  identity lsp-encoding-lambda {
    base lsp-encoding-types;
    description
      "Lambda (photonic) LSP encoding";
    reference "RFC3471";
  }
  identity lsp-encoding-fiber {
    base lsp-encoding-types;
    description
      "Fiber LSP encoding";
    reference "RFC3471";
  }
  identity lsp-encoding-fiber-channel {
    base lsp-encoding-types;
    description
      "Fiber Channel LSP encoding";
    reference "RFC3471";
  }
  identity lsp-encoding-oduk {
    base lsp-encoding-types;
    description
      "G.709 ODUk (Digital Path) LSP encoding";
    reference "RFC4328";
  }
  identity lsp-encoding-optical-channel {
    base lsp-encoding-types;
    description
      "G.709 Optical Channel LSP encoding";
    reference "RFC4328";
  }
  identity lsp-encoding-line {
    base lsp-encoding-types;
    description
      "Line (e.g., 8B/10B) LSP encoding";
      reference "RFC6004";
  }

  identity path-signaling-type {
    description
      "base identity from which specific LSPs 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 "RFC3209";
  }
  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 "RFC4873";
  }
  identity path-scope-end-to-end {
    base path-scope-type;
    description
      "Path scope end to end";
    reference "RFC4873";
  }

  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 "RFC4874";
  }
  identity route-exclude-srlg {
    base route-usage-type;
    description "Exclude SRLG";
    reference "RFC4874";
  }

  identity path-metric-type {
    description
      "Base identity for path metric type";
  }
  identity path-metric-te {
    base path-metric-type;
    description
      "TE path metric";
    reference "RFC3785";
  }
  identity path-metric-igp {
    base path-metric-type;
    description
      "IGP path metric";
    reference "RFC3785";
  }
  identity path-metric-hop {
    base path-metric-type;
    description
      "Hop path metric";
  }
  identity path-metric-delay-average {
    base path-metric-type;
    description
      "Unidirectional average link delay";
    reference "RFC7471";
  }
  identity path-metric-delay-minimum {
    base path-metric-type;
    description
      "Unidirectional minimum link delay";
    reference "RFC7471";
  }
  identity path-metric-residual-bandwidth {
    base path-metric-type;
    description
      "Unidirectional Residual Bandwidth, which is defined to be
       Maximum Bandwidth [RFC3630] minus the bandwidth currently
       allocated to LSPs.";
    reference "RFC7471";
  }
  identity path-metric-optimize-includes {
    base path-metric-type;
    description
      "A metric that optimizes the number of included resources
       specified in a set";
  }
  identity path-metric-optimize-excludes {
    base path-metric-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 path tie-breaker type";
  }
  identity path-tiebreaker-minfill {
    base path-tiebreaker-type;
    description
      "Min-Fill LSP path placement";
  }
  identity path-tiebreaker-maxfill {
    base path-tiebreaker-type;
    description
      "Max-Fill LSP path placement";
  }
  identity path-tiebreaker-random {
    base path-tiebreaker-type;
    description
      "Random LSP path placement";
  }

  identity resource-affinities-type {
    description
      "Base identity for resource affinities";
    reference "RFC2702";
  }
  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 "RFC2702 and RFC3209";
  }
  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 "RFC2702 and RFC3209";
  }
  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 "RFC2702 and RFC3209";
  }

  identity te-optimization-criterion {
    description
      "Base identity for TE optimization criterion.";
    reference
      "RFC3272: 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 "RFC5541";
  }
  identity delay {
    base te-optimization-criterion;
    description "Optimized on delay.";
    reference "RFC5541";
  }

  identity path-computation-srlg-type {
    description
      "Base identity for SRLG path computation";
  }
  identity srlg-ignore {
    base path-computation-srlg-type;
    description
      "Ignores SRLGs in path computation";
  }
  identity srlg-strict {
    base path-computation-srlg-type;
    description
      "Include strict SRLG check in path computation";
  }
  identity srlg-preferred {
    base path-computation-srlg-type;
    description
      "Include preferred SRLG check in path computation";
  }
  identity srlg-weighted {
    base path-computation-srlg-type;
    description
      "Include weighted SRLG check in path computation";
  }

  /**
   * 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 un-specified 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 dataplane 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 un-specified technologies, rt-types:generalized-label
       is used.";
    container te-label {
      description
        "Container that specifies TE label. The choices can
         be augmented for specific dataplane 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 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 the default topology provider ID=0";
      }
      leaf client-id {
        type te-global-id;
        default 0;
        description
          "An identifier to uniquely identify a client. If omitted,
           it assumes the default topology client ID=0";
      }
      leaf topology-id {
        type te-topology-id;
        default '';
        description
          "When the datastore contains several topologies, the
           topology-id distinguishes between them. If omitted, the
           default empty string topology-id is assumed";
      }
    }
  }

  /**
   * TE performance metric groupings
   **/
  grouping performance-metrics-one-way-delay-loss {
    description
      "Performance Metric (PM) information in real time that can
      be applicable to links or connections. PM defined
      in this grouping is applicable to generic TE performance
      metrics as well as packet TE performance metrics.";
    reference
      "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
      RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
      RFC7823: Performance-Based Path Selection for Explicitly
      Routed Label Switched Paths (LSPs) Using TE Metric
      Extensions";
    leaf one-way-delay {
      type uint32 {
        range '0..16777215';
      }
      description "One-way delay or latency in micro seconds.";
    }
    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 metric information in real time that can
      be applicable to links or connections. PM defined
      in this grouping is applicable to generic TE performance
      metrics as well as packet TE performance metrics.";
    reference
      "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
      RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
      RFC7823: Performance-Based Path Selection for Explicitly
      Routed Label Switched Paths (LSPs) Using TE Metric
      Extensions";
    leaf two-way-delay {
      type uint32 {
        range '0..16777215';
      }
      description "Two-way delay or latency in micro seconds.";
    }
    leaf two-way-delay-normality {
      type te-types:performance-metrics-normality;
      description "Two-way delay normality.";
    }
  }

  grouping performance-metrics-one-way-bandwidth {
    description
      "Performance metric information in real time that can
      be applicable to links. PM defined
      in this grouping is applicable to generic TE performance
      metrics as well as packet TE performance metrics.";
    reference
      "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
      RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
      RFC7823: 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)
         [RFC3630] and provides an aggregated remainder across QoS
         classes.";
    }
    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 throttle grouping.";
    leaf one-way-delay {
      type uint32 {
        range '0..16777215';
      }
      default 0;
      description "One-way delay or latency in micro seconds.";
    }
    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)
         [RFC3630] and provides an aggregated remainder across QoS
         classes.";
    }
    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 throttle grouping.";
    leaf two-way-delay {
      type uint32 {
        range '0..16777215';
      }
      default 0;
      description "Two-way delay or latency in micro seconds.";
    }
  }

  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
      "A container containing performance metric attributes.";
    container performance-metrics-one-way {
      description
        "One-way link performance information in real time.";
      reference
        "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
         RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
         RFC7823: 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
        "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
         RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
         RFC7823: Performance-Based Path Selection for Explicitly
         Routed Label Switched Paths (LSPs) Using TE Metric
         Extensions";
      uses performance-metrics-two-way-delay-loss;
    }
  }

  grouping performance-metrics-throttle-container {
    description
      "A container controlling performance metric throttle.";
    container throttle {
      must "suppression-interval >= measure-interval" {
        error-message
          "suppression-interval cannot be less then
           measure-interval.";
        description
          "Constraint on suppression-interval and
           measure-interval.";
      }
      description
        "Link performance information in real time.";
      reference
        "RFC7471: OSPF Traffic Engineering (TE) Metric Extensions.
         RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions.
         RFC7823: 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';
        }
        default 0;
        description
          "Offset value to be added to the measured delay value.";
      }
      leaf measure-interval {
        type uint32;
        default 30;
        description
          "Interval in seconds to measure the extended metric
           values.";
      }
      leaf advertisement-interval {
        type uint32;
        default 0;
        description
          "Interval in seconds to advertise the extended metric
           values.";
      }
      leaf suppression-interval {
        type uint32 {
          range '1 .. max';
        }
        default 120;
        description
          "Interval in seconds to suppress advertising the extended
           metric values.";
        reference "RFC 7810, Section-6";
      }
      container threshold-out {
        uses performance-metrics-thresholds;
        description
          "If the measured parameter falls outside an upper bound
           for all but the min delay metric (or lower bound for
           min-delay metric only) and the advertised value is not
           already outside that bound, anomalous announcement will be
           triggered.";
      }
      container threshold-in {
        uses performance-metrics-thresholds;
        description
          "If the measured parameter falls inside an upper bound
           for all but the min delay metric (or lower bound for
           min-delay metric only) and the advertised value is not
           already inside that bound, normal (anomalous-flag cleared)
           announcement will be triggered.";
      }
      container threshold-accelerated-advertisement {
        description
          "When the difference between the last advertised value and
           current measured value exceed this threshold, anomalous
           announcement will be triggered.";
        uses performance-metrics-thresholds;
      }
    }
  } // performance-metrics-throttle-container

  /**
   * 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 {
          leaf node-id {
            type te-node-id;
            mandatory true;
            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
            "RFC3209: section 4.3 for EXPLICIT_ROUTE in RSVP-TE
             RFC3477: Signalling Unnumbered Links in 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 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
            "RFC3209: section 4.3 for EXPLICIT_ROUTE in RSVP-TE
             RFC3477: Signalling Unnumbered Links in RSVP-TE";
        }
      }
      case unnumbered-link-hop {
        container unnumbered-link-hop {
          leaf link-tp-id {
            type te-tp-id;
            mandatory true;
            description
              "TE link termination point identifier. The combination
               of TE link ID and the TE node ID is used to identify an
               unnumbered TE link.";
          }
          leaf node-id {
            type te-node-id;
            mandatory true;
            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
            "RFC3209: section 4.3 for EXPLICIT_ROUTE in RSVP-TE
             RFC3477: Signalling Unnumbered Links in RSVP-TE";
        }
      }
      case as-number {
        container as-number-hop {
          leaf as-number {
            type inet:as-number;
            mandatory true;
            description "The AS number";
          }
          leaf hop-type {
            type te-hop-type;
            default 'strict';
            description "strict or loose hop";
          }
          description
            "Autonomous System explicit route hop";
        }
      }
      case label {
        container label-hop {
          description "Label hop type";
          uses te-label;
        }
        description
          "The label explicit route hop type";
      }
    }
  }

  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 {
          description "Numbered node route hop container";
          leaf node-id {
            type te-node-id;
            mandatory true;
            description
              "The identifier of a node in the TE topology.";
          }
          leaf-list flags {
            type path-attribute-flags;
            description "Record route per hop flags";
            reference "RFC3209, RFC4090, RFC4561";
          }
        }
        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 link termination point identifier.";
          }
          leaf-list flags {
            type path-attribute-flags;
            description "Record route per hop flags";
            reference "RFC3209, RFC4090, RFC4561";
          }
        }
        description "Numbered link route hop";
      }
      case unnumbered-link-hop {
        container unnumbered-link-hop {
          leaf link-tp-id {
            type te-tp-id;
            mandatory true;
            description
                "TE link termination point identifier. The combination
                 of TE link ID and the TE node ID is used to identify an
                 unnumbered TE link.";
          }
          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 "Record route per hop flags";
            reference "RFC3209, RFC4090, RFC4561";
          }
          description
            "Unnumbered link record route hop";
          reference
            "RFC3477: Signalling Unnumbered Links in
             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 "Record route per hop flags";
            reference "RFC3209, RFC4090, RFC4561";
          }
        }
        description
          "The Label record route entry types";
      }
    }
  }

  grouping label-restriction-info {
    description "Label set item info";
    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
        "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, attribute 'label-end' 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
        "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 will have to 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.
         The MSB 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 the label-start.

         For example, assuming 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 List of label restrictions specifying what labels
       may or may not be used on a link connectivity.";
    container label-restrictions {
      description
        "The label restrictions container";
      list label-restriction {
        key "index";
        description
          "The absence of label-set implies that all labels are
           acceptable; otherwise only restricted labels are
           available.";
        reference
          "RFC7579: 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-type;
      }
      description
        "Identifies an entry in the list of metric-types to
         optimize the TE path for.";
    }
    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
        "RFC4202: 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 "RFC3209";
    }
    leaf hold-priority {
      type uint8 {
        range '0..7';
      }
      default 7;
      description
        "TE LSP requested hold priority";
      reference "RFC3209";
    }
    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";
    uses te-topology-identifier;
    uses common-constraints;
  }

  grouping path-constraints-route-objects {
    description
      "List of route entries to be included or excluded when performing
       path computation.";
    container explicit-route-objects-always {
      description
        "Container for the exclude route object list";
      list route-object-exclude-always {
        key index;
        ordered-by user;
        description
          "List of route objects to always exclude
           from 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 path
           computation";
        leaf explicit-route-usage {
          type identityref {
            base route-usage-type;
          }
          default te-types:route-include-object;
          description
            "Include or exclude usage. Default is to include";
        }
        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 {
          augment "type" {
            case srlg {
              container srlg {
                description "SRLG container";
                leaf srlg {
                  type uint32;
                  description "SRLG value";
                }
              }
              description "An SRLG value to be included or excluded";
            }
            description
              "Augmentation to generic explicit route for SRLG
               exclusion";
          }
        }
      }
    }
  }

  grouping path-route-include-objects {
    description
      "List of route object(s) 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 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 object(s) 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 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 {
        augment "type" {
          case srlg {
            container srlg {
              description "SRLG container";
              leaf srlg {
                type uint32;
                description "SRLG value";
              }
            }
            description "An SRLG value to be included or excluded";
          }
          description
            "Augmentation to generic explicit route for SRLG exclusion";
        }
      }
    }
  }

  grouping generic-path-metric-bounds {
    description "TE path metric bounds grouping";
    container path-metric-bounds {
      description "TE path metric bounds container";
      list path-metric-bound {
        key metric-type;
        description "List of TE path metric bounds";
        leaf metric-type {
          type identityref {
            base path-metric-type;
          }
          description
            "Identifies an entry in the list of metric-types
             bound for the TE path.";
        }
        leaf upper-bound {
          type uint64;
          default 0;
          description
            "Upper bound on end-to-end TE path metric. A zero indicate
             an unbounded upper limit for the specific metric-type";
        }
      }
    }
  }

  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 {
            description
              "Container for the list of tiebreaker(s)";
            list tiebreaker {
              key "tiebreaker-type";
              description
                "The list of tiebreaker criterion to apply
                 on an equally favored set of paths to pick best";
              leaf tiebreaker-type {
                type identityref {
                  base path-metric-type;
                }
                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";
            }
          }
        }
      }
    }
  }

  grouping generic-path-affinities {
    description
      "Path affinities grouping";
    container path-affinities-values {
      description
        "Path affinities values representation";
      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 affinities
             constraints";
        }
        leaf value {
          type admin-groups;
          default '';
          description "The affinity value. The default is empty.";
        }
      }
    }
    container path-affinity-names {
      description
        "Path affinities named representation style";
      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 affinities
             constraints";
        }
        list affinity-name {
          key "name";
          leaf name {
            type string;
            description "Identify a named affinity entry.";
          }
          description "List of named affinities";
        }
      }
    }
  }

  grouping generic-path-srlgs {
    description
      "Path SRLG grouping";
    container path-srlgs-lists {
      description
        "Path SRLG properties container";
      list path-srlgs-list {
        key "usage";
        description
          "List entries of value SRLGs to be included or excluded";
        leaf usage {
          type identityref {
            base route-usage-type;
          }
          description
            "Identifies an entry of list of SRLGs to either include
             or exclude";
        }
        leaf-list values {
          type srlg;
          description "List of SRLG values";
        }
      }
    }
    container path-srlgs-names {
      description "Container for named SRLG list";
      list path-srlgs-name {
        key "usage";
        description
          "List entries of named SRLGs to be included or excluded";
        leaf usage {
          type identityref {
            base route-usage-type;
          }
          description
            "Identifies an entry of list of named SRLGs to either
             include or exclude";
        }
        leaf-list names {
          type string;
          description "List of named 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, disjointness level overrides the one 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;
        }
      }
    }
  }
}
]]></sourcecode>
      </figure>
    </section>
    <section anchor="packet-te-types-yang-module" numbered="true" toc="default">
      <name>Packet TE Types YANG Module</name>
      <t>The ietf-te-packet-types module imports from the following modules:</t>
      <ul spacing="normal">
        <li>ietf-te-types defined in this document.</li>
      </ul>
      <figure anchor="fig-mpls-te-types">
        <name>TE packet types YANG module</name>
        <sourcecode name="ietf-te-packet-types@2019-11-18.yang" type="" markers="true"><![CDATA[
module ietf-te-packet-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-te-packet-types";

  /* Replace with IANA when assigned */
  prefix "te-packet-types";

  /* Import TE generic types */
  import ietf-te-types {
    prefix te-types;
    reference
      "RFC XXXX: A YANG Data Model for Common Traffic Engineering
       Types";
  }

  organization
    "IETF TEAS Working Group";

  contact
    "WG Web:   <http://tools.ietf.org/wg/teas/>
     WG List:  <mailto:teas@ietf.org>

     Editor:   Tarek Saad
               <mailto:tsaad@juniper.net>

     Editor:   Rakesh Gandhi
               <mailto:rgandhi@cisco.com>

     Editor:   Vishnu Pavan Beeram
               <mailto:vbeeram@juniper.net>

     Editor:   Himanshu Shah
               <mailto:hshah@ciena.com>

     Editor:   Xufeng Liu
               <mailto:xufeng.liu.ietf@gmail.com>

     Editor:   Igor Bryskin
               <mailto:i_bryskin@yahoo.com>

     Editor:   Young Lee
               <mailto:leeyoung@huawei.com>";

  description
    "This module contains a collection of generally useful MPLS TE
     specific YANG data type definitions. The model fully conforms
     to the Network Management Datastore Architecture (NMDA).

     Copyright (c) 2018 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 Simplified 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; see
     the RFC itself for full legal notices.";

  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.

  // RFC Ed.: update the date below with the date of RFC publication
  // and remove this note.

  revision "2019-11-18" {
    description "Latest revision of TE MPLS types";
    reference
      "RFC XXXX: A YANG Data Model for Common Traffic Engineering
       Types";
  }

  /**
   * Typedefs
   */
  typedef te-bandwidth-requested-type {
    type enumeration {
      enum specified {
        description
          "Bandwidth 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 that defines a set of Traffic
       Trunks crossing a link that is governed by a specific
       set of bandwidth constraints. CT is used for the
       purposes of link bandwidth allocation, constraint-
       based routing and admission control.";
    reference "RFC4124: Protocols for Diffserv-aware TE";
  }

  typedef bc-type {
    type uint8 {
      range '0..7';
    }
    description
      "Diffserv-TE bandwidth constraint as defined in RFC4124";
    reference "RFC4124: Protocols for Diffserv-aware TE";
  }

  typedef bandwidth-kbps {
    type uint64;
    units "Kbps";
    description
      "Bandwidth values expressed in kilobits per second";
  }

  typedef bandwidth-mbps {
    type uint64;
    units "Mbps";
    description
      "Bandwidth values expressed in megabits per second";
  }

  typedef bandwidth-gbps {
    type uint64;
    units "Gbps";
    description
      "Bandwidth values expressed in gigabits per second";
  }

  identity backup-protection-type {
    description
      "Base identity for 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 Diffserv-TE bandwidth constraint
      model type";
    reference "RFC4124: Protocols for Diffserv-aware TE";
  }

  identity bc-model-rdm {
    base bc-model-type;
    description
      "Russian Doll bandwidth constraint model type.";
    reference "RFC4127: Russian Dolls Model for DS-TE";
  }

  identity bc-model-mam {
    base bc-model-type;
    description
      "Maximum Allocation bandwidth constraint
      model type.";
    reference "RFC4125: Maximum Allocation Model for DS-TE";
  }

  identity bc-model-mar {
    base bc-model-type;
    description
      "Maximum Allocation with Reservation
      bandwidth constraint model type.";
    reference "RFC4126: MAR Bandwidth Constraints Model for DS-TE";
  }

  grouping performance-metrics-attributes-packet {
    description
      "A container containing performance metric attributes.";
    uses te-types:performance-metrics-attributes {
      augment performance-metrics-one-way {
        leaf one-way-min-delay {
          type uint32 {
            range '0..16777215';
          }
          description
            "One-way minimum delay or latency in micro seconds.";
        }
        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';
          }
          description
            "One-way maximum delay or latency in micro seconds.";
        }
        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';
          }
          description "One-way delay variation in micro seconds.";
          reference "RFC5481, section 4.2";
        }
        leaf one-way-delay-variation-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description "One-way delay variation normality.";
          reference "RFC7471, RFC8570, and RFC7823";
        }
        leaf one-way-packet-loss {
          type decimal64 {
            fraction-digits 6;
            range '0 .. 50.331642';
          }
          description
            "One-way packet loss as a percentage of the total traffic
             sent over a configurable interval. The finest precision is
             0.000003%. where the maximum 50.331642%.";
          reference "RFC 7810, section-4.4";
        }
        leaf one-way-packet-loss-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description "Packet loss normality.";
          reference "RFC7471, RFC8570, and RFC7823";
        }
        description
          "PM one-way packet specific augmentation to generic PM
           grouping";
      }
      augment performance-metrics-two-way {
        leaf two-way-min-delay {
          type uint32 {
            range '0..16777215';
          }
          default 0;
          description
            "Two-way minimum delay or latency in micro seconds.";
        }
        leaf two-way-min-delay-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description "Two-way minimum delay or latency normality.";
          reference "RFC7471, RFC8570, and RFC7823";
        }
        leaf two-way-max-delay {
          type uint32 {
            range '0..16777215';
          }
          default 0;
          description
            "Two-way maximum delay or latency in micro seconds.";
        }
        leaf two-way-max-delay-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description "Two-way maximum delay or latency normality.";
          reference "RFC7471, RFC8570, and RFC7823";
        }
        leaf two-way-delay-variation {
          type uint32 {
            range '0..16777215';
          }
          default 0;
          description "Two-way delay variation in micro seconds.";
          reference "RFC5481, section 4.2";
        }
        leaf two-way-delay-variation-normality {
          type te-types:performance-metrics-normality;
          default "normal";
          description "Two-way delay variation normality.";
          reference "RFC7471, RFC8570, and RFC7823";
        }
        leaf two-way-packet-loss {
          type decimal64 {
            fraction-digits 6;
            range '0 .. 50.331642';
          }
          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
          "PM two-way packet specific augmentation to generic PM
           grouping";
        reference "RFC7471, RFC8570, and RFC7823";
      }
    }
  }

  grouping one-way-performance-metrics-packet {
    description
      "One-way packet performance metrics throttle grouping.";
    leaf one-way-min-delay {
      type uint32 {
        range '0..16777215';
      }
      default 0;
      description "One-way minimum delay or latency in micro seconds.";
    }
    leaf one-way-max-delay {
      type uint32 {
        range '0..16777215';
      }
      default 0;
      description "One-way maximum delay or latency in micro seconds.";
    }
    leaf one-way-delay-variation {
      type uint32 {
        range '0..16777215';
      }
      default 0;
      description "One-way delay variation in micro seconds.";
    }
    leaf one-way-packet-loss {
      type decimal64 {
        fraction-digits 6;
        range '0 .. 50.331642';
      }
      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 two-way-performance-metrics-packet {
    description
      "Two-way packet performance metrics throttle grouping.";
    leaf two-way-min-delay {
      type uint32 {
        range '0..16777215';
      }
      default 0;
      description "Two-way minimum delay or latency in micro seconds.";
    }
    leaf two-way-max-delay {
      type uint32 {
        range '0..16777215';
      }
      default 0;
      description "Two-way maximum delay or latency in micro seconds.";
    }
    leaf two-way-delay-variation {
      type uint32 {
        range '0..16777215';
      }
      default 0;
      description "Two-way delay variation in micro seconds.";
    }
    leaf two-way-packet-loss {
      type decimal64 {
        fraction-digits 6;
        range '0 .. 50.331642';
      }
      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 performance-metrics-throttle-container-packet {
    description
      "Packet performance metrics 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
            "PM threshold-out packet augmentation to
             generic grouping";
        }
        augment "throttle/threshold-in" {
          uses one-way-performance-metrics-packet;
          uses two-way-performance-metrics-packet;
          description
            "PM threshold-in packet augmentation to
             generic grouping";
        }
        augment "throttle/threshold-accelerated-advertisement" {
          uses one-way-performance-metrics-packet;
          uses two-way-performance-metrics-packet;
          description
            "PM accelerated advertisement packet augmentation to
             generic grouping";
        }
    }
  }
}
]]></sourcecode>
      </figure>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document registers the following URIs in the IETF XML registry
<xref target="RFC3688" format="default"/>.
Following the format in <xref target="RFC3688" format="default"/>, the following registration is
requested to be made.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
   URI: urn:ietf:params:xml:ns:yang:ietf-te-types
   XML: N/A, the requested URI is an XML namespace.

   URI: urn:ietf:params:xml:ns:yang:ietf-te-packet-types
   XML: N/A, the requested URI is an XML namespace.
]]></artwork>
      <t>This document registers two YANG modules in the YANG Module Names
registry <xref target="RFC6020" format="default"/>.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
   name:       ietf-te-types
   namespace:  urn:ietf:params:xml:ns:yang:ietf-te-types
   prefix:     te-types
   reference:  RFCXXXX

   name:       ietf-te-packet-types
   namespace:  urn:ietf:params:xml:ns:yang:ietf-te-packet-types
   prefix:     te-packet-types
   reference:  RFCXXXX
]]></artwork>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The YANG module specified in this document defines a schema for data that is
designed to be accessed via network management protocols such as NETCONF
<xref target="RFC6241" format="default"/> or RESTCONF <xref target="RFC8040" format="default"/>. The lowest NETCONF layer is the secure
transport layer, and the mandatory-to-implement secure transport is Secure
Shell (SSH) <xref target="RFC6242" format="default"/>.  The lowest RESTCONF layer is HTTPS, and the
mandatory-to-implement secure transport is TLS <xref target="RFC8446" format="default"/>.</t>
      <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341" format="default"/> 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 module in this document defines common TE type definitions
(i.e., typedef, identity and grouping statements) in YANG data modeling
language to be imported and used by other TE modules. When imported
and used, the resultant schema will have data nodes that can be writable, or
readable. The access to such data nodes may be considered sensitive or
vulnerable in some network environments.  Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative effect on
network operations.</t>
      <t>The security considerations spelled out in the YANG 1.1 specification
<xref target="RFC7950" format="default"/> apply for this document as well.</t>
    </section>
    <section anchor="acknowledgement" numbered="true" toc="default">
      <name>Acknowledgement</name>
      <t>The authors would like to thank the  members of the multi-vendor YANG design team 
who are involved in the definition of these data types.</t>
      <t>The authors would also like to thank Tom Petch, Jan Lindblad, Sergio Belotti, Italo Busi,
Carlo Perocchio, Francesco Lazzeri, and Aihua Guo for their review 
comments and for providing valuable feedback on this document.</t>
    </section>
    <section anchor="contributors" numbered="true" toc="default">
      <name>Contributors</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
   Himanshu Shah
   Ciena

   Email: hshah@ciena.com


   Young Lee
   Huawei Technologies

   Email: leeyoung@huawei.com

]]></artwork>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6020"/>
            <seriesInfo name="RFC" value="6020"/>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization/>
            </author>
            <date year="2010" month="October"/>
            <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>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6241"/>
            <seriesInfo name="RFC" value="6241"/>
            <author initials="R." surname="Enns" fullname="R. Enns" role="editor">
              <organization/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization/>
            </author>
            <author initials="A." surname="Bierman" fullname="A. Bierman" role="editor">
              <organization/>
            </author>
            <date year="2011" month="June"/>
            <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>
        </reference>
        <reference anchor="RFC8294" target="https://www.rfc-editor.org/info/rfc8294">
          <front>
            <title>Common YANG Data Types for the Routing Area</title>
            <seriesInfo name="DOI" value="10.17487/RFC8294"/>
            <seriesInfo name="RFC" value="8294"/>
            <author initials="X." surname="Liu" fullname="X. Liu">
              <organization/>
            </author>
            <author initials="Y." surname="Qu" fullname="Y. Qu">
              <organization/>
            </author>
            <author initials="A." surname="Lindem" fullname="A. Lindem">
              <organization/>
            </author>
            <author initials="C." surname="Hopps" fullname="C. Hopps">
              <organization/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger">
              <organization/>
            </author>
            <date year="2017" month="December"/>
            <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>
        </reference>
        <reference anchor="RFC6991" target="https://www.rfc-editor.org/info/rfc6991">
          <front>
            <title>Common YANG Data Types</title>
            <seriesInfo name="DOI" value="10.17487/RFC6991"/>
            <seriesInfo name="RFC" value="6991"/>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization/>
            </author>
            <date year="2013" month="July"/>
            <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>
        </reference>
        <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951">
          <front>
            <title>JSON Encoding of Data Modeled with YANG</title>
            <seriesInfo name="DOI" value="10.17487/RFC7951"/>
            <seriesInfo name="RFC" value="7951"/>
            <author initials="L." surname="Lhotka" fullname="L. Lhotka">
              <organization/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t>This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <seriesInfo name="DOI" value="10.17487/RFC7950"/>
            <seriesInfo name="RFC" value="7950"/>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization/>
            </author>
            <date year="2016" month="August"/>
            <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>
        </reference>
        <reference anchor="RFC8345" target="https://www.rfc-editor.org/info/rfc8345">
          <front>
            <title>A YANG Data Model for Network Topologies</title>
            <seriesInfo name="DOI" value="10.17487/RFC8345"/>
            <seriesInfo name="RFC" value="8345"/>
            <author initials="A." surname="Clemm" fullname="A. Clemm">
              <organization/>
            </author>
            <author initials="J." surname="Medved" fullname="J. Medved">
              <organization/>
            </author>
            <author initials="R." surname="Varga" fullname="R. Varga">
              <organization/>
            </author>
            <author initials="N." surname="Bahadur" fullname="N. Bahadur">
              <organization/>
            </author>
            <author initials="H." surname="Ananthakrishnan" fullname="H. Ananthakrishnan">
              <organization/>
            </author>
            <author initials="X." surname="Liu" fullname="X. Liu">
              <organization/>
            </author>
            <date year="2018" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688">
          <front>
            <title>The IETF XML Registry</title>
            <seriesInfo name="DOI" value="10.17487/RFC3688"/>
            <seriesInfo name="RFC" value="3688"/>
            <seriesInfo name="BCP" value="81"/>
            <author initials="M." surname="Mealling" fullname="M. Mealling">
              <organization/>
            </author>
            <date year="2004" month="January"/>
            <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>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040">
          <front>
            <title>RESTCONF Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC8040"/>
            <seriesInfo name="RFC" value="8040"/>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization/>
            </author>
            <date year="2017" month="January"/>
            <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>
        </reference>
        <reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6242">
          <front>
            <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6242"/>
            <seriesInfo name="RFC" value="6242"/>
            <author initials="M." surname="Wasserman" fullname="M. Wasserman">
              <organization/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem.  This document obsoletes RFC 4742.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <seriesInfo name="DOI" value="10.17487/RFC8446"/>
            <seriesInfo name="RFC" value="8446"/>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2018" month="August"/>
            <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>
        </reference>
        <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <seriesInfo name="DOI" value="10.17487/RFC8341"/>
            <seriesInfo name="RFC" value="8341"/>
            <seriesInfo name="STD" value="91"/>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization/>
            </author>
            <date year="2018" month="March"/>
            <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>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC3209" target="https://www.rfc-editor.org/info/rfc3209">
          <front>
            <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
            <seriesInfo name="DOI" value="10.17487/RFC3209"/>
            <seriesInfo name="RFC" value="3209"/>
            <author initials="D." surname="Awduche" fullname="D. Awduche">
              <organization/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger">
              <organization/>
            </author>
            <author initials="D." surname="Gan" fullname="D. Gan">
              <organization/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization/>
            </author>
            <author initials="V." surname="Srinivasan" fullname="V. Srinivasan">
              <organization/>
            </author>
            <author initials="G." surname="Swallow" fullname="G. Swallow">
              <organization/>
            </author>
            <date year="2001" month="December"/>
            <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>
        </reference>
        <reference anchor="RFC7308" target="https://www.rfc-editor.org/info/rfc7308">
          <front>
            <title>Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7308"/>
            <seriesInfo name="RFC" value="7308"/>
            <author initials="E." surname="Osborne" fullname="E. Osborne">
              <organization/>
            </author>
            <date year="2014" month="July"/>
            <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>
        </reference>
        <reference anchor="RFC6511" target="https://www.rfc-editor.org/info/rfc6511">
          <front>
            <title>Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths</title>
            <seriesInfo name="DOI" value="10.17487/RFC6511"/>
            <seriesInfo name="RFC" value="6511"/>
            <author initials="Z." surname="Ali" fullname="Z. Ali">
              <organization/>
            </author>
            <author initials="G." surname="Swallow" fullname="G. Swallow">
              <organization/>
            </author>
            <author initials="R." surname="Aggarwal" fullname="R. Aggarwal">
              <organization/>
            </author>
            <date year="2012" month="February"/>
            <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>
        </reference>
        <reference anchor="RFC5541" target="https://www.rfc-editor.org/info/rfc5541">
          <front>
            <title>Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC5541"/>
            <seriesInfo name="RFC" value="5541"/>
            <author initials="JL." surname="Le Roux" fullname="JL. Le Roux">
              <organization/>
            </author>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
              <organization/>
            </author>
            <author initials="Y." surname="Lee" fullname="Y. Lee">
              <organization/>
            </author>
            <date year="2009" month="June"/>
            <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>
        </reference>
        <reference anchor="RFC3272" target="https://www.rfc-editor.org/info/rfc3272">
          <front>
            <title>Overview and Principles of Internet Traffic Engineering</title>
            <seriesInfo name="DOI" value="10.17487/RFC3272"/>
            <seriesInfo name="RFC" value="3272"/>
            <author initials="D." surname="Awduche" fullname="D. Awduche">
              <organization/>
            </author>
            <author initials="A." surname="Chiu" fullname="A. Chiu">
              <organization/>
            </author>
            <author initials="A." surname="Elwalid" fullname="A. Elwalid">
              <organization/>
            </author>
            <author initials="I." surname="Widjaja" fullname="I. Widjaja">
              <organization/>
            </author>
            <author initials="X." surname="Xiao" fullname="X. Xiao">
              <organization/>
            </author>
            <date year="2002" month="May"/>
            <abstract>
              <t>This memo 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 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 IP networks are discussed throughout this document.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4657" target="https://www.rfc-editor.org/info/rfc4657">
          <front>
            <title>Path Computation Element (PCE) Communication Protocol Generic Requirements</title>
            <seriesInfo name="DOI" value="10.17487/RFC4657"/>
            <seriesInfo name="RFC" value="4657"/>
            <author initials="J." surname="Ash" fullname="J. Ash" role="editor">
              <organization/>
            </author>
            <author initials="J.L." surname="Le Roux" fullname="J.L. Le Roux" role="editor">
              <organization/>
            </author>
            <date year="2006" month="September"/>
            <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>
        </reference>
        <reference anchor="RFC5817" target="https://www.rfc-editor.org/info/rfc5817">
          <front>
            <title>Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks</title>
            <seriesInfo name="DOI" value="10.17487/RFC5817"/>
            <seriesInfo name="RFC" value="5817"/>
            <author initials="Z." surname="Ali" fullname="Z. Ali">
              <organization/>
            </author>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
              <organization/>
            </author>
            <author initials="A." surname="Zamfir" fullname="A. Zamfir">
              <organization/>
            </author>
            <author initials="J." surname="Newton" fullname="J. Newton">
              <organization/>
            </author>
            <date year="2010" month="April"/>
            <abstract>
              <t>MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled.  MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.</t>
              <t>This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource.  These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4328" target="https://www.rfc-editor.org/info/rfc4328">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control</title>
            <seriesInfo name="DOI" value="10.17487/RFC4328"/>
            <seriesInfo name="RFC" value="4328"/>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou" role="editor">
              <organization/>
            </author>
            <date year="2006" month="January"/>
            <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>
        </reference>
        <reference anchor="RFC6004" target="https://www.rfc-editor.org/info/rfc6004">
          <front>
            <title>Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching</title>
            <seriesInfo name="DOI" value="10.17487/RFC6004"/>
            <seriesInfo name="RFC" value="6004"/>
            <author initials="L." surname="Berger" fullname="L. Berger">
              <organization/>
            </author>
            <author initials="D." surname="Fedyk" fullname="D. Fedyk">
              <organization/>
            </author>
            <date year="2010" month="October"/>
          </front>
        </reference>
        <reference anchor="RFC6205" target="https://www.rfc-editor.org/info/rfc6205">
          <front>
            <title>Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers</title>
            <seriesInfo name="DOI" value="10.17487/RFC6205"/>
            <seriesInfo name="RFC" value="6205"/>
            <author initials="T." surname="Otani" fullname="T. Otani" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Li" fullname="D. Li" role="editor">
              <organization/>
            </author>
            <date year="2011" month="March"/>
            <abstract>
              <t>Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.</t>
              <t>Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching.  For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors.  Global wavelength semantics are not considered.</t>
              <t>In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the Dense Wavelength Division Multiplexing (DWDM) and Coarse Wavelength Division Multiplexing (CWDM) grids defined by the International Telecommunication Union Telecommunication Standardization Sector. The label format defined in this document can be used in GMPLS signaling and routing protocols.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7139" target="https://www.rfc-editor.org/info/rfc7139">
          <front>
            <title>GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks</title>
            <seriesInfo name="DOI" value="10.17487/RFC7139"/>
            <seriesInfo name="RFC" value="7139"/>
            <author initials="F." surname="Zhang" fullname="F. Zhang" role="editor">
              <organization/>
            </author>
            <author initials="G." surname="Zhang" fullname="G. Zhang">
              <organization/>
            </author>
            <author initials="S." surname="Belotti" fullname="S. Belotti">
              <organization/>
            </author>
            <author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli">
              <organization/>
            </author>
            <author initials="K." surname="Pithewan" fullname="K. Pithewan">
              <organization/>
            </author>
            <date year="2014" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC7551" target="https://www.rfc-editor.org/info/rfc7551">
          <front>
            <title>RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7551"/>
            <seriesInfo name="RFC" value="7551"/>
            <author initials="F." surname="Zhang" fullname="F. Zhang" role="editor">
              <organization/>
            </author>
            <author initials="R." surname="Jing" fullname="R. Jing">
              <organization/>
            </author>
            <author initials="R." surname="Gandhi" fullname="R. Gandhi" role="editor">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC7571" target="https://www.rfc-editor.org/info/rfc7571">
          <front>
            <title>GMPLS RSVP-TE Extensions for Lock Instruct and Loopback</title>
            <seriesInfo name="DOI" value="10.17487/RFC7571"/>
            <seriesInfo name="RFC" value="7571"/>
            <author initials="J." surname="Dong" fullname="J. Dong">
              <organization/>
            </author>
            <author initials="M." surname="Chen" fullname="M. Chen">
              <organization/>
            </author>
            <author initials="Z." surname="Li" fullname="Z. Li">
              <organization/>
            </author>
            <author initials="D." surname="Ceccarelli" fullname="D. Ceccarelli">
              <organization/>
            </author>
            <date year="2015" month="July"/>
            <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>
        </reference>
        <reference anchor="RFC7579" target="https://www.rfc-editor.org/info/rfc7579">
          <front>
            <title>General Network Element Constraint Encoding for GMPLS-Controlled Networks</title>
            <seriesInfo name="DOI" value="10.17487/RFC7579"/>
            <seriesInfo name="RFC" value="7579"/>
            <author initials="G." surname="Bernstein" fullname="G. Bernstein" role="editor">
              <organization/>
            </author>
            <author initials="Y." surname="Lee" fullname="Y. Lee" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Li" fullname="D. Li">
              <organization/>
            </author>
            <author initials="W." surname="Imajuku" fullname="W. Imajuku">
              <organization/>
            </author>
            <author initials="J." surname="Han" fullname="J. Han">
              <organization/>
            </author>
            <date year="2015" month="June"/>
            <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>
        </reference>
        <reference anchor="RFC3471" target="https://www.rfc-editor.org/info/rfc3471">
          <front>
            <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description</title>
            <seriesInfo name="DOI" value="10.17487/RFC3471"/>
            <seriesInfo name="RFC" value="3471"/>
            <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
              <organization/>
            </author>
            <date year="2003" month="January"/>
            <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>
        </reference>
        <reference anchor="RFC3477" target="https://www.rfc-editor.org/info/rfc3477">
          <front>
            <title>Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC3477"/>
            <seriesInfo name="RFC" value="3477"/>
            <author initials="K." surname="Kompella" fullname="K. Kompella">
              <organization/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
              <organization/>
            </author>
            <date year="2003" month="January"/>
            <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>
        </reference>
        <reference anchor="RFC3785" target="https://www.rfc-editor.org/info/rfc3785">
          <front>
            <title>Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric</title>
            <seriesInfo name="DOI" value="10.17487/RFC3785"/>
            <seriesInfo name="RFC" value="3785"/>
            <seriesInfo name="BCP" value="87"/>
            <author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur">
              <organization/>
            </author>
            <author initials="R." surname="Uppili" fullname="R. Uppili">
              <organization/>
            </author>
            <author initials="A." surname="Vedrenne" fullname="A. Vedrenne">
              <organization/>
            </author>
            <author initials="P." surname="Merckx" fullname="P. Merckx">
              <organization/>
            </author>
            <author initials="T." surname="Telkamp" fullname="T. Telkamp">
              <organization/>
            </author>
            <date year="2004" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC4124" target="https://www.rfc-editor.org/info/rfc4124">
          <front>
            <title>Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering</title>
            <seriesInfo name="DOI" value="10.17487/RFC4124"/>
            <seriesInfo name="RFC" value="4124"/>
            <author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur" role="editor">
              <organization/>
            </author>
            <date year="2005" month="June"/>
            <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>
        </reference>
        <reference anchor="RFC4202" target="https://www.rfc-editor.org/info/rfc4202">
          <front>
            <title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC4202"/>
            <seriesInfo name="RFC" value="4202"/>
            <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
              <organization/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization/>
            </author>
            <date year="2005" month="October"/>
            <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>
        </reference>
        <reference anchor="RFC7471" target="https://www.rfc-editor.org/info/rfc7471">
          <front>
            <title>OSPF Traffic Engineering (TE) Metric Extensions</title>
            <seriesInfo name="DOI" value="10.17487/RFC7471"/>
            <seriesInfo name="RFC" value="7471"/>
            <author initials="S." surname="Giacalone" fullname="S. Giacalone">
              <organization/>
            </author>
            <author initials="D." surname="Ward" fullname="D. Ward">
              <organization/>
            </author>
            <author initials="J." surname="Drake" fullname="J. Drake">
              <organization/>
            </author>
            <author initials="A." surname="Atlas" fullname="A. Atlas">
              <organization/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi">
              <organization/>
            </author>
            <date year="2015" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC8570" target="https://www.rfc-editor.org/info/rfc8570">
          <front>
            <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
            <seriesInfo name="DOI" value="10.17487/RFC8570"/>
            <seriesInfo name="RFC" value="8570"/>
            <author initials="L." surname="Ginsberg" fullname="L. Ginsberg" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Giacalone" fullname="S. Giacalone">
              <organization/>
            </author>
            <author initials="D." surname="Ward" fullname="D. Ward">
              <organization/>
            </author>
            <author initials="J." surname="Drake" fullname="J. Drake">
              <organization/>
            </author>
            <author initials="Q." surname="Wu" fullname="Q. Wu">
              <organization/>
            </author>
            <date year="2019" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC7823" target="https://www.rfc-editor.org/info/rfc7823">
          <front>
            <title>Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions</title>
            <seriesInfo name="DOI" value="10.17487/RFC7823"/>
            <seriesInfo name="RFC" value="7823"/>
            <author initials="A." surname="Atlas" fullname="A. Atlas">
              <organization/>
            </author>
            <author initials="J." surname="Drake" fullname="J. Drake">
              <organization/>
            </author>
            <author initials="S." surname="Giacalone" fullname="S. Giacalone">
              <organization/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi">
              <organization/>
            </author>
            <date year="2016" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC6370" target="https://www.rfc-editor.org/info/rfc6370">
          <front>
            <title>MPLS Transport Profile (MPLS-TP) Identifiers</title>
            <seriesInfo name="DOI" value="10.17487/RFC6370"/>
            <seriesInfo name="RFC" value="6370"/>
            <author initials="M." surname="Bocci" fullname="M. Bocci">
              <organization/>
            </author>
            <author initials="G." surname="Swallow" fullname="G. Swallow">
              <organization/>
            </author>
            <author initials="E." surname="Gray" fullname="E. Gray">
              <organization/>
            </author>
            <date year="2011" month="September"/>
            <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>
        </reference>
        <reference anchor="RFC5003" target="https://www.rfc-editor.org/info/rfc5003">
          <front>
            <title>Attachment Individual Identifier (AII) Types for Aggregation</title>
            <seriesInfo name="DOI" value="10.17487/RFC5003"/>
            <seriesInfo name="RFC" value="5003"/>
            <author initials="C." surname="Metz" fullname="C. Metz">
              <organization/>
            </author>
            <author initials="L." surname="Martini" fullname="L. Martini">
              <organization/>
            </author>
            <author initials="F." surname="Balus" fullname="F. Balus">
              <organization/>
            </author>
            <author initials="J." surname="Sugimoto" fullname="J. Sugimoto">
              <organization/>
            </author>
            <date year="2007" month="September"/>
            <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>
        </reference>
        <reference anchor="RFC3630" target="https://www.rfc-editor.org/info/rfc3630">
          <front>
            <title>Traffic Engineering (TE) Extensions to OSPF Version 2</title>
            <seriesInfo name="DOI" value="10.17487/RFC3630"/>
            <seriesInfo name="RFC" value="3630"/>
            <author initials="D." surname="Katz" fullname="D. Katz">
              <organization/>
            </author>
            <author initials="K." surname="Kompella" fullname="K. Kompella">
              <organization/>
            </author>
            <author initials="D." surname="Yeung" fullname="D. Yeung">
              <organization/>
            </author>
            <date year="2003" month="September"/>
            <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>
        </reference>
        <reference anchor="RFC6827" target="https://www.rfc-editor.org/info/rfc6827">
          <front>
            <title>Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols</title>
            <seriesInfo name="DOI" value="10.17487/RFC6827"/>
            <seriesInfo name="RFC" value="6827"/>
            <author initials="A." surname="Malis" fullname="A. Malis" role="editor">
              <organization/>
            </author>
            <author initials="A." surname="Lindem" fullname="A. Lindem" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou" role="editor">
              <organization/>
            </author>
            <date year="2013" month="January"/>
            <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>
        </reference>
        <reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5305">
          <front>
            <title>IS-IS Extensions for Traffic Engineering</title>
            <seriesInfo name="DOI" value="10.17487/RFC5305"/>
            <seriesInfo name="RFC" value="5305"/>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization/>
            </author>
            <author initials="H." surname="Smit" fullname="H. Smit">
              <organization/>
            </author>
            <date year="2008" month="October"/>
            <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>
        </reference>
        <reference anchor="RFC6119" target="https://www.rfc-editor.org/info/rfc6119">
          <front>
            <title>IPv6 Traffic Engineering in IS-IS</title>
            <seriesInfo name="DOI" value="10.17487/RFC6119"/>
            <seriesInfo name="RFC" value="6119"/>
            <author initials="J." surname="Harrison" fullname="J. Harrison">
              <organization/>
            </author>
            <author initials="J." surname="Berger" fullname="J. Berger">
              <organization/>
            </author>
            <author initials="M." surname="Bartlett" fullname="M. Bartlett">
              <organization/>
            </author>
            <date year="2011" month="February"/>
            <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>
        </reference>
        <reference anchor="RFC4203" target="https://www.rfc-editor.org/info/rfc4203">
          <front>
            <title>OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC4203"/>
            <seriesInfo name="RFC" value="4203"/>
            <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
              <organization/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization/>
            </author>
            <date year="2005" month="October"/>
            <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>
        </reference>
        <reference anchor="RFC5307" target="https://www.rfc-editor.org/info/rfc5307">
          <front>
            <title>IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC5307"/>
            <seriesInfo name="RFC" value="5307"/>
            <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
              <organization/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization/>
            </author>
            <date year="2008" month="October"/>
            <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>
        </reference>
        <reference anchor="RFC6378" target="https://www.rfc-editor.org/info/rfc6378">
          <front>
            <title>MPLS Transport Profile (MPLS-TP) Linear Protection</title>
            <seriesInfo name="DOI" value="10.17487/RFC6378"/>
            <seriesInfo name="RFC" value="6378"/>
            <author initials="Y." surname="Weingarten" fullname="Y. Weingarten" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Bryant" fullname="S. Bryant">
              <organization/>
            </author>
            <author initials="E." surname="Osborne" fullname="E. Osborne">
              <organization/>
            </author>
            <author initials="N." surname="Sprecher" fullname="N. Sprecher">
              <organization/>
            </author>
            <author initials="A." surname="Fulignoli" fullname="A. Fulignoli" role="editor">
              <organization/>
            </author>
            <date year="2011" month="October"/>
            <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>
        </reference>
        <reference anchor="RFC4427" target="https://www.rfc-editor.org/info/rfc4427">
          <front>
            <title>Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)</title>
            <seriesInfo name="DOI" value="10.17487/RFC4427"/>
            <seriesInfo name="RFC" value="4427"/>
            <author initials="E." surname="Mannie" fullname="E. Mannie" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou" role="editor">
              <organization/>
            </author>
            <date year="2006" month="March"/>
            <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>
        </reference>
        <reference anchor="RFC4090" target="https://www.rfc-editor.org/info/rfc4090">
          <front>
            <title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title>
            <seriesInfo name="DOI" value="10.17487/RFC4090"/>
            <seriesInfo name="RFC" value="4090"/>
            <author initials="P." surname="Pan" fullname="P. Pan" role="editor">
              <organization/>
            </author>
            <author initials="G." surname="Swallow" fullname="G. Swallow" role="editor">
              <organization/>
            </author>
            <author initials="A." surname="Atlas" fullname="A. Atlas" role="editor">
              <organization/>
            </author>
            <date year="2005" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC4561" target="https://www.rfc-editor.org/info/rfc4561">
          <front>
            <title>Definition of a Record Route Object (RRO) Node-Id Sub-Object</title>
            <seriesInfo name="DOI" value="10.17487/RFC4561"/>
            <seriesInfo name="RFC" value="4561"/>
            <author initials="J.-P." surname="Vasseur" fullname="J.-P. Vasseur" role="editor">
              <organization/>
            </author>
            <author initials="Z." surname="Ali" fullname="Z. Ali">
              <organization/>
            </author>
            <author initials="S." surname="Sivabalan" fullname="S. Sivabalan">
              <organization/>
            </author>
            <date year="2006" month="June"/>
            <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>
        </reference>
        <reference anchor="RFC4736" target="https://www.rfc-editor.org/info/rfc4736">
          <front>
            <title>Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC4736"/>
            <seriesInfo name="RFC" value="4736"/>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role="editor">
              <organization/>
            </author>
            <author initials="Y." surname="Ikejiri" fullname="Y. Ikejiri">
              <organization/>
            </author>
            <author initials="R." surname="Zhang" fullname="R. Zhang">
              <organization/>
            </author>
            <date year="2006" month="November"/>
            <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>
        </reference>
        <reference anchor="RFC5712" target="https://www.rfc-editor.org/info/rfc5712">
          <front>
            <title>MPLS Traffic Engineering Soft Preemption</title>
            <seriesInfo name="DOI" value="10.17487/RFC5712"/>
            <seriesInfo name="RFC" value="5712"/>
            <author initials="M." surname="Meyer" fullname="M. Meyer" role="editor">
              <organization/>
            </author>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role="editor">
              <organization/>
            </author>
            <date year="2010" month="January"/>
            <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>
        </reference>
        <reference anchor="RFC4920" target="https://www.rfc-editor.org/info/rfc4920">
          <front>
            <title>Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE</title>
            <seriesInfo name="DOI" value="10.17487/RFC4920"/>
            <seriesInfo name="RFC" value="4920"/>
            <author initials="A." surname="Farrel" fullname="A. Farrel" role="editor">
              <organization/>
            </author>
            <author initials="A." surname="Satyanarayana" fullname="A. Satyanarayana">
              <organization/>
            </author>
            <author initials="A." surname="Iwata" fullname="A. Iwata">
              <organization/>
            </author>
            <author initials="N." surname="Fujita" fullname="N. Fujita">
              <organization/>
            </author>
            <author initials="G." surname="Ash" fullname="G. Ash">
              <organization/>
            </author>
            <date year="2007" month="July"/>
            <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>
        </reference>
        <reference anchor="RFC5420" target="https://www.rfc-editor.org/info/rfc5420">
          <front>
            <title>Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC5420"/>
            <seriesInfo name="RFC" value="5420"/>
            <author initials="A." surname="Farrel" fullname="A. Farrel" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou">
              <organization/>
            </author>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
              <organization/>
            </author>
            <author initials="A." surname="Ayyangarps" fullname="A. Ayyangarps">
              <organization/>
            </author>
            <date year="2009" month="February"/>
            <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>
        </reference>
        <reference anchor="RFC7570" target="https://www.rfc-editor.org/info/rfc7570">
          <front>
            <title>Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7570"/>
            <seriesInfo name="RFC" value="7570"/>
            <author initials="C." surname="Margaria" fullname="C. Margaria" role="editor">
              <organization/>
            </author>
            <author initials="G." surname="Martinelli" fullname="G. Martinelli">
              <organization/>
            </author>
            <author initials="S." surname="Balls" fullname="S. Balls">
              <organization/>
            </author>
            <author initials="B." surname="Wright" fullname="B. Wright">
              <organization/>
            </author>
            <date year="2015" month="July"/>
            <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>
        </reference>
        <reference anchor="RFC4875" target="https://www.rfc-editor.org/info/rfc4875">
          <front>
            <title>Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
            <seriesInfo name="DOI" value="10.17487/RFC4875"/>
            <seriesInfo name="RFC" value="4875"/>
            <author initials="R." surname="Aggarwal" fullname="R. Aggarwal" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Yasukawa" fullname="S. Yasukawa" role="editor">
              <organization/>
            </author>
            <date year="2007" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC5151" target="https://www.rfc-editor.org/info/rfc5151">
          <front>
            <title>Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions</title>
            <seriesInfo name="DOI" value="10.17487/RFC5151"/>
            <seriesInfo name="RFC" value="5151"/>
            <author initials="A." surname="Farrel" fullname="A. Farrel" role="editor">
              <organization/>
            </author>
            <author initials="A." surname="Ayyangar" fullname="A. Ayyangar">
              <organization/>
            </author>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
              <organization/>
            </author>
            <date year="2008" month="February"/>
            <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>
        </reference>
        <reference anchor="RFC5150" target="https://www.rfc-editor.org/info/rfc5150">
          <front>
            <title>Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC5150"/>
            <seriesInfo name="RFC" value="5150"/>
            <author initials="A." surname="Ayyangar" fullname="A. Ayyangar">
              <organization/>
            </author>
            <author initials="K." surname="Kompella" fullname="K. Kompella">
              <organization/>
            </author>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
              <organization/>
            </author>
            <author initials="A." surname="Farrel" fullname="A. Farrel">
              <organization/>
            </author>
            <date year="2008" month="February"/>
            <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>
        </reference>
        <reference anchor="RFC6001" target="https://www.rfc-editor.org/info/rfc6001">
          <front>
            <title>Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6001"/>
            <seriesInfo name="RFC" value="6001"/>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou">
              <organization/>
            </author>
            <author initials="M." surname="Vigoureux" fullname="M. Vigoureux">
              <organization/>
            </author>
            <author initials="K." surname="Shiomoto" fullname="K. Shiomoto">
              <organization/>
            </author>
            <author initials="D." surname="Brungard" fullname="D. Brungard">
              <organization/>
            </author>
            <author initials="JL." surname="Le Roux" fullname="JL. Le Roux">
              <organization/>
            </author>
            <date year="2010" month="October"/>
            <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>
        </reference>
        <reference anchor="RFC6790" target="https://www.rfc-editor.org/info/rfc6790">
          <front>
            <title>The Use of Entropy Labels in MPLS Forwarding</title>
            <seriesInfo name="DOI" value="10.17487/RFC6790"/>
            <seriesInfo name="RFC" value="6790"/>
            <author initials="K." surname="Kompella" fullname="K. Kompella">
              <organization/>
            </author>
            <author initials="J." surname="Drake" fullname="J. Drake">
              <organization/>
            </author>
            <author initials="S." surname="Amante" fullname="S. Amante">
              <organization/>
            </author>
            <author initials="W." surname="Henderickx" fullname="W. Henderickx">
              <organization/>
            </author>
            <author initials="L." surname="Yong" fullname="L. Yong">
              <organization/>
            </author>
            <date year="2012" month="November"/>
            <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>
        </reference>
        <reference anchor="RFC7260" target="https://www.rfc-editor.org/info/rfc7260">
          <front>
            <title>GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration</title>
            <seriesInfo name="DOI" value="10.17487/RFC7260"/>
            <seriesInfo name="RFC" value="7260"/>
            <author initials="A." surname="Takacs" fullname="A. Takacs">
              <organization/>
            </author>
            <author initials="D." surname="Fedyk" fullname="D. Fedyk">
              <organization/>
            </author>
            <author initials="J." surname="He" fullname="J. He">
              <organization/>
            </author>
            <date year="2014" month="June"/>
            <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>
        </reference>
        <reference anchor="RFC8001" target="https://www.rfc-editor.org/info/rfc8001">
          <front>
            <title>RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information</title>
            <seriesInfo name="DOI" value="10.17487/RFC8001"/>
            <seriesInfo name="RFC" value="8001"/>
            <author initials="F." surname="Zhang" fullname="F. Zhang" role="editor">
              <organization/>
            </author>
            <author initials="O." surname="Gonzalez de Dios" fullname="O. Gonzalez de Dios" role="editor">
              <organization/>
            </author>
            <author initials="C." surname="Margaria" fullname="C. Margaria">
              <organization/>
            </author>
            <author initials="M." surname="Hartley" fullname="M. Hartley">
              <organization/>
            </author>
            <author initials="Z." surname="Ali" fullname="Z. Ali">
              <organization/>
            </author>
            <date year="2017" month="January"/>
            <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>
        </reference>
        <reference anchor="RFC8149" target="https://www.rfc-editor.org/info/rfc8149">
          <front>
            <title>RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8149"/>
            <seriesInfo name="RFC" value="8149"/>
            <author initials="T." surname="Saad" fullname="T. Saad" role="editor">
              <organization/>
            </author>
            <author initials="R." surname="Gandhi" fullname="R. Gandhi" role="editor">
              <organization/>
            </author>
            <author initials="Z." surname="Ali" fullname="Z. Ali">
              <organization/>
            </author>
            <author initials="R." surname="Venator" fullname="R. Venator">
              <organization/>
            </author>
            <author initials="Y." surname="Kamite" fullname="Y. Kamite">
              <organization/>
            </author>
            <date year="2017" month="April"/>
            <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>
        </reference>
        <reference anchor="RFC8169" target="https://www.rfc-editor.org/info/rfc8169">
          <front>
            <title>Residence Time Measurement in MPLS Networks</title>
            <seriesInfo name="DOI" value="10.17487/RFC8169"/>
            <seriesInfo name="RFC" value="8169"/>
            <author initials="G." surname="Mirsky" fullname="G. Mirsky">
              <organization/>
            </author>
            <author initials="S." surname="Ruffini" fullname="S. Ruffini">
              <organization/>
            </author>
            <author initials="E." surname="Gray" fullname="E. Gray">
              <organization/>
            </author>
            <author initials="J." surname="Drake" fullname="J. Drake">
              <organization/>
            </author>
            <author initials="S." surname="Bryant" fullname="S. Bryant">
              <organization/>
            </author>
            <author initials="A." surname="Vainshtein" fullname="A. Vainshtein">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC6780" target="https://www.rfc-editor.org/info/rfc6780">
          <front>
            <title>RSVP ASSOCIATION Object Extensions</title>
            <seriesInfo name="DOI" value="10.17487/RFC6780"/>
            <seriesInfo name="RFC" value="6780"/>
            <author initials="L." surname="Berger" fullname="L. Berger">
              <organization/>
            </author>
            <author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur">
              <organization/>
            </author>
            <author initials="A." surname="Narayanan" fullname="A. Narayanan">
              <organization/>
            </author>
            <date year="2012" month="October"/>
            <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>
        </reference>
        <reference anchor="RFC4872" target="https://www.rfc-editor.org/info/rfc4872">
          <front>
            <title>RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery</title>
            <seriesInfo name="DOI" value="10.17487/RFC4872"/>
            <seriesInfo name="RFC" value="4872"/>
            <author initials="J.P." surname="Lang" fullname="J.P. Lang" role="editor">
              <organization/>
            </author>
            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
              <organization/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou" role="editor">
              <organization/>
            </author>
            <date year="2007" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC4873" target="https://www.rfc-editor.org/info/rfc4873">
          <front>
            <title>GMPLS Segment Recovery</title>
            <seriesInfo name="DOI" value="10.17487/RFC4873"/>
            <seriesInfo name="RFC" value="4873"/>
            <author initials="L." surname="Berger" fullname="L. Berger">
              <organization/>
            </author>
            <author initials="I." surname="Bryskin" fullname="I. Bryskin">
              <organization/>
            </author>
            <author initials="D." surname="Papadimitriou" fullname="D. Papadimitriou">
              <organization/>
            </author>
            <author initials="A." surname="Farrel" fullname="A. Farrel">
              <organization/>
            </author>
            <date year="2007" month="May"/>
            <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>
        </reference>
        <reference anchor="G709" target="https://www.itu.int/rec/T-REC-G.709">
          <front>
            <title>G.709: Interfaces for the optical transport network</title>
            <author>
              <organization/>
            </author>
            <date year="2016" month="June" day="22"/>
          </front>
        </reference>
        <reference anchor="RFC2702" target="https://www.rfc-editor.org/info/rfc2702">
          <front>
            <title>Requirements for Traffic Engineering Over MPLS</title>
            <seriesInfo name="DOI" value="10.17487/RFC2702"/>
            <seriesInfo name="RFC" value="2702"/>
            <author initials="D." surname="Awduche" fullname="D. Awduche">
              <organization/>
            </author>
            <author initials="J." surname="Malcolm" fullname="J. Malcolm">
              <organization/>
            </author>
            <author initials="J." surname="Agogbua" fullname="J. Agogbua">
              <organization/>
            </author>
            <author initials="M." surname="O'Dell" fullname="M. O'Dell">
              <organization/>
            </author>
            <author initials="J." surname="McManus" fullname="J. McManus">
              <organization/>
            </author>
            <date year="1999" month="September"/>
            <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>
        </reference>
        <reference anchor="RFC4125" target="https://www.rfc-editor.org/info/rfc4125">
          <front>
            <title>Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering</title>
            <seriesInfo name="DOI" value="10.17487/RFC4125"/>
            <seriesInfo name="RFC" value="4125"/>
            <author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur">
              <organization/>
            </author>
            <author initials="W." surname="Lai" fullname="W. Lai">
              <organization/>
            </author>
            <date year="2005" month="June"/>
            <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>
        </reference>
        <reference anchor="RFC4126" target="https://www.rfc-editor.org/info/rfc4126">
          <front>
            <title>Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering &amp; Performance Comparisons</title>
            <seriesInfo name="DOI" value="10.17487/RFC4126"/>
            <seriesInfo name="RFC" value="4126"/>
            <author initials="J." surname="Ash" fullname="J. Ash">
              <organization/>
            </author>
            <date year="2005" month="June"/>
            <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>
        </reference>
        <reference anchor="RFC4127" target="https://www.rfc-editor.org/info/rfc4127">
          <front>
            <title>Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering</title>
            <seriesInfo name="DOI" value="10.17487/RFC4127"/>
            <seriesInfo name="RFC" value="4127"/>
            <author initials="F." surname="Le Faucheur" fullname="F. Le Faucheur" role="editor">
              <organization/>
            </author>
            <date year="2005" month="June"/>
            <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>
        </reference>
      </references>
    </references>
  </back>

</rfc>
