<?xmlversion="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 -->version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ ]> <?rfc toc="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"docName="draft-ietf-teas-yang-te-types-14" category="std">docName="draft-ietf-teas-yang-te-types-13" number="8776" category="std" obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.40.1 --> <front> <title abbrev="TE Common YANGTypes">Traffic Engineering CommonTypes">Common YANGTypes</title>Data Types for Traffic Engineering</title> <seriesInfo name="RFC" value="8776"/> <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>CiscoSystems Inc</organization>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> <authorinitials="V.P."initials="V." 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><organization>Futurewei Technologies, Inc.</organization> <address> <email>i_bryskin@yahoo.com</email> </address> </author> <dateyear="2019" month="December" day="10"/> <workgroup>TEAS Working Group</workgroup> <keyword>Internet-Draft</keyword>month="May" year="2020"/> <keyword>TE Tunnel</keyword> <keyword>TE Model</keyword> <keyword>TE Types</keyword> <keyword>TE YANG</keyword> <keyword>TE Topology</keyword> <keyword>TE Interfaces</keyword> <keyword>TE LSP Model</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"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>YANG <xreftarget="RFC6020"/> andtarget="RFC6020" format="default"/> <xreftarget="RFC7950"/>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 asNETCONFthe Network Configuration Protocol (NETCONF) <xreftarget="RFC6241"/>.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"title="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”,"<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and“OPTIONAL”"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>The terminology for describing YANG data models is found in <xreftarget="RFC7950"/>.</t>target="RFC7950" format="default"/>.</t> </section> <section anchor="prefixes-in-data-node-names"title="Prefixesnumbered="true" toc="default"> <name>Prefixes in Data NodeNames">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 inTable 1.</t> <figure><artwork><![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></figure><xref target="prefixes-modules-table"/>.</t> <table anchor="prefixes-modules-table"> <name>Prefixes and Corresponding YANG Modules</name> <thead> <tr> <th>Prefix</th> <th>YANG Module</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>yang</td> <td>ietf-yang-types</td> <td><xref target="RFC6991"/></td> </tr> <tr> <td>inet</td> <td>ietf-inet-types</td> <td><xref target="RFC6991"/></td> </tr> <tr> <td>rt-types</td> <td>ietf-routing-types</td> <td><xref target="RFC8294"/></td> </tr> <tr> <td>te-types</td> <td>ietf-te-types</td> <td>This document</td> </tr> <tr> <td>te-packet-types</td> <td>ietf-te-packet-types</td> <td>This document</td> </tr> </tbody> </table> </section> </section> <section anchor="acronyms-and-abbreviations"title="Acronyms and Abbreviations"> <t><list style='empty'> <t>GMPLS: Generalizednumbered="true" toc="default"> <name>Acronyms and Abbreviations</name> <dl newline="false" spacing="normal" indent="10"> <dt>GMPLS:</dt><dd>Generalized Multiprotocol LabelSwitching</t> </list></t> <t><list style='empty'> <t>LSP: LabelSwitching</dd> <dt>LSP:</dt><dd>Label SwitchedPath</t> </list></t> <t><list style='empty'> <t>LSR: LabelPath</dd> <dt>LSR:</dt><dd>Label SwitchingRouter</t> </list></t> <t><list style='empty'> <t>LER: LabelRouter</dd> <dt>LER:</dt><dd>Label EdgeRouter</t> </list></t> <t><list style='empty'> <t>MPLS: MultiprotocolRouter</dd> <dt>MPLS:</dt><dd>Multiprotocol LabelSwitching</t> </list></t> <t><list style='empty'> <t>RSVP: ResourceSwitching</dd> <dt>RSVP:</dt><dd>Resource ReservationProtocol</t> </list></t> <t><list style='empty'> <t>TE: Traffic Engineering</t> </list></t> <t><list style='empty'> <t>DS-TE: DifferentiatedProtocol</dd> <dt>TE:</dt><dd>Traffic Engineering</dd> <dt>DS-TE:</dt><dd>Differentiated Services TrafficEngineering</t> </list></t> <t><list style='empty'> <t>SRLG: Shared LinkEngineering</dd> <dt>SRLG:</dt><dd>Shared RiskGroup</t> </list></t> <t><list style='empty'> <t>NBMA:Link Group</dd> <dt>NBMA:</dt><dd> Non-BroadcastMultiple-access Network</t> </list></t> <t><list style='empty'> <t>APS: AutomaticMulti-Access</dd> <dt>APS:</dt><dd>Automatic ProtectionSwitching</t> </list></t> <t><list style='empty'> <t>SD: Signal Degrade</t> </list></t> <t><list style='empty'> <t>SF: Signal Fail</t> </list></t> <t><list style='empty'> <t>WTR: Wait to Restore</t> </list></t> <t><list style='empty'> <t>PM: Performance Metrics</t> </list></t>Switching</dd> <dt>SD:</dt><dd>Signal Degrade</dd> <dt>SF:</dt><dd>Signal Fail</dd> <dt>WTR:</dt><dd>Wait-to-Restore</dd> <dt>PM:</dt><dd>Performance Metrics</dd> </dl> </section> <section anchor="overview"title="Overview">numbered="true" toc="default"> <name>Overview</name> <t>This document defines two YANG modules for common TE types:ietf-te-types"ietf&nbhy;te&nbhy;types" for TE generic types andietf-te-packet-types"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"title="TEnumbered="true" toc="default"> <name>TE Types ModuleContents">Contents</name> <t>Theietf-te-types"ietf-te-types" module (<xref target="te-types-yang-module"/>) contains common TE types that are independent and agnostic of any specific technology orcontrol planecontrol-plane instance.</t> <t>Theietf-te-types"ietf-te-types" module contains the following YANG reusable types and groupings:</t><t>te-bandwidth:</t> <t><list style='empty'> <t>A<dl newline="true" spacing="normal"> <dt>te-bandwidth:</dt> <dd>A YANG grouping that defines the generic TE bandwidth. The modeling structure allows augmentation for each technology. Forun-specifiedunspecified technologies, thestring encoded te-bandwidthstring-encoded "te-bandwidth" type isused.</t> </list></t> <t>te-label:</t> <t><list style='empty'> <t>Aused.</dd> <dt>te-label:</dt> <dd>A YANG grouping that defines the generic TE label. The modeling structure allows augmentation for each technology. Forun-specifiedunspecified technologies,rt-types:generalized-label"rt-types:generalized-label" isused.</t> </list></t> <t>performance-metrics-attributes:</t> <t><list style='empty'> <t>Aused.</dd> <dt>performance-metrics-attributes:</dt> <dd>A YANG grouping that defines one-way and two-way measuredperformance metricsPerformance Metrics (PM) andanomalous indicationindications of anomalies on link(s) or the path as defined in <xreftarget="RFC7471"/>,target="RFC7471" format="default"/>, <xreftarget="RFC8570"/>,target="RFC8570" format="default"/>, and <xreftarget="RFC7823"/>.</t> </list></t> <t>performance-metrics-throttle-container:</t> <t><list style='empty'> <t>Atarget="RFC7823" format="default"/>.</dd> <dt>performance-metrics-throttle-container:</dt> <dd>A YANG grouping that defines configurable thresholds for advertisement suppression and measurementintervals.</t> </list></t> <t>te-ds-class:</t> <t><list style='empty'> <t>Aintervals.</dd> <dt>te-ds-class:</dt> <dd>A type representing theDifferentiated-ServicesDifferentiated Services (DS) Class-Type of traffic as defined in <xreftarget="RFC4124"/>.</t> </list></t> <t>te-label-direction:</t> <t><list style='empty'> <t>Antarget="RFC4124" format="default"/>.</dd> <dt>te-label-direction:</dt> <dd>An enumerated type for specifying the forward or reverse direction of alabel.</t> </list></t> <t>te-hop-type:</t> <t><list style='empty'> <t>Anlabel.</dd> <dt>te-hop-type:</dt> <dd>An enumerated type for specifying that a hopasis loose orstrict.</t> </list></t> <t>te-global-id:</t> <t><list style='empty'> <t>Astrict.</dd> <dt>te-global-id:</dt> <dd>A type representing the identifier that uniquelyidentifyidentifies an operator, which can be either a provider or a client. The definition of this type is taken from <xref target="RFC6370"/> and <xref target="RFC5003"/>. This attribute type is used solely to provide a globally unique context for TEtopologies.</t> </list></t> <t>te-node-id:</t> <t><list style='empty'> <t>Atopologies.</dd> <dt>te-node-id:</dt> <dd>A type representing the identifier for a node in a TE topology. The identifier is represented as 4 octets in dotted-quad notation. This attributeMAY<bcp14>MAY</bcp14> be mapped to the Router Address TLV described inSection 2.4.1 of<xreftarget="RFC3630"/>,target="RFC3630" sectionFormat="of" section="2.4.1"/>, the TE Router ID described inSection 3 of<xreftarget="RFC6827"/>,target="RFC6827" sectionFormat="of" section="3"/>, the Traffic Engineering Router ID TLV described inSection 4.3 of<xreftarget="RFC5305"/>,target="RFC5305" sectionFormat="of" section="4.3"/>, or the TE Router ID TLV described inSection 3.2.1 of<xreftarget="RFC6119"/>.target="RFC6119" sectionFormat="of" section="3.2.1"/>. The reachability of such a TE nodeMAY<bcp14>MAY</bcp14> be achieved by a mechanism such asSection 6.2 ofthat described in <xreftarget="RFC6827"/>.</t> </list></t> <t>te-topology-id:</t> <t><list style='empty'> <t>Atarget="RFC6827" sectionFormat="of" section="6.2"/>.</dd> <dt>te-topology-id:</dt> <dd>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 bethe network-types,"network-types" as defined inietf-networkthe "ietf-network" module in <xreftarget="RFC8345"/>,target="RFC8345" format="default"/>, to help the usertobetter understand the topologybetterbefore furtherinquiry.</t> </list></t> <t>te-tp-id:</t> <t><list style='empty'> <t>Ainquiry is made.</dd> <dt>te-tp-id:</dt> <dd>A type representing the identifier of a TE interfacelink termination endpoint (TP)Link Termination Point (LTP) on a specific TE node where the TE link connects. This attribute is mapped to a local or remote link identifierin<xreftarget="RFC3630"/> andtarget="RFC3630" format="default"/> <xreftarget="RFC5305"/>.</t> </list></t> <t>te-path-disjointness:</t> <t><list style='empty'> <t>Atarget="RFC5305" format="default"/>.</dd> <dt>te-path-disjointness:</dt> <dd>A type representing the different resource disjointness options for a TE tunnel path as defined in <xreftarget="RFC4872"/>.</t> </list></t> <t>admin-groups:</t> <t><list style='empty'> <t>Atarget="RFC4872" format="default"/>.</dd> <dt>admin-groups:</dt> <dd>A union type for a TElink’slink's classic or extended administrative groups as defined in <xreftarget="RFC3630"/>target="RFC3630" format="default"/>, <xref target="RFC5305" format="default"/>, and <xreftarget="RFC5305"/>.</t> </list></t> <t>srlg:</t> <t><list style='empty'> <t>Atarget="RFC7308"/>. </dd> <dt>srlg:</dt> <dd>A type representing the Shared Risk Link Group (SRLG) as defined in <xreftarget="RFC4203"/>target="RFC4203" format="default"/> and <xreftarget="RFC5307"/>.</t> </list></t> <t>te-metric:</t> <t><list style='empty'> <t>Atarget="RFC5307" format="default"/>.</dd> <dt>te-metric:</dt> <dd>A type representing the TE metric as defined in <xreftarget="RFC3785"/>.</t> </list></t> <t>te-recovery-status:</t> <t><list style='empty'> <t>Antarget="RFC3785" format="default"/>.</dd> <dt>te-recovery-status:</dt> <dd>An enumerated type for the differentstatusstatuses of a recovery action as defined in <xreftarget="RFC4427"/>target="RFC4427" format="default"/> and <xreftarget="RFC6378"/>.</t> </list></t> <t>path-attribute-flags:</t> <t><list style='empty'> <t>Atarget="RFC6378" format="default"/>.</dd> <dt>path-attribute-flags:</dt> <dd>A base YANG identity for supported LSP path flags as defined in <xreftarget="RFC3209"/>,target="RFC3209" format="default"/>, <xreftarget="RFC4090"/>,target="RFC4090" format="default"/>, <xreftarget="RFC4736"/>,target="RFC4736" format="default"/>, <xreftarget="RFC5712"/>,target="RFC5712" format="default"/>, <xreftarget="RFC4920"/>,target="RFC4920" format="default"/>, <xreftarget="RFC5420"/>,target="RFC5420" format="default"/>, <xreftarget="RFC7570"/>,target="RFC7570" format="default"/>, <xreftarget="RFC4875"/>,target="RFC4875" format="default"/>, <xreftarget="RFC5151"/>,target="RFC5151" format="default"/>, <xreftarget="RFC5150"/>,target="RFC5150" format="default"/>, <xreftarget="RFC6001"/>,target="RFC6001" format="default"/>, <xreftarget="RFC6790"/>,target="RFC6790" format="default"/>, <xreftarget="RFC7260"/>,target="RFC7260" format="default"/>, <xreftarget="RFC8001"/>,target="RFC8001" format="default"/>, <xreftarget="RFC8149"/>,target="RFC8149" format="default"/>, and <xreftarget="RFC8169"/>.</t> </list></t> <t>link-protection-type:</t> <t><list style='empty'> <t>Atarget="RFC8169" format="default"/>.</dd> <dt>link-protection-type:</dt> <dd>A base YANG identity for supported link protection types as defined in <xreftarget="RFC4872"/>,target="RFC4872" format="default"/> and <xreftarget="RFC4427"/></t> </list></t> <t>restoration-scheme-type:</t> <t><list style='empty'> <t>Atarget="RFC4427" format="default"/>.</dd> <dt>restoration-scheme-type:</dt> <dd>A base YANG identity for supported LSP restoration schemes as defined in <xreftarget="RFC4872"/>.</t> </list></t> <t>protection-external-commands:</t> <t><list style='empty'> <t>Atarget="RFC4872" format="default"/>.</dd> <dt>protection-external-commands:</dt> <dd>A base YANG identity for supportedprotectionprotection-related external commands used fortrouble shooting purposestroubleshooting purposes, as defined in <xreftarget="RFC4427"/>.</t> </list></t> <t>association-type:</t> <t><list style='empty'> <t>Atarget="RFC4427" format="default"/>.</dd> <dt>association-type:</dt> <dd>A base YANG identity for supportedLabel Switched Path (LSP)LSP association types as defined in <xreftarget="RFC6780"/>,target="RFC6780" format="default"/>, <xreftarget="RFC4872"/>,target="RFC4872" format="default"/>, and <xreftarget="RFC4873"/>.</t> </list></t> <t>objective-function-type:</t> <t><list style='empty'> <t>Atarget="RFC4873" format="default"/>.</dd> <dt>objective-function-type:</dt> <dd>A base YANG identity for supported path computation objective functions as defined in <xreftarget="RFC5541"/>.</t> </list></t> <t>te-tunnel-type:</t> <t><list style='empty'> <t>Atarget="RFC5541" format="default"/>.</dd> <dt>te-tunnel-type:</dt> <dd>A base YANG identity for supported TE tunnel types as defined in <xreftarget="RFC3209"/>target="RFC3209" format="default"/> and <xreftarget="RFC4875"/>.</t> </list></t> <t>lsp-encoding-types:</t> <t><list style='empty'> <t>basetarget="RFC4875" format="default"/>.</dd> <dt>lsp-encoding-types:</dt> <dd>A base YANG identity for supported LSP encoding types as defined in <xreftarget="RFC3471"/>.</t> </list></t> <t>lsp-protection-type:</t> <t><list style='empty'> <t>Atarget="RFC3471" format="default"/>.</dd> <dt>lsp-protection-type:</dt> <dd>A base YANG identity for supported LSP protection types as defined in <xreftarget="RFC4872"/>target="RFC4872" format="default"/> and <xreftarget="RFC4873"/>.</t> </list></t> <t>switching-capabilities:</t> <t><list style='empty'> <t>Atarget="RFC4873" format="default"/>.</dd> <dt>switching-capabilities:</dt> <dd>A base YANG identity for supported interface switching capabilities as defined in <xreftarget="RFC3471"/>.</t> </list></t> <t>resource-affinities-type:</t> <t><list style='empty'> <t>Atarget="RFC3471" format="default"/>.</dd> <dt>resource-affinities-type:</dt> <dd>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 <xreftarget="RFC2702"/>target="RFC2702" format="default"/> and <xreftarget="RFC3209"/>.</t> </list></t> <t>path-metric-type:</t> <t><list style='empty'> <t>Atarget="RFC3209" format="default"/>.</dd> <dt>path-metric-type:</dt> <dd>A base YANG identity for supported path metric types as defined in <xreftarget="RFC3785"/>target="RFC3785" format="default"/> and <xreftarget="RFC7471"/>.</t> </list></t> <t>explicit-route-hop:</t> <t><list style='empty'> <t>Atarget="RFC7471" format="default"/>.</dd> <dt>explicit-route-hop:</dt> <dd>A YANG grouping that defines supported explicit routes as defined in <xreftarget="RFC3209"/>target="RFC3209" format="default"/> and <xreftarget="RFC3477"/>.</t> </list></t> <t>te-link-access-type:</t> <t><list style='empty'> <t>Antarget="RFC3477" format="default"/>.</dd> <dt>te-link-access-type:</dt> <dd>An enumerated type for the different TE link access types as defined in <xreftarget="RFC3630"/>.</t> </list></t>target="RFC3630" format="default"/>.</dd> </dl> </section> <section anchor="packet-te-types-module-contents"title="Packetnumbered="true" toc="default"> <name>Packet TE Types ModuleContents">Contents</name> <t>Theietf-te-packet-types"ietf-te-packet-types" module (<xref target="packet-te-types-yang-module"/>) covers the common types and groupings that are specific to packet technology.</t> <t>Theietf-te-packet-types"ietf-te-packet-types" module contains the following YANG reusable types and groupings:</t><t>backup-protection-type:</t> <t><list style='empty'> <t>A<dl newline="true" spacing="normal"> <dt>backup-protection-type:</dt> <dd>A base YANG identity for supported protection types that a backup or bypass tunnel can provide as defined in <xreftarget="RFC4090"/>.</t> </list></t> <t>te-class-type:</t> <t><list style='empty'> <t>Atarget="RFC4090" format="default"/>.</dd> <dt>te-class-type:</dt> <dd>A type that represents the Diffserv-TEclass-typeClass-Type as defined in <xreftarget="RFC4124"/>.</t> </list></t> <t>bc-type:</t> <t><list style='empty'> <t>Atarget="RFC4124" format="default"/>.</dd> <dt>bc-type:</dt> <dd>A type that representstheDiffserv-TE BandwidthConstraint (BC)Constraints (BCs) as defined in <xreftarget="RFC4124"/>.</t> </list></t> <t>bc-model-type:</t> <t><list style='empty'> <t>Atarget="RFC4124" format="default"/>.</dd> <dt>bc-model-type:</dt> <dd>A base YANG identity for supported Diffserv-TEbandwidth constraint modelsBandwidth Constraints Models as defined in <xreftarget="RFC4125"/>,target="RFC4125" format="default"/>, <xreftarget="RFC4126"/>target="RFC4126" format="default"/>, and <xreftarget="RFC4127"/>.</t> </list></t> <t>te-bandwidth-requested-type:</t> <t><list style='empty'> <t>Antarget="RFC4127" format="default"/>.</dd> <dt>te-bandwidth-requested-type:</dt> <dd>An enumerated type for the different options to request bandwidth for a specifictunnel.</t> </list></t> <t>performance-metrics-attributes-packet:</t> <t><list style='empty'> <t>Atunnel.</dd> <dt>performance-metrics-attributes-packet:</dt> <dd>A YANG grouping that contains the generic performance metrics and additionalpacket specific metrics.</t> </list></t>packet-specific metrics.</dd> </dl> </section> </section> <section anchor="te-types-yang-module"title="TEnumbered="true" toc="default"> <name>TE Types YANGModule">Module</name> <t>Theietf-te-types"ietf-te-types" module imports from the following modules:</t><t><list style="symbols"> <t>ietf-yang-types<ul spacing="normal"> <li>"ietf-yang-types" andietf-inet-types"ietf-inet-types" as defined in <xreftarget="RFC6991"/></t> <t>ietf-routing-typestarget="RFC6991" format="default"/></li> <li>"ietf-routing-types" as defined in <xreftarget="RFC8294"/></t> </list></t>target="RFC8294" format="default"/></li> </ul> <t>In addition tothe references cross-referenced in<xreftarget="te-types-contents"> </xref>,target="RFC6991"/> and <xref target="RFC8294"/>, thismodel alsomodule references the followingRFCsdocuments in defining the types and YANGgrouping of the YANG module: <xref target="RFC3272"/>,groupings: <xreftarget="RFC4202"/>,target="RFC3272" format="default"/>, <xreftarget="RFC4328"/>,target="RFC4090" format="default"/>, <xreftarget="RFC4657"/>,target="RFC4202" format="default"/>, <xreftarget="RFC5817"/>,target="RFC4328" format="default"/>, <xreftarget="RFC6004"/>,target="RFC4561" format="default"/>, <xreftarget="RFC6511"/>,target="RFC4657" format="default"/>, <xreftarget="RFC6205"/>,target="RFC5817" format="default"/>, <xreftarget="RFC7139"/>,target="RFC6004" format="default"/>, <xreftarget="RFC7308"/>,target="RFC6511" format="default"/>, <xreftarget="RFC7551"/>,target="RFC7139" format="default"/>, <xreftarget="RFC7571"/>,target="RFC7308" format="default"/>, <xreftarget="RFC7579"/>,target="RFC7551" format="default"/>, <xreftarget="RFC4090"/>,target="RFC7571" format="default"/>, <xreftarget="RFC4561"/>target="RFC7579" format="default"/>, and <xreftarget="RFC7951"/>, <xref target="G709"/>.</t> <figure title="TE basic types YANG module" anchor="fig-basic-types"><artwork><![CDATA[ <CODE BEGINS> file "ietf-te-types@2019-11-18.yang"target="G.709" format="default"/>.</t> <sourcecode name="ietf-te-types@2020-04-06.yang" type="yang" 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";te-types; import ietf-inet-types { prefix inet; reference"RFC6991:"RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix"yang";yang; reference"RFC6991:"RFC 6991: Common YANG Data Types"; } import ietf-routing-types { prefix"rt-types";rt-types; reference"RFC8294:"RFC 8294: 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/><https://datatracker.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>";<mailto:i_bryskin@yahoo.com>"; description "This YANG module contains a collection of generally usefulTE specificYANG data typedefinitions.definitions specific to TE. The model fully conforms to the Network Management Datastore Architecture (NMDA). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c)20182020 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 RFCXXXX;8776; 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"2020-04-06 { description "Latest revision of TEtypes";types."; reference "RFCXXXX: A8776: Common YANG DataModelTypes forCommonTrafficEngineering Types";Engineering"; } /** * Typedefs */ typedef admin-group { type yang:hex-string { /* 01:02:03:04 */ length "1..11"; } description "Administrativegroup/Resource class/Colorgroup / resource class / color representation inhex-string'hex-string' type. TheMost Significant Byte (MSB)most significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity."; reference"RFC3630 and RFC5305";"RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5305: IS-IS Extensions for Traffic Engineering RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } typedef admin-groups { type union { type admin-group; type extended-admin-group; } description"TE"Derived types for TE administrativegroup derived type";groups."; } typedef extended-admin-group { type yang:hex-string; description "Extended administrativegroup/Resource class/Colorgroup / resource class / color representation inhex-string'hex-string' type. TheMSBmost significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity."; reference"RFC7308";"RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } typedef path-attribute-flags { type union { type identityref { base session-attributes-flags; } type identityref { base lsp-attributes-flags; } } description "Path attributes flagstype";type."; } typedef performance-metrics-normality { type enumeration { enum"unknown"unknown { value 0; description "Unknown."; } enum"normal"normal { value 1; description "Normal. Indicates that the anomalous bit is notset";set."; } enum"abnormal"abnormal { value 2; description "Abnormal.IndicateIndicates that the anomalous bit is set."; } } description "Indicates whether a performance metric is normal (anomalous bit notset,set), abnormal (anomalous bit set), or unknown."; reference"RFC7471:"RFC 7471: OSPF Traffic Engineering (TE) MetricExtensions. RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. RFC7823:Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } typedef srlg { type uint32; description "SRLGtype";type."; reference"RFC4203 and RFC5307";"RFC 4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) RFC 5307: IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"; } typedef te-common-status { type enumeration { enum up { description "Enabled."; } enum down { description "Disabled."; } enum testing { description "In some test mode."; } enum preparing-maintenance { description"Resource"The resource is disabled in the control plane to prepare for a graceful shutdown for maintenance purposes."; reference"RFC5817:"RFC 5817: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks"; } enum maintenance { description"Resource"The resource is disabled in the data plane for maintenance purposes."; } enum unknown { description "Status isunknown";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 bandwidthtype thattype. It is a string containing a list of numbers separated by commas,withwhere each of thesenumbernumbers can be non-negative decimal, hex integer, or hex float: (dec | hex | float)[*(','(dec | hex | float))] Forpacket switchingthe packet-switching type, the string encoding follows the typebandwidth-ieee-float32'bandwidth-ieee-float32' as defined in RFC 8294(e.g.(e.g., 0x1p10), where the units are in bytes per second. ForOTNthe Optical Transport Network (OTN) switching type, a list of integers can be used, such as '0,2,3,1', indicating2 odu0'stwo ODU0s and1 odu3.one ODU3. ('ODU' stands for 'Optical Data Unit'.) ForDWDM,Dense Wavelength Division Multiplexing (DWDM), a list of pairs of slotnumbernumbers andwidthwidths 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 inhexhex, where the prefix '0x' precedes the hexnumber";number."; reference "RFC8294, G709";8294: Common YANG Data Types for the Routing Area ITU-T Recommendation G.709: Interfaces for the optical transport network"; }// te-bandwidthtypedef te-ds-class { type uint8 { range'0..7';"0..7"; } description "The Differentiated Services Class-Type of traffic."; reference"RFC4124: section-4.3.1";"RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering, Section 4.3.1"; } typedef te-global-id { type uint32; description "An identifier to uniquely identify an operator, which can be either a provider or a client. The definition of this type is taken fromRFC6370RFCs 6370 andRFC5003.5003. This attribute type is used solely to provide a globally unique context for TE topologies."; reference "RFC 5003: Attachment Individual Identifier (AII) Types for Aggregation RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers"; } typedef te-hop-type { type enumeration { enum loose { description"loose"A loose hop in an explicitpath";path."; } enum strict { description"strict"A strict hop in an explicitpath";path."; } } description"enumerated"Enumerated type for specifying loose or strictpaths";paths."; reference"RFC3209: section-4.3.2";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3.3"; } typedef te-link-access-type { type enumeration { enum point-to-point { description "The link is point-to-point."; } enum multi-access { description "The link is multi-access, including broadcast and NBMA."; } } description "Defines a type representing the access type of a TE link."; reference"RFC3630:"RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version2.";2"; } typedef te-label-direction { type enumeration { enum forward { description "Label allocated for the forward LSPdirection";direction."; } enum reverse { description "Label allocated for the reverse LSPdirection";direction."; } } description"enumerated"Enumerated type for specifying the forward or reverselabel";label."; } typedef te-link-direction { type enumeration { enum incoming { description"explicit"The explicit route represents an incoming link on anode";node."; } enum outgoing { description"explicit"The explicit route represents an outgoing link on anode";node."; } } description"enumerated"Enumerated type for specifying the direction of a link on anode";node."; } typedef te-metric { type uint32; description "TEmetric";metric."; reference"RFC3785";"RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric"; } 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 TLV described in Section 2.4.1 of[RFC3630],RFC 3630, the TE Router ID described in Section 3 of[RFC6827],RFC 6827, the Traffic Engineering Router ID TLV described in Section 4.3 of[RFC5305],RFC 5305, or the TE Router ID TLV described in Section 3.2.1 of[RFC6119].RFC 6119. The reachability of such a TE node MAY be achieved by a mechanism such as that described in Section 6.2 of[RFC6827]."; } typedef te-oper-status { type te-common-status;RFC 6827."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2, Section 2.4.1 RFC 5305: IS-IS Extensions for Traffic Engineering, Section 4.3 RFC 6119: IPv6 Traffic Engineering in IS-IS, Section 3.2.1 RFC 6827: Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols, Section 3"; } typedef te-oper-status { type te-common-status; description "Defines a type representing the operational status of a TE resource."; } typedef te-admin-status { type te-common-status; description "Defines a type representing the administrative status of a TE resource."; } typedef te-path-disjointness { type bits { bit node { position 0; description "Node disjoint."; } bit link { position 1; description "Link disjoint."; } bit srlg { position 2; description "SRLG (Shared Risk Link Group) disjoint."; } } description "Type of the resource disjointness for a TE tunnel path."; reference"RFC4872:"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; }// te-path-disjointnesstypedef te-recovery-status { type enumeration { enum normal { description "Both the recovery span and the workingspansspan 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 beenstarted,started but not completed."; } enum recovery-succeeded { description "The recovery action has succeeded. The working span has reported a failure/degradeconditioncondition, 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 isunavailable -- eitherunavailable, as a result of either anoperator Lockoutoperator's lockout command or a failure condition detected on the recovery span."; } enum recovery-admin { description "The operator has issued a commandswitchingto switch the user traffic to the recovery span."; } enum wait-to-restore { description "The recovery domain is recovering from a failure/degrade condition on the working span that is being controlled by the Wait-to-Restore (WTR) timer."; } } description "Defines the status of a recovery action."; reference"RFC4427:"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching(GMPLS). RFC6378:(GMPLS) RFC 6378: 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"add { value 0; description "A TE node orte-linkTE link has been added."; } enum"remove"remove { value 1; description "A TE node orte-linkTE link has been removed."; } enum"update"update { value 2; description "A TE node orte-linkTE link has been updated."; } } description "TEEventevent type fornotifications";notifications."; }// te-topology-event-typetypedef te-topology-id { type union { type string { length0;"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 bethe network-types,'network-types' as defined inietf-network.yang,the 'ietf-network' module in RFC 8345, to help the usertobetter understand the topologybetterbefore furtherinquiry.";inquiry is made."; reference"RFC8345";"RFC 8345: A YANG Data Model for Network Topologies"; } typedef te-tp-id { type union { type uint32; // Unnumbered type inet:ip-address; // IPv4 or IPv6 address } description "An identifier for a TE link endpoint on a node. This attribute is mapped to a local or remote link identifier as defined inRFC3630RFCs 3630 andRFC5305.";5305."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5305: IS-IS Extensions for Traffic Engineering"; } /* TE features */ feature p2mp-te { description "Indicates support forP2MP-TE";Point-to-Multipoint TE (P2MP-TE)."; reference"RFC4875";"RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"; } feature frr-te { description "Indicates support for TEFastReroute (FRR)";Fast Reroute (FRR)."; reference"RFC4090";"RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } feature extended-admin-groups { description "Indicates support for TE link extendedadminadministrative groups."; reference"RFC7308";"RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } feature named-path-affinities { description "Indicates support for named pathaffinities";affinities."; } feature named-extended-admin-groups { description "Indicates support for named extendedadmin groups";administrative groups."; } feature named-srlg-groups { description "Indicates support for named SRLGgroups";groups."; } feature named-path-constraints { description "Indicates support for named pathconstraints";constraints."; } feature path-optimization-metric { description "Indicates support for path optimizationmetric";metrics."; } feature path-optimization-objective-function { description "Indicates support for path optimization objectivefunction";functions."; } /* * Identities */ identity session-attributes-flags { description "Base identity for the RSVP-TE session attributesflags";flags."; } identity local-protection-desired { base session-attributes-flags; description"Fastreroute local"Local protection is desired."; reference"RFC3209";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.7.1"; } identity se-style-desired { base session-attributes-flags; description "Shared explicitstylestyle, to allow the LSP to be establishedsharingand share resources with the old LSP."; reference"RFC3209";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity local-recording-desired { base session-attributes-flags; description"Local"Label recordingdesired";is desired."; reference"RFC3209";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.7.1"; } identity bandwidth-protection-desired { base session-attributes-flags; description"Request"Requests FRR bandwidth protection onLSRsLSRs, if present."; reference"RFC4090";"RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } identity node-protection-desired { base session-attributes-flags; description"Request"Requests FRR node protection onLSRsLSRs, if present."; reference"RFC4090";"RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } identity path-reevaluation-request { base session-attributes-flags; description "This flag indicates that a path re-evaluation (of the current path in use) is requested. Note that this does not trigger any LSPReroutereroutes but instead just signals a request to evaluate whether a preferable path exists."; reference"RFC4736";"RFC 4736: Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)"; } identity soft-preemption-desired { base session-attributes-flags; description"Soft-preemption"Soft preemption of LSP resources isdesired";desired."; reference"RFC5712";"RFC 5712: MPLS Traffic Engineering Soft Preemption"; } identity lsp-attributes-flags { description "Base identity forper hop attribute flags";LSP attributes flags."; } identity end-to-end-rerouting-desired { base lsp-attributes-flags; description "Indicates end-to-endre-routingrerouting behavior for an LSPunderundergoing establishment. This MAY also be usedfor specifyingto specify 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"RFC 4920: Crankback Signaling Extensions foranMPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSPunder establishment. This MAYEstablishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity boundary-rerouting-desired { base lsp-attributes-flags; description "Indicates boundary rerouting behavior for an LSP undergoing establishment. This MAY also be usedfor specifying theto specify segment-based LSP recovery through nested crankback for established LSPs. The boundaryABR/ASBRArea Border Router (ABR) / Autonomous System Border Router (ASBR) caneitherdecide to forward the PathErr message upstream to either an upstream boundary ABR/ASBR ortothe ingress LSR. Alternatively, it can try to select another egress boundary LSR."; reference"RFC4920, RFC5420, RFC7570";"RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity segment-based-rerouting-desired { base lsp-attributes-flags; description "Indicates segment-basedre-routingrerouting behavior for an LSPunderundergoing establishment. This MAY also be used to specifythe segment- basedsegment-based LSP recovery for established LSPs."; reference"RFC4920, RFC5420, RFC7570";"RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity lsp-integrity-required { base lsp-attributes-flags; description "Indicates that LSP integrity isrequired";required."; reference"RFC4875, RFC7570";"RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity contiguous-lsp-desired { base lsp-attributes-flags; description "Indicates that a contiguous LSP isdesired";desired."; reference"RFC5151, RFC7570";"RFC 5151: Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity lsp-stitching-desired { base lsp-attributes-flags; description "Indicates that LSP stitching isdesired";desired."; reference"RFC5150, RFC7570";"RFC 5150: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity pre-planned-lsp-flag { base lsp-attributes-flags; description "Indicates that the LSP MUST be provisioned in the control plane only."; reference"RFC6001, RFC7570";"RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity non-php-behavior-flag { base lsp-attributes-flags; description "Indicatesnon-phpthat non-PHP (non-Penultimate Hop Popping) behavior for the LSP isdesired"; 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))";desired."; reference"RFC6511, RFC7570"; }"RFC 6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity oob-mapping-flag { base lsp-attributes-flags; description "Indicates that signaling of the egress binding information is out of band (e.g., via the Border Gateway Protocol (BGP))."; reference "RFC 6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity entropy-label-capability { base lsp-attributes-flags; description "Indicates entropy labelcapability";capability."; reference"RFC6790, RFC7570";"RFC 6790: The Use of Entropy Labels in MPLS Forwarding RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity oam-mep-entity-desired { base lsp-attributes-flags; description "OAM Maintenance Entity Group End Point (MEP) entitiesdesired";desired."; reference"RFC7260";"RFC 7260: GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration"; } identity oam-mip-entity-desired { base lsp-attributes-flags; description "OAM Maintenance Entity Group Intermediate Points (MIP) entitiesdesired";desired."; reference"RFC7260";"RFC 7260: GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration"; } identity srlg-collection-desired { base lsp-attributes-flags; description "SRLG collectiondesired";desired."; reference"RFC8001, RFC7570";"RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) RFC 8001: RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information"; } identity loopback-desired { base lsp-attributes-flags; description "This flag indicates that a particular node on the LSP is required to enter loopback mode. This can also be usedfor specifyingto specify the loopback state of the node."; reference"RFC7571";"RFC 7571: GMPLS RSVP-TE Extensions for Lock Instruct and Loopback"; } identity p2mp-te-tree-eval-request { base lsp-attributes-flags; description "P2MP-TE tree re-evaluationrequest";request."; reference"RFC8149";"RFC 8149: RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)"; } identity rtm-set-desired { base lsp-attributes-flags; description "Residence Time Measurement (RTM) attribute flagrequested";requested."; reference"RFC8169";"RFC 8169: Residence Time Measurement in MPLS Networks"; } identity link-protection-type { description "Base identity for the link protection type."; } identity link-protection-unprotected { base link-protection-type; description "Unprotected linktype";type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity link-protection-extra-traffic { base link-protection-type; description"Extra-traffic"Extra-Traffic protected linktype";type."; reference"RFC4427.";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity link-protection-shared { base link-protection-type; description "Shared protected linktype";type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity link-protection-1-for-1 { base link-protection-type; description"One for one"One-for-one (1:1) protected linktype";type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity link-protection-1-plus-1 { base link-protection-type; description"One plus one"One-plus-one (1+1) protected linktype";type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity link-protection-enhanced { base link-protection-type; description"Enhanced protection protected"A compound linktype"; reference "RFC4872"; } identity association-type { description "Base identity for tunnel association"; }protection type derived from the underlay TE tunnel protection configuration supporting the TE link."; } identity association-type { description "Base identity for the tunnel association."; } identity association-type-recovery { base association-type; description "AssociationType Recoverytype for recovery, used to associate LSPs of the same tunnel forrecovery";recovery."; reference"RFC6780, RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery RFC 6780: RSVP ASSOCIATION Object Extensions"; } identity association-type-resource-sharing { base association-type; description "AssociationType Resource Sharingtype for resource sharing, used to enable resource sharing during make-before-break."; reference"RFC6780, RFC4873";"RFC 4873: GMPLS Segment Recovery RFC 6780: RSVP ASSOCIATION Object Extensions"; } identity association-type-double-sided-bidir { base association-type; description "AssociationType Double Sidedtype for double-sided bidirectional LSPs, used to associate two LSPs of two tunnels that are independently configured on eitherendpoint";endpoint."; reference"RFC7551";"RFC 7551: RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"; } identity association-type-single-sided-bidir { base association-type; description "AssociationType Single Sidedtype for single-sided bidirectional LSPs, used to associate two LSPs of two tunnels, whereaone tunnel is configured on oneside/endpoint,side/endpoint and the other tunnel is dynamically created on the otherendpoint";endpoint."; reference"RFC6780,RFC7551";"RFC 6780: RSVP ASSOCIATION Object Extensions RFC 7551: RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"; } identity objective-function-type { description "Base objective functiontype";type."; } identity of-minimize-cost-path { base objective-function-type; description"Minimize cost of"Objective function for minimizing pathobjective function";cost."; reference"RFC5541";"RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-load-path { base objective-function-type; description"Minimize"Objective function for minimizing the load onpath(s) objective function";one or more paths."; reference"RFC5541";"RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-maximize-residual-bandwidth { base objective-function-type; description"Maximize the"Objective function for maximizing residualbandwidth objective function";bandwidth."; reference"RFC5541";"RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-agg-bandwidth-consumption { base objective-function-type; description"minimize the"Objective function for minimizing aggregate bandwidthconsumption objective function";consumption."; reference"RFC5541";"RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-load-most-loaded-link { base objective-function-type; description"Minimize"Objective function for minimizing the load on themost loadedlinkobjective function";that is carrying the highest load."; reference"RFC5541";"RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-cost-path-set { base objective-function-type; description"Minimize"Objective function for minimizing the cost on a pathset objective function";set."; reference"RFC5541";"RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity path-computation-method { description"base"Base identity for supported path computationmechanisms";mechanisms."; } identity path-locally-computed { base path-computation-method; description"indicates"Indicates a constrained-path LSP in which the path is computed by the localLER";LER."; reference"RFC3272 section"RFC 3272: Overview and Principles of Internet Traffic Engineering, 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";"RFC 3272: Overview and Principles of Internet Traffic Engineering RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity path-explicitly-defined { base path-computation-method; description"constrained-path"Constrained-path LSP in which the path is explicitly specified as a collection of strictor/andand/or loosehops";hops."; reference"RFC3209"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 3272: Overview andRFC3272";Principles of Internet Traffic Engineering"; } identity lsp-metric-type { description "Base identity fortypes ofthe LSP metricspecification";specification types."; } identity lsp-metric-relative { base lsp-metric-type; description "The metric specified for the LSPs to which this identity refers is specified as arelativevalue relative to the IGP metric cost to the LSP'stail-end.";tail end."; reference"RFC4657"; } identity lsp-metric-absolute { base lsp-metric-type;"RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity lsp-metric-absolute { base lsp-metric-type; description "The metric specified for the LSPs to which this identity refers is specified as an absolutevalue";value."; reference"RFC4657";"RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity lsp-metric-inherited { base lsp-metric-type; description "The metric for the LSPs to which this identity refers is not specifiedexplicitly - but ratherexplicitly; rather, it is directly inherited from the IGPcost directly";cost."; reference"RFC4657";"RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity te-tunnel-type { description "Base identity from which specific tunnel types are derived."; } identity te-tunnel-p2p { base te-tunnel-type; description "TEpoint-to-pointPoint-to-Point (P2P) tunnel type."; reference"RFC3209";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity te-tunnel-p2mp { base te-tunnel-type; description "TEpoint-to-multipointP2MP tunnel type."; reference"RFC4875";"RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"; } identity tunnel-action-type { description "Base identity from which specific tunnel action types are derived."; } identity tunnel-action-resetup { base tunnel-action-type; description "TE tunnel actionresetup. Tearsthat tears down the tunnel's current LSP (if any) and attempts to re-establish a newLSP";LSP."; } identity tunnel-action-reoptimize { base tunnel-action-type; description "TE tunnel actionreoptimize. Reoptimizesthat reoptimizes the placement of the tunnelLSP(s)";LSP(s)."; } identity tunnel-action-switchpath { base tunnel-action-type; description "TE tunnel actionswitchpath Switchesthat switches the tunnel's LSP to use the specifiedpath";path."; } identity te-action-result { description "Base identity from which specific TE action results are derived."; } identity te-action-success { base te-action-result; description "TE action was successful."; } identity te-action-fail { base te-action-result; description "TE action failed."; } identity tunnel-action-inprogress { base te-action-result; description "TE actioninprogress.";is in progress."; } identity tunnel-admin-state-type { description "Base identity for TE tunneladmin states";administrative states."; } identity tunnel-admin-state-up { base tunnel-admin-state-type; description"Tunnel administratively"Tunnel's administrative stateup";is up."; } identity tunnel-admin-state-down { base tunnel-admin-state-type; description"Tunnel administratively"Tunnel's administrative statedown";is down."; } identity tunnel-state-type { description "Base identity for TE tunnelstates";states."; } identity tunnel-state-up { base tunnel-state-type; description"Tunnel"Tunnel's stateup";is up."; } identity tunnel-state-down { base tunnel-state-type; description"Tunnel"Tunnel's statedown";is down."; } identity lsp-state-type { description "Base identity for TE LSPstates";states."; } identity lsp-path-computing { base lsp-state-type; description "State pathcomputecomputation is inprogress";progress."; } identity lsp-path-computation-ok { base lsp-state-type; description "State pathcompute successful";computation was successful."; } identity lsp-path-computation-failed { base lsp-state-type; description "State pathcompute failed";computation failed."; } identity lsp-state-setting-up { base lsp-state-type; description "Statesetting up";is being set up."; } identity lsp-state-setup-ok { base lsp-state-type; description "State setupsuccessful";was successful."; } identity lsp-state-setup-failed { base lsp-state-type; description "State setupfailed";failed."; } identity lsp-state-up { base lsp-state-type; description "Stateup";is up."; } identity lsp-state-tearing-down { base lsp-state-type; description "Statetearing down";is being torn down."; } identity lsp-state-down { base lsp-state-type; description "Statedown";is down."; } identity path-invalidation-action-type { description "Base identity for TE path invalidation actiontypes";types."; } identity path-invalidation-action-drop { base path-invalidation-action-type; description"TE path"Upon invalidationaction to drop";of the TE tunnel path, the tunnel remains valid, but any packet mapped over the tunnel is dropped."; reference"RFC3209 section"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 2.5"; } identity path-invalidation-action-teardown { base path-invalidation-action-type; description "TE path invalidation actionteardown";teardown."; reference"RFC3209 section"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 2.5"; } identity lsp-restoration-type { description "Base identity from which LSP restoration types are derived."; } identity lsp-restoration-restore-any { base lsp-restoration-type; description"Restores when any of the LSPs is"Any LSP affected by afailure";failure is restored."; } identity lsp-restoration-restore-all { base lsp-restoration-type; description"Restores when"Affected LSPs are restored after all LSPs of the tunnelLSPsareaffected by failure";broken."; } identity restoration-scheme-type { description "Base identity for LSP restorationschemes";schemes."; } identity restoration-scheme-preconfigured { base restoration-scheme-type; description "Restoration LSP is preconfigured prior to thefailure";failure."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity restoration-scheme-precomputed { base restoration-scheme-type; description "Restoration LSP is precomputed prior to thefailure";failure."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity restoration-scheme-presignaled { base restoration-scheme-type; description "Restoration LSP is presignaled prior to thefailure";failure."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity lsp-protection-type { description "Base identity from which LSP protection types are derived."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-unprotected { base lsp-protection-type; description"LSP"'Unprotected' LSP protection'Unprotected'";type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-reroute-extra { base lsp-protection-type; description"LSP"'(Full) Rerouting' LSP protection'(Full) Rerouting'";type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-reroute { base lsp-protection-type; description"LSP protection 'Rerouting"'Rerouting withoutExtra-Traffic'";Extra-Traffic' LSP protection type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-1-for-n { base lsp-protection-type; description"LSP protection '1:N"'1:N Protection withExtra-Traffic'";Extra-Traffic' LSP protection type."; reference"RFC4872"; } identity lsp-protection-unidir-1-for-1 { base lsp-protection-type; description "LSP protection '1:1 Unidirectional Protection'"; reference "RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identitylsp-protection-bidir-1-for-1lsp-protection-1-for-1 { base lsp-protection-type; description "LSP protection '1:1Bidirectional Protection'";Protection Type'."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-unidir-1-plus-1 { base lsp-protection-type; description"LSP protection '1+1"'1+1 UnidirectionalProtection'";Protection' LSP protection type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-bidir-1-plus-1 { base lsp-protection-type; description"LSP protection '1+1"'1+1 BidirectionalProtection'";Protection' LSP protection type."; reference"RFC4872";"RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-extra-traffic { base lsp-protection-type; description"LSP"Extra-Traffic LSP protection'Extra-Traffic'";type."; reference"RFC4427.";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } 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"The protection transport entitywhichhas a signal fail condition that is of higher priority than the forcedswitchswitchover command."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity lockout-of-protection { base lsp-protection-state; description "A Loss of Protection (LoP) command is active."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity forced-switch { base lsp-protection-state; description "A forcedswitchswitchover command is active."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity signal-fail { base lsp-protection-state; description "There is a signal fail condition on either the working path or the protection path."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity signal-degrade { base lsp-protection-state; description "There isana signal degrade condition on either the working path or the protection path."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity manual-switch { base lsp-protection-state; description "A manualswitchswitchover command is active."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity wait-to-restore { base lsp-protection-state; description "Await time to restore (WTR)WTR timer is running."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity do-not-revert { base lsp-protection-state; description "ADNRDo Not Revert (DNR) condition is active because ofanon-revertive behavior."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity failure-of-protocol { base lsp-protection-state; description"The"LSP protection is not working because of afailure ofprotocol failure condition."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity protection-external-commands { description "Base identity from whichprotectionprotection-related external commands used fortrouble shootingtroubleshooting purposes are derived."; } identity action-freeze { base protection-external-commands; description "A temporary configuration action initiated by an operator commandto preventthat prevents anyswitchswitchover actionto befrom being takenandand, assuchsuch, freezes the current state."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity clear-freeze { base protection-external-commands; description "An action that clears the active freeze state."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-lockout-of-normal { base protection-external-commands; description "A temporary configuration action initiated by an operator command to ensure that the normal traffic is not allowed to use the protection transport entity."; reference"RFC4427"; } identity"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity clear-lockout-of-normal { base protection-external-commands; description "An action that clears the active lockout of the normal state."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-lockout-of-protection { base protection-external-commands; description "A temporary configuration action initiated by an operator command to ensure that the protection transport entity is temporarily not available to transport a traffic signal (either normal orextra traffic).";Extra-Traffic)."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-forced-switch { base protection-external-commands; description "Aswitchswitchover action initiated by an operator command to switch theextra trafficExtra-Traffic signal, the normal traffic signal, or the null signal to the protection transport entity, unlessana switchover command of equal or higher priorityswitch commandis in effect."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-manual-switch { base protection-external-commands; description "Aswitchswitchover action initiated by an operator command to switch theextra trafficExtra-Traffic signal, the normal traffic signal, or the null signal to the protection transport entity, unless a fault condition exists on other transport entities orana switchover command of equal or higher priorityswitch commandis in effect."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-exercise { base protection-external-commands; description "An actionto startthat starts testingif thewhether or not APS communication is operating correctly. It is of lower priority than any other state or command."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity clear { base protection-external-commands; description "An action that clears the active near-end lockout of a protection, forcedswitch,switchover, manualswitch,switchover, WTR state, or exercise command."; reference"RFC4427";"RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity switching-capabilities { description "Base identity for interface switchingcapabilities";capabilities."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-psc1 { base switching-capabilities; description "Packet-Switch Capable-1(PSC-1)";(PSC-1)."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-evpl { base switching-capabilities; description "Ethernet Virtual Private Line(EVPL)";(EVPL)."; reference"RFC6004";"RFC 6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching"; } identity switching-l2sc { base switching-capabilities; description "Layer-2 Switch Capable(L2SC)";(L2SC)."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-tdm { base switching-capabilities; description "Time-Division-Multiplex Capable(TDM)";(TDM)."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-otn { base switching-capabilities; description "OTN-TDMcapable";capable."; reference"RFC7138";"RFC 7138: Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks"; } identity switching-dcsc { base switching-capabilities; description "Data Channel Switching Capable(DCSC)";(DCSC)."; reference"RFC6002";"RFC 6002: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions"; } identity switching-lsc { base switching-capabilities; description "Lambda-Switch Capable(LSC)";(LSC)."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-fsc { base switching-capabilities; description "Fiber-Switch Capable(FSC)";(FSC)."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-types { description "Base identity for encodingtypes";types."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-packet { base lsp-encoding-types; description "Packet LSPencoding";encoding."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-ethernet { base lsp-encoding-types; description "Ethernet LSPencoding";encoding."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-pdh { base lsp-encoding-types; description "ANSI/ETSI PDH LSPencoding";encoding."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-sdh { base lsp-encoding-types; description "SDH ITU-T G.707 / SONET ANSI T1.105 LSPencoding";encoding."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-digital-wrapper { base lsp-encoding-types; description "Digital Wrapper LSPencoding";encoding."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-lambda { base lsp-encoding-types; description "Lambda (photonic) LSPencoding";encoding."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-fiber { base lsp-encoding-types; description "Fiber LSPencoding";encoding."; reference"RFC3471"; } identity lsp-encoding-fiber-channel { base lsp-encoding-types; description "Fiber Channel"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-fiber-channel { base lsp-encoding-types; description "FiberChannel LSPencoding";encoding."; reference"RFC3471";"RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-oduk { base lsp-encoding-types; description "G.709 ODUk (Digital Path) LSPencoding";encoding."; reference"RFC4328";"RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control"; } identity lsp-encoding-optical-channel { base lsp-encoding-types; description "G.709 Optical Channel LSPencoding";encoding."; reference"RFC4328";"RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control"; } identity lsp-encoding-line { base lsp-encoding-types; description "Line (e.g., 8B/10B) LSPencoding";encoding."; reference"RFC6004";"RFC 6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching"; } identity path-signaling-type { description"base"Base identity from which specificLSPsLSP path setup types arederived";derived."; } identity path-setup-static { base path-signaling-type; description "Static LSP provisioning pathsetup";setup."; } identity path-setup-rsvp { base path-signaling-type; description "RSVP-TE signaling pathsetup";setup."; reference"RFC3209";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity path-setup-sr { base path-signaling-type; description "Segment-routing pathsetup";setup."; } identity path-scope-type { description"base"Base identity from which specific path scope types arederived";derived."; } identity path-scope-segment { base path-scope-type; description "Path scopesegment";segment."; reference"RFC4873";"RFC 4873: GMPLS Segment Recovery"; } identity path-scope-end-to-end { base path-scope-type; description "Path scope end toend";end."; reference"RFC4873";"RFC 4873: GMPLS Segment Recovery"; } identity route-usage-type { description "Base identity for routeusage";usage."; } identity route-include-object { base route-usage-type; description"Include route object";"'Include route' object."; } identity route-exclude-object { base route-usage-type; description"Exclude route object";"'Exclude route' object."; reference"RFC4874";"RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"; } identity route-exclude-srlg { base route-usage-type; description"Exclude SRLG";"Excludes SRLGs."; reference"RFC4874";"RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"; } identity path-metric-type { description "Base identity for the path metrictype";type."; } identity path-metric-te { base path-metric-type; description "TE pathmetric";metric."; reference"RFC3785";"RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric"; } identity path-metric-igp { base path-metric-type; description "IGP pathmetric";metric."; reference"RFC3785";"RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric"; } identity path-metric-hop { base path-metric-type; description "Hop pathmetric";metric."; } identity path-metric-delay-average { base path-metric-type; description"Unidirectional average"Average unidirectional linkdelay";delay."; reference"RFC7471";"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; } identity path-metric-delay-minimum { base path-metric-type; description"Unidirectional minimum"Minimum unidirectional linkdelay";delay."; reference"RFC7471";"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; } identity path-metric-residual-bandwidth { base path-metric-type; description "Unidirectional Residual Bandwidth, which is defined to be Maximum Bandwidth[RFC3630](RFC 3630) minus the bandwidth currently allocated to LSPs."; reference"RFC7471";"RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions"; } identity path-metric-optimize-includes { base path-metric-type; description "A metric that optimizes the number of included resources specified in aset";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 aset";set."; } identity path-tiebreaker-type { description "Base identity for the pathtie-breaker type";tiebreaker type."; } identity path-tiebreaker-minfill { base path-tiebreaker-type; description "Min-Fill LSP pathplacement";placement."; } identity path-tiebreaker-maxfill { base path-tiebreaker-type; description "Max-Fill LSP pathplacement";placement."; } identity path-tiebreaker-random { base path-tiebreaker-type; description "Random LSP pathplacement";placement."; } identity resource-affinities-type { description "Base identity for resourceaffinities";class affinities."; reference"RFC2702";"RFC 2702: Requirements for Traffic Engineering Over MPLS"; } identity resource-aff-include-all { base resource-affinities-type; description "The set of attribute filters associated with atunneltunnel, all of which must be present for a link to beacceptable";acceptable."; reference"RFC2702 and RFC3209";"RFC 2702: Requirements for Traffic Engineering Over MPLS RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity resource-aff-include-any { base resource-affinities-type; description "The set of attribute filters associated with atunneltunnel, any of which must be present for a link to beacceptable";acceptable."; reference"RFC2702 and RFC3209";"RFC 2702: Requirements for Traffic Engineering Over MPLS RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity resource-aff-exclude-any { base resource-affinities-type; description "The set of attribute filters associated with atunneltunnel, any of which renders a linkunacceptable";unacceptable."; reference"RFC2702 and RFC3209";"RFC 2702: Requirements for Traffic Engineering Over MPLS RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity te-optimization-criterion { description "Base identity for the TE optimizationcriterion.";criteria."; reference"RFC3272:"RFC 3272: Overview and Principles of Internet TrafficEngineering.";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";"RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity delay { base te-optimization-criterion; description "Optimized on delay."; reference"RFC5541";"RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity path-computation-srlg-type { description "Base identity for SRLG pathcomputation";computation."; } identity srlg-ignore { base path-computation-srlg-type; description "Ignores SRLGs in the pathcomputation";computation."; } identity srlg-strict { base path-computation-srlg-type; description"Include"Includes a strict SRLG check in the pathcomputation";computation."; } identity srlg-preferred { base path-computation-srlg-type; description"Include"Includes a preferred SRLG check in the pathcomputation";computation."; } identity srlg-weighted { base path-computation-srlg-type; description"Include"Includes a weighted SRLG check in the pathcomputation";computation."; } /** * TE bandwidth groupings **/ grouping te-bandwidth { description "This grouping defines the generic TE bandwidth. For some knowndata planedata-plane technologies, specific modeling structures are specified. Thestring encoded te-bandwidthstring-encoded 'te-bandwidth' type is used forun-specifiedunspecified 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 specificdataplanedata-plane technologies."; choice technology { defaultgeneric;"generic"; description"Data plane"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. Forun-specifiedunspecified technologies,rt-types:generalized-label'rt-types:generalized-label' is used."; container te-label { description "Container that specifies the TE label. The choices can be augmented for specificdataplanedata-plane technologies."; choice technology { defaultgeneric;"generic"; description"Data plane"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';"forward"; description "Labeldirection";direction."; } } } grouping te-topology-identifier { description "Augmentation for a TE topology."; container te-topology-identifier { description "TE topology identifiercontainer";container."; leaf provider-id { type te-global-id; default0;"0"; description "An identifier to uniquely identify a provider. If omitted, it assumes that thedefaulttopology providerID=0";ID value = 0 (the default)."; } leaf client-id { type te-global-id; default0;"0"; description "An identifier to uniquely identify a client. If omitted, it assumes that thedefaulttopology clientID=0";ID value = 0 (the default)."; } leaf topology-id { type te-topology-id; default'';""; description "When the datastore contains several topologies,the topology-id'topology-id' distinguishes between them. If omitted, the defaultempty(empty) stringtopology-idfor this leaf isassumed";assumed."; } } } /** * TE performancemetricmetrics groupings **/ grouping performance-metrics-one-way-delay-loss { description "PerformanceMetricMetrics (PM) information in real time that can be applicable to links or connections. PM defined in this groupingisare applicable to generic TEperformance metricsPM as well as packet TEperformance metrics.";PM."; reference"RFC7471:"RFC 7471: OSPF Traffic Engineering (TE) MetricExtensions. RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. RFC7823:Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; leaf one-way-delay { type uint32 { range'0..16777215';"0..16777215"; } description "One-way delay or latency inmicro seconds.";microseconds."; } 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"PM information in real time that can be applicable to links or connections. PM defined in this groupingisare applicable to generic TEperformance metricsPM as well as packet TEperformance metrics.";PM."; reference"RFC7471:"RFC 7471: OSPF Traffic Engineering (TE) MetricExtensions. RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. RFC7823:Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; leaf two-way-delay { type uint32 { range'0..16777215';"0..16777215"; } description "Two-way delay or latency inmicro seconds.";microseconds."; } 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"PM information in real time that can be applicable to links. PM defined in this groupingisare applicable to generic TEperformance metricsPM as well as packet TEperformance metrics.";PM."; reference"RFC7471:"RFC 7471: OSPF Traffic Engineering (TE) MetricExtensions. RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. RFC7823:Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; leaf one-way-residual-bandwidth { type rt-types:bandwidth-ieee-float32; units'bytes"bytes persecond';second"; default'0x0p0';"0x0p0"; description "Residual bandwidth that subtracts tunnel reservations from Maximum Bandwidth (or link capacity)[RFC3630](RFC 3630) and provides an aggregated remainder across QoS classes."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2"; } leaf one-way-residual-bandwidth-normality { type te-types:performance-metrics-normality; default'normal';"normal"; description "Residual bandwidth normality."; } leaf one-way-available-bandwidth { type rt-types:bandwidth-ieee-float32; units'bytes"bytes persecond';second"; default'0x0p0';"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';"normal"; description "Available bandwidth normality."; } leaf one-way-utilized-bandwidth { type rt-types:bandwidth-ieee-float32; units'bytes"bytes persecond';second"; default'0x0p0';"0x0p0"; description "Bandwidth utilization that represents the actual utilization of the link(i.e.(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';"normal"; description "Bandwidth utilization normality."; } } grouping one-way-performance-metrics { description "One-wayperformance metricsPM throttle grouping."; leaf one-way-delay { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "One-way delay or latency inmicro seconds.";microseconds."; } leaf one-way-residual-bandwidth { type rt-types:bandwidth-ieee-float32; units'bytes"bytes persecond';second"; default'0x0p0';"0x0p0"; description "Residual bandwidth that subtracts tunnel reservations from Maximum Bandwidth (or link capacity)[RFC3630](RFC 3630) and provides an aggregated remainder across QoS classes."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2"; } leaf one-way-available-bandwidth { type rt-types:bandwidth-ieee-float32; units'bytes"bytes persecond';second"; default'0x0p0';"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"bytes persecond';second"; default'0x0p0';"0x0p0"; description "Bandwidth utilization that represents the actual utilization of the link(i.e.(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-wayperformance metricsPM throttle grouping."; leaf two-way-delay { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "Two-way delay or latency inmicro seconds.";microseconds."; } } grouping performance-metrics-thresholds { description "Grouping for configurable thresholds for measuredattributes";attributes."; uses one-way-performance-metrics; uses two-way-performance-metrics; } grouping performance-metrics-attributes { description"A container containing performance metric"Contains PM attributes."; container performance-metrics-one-way { description "One-way link performance information in real time."; reference"RFC7471:"RFC 7471: OSPF Traffic Engineering (TE) MetricExtensions. RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. RFC7823:Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; 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"RFC 6374: Packet Loss and Delay Measurement forExplicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions";MPLS Networks"; uses performance-metrics-two-way-delay-loss; } } grouping performance-metrics-throttle-container { description"A container controlling performance metric throttle.";"Controls PM throttling."; container throttle { must"suppression-interval'suppression-interval >=measure-interval"measure-interval' { error-message"suppression-interval"'suppression-interval' cannot be lessthen measure-interval.";than " + "'measure-interval'."; description "Constraint onsuppression-interval'suppression-interval' andmeasure-interval.";'measure-interval'."; } description "Link performance information in real time."; reference"RFC7471:"RFC 7471: OSPF Traffic Engineering (TE) MetricExtensions. RFC8570: IS-IS Traffic Engineering (TE) Metric Extensions. RFC7823:Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; leaf one-way-delay-offset { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "Offset value to be added to the measured delay value."; } leaf measure-interval { type uint32; default30;"30"; description"Interval"Interval, insecondsseconds, to measure the extended metric values."; } leaf advertisement-interval { type uint32; default0;"0"; description"Interval"Interval, insecondsseconds, to advertise the extended metric values."; } leaf suppression-interval { type uint32 { range'1 .. max';"1..max"; } default120;"120"; description"Interval"Interval, insecondsseconds, to suppressadvertisingadvertisement of the extended metric values."; reference "RFC7810, Section-6";8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 6"; } container threshold-out { uses performance-metrics-thresholds; description "If the measured parameter falls outside an upper bound for all but themin delayminimum-delay metric (or a lower bound formin-delaythe minimum-delay metric only) and the advertised value is not already outside that bound,anomalousan 'anomalous' announcement (anomalous bit set) will be triggered."; } container threshold-in { uses performance-metrics-thresholds; description "If the measured parameter falls inside an upper bound for all but themin delayminimum-delay metric (or a lower bound formin-delaythe minimum-delay metric only) and the advertised value is not already inside that bound,normal (anomalous-flag cleared)a 'normal' announcement (anomalous bit cleared) will be triggered."; } container threshold-accelerated-advertisement { description "When the difference between the last advertised value and the current measured valueexceedexceeds this threshold,anomalousan 'anomalous' announcement (anomalous bit set) will be triggered."; uses performance-metrics-thresholds; } } }// performance-metrics-throttle-container/** * TE tunnel generic groupings **/ grouping explicit-route-hop { description "The explicit route entrygrouping";grouping."; choice type { description "The explicit route entrytype";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';"strict"; description"strict"Strict or loosehop";hop."; } description "Numbered node routehop";hop."; reference"RFC3209: section 4.3"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TERFC3477:RFC 3477: Signalling Unnumbered Links inRSVP-TE";Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; } } case numbered-link-hop { container numbered-link-hop { leaf link-tp-id { type te-tp-id; mandatory true; description "TElink termination pointLink Termination Point (LTP) identifier."; } leaf hop-type { type te-hop-type; default'strict';"strict"; description"strict"Strict or loosehop";hop."; } leaf direction { type te-link-direction; default'outgoing';"outgoing"; description "Link route objectdirection";direction."; } description "Numbered link explicit routehop";hop."; reference"RFC3209: section 4.3"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TERFC3477:RFC 3477: Signalling Unnumbered Links inRSVP-TE";Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; } } case unnumbered-link-hop { container unnumbered-link-hop { leaf link-tp-id { type te-tp-id; mandatory true; description "TElink termination pointLTP identifier. The combination of the 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';"strict"; description"strict"Strict or loosehop";hop."; } leaf direction { type te-link-direction; default'outgoing';"outgoing"; description "Link route objectdirection";direction."; } description "Unnumbered link explicit routehop";hop."; reference"RFC3209: section 4.3"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TERFC3477:RFC 3477: Signalling Unnumbered Links inRSVP-TE";Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; } } case as-number { container as-number-hop { leaf as-number { type inet:as-number; mandatory true; description "TheAS number";Autonomous System (AS) number."; } leaf hop-type { type te-hop-type; default'strict';"strict"; description"strict"Strict or loosehop";hop."; } description"Autonomous System"AS explicit routehop";hop."; } } case label { container label-hop { description "Label hoptype";type."; uses te-label; } description "The label explicit route hoptype";type."; } } } grouping record-route-state { description "Therecord route grouping";Record Route grouping."; leaf index { type uint32; description "RecordrouteRoute 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 keyvalues";values."; } choice type { description "Therecord routeRecord Route entrytype";type."; case numbered-node-hop { container numbered-node-hop { description "Numbered node route hopcontainer";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";"Path attributes flags."; reference"RFC3209, RFC4090, RFC4561";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } description "Numbered node routehop";hop."; } case numbered-link-hop { container numbered-link-hop { description "Numbered link route hopcontainer";container."; leaf link-tp-id { type te-tp-id; mandatory true; description "Numbered TElink termination pointLTP identifier."; } leaf-list flags { type path-attribute-flags; description"Record route per hop flags";"Path attributes flags."; reference"RFC3209, RFC4090, RFC4561";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } description "Numbered link routehop";hop."; } case unnumbered-link-hop { container unnumbered-link-hop { leaf link-tp-id { type te-tp-id; mandatory true; description "TElink termination pointLTP identifier. The combination of the 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";"Path attributes flags."; reference"RFC3209, RFC4090, RFC4561";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } description "Unnumbered linkrecord route hop";Record Route hop."; reference"RFC3477:"RFC 3477: Signalling Unnumbered Links inRSVP-TE";Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; } description "Unnumbered link routehop";hop."; } case label { container label-hop { description "Label route hoptype";type."; uses te-label; leaf-list flags { type path-attribute-flags; description"Record route per hop flags";"Path attributes flags."; reference"RFC3209, RFC4090, RFC4561";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } description "TheLabel record routelabel Record Route entrytypes";types."; } } } grouping label-restriction-info { description "Label set iteminfo";information."; leaf restriction { type enumeration { enum inclusive { description "The label or label range is inclusive."; } enum exclusive { description "The label or label range is exclusive."; } } default'inclusive';"inclusive"; description"Whether"Indicates whether the list item is inclusive or exclusive."; } leaf index { type uint32; description "The index of the label restriction list entry."; } container label-start { must "(not(../label-end/te-label/direction) and" + " not(te-label/direction))" + " or " + "(../label-end/te-label/direction = te-label/direction)" + " or " + "(not(te-label/direction) and" + " (../label-end/te-label/direction = 'forward'))" + " or " + "(not(../label-end/te-label/direction) and" + " (te-label/direction = 'forward'))" { error-message"label-start"'label-start' andlabel-end'label-end' must have the samedirection.";" + "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 whichcase, attributecase the 'label-end' attribute is not set."; uses te-label; } container label-end { must "(not(../label-start/te-label/direction) and" + " not(te-label/direction))" + " or " + "(../label-start/te-label/direction = te-label/direction)" + " or " + "(not(te-label/direction) and" + " (../label-start/te-label/direction = 'forward'))" + " or " + "(not(../label-start/te-label/direction) and" + " (te-label/direction = 'forward'))" { error-message"label-start"'label-start' andlabel-end'label-end' must have the samedirection.";" + "direction."; } description"The"This is the ending label if a label range isspecified;specified. This attribute is notset, Ifset 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-start' <label-end'label-end' enforceslabel-step'label-step' > 0label-start'label-start' >label-end'label-end' enforceslabel-step'label-step' <0";0."; choice technology { defaultgeneric;"generic"; description"Data plane"Data-plane technology type."; case generic { leaf generic { type int32; default1;"1"; description "Label rangestep";step."; } } } } leaf range-bitmap { type yang:hex-string; description "When there are gaps betweenlabel-start'label-start' andlabel-end,'label-end', this attribute is used to specify the positions of the used labels. This is represented inbig-endianbig endian ashex-string.'hex-string'. TheMSBmost significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity. Eachbit-positionbit position in therange-bitmap hex-string'range-bitmap' 'hex-string' maps to a label in the range derived fromthe label-start.'label-start'. For example, assuminglabel-start=16000that 'label-start' = 16000 andrange-bitmap=0x01000001,'range-bitmap' = 0x01000001, then: -bit-position(0)bit position (0) is set, and the corresponding mapped label from the rangeis:is 16000 + (0 *label-step)'label-step') or 16000 for defaultlabel-step=1.'label-step' = 1. -bit-position(24)bit position (24) is set, and the corresponding mapped label from the rangeis:is 16000 + (24 *label-step)'label-step') or 16024 for defaultlabel-step=1";'label-step' = 1."; } } grouping label-set-info { description "Grouping forListthe list of label restrictions specifying what labels may or may not beused on a link connectivity.";used."; container label-restrictions { description "The label restrictionscontainer";container."; list label-restriction { key "index"; description "The absence oflabel-setthe label restrictions container implies that all labels are acceptable;otherwiseotherwise, only restricted labels are available."; reference"RFC7579:"RFC 7579: General Network Element Constraint Encoding for GMPLS-Controlled Networks"; uses label-restriction-info; } } } grouping optimization-metric-entry { description "Optimization metrics configurationgrouping";grouping."; leaf metric-type { type identityref { base path-metric-type; } description "Identifiesan entry inthelist of metric-types to optimize'metric-type' that theTEpathfor.";computation process uses for optimization."; } leaf weight { type uint8; default1;"1"; description "TE path metric normalizationweight";weight."; } container explicit-route-exclude-objects { when "../metric-type = " + "'te-types:path-metric-optimize-excludes'"; description "Container for theexclude route'exclude route' objectlist";list."; uses path-route-exclude-objects; } container explicit-route-include-objects { when "../metric-type = " + "'te-types:path-metric-optimize-includes'"; description "Container for theinclude route'include route' objectlist";list."; uses path-route-include-objects; } } grouping common-constraints { description "Common constraints grouping that can be set on a constraint set or directly on thetunnel";tunnel."; uses te-bandwidth { description "A requested bandwidth to use for pathcomputation";computation."; } leaf link-protection { type identityref { base link-protection-type; } defaultte-types:link-protection-unprotected;"te-types:link-protection-unprotected"; description "Link protection type required for the links included in the computedpath";path."; reference"RFC4202:"RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching(GMPLS).";(GMPLS)"; } leaf setup-priority { type uint8 { range'0..7';"0..7"; } default7;"7"; description "TE LSP requested setuppriority";priority."; reference"RFC3209";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf hold-priority { type uint8 { range'0..7';"0..7"; } default7;"7"; description "TE LSP requested holdpriority";priority."; reference"RFC3209";"RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf signaling-type { type identityref { base path-signaling-type; } defaultte-types:path-setup-rsvp;"te-types:path-setup-rsvp"; description "TE tunnel path signalingtype";type."; } } grouping tunnel-constraints { description "Tunnel constraints grouping that can be set on a constraint set or directly on thetunnel";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 the path computation."; container explicit-route-objects-always { description "Container for theexclude route'exclude route' objectlist";list."; list route-object-exclude-always { keyindex;"index"; ordered-by user; description "List of route objects to always exclude from the pathcomputation";computation."; leaf index { type uint32; description "Explicitroute objectRoute 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 keyvalues";values."; } uses explicit-route-hop; } list route-object-include-exclude { keyindex;"index"; ordered-by user; description "List of route objects to include or exclude in the pathcomputation";computation."; leaf explicit-route-usage { type identityref { base route-usage-type; } defaultte-types:route-include-object;"te-types:route-include-object"; description"Include"Indicates whether to include or excludeusage. Defaultthe route object. The default is toinclude";include it."; } leaf index { type uint32; description "Route object include-exclude index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on keyvalues";values."; } uses explicit-route-hop { augment "type" { case srlg { container srlg { description "SRLGcontainer";container."; leaf srlg { type uint32; description "SRLGvalue";value."; } } description "An SRLG value to be included orexcluded";excluded."; } description "Augmentationtofor a generic explicit route for SRLGexclusion";exclusion."; } } } } } grouping path-route-include-objects { description "List of routeobject(s)objects to be included when performing the path computation."; list route-object-include-object { keyindex;"index"; ordered-by user; description "List ofexplicit route objectsExplicit Route Objects to be included in the pathcomputation";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 keyvalues";values."; } uses explicit-route-hop; } } grouping path-route-exclude-objects { description "List of routeobject(s)objects to be excluded when performing the path computation."; list route-object-exclude-object { keyindex;"index"; ordered-by user; description "List ofexplicit route objectsExplicit Route Objects to be excluded in the pathcomputation";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 keyvalues";values."; } uses explicit-route-hop { augment "type" { case srlg { container srlg { description "SRLGcontainer";container."; leaf srlg { type uint32; description "SRLGvalue";value."; } } description "An SRLG value to be included orexcluded";excluded."; } description "Augmentationtofor a generic explicit route for SRLGexclusion";exclusion."; } } } } grouping generic-path-metric-bounds { description "TE path metric boundsgrouping";grouping."; container path-metric-bounds { description "TE path metric boundscontainer";container."; list path-metric-bound { keymetric-type;"metric-type"; description "List of TE path metricbounds";bounds."; leaf metric-type { type identityref { base path-metric-type; } description "Identifies an entry in the list ofmetric-types'metric-type' items bound for the TE path."; } leaf upper-bound { type uint64; default0;"0"; description "Upper bound on the end-to-end TE path metric. A zeroindicateindicates an unbounded upper limit for the specificmetric-type";'metric-type'."; } } } } grouping generic-path-optimization { description "TE generic path optimizationgrouping";grouping."; container optimizations { description "The objective function container that includes attributes to impose when computing a TEpath";path."; choice algorithm { description "Optimizations algorithm."; case metric { if-featurepath-optimization-metric;"path-optimization-metric"; /* Optimize by metric */ list optimization-metric { key "metric-type"; description "TE path metrictype";type."; uses optimization-metric-entry; } /* Tiebreakers */ container tiebreakers { description "Container for the list oftiebreaker(s)";tiebreakers."; list tiebreaker { key "tiebreaker-type"; description "The list of tiebreakercriterioncriteria to apply on an equally favored set ofpathspaths, in order to pickbest";the best."; leaf tiebreaker-type { type identityref { base path-metric-type; } description "Identifies an entry in the list of tiebreakers."; } } } } case objective-function { if-featurepath-optimization-objective-function;"path-optimization-objective-function"; /* Objective functions */ container objective-function { description "The objective function container that includes attributes to impose when computing a TEpath";path."; leaf objective-function-type { type identityref { base objective-function-type; } defaultte-types:of-minimize-cost-path;"te-types:of-minimize-cost-path"; description "Objective functionentry";entry."; } } } } } } grouping generic-path-affinities { description "Path affinitiesgrouping";grouping."; container path-affinities-values { description "Path affinitiesvalues representation";represented as values."; list path-affinities-value { key "usage"; description "List of named affinityconstraints";constraints."; leaf usage { type identityref { base resource-affinities-type; } description "Identifies an entry in the list of valueaffinities constraints";affinity constraints."; } leaf value { type admin-groups; default'';""; description "The affinity value. The default is empty."; } } } container path-affinity-names { description "Path affinitiesnamed representation style";represented as names."; list path-affinity-name { key "usage"; description "List of named affinityconstraints";constraints."; leaf usage { type identityref { base resource-affinities-type; } description "Identifies an entry in the list of namedaffinities constraints";affinity constraints."; } list affinity-name { key "name"; leaf name { type string; description"Identify"Identifies a named affinity entry."; } description "List of namedaffinities";affinities."; } } } } grouping generic-path-srlgs { description "Path SRLGgrouping";grouping."; container path-srlgs-lists { description "Path SRLG propertiescontainer";container."; list path-srlgs-list { key "usage"; description "Listentriesofvalue SRLGsSRLG values to be included orexcluded";excluded."; leaf usage { type identityref { base route-usage-type; } description "Identifies an entryofin a list of SRLGs to either include orexclude";exclude."; } leaf-list values { type srlg; description "List of SRLGvalues";values."; } } } container path-srlgs-names { description "Container for the list of namedSRLG list";SRLGs."; list path-srlgs-name { key "usage"; description "Listentriesof named SRLGs to be included orexcluded";excluded."; leaf usage { type identityref { base route-usage-type; } description "Identifies an entryofin a list of named SRLGs to either include orexclude";exclude."; } leaf-list names { type string; description "List of namedSRLGs";SRLGs."; } } } } grouping generic-path-disjointness { description "Path disjointnessgrouping";grouping."; leaf disjointness { type te-path-disjointness; description "The type of resource disjointness. When configured for a primary path, the disjointness level applies to all secondary LSPs. When configured for a secondary path, the disjointness level overrides theonelevel configured for the primarypath";path."; } } grouping common-path-constraints-attributes { description "Common path constraints configurationgrouping";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 configurationgrouping";grouping."; container path-constraints { description "TE named path constraintscontainer";container."; uses common-path-constraints-attributes; uses generic-path-disjointness; } } grouping generic-path-properties { description "TE generic path propertiesgrouping";grouping."; container path-properties { config false; description "The TE pathproperties";properties."; list path-metric { keymetric-type;"metric-type"; description "TE path metrictype";type."; leaf metric-type { type identityref { base path-metric-type; } description "TE path metrictype";type."; } leaf accumulative-value { type uint64; description "TE path metric accumulativevalue";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 anLSP";LSP."; list path-route-object { keyindex;"index"; ordered-by user; description "List of route objects either returned by the computation engine or actually used by anLSP";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 keyvalues";values."; } uses explicit-route-hop; } } } } }<CODE ENDS> ]]></artwork></figure>]]></sourcecode> </section> <section anchor="packet-te-types-yang-module"title="Packetnumbered="true" toc="default"> <name>Packet TE Types YANGModule">Module</name> <t>Theietf-te-packet-types"ietf-te-packet-types" module imports from thefollowing modules:</t> <t><list style="symbols"> <t>ietf-te-types"ietf-te-types" module defined in <xref target="te-types-yang-module"/> of this document.</t></list></t> <figure title="TE packet types YANG module" anchor="fig-mpls-te-types"><artwork><![CDATA[ <CODE BEGINS> file "ietf-te-packet-types@2019-11-18.yang"<sourcecode name="ietf-te-packet-types@2020-04-06.yang" type="yang" 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";te-packet-types; /* Import TE generic types */ import ietf-te-types { prefix te-types; reference "RFCXXXX: A8776: Common YANG DataModelTypes forCommonTrafficEngineering Types";Engineering"; } organization "IETFTEASTraffic Engineering Architecture and Signaling (TEAS) Working Group"; contact "WG Web:<http://tools.ietf.org/wg/teas/><https://datatracker.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>";<mailto:i_bryskin@yahoo.com>"; description "This YANG module contains a collection of generally usefulMPLS TE specificYANG data typedefinitions.definitions specific to MPLS TE. The model fully conforms to the Network Management Datastore Architecture (NMDA). Copyright (c)20182020 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 RFCXXXX;8776; 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"2020-04-06 { description "Latest revision of TE MPLStypes";types."; reference "RFCXXXX: A8776: Common YANG DataModelTypes forCommonTrafficEngineering Types";Engineering"; } /** * Typedefs */ typedef te-bandwidth-requested-type { type enumeration { enum specified { description "Bandwidth is explicitlyspecified";specified."; } enum auto { description "Bandwidth is automaticallycomputed";computed."; } } description"enumerated"Enumerated type for specifying whether bandwidth is explicitly specified or automaticallycomputed";computed."; } typedef te-class-type { type uint8; description "Diffserv-TEclass-type that definesClass-Type. Defines a set of Traffic Trunks crossing a link that is governed by a specific set of bandwidth constraints.CTClass-Type is used for the purposes of link bandwidth allocation,constraint- based routingconstraint-based routing, and admission control."; reference"RFC4124: Protocols"RFC 4124: Protocol Extensions for Support of Diffserv-awareTE";MPLS Traffic Engineering"; } typedef bc-type { type uint8 { range'0..7';"0..7"; } description "Diffserv-TE bandwidthconstraintconstraints as defined inRFC4124";RFC 4124."; reference"RFC4124: Protocols"RFC 4124: Protocol Extensions for Support of Diffserv-awareTE";MPLS Traffic Engineering"; } typedef bandwidth-kbps { type uint64; units "Kbps"; description "Bandwidthvaluesvalues, expressed in kilobits persecond";second."; } typedef bandwidth-mbps { type uint64; units "Mbps"; description "Bandwidthvaluesvalues, expressed in megabits persecond";second."; } typedef bandwidth-gbps { type uint64; units "Gbps"; description "Bandwidthvaluesvalues, expressed in gigabits persecond";second."; } identity backup-protection-type { description "Base identity for the backup protectiontype";type."; } identity backup-protection-link { base backup-protection-type; description"backup"Backup provides link protectiononly";only."; } identity backup-protection-node-link { base backup-protection-type; description"backup"Backup offers node (preferred) or linkprotection";protection."; } identity bc-model-type { description "Base identity for the Diffserv-TEbandwidth constraint model type";Bandwidth Constraints Model type."; reference"RFC4124: Protocols"RFC 4124: Protocol Extensions for Support of Diffserv-awareTE";MPLS Traffic Engineering"; } identity bc-model-rdm { base bc-model-type; description "RussianDoll bandwidth constraint modelDolls Bandwidth Constraints Model type."; reference"RFC4127:"RFC 4127: Russian Dolls Bandwidth Constraints Model forDS-TE";Diffserv-aware MPLS Traffic Engineering"; } identity bc-model-mam { base bc-model-type; description "Maximum Allocationbandwidth constraint modelBandwidth Constraints Model type."; reference"RFC4125:"RFC 4125: Maximum Allocation Bandwidth Constraints Model forDS-TE";Diffserv-aware MPLS Traffic Engineering"; } identity bc-model-mar { base bc-model-type; description "Maximum Allocation with Reservationbandwidth constraint modelBandwidth Constraints Model type."; reference"RFC4126: MAR"RFC 4126: Max Allocation with Reservation Bandwidth Constraints Model forDS-TE";Diffserv-aware MPLS Traffic Engineering & Performance Comparisons"; } grouping performance-metrics-attributes-packet { description"A container containing performance metric"Contains PM attributes."; uses te-types:performance-metrics-attributes { augmentperformance-metrics-one-way"performance-metrics-one-way" { leaf one-way-min-delay { type uint32 { range'0..16777215';"0..16777215"; } description "One-way minimum delay or latency inmicro seconds.";microseconds."; } 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';"0..16777215"; } description "One-way maximum delay or latency inmicro seconds.";microseconds."; } 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';"0..16777215"; } description "One-way delay variation inmicro seconds.";microseconds."; reference"RFC5481, section"RFC 5481: Packet Delay Variation Applicability Statement, Section 4.2"; } leaf one-way-delay-variation-normality { type te-types:performance-metrics-normality; default "normal"; description "One-way delay variation normality."; reference"RFC7471, RFC8570, and RFC7823";"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } leaf one-way-packet-loss { type decimal64 { fraction-digits 6; range'0 .. 50.331642';"0..50.331642"; } description "One-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is0.000003%.0.000003%, where the maximum is 50.331642%."; reference "RFC7810, section-4.4";8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.4"; } leaf one-way-packet-loss-normality { type te-types:performance-metrics-normality; default "normal"; description "Packet loss normality."; reference"RFC7471, RFC8570, and RFC7823";"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } description "PM one-waypacket specificpacket-specific augmentationtofor a generic PMgrouping";grouping."; } augmentperformance-metrics-two-way"performance-metrics-two-way" { leaf two-way-min-delay { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "Two-way minimum delay or latency inmicro seconds.";microseconds."; } 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";"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } leaf two-way-max-delay { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "Two-way maximum delay or latency inmicro seconds.";microseconds."; } 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";"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } leaf two-way-delay-variation { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "Two-way delay variation inmicro seconds.";microseconds."; reference"RFC5481, section"RFC 5481: Packet Delay Variation Applicability Statement, Section 4.2"; } leaf two-way-delay-variation-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way delay variation normality."; reference"RFC7471, RFC8570, and RFC7823";"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } leaf two-way-packet-loss { type decimal64 { fraction-digits 6; range'0 .. 50.331642';"0..50.331642"; } default0;"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-waypacket specificpacket-specific augmentationtofor a generic PMgrouping";grouping."; reference"RFC7471, RFC8570, and RFC7823";"RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } } } grouping one-way-performance-metrics-packet { description "One-way packetperformance metricsPM throttle grouping."; leaf one-way-min-delay { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "One-way minimum delay or latency inmicro seconds.";microseconds."; } leaf one-way-max-delay { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "One-way maximum delay or latency inmicro seconds.";microseconds."; } leaf one-way-delay-variation { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "One-way delay variation inmicro seconds.";microseconds."; } leaf one-way-packet-loss { type decimal64 { fraction-digits 6; range'0 .. 50.331642';"0..50.331642"; } default0;"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 packetperformance metricsPM throttle grouping."; leaf two-way-min-delay { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "Two-way minimum delay or latency inmicro seconds.";microseconds."; } leaf two-way-max-delay { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "Two-way maximum delay or latency inmicro seconds.";microseconds."; } leaf two-way-delay-variation { type uint32 { range'0..16777215';"0..16777215"; } default0;"0"; description "Two-way delay variation inmicro seconds.";microseconds."; } leaf two-way-packet-loss { type decimal64 { fraction-digits 6; range'0 .. 50.331642';"0..50.331642"; } default0;"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 "Packetperformance metricsPM thresholdgrouping";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 augmentationtofor a genericgrouping";grouping."; } augment "throttle/threshold-in" { uses one-way-performance-metrics-packet; uses two-way-performance-metrics-packet; description "PM threshold-in packet augmentationtofor a genericgrouping";grouping."; } augment "throttle/threshold-accelerated-advertisement" { uses one-way-performance-metrics-packet; uses two-way-performance-metrics-packet; description "PM accelerated advertisement packet augmentationtofor a genericgrouping";grouping."; } } } }<CODE ENDS> ]]></artwork></figure>]]></sourcecode> </section> <section anchor="iana-considerations"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document registers the following URIs in theIETF XML registry <xref target="RFC3688"/>. Following"ns" subregistry within theformat in"IETF XML Registry" <xreftarget="RFC3688"/>, the following registration is requested to be made.</t> <figure><artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-te-types XML: N/A,target="RFC3688" format="default"/>.</t> <ul empty="true"><li> <dl newline="false" spacing="compact"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-te-types</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. URI: urn:ietf:params:xml:ns:yang:ietf-te-packet-types XML: N/A,namespace.</dd> </dl></li></ul> <ul empty="true"><li> <dl newline="false" spacing="compact"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-te-packet-types</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. ]]></artwork></figure>namespace.</dd> </dl></li></ul> <t>This document registers two YANG modules in theYANG"YANG ModuleNamesNames" registry <xreftarget="RFC6020"/>.</t> <figure><artwork><![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></figure>target="RFC6020" format="default"/>.</t> <ul empty="true"><li> <dl newline="false" spacing="compact"> <dt>Name:</dt><dd>ietf-te-types</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-te-types</dd> <dt>Prefix:</dt><dd>te-types</dd> <dt>Reference:</dt><dd>RFC 8776</dd> </dl></li></ul> <ul empty="true"><li> <dl newline="false" spacing="compact"> <dt>Name:</dt><dd>ietf-te-packet-types</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-te-packet-types</dd> <dt>Prefix:</dt><dd>te-packet-types</dd> <dt>Reference:</dt><dd>RFC 8776</dd> </dl></li></ul> </section> <section anchor="security-considerations"title="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 <xreftarget="RFC6241"/>target="RFC6241" format="default"/> or RESTCONF <xreftarget="RFC8040"/>.target="RFC8040" format="default"/>. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) <xreftarget="RFC6242"/>.target="RFC6242" format="default"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xreftarget="RFC8446"/>.</t>target="RFC8446" format="default"/>.</t> <t>The Network Configuration Access Control Model (NACM) <xreftarget="RFC8341"/>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.,(e.g., typedef,identityidentity, 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 bewritable,writable or readable.The accessAccess 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 <xreftarget="RFC7950"/>target="RFC7950" format="default"/> apply for this document as well.</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8345.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3209.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7308.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6511.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5541.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3272.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4657.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5817.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4328.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6004.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7139.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7551.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7571.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7579.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3471.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3477.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3785.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4124.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7471.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8570.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7823.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6370.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5003.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3630.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6827.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4203.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6378.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4427.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4090.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4561.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4736.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5712.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4920.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5420.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7570.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4875.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5151.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5150.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6001.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7260.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8001.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8149.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8169.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6780.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4872.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4873.xml"/> <reference anchor="G.709" target="https://www.itu.int/rec/T-REC-G.709/"> <front> <title>Interfaces for the optical transport network</title> <seriesInfo name="ITU-T" value="Recommendation G.709"/> <author> <organization>ITU-T</organization> </author> <date month="June" year="2016"/> </front> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2702.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4125.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4126.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4127.xml"/> </references> </references> <sectionanchor="acknowledgement" title="Acknowledgement">anchor="acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</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 thankTom Petch, Jan Lindblad, Sergio Belotti, Italo Busi, Carlo Perocchio, Francesco Lazzeri, and Aihua Guo<contact fullname="Tom Petch"/>, <contact fullname="Jan Lindblad"/>, <contact fullname="Sergio Belotti"/>, <contact fullname="Italo Busi"/>, <contact fullname="Carlo Perocchio"/>, <contact fullname="Francesco Lazzeri"/>, and <contact fullname="Aihua Guo"/> for their review comments and for providing valuable feedback on this document.</t> </section> <section anchor="contributors"title="Contributors"> <figure><artwork><![CDATA[ Himanshu Shah Ciena Email: hshah@ciena.com Young Lee Huawei Technologies Email: leeyoung@huawei.com ]]></artwork></figure>numbered="false" toc="default"> <name>Contributors</name> <contact fullname="Himanshu Shah"> <organization>Ciena</organization> <address> <email>hshah@ciena.com</email> </address> </contact> <contact fullname="Young Lee"> <organization>Samsung Electronics</organization> <address> <email>younglee.tx@gmail.com</email> </address> </contact> </section></middle> <back> <references title='Normative References'> <reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <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> <seriesInfo name='BCP' value='14'/> <seriesInfo name='RFC' value='2119'/> <seriesInfo name='DOI' value='10.17487/RFC2119'/> </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> <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> <seriesInfo name='BCP' value='14'/> <seriesInfo name='RFC' value='8174'/> <seriesInfo name='DOI' value='10.17487/RFC8174'/> </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> <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> <seriesInfo name='RFC' value='6020'/> <seriesInfo name='DOI' value='10.17487/RFC6020'/> </reference> <reference anchor="RFC6241" target='https://www.rfc-editor.org/info/rfc6241'> <front> <title>Network Configuration Protocol (NETCONF)</title> <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> <seriesInfo name='RFC' value='6241'/> <seriesInfo name='DOI' value='10.17487/RFC6241'/> </reference> <reference anchor="RFC8294" target='https://www.rfc-editor.org/info/rfc8294'> <front> <title>Common YANG Data Types for the Routing Area</title> <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> <seriesInfo name='RFC' value='8294'/> <seriesInfo name='DOI' value='10.17487/RFC8294'/> </reference> <reference anchor="RFC6991" target='https://www.rfc-editor.org/info/rfc6991'> <front> <title>Common YANG Data Types</title> <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> <seriesInfo name='RFC' value='6991'/> <seriesInfo name='DOI' value='10.17487/RFC6991'/> </reference> <reference anchor="RFC7951" target='https://www.rfc-editor.org/info/rfc7951'> <front> <title>JSON Encoding of Data Modeled with YANG</title> <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> <seriesInfo name='RFC' value='7951'/> <seriesInfo name='DOI' value='10.17487/RFC7951'/> </reference> <reference anchor="RFC7950" target='https://www.rfc-editor.org/info/rfc7950'> <front> <title>The YANG 1.1 Data Modeling Language</title> <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> <seriesInfo name='RFC' value='7950'/> <seriesInfo name='DOI' value='10.17487/RFC7950'/> </reference> <reference anchor="RFC8345" target='https://www.rfc-editor.org/info/rfc8345'> <front> <title>A YANG Data Model for Network Topologies</title> <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> <seriesInfo name='RFC' value='8345'/> <seriesInfo name='DOI' value='10.17487/RFC8345'/> </reference> <reference anchor="RFC3688" target='https://www.rfc-editor.org/info/rfc3688'> <front> <title>The IETF XML Registry</title> <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> <seriesInfo name='BCP' value='81'/> <seriesInfo name='RFC' value='3688'/> <seriesInfo name='DOI' value='10.17487/RFC3688'/> </reference> <reference anchor="RFC8040" target='https://www.rfc-editor.org/info/rfc8040'> <front> <title>RESTCONF Protocol</title> <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> <seriesInfo name='RFC' value='8040'/> <seriesInfo name='DOI' value='10.17487/RFC8040'/> </reference> <reference anchor="RFC6242" target='https://www.rfc-editor.org/info/rfc6242'> <front> <title>Using the NETCONF Protocol over Secure Shell (SSH)</title> <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> <seriesInfo name='RFC' value='6242'/> <seriesInfo name='DOI' value='10.17487/RFC6242'/> </reference> <reference anchor="RFC8446" target='https://www.rfc-editor.org/info/rfc8446'> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <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> <seriesInfo name='RFC' value='8446'/> <seriesInfo name='DOI' value='10.17487/RFC8446'/> </reference> <reference anchor="RFC8341" target='https://www.rfc-editor.org/info/rfc8341'> <front> <title>Network Configuration Access Control Model</title> <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> <seriesInfo name='STD' value='91'/> <seriesInfo name='RFC' value='8341'/> <seriesInfo name='DOI' value='10.17487/RFC8341'/> </reference> </references> <references title='Informative References'> <reference anchor="RFC3209" target='https://www.rfc-editor.org/info/rfc3209'> <front> <title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title> <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> <seriesInfo name='RFC' value='3209'/> <seriesInfo name='DOI' value='10.17487/RFC3209'/> </reference> <reference anchor="RFC7308" target='https://www.rfc-editor.org/info/rfc7308'> <front> <title>Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)</title> <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> <seriesInfo name='RFC' value='7308'/> <seriesInfo name='DOI' value='10.17487/RFC7308'/> </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> <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> <seriesInfo name='RFC' value='6511'/> <seriesInfo name='DOI' value='10.17487/RFC6511'/> </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> <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> <seriesInfo name='RFC' value='5541'/> <seriesInfo name='DOI' value='10.17487/RFC5541'/> </reference> <reference anchor="RFC3272" target='https://www.rfc-editor.org/info/rfc3272'> <front> <title>Overview and Principles of Internet Traffic Engineering</title> <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> <seriesInfo name='RFC' value='3272'/> <seriesInfo name='DOI' value='10.17487/RFC3272'/> </reference> <reference anchor="RFC4657" target='https://www.rfc-editor.org/info/rfc4657'> <front> <title>Path Computation Element (PCE) Communication Protocol Generic Requirements</title> <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> <seriesInfo name='RFC' value='4657'/> <seriesInfo name='DOI' value='10.17487/RFC4657'/> </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> <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> <seriesInfo name='RFC' value='5817'/> <seriesInfo name='DOI' value='10.17487/RFC5817'/> </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> <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> <seriesInfo name='RFC' value='4328'/> <seriesInfo name='DOI' value='10.17487/RFC4328'/> </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> <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> <seriesInfo name='RFC' value='6004'/> <seriesInfo name='DOI' value='10.17487/RFC6004'/> </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> <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> <seriesInfo name='RFC' value='6205'/> <seriesInfo name='DOI' value='10.17487/RFC6205'/> </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> <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> <seriesInfo name='RFC' value='7139'/> <seriesInfo name='DOI' value='10.17487/RFC7139'/> </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> <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> <seriesInfo name='RFC' value='7551'/> <seriesInfo name='DOI' value='10.17487/RFC7551'/> </reference> <reference anchor="RFC7571" target='https://www.rfc-editor.org/info/rfc7571'> <front> <title>GMPLS RSVP-TE Extensions for Lock Instruct and Loopback</title> <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> <seriesInfo name='RFC' value='7571'/> <seriesInfo name='DOI' value='10.17487/RFC7571'/> </reference> <reference anchor="RFC7579" target='https://www.rfc-editor.org/info/rfc7579'> <front> <title>General Network Element Constraint Encoding for GMPLS-Controlled Networks</title> <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> <seriesInfo name='RFC' value='7579'/> <seriesInfo name='DOI' value='10.17487/RFC7579'/> </reference> <reference anchor="RFC3471" target='https://www.rfc-editor.org/info/rfc3471'> <front> <title>Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description</title> <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> <seriesInfo name='RFC' value='3471'/> <seriesInfo name='DOI' value='10.17487/RFC3471'/> </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> <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> <seriesInfo name='RFC' value='3477'/> <seriesInfo name='DOI' value='10.17487/RFC3477'/> </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> <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> <seriesInfo name='BCP' value='87'/> <seriesInfo name='RFC' value='3785'/> <seriesInfo name='DOI' value='10.17487/RFC3785'/> </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> <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> <seriesInfo name='RFC' value='4124'/> <seriesInfo name='DOI' value='10.17487/RFC4124'/> </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> <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> <seriesInfo name='RFC' value='4202'/> <seriesInfo name='DOI' value='10.17487/RFC4202'/> </reference> <reference anchor="RFC7471" target='https://www.rfc-editor.org/info/rfc7471'> <front> <title>OSPF Traffic Engineering (TE) Metric Extensions</title> <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> <seriesInfo name='RFC' value='7471'/> <seriesInfo name='DOI' value='10.17487/RFC7471'/> </reference> <reference anchor="RFC8570" target='https://www.rfc-editor.org/info/rfc8570'> <front> <title>IS-IS Traffic Engineering (TE) Metric Extensions</title> <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> <seriesInfo name='RFC' value='8570'/> <seriesInfo name='DOI' value='10.17487/RFC8570'/> </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> <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> <seriesInfo name='RFC' value='7823'/> <seriesInfo name='DOI' value='10.17487/RFC7823'/> </reference> <reference anchor="RFC6370" target='https://www.rfc-editor.org/info/rfc6370'> <front> <title>MPLS Transport Profile (MPLS-TP) Identifiers</title> <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> <seriesInfo name='RFC' value='6370'/> <seriesInfo name='DOI' value='10.17487/RFC6370'/> </reference> <reference anchor="RFC5003" target='https://www.rfc-editor.org/info/rfc5003'> <front> <title>Attachment Individual Identifier (AII) Types for Aggregation</title> <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> <seriesInfo name='RFC' value='5003'/> <seriesInfo name='DOI' value='10.17487/RFC5003'/> </reference> <reference anchor="RFC3630" target='https://www.rfc-editor.org/info/rfc3630'> <front> <title>Traffic Engineering (TE) Extensions to OSPF Version 2</title> <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> <seriesInfo name='RFC' value='3630'/> <seriesInfo name='DOI' value='10.17487/RFC3630'/> </reference> <reference anchor="RFC6827" target='https://www.rfc-editor.org/info/rfc6827'> <front> <title>Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols</title> <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> <seriesInfo name='RFC' value='6827'/> <seriesInfo name='DOI' value='10.17487/RFC6827'/> </reference> <reference anchor="RFC5305" target='https://www.rfc-editor.org/info/rfc5305'> <front> <title>IS-IS Extensions for Traffic Engineering</title> <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> <seriesInfo name='RFC' value='5305'/> <seriesInfo name='DOI' value='10.17487/RFC5305'/> </reference> <reference anchor="RFC6119" target='https://www.rfc-editor.org/info/rfc6119'> <front> <title>IPv6 Traffic Engineering in IS-IS</title> <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> <seriesInfo name='RFC' value='6119'/> <seriesInfo name='DOI' value='10.17487/RFC6119'/> </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> <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> <seriesInfo name='RFC' value='4203'/> <seriesInfo name='DOI' value='10.17487/RFC4203'/> </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> <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> <seriesInfo name='RFC' value='5307'/> <seriesInfo name='DOI' value='10.17487/RFC5307'/> </reference> <reference anchor="RFC6378" target='https://www.rfc-editor.org/info/rfc6378'> <front> <title>MPLS Transport Profile (MPLS-TP) Linear Protection</title> <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> <seriesInfo name='RFC' value='6378'/> <seriesInfo name='DOI' value='10.17487/RFC6378'/> </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> <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> <seriesInfo name='RFC' value='4427'/> <seriesInfo name='DOI' value='10.17487/RFC4427'/> </reference> <reference anchor="RFC4090" target='https://www.rfc-editor.org/info/rfc4090'> <front> <title>Fast Reroute Extensions to RSVP-TE for LSP Tunnels</title> <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> <seriesInfo name='RFC' value='4090'/> <seriesInfo name='DOI' value='10.17487/RFC4090'/> </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> <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> <seriesInfo name='RFC' value='4561'/> <seriesInfo name='DOI' value='10.17487/RFC4561'/> </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> <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> <seriesInfo name='RFC' value='4736'/> <seriesInfo name='DOI' value='10.17487/RFC4736'/> </reference> <reference anchor="RFC5712" target='https://www.rfc-editor.org/info/rfc5712'> <front> <title>MPLS Traffic Engineering Soft Preemption</title> <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> <seriesInfo name='RFC' value='5712'/> <seriesInfo name='DOI' value='10.17487/RFC5712'/> </reference> <reference anchor="RFC4920" target='https://www.rfc-editor.org/info/rfc4920'> <front> <title>Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE</title> <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> <seriesInfo name='RFC' value='4920'/> <seriesInfo name='DOI' value='10.17487/RFC4920'/> </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> <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> <seriesInfo name='RFC' value='5420'/> <seriesInfo name='DOI' value='10.17487/RFC5420'/> </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> <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> <seriesInfo name='RFC' value='7570'/> <seriesInfo name='DOI' value='10.17487/RFC7570'/> </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> <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> <seriesInfo name='RFC' value='4875'/> <seriesInfo name='DOI' value='10.17487/RFC4875'/> </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> <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> <seriesInfo name='RFC' value='5151'/> <seriesInfo name='DOI' value='10.17487/RFC5151'/> </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> <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> <seriesInfo name='RFC' value='5150'/> <seriesInfo name='DOI' value='10.17487/RFC5150'/> </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> <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> <seriesInfo name='RFC' value='6001'/> <seriesInfo name='DOI' value='10.17487/RFC6001'/> </reference> <reference anchor="RFC6790" target='https://www.rfc-editor.org/info/rfc6790'> <front> <title>The Use of Entropy Labels in MPLS Forwarding</title> <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> <seriesInfo name='RFC' value='6790'/> <seriesInfo name='DOI' value='10.17487/RFC6790'/> </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> <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> <seriesInfo name='RFC' value='7260'/> <seriesInfo name='DOI' value='10.17487/RFC7260'/> </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> <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> <seriesInfo name='RFC' value='8001'/> <seriesInfo name='DOI' value='10.17487/RFC8001'/> </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> <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> <seriesInfo name='RFC' value='8149'/> <seriesInfo name='DOI' value='10.17487/RFC8149'/> </reference> <reference anchor="RFC8169" target='https://www.rfc-editor.org/info/rfc8169'> <front> <title>Residence Time Measurement in MPLS Networks</title> <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> <seriesInfo name='RFC' value='8169'/> <seriesInfo name='DOI' value='10.17487/RFC8169'/> </reference> <reference anchor="RFC6780" target='https://www.rfc-editor.org/info/rfc6780'> <front> <title>RSVP ASSOCIATION Object Extensions</title> <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> <seriesInfo name='RFC' value='6780'/> <seriesInfo name='DOI' value='10.17487/RFC6780'/> </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> <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> <seriesInfo name='RFC' value='4872'/> <seriesInfo name='DOI' value='10.17487/RFC4872'/> </reference> <reference anchor="RFC4873" target='https://www.rfc-editor.org/info/rfc4873'> <front> <title>GMPLS Segment Recovery</title> <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> <seriesInfo name='RFC' value='4873'/> <seriesInfo name='DOI' value='10.17487/RFC4873'/> </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></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> <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> <seriesInfo name='RFC' value='2702'/> <seriesInfo name='DOI' value='10.17487/RFC2702'/> </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> <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> <seriesInfo name='RFC' value='4125'/> <seriesInfo name='DOI' value='10.17487/RFC4125'/> </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 & Performance Comparisons</title> <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> <seriesInfo name='RFC' value='4126'/> <seriesInfo name='DOI' value='10.17487/RFC4126'/> </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> <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> <seriesInfo name='RFC' value='4127'/> <seriesInfo name='DOI' value='10.17487/RFC4127'/> </reference> </references></back><!-- ##markdown-source: H4sIAPdC8F0AA+29e3Mbx/Eo+j8+xVymTom0CRDgQ6SgxDElUjLPFSUeko6T 67hSC2BIbLTYRXYXohhH57Pffsxrd2cXT8l2fmapSiQw093T09PT09Pd0263 W3mYR7IvbtPg7i4civP4PoylTMP4XrxMJpMkFn87ffta3D5OZdYKBoNUfoDW 554vR8kwDiYAawSw8nYo87t2LoOs/RjE9/BbO8dm7d5haxjk8j5JH/siy0et cJr2RZ7Osny/233W3W89JOn7+zSZTRHR6Y34Af5Gel7jZ6338hEajPriIs5l Gsu8fYb4Wq0sD+LRP4IoiYGGRyBoGvbFj3ky3BVZkuapvMvgt8cJ/vJTqxXM 8nGS9lst0W4J+AnjDPB1xE0QjOgDHsxtkMr39sMkvQ/i8N9BHiZxX/zvWRxO ZSreyhyJzqiJnARhBCPKoM+3/+QWHaBTISI81x3xGqgdhy2D6Dp4L7Ox83ER 1cswGybi5jHL5SSDsQ9bFhU2hE7fDrFNZ5hMWi6uv3bEm3BmEf11dieBm+qz Ipa/JFEeFIajUHykTp0onHVwYr+9x48rqP7SEVcd8QLkJ5hYhH8Js3E8E1fB hyB2vpzPSoX7w4D6FHhZmLULwJk+ZiAkzsRdgIQVPi7iu4hH4YdwNAsid9LC fwy4x7ePwThRvIyTdAK9Psg+NL1+9XK/13umfj3pHR+qX59297v61/3Dnm6w /8w0ePZMf3r87Mj5VXc7OTg8Ur8ePD05AdEM47sS7oP9rsZ9fNA90aCPehre 0ZHBfbB/vK9+PXx6dKwbAM3604N9A6HbNXTudzUZx70Dg+3Iknx07PyqGxwc mk/hV43i4PhEAzvs7WsUh/tdTdmx7XZydKxZcXyyf6DJOTCfHnW7B4ZBB4bb J/tmbAeG9Kd2kgDbgW1wbOHqwR8eGgiHoIH0r0dPNWWHxwdPNYTjnmHqMzPj R4fm12M7isOTY03OUc+wD341pHe7+tOnxwbx8f5TIxK2wUnv0Erd02em24mD bd/+SiN+fczSIkQepPcy74txnk+z/t7ew8NDJ8xhMcf5XiqHe7ft6/OX7dcd 6MDteVvYok+Urr0LhjITIJEiH0uRTPNwGESguYM4m4KCFTEv3S0CMAId3xf7 3d7Tdvdpe3+/1Wr9CKtpIuP8p774A7R43QEqOzC80ueLE0v9Pd0N7Se9g57o g6qLZZCKaZrkcojLX2QPYT4c46aCw7m8enPjjAPa3YWR3KpCNoM6bHeP4Z9n SIBxnRFB91/ZgLrrDag7Z0BdGtA5SBTu5SKqH1kT+Uftbq/dO6iQf4Iqcg3i T5ppPwH7QKawH8P+K0byLoxDpJkXiVoO7liwWSqzPElpF2oa0dN2j0bUarXb bREMMpjOIex7t+MwE2BqzbAb44RFGYhhEkUKS3InhmydAbRAkNlFqMmoAk5m sG2y5UYNJslIRig6ERhqs+BedgCLzCRAT2HnGWloPkBgHQGwXMYjaJcnYgB/ TlDo4M/BI4KeRdApHwc542n5LM3t2/MdwBLfhfczZg2hAYsul2IYTINBGAFn ZdZhdkzC0SiSrdYfUDGlgIMG3mrRmH7+We3Gnz4RFPobt1n4O0RW+QctZhkP gcksUoNddhU9/Pu1nMC0iqs0GcrRDLjwMogiMDABIxgMeQhDDKqyMAliQEVT h2KRwKxlIpsNxyLIxNvz25fv3r5SAwAb4tMnmgmeKkNnNpsig3Ek2QSQigzW Dcz5YBZGYHZXZh0QgaEDf0zkcAwWUDbJWjBMnlyR4MpTre/SZEK63YCizztl qQsV0xcSPCVErSpwK4GMRggcrBY6n7S1UNxgKOF9bMQNQRYFdDqNgPmDSBLr zUTXCt6dDHKYwQzMLW69ne2olTUSySzPgHs4ttxlAjDlD3+g1R/GSZTcP7Zo quB0IvB4komty+9vbrd2+X/x9h39fn3+f76/uD4/w99vvjt988b8olvcfPfu +zfwfUv9Znu+fHd5ef72jDvDp6L00eXp37ZI/sTWu6vbi3dvT99s4UJHsltm 7pCDap3inj5NJS7VAOcpG6bhAP6APi9eXoneIUsimruwdOh3tHc/fWo9jGXM qJI4ggHTnzARj8h81N8AAiUTlm6YB7QsQMzHyUMsQNpkh3mVW+bRTCkKcF5K yinDhXuXzGIizlnQPAtXcKQLP0pSa2fY6S10Em/hGJC1WhdxceJ26XyQ4YQS gjgZKTnjpWCximTwT5DsjKRuyjhGoCaQQJQ6OnAG6Uh9B2PMkmEYID9hzxpj G1AjKUjWNIHThh6W0Y9KOTrMAfpvSXB7MLD/a37IoMKfr9vln+on3o+/NiD+ o7glhP2EyGJq3I+v5R1MVjzkD/+zWSrQKSCEi44cBuwroHWsPv5RHZ1+KlEB HdBgqILAjxcFkRZaGhCgcPLQIYRB4FmuCkI7Nkogqh8XpLAMYhoM3xuyLYjS x3Ug1pgRAwN/lPD17YrCdeGRYSW6rozCZnw6TJP4UZlDp+QrCnkTbLW+Ea/R Ku2L1zKG03wU/htWwOUsykO9EYo3wQAW3Y2297DPm5urfuFz6HQV5GP+7rpf 7iOuYeZkSl+fm6/PR7Bt2m+Yjrm4r2/+AsivZZbMUlgD8ItMP7A5cKW6YbPb c6/3DL86u2njt2fhHS2knHXDDYAJce+s6XVz/eZ1X9yMQeuM0NJ/L67D7L3y fsH3b19cnvZBxcXtF2kSjIZBlqvBRLIdDAFypr0o2Pz0CgZ7OssT9CMMiXS1 XRdGe3MGOGFfhRPdmbxPg5GkT1+ZT18FIY33h1vg6w9BmOM2ck3GLDW9ugSx gUMiOixQZ1zKPA2HGcrFuw84ZPlQZ70CrQWxot1A7em357yt91vFZYVN4Lt7 lCYYlrUWvEsHWrfUB9lUDtE600bHOzaAwDbircg20Khpz9R2ACr1bJhMay2C c3aHikvWpy8TtI7BWvv5D8YFOlSffeJ9sDgwpYexTRCC+VjiA5vSbHaP5BQN b9zVweoM7uMkwykGwoL4UdiBmrEJ4itab5GYgkGJQHAXG+otuZkU3PTuwNxL HowiSOUsI6XhMdf6rRaAGsBnD+EoH/dJGrmbbsOjMXIA8PWEwnhNz06LTUNj ysFhCEx+tLoDpAbwzu5xCnh1omjIAGxqO3CE8Ao+nsV6etF+1F+HuAnzjk5W Iex5CZ1nHOoBAA4RDRE8KHRobBFqjaXHRb2+yJj09ta/t0qXiYa+diRTu2zb E1627SCH/wegMrP540ti2X4IHmn2YS3T7xMZZDPUYA5woYBTwyAGjRQlM7Ta RuqwBJDQA/AeDXDlZpqCtmfzlO1xY/8dHsP5aFeZpUfHXfzDHvdO9g/IOvQN LR+DDoRDfFsJtkznD9EcB0nWx7AfjpNoxGooGIF+y8OMz3V4PIOvM32IVYzQ ByfcQ6KMxWcEqiACq1GhJ/lKJfbGzUJZmcXdo212j+2zmx3xEru3UeGQOlIb iodd6HwlhmipbY/ClPcBxh6D1IMaS2mLIkpwaCxYj5oW+OgBDV74BvZ2maKP QIMBiULFo6UbEY2TKcnfghigOZIeJQnAxa9wunIGdR8lgyBqh6NGXoWoDHEh pDx7szj810zCCUV9gSIqQHcDDUm6C+eWEFbUED4bSCBfhrQVBPrEnCIRcMCN QtLu+niqvTxmA9B6IQ/ey5gP0XyEPzgu+CDQfY1zgIDQEaFXWEGxiCyJkGLY XBUZQAKPPnqErjwk0snyY663wTyZqkXP7MJDzRLMIimmkxCd3ByIj3rcTmug 1ADjs+OhSIa5zOkANoK1BXL6r1kwAoisvjxjhtMqHkIneGCkozySxDaaOB2N cAXZIylqK7BXlN2y3zns9JD7xFW8CcC1j/2BbgXi4qxwoAUAuveB6YkXB6an xzlgQEHvwulYgzrsWGB49YDAlNpyKanrftDZd8bxlI7Zmt0pKnt2ez1iE/YR IViaJcU9aBPKD+xqC6Cn8fAYn5LG9bSzXxo3CApKip7npaXFFZCLHIUCbwQS NBVhNscB+pZiWseTxJ6fUQTYCySB0TFA34X+mZwGrBdgIGBXw4mhQ2wwvXiR Uk/lS+OdbZeYa3Qd2S/a2cZbw8EhzQvSJKMprrEU/5iB4ZTSCZ5MOmHGA2hy nLeBvEO672YpaYUw/tcsTB95eeXTJdhFWhEmLtR3KLTFKe8Hb3tgxU0T+F5s 317t4CYYCNcKpSl/QM+Jli2CADogRv9Ep7K44A+7sKIEr2lIZZPLkvq6yzl2 F5KjrkiiecC4C8OOkf0TqYT9sHnLGuktC53dfHpy+ypBUZsnKZsZjCSq3evx ZosoCUbAsjbt0JoC0IfK86d1IY7vCUgMbo1oDYPh9FE5qKl/iK50vFLlrT4r YgRJaOZGlkb3jaNXJzc6tNHxjU5uYhvPdTve4e3jvlBAdawZzzZLIz4YMrfy wcb7Vw0LNuoENm044YBWnmVNu3JxFrk9C7IGArqH/fSe8RyifrHjwZtWNsZQ ioyUtu+i4F5P4yDIlJ+bJTNnl6DydeNB+OaK5YN6eYe6331mLEK8x7V/HB88 NX/gBa795tm+bYaXuOaPY2VSagE8ss16Rz33D9sMr3PtH8cOBXila61Vtxle 6xZMV7zcJW6hHLft5ZFjSc3nFq1x5+JJnc7qltauO3GtlnNF1c6GY7Bdl0KO U+WAEAyiAT2Khh0nrtYUtpE2nnyBLQuLiDNeDUNoGCzVsBDRfgfbPaHlI6az dArWpp+2Q7VNar/uspPg8VuJbWDOjnAgVqaGbR0lQicFGdx3/+DzDbuoQZm1 72bx8nJCKwp4NJ2pc6aBJzS8Gv2IcSZasbD6XgqxVfq1osnr2S4MXoS4MLJp m47oxkVLWBcTTN2xAS+dLBWeFdcfaauFl19hjDyv5ta77V5/Loremho2LsCF 0zhsvWe30SKOqf1SY7dmyF0YAR1Z5WIkMHNP18KzLEfbLgMJzMiJwXYBW0kJ 27lDOc3p7F2m/M94Q3XcLXCRJUdvOLw5Lr8s1KZaLye0tTo+B81A+REvIMOc rhHoFDzfv2Bx696Cei+0MjDeyhzucddgL/Dcs3dxl9dmpXIh14+bLCN180Y+ 1VqnZ9GpWPDIGt8iuhE8l7iFe1/j87Q+TTgeM27XIbYAupVdmQMAN1tZIVSU AQ9JMFQ0UgeP0wDZzisDzzvm/O/RG2Te8IyToesSQ/NL8I2tmBlXEl5itGG+ bK9Gd9FguDTkF9plimKAtjYdbF689Nu+DiJyhS7FVRet8dTiJGu06vbYpzQA s7Lp1F9PzZJSH5g1ZUCDCf2vGVg2crTk2tInHhBbBcKhl9WdFW2SgLluWSXf 9aqlIOva/VzrjR2NQnV6V+vK0KOa4YK3C53w8WpvuDngq24nsMQuOXXVA+S3 Kze/5hrHucotCw7e54Kt2vZd2Jbb4sUt2rUXsRmn9jil+o4bDoxpAivCfEDd fxQ/bVfvbXZ22fHHUQJBlCUunOI4AT27xchvqI5sdpjFeSOPonTvwvotpfHJ +Gvp86Lzx8H+CYqx+uvp0bH5CiN9zR8Y4Gv/OOr17B/75LniPzDi1/5x0D2x fxwd9Zw/jgt/1B28jp72eFW1dNCGOvlgZCr7oJwr5D++fHcG+uP89cXbm2/Q epBiqyBX3+53e88oMO6kg/Ky1dKCVpC+n8FIJXHCvQUnu9fpPW9xYHg2RbNo a5bGfezUR8fTJOt/nET9OOtjr34B2NZzvCLf+0pcy2mEXcmCuTh9e0phL2jb cDTSV3vQTkWCbBV78zKoiPTPdPeuuuDnz+kDI0piS8l5v5BtQREutwq6EJ/K GJyFVMCwRRzbDI7ieiui0ZdOXlQUD1+DyujNa4YuTlMZWPxu/D5B3ro4v33l 9dyepmDz4n5L12mwzPgOW0V8nd7scNRDIbGEp4qU5jBn+D+8Fj/IQR9+/SOG ivb39vIkiTLKgOgAOXsP93uY4bL3jYL3WrwJsxw6/BHTCfKkj99+q5t/o4It zkEFJWmf4i0KySXOjwFQziKpAqkkjvjgVFJEqnBq0jR80DwZGVV434WwzWTj GTrExnWQxhl8CVTJOPBTVcxW8YGoTU2pAqvkhHjAeVJAqoD+lsyQKCnroERS PmKbb8ez4EGGBIUljK8CplaKb9VWUrBPy3GV6gI3ekQH9t0sgp2YUZttuhhN 6UYjd+xFM5zqEQbeZoIVwPlKeitUMSPi0sao4tqkAI/iitp+e3l2utNRXHmZ TB/T8H4MRt5wB0OXT4RamHiwUw52NDwyDASiLsb7TLdHnImV6d0P7947QpxG kSCweNuERh5dVVP3azlCJy7aQfqWFbiCu6zyNuMngzAOUjIYJ9kua+0k5f74 B6gYZImJ091Fp/kUffI52euzNJsFMQa5sG8um5FnpMAxOKfJOONAxkzPHRkO fKl0Ayoz4mG+uDkDGabmat4kXd4BVYULpaHmgmXhkwwE7R4Msys8D2Sh4eK1 jAL2Aifc/ExFoqjvt3V8OyXXSWn1liK8jflFOx1uTWKoN0x9telGBiJ/gpRC jUGRi7/Cz3MYhhoP6W34OMwzGd2RKkdZExGRjhHRYBt11G66R03PR50+HiRo W0VwyjsAQgZdsAXY1QO8kaWw+QkcFTmYlSAASNkpQ5tNMYCejW/8ZSDBDDPR mPyZon86G0Rq7hlICYtFgGFsxJUta35sqU3PWc1i6w2Az3LbHjDpsJ3yZqj0 xpbmZF/b8LQdXvJaBR6qndIXKqY0TmmX3vvqK/zmK/oclADJAtkmOX8gnEsU NQhSGGT6jOXHtgqC+VkhANOn2+t39/vdg373kEHhTwRKF9i61et0ej01vE9l nuhhnnouXvZMaB2dRfdewiE+tQdL9kdaPe2QhvR2zPhhXi8TYDvu8bScYdW+ eISJ3r68ebFDF/NokQd4j5flZu3Ku1yDoCBpEBbslOHxDAOiYNEF5Cj8t0wT +i7TDXUwiDTb9ocgmuFlNt4eikTpEJw/ioHMH5Xgl60hdKWQ3KkLJjuNnsnK 3Nniay89R3yMt02fu5/r2692pUFlumAzOvdekhWi8qtU+lA0yNbzOjE5b7qo 88qLnoCK2DTLy82LJrnwC4QGsIhceAVCAyjJRVUs8NxVZbLv9myOSGi3CYA3 Xyg/ecYhSq5DgSBq0fm0IBx0kjfD8EgZXYXYXupOzy9bPi8IZeRSaIQzfu2F cbmAn8FhL34fJw/xlkM7z0/3ufmgKo0kkd9zVz1Pli8MmQmpAu7NBfyWenYo Dxnz4TMnIG4QUjwFbEBoJtSgDgZ1yPfnIj9VfS16dhmhEFfIABLKw6/V83Y0 cDjW0VQVlxMPDgkQ2wadpg+xqpGD5TWotKMG8OUOxdrMivPj218pw1i8u7ny nxUpBYiDlQXpH7KwzGpX0YV9cXHTvrhZEQKlM7vR0e0XQaavBG+ktvNRMZwr 9z8Fe3F/vAfw3iZmdJ2Y7YjvKScFdDdToXtaYqrLCsMYCtojjPOD/YpmFlsY tmCXZllVYeyCs4MdVxGhh5qMGBV2sNCSNdtHgxCfx+itH9UszRHm08yFcRZm TUDQnHNtoVo4F3j0mEjqQCetGoCwSYENjZ6TSUBpk7Qq5oI3Ox+GmyuSnU3H ieemsEHEQV5o93R6n4KZjSdHOJLnxB3KjnPI0JfhlvbqgmJyVBUB8VrDvNEw gShKPkaRKGR6wIcuNb51pEs/+Fm3MYbRGZm5VeKAS2CVGQVqlN6ZT8kNCz1G d6pdaEFVemZSe/1hP+q6jHJSMx1kZs0hHn/Hux7t1YOzFktmP1gbGEJhhvKk ++PHv/603d3e/nun++edP/84vfpp++9f7/y5++f/8Ec7/3miWn8tnvTgs+0f /z4K2nen7Vc//dzdPfr0Y3f/8OlJcDp8Kc9/AhAOkO3e/o/d9vFPBRA/dns/ /X30n+6f/z6Cf9D+P0SDA7W3e/LpP38ffe302t7d/jVTurPz1ZM5ZyU6iIfF axs7Y/YKjnKZ1awp34NzLMT784wO63yIzspBlpNJoP0ilFjAfofMLAJ19laB lzHo7xiO8mSOj+QwhM14F21sijW4lyntxvj3XZQEeV9D2Ya24j/0xX/4q50f v9p+svvE88XOTyYbDfMa9D2UiWDAoVfzNLjmAadMcCSnMDJtL+5CKdFkBjQH ++79EJ6/0ScttmXnviO6H3vTXndnV0OxQZdgXec63V1Z/ViuJpPAeuOYYsLf 3b6tUG2nQ/HLhLRi0Pcuxeuaqctgte3u7x7s9p7smuwIALUvktGs+4Rvjnr4 x0HHRXz2w9mli2oahOxWyyIwqBxniron1YHv9GPpcAg4KBIQiLuUj0OPDLNL AqRB0EcMe59vFcvtD1jgnIZ2BC/BxIuxpEj0WJjlarg5phbDfMt0iCcQui10 3QTOrKk7iSfdj0/w96EcqQs6bMYM8Zo1JBO7VD+FNSg6iArpQEWNqjM5yhbV idGnKRyBJRDS6RzPVwDlrA9/nof/8EhldlAuKUbhsHPQ6Xk3AZNRsYAVqCk7 jQspFsmSCRb0MzfLgn4WT7VQiRbGCO12DxwoK+dZ8JqYl2zh5axOe1nI0uVs l7lmBDfDDBlM0IhtlBB6BfwmCqfPzAet2i0Gu0Zot+ak9pRyeqyNMfZfE1KZ q4IQ73tZXY52WojlFGrfzpM2x9zPZdDtWAfNZ6W+NcbhBLNxdSruUuDdnqh5 h9GMNriByfRFMccM4IWP5PPsSCfcy6QqIDlNR2qqvlV/FrbnTlxeePLW4/2L ul/Y96+cUmbaQrOpc9Lm8pkP0JhcOQy0e9ZNasOYTYPaP7E66W1lXBpAE64V l5g/P4/7El/rF9ByDAepTCYLnYqLoYxuzFgQWzAk+5TzgnkufsZD//tkfZwG TCPOFSfAchGWkQdBmfXKF7aID8akePiV5fGJ5+bAZgFWPPFOil79Vr9K1qAx vp3cMPpZNYPQHEacREIFcK1sQvrxpRT+qLTbT/MTCumnkFX4o0qu+2mxnEJH jP2JhT+qa6Gf6tIK6yGY3MIfVWrhT4W5WC29kH7m5hgaLvh1PFqHHldg2U1Y K5jz9jO2PjmU0SQu2VMxDLHsHCmQxzdYn5G+0tXWYiQWaaxk47mEDvCcqtUk O9NH7o41TTK2qf2XH3gzMbL5elULB0GSdvOA9F97wHaI7ZtBOv7oAkj/ZYZy S2/7c+12anHVn7n00YoWhy9p0Zes2GQjUTlOKiKD0cmOSYSrlCOYEeF5PEJz Ev7T46wUyGlf1VSpEdtUU2dH97xWuXmFI2tFWErCVMoKXMgEUJcyczfjF4kK vLBZg+h9UGF32TSI2aVCUUlOR8dyIjcCZSTtqugmpVVB/w+k4/AiqnXJSyzc BvjENm7RdL+CRhgcF3eIHEWB2xWJ4UifGHaPNLy/h+6g/GLl9YF1THBrTH6X i4R+IbO/nEw5DnBQkry6CGVXwO5Gt2GYoxXJRfDPwJ6Xo3UoMCA4cMydLvze 5ZrmCnp6gjCapXJvxNWD8NCsQq11CBinXvP0uUD0TBamz505SokuiBHSMo8T SNA6bOD+tVhUqNSyE64jrIjR3HU+imXnVCPxTuo8bMvxzR3PHI6peZnFwQdo SKk2y00OXaLYzu22cSZllJmcgbbk6keueGl3lHiTDN9j2J/KCWW/kxJbR1xH MiepK8BYQf5oo19shIZE5GKYZTNaUZpOx5esVlFJ592pjKhFSXwIQvJhcJLu srMwSvDKjG14+og88OiKqygBl07LYMXMgl7RNxqsCNSdZkSmZ2Gw0O8HRb2q PSa2f7i9BrUewla1tFNElXGsy25v3N+xaLjZcsX2VbHM77VNgN4plAlVI0Fz Yvmd3g0qoALmfNt6a0o9X3GpZ7GNn7exmoSqFW3J85qUuYT9JcAzYzApeNH8 14Liyd6ft38M2v8+bf9/3fazv7f/0fnp653tvcpHc2+7TospU4Reu6HIctWU CVvdwRwz1Vd+K9lUNqFdfHH34FYwGq0SKnRqSMaxsGvF7ugAtFY1bnHY6Sph RM1IGW4tWo6WXSmAqBEtw62g9YcbnuPsWCEo1E4uGLKe+ayb8dKlRiEwzi/X +KMiWrvPESGIFhyNuZVp82kujPK1Of48qayUPqwLp8nXSy+nBqaahRU31+yh n3UL99DPetV7lJh5S/hQktcCtXt4ShYr4ON1oWGVIL8SmTYKk+u2s/MJ4vN9 zLeLxozguycYVz+cgmlALikStIurD4fIbPj/qVBfLD+zOnnbVBIyvsc6l9mS NYKcjaccteyo372vkBJdUJuDxdVfYro/mcI+o3jXGDyoMnxpbFf7l3iC9t91 nhw706YR3aXpCniA7ldBll9Ldhxvv7q+3vEj7T7rVpH6QqCzFWjgWSzEQas+ DHKRiGFNE26mI3YA2FoOy9JEQFRpJgOkDtdGuMAYizxQo6/Di96jtbCRO6kZ B/HR5pavw0gHShUb4UGVPFHJjsWbgoXxESYXjnuHMAdjtazM+tirpWVcvYHQ vhIXHGgOEkZ/o/owqf91Eev1lGGQbbF0AF0LKJdcpot0luLQjVfY9CTt6FZ+ wCcIUnNGXiCevmD0oJpJlZphxetUhwjpogKh+1c63oxXKcxkO8sfI7kWZZpt yqlqbtIIMu4SVJiWeIj3l1SaRW8LcNqBM3mYYWhyNqYQV+NHzWwCVhLRPesy Q2Pm48EspYI/6/H+DfHbQNO8XoIeG1O2IYHQbL9WhSFg43Hi/RzRgH9vbq4z Eeq7AnWzUBMHZLcph3q6EvyMhNOZYMM0k3pKpcTDCasnXUNjHarJHMImOsDN FmUh3ZXKtsUotvluQIv7cJZSXQ9qCbsTWKY77BFR9UE64m1isyqoSrg0nlN0 6GoXM1bqxtWk7Q50+GJRbhmMxD8xgTaj1PXMXsDpwcP6UwRKN9uCOEr+MSJO fgyzvMZqwLp4Hl2S3OUgIhJPQJsSkZsiTDzhqypxSkNYteelFIv22d3C6gZP 8lF1O/BtBBi7SfWGbbEqv+6XfD+D/7HOrtFB9XlQjVumBY8Cp+CDXoVjWJgo 497Y3sgyOvtYdUuF55Vtj7e2VIxERZW6GQClQBGDACbCIYHnRHm0nN6udseM kxpxerbf3dWv4e3qt/A8GhQfcgnSx8/CUA28gZ2Wj5XxMTtruVlioz0AU6X2 9oCSegpMxFrjs/sxHHtRK4hhGsTvseZTI3f5jt6M5PTF9d7pzYtrOkYrjzeG YI+co68J/cHZxdyg8xTO77BM6WWrKRocwYT28Nj+qTFoMAZRkmp3MoyUgidA iZuD5GlExRXRlMNQXbAQkLA8pWBKvrPBLDKiU3L3MiYEt5YMFVj+WQSpOKkb lyZkFQsTO6EVNg3DI0r0BMBGFyJyhsLRU/iLNtWVeOdyDSk2IPWOWKvW8fzu 0lcmEO8BwvtZMsvaSMmqk+sSaEEyrXP2nd5Rbw4Ds1xXatwEeUiTgbgAdU3T C/ttG/OcYnz0AQghY2f9haHtf3rXbCA5fBrNAZNiZaykQmoaPhXml1esm9sw Dsw9mY6nbb3wNjUQBbe4oPXo5rAeK2g1kJwkgzZ611AsNkRtZkoYqTAVrVpD fpfJvBVsPfXo2p3l7eSO8hbELie57IoPYSBewAEI9PNrgI3PdZiLp+0Xr692 /I6vOWOWONnTRxXEa8qNPq61HhRQjmC1NUwf/QQeP2taD0kwaU8k1o7FP9fe Kt6dXopLJynxnLFwte9z4PcVl3S/PL/aEdqt0ShUWCW6huzwy5BN7/xO5Aiz Tpj+DAZwcWVCjNYYB/nobFWjNdQlOeuc+khNtJw065YoSaZoj63NVt9xMqCC OeFwFgWpui2LHQXjHugIN57ocAIMVZxKrMx7NLKUCaF71tiltj+/WKoURuzk JZcmDM5Xnv2DHfZtMBb5LOw7dy84ZcqLLxBW6WitgPpnr3foccGk+aSdyXzt ObuW+KQX4roNJ/himX2pZ/v69nKndDq0p/saWp9qWgsS5injvtgZ1VfEveMR 4RKCWaz+KHHGQ4dnor53enMF5trU/5Pj/fnUyI95GrR1kMry9JwX+i9M2+H+ 8QKsytjTuTxVykW6WVb12jDr7d4K5LxTuex4b7tpmqYRWN+rEoWdPwNVMh4H VKJ1BXnSXZ2FtQJxLnXl9wEWW90qjNjpXB13GbIJ1nUHXm5Uq+5OnVcHKN7Z BC/pE6kp1E6HSycoPcOwHEXxHV0TO5HGVTPshM0w/2R6BqUKzuuLgw0NTkVx 3yioepCS6oYY36MZomo2mtF/k+C9bHMIQXuQyqCaD1cZ68ECYx3RCxRt3HdG 7UE4CtPNjPaMX7a4QbiC4LJsB1F1cvWI8dlNNc/0O8+v/4VJVTRSVbeyRwzl jtJhBzXWxZHHuqiwBmvYfA7W3BDcjbBmV6WWmwcMwqzIFtR1RqAA4Z5mzK6J glYPrpv+o8c4mHDauxiCoOUF/toejSwmMSyyunCE8L8SUquoqle1bnEuF/Bd G7NZJuG/MT0my+mS3J22Gsx1swfzd6ngCYTHVQzwJtl/eVzxiBwdekTNpTJK gtEmqWRzO6DJR7D0dKUGZ9qvSnXwkalO0VKdgQVeLt2yKvkKsM53IeDOrePm RqD5HtzfO3X0MQBipu6C1hrIxJ0HwJFijRKn8IdwMNmxbFaaJij4+Bv62Wxm 1CYlK6cCvrAeGE0hCnaDwzFLGI9XGxwGL+VYX60i8DUkrHBG5aAc84ARxsqM k1FVszGarUHFDqt/DElRZhIePbeDhJ4iFKJHRUbRKq2hr3b3cp0HJkpIBR8p 57qqqmH9rHwJnQmDf/CohAdjHd6cX9dENxzv6woL4qhzWDM4/ZIWjA8Ov2m4 zvC2Xs4bkR5LSwu2qqgMI0Ls5OAInOe92ISzZWsCcfUSI3tSME71fdWFqpOG 9LJpE1sPL4ed8itDdqhCDRUvt7QU4PvG6H2hAFnnRSMTJuNU3BbbqqaIif7k 27QS3WR6hCNX5nZU5GxAATOUE6FApDKfpbGd3TIsJFB5kkzMK0mA6l945UtV QpP4lHDNHdLTo2MybFFOamVD1ypsa06uLhtzpb0kGxa5sM9fB9XK6aq8SZLu oQVGhUgUhHEyra8+ogNcneEXTqTZ1H1Yqk7feA9+9NaBioBQoX26invNOdDB llLR7w/S5XSJmAYfpSwhdEpTkLkLAqn5jUXIjMMN2aMZjyVBiww3NHH6gBL2 i9dmeKT/+WMFBLA9wTI+YYSBB/Ui2MiLYJAl0Sz/NfEC9jhNFDFjtYGFMaze sOzAW35ki4/HriuqvWrG5KyyNsUmpYGKptcUmrd9YL6NqoHp5nNW5HcROBxw WVB8S3DhRYUU8NBKjyjph3ZSLXaqjLXHNWhRT/enLtuLNNVz/bxcV8ghYZl4 R5eQybqUUD2hBckpBtNbehhl0HRsXHpeAucpNG0AosehYX4KZGAQYT4rcqdC ZxOHinQocLD3yiB1ywhyM3xNWAX8oc7eDjHF9HGH3jVStOeYi5arB77aJkwD czDkA/aaPyIVLC03NygN0WYNmo8yQc8u0F2Huh5SvYFWOMPOI5dzUsvn6HXI tRA1tarWceZQ9yTTocezjI8WVlWZamUVnWKFBhOE15BerI5vJAZgLSq7hgTK wjb1OvSqLtDn8VlbtKr/3SxqRINpuCvjcLO4GyQgxIsiDkFYFZMF0WlQPKYg i1za1HKEjJJIuFhu/cgcVH7lUqLFNzoHn6nygjYq3cTSM1PzkTvFqzeKfqTr D3s5vS6P53C3ga+LDGkuAxtZtziGGh5xqNeKDOKoLj936JVhe1Qq3X8U0dZq 0xsi3XFgUEkuvbrmIlVJP+83g9kqqQURFypOrImcYfkRM0TY6ilUtCiJS2FU ILzSWEA0m67DVbZx5rHTRbYmJxnhfBYuxToNvJlZueS6+OX1uxT9Coi7hr3I lkSiwdeoBpLnMIbzXjhigV7FWGZNoRJKLKyCqVzjh/HhHqVJYZIaiWw8S9RS lAhEUu9B0c7F/c7REoTjHJbn5zMQr7AsQ31ZllJb4mPVc5FKgtFgKufVBqOy TIEq5tLGhKKSaJcJreWYKqmSqadN40d9NiAHAqaP391xoARWBNTVXpagLYo2 RVsUlQ4tXKbLJbBInkufizSDI8Zk+V29PHMMxrNCPbiwErm9NXYYUkPXHJ4w AcqlXYQ9TUOby+HywxcwtTjt1XuOTVGuIH8WujmC+nPQbSCvQnfFPJoXK7iQ Vqk8OF/jBFswAKtIV12IYZX6WkaWaHzixB0+WZ0wlVbNUYebIm371SyKdlSG JpgX69O3KcoMSeZJUw6XVJVn1yCUYxErRtKqhPb6b50KVJwPvilSZzHG9Hij J9eiuCe+jwvRQnYAa1A7+FzEvtg8rYaznhjQdaj9+vOydvPUfgbe1sdFr0Fr 85Iye1gxPrqBSPaILLgBYaiWpUW9S8XBohhg4dTRKr6tVcr1cirL+vhBcD0n NH5PkdF64PIOTedjzIdyCF0WlR4EXbSlUj3DROBpx68WOrQgTV9b6lQoAnnn xhJq4/Aeb9jIlCD31jgoZNVR7UCMYGaPuS4TWVerUDTYSRFXxNwYR07FmySj u21H2W+/Sa52TDFLZBfF/axCLw9cXT6sRaeXhesR54jYZxYqFXTrq2SsLnzd 4PaGOtULDEeX893EiGI9pGqN4OZRbXBYMM8YR7kBEWJIGxUhf2HW1chDWFQV le8k3VqpmJY9oxp+qxA5Stpxkrep9G8lFWwpEs/eXjsiYDgnBnIY4P0e1QGN yWxGXIVgQZ20u5Ia4YOZVnuU97qWfJcKOGEIha5uWxiLLjZsEyuEMBQYTiw8 JHdMRdOCIsPaSiYXr5Blj5DOgEygmQanyaHokpQTD7JxktBBRO/tc65E9UVl KmXxxrtpHLV20CmVgoVzeWrTFAruPgrM0yUqnSfK9FD06uXnU6kiKXq/1Nq2 Dk8sYklPj1FZ+qzwbB+PhW+rdbiAY47UG2JV7gwjGaQbY451emJAIcHO1NNP HDTMeFakVc2kY0pUbbhffFJljJmd9pFrRaLzlgCuWapvZgt/O1EGrjelZLmt OrufgWHzJlqhpEdBK+byenPuNx9/dfPeMI9OQrbGH0aPLBem5Dx69kw/+xYF mzW6+7ayZBSPsWwLuaNU651VtiytL+sM4FU4Tbwuqrg61ro85R7OUYaDkdMy O3Z9K01/xQadBRLPokhbh8p92jBXu2IWRxh54lb6l/+aMbfLB6iqhRbCrkYX BWtMRa0h+dubiiKA1abCwkAzB+OsrGXHNegoPY5N/CIMLCdRqHP2xedSfpTp MMzW3muLSjjhBz7MK/Ih36WdXt0Q/bNYxXs7mke/VsGPIKQcQdtRZbrpyduS X4Du6JCpFoKq+ZCu4xigvWOz3PBvSfg2AZWes3tT0TRmpLvFA/tu8fC1K+BY w+PedTiJelfN67KsKByE9SMMtqZNYxnl6l0hFltJ74KhdJ7ycGH5L6EPfTU5 LDHTbFjwcfrJrN1lr+h17TbHWIqX2CWS7Z7Yvrp52e75CwDNI0l+mEZrkHSO chzLXPwlTPMZOVrDD5SMHsZwdD3/y9WbmsJE3a4nfclij/az4Rp0vQkeZdre F0Veie03+zcvV2NUPpqsQQ8WK2mfhVx0q00Ph0wj+dESdnt2uRpdSR6vQde7 27dtQM2iHfnvPY97BydNFIyGa03VGb4Q9nIcUFCAfT3FcObsZd2UgQx5nPaO DK0pQpPBKGhXJGhVAbpbi5pX4QAEukzMqwWIaZXuCqBNQlWZ+Y55CZ2oezqB TYsxoYB2Slqs7LwpUjVHBdJtue6xKh1Sq67VKDGabxO0TEcVv+aCZJy+vbnY O7+9udgIHdnKdNycfScubr9v34rXnePusdgTN+/ent8KpE/c9jq97tFGKByF 92EOhsxDig9hpCtSe8ZQxA8KyiYoi0hfrEgQKxuxPR0neQJG5s5GSLpDpbEi RaRwNkdFe6g0/DrU6F1iE1Qlo1klyndBYlDCn4l3Z9+/h91JSRLW711g0g4P 9j17aZEwwIXl89djmKKRYS3OuAXoi9CyW1HKySjkgpYnL/Z63RdeljXYii5V XPRAl9icE3g1qPOam0Qhikd0c5k4stpEYmnPeJU9uvrCjCOSi7EBHirrlSj3 ViECbCySg15VYPCFYzvI0+xDNX54QdTmhQ1TsrSEdLFMSJcV6cpsUIWVdaBU ZfhVjEM4g68tAYXJR4iLTz7hVwWhq8M21DXYNThEwqmg+Jent2KVg8QpDL8e FVI7Y2urQB94JoMj+WZYwXzp6FyOsqO+1SEy4DAeRrORVE/duCMsI64d4gWD UNgYUB06+XFtdOcfa9B5GOo5DxfpcN7bXowKix/Lr87DWxGpFYsl0HJV2ez+ ElQF6LIiqQtlzJ+7ePwa6vikLolB5+zfV/XlIsixTML62MeebI9FsH8H/crY a5GMZBQ8toMPMsVXBVZBVwr706CoahJB9zsNvBZYlTKqYzSbbIIyDWptypor d61K3rUu2fVCQ91VG1C5qo3eg6jiFwzIdBA/XvNTfj/hYGfslXXqZvENtn2W 3T7JnicNbw/M54hOQdcaOFuJIadGK6Bj2aa18w0GPr2I15wKxchUezSedps3 HmJdKrAIFqRaKdANU50ADRM1RcUhKHzmVtq+mVM7hMoY8lBSDUs4Oq2kgKF/ WwFo0sIOGhCpu7CY7eOjpJZRl2HcfoUAyH5FGky9ggWQBx/XQx58XB15Ckso qeqgRXFfc/dazIUdXRdOtQ8zLm8p6TKppccdy+t6/9jnH3UpMBZVKcurjsr6 7ZjeQ+GX3G0B7hBfncncyluURaCfxdJ5/oAb+rEunOD7WfRCBb05pp5KdWrn cURPMBzKaV7rssaR22pQvoOKnwvFPLwvywXO3PsFuaDNzF8NF1JJjwarkYtZ vNp43QGDvVx4NHOIBZFSGwKzaM5v4ZVMA6QpKgeLkvXFO7CePoTygci8SkHw 8B6Iwq/pHQd0KKtcAL15nMf3YBrI1IR+loLvc7PPFc58tSP1nBLeuaPRgVXT aRR64wCpVNR6mLjwLgLyWyT+spdk020EM0Gai7qyZbgFEOhpjGU1N72CUa5Z 6bk0QtjhfVyKJ66nof6kQkAyQkxxFwsiVxX41kSuztoKGD8BMpbD90sQwm8j lnJu16DFwluJnAcZ3o/n1QtdnBoDbiFiWvjornp1F3SQNfzpEWTQD/wCLz3B qz/CNVI+xnh1Nix704dPI2yY38tYplxHycAxxaleYTHWZCLF+xjT/0d4lcsv R+VyOI7xbXfYLnatiw0fR4mcNAEQjdmQHx5HL5sxj7mkJgoOkEPuYTzEOEPR AGgFAu3mWZUZ8N8Y2S4VhmgqtqfosAToB++DGbnfsGBvkKu32gvROgWYSoXg q1lYBjP1sbsmzual7YMHC010VuQ0UTscJ6FzDhJVWu2DMsBknIbqLGhahQJn v3w0hCKpHAmmpv2580V1DPr2voTssVCxjunNrCT97PSPZHDn/ULNrMvO54Wv /fQQTfa8XDpuaUT86pZLIK/14m/8/yff0uOnreYsO2603pIjGEtLLl3WB1g2 0kxJYcnWrpFdkeZ8h9MnIoIId0weiQagFptX9N0hryD2PFpX5HFsdpL+R4h8 /QwsvACMhG5A/hXBxpPlkKxXKL8eZ1o8r3D2iXrp9ImXt3j7jcQaAIau0gp0 F1eeTInvbd6fYYxp/VI7ZaFh+1YXQFMAvHJcD71chswCEk5bA8wMhZioKkyn ANbDxvsoGQQRfFdlYHeuUJ7GLn5Mg4jDf82wjJz6+JEemmb8HXFxJ5JJmMM6 2nWFJ8zxgDabKEWk0ZshagDi4uxP3dI0qTEO4dQQ57/UCBn7yuPj7g2jcwTD Mz7nW88i8Eu/O8QfsEwOEQYqhrP/lCTh27boeI80BaSsC+H4okDcKKQA5hm+ O5uB4swfJMOeFJhTBqGJxcqoj9r+cuGGmeLgqG6VuvvkVKaka/BwpbyoTZum 01y5ZrN2Esv2Q/CorguiJGsIWbty0F0yuu2ryx33nU1UhKlEPlKaJUU4my0G 9xc89g514gj6HTKOy45jVk5ZR1xdan+96kdPqLq7OXKpAMjZ0p1Bqu5qqJic 9iAjfF9KqCA5LwurXnw9fuXL74t3N1evtB/BdSCI7dvzHc2a84+5jDMakgKA L+IdHXf74uKmfXGzGoDjk/2DvnBmoo3H4BEFyIgbqau8oxY+N4WqdfeEKgnx dqBKyXLPDAMvr7Id8T0+OYR8YRpUR0uJYg0t1oLomOVKi3UWxvnBvrOE0yC+ l+JJt9PpPT0+Pt7vHT0pK4CiO4FhK58EvvwHp4V4+IiyMAmHKb6qjdkUZrI+ 1dClMsnwhFmgUBW2y/q+RWH6PJ9Pm2nrUlLcT30o8odkpXWnlvnvS+5/5JIr SM2Gl9wtw15pyRWlefNLrkjbiktO64UF/DUbX3G/L7Ff+RKrbh+1YQrlg6R9 wyuUUrbvoiSAlajlGMzoPBNPBo9Y+weDoXkVPbFyruzX7sfutPvEI/72cH9d fZaMT/mzQZ4GQyy2T/c81uTEC670A0ltxkF51aiHbf2wLmZKAGcfd2x/GxGB NyrqfMKPeuiXxTCSYBLgw4ipCEBNwE72f5IbC2IYgUUrmzbqKqc3pUIUa/kb H2+9PPXqlxLNJgH6VyQepyYpuyQflXedNMftLNkeNvRlwq8/j5wvjR+4cLAB 0UMOKjcErjXKp4/bOuyV7+5RO4EmJB9Z4KCexaNIveC262SWW6wV+gvY4bik i7KiUx9mCM6YJNAeWE1y6JnTLyiIvtlbRBJnechOrF+PIFrdwsQFNt81lerS 3eS8FsTQba/mlGZyO+zIDu5xRiZDPspTkGa607EgSLpKQjXwElQQK0ce1TMa tWJVuSUp0N0kYdW5+oIC5p+VBYwpTb2HlHoTSp+SPKYI8DRN8hwkXaPofNZz ZckFtvGD5u+WgvhClsLvu+5/3677+/71K96/ShdD6pi/1Eagz+7LbwQb93Y0 bQQruT8W8PONQVzGSdRUcu61BnDHfjmu70ROANsbvzPCYwL/tHdohvXlGvZp p1XDJKo4mHljstgb7gSdGz/1WwmcdqxYaNW7wgY3TvM1uN7WSd5dpHVuHHtb 66+EspaLRGzASyLWdpSINXwlwuORVPK02K3Swl1K8SifFpAIJdHNEqHX9+8S 8YtIRPW+Y0ktSvtE2wrCwponTaKoRvVosJ4gBb0xaZmikPEtfBkdnw8L6bW/ HA3mSHzzJ62YzWdbzs4k0zRJYSQZJhJa5tUAGwYxhgfDHk7V3GD3LoSflBG5 QSY1t97mhXF6b96L1L7aOQeJ5+LArok3v6+sz7iyPFebyd1dZgqs4I/fNGo0 jtzIpMWDRd4xZvO4NV56jEZ8UCicYdiaonZVKaIhlYXNP5xqvMfBfCovNEh8 55KNNyRQYTRPxsdI+KQ0A4KJzmqoDkZUfjmjPKSlaV+ZdIN2LeK9OmBhKeqJ TgcT8xpFqLe/8hg1dWawdPJwhltUVbSEy8MtZx2I45NedxcWLdfre1rhS0Hz s8ndxtp7dvz1O5ux0eeP+K64OqZBGgAYDIMOoggM+FmehSOJTpMZFc4ZJLOi aqZMpSiid8cJVKiyLTQnyEVDVRGpL3Yo8CuM24X2SRzxs818nNXyNVJrm7NV XAhBBHp89GhopVMx4doFMMkkiJIZun1i+Ei9pvyAiYODYixVGt7fwwSNqiLq m4ow/sIzEca/mYlQpLrzoMqabpv5aN9FwT3XmpSjnQIUz0QtOzuYNxZhjU4J v7uKsRAFPCckL7zTC9aJpoNDOJhdFWaU7BVdWtzMJreSH4cStyS8ZDfEOkK6 ChuWkj4nck/s7S1o2JZj/FTmno4FaIrvk8oKaXPlClsAoSaLULdX5TNg6Omj gaZNYhXZbTOx6s5XdQBNdjSBw7BtzuQGYYmTkUtmUb6aWqmNjL4phIrij74/ Ud8+L3yJNU+xZjDQlc5k8bumkO+xdMNj1TMMI6ndeJ6IZ1cGHJphIO0CN4tE 66/LlCnnJed6PamlG04VnA1G2icBZo/Ne6RVggod3yp+87h4Bsudq/Y6cUcl hPbNC6GHnQO2i/969ebi5cXtP67ffQ8sAmYp33SRv1xS7LgvbqiCER3Xvo+1 AGCx0/eZ03mranl88soXnvXny5enlZor+iaf1osYfbcZATtnzwRsQbA18Jlp muChzYrdb0iyapMaXIqIvZ68hgJdIIf3CT4x2EAZnTzdGkCeZIcyhXVzYdcB zUdJpf02F8QsXmxJNLf7lS4KzmdKJgPVogQEdbWGc3FmDCz4iPQcfKTTG+Hs YVMdKmAsbzS4Ocvx982pTPf/GBXiLNX/HiUSZG1VgsenOsy3fqXh62zmEQDk fdNipSXBi+D0Ru3qvx0pr5Wh01mewEkFD9M3j1kuJ81S5J2yYr6oO12cU1ie Kk/WIDYpWPD4w/eIspw26bqBvKe927GmqTqWIpa61ER8EDsdqQPOnLc4ERu3 V1hKRxuSBYxG+ei7W/ZcEtvDzrULFoknMLwVMUS7qVgGOLuLOhspBR2FWc6d AaqqcQXfh25OunPZP3ikXgA/Na8cpzJ65Fgt8V4qj6t2Hn9a/iRX4NvnPMct cgTx5Hua+fsN7rJtnG6BHpnMRzbVuzCX4uS5yRqUTUEU0VWFDKNOW8Ve1fqy u7hFHHafdfmXo6e9Grq9C3v+iXHjhzI/9shu3XOE5Quarm9LxuIaB7v/Pnkp zphfXn6jZ5ZNnVo2dm75MieX3/Wmn+6FjwhpyaJY9ICwgIFfOhXUWvslBlUo bF6vG7A1a2xB/KmxOH+rgrGQpayY4rfEstIsVE1lZjs+c4ynEb7rvUuq5rLm Pl7oh3jOwGauieyAKBrKEgREqocoLd/xU64ym+FzZrVzbg8DiZIRdcNML9ip 7h2vnBIKqqe4OgrT3YeiHDL6xBDUHDj8w1iaF7tJKJmhzoD4DbYSaicqerXz iD136KBjJTt25ogckp8i1vI65Qf6NAEc9rQdJ/l2p7PHLWQ82tNLcc94Seju ckt8Xd1/kEC8vNz2dNrZMu2/hlbAHPcDwDwHq/iT8ECdB7SGmOYRLECKKcQz f1zrc9QzghIJiwShuZOONoYhiKd+HHxQ0eTBRFqX2IIRYVSDK+RIeUJh9BK+ /BiUl6QtT2cpdEFwc3Ufjv0xNCTSn7sAnKo0YGVwuVPcpXadkqlPzFCf6KKc oALtyDxbjn/F2Ncg/OuFRv4LrJg6vL/ImmkgZtVVsyJffxPrhl4IWXC1PC+t FiviVqx3sSpRZcHYjnbpLS//WS6taVc7HmoF22DKMRY6yINAZMYRZodY0AH6 G55y5DI7uDhUg5lNUYhAWwYbHWCw3akQMs0FmMm4QWpYctqhbBv5MZhMI/eh VHd2/+jMrYzp0dXMHfk3ouvv+M2cjn8UtgrWb6iAXimm0aWw13TB4kgvDn+O ZfzJETi2QrFnexDmk2BatI8e4Zv+WH5scz2teQYaSVoqqSDqfTDNiqLoW9KO YOSVBaaP4LyC2DM7TTJ65tl9xPhO+2wV4Kxj9jaTU8ZpYYPwHrGGmDrpQLAj LC2Ny5sXeoe8A9rHYPTpONxI3uV6bWFmHKiCf83wyOKAeCMD0jT/lmkiOH1O 9dCpSCaiahI84iJT1c0sCLyUGqTyA2YR20/PsUQmTFhbs8PkvLlTaYcF4Kcc 5VpaT4V+Qj0VxTmqRmnwvHVatqu7srmomj0VUeM/9Z52u91iMJlL2p+6H7u9 Lv70qJBb3Hcktl0Y2XZ3h1QyKlrtqaHHqrNpwnp8gi8hqqkvLBIzDK3Y+4Lp +lpsd8VXjsLYEcUQQtUOma8XoG38p16nntr9w89C7v7hXHqhSR29zqnEd5AF YmsOsApHMY3uDR53jK53DkJ646TbkgcMmuTlqCmdcPbfhOoMUSIGrdkk1nXy deGsD07OfHlLLOCbuzV6aPRUuMQBVaA7ChqvfbboELg1d4tArMEgI+eFZlKb HAATLEufcTQpxreq/RmUpTuV9qWA51y9+QFj0jGE1QzD6LlKX50e7A3XdqnE HIyj42d98ZpLtYq3oKmT9L04j9iIcFJbztUbhy4mlIPXl1dvbtovVR4QEKVg uM4csnT87pJ5TpZCfXz13A07aTx+lsI7ADoF1uR70qe+K8rqO2F6J1a104F5 jhw0PL8zx+y80F7azHtDiZLigMwKd5v6kQTt0qUa6zABHhcHV2Wv+jhO7M5d MifKNWHdJ9BU/QrFVYZd4+AoxccW35+z6/QBbYQtOGa4jP+TKJ0otp7YEh1N jyI92Wo0SGy9ZpXfr183KgajIP+Lljkh9Q5kocEX3/rb9OD1O1ZLDz70vB/Y PPjSQOo2kWEymeATFkZjNOQuv6S2wm1rU+BVtTfcGOgVFjOcwOnAX6Xq4Ada MeFlxMHcW6rcmD5hLVjR/hS0JFhvWV6oDYGVemHBm4epyu8aKEa4F2HTNMml x5/boE9K/Wp0iir3q0Wj3GkWqz/smbUhkdASyWUgYOxhautgqEqW+jkzK53G eEU+UGpHPjbS4084PNzv7vcpYQ+n2CbfIayb2XSapKj8LIrXtnS4uIQhh+0r oDYZJlEh3Y8SDWkD2ul45oLfcZ2mYZJWyv+QPnQmwWbwHdfWNThudhFzPRAr Qvz+rkZf5VDxGdqCBqesj1+McMS+Gt3e14wX3Ex9j+s2yH7p3eC6nUxld/AT vOZtYOf6y1OEg7ospsluGfzn1GTYQSsyT113p0FVBT+vDE499mJaKCVf3KU8 A9Xmvr0mC/kNwYHZU0bm6gV/p31OZeQ4ZmNZhVYN/NI+qihrB9FD8DjH1l9l ryfDy0Vl3xErYuQDANn/1rKlcDIsrfNI0WJzzwVFNmqu45GckSncBSMbD4Q1 O49ZeMVbLbPmyvmxDffl58WAQcWqhcLu8Get0DsCsHr4Hf5YBxcthWqmVlmh VOddGzpaZr7MxGuDzK4d/YKSy5+GqS8NlZ5TrkqCX/viT8NTzGXWetSwz0Zc SN4uquMm9B1xpnCELn+8U70h0b8uSnxRCv57VkCBR+odGrFFW2FJJMh17bzW 7XxjNKz369L+y6+CecMFnQmsgVQ7j/WoiCceNJ9azX8Xy4TGwgJr2OFKeIow G8K1Co+5OEWoSxHb+rm98mBUbENt1kTN609FA6DpiDp38+fm29lOmTk1Wz45 7Gu2/XotXHi03qOCaxRwzXmH6Ze+Pa5sxRQOOrX7rlf11NSk8G4IBaWj9cVC qmZNRbOWmtHS1bjJNgqd3ym0tNDNszOXE7oiUV9Q6Movbf8udMsLncOLhl2t bk+bs6Mts5817WaNe9miO1lxj6ndcVbcwxbMmlpq9/JuV/O2KAWz7Xo+qfCG R1tU3NWqYbnKgq1vVwd0IbA110YVoKXDg+eioJIeydrCi7Zs8vsuLIyQzbH0 6y4uFpaAJS8xiiJsSrW41xj+GFQaKRWHqbDUWU5PD4smfqX+U1OIuK08g5pH xqN2nlA0SXEWOuKUL+9BQYbDIC9GiVMNm5igwOLiajZROAlzM0z7eqzly6rL ofBwt3816CVJIyi0dxZFaVW4zRa4UOUdBKNt72Yx+5DdujWBOUY50+8UNcVj 3WSKmZu0e/NWh0MNNOc1hSZwJ4ju0R05nhTidmru/jLbvBKRoxaWK0zhXftO BvQUaYXHaqm48rT3ldCPceNmpgBSpRgju7QQqmBKC5JulP1C4ZtYVzF4mnOJ 2rr70rp1DqO5DeUglcF7fKu+MAxnTp0mP9cRWT7pVN1xWkFYcGDRlYZBbWyD yl5KTLPf+xg3L3/IS4kY6tfXyR83nbq1BvUPRimApvjXLIiiR3EXfEhS9vQj rCmVHoTO03D4HrZcx8toBkdll4vE11kL9Yqcf+aqc/4pH3abmbOYgnfEobOE leLLz6BFafRJ2+iThRdotW95sVaUVa2Yz6FjbhrWKnqRf5bVjm5frlxZId0v XAuI1sA/JV75qrpSSg7C5K4N5zK+tR4mWU7bWMNyBU1eZSIJYYPDZXH3R2Ez xbKlcZiHTXW2qRip07DZsLQN2yqAtnEvLQNXfUy8Yun4Z0zNMppylBJ5UudH KWmjMw4mWPOcgT66t1lly3NF77LMklk6lC7dn8v2VAXsDKKipPmHVjI6yyxV gwxGWFOQ5r+Q3uZ7INeTJ2XYy8Va6cg8sq5uerG2PlWqUqbbEYPHNk7gkqLG c16UNJHlj5GslzdGtISw/XeKWGEsy4sYQqljqGIpflpQd5w2XG6rWFMMy/ZM woV9YLo0D4V8tUYu1Uxl6L2DWEj7oqdknuIlH0KzyiUwlKG6yAoggNM0mWLB S9l8oLeQ19Gv+q7c6CYkoenqfEMLYuEbvSUWAoayKikwo5AhZWSqkRTXgh1V rbZl/pY2SzNInIJarfrGIaX+PqxBf/IE1yrP8gmGBZ+wVUMISgA3JDEW5W9f YkpjYbkpykv1MnyO3BTnzoy0qhEbNBlRtKoSG4XZP7H0RCx9D0wrpVNo5ItA 9kCx9SAqeBqvHdCsoJ7JndkUC/CdtIUf+HxhklCo5jJGfk0CmDrEu6tqBzvk RfKDm7JAL+pKFcMSqTrj2B0r8HdqUJhWFg5jq2ISyQeZpvTUGZKSxLIMrvBq lkv8Vt11lAqUqsRCLfLujopdVXc0NuyrMcy8ITxLfVnv865rZDfguhakjZ43 y+9CUW6vo2QQRGq5NI9cdWnesqtIq86uemSl/drlbcOMFprXLuE6iSl0cMyH BTywTutmrlTACsVaLJmeSc+q59WuPYO2f+3lxNLXEs1ex1/iMmIeTaWzXDAc ziazKCBPRs3BznePUI/PhVi5pyvXt5i/bBsXrkdKfPGaJZJdg6LeB1u8jlZW XCrzWcq3tO5s2XjvQPlj8KUX3Kb5fb7oke+MB3Q/DJrfFRIjgy7plTNPKb6u IcKuwQLxR9lVx1YeUNEKWWZ0tUFoDVe+DU7E1S/o8WftELS1g9CKy3ZOKKbf 1PrU+uPLd2fn4vzt2c03rf9rflo/98UfQBu2QXPYDKkwj+SfcInSp1y5R/zt 9O1rMUlGs0hugR7/g7iiRzpRU97aBpfUoNUizsr8rk22FjZUwBkCOWPTPLOZ mXdJFCUPlMVJLbJ+q9U2ILivZiJNADI1Aa0BPO+0Wu6YeKgvzl9fvL35RtyF gG7LR8u3+93es3av1+6ddDAde6ulifMRjnKIrdpgOuHdu+h1KNWLrGVoCUhg JfSxb58e5sj6HydRP876lOrtg8kXcntfiWs5jRACJf1fnL49ZS91kGF0PQyY POtT0PfhR7FVB+SCWCqcrZIJp87M7xI/eWkpuPpTFqRyygm9R/NX+OmLU55p StiH6Zb0mKtQJpzn2SotmLemABSZAUl6H8TqvoGabF2c374C8k9vxA9J+h5F gZJjeYCksYdcIGHrh9fiBznow69/HOf5tL+3lydJlHVweB0AvPdwv5fLINv7 hpFDe9Ri0OGPkyCM8qSP336rm3+j7kXPR2GepAj2Nkjle3ETBKPyWjYAMvjy 23/O4hDsg04s8yqQ6+C9zMbidRCPxmEdHOQCfP3tMMyGSQfUZxXOX8JsHM9g vX0AFfQCmBpM6qB9GNDXzXR9B9Z8nI1n4mYcjOsgjTP4EqiSceCn6q+zO9Dp wNdZHYiP1KIThTOamG/v8XM/sIt7EKEX6WP2vlz5zYIL/zHgBt8+BuOkhld/ A/MeiJKyDkok5SO2+XY8Cx5kSFBYwso7CBcCUipBGQwZpZlE+hW1RNWc0NvZ 3SwSmDkldFVrE6VAS2aES4Z2MNJkXG2Bt5AJL6QZAkIDNUknahtRRRF0FvFl EAf3nEiMKzCDcUtxmg7HISae4W3e9tvLs9MdXVTgZTJ9TCl1dXu4I0DjnQhe ZylWfNF59CArman8YPJgRvj2bzCDXSrN7Ku8I9kR4hSOpQQ2U29wY/0j7n4t wfjnE0JIV7sjyvXD97L44IyfYAVJ2EppnLus93Tevd4WgSXIOlIQu7iHTrE0 ZU7ZcbM0mwUxVozgWgDZjHb3Asdgg5QxPjoG3ewZB3cPPoDfUNo4DfPFzRkI MjVX8yYp0gTfk471A1zisDPUXLAsfJKBtN3DQe4KHw+nBDzNBjRnMWUp4eZn ardS32+j5spQdSEYKa3yUoRTKrd+Y5lkUe88RERY2JKJPwFl/Amtqp/DMNR4 kGb8OMwzGd2RwkZZAzsLSY+THFDSrTNuJXvU9HzU6eNVBm1MCI5nSb3fjS1U bXTkfyonCdUOovI8AAFAyk4Z2mw6wtrX5P3AXwYStnxb6YY+U/RPZ4NIzT0D KWGxCLCCB3Fly27nW74z5BsAjzGquj0HhtFydWsTfv6dzz6UBJ+DJuBXkXCX zvmDQnpt2+QQusfB2lKGVGXQFEaaf5axr4aH1qwEJWRAGEP0k4sBtEKyJHDs gu9qDgNWcpzpWgL/qc5doseKNjqOHTlfqInBNQzdh+A1Jb5R0UGkniCaJ2c2 hhHYYhX+O/n/HorPQnxvMv2Aj9o7/SligS3ZjLx2HKLI0mMkJp1hnvAwTbKM oxS4OC9FO8DBFv136jgRmE1Gd1YgLSsc501HvLw1h52Sow+0KkZIZOxfdp9c Ry9kojWxhdbWPQf0xGiqUpFxqeK9Lr3VqF+z7ZSXF+cw9/YP+0LnIfN74YZv wQNWO1JVXwszMhj658JIZDWBt1aw3GnysQz3QOfgoYje6GjMUn8/mGblQWkn Clh0sNlu/b/QZKtW5uyCU5c/IPv4LCXT/j6MkgFCwXBKdhc3UTOZT83lGtRM YO9Zgpr7+dS8XoOa+7CBGu1xA3KG7yn9vVBToN7Ji2/v2t5UcYoglAsFLISK 1iSjIkefn5ja8VvMH8jzH5UKFmAhnIXooFramyEmwfcTM66svT2l1YRvPVLl 2yJ5PsqGbTKbl56DeUte9WSb3HGFrrXaq2Sno0mBg+5wahl3PQO1CufAswSf e/TpK0t2rc497gsXTuZYM2c37WaqJ8EKVF8GH8MJmA2nZh9ZjPG1IzjqCw/M pYaRbmQYZL1e0xHI9XquOjNPYVyn18LqqpfOPU3t8BqfobfXNcpvVL9Uyq/Q w281j9BboHooppwCV5JoJMTs0zq3yNdcPRvuWJmF18TtW7Teu4fSM9BznhNf 8DL+nSKJgi9BDhg/lenOYRbJNTwJwWrTT0M3ZGFUxtFWRaFyz4ga+Wr6Fd35 HAW3xd9uPfePb4ExGfCLDCb4+MtNilqcG5kUPY5felLqxrTMpPBAPgRpWK56 v/mpsaQzyRZr0yyUFeHR4Ulv13lBbn/pQf7C81YevHe6yqM+Pjzu0RsMJ0fH XfZr4acn+wfzh69uBKIk80TujOB8COifHpam+C4N2FQbhfdo+j597pUA0emI o27n4KD39HB/9fWpNh8iEf2KqPSHGCV7L7VbLU/yADbI4lmYfzCelsJWuNAP B0cMIqrsi3tvxH5UOlbneKcxZC9PWLqN63aoOOrB/+qgzyBlb5ReZmaU/6tp nsTxSa9rxLN92Dlcan5+IdG8ctj/OcSxxgV0dal5oAXA+MSDmrTXq0t3ykrx HRZlk+2QPyQ+20F9/Hlth2WyJW8VnZswKCqD+4UEbe6YPpsyNBz4nFbIStO7 AdOkMrhfenqXMk02Ob1fwJ5pnmTLhC9k5NSM/BeWgC9m5Ojh/xqMnFWW/6/N 8lmK07+wkE3nmS2LWCB5Edi6FsgKMl1bilvbhx4GzvPWlAzrqpcGo7vTJM8j +4qwKdfT7Erxq9EGFVouKWoWyHK+hjr9+clDdGWT/9xEL7uJe4iu27o+M+mL blMein06t1bfNujaZj27yHAMqJVPlKRK7cpeU6dW9Kmn6q1Wpyus7pICXH51 1x92PpO0rXyY+eQh+kut7pVNdA/RX3h1L2uEeij+Na7uVa2mL766vY4HtSTb 5iJl7kK/alzgMqPK4b7cp0brq0qIM5O2pJtqtWcwtZNZXizyxiVw5topz8td 5iu/hYxoNN9c4rRclGy3oq2rDTmP6fZpIS6E8a+XCVTN8AvwAN/LiTjmqh2M PmAaVEaRp7821jiEigKhm+HTgikUk2mU2dh6m0ShaKjJoqBof7zkDUcqlC/D 7AknuwEOG/f4OmCalRIlvr++MK+eUYTpXy/fqMbpY+vnn/FFgacnJ58+dVqv TCcGAeymJ9acRrsl6AqQ2lKyln3KgHOmJ8EIAzCRA8AjoKUvFsl/MPXrgNi+ eLt3yngtdIBE0YIxDcdkV3B08cJo3AyJlbDhuOrn4SFxZ9LMgpMCI94irJae Dub00+5+F6dDcw3x9ZWsVRhkiIEWS3GWEzoYrvu5ObTCV0AMxrS26qgo829Z Ysr9SzSVv/aRRjPwB4y+ntGLHdVFIgsR0Da2s5wf5IZbDsdyEvBzbhSNzxGV LVAvnGrDwo0ahSLDPoSBiFXo/cSG3k9N1E82G47RPHl7fvvy3dtXvOye7h/2 Pn1CK/L6/IY+h/n/f9BB0D1EAeDHQZMHND9UR7A3H7Hig3p3GActW7D84owS d+hb++4dkALkJ+kjFlfEOHYmi7sJ2w3A3TCom7GMIrF9c/PdjqIFiNxHWlxi DLmGmu9ub69uDOLWEohv39zoUR8ePiWxv3USGV4WcrtPieFCPXmmIl22356+ vNTknhwQT034GlEjAR9OmX4BTU2celgI9oHhLApSw2N3QjAFTz3ciBagTX/P ZgMVQYu59+bhNy8QLQcCs4SVYCKr0OjixLSylNbK5lCFkZ9XMkRa22FHdnZ1 TOSujWZCVMYczWB/o9nIdhCLzTihsCMMR49ghc7QfFZVLygnDPdMTtGgcGJ6 GA+pUKpNVRvQbVu6rVakGRj0mImhFpZ92pZQY2BfVni05QHWMrJzF/M9UhmM 6FE9kkE1d/gsKS4qB4B6wnOoNABVB4zxWUh6mr71YRZhEg5b+CJLJtKsWRl/ CNMkJraAqP+A5QidyRLbsnMPrJWjMG+zDOy0OH8kKwxBJ6VwPrgbNonjogGj orjnDGZ5d4e5pmCqaDosyo5goci0XhsW9BqqMXryD7G520qv0zOOS440I1Vz /OwINAqXVlQB3a50gWZ6AHgd1KSnw/dx8gCwWYkxGTq95yGZwTEjCt9Lzp8J KNxcCjiLYJaHyf+Z0MtRH2Q8AlwsY6Q6QasHE9F6GCf0Rm0Yf0iiD1oXu+Ks AGn20hbQ8dESRFlSIug2mYgrmQ/Hu+J/Y9ZwGI8GUQCyeCPT+zARL2QERmy4 Ky7gXAh/zrJwt/UySOH3K5kmw+E4THbFqxRtzWyYiDfBv/8Nth+rt9NwPAvE 61mi4+LDlJJF5INo4eJEEaKGpFxIDeGyw2BiEr07KUcY1sqPDZXSU//Aqg3D 32CEnK5Km28lGe8lptzRV+eYstYXpUy8Fn1XyHP7jlLZxK1+NxlTkB0AnpQ3 TcD/D7zw9vs6sgEA --></rfc>