GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7813

Internet Engineering Task Force (IETF) J. Farkas, Ed. Request for Comments: 7813 Ericsson Category: Standards Track N. Bragg ISSN: 2070-1721 Ciena

                                                          P. Unbehagen
                                                                 Avaya
                                                            G. Parsons
                                                              Ericsson
                                                      P. Ashwood-Smith
                                                   Huawei Technologies
                                                             C. Bowers
                                                      Juniper Networks
                                                             June 2016
                 IS-IS Path Control and Reservation

Abstract

 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.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7813.

Farkas, et al. Standards Track [Page 1] RFC 7813 IS-IS PCR June 2016

Copyright Notice

 Copyright (c) 2016 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
 3.  Terminology and Definitions . . . . . . . . . . . . . . . . .   4
 4.  Explicit Trees  . . . . . . . . . . . . . . . . . . . . . . .   6
 5.  Explicit ECT Algorithms . . . . . . . . . . . . . . . . . . .   9
 6.  IS-IS PCR Sub-TLVs  . . . . . . . . . . . . . . . . . . . . .  11
   6.1.  Topology Sub-TLV  . . . . . . . . . . . . . . . . . . . .  11
   6.2.  Hop Sub-TLV . . . . . . . . . . . . . . . . . . . . . . .  15
   6.3.  Bandwidth Constraint Sub-TLV  . . . . . . . . . . . . . .  19
   6.4.  Bandwidth Assignment Sub-TLV  . . . . . . . . . . . . . .  21
   6.5.  Timestamp Sub-TLV . . . . . . . . . . . . . . . . . . . .  23
 7.  MRT-FRR Application . . . . . . . . . . . . . . . . . . . . .  24
 8.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
 9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
 10. Security Considerations . . . . . . . . . . . . . . . . . . .  29
 11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
   11.1.  Normative References . . . . . . . . . . . . . . . . . .  30
   11.2.  Informative References . . . . . . . . . . . . . . . . .  31
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  32
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

Farkas, et al. Standards Track [Page 2] RFC 7813 IS-IS PCR June 2016

1. Introduction

 IEEE 802.1Qca Path Control and Reservation (PCR) [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 [RFC6329] and
 [IEEE8021aq] (already rolled into [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.
 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
 Std 802.1Qca.  In addition to the sub-TLVs specified here, IS-IS PCR
 relies on the following IS-IS SPB sub-TLVs specified by [RFC6329]:
 o  SPB Link Metric sub-TLV
 o  SPB Base VLAN-Identifiers sub-TLV
 o  SPB Instance sub-TLV
 o  SPBV MAC address sub-TLV
 o  SPBM Service Identifier and Unicast Address sub-TLV
 These sub-TLVs are used to provide the link metric and the
 associations among bridges, Media Access Control (MAC) addresses,
 VLAN IDs (VIDs), and I-SIDs within an IS-IS domain.  The use of these
 SPB sub-TLVs for PCR is specified by IEEE Std 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; however, when
 it supports both, they are implemented by the same IS-IS entity on a
 per-instance basis.
 The sub-TLVs specified in this document can also be applied for Fast
 Reroute using Maximally Redundant Trees (MRT-FRR) [RFC7812] in a
 Layer 2 network.  Maximally Redundant Trees (MRTs) are computed as
 specified in [RFC7811].  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.
 PCR uses IS-IS, the SPB sub-TLVs listed above, and the new sub-TLVs
 defined in this document.  IS-IS PCR has no impact on IETF protocols.

Farkas, et al. Standards Track [Page 3] RFC 7813 IS-IS PCR June 2016

2. Conventions Used in This Document

 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 [RFC2119].

3. Terminology and Definitions

 This document uses the terminology defined in [RFC7812].  Only the
 abbreviations are resolved here for the MRT terms; please refer to
 [RFC7812] for the complete definition.
 ADAG:  Almost Directed Acyclic Graph [RFC7812]
 B-VID:  Backbone VID [IEEE8021Q]
 Base VID:  The VID used to identify a VLAN in management operations.
    [IEEE8021Q]
 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.  [IEEE8021Qca]
 Constrained tree:  A tree meeting a certain constraint, e.g.,
    providing minimally available bandwidth.  [IEEE8021Qca]
 CSPF:  Constrained Shortest Path First
 DAG:  Directed Acyclic Graph [RFC7812]
 DEI:  Drop Eligible Indicator [IEEE8021Q]
 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 [IEEE8021Q].  It can be also one of the
    explicit path-control algorithms specified by [IEEE8021Qca].  Each
    ECT Algorithm has a 32-bit unique ID.
 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.  [IEEE8021Qca]
 ETDB:  Explicit Tree Database - A database storing explicit trees.
    [IEEE8021Qca]

Farkas, et al. Standards Track [Page 4] RFC 7813 IS-IS PCR June 2016

 FDB:  Filtering Database [IEEE8021Q]
 GADAG:  Generalized ADAG [RFC7812]
 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.  [IEEE8021Qca]
 I-SID:  Backbone Service Instance Identifier - A 24-bit ID.
    [IEEE8021Q]
 LSDB:  Link State Database
 MRT:  Maximally Redundant Trees [RFC7812]
 MRT-Blue:  MRT-Blue is used to describe one of the two MRTs.
    [RFC7812]
 MRT-Red:  MRT-Red is used to describe one of the two MRTs.  [RFC7812]
 MRT Root:  The common root of the two MRTs: MRT-Blue and MRT-Red.
 MSRP:  Multiple Stream Registration Protocol, standardized as IEEE
    Std 802.1Qat, already rolled into [IEEE8021Q].
 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.  [IEEE8021Qca]
 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).  [RFC4655]
 PCP:  Priority Code Point, which identifies a traffic class.
    [IEEE8021Q]
 PTP:  Precision Time Protocol specified by [IEEE1588].
 SPB:  Shortest Path Bridging
 SPBM:  SPB MAC - The SPB mode where a MAC or its shorthand
    (SPSourceID: Shortest Path Source ID) is used to identify an SPT.
    [IEEE8021Q]

Farkas, et al. Standards Track [Page 5] RFC 7813 IS-IS PCR June 2016

 SPBV:  SPB VID - The SPB mode where a unique VID is assigned to each
    SPT Root bridge and is used to identify an SPT.  [IEEE8021Q]
 SPF:  Shortest Path First
 SPT:  Shortest Path Tree [IEEE8021Q]
 SRLG:  Shared Risk Link Group - A set of links that share a resource
    whose failure affects each link.  [RFC5307]
 TAI:  Temps Atomique International - International Atomic Time
    [IEEE1588]
 TED:  Traffic Engineering Database - A database storing the traffic
    engineering information propagated by IS-IS.  [RFC5305]
 VID:  VLAN ID [IEEE8021Q]
 VLAN:  Virtual Local Area Network [IEEE8021Q]

4. Explicit Trees

 Explicit trees may be determined in some fashion.  For example, an
 explicit tree may be determined by a Path Computation Element (PCE)
 [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 specify an explicit tree as described in
 Section 6.1.  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 only be 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.
 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

Farkas, et al. Standards Track [Page 6] RFC 7813 IS-IS PCR June 2016

 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.
 The operation details of the PCE are not specified by this document
 or by IEEE Std 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 Std
 802.1Qca.
 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.
 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 (Section 6.1) of the tree or by the
 corresponding ECT Algorithm (Section 5).
 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
 applies 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).
 An explicit tree is specified by a Topology sub-TLV (Section 6.1).
 The Topology sub-TLV associates one or more VIDs with an explicit
 tree.  The Topology sub-TLV includes two or more Hop sub-TLVs
 (Section 6.2), and a hop is specified by an IS-IS System ID.  A Hop

Farkas, et al. Standards Track [Page 7] RFC 7813 IS-IS PCR June 2016

 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).
 Explicit trees are propagated and set up by IS-IS PCR in a domain.
 The PCE or its PCA assembles the Topology sub-TLVs (Section 6.1), 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]
 two-tuples associated with an ET.
 Due to the LSP aging of IS-IS, the Topology sub-TLVs (Section 6.1)
 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.
 The owner PCE can withdraw an explicit tree by sending an updated LSP
 that does not include the Topology sub-TLV (Section 6.1).  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.  IS-IS PCR then removes (or updates) the
 explicit tree.
 There is no precedence order between explicit trees.  Precedence
 order among bandwidth assignments recorded by IS-IS PCR is specified
 in Section 6.4.
 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.
 The bridges MAY support the following IS-IS features for the
 computation of explicit trees.  The Extended IS Reachability TLV
 (type 22) specified in [RFC5305] provides the following link
 attribute IS-IS sub-TLVs:
 o  Administrative Group (color) (sub-TLV type 3),

Farkas, et al. Standards Track [Page 8] RFC 7813 IS-IS PCR June 2016

 o  Maximum Link Bandwidth (sub-TLV type 9),
 o  Maximum Reservable Link Bandwidth (sub-TLV type 10),
 o  Unreserved Bandwidth (sub-TLV type 11),
 o  TE Default Metric (sub-TLV type 18).
 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).
 Further attributes are provided by the IS-IS TE Metric Extension link
 attribute sub-TLVs specified in [RFC7810]:
 o  Unidirectional Link Delay (sub-TLV type 33),
 o  Min/Max Unidirectional Link Delay (sub-TLV type 34),
 o  Unidirectional Delay Variation (sub-TLV type 35),
 o  Unidirectional Link Loss (sub-TLV type 36),
 o  Unidirectional Residual Bandwidth (sub-TLV type 37),
 o  Unidirectional Available Bandwidth (sub-TLV type 38),
 o  Unidirectional Utilized Bandwidth (sub-TLV type 39).
 The Shared Risk Link Group (SRLG) information provided by the SRLG
 TLV (type 138) [RFC5307] MAY also be 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.

5. Explicit ECT Algorithms

 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 [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 Std 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 [RFC6329].

Farkas, et al. Standards Track [Page 9] RFC 7813 IS-IS PCR June 2016

 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
 (Section 6.1), and then instructs IS-IS PCR to install it.  The value
 for the ST ECT Algorithm is 00-80-C2-17.
 The Loose Tree (LT) ECT Algorithm MAY also be 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 (Section 6.1) 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
 (Section 6.2) 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.
 The Loose Tree Set (LTS) ECT Algorithm MAY also be supported.  It is
 used if connectivity among the Edge Bridges specified by the Topology
 sub-TLV (Section 6.1) 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 Section 6.2).  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.
 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 [RFC6329] is applied
 (see also subclauses 28.5 - 28.8 of [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 [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.

Farkas, et al. Standards Track [Page 10] RFC 7813 IS-IS PCR June 2016

 The MRT ECT Algorithm MAY also be supported.  It is used for the
 establishment and maintenance of MRTs in a distributed fashion.  The
 MRT Lowpoint algorithm specified by [RFC7811] MUST be used for the
 computation of MRTs.  The MRT Lowpoint algorithm first computes the
 GADAG and 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 (Section 6.1).  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.
 The MRT GADAG (MRTG) ECT Algorithm MAY also be 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
 (Section 6.1), which is flooded in the domain.  The bridges then
 compute the MRTs for the MRT Roots based on the GADAG received.
 Section 7 provides more details on the description of the GADAG.  The
 value for the MRTG ECT Algorithm is 00-80-C2-19.
 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.
 The SPB Link Metric sub-TLV [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.

6. IS-IS PCR Sub-TLVs

 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 the Topology sub-TLV.

6.1. Topology Sub-TLV

 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 Section 7 in detail.
 The Topology sub-TLV MUST be carried in an MT-Capability TLV (type
 144) [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
 (Section 6.2).  A Topology sub-TLV describing a loose tree MAY also
 convey further sub-TLVs to specify constraints.  Figure 1 shows the
 format of the Topology sub-TLV.

Farkas, et al. Standards Track [Page 11] RFC 7813 IS-IS PCR June 2016

    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)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 1: Topology Sub-TLV
 The parameters of explicit trees are encoded by the Topology sub-TLV
 as follows:
 a.  Type (8 bits): The type of the sub-TLV, its value is 21.
 b.  Length (8 bits): The total number of bytes contained in the Value
     field.
 c.  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.
 d.  Reserved (Res) (4 bits): The reserved bits MUST be set to 0 on
     transmission and the value MUST be ignored on reception.
 e.  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
     (Section 5) require further VIDs that are associated with the
     VLAN via the SPB Instance sub-TLV [RFC6329].  A Topology sub-TLV
     specifying a GADAG can have zero Base VID parameters.  In this

Farkas, et al. Standards Track [Page 12] RFC 7813 IS-IS PCR June 2016

     case, the given GADAG MUST be applied for each VLAN associated
     with the MRTG ECT Algorithm (Section 5).
 f.  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.
 A topology is specified by a list of Hop sub-TLVs (Section 6.2), 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.
 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; after
 that, the order of the branches does not matter within the Topology
 sub-TLV.  Figure 2 shows an example strict tree and its description.

Farkas, et al. Standards Track [Page 13] RFC 7813 IS-IS PCR June 2016

                                         +-----------+
                                         |     A     |
                                         +-----------+
                                         |     I     |
                                         +-----------+
                                         |     H     |
                [B]---[A]---[I]          +-----------+
                 |           |           |     G     |
                 |           |           +-----------+
                 |           |           |     E     |
                [C]---[F]   [H]          +-----------+
                 |           |           |     A     |
                 |           |           +-----------+
                 |           |           |     B     |
                [D]   [E]---[G]          +-----------+
                                         |     C     |
                                         +-----------+
                                         |     D     |
                                         +-----------+
                                         |     C     |
                                         +-----------+
                                         |     F     |
                                         +-----------+
      Figure 2: A Strict Tree and Its Description; Root = Node A
 The Topology sub-TLV of a loose tree does not provide any path or
 path segment other than the hops that are to participate.  The root
 MUST be the first hop.  The leaves of a single loose tree MUST also
 be 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 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 to be a
 loose hop.  The path of a loose hop MUST be pruned from the tree if
 the path would create a loop or hairpin.
 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.

Farkas, et al. Standards Track [Page 14] RFC 7813 IS-IS PCR June 2016

 The Topology sub-TLV specifies a GADAG if the Base VIDs conveyed by
 the Topology sub-TLV are associated with the MRTG ECT Algorithm.
 Section 7 provides the details on the description of a GADAG by a
 Topology sub-TLV.
 Each Edge Bridge of an explicit tree MUST always be 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 Section 6.2) in the
 appropriate Hop sub-TLVs.
 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 [RFC5305] or a Bandwidth Constraint (Section 6.3).  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.
 IS-IS PCR MAY be used for recording bandwidth assignment.  In that
 case, the Topology sub-TLV conveys Bandwidth Assignment sub-TLV
 (Section 6.4), and it MAY also convey Timestamp sub-TLV
 (Section 6.5).  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.

6.2. Hop Sub-TLV

 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 (Section 6.1).  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 Section 6.1.  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 a special role in the tree.  The Hop sub-TLV MAY also
 specify a delay budget for a loose hop.

Farkas, et al. Standards Track [Page 15] RFC 7813 IS-IS PCR June 2016

 By default, the Edge Bridges both transmit and receive with respect
 to each VID associated with an explicit tree, except for an LTS
 (Section 5) 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.
 Figure 3 shows the format of the variable length Hop sub-TLV, which
 MUST be conveyed by a Topology sub-TLV (Section 6.1).
    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)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Figure 3: Hop Sub-TLV
 The parameters of a hop are encoded as follows:
 a.  Type (8 bits): The type of the sub-TLV, its value is 22.
 b.  Length (8 bits): The total number of bytes contained in the Value
     field.

Farkas, et al. Standards Track [Page 16] RFC 7813 IS-IS PCR June 2016

 c.  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.
     1.  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.
     2.  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.
     3.  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.
     4.  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
         (Section 5), 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 (Section 5), 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
         (Section 5), 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.

Farkas, et al. Standards Track [Page 17] RFC 7813 IS-IS PCR June 2016

         If the Base VIDs conveyed by the Topology sub-TLV are
         associated with the MRTG ECT algorithm (Section 5), 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.
     5.  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 Section 7.
     6.  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.
     7.  Reserved (Res) (2 bits): The reserved bits MUST be set to 0
         on transmission, and the value MUST be ignored on reception.
 d.  System ID (48 bits): The six-byte IS-IS System Identifier of the
     bridge to which the Hop sub-TLV refers.
 e.  Extended Local Circuit ID (32 bits): The Extended Local Circuit
     ID [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.
 f.  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.
 g.  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.

Farkas, et al. Standards Track [Page 18] RFC 7813 IS-IS PCR June 2016

     1.  T flag (1 bit): This is the Transmit allowed flag for the VID
         following the flag.
     2.  R flag (1 bit): This is the Receive allowed flag for the VID
         following the flag.
     3.  Reserved (Res) (2 bits): The reserved bits MUST be set to 0
         on transmission, and the value MUST be ignored on reception.
     4.  VID (12 bits): A VID.
 h.  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 [RFC7810].  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 (Section 5).
     If the 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.

6.3. Bandwidth Constraint Sub-TLV

 The Bandwidth Constraint sub-TLV MAY be included in a Topology sub-
 TLV (Section 6.1) 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.  Figure 4 shows the format of the Bandwidth Constraint sub-
 TLV.

Farkas, et al. Standards Track [Page 19] RFC 7813 IS-IS PCR June 2016

    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)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 4: Bandwidth Constraint Sub-TLV
 The parameters of the bandwidth constraint are encoded as follows:
 a.  Type (8 bits): The type of the sub-TLV, its value is 23.
 b.  Length (8 bits): The total number of bytes contained in the Value
     field.  The value of the Length field is 5 bytes.
 c.  PCP (4 bits): The Priority Code Point (PCP) parameter identifies
     the traffic class the Available Bandwidth parameter refers to, if
     any.
 d.  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 the
     peak information rate.
 e.  PCP (P) flag (1 bit): If this flag is set, then the PCP parameter
     is taken into account.
 f.  Reserved (Res) (3 bits): The reserved bits MUST be set to 0 on
     transmission, and the value MUST be ignored on reception.
 g.  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 [RFC5305], the
     Available Bandwidth is encoded as a 32-bit IEEE floating-point
     number [IEEE754], and the units are bytes (not bits!) per second.
     When the Unreserved Bandwidth sub-TLV (sub-TLV type 11 specified
     by [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

Farkas, et al. Standards Track [Page 20] RFC 7813 IS-IS PCR June 2016

     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 Section 6.2) of the Edge Bridges.  If
     all the VIDs of the Topology sub-TLV (Section 6.1) 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.

6.4. Bandwidth Assignment Sub-TLV

 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.
 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
 (Section 6.1).  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 (Section 6.1).  Figure 5
 shows the format of the Bandwidth Assignment sub-TLV.

Farkas, et al. Standards Track [Page 21] RFC 7813 IS-IS PCR June 2016

    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)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 5: Bandwidth Assignment Sub-TLV
 The parameters of the bandwidth assignment are encoded as follows:
 a.  Type (8 bits): The type of the sub-TLV, its value is 24.
 b.  Length (8 bits): The total number of bytes contained in the Value
     field.  The value of the Length field is 5 bytes.
 c.  PCP (3 bits): The PCP parameter identifies the traffic class for
     which the bandwidth is to be assigned.
 d.  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 the committed information
     rate.  If the DEI parameter is set, then the bandwidth assignment
     is performed for providing the peak information rate.
 e.  Importance (Imp) (3 bits): This is the Importance parameter for
     determining precedence order among bandwidth assignments within a
     PCP as described below.  A lower numerical value indicates more
     important bandwidth assignment within a PCP.  The default value
     of the Importance parameter is 7.
 f.  Reserved (R) (1 bit): The reserved bit MUST be set to 0 on
     transmission, and the value MUST be ignored on reception.
 g.  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 [RFC5305], the
     Bandwidth parameter is encoded as a 32-bit IEEE floating-point
     number [IEEE754], and the units are bytes (not bits!) per second.
     The bandwidth assignment applies for both directions in case of
     symmetric explicit trees.

Farkas, et al. Standards Track [Page 22] RFC 7813 IS-IS PCR June 2016

 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 that, precedence ordering is required among
 bandwidth assignments, then ordering based on the following
 parameters MUST be applied:
 1.  PCP parameter of Bandwidth Assignment sub-TLV,
 2.  Importance parameter of Bandwidth Assignment sub-TLV,
 3.  Timestamp sub-TLV (if present in the Topology sub-TLV).
 A bandwidth assignment takes precedence if it has a higher PCP, or a
 higher Importance within a PCP, or an earlier timestamp in case of
 equal Importance within a PCP.  A bandwidth assignment associated
 with a timestamp takes precedence over a bandwidth assignment without
 a 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 a 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 lowest LSP ID.

6.5. Timestamp Sub-TLV

 The Timestamp sub-TLV MAY be included in a Topology sub-TLV
 (Section 6.1) in order to provide precedence order among equally
 important bandwidth assignments within a PCP as described in
 Section 6.4.  Figure 6 shows the format of the Timestamp sub-TLV.
    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)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 6: Timestamp Sub-TLV
 The timestamp represents a positive time with respect to the
 Precision Time Protocol (PTP) epoch, and it is encoded as follows:
 a.  Type (8 bits): The type of the sub-TLV; its value is 25.

Farkas, et al. Standards Track [Page 23] RFC 7813 IS-IS PCR June 2016

 b.  Length (8 bits): The total number of bytes contained in the Value
     field.  The value of the Length field is 4 bytes.
 c.  Time (32 bits): This is the time in units of seconds with respect
     to the PTP epoch.
 The Timestamp sub-TLV carries the seconds portion of PTP as specified
 by [IEEE1588].  The epoch is 1970-01-01 00:00:00 TAI (i.e., the PTP
 time does not include leap seconds).

7. MRT-FRR Application

 The application of MRT by [IEEE8021Qca] is discussed in detail in
 [MRT-IEEE8021qca].  This section describes some special
 considerations for the use of the MRT Lowpoint algorithm [RFC7811],
 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.
 IS-IS PCR does not use the MRT Profile specified in [RFC7812].  IS-IS
 PCR only relies on the algorithm specification in [RFC7811].  Both
 the MRT ECT Algorithm and the MRTG ECT Algorithm use the MRT Lowpoint
 algorithm specified in [RFC7811].
 The SPB Link Metric sub-TLV [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 [RFC6329] MUST be used, which
 is based on the lower BridgeID.  (The BridgeID is an 8-byte quantity
 whose upper 2 bytes are the node's BridgePriority and lower 6 bytes
 are the node's System ID.)  Note that if MRTs are used for source-
 specific multicast (see [IEEE8021Qca] for details), then the bridges
 have to compute the MRTs of the other bridges in addition to their
 own 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.)
 The GADAG is identical for all the MRTs within a network domain, as a
 consequence of the use of the MRT Lowpoint algorithm [RFC7811].
 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 computed only by the GADAG Computer, which then MUST flood

Farkas, et al. Standards Track [Page 24] RFC 7813 IS-IS PCR June 2016

 the descriptor Topology sub-TLV of the GADAG.  The bridges then
 compute the MRTs based on the received GADAG.
 The GADAG computation requires the selection of the GADAG Root.  The
 bridge with the best BridgeID MUST be selected as the GADAG Root,
 where the numerically lower value indicates the better identifier.
 The Bridge Priority component of the BridgeID allows the
 configuration of the GADAG Root by management action.  The Bridge
 Priority is conveyed by the SPB Instance sub-TLV [RFC6329].
 The GADAG Computer MUST perform the GADAG computation as specified by
 the MRT Lowpoint algorithm [RFC7811].  The GADAG Computer then MUST
 encode the GADAG in a Topology sub-TLV (Section 6.1), 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 Section 6.2) is
 used to mark the end of a topology block.  (A GADAG with multiple
 blocks is illustrated in Figure 8.)  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 Section 6.2) 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.
 Figure 7 shows an example GADAG.  The figure also illustrates the
 description of the GADAG; it shows the System ID parameter of the Hop
 sub-TLV (Section 6.2) and the order of hops in the Topology sub-TLV
 (Section 6.1).

Farkas, et al. Standards Track [Page 25] RFC 7813 IS-IS PCR June 2016

                                                     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 |
                                        +-----------+---+
      Figure 7: A GADAG and Its Description; GADAG Root = Node A
 A topology can comprise multiple blocks, like the one illustrated in
 Figure 8(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 Figure 8(b).  Note that two arcs with opposite directions
 represent a cut-link in a GADAG; see, for example, the cut-link
 between D and G.  The encoding starts with the block (ADAG) involving
 the GADAG Root as illustrated in Figure 8.  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

Farkas, et al. Standards Track [Page 26] RFC 7813 IS-IS PCR June 2016

 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.
 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 Figure 8, 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.

Farkas, et al. Standards Track [Page 27] RFC 7813 IS-IS PCR June 2016

                                                     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
  Figure 8: A GADAG with Cut-Links and Its Description; GADAG Root =
                                Node A

Farkas, et al. Standards Track [Page 28] RFC 7813 IS-IS PCR June 2016

8. Summary

 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.

9. IANA Considerations

 This document defines the following IS-IS sub-TLVs within the
 MT-Capability TLV (type 144).  They are listed in the "IS-IS TLV
 Codepoints" registry.
       Type        Description                           Length
       ----        ----------------------------        --------
         21        Topology                            variable
         22        Hop                                 variable
         23        Bandwidth Constraint                       5
         24        Bandwidth Assignment                       5
         25        Timestamp                                  4

10. Security Considerations

 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.
 Any mechanism that chooses forwarding paths, and allocates resources
 to those paths, is potentially vulnerable to attack.  The security
 considerations section of [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.
 Because the mechanism assumed for distributing tree information
 relies on IS-IS routing, IS-IS routing security considerations
 (Section 6, [RFC1195]) and mechanisms (e.g., [RFC5310]) used to
 authenticate peer advertisements apply.

Farkas, et al. Standards Track [Page 29] RFC 7813 IS-IS PCR June 2016

11. References

11.1. Normative References

 [IEEE8021Qca]
            IEEE, "IEEE Standard for Local and metropolitan area
            networks - Bridges and Bridged Networks - Amendment 24:
            Path Control and Reservation", IEEE 802.1Qca-2015,
            DOI 10.1109/IEEESTD.2016.7434544, 2016,
            <https://standards.ieee.org/findstds/
            standard/802.1Qca-2015.html>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.
 [RFC5303]  Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way
            Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303,
            DOI 10.17487/RFC5303, October 2008,
            <http://www.rfc-editor.org/info/rfc5303>.
 [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
            Engineering", RFC 5305, DOI 10.17487/RFC5305, October
            2008, <http://www.rfc-editor.org/info/rfc5305>.
 [RFC5307]  Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
            in Support of Generalized Multi-Protocol Label Switching
            (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
            <http://www.rfc-editor.org/info/rfc5307>.
 [RFC6329]  Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
            A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE
            802.1aq Shortest Path Bridging", RFC 6329,
            DOI 10.17487/RFC6329, April 2012,
            <http://www.rfc-editor.org/info/rfc6329>.
 [RFC7810]  Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
            Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
            RFC 7810, DOI 10.17487/RFC7810, May 2016,
            <http://www.rfc-editor.org/info/rfc7810>.
 [RFC7811]  Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
            Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
            Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
            DOI 10.17487/RFC7811, June 2016,
            <http://www.rfc-editor.org/info/rfc7811>.

Farkas, et al. Standards Track [Page 30] RFC 7813 IS-IS PCR June 2016

11.2. Informative References

 [IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization
            Protocol for Networked Measurement and Control Systems",
            IEEE 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, 2008,
            <http://standards.ieee.org/findstds/
            standard/1588-2008.html>.
 [IEEE754]  IEEE, "IEEE Standard for Floating-Point Arithmetic",
            IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935, 2008,
            <http://standards.ieee.org/findstds/
            standard/754-2008.html>.
 [IEEE8021aq]
            IEEE, "IEEE Standard for Local and metropolitan area
            networks -- Media Access Control (MAC) Bridges and Virtual
            Bridged Local Area Networks -- Amendment 20: Shortest Path
            Bridging", IEEE 802.1aq-2012,
            DOI 10.1109/IEEESTD.2012.6231597, 2012,
            <https://standards.ieee.org/findstds/
            standard/802.1aq-2012.html>.
 [IEEE8021Q]
            IEEE, "IEEE Standard for Local and metropolitan area
            networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
            DOI 10.1109/IEEESTD.2014.6991462, 2014,
            <https://standards.ieee.org/findstds/
            standard/802.1Q-2014.html>.
 [MRT-IEEE8021qca]
            Bowers, C. and J. Farkas, "Applicability of Maximally
            Redundant Trees to IEEE 802.1Qca Path Control and
            Reservation", Work in Progress, draft-bowers-rtgwg-mrt-
            applicability-to-8021qca-01, July 2015.
 [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
            dual environments", RFC 1195, DOI 10.17487/RFC1195,
            December 1990, <http://www.rfc-editor.org/info/rfc1195>.
 [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
            Element (PCE)-Based Architecture", RFC 4655,
            DOI 10.17487/RFC4655, August 2006,
            <http://www.rfc-editor.org/info/rfc4655>.
 [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
            and M. Fanto, "IS-IS Generic Cryptographic
            Authentication", RFC 5310, DOI 10.17487/RFC5310, February
            2009, <http://www.rfc-editor.org/info/rfc5310>.

Farkas, et al. Standards Track [Page 31] RFC 7813 IS-IS PCR June 2016

 [RFC7812]  Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
            IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
            FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
            <http://www.rfc-editor.org/info/rfc7812>.

Acknowledgements

 The authors would like to thank Don Fedyk and Eric Gray for their
 comments and suggestions.

Authors' Addresses

 Janos Farkas (editor)
 Ericsson
 Konyves Kalman krt. 11/B
 Budapest  1097
 Hungary
 Email: janos.farkas@ericsson.com
 Nigel Bragg
 Ciena
 43-51 Worship Street
 London  EC2A 2DX
 United Kingdom
 Email: nbragg@ciena.com
 Paul Unbehagen Jr
 Avaya
 1300 W. 120th Avenue
 Westminster, CO  80234
 United States
 Email: unbehagen@avaya.com
 Glenn Parsons
 Ericsson
 349 Terry Fox Drive
 Ottawa  ON, K2K 2V6
 Canada
 Email: glenn.parsons@ericsson.com

Farkas, et al. Standards Track [Page 32] RFC 7813 IS-IS PCR June 2016

 Peter Ashwood-Smith
 Huawei Technologies
 303 Terry Fox Drive, Suite 400
 Ottawa  ON, K2K 3J1
 Canada
 Email: Peter.AshwoodSmith@huawei.com
 Chris Bowers
 Juniper Networks
 1194 N. Mathilda Ave.
 Sunnyvale, CA  94089
 United States
 Email: cbowers@juniper.net

Farkas, et al. Standards Track [Page 33]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7813.txt · Last modified: 2016/06/16 22:58 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki