idnits 2.17.1 draft-ietf-isis-layer2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1504 has weird spacing: '...d Flags sub-...' == Line 1505 has weird spacing: '...d-VLANs sub...' == Line 1506 has weird spacing: '...dFwrdrs sub-t...' == Line 1507 has weird spacing: '...Options sub-t...' == Line 1516 has weird spacing: '...-Groups sub-...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o A bit, A bit when set declares this is an SPVID with auto allocation. If the VID value is zero. A VID will be allocated once the bridge has synchronized the IS-IS LSPs. Neighbor bridges can distribute the LSPs but MUST not populate filtering databases (forwarding) for traffic from a bridge that has an SPVID of 0. When the bridge allocating receives the complete LSPs from the IS-IS adjacency it will allocate one or more SPVIDs according to the allocation logic. It will then re-advertise this LSP with the allocated value. If bridges detect a collision of allocated SPVIDs the loosing bridge will have its forwarding removed just as if it was unallocated. When the originating bridge detects it is a loosing bridge in a collision it reallocates and simply re-advertises a new SPVID. A bridge SHOULD remember SPVID allocations through restarts by storing them in non volatile memory and therefore reuse the SPVID value. -- The document date (July 11, 2009) is 5403 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: 'RFC1195' is mentioned on line 104, but not defined == Missing Reference: 'TBD' is mentioned on line 1366, but not defined == Missing Reference: 'RFC5305' is mentioned on line 1092, but not defined == Missing Reference: 'REF' is mentioned on line 1189, but not defined == Unused Reference: 'RFC 1195' is defined on line 1594, but no explicit reference was found in the text == Unused Reference: 'RFC 5305' is defined on line 1603, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Obsolete normative reference: RFC 5306 (Obsoleted by RFC 8706) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Banerjee, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track July 11, 2009 5 Expires: January 12, 2010 7 Extensions to IS-IS for Layer-2 Systems 8 draft-ietf-isis-layer2-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 12, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document specifies the IS-IS extensions necessary to support 47 multi-link IPv4 and IPv6 networks, as well as to provide true link 48 state routing to any protocols running directly over layer 2. While 49 supporting this concept involves several pieces, this document only 50 describes extensions to IS-IS. We leave it to the systems using 51 these IS-IS extensions to explain how the information carried in 52 IS-IS is used. 54 Table of Contents 56 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . . . 4 59 2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 5 60 2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6 61 2.2.1. The Group MAC Address sub-TLV . . . . . . . . . . . . 6 62 2.2.2. The Group IP Address sub-TLV . . . . . . . . . . . . . 8 63 2.2.3. The Group IPv6 Address sub-TLV . . . . . . . . . . . . 10 64 2.3. Multi Topology aware Port Capability TLV . . . . . . . . . 12 65 2.3.1. The Special VLANs and Flags sub-TLV . . . . . . . . . 13 66 2.3.2. Enabled VLANs sub-TLV . . . . . . . . . . . . . . . . 14 67 2.3.3. Appointed Forwarders sub-TLV . . . . . . . . . . . . . 14 68 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV . . . . . . . . . 15 69 2.3.5. Base VLAN-Identifiers sub-TLV . . . . . . . . . . . . 16 70 2.4. Sub-TLVs for the Router Capability TLV . . . . . . . . . . 18 71 2.4.1. The TRILL Version sub-TLV . . . . . . . . . . . . . . 18 72 2.4.2. The Nickname sub-TLV . . . . . . . . . . . . . . . . . 18 73 2.4.3. The Trees sub-TLV . . . . . . . . . . . . . . . . . . 19 74 2.4.4. The Tree Roots Identifier Sub-TLV . . . . . . . . . . 20 75 2.4.5. The Tree Used Identifier Sub-TLV . . . . . . . . . . . 21 76 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV . . . 22 77 2.4.7. The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 23 78 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-tlv . . . . 24 79 2.5. Multi Topology Aware Capability TLV . . . . . . . . . . . 25 80 2.5.1. SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 26 81 2.5.2. Service Identifier and Unicast Address sub-TLV . . . . 29 82 2.6. SPB Link Metric sub-tlv . . . . . . . . . . . . . . . . . 30 83 3. The Multicast Group PDU . . . . . . . . . . . . . . . . . . . 31 84 3.1. The Multicast Group Partial Sequence Number PDU . . . . . 32 85 3.2. The Multicast Group Complete Sequence Number PDU . . . . . 32 86 3.3. Enhancements to the flooding process . . . . . . . . . . . 32 87 3.4. Enhancements to the maximum sequence number reached . . . 33 88 4. Considerations for Using L2 Information in IS-IS . . . . . . . 33 89 4.1. Building SPF Trees with Layer 2 Information . . . . . . . 33 90 4.2. Designated Intermediate Routers . . . . . . . . . . . . . 33 91 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 94 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 35 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 37 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 37 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 100 1. Overview 102 There are a number of systems (for example, [RBRIDGES], [802.1aq]) 103 that use layer 2 addresses carried in a link state routing protocol, 104 specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing 105 in specific environments. This document specifies a set of TLVs and 106 sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new PDU 107 types, to support these proposed systems. Some of these TLVs are 108 generic layer 2 additions and some are specific to [RBRIDGES] or to 109 [802.1aq]. This draft does not propose any new forwarding mechanisms 110 using this additional information carried within IS-IS. 112 This document specifies additional TLVs and sub-TLVs, to carry 113 unicast and multicast attached address information. It also proposes 114 additional TLVs and sub-TLVs to carry information as required by the 115 IETF RBridge and IEEE 802.1aq protocols. 117 This document specifies three new IS-IS PDUs, the Multicast Group 118 (MGROUP) PDU, for carrying a list of attached or joined multicast 119 groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) 120 PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU 121 packets are also defined to be used with the new MGROUP-PDU to 122 perform database exchange on the MGROUP PDU packets. 124 1.1. Terminology 126 The term "Hello" or "Hello PDU" in this document, when not further 127 qualified, includes both LAN IIH PDU and P2P IIH PDU. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119. 133 2. TLV and sub-TLV Enhancements to IS-IS 135 In this section we describe the enhancements that are being proposed 136 for the TLV and sub-TLVs as needed by Layer-2 technologies. 138 In particular, Sections 2.1 specifies the MAC-Reachability TLV; 139 Section 2.2 specifies the Group Address TLV and its sub-TLVs; Section 140 2.3 specifies the Port Capabilities TLV. These are expected to be of 141 generic use in current and future Layer-2 uses of IS-IS. We propose 142 enhancements to the Capability TLV in Section 2.4 and in Section 2.5 143 we propose a Multi Topology aware Capability TLV with its sub-TLVs. 145 2.1. The MAC-Reachability TLV 147 The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the 148 following format: 150 +-+-+-+-+-+-+-+-+ 151 | Type= MAC-RI | (1 byte) 152 +-+-+-+-+-+-+-+-+ 153 | Length | (1 byte) 154 +-+-+-+-+-+-+-+-+ 155 | Confidence | (1 byte) 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Topology-Id/ Nickname-Id | (2 bytes) 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | RESV | VLAN-ID | (2 bytes) 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | MAC (1) (6 bytes) | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | ................. | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | MAC (N) (6 bytes) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 o Type: TLV Type, set to 141 (MAC-RI). 170 o Length: Total number of bytes contained in the value field given 171 by 5 + 6*n bytes. 173 o Confidence: This carries an 8-bit quantity indicating the 174 confidence level in the MAC addresses being transported. Whether 175 this field is used, and its semantics if used, are further defined 176 by the specific protocol using Layer-2-IS-IS. If not used, it 177 must be set to zero on transmission and be ignored on receipt. 179 o Topology-Id/Nickname-Id: Depending on the technology in which it 180 is used, this carries the topology-id or nickname-id. When this 181 field is set to zero this implies that the MAC addresses are 182 reachable across all topologies or across all nicknames of the 183 originating IS. 185 o RESV: Must be sent as zero on transmission and is ignored on 186 receipt. 188 o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for 189 all subsequent MAC addresses in this TLV, or the value zero if no 190 VLAN is specified. 192 o MAC(i): This is the 48-bit MAC address reachable from the IS that 193 is announcing this TLV. 195 The MAC-RI TLV is carried in a standard Level 1 link state PDU. It 196 MUST contain only unicast addresses. 198 2.2. The Group Address TLV 200 The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the 201 following format: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |Type = GADDRTLV| Length | sub-TLVs | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 o Type: TLV Type, set to GADDR-TLV 142 [TBD]. 210 o Length: Total number of bytes contained in the value field, which 211 includes the length of the sub-tlvs carried in this TLV. 213 o sub-TLVs: The Group Address TLV value contains sub-TLVs formatted 214 as described in [RFC5305]. The sub-TLVs for this TLV are 215 specified in the following subsections. 217 The GADDR TLV is carried within Multicast Group Level 1 link state 218 PDU. 220 2.2.1. The Group MAC Address sub-TLV 222 The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS sub-TLV type 1 223 within the GADDR TLV and has the following format: 225 +-+-+-+-+-+-+-+-+ 226 | Type=GMAC-ADDR| (1 byte) 227 +-+-+-+-+-+-+-+-+ 228 | Length | (1 byte) 229 +-+-+-+-+-+-+-+-+ 230 | Confidence | (1 byte) 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Topology-Id/ Nickname-Id | (2 bytes) 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | RESV | VLAN-ID | (2 bytes) 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 |Num Group Recs | (1 byte) 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | GROUP RECORDS (1) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | ................. | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | GROUP RECORDS (N) | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 where each group record is of the form: 247 +-+-+-+-+-+-+-+-+ 248 | RESERVED | (1 byte) 249 +-+-+-+-+-+-+-+-+ 250 | Num of Sources| (1 byte) 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Group Address (6 bytes) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Source 1 Address (6 bytes) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Source 2 Address (6 bytes) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Source M Address (6 bytes) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 o Type: sub-TLV Type, set to 1 (GMAC-ADDR) of length 1 byte. 263 o Length: Total number of bytes contained in the value field. 265 o Confidence: This carries an 8-bit quantity indicating the 266 confidence level in the MAC addresses being transported. Whether 267 this field is used, and its semantics if used, are further defined 268 by the specific protocol using Layer-2-IS-IS. If not used, it 269 must be set to zero on transmission and be ignored on receipt. 271 o Topology-Id/Nickname-Id: Depending on the technology in which it 272 is used, this carries the topology-id or nickname-id. When this 273 field is set to zero this implies that the MAC addresses are 274 reachable across all topologies or across all nicknames of the 275 originating IS. 277 o RESV: Must be sent as zero on transmission and is ignored on 278 receipt. 280 o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for 281 all subsequent MAC addresses in this TLV, or the value zero if no 282 VLAN is specified. 284 o Number of Group Records: This is of length 1 byte and lists the 285 number of group records in this TLV. 287 o Group Record: Each group record has a reserved space and followed 288 by the number of sources, each of length 1 byte. It then has a 289 48-bit multicast Group Address followed by 48-bit source MAC 290 addresses. An address being a group multicast address or unicast 291 source address can be checked using the multicast bit in the 292 address. If the number of sources do not fit in a single sub-tlv, 293 it is permitted to have the same group address repeated with 294 different source addresses repeated in different sub-tlvs. 296 The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be 297 carried in a standard Level 1 link state MGROUP PDU. 299 2.2.2. The Group IP Address sub-TLV 301 The Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has 302 the following format: 304 +-+-+-+-+-+-+-+-+ 305 | Type=GIP-ADDR | 306 +-+-+-+-+-+-+-+-+ 307 | Length | (1 byte) 308 +-+-+-+-+-+-+-+-+ 309 | Confidence | (1 byte) 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Topology-Id/ Nickname-Id | (2 bytes) 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | RESV | VLAN-ID | (2 bytes) 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |Num Group Recs | (1 byte) 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | GROUP RECORDS (1) | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | ................. | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | GROUP RECORDS (N) | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 where each group record is of the form: 326 +-+-+-+-+-+-+-+-+ 327 | RESERVED | (1 byte) 328 +-+-+-+-+-+-+-+-+ 329 | Num of Sources| (1 byte) 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Group Address (4 bytes) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Source 1 Address (4 bytes) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Source 2 Address (4 bytes) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Source M Address (4 bytes) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 o Type: sub-TLV Type, set to 2 (GIP-ADDR). 342 o Length: Total number of bytes contained in the value field of the 343 TLV. 345 o Confidence: This carries an 8-bit quantity indicating the 346 confidence level in the IP addresses being transported. Whether 347 this field is used, and its semantics if used, are further defined 348 by the specific protocol using Layer-2-IS-IS. If not used, it 349 must be set to zero on transmission and be ignored on receipt. 351 o Topology-Id/Nickname-Id: Depending on the technology in which it 352 is used, this carries the topology-id or nickname-id. When this 353 field is set to zero this implies that the MAC addresses are 354 reachable across all topologies or across all nicknames of the 355 originating IS. 357 o RESV: Must be sent as zero on transmission and is ignored on 358 receipt. 360 o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for 361 all subsequent MAC addresses in this TLV, or the value zero if no 362 VLAN is specified. 364 o Number of Group Records: This is of length 1 byte and lists the 365 number of group records in this TLV. 367 o Group Record: Each group record has a reserved space and followed 368 by the number of sources, each of length 1 byte. It is followed 369 by a 32-bit IPv4 Group Address followed by 32-bit source IPv4 370 addresses. If the number of sources do not fit in a single sub- 371 tlv, it is permitted to have the same group address repeated with 372 different source addresses repeated in different sub-tlvs. 374 The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried 375 in a standard Level 1 link state MGROUP PDU. 377 2.2.3. The Group IPv6 Address sub-TLV 379 The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and 380 has the following format: 382 +-+-+-+-+-+-+-+-+ 383 |Type=GIPv6-ADDR| 384 +-+-+-+-+-+-+-+-+ 385 | Length | (1 byte) 386 +-+-+-+-+-+-+-+-+ 387 | Confidence | (1 byte) 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Topology-Id/ Nickname-Id | (2 bytes) 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | RESV | VLAN-ID | (2 bytes) 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |Num Group Recs | (1 byte) 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | GROUP RECORDS (1) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | ................. | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | GROUP RECORDS (N) | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 where each group record is of the form: 404 +-+-+-+-+-+-+-+-+ 405 | RESERVED | (1 byte) 406 +-+-+-+-+-+-+-+-+ 407 | Num of Sources| (1 byte) 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Group Address (16 bytes) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Source 1 Address (16 bytes) | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Source 2 Address (16 bytes) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Source M Address (16 bytes) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 o Type: sub-TLV Type, set to 3 (GIPV6-ADDR). 420 o Length: Total number of bytes contained in the value field. 422 o Confidence: This carries an 8-bit quantity indicating the 423 confidence level in the IPv6 addresses being transported. Whether 424 this field is used, and its semantics if used, are further defined 425 by the specific protocol using Layer-2-IS-IS. If not used, it 426 must be set to zero on transmission and be ignored on receipt. 428 o Topology-Id/Nickname-Id: Depending on the technology in which it 429 is used, this carries the topology-id or nickname-id. When this 430 field is set to zero this implies that the MAC addresses are 431 reachable across all topologies or across all nicknames of the 432 originating IS. 434 o RESV: Must be sent as zero on transmission and is ignored on 435 receipt. 437 o VLAN-ID: This carries a 12 bit VLAN identifier that is valid for 438 all subsequent MAC addresses in this TLV, or the value zero if no 439 VLAN is specified. 441 o Number of Group Records: This of length 1 byte and lists the 442 number of group records in this TLV. 444 o Group Record: Each group record has a reserved space and followed 445 by the number of sources, each of length 1 byte. It is followed 446 by a 128-bit multicast IPv6 Group Address followed by 128-bit 447 source IPv6 addresses. If the number of sources do not fit in a 448 single sub-tlv, it is permitted to have the same group address 449 repeated with different source addresses repeated in different 450 sub-tlvs. 452 The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be 453 carried in a standard Level 1 link state MGROUP PDU. 455 2.3. Multi Topology aware Port Capability TLV 457 The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS 458 TLV type 143 [TBD], and has the following format: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |Type=MT PORTCAP| Length |O|R|R|R| Topology Identifier | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | sub-TLVs | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 o Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD]. 469 o Length: Total number of bytes contained in the value field, 470 including the length of the sub-TLVs carried in this TLV. 472 o O bit: The overload bit that follows the semantics associated with 473 an overloaded intermediate system. 475 o Topology Identifier: MT ID is a 12-bit field containing the MT ID 476 of the topology being announced. This field when set to zero 477 implies that it is being used to carry base topology information. 479 In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, 480 it may be non-zero. 482 o sub-TLVs: The MT aware Port Capabilities TLV value contains sub- 483 TLVs formatted as described in [RFC5305]. They are defined in the 484 next sections. 486 The MT aware PORT-CAP-TLV MUST be carried only within a LAN IIH PDU, 487 or a P2P IIH PDU. It may occur multiple times in a Hello PDU. 489 2.3.1. The Special VLANs and Flags sub-TLV 491 The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST appear 492 exactly once in a MT aware Port Capability TLV in every LAN IIH PDU. 493 It has the following format: 494 0 1 2 3 4 - 15 16 - 19 20 - 31 495 +----+----+----+----+------------+----------+------------+ 496 | AF | AC | VM | BY | Outer.VLAN | Reserved | Desig.VLAN | 497 +----+----+----+----+------------+----------+------------+ 499 o Type: TLV Type, set to VLAN and Flags sub-TLV 1 [TBD]. 501 o Length: 4 - Number of bytes contained in the value field. 503 o The first and second bytes have a copy of the Outer VLAN ID 504 associated with the Hello frame when it was sent. The lower 4 505 bits of the first byte give the upper ID bits of the VLAN ID and 506 the second byte gives the lower VLAN ID bits. 508 o The upper 4 bits of the first byte are flag bits as shown. The AF 509 bit, if one, indicates that the sending Intermediate System 510 believes it is Appointed Forwarder for the VLAN and port on which 511 the Hellos was sent. The AC bit, if one, indicates that the 512 sending port is configured as an access port. The VM bit, if a 513 one, indicates that the sending Intermediate System has detected 514 VLAN mapping within the link. The BY bit, if set, indicates 515 bypass psuedonode. 517 o The third and forth bytes give the Designated VLAN for the link. 518 The lower 4 bits of the third byte give the upper ID bits of the 519 Designated VLAN and the forth byte gives the lower VLAN ID bits. 520 The upper 4 bits of the third byte are reserved and MUST be sent 521 as zero and ignored on receipt. 523 The VLAN and Flags sub-TLV is carried within the MT aware PORT-CAP 524 TLV and MUST be carried in LAN IIH PDU. It MUST NOT be carried 525 within a P2P IIH PDU. 527 2.3.2. Enabled VLANs sub-TLV 529 The Enabled VLAN sub-TLV specifies the VLANs enabled for end station 530 service at the port on which the Hello was sent. 532 o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 2 [TBD]. 534 o Length: variable, depending on contents described next. 536 o The minimum size of the value is 3 bytes. The third and 537 subsequent bytes provide a bit map of enabled VLANs starting at 538 the VLAN ID indicated in the first two bytes. The lower order 539 four bits of the first byte give the upper bits of the starting 540 VLAN ID and the second byte gives the lower bits of that VLAN ID. 541 The upper four bits of the first byte are reserved and MUST be 542 sent as zero and ignored on receipt. The highest order bit of the 543 third byte indicates the VLAN equal to the starting ID while the 544 lowest order bit of the third byte indicated that ID plus 7. For 545 example, VLANs 1 and 14 being enabled for end station service 546 could be encoded in 4-bytes value 0x00 0x01 0x80 0x04 or, 547 alternatively, as 0x00 0x00 0x40 0x02. 549 This sub-TLV may occur more than once in a Hello and a VLAN is 550 enabled for end station service on the port where the Hellos was sent 551 if this is indicated by any occurrence in the Hello. For example, a 552 receiver could allocate a 512-byte buffer and, with appropriate 553 shifting operations, OR in the enabled bits for each subTLV of this 554 type it finds in a Hello to derive the complete bit map of these 555 VLANs. 557 The Enabled VLAN sub-TLV is carried within the MT aware PORT-CAP TLV 558 and MUST be carried in LAN IIH PDU. It MUST NOT be carried within a 559 P2P IIH PDU. 561 2.3.3. Appointed Forwarders sub-TLV 563 The Appointed Forwarder sub-TLV provides the mechanism by which the 564 Designated Intermediate System can inform other Intermediate Systems 565 on the link that they are the designated VLAN-x forwarder for that 566 link for one or more ranges of VLAN IDs. 568 o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 3 [TBD]. 570 o Length: The size of the value is 6*n bytes where there are n 571 appointments. Each 6-byte part of the value is formatted as 572 follows: 574 +----------------+-----+-----+---------+-----+----+---------+ 575 | byte 1 - 2 | byte 3 | byte 4 | byte 5 | byte 6 | 576 +----------------+-----+-----+---------+-----+----+---------+ 577 | Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID | 578 +----------------+-----+-----+---------+-----+----+---------+ 580 o The appointed forwarder Intermediate System is specified by its 581 nickname in the first two bytes. 583 o The "Res" fields of 4 bits each are reserved and MUST be sent as 584 zero and ignored on receipt. 586 The VLAN range given is inclusive. To specify a single VLAN, that 587 VLAN ID appears as both the start and end VLAN. The Intermediate 588 System whose nickname is given is appointed forwarder for those VLANs 589 for which it has end station service enabled (see item 2 above) in 590 the inclusive range. For example, assume an Intermediate System with 591 end station service enabled on VLANs 100, 101, 199, and 200 (and 592 possibly other VLANs less than 100 or greater than 200), but not 593 enabled for VLANs 102 through 198. It could be appointed forwarder 594 for these four VLANs through either (1) a single 6-byte value 595 sequence with start and end VLAN IDs of 100 and 200, or (2) a 12-byte 596 value sequence with start and end VLAN IDs of 100 and 101 in the 597 first part and 199 and 200 in the second part. 599 An Intermediate System's nickname may occur as appointed forwarder 600 for multiple VLAN ranges within the same or different Port Capability 601 TLVs within a Designated Intermediate Systems's Hello. In the 602 absence of appointed forwarder sub-TLVs referring to a VLAN, the 603 Designated Intermediate System acts as the appointed forwarder for 604 that VLAN if end station service is enabled. 606 The Appointed Forwarder sub-TLV is carried within the MT aware PORT- 607 CAP TLV and MUST be carried in a LAN IIH PDU. This MUST NOT be 608 carried in a P2P IIH PDU. 610 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV 612 By including this sub-TLV within one or more MT aware Port Capability 613 TLVs in its Hellos, an Intermediate System can advertise the Hop-by- 614 Hop options it supports on the port through which it sends the Hello. 615 This sub-TLV may appear zero or more times within a MT aware Port 616 Capability TLV. By default, in the absence of any HBHOPT sub-TLVs, 617 no Hop-by-Hop options are supported. 619 There are two types of Hop-by-Hop option encoding within the TRILL 620 Header: bit options and TLV encoded options. 622 The bit-encoded options supported are indicated by an HBHOPT sub-TLV 623 of length 3: an initial value byte of 0xFF followed by four bytes in 624 which each bit indicates that the corresponding bit option is 625 implemented; in those four bytes the top two bits (0xC0000000) are 626 critical option summary bits that all RBridges MUST understand. 627 Those two bits are reserved in the HBHOPT sub-TLV and must be sent as 628 zero are ignored on receipt. 630 The implementation of a TLV encoded option is indicated by an HBHOPT 631 sub-TLV whose value starts with a byte equal to the first byte of the 632 option. Such HBHOPT sub-TLVs may have additional value bytes further 633 indicating how the option is supported as specified with the option's 634 definition, for example a list of supported security algorithms. 636 +-+-+-+-+-+-+-+-+ 637 | Type = HBHOPT | 638 +-+-+-+-+-+-+-+-+ 639 | Length | (1 byte) 640 +-+-+-+-+-+-+-+-+ 641 | Option | (1 byte) 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Option dependent variable length information | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 o Type: sub-TLV Type, set to Hop-by-Hop sub-TLV 4 [TBD]. 648 o Length: variable, minimum 1. 650 o Value: The first byte of the option followed by option dependent 651 information. 653 2.3.5. Base VLAN-Identifiers sub-TLV 655 This sub-TLV is added to an IIH PDU to indicate the algorithms for 656 the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) are in 657 use. This information should be the same on all bridges in the 658 topology identified by MT-PORT-CAP TLV it is being carried. 659 Discrepancies between neighbours with respect to this sub-TLV are 660 temporarily allowed but the Base-VID must agree and use a spanning 661 tree algorithm. 663 +-+-+-+-+-+-+-+-+ 664 |Type = B-VID | 665 +-+-+-+-+-+-+-+-+ 666 | Length | (1 byte) 667 +-+-+-+-+-+-+-+-+ 668 |M|B| RESERVED | (1 byte) 669 +-+-+-+-+-+-+-+-+-------------------------------- 670 | VID Tuple (1) (4 bytes) | 671 +-----------------------------------------------+ 672 | ......................... | 673 +-----------------------------------------------+ 674 | VID Tuples (N) (4 bytes) | 675 +-----------------------------------------------+ 677 o Type: sub-TLV Type, set to Base-VALN-ID sub-TLV 5 [TBD]. 679 o Length: The size of the value is VID Tuples*4 + 1 bytes. Each 680 4-byte part of the N-VID tuple is formatted as follows: 682 0 1 - 3 4 - 15 16 - 19 20 - 31 683 +-+----------+-------+-----------+------------+ 684 |A| Reserved | VID | Algorithm | B-VID | 685 +-+----------+-------+-----------+------------+ 687 o The M bit when set indicates that the Mode is Shortest Path VIDs 688 one VID per tree. When clear this bit indicates that this is 689 using single VIDs. Neighboring bridges must have matching 690 configuration or the adjacency is rejected. 692 o The B Bit when set indicates this is Backbone Bridging 693 alternatively when clear this bit indicates this is Shortest path 694 bridging. 696 o Combinations of the M and B bits are specified in the [IEEE 697 802.1aq]. 699 o Algorithm: Specifies the tie breaking algorithm to be used for 700 this VID. Currently only the following values are supported: 702 * ALG = 0 a spanning tree. 704 * ALG = 1 the Low PATHID algorithm is used for this VID. 706 * ALG = 2 the High PATHID algorithm is used. 708 o A bit when set declares this an SPVID with auto allocation. 710 o VID is the VID for which the given algorithm applies, see [IEEE 711 802.1aq]. 713 o B-VID is the B-VID for which the given algorithm applies, see 714 [IEEE 802.1aq]. 716 o The "Reserved" fields MUST be sent as zero and ignored on receipt. 718 The Base VLAN-Identifier sub-TLV is carried within the MT aware PORT- 719 CAP TLV and this is carried in a IIH PDU. 721 2.4. Sub-TLVs for the Router Capability TLV 723 The Router Capability TLV is an optional TLV [RFC 4971] that may be 724 generated by the originating Intermediate System. We specify these 725 additional sub-TLVs that can be carried in it. These sub-TLVs 726 announce the capabilities of the Intermediate System for the entire 727 IS-IS routing domain. 729 2.4.1. The TRILL Version sub-TLV 731 The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL 732 Versions. The device announces the maximum version of TRILL, it is 733 capable of supporting, including lower versions. In the event, this 734 sub-TLV is missing, this implies that the node can only support the 735 base version of the protocol. 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Type | Length | Reserved | Max-version | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 o Type: sub-TLV Type, set to 5 (TRILL-VER). 744 o Length: 2 - Total number of bytes contained in the TLV. 746 o Reserved: Set to zero on transmission and ignored on receipt. 748 o Max-version: Set to application dependent values. 750 2.4.2. The Nickname sub-TLV 752 The Nickname (NICK) sub-TLV carries information about the nicknames 753 of the advertising device, along with information about its priority 754 to hold those nicknames. The Nickname sub-TLV MUST be carried within 755 the Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated 756 by the originating IS. 758 +-+-+-+-+-+-+-+-+ 759 |Type = NICKNAME| 760 +-+-+-+-+-+-+-+-+ 761 | Length | (1 byte) 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | NICKNAME RECORDS (1) | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | ................. | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | NICKNAME RECORDS (N) | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 where each nickname record is of the form: 772 +-+-+-+-+-+-+-+-+-+ 773 | Priority | (1 byte) 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Nickname | (2 bytes) 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 o Type: TLV Type, set to 6 (NICK). 780 o Length: Total number of bytes contained in the TLV. 782 o Priority: Set to application dependent values. 784 o Nickname: This is an unsigned 16-bit integer that gives device 785 identifier or alias. 787 Each nickname record consists of a one-byte priority set to 788 application dependent values, and two bytes of device identifier or 789 alias (i.e., actual nickname). 791 2.4.3. The Trees sub-TLV 793 The Trees sub-TLV MUST occur only once and can be carried within the 794 Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by 795 the originating IS. Each device announces four numbers: its own 796 priority to be a multi-destination frame distribution tree root; the 797 number of trees it dictates that all other Intermediate Systems in 798 the campus compute if it is the highest priority tree root; the 799 maximum number of trees it is able to compute; and the number of 800 distribution trees it wishes to be able to use in forwarding multi- 801 destination traffic. 803 Once a node receives a new LSP, it runs an election algorithm, 804 independently of the other nodes in the network, to determine if it 805 is the highest priority root. The node that announced the 806 numerically highest priority to become a tree root is elected the to 807 be the highest priority tree root. If two devices advertise the same 808 priority, the device with the higher system ID has the higher 809 priority to be a tree root. The elected highest priority tree root 810 dictates the number of distribution tree roots to be used in the 811 network domain and can list those roots in the tree roots identifier 812 sub-TLV. 814 +-+-+-+-+-+-+-+-+ 815 |Type = TREE | 816 +-+-+-+-+-+-+-+-+ 817 | Length | (1 byte) 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Tree Root Priority | (2 byte) 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Number of trees to compute | (2 byte) 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Maximum trees able to compute | (2 byte) 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Number of trees to use | (2 byte) 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 o Type: sub-TLV Type, set to 7 (TREE). 830 o Length: 6 : Total number of bytes contained in the value field. 832 o Tree Root Pri: This is an unsigned 16-bit integer that gives the 833 value of the priority with which this node wants to be the highest 834 priority root node in the Layer-2 domain. 836 o Number of trees to compute: This is an unsigned 16-bit integer 837 that gives the requested number of distribution trees for multi- 838 destination frames that will be in use in the Layer-2 domain, if 839 this device becomes the highest priority tree root in the domain. 841 o Maximum number of tree able to compute: This is an unsigned 16-bit 842 integer that give the maximum number of threes that the 843 originating IS is able to compute for the campus. 845 o Number of trees to use: This is an unsigned 16-bit integer that 846 gives the number of distribution trees the originating IS wishes 847 to be able to use. 849 2.4.4. The Tree Roots Identifier Sub-TLV 851 The tree root identifier sub-TLV is is an ordered list of nicknames. 852 When originated by the Intermediate System which is the highest 853 priority tree root, this list is the tree roots for which other 854 Intermediate Systems are required to compute trees. If this 855 information is spread across multiple sub-tlvs, the starting tree 856 root identifier is used to figure out the ordered list. It is 857 carried within the CAPABILITY TLV in a level-1 non-pseudo-node LSP 858 and is given as: 860 +-+-+-+-+-+-+-+-+ 861 |Type=TREE-RT-ID| 862 +-+-+-+-+-+-+-+-+ 863 | Length | (1 byte) 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 |Starting Tree Root Identifier| (2 bytes) 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Nickname (K-th root) | (2 bytes) 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Nickname (K+1 - th root) | (2 bytes) 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Nickname (...) | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 o Type: sub-TLV Type, set to 8 (TREE-RT-IDs). 876 o Length: Total number of bytes contained in the value field. 878 o Starting Tree Root Identifier: This identifies the starting tree 879 root identifier of the nicknames which are roots for the domain. 880 This is set to 1 for the first sub-TLV. The starting value and 881 the length field gives the number of nicknames being carried in 882 the sub-TLV. In the event a tree identifier can be computed from 883 two such sub-TLVs and are different, then it is assumed that this 884 is a transient condition which will get cleared. 886 o Nickname: The nickname associated with a Intermediate System id on 887 which this tree is based. 889 A locally significant hash may be used by edge devices to determine 890 which multicast root (or set of multicast roots) is used to send 891 traffic for a specific multicast group. If there is a discrepancy 892 between the number of multi-destination trees the broadcast-root has 893 announced, and the number of roots the root-identifier sub-tlv 894 carries, nodes MUST compute trees for the additional roots. 896 2.4.5. The Tree Used Identifier Sub-TLV 898 This sub-TLV has the same structure as the Tree Roots Identifier Sub- 899 TLV specified in the above section. The only difference is that its 900 sub-TLV type is set to 9 TBD (TREE-USE-IDs) and the roots listed are 901 only those that the originating intermediate systems wishes to use. 903 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV 905 The value of this sub-TLV consists of a VLAN range, flags, and a 906 variable length list of spanning tree root bridge IDs. This sub-TLV 907 may appear zero, one, or many times. The union of the VLAN ranges in 908 all occurrences MUST be precisely the set of VLANs for which the 909 originating Intermediate System is appointed forwarder on at least 910 one port and the VLAN ranges in multiple VLANs sub-TLVs for an 911 Intermediate System MUST NOT overlap. That is, the intersection of 912 the VLAN ranges for any pair of these sub-TLVs originated by an 913 Intermediate System must be null. The value length is 4 + 6*n where 914 n is the number of root bridge IDs. The initial 4 bytes of value are 915 as follows: 917 +-+-+-+-+-+-+-+-+ 918 |Type = INT-VLAN| 919 +-+-+-+-+-+-+-+-+ 920 | Length | (1 byte) 921 +---------------+-----+ 922 | Nickname-Id | (2 bytes) 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Interested VLANS | (8 bytes) 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Root Bridges | (6*n bytes) 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 o Type: sub-TLV Type, set to 10 (INT-VLAN). 931 o Length: Total number of bytes contained in the value field. 933 o Nickname Id: If this is set to 0, then it applies to all device- 934 ids generated by the node. It may alternatively be set to a 935 specific nickname-id, in the event a node wants to segregate 936 traffic using multiple device-ids. 938 o Interested VLANS: In the Interested VLANs, as shown below, the M4 939 bit indicates that there is an IPv4 multicast router on a link for 940 which the originating Intermediate System is appointed forwarder 941 for every VLAN in the indicated range. The M6 bit indicates the 942 same for an IPv6 multicast router. The R and Reserved bits MUST 943 be sent as zero and are ignored on receipt. The VLAN start and 944 end IDs are inclusive. A range of one VLAN ID is indicated by 945 setting them both to that VLAN ID value. It has the following 946 format: 948 0 1 2 3 4 - 15 16 - 19 20 - 31 949 +----+----+----+----+------------+----------+------------+ 950 | M4 | M6 | R | R | VLAN start | Reserved | VLAN end | 951 +----+----+----+----+------------+----------+------------+ 952 | Appointed Forwarder Status Lost Counter | 953 +----+----+----+----+------------+----------+------------+ 955 o Root Bridges: The list of zero or more spanning tree root bridge 956 IDs is the set of root bridge IDs seen for all ports for which the 957 Intermediate System is appointed forwarder for the VLANs in the 958 range. This information is learned from BPDUs heard by the 959 Intermediate System. If MSTP is in use on a link, the root bridge 960 referred to is the CIST (common and internal spanning tree) root 961 bridge. (While, of course, only one spanning tree root should be 962 seen on any particular port, there may be multiple ports in the 963 same VLAN connected to differed bridged LANs with different 964 spanning tree roots.) If no spanning tree roots can be seen on 965 any of the links in any of the VLANs in the range indicated for 966 which the Intermediate System is appointed forwarder (for example 967 all such links are point-to-point links to other Intermediate 968 Systems or to end stations so no BPDUs are received) then the 969 listed set of spanning tree root IDs will be null. 971 If there are any two VLANs in the range indicated for which the value 972 of the M4, or M6 bits are different, the sub-TLV is incorrect and 973 must be split into multiple sub-TLVs each indicating only VLANs with 974 the same M4, and M6 values. If there are any two VLANs in the range 975 indicated for which the set of root bridge IDs see on all links for 976 which the Intermediate System is appointed forwarder for the VLAN are 977 not the same, the sub-TLV is incorrect and must be split into 978 multiple subTLVs each indicating only VLANs with the same set of DRB 979 seen root bridge IDs. It is always safe to use sub-TLVs with a 980 "range" of one VLAN ID but this may be too verbose. 982 This sub-TLV is carried within the CAPABILITY TLV in a level-1 non- 983 pseudo-node LSP. 985 2.4.7. The VLAN Group sub-TLV 987 The VLAN Group sub-TLV consists of two or more 16-bit fields each of 988 which has a VLAN ID in the low order 12 bits. The top 4 bits MUST be 989 sent as zero and ignored on receipt. The first such VLAN ID is the 990 primary, or may be zero if there is no primary. It is carried within 991 the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is given as: 993 +-+-+-+-+-+-+-+-+ 994 |Type=VLAN-GROUP| 995 +-+-+-+-+-+-+-+-+ 996 | Length | (1 byte) 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | VLAN-GROUP RECORDS (1) | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | ................. | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | VLAN-GROUP RECORDS (N) | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 where each VLAN group record is of the form: 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Primary VLAN ID (2 bytes) | Secondary VLAN ID (2 bytes) | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 o Type: TLV Type, set to 11 (VLAN-GROUPs). 1013 o Length: Total number of bytes contained in the value field. 1015 o Primary VLAN-ID: This identifies the primary VLAN-ID. 1017 o Secondary VLAN-ID: This identifies the secondary VLAN-ID, address 1018 learning is shared at the Intermediate System that announces this 1019 sub-tlv. 1021 This sub-TLV may appear zero, one, or multiple times. 1023 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-tlv 1025 By including this sub-TLV within one or more Router Capability TLVs 1026 in its LSPs, an RBridge can advertise the Ingress-to-Egress options 1027 it supports. This sub-TLV may appear zero or more times within a 1028 Router Capability TLV. By default, in the absence of any ITEOPT sub- 1029 TLVs, no Ingress-to-Egress options are supported. 1031 All Ingress-to-Egress options are TLV encoded within the TRILL Header 1032 options area. The implementation of a TLV encoded option is 1033 indicated by an ITEOPT sub-TLV whose value starts with a byte equal 1034 to the first byte of the option. Such ITEOPT sub-TLVs may have 1035 additional value bytes further indicating how the option is supported 1036 as specified in the option's definition, for example a list of 1037 supported security algorithms. 1039 +-+-+-+-+-+-+-+-+ 1040 | Type = ITEOPT | 1041 +-+-+-+-+-+-+-+-+ 1042 | Length | (1 byte) 1043 +-+-+-+-+-+-+-+-+ 1044 | Option | (1 byte) 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Option dependent variable length information | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 o Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12 1050 [TBD]. 1052 o Length: variable, minimum 1. 1054 o Value: The first byte of the option followed by option dependent 1055 information. 1057 2.5. Multi Topology Aware Capability TLV 1059 This section defines a new optional Intermediate System to 1060 Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of 1061 multiple sub-TLVs, which allows a router to announce its capabilities 1062 for a particular topology within an IS-IS level or the entire routing 1063 domain. This is different from Capability TLV defined in RFC 4971, 1064 in the sense, the capabilities announced here are topology scoped. 1066 The Multi Topology Aware Capability (MT-CAPABILITY) is an optional 1067 IS-IS TLV type 144 [TBD], that may be generated by the originating IS 1068 and has the following format: 1069 0 1 2 3 1070 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 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 |Type=MTCAPABTLV| Length |O|R|R|R| Topology Identifier | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | sub-TLVs | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 o Type: TLV Type, set to MT-CAPABILITY TLV 144 [TBD]. 1079 o Length: Total number of bytes contained in the value field, 1080 including the length of the sub-TLVs carried in this TLV. 1082 o O bit: The overload bit that follows the semantics associated with 1083 an overloaded intermediate system. 1085 o Topology Identifier: MT ID is a 12-bit field containing the MT ID 1086 of the topology being announced. This field when set to zero 1087 implies that it is being used to carry base topology information. 1088 In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, 1089 it may be non-zero. 1091 o sub-tlvs: The MT aware Capabilities TLV value contains sub-TLVs 1092 formatted as described in [RFC5305]. They are defined in the next 1093 sections. 1095 The MT-aware CAPABILITY TLV MUST be carried only within a LSP PDU. 1096 It may occur multiple times in a LSP PDU. 1098 2.5.1. SPB Instance sub-TLV 1100 The SPB Instance sub-TLV gives the SPSourceID for this node/topology 1101 instance. This is the 20 bit value that is used in the formation of 1102 multicast DA addresses for packets originating from this node/ 1103 instance. The SPSourceID occupies the upper 20 bits of the multicast 1104 DA together with 4 other bits (see the SPB 802.1ah multicast DA 1105 address format section). 1107 This TLV SHOULD be carried within the fragment ZERO LSP. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 |S| reserved | N-VID | (2 bytes) 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | VLAN-ID (1) Tuples | (4 bytes) 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | VLAN-ID (N) Tuples | (4 bytes) 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 |R R R R| SPS Flags |V| SPSOURCEID | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Reserved (Auto Allocation Tiebreaker) | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Bridge Identifier | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Bridge Identifier (cont) | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | CIST Root Identifier | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | CIST Root Identifier (cont) | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | CIST External ROOT Path Cost | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 where VLAN-ID tuples have the format as: 1135 0 1 2- 3 4 - 15 16 - 19 20 - 31 1136 +-+-+---------+-------+-----------+------------+ 1137 |A|U|Reserved | VID | Algorithm | B-VID | 1138 +-+-+---------+-------+-----------+------------+ 1140 o Type: TLV Type, set to SPB Instance sub-TLV 1 [TBD]. 1142 o Length: Total number of bytes contained in the value field. 1144 o S bit indicates the presence of sub-TLVs following this value. 1146 o The N-VID must be set to the number of VIDs tuples that follow. 1147 This allows the sub-TLV starting point to be found. Note N-VID 1148 here does not include the Base VID. 1150 o Each VID Tuple consists of: 1152 o ALG specifies the tie breaking algorithm to be used for this VID. 1153 Currently only the following values are supported: 1155 * ALG = 0 a spanning tree. 1157 * ALG = 1 the Low PATHID algorithm is used for this VID. 1159 * ALG = 2 the High PATHID algorithm is used. 1161 o VID is the VID for which the given algorithm applies. This 1162 structure is used to indicate both shortest path VIDs and Single 1163 VIDs in the Case of SPBB. Note the VID represents the SPVID 1164 associated with SPT Set. More details are in [REF]. 1166 o U bit, when set indicates that there are I-SIDs that locally use 1167 the VID associated with this SPT SET. This U bit is used to avoid 1168 taking actions that would adversely affect traffic network wide. 1170 o A bit, A bit when set declares this is an SPVID with auto 1171 allocation. If the VID value is zero. A VID will be allocated 1172 once the bridge has synchronized the IS-IS LSPs. Neighbor bridges 1173 can distribute the LSPs but MUST not populate filtering databases 1174 (forwarding) for traffic from a bridge that has an SPVID of 0. 1175 When the bridge allocating receives the complete LSPs from the 1176 IS-IS adjacency it will allocate one or more SPVIDs according to 1177 the allocation logic. It will then re-advertise this LSP with the 1178 allocated value. If bridges detect a collision of allocated 1179 SPVIDs the loosing bridge will have its forwarding removed just as 1180 if it was unallocated. When the originating bridge detects it is 1181 a loosing bridge in a collision it reallocates and simply re- 1182 advertises a new SPVID. A bridge SHOULD remember SPVID 1183 allocations through restarts by storing them in non volatile 1184 memory and therefore reuse the SPVID value. 1186 o The SPSOURCEID is a 20 bit value used to construct multicast DA's 1187 as described below for multicast packets originating from the 1188 origin (SPB node) of the link state packet (LSP) that contains 1189 this TLV. More details are in [REF]. 1191 o The Auto Allocation Tie Breaker is a reserved field that would 1192 allow collisions in SPSOURCEID to be resolved. If these fields 1193 are equal then the Bridge Priority takes precedence and if Bridge 1194 Priority is equal then the numerically higher Bridge ID wins. The 1195 V bit indicates this SPSOURCEID is auto allocated. Note 1196 SPSOURCEIDs are only used in the case of Backbone Brides with 1197 single VIDs ( Base-VID TLV B bit = 1 and M bit = 0). Single VIDS 1198 are not auto allocated. If the A bit is clear the SPSOURCEID has 1199 been configured and must be unique. When the bridge allocating 1200 receives the complete LSP from the IS-IS adjacency it will 1201 allocate a SPSOURCEID according to the allocation logic. It will 1202 then re-advertise this LSP with the allocated value. If bridges 1203 detect a collision of allocated SPSOURCEIDs the loosing bridge 1204 (determined by the tie breaking algorithm) will have its 1205 forwarding removed just as if it was unallocated. When the 1206 originating bridge detects it is a loosing bridge in a collision 1207 it reallocates and simple re-advertises a new SPSOURCEID. A 1208 bridge SHOULD remember SPSOURCEID allocations through restarts by 1209 storing them in non volatile memory and reuse the SPSOURCEID 1210 value. 1212 o Bridge Identifier is the Spanning tree compatible Bridge 1213 identifier. This is configured exactly as specified in IEEE802 1214 [802.1D]. This allows SPB to build a compatible Spanning tree 1215 using link state. 1217 o The four most significant bits of the most significant byte of a 1218 Bridge Identifier comprise a settable priority component that 1219 permits the relative priority of Bridges to be managed. The next 1220 most significant twelve bits of a Bridge Identifier (the four 1221 least significant bits of the most significant byte, plus the 1222 second most significant byte) comprise a locally assigned system 1223 ID extension. The six least significant bytes ensure the 1224 uniqueness of the Bridge identifier; they shall be derived from 1225 the globally unique Bridge Address according to the following 1226 procedure. The third most significant byte is derived from the 1227 initial byte of the MAC Address; the least significant bit of the 1228 byte (Bit 1) is assigned the value of the first bit of the Bridge 1229 Address, the next most significant bit is assigned the value of 1230 the second bit of the Bridge Address, and so on. The fourth 1231 through eighth bytes are similarly assigned the values of the 1232 second to the sixth bytes of the Bridge Address. 1234 o CIST Root Identifier is for SPB interworking with RSTO and MSTP at 1235 SPT Region Boundaries. This is an imported value from a Spanning 1236 tree. 1238 o CIST External Root Path Cost is the cost from the Spanning tree 1239 algorithm to the Root. 1241 2.5.2. Service Identifier and Unicast Address sub-TLV 1243 The SPB Service Identifier and Unicast Address TLV is used to 1244 introduce service group membership on the originating node and/or to 1245 advertise an additional B-MAC unicast address present on, or 1246 reachable by the node. 1248 0 1 2 3 1249 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 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | B-MAC ADDRESS | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | B-MAC ADDRESS (cont) | Res. | VID | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 |T|R| Reserved | ISID #1 | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 |T|R| Reserved | ISID #2 | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 |T|R| Reserved | ISID #n | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 o Type: TLV Type, set to Service Identifier and Unicast Address sub- 1263 TLV 2 [TBD]. 1265 o Length: Total number of bytes contained in the value field. 1267 o B-MAC ADDRESS is a unicast address of this node. It may be either 1268 the single nodal address, or may address a port or any other level 1269 of granularity relative to the node. In the case where the node 1270 only has one B-MAC address this should be the same as the SYS-ID 1271 of the node. To add multiple B-MACs this TLV must be repeated per 1272 additional B-MAC. 1274 o ISID #1 .. #N are 24 bit service group membership identifiers. If 1275 two nodes have an ISID in common, intermediate nodes on the unique 1276 shortest path between them will create forwarding state for the 1277 related B-MAC addresses and will also construct multicast 1278 forwarding state using the ISID and the node's SPSOURCEID to 1279 construct a multicast DA as described in IEEE 802.1aq LSB. Each 1280 ISID has a Transmit(T) and Receive(R) bit which indicates if the 1281 membership is as a Transmitter/Receiver or both (with both bits 1282 set). In the case where the Transmit(T) and Receive(R) bits are 1283 both zero, the ISID is ignored. If more ISIDs are associated with 1284 a particular B-MAC than can fit in a single TLV, this TLV can be 1285 repeated with the same B-MAC but with different ISID values. 1287 2.6. SPB Link Metric sub-tlv 1289 The SPB Link Metric Sub TLV occurs nested as within the Extended 1290 Reachability TLV (type 22), or the Multi Topology Intermediate System 1291 TLV (type 222). If this sub TLV is not present for an ISIS adjacency 1292 then that adjacency MUST NOT carry SPB traffic for the given topology 1293 instance. 1295 0 1 2 3 1296 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 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Reserved (must be 0) | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 | SPB-LINK-METRIC | Num port ID | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Port Identifier | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 o Type: TLV Type, set to SPB Link Metric sub-TLV 5 [TBD]. 1307 o Length: Total number of bytes contained in the value field. 1309 o SPB-LINK-METRIC indicates the administrative cost or weight of 1310 using this link as a 24 bit unsigned number. Smaller numbers 1311 indicate lower weights and are more likely to carry SPB traffic. 1312 Only one metric is allowed per SPB instance per link. If multiple 1313 metrics are required multiple SPB instances are required, either 1314 within IS-IS or within several independent IS-IS instances. 1316 o Num of Ports is the number of ports associated with this link. 1318 o Port Identifier is the standard IEEE port identifier used to build 1319 a spanning tree associated with this link. 1321 SPB routes follow the minimum sum of link metrics from the source to 1322 the destination. If any SPB link metric is not the same as its 1323 reverse direction metric the metric for both directions of the above 1324 calculation is considered to be the maximum of the two differing 1325 metrics. If an SPB metric TLV is missing from one or both directions 1326 of an adjacency no SPB traffic may flow between those nodes for the 1327 corresponding SPB topology instance (MT-ID). In the event of two or 1328 more equal minimum sum of link metrics paths, the unique shortest 1329 path is chosen according to the symmetric tie breaking algorithm Low- 1330 PATHID and/or High-PATHID as described in IEEE 802.1aq LSB. When a 1331 single SPB instance is used this TLV occurs as a sub-TLV of TLV 22 1332 but when multiple instances are used it must be present as a sub-TLV 1333 of the Multi Topology Intermediate System Tlv (type 222) with the 1334 appropriate MT-ID to correlate it with the other top level TLV's used 1335 to specify the SPB topology instance in question. 1337 3. The Multicast Group PDU 1339 The systems that this dcoument is concerned with want to carry not 1340 only layer-2 unicast information in the link state protocols, but 1341 also multicast information. This document specifies three new IS-IS 1342 PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of 1343 attached or joined multicast groups. The Multicast Group Complete 1344 Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial 1345 Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used 1346 with the new MGROUP-PDU to perform database exchange on the MGROUP 1347 PDU packets. 1349 In the Layer-2 environment, it is expected the join/leave frequency 1350 of the multicast members will be much higher than unicast topology 1351 changes. It is efficient to separate the updates for the group 1352 membership change information from the remainder of the information 1353 by placing this information in a separate PDU. This enables 1354 reachability information, that would trigger an SPF, to be not 1355 impacted at all. Furthermore, during SPF runs, TLVs being on 1356 different PDUs which do not affect SPF need not be inspected during 1357 processing. 1359 The choice of a different PDU also opens the LSP-space to another 256 1360 fragments to carry a large number of groups. This additional space 1361 can be used judiciously to carry only multicast information. 1363 The Multicast Group (MGROUP) PDU can be used to advertise a set of 1364 attached, or joined, multicast groups. The MGROUP PDU is formatted 1365 identical to a Level 1 Link State PDU, as described in Section 9.3 of 1366 [IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify 1367 this PDU is carrying multicast group information, rather than unicast 1368 reachability information. The PDU MUST NOT carry Area Address TLV or 1369 Protocol Support TLV in the zeroth fragment. 1371 The Multicast Group PDU carries TLVs indicating multicast membership 1372 information. There are three sub-TLVs of the GADDR TLV defined in 1373 this document, that MAY be present in this PDU, namely, GMAC-ADDR, 1374 GIP-ADDR, and GIPV6-ADDR TLVs. 1376 One or more TLVs MAY be carried in a single MGROUP PDU. Future 1377 multicast address TLVs MAY be defined using other type codes, and be 1378 carried in an MGROUP PDU. 1380 The information carried in this PDU is processed in a similar fashion 1381 as described in [RFC 1584]. 1383 3.1. The Multicast Group Partial Sequence Number PDU 1385 The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used 1386 to reliably flood the MGROUP PDU following the base protocol 1387 specifications. 1389 3.2. The Multicast Group Complete Sequence Number PDU 1391 The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is 1392 used to reliably flood the MGROUP PDU following the base protocol 1393 specifications. 1395 3.3. Enhancements to the flooding process 1397 This document proposes that the information contained in the MGROUP- 1398 PDU is in a parallel database and its update mechanisms mimic that of 1399 the regular database. Nodes running IS-IS in an L2 domain MUST 1400 support these additional MGROUP PDUs defined in this document. In 1401 general, the flooding of the MGROUP-PDU in tandem with the MGROUP- 1402 PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined 1403 for the regular LSP, PSNP, and CSNP PDUs. 1405 For example, on P2P links CSNP is exchanged on the formation of an 1406 adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged 1407 between the neighbors at the same time. This gets the initial 1408 MGROUP-database synchronization going. After this similar actions of 1409 the base protocol specifications for the regular database 1410 synchronization will be maintained to keep the MGROUP-database 1411 synchronized. 1413 Similarly, on LAN links the DIS is responsible for sending periodic 1414 CSNP transmissions. The DIS in the L2 IS-IS network domain will also 1415 be responsible for sending periodic MGROUP-CSNP transmissions. The 1416 update and flooding process will work in parallel for the two 1417 databases and there is no further synchronization between them. 1419 In general, the database synchronization is performed in parallel 1420 with no interactions between the messages. However, the initial 1421 triggers that start a CSNP exchange are correlated, in the sense it 1422 also triggers a MGROUP-CSNP exchange. For example, during graceful 1423 restart [RFC 5306], the normal hello operations as described in the 1424 RFC will be followed. The enhancements will take place such that 1425 CSNP and PSNP triggers will necessitate a parallel MGROUP-CSNP and 1426 MGROUP-PSNP exchange and update process will be triggered in parallel 1427 for the MGROUP-PDUs. After both databases containing the regular 1428 PDUs and MGROUP-PDUs have been obtained, the restart process is 1429 deemed complete. 1431 3.4. Enhancements to the maximum sequence number reached 1433 In the event, LSPs reach the maximum sequence number, ISO/IEC 10589 1434 states the rules for the process to shut down and its duration. With 1435 the introduction of the MGROUP-PDU, the same process now applies when 1436 LSPs from either database reach the maximum sequence number. 1438 4. Considerations for Using L2 Information in IS-IS 1440 While this document does not specify the way in which addresses 1441 carried in these TLVs are used in IS-IS, two general areas of concern 1442 are considered in this section: building the SPF tree when using this 1443 information, and the election of designated intermediate systems 1444 (DIS) in an environment using this information. 1446 4.1. Building SPF Trees with Layer 2 Information 1448 Each IS which is part of a single broadcast domain from a layer 2 1449 perspective will build multiple SPF trees (SPT) for every IS that is 1450 announced by the IS deemed to be the broadcast root. 1452 We assume some mechanism for forwarding traffic to these attached 1453 addresses added to the SPT is provided for in the mechanism proposing 1454 the use of these extension TLVs. 1456 4.2. Designated Intermediate Routers 1458 A single DIS SHOULD be elected as described in [IS-IS] for each layer 1459 2 broadcast domain (VLAN) for which information is being carried in 1460 IS-IS. This reduces the amount of work required to flood and 1461 maintain synchronized databases over the underlying media on which 1462 IS-IS is running and providing layer 2 forwarding information for. 1464 5. Acknowledgements 1466 The authors would like to thank Les Ginsberg for his useful comments. 1468 6. Security Considerations 1470 This document adds no additional security risks to IS-IS, nor does it 1471 provide any additional security for IS-IS. 1473 7. IANA Considerations 1475 This document creates three new PDU types, namely the MCAST PDU, 1476 MCAST-CSNP PDU, and the MCAST-PSNP PDU. IANA SHOULD assign a new PDU 1477 type to the level-1 PDUs described above and reflect it in the PDU 1478 registry. 1480 MCAST-PDU Level-1 PDU Type: 19 1481 MCAST-CSNP-PDU Level-1 PDU Type: 22 1482 MCAST-PSNP-PDU Level-1 PDU Type: 29 1484 This document requires the definition a set of new ISIS TLVs, the 1485 MAC-Reachability TLV (type 141), the Group Address TLV (type 142), 1486 and the Link-Capability TLV (type 143), that needs to be reflected in 1487 the ISIS TLV code-point registry. 1489 This document creates a number of new sub-TLV in the numbering space 1490 for the Group Address TLV, the Link Capability TLV, and the 1491 Capability TLV. The TLV and sub-TLVs are given below along with 1492 technologies that use them. 1494 IIH LSP SNP MCAST MCAST TRILL/ 1495 LSP SNP IEEE 1496 MAC-RI TLV (141) - X - - - T/I 1498 GADDR-TLV (142) - - - X - T/I 1499 GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X - T/I 1500 GADDR-TLV.GMAC-IP sub-tlv 2 - - - X - T/I 1501 GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X - T/I 1503 MT-Port-Cap-TLV (143) X - - - - T/- 1504 PortCap.VLAN and Flags sub-tlv 1 X - - - - T/- 1505 PortCap.Enabled-VLANs sub-tlv 2 X - - - - T/- 1506 PortCap.AppointedFwrdrs sub-tlv 3 X - - - - T/- 1507 PortCap.HopbyHopOptions sub-tlv 4 X - - - - T/- 1508 PortCap.BaseVLANID sub-tlv 5 X - - - - -/I 1510 CAPABILITY.Trill-Version sub-tlv 5 - X - - - T/- 1511 CAPABILITY.Nickname sub-tlv 6 - X - X - T/- 1512 CAPABILITY.Tree sub-tlv 7 - X - - - T/- 1513 CAPABILITY.Tree Roots Id sub-tlv 8 - X - - - T/- 1514 CAPABILITY.TreeUseRootId sub-tlv 9 - X - - - T/- 1515 CAPABILITY.Int-VLANs sub-tlv 10 - X - X - T/- 1516 CAPABILITY.VLAN-Groups sub-tlv 11 - X - - - T/- 1517 CAPABILITY.ITEOPT sub-tlv 12 - X - - - T/- 1519 MT-Capability-TLV (144) X - - - - -/I 1520 MT-Cap.SPB Instance sub-tlv 1 X - - - - -/I 1521 MT-Cap.Service Id. sub-tlv 2 X - - - - -/I 1523 EXT-IS.SPB Link Metric sub-tlv 5 X - - - - -/I 1524 MT-EXT-IS.SPB LinkMetric sub-tlv 5 X - - - - -/I 1526 IANA SHOULD manage the remaining space using the consensus method. 1528 8. Contributing Authors 1530 David Ward 1531 Cisco Systems 1532 170 W Tasman Drive 1533 San Jose, CA 95138 1534 US 1536 Email: wardd@cisco.com 1538 Russ White 1539 Cisco Systems 1540 170 W Tasman Drive 1541 San Jose, CA 95138 1542 US 1544 Email: riw@cisco.com 1546 Dino Farinacci 1547 Cisco Systems 1548 170 W Tasman Drive 1549 San Jose, CA 95138 1550 US 1552 Email: dino@cisco.com 1554 Radia Perlman 1555 Sun Microsystems 1556 16 Network Circle 1557 Menlo Park, CA 94025 1558 US 1560 Email: Radia.Perlman@Sun.com 1562 Donald E. Eastlake 3rd 1563 Stellar Switches 1564 155 Beaver Street 1565 Milford, MA 07157 1566 US 1568 Email: d3e3e3@gmail.com 1570 Peter Ashwood-Smith 1571 Huawei Technologies Canada Co. Ltd. 1572 411 Legget Drive, Suite 503 1573 Kanta, Ontario K2K 3C9 1574 CANADA 1576 Email: Peter.AshwoodSmith@huawei.com 1578 Don Fedyk 1579 Alcatel-Lucent 1580 220 Hayden Road 1581 Groton, MA 01450 1582 US 1583 Email: Donald.Fedyk@alcatel-lucent.com 1585 9. References 1587 9.1. Normative References 1589 [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System 1590 Intra-Domain Routing Exchange Protocol for use in 1591 Conjunction with the Protocol for Providing the 1592 Connectionless-mode Network Service (ISO 8473)", 2005. 1594 [RFC 1195] 1595 Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1596 Dual Environments", 1990. 1598 [RFC 4971] 1599 Vasseur, JP. and N. Shen, "Intermediate System to 1600 Intermediate System (IS-IS) Extensions for Advertising 1601 Router Information", 2007. 1603 [RFC 5305] 1604 Li, T. and H. Smit, "IS-IS Extensions for Traffic 1605 Engineering", 2008. 1607 [RFC 5306] 1608 Shand, M. and L. Ginsberg, "Restart Signaling for 1609 Intermediate System to Intermediate System (IS-IS)", 2004. 1611 9.2. Informative References 1613 [IEEE 802.1aq] 1614 "Standard for Local and Metropolitan Area Networks / 1615 Virtual Bridged Local Area Networks / Amendment 9: 1616 Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008. 1618 [RBRIDGES] 1619 Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 1620 Ghanwani, "RBridges: Base Protocol Specification", 2009. 1622 [RFC 1584] 1623 Moy, J., "Multicast Extensions to OSPF", March 1994. 1625 Author's Address 1627 Ayan Banerjee (editor) 1628 Cisco Systems 1629 170 W Tasman Drive 1630 San Jose, CA 95138 1631 US 1633 Email: ayabaner@cisco.com