One document matched: draft-ietf-isis-pcr-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1195 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC6329 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6329.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC5303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5303.xml">
<!ENTITY RFC5305 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml">
<!ENTITY RFC5307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5307.xml">
<!ENTITY RFC5310 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5310.xml">
<!ENTITY I-D.ietf-isis-te-metric-extensions SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-isis-te-metric-extensions.xml">
<!ENTITY I-D.ietf-rtgwg-mrt-frr-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-mrt-frr-architecture.xml">
<!ENTITY I-D.ietf-rtgwg-mrt-frr-algorithm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-mrt-frr-algorithm.xml">
<!ENTITY I-D.bowers-rtgwg-mrt-applicability-to-8021qca SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bowers-rtgwg-mrt-applicability-to-8021qca.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-isis-pcr-05" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="IS-IS PCR">IS-IS Path Computation and Reservation</title>
<author fullname="János Farkas" initials="J." surname="Farkas" role="editor">
<organization>Ericsson</organization>
<address>
<postal>
<street>Konyves Kálmán krt. 11/B</street>
<city>Budapest</city>
<country>Hungary</country>
<code>1097</code>
</postal>
<email>janos.farkas@ericsson.com</email>
</address>
</author>
<author fullname="Nigel Bragg" initials="N." surname="Bragg">
<organization>Ciena</organization>
<address>
<postal>
<street>43-51 Worship Street</street>
<city>London</city>
<country>UK</country>
<code>EC2A 2DX</code>
</postal>
<email>nbragg@ciena.com</email>
</address>
</author>
<author fullname="Paul Unbehagen Jr" initials="P." surname="Unbehagen">
<organization>Avaya</organization>
<address>
<postal>
<street>1300 W. 120th Avenue</street>
<city>Westminster</city>
<country>USA</country>
<code>CO 80234</code>
</postal>
<email>unbehagen@avaya.com</email>
</address>
</author>
<author fullname="Glenn Parsons" initials="G." surname="Parsons">
<organization>Ericsson</organization>
<address>
<postal>
<street>349 Terry Fox Drive</street>
<city>Ottawa</city>
<country>Canada</country>
<code>ON, K2K 2V6</code>
</postal>
<email>glenn.parsons@ericsson.com</email>
</address>
</author>
<author fullname="Peter Ashwood-Smith" initials="P." surname="Ashwood-Smith">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>303 Terry Fox Drive, Suite 400</street>
<city>Ottawa</city>
<country>Canada</country>
<code>ON, K2K 3J1</code>
</postal>
<email>Peter.AshwoodSmith@huawei.com</email>
</address>
</author>
<author fullname="Chris Bowers" initials="C." surname="Bowers">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>cbowers@juniper.net</email>
</address>
</author>
<date month="February" day="11" year="2016" />
<area>Routing</area>
<workgroup>IS-IS for IP Internets</workgroup>
<keyword>IS-IS, SPB</keyword>
<abstract>
<t>IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest Path Bridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR.</t>
</abstract>
</front>
<!-- ***** MIDDLE MATTER ***** -->
<middle>
<section title="Introduction">
<t>IEEE 802.1Qca Path Control and Reservation (PCR) <xref target="IEEE8021Qca"/> specifies extensions to IS-IS for the control of Explicit Trees (ETs). The PCR extensions are compatible with the Shortest Path Bridging (SPB) extensions to IS-IS specified by <xref target="RFC6329"/> and <xref target="IEEE8021aq"/> (already rolled into <xref target="IEEE8021Q"/>). Furthermore, IS-IS with PCR extensions relies on the SPB architecture and terminology; and some of the IS-IS SPB sub-TLVs are also leveraged. IS-IS PCR builds upon IS-IS and uses IS-IS in a similar way to SPB. IS-IS PCR only addresses point-to-point physical links, although IS-IS also supports shared media LANs.</t>
<t>This document specifies five IS-IS sub-TLVs for the control of explicit trees by IS-IS PCR in a Layer 2 network as specified by IEEE 802.1Qca. In addition to the sub-TLVs specified here, IS-IS PCR relies on the following IS-IS SPB sub-TLVs specified by <xref target="RFC6329"/>:</t>
<t><list style="symbols">
<t>SPB Link Metric sub-TLV</t>
<t>SPB Base VLAN-Identifiers sub-TLV</t>
<t>SPB Instance sub-TLV</t>
<t>SPBV MAC address sub-TLV</t>
<t>SPBM Service Identifier and Unicast Address sub-TLV</t>
</list></t>
<t>These sub-TLVs are used to provide the link metric and the associations among bridges, MAC addresses, VIDs and I-SIDs within an IS-IS domain. The use of these SPB sub-TLVs for PCR is specified by IEEE 802.1Qca. Note that IS-IS PCR does not require the implementation of the full IS-IS SPB protocol but only the support of these SPB sub-TLVs. A bridge can support both IS-IS SPB and IS-IS PCR at the same time but when it supports both they are implemented by the same IS-IS entity on a per instance basis.</t>
<t>The sub-TLVs specified here can be also applied for Fast ReRoute using Maximally Redundant Trees (MRT-FRR) <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/> in a Layer 2 network. MRTs are computed as specified in <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>. If MRT computation is split such that the Generalized Almost Directed Acyclic Graph (GADAG) is computed centrally, then these sub-TLVs can be used to distribute the GADAG, which is identical for each network node throughout a network domain.</t>
<t>PCR uses IS-IS, the SPB sub-TLVs listed above, and the new sub-TLVs defined here. IS-IS PCR has no impact to IETF protocols.</t>
</section>
<section title="Conventions Used in This Document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section title="Terminology and Definitions">
<t>This document uses the terminology defined in <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. Only the abbreviations are resolved here for the MRT terms, please refer to <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/> for the complete definition.</t>
<t><list style="hanging">
<t hangText="ADAG:">Almost Directed Acyclic Graph <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/></t>
<t hangText="B-VID:">Backbone VID <xref target="IEEE8021Q"/></t>
<t hangText="Base VID:">The VID used to identify a VLAN in management operations. <xref target="IEEE8021Q"/></t>
<t hangText="BLCE:">Bridge Local Computation Engine - A computation engine in a bridge that performs path and routing computations. The BLCE implements e.g. SPF, CSPF, or the Maximally Redundant Trees Algorithm. <xref target="IEEE8021Qca"/></t>
<t hangText="Constrained tree:">A tree meeting a certain constraint, e.g. providing a minimal available bandwidth. <xref target="IEEE8021Qca"/></t>
<t hangText="DAG:">Directed Acyclic Graph <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/></t>
<t hangText="DEI:">Drop Eligible Indicator <xref target="IEEE8021Q"/></t>
<t hangText="ECT Algorithm:">Equal Cost Tree Algorithm - The algorithm and mechanism that is used for the control of the active topology, i.e. forwarding trees. It can be one of the shortest path algorithms specified by <xref target="IEEE8021Q"/>. It can be also one of the explicit path control algorithms specified by <xref target="IEEE8021Qca"/>. Each ECT Algorithm has a 32-bit unique ID.</t>
<t hangText="ET:">Explicit Tree - An explicitly defined tree, which is specified by its Edge Bridges and the paths among the Edge Bridges. If only the Edge Bridges are specified but the paths are not, then it is a loose explicit tree. If the paths are also specified, then it is a strict explicit tree. <xref target="IEEE8021Qca"/></t>
<t hangText="ETDB:">Explicit Tree Database - A database storing explicit trees. <xref target="IEEE8021Qca"/></t>
<t hangText="FDB:">Filtering Database <xref target="IEEE8021Q"/></t>
<t hangText="GADAG:">Generalized ADAG <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/></t>
<t hangText="Hop:">A hop is specified by two nodes. A strict hop has no intermediate nodes, whereas a loose hop can have one or more intermediate nodes. IS-IS PCR specifies an explicit tree by an ordered list of hops starting at the root, each successive hop being defined by the next element of the list. <xref target="IEEE8021Qca"/></t>
<t hangText="I-SID:">Backbone Service Instance Identifier - A 24-bit ID. <xref target="IEEE8021Q"/></t>
<t hangText="MRT:"> Maximally Redundant Trees <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/></t>
<t hangText="MRT-Blue:"> MRT-Blue is used to describe one of the two MRTs. <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/></t>
<t hangText="MRT-Red:"> MRT-Red is used to describe one of the two MRTs. <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/></t>
<t hangText="MRT Root:"> The common root of the two MRTs: MRT-Blue and MRT-Red.</t>
<t hangText="MSRP:">Multiple Stream Registration Protocol, standardized as IEEE 802.1Qat, already rolled into <xref target="IEEE8021Q"/>.</t>
<t hangText="PCA:">Path Control Agent - The agent that is part of the IS-IS domain and thus can perform IS-IS operations on behalf of a PCE, e.g. maintain the LSDB and send LSPs. <xref target="IEEE8021Qca"/></t>
<t hangText="PCE:">Path Computation Element - An entity that is capable of computing a path through a network based on a representation of the topology of the network (obtained by undefined means external to the PCE). <xref target="RFC4655"/></t>
<t hangText="PCP:">Priority Code Point, which identifies a traffic class. <xref target="IEEE8021Q"/></t>
<t hangText="PTP:">Precision Time Protocol specified by <xref target="IEEE1588"/>.</t>
<t hangText="SPBM:">SPB MAC - The SPB mode where a MAC or its shorthand (SPSourceID: Shortest Path Source ID) is used to identify an SPT. <xref target="IEEE8021Q"/></t>
<t hangText="SPBV:">SPB VID - The SPB mode where a unique VID is assigned to each SPT Root bridge and is used to identify an SPT. <xref target="IEEE8021Q"/></t>
<t hangText="SPF:">Shortest Path First</t>
<t hangText="SPT:">Shortest Path Tree <xref target="IEEE8021Q"/></t>
<t hangText="SRLG:">Shared Risk Link Group - A set of links that share a resource whose failure affects each link. <xref target="RFC5307"/></t>
<t hangText="TAI:">Temps Atomique International - International Atomic Time <xref target="IEEE1588"/></t>
<t hangText="TED:">Traffic Engineering Database - A database storing the traffic engineering information propagated by IS-IS. <xref target="RFC5305"/></t>
<t hangText="VID:">VLAN ID <xref target="IEEE8021Q"/></t>
<t hangText="VLAN:">Virtual Local Area Network <xref target="IEEE8021Q"/></t>
</list></t>
</section>
<section anchor="sec_trees" title="Explicit Trees">
<t>Explicit trees may be determined in some fashion. For example, an explicit tree may be determined by a Path Computation Element (PCE) <xref target="RFC4655"/>. A PCE is an entity that is capable of computing a topology for forwarding based on a network topology, its corresponding attributes, and potential constraints. If a PCE is used, it MUST explicitly describe a forwarding tree as described in <xref target="sec_topology"/>. Either a single PCE or multiple PCEs determine explicit trees for a domain. Even if there are multiple PCEs in a domain, each explicit tree MUST be only determined by one PCE, which is referred to as the owner PCE of the tree. PCEs and IS-IS PCR can be used in combination with IS-IS SPB shortest path routing. The remainder of this section, and subsequent sections, are written assuming PCE use.</t>
<t>The PCE interacts with the active topology control protocol, i.e. with IS-IS. The collaboration with IS-IS can be provided by a Path Control Agent (PCA) on behalf of a PCE. Either the PCE or the corresponding PCA is part of the IS-IS domain. If the PCE is not part of the IS-IS domain, then the PCE MUST be associated with a PCA that is part of the IS-IS domain. The PCE or its PCA MUST establish IS-IS adjacency in order to receive all the LSPs transmitted by the bridges in the domain. The PCE, either on its own or via its PCA, can control the establishment of explicit trees in that domain by injecting an LSP conveying an explicit tree and thus instruct IS-IS to set up the explicit tree determined by the PCE. If instructed to do so by a PCE, IS-IS MAY also record and communicate bandwidth assignments, which MUST NOT be applied if reservation protocol (e.g. Multiple Stream Registration Protocol (MSRP)) is used in the domain. Both MSRP and IS-IS MUST NOT be used to make bandwidth assignments in the same domain.</t>
<t>The operation details of the PCE are not specified by this document or by IEEE 802.1Qca. If the PCE is part of the IS-IS domain, then the PCE uses IS-IS PDUs to communicate with the IS-IS domain and the PCE has a live IS-IS LSDB, (i.e. the PCE implements the PCA functions too). A PCE can instead communicate with the IS-IS domain via a PCA, e.g. to retrieve the LSDB or instruct the creation of an explicit tree. However, the means of communication between the PCE and the PCA is not specified by this document or by IEEE 802.1Qca.</t>
<t>An Explicit Tree (ET) is an undirected loop-free topology, whose use is under the control of the owner PCE by means of associating VIDs and MAC addresses with it. An ET MUST NOT contain Cycles. As it is undirected, an ET contains no assumptions about the direction of any flows that use it; it can be used in either direction as specified by the VIDs and MAC addresses associated with it. It is the responsibility of the PCE to ensure reverse path congruency and multicast-unicast congruency if that is required.</t>
<t>An explicit tree is either strict or loose. A strict explicit tree specifies all bridges and paths it comprises. A loose tree only specifies the bridges as a list of hops that have a special role in the tree, e.g. an Edge Bridge, and no path or path segment is specified between the bridges, which are therefore loose hops even if Edge Bridges are adjacent neighbors. The special role of a hop can be: Edge Bridge, root, leaf, a bridge to be avoided, or a transit hop in case of a tree with a single leaf. The path for a loose hop is determined by the Bridge Local Computation Engine (BLCE) of the bridges. The shortest path is used for a loose hop unless specified otherwise by the descriptor (<xref target="sec_topology"/>) of the tree or by the corresponding ECT Algorithm (<xref target="sec_ect"/>).</t>
<t>A loose explicit tree is constrained if the tree descriptor includes one or more constraints, e.g. the administrative group that the links of the tree have to belong to. The BLCE of the bridges then apply the Constrained Shortest Path First (CSPF) algorithm, which is Shortest Path First (SPF) on the topology that only contains the links meeting the constraint(s).</t>
<t>An explicit tree is specified by a Topology sub-TLV (<xref target="sec_topology"/>). The Topology sub-TLV associates one or more VIDs with an explicit tree. The Topology sub-TLV includes two or more Hop sub-TLVs (<xref target="sec_hop"/>), and a hop is specified by an IS-IS System ID. A Hop sub-TLV MAY include a delay constraint for a loose hop. A Topology sub-TLV MAY also include further sub-TLVs to constrain loose hops. The bridges involved in an explicit tree store the corresponding Topology sub-TLVs in their Explicit Tree Database (ETDB).</t>
<t>Explicit trees are propagated and set-up by IS-IS PCR in a domain. The PCE or its PCA assembles the Topology sub-TLVs (<xref target="sec_topology"/>), and adds it into an LSP, which is flooded throughout the domain. The Topology sub-TLV is flooded by the same techniques used for the SPB LSPs. The bridges then MUST process the Topology sub-TLV upon reception. If the Topology sub-TLV specifies one or more loose trees, then the path for the loose hops is determined by the BLCE of the bridges. The bridges then install the appropriate FDB entries for frame forwarding along the tree described by the Topology sub-TLV, or the trees computed based on the Topology sub-TLV. Dynamic Filtering Entries are maintained by IS-IS for the VID, MAC address tuples associated with an ET.</t>
<t>Due to the LSP aging of IS-IS, the Topology sub-TLVs (<xref target="sec_topology"/>) have to be refreshed similar to other IS-IS TLVs in order to keep the integrity of the LSDB. The corresponding Dynamic Filtering Entries are also refreshed in the FDB when a Topology sub-TLV is refreshed. Refreshing Topology sub-TLVs is the task of the entity being part of the IS-IS domain, i.e. either the PCE or the PCA.</t>
<t>The owner PCE can withdraw an explicit tree by sending an updated LSP that does not include the Topology sub-TLV (<xref target="sec_topology"/>). If a Topology sub-TLV is removed from an LSP (or has been changed), so that (previous) Topology sub-TLV is no longer present (or has been changed) in the LSDB, then that (previous) Topology sub-TLV is implicitly withdrawn. ISIS-PCR then removes (or updates) the explicit tree.</t>
<t>There is no precedence order between Explicit Trees. Precedence order among bandwidth assignments recorded by IS-IS PCR is specified in <xref target="sec_assignment"/>.</t>
<t>If it is not possible to install an explicit tree, e.g. constraint(s) cannot be met or the Topology sub-TLV is ill-formed, then no tree is installed but a management report is generated.</t>
<t>The bridges MAY support the following IS-IS features for the computation of explicit trees. The Extended IS Reachability TLV (type 22) specified in <xref target="RFC5305"/> provides the following link attribute IS-IS sub-TLVs: </t>
<t><list style="symbols">
<t>Administrative Group (color, resource class) (sub-TLV type 3),</t>
<t>Maximum Link Bandwidth (sub-TLV type 9),</t>
<t>Maximum Reservable Link bandwidth (sub-TLV type 10),</t>
<t>Unreserved Bandwidth (sub-TLV type 11),</t>
<t>Traffic Engineering Default Metric (sub-TLV type 18).</t>
</list></t>
<t>When the Unreserved Bandwidth sub-TLV is used in a Layer 2 bridge network, the priority value encoded in the sub-TLV provides the PCP, i.e. identifies a traffic class (not a setup priority level).</t>
<t>Further attributes are provided by the IS-IS TE Metric Extension link attribute sub-TLVs specified in <xref target="I-D.ietf-isis-te-metric-extensions"/>:</t>
<t><list style="symbols">
<t>Unidirectional Link Delay (sub-TLV type 33),</t>
<t>Min/Max Unidirectional Link Delay (sub-TLV type 34),</t>
<t>Unidirectional Delay Variation (sub-TLV type 35),</t>
<t>Unidirectional Link Loss (sub-TLV type 36),</t>
<t>Unidirectional Residual Bandwidth (sub-TLV type 37),</t>
<t>Unidirectional Available Bandwidth (sub-TLV type 38),</t>
<t>Unidirectional Utilized Bandwidth (sub-TLV type 39).</t>
</list></t>
<t>The Shared Risk Link Group (SRLG) information provided by the SRLG TLV (type 138) <xref target="RFC5307"/> MAY be also used. In order to indicate that the interface is unnumbered in this case, the corresponding flag takes value 0. The Link Local Identifier is an Extended Local Circuit Identifier and the Link Remote Identifier is a Neighbor Extended Local Circuit ID.</t>
</section>
<section anchor="sec_ect" title="Explicit ECT Algorithms">
<t>The exact IS-IS control mode of operation MUST be selected for a VLAN by associating its Base VID with the appropriate ECT Algorithm in the SPB Base VLAN-Identifiers sub-TLV <xref target="RFC6329"/>, in addition to allocating the Base VID to IS-IS control. There are five distinct ECT Algorithms for the five explicit path control modes. The operation details of the explicit ECT Algorithms and their configuration is specified by IEEE 802.1Qca, a high level overview is given here. An ECT Algorithm value consists of the IEEE 802.1 OUI (Organizationally Unique Identifier) value 00-80-C2 concatenated with an index <xref target="RFC6329"/>.</t>
<t>The Strict Tree (ST) ECT Algorithm MUST be used for a strict explicit tree. A strict ET is static as no other entity can update it but the owner PCE. In case of a topology change, it is the task of the owner PCE to detect the topology change, e.g. based on the changes in the LSDB, and to update the strict trees if needed. That is, the owner PCE computes the new tree, assembles its descriptor (<xref target="sec_topology"/>), and then instructs IS-IS PCR to install it. The value for the ST ECT algorithm is 00-80-C2-17.</t>
<t>The Loose Tree (LT) ECT Algorithm MAY be also supported. It is used for a single loose explicit tree. The path for loose hops is determined by the BLCE of the bridges; therefore, the Topology sub-TLV (<xref target="sec_topology"/>) specifying the tree MUST indicate which hop is the root of the tree. The loose hops are maintained by IS-IS, i.e. restored upon a topology change if a loop-free path is available. If the tree computed by the BLCE visits the same bridge twice (implying that a loop or hairpin has been created), then that loop or hairpin MUST be pruned from the tree even if it contains a hop specified by the Topology sub-TLV. It is a constraint if a bridge is not to be included, which can be specified by the Exclude flag of a Hop sub-TLV (<xref target="sec_hop"/>) conveyed by the Topology sub-TLV specifying the tree. The range of values for the LT ECT Algorithms is 00-80-C2-21...00-80-C2-30.</t>
<t>The Loose Tree Set (LTS) ECT Algorithm MAY be also supported. It is used if connectivity among the Edge Bridges specified by the Topology sub-TLV (<xref target="sec_topology"/>) is to be provided by a set of loose trees such that one tree is rooted at each Edge Bridge. The BLCE of the bridges compute the loose trees, which are maintained by IS-IS, i.e. restored upon a topology change. One constraint can be to avoid some bridges in these trees, which can be specified by the Exclude flag (item c.6. in <xref target="sec_hop"/>). Further constraints can be specified by the Topology sub-TLV. The range of values for the LT ECT Algorithms is 00-80-C2-31...00-80-C2-40.</t>
<t>The LT and LTS ECT Algorithms use the shortest paths after pruning the topology according to the constraint(s) if any. The shortest path tie-breaking specified by Section 12 of <xref target="RFC6329"/> is applied (see also subclauses 28.5 - 28.8 of <xref target="IEEE8021aq"/>), that's why range of values are associated with the LT and LTS ECT Algorithms. In case of the LT ECT Algorithm, the indexes are 0x21...0x30, and ECT-MASK{index-0x20} is applied to retrieve the ECT-MASK of Section 12 of <xref target="RFC6329"/>. In case of the LTS ECT Algorithm, the indexes are 0x31...0x40, and ECT-MASK{index-0x30} is applied to retrieve the ECT-MASK for shortest path tie-breaking.</t>
<t>The MRT ECT Algorithm MAY be also supported. It is used for the establishment and maintenance of MRTs in a distributed fashion. The MRT Lowpoint Algorithm specified by <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/> MUST be used for the computation of MRTs. The MRT Lowpoint Algorithm first computes the GADAG then produces two MRTs for each MRT Root: MRT-Blue and MRT-Red. If the level of redundancy provided by each bridge being an MRT Root is not required, then the MRT Roots can be specified by a Topology sub-TLV (<xref target="sec_topology"/>). Both the GADAG and the MRT computation steps are performed distributed, i.e. by each bridge. The value for the MRT ECT algorithm is 00-80-C2-18.</t>
<t>The MRT GADAG (MRTG) ECT Algorithm MAY be also supported. It splits the computation into two. As the GADAG is identical for each MRT within a domain, it is computed by a single entity, which is the GADAG Computer. The GADAG is then described in a Topology sub-TLV (<xref target="sec_topology"/>), which is flooded in the domain. The bridges then compute the MRTs for the MRT Roots based on the GADAG received. <xref target="sec_mrt"/> provides more details on the description of the GADAG. The value for the MRTG ECT algorithm is 00-80-C2-19.</t>
<t>MRTs are loose trees as bridges are involved in their computation and restoration. Thus both the MRT and the MRTG ECT Algorithms provide a set of loose trees: two MRTs for each MRT Root.</t>
<t>The SPB Link Metric sub-TLV <xref target="RFC6329"/> specifies the metric of each link for IS-IS PCR if the LT, the LTS, the MRT, or the MRTG ECT Algorithm is used. If the SPB Link Metric values advertised by different ends of an adjacency are different, then the maximum value MUST be used.</t>
</section>
<section anchor="sec_tlvs" title="IS-IS PCR sub-TLVs">
<t>The following sub-TLVs are specified for IS-IS PCR. The Topology sub-TLV MUST be carried in an MT-Capability TLV, the rest of the sub-TLVs are conveyed by Topology sub-TLV.</t>
<section anchor="sec_topology" title="Topology sub-TLV">
<t>An explicit tree MUST be described by the variable length Topology sub-TLV. A Generalized Almost Directed Acyclic Graph (GADAG) MAY be described by a Topology sub-TLV as explained in <xref target="sec_mrt"/> in detail. The Topology sub-TLV MUST be carried in an MT-Capability TLV (type 144) <xref target="RFC6329"/> in a Link State PDU. A Topology sub-TLV specifying an explicit tree conveys one or more Base VIDs, two or more Hop sub-TLVs (<xref target="sec_hop"/>). A Topology sub-TLV describing a loose tree MAY also convey further sub-TLVs to specify constraints. <xref target="fig_topology"/> shows the format of the Topology sub-TLV.</t>
<figure anchor="fig_topology" align="center"
title="Topology sub-TLV">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| Num Base VIDs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Base VID 1 (12 bits) | (2 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Base VID n (12 bits) | (2 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV 1 (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLV m (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The parameters of explicit trees are encoded by the Topology sub-TLV as follows:</t>
<t><list style="letters">
<t>Type (8 bits): The type of the sub-TLV, its value is 21.</t>
<t>Length (8 bits): The total number of bytes contained in the Value field.</t>
<t>Number of Base VIDs (8 bits): The number of Base VIDs carried in the Topology sub-TLV. Its minimum value is 1 if the Topology sub-TLV specifies one or more explicit trees. Its value can be 0 if the Topology sub-TLV specifies a GADAG.</t>
<t>Reserved (Res) (4 bits): The reserved bits MUST be set to 0 on sending and the value MUST be ignored on reception.</t>
<t>Base VID (12 bits): The Base VID parameter provides the Base VID of the VLAN that is associated with the explicit tree. Multiple Base VIDs can be associated with the same explicit tree. In addition to the Base VID, some of the explicit ECT Algorithms (<xref target="sec_ect"/>) require further VIDs which are associated with the VLAN via the SPB Instance sub-TLV <xref target="RFC6329"/>. A Topology sub-TLV specifying a GADAG can have zero Base VID parameters. In this case, the given GADAG MUST be applied for each VLAN associated with the MRTG ECT Algorithm (<xref target="sec_ect"/>).</t>
<t>sub TLVs: The rest conveys further sub-TLVs that specify the hops of the topology and can also specify constraints as described in the following.</t>
</list></t>
<t>A topology is specified by a list of Hop sub-TLVs (<xref target="sec_hop"/>), and a hop is specified by an IS-IS System ID. An ill-formed Topology sub-TLV, e.g. specifying an invalid or inconsistent tree is ignored, no tree is installed but a management report is generated.</t>
<t>The Topology sub-TLV specifies a strict tree by decomposing the tree to branches. Each branch is a point-to-point path specified by an ordered list of hops where the end of each branch is a leaf. Each element of a branch is the direct link between adjacent neighbor bridges whose Hop sub-TLV is next to each other in the Topology sub-TLV. The first hop of the Topology sub-TLV is the root, hence, the first branch originates from the root. The rest of the branches fork from another branch. The first hop of a branch is a bridge that is already part of a former branch and the last hop is a leaf bridge. Therefore, the hop after a leaf hop is the beginning of a new branch, if any. A hop of a branch is created if and only if the bridge specified for that hop is directly connected to the preceding bridge of the same branch. The first branch MUST begin with the root and after that the order of the branches does not matter within the Topology sub-TLV. <xref target="fig_tree"/> shows an example strict tree and its description.</t>
<figure anchor="fig_tree" align="center"
title="A strict tree and its description; root = Node A">
<artwork align="center"><![CDATA[
+-----------+
| A |
+-----------+
| I |
+-----------+
| H |
[B]---[A]---[I] +-----------+
| | | G |
| | +-----------+
| | | E |
[C]---[F] [H] +-----------+
| | | A |
| | +-----------+
| | | B |
[D] [E]---[G] +-----------+
| C |
+-----------+
| D |
+-----------+
| C |
+-----------+
| F |
+-----------+
]]></artwork>
</figure>
<t>The Topology sub-TLV of a loose tree does not provide any path or path segment, but the hops which are to participate. The root MUST be the first hop. The leaves of a single loose tree MUST be also specified. Hop sub-TLVs can be included in a Topology sub-TLV to specify bridges that have to be avoided. If the Topology sub-TLV only specifies a single leaf, then one or more transit hops can be specified by the Topology sub-TLV to direct the path along a sequence of bridges, specified by the order of hops. If bridges whose respective Hop sub-TLVs are adjacent to each other in the Topology sub-TLV but are not topology neighbors, then it is a loose hop. If a Topology sub-TLV conveys one or more loose hops, then that sub-TLV defines a loose explicit tree and each hop is considered as a loose hop. The path of a loose hop MUST be pruned from the tree if the path would create a loop or hairpin.</t>
<t>If the Base VIDs of the Topology sub-TLV are associated with the LTS ECT Algorithm or the MRT ECT Algorithm, then the Hop sub-TLVs conveyed by the Topology sub-TLV belong to Edge Bridges or bridges to be excluded. The BLCEs compute the loose trees, e.g. MRTs, such that they span the Edge Bridges and are rooted at an Edge Bridge.</t>
<t>The Topology sub-TLV specifies a GADAG if the Base VIDs conveyed by the Topology sub-TLV are associated with the MRTG ECT Algorithm. <xref target="sec_mrt"/> provides the details on the description of a GADAG by a Topology sub-TLV.</t>
<t>Each Edge Bridge of an explicit tree MUST be always specified in the Topology sub-TLV by the inclusion of the Hop sub-TLVs corresponding to the Edge Bridges. The Edge Bridges of a tree are identified by setting the Edge Bridge flag (item c.3. in <xref target="sec_hop"/>) in the appropriate Hop sub-TLVs.</t>
<t>If the explicit tree is loose, then the Topology sub-TLV MAY convey further sub-TLVs to specify constraints, e.g. an Administrative Group sub-TLV <xref target="RFC5305"/> or a Bandwidth Constraint (<xref target="sec_constraint"/>). If it is not possible to meet the constraint(s) specified by the Topology sub-TLV, then no tree is installed but a management report is generated.</t>
<t>IS-IS PCR MAY be used for recording bandwidth assignment. In that case, the Topology sub-TLV conveys Bandwidth Assignment sub-TLV (<xref target="sec_assignment"/>) and it MAY also convey Timestamp sub-TLV (<xref target="sec_timestamp"/>).
If assignment of the bandwidth indicated by the Bandwidth Assignment sub-TLV of the Topology sub-TLV would result in overbooking any link of the explicit tree, then bandwidth assignment MUST NOT be performed and a management report is generated. If the Topology sub-TLV specifies a new valid explicit tree, then the tree is installed without bandwidth assignment.</t>
</section>
<section anchor="sec_hop" title="Hop sub-TLV">
<t>The Hop sub-TLV MUST be used to specify a hop of a topology. Each Hop sub-TLV conveys an IS-IS System ID, which specifies a hop. A Hop sub-TLV is conveyed by a Topology sub-TLV (<xref target="sec_topology"/>). A strict explicit tree is decomposed to branches where each branch is a point-to-point path specified by an ordered list of Hop sub-TLVs as specified in <xref target="sec_topology"/>. A hop of a branch is created if and only if the bridge specified for that hop is directly connected to the preceding bridge in the path. That is, a point-to-point LAN is identified by the two bridges it interconnects; and the LAN is part of the strict tree if and only if the Hop sub-TLVs of the two bridges are next to each other in the Topology sub-TLV. A Hop sub-TLV can convey a Circuit ID in order to distinguish multiple links between adjacent neighbor bridges. A Hop sub-TLV also specifies the role of a bridge, e.g. if it is the root or an Edge Bridge. The Topology sub-TLV of a loose tree only comprises the Hop sub-TLV of the bridges that have special role in the tree. The Hop sub-TLV MAY also specify a delay budget for a loose hop.</t>
<t>By default, the Edge Bridges both transmit and receive with respect to each VID associated with an explicit tree, except for an LTS (<xref target="sec_ect"/>) associated with a learning VLAN, which uses a unidirectional VID per bridge. The Hop sub-TLV allows different configuration by means of the Transmit (T) and Receive (R) flags conveyed in the sub-TLV. The VID and its T/R flags are only present in the Hop sub-TLV if the behavior of the Edge Bridges differs from the default.</t>
<t><xref target="fig_hop"/> shows the format of the variable length Hop sub-TLV, which MUST be conveyed by a Topology sub-TLV (<xref target="sec_topology"/>).</t>
<figure anchor="fig_hop" align="center"
title="Hop sub-TLV">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
|C|V|B|R|L|E|Res| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Local Circuit ID (4 bytes if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of VIDs | (1 byte if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R|Res| VID 1 (12 bits) | (2 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.................
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R|Res| VID n (12 bits) | (2 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Constraint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay Constraint | (6 bytes if present)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The parameters of a hop are encoded as follows:</t>
<t><list style="letters">
<t>Type (8 bits): The type of the sub-TLV, its value is 22.</t>
<t>Length (8 bits): The total number of bytes contained in the Value field.</t>
<t>Hop Flags (8 bits): The Hop sub-TLV conveys six one-bit flags. The Circuit and the VID flags influence the length of the Hop sub-TLV. Two bits are reserved for future use, transmitted as 0 and ignored on receipt.
<list style="numbers">
<t>Circuit (C) flag (1 bit): The Circuit flag is a one-bit flag to indicate whether or not the Extended Local Circuit ID parameter is present. If the flag is set, then an Extended Local Circuit ID is also included in the Hop sub-TLV.</t>
<t>VID (V) flag (1 bit): The VID flag is a one-bit flag to indicate whether or not one or more VIDs are conveyed by the Hop sub-TLV. If the flag is set, then the Number of VIDs parameter is present and indicates how many VIDs are conveyed by the Hop sub-TLV. If the VID flag is reset, then neither the Number of VIDs parameter nor VIDs are present in the Hop sub-TLV.</t>
<t>Edge Bridge (B) flag (1 bit): The Edge Bridge flag is a one-bit flag to indicate whether or not the given System is an Edge Bridge, i.e. transmitter and/or receiver. If the System is an Edge Bridge, then the Edge Bridge flag MUST be set. The Edge Bridge flag indicates that FDB entries have to be installed for the given hop as specified by the SPBV MAC address sub-TLV or SPBM Service Identifier and Unicast Address sub-TLV of the hop.</t>
<t>Root (R) flag (1 bit): The Root flag is a one-bit flag to indicate whether or not the given System is a root of the explicit tree specified by the Topology sub-TLV. If the System is a root of a tree, then the Root flag MUST be set.
If the Topology sub-TLV specifies a single tree, i.e. the Base VIDs conveyed by the Topology sub-TLV are associated with either the ST ECT Algorithm or the LT ECT Algorithm (<xref target="sec_ect"/>), then the Root flag is only set for one of the Systems conveyed by the Topology sub-TLV. Furthermore, the first Hop sub-TLV of the Topology sub-TLV conveys the System that is the root of the tree.
If the Topology sub-TLV specifies a Loose Tree Set, i.e. the Base VIDs conveyed by the Topology sub-TLV are associated with the LTS ECT Algorithm (<xref target="sec_ect"/>), then the Root flag is set for each Edge Bridge as each of them roots a tree.
If the Topology sub-TLV is used for MRT operations, i.e. the Base VIDs conveyed by the Topology sub-TLV are associated with either the MRT ECT Algorithm or the MRTG ECT Algorithm (<xref target="sec_ect"/>), then the Root flag is set for each MRT Root. If no MRT Root is specified by a Topology sub-TLV specifying a GADAG, then each SPT Root is an MRT Root as well.
If the Base VIDs conveyed by the Topology sub-TLV are associated with the MRTG ECT Algorithm (<xref target="sec_ect"/>), then the Topology sub-TLV specifies a GADAG and the very first Hop sub-TLV specifies the GADAG Root. There is no flag for indicating the GADAG Root.</t>
<t>Leaf (L) flag (1 bit): The Leaf flag is a one-bit flag to indicate whether or not the given System is a leaf of the explicit tree specified by the Topology sub-TLV. If the System is a leaf, then the Leaf flag MUST be set.
The Leaf flag is only used to mark a leaf of a tree if the Topology sub-TLV specifies a single tree.
The Leaf flag MUST be used to indicate the end of a topology block if the Topology sub-TLV specifies a GADAG, see <xref target="sec_mrt"/>.</t>
<t>Exclude (E) flag (1 bit): The Exclude flag is a one-bit flag to indicate if the given System MUST be excluded from the topology. The Exclude flag and the Root flag cannot be set for a given hop at the same time.</t>
<t>Reserved (Res) (2 bits): The reserved bits MUST be set to 0 on sending and the value MUST be ignored on reception.</t>
</list></t>
<t>System ID (48 bits): The 6-byte IS-IS System Identifier of the bridge that the Hop sub-TLV refers to.</t>
<t>Extended Local Circuit ID (32 bits): The Extended Local Circuit ID <xref target="RFC5303"/> parameter is not necessarily present in the Hop sub-TLV. Its presence is indicated by the Circuit flag.
Parallel links corresponding to different IS-IS adjacencies between a pair of neighbor bridges can be distinguished by means of the Extended Local Circuit ID. The Extended Local Circuit ID is conveyed by the Hop sub-TLV specifying the bridge nearer to the root of the tree, and identifies a circuit that attaches the given bridge to its neighbor cited by the next Hop sub-TLV of the Topology sub-TLV. The Extended Local Circuit ID can only be used in strict trees.</t>
<t>Number of VIDs (8 bits): The Number of VIDs parameter is not present if the Hop sub-TLV does not convey VIDs, which is indicated by the VID flag.</t>
<t>VID and its T/R flags (14 bits): The VID and its T/R flags are only present in the Hop sub-TLV if the given bridge is an Edge Bridge and it behaves differently from the default with respect to that particular VID.
<list style="numbers">
<t>T flag (1 bit): This is the Transmit allowed flag for the VID following the flag.</t>
<t>R flag (1 bit): This is the Receive allowed flag for the VID following the flag.</t>
<t>Reserved (Res) (2 bits): The reserved bits MUST be set to 0 on sending and the value MUST be ignored on reception.</t>
<t>VID (12 bits): A VID.</t>
</list></t>
<t>Delay Constraint (48 bits): A Hop sub-TLV MAY specify a delay constraint. The Length of the Hop sub-TLV indicates whether or not a delay constraint is present because the Length of a Hop sub-TLV conveying a delay constraint is six bytes greater than it would be without the delay constraint. The last six bytes then specify a delay constraint if they convey a Unidirectional Link Delay sub-TLV <xref target="I-D.ietf-isis-te-metric-extensions"/>. The delay constraint MAY be used in a Topology sub-TLV that specifies a single loose tree, i.e. the Base VIDs are associated with the LT ECT Algorithm (<xref target="sec_ect"/>). If delay constraint is applied, then the loose hop MUST fit in the delay budget specified by the Delay parameter of the Unidirectional Link Delay sub-TLV conveyed by the Hop sub-TLV. If the Topology sub-TLV specifies a single leaf, then the path between the preceding Hop sub-TLV and the current Hop sub-TLV MUST meet the delay budget. If the Topology sub-TLV specifies multiple leaves, then the path between the root and the current Hop sub-TLV MUST to meet the delay budget. If the tree is used as a reverse congruent tree, then the delay constraint applies in both directions. If the tree is used as a directed tree, then the delay constraint applies in the direction of the tree. If it is not possible to meet the delay constraint specified by the Topology sub-TLV, then no tree is installed but a management report is generated.</t>
</list></t>
</section>
<section anchor="sec_constraint" title="Bandwidth Constraint sub-TLV">
<t>The Bandwidth Constraint sub-TLV MAY be included in a Topology sub-TLV (<xref target="sec_topology"/>) in order to specify how much available bandwidth is to be provided by the constrained tree. Each loose hop MUST meet the bandwidth constraint. The bandwidth value of the constraint is a total value or it only refers to a single PCP as specified by the sub-TLV. <xref target="fig_constraint"/> shows the format of the Bandwidth Constraint sub-TLV.</t>
<figure anchor="fig_constraint" align="center"
title="Bandwidth Constraint sub-TLV">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| PCP |D|P| Res | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Bandwidth (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The parameters of the bandwidth constraint are encoded as follows:</t>
<t><list style="letters">
<t>Type (8 bits): The type of the sub-TLV, its value is 23.</t>
<t>Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 5 bytes.</t>
<t>PCP (4 bits): The Priority Code Point (PCP) parameter identifies the traffic class the Available Bandwidth parameter refers to, if any.</t>
<t>DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) parameter.
If the DEI parameter is clear, then the bandwidth constraint refers to committed information rate.
If the DEI parameter is set, then the bandwidth constraint refers to peak information rate.</t>
<t>PCP (P) flag (1 bit): If this flag is set, then the PCP parameter is taken into account.</t>
<t>Reserved (Res) (3 bits): The reserved bits MUST be set to 0 on sending and the value MUST be ignored on reception.</t>
<t>Available Bandwidth (32 bits): The Available Bandwidth is specific to the traffic class identified by the PCP parameter if the PCP flag is set, otherwise, it is total bandwidth. In-line with the bandwidth parameters specified in <xref target="RFC5305"/>, the Available Bandwidth is encoded as a 32-bit IEEE floating point number <xref target="IEEE754"/>, and the units are bytes (not bits!) per second. When the Unreserved Bandwidth sub-TLV (sub-TLV type 11 specified by <xref target="RFC5305"/>) is used in a Layer 2 bridge network, the priority value encoded in the Unreserved Bandwidth sub-TLV provides the PCP, i.e. identifies a traffic class (not a setup priority level). Thus, the Available Bandwidth of a traffic class is easily comparable with the Unreserved Bandwidth stored in the TED for the given traffic class.
The bandwidth constraint applies for both directions in case of symmetric explicit trees. Nevertheless, a VID associated with an explicit tree can be made unidirectional by means of the T/R flags belonging to the VID in the Hop sub-TLV (item g. in <xref target="sec_hop"/>) of the Edge Bridges. If all the VIDs of the Topology sub-TLV (<xref target="sec_topology"/>) are unidirectional and all belong to the traffic class identified by the PCP parameter of the Bandwidth Constraint sub-TLV, then it is enough to meet the bandwidth constraint in the direction applied for those VIDs.</t>
</list></t>
</section>
<section anchor="sec_assignment" title="Bandwidth Assignment sub-TLV">
<t>IS-IS PCR MAY be used for recording bandwidth assignment for explicitly placed data traffic in a domain if MSRP is not used within the domain. If MSRP is used in a domain, then only MSRP performs reservations and IS-IS does not. Both MSRP and IS-IS MUST NOT be used to make bandwidth assignments in the same domain.</t>
<t>The Bandwidth Assignment sub-TLV can be used to define the amount of bandwidth whose assignment is to be recorded by IS-IS PCR at each hop of the explicit tree described by the corresponding Topology sub-TLV (<xref target="sec_topology"/>). The Bandwidth Assignment sub-TLV is used by IS-IS PCR for the recording of bandwidth assignment for a traffic class identified by the PCP parameter of a VLAN tag. If precedence order has to be determined among bandwidth assignments in a domain with multiple PCEs, then IS-IS PCR does it as described below. If the bandwidth assignment specified by the Topology sub-TLV is not possible, e.g. due to overbooking, then bandwidth recording MUST NOT be performed and a management report is generated. If the Topology sub-TLV specifies a new valid explicit tree, then the tree is installed without bandwidth assignment. The Bandwidth Assignment sub-TLV is conveyed by a Topology sub-TLV (<xref target="sec_topology"/>). <xref target="fig_assignment"/> shows the format of the Bandwidth Assignment sub-TLV.</t>
<figure anchor="fig_assignment" align="center"
title="Bandwidth Assignment sub-TLV">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+
| PCP |D| Imp |R| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The parameters of the bandwidth assignment are encoded as follows:</t>
<t><list style="letters">
<t>Type (8 bits): The type of the sub-TLV, its value is 24.</t>
<t>Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 5 bytes.</t>
<t>PCP (3 bits): The PCP parameter identifies the traffic class the bandwidth to be assigned for.</t>
<t>DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) parameter.
If the DEI parameter is clear, then the bandwidth assignment is performed for providing committed information rate.
If the DEI parameter is set, then the bandwidth assignment is performed for providing peak information rate.</t>
<t>Importance (Imp) (3 bits): This is the Importance parameter for determining precedence order among bandwidth assignments within a PCP as described below. Lower numerical value indicates more important bandwidth assignment within a PCP. The default value of the Importance parameter is 7.</t>
<t>Reserved (R) (1 bit): The reserved bit MUST be set to 0 on sending and the value MUST be ignored on reception.</t>
<t>Bandwidth (32 bits): This is the amount of bandwidth to be assigned for the traffic class identified by the PCP parameter. In-line with the bandwidth values specified in <xref target="RFC5305"/>, the Bandwidth parameter is encoded as a 32-bit IEEE floating point number <xref target="IEEE754"/>, and the units are bytes (not bits!) per second.
The bandwidth assignment applies for both directions in case of symmetric explicit trees.</t>
</list></t>
<t>The PCEs are collectively responsible for making a consistent set of bandwidth assignments when IS-IS PCR is used for recording bandwidth allocations. If despite of that, precedence ordering is required among bandwidth assignments, then ordering based on the following parameters MUST be applied:
<list style="numbers">
<t>PCP parameter of Bandwidth Assignment sub-TLV,</t>
<t>Importance parameter of Bandwidth Assignment sub-TLV,</t>
<t>Timestamp sub-TLV (if present in the Topology sub-TLV).</t>
</list>
A bandwidth assignment takes precedence if it has higher PCP, or higher Importance within a PCP, or earlier timestamp in case of equal Importance within a PCP. A bandwidth assignment associated with a timestamp takes precedence over a bandwidth assignment without timestamp when PCP and Importance of different bandwidth assignments are both equal.
If resolution is not possible based on the above parameters or they are not available, e.g. each bandwidth assignment lacks timestamp or the precedence order has to be determined for the use of a VID, then the item is granted to the PCE whose LSP has the numerically least LSP ID.</t>
</section>
<section anchor="sec_timestamp" title="Timestamp sub-TLV">
<t> The Timestamp sub-TLV MAY be included in a Topology sub-TLV (<xref target="sec_topology"/>) in order to provide precedence order among equally important bandwidth assignments within a PCP as described in <xref target="sec_assignment"/>. <xref target="fig_timestamp"/> shows the format of the Timestamp sub-TLV.</t>
<figure anchor="fig_timestamp" align="center"
title="Timestamp sub-TLV">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Type | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The timestamp represents a positive time with respect to the Precision Time Protocol (PTP) epoch and it is encoded as follows:</t>
<t><list style="letters">
<t>Type (8 bits): The type of the sub-TLV, its value is 25.</t>
<t>Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 4 bytes.</t>
<t>Time (32 bits): This is the time in units of seconds with respect to the PTP epoch.</t>
</list></t>
<t>The Timestamp sub-TLV carries the seconds portion of PTP as specified by <xref target="IEEE1588"/>. The epoch is 1970-01-01 00:00:00 TAI (i.e., the PTP time does not include leap seconds).</t>
</section>
</section>
<section anchor="sec_mrt" title="MRT-FRR Application">
<t>The application of MRT by <xref target="IEEE8021Qca"/> is discussed in detail in <xref target="I-D.bowers-rtgwg-mrt-applicability-to-8021qca"/>. This section describes some special considerations for the use of the MRT Lowpoint Algorithm <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>, which are applicable both to the MRT ECT Algorithm and the MRTG ECT Algorithm. This section also explains details related to the MRTG ECT Algorithm and the application of the Topology sub-TLV in particular.</t>
<t>IS-IS PCR does not use the MRT Profile specified in <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. IS-IS PCR only relies on the algorithm specification in <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>. Both the MRT ECT Algorithm and the MRTG ECT Algorithm use the MRT Lowpoint Algorithm specified in <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>.</t>
<t>The SPB Link Metric sub-TLV <xref target="RFC6329"/> specifies the metric of each link for IS-IS PCR including the MRT Algorithms. If the SPB Link Metric values advertised by different ends of an adjacency are different, then the maximum value MUST be used. If equal cost (sub)paths are found during the MRT computation, then the default tie-breaking specified by Section 11 of <xref target="RFC6329"/> MUST be used, which is based on the lower Bridge ID. (The BridgeID is an 8-byte quantity whose upper 2 bytes are the node's BridgePriority and lower 6 bytes are the node's SYSID.) Note also that if MRTs are used for source specific multicast (see <xref target="IEEE8021Qca"/> for details), then the bridges have to compute the MRTs of the other bridges in addition to their own one in order to be able to install the appropriated FDB entries. (This is similar to the need for all pairs shortest path computation instead of Dijkstra for source specific shortest path multicast trees.)</t>
<t>The GADAG is identical for all the MRTs within a network domain, as a consequence of the use of the MRT Lowpoint Algorithm <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>. Therefore, it is beneficial to compute the GADAG by a single entity, which is referred to as the GADAG Computer and is either a PCE or the GADAG Root. If the MRTG ECT Algorithm is applied, then the GADAG MUST be only computed by the GADAG Computer, which then MUST flood the descriptor Topology sub-TLV of the GADAG. The bridges then compute the MRTs based on the received GADAG.</t>
<t>The GADAG computation requires the selection of the GADAG Root. The bridge with the best Bridge Identifier MUST be selected as the GADAG Root, where the numerically lower value indicates the better identifier. The Bridge Priority component of the Bridge Identifier allows the configuration of the GADAG Root by management action. The Bridge Priority is conveyed by the SPB Instance sub-TLV <xref target="RFC6329"/>.</t>
<t>The GADAG Computer MUST perform the GADAG computation as specified by the MRT Lowpoint Algorithm <xref target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>. The GADAG Computer then MUST encode the GADAG in a Topology sub-TLV (<xref target="sec_topology"/>), which is then flooded throughout the domain. A GADAG is encoded in a Topology sub-TLV by means of directed ear decomposition as follows. A directed ear is a directed point-to-point path whose end points can coincide but no other element of the path is repeated in the ear. Each ear is specified by an ordered list of hops such that the order of hops is according to the direction of the arcs in the GADAG. There are no leaves in a GADAG, hence, the Leaf flag (item c.5. in <xref target="sec_hop"/>) is used to mark the end of a topology block. (A GADAG with multiple blocks is illustrated in <xref target="fig_gadag_cut"/>.) The sequence of ears in the Topology sub-TLV is such that the end points of an ear belong to preceding ears. The GADAG Root is not marked by any flag but the GADAG Root is the first hop in the Topology sub-TLV, correspondingly the first ear starts and ends with the GADAG Root. MRT Roots MUST be marked by the Root flag (item c.4. in <xref target="sec_hop"/>) and all other Edge Bridges are leaves of the given MRTs. If no MRT Root is specified, then each SPT Root is also an MRT Root.</t>
<t><xref target="fig_gadag"/> shows an example GADAG. The figure also illustrates the description of the GADAG, it shows the System ID parameter of the Hop sub-TLV (<xref target="sec_hop"/>) and the order of hops in the Topology sub-TLV (<xref target="sec_topology"/>).</t>
<figure anchor="fig_gadag" align="center"
title="A GADAG and its description; GADAG Root = Node A">
<artwork align="center"><![CDATA[
Leaf
Hop flag
+-----------+---+
| A | |
+-----------+---+
| B | |
+-----------+---+
| C | |
+-----------+---+
| F | |
[B]<---[A]<---[I] +-----------+---+
| ^ ^ | A | |
| | | +-----------+---+
V | | | C | |
[C]--->[F]--->[H] +-----------+---+
| ^ | D | |
| | +-----------+---+
V | | E | |
[D]--->[E]--->[G] +-----------+---+
| G | |
+-----------+---+
| H | |
+-----------+---+
| I | |
+-----------+---+
| A | |
+-----------+---+
| F | |
+-----------+---+
| H | X |
+-----------+---+
]]></artwork>
</figure>
<t>A topology can comprise multiple blocks, like the one illustrated in <xref target="fig_gadag_cut"/>(a). This example topology comprises four blocks as each cut-link is a block. A-B-C-D-E-F is a block, D-G is another block, G-H, and H-J-K are further blocks. A GADAG for this topology is shown in <xref target="fig_gadag_cut"/>(b). Note that two arcs with opposite direction represent a cut-link in a GADAG, see e.g. the cut-link between D and G. The encoding starts with the block (ADAG) involving the GADAG Root as illustrated in <xref target="fig_gadag_cut"/>. The first hop in the Topology sub-TLV is the GADAG Root (node A in this example.) The ADAG of the first block is then described using the ear decomposition, as described above. In this example, the first block has been completely traversed at the second occurrence of node A in the GADAG descriptor. The end of a block is indicated by setting the Leaf flag for the last hop of the block, e.g. for the second occurrence of node A in the example GADAG descriptor. The next node that appears in the GADAG descriptor (D in this case) is the localroot for the nodes in the next block. Continuing this process, the Leaf flag is set for the third occurrence of D, the third occurrence of G, and the third occurrence of H, each indicating the end of a block.
The first hop of the first block is the GADAG Root, the fist hop in the rest of the blocks is the localroot. The position of the set Leaf flags helps to determine the localroot, which is the next hop. In the example GADAG descriptor, one can determine that A is the localroot for B,C,D,E,F (and A is the GADAG Root). D is the localroot for G. G is the localroot for H.
And H is the localroot for J and K. The GADAG Root is assigned a localroot of None.</t>
<t>Block IDs are reconstructed while parsing a Topology sub-TLV specifying a GADAG. The current Block ID starts at 0 and is assigned to the GADAG Root. A node appearing in the GADAG descriptor
without a previously-assigned Block ID value is assigned the current Block ID. And the current Block ID is incremented by 1 after processing the localroot of a block. Note that the localroot of a block will keep the Block ID of the first block in which it is assigned a Block ID. In the example in <xref target="fig_gadag_cut"/>, A has Block ID=0. B, C, D, E, and F have Block ID=1. G has Block ID=2. H has Block ID=3. J and K have Block ID=4.</t>
<figure anchor="fig_gadag_cut" align="center"
title="A GADAG with cut-links and its description; GADAG Root = Node A">
<artwork align="center"><![CDATA[
Leaf
Hop flag
[F]--[E] +--[K] +-----------+---+
| | | | | A | |
| | | | +-----------+---+
[A] [D]--[G]--[H] | | B | |
| | | | +-----------+---+
| | | | | C | |
[B]--[C] +--[J] +-----------+---+
| D | |
(a) topology +-----------+---+
| E | |
+-----------+---+
| F | |
+-----------+---+
| A | X |
+-----------+---+
+-+ +-+ +-+ | D | |
|F|<-|E| +--|K| +-----------+---+
+-+ +-+ | +-+ | G | |
| ^ | ^ +-----------+---+
| | V | | D | X |
V +-+ +-+ +-+ | +-----------+---+
+-+ | |->| |->| | | | G | |
|A| |D| |G| |H| | +-----------+---+
+-+ | |<-| |<-| | | | H | |
| +-+ +-+ +-+ | +-----------+---+
| ^ | | | G | X |
V | | | +-----------+---+
+-+ +-+ | +-+ | H | |
|B|->|C| +->|J| +-----------+---+
+-+ +-+ +-+ | J | |
+-----------+---+
(b) GADAG | K | |
+-----------+---+
| H | X |
+-----------+---+
(c) GADAG descriptor
]]></artwork>
</figure>
</section>
<section anchor="sec_sum" title="Summary">
<t>This document specifies IS-IS sub-TLVs for the control of explicit trees in Layer 2 networks. These sub-TLVs can be also used for the distribution of a centrally computed GADAG or MRTs if MFT-FRR is used.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document defines the following IS-IS sub-TLVs within the MT-Capability TLV (type 144). They are listed in the IS-IS TLV codepoint registry.</t>
<figure align="center">
<artwork align="center"><![CDATA[
Type Description Length
---- ---------------------------- --------
21 Topology sub-TLV variable
22 Hop sub-TLV variable
23 Bandwidth Constraint sub-TLV 5
24 Bandwidth Assignment sub-TLV 5
25 Timestamp sub-TLV 4
]]></artwork>
</figure>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document adds no additional security risks to IS-IS, nor does it provide any additional security for IS-IS when used in a configured environment or a single-operator domain such as a data center. IS-IS PCR is not for zero configuration environments.</t>
<t>Any mechanism that chooses forwarding paths, and allocates resources to those paths, is potentially vulnerable to attack. The security considerations section of <xref target="RFC4655"/> describes the risks associated with the use of PCE for this purpose and should be referred to. Use of any other means to determine paths should only be used after considering similar concerns.</t>
<t>Because the mechanism assumed for distributing tree information relies on IS-IS routing, IS-IS routing security considerations (Section 6, <xref target="RFC1195"/>) and mechanisms (e.g. <xref target="RFC5310"/>) used to authenticate peer advertisements apply.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Don Fedyk and Eric Gray for their comments and suggestions.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC6329;
&RFC5303;
&RFC5305;
&RFC5307;
&I-D.ietf-isis-te-metric-extensions;
&I-D.ietf-rtgwg-mrt-frr-algorithm;
<reference anchor="IEEE8021Qca" target="http://www.ieee802.org/1/pages/802.1ca.html">
<front>
<title>IEEE 802.1Qca Bridges and Bridged Networks - Amendment: Path Control and Reservation</title>
<author>
<organization>IEEE 802.1</organization>
</author>
<date year="2016" />
</front>
</reference>
</references>
<references title="Informative References">
&RFC1195;
&RFC4655;
&RFC5310;
&I-D.ietf-rtgwg-mrt-frr-architecture;
&I-D.bowers-rtgwg-mrt-applicability-to-8021qca;
<reference anchor="IEEE8021aq" target="http://standards.ieee.org/getieee802/download/802.1aq-2012.pdf">
<front>
<title>IEEE 802.1aq: IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks - Amendment 20: Shortest Path Bridging</title>
<author>
<organization>IEEE 802.1</organization>
</author>
<date year="2012" />
</front>
</reference>
<reference anchor="IEEE8021Q" target="http://standards.ieee.org/getieee802/download/802.1aq-2012.pdf">
<front>
<title>IEEE 802.1Q-2014: IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks</title>
<author>
<organization>IEEE 802.1</organization>
</author>
<date year="2014" />
</front>
</reference>
<reference anchor="IEEE1588" target="http://standards.ieee.org/findstds/standard/1588-2008.html">
<front>
<title>IEEE 1588: IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems</title>
<author>
<organization>IEEE 1588</organization>
</author>
<date year="2008" />
</front>
</reference>
<reference anchor="IEEE754" target="http://standards.ieee.org/findstds/standard/754-2008.html">
<front>
<title>IEEE 754: IEEE Standard for Floating-Point Arithmetic</title>
<author>
<organization>IEEE 754</organization>
</author>
<date year="2008" />
</front>
</reference>
</references>
<!-- Change Log
draft-farkas-isis-pcr-00 2014-10-17 Initial version - in sync with P802.1Qca D1.1
draft-farkas-isis-pcr-01 2014-12-04 Updates in order to be sync with P802.1Qca D1.2. sub-TLV figures are replaced to the format used by RFC 6329.
draft-farkas-isis-pcr-02 2015-03-09 Updates in order to be sync with P802.1Qca D1.4 and to resolve comments received.
draft-ietf-isis-pcr-00 Adopted by WG.
draft-ietf-isis-pcr-01 2015-07-06 IS-IS PCR sub-TLV code point values added, updates according to the changes in P802.1Qca D2.1
draft-ietf-isis-pcr-02 2015-09-17 updates according to WGLC comments
draft-ietf-isis-pcr-03 2015-11-30 outdated references updated, IEEE8021aq moved to informative
draft-ietf-isis-pcr-04 2015-12-17 updates to resolve AD review comments
draft-ietf-isis-pcr-05 2016-02-11 updates to resolve IESG Last Call comments
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 22:26:47 |