idnits 2.17.1 draft-farkas-isis-pcr-02.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 (March 9, 2015) is 3308 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 615, but not defined == Missing Reference: 'F' is mentioned on line 615, but not defined == Missing Reference: 'H' is mentioned on line 1227, but not defined == Missing Reference: 'D' is mentioned on line 1227, but not defined == Missing Reference: 'E' is mentioned on line 619, but not defined == Missing Reference: 'G' is mentioned on line 1227, but not defined == Missing Reference: 'A' is mentioned on line 1227, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-isis-te-metric-extensions-04 == Outdated reference: A later version (-09) exists of draft-ietf-rtgwg-mrt-frr-algorithm-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021Qca' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021aq' == Outdated reference: A later version (-01) exists of draft-bowers-rtgwg-mrt-applicability-to-8021qca-00 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-05 Summary: 0 errors (**), 0 flaws (~~), 12 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: September 10, 2015 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 March 9, 2015 16 IS-IS Path Computation and Reservation 17 draft-farkas-isis-pcr-02 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 September 10, 2015. 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 . . . . . . . . . . . . . . . . . . . . . 11 68 6.1. Topology sub-TLV . . . . . . . . . . . . . . . . . . . . 11 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 end points and the paths among the end points. If only the 184 end points are specified but the paths are not, then it is a loose 185 explicit tree. If the paths are also specified, then it is a 186 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 its endpoints, 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. a traffic end point, and no path or path segment is 332 specified between the bridges, which are therefore loose hops even if 333 traffic end points are adjacent neighbors. The special role of a hop 334 can be: traffic end point, root, leaf, a bridge to be avoided, or a 335 transit hop in case of a tree with a single leaf. The path for a 336 loose hop is determined by the Bridge Local Computation Engine (BLCE) 337 of the bridges. The shortest path is used for a loose hop unless 338 specified otherwise by the descriptor (Section 6.1) of the tree or by 339 the 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 There is no precedence order between Explicit Trees. Precedence 378 order among bandwidth assignments recorded by IS-IS PCR is specified 379 in Section 6.4. 381 If it is not possible to install an explicit tree, e.g. constraint(s) 382 cannot be met or the Topology sub-TLV is ill-formed, then no tree is 383 installed but a management report is generated. 385 The bridges MAY support the following IS-IS features for the 386 computation of explicit trees. The Extended IS Reachability TLV 387 (type 22) specified in [RFC5305] provides the following link 388 attribute IS-IS sub-TLVs: 390 o Administrative Group (color, resource class) (sub-TLV type 3), 392 o Maximum Link Bandwidth (sub-TLV type 9), 394 o Maximum Reservable Link bandwidth (sub-TLV type 10), 396 o Unreserved Bandwidth (sub-TLV type 11), 398 o Traffic Engineering Default Metric (sub-TLV type 18). 400 When the Unreserved Bandwidth sub-TLV is used in a Layer 2 bridge 401 network, the priority value encoded in the sub-TLV provides the PCP, 402 i.e. identifies a traffic class (not a setup priority level). 404 Further attributes are provided by the IS-IS TE Metric Extension link 405 attribute sub-TLVs specified in [I-D.ietf-isis-te-metric-extensions]: 407 o Unidirectional Link Delay, 409 o Min/Max Unidirectional Link Delay, 411 o Unidirectional Delay Variation, 413 o Unidirectional Link Loss, 415 o Unidirectional Residual Bandwidth, 417 o Unidirectional Available Bandwidth, 419 o Unidirectional Utilized Bandwidth. 421 The Shared Risk Link Group (SRLG) information provided by the SRLG 422 TLV (type 138) [RFC5307] MAY be also used. In order to indicate that 423 the interface is unnumbered in this case, the corresponding flag 424 takes value 0. The Link Local Identifier is an Extended Local 425 Circuit Identifier and the Link Remote Identifier is a Neighbor 426 Extended Local Circuit ID. 428 5. Explicit ECT Algorithms 430 The exact IS-IS control mode of operation MUST be selected for a VLAN 431 by associating its Base VID with the appropriate ECT Algorithm in the 432 SPB Base VLAN-Identifiers sub-TLV [RFC6329], in addition to 433 allocating the Base VID to IS-IS control. There are five distinct 434 ECT Algorithms for the five explicit path control modes. The 435 operation details of the explicit ECT Algorithms and their 436 configuration is specified by IEEE 802.1Qca, a high level overview is 437 given here. An ECT Algorithm value consists of the IEEE 802.1 OUI 438 (Organizationally Unique Identifier) value 00-80-C2 concatenated with 439 an index [RFC6329]. 441 The Strict Tree (ST) ECT Algorithm MUST be used for a strict explicit 442 tree. A strict ET is static as no other entity can update it but the 443 owner PCE. In case of a topology change, it is the task of the owner 444 PCE to detect the topology change, e.g. based on the changes in the 445 LSDB, and to update the strict trees if needed. That is, the owner 446 PCE computes the new tree, assembles its descriptor (Section 6.1), 447 and then instructs IS-IS PCR to install it. The value for the ST ECT 448 algorithm is 00-80-C2-17. 450 The Loose Tree (LT) ECT Algorithm MAY be also supported. It is used 451 for a single loose explicit tree. The path for loose hops is 452 determined by the BLCE of the bridges; therefore, the Topology sub- 453 TLV (Section 6.1) specifying the tree MUST indicate which hop is the 454 Root of the tree. The loose hops are maintained by IS-IS, i.e. 455 restored upon a topology change if a loop-free path is available. If 456 the tree computed by the BLCE visits the same bridge twice (implying 457 that a loop or hairpin has been created), then that loop or hairpin 458 MUST be pruned from the tree even if it contains a hop specified by 459 the Topology sub-TLV. It is a constraint if a bridge is not to be 460 included, which can be specified by the Exclude flag of a Hop sub-TLV 461 (Section 6.2) conveyed by the Topology sub-TLV specifying the tree. 462 The range of values for the LT ECT Algorithms is 463 00-80-C2-21...00-80-C2-30. 465 The Loose Tree Set (LTS) ECT Algorithm MAY be also supported. It is 466 used if connectivity among the traffic end points specified by the 467 Topology sub-TLV (Section 6.1) is to be provided by a set of loose 468 trees such that one tree is rooted at each traffic end point. The 469 BLCE of the bridges compute the loose trees, which are maintained by 470 IS-IS, i.e. restored upon a topology change. One constraint can be 471 to avoid some bridges in these trees, which can be specified by the 472 Exclude flag (item c.6. in Section 6.2). Further constraints can be 473 specified by the Topology sub-TLV. The range of values for the LT 474 ECT Algorithms is 00-80-C2-31...00-80-C2-40. 476 The LT and LTS ECT Algorithms use the shortest paths after pruning 477 the topology according to the constraint(s) if any. The shortest 478 path tie-breaking specified by Section 12 of [RFC6329] is applied 479 (see also subclauses 28.5 - 28.8 of [IEEE8021aq]), that's why range 480 of values are associated with the LT and LTS ECT Algorithms. In case 481 of the LT ECT Algorithm, the indexes are 0x21...0x30, and ECT- 482 MASK{index-0x20} is applied to retrieve the ECT-MASK of Section 12 of 483 [RFC6329]. In case of the LTS ECT Algorithm, the indexes are 484 0x31...0x40, and ECT-MASK{index-0x30} is applied to retrieve the ECT- 485 MASK for shortest path tie-breaking. 487 The MRT ECT Algorithm MAY be also supported. It is used for the 488 establishment and maintenance of MRTs in a distributed fashion. The 489 MRT Lowpoint Algorithm specified by 490 [I-D.ietf-rtgwg-mrt-frr-algorithm] MUST be used for the computation 491 of MRTs. The MRT Lowpoint Algorithm first computes the GADAG then 492 produces two MRTs for each MRT Root: MRT-Blue and MRT-Red. If the 493 level of redundancy provided by each bridge being an MRT Root is not 494 required, then the MRT Roots can be specified by a Topology sub-TLV 495 (Section 6.1). Both the GADAG and the MRT computation steps are 496 performed distributed, i.e. by each bridge. The value for the MRT 497 ECT algorithm is 00-80-C2-18. 499 The MRT GADAG (MRTG) ECT Algorithm MAY be also supported. It splits 500 the computation into two. As the GADAG is identical for each MRT 501 within a domain, it is computed by a single entity, which is the 502 GADAG Computer. The GADAG is then described in a Topology sub-TLV 503 (Section 6.1), which is flooded in the domain. The bridges then 504 compute the MRTs for the MRT Roots based on the GADAG received. 505 Section 7 provides more details on the description of the GADAG. The 506 value for the MRTG ECT algorithm is 00-80-C2-19. 508 MRTs are loose trees as bridges are involved in their computation and 509 restoration. Thus both the MRT and the MRTG ECT Algorithms provide a 510 set of loose trees: two MRTs for each MRT Root. 512 6. IS-IS PCR sub-TLVs 514 The following sub-TLVs are specified for IS-IS PCR. The Topology 515 sub-TLV MUST be carried in an MT-Capability TLV, the rest of the sub- 516 TLVs are conveyed by Topology sub-TLV. 518 6.1. Topology sub-TLV 520 The variable length Topology sub-TLV MUST be used to describe an 521 explicit tree. The Topology sub-TLV MAY be also used for describing 522 a Generalized Almost Directed Acyclic Graph (GADAG) as explained in 523 Section 7 in detail. The Topology sub-TLV MUST be carried in an MT- 524 Capability TLV (type 144) [RFC6329] in a Link State PDU. A Topology 525 sub-TLV specifying an explicit tree conveys one or more Base VIDs, 526 two or more Hop sub-TLVs (Section 6.2). A Topology sub-TLV 527 describing a loose tree MAY also convey further sub-TLVs to specify 528 constraints. Figure 1 shows the format of the Topology sub-TLV. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+ 533 | Type | (1 byte) 534 +-+-+-+-+-+-+-+-+ 535 | Length | (1 byte) 536 +-+-+-+-+-+-+-+-+ 537 | Num Base VIDs | (1 byte) 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Res | Base VID 1 (12 bits) | (0 or 2 bytes) 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 ................. 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Res | Base VID n (12 bits) | (0 or 2 bytes) 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | sub-TLV 1 (variable) | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 ................. 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | sub-TLV m (variable) | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Figure 1: Topology sub-TLV 554 The parameters of explicit trees are encoded by the Topology sub-TLV 555 as follows: 557 a. Type (8 bits): The type of the sub-TLV, its value is TBD. 559 b. Length (8 bits): The total number of bytes contained in the Value 560 field. 562 c. Number of Base VIDs (8 bits): The number of Base VIDs carried in 563 the Topology sub-TLV. Its minimum value is 1 if the Topology 564 sub-TLV specifies one or more explicit trees. Its value can be 0 565 if the Topology sub-TLV specifies a GADAG. 567 d. Reserved (Res) (4 bits): The reserved bits take value 0. 569 e. Base VID (12 bits): The Base VID parameter provides the Base VID 570 of the VLAN that is associated with the explicit tree. Multiple 571 Base VIDs can be associated with the same explicit tree. In 572 addition to the Base VID, some of the explicit ECT Algorithms 573 (Section 5) require further VIDs which are associated with the 574 VLAN via the SPB Instance sub-TLV [RFC6329]. A Topology sub-TLV 575 specifying a GADAG can have zero Base VID parameters. In this 576 case, the given GADAG MUST be applied for each VLAN associated 577 with the MRTG ECT Algorithm (Section 5). 579 f. sub TLVs: The rest conveys further sub-TLVs that specify the hops 580 of the topology and can also specify constraints as described in 581 the following. 583 A topology is specified by a list of Hop sub-TLVs (Section 6.2), and 584 a hop is specified by an IS-IS System ID. An ill-formed Topology 585 sub-TLV, e.g. specifying an invalid or inconsistent tree is ignored, 586 no tree is installed but a management report is generated. 588 The Topology sub-TLV specifies a strict tree by decomposing the tree 589 to branches. Each branch is a point-to-point path specified by an 590 ordered list of hops where the end of each branch is a leaf. Each 591 element of a branch is the direct link between adjacent neighbor 592 bridges whose Hop sub-TLV is next to each other in the Topology sub- 593 TLV. The first hop of the Topology sub-TLV is the root, hence, the 594 first branch originates from the root. The rest of the branches fork 595 from another branch. The first hop of a branch is a bridge that is 596 already part of a former branch and the last hop is a leaf bridge. 597 Therefore, the hop after a leaf hop is the beginning of a new branch, 598 if any. A hop of a branch is created if and only if the bridge 599 specified for that hop is directly connected to the preceding bridge 600 of the same branch. The first branch MUST begin with the root and 601 after that the order of the branches does not matter within the 602 Topology sub-TLV. Figure 2 shows an example strict tree and its 603 description. 605 +-----------+ 606 | A | 607 +-----------+ 608 | I | 609 +-----------+ 610 | H | 611 [B]---[A]---[I] +-----------+ 612 | | | G | 613 | | +-----------+ 614 | | | E | 615 [C]---[F] [H] +-----------+ 616 | | | A | 617 | | +-----------+ 618 | | | B | 619 [D] [E]---[G] +-----------+ 620 | C | 621 +-----------+ 622 | D | 623 +-----------+ 624 | C | 625 +-----------+ 626 | F | 627 +-----------+ 629 Figure 2: A strict tree and its description; root = Node A 631 The Topology sub-TLV of a loose tree does not provide any path or 632 path segment, but the hops which are to participate. The root MUST 633 be the first hop. The leaves of a single loose tree MUST be also 634 specified. Hop sub-TLVs can be included in a Topology sub-TLV to 635 specify bridges that have to be avoided. If the Topology sub-TLV 636 only specifies a single leaf, then one or more transit hops can be 637 specified by the Topology sub-TLV to direct the path along a sequence 638 of bridges, specified by the order of hops. If bridges whose 639 respective Hop sub-TLVs are adjacent to each other in the Topology 640 sub-TLV but are not topology neighbors, then it is a loose hop. If a 641 Topology sub-TLV conveys one or more loose hops, then that sub-TLV 642 defines a loose explicit tree and each hop is considered as a loose 643 hop. The path of a loose hop MUST be pruned from the tree if the 644 path would create a loop or hairpin. 646 If the Base VIDs of the Topology sub-TLV are associated with the LTS 647 ECT Algorithm or the MRT ECT Algorithm, then the Hop sub-TLVs 648 conveyed by the Topology sub-TLV belong to traffic end points or 649 bridges to be excluded. The BLCEs compute the loose trees, e.g. 650 MRTs, such that they span the traffic end points and are rooted at a 651 traffic end point. 653 The Topology sub-TLV specifies a GADAG if the Base VIDs conveyed by 654 the Topology sub-TLV are associated with the MRTG ECT Algorithm. 655 Section 7 provides the details on the description of a GADAG by a 656 Topology sub-TLV. 658 Each traffic end point of an explicit tree MUST be always specified 659 in the Topology sub-TLV by the inclusion of the Hop sub-TLVs 660 corresponding to the traffic end points. The traffic end points of a 661 tree are identified by setting the Traffic End Point flag (item c.3. 662 in Section 6.2) in the appropriate Hop sub-TLVs. 664 If the explicit tree is loose, then the Topology sub-TLV MAY convey 665 further sub-TLVs to specify constraints, e.g. an Administrative Group 666 sub-TLV [RFC5305] or a Bandwidth Constraint (Section 6.3). If it is 667 not possible to meet the constraint(s) specified by the Topology sub- 668 TLV, then no tree is installed but a management report is generated. 670 If IS-IS PCR is used for recording bandwidth assignment, then the 671 Topology sub-TLV conveys Bandwidth Assignment sub-TLV (Section 6.4) 672 and it can also convey Timestamp sub-TLV (Section 6.5). If the 673 bandwidth assignment specified by the Topology sub-TLV is not 674 possible, e.g. due to overbooking, then bandwidth assignment MUST NOT 675 be performed and a management report is generated. If the Topology 676 sub-TLV specifies a new valid explicit tree, then the tree is 677 installed without bandwidth assignment. 679 6.2. Hop sub-TLV 681 The Hop sub-TLV MUST be used to specify a hop of a topology. Each 682 Hop sub-TLV conveys an IS-IS System ID, which specifies a hop. A Hop 683 sub-TLV is conveyed by a Topology sub-TLV (Section 6.1). A strict 684 explicit tree is decomposed to branches where each branch is a point- 685 to-point path specified by an ordered list of Hop sub-TLVs as 686 specified in Section 6.1. A hop of a branch is created if and only 687 if the bridge specified for that hop is directly connected to the 688 preceding bridge in the path. That is, a point-to-point LAN is 689 identified by the two bridges it interconnects; and the LAN is part 690 of the strict tree if and only if the Hop sub-TLVs of the two bridges 691 are next to each other in the Topology sub-TLV. A Hop sub-TLV can 692 convey a Circuit ID in order to distinguish multiple links between 693 adjacent neighbor bridges. A Hop sub-TLV also specifies the role of 694 a bridge, e.g. if it is the root or a traffic end point. The 695 Topology sub-TLV of a loose tree only comprises the Hop sub-TLV of 696 the bridges that have special role in the tree. The Hop sub-TLV MAY 697 also specify a delay budget for a loose hop. 699 By default, the traffic end points both transmit and receive with 700 respect to each VID associated with an explicit tree, except for an 701 LTS (Section 5) associated with a learning VLAN, which uses a 702 unidirectional VID per bridge. The Hop sub-TLV allows different 703 configuration by means of the Transmit (T) and Receive (R) flags 704 conveyed in the sub-TLV. The VID and its T/R flags are only present 705 in the Hop sub-TLV if the behavior of the traffic end points differs 706 from the default. 708 Figure 3 shows the format of the variable length Hop sub-TLV, which 709 MUST be conveyed by a Topology sub-TLV (Section 6.1). 711 0 1 2 3 712 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 713 +-+-+-+-+-+-+-+-+ 714 | Type | (1 byte) 715 +-+-+-+-+-+-+-+-+ 716 | Length | (1 byte) 717 +-+-+-+-+-+-+-+-+ 718 |C|V|T|R|L|E|Res| (1 byte) 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | System ID | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | System ID | (6 bytes) 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Extended Local Circuit ID (0 or 4 bytes) | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Num of VIDs | (0 or 1 byte) 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 |T|R|Res| VID 1 (12 bits) | (0 or 2 bytes) 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 ................. 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 |T|R|Res| VID n (12 bits) | (0 or 2 bytes) 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Delay Constraint | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Delay Constraint | (0 or 6 bytes) 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 3: Hop sub-TLV 741 The parameters of a hop are encoded as follows: 743 a. Type (8 bits): The type of the sub-TLV, its value is TBD. 745 b. Length (8 bits): The total number of bytes contained in the Value 746 field. 748 c. Hop Flags (8 bits): The Hop sub-TLV conveys six one-bit flags. 749 The Circuit and the VID flags influence the length of the Hop 750 sub-TLV. Two bits are reserved for future use, transmitted as 0 751 and ignored on receipt. 753 1. Circuit (C) flag (1 bit): The Circuit flag is a one-bit flag 754 to indicate whether or not the Extended Local Circuit ID 755 parameter is present. If the flag is set, then an Extended 756 Local Circuit ID is also included in the Hop sub-TLV. 758 2. VID (V) flag (1 bit): The VID flag is a one-bit flag to 759 indicate whether or not one or more VIDs are conveyed by the 760 Hop sub-TLV. If the flag is set, then the Number of VIDs 761 parameter is present and indicates how many VIDs are conveyed 762 by the Hop sub-TLV. If the VID flag is reset, then neither 763 the Number of VIDs parameter nor VIDs are present in the Hop 764 sub-TLV. 766 3. Traffic End Point (T) flag (1 bit): The Traffic End Point 767 flag is a one-bit flag to indicate whether or not the given 768 System is a traffic end point, i.e. transmitter and/or 769 receiver. If the System is a traffic end point, then the 770 Traffic End Point flag MUSt be set. (The Traffic End Point 771 flag indicates whether FDB entries are to be installed for 772 the given hop.) 774 4. Root (R) flag (1 bit): The Root flag is a one-bit flag to 775 indicate whether or not the given System is a Root of the 776 explicit tree specified by the Topology sub-TLV. If the 777 System is a root of a tree, then the Root flag MUST be set. 778 If the Topology sub-TLV specifies a single tree, i.e. the 779 Base VIDs conveyed by the Topology sub-TLV are associated 780 with either the ST ECT Algorithm or the LT ECT Algorithm 781 (Section 5), then the Root flag is only set for one of the 782 Systems conveyed by the Topology sub-TLV. Furthermore, the 783 first Hop sub-TLV of the Topology sub-TLV conveys the System 784 that is the root of the tree. If the Topology sub-TLV 785 specifies a Loose Tree Set, i.e. the Base VIDs conveyed by 786 the Topology sub-TLV are associated with the LTS ECT 787 Algorithm (Section 5), then the Root flag is set for each 788 traffic end point as each of them roots a tree. If the 789 Topology sub-TLV is used for MRT operations, i.e. the Base 790 VIDs conveyed by the Topology sub-TLV are associated with 791 either the MRT ECT Algorithm or the MRTG ECT Algorithm 792 (Section 5), then the Root flag is set for each MRT Root. If 793 no MRT Root is specified by a Topology sub-TLV specifying a 794 GADAG, then each SPT Root is an MRT Root as well. If the 795 Base VIDs conveyed by the Topology sub-TLV are associated 796 with the MRTG ECT Algorithm (Section 5), then the Topology 797 sub-TLV specifies a GADAG and the very first Hop sub-TLV 798 specifies the GADAG Root. There is no flag for indicating 799 the GADAG Root. 801 5. Leaf (L) flag (1 bit): The Leaf flag is a one-bit flag to 802 indicate whether or not the given System is a Leaf of the 803 explicit tree specified by the Topology sub-TLV. If the 804 System is a Leaf, then the Leaf flag MUST be set. The Leaf 805 flag is only used to mark a leaf of a tree if the Topology 806 sub-TLV specifies a single tree. The Leaf flag MUST be used 807 to indicate the end of a topology block if the Topology sub- 808 TLV specifies a GADAG, see Section 7. 810 6. Exclude (E) flag (1 bit): The Exclude flag is a one-bit flag 811 to indicate if the given System MUST be excluded from the 812 topology. The Exclude flag and the Root flag cannot be set 813 for a given hop at the same time. 815 7. Reserved (Res) (2 bits): The reserved bits take value 0. 817 d. System ID (48 bits): The 6-byte IS-IS System Identifier of the 818 bridge that the Hop sub-TLV refers to. 820 e. Extended Local Circuit ID (32 bits): The Extended Local Circuit 821 ID [RFC5303] parameter is not necessarily present in the Hop sub- 822 TLV. Its presence is indicated by the Circuit flag. Parallel 823 links corresponding to different IS-IS adjacencies between a pair 824 of neighbor bridges can be distinguished by means of the Extended 825 Local Circuit ID. The Extended Local Circuit ID is conveyed by 826 the Hop sub-TLV specifying the bridge nearer to the root of the 827 tree, and identifies a circuit that attaches the given bridge to 828 its neighbor cited by the next Hop sub-TLV of the Topology sub- 829 TLV. The Extended Local Circuit ID can only be used in strict 830 trees. 832 f. Number of VIDs (8 bits): The Number of VIDs parameter is not 833 present if the Hop sub-TLV does not convey VIDs, which is 834 indicated by the VID flag. 836 g. VID and its T/R flags (14 bits): The VID and its T/R flags are 837 only present in the Hop sub-TLV if the given bridge is a traffic 838 end point and it behaves differently from the default with 839 respect to that particular VID. 841 1. T flag (1 bit): This is the Transmit allowed flag for the VID 842 following the flag. 844 2. R flag (1 bit): This is the Receive allowed flag for the VID 845 following the flag. 847 3. Reserved (Res) (2 bits): The reserved bits take value 0. 849 4. VID (12 bits): A VID. 851 h. Delay Constraint (48 bits): The last six bytes specify a delay 852 constraint if they convey a Unidirectional Link Delay sub-TLV 853 [I-D.ietf-isis-te-metric-extensions]. The delay constraint MAY 854 be used in a Topology sub-TLV that specifies a single loose tree, 855 i.e. the Base VIDs are associated with the LT ECT Algorithm 856 (Section 5). If delay constraint is applied, then the loose hop 857 MUST fit in the delay budget specified by the Delay parameter of 858 the Unidirectional Link Delay sub-TLV conveyed by the Hop sub- 859 TLV. If the Topology sub-TLV specifies a single leaf, then the 860 path between the preceding Hop sub-TLV and the current Hop sub- 861 TLV MUST meet the delay budget. If the Topology sub-TLV 862 specifies multiple leaves, then the path between the root and the 863 current Hop sub-TLV MUST to meet the delay budget. If the tree 864 is used as a reverse congruent tree, then the delay constraint 865 applies in both directions. If the tree is used as a directed 866 tree, then the delay constraint applies in the direction of the 867 tree. If it is not possible to meet the delay constraint 868 specified by the Topology sub-TLV, then no tree is installed but 869 a management report is generated. 871 6.3. Bandwidth Constraint sub-TLV 873 The Bandwidth Constraint sub-TLV MAY be included in a Topology sub- 874 TLV (Section 6.1) in order to specify how much available bandwidth is 875 to be provided by the constrained tree. Each loose hop MUST meet the 876 bandwidth constraint. The bandwidth value of the constraint is a 877 total value or it only refers to a single PCP as specified by the 878 sub-TLV. Figure 4 shows the format of the Bandwidth Constraint sub- 879 TLV. 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+ 884 | Type | (1 byte) 885 +-+-+-+-+-+-+-+-+ 886 | Length | (1 byte) 887 +-+-+-+-+-+-+-+-+ 888 | PCP |D|P| Res | (1 byte) 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Available Bandwidth (4 bytes) | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Figure 4: Bandwidth Constraint sub-TLV 895 The parameters of the bandwidth constraint are encoded as follows: 897 a. Type (8 bits): The type of the sub-TLV, its value is TBD. 899 b. Length (8 bits): The total number of bytes contained in the Value 900 field. The value of the Length field is 5 bytes. 902 c. PCP (4 bits): The Priority Code Point (PCP) parameter identifies 903 the traffic class the Available Bandwidth parameter refers to, if 904 any. 906 d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) 907 parameter. If the DEI parameter is clear, then the bandwidth 908 constraint refers to committed information rate. If the DEI 909 parameter is set, then the bandwidth constraint refers to peak 910 information rate. 912 e. PCP (P) flag (1 bit): If this flag is set, then the PCP parameter 913 is taken into account. 915 f. Reserved (Res) (3 bits): The reserved bits take value 0. 917 g. Available Bandwidth (32 bits): The Available Bandwidth is 918 specific to the traffic class identified by the PCP parameter if 919 the PCP flag is set, otherwise, it is total bandwidth. In-line 920 with the bandwidth parameters specified in [RFC5305], the 921 Available Bandwidth is encoded as a 32-bit IEEE floating point 922 number, and the units are bytes (not bits!) per second. When the 923 Unreserved Bandwidth sub-TLV (sub-TLV type 11 specified by 924 [RFC5305]) is used in a Layer 2 bridge network, the priority 925 value encoded in the Unreserved Bandwidth sub-TLV provides the 926 PCP, i.e. identifies a traffic class (not a setup priority 927 level). Thus, the Available Bandwidth of a traffic class is 928 easily comparable with the Unreserved Bandwidth stored in the TED 929 for the given traffic class. The bandwidth constraint applies 930 for both directions in case of symmetric explicit trees. 931 Nevertheless, a VID associated with an explicit tree can be made 932 unidirectional by means of the T/R flags belonging to the VID in 933 the Hop sub-TLV (item g. in Section 6.2) of the traffic end 934 points. If all the VIDs of the Topology sub-TLV (Section 6.1) 935 are unidirectional and all belong to the traffic class identified 936 by the PCP parameter of the Bandwidth Constraint sub-TLV, then it 937 is enough to meet the bandwidth constraint in the direction 938 applied for those VIDs. 940 6.4. Bandwidth Assignment sub-TLV 942 IS-IS PCR MAY be used for recording bandwidth assignment for 943 explicitly placed data traffic in a domain if MSRP is not used within 944 the domain. If MSRP is used in a domain, then only MSRP performs 945 reservations. Both MSRP and IS-IS MUST NOT be used to make bandwidth 946 assignments in the same domain. 948 The Bandwidth Assignment sub-TLV can be used to define the amount of 949 bandwidth whose assignment is to be recorded by IS-IS PCR at each hop 950 of the explicit tree described by the corresponding Topology sub-TLV 951 (Section 6.1). The Bandwidth Assignment sub-TLV is used by IS-IS PCR 952 for the recording of bandwidth assignment for a traffic class 953 identified by the PCP parameter of a VLAN tag. If precedence order 954 has to be determined among bandwidth assignments in a domain with 955 multiple PCEs, then IS-IS PCR does it as described below. If the 956 bandwidth assignment specified by the Topology sub-TLV is not 957 possible, e.g. due to overbooking, then bandwidth recording MUST NOT 958 be performed and a management report is generated. If the Topology 959 sub-TLV specifies a new valid explicit tree, then the tree is 960 installed without bandwidth assignment. The Bandwidth Assignment 961 sub-TLV is conveyed by a Topology sub-TLV (Section 6.1). Figure 5 962 shows the format of the Bandwidth Assignment sub-TLV. 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+ 967 | Type | (1 byte) 968 +-+-+-+-+-+-+-+-+ 969 | Length | (1 byte) 970 +-+-+-+-+-+-+-+-+ 971 | PCP |D| Imp |R| (1 byte) 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Bandwidth (4 bytes) | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 Figure 5: Bandwidth Assignment sub-TLV 978 The parameters of the bandwidth constraint are encoded as follows: 980 a. Type (8 bits): The type of the sub-TLV, its value is TBD. 982 b. Length (8 bits): The total number of bytes contained in the Value 983 field. The value of the Length field is 5 bytes. 985 c. PCP (3 bits): The PCP parameter identifies the traffic class the 986 bandwidth to be assigned for. 988 d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) 989 parameter. If the DEI parameter is clear, then the bandwidth 990 assignment is performed for providing committed information rate. 991 If the DEI parameter is set, then the bandwidth assignment is 992 performed for providing peak information rate. 994 e. Importance (Imp) (3 bits): This is the Importance parameter for 995 determining precedence order among bandwidth assignments within a 996 PCP as described below. Lower numerical value indicates more 997 important bandwidth assignment within a PCP. The default value 998 of the Importance parameter is 7. 1000 f. Reserved (R) (1 bit): The reserved bit takes value 0. 1002 g. Bandwidth (32 bits): This is the amount of bandwidth to be 1003 assigned for the traffic class identified by the PCP parameter. 1004 In-line with the bandwidth values specified in [RFC5305], the 1005 Bandwidth parameter is encoded as a 32-bit IEEE floating point 1006 number, and the units are bytes (not bits!) per second. The 1007 bandwidth assignment applies for both directions in case of 1008 symmetric explicit trees. 1010 The PCEs are collectively responsible for making a consistent set of 1011 bandwidth assignments when IS-IS PCR is used for recording bandwidth 1012 allocations. If despite of that, precedence ordering is required 1013 among bandwidth assignments, then ordering based on the following 1014 parameters MUST be applied: 1016 1. PCP parameter of Bandwidth Assignment sub-TLV, 1018 2. Importance parameter of Bandwidth Assignment sub-TLV, 1020 3. Timestamp sub-TLV (if present in the Topology sub-TLV). 1022 A bandwidth assignment takes precedence if it has higher PCP, or 1023 higher Importance within a PCP, or earlier timestamp in case of equal 1024 Importance within a PCP. A bandwidth assignment associated with a 1025 timestamp takes precedence over a bandwidth assignment without 1026 timestamp. If resolution is not possible based on the above 1027 parameters or they are not available, e.g. each bandwidth assignment 1028 lacks timestamp or the same VID is called for, then the item is 1029 granted to the PCE whose LSP has the numerically least LSP ID. 1031 6.5. Timestamp sub-TLV 1033 The Timestamp sub-TLV MAY be included in a Topology sub-TLV 1034 (Section 6.1) in order to provide precedence order among equally 1035 important bandwidth assignments within a PCP as described in 1036 Section 6.4. Figure 6 shows the format of the Timestamp sub-TLV. 1038 0 1 2 3 1039 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 1040 +-+-+-+-+-+-+-+-+ 1041 | Type | (1 byte) 1042 +-+-+-+-+-+-+-+-+ 1043 | Length | (1 byte) 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Time (4 bytes) | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 Figure 6: Timestamp sub-TLV 1050 The timestamp represents a positive time with respect to the 1051 Precision Time Protocol (PTP) epoch and it is encoded as follows: 1053 a. Type (8 bits): The type of the sub-TLV, its value is TBD. 1055 b. Length (8 bits): The total number of bytes contained in the Value 1056 field. The value of the Length field is 4 bytes. 1058 c. Time (32 bits): This is the time in units of seconds with respect 1059 to the PTP epoch. 1061 The Timestamp sub-TLV carries the seconds portion of PTP as specified 1062 by [IEEE1588]. The epoch is 1970-01-01 00:00:00 TAI (i.e., the PTP 1063 time does not include leap seconds). 1065 7. MRT-FRR Application 1067 The application of MRT by [IEEE8021Qca] is discussed in detail in 1068 [I-D.bowers-rtgwg-mrt-applicability-to-8021qca]. This section 1069 describes some special considerations for the use of the MRT Lowpoint 1070 Algorithm [I-D.ietf-rtgwg-mrt-frr-algorithm], which are applicable 1071 both to the MRT ECT Algorithm and the MRTG ECT Algorithm. This 1072 section also explains details related to the MRTG ECT Algorithm and 1073 the application of the Topology sub-TLV in particular. 1075 The SPB Link Metric sub-TLV [RFC6329] specifies the metric of each 1076 link for IS-IS PCR including the MRT Algorithms. If the SPB Link 1077 Metric values advertised by different ends of an adjacency are 1078 different, then the maximum value MUST be used. If equal cost 1079 (sub)paths are found during the MRT computation, then the default 1080 tie-breaking specified by Section 11 of [RFC6329] MUST be used, which 1081 is based on the lower Bridge ID. (The BridgeID is an 8-byte quantity 1082 whose upper 2 bytes are the node's BridgePriority and lower 6 bytes 1083 are the node's SYSID.) Note also that if MRTs are used for source 1084 specific multicast (see [IEEE8021Qca] for details), then the bridges 1085 have to compute the MRTs of the other bridges in addition to their 1086 own one in order to be able to install the appropriated FDB entries. 1087 (This is similar to the need for all pairs shortest path computation 1088 instead of Dijkstra for source specific shortest path multicast 1089 trees.) 1091 The GADAG is identical for all the MRTs within a network domain, as a 1092 consequence of the use of the MRT Lowpoint Algorithm 1093 [I-D.ietf-rtgwg-mrt-frr-algorithm]. Therefore, it is beneficial to 1094 compute the GADAG by a single entity, which is referred to as the 1095 GADAG Computer and is either a PCE or the GADAG Root. If the MRTG 1096 ECT Algorithm is applied, then the GADAG MUST be only computed by the 1097 GADAG Computer, which then MUST flood the descriptor Topology sub-TLV 1098 of the GADAG. The bridges then compute the MRTs based on the 1099 received GADAG. 1101 The GADAG computation requires the selection of the GADAG Root. The 1102 bridge with the best Bridge Identifier MUST be selected as the GADAG 1103 Root, where the numerically lower value indicates the better 1104 identifier. The Bridge Priority component of the Bridge Identifier 1105 allows the configuration of the GADAG Root by management action. The 1106 Bridge Priority is conveyed by the SPB Instance sub-TLV [RFC6329]. 1108 The GADAG Computer MUST perform the GADAG computation as specified by 1109 the MRT Lowpoint Algorithm [I-D.ietf-rtgwg-mrt-frr-algorithm]. The 1110 GADAG Computer then MUST encode the GADAG in a Topology sub-TLV 1111 (Section 6.1), which is then flooded throughout the domain. A GADAG 1112 is encoded in a Topology sub-TLV by means of directed ear 1113 decomposition as follows. A directed ear is a directed point-to- 1114 point path whose end points can coincide but no other element of the 1115 path is repeated in the ear. Each ear is specified by an ordered 1116 list of hops such that the order of hops is according to the 1117 direction of the arcs in the GADAG. There are no leaves in a GADAG, 1118 hence, the Leaf flag (item c.5. in Section 6.2) is used to mark the 1119 end of a topology block. (A GADAG with multiple blocks is 1120 illustrated in Figure 8.) The sequence of ears in the Topology sub- 1121 TLV is such that the end points of an ear belong to preceding ears. 1122 The GADAG Root is not marked by any flag but the GADAG Root is the 1123 first hop in the Topology sub-TLV, correspondingly the first ear 1124 starts and ends with the GADAG Root. MRT Roots MUST be marked by the 1125 Root flag (item c.4. in Section 6.2) and all other traffic end points 1126 are leaves of the given MRTs. If no MRT Root is specified, then each 1127 SPT Root is also an MRT Root. 1129 Figure 7 shows an example GADAG. The figure also illustrates the 1130 description of the GADAG, it shows the System ID parameter of the Hop 1131 sub-TLV (Section 6.2) and the order of hops in the Topology sub-TLV 1132 (Section 6.1). 1134 Leaf 1135 Hop flag 1136 +-----------+---+ 1137 | A | | 1138 +-----------+---+ 1139 | B | | 1140 +-----------+---+ 1141 | C | | 1142 +-----------+---+ 1143 | F | | 1144 [B]<---[A]<---[I] +-----------+---+ 1145 | ^ ^ | A | | 1146 | | | +-----------+---+ 1147 V | | | C | | 1148 [C]--->[F]--->[H] +-----------+---+ 1149 | ^ | D | | 1150 | | +-----------+---+ 1151 V | | E | | 1152 [D]--->[E]--->[G] +-----------+---+ 1153 | G | | 1154 +-----------+---+ 1155 | H | | 1156 +-----------+---+ 1157 | I | | 1158 +-----------+---+ 1159 | A | | 1160 +-----------+---+ 1161 | F | | 1162 +-----------+---+ 1163 | H | X | 1164 +-----------+---+ 1166 Figure 7: A GADAG and its description; GADAG root = Node A 1168 A topology can be comprised of multiple blocks, like the one 1169 illustrated in Figure 8(a). This example topology is comprised of 1170 four blocks as each cut-link is a block. A-B-C-D-E-F is a block, D-G 1171 is another block, G-H, and H-J-K are further blocks. The GADAG for 1172 this topology is shown in Figure 8(b). Note that the GADAG includes 1173 two arcs for each cut-link and the direction of each arc is 1174 different, e.g. D->G and G->D. The encoding starts with the Block 1175 (ADAG) involving the GADAG Root as illustrated in Figure 8. The 1176 first hop in the Topology sub-TLV is the GADAG Root (node A in this 1177 example.) The ADAG of the first block is then described using the 1178 ear decomposition, as described above. In this example, the first 1179 block has been completely traversed at the second occurrence of node 1180 A in the GADAG descriptor. The end of a block is indicated by 1181 setting the Leaf flag for the last hop of the block, e.g. for the 1182 second occurrence of node A in the example GADAG descriptor. The 1183 next node that appears in the GADAG descriptor (D in this case) is 1184 the localroot for the nodes in the next block. Continuing this 1185 process, the Leaf flag is set for the third occurrence of D, the 1186 third occurrence of G, and the third occurrence of H, each indicating 1187 the end of a block. The first hop of the first block is the GADAG 1188 Root, the fist hop in the rest of the blocks is the localroot. The 1189 position of the set Leaf flags helps to determine the localroot, 1190 which is the next hop. In the example GADAG descriptor, one can 1191 determine that A is the localroot for B,C,D,E,F (and A is the GADAG 1192 Root). D is the localroot for G. G is the localroot for H. And H 1193 is the localroot for J and K. The GADAG Root is assigned a localroot 1194 of None. 1196 Block IDs are reconstructed while parsing a Topology sub-TLV 1197 specifying a GADAG. The current Block ID starts at 0 and is assigned 1198 to the GADAG Root. A node appearing in the GADAG descriptor without 1199 a previously-assigned Block ID value is assigned the current Block 1200 ID. And the current Block ID is incremented by 1 after processing 1201 the localroot of a block. Note that the localroot of a block will 1202 keep the Block ID of the first block in which it is assigned a Block 1203 ID. In the example in Figure 8, A has Block ID=0. B, C, D, E, and F 1204 have Block ID=1. G has Block ID=2. H has Block ID=3. J and K have 1205 Block ID=4. 1207 Leaf 1208 Hop flag 1209 [F]--[E] |--[K] +-----------+---+ 1210 | | | | | A | | 1211 | | | | +-----------+---+ 1212 [A] [D]--[G]--[H] | | B | | 1213 | | | | +-----------+---+ 1214 | | | | | C | | 1215 [B]--[C] |--[J] +-----------+---+ 1216 | D | | 1217 (a) topology +-----------+---+ 1218 | E | | 1219 +-----------+---+ 1220 | F | | 1221 +-----------+---+ 1222 | A | X | 1223 +-----------+---+ 1224 [F]<-[E] |--[K] | D | | 1225 | ^ | ^ +-----------+---+ 1226 V | V | | G | | 1227 [A] [D]->[G]->[H] | +-----------+---+ 1228 | [D]<-[G]<-[H] | | D | X | 1229 | ^ | | +-----------+---+ 1230 V | | | | G | | 1231 [B]->[C] |->[J] +-----------+---+ 1232 | H | | 1233 (b) GADAG +-----------+---+ 1234 | G | X | 1235 +-----------+---+ 1236 | H | | 1237 +-----------+---+ 1238 | J | | 1239 +-----------+---+ 1240 | K | | 1241 +-----------+---+ 1242 | H | X | 1243 +-----------+---+ 1245 (c) GADAG descriptor 1247 Figure 8: A GADAG with cut-links and its description; GADAG root = 1248 Node A 1250 8. Summary 1252 This document specifies IS-IS sub-TLVs for the control of explicit 1253 trees in Layer 2 networks. These sub-TLVs can be also used for the 1254 distribution of a centrally computed GADAG or MRTs if MFT-FRR is 1255 used. 1257 9. IANA Considerations 1259 Five new code points are required within MT-Capability [RFC6329] for 1260 the five new sub-TLVs: 1262 o Topology sub-TLV 1264 o Hop sub-TLV 1266 o Bandwidth Constraint sub-TLV 1268 o Bandwidth Assignment sub-TLV 1270 o Timestamp sub-TLV 1272 10. Security Considerations 1274 This document adds no additional security risks to IS-IS, nor does it 1275 provide any additional security for IS-IS when used in a configured 1276 environment or a single-operator domain such as a data center. IS-IS 1277 PCR is not for zero configuration environments. 1279 However, if IS-IS PCR is used to record bandwidth assignments in a 1280 network with multiple PCEs, then race conditions can appear and the 1281 precedence can be resolved by Importance parameter of the Bandwidth 1282 Assignment sub-TLV and the Time parameter of the Timestamp sub-TLV, 1283 especially if the different PCEs are administered by different 1284 entities. 1286 11. Acknowledgements 1288 The authors would like to thank Don Fedyk and Eric Gray for their 1289 comments and suggestions. 1291 12. References 1293 12.1. Normative References 1295 [I-D.ietf-isis-te-metric-extensions] 1296 Previdi, S., Giacalone, S., Ward, D., Drake, J., Atlas, 1297 A., Filsfils, C., and W. Wu, "IS-IS Traffic Engineering 1298 (TE) Metric Extensions", draft-ietf-isis-te-metric- 1299 extensions-04 (work in progress), October 2014. 1301 [I-D.ietf-rtgwg-mrt-frr-algorithm] 1302 Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. 1303 Gopalan, "Algorithms for computing Maximally Redundant 1304 Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr- 1305 algorithm-02 (work in progress), January 2015. 1307 [IEEE8021Qca] 1308 IEEE 802.1, "IEEE 802.1Qca Bridges and Bridged Networks - 1309 Amendment: Path Control and Reservation - Draft 1.4", 1310 (work in progress), February 12, 2015, 1311 . 1313 [IEEE8021aq] 1314 IEEE 802.1, "IEEE 802.1aq: IEEE Standard for Local and 1315 metropolitan area networks - Media Access Control (MAC) 1316 Bridges and Virtual Bridged Local Area Networks - 1317 Amendment 20: Shortest Path Bridging", 2012, 1318 . 1321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1322 Requirement Levels", BCP 14, RFC 2119, March 1997. 1324 [RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way 1325 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 1326 October 2008. 1328 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1329 Engineering", RFC 5305, October 2008. 1331 [RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support 1332 of Generalized Multi-Protocol Label Switching (GMPLS)", 1333 RFC 5307, October 2008. 1335 [RFC6329] Fedyk, D., Ashwood-Smith, P., Allan, D., Bragg, A., and P. 1336 Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq 1337 Shortest Path Bridging", RFC 6329, April 2012. 1339 12.2. Informative References 1341 [I-D.bowers-rtgwg-mrt-applicability-to-8021qca] 1342 Bowers, C. and J. Farkas, "Applicability of Maximally 1343 Redundant Trees to IEEE 802.1Qca Path Control and 1344 Reservation", draft-bowers-rtgwg-mrt-applicability-to- 1345 8021qca-00 (work in progress), February 2015. 1347 [I-D.ietf-rtgwg-mrt-frr-architecture] 1348 Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, 1349 A., Tantsura, J., and R. White, "An Architecture for IP/ 1350 LDP Fast-Reroute Using Maximally Redundant Trees", draft- 1351 ietf-rtgwg-mrt-frr-architecture-05 (work in progress), 1352 January 2015. 1354 [IEEE1588] 1355 IEEE 1588, "IEEE 1588: IEEE Standard for a Precision Clock 1356 Synchronization Protocol for Networked Measurement and 1357 Control Systems", 2008, 1358 . 1361 [IEEE8021Q] 1362 IEEE 802.1, "IEEE 802.1Q-2014: IEEE Standard for Local and 1363 metropolitan area networks - Bridges and Bridged 1364 Networks", 2014, . 1367 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1368 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1370 Authors' Addresses 1372 Janos Farkas (editor) 1373 Ericsson 1374 Konyves Kalman krt. 11/B 1375 Budapest 1097 1376 Hungary 1378 Email: janos.farkas@ericsson.com 1380 Nigel Bragg 1381 Ciena 1382 43-51 Worship Street 1383 London EC2A 2DX 1384 UK 1386 Email: nbragg@ciena.com 1387 Paul Unbehagen Jr 1388 Avaya 1389 1300 W. 120th Avenue 1390 Westminster CO 80234 1391 USA 1393 Email: unbehagen@avaya.com 1395 Glenn Parsons 1396 Ericsson 1397 349 Terry Fox Drive 1398 Ottawa ON, K2K 2V6 1399 Canada 1401 Email: glenn.parsons@ericsson.com 1403 Peter Ashwood-Smith 1404 Huawei Technologies 1405 303 Terry Fox Drive, Suite 400 1406 Ottawa ON, K2K 3J1 1407 Canada 1409 Email: Peter.AshwoodSmith@huawei.com 1411 Chris Bowers 1412 Juniper Networks 1413 1194 N. Mathilda Ave. 1414 Sunnyvale, CA 94089 1415 US 1417 Email: cbowers@juniper.net