idnits 2.17.1 draft-ietf-isis-pcr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'C' is mentioned on line 629, but not defined == Missing Reference: 'F' is mentioned on line 629, but not defined == Missing Reference: 'H' is mentioned on line 1228, but not defined == Missing Reference: 'D' is mentioned on line 1228, but not defined == Missing Reference: 'E' is mentioned on line 633, but not defined == Missing Reference: 'G' is mentioned on line 1228, but not defined == Missing Reference: 'A' is mentioned on line 1228, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-isis-te-metric-extensions-07 == Outdated reference: A later version (-09) exists of draft-ietf-rtgwg-mrt-frr-algorithm-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021aq' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021Qca' == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-06 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets J. Farkas, Ed. 3 Internet-Draft Ericsson 4 Intended status: Standards Track N. Bragg 5 Expires: January 7, 2016 Ciena 6 P. Unbehagen 7 Avaya 8 G. Parsons 9 Ericsson 10 P. Ashwood-Smith 11 Huawei Technologies 12 C. Bowers 13 Juniper Networks 14 July 6, 2015 16 IS-IS Path Computation and Reservation 17 draft-ietf-isis-pcr-01 19 Abstract 21 IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit 22 path control via IS-IS in Layer 2 networks in order to move beyond 23 the shortest path capabilities provided by IEEE 802.1aq Shortest Path 24 Bridging (SPB). IS-IS PCR provides capabilities for the 25 establishment and control of explicit forwarding trees in a Layer 2 26 network domain. This document specifies the sub-TLVs for IS-IS PCR. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 7, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 65 4. Explicit Trees . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Explicit ECT Algorithms . . . . . . . . . . . . . . . . . . . 10 67 6. IS-IS PCR sub-TLVs . . . . . . . . . . . . . . . . . . . . . 12 68 6.1. Topology sub-TLV . . . . . . . . . . . . . . . . . . . . 12 69 6.2. Hop sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.3. Bandwidth Constraint sub-TLV . . . . . . . . . . . . . . 19 71 6.4. Bandwidth Assignment sub-TLV . . . . . . . . . . . . . . 21 72 6.5. Timestamp sub-TLV . . . . . . . . . . . . . . . . . . . . 23 73 7. MRT-FRR Application . . . . . . . . . . . . . . . . . . . . . 23 74 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 77 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 80 12.2. Informative References . . . . . . . . . . . . . . . . . 29 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 83 1. Introduction 85 IEEE 802.1Qca Path Control and Reservation (PCR) [IEEE8021Qca] 86 specifies extensions to IS-IS for the control of Explicit Trees 87 (ETs). The PCR extensions are compatible with the Shortest Path 88 Bridging (SPB) extensions to IS-IS specified by [RFC6329] and 89 [IEEE8021aq] (already rolled into [IEEE8021Q]). Furthermore, IS-IS 90 with PCR extensions relies on the SPB architecture and terminology; 91 and some of the IS-IS SPB sub-TLVs are also leveraged. IS-IS PCR 92 builds upon IS-IS and uses IS-IS in a similar way to SPB. IS-IS PCR 93 only addresses point-to-point physical links, although IS-IS also 94 supports shared media LANs. 96 This document specifies five IS-IS sub-TLVs for the control of 97 explicit trees by IS-IS PCR in a Layer 2 network as specified by IEEE 98 802.1Qca. In addition to the sub-TLVs specified here, IS-IS PCR 99 relies on the following IS-IS SPB sub-TLVs specified by [RFC6329]: 101 o SPB Link Metric sub-TLV 103 o SPB Base VLAN-Identifiers sub-TLV 105 o SPB Instance sub-TLV 107 o SPBV MAC address sub-TLV 109 o SPBM Service Identifier and Unicast Address sub-TLV 111 These sub-TLVs are used to provide the link metric and the 112 associations among bridges, MAC addresses, VIDs and I-SIDs within an 113 IS-IS domain. The use of these SPB sub-TLVs for PCR is specified by 114 IEEE 802.1Qca. Note that IS-IS PCR does not require the 115 implementation of the full IS-IS SPB protocol but only the support of 116 these SPB sub-TLVs. A bridge can support both IS-IS SPB and IS-IS 117 PCR at the same time but when it supports both they are implemented 118 by the same IS-IS entity on a per instance basis. 120 The sub-TLVs specified here can be also applied for Fast ReRoute 121 using Maximally Redundant Trees (MRT-FRR) 122 [I-D.ietf-rtgwg-mrt-frr-architecture] in a Layer 2 network. MRTs are 123 computed as specified in [I-D.ietf-rtgwg-mrt-frr-algorithm]. If MRT 124 computation is split such that the Generalized Almost Directed 125 Acyclic Graph (GADAG) is computed centrally, then these sub-TLVs can 126 be used to distribute the GADAG, which is identical for each network 127 node throughout a network domain. 129 PCR uses IS-IS, the SPB sub-TLVs listed above, and the new sub-TLVs 130 defined here. IS-IS PCR has no impact to IETF protocols. 132 2. Conventions Used in This Document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 The lowercase forms with an initial capital "Must", "Must Not", 139 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 140 in this document are to be interpreted in the sense defined in 142 [RFC2119], but are used where the normative behavior is defined in 143 documents published by SDOs other than the IETF. 145 3. Terminology and Definitions 147 ADAG: Almost Directed Acyclic Graph - a digraph that can be 148 transformed into a DAG by removing all arcs incoming to the root. 149 [I-D.ietf-rtgwg-mrt-frr-architecture] 151 B-VID: Backbone VID. [IEEE8021Q] 153 Base VID: The VID used to identify a VLAN in management operations. 154 [IEEE8021aq] 156 BLCE: Bridge Local Computation Engine - A computation engine in a 157 bridge that performs path and routing computations. The BLCE 158 implements e.g. SPF, CSPF, or the Maximally Redundant Trees 159 Algorithm. [IEEE8021Qca] 161 Constrained tree: A tree meeting a certain constraint, e.g. 162 providing a minimal available bandwidth. [IEEE8021Qca] 164 Cut-node: A node is a cut-node if removing it partitions the 165 network. [I-D.ietf-rtgwg-mrt-frr-architecture] 167 Cut-link: A link is a cut-link if removing it partitions the 168 network. [I-D.ietf-rtgwg-mrt-frr-architecture] 170 DAG: Directed Acyclic Graph - a digraph containing no directed 171 cycle. [I-D.ietf-rtgwg-mrt-frr-architecture] 173 DEI: Drop Eligible Indicator. [IEEE8021Q] 175 ECT Algorithm: Equal Cost Tree Algorithm - The algorithm and 176 mechanism that is used for the control of the active topology, 177 i.e. forwarding trees. It can be one of the shortest path 178 algorithms specified by IEEE 802.1aq. It can be also one of the 179 explicit path control algorithms specified by IEEE 802.1Qca. Each 180 ECT Algorithm has a 32-bit unique ID. [IEEE8021aq] 182 ET: Explicit Tree - An explicitly defined tree, which is specified 183 by its Edge Bridges and the paths among the Edge Bridges. If only 184 the Edge Bridges are specified but the paths are not, then it is a 185 loose explicit tree. If the paths are also specified, then it is 186 a strict explicit tree. [IEEE8021Qca] 188 ETDB: Explicit Tree Database - A database storing explicit trees. 189 [IEEE8021Qca] 191 FDB: Filtering Database. [IEEE8021Q] 193 GADAG: Generalized ADAG - a digraph, which has only ADAGs as all of 194 its topology blocks. [I-D.ietf-rtgwg-mrt-frr-architecture] 196 Hop: A hop is specified by two nodes. A strict hop has no 197 intermediate nodes, whereas a loose hop can have one or more 198 intermediate nodes. IS-IS PCR specifies an explicit tree by an 199 ordered list of hops starting at the root, each successive hop 200 being defined by the next element of the list. [IEEE8021Qca] 202 I-SID: Backbone Service Instance Identifier - A 24-bit ID. 203 [IEEE8021Q] 205 Maximally Redundant Trees (MRTs): A pair of trees with a common MRT 206 Root where the path from any leaf node to the MRT Root along the 207 first tree (MRT-Blue) and the path from the same leaf node along 208 the second tree (MRT-Red) share the minimum number of nodes and 209 the minimum number of links. Each such shared node is a cut-node. 210 Any shared links are cut-links. 211 [I-D.ietf-rtgwg-mrt-frr-architecture] 213 MRT-Blue: MRT-Blue is one of the two MRTs; specifically, MRT-Blue is 214 the increasing MRT where links in the GADAG are taken in the 215 direction from a lower topologically ordered node to a higher one. 216 [I-D.ietf-rtgwg-mrt-frr-architecture] 218 MRT-Red: MRT-Red is one of the two MRTs; specifically, MRT-Red is 219 the decreasing MRT where links in the GADAG are taken in the 220 direction from a higher topologically ordered node to a lower one. 221 [I-D.ietf-rtgwg-mrt-frr-architecture] 223 MRT Root: The common root of the two MRTs: MRT-Blue and MRT-Red. 224 [I-D.ietf-rtgwg-mrt-frr-architecture] 226 MSRP: Multiple Stream Registration Protocol, standardized as IEEE 227 802.1Qat, already rolled into [IEEE8021Q]. 229 PCA: Path Control Agent - The agent that is part of the IS-IS domain 230 and thus can perform IS-IS operations on behalf of a PCE, e.g. 231 maintain the LSDB and send LSPs. [IEEE8021Qca] 233 PCE: Path Computation Element - An entity that is capable of 234 computing a path through a network based on a representation of 235 the topology of the network (obtained by undefined means external 236 to the PCE). [RFC4655] 238 PCP: Priority Code Point, which identifies a traffic class. 239 [IEEE8021Q] 241 PTP: Precision Time Protocol specified by [IEEE1588]. 243 Redundant trees: A pair of trees with a common root where the paths 244 from any leaf node to the root along the first tree and the second 245 tree are disjoint. [I-D.ietf-rtgwg-mrt-frr-architecture] 247 SPBM: SPB MAC - The SPB mode where a MAC or its shorthand 248 (SPSourceID: Shortest Path Source ID) is used to identify an SPT. 249 [IEEE8021aq] 251 SPBV: SPB VID - The SPB mode where a unique VID is assigned to each 252 SPT Root bridge and is used to identify an SPT. [IEEE8021aq] 254 SPF: Shortest Path First. 256 SPT: Shortest Path Tree. [IEEE8021aq] 258 SRLG: Shared Risk Link Group - A set of links that share a resource 259 whose failure affects each link. [RFC5307] 261 TAI: Temps Atomique International - International Atomic Time. 262 [IEEE1588] 264 topology block: Either a maximally two-connected cluster, a cut-link 265 with the two nodes at either end, or an isolated node. 266 [I-D.ietf-rtgwg-mrt-frr-architecture] 268 TED: Traffic Engineering Database - A database storing the traffic 269 engineering information propagated by IS-IS. [RFC5305] 271 two-connected: A graph that has no cut-nodes. This is a graph that 272 requires at least two nodes to be removed before gets partitioned. 273 [I-D.ietf-rtgwg-mrt-frr-architecture] 275 VID: VLAN ID. [IEEE8021Q] 277 VLAN: Virtual Local Area Network. [IEEE8021Q] 279 4. Explicit Trees 281 An explicit tree is determined by a Path Computation Element (PCE) 282 [RFC4655] and is not required to follow the shortest path. A PCE is 283 an entity that is capable of computing a topology for forwarding 284 based on a network topology, its corresponding attributes, and 285 potential constraints. A PCE MUST explicitly describe a forwarding 286 tree as described in Section 6.1. Either a single PCE or multiple 287 PCEs determine explicit trees for a domain. Even if there are 288 multiple PCEs in a domain, each explicit tree MUST be only determined 289 by one PCE, which is referred to as the owner PCE of the tree. PCEs 290 and IS-IS PCR can be used in combination with IS-IS SPB shortest path 291 routing. 293 The PCE interacts with the active topology control protocol, i.e. 294 with IS-IS. The collaboration with IS-IS can be provided by a Path 295 Control Agent (PCA) on behalf of a PCE. Either the PCE or the 296 corresponding PCA is part of the IS-IS domain. If the PCE is not 297 part of the IS-IS domain, then the PCE MUST be associated with a PCA 298 that is part of the IS-IS domain. The PCE or its PCA MUST establish 299 IS-IS adjacency in order to receive all the LSPs transmitted by the 300 bridges in the domain. The PCE, either on its own or via its PCA, 301 can control the establishment of explicit trees in that domain by 302 injecting an LSP conveying an explicit tree and thus instruct IS-IS 303 to set up the explicit tree determined by the PCE. If instructed to 304 do so by a PCE, IS-IS MAY also record and communicate bandwidth 305 assignments, which MUST NOT be applied if reservation protocol (e.g. 306 Multiple Stream Registration Protocol (MSRP)) is used in the domain. 307 Both MSRP and IS-IS MUST NOT be used to make bandwidth assignments in 308 the same domain. 310 The operation details of the PCE are not specified by this document 311 or by IEEE 802.1Qca. If the PCE is part of the IS-IS domain, then 312 the PCE uses IS-IS PDUs to communicate with the IS-IS domain and the 313 PCE has a live IS-IS LSDB, (i.e. the PCE implements the PCA functions 314 too). A PCE can instead communicate with the IS-IS domain via a PCA, 315 e.g. to retrieve the LSDB or instruct the creation of an explicit 316 tree. However, the means of communication between the PCE and the 317 PCA is not specified by this document or by IEEE 802.1Qca. 319 An Explicit Tree (ET) is an undirected loop-free topology, whose use 320 is under the control of the owner PCE by means of associating VIDs 321 and MAC addresses with it. An ET MUST NOT contain Cycles. As it is 322 undirected, an ET contains no assumptions about the direction of any 323 flows that use it; it can be used in either direction as specified by 324 the VIDs and MAC addresses associated with it. It is the 325 responsibility of the PCE to ensure reverse path congruency and 326 multicast-unicast congruency if that is required. 328 An explicit tree is either strict or loose. A strict explicit tree 329 specifies all bridges and paths it comprises. A loose tree only 330 specifies the bridges as a list of hops that have a special role in 331 the tree, e.g. an Edge Bridge, and no path or path segment is 332 specified between the bridges, which are therefore loose hops even if 333 Edge Bridges are adjacent neighbors. The special role of a hop can 334 be: Edge Bridge, root, leaf, a bridge to be avoided, or a transit hop 335 in case of a tree with a single leaf. The path for a loose hop is 336 determined by the Bridge Local Computation Engine (BLCE) of the 337 bridges. The shortest path is used for a loose hop unless specified 338 otherwise by the descriptor (Section 6.1) of the tree or by the 339 corresponding ECT Algorithm (Section 5). 341 A loose explicit tree is constrained if the tree descriptor includes 342 one or more constraints, e.g. the administrative group that the links 343 of the tree have to belong to. The BLCE of the bridges then apply 344 the Constrained Shortest Path First (CSPF) algorithm, which is 345 Shortest Path First (SPF) on the topology that only contains the 346 links meeting the constraint(s). 348 An explicit tree is specified by a Topology sub-TLV (Section 6.1). 349 The Topology sub-TLV associates one or more VIDs with an explicit 350 tree. The Topology sub-TLV includes two or more Hop sub-TLVs 351 (Section 6.2), and a hop is specified by an IS-IS System ID. A Hop 352 sub-TLV MAY include a delay constraint for a loose hop. A Topology 353 sub-TLV MAY also include further sub-TLVs to constrain loose hops. 354 The bridges involved in an explicit tree store the corresponding 355 Topology sub-TLVs in their Explicit Tree Database (ETDB). 357 Explicit trees are propagated and set-up by IS-IS PCR in a domain. 358 The PCE or its PCA assembles the Topology sub-TLVs (Section 6.1), and 359 adds it into an LSP, which is flooded throughout the domain. The 360 Topology sub-TLV is flooded by the same techniques used for the SPB 361 LSPs. The bridges then MUST process the Topology sub-TLV upon 362 reception. If the Topology sub-TLV specifies one or more loose 363 trees, then the path for the loose hops is determined by the BLCE of 364 the bridges. The bridges then install the appropriate FDB entries 365 for frame forwarding along the tree described by the Topology sub- 366 TLV, or the trees computed based on the Topology sub-TLV. Dynamic 367 Filtering Entries are maintained by IS-IS for the VID, MAC address 368 tuples associated with an ET. 370 Due to the LSP aging of IS-IS, the Topology sub-TLVs (Section 6.1) 371 have to be refreshed similar to other IS-IS TLVs in order to keep the 372 integrity of the LSDB. The corresponding Dynamic Filtering Entries 373 are also refreshed in the FDB when a Topology sub-TLV is refreshed. 374 Refreshing Topology sub-TLVs is the task of the entity being part of 375 the IS-IS domain, i.e. either the PCE or the PCA. 377 The owner PCE can withdraw an explicit tree by sending an updated LSP 378 that does not include the Topology sub-TLV (Section 6.1). If a 379 Topology sub-TLV is removed from an LSP (or has been changed), so 380 that (previous) Topology sub-TLV is no longer present (or has been 381 changed) in the LSDB, then that (previous) Topology sub-TLV is 382 implicitly withdrawn. ISIS-PCR then removes (or updates) the 383 explicit tree. 385 There is no precedence order between Explicit Trees. Precedence 386 order among bandwidth assignments recorded by IS-IS PCR is specified 387 in Section 6.4. 389 If it is not possible to install an explicit tree, e.g. constraint(s) 390 cannot be met or the Topology sub-TLV is ill-formed, then no tree is 391 installed but a management report is generated. 393 The bridges MAY support the following IS-IS features for the 394 computation of explicit trees. The Extended IS Reachability TLV 395 (type 22) specified in [RFC5305] provides the following link 396 attribute IS-IS sub-TLVs: 398 o Administrative Group (color, resource class) (sub-TLV type 3), 400 o Maximum Link Bandwidth (sub-TLV type 9), 402 o Maximum Reservable Link bandwidth (sub-TLV type 10), 404 o Unreserved Bandwidth (sub-TLV type 11), 406 o Traffic Engineering Default Metric (sub-TLV type 18). 408 When the Unreserved Bandwidth sub-TLV is used in a Layer 2 bridge 409 network, the priority value encoded in the sub-TLV provides the PCP, 410 i.e. identifies a traffic class (not a setup priority level). 412 Further attributes are provided by the IS-IS TE Metric Extension link 413 attribute sub-TLVs specified in [I-D.ietf-isis-te-metric-extensions]: 415 o Unidirectional Link Delay (sub-TLV type 33), 417 o Min/Max Unidirectional Link Delay (sub-TLV type 34), 419 o Unidirectional Delay Variation (sub-TLV type 35), 421 o Unidirectional Link Loss (sub-TLV type 36), 423 o Unidirectional Residual Bandwidth (sub-TLV type 37), 425 o Unidirectional Available Bandwidth (sub-TLV type 38), 427 o Unidirectional Utilized Bandwidth (sub-TLV type 39). 429 The Shared Risk Link Group (SRLG) information provided by the SRLG 430 TLV (type 138) [RFC5307] MAY be also used. In order to indicate that 431 the interface is unnumbered in this case, the corresponding flag 432 takes value 0. The Link Local Identifier is an Extended Local 433 Circuit Identifier and the Link Remote Identifier is a Neighbor 434 Extended Local Circuit ID. 436 5. Explicit ECT Algorithms 438 The exact IS-IS control mode of operation MUST be selected for a VLAN 439 by associating its Base VID with the appropriate ECT Algorithm in the 440 SPB Base VLAN-Identifiers sub-TLV [RFC6329], in addition to 441 allocating the Base VID to IS-IS control. There are five distinct 442 ECT Algorithms for the five explicit path control modes. The 443 operation details of the explicit ECT Algorithms and their 444 configuration is specified by IEEE 802.1Qca, a high level overview is 445 given here. An ECT Algorithm value consists of the IEEE 802.1 OUI 446 (Organizationally Unique Identifier) value 00-80-C2 concatenated with 447 an index [RFC6329]. 449 The Strict Tree (ST) ECT Algorithm MUST be used for a strict explicit 450 tree. A strict ET is static as no other entity can update it but the 451 owner PCE. In case of a topology change, it is the task of the owner 452 PCE to detect the topology change, e.g. based on the changes in the 453 LSDB, and to update the strict trees if needed. That is, the owner 454 PCE computes the new tree, assembles its descriptor (Section 6.1), 455 and then instructs IS-IS PCR to install it. The value for the ST ECT 456 algorithm is 00-80-C2-17. 458 The Loose Tree (LT) ECT Algorithm MAY be also supported. It is used 459 for a single loose explicit tree. The path for loose hops is 460 determined by the BLCE of the bridges; therefore, the Topology sub- 461 TLV (Section 6.1) specifying the tree MUST indicate which hop is the 462 root of the tree. The loose hops are maintained by IS-IS, i.e. 463 restored upon a topology change if a loop-free path is available. If 464 the tree computed by the BLCE visits the same bridge twice (implying 465 that a loop or hairpin has been created), then that loop or hairpin 466 MUST be pruned from the tree even if it contains a hop specified by 467 the Topology sub-TLV. It is a constraint if a bridge is not to be 468 included, which can be specified by the Exclude flag of a Hop sub-TLV 469 (Section 6.2) conveyed by the Topology sub-TLV specifying the tree. 470 The range of values for the LT ECT Algorithms is 471 00-80-C2-21...00-80-C2-30. 473 The Loose Tree Set (LTS) ECT Algorithm MAY be also supported. It is 474 used if connectivity among the Edge Bridges specified by the Topology 475 sub-TLV (Section 6.1) is to be provided by a set of loose trees such 476 that one tree is rooted at each Edge Bridge. The BLCE of the bridges 477 compute the loose trees, which are maintained by IS-IS, i.e. restored 478 upon a topology change. One constraint can be to avoid some bridges 479 in these trees, which can be specified by the Exclude flag (item c.6. 480 in Section 6.2). Further constraints can be specified by the 481 Topology sub-TLV. The range of values for the LT ECT Algorithms is 482 00-80-C2-31...00-80-C2-40. 484 The LT and LTS ECT Algorithms use the shortest paths after pruning 485 the topology according to the constraint(s) if any. The shortest 486 path tie-breaking specified by Section 12 of [RFC6329] is applied 487 (see also subclauses 28.5 - 28.8 of [IEEE8021aq]), that's why range 488 of values are associated with the LT and LTS ECT Algorithms. In case 489 of the LT ECT Algorithm, the indexes are 0x21...0x30, and ECT- 490 MASK{index-0x20} is applied to retrieve the ECT-MASK of Section 12 of 491 [RFC6329]. In case of the LTS ECT Algorithm, the indexes are 492 0x31...0x40, and ECT-MASK{index-0x30} is applied to retrieve the ECT- 493 MASK for shortest path tie-breaking. 495 The MRT ECT Algorithm MAY be also supported. It is used for the 496 establishment and maintenance of MRTs in a distributed fashion. The 497 MRT Lowpoint Algorithm specified by 498 [I-D.ietf-rtgwg-mrt-frr-algorithm] MUST be used for the computation 499 of MRTs. The MRT Lowpoint Algorithm first computes the GADAG then 500 produces two MRTs for each MRT Root: MRT-Blue and MRT-Red. If the 501 level of redundancy provided by each bridge being an MRT Root is not 502 required, then the MRT Roots can be specified by a Topology sub-TLV 503 (Section 6.1). Both the GADAG and the MRT computation steps are 504 performed distributed, i.e. by each bridge. The value for the MRT 505 ECT algorithm is 00-80-C2-18. 507 The MRT GADAG (MRTG) ECT Algorithm MAY be also supported. It splits 508 the computation into two. As the GADAG is identical for each MRT 509 within a domain, it is computed by a single entity, which is the 510 GADAG Computer. The GADAG is then described in a Topology sub-TLV 511 (Section 6.1), which is flooded in the domain. The bridges then 512 compute the MRTs for the MRT Roots based on the GADAG received. 513 Section 7 provides more details on the description of the GADAG. The 514 value for the MRTG ECT algorithm is 00-80-C2-19. 516 MRTs are loose trees as bridges are involved in their computation and 517 restoration. Thus both the MRT and the MRTG ECT Algorithms provide a 518 set of loose trees: two MRTs for each MRT Root. 520 The SPB Link Metric sub-TLV [RFC6329] specifies the metric of each 521 link for IS-IS PCR if the LT, the LTS, the MRT, or the MRTG ECT 522 Algorithm is used. If the SPB Link Metric values advertised by 523 different ends of an adjacency are different, then the maximum value 524 MUST be used. 526 6. IS-IS PCR sub-TLVs 528 The following sub-TLVs are specified for IS-IS PCR. The Topology 529 sub-TLV MUST be carried in an MT-Capability TLV, the rest of the sub- 530 TLVs are conveyed by Topology sub-TLV. 532 6.1. Topology sub-TLV 534 The variable length Topology sub-TLV MUST be used to describe an 535 explicit tree. The Topology sub-TLV MAY be also used for describing 536 a Generalized Almost Directed Acyclic Graph (GADAG) as explained in 537 Section 7 in detail. The Topology sub-TLV MUST be carried in an MT- 538 Capability TLV (type 144) [RFC6329] in a Link State PDU. A Topology 539 sub-TLV specifying an explicit tree conveys one or more Base VIDs, 540 two or more Hop sub-TLVs (Section 6.2). A Topology sub-TLV 541 describing a loose tree MAY also convey further sub-TLVs to specify 542 constraints. Figure 1 shows the format of the Topology sub-TLV. 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+ 547 | Type | (1 byte) 548 +-+-+-+-+-+-+-+-+ 549 | Length | (1 byte) 550 +-+-+-+-+-+-+-+-+ 551 | Num Base VIDs | (1 byte) 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Res | Base VID 1 (12 bits) | (0 or 2 bytes) 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 ................. 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Res | Base VID n (12 bits) | (0 or 2 bytes) 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | sub-TLV 1 (variable) | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 ................. 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | sub-TLV m (variable) | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 1: Topology sub-TLV 568 The parameters of explicit trees are encoded by the Topology sub-TLV 569 as follows: 571 a. Type (8 bits): The type of the sub-TLV, its value is 21. 573 b. Length (8 bits): The total number of bytes contained in the Value 574 field. 576 c. Number of Base VIDs (8 bits): The number of Base VIDs carried in 577 the Topology sub-TLV. Its minimum value is 1 if the Topology 578 sub-TLV specifies one or more explicit trees. Its value can be 0 579 if the Topology sub-TLV specifies a GADAG. 581 d. Reserved (Res) (4 bits): The reserved bits take value 0. 583 e. Base VID (12 bits): The Base VID parameter provides the Base VID 584 of the VLAN that is associated with the explicit tree. Multiple 585 Base VIDs can be associated with the same explicit tree. In 586 addition to the Base VID, some of the explicit ECT Algorithms 587 (Section 5) require further VIDs which are associated with the 588 VLAN via the SPB Instance sub-TLV [RFC6329]. A Topology sub-TLV 589 specifying a GADAG can have zero Base VID parameters. In this 590 case, the given GADAG MUST be applied for each VLAN associated 591 with the MRTG ECT Algorithm (Section 5). 593 f. sub TLVs: The rest conveys further sub-TLVs that specify the hops 594 of the topology and can also specify constraints as described in 595 the following. 597 A topology is specified by a list of Hop sub-TLVs (Section 6.2), and 598 a hop is specified by an IS-IS System ID. An ill-formed Topology 599 sub-TLV, e.g. specifying an invalid or inconsistent tree is ignored, 600 no tree is installed but a management report is generated. 602 The Topology sub-TLV specifies a strict tree by decomposing the tree 603 to branches. Each branch is a point-to-point path specified by an 604 ordered list of hops where the end of each branch is a leaf. Each 605 element of a branch is the direct link between adjacent neighbor 606 bridges whose Hop sub-TLV is next to each other in the Topology sub- 607 TLV. The first hop of the Topology sub-TLV is the root, hence, the 608 first branch originates from the root. The rest of the branches fork 609 from another branch. The first hop of a branch is a bridge that is 610 already part of a former branch and the last hop is a leaf bridge. 611 Therefore, the hop after a leaf hop is the beginning of a new branch, 612 if any. A hop of a branch is created if and only if the bridge 613 specified for that hop is directly connected to the preceding bridge 614 of the same branch. The first branch MUST begin with the root and 615 after that the order of the branches does not matter within the 616 Topology sub-TLV. Figure 2 shows an example strict tree and its 617 description. 619 +-----------+ 620 | A | 621 +-----------+ 622 | I | 623 +-----------+ 624 | H | 625 [B]---[A]---[I] +-----------+ 626 | | | G | 627 | | +-----------+ 628 | | | E | 629 [C]---[F] [H] +-----------+ 630 | | | A | 631 | | +-----------+ 632 | | | B | 633 [D] [E]---[G] +-----------+ 634 | C | 635 +-----------+ 636 | D | 637 +-----------+ 638 | C | 639 +-----------+ 640 | F | 641 +-----------+ 643 Figure 2: A strict tree and its description; root = Node A 645 The Topology sub-TLV of a loose tree does not provide any path or 646 path segment, but the hops which are to participate. The root MUST 647 be the first hop. The leaves of a single loose tree MUST be also 648 specified. Hop sub-TLVs can be included in a Topology sub-TLV to 649 specify bridges that have to be avoided. If the Topology sub-TLV 650 only specifies a single leaf, then one or more transit hops can be 651 specified by the Topology sub-TLV to direct the path along a sequence 652 of bridges, specified by the order of hops. If bridges whose 653 respective Hop sub-TLVs are adjacent to each other in the Topology 654 sub-TLV but are not topology neighbors, then it is a loose hop. If a 655 Topology sub-TLV conveys one or more loose hops, then that sub-TLV 656 defines a loose explicit tree and each hop is considered as a loose 657 hop. The path of a loose hop MUST be pruned from the tree if the 658 path would create a loop or hairpin. 660 If the Base VIDs of the Topology sub-TLV are associated with the LTS 661 ECT Algorithm or the MRT ECT Algorithm, then the Hop sub-TLVs 662 conveyed by the Topology sub-TLV belong to Edge Bridges or bridges to 663 be excluded. The BLCEs compute the loose trees, e.g. MRTs, such 664 that they span the Edge Bridges and are rooted at an Edge Bridge. 666 The Topology sub-TLV specifies a GADAG if the Base VIDs conveyed by 667 the Topology sub-TLV are associated with the MRTG ECT Algorithm. 668 Section 7 provides the details on the description of a GADAG by a 669 Topology sub-TLV. 671 Each Edge Bridge of an explicit tree MUST be always specified in the 672 Topology sub-TLV by the inclusion of the Hop sub-TLVs corresponding 673 to the Edge Bridges. The Edge Bridges of a tree are identified by 674 setting the Edge Bridge flag (item c.3. in Section 6.2) in the 675 appropriate Hop sub-TLVs. 677 If the explicit tree is loose, then the Topology sub-TLV MAY convey 678 further sub-TLVs to specify constraints, e.g. an Administrative Group 679 sub-TLV [RFC5305] or a Bandwidth Constraint (Section 6.3). If it is 680 not possible to meet the constraint(s) specified by the Topology sub- 681 TLV, then no tree is installed but a management report is generated. 683 IS-IS PCR MAY be used for recording bandwidth assignment. In that 684 case, the Topology sub-TLV conveys Bandwidth Assignment sub-TLV 685 (Section 6.4) and it MAY also convey Timestamp sub-TLV (Section 6.5). 686 If assignment of the bandwidth indicated by the Bandwidth Assignment 687 sub-TLV of the Topology sub-TLV would result in overbooking any link 688 of the explicit tree, then bandwidth assignment MUST NOT be performed 689 and a management report is generated. If the Topology sub-TLV 690 specifies a new valid explicit tree, then the tree is installed 691 without bandwidth assignment. 693 6.2. Hop sub-TLV 695 The Hop sub-TLV MUST be used to specify a hop of a topology. Each 696 Hop sub-TLV conveys an IS-IS System ID, which specifies a hop. A Hop 697 sub-TLV is conveyed by a Topology sub-TLV (Section 6.1). A strict 698 explicit tree is decomposed to branches where each branch is a point- 699 to-point path specified by an ordered list of Hop sub-TLVs as 700 specified in Section 6.1. A hop of a branch is created if and only 701 if the bridge specified for that hop is directly connected to the 702 preceding bridge in the path. That is, a point-to-point LAN is 703 identified by the two bridges it interconnects; and the LAN is part 704 of the strict tree if and only if the Hop sub-TLVs of the two bridges 705 are next to each other in the Topology sub-TLV. A Hop sub-TLV can 706 convey a Circuit ID in order to distinguish multiple links between 707 adjacent neighbor bridges. A Hop sub-TLV also specifies the role of 708 a bridge, e.g. if it is the root or an Edge Bridge. The Topology 709 sub-TLV of a loose tree only comprises the Hop sub-TLV of the bridges 710 that have special role in the tree. The Hop sub-TLV MAY also specify 711 a delay budget for a loose hop. 713 By default, the Edge Bridges both transmit and receive with respect 714 to each VID associated with an explicit tree, except for an LTS 715 (Section 5) associated with a learning VLAN, which uses a 716 unidirectional VID per bridge. The Hop sub-TLV allows different 717 configuration by means of the Transmit (T) and Receive (R) flags 718 conveyed in the sub-TLV. The VID and its T/R flags are only present 719 in the Hop sub-TLV if the behavior of the Edge Bridges differs from 720 the default. 722 Figure 3 shows the format of the variable length Hop sub-TLV, which 723 MUST be conveyed by a Topology sub-TLV (Section 6.1). 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+ 728 | Type | (1 byte) 729 +-+-+-+-+-+-+-+-+ 730 | Length | (1 byte) 731 +-+-+-+-+-+-+-+-+ 732 |C|V|B|R|L|E|Res| (1 byte) 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | System ID | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | System ID | (6 bytes) 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Extended Local Circuit ID (0 or 4 bytes) | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Num of VIDs | (0 or 1 byte) 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 |T|R|Res| VID 1 (12 bits) | (0 or 2 bytes) 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 ................. 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 |T|R|Res| VID n (12 bits) | (0 or 2 bytes) 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Delay Constraint | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Delay Constraint | (0 or 6 bytes) 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Figure 3: Hop sub-TLV 755 The parameters of a hop are encoded as follows: 757 a. Type (8 bits): The type of the sub-TLV, its value is 22. 759 b. Length (8 bits): The total number of bytes contained in the Value 760 field. 762 c. Hop Flags (8 bits): The Hop sub-TLV conveys six one-bit flags. 763 The Circuit and the VID flags influence the length of the Hop 764 sub-TLV. Two bits are reserved for future use, transmitted as 0 765 and ignored on receipt. 767 1. Circuit (C) flag (1 bit): The Circuit flag is a one-bit flag 768 to indicate whether or not the Extended Local Circuit ID 769 parameter is present. If the flag is set, then an Extended 770 Local Circuit ID is also included in the Hop sub-TLV. 772 2. VID (V) flag (1 bit): The VID flag is a one-bit flag to 773 indicate whether or not one or more VIDs are conveyed by the 774 Hop sub-TLV. If the flag is set, then the Number of VIDs 775 parameter is present and indicates how many VIDs are conveyed 776 by the Hop sub-TLV. If the VID flag is reset, then neither 777 the Number of VIDs parameter nor VIDs are present in the Hop 778 sub-TLV. 780 3. Edge Bridge (B) flag (1 bit): The Edge Bridge flag is a one- 781 bit flag to indicate whether or not the given System is an 782 Edge Bridge, i.e. transmitter and/or receiver. If the System 783 is an Edge Bridge, then the Edge Bridge flag MUST be set. 784 The Edge Bridge flag indicates that FDB entries have to be 785 installed for the given hop as specified by the SPBV MAC 786 address sub-TLV or SPBM Service Identifier and Unicast 787 Address sub-TLV of the hop. 789 4. Root (R) flag (1 bit): The Root flag is a one-bit flag to 790 indicate whether or not the given System is a root of the 791 explicit tree specified by the Topology sub-TLV. If the 792 System is a root of a tree, then the Root flag MUST be set. 793 If the Topology sub-TLV specifies a single tree, i.e. the 794 Base VIDs conveyed by the Topology sub-TLV are associated 795 with either the ST ECT Algorithm or the LT ECT Algorithm 796 (Section 5), then the Root flag is only set for one of the 797 Systems conveyed by the Topology sub-TLV. Furthermore, the 798 first Hop sub-TLV of the Topology sub-TLV conveys the System 799 that is the root of the tree. If the Topology sub-TLV 800 specifies a Loose Tree Set, i.e. the Base VIDs conveyed by 801 the Topology sub-TLV are associated with the LTS ECT 802 Algorithm (Section 5), then the Root flag is set for each 803 Edge Bridge as each of them roots a tree. If the Topology 804 sub-TLV is used for MRT operations, i.e. the Base VIDs 805 conveyed by the Topology sub-TLV are associated with either 806 the MRT ECT Algorithm or the MRTG ECT Algorithm (Section 5), 807 then the Root flag is set for each MRT Root. If no MRT Root 808 is specified by a Topology sub-TLV specifying a GADAG, then 809 each SPT Root is an MRT Root as well. If the Base VIDs 810 conveyed by the Topology sub-TLV are associated with the MRTG 811 ECT Algorithm (Section 5), then the Topology sub-TLV 812 specifies a GADAG and the very first Hop sub-TLV specifies 813 the GADAG Root. There is no flag for indicating the GADAG 814 Root. 816 5. Leaf (L) flag (1 bit): The Leaf flag is a one-bit flag to 817 indicate whether or not the given System is a leaf of the 818 explicit tree specified by the Topology sub-TLV. If the 819 System is a leaf, then the Leaf flag MUST be set. The Leaf 820 flag is only used to mark a leaf of a tree if the Topology 821 sub-TLV specifies a single tree. The Leaf flag MUST be used 822 to indicate the end of a topology block if the Topology sub- 823 TLV specifies a GADAG, see Section 7. 825 6. Exclude (E) flag (1 bit): The Exclude flag is a one-bit flag 826 to indicate if the given System MUST be excluded from the 827 topology. The Exclude flag and the Root flag cannot be set 828 for a given hop at the same time. 830 7. Reserved (Res) (2 bits): The reserved bits take value 0. 832 d. System ID (48 bits): The 6-byte IS-IS System Identifier of the 833 bridge that the Hop sub-TLV refers to. 835 e. Extended Local Circuit ID (32 bits): The Extended Local Circuit 836 ID [RFC5303] parameter is not necessarily present in the Hop sub- 837 TLV. Its presence is indicated by the Circuit flag. Parallel 838 links corresponding to different IS-IS adjacencies between a pair 839 of neighbor bridges can be distinguished by means of the Extended 840 Local Circuit ID. The Extended Local Circuit ID is conveyed by 841 the Hop sub-TLV specifying the bridge nearer to the root of the 842 tree, and identifies a circuit that attaches the given bridge to 843 its neighbor cited by the next Hop sub-TLV of the Topology sub- 844 TLV. The Extended Local Circuit ID can only be used in strict 845 trees. 847 f. Number of VIDs (8 bits): The Number of VIDs parameter is not 848 present if the Hop sub-TLV does not convey VIDs, which is 849 indicated by the VID flag. 851 g. VID and its T/R flags (14 bits): The VID and its T/R flags are 852 only present in the Hop sub-TLV if the given bridge is an Edge 853 Bridge and it behaves differently from the default with respect 854 to that particular VID. 856 1. T flag (1 bit): This is the Transmit allowed flag for the VID 857 following the flag. 859 2. R flag (1 bit): This is the Receive allowed flag for the VID 860 following the flag. 862 3. Reserved (Res) (2 bits): The reserved bits take value 0. 864 4. VID (12 bits): A VID. 866 h. Delay Constraint (48 bits): The last six bytes specify a delay 867 constraint if they convey a Unidirectional Link Delay sub-TLV 868 [I-D.ietf-isis-te-metric-extensions]. The delay constraint MAY 869 be used in a Topology sub-TLV that specifies a single loose tree, 870 i.e. the Base VIDs are associated with the LT ECT Algorithm 871 (Section 5). If delay constraint is applied, then the loose hop 872 MUST fit in the delay budget specified by the Delay parameter of 873 the Unidirectional Link Delay sub-TLV conveyed by the Hop sub- 874 TLV. If the Topology sub-TLV specifies a single leaf, then the 875 path between the preceding Hop sub-TLV and the current Hop sub- 876 TLV MUST meet the delay budget. If the Topology sub-TLV 877 specifies multiple leaves, then the path between the root and the 878 current Hop sub-TLV MUST to meet the delay budget. If the tree 879 is used as a reverse congruent tree, then the delay constraint 880 applies in both directions. If the tree is used as a directed 881 tree, then the delay constraint applies in the direction of the 882 tree. If it is not possible to meet the delay constraint 883 specified by the Topology sub-TLV, then no tree is installed but 884 a management report is generated. 886 6.3. Bandwidth Constraint sub-TLV 888 The Bandwidth Constraint sub-TLV MAY be included in a Topology sub- 889 TLV (Section 6.1) in order to specify how much available bandwidth is 890 to be provided by the constrained tree. Each loose hop MUST meet the 891 bandwidth constraint. The bandwidth value of the constraint is a 892 total value or it only refers to a single PCP as specified by the 893 sub-TLV. Figure 4 shows the format of the Bandwidth Constraint sub- 894 TLV. 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+ 899 | Type | (1 byte) 900 +-+-+-+-+-+-+-+-+ 901 | Length | (1 byte) 902 +-+-+-+-+-+-+-+-+ 903 | PCP |D|P| Res | (1 byte) 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Available Bandwidth (4 bytes) | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Figure 4: Bandwidth Constraint sub-TLV 910 The parameters of the bandwidth constraint are encoded as follows: 912 a. Type (8 bits): The type of the sub-TLV, its value is 23. 914 b. Length (8 bits): The total number of bytes contained in the Value 915 field. The value of the Length field is 5 bytes. 917 c. PCP (4 bits): The Priority Code Point (PCP) parameter identifies 918 the traffic class the Available Bandwidth parameter refers to, if 919 any. 921 d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) 922 parameter. If the DEI parameter is clear, then the bandwidth 923 constraint refers to committed information rate. If the DEI 924 parameter is set, then the bandwidth constraint refers to peak 925 information rate. 927 e. PCP (P) flag (1 bit): If this flag is set, then the PCP parameter 928 is taken into account. 930 f. Reserved (Res) (3 bits): The reserved bits take value 0. 932 g. Available Bandwidth (32 bits): The Available Bandwidth is 933 specific to the traffic class identified by the PCP parameter if 934 the PCP flag is set, otherwise, it is total bandwidth. In-line 935 with the bandwidth parameters specified in [RFC5305], the 936 Available Bandwidth is encoded as a 32-bit IEEE floating point 937 number, and the units are bytes (not bits!) per second. When the 938 Unreserved Bandwidth sub-TLV (sub-TLV type 11 specified by 939 [RFC5305]) is used in a Layer 2 bridge network, the priority 940 value encoded in the Unreserved Bandwidth sub-TLV provides the 941 PCP, i.e. identifies a traffic class (not a setup priority 942 level). Thus, the Available Bandwidth of a traffic class is 943 easily comparable with the Unreserved Bandwidth stored in the TED 944 for the given traffic class. The bandwidth constraint applies 945 for both directions in case of symmetric explicit trees. 946 Nevertheless, a VID associated with an explicit tree can be made 947 unidirectional by means of the T/R flags belonging to the VID in 948 the Hop sub-TLV (item g. in Section 6.2) of the Edge Bridges. If 949 all the VIDs of the Topology sub-TLV (Section 6.1) are 950 unidirectional and all belong to the traffic class identified by 951 the PCP parameter of the Bandwidth Constraint sub-TLV, then it is 952 enough to meet the bandwidth constraint in the direction applied 953 for those VIDs. 955 6.4. Bandwidth Assignment sub-TLV 957 IS-IS PCR MAY be used for recording bandwidth assignment for 958 explicitly placed data traffic in a domain if MSRP is not used within 959 the domain. If MSRP is used in a domain, then only MSRP performs 960 reservations and IS-IS does not. Both MSRP and IS-IS MUST NOT be 961 used to make bandwidth assignments in the same domain. 963 The Bandwidth Assignment sub-TLV can be used to define the amount of 964 bandwidth whose assignment is to be recorded by IS-IS PCR at each hop 965 of the explicit tree described by the corresponding Topology sub-TLV 966 (Section 6.1). The Bandwidth Assignment sub-TLV is used by IS-IS PCR 967 for the recording of bandwidth assignment for a traffic class 968 identified by the PCP parameter of a VLAN tag. If precedence order 969 has to be determined among bandwidth assignments in a domain with 970 multiple PCEs, then IS-IS PCR does it as described below. If the 971 bandwidth assignment specified by the Topology sub-TLV is not 972 possible, e.g. due to overbooking, then bandwidth recording MUST NOT 973 be performed and a management report is generated. If the Topology 974 sub-TLV specifies a new valid explicit tree, then the tree is 975 installed without bandwidth assignment. The Bandwidth Assignment 976 sub-TLV is conveyed by a Topology sub-TLV (Section 6.1). Figure 5 977 shows the format of the Bandwidth Assignment sub-TLV. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+ 982 | Type | (1 byte) 983 +-+-+-+-+-+-+-+-+ 984 | Length | (1 byte) 985 +-+-+-+-+-+-+-+-+ 986 | PCP |D| Imp |R| (1 byte) 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Bandwidth (4 bytes) | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 Figure 5: Bandwidth Assignment sub-TLV 993 The parameters of the bandwidth assignment are encoded as follows: 995 a. Type (8 bits): The type of the sub-TLV, its value is 24. 997 b. Length (8 bits): The total number of bytes contained in the Value 998 field. The value of the Length field is 5 bytes. 1000 c. PCP (3 bits): The PCP parameter identifies the traffic class the 1001 bandwidth to be assigned for. 1003 d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) 1004 parameter. If the DEI parameter is clear, then the bandwidth 1005 assignment is performed for providing committed information rate. 1006 If the DEI parameter is set, then the bandwidth assignment is 1007 performed for providing peak information rate. 1009 e. Importance (Imp) (3 bits): This is the Importance parameter for 1010 determining precedence order among bandwidth assignments within a 1011 PCP as described below. Lower numerical value indicates more 1012 important bandwidth assignment within a PCP. The default value 1013 of the Importance parameter is 7. 1015 f. Reserved (R) (1 bit): The reserved bit takes value 0. 1017 g. Bandwidth (32 bits): This is the amount of bandwidth to be 1018 assigned for the traffic class identified by the PCP parameter. 1019 In-line with the bandwidth values specified in [RFC5305], the 1020 Bandwidth parameter is encoded as a 32-bit IEEE floating point 1021 number, and the units are bytes (not bits!) per second. The 1022 bandwidth assignment applies for both directions in case of 1023 symmetric explicit trees. 1025 The PCEs are collectively responsible for making a consistent set of 1026 bandwidth assignments when IS-IS PCR is used for recording bandwidth 1027 allocations. If despite of that, precedence ordering is required 1028 among bandwidth assignments, then ordering based on the following 1029 parameters MUST be applied: 1031 1. PCP parameter of Bandwidth Assignment sub-TLV, 1033 2. Importance parameter of Bandwidth Assignment sub-TLV, 1035 3. Timestamp sub-TLV (if present in the Topology sub-TLV). 1037 A bandwidth assignment takes precedence if it has higher PCP, or 1038 higher Importance within a PCP, or earlier timestamp in case of equal 1039 Importance within a PCP. A bandwidth assignment associated with a 1040 timestamp takes precedence over a bandwidth assignment without 1041 timestamp when PCP and Importance of different bandwidth assignments 1042 are both equal. If resolution is not possible based on the above 1043 parameters or they are not available, e.g. each bandwidth assignment 1044 lacks timestamp or the precedence order has to be determined for the 1045 use of a VID, then the item is granted to the PCE whose LSP has the 1046 numerically least LSP ID. 1048 6.5. Timestamp sub-TLV 1050 The Timestamp sub-TLV MAY be included in a Topology sub-TLV 1051 (Section 6.1) in order to provide precedence order among equally 1052 important bandwidth assignments within a PCP as described in 1053 Section 6.4. Figure 6 shows the format of the Timestamp sub-TLV. 1055 0 1 2 3 1056 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 1057 +-+-+-+-+-+-+-+-+ 1058 | Type | (1 byte) 1059 +-+-+-+-+-+-+-+-+ 1060 | Length | (1 byte) 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Time (4 bytes) | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Figure 6: Timestamp sub-TLV 1067 The timestamp represents a positive time with respect to the 1068 Precision Time Protocol (PTP) epoch and it is encoded as follows: 1070 a. Type (8 bits): The type of the sub-TLV, its value is 25. 1072 b. Length (8 bits): The total number of bytes contained in the Value 1073 field. The value of the Length field is 4 bytes. 1075 c. Time (32 bits): This is the time in units of seconds with respect 1076 to the PTP epoch. 1078 The Timestamp sub-TLV carries the seconds portion of PTP as specified 1079 by [IEEE1588]. The epoch is 1970-01-01 00:00:00 TAI (i.e., the PTP 1080 time does not include leap seconds). 1082 7. MRT-FRR Application 1084 The application of MRT by [IEEE8021Qca] is discussed in detail in 1085 [I-D.bowers-rtgwg-mrt-applicability-to-8021qca]. This section 1086 describes some special considerations for the use of the MRT Lowpoint 1087 Algorithm [I-D.ietf-rtgwg-mrt-frr-algorithm], which are applicable 1088 both to the MRT ECT Algorithm and the MRTG ECT Algorithm. This 1089 section also explains details related to the MRTG ECT Algorithm and 1090 the application of the Topology sub-TLV in particular. 1092 The SPB Link Metric sub-TLV [RFC6329] specifies the metric of each 1093 link for IS-IS PCR including the MRT Algorithms. If the SPB Link 1094 Metric values advertised by different ends of an adjacency are 1095 different, then the maximum value MUST be used. If equal cost 1096 (sub)paths are found during the MRT computation, then the default 1097 tie-breaking specified by Section 11 of [RFC6329] MUST be used, which 1098 is based on the lower Bridge ID. (The BridgeID is an 8-byte quantity 1099 whose upper 2 bytes are the node's BridgePriority and lower 6 bytes 1100 are the node's SYSID.) Note also that if MRTs are used for source 1101 specific multicast (see [IEEE8021Qca] for details), then the bridges 1102 have to compute the MRTs of the other bridges in addition to their 1103 own one in order to be able to install the appropriated FDB entries. 1104 (This is similar to the need for all pairs shortest path computation 1105 instead of Dijkstra for source specific shortest path multicast 1106 trees.) 1108 The GADAG is identical for all the MRTs within a network domain, as a 1109 consequence of the use of the MRT Lowpoint Algorithm 1110 [I-D.ietf-rtgwg-mrt-frr-algorithm]. Therefore, it is beneficial to 1111 compute the GADAG by a single entity, which is referred to as the 1112 GADAG Computer and is either a PCE or the GADAG Root. If the MRTG 1113 ECT Algorithm is applied, then the GADAG MUST be only computed by the 1114 GADAG Computer, which then MUST flood the descriptor Topology sub-TLV 1115 of the GADAG. The bridges then compute the MRTs based on the 1116 received GADAG. 1118 The GADAG computation requires the selection of the GADAG Root. The 1119 bridge with the best Bridge Identifier MUST be selected as the GADAG 1120 Root, where the numerically lower value indicates the better 1121 identifier. The Bridge Priority component of the Bridge Identifier 1122 allows the configuration of the GADAG Root by management action. The 1123 Bridge Priority is conveyed by the SPB Instance sub-TLV [RFC6329]. 1125 The GADAG Computer MUST perform the GADAG computation as specified by 1126 the MRT Lowpoint Algorithm [I-D.ietf-rtgwg-mrt-frr-algorithm]. The 1127 GADAG Computer then MUST encode the GADAG in a Topology sub-TLV 1128 (Section 6.1), which is then flooded throughout the domain. A GADAG 1129 is encoded in a Topology sub-TLV by means of directed ear 1130 decomposition as follows. A directed ear is a directed point-to- 1131 point path whose end points can coincide but no other element of the 1132 path is repeated in the ear. Each ear is specified by an ordered 1133 list of hops such that the order of hops is according to the 1134 direction of the arcs in the GADAG. There are no leaves in a GADAG, 1135 hence, the Leaf flag (item c.5. in Section 6.2) is used to mark the 1136 end of a topology block. (A GADAG with multiple blocks is 1137 illustrated in Figure 8.) The sequence of ears in the Topology sub- 1138 TLV is such that the end points of an ear belong to preceding ears. 1139 The GADAG Root is not marked by any flag but the GADAG Root is the 1140 first hop in the Topology sub-TLV, correspondingly the first ear 1141 starts and ends with the GADAG Root. MRT Roots MUST be marked by the 1142 Root flag (item c.4. in Section 6.2) and all other Edge Bridges are 1143 leaves of the given MRTs. If no MRT Root is specified, then each SPT 1144 Root is also an MRT Root. 1146 Figure 7 shows an example GADAG. The figure also illustrates the 1147 description of the GADAG, it shows the System ID parameter of the Hop 1148 sub-TLV (Section 6.2) and the order of hops in the Topology sub-TLV 1149 (Section 6.1). 1151 Leaf 1152 Hop flag 1153 +-----------+---+ 1154 | A | | 1155 +-----------+---+ 1156 | B | | 1157 +-----------+---+ 1158 | C | | 1159 +-----------+---+ 1160 | F | | 1161 [B]<---[A]<---[I] +-----------+---+ 1162 | ^ ^ | A | | 1163 | | | +-----------+---+ 1164 V | | | C | | 1165 [C]--->[F]--->[H] +-----------+---+ 1166 | ^ | D | | 1167 | | +-----------+---+ 1168 V | | E | | 1169 [D]--->[E]--->[G] +-----------+---+ 1170 | G | | 1171 +-----------+---+ 1172 | H | | 1173 +-----------+---+ 1174 | I | | 1175 +-----------+---+ 1176 | A | | 1177 +-----------+---+ 1178 | F | | 1179 +-----------+---+ 1180 | H | X | 1181 +-----------+---+ 1183 Figure 7: A GADAG and its description; GADAG Root = Node A 1185 A topology can comprise multiple blocks, like the one illustrated in 1186 Figure 8(a). This example topology comprises four blocks as each 1187 cut-link is a block. A-B-C-D-E-F is a block, D-G is another block, 1188 G-H, and H-J-K are further blocks. A GADAG for this topology is 1189 shown in Figure 8(b). Note that two arcs with opposite direction 1190 represent a cut-link in a GADAG, see e.g. the cut-link between D and 1191 G. The encoding starts with the block (ADAG) involving the GADAG 1192 Root as illustrated in Figure 8. The first hop in the Topology sub- 1193 TLV is the GADAG Root (node A in this example.) The ADAG of the 1194 first block is then described using the ear decomposition, as 1195 described above. In this example, the first block has been 1196 completely traversed at the second occurrence of node A in the GADAG 1197 descriptor. The end of a block is indicated by setting the Leaf flag 1198 for the last hop of the block, e.g. for the second occurrence of node 1199 A in the example GADAG descriptor. The next node that appears in the 1200 GADAG descriptor (D in this case) is the localroot for the nodes in 1201 the next block. Continuing this process, the Leaf flag is set for 1202 the third occurrence of D, the third occurrence of G, and the third 1203 occurrence of H, each indicating the end of a block. The first hop 1204 of the first block is the GADAG Root, the fist hop in the rest of the 1205 blocks is the localroot. The position of the set Leaf flags helps to 1206 determine the localroot, which is the next hop. In the example GADAG 1207 descriptor, one can determine that A is the localroot for B,C,D,E,F 1208 (and A is the GADAG Root). D is the localroot for G. G is the 1209 localroot for H. And H is the localroot for J and K. The GADAG Root 1210 is assigned a localroot of None. 1212 Block IDs are reconstructed while parsing a Topology sub-TLV 1213 specifying a GADAG. The current Block ID starts at 0 and is assigned 1214 to the GADAG Root. A node appearing in the GADAG descriptor without 1215 a previously-assigned Block ID value is assigned the current Block 1216 ID. And the current Block ID is incremented by 1 after processing 1217 the localroot of a block. Note that the localroot of a block will 1218 keep the Block ID of the first block in which it is assigned a Block 1219 ID. In the example in Figure 8, A has Block ID=0. B, C, D, E, and F 1220 have Block ID=1. G has Block ID=2. H has Block ID=3. J and K have 1221 Block ID=4. 1223 Leaf 1224 Hop flag 1225 [F]--[E] +--[K] +-----------+---+ 1226 | | | | | A | | 1227 | | | | +-----------+---+ 1228 [A] [D]--[G]--[H] | | B | | 1229 | | | | +-----------+---+ 1230 | | | | | C | | 1231 [B]--[C] +--[J] +-----------+---+ 1232 | D | | 1233 (a) topology +-----------+---+ 1234 | E | | 1235 +-----------+---+ 1236 | F | | 1237 +-----------+---+ 1238 | A | X | 1239 +-----------+---+ 1240 +-+ +-+ +-+ | D | | 1241 |F|<-|E| +--|K| +-----------+---+ 1242 +-+ +-+ | +-+ | G | | 1243 | ^ | ^ +-----------+---+ 1244 | | V | | D | X | 1245 V +-+ +-+ +-+ | +-----------+---+ 1246 +-+ | |->| |->| | | | G | | 1247 |A| |D| |G| |H| | +-----------+---+ 1248 +-+ | |<-| |<-| | | | H | | 1249 | +-+ +-+ +-+ | +-----------+---+ 1250 | ^ | | | G | X | 1251 V | | | +-----------+---+ 1252 +-+ +-+ | +-+ | H | | 1253 |B|->|C| +->|J| +-----------+---+ 1254 +-+ +-+ +-+ | J | | 1255 +-----------+---+ 1256 (b) GADAG | K | | 1257 +-----------+---+ 1258 | H | X | 1259 +-----------+---+ 1261 (c) GADAG descriptor 1263 Figure 8: A GADAG with cut-links and its description; GADAG Root = 1264 Node A 1266 8. Summary 1268 This document specifies IS-IS sub-TLVs for the control of explicit 1269 trees in Layer 2 networks. These sub-TLVs can be also used for the 1270 distribution of a centrally computed GADAG or MRTs if MFT-FRR is 1271 used. 1273 9. IANA Considerations 1275 This document defines the following IS-IS sub-TLVs within the MT- 1276 Capability TLV (type 144). They are listed in the IS-IS TLV 1277 codepoint registry. 1279 Type Description Length 1280 ---- ---------------------------- -------- 1281 21 Topology sub-TLV variable 1282 22 Hop sub-TLV variable 1283 23 Bandwidth Constraint sub-TLV 5 1284 24 Bandwidth Assignment sub-TLV 5 1285 25 Timestamp sub-TLV 4 1287 10. Security Considerations 1289 This document adds no additional security risks to IS-IS, nor does it 1290 provide any additional security for IS-IS when used in a configured 1291 environment or a single-operator domain such as a data center. IS-IS 1292 PCR is not for zero configuration environments. 1294 However, if IS-IS PCR is used to record bandwidth assignments in a 1295 network with multiple PCEs, then race conditions can appear and the 1296 precedence can be resolved by Importance parameter of the Bandwidth 1297 Assignment sub-TLV and the Time parameter of the Timestamp sub-TLV, 1298 especially if the different PCEs are administered by different 1299 entities. 1301 11. Acknowledgements 1303 The authors would like to thank Don Fedyk and Eric Gray for their 1304 comments and suggestions. 1306 12. References 1308 12.1. Normative References 1310 [I-D.ietf-isis-te-metric-extensions] 1311 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 1312 A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering 1313 (TE) Metric Extensions", draft-ietf-isis-te-metric- 1314 extensions-07 (work in progress), June 2015. 1316 [I-D.ietf-rtgwg-mrt-frr-algorithm] 1317 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 1318 Gopalan, "Algorithms for computing Maximally Redundant 1319 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 1320 algorithm-05 (work in progress), July 2015. 1322 [IEEE8021aq] 1323 IEEE 802.1, "IEEE 802.1aq: IEEE Standard for Local and 1324 metropolitan area networks - Media Access Control (MAC) 1325 Bridges and Virtual Bridged Local Area Networks - 1326 Amendment 20: Shortest Path Bridging", 2012, 1327 . 1330 [IEEE8021Qca] 1331 IEEE 802.1, "IEEE 802.1Qca Bridges and Bridged Networks - 1332 Amendment: Path Control and Reservation - Draft 2.1", 1333 (work in progress), June 24, 2015, 1334 . 1336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1337 Requirement Levels", BCP 14, RFC 2119, March 1997. 1339 [RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way 1340 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 1341 October 2008. 1343 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1344 Engineering", RFC 5305, October 2008. 1346 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1347 of Generalized Multi-Protocol Label Switching (GMPLS)", 1348 RFC 5307, October 2008. 1350 [RFC6329] Fedyk, D., Ashwood-Smith, P., Allan, D., Bragg, A., and P. 1351 Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq 1352 Shortest Path Bridging", RFC 6329, April 2012. 1354 12.2. Informative References 1356 [I-D.bowers-rtgwg-mrt-applicability-to-8021qca] 1357 Bowers, C. and J. Farkas, "Applicability of Maximally 1358 Redundant Trees to IEEE 802.1Qca Path Control and 1359 Reservation", draft-bowers-rtgwg-mrt-applicability-to- 1360 8021qca-01 (work in progress), July 2015. 1362 [I-D.ietf-rtgwg-mrt-frr-architecture] 1363 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 1364 A., Tantsura, J., and R. White, "An Architecture for IP/ 1365 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 1366 ietf-rtgwg-mrt-frr-architecture-06 (work in progress), 1367 July 2015. 1369 [IEEE1588] 1370 IEEE 1588, "IEEE 1588: IEEE Standard for a Precision Clock 1371 Synchronization Protocol for Networked Measurement and 1372 Control Systems", 2008, 1373 . 1376 [IEEE8021Q] 1377 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 1378 metropolitan area networks - Bridges and Bridged 1379 Networks", 2014, . 1382 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1383 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1385 Authors' Addresses 1387 Janos Farkas (editor) 1388 Ericsson 1389 Konyves Kalman krt. 11/B 1390 Budapest 1097 1391 Hungary 1393 Email: janos.farkas@ericsson.com 1395 Nigel Bragg 1396 Ciena 1397 43-51 Worship Street 1398 London EC2A 2DX 1399 UK 1401 Email: nbragg@ciena.com 1402 Paul Unbehagen Jr 1403 Avaya 1404 1300 W. 120th Avenue 1405 Westminster CO 80234 1406 USA 1408 Email: unbehagen@avaya.com 1410 Glenn Parsons 1411 Ericsson 1412 349 Terry Fox Drive 1413 Ottawa ON, K2K 2V6 1414 Canada 1416 Email: glenn.parsons@ericsson.com 1418 Peter Ashwood-Smith 1419 Huawei Technologies 1420 303 Terry Fox Drive, Suite 400 1421 Ottawa ON, K2K 3J1 1422 Canada 1424 Email: Peter.AshwoodSmith@huawei.com 1426 Chris Bowers 1427 Juniper Networks 1428 1194 N. Mathilda Ave. 1429 Sunnyvale, CA 94089 1430 US 1432 Email: cbowers@juniper.net