]> Common YANG Data Types for Traffic Engineering Huawei
italo.busi@huawei.com
Futurewei Technologies
aihuaguo.ietf@gmail.com
Alef Edge
xufeng.liu.ietf@gmail.com
Cisco Systems Inc.
tsaad.net@gmail.com
Individual
i_bryskin@yahoo.com
TEAS Working Group This document defines a collection of common data types, identities, and groupings in YANG data modeling language. These derived common data types, identities and groupings are intended to be imported by other modules, e.g., those which model the Traffic Engineering (TE) configuration and state capabilities. This document obsoletes RFC 8776.
Introduction YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols such as the Network Configuration Protocol (NETCONF) or RESTCONF . The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. This document introduces a collection of common data types derived from the built-in YANG data types. The derived data types, identities, and groupings are mainly designed to be the common definitions applicable for modeling Traffic Engineering (TE) features in models defined outside of this document. Nevertheless, these common definitions can be used by any other module per the guidance in Sections and of .
  • Note: Some groupings defined in this document do not follow the guidelines of not to include "default" statements. This is due to the fact that they were already defined in and removing "default" statements is not a backward compatible change, as defined in .
This document adds new common data types, identities, and groupings to both the "ietf-te-types" and the "ietf-te-packet-types" YANG modules and obsoletes . For further details, refer to .
Editorial Note (To be removed by Editors of this document before sending it to the RFC Editor)
  • Note to the RFC Editor: This section is to be removed this document is sent to the RFC Editor.
The YANG trees in have been generated by pyang and have some bugs to be fixed before publication. Please manually fix the YANG tree before sending the document to the RFC Editor.
Editorial Note (To be removed by the RFC Editor)
  • Note to the RFC Editor: This section is to be removed prior to publication.
This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please apply the following replacements: XXXX --> the assigned RFC number for this I-D draft-ietf-pce-sid-algo-29, Sections 4.5.1 and 4.5.2 --> the draft version and section number as in the latest version of at the time this document is published as an RFC 2026-01-15 --> the actual date of the publication of this document 2026-02-06 --> the actual date of the publication of this document
References to RFCs This document references a huge number of RFCs only by the RFC number which makes it really hard to follow. A preference has been expressed to replace the references with the RFC title in the text and just use RFC number as a reference. For example: In section 1 change:
  • Section 4.12 of and Section 4.13 of .
to
  • Section 4.12 and Section 4.13 of YANG Data Models guidelines document .
It is suggested that the RFC Editor and the tooling team identify a way to expand the references as proposed in a programmatic way.
Terminology 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 when, and only when, they appear in all capitals, as shown here. The terminology for describing YANG data models is found in .
Prefixes in Data Node Names Names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in . Prefix YANG module Reference yang ietf-yang-types inet ietf-inet-types rt-types ietf-routing-types te-types ietf-te-types RFC XXXX te-packet-types ietf-te-packet-types RFC XXXX
Tree Diagrams Tree diagrams used in this document follow the notation defined in .
Acronyms and Abbreviations
APS:
Automatic Protection Switching
GMPLS:
Generalized Multiprotocol Label Switching
LER:
Label Edge Router
LSP:
Label Switched Path
  • Note: in this document, "LSP" refers to a TE LSP or a TE path.
LSR:
Label Switching Router
MPLS:
Multiprotocol Label Switching
NBMA:
Non-Broadcast Multi-Access
PM:
Performance Metrics
RSVP:
Resource Reservation Protocol
SRLG:
Shared Risk Link Group
TE:
Traffic Engineering
WTR:
Wait-to-Restore
Overview This document defines two YANG modules for common TE types: "ietf-te-types" () for TE generic types and "ietf-te-packet-types" () for packet-specific types. Other technology-specific TE types are outside the scope of this document.
TE Types Module Contents The "ietf-te-types" module () contains TE types that are commonly used across multiple TE technology-specific modules.
Identities The "ietf-te-types" module contains the following YANG reusable identities:
path-attribute-flags:
A base identity for supported LSP path flags as defined in , , , , , , , , , , , , , , , and .
link-protection-type:
A base identity for supported link protection types as defined in .
restoration-scheme-type:
A base identity for supported LSP restoration schemes as defined in .
protection-external-commands:
A base identity for supported protection-related external commands used for troubleshooting purposes, as defined in , , , and .
association-type:
A base identity for supported LSP association types as defined in , , , and .
objective-function-type:
A base identity for supported path objective functions as defined in .
te-tunnel-type:
A base identity for supported TE tunnel types as defined in and .
lsp-encoding-types:
A base identity for supported LSP encoding types as defined in , , and . These defined identities includes also technology-specific LSP encoding types for backward compatibility with .
Additional technology-specific LSP encoding types can be defined in specific technology-specific modules.
lsp-protection-type:
A base identity for supported LSP protection types as defined in and .
switching-capabilities:
A base identity for supported interface switching capabilities as defined in , , , , and . These defined identities includes also technology-specific interface switching capabilities for backward compatibility with .
Additional technology-specific interface switching capabilities can be defined in specific technology-specific modules.
resource-affinities-type:
A base identity for supported attribute filters associated with a tunnel that must be satisfied for a link to be acceptable as defined in and .
path-metric-type:
A base identity for supported path metric types as defined in , , , , , , and .
The unit of the path metric value is interpreted in the context of the path metric type. The derived identities MUST describe the unit and maximum value of the path metric types they define.
For example, the measurement unit is not applicable for the number of hops metric ('path-metric-hop'). Conversely, the bound of the 'path-metric-loss', defined in 'ietf-te-packet-types', is defined in multiples of the basic unit 0.000003% as described in and .
lsp-provisioning-error-reason:
A base identity for indicating LSP provisioning error reasons. No standard LSP provisioning error reasons are defined in this document.
path-computation-error-reason:
A base identity for indicating path computation error reasons as defined in .
protocol-origin-type:
A base identity for the type of protocol origin as defined in .
svec-objective-function-type:
A base identity for supported SVEC objective functions as defined in and .
svec-metric-type:
A base identity for supported SVEC metric types as defined in .
Path Computation Errors The "ietf-te-types" module contains the YANG reusable identities for indicating path computation error reasons as defined in , , , , , and . It also defines the following additional YANG reusable identities for indicating the following path computation error reasons:
path-computation-error-no-topology:
A base identity for indicating path computation error when there is no topology with the provided topology identifier.
path-computation-error-no-dependent-server:
A base identity for indicating path computation error when one or more dependent path computation servers are unavailable.
The dependent path computation server could be a Backward-Recursive Path Computation (BRPC) downstream PCE, as defined in , or a child PCE, as defined in .
The derived identities are defined in the "ietf-te-types" module, instead of an IANA-maintained module, because there are error reasons which are: applicable only to the TE YANG modules and not to PCEP environments (e.g., path-computation-error-no-topology); technology-specific which are better defined in technology-specific YANG modules; match more than one PCEP number in order to hide the details of the underlay PCE architecture (e.g., path-computation-error-no-dependent-server).
Protocol Origin The protocol origin identifies the protocol or mechanism a controller uses to instantiate a TE tunnel. To model this, the "ietf-te-types" module provides a set of reusable YANG identities. In addition to identities for protocols like PCEP and BGP , the module defines the following identity for tunnels created via an Application Programmable Interface (API):
protocol-origin-api:
A YANG identity used when the TE tunnel is instantiated through an API.
Data Types The "ietf-te-types" module contains the following YANG reusable data types:
te-ds-class:
A type representing the Differentiated Services (DS) Class-Type of traffic as defined in .
te-label-direction:
An enumerated type for specifying the forward or reverse direction of a label.
te-hop-type:
An enumerated type for specifying that a hop is loose or strict.
te-global-id:
A type representing the identifier that uniquely identifies an operator, which can be either a provider or a client. The definition of this type is taken from and . This attribute type is used solely to provide a globally unique context for TE topologies.
te-node-id:
A type representing the identifier for a node in a TE topology. The identifier is represented either as 4-octet in dotted-quad notation or as 16-octet in an IPv6 address notation.
This attribute MAY be mapped to the Router Address TLV described in , the TE Router ID described in , the Traffic Engineering Router ID TLV described in , or the TE Router ID TLV described in .
The reachability of such a TE node MAY be achieved by a mechanism such as that described in .
te-topology-id:
A type representing the identifier for a topology. It is optional to have one or more prefixes at the beginning, separated by colons. The prefixes can be "network-types" as defined in the "ietf-network" module in , to help the user better understand the topology before further inquiry is made.
te-tp-id:
A type representing the identifier of a TE interface Link Termination Point (LTP) on a specific TE node where the TE link connects. This attribute is mapped to a local or remote link identifier .
te-path-disjointness:
A type representing the different resource disjointness options for a TE tunnel path as defined in .
admin-groups:
A union type for a TE link's classic administrative groups, as defined in and , or extended administrative groups, as defined in .
srlg:
A type representing the Shared Risk Link Group (SRLG) as defined in and .
te-metric:
A type representing the TE metric as defined in .
te-recovery-status:
An enumerated type for the different status of a recovery action as defined in and .
te-link-access-type:
An enumerated type for the different TE link access types as defined in .
Groupings The "ietf-te-types" module contains the following YANG reusable groupings:
te-bandwidth:
A grouping that defines the generic TE bandwidth. The modeling structure allows augmentation for each technology. For unspecified technologies, the string-encoded "te-bandwidth" type is used.
te-label:
A grouping that defines the generic TE label. The modeling structure allows augmentation for each technology. For unspecified technologies, "rt-types:generalized-label" is used.
performance-metrics-attributes:
A grouping that defines one-way and two-way measured Performance Metrics (PM) and indications of anomalies on links or the path as defined in , , , and .
performance-metrics-throttle-container:
A grouping that defines thresholds for advertisement suppression and measurement intervals.
explicit-route-hop:
A grouping that defines supported explicit routes as defined in and .
explicit-route-hop-with-srlg:
A grouping that augments the 'explicit-route-hop' to specify also SRLG hops.
encoding-and-switching-type:
A grouping that defines the LSP encoding and switching types.
Packet TE Types Module Contents The "ietf-te-packet-types" module () covers the common types and groupings that are specific to packet technology.
Identities The "ietf-te-packet-types" module contains the following YANG reusable identities:
backup-protection-type:
A base identity for supported protection types that a backup or bypass tunnel can provide as defined in .
bc-model-type:
A base identity for supported Diffserv-TE Bandwidth Constraints Models as defined in , , and .
bandwidth-profile-type:
A base identity for various bandwidth profiles, also known as traffic profiles in , that may be used to specify the temporal properties of a packet stream (e.g., MPLS-TE LSPs), e.g., as specified in , and .
Data Types The "ietf-te-packet-types" module contains the following YANG reusable data type:
te-bandwidth-requested-type:
An enumerated type for the different options to request bandwidth for a specific tunnel.
Groupings The "ietf-te-packet-types" module contains the following YANG reusable groupings:
performance-metrics-attributes-packet:
A grouping that contains the generic performance metrics and additional packet-specific metrics.
bandwidth-profile-parameters:
A grouping that defines common parameters for bandwidth profiles in packet networks.
te-packet-path-bandwidth:
A grouping that defines the path bandwidth information and could be used in any Packet TE model (e.g., MPLS-TE topology model) for the path bandwidth representation (e.g., the bandwidth of an MPLS-TE LSP).
All the path and LSP bandwidth related sections in the "ietf-te-types" generic module, , need to be augmented with this grouping for the usage of Packet TE technologies.
te-packet-link-bandwidth:
A grouping that defines the link bandwidth information and could be used in any Packet TE model (e.g., MPLS-TE topology) for link bandwidth representation.
All the link bandwidth related sections in the "ietf-te-types" generic module, , need to be augmented with this grouping for the usage of Packet TE technologies.
TE Types YANG Module The "ietf-te-types" module imports the following modules: "ietf-yang-types" and "ietf-inet-types" as defined in "ietf-routing-types" as defined in "ietf-network" and "ietf-network-topology" as defined in In addition to and , this module references the following documents in defining the types and YANG groupings: , , , , , , , , , , , , , , , , and .
WG List: Editor: Tarek Saad Editor: Rakesh Gandhi Editor: Vishnu Pavan Beeram Editor: Xufeng Liu Editor: Igor Bryskin "; description "This YANG module contains a collection of generally useful YANG data type definitions specific to TE. 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) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-02-06 { description "This revision adds the following new identities: - lsp-provisioning-error-reason; - association-type-diversity; - tunnel-admin-state-auto; - lsp-restoration-restore-none; - restoration-scheme-rerouting; - path-metric-optimization-type; - link-path-metric-type; - link-metric-type and its derived identities; - path-computation-error-reason and its derived identities; - protocol-origin-type and its derived identities; - svec-objective-function-type and its derived identities; - svec-metric-type and its derived identities. This revision adds the following new data types: - path-type. This revision adds the following new groupings: - explicit-route-hop-with-srlg; - encoding-and-switching-type; - te-generic-node-id. This revision updates the following identities: - objective-function-type; - action-exercise; - path-metric-type; - path-metric-te; - path-metric-igp; - path-metric-hop; - path-metric-delay-average; - path-metric-delay-minimum; - path-metric-residual-bandwidth; - path-metric-optimize-includes; - path-metric-optimize-excludes; - te-optimization-criterion. This revision updates the following data types: - te-node-id. This revision updates the following groupings: - explicit-route-hop: - adds the following leaves: - node-id-uri; - link-tp-id-uri; - updates the following leaves: - node-id; - link-tp-id; - record-route-state: - adds the following leaves: - node-id-uri; - link-tp-id-uri; - updates the following leaves: - node-id; - link-tp-id; - optimization-metric-entry: - updates the following leaves: - metric-type; - tunnel-constraints; - adds the following leaves: - network-id; - path-constraints-route-objects: - updates the following containers: - explicit-route-objects-always; - generic-path-metric-bounds: - updates the following leaves: - metric-type; - generic-path-optimization - adds the following leaves: - tiebreaker; - deprecate the following containers: - tiebreakers. This revision obsoletes the following identities: - of-minimize-agg-bandwidth-consumption; - of-minimize-load-most-loaded-link; - of-minimize-cost-path-set; - lsp-protection-reroute-extra; - lsp-protection-reroute. This revision provides also few editorial changes."; reference "RFC XXXX: Common YANG Data Types for Traffic Engineering"; } revision 2020-06-10 { description "Initial Version of TE types."; reference "RFC 8776: Common YANG Data Types for Traffic Engineering"; } /* * Features */ feature p2mp-te { description "Indicates support for Point-to-Multipoint TE (P2MP-TE)."; reference "RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"; } feature frr-te { description "Indicates support for TE Fast Reroute (FRR)."; reference "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } feature extended-admin-groups { description "Indicates support for TE link extended administrative groups."; reference "RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } feature named-path-affinities { description "Indicates support for named path affinities."; } feature named-extended-admin-groups { description "Indicates support for named extended administrative groups."; } feature named-srlg-groups { description "Indicates support for named Shared Risk Link Group (SRLG)."; } feature named-path-constraints { description "Indicates support for named path constraints."; } feature path-optimization-metric { description "Indicates support for path optimization metrics."; } feature path-optimization-objective-function { description "Indicates support for path optimization objective functions."; } /* * Identities */ identity lsp-provisioning-error-reason { description "Base identity for LSP provisioning errors."; } identity session-attributes-flags { description "Base identity for the RSVP-TE session attributes flags."; } identity local-protection-desired { base session-attributes-flags; description "Local protection is desired."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.7.1"; } identity se-style-desired { base session-attributes-flags; description "Shared explicit style, to allow the LSP to be established and share resources with the old LSP."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity local-recording-desired { base session-attributes-flags; description "Label recording is desired."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.7.1"; } identity bandwidth-protection-desired { base session-attributes-flags; description "Requests FRR bandwidth protection on LSRs, if present."; reference "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } identity node-protection-desired { base session-attributes-flags; description "Requests FRR node protection on LSRs, if present."; reference "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels"; } identity path-reevaluation-request { base session-attributes-flags; description "Indicates that a path re-evaluation (of the current path in use) is requested. Note that this does not trigger any LSP reroutes but instead just signals a request to evaluate whether a preferable path exists."; reference "RFC 4736: Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)"; } identity soft-preemption-desired { base session-attributes-flags; description "Soft preemption of LSP resources is desired."; reference "RFC 5712: MPLS Traffic Engineering Soft Preemption"; } identity lsp-attributes-flags { description "Base identity for LSP attributes flags."; } identity end-to-end-rerouting-desired { base lsp-attributes-flags; description "Indicates end-to-end rerouting behavior for an LSP undergoing establishment. This MAY also be used to specify the behavior of end-to-end LSP recovery for established LSPs."; reference "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity boundary-rerouting-desired { base lsp-attributes-flags; description "Indicates boundary rerouting behavior for an LSP undergoing establishment. This MAY also be used to specify segment-based LSP recovery through nested crankback for established LSPs. The boundary Area Border Router (ABR) / Autonomous System Border Router (ASBR) can decide to forward the PathErr message upstream to either an upstream boundary ABR/ASBR or the ingress LSR. Alternatively, it can try to select another egress boundary LSR."; reference "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity segment-based-rerouting-desired { base lsp-attributes-flags; description "Indicates segment-based rerouting behavior for an LSP undergoing establishment. This MAY also be used to specify segment-based LSP recovery for established LSPs."; reference "RFC 4920: Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE RFC 5420: Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity lsp-integrity-required { base lsp-attributes-flags; description "Indicates that LSP integrity is required."; reference "RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity contiguous-lsp-desired { base lsp-attributes-flags; description "Indicates that a contiguous LSP is desired."; reference "RFC 5151: Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity lsp-stitching-desired { base lsp-attributes-flags; description "Indicates that LSP stitching is desired."; reference "RFC 5150: Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity pre-planned-lsp-flag { base lsp-attributes-flags; description "Indicates that the LSP MUST be provisioned in the control plane only."; reference "RFC 6001: Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity non-php-behavior-flag { base lsp-attributes-flags; description "Indicates that non-PHP (non-Penultimate Hop Popping) behavior for the LSP is desired."; reference "RFC 6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity oob-mapping-flag { base lsp-attributes-flags; description "Indicates that signaling of the egress binding information is out of band (e.g., via the Border Gateway Protocol (BGP))."; reference "RFC 6511: Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity entropy-label-capability { base lsp-attributes-flags; description "Indicates entropy label capability."; reference "RFC 6790: The Use of Entropy Labels in MPLS Forwarding RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)"; } identity oam-mep-entity-desired { base lsp-attributes-flags; description "OAM Maintenance Entity Group End Point (MEP) entities desired."; reference "RFC 7260: GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration"; } identity oam-mip-entity-desired { base lsp-attributes-flags; description "OAM Maintenance Entity Group Intermediate Points (MIP) entities desired."; reference "RFC 7260: GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration"; } identity srlg-collection-desired { base lsp-attributes-flags; description "Shared Risk Link Group (SRLG) collection desired."; reference "RFC 7570: Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) RFC 8001: RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information"; } identity loopback-desired { base lsp-attributes-flags; description "Indicates that a particular node on the LSP is required to enter loopback mode. This can also be used to specify the loopback state of the node."; reference "RFC 7571: GMPLS RSVP-TE Extensions for Lock Instruct and Loopback"; } identity p2mp-te-tree-eval-request { base lsp-attributes-flags; description "P2MP-TE tree re-evaluation request."; reference "RFC 8149: RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)"; } identity rtm-set-desired { base lsp-attributes-flags; description "Residence Time Measurement (RTM) attribute flag requested."; reference "RFC 8169: Residence Time Measurement in MPLS Networks"; } identity link-protection-type { description "Base identity for the link protection type."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), section 2.2 RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, section 7"; } identity link-protection-unprotected { base link-protection-type; description "'Unprotected' link protection type."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), section 2.2 RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, section 7"; } identity link-protection-extra-traffic { base link-protection-type; description "'Extra-Traffic' link protection type."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), section 2.2 RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, section 7"; } identity link-protection-shared { base link-protection-type; description "'Shared' link protection type."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), section 2.2 RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, section 7"; } identity link-protection-1-for-1 { base link-protection-type; description "'Dedicated 1:1' link protection type."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), section 2.2 RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, section 7"; } identity link-protection-1-plus-1 { base link-protection-type; description "'Dedicated 1+1' link protection type."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), section 2.2 RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, section 7"; } identity link-protection-enhanced { base link-protection-type; description "'Enhanced' link protection type."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), section 2.2 RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, section 7"; } identity association-type { description "Base identity for the tunnel association."; } identity association-type-recovery { base association-type; description "Association type for recovery, used to associate LSPs of the same tunnel for recovery."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery RFC 6780: RSVP ASSOCIATION Object Extensions"; } identity association-type-resource-sharing { base association-type; description "Association type for resource sharing, used to enable resource sharing during make-before-break."; reference "RFC 4873: GMPLS Segment Recovery RFC 6780: RSVP ASSOCIATION Object Extensions"; } identity association-type-double-sided-bidir { base association-type; description "Association type for double-sided bidirectional LSPs, used to associate two LSPs of two tunnels that are independently configured on either endpoint."; reference "RFC 7551: RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"; } identity association-type-single-sided-bidir { base association-type; description "Association type for single-sided bidirectional LSPs, used to associate two LSPs of two tunnels, where one tunnel is configured on one side/endpoint and the other tunnel is dynamically created on the other endpoint."; reference "RFC 6780: RSVP ASSOCIATION Object Extensions RFC 7551: RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"; } identity association-type-diversity { base association-type; description "Association Type diversity used to associate LSPs whose paths are to be diverse from each other."; reference "RFC 8800: Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling"; } identity objective-function-type { description "Base identity for path objective function types."; } identity of-minimize-cost-path { base objective-function-type; description "Objective function for minimizing path cost."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-load-path { base objective-function-type; description "Objective function for minimizing the load on one or more paths."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-maximize-residual-bandwidth { base objective-function-type; description "Objective function for maximizing residual bandwidth."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-agg-bandwidth-consumption { base objective-function-type; status obsolete; description "Objective function for minimizing aggregate bandwidth consumption. This identity has been obsoleted: the 'svec-of-minimize-agg-bandwidth-consumption' identity SHOULD be used instead."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-load-most-loaded-link { base objective-function-type; status obsolete; description "Objective function for minimizing the load on the link that is carrying the highest load. This identity has been obsoleted: the 'svec-of-minimize-load-most-loaded-link' identity SHOULD be used instead."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity of-minimize-cost-path-set { base objective-function-type; status obsolete; description "Objective function for minimizing the cost on a path set. This identity has been obsoleted: the 'svec-of-minimize-cost-path-set' identity SHOULD be used instead."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity path-computation-method { description "Base identity for supported path computation mechanisms."; } identity path-locally-computed { base path-computation-method; description "Indicates a constrained-path LSP in which the path is computed by the local LER."; reference "RFC 9522: Overview and Principles of Internet Traffic Engineering, Section 4.4"; } identity path-externally-queried { base path-computation-method; description "Constrained-path LSP in which the path is obtained by querying an external source, such as a PCE server. In the case that an LSP is defined to be externally queried, it may also have associated explicit definitions (provided to the external source to aid computation). The path that is returned by the external source may require further local computation on the device."; reference "RFC 9522: Overview and Principles of Internet Traffic Engineering RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity path-explicitly-defined { base path-computation-method; description "Constrained-path LSP in which the path is explicitly specified as a collection of strict and/or loose hops."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 9522: Overview and Principles of Internet Traffic Engineering"; } identity lsp-metric-type { description "Base identity for the LSP metric specification types."; } identity lsp-metric-relative { base lsp-metric-type; description "The metric specified for the LSPs to which this identity refers is specified as a value relative to the IGP metric cost to the LSP's tail end."; reference "RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity lsp-metric-absolute { base lsp-metric-type; description "The metric specified for the LSPs to which this identity refers is specified as an absolute value."; reference "RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity lsp-metric-inherited { base lsp-metric-type; description "The metric for the LSPs to which this identity refers is not specified explicitly; rather, it is directly inherited from the IGP cost."; reference "RFC 4657: Path Computation Element (PCE) Communication Protocol Generic Requirements"; } identity te-tunnel-type { description "Base identity from which specific tunnel types are derived."; } identity te-tunnel-p2p { base te-tunnel-type; description "TE Point-to-Point (P2P) tunnel type."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity te-tunnel-p2mp { base te-tunnel-type; description "TE P2MP tunnel type."; reference "RFC 4875: Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)"; } identity tunnel-action-type { description "Base identity from which specific tunnel action types are derived."; } identity tunnel-action-resetup { base tunnel-action-type; description "TE tunnel action that tears down the tunnel's current LSP (if any) and attempts to re-establish a new LSP."; } identity tunnel-action-reoptimize { base tunnel-action-type; description "TE tunnel action that reoptimizes the placement of the tunnel LSP(s)."; } identity tunnel-action-switchpath { base tunnel-action-type; description "TE tunnel action that switches the tunnel's LSP to use the specified path."; } identity te-action-result { description "Base identity from which specific TE action results are derived."; } identity te-action-success { base te-action-result; description "TE action was successful."; } identity te-action-fail { base te-action-result; description "TE action failed."; } identity tunnel-action-inprogress { base te-action-result; description "TE action is in progress."; } identity tunnel-admin-state-type { description "Base identity for TE tunnel administrative states."; } identity tunnel-admin-state-up { base tunnel-admin-state-type; description "Tunnel's administrative state is up."; } identity tunnel-admin-state-down { base tunnel-admin-state-type; description "Tunnel's administrative state is down."; } identity tunnel-admin-state-auto { base tunnel-admin-state-type; description "Tunnel administrative auto state. The administrative status in state datastore transitions to 'tunnel-admin-up' when the tunnel used by the client layer, and to 'tunnel-admin-down' when it is not used by the client layer."; } identity tunnel-state-type { description "Base identity for TE tunnel states."; } identity tunnel-state-up { base tunnel-state-type; description "Tunnel's state is up."; } identity tunnel-state-down { base tunnel-state-type; description "Tunnel's state is down."; } identity lsp-state-type { description "Base identity for TE LSP states."; } identity lsp-path-computing { base lsp-state-type; description "State path computation is in progress."; } identity lsp-path-computation-ok { base lsp-state-type; description "State path computation was successful."; } identity lsp-path-computation-failed { base lsp-state-type; description "State path computation failed."; } identity lsp-state-setting-up { base lsp-state-type; description "State is being set up."; } identity lsp-state-setup-ok { base lsp-state-type; description "State setup was successful."; } identity lsp-state-setup-failed { base lsp-state-type; description "State setup failed."; } identity lsp-state-up { base lsp-state-type; description "State is up."; } identity lsp-state-tearing-down { base lsp-state-type; description "State is being torn down."; } identity lsp-state-down { base lsp-state-type; description "State is down."; } identity path-invalidation-action-type { description "Base identity for TE path invalidation action types."; } identity path-invalidation-action-drop { base path-invalidation-action-type; description "Upon invalidation of the TE tunnel path, the tunnel remains valid, but any packet mapped over the tunnel is dropped."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 2.5"; } identity path-invalidation-action-teardown { base path-invalidation-action-type; description "TE path invalidation action teardown."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 2.5"; } identity lsp-restoration-type { description "Base identity from which LSP restoration types are derived."; } identity lsp-restoration-restore-none { base lsp-restoration-type; description "No LSP affected by a failure is restored."; } identity lsp-restoration-restore-any { base lsp-restoration-type; description "Any LSP affected by a failure is restored."; } identity lsp-restoration-restore-all { base lsp-restoration-type; description "Affected LSPs are restored after all LSPs of the tunnel are broken."; } identity restoration-scheme-type { description "Base identity for LSP restoration schemes."; } identity restoration-scheme-rerouting { base restoration-scheme-type; description "Restoration LSP is computed, signalled and configured after the failure detection. This restoration scheme is also known as 'Full LSP Re-routing', with the alternate route being computed after the failure occurs."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 11"; } identity restoration-scheme-preconfigured { base restoration-scheme-type; description "Restoration LSP is precomputed, presignalled and preconfigured prior to the failure."; } identity restoration-scheme-precomputed { base restoration-scheme-type; description "Restoration LSP is precomputed, but not presignalled nor preconfigured, prior to the failure. This restoration scheme is also known as 'Full LSP Re-routing', with the alternate route being precomputed and stored for use when the failure occurs."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 11"; } identity restoration-scheme-presignaled { base restoration-scheme-type; description "Restoration LSP is presignaled, but not preconfigured, prior to the failure. This restoration scheme is also known as 'Pre-planned LSP Re-routing'."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 8"; } identity lsp-protection-type { description "Base identity from which LSP protection types are derived."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-unprotected { base lsp-protection-type; description "'Unprotected' LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } identity lsp-protection-reroute-extra { base lsp-protection-type; status obsolete; description "'(Full) Rerouting' LSP protection type. This identity has been obsoleted: the 'restoration-scheme-rerouting' or 'restoration-scheme-precomputed' identity SHOULD be used instead."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 11"; } identity lsp-protection-reroute { base lsp-protection-type; status obsolete; description "'Rerouting without Extra-Traffic' LSP protection type. This identity has been obsoleted: the 'restoration-scheme-presignaled' identity SHOULD be used instead."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 8"; } identity lsp-protection-1-for-n { base lsp-protection-type; description "'1:N Protection with Extra-Traffic' LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 7.3"; } identity lsp-protection-1-for-1 { base lsp-protection-type; description "LSP protection '1:1 Protection Type'."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 7"; } identity lsp-protection-unidir-1-plus-1 { base lsp-protection-type; description "'1+1 Unidirectional Protection' LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 5"; } identity lsp-protection-bidir-1-plus-1 { base lsp-protection-type; description "'1+1 Bidirectional Protection' LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 6"; } identity lsp-protection-extra-traffic { base lsp-protection-type; description "Extra-Traffic LSP protection type."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery, section 7"; } identity lsp-protection-state { description "Base identity of protection states for reporting purposes."; } identity normal { base lsp-protection-state; description "Normal state."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity signal-fail-of-protection { base lsp-protection-state; description "The protection transport entity has a signal fail condition that is of higher priority than the forced switchover command."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity lockout-of-protection { base lsp-protection-state; description "A Loss of Protection (LoP) command is active."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity forced-switch { base lsp-protection-state; description "A forced switchover command is active."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity signal-fail { base lsp-protection-state; description "There is a signal fail condition on either the working path or the protection path."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity signal-degrade { base lsp-protection-state; description "There is a signal degrade condition on either the working path or the protection path."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity manual-switch { base lsp-protection-state; description "A manual switchover command is active."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity wait-to-restore { base lsp-protection-state; description "A Wait-to-Restore (WTR) timer is running."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity do-not-revert { base lsp-protection-state; description "A Do Not Revert (DNR) condition is active because of non-revertive behavior."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity failure-of-protocol { base lsp-protection-state; description "LSP protection is not working because of a protocol failure condition."; reference "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity protection-external-commands { description "Base identity from which protection-related external commands used for troubleshooting purposes are derived."; } identity action-freeze { base protection-external-commands; description "A temporary configuration action initiated by an operator command that prevents any switchover action from being taken and, as such, freezes the current state."; reference "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity clear-freeze { base protection-external-commands; description "An action that clears the active freeze state."; reference "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-lockout-of-normal { base protection-external-commands; description "A temporary configuration action initiated by an operator command to ensure that the normal traffic is not allowed to use the protection transport entity."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity clear-lockout-of-normal { base protection-external-commands; description "An action that clears the active lockout of the normal state."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-lockout-of-protection { base protection-external-commands; description "A temporary configuration action initiated by an operator command to ensure that the protection transport entity is temporarily not available to transport a traffic signal (either normal or Extra-Traffic)."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-forced-switch { base protection-external-commands; description "A switchover action initiated by an operator command to switch the Extra-Traffic signal, the normal traffic signal, or the null signal to the protection transport entity, unless a switchover command of equal or higher priority is in effect."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-manual-switch { base protection-external-commands; description "A switchover action initiated by an operator command to switch the Extra-Traffic signal, the normal traffic signal, or the null signal to the protection transport entity, unless a fault condition exists on other transport entities or a switchover command of equal or higher priority is in effect."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity action-exercise { base protection-external-commands; description "An action that starts testing whether or not Automatic Protection Switching (APS) communication is operating correctly. It is of lower priority than any other state or command."; reference "RFC 7271: MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity clear { base protection-external-commands; description "An action that clears the active near-end lockout of a protection, forced switchover, manual switchover, Wait-to-Restore (WTR) state, or exercise command."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } identity switching-capabilities { description "Base identity for interface switching capabilities."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-psc1 { base switching-capabilities; description "Packet-Switch Capable-1 (PSC-1)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-evpl { base switching-capabilities; description "Ethernet Virtual Private Line (EVPL)."; reference "RFC 6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching"; } identity switching-l2sc { base switching-capabilities; description "Layer-2 Switch Capable (L2SC)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-tdm { base switching-capabilities; description "Time-Division-Multiplex Capable (TDM)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-otn { base switching-capabilities; description "OTN-TDM capable."; reference "RFC 7138: Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks"; } identity switching-dcsc { base switching-capabilities; description "Data Channel Switching Capable (DCSC)."; reference "RFC 6002: Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions"; } identity switching-lsc { base switching-capabilities; description "Lambda-Switch Capable (LSC)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity switching-fsc { base switching-capabilities; description "Fiber-Switch Capable (FSC)."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-types { description "Base identity for encoding types."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-packet { base lsp-encoding-types; description "Packet LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-ethernet { base lsp-encoding-types; description "Ethernet LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-pdh { base lsp-encoding-types; description "ANSI/ETSI PDH LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-sdh { base lsp-encoding-types; description "SDH ITU-T G.707 / SONET ANSI T1.105 LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-digital-wrapper { base lsp-encoding-types; description "Digital Wrapper LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-lambda { base lsp-encoding-types; description "Lambda (photonic) LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-fiber { base lsp-encoding-types; description "Fiber LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-fiber-channel { base lsp-encoding-types; description "FiberChannel LSP encoding."; reference "RFC 3471: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"; } identity lsp-encoding-oduk { base lsp-encoding-types; description "G.709 ODUk (Digital Path) LSP encoding."; reference "RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control"; } identity lsp-encoding-optical-channel { base lsp-encoding-types; description "G.709 Optical Channel LSP encoding."; reference "RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control"; } identity lsp-encoding-line { base lsp-encoding-types; description "Line (e.g., 8B/10B) LSP encoding."; reference "RFC 6004: Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching"; } identity path-signaling-type { description "Base identity from which specific LSP path setup types are derived."; } identity path-setup-static { base path-signaling-type; description "Static LSP provisioning path setup."; } identity path-setup-rsvp { base path-signaling-type; description "RSVP-TE signaling path setup."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } identity path-setup-sr { base path-signaling-type; description "Segment-routing path setup."; } identity path-scope-type { description "Base identity from which specific path scope types are derived."; } identity path-scope-segment { base path-scope-type; description "Path scope segment."; reference "RFC 4873: GMPLS Segment Recovery"; } identity path-scope-end-to-end { base path-scope-type; description "Path scope end to end."; reference "RFC 4873: GMPLS Segment Recovery"; } identity route-usage-type { description "Base identity for route usage."; } identity route-include-object { base route-usage-type; description "'Include route' object."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3.2 RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP), Section 7.12 RFC 7896: Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)"; } identity route-exclude-object { base route-usage-type; description "'Exclude route' object."; reference "RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"; } identity route-exclude-srlg { base route-usage-type; description "Excludes Shared Risk Link Groups (SRLGs)."; reference "RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"; } identity path-metric-optimization-type { description "Base identity used to define the path metric optimization types."; } identity link-path-metric-type { description "Base identity used to define the link and the path metric types. The unit of the path metric value is interpreted in the context of the path metric type and the derived identities SHOULD describe the unit of the path metric types they define."; } identity link-metric-type { base link-path-metric-type; description "Base identity for the link metric types."; } identity link-metric-te { base link-metric-type; description "Traffic Engineering (TE) Link Metric."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2, Section 2.5.5 RFC 5305: IS-IS Extensions for Traffic Engineering, Section 3.7"; } identity link-metric-igp { base link-metric-type; description "Interior Gateway Protocol (IGP) Link Metric."; reference "RFC 3785: Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric"; } identity link-metric-delay-average { base link-metric-type; description "Unidirectional Link Delay, measured in units of microseconds."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, Section 4.1 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.1"; } identity link-metric-delay-minimum { base link-metric-type; description "Minimum unidirectional Link Delay, measured in units of microseconds."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, Section 4.2 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.2"; } identity link-metric-delay-maximum { base link-metric-type; description "Maximum unidirectional Link Delay, measured in units of microseconds."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, Section 4.2 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.2"; } identity link-metric-residual-bandwidth { base link-metric-type; description "Unidirectional Residual Bandwidth, measured in units of bytes per second. It is defined to be Maximum Bandwidth minus the bandwidth currently allocated to LSPs."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, Section 4.5 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.5"; } identity path-metric-type { base link-path-metric-type; base path-metric-optimization-type; description "Base identity for the path metric types."; } identity path-metric-te { base path-metric-type; description "Traffic Engineering (TE) Path Metric."; reference "RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP), Section 7.8"; } identity path-metric-igp { base path-metric-type; description "Interior Gateway Protocol (IGP) Path Metric."; reference "RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP), section 7.8"; } identity path-metric-hop { base path-metric-type; description "Hop Count Path Metric."; reference "RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP), Section 7.8"; } identity path-metric-delay-average { base path-metric-type; description "The Path Delay Metric, measured in units of microseconds."; reference "RFC 8233: Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs), Section 3.1.1"; } identity path-metric-delay-minimum { base path-metric-type; description "The Path Min Delay Metric, measured in units of microseconds."; reference "I-D.ietf-pce-sid-algo: Carrying SR-Algorithm information in PCE-based Networks, draft-ietf-pce-sid-algo-29, Sections 4.5.1 and 4.5.2"; } identity path-metric-residual-bandwidth { base path-metric-type; description "The Path Residual Bandwidth, defined as the minimum Link Residual Bandwidth all the links along the path. The Path Residual Bandwidth can be seen as the path metric associated with the Maximum residual Bandwidth Path (MBP) objective function."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity path-metric-optimize-includes { base path-metric-optimization-type; description "A metric that optimizes the number of included resources specified in a set."; } identity path-metric-optimize-excludes { base path-metric-optimization-type; description "A metric that optimizes to a maximum the number of excluded resources specified in a set."; } identity path-tiebreaker-type { description "Base identity for the path tiebreaker type."; } identity path-tiebreaker-minfill { base path-tiebreaker-type; description "Min-Fill LSP path placement: selects the path with the most available bandwidth (load balance LSPs over more links)."; } identity path-tiebreaker-maxfill { base path-tiebreaker-type; description "Max-Fill LSP path placement: selects the path with the least available bandwidth (packing more LSPs over few links)."; } identity path-tiebreaker-random { base path-tiebreaker-type; description "Random LSP path placement."; } identity resource-affinities-type { description "Base identity for resource class affinities."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 2702: Requirements for Traffic Engineering Over MPLS"; } identity resource-aff-include-all { base resource-affinities-type; description "The set of attribute filters associated with a tunnel, all of which must be present for a link to be acceptable."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 2702: Requirements for Traffic Engineering Over MPLS"; } identity resource-aff-include-any { base resource-affinities-type; description "The set of attribute filters associated with a tunnel, any of which must be present for a link to be acceptable."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 2702: Requirements for Traffic Engineering Over MPLS"; } identity resource-aff-exclude-any { base resource-affinities-type; description "The set of attribute filters associated with a tunnel, any of which renders a link unacceptable."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 2702: Requirements for Traffic Engineering Over MPLS"; } identity te-optimization-criterion { description "Base identity for the TE optimization criteria."; reference "RFC 9522: Overview and Principles of Internet Traffic Engineering"; } identity not-optimized { base te-optimization-criterion; description "Optimization is not applied."; } identity cost { base te-optimization-criterion; description "Optimized on cost."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity delay { base te-optimization-criterion; description "Optimized on delay."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity path-computation-srlg-type { description "Base identity for Shared Risk Link Group (SRLG) path computation."; } identity srlg-ignore { base path-computation-srlg-type; description "Ignores Shared Risk Link Groups (SRLGs) in the path computation."; } identity srlg-strict { base path-computation-srlg-type; description "Includes a strict Shared Risk Link Group (SRLG) check in the path computation."; } identity srlg-preferred { base path-computation-srlg-type; description "Includes a preferred Shared Risk Link Group (SRLG) check in the path computation."; } identity srlg-weighted { base path-computation-srlg-type; description "Includes a weighted Shared Risk Link Group (SRLG) check in the path computation."; } identity path-computation-error-reason { description "Base identity for path computation error reasons."; } identity path-computation-error-path-not-found { base path-computation-error-reason; description "Path computation has failed because of an unspecified reason."; reference "RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP), Section 7.5"; } identity path-computation-error-no-topology { base path-computation-error-reason; description "Path computation has failed because there is no topology with the provided topology-identifier."; } identity path-computation-error-no-dependent-server { base path-computation-error-reason; description "Path computation has failed because one or more dependent path computation servers are unavailable. The dependent path computation server could be a Backward-Recursive Path Computation (BRPC) downstream PCE or a child PCE."; reference "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture"; } identity path-computation-error-pce-unavailable { base path-computation-error-reason; description "Path computation has failed because PCE is not available. It corresponds to bit 31 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP) https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-no-inclusion-hop { base path-computation-error-reason; description "Path computation has failed because there is no node or link provided by one or more inclusion hops."; } identity path-computation-error-destination-unknown-in-domain { base path-computation-error-reason; description "Path computation has failed because the destination node is unknown in indicated destination domain. It corresponds to bit 19 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-no-resource { base path-computation-error-reason; description "Path computation has failed because there is no available resource in one or more domains. It corresponds to bit 20 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-child-pce-unresponsive { base path-computation-error-no-dependent-server; description "Path computation has failed because child PCE is not responsive. It corresponds to bit 21 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-destination-domain-unknown { base path-computation-error-reason; description "Path computation has failed because the destination domain was unknown. It corresponds to bit 22 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-p2mp { base path-computation-error-reason; description "Path computation has failed because of P2MP reachability problem. It corresponds to bit 24 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 8306: Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-no-gco-migration { base path-computation-error-reason; description "Path computation has failed because of no Global Concurrent Optimization (GCO) migration path found. It corresponds to bit 26 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 5557: Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-no-gco-solution { base path-computation-error-reason; description "Path computation has failed because of no GCO solution found. It corresponds to bit 25 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 5557: Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-pks-expansion { base path-computation-error-reason; description "Path computation has failed because of Path-Key Subobject (PKS) expansion failure. It corresponds to bit 27 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 5520: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-brpc-chain-unavailable { base path-computation-error-no-dependent-server; description "Path computation has failed because PCE BRPC chain unavailable. It corresponds to bit 28 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 5441: A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-source-unknown { base path-computation-error-reason; description "Path computation has failed because source node is unknown. It corresponds to bit 29 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP); https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity path-computation-error-destination-unknown { base path-computation-error-reason; description "Path computation has failed because destination node is unknown. It corresponds to bit 30 of the Flags field of the NO-PATH-VECTOR TLV."; reference "RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP); https://www.iana.org/assignments/pcep /pcep.xhtml#no-path-vector-tlv"; } identity protocol-origin-type { description "Base identity for protocol origin type."; } identity protocol-origin-api { base protocol-origin-type; description "Protocol origin is via Application Programming Interface (API)."; } identity protocol-origin-pcep { base protocol-origin-type; description "Protocol origin is Path Computation Engine Protocol (PCEP)."; reference "RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP)"; } identity protocol-origin-bgp { base protocol-origin-type; description "Protocol origin is Border Gateway Protocol (BGP)."; reference "RFC 9012: The BGP Tunnel Encapsulation Attribute"; } identity svec-objective-function-type { description "Base identity for SVEC objective function type."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-of-minimize-agg-bandwidth-consumption { base svec-objective-function-type; description "Objective function for minimizing aggregate bandwidth consumption (MBC)."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-of-minimize-load-most-loaded-link { base svec-objective-function-type; description "Objective function for minimizing the load on the link that is carrying the highest load (MLL)."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-of-minimize-cost-path-set { base svec-objective-function-type; description "Objective function for minimizing the cost on a path set (MCC)."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-of-minimize-common-transit-domain { base svec-objective-function-type; description "Objective function for minimizing the number of common transit domains (MCTD)."; reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } identity svec-of-minimize-shared-link { base svec-objective-function-type; description "Objective function for minimizing the number of shared links (MSL)."; reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } identity svec-of-minimize-shared-srlg { base svec-objective-function-type; description "Objective function for minimizing the number of shared Shared Risk Link Groups (SRLG) (MSS)."; reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } identity svec-of-minimize-shared-nodes { base svec-objective-function-type; description "Objective function for minimizing the number of shared nodes (MSN)."; reference "RFC 8685: Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture."; } identity svec-metric-type { description "Base identity for SVEC metric type."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-metric-cumulative-te { base svec-metric-type; description "Cumulative TE cost."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-metric-cumulative-igp { base svec-metric-type; description "Cumulative IGP cost."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-metric-cumulative-hop { base svec-metric-type; description "Cumulative Hop path metric."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-metric-aggregate-bandwidth-consumption { base svec-metric-type; description "Aggregate bandwidth consumption."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } identity svec-metric-load-of-the-most-loaded-link { base svec-metric-type; description "Load of the most loaded link."; reference "RFC 5541: Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)"; } /* * Typedefs */ typedef admin-group { type yang:hex-string { /* 01:02:03:04 */ length "1..11"; } description "Administrative group / resource class / color representation in 'hex-string' type. The most significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5305: IS-IS Extensions for Traffic Engineering RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } typedef admin-groups { type union { type admin-group; type extended-admin-group; } description "Derived types for TE administrative groups."; } typedef extended-admin-group { type yang:hex-string; description "Extended administrative group / resource class / color representation in 'hex-string' type. The most significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity."; reference "RFC 7308: Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)"; } typedef path-attribute-flags { type union { type identityref { base session-attributes-flags; } type identityref { base lsp-attributes-flags; } } description "Path attributes flags type."; } typedef performance-metrics-normality { type enumeration { enum unknown { value 0; description "Unknown."; } enum normal { value 1; description "Normal. Indicates that the anomalous bit is not set."; } enum abnormal { value 2; description "Abnormal. Indicates that the anomalous bit is set."; } } description "Indicates whether a performance metric is normal (anomalous bit not set), abnormal (anomalous bit set), or unknown."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions"; } typedef srlg { type uint32; description "Shared Risk Link Group (SRLG) type."; reference "RFC 4203: OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) RFC 5307: IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"; } typedef te-common-status { type enumeration { enum up { description "Enabled."; } enum down { description "Disabled."; } enum testing { description "In some test mode."; } enum preparing-maintenance { description "The resource is disabled in the control plane to prepare for a graceful shutdown for maintenance purposes."; reference "RFC 5817: Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks"; } enum maintenance { description "The resource is disabled in the data plane for maintenance purposes."; } enum unknown { description "Status is unknown."; } } description "Defines a type representing the common states of a TE resource."; } typedef te-bandwidth { type string { pattern '0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|' + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?' + '[pP](\+)?(12[0-7]|' + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+' + '(,(0[xX](0((\.0?)?[pP](\+)?0?|(\.0?))|' + '1(\.([\da-fA-F]{0,5}[02468aAcCeE]?)?)?' + '[pP](\+)?(12[0-7]|' + '1[01]\d|0?\d?\d)?)|0[xX][\da-fA-F]{1,8}|\d+))*'; } description "This is the generic bandwidth type. It is a string containing a list of numbers separated by commas, where each of these numbers can be non-negative decimal, hex integer, or hex float, as defined in ISO/IEC 9899: (dec | hex | float)[*(','(dec | hex | float))] For the packet-switching type, the string encoding MUST follow the type 'bandwidth-ieee-float32' as defined in RFC 8294 (e.g., 0x1p10), where the units are in bytes per second. Canonically, the string is represented as all lowercase and in hex, where the prefix '0x' precedes the hex number."; reference "ISO/IEC 9899:2024: Information Technology - Programming Languages - C, Section 6.4.4.2 RFC 8294: Common YANG Data Types for the Routing Area"; } typedef te-ds-class { type uint8 { range "0..7"; } description "The Differentiated Services Class-Type of traffic."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering, Section 4.3.1"; } typedef te-global-id { type uint32; description "An identifier to uniquely identify an operator, which can be either a provider or a client. The definition of this type is taken from RFCs 6370 and 5003. This attribute type is used solely to provide a globally unique context for TE topologies."; reference "RFC 5003: Attachment Individual Identifier (AII) Types for Aggregation RFC 6370: MPLS Transport Profile (MPLS-TP) Identifiers"; } typedef te-hop-type { type enumeration { enum loose { description "A loose hop in an explicit path."; } enum strict { description "A strict hop in an explicit path."; } } description "Enumerated type for specifying loose or strict paths."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3.3"; } typedef te-link-access-type { type enumeration { enum point-to-point { description "The link is point-to-point."; } enum multi-access { description "The link is multi-access, including broadcast and NBMA."; } } description "The access types of a TE link."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2"; } typedef te-label-direction { type enumeration { enum forward { description "Label allocated for the forward LSP direction."; } enum reverse { description "Label allocated for the reverse LSP direction."; } } description "Enumerated type for specifying the forward or reverse label."; } typedef te-link-direction { type enumeration { enum incoming { description "The explicit route represents an incoming link on a node."; } enum outgoing { description "The explicit route represents an outgoing link on a node."; } } description "Enumerated type for specifying the direction of a link on a node."; } typedef te-metric { type uint32; description "Traffic Engineering (TE) metric."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2, Section 2.5.5 RFC 5305: IS-IS Extensions for Traffic Engineering, Section 3.7"; } typedef te-node-id { type union { type yang:dotted-quad; type inet:ipv6-address-no-zone; } description "A type representing the identifier for a node in a TE topology. The identifier is represented either as 4 octets in dotted-quad notation, or as 16 octets in full, mixed, shortened, or shortened-mixed IPv6 address notation. This attribute MAY be mapped to the Router Address TLV described in Section 2.4.1 of RFC 3630, the TE Router ID described in Section 3 of RFC 6827, the Traffic Engineering Router ID TLV described in Section 4.3 of RFC 5305, the TE Router ID TLV described in Section 3.2.1 of RFC 6119, or the IPv6 TE Router ID TLV described in Section 4.1 of RFC 6119. The reachability of such a TE node MAY be achieved by a mechanism such as that described in Section 6.2 of RFC 6827."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2, Section 2.4.1 RFC 5305: IS-IS Extensions for Traffic Engineering, Section 4.3 RFC 6119: IPv6 Traffic Engineering in IS-IS, Section 3.2.1 RFC 6827: Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols, Section 3"; } typedef te-oper-status { type te-common-status; description "Defines a type representing the operational status of a TE resource."; } typedef te-admin-status { type te-common-status; description "Defines a type representing the administrative status of a TE resource."; } typedef te-path-disjointness { type bits { bit node { position 0; description "Node disjoint."; } bit link { position 1; description "Link disjoint."; } bit srlg { position 2; description "Shared Risk Link Group (SRLG) disjoint."; } } description "Type of the resource disjointness for a TE tunnel path."; reference "RFC 4872: RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"; } typedef te-recovery-status { type enumeration { enum normal { description "Both the recovery span and the working span are fully allocated and active, data traffic is being transported over (or selected from) the working span, and no trigger events are reported."; } enum recovery-started { description "The recovery action has been started but not completed."; } enum recovery-succeeded { description "The recovery action has succeeded. The working span has reported a failure/degrade condition, and the user traffic is being transported (or selected) on the recovery span."; } enum recovery-failed { description "The recovery action has failed."; } enum reversion-started { description "The reversion has started."; } enum reversion-succeeded { description "The reversion action has succeeded."; } enum reversion-failed { description "The reversion has failed."; } enum recovery-unavailable { description "The recovery is unavailable, as a result of either an operator's lockout command or a failure condition detected on the recovery span."; } enum recovery-admin { description "The operator has issued a command to switch the user traffic to the recovery span."; } enum wait-to-restore { description "The recovery domain is recovering from a failure/degrade condition on the working span that is being controlled by the Wait-to-Restore (WTR) timer."; } } description "Defines the status of a recovery action."; reference "RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection RFC 4427: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)"; } typedef te-template-name { type string { pattern '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*'; } description "A type for the name of a TE node template or TE link template."; } typedef te-topology-event-type { type enumeration { enum add { value 0; description "A TE node or TE link has been added."; } enum remove { value 1; description "A TE node or TE link has been removed."; } enum update { value 2; description "A TE node or TE link has been updated."; } } description "TE event type for notifications."; } typedef te-topology-id { type union { type string { length "0"; // empty string } type string { pattern '([a-zA-Z0-9\-_.]+:)*' + '/?([a-zA-Z0-9\-_.]+)(/[a-zA-Z0-9\-_.]+)*'; } } description "An identifier for a topology. It is optional to have one or more prefixes at the beginning, separated by colons. The prefixes can be 'network-types' as defined in the 'ietf-network' module in RFC 8345, to help the user better understand the topology before further inquiry is made."; reference "RFC 8345: A YANG Data Model for Network Topologies"; } typedef te-tp-id { type union { type uint32; // Unnumbered type inet:ip-address; // IPv4 or IPv6 address } description "An identifier for a TE link endpoint on a node. This attribute is mapped to a local or remote link identifier as defined in RFCs 3630 and 5305."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2 RFC 5305: IS-IS Extensions for Traffic Engineering"; } typedef path-type { type enumeration { enum primary-path { description "Indicates that the TE path is a primary path."; } enum secondary-path { description "Indicates that the TE path is a secondary path."; } enum primary-reverse-path { description "Indicates that the TE path is a primary reverse path."; } enum secondary-reverse-path { description "Indicates that the TE path is a secondary reverse path."; } } description "The type of TE path, indicating whether a path is a primary, or a reverse primary, or a secondary, or a reverse secondary path."; } /* * TE bandwidth groupings */ grouping te-bandwidth { description "This grouping defines the generic TE bandwidth. For some known data-plane technologies, specific modeling structures are specified. The string-encoded 'te-bandwidth' type is used for unspecified technologies. The modeling structure can be augmented later for other technologies."; container te-bandwidth { description "Container that specifies TE bandwidth. The choices can be augmented for specific data-plane technologies."; choice technology { default "generic"; description "Data-plane technology type."; case generic { leaf generic { type te-bandwidth; description "Bandwidth specified in a generic format."; } } } } } /* * TE label groupings */ grouping te-label { description "This grouping defines the generic TE label. The modeling structure can be augmented for each technology. For unspecified technologies, 'rt-types:generalized-label' is used."; container te-label { description "Container that specifies the TE label. The choices can be augmented for specific data-plane technologies."; choice technology { default "generic"; description "Data-plane technology type."; case generic { leaf generic { type rt-types:generalized-label; description "TE label specified in a generic format."; } } } leaf direction { type te-label-direction; default "forward"; description "Label direction."; } } } grouping te-topology-identifier { description "Augmentation for a TE topology."; container te-topology-identifier { description "TE topology identifier container."; leaf provider-id { type te-global-id; default "0"; description "An identifier to uniquely identify a provider. If omitted, it assumes that the topology provider ID value = 0 (the default)."; } leaf client-id { type te-global-id; default "0"; description "An identifier to uniquely identify a client. If omitted, it assumes that the topology client ID value = 0 (the default)."; } leaf topology-id { type te-topology-id; default ""; description "When the datastore contains several topologies, 'topology-id' distinguishes between them. If omitted, the default (empty) string for this leaf is assumed."; } } } /* * TE performance metrics groupings */ grouping performance-metrics-one-way-delay-loss { description "Performance Metrics (PM) information in real time that can be applicable to links or connections. PM defined in this grouping are applicable to generic TE PM as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; leaf one-way-delay { type uint32 { range "0..16777215"; } units "microseconds"; description "One-way delay or latency, also known as Unidirectional Link Delay."; reference "RFC 7679: A One-Way Delay Metric for IP Performance Metrics (IPPM)"; } leaf one-way-delay-normality { type te-types:performance-metrics-normality; description "The normality of the 'one-way-delay' metric."; } } grouping performance-metrics-two-way-delay-loss { description "Performance Metrics (PM) information in real time that can be applicable to links or connections. PM defined in this grouping are applicable to generic TE PM as well as packet TE PM."; leaf two-way-delay { type uint32 { range "0..16777215"; } units "microseconds"; description "Two-way delay or latency, also known as Roudn-trip Delay."; reference "RFC 2681: A Round-trip Delay Metric for IPPM"; } leaf two-way-delay-normality { type te-types:performance-metrics-normality; description "The normality of the 'two-way-delay' metric."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; } } grouping performance-metrics-one-way-bandwidth { description "Performance Metrics (PM) information in real time that can be applicable to links. PM defined in this grouping are applicable to generic TE PM as well as packet TE PM."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; leaf one-way-residual-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Residual bandwidth that subtracts tunnel reservations from Maximum Bandwidth (or link capacity) (RFC 3630) and provides an aggregated remainder across QoS classes."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2"; } leaf one-way-residual-bandwidth-normality { type te-types:performance-metrics-normality; default "normal"; description "Residual bandwidth normality."; } leaf one-way-available-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Available bandwidth that is defined to be residual bandwidth minus the measured bandwidth used for the actual forwarding of non-RSVP-TE LSP packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths."; } leaf one-way-available-bandwidth-normality { type te-types:performance-metrics-normality; default "normal"; description "Available bandwidth normality."; } leaf one-way-utilized-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Bandwidth utilization that represents the actual utilization of the link (i.e., as measured in the router). For a bundled link, bandwidth utilization is defined to be the sum of the component link bandwidth utilizations."; } leaf one-way-utilized-bandwidth-normality { type te-types:performance-metrics-normality; default "normal"; description "Bandwidth utilization normality."; } } grouping one-way-performance-metrics { description "One-way Performance Metrics (PM) throttle grouping."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; leaf one-way-delay { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "One-way delay or latency, also known as Unidirectional Link Delay."; reference "RFC 7679: A One-Way Delay Metric for IP Performance Metrics (IPPM)"; } leaf one-way-residual-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Residual bandwidth that subtracts tunnel reservations from Maximum Bandwidth (or link capacity) (RFC 3630) and provides an aggregated remainder across QoS classes."; reference "RFC 3630: Traffic Engineering (TE) Extensions to OSPF Version 2"; } leaf one-way-available-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Available bandwidth that is defined to be residual bandwidth minus the measured bandwidth used for the actual forwarding of non-RSVP-TE LSP packets. For a bundled link, available bandwidth is defined to be the sum of the component link available bandwidths."; } leaf one-way-utilized-bandwidth { type rt-types:bandwidth-ieee-float32; units "bytes per second"; default "0x0p0"; description "Bandwidth utilization that represents the actual utilization of the link (i.e., as measured in the router). For a bundled link, bandwidth utilization is defined to be the sum of the component link bandwidth utilizations."; } } grouping two-way-performance-metrics { description "Two-way Performance Metrics (PM) throttle grouping."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; leaf two-way-delay { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "Two-way delay or latency, also known as Roudn-trip Delay."; reference "RFC 2681: A Round-trip Delay Metric for IPPM"; } } grouping performance-metrics-thresholds { description "Grouping for configurable thresholds for measured attributes."; uses one-way-performance-metrics; uses two-way-performance-metrics; } grouping performance-metrics-attributes { description "Contains Performance Metrics (PM) attributes."; container performance-metrics-one-way { description "One-way link performance information in real time."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; uses performance-metrics-one-way-delay-loss; uses performance-metrics-one-way-bandwidth; } container performance-metrics-two-way { description "Two-way link performance information in real time."; reference "RFC 6374: Packet Loss and Delay Measurement for MPLS Networks"; uses performance-metrics-two-way-delay-loss; } } grouping performance-metrics-throttle-container { description "Controls Performance Metrics (PM) throttling."; container throttle { must 'suppression-interval >= measure-interval' { error-message "'suppression-interval' cannot be less than " + "'measure-interval'."; description "Constraint on 'suppression-interval' and 'measure-interval'."; } description "Link performance information in real time."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; leaf one-way-delay-offset { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "Offset value to be added to the measured delay value."; } leaf measure-interval { type uint32; units "seconds"; default "30"; description "Interval to measure the extended metric values."; } leaf advertisement-interval { type uint32; units "seconds"; default "0"; description "Interval to advertise the extended metric values."; } leaf suppression-interval { type uint32 { range "1..max"; } units "seconds"; default "120"; description "Interval to suppress advertisement of the extended metric values."; reference "RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 6"; } container threshold-out { description "If the measured parameter falls outside an upper bound for all but the minimum-delay metric (or a lower bound for the minimum-delay metric only) and the advertised value is not already outside that bound, an 'anomalous' announcement (anomalous bit set) will be triggered."; uses performance-metrics-thresholds; } container threshold-in { description "If the measured parameter falls inside an upper bound for all but the minimum-delay metric (or a lower bound for the minimum-delay metric only) and the advertised value is not already inside that bound, a 'normal' announcement (anomalous bit cleared) will be triggered."; uses performance-metrics-thresholds; } container threshold-accelerated-advertisement { description "When the difference between the last advertised value and the current measured value exceeds this threshold, an 'anomalous' announcement (anomalous bit set) will be triggered."; uses performance-metrics-thresholds; } } } /* * TE tunnel generic groupings */ grouping explicit-route-hop { description "The explicit route entry grouping."; choice type { description "The explicit route entry type."; case numbered-node-hop { container numbered-node-hop { must 'node-id-uri or node-id' { description "At least one node identifier needs to be present."; } description "Numbered node route hop."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TE RFC 3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; } leaf node-id { type te-node-id; description "The identifier of a node in the TE topology."; } leaf hop-type { type te-hop-type; default "strict"; description "Strict or loose hop."; } } } case numbered-link-hop { container numbered-link-hop { description "Numbered link explicit route hop."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TE RFC 3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; leaf link-tp-id { type te-tp-id; mandatory true; description "TE Link Termination Point (LTP) identifier."; } leaf hop-type { type te-hop-type; default "strict"; description "Strict or loose hop."; } leaf direction { type te-link-direction; default "outgoing"; description "Link route object direction."; } } } case unnumbered-link-hop { container unnumbered-link-hop { must '(link-tp-id-uri or link-tp-id) and ' + '(node-id-uri or node-id)' { description "At least one node identifier and at least one Link Termination Point (LTP) identifier need to be present."; } description "Unnumbered link explicit route hop."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels, Section 4.3, EXPLICIT_ROUTE in RSVP-TE RFC 3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; leaf link-tp-id-uri { type nt:tp-id; description "Link Termination Point (LTP) identifier."; } leaf link-tp-id { type te-tp-id; description "TE LTP identifier. The combination of the TE link ID and the TE node ID is used to identify an unnumbered TE link."; } leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; } leaf node-id { type te-node-id; description "The identifier of a node in the TE topology."; } leaf hop-type { type te-hop-type; default "strict"; description "Strict or loose hop."; } leaf direction { type te-link-direction; default "outgoing"; description "Link route object direction."; } } } case as-number { container as-number-hop { description "Autonomous System (AS) explicit route hop."; leaf as-number { type inet:as-number; mandatory true; description "The Autonomous System (AS) number."; } leaf hop-type { type te-hop-type; default "strict"; description "Strict or loose hop."; } } } case label { description "The label explicit route hop type."; container label-hop { description "Label hop type."; uses te-label; } } } } grouping explicit-route-hop-with-srlg { description "Augments the explicit route entry grouping with Shared Risk Link Group (SRLG) hop type."; uses explicit-route-hop { augment "type" { description "Augmentation for a generic explicit route for Shared Risk Link Group (SRLG) inclusion or exclusion."; case srlg { description "An Shared Risk Link Group (SRLG) value to be included or excluded."; container srlg { description "Shared Risk Link Group (SRLG) container."; leaf srlg { type uint32; description "Shared Risk Link Group (SRLG) value."; } } } } } } grouping record-route-state { description "The Record Route grouping."; leaf index { type uint32; description "Record Route hop index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } choice type { description "The Record Route entry type."; case numbered-node-hop { description "Numbered node route hop."; container numbered-node-hop { must 'node-id-uri or node-id' { description "At least one node identifier need to be present."; } description "Numbered node route hop container."; leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; } leaf node-id { type te-node-id; description "The identifier of a node in the TE topology."; } leaf-list flags { type path-attribute-flags; description "Path attributes flags."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } } case numbered-link-hop { description "Numbered link route hop."; container numbered-link-hop { description "Numbered link route hop container."; leaf link-tp-id { type te-tp-id; mandatory true; description "Numbered TE LTP identifier."; } leaf-list flags { type path-attribute-flags; description "Path attributes flags."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } } case unnumbered-link-hop { description "Unnumbered link route hop."; container unnumbered-link-hop { must '(link-tp-id-uri or link-tp-id) and ' + '(node-id-uri or node-id)' { description "At least one node identifier and at least one Link Termination Point (LTP) identifier need to be present."; } description "Unnumbered link Record Route hop."; reference "RFC 3477: Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)"; leaf link-tp-id-uri { type nt:tp-id; description "Link Termination Point (LTP) identifier."; } leaf link-tp-id { type te-tp-id; description "TE LTP identifier. The combination of the TE link ID and the TE node ID is used to identify an unnumbered TE link."; } leaf node-id-uri { type nw:node-id; description "The identifier of a node in the topology."; } leaf node-id { type te-node-id; description "The identifier of a node in the TE topology."; } leaf-list flags { type path-attribute-flags; description "Path attributes flags."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } } case label { description "The label Record Route entry types."; container label-hop { description "Label route hop type."; uses te-label; leaf-list flags { type path-attribute-flags; description "Path attributes flags."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels RFC 4561: Definition of a Record Route Object (RRO) Node-Id Sub-Object"; } } } } } grouping label-restriction-info { description "Label set item information."; leaf restriction { type enumeration { enum inclusive { description "The label or label range is inclusive."; } enum exclusive { description "The label or label range is exclusive."; } } default "inclusive"; description "Indicates whether the list item is inclusive or exclusive."; } leaf index { type uint32; description "The index of the label restriction list entry."; } container label-start { must "(not(../label-end/te-label/direction) and" + " not(te-label/direction))" + " or " + "(../label-end/te-label/direction = te-label/direction)" + " or " + "(not(te-label/direction) and" + " (../label-end/te-label/direction = 'forward'))" + " or " + "(not(../label-end/te-label/direction) and" + " (te-label/direction = 'forward'))" { error-message "'label-start' and 'label-end' must have the " + "same direction."; } description "This is the starting label if a label range is specified. This is the label value if a single label is specified, in which case the 'label-end' attribute is not set."; uses te-label; } container label-end { must "(not(../label-start/te-label/direction) and" + " not(te-label/direction))" + " or " + "(../label-start/te-label/direction = " + "te-label/direction)" + " or " + "(not(te-label/direction) and" + " (../label-start/te-label/direction = 'forward'))" + " or " + "(not(../label-start/te-label/direction) and" + " (te-label/direction = 'forward'))" { error-message "'label-start' and 'label-end' must have the " + "same direction."; } description "This is the ending label if a label range is specified. This attribute is not set if a single label is specified."; uses te-label; } container label-step { description "The step increment between labels in the label range. The label start/end values MUST be consistent with the sign of label step. For example: 'label-start' < 'label-end' enforces 'label-step' > 0 'label-start' > 'label-end' enforces 'label-step' < 0."; choice technology { default "generic"; description "Data-plane technology type."; case generic { leaf generic { type int32; default "1"; description "Label range step."; } } } } leaf range-bitmap { type yang:hex-string; description "When there are gaps between 'label-start' and 'label-end', this attribute is used to specify the positions of the used labels. This is represented in big endian as 'hex-string'. In case the restriction is 'inclusive', the bit-position is set if the corresponding mapped label is available. In this case, if the range-bitmap is not present, all the labels in the range are available. In case the restriction is 'exclusive', the bit-position is set if the corresponding mapped label is not available. In this case, if the range-bitmap is not present, all the labels in the range are not available. The most significant byte in the hex-string is the farthest to the left in the byte sequence. Leading zero bytes in the configured value may be omitted for brevity. Each bit position in the 'range-bitmap' 'hex-string' maps to a label in the range derived from 'label-start'. For example, assuming that 'label-start' = 16000 and 'range-bitmap' = 0x01000001, then: - bit position (0) is set, and the corresponding mapped label from the range is 16000 + (0 * 'label-step') or 16000 for default 'label-step' = 1. - bit position (24) is set, and the corresponding mapped label from the range is 16000 + (24 * 'label-step') or 16024 for default 'label-step' = 1."; } } grouping label-set-info { description "Grouping for the list of label restrictions specifying what labels may or may not be used."; container label-restrictions { description "The label restrictions container."; list label-restriction { key "index"; description "The absence of the label restrictions container implies that all labels are acceptable; otherwise, only restricted labels are available."; reference "RFC 7579: General Network Element Constraint Encoding for GMPLS-Controlled Networks"; uses label-restriction-info; } } } grouping optimization-metric-entry { description "Optimization metrics configuration grouping."; leaf metric-type { type identityref { base path-metric-optimization-type; } description "Identifies the 'metric-type' that the path computation process uses for optimization."; } leaf weight { type uint8; default "1"; description "TE path metric normalization weight."; } container explicit-route-exclude-objects { when "../metric-type = " + "'te-types:path-metric-optimize-excludes'"; description "Container for the 'exclude route' object list."; uses path-route-exclude-objects; } container explicit-route-include-objects { when "../metric-type = " + "'te-types:path-metric-optimize-includes'"; description "Container for the 'include route' object list."; uses path-route-include-objects; } } grouping common-constraints { description "Common constraints grouping that can be set on a constraint set or directly on the tunnel."; uses te-bandwidth { description "A requested bandwidth to use for path computation."; } leaf link-protection { type identityref { base link-protection-type; } default "te-types:link-protection-unprotected"; description "Link protection type required for the links included in the computed path."; reference "RFC 4202: Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)"; } leaf setup-priority { type uint8 { range "0..7"; } default "7"; description "TE LSP requested setup priority."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf hold-priority { type uint8 { range "0..7"; } default "7"; description "TE LSP requested hold priority."; reference "RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels"; } leaf signaling-type { type identityref { base path-signaling-type; } default "te-types:path-setup-rsvp"; description "TE tunnel path signaling type."; } } grouping tunnel-constraints { description "Tunnel constraints grouping that can be set on a constraint set or directly on the tunnel."; leaf network-id { type nw:network-id; description "The network topology identifier."; } uses te-topology-identifier; uses common-constraints; } grouping path-constraints-route-objects { description "List of route entries to be included or excluded when performing the path computation."; container explicit-route-objects { description "Container for the explicit route object lists."; list route-object-exclude-always { key "index"; ordered-by user; description "List of route objects to always exclude from the path computation."; leaf index { type uint32; description "Explicit Route Object index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop { refine "type/numbered-node-hop/numbered-node-hop" + "/hop-type" { must '. = "strict"' { description "Loose hops can only be used for 'include' route objects."; reference "RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE), Section 3.1"; } } } } list route-object-include-exclude { key "index"; ordered-by user; description "List of route objects to include or exclude in the path computation."; leaf explicit-route-usage { type identityref { base route-usage-type; } default "te-types:route-include-object"; description "Indicates whether to include or exclude the route object. The default is to include it."; } leaf index { type uint32; description "Route object include-exclude index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop-with-srlg { refine "type/numbered-node-hop/numbered-node-hop" + "/hop-type" { must '(. = "strict") or ' + 'derived-from-or-self(../../explicit-route-usage,' + '"te-types:route-include-object")' { description "Loose hops can only be used for 'include' route objects."; reference "RFC 4874: Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE), Section 3.1"; } } } } } } grouping path-route-include-objects { description "List of route objects to be included when performing the path computation."; list route-object-include-object { key "index"; ordered-by user; description "List of Explicit Route Objects to be included in the path computation."; leaf index { type uint32; description "Route object entry index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop; } } grouping path-route-exclude-objects { description "List of route objects to be excluded when performing the path computation."; list route-object-exclude-object { key "index"; ordered-by user; description "List of Explicit Route Objects to be excluded in the path computation."; leaf index { type uint32; description "Route object entry index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop-with-srlg; } } grouping generic-path-metric-bounds { description "TE path metric bounds grouping."; container path-metric-bounds { description "Top-level container for the list of path metric bounds."; list path-metric-bound { key "metric-type"; description "List of path metric bounds, which can apply to link and path metrics. TE paths which have at least one path metric which exceeds the specified bounds MUST NOT be selected. TE paths that traverse TE links which have at least one link metric which exceeds the specified bounds MUST NOT be selected."; leaf metric-type { type identityref { base link-path-metric-type; } description "Identifies an entry in the list of 'metric-type' items bound for the TE path."; } leaf upper-bound { type uint64; default "0"; description "Upper bound on the specified 'metric-type'. A zero indicates an unbounded upper limit for the specified 'metric-type'. The unit of is interpreted in the context of the 'metric-type' identity."; } } } } grouping generic-path-optimization { description "TE generic path optimization grouping."; container optimizations { description "The objective function container that includes attributes to impose when computing a TE path."; choice algorithm { description "Optimizations algorithm."; case metric { if-feature "path-optimization-metric"; /* Optimize by metric */ list optimization-metric { key "metric-type"; description "TE path metric type."; uses optimization-metric-entry; } /* Tiebreakers */ container tiebreakers { status deprecated; description "Container for the list of tiebreakers. This container has been deprecated by the tiebreaker leaf."; list tiebreaker { key "tiebreaker-type"; status deprecated; description "The list of tiebreaker criteria to apply on an equally favored set of paths, in order to pick the best."; leaf tiebreaker-type { type identityref { base path-metric-type; } status deprecated; description "Identifies an entry in the list of tiebreakers."; } } } } case objective-function { if-feature "path-optimization-objective-function"; /* Objective functions */ container objective-function { description "The objective function container that includes attributes to impose when computing a TE path."; leaf objective-function-type { type identityref { base objective-function-type; } default "te-types:of-minimize-cost-path"; description "Objective function entry."; } } } } } leaf tiebreaker { type identityref { base path-tiebreaker-type; } default "te-types:path-tiebreaker-random"; description "The tiebreaker criteria to apply on an equally favored set of paths, in order to pick the best."; } } grouping generic-path-affinities { description "Path affinities grouping."; container path-affinities-values { description "Path affinities represented as values."; list path-affinities-value { key "usage"; description "List of named affinity constraints."; leaf usage { type identityref { base resource-affinities-type; } description "Identifies an entry in the list of value affinity constraints."; } leaf value { type admin-groups; default ""; description "The affinity value. The default is empty."; } } } container path-affinity-names { description "Path affinities represented as names."; list path-affinity-name { key "usage"; description "List of named affinity constraints."; leaf usage { type identityref { base resource-affinities-type; } description "Identifies an entry in the list of named affinity constraints."; } list affinity-name { key "name"; description "List of named affinities."; leaf name { type string; description "Identifies a named affinity entry."; } } } } } grouping generic-path-srlgs { description "Path Shared Risk Link Group (SRLG) grouping."; container path-srlgs-lists { description "Path Shared Risk Link Group (SRLG) properties container."; list path-srlgs-list { key "usage"; description "List of Shared Risk Link Group (SRLG) values to be included or excluded."; leaf usage { type identityref { base route-usage-type; } description "Identifies an entry in a list of Shared Risk Link Groups (SRLGs) to either include or exclude."; } leaf-list values { type srlg; description "List of Shared Risk Link Group (SRLG) values."; } } } container path-srlgs-names { description "Container for the list of named Shared Risk Link Groups (SRLGs)."; list path-srlgs-name { key "usage"; description "List of named Shared Risk Link Groups (SRLGs) to be included or excluded."; leaf usage { type identityref { base route-usage-type; } description "Identifies an entry in a list of named Shared Risk Link Groups (SRLGs) to either include or exclude."; } leaf-list names { type string; description "List of named Shared Risk Link Groups (SRLGs)."; } } } } grouping generic-path-disjointness { description "Path disjointness grouping."; leaf disjointness { type te-path-disjointness; description "The type of resource disjointness. When configured for a primary path, the disjointness level applies to all secondary LSPs. When configured for a secondary path, the disjointness level overrides the level configured for the primary path."; } } grouping common-path-constraints-attributes { description "Common path constraints configuration grouping."; uses common-constraints; uses generic-path-metric-bounds; uses generic-path-affinities; uses generic-path-srlgs; } grouping generic-path-constraints { description "Global named path constraints configuration grouping."; container path-constraints { description "TE named path constraints container."; uses common-path-constraints-attributes; uses generic-path-disjointness; } } grouping generic-path-properties { description "TE generic path properties grouping."; container path-properties { config false; description "The TE path properties."; list path-metric { key "metric-type"; description "TE path metric type."; leaf metric-type { type identityref { base path-metric-type; } description "TE path metric type."; } leaf accumulative-value { type uint64; description "TE path metric accumulative value."; } } uses generic-path-affinities; uses generic-path-srlgs; container path-route-objects { description "Container for the list of route objects either returned by the computation engine or actually used by an LSP."; list path-route-object { key "index"; ordered-by user; description "List of route objects either returned by the computation engine or actually used by an LSP."; leaf index { type uint32; description "Route object entry index. The index is used to identify an entry in the list. The order of entries is defined by the user without relying on key values."; } uses explicit-route-hop; } } } } grouping encoding-and-switching-type { description "Common grouping to define the LSP encoding and switching types"; leaf encoding { type identityref { base te-types:lsp-encoding-types; } description "LSP encoding type."; reference "RFC 3945: Generalized Multi-Protocol Label Switching (GMPLS) Architecture"; } leaf switching-type { type identityref { base te-types:switching-capabilities; } description "LSP switching type."; reference "RFC 3945: Generalized Multi-Protocol Label Switching (GMPLS) Architecture"; } } grouping te-generic-node-id { description "A reusable grouping for a TE generic node identifier."; leaf id { type union { type te-node-id; type inet:ip-address; type nw:node-id; } description "The identifier of the node. It can be represented as IP address or dotted quad address or as a URI. The type data node disambiguates the union type."; } leaf type { type enumeration { enum ip { description "IP address representation of the node identifier."; } enum te-id { description "TE identifier of the node"; } enum node-id { description "URI representation of the node identifier."; } } description "Type of node identifier representation."; } } } ]]>
Packet TE Types YANG Module The "ietf-te-packet-types" module imports the following modules: "ietf-yang-types" as defined in "ietf-te-types" as defined in of this document
WG List: Editor: Tarek Saad Editor: Rakesh Gandhi Editor: Vishnu Pavan Beeram Editor: Xufeng Liu Editor: Igor Bryskin "; description "This YANG module contains a collection of generally useful YANG data type definitions specific to Packet Traffic Engineering (TE). The model conforms to the Network Management Datastore Architecture (NMDA). The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: update the date below with the date of RFC publication // and remove this note. revision 2026-01-15 { description "This revision adds the following new identities: - bandwidth-profile-type; - link-metric-delay-variation; - link-metric-loss; - path-metric-delay-variation; - path-metric-loss. This revision adds the following new groupings: - bandwidth-profile-parameters; - te-packet-path-bandwidth; - te-packet-link-bandwidth. This revision provides also few editorial changes."; reference "RFC XXXX: Common YANG Data Types for Traffic Engineering"; } revision 2020-06-10 { description "Latest revision of TE MPLS types."; reference "RFC 8776: Common YANG Data Types for Traffic Engineering"; } /* * Identities */ identity bandwidth-profile-type { description "Bandwidth Profile Types"; } identity mef-10 { base bandwidth-profile-type; description "MEF 10 Bandwidth Profile"; reference "MEF 10.3: Ethernet Services Attributes Phase 3"; } identity rfc-2697 { base bandwidth-profile-type; description "RFC 2697 Bandwidth Profile"; reference "RFC 2697: A Single Rate Three Color Marker"; } identity rfc-2698 { base bandwidth-profile-type; description "RFC 2698 Bandwidth Profile"; reference "RFC 2698: A Two Rate Three Color Marker"; } // Derived identities from te-types:link-metric-type identity link-metric-delay-variation { base te-types:link-metric-type; description "The Unidirectional Delay Variation Metric, measured in units of microseconds."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, Section 4.3 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.3"; } identity link-metric-loss { base te-types:link-metric-type; description "The Unidirectional Link Loss Metric, measured in units of 0.000003%."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions, Section 4.4 RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.4"; } // Derived identities from te-types:path-metric-type identity path-metric-delay-variation { base te-types:path-metric-type; description "The Path Delay Variation Metric, measured in units of microseconds."; reference "RFC 8233: Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs), Section 3.1.2"; } identity path-metric-loss { base te-types:path-metric-type; description "The Path Loss Metric, measured in units of 0.000003%."; reference "RFC 8233: Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs), Section 3.1.3"; } identity backup-protection-type { description "Base identity for the backup protection type."; } identity backup-protection-link { base backup-protection-type; description "Backup provides link protection only."; } identity backup-protection-node-link { base backup-protection-type; description "Backup offers node (preferred) or link protection."; } identity bc-model-type { description "Base identity for the Diffserv-TE Bandwidth Constraints Model type."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"; } identity bc-model-rdm { base bc-model-type; description "Russian Dolls Bandwidth Constraints Model type."; reference "RFC 4127: Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering"; } identity bc-model-mam { base bc-model-type; description "Maximum Allocation Bandwidth Constraints Model type."; reference "RFC 4125: Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering"; } identity bc-model-mar { base bc-model-type; description "Maximum Allocation with Reservation Bandwidth Constraints Model type."; reference "RFC 4126: Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons"; } /* * Typedefs */ typedef te-bandwidth-requested-type { type enumeration { enum specified-value { description "Bandwidth value is explicitly specified."; } enum specified-profile { description "Bandwidth profile is explicitly specified."; } enum auto { description "Bandwidth is automatically computed."; } } description "Enumerated type for specifying whether bandwidth is explicitly specified or automatically computed."; } typedef te-class-type { type uint8; description "Diffserv-TE Class-Type. Defines a set of Traffic Trunks crossing a link that is governed by a specific set of bandwidth constraints. Class-Type is used for the purposes of link bandwidth allocation, constraint-based routing, and admission control."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"; } typedef bc-type { type uint8 { range "0..7"; } description "Diffserv-TE bandwidth constraints as defined in RFC 4124."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering"; } typedef bandwidth-kbps { type uint64; units "kilobits per second"; description "Bandwidth values, expressed in kilobits per second."; } typedef bandwidth-mbps { type uint64; units "megabits per second"; description "Bandwidth values, expressed in megabits per second."; } typedef bandwidth-gbps { type uint64; units "gigabits per second"; description "Bandwidth values, expressed in gigabits per second."; } /* * Groupings */ grouping performance-metrics-attributes-packet { description "Contains Performance Metrics (PM) information."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; uses te-types:performance-metrics-attributes { augment "performance-metrics-one-way" { description "Performance Metrics (PM) one-way packet-specific augmentation for a generic PM grouping."; leaf one-way-min-delay { type uint32 { range "0..16777215"; } units "microseconds"; description "One-way minimum delay or latency."; } leaf one-way-min-delay-normality { type te-types:performance-metrics-normality; default "normal"; description "One-way minimum delay or latency normality."; } leaf one-way-max-delay { type uint32 { range "0..16777215"; } units "microseconds"; description "One-way maximum delay or latency."; } leaf one-way-max-delay-normality { type te-types:performance-metrics-normality; default "normal"; description "One-way maximum delay or latency normality."; } leaf one-way-delay-variation { type uint32 { range "0..16777215"; } units "microseconds"; description "One-way delay variation."; reference "RFC 5481: Packet Delay Variation Applicability Statement, Section 4.2"; } leaf one-way-delay-variation-normality { type te-types:performance-metrics-normality; default "normal"; description "One-way delay variation normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; } leaf one-way-packet-loss { type decimal64 { fraction-digits 6; range "0..50.331642"; } units "percent"; description "One-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%."; reference "RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions, Section 4.4"; } leaf one-way-packet-loss-normality { type te-types:performance-metrics-normality; default "normal"; description "Packet loss normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; } } augment "performance-metrics-two-way" { description "Performance Metrics (PM) two-way packet-specific augmentation for a generic PM grouping."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; leaf two-way-min-delay { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "Two-way minimum delay or latency."; } leaf two-way-min-delay-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way minimum delay or latency normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; } leaf two-way-max-delay { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "Two-way maximum delay or latency."; } leaf two-way-max-delay-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way maximum delay or latency normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; } leaf two-way-delay-variation { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "Two-way delay variation."; reference "RFC 5481: Packet Delay Variation Applicability Statement, Section 4.2"; } leaf two-way-delay-variation-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way delay variation normality."; reference "RFC 7471: OSPF Traffic Engineering (TE) Metric Extensions RFC 8570: IS-IS Traffic Engineering (TE) Metric Extensions RFC 7823: Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions"; } leaf two-way-packet-loss { type decimal64 { fraction-digits 6; range "0..50.331642"; } units "percent"; default "0"; description "Two-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%."; } leaf two-way-packet-loss-normality { type te-types:performance-metrics-normality; default "normal"; description "Two-way packet loss normality."; } } } } grouping one-way-performance-metrics-packet { description "One-way packet Performance Metrics (PM) throttle grouping."; leaf one-way-min-delay { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "One-way minimum delay or latency."; } leaf one-way-max-delay { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "One-way maximum delay or latency."; } leaf one-way-delay-variation { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "One-way delay variation."; } leaf one-way-packet-loss { type decimal64 { fraction-digits 6; range "0..50.331642"; } units "percent"; default "0"; description "One-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%."; } } grouping one-way-performance-metrics-gauge-packet { description "One-way packet Performance Metrics (PM) throttle grouping. This grouping is used to report the same metrics defined in the one-way-performance-metrics-packet grouping, using gauges instead of uint32 data types and referencing IPPM RFCs instead of IGP-TE RFCs."; leaf one-way-min-delay { type yang:gauge64; units "microseconds"; description "One-way minimum delay or latency."; } leaf one-way-max-delay { type yang:gauge64; units "microseconds"; description "One-way maximum delay or latency."; reference "RFC 7679: A One-Way Delay Metric for IP Performance Metrics (IPPM)"; } leaf one-way-delay-variation { type yang:gauge64; units "microseconds"; description "One-way delay variation."; reference "RFC 3393: IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)"; } leaf one-way-packet-loss { type decimal64 { fraction-digits 5; range "0..100"; } description "The ratio of packets dropped to packets transmitted between two endpoints."; reference "RFC 7680: A One-Way Loss Metric for IP Performance Metrics (IPPM)"; } } grouping two-way-performance-metrics-packet { description "Two-way packet Performance Metrics (PM) throttle grouping."; leaf two-way-min-delay { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "Two-way minimum delay or latency."; } leaf two-way-max-delay { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "Two-way maximum delay or latency."; } leaf two-way-delay-variation { type uint32 { range "0..16777215"; } units "microseconds"; default "0"; description "Two-way delay variation."; } leaf two-way-packet-loss { type decimal64 { fraction-digits 6; range "0..50.331642"; } units "percent"; default "0"; description "Two-way packet loss as a percentage of the total traffic sent over a configurable interval. The finest precision is 0.000003%."; } } grouping two-way-performance-metrics-gauge-packet { description "Two-way packet Performance Metrics (PM) throttle grouping. This grouping is used to report the same metrics defined in the two-way-performance-metrics-packet grouping, using gauges instead of uint32 data types and referencing IPPM RFCs instead of IGP-TE RFCs."; leaf two-way-min-delay { type yang:gauge64; units "microseconds"; description "Two-way minimum delay or latency."; reference "RFC 2681: A Round-trip Delay Metric for IPPM"; } leaf two-way-max-delay { type yang:gauge64; units "microseconds"; description "Two-way maximum delay or latency."; reference "RFC 2681: A Round-trip Delay Metric for IPPM"; } leaf two-way-delay-variation { type yang:gauge64; units "microseconds"; description "Two-way delay variation."; reference "RFC 5481: Packet Delay Variation Applicability Statement"; } leaf two-way-packet-loss { type decimal64 { fraction-digits 5; range "0..100"; } description "The ratio of packets dropped to packets transmitted between two endpoints."; } } grouping performance-metrics-throttle-container-packet { description "Packet Performance Metrics (PM) threshold grouping."; uses te-types:performance-metrics-throttle-container { augment "throttle/threshold-out" { description "Performance Metrics (PM) threshold-out packet augmentation for a generic grouping."; uses one-way-performance-metrics-packet; uses two-way-performance-metrics-packet; } augment "throttle/threshold-in" { description "Performance Metrics (PM) threshold-in packet augmentation for a generic grouping."; uses one-way-performance-metrics-packet; uses two-way-performance-metrics-packet; } augment "throttle/threshold-accelerated-advertisement" { description "Performance Metrics (PM) accelerated advertisement packet augmentation for a generic grouping."; uses one-way-performance-metrics-packet; uses two-way-performance-metrics-packet; } } } grouping bandwidth-profile-parameters { description "Common parameters to define bandwidth profiles, also known as traffic profiles in RFC 2475, that may be used to specify the temporal properties of a packet stream (e.g., MPLS-TE LSPs), e.g., as specified in MEF 10, RFC 2697 or RFC 2698."; reference "RFC 2475: An Architecture for Differentiated Services MEF 10.3: Ethernet Services Attributes Phase 3 RFC 2697: A Single Rate Three Color Marker RFC 2698: A Two Rate Three Color Marker"; leaf cir { type uint64; units "bits per second"; description "Committed Information Rate (CIR)."; } leaf cbs { type uint64; units "bytes"; description "Committed Burst Size (CBS)."; } leaf eir { type uint64; units "bits per second"; description "Excess Information Rate (EIR)."; } leaf ebs { type uint64; units "bytes"; description "Excess Burst Size (EBS)."; } leaf pir { type uint64; units "bits per second"; description "Peak Information Rate (PIR)."; } leaf pbs { type uint64; units "bytes"; description "Peak Burst Size (PBS)."; } } grouping te-packet-path-bandwidth { description "Bandwidth attributes for TE Packet paths."; container packet-bandwidth { description "Bandwidth attributes for TE Packet paths."; leaf specification-type { type te-bandwidth-requested-type; description "The bandwidth specification type, either explicitly specified or automatically computed."; } leaf set-bandwidth { when "../specification-type = 'specified-value'" { description "When the bandwidth value is explicitly specified."; } type bandwidth-kbps; description "Set the bandwidth value explicitly, e.g., using offline calculation."; } container bandwidth-profile { when "../specification-type = 'specified-profile'" { description "When the bandwidth profile is explicitly specified."; } description "Set the bandwidth profile attributes explicitly."; leaf bandwidth-profile-name { type string; description "Name of Bandwidth Profile."; } leaf bandwidth-profile-type { type identityref { base bandwidth-profile-type; } description "Type of Bandwidth Profile."; } uses bandwidth-profile-parameters; } leaf class-type { type te-types:te-ds-class; description "The Class-Type of traffic transported by the LSP."; reference "RFC 4124: Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering, Section 4.3.1"; } leaf signaled-bandwidth { type te-packet-types:bandwidth-kbps; config false; description "The currently signaled bandwidth of the LSP. In the case where the bandwidth is specified explicitly, then this will match the value of the set-bandwidth leaf. In the cases where the bandwidth is dynamically computed by the system, the current value of the bandwidth should be reflected."; } } } grouping te-packet-link-bandwidth { description "Bandwidth attributes for Packet TE links."; leaf packet-bandwidth { type uint64; units "bits per second"; description "Bandwidth value for Packet TE links."; } } } ]]>
IANA Considerations This document requests IANA to update the following URIs in the "IETF XML Registry" to refer to this document:
This document requests IANA to register the following YANG modules in the "YANG Module Names" registry within the "YANG Parameters" registry group.
Security Considerations This section is modeled after the template described in Section 3.7 of . The "ietf-te-types" and the "ietf-te-packet-types" YANG modules define data models that are designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) 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. The YANG modules define a set of identities, types, and groupings. These nodes are intended to be reused by other YANG modules. The modules by themselves do not expose any data nodes that are writable, data nodes that contain read-only state, or RPCs. As such, there are no additional security issues related to the YANG module that need to be considered. Modules that use the groupings that are defined in this document should identify the corresponding security considerations. For example using 'explicit-route-hop', 'record-route-state' or 'te-topology-identifier' (which includes the 'client-id') groupings may expose sensitive topology information.
Information Technology - Programming Languages - C International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) 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] The YANG 1.1 Data Modeling Language 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). Common YANG Data Types for Traffic Engineering 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. Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Common YANG Data Types This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. Common YANG Data Types for the Routing Area 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. MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled. This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] MPLS Transport Profile (MPLS-TP) Linear Protection 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. 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] RSVP-TE: Extensions to RSVP for LSP Tunnels 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] Fast Reroute Extensions to RSVP-TE for LSP Tunnels 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. 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] MPLS Traffic Engineering Soft Preemption 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] Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE 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. 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] Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) 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. 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. 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. 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] Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) 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. Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) 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. 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] Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions 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. 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] Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) 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). 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. 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] Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) 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). 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] The Use of Entropy Labels in MPLS Forwarding 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] GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration 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. RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information 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). RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) 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. Residence Time Measurement in MPLS Networks 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. 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. RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery 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] Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) This document defines protocol extensions and procedures for BGP Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. [STANDARDS-TRACK] RSVP ASSOCIATION Object Extensions 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] GMPLS Segment Recovery 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] Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other. Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) 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.). 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. 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. 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] Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description 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] Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control 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] Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF- and ITU-defined parameters is also covered. Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP). [STANDARDS-TRACK] Revised Definition of the GMPLS Switching Capability and Type Fields GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via the Switching Capability field, and in signaling protocols via the Switching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs 3471, 4202, 4203, and 5307. Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203. Traffic Engineering (TE) Extensions to OSPF Version 2 This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric 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. Path Computation Element (PCE) Communication Protocol (PCEP) This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] OSPF Traffic Engineering (TE) Metric Extensions 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. 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. 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. Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation. IS-IS Traffic Engineering (TE) Metric Extensions 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. 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. 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. This document obsoletes RFC 7810. Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains. This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support H-PCE procedures. A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. [STANDARDS-TRACK] Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information. This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity. This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled within in a Resource Reservation Protocol TE (RSVP-TE) explicit route object. [STANDARDS-TRACK] Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization The Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution. This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK] Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs. This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. This document obsoletes RFC 6006. The BGP Tunnel Encapsulation Attribute This document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels. This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired. Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering 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] MPLS Transport Profile (MPLS-TP) Identifiers 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. 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] Attachment Individual Identifier (AII) Types for Aggregation 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] A Recommendation for IPv6 Address Text Representation As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). 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. 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. 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] IS-IS Extensions for Traffic Engineering 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] IPv6 Traffic Engineering in IS-IS 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] A YANG Data Model for Network Topologies 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. Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) 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). 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. IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK] A One-Way Delay Metric for IP Performance Metrics (IPPM) This memo defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IP Performance Metrics (IPPM) Framework document, RFC 2330; the reader is assumed to be familiar with that document. This memo makes RFC 2679 obsolete. A Round-trip Delay Metric for IPPM This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK] Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) 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] Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) 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] Definition of a Record Route Object (RRO) Node-Id Sub-Object 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] Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths 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] GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks 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. 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. RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) 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. GMPLS RSVP-TE Extensions for Lock Instruct and Loopback 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. General Network Element Constraint Encoding for GMPLS-Controlled Networks 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. 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. An Update to YANG Module Names Registration This document amends the IANA guidance on the uniqueness of YANG module and submodule names. The document updates RFC 6020 to clarify how modules and their revisions are handled by IANA. Network Configuration Access Control Model 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. This document obsoletes RFC 6536. Ethernet Services Attributes Phase 3 MEF Network Configuration Protocol (NETCONF) 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] RESTCONF Protocol 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). Guidelines for Authors and Reviewers of Documents Containing YANG Data Models YumaWorks Orange Huawei This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP) Cisco Systems, Inc. Cisco Systems, Inc. ZTE Corporation Huawei Technologies Nokia This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to enhance support for Segment Routing (SR) with a focus on the use of Segment Identifiers (SIDs) and SR- Algorithms in Traffic Engineering (TE). The SR-Algorithm associated with a SID defines the path computation algorithm used by Interior Gateway Protocols (IGPs). It introduces mechanisms for PCEP peers to signal SR-Algorithm associated with SIDs by encoding this information in Explicit Route Object (ERO) and Record Route Object (RRO) subobjects, enables SR-Algorithm constraints for path computation, and defines new metric types for the METRIC object. This document updates RFC 8664 and RFC 9603 to allow such extensions. YANG Tree Diagrams This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. Generalized Multi-Protocol Label Switching (GMPLS) Architecture Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. [STANDARDS-TRACK] A Framework for MPLS in Transport Networks This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document. 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. This document is not an Internet Standards Track specification; it is published for informational purposes. Multiprotocol Label Switching Architecture This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] OSPF Version 2 This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] Framework for IP Performance Metrics The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK] Overview and Principles of Internet Traffic Engineering This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) 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. Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) 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. Requirements for Traffic Engineering Over MPLS 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. Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions 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. Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering 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. Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons 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. Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering 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. An Architecture for Differentiated Services This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. A Single Rate Three Color Marker This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community. A Two Rate Three Color Marker This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community. Path Computation Element (PCE) Communication Protocol Generic Requirements 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. The IETF XML Registry 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. The Secure Shell (SSH) Authentication Protocol The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] The Transport Layer Security (TLS) Protocol Version 1.3 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. 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. QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.
The Complete Schema Trees This appendix presents the complete tree of the TE and Packet TE types data model. See for an explanation of the symbols used. The data type of every leaf node is shown near the right end of the corresponding line.
TE Types Schema Tree
Packet TE Types Schema Tree
Changes from RFC 8776 This version adds new common data types, identities, and groupings to the YANG modules. It also updates some of the existing data types, identities, and groupings in the YANG modules and fixes few bugs in . The following new identities have been added to the 'ietf-te-types' module: lsp-provisioning-error-reason; association-type-diversity; tunnel-admin-state-auto; lsp-restoration-restore-none; restoration-scheme-rerouting; path-metric-optimization-type; link-path-metric-type; link-metric-type and its derived identities; path-computation-error-reason and its derived identities; protocol-origin-type and its derived identities; svec-objective-function-type and its derived identities; svec-metric-type and its derived identities. The following new data types have been added to the 'ietf-te-types' module: path-type. The following new groupings have been added to the 'ietf-te-types' module: explicit-route-hop-with-srlg; encoding-and-switching-type; te-generic-node-id. The following new identities have been added to the 'ietf-te-packet-types' module: bandwidth-profile-type; link-metric-delay-variation; link-metric-loss; path-metric-delay-variation; path-metric-loss. The following new groupings have been added to the 'ietf-te-packet-types' module: te-packet-path-bandwidth; te-packet-link-bandwidth. The following identities, already defined in , have been updated in the 'ietf-te-types' module: objective-function-type (editorial); action-exercise (bug fix); path-metric-type: new base identities have been added; path-metric-te (bug fix); path-metric-igp (bug fix); path-metric-hop (bug fix); path-metric-delay-average (bug fix); path-metric-delay-minimum (bug fix); path-metric-residual-bandwidth (bug fix); path-metric-optimize-includes (bug fix); path-metric-optimize-excludes (bug fix); te-optimization-criterion (editorial). The following data type, already defined in , has been updated in the 'ietf-te-types' module: te-node-id; The data type has been changed to be a union. The following groupings, already defined in , have been updated in the 'ietf-te-types' module: explicit-route-hop The following new leaves have been added to the 'explicit-route-hop' grouping: node-id-uri; link-tp-id-uri; The following leaves, already defined in , have been updated in the 'explicit-route-hop': node-id; link-tp-id. The "mandatory true" statements for the node-id and link-tp-id have been replaced by "must" statements that requires at least the presence of: node-id or node-id-uri; link-tp-id or link-tp-id-uri. explicit-route-hop The following new leaves have been added to the 'explicit-route-hop' grouping: node-id-uri; link-tp-id-uri; The following leaves, already defined in , have been updated in the 'explicit-route-hop': node-id; link-tp-id. The "mandatory true" statements for the node-id and link-tp-id have been replaced by "must" statements that requires at least the presence of: node-id or node-id-uri; link-tp-id or link-tp-id-uri. optimization-metric-entry: The following leaves, already defined in , have been updated in the 'optimization-metric-entry': metric-type; The base identity has been updated without impacting the set of derived identities that are allowed. tunnel-constraints; The following new leaf has been added to the 'tunnel-constraints' grouping: network-id; path-constraints-route-objects: The following container, already defined in , has been updated in the 'path-constraints-route-objects': explicit-route-objects-always; The container has been renamed as 'explicit-route-objects'. This change is not affecting any IETF standard YANG data models since this grouping has not yet been used by any YANG data model defined in existing IETF RFCs. generic-path-metric-bounds: The following leaves, already defined in , have been updated in the 'optimization-metric-entry': metric-type; The base identity has been updated to: increase the set of derived identities that are allowed and; remove from this set the 'path-metric-optimize-includes' and the 'path-metric-optimize-excludes' identities (bug fixing) generic-path-optimization The following new leaf has been added to the 'generic-path-optimization' grouping: tiebreaker; The following container, already defined in , has been deprecated: tiebreakers. The following identities, already defined in , have been obsoleted in the 'ietf-te-types' module for bug fixing: of-minimize-agg-bandwidth-consumption (the 'svec-of-minimize-agg-bandwidth-consumption' identity should be used instead); of-minimize-load-most-loaded-link (the 'svec-of-minimize-load-most-loaded-link' identity should be used instead); of-minimize-cost-path-set (the 'svec-of-minimize-cost-path-set' identity should be used instead); lsp-protection-reroute-extra (the 'restoration-scheme-rerouting' identity should be used instead); lsp-protection-reroute (the 'restoration-scheme-rerouting' identity should be used instead).
Acknowledgements The authors would like to thank Robert Wilton, Lou Berger, Mahesh Jethanandani and Jeff Haas for their valuable input to the discussion about the process to follow to provide tiny updates to a YANG module already published as an RFC. The authors would like to thank Mohamed Boucadair and Sergio Belotti for their valuable comments and suggestions on this document. This document was prepared using kramdown.
Contributors Juniper Networks
vbeeram@juniper.net
Cisco Systems, Inc.
rgandhi@cisco.com