idnits 2.17.1 draft-ietf-isis-layer2-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 5 instances of too long lines in the document, the longest one being 8 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 2312 has weird spacing: '...d Flags sub-T...' == Line 2313 has weird spacing: '...d-VLANs sub-...' == Line 2318 has weird spacing: '...ntifier sub-T...' == Line 2330 has weird spacing: '...-Groups sub-...' == Line 2340 has weird spacing: '... Metric sub-...' == 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 'SHOULD not' in this paragraph: The TRILL-Hello PDU has the same general structure as an IS-IS LAN PDU. An RBridge (an Intermediate System supporting TRILL) sends this PDU, with the same timing as the IS-IS LAN Hello PDU. More specifically, in a TRILL-Hello PDU the IS-IS Common Header and the fixed PDU Header are the same as a Level 1 IS-IS LAN Hello except that a new PDU Type number is used as listed in Section 7. The circuit type field, of course, is always equal to one. A TRILL-Hello PDU SHOULD not be padded and MUST NOT exceed a length limit equal to 42 bytes shorter than the reasonable lower bound for the link MTU. For example, for an 802.3 Ethernet link, the MTU SHOULD be assumed to be 1512 bytes for the purpose of determining the maximum size of TRILL-Hello PDUs on that link. Thus, for such a link, TRILL-Hellos MUST NOT exceed 1470 bytes. -- The document date (March 8, 2010) is 5162 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 119, but not defined == Missing Reference: 'TBD' is mentioned on line 2113, but not defined == Missing Reference: 'RFC5305' is mentioned on line 1816, but not defined == Missing Reference: 'RFC 5226' is mentioned on line 2349, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC 1195' is defined on line 2419, but no explicit reference was found in the text == Unused Reference: 'RFC 5305' is defined on line 2428, 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: 5 errors (**), 0 flaws (~~), 13 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 March 8, 2010 5 Expires: September 9, 2010 7 Extensions to IS-IS for Layer-2 Systems 8 draft-ietf-isis-layer2-03 10 Abstract 12 This document specifies the IS-IS extensions necessary to support 13 multi-link IPv4 and IPv6 networks, as well as to provide true link 14 state routing to any protocols running directly over layer 2. While 15 supporting this concept involves several pieces, this document only 16 describes extensions to IS-IS. We leave it to the systems using 17 these IS-IS extensions to explain how the information carried in 18 IS-IS is used. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 9, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. PDU, TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . 4 63 2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 4 64 2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6 65 2.2.1. The Group MAC Address sub-TLV . . . . . . . . . . . . 6 66 2.2.2. The Group IP Address sub-TLV . . . . . . . . . . . . . 8 67 2.2.3. The Group IPv6 Address sub-TLV . . . . . . . . . . . . 10 68 2.2.4. The SPBV MAC Address sub-TLV . . . . . . . . . . . . . 11 69 2.3. Multi Topology aware Port Capability TLV . . . . . . . . . 13 70 2.3.1. The Special VLANs and Flags sub-TLV . . . . . . . . . 14 71 2.3.2. Enabled VLANs sub-TLV . . . . . . . . . . . . . . . . 15 72 2.3.3. Appointed Forwarders sub-TLV . . . . . . . . . . . . . 16 73 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV . . . . . . . . . 17 74 2.3.5. Base VLAN-Identifiers sub-TLV . . . . . . . . . . . . 18 75 2.3.6. SPB Digest sub-TLV . . . . . . . . . . . . . . . . . . 19 76 2.3.7. Site Identifier sub-TLV . . . . . . . . . . . . . . . 21 77 2.3.8. Site Group IPv4 sub-TLV . . . . . . . . . . . . . . . 21 78 2.3.9. Site Group IPv6 sub-TLV . . . . . . . . . . . . . . . 22 79 2.3.10. Adjacency Server IPv4 sub-TLV . . . . . . . . . . . . 22 80 2.3.11. Adjacency Server IPv6 sub-TLV . . . . . . . . . . . . 23 81 2.4. Sub-TLVs for the Router Capability TLV . . . . . . . . . . 23 82 2.4.1. The TRILL Version sub-TLV . . . . . . . . . . . . . . 23 83 2.4.2. The Nickname sub-TLV . . . . . . . . . . . . . . . . . 24 84 2.4.3. The Trees sub-TLV . . . . . . . . . . . . . . . . . . 25 85 2.4.4. The Tree Identifiers Sub-TLV . . . . . . . . . . . . . 26 86 2.4.5. The Trees Used Identifiers Sub-TLV . . . . . . . . . . 27 87 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV . . . 27 88 2.4.7. The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 29 89 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-TLV . . . . 30 90 2.4.9. VLAN Mapping (VMAP) sub-TLV . . . . . . . . . . . . . 31 91 2.5. Multi Topology Aware Capability TLV . . . . . . . . . . . 32 92 2.5.1. SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 33 93 2.5.2. SPBM Service Identifier and Unicast Address sub-TLV . 36 94 2.6. Sub-TLVs of the Extended Reachability TLV . . . . . . . . 37 95 2.6.1. SPB Link Metric sub-TLV . . . . . . . . . . . . . . . 37 96 2.6.2. MTU sub-TLV . . . . . . . . . . . . . . . . . . . . . 38 97 2.7. TRILL Neighbor TLV . . . . . . . . . . . . . . . . . . . . 39 98 2.8. The Group Membership Active Source TLV . . . . . . . . . . 40 99 2.8.1. The Group MAC Active Source sub-TLV . . . . . . . . . 41 100 2.8.2. The Group IP Active Source sub-TLV . . . . . . . . . . 42 101 2.8.3. The Group IPv6 Active Source sub-TLV . . . . . . . . . 44 102 2.9. PDU Extensions to IS-IS . . . . . . . . . . . . . . . . . 46 103 2.9.1. The Multicast Group PDU . . . . . . . . . . . . . . . 46 104 2.9.2. The TRILL-Hello PDU . . . . . . . . . . . . . . . . . 48 105 2.9.3. The MTU PDU . . . . . . . . . . . . . . . . . . . . . 49 106 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 107 4. Security Considerations . . . . . . . . . . . . . . . . . . . 50 108 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 109 6. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 53 110 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 111 7.1. Normative References . . . . . . . . . . . . . . . . . . . 54 112 7.2. Informative References . . . . . . . . . . . . . . . . . . 55 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 115 1. Overview 117 There are a number of systems (for example, [RBRIDGES], [802.1aq]) 118 that use layer 2 addresses carried in a link state routing protocol, 119 specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 120 routing. This document specifies a set of TLVs and sub-TLVs to be 121 added to [IS-IS] level 1 PDUs, and six new PDU types, to support 122 these proposed systems. Some of these TLVs are generic layer 2 123 additions and some are specific to [RBRIDGES] or to [802.1aq]. This 124 draft does not propose any new forwarding mechanisms using this 125 additional information carried within IS-IS. 127 This document specifies additional TLVs and sub-TLVs, to carry 128 unicast and multicast attached address information. It also 129 specifies additional TLVs and sub-TLVs to carry information as 130 required by the IETF TRILL and IEEE 802.1aq protocols. 132 This document specifies six new IS-IS PDUs. The Multicast Group 133 (MGROUP) PDU, for carrying a list of attached or joined multicast 134 groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) 135 PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU 136 packets are also defined to be used with the new MGROUP-PDU to 137 perform database exchange on the MGROUP PDUs. The TRILL-Hello PDU 138 provides the subnet specific layer of IS-IS for TRILL links. The 139 MTU-probe and MTU-ack PDUs provide a means of testing link MTU. 141 1.1. Terminology 143 The term "Hello" or "Hello PDU" in this document, when not further 144 qualified, includes the TRILL IIH PDU, the LAN IIH PDU and the P2P 145 IIH PDU. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119. 151 2. PDU, TLV and sub-TLV Enhancements to IS-IS 153 In this section we specify the enhancements for the PDUs, TLVs and 154 sub-TLVs as needed by Layer-2 technologies. 156 2.1. The MAC-Reachability TLV 158 The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the 159 following format: 161 +-+-+-+-+-+-+-+-+ 162 | Type= MAC-RI | (1 byte) 163 +-+-+-+-+-+-+-+-+ 164 | Length | (1 byte) 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Topology-Id/ Nickname | (2 bytes) 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Confidence | (1 byte) 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | RESV | VLAN-ID | (2 bytes) 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | MAC (1) (6 bytes) | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | ................. | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | MAC (N) (6 bytes) | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 o Type: TLV Type, set to 141 (MAC-RI). 181 o Length: Total number of bytes contained in the value field given 182 by 5 + 6*n bytes. 184 o Confidence: This carries an 8-bit quantity indicating the 185 confidence level in the MAC addresses being transported. Whether 186 this field is used, and its semantics if used, are further defined 187 by the specific protocol using Layer-2-IS-IS. If not used, it 188 MUST be set to zero on transmission and be ignored on receipt. 190 o Topology-Id/Nickname : Depending on the technology in which it is 191 used, this carries the topology-id or nickname. When this field 192 is set to zero this implies that the MAC addresses are reachable 193 across all topologies or across all nicknames of the originating 194 IS. 196 o RESV: Must be sent as zero on transmission and is ignored on 197 receipt. 199 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 200 all subsequent MAC addresses in this TLV, or the value zero if no 201 VLAN is specified. 203 o MAC(i): This is the 48-bit MAC address reachable from the IS that 204 is announcing this TLV. 206 The MAC-RI TLV is carried in a standard Level 1 link state PDU. It 207 MUST contain only unicast addresses. 209 2.2. The Group Address TLV 211 The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the 212 following format: 214 +-+-+-+-+-+-+-+-+ 215 | Type=GADDRTLV | (1 byte) 216 +-+-+-+-+-+-+-+-+ 217 | Length | (1 byte) 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | sub-TLVs (variable bytes) | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 o Type: TLV Type, set to GADDR-TLV 142 [TBD]. 224 o Length: Total number of bytes contained in the value field, which 225 includes the length of the sub-TLVs carried in this TLV. 227 o sub-TLVs: The Group Address TLV value contains sub-TLVs formatted 228 as described in [RFC5305]. The sub-TLVs for this TLV are 229 specified in the following subsections. 231 The GADDR TLV is carried only within a Multicast Group Level 1 link 232 state PDU. 234 2.2.1. The Group MAC Address sub-TLV 236 The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS sub-TLV type 1 237 within the GADDR TLV and has the following format: 239 +-+-+-+-+-+-+-+-+ 240 | Type=GMAC-ADDR| (1 byte) 241 +-+-+-+-+-+-+-+-+ 242 | Length | (1 byte) 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Topology-Id/ Nickname | (2 bytes) 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Confidence | (1 byte) 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | RESV | VLAN-ID | (2 bytes) 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |Num Group Recs | (1 byte) 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | GROUP RECORDS (1) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | ................. | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | GROUP RECORDS (N) | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 where each group record is of the form: 261 +-+-+-+-+-+-+-+-+ 262 | RESERVED | (1 byte) 263 +-+-+-+-+-+-+-+-+ 264 | Num of Sources| (1 byte) 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Group Address (6 bytes) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Source 1 Address (6 bytes) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Source 2 Address (6 bytes) | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Source M Address (6 bytes) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 o Type: sub-TLV Type, set to 1 (GMAC-ADDR) of length 1 byte. 277 o Length: Total number of bytes contained in the value field. 279 o Confidence: This carries an 8-bit quantity indicating the 280 confidence level in the MAC addresses being transported. Whether 281 this field is used, and its semantics if used, are further defined 282 by the specific protocol using Layer-2-IS-IS. If not used, it 283 MUST be set to zero on transmission and be ignored on receipt. 285 o Topology-Id/Nickname : Depending on the technology in which it is 286 used, this carries the topology-id or nickname. When this field 287 is set to zero this implies that the MAC addresses are reachable 288 across all topologies or across all nicknames of the originating 289 IS. 291 o RESERVED: Must be sent as zero on transmission and is ignored on 292 receipt. 294 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 295 all subsequent MAC addresses in this TLV, or the value zero if no 296 VLAN is specified. 298 o Number of Group Records: This is of length 1 byte and lists the 299 number of group records in this TLV. 301 o Group Record: Each group record has a one byte reserved space and 302 the next byte carries the number of sources. It then has a 48-bit 303 multicast Group Address followed by 48-bit source MAC addresses. 305 An address being a group multicast address or unicast source 306 address can be checked using the multicast bit in the address. If 307 the number of sources do not fit in a single sub-TLV, it is 308 permitted to have the same group address repeated with different 309 source addresses in another sub-TLV of another instance of the 310 Group Address TLV. 312 The GMAC-ADDR sub-TLV is carried only within a GADDR TLV and MUST be 313 carried in a standard Level 1 link state MGROUP PDU. 315 2.2.2. The Group IP Address sub-TLV 317 The Group IP Address (GIP-ADDR) sub-TLV IS-IS sub-TLV type 2 within 318 the GADDR TLV and has the following format: 320 +-+-+-+-+-+-+-+-+ 321 | Type=GIP-ADDR | 322 +-+-+-+-+-+-+-+-+ 323 | Length | (1 byte) 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Topology-Id/ Nickname | (2 bytes) 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Confidence | (1 byte) 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | RESV | VLAN-ID | (2 bytes) 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |Num Group Recs | (1 byte) 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | GROUP RECORDS (1) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | ................. | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | GROUP RECORDS (N) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 where each group record is of the form: 342 +-+-+-+-+-+-+-+-+ 343 | RESERVED | (1 byte) 344 +-+-+-+-+-+-+-+-+ 345 | Num of Sources| (1 byte) 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Group Address (4 bytes) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Source 1 Address (4 bytes) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Source 2 Address (4 bytes) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Source M Address (4 bytes) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 o Type: sub-TLV Type, set to 2 (GIP-ADDR). 358 o Length: Total number of bytes contained in the value field of the 359 TLV. 361 o Confidence: This carries an 8-bit quantity indicating the 362 confidence level in the IP addresses being transported. Whether 363 this field is used, and its semantics if used, are further defined 364 by the specific protocol using Layer-2-IS-IS. If not used, it 365 must be set to zero on transmission and be ignored on receipt. 367 o Topology-Id/Nickname : Depending on the technology in which it is 368 used, this carries the topology-id or nickname. When this field 369 is set to zero this implies that the addresses are reachable 370 across all topologies or across all nicknames of the originating 371 IS. 373 o RESERVED: Must be sent as zero on transmission and is ignored on 374 receipt. 376 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 377 all subsequent addresses in this TLV, or the value zero if no VLAN 378 is specified. 380 o Number of Group Records: This is of length 1 byte and lists the 381 number of group records in this TLV. 383 o Group Record: Each group record has a one byte reserved space and 384 the next byte carries the number of sources. It is followed by a 385 32-bit IPv4 Group Address followed by 32-bit source IPv4 386 addresses. If the number of sources do not fit in a single sub- 387 TLV, it is permitted to have the same group address repeated with 388 different source addresses repeated in another sub-TLV of another 389 instance of the Group Address TLV. 391 The GIP-ADDR sub-TLV is carried only within a GADDR TLV and MUST be 392 carried in a standard Level 1 link state MGROUP PDU. 394 2.2.3. The Group IPv6 Address sub-TLV 396 The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and 397 has the following format: 399 +-+-+-+-+-+-+-+-+ 400 |Type=GIPv6-ADDR| 401 +-+-+-+-+-+-+-+-+ 402 | Length | (1 byte) 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Topology-Id/ Nickname | (2 bytes) 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Confidence | (1 byte) 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | RESV | VLAN-ID | (2 bytes) 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |Num Group Recs | (1 byte) 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | GROUP RECORDS (1) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | ................. | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | GROUP RECORDS (N) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 where each group record is of the form: 421 +-+-+-+-+-+-+-+-+ 422 | RESERVED | (1 byte) 423 +-+-+-+-+-+-+-+-+ 424 | Num of Sources| (1 byte) 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Group Address (16 bytes) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Source 1 Address (16 bytes) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Source 2 Address (16 bytes) | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Source M Address (16 bytes) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 o Type: sub-TLV Type, set to 3 (GIPV6-ADDR). 437 o Length: Total number of bytes contained in the value field. 439 o Confidence: This carries an 8-bit quantity indicating the 440 confidence level in the IPv6 addresses being transported. Whether 441 this field is used, and its semantics if used, are further defined 442 by the specific protocol using Layer-2-IS-IS. If not used, it 443 must be set to zero on transmission and be ignored on receipt. 445 o Topology-Id/Nickname : Depending on the technology in which it is 446 used, this carries the topology-id or nickname. When this field 447 is set to zero this implies that the addresses are reachable 448 across all topologies or across all nicknames of the originating 449 IS. 451 o RESERVED: Must be sent as zero on transmission and is ignored on 452 receipt. 454 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 455 all subsequent addresses in this TLV, or the value zero if no VLAN 456 is specified. 458 o Number of Group Records: This of length 1 byte and lists the 459 number of group records in this TLV. 461 o Group Record: Each group record has a one byte reserved space and 462 the next byte carries the number of sources. It is followed by a 463 128-bit multicast IPv6 Group Address followed by 128-bit source 464 IPv6 addresses. If the number of sources do not fit in a single 465 sub-TLV, it is permitted to have the same group address repeated 466 with different source addresses repeated in another sub-TLV in 467 another instance of the Group Address TLV. 469 The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV and MUST be 470 carried in a standard Level 1 link state MGROUP PDU. 472 2.2.4. The SPBV MAC Address sub-TLV 474 The SPBV MAC Address (SPBV-MAC-ADDR) TLV is IS-IS sub-TLV type 4 and 475 has the following format: 477 +-+-+-+-+-+-+-+-+ 478 | Type=SPBV-ADDR| (1 byte) 479 +-+-+-+-+-+-+-+-+ 480 | Length | (1 byte) 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |R|R|S|R| SPVID | (2 bytes) 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |T|R| Reserved | MAC 1 Address | (1+6 bytes) 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | ... | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 |T|R| Reserved | MAC N Address | (1+6 bytes) 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 o Type: sub-TLV Type, set to 4 (SPBV-MAC-ADDR). 493 o Length: Total number of bytes contained in the value field. The 494 number of MAC address associated with the SPVID is computed by 495 (Length - 2)/7. 497 o SR bits (2-bits) The SR bits are the service requirement parameter 498 from MMRP. The service requirement parameters have the value 0 499 (Forward all Groups) and 1 (Forward All Unregistered Groups) 500 defined. However this attribute may also be missing. So the SR 501 bits are defined as 0 not declared, 1 Forward all Groups and 2 502 Forward All Unregistered Groups. These bits have a two Reserved 503 bits set before them. 505 o SPVID (12-bits) The SPVID and by association Base VID and the ECT- 506 ALGORITHM and SPT Set that the MAC addresses defined below will 507 use. If the SPVID is not allocated the SPVID Value is 0. Note 508 that if the ECT-Algorithm in use is Spanning Tree Algorithm this 509 value should be populated with the Base VID and the MAC can be 510 populated. 512 o T Bit (1-bit) This is the Transmit allowed Bit for the following 513 group MAC address. This is an indication that SPBV Group MAC 514 Address with SPVID of source should be populated (for the bridge 515 advertising this Group MAC), and installed in the FDB of transit 516 bridges, when the bridge computing the trees is on the 517 corresponding ECT-ALGORITHM shortest path between the bridge 518 advertising this MAC with the T bit set, and any receiver of this 519 Group MAC Address. A bridge that does not advertise this bit set 520 for an Group MAC Address should have no forwarding state installed 521 for traffic originating from that bridge on other transit bridges 522 in the network. 524 o R Bit (1-bit) This is the Receive allowed Bit for the following 525 Group MAC Address. This is an indication that SPBV Group MAC 526 Addresses as receiver should be populated (for bridges advertising 527 this Group MAC Address with the T bit set) and installed when the 528 bridge computing the trees lies on the corresponding shortest path 529 for this ECT-ALGORITHM between this receiver and any transmitter 530 on this Group MAC Address. An entry that does not have this bit 531 set for a Group MAC Address is prevented from receiving on this 532 Group MAC Address because transit bridges will not install 533 multicast forwarding state towards it in their FDBs or the traffic 534 is explicitly filtered. 536 o MAC Address (48-bits) The MAC is the address is either a group 537 address or an individual address. Individual addresses are 538 optional and normal MAC learning can be used. When the MAC 539 address is a group address it declares this bridge as part of the 540 multicast interest for this destination MAC address. Multicast 541 trees can be efficiently constructed for destination by populating 542 multicast FDB entries for the subset of the shortest path tree 543 that connects the bridges supporting the multicast address. This 544 replaces the function of MMRP for SPTs. The T and R bits above 545 have meaning if this is a group address. Individual addresses are 546 populated only as if the R bit was not set. 548 The SPBV-MAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be 549 carried only in a standard Level 1 link state MGROUP PDU. 551 2.3. Multi Topology aware Port Capability TLV 553 The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS 554 TLV type 143 [TBD], and has the following format: 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 |Type=MT PORTCAP| Length |O|R|R|R| Topology Identifier | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | sub-TLVs | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 o Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD]. 565 o Length: Total number of bytes contained in the value field, 566 including the length of the sub-TLVs carried in this TLV. 568 o O bit: The overload bit that follows the semantics associated with 569 an overloaded intermediate system. 571 o Topology Identifier: MT ID is a 12-bit field containing the MT ID 572 of the topology being announced. This field when set to zero 573 implies that it is being used to carry base topology information. 574 In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, 575 it may be non-zero. 577 o sub-TLVs: The MT aware Port Capabilities TLV value contains sub- 578 TLVs formatted as described in [RFC5305]. They are defined in the 579 next sections. 581 The MT-PORT-CAP TLV may occur multiple times, and is carried only 582 within a Hello PDU. 584 2.3.1. The Special VLANs and Flags sub-TLV 586 The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST only appear 587 in a MT-PORT-CAP TLV. This is carried exactly once in every TRILL 588 IIH PDU. It has the following format: 590 +-+-+-+-+-+-+-+-+ 591 |Type=VLAN Flags| (1 byte) 592 +-+-+-+-+-+-+-+-+ 593 | Length | (1 byte) 594 +--------------------------------+ 595 | Port ID | (2 bytes) 596 +--------------------------------+ 597 | Sender Nickname | (2 bytes) 598 +--+--+--+--+--------------------+ 599 |AF|AC|VM|BY| Outer.VLAN | (2 bytes) 600 +-----------+--------------------+ 601 |Reserved | Desig.VLAN | (2 bytes) 602 +-----------+--------------------+ 604 o Type: TLV Type, set to VLAN and Flags sub-TLV 1 [TBD]. 606 o Length: 8 - Number of bytes contained in the value field. 608 o Port ID: An ID for the port on which the enclosing TRILL IIH PDU 609 is being sent. The transmitting RBridge assigns this ID such that 610 each of its ports has an ID different from all of its other ports. 612 o Sender nickname: If the sending intermediate system is holding any 613 nicknames, one MUST be included here. Otherwise, the field is set 614 to zero. This field is to support intelligent end stations that 615 determine the egress RBridge for unicast data through a directory 616 service or the like and need a nickname for their first hop to 617 insert as the ingress nickname to correctly format a TRILL 618 encapsulated data frame. 620 o The fifth and sixth bytes have a copy of the Outer VLAN ID 621 associated with the Hello frame when it was sent. The lower 4 622 bits of the fifth byte give the upper ID bits of the VLAN ID and 623 the sixth byte gives the lower VLAN ID bits. 625 o The upper 4 bits of the fifth byte are flag bits as shown. The AF 626 bit, if one, indicates that the sending Intermediate System 627 believes it is Appointed Forwarder for the VLAN and port on which 628 the Hello was sent. The AC bit, if one, indicates that the 629 sending port is configured as an access port. The VM bit, if a 630 one, indicates that the sending Intermediate System has detected 631 VLAN mapping within the link. The BY bit, if set, indicates 632 bypass psuedonode. 634 o The seventh and eighth bytes give the Designated VLAN for the 635 link. The lower 4 bits of the seventh byte give the upper ID bits 636 of the Designated VLAN and the eighth byte gives the lower VLAN ID 637 bits. The upper 4 bits of the seventh byte are reserved and MUST 638 be sent as zero and ignored on receipt. 640 The VLAN and Flags sub-TLV is carried within the MT-PORT-CAP TLV. It 641 MUST be carried exactly once in a TRILL IIH PDU. It MUST NOT be 642 carried within a LAN or a P2P IIH PDU. 644 2.3.2. Enabled VLANs sub-TLV 646 The Enabled VLAN sub-TLV specifies the VLANs enabled for end station 647 service at the port on which the Hello was sent. 649 +-+-+-+-+-+-+-+-+ 650 |Type=EnabledVLAN| 651 +-+-+-+-+-+-+-+-+ 652 | Length | (1 byte) 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 |Resv | Start Vlan Id | (2 bytes) 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Vlan bit-map.... 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 2 [TBD]. 661 o Length: variable, depending on contents described next. 663 o The minimum size of the value is 3 bytes. The third and 664 subsequent bytes provide a bit map of enabled VLANs starting at 665 the VLAN ID indicated in the first two bytes. The lower order 666 four bits of the first byte give the upper bits of the starting 667 VLAN ID and the second byte gives the lower bits of that VLAN ID. 669 The upper four bits of the first byte are reserved and MUST be 670 sent as zero and ignored on receipt. The highest order bit of the 671 third byte indicates the VLAN equal to the starting ID while the 672 lowest order bit of the third byte indicates that ID plus 7. For 673 example, VLANs 1 and 14 being enabled for end station service 674 could be encoded in 4-bytes value 0x00 0x01 0x80 0x04 or, 675 alternatively, as 0x00 0x00 0x40 0x02. 677 This sub-TLV may occur more than once in a Hello and a VLAN is 678 enabled for end station service on the port where the Hello was sent 679 if this is indicated by any occurrence in the Hello. For example, a 680 receiver could allocate a 512-byte buffer and, with appropriate 681 shifting operations, OR in the enabled bits for each subTLV of this 682 type it finds in a Hello to derive the complete bit map of these 683 VLANs. 685 The Enabled VLAN sub-TLV is carried only within the MT-PORT-CAP TLV. 686 If present, it MUST be carried in TRILL IIH PDU. It MUST NOT be 687 carried within a LAN IIH or a P2P IIH PDU. 689 2.3.3. Appointed Forwarders sub-TLV 691 The Appointed Forwarder sub-TLV provides the mechanism by which the 692 Designated Intermediate System can inform other Intermediate Systems 693 on the link that they are the designated VLAN-x forwarder for that 694 link for one or more ranges of VLAN IDs. 696 o Type: sub-TLV Type, set to Appointed Forwarders sub-TLV 3 [TBD]. 698 o Length: The size of the value is 6*n bytes where there are n 699 appointments. Each 6-byte part of the value is formatted as 700 follows: 702 +-+-+-+-+-+-+-+-+ 703 |Type=App Frwrdr| 704 +-+-+-+-+-+-+-+-+ 705 | Length | (1 byte) 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Appointment Information (1) | (6 bytes) 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | ................. | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Appointment Information (N) | (6 bytes) 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 o where each appointment information is of the form: 716 +---------------------------+ 717 | Appointee Nick | (2 bytes) 718 +---------------------------+ 719 | Res | Start VLAN ID | (2 bytes) 720 +---------------------------+ 721 | Res | End VLAN ID | (2 bytes) 722 +---------------------------+ 724 o The appointed forwarder Intermediate System is specified by its 725 nickname in the first two bytes. 727 o The "Res" fields of 4 bits each are reserved and MUST be sent as 728 zero and ignored on receipt. 730 The VLAN range given is inclusive. To specify a single VLAN, that 731 VLAN ID appears as both the start and end VLAN. The Intermediate 732 System whose nickname is given is appointed forwarder for those VLANs 733 for which it has end station service enabled (see item 2 above) in 734 the inclusive range. For example, assume an Intermediate System with 735 end station service enabled on VLANs 100, 101, 199, and 200 (and 736 possibly other VLANs less than 100 or greater than 200), but not 737 enabled for VLANs 102 through 198. It could be appointed forwarder 738 for these four VLANs through either (1) a single 6-byte value 739 sequence with start and end VLAN IDs of 100 and 200, or (2) a 12-byte 740 value sequence with start and end VLAN IDs of 100 and 101 in the 741 first part and 199 and 200 in the second part. 743 An Intermediate System's nickname may occur as appointed forwarder 744 for multiple VLAN ranges within the same or different Port Capability 745 TLVs within a TRILL Hello. In the absence of appointed forwarder 746 sub-TLVs referring to a VLAN, the Designated Intermediate System acts 747 as the appointed forwarder for that VLAN if end station service is 748 enabled. 750 The Appointed Forwarder sub-TLV is carried within the MT-PORT-CAP 751 TLV. If present, it MUST be carried in a TRILL IIH PDU. This MUST 752 NOT be carried in a LAN IIH PDU or a P2P IIH PDU. 754 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV 756 By including this sub-TLV within one or more MT aware Port Capability 757 TLVs in its Hellos, an Intermediate System can advertise the Hop-by- 758 Hop options it supports on the port through which it sends the Hello. 759 This sub-TLV may appear zero or more times within a MT aware Port 760 Capability TLV. By default, in the absence of any HBHOPT sub-TLVs, 761 no Hop-by-Hop options are supported. 763 There are two types of Hop-by-Hop option encodings within the TRILL 764 Header: bit options and TLV encoded options. 766 The bit-encoded options supported are indicated by an HBHOPT sub-TLV 767 of length 3: an initial value byte of 0x00 followed by two bytes in 768 which each bit indicates that the corresponding bit option is 769 implemented; in those two bytes the top two bits (0xC000) are 770 critical option summary bits that all RBridges MUST understand; 771 therefore support for these bits need not be advertised. Those two 772 bits are reserved in the HBHOPT sub-TLV and must be sent as zero and 773 are ignored on receipt. 775 The implementation of a TLV encoded option is indicated by an HBHOPT 776 sub-TLV whose value starts with a byte equal to the first byte of the 777 option. Such HBHOPT sub-TLVs may have additional value bytes further 778 indicating how the option is supported as specified with the option's 779 definition, for example a list of supported security algorithms. 781 +-+-+-+-+-+-+-+-+ 782 | Type = HBHOPT | 783 +-+-+-+-+-+-+-+-+ 784 | Length | (1 byte) 785 +-+-+-+-+-+-+-+-+ 786 | Option | (1 byte) 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Option dependent variable length information | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 o Type: sub-TLV Type, set to Hop-by-Hop sub-TLV 4 [TBD]. 793 o Length: variable, minimum 1. 795 o Value: The first byte of the TLV encoded option which must be non- 796 zero, followed by option dependent information. 798 2.3.5. Base VLAN-Identifiers sub-TLV 800 This sub-TLV is added to an IIH PDU to indicate the algorithms for 801 the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) that 802 are in use. This information should be the same on all bridges in 803 the topology identified by MT-PORT-CAP TLV it is being carried. 804 Discrepancies between neighbours with respect to this sub-TLV are 805 temporarily allowed but the Base-VID must agree and use a spanning 806 tree algorithm. 808 +-+-+-+-+-+-+-+-+ 809 |Type = B-VID | 810 +-+-+-+-+-+-+-+-+ 811 | Length | (1 byte) 812 +-+-+-+-+-+-+-+-+-------------------------------- 813 | ECT - VID Tuple (1) (6 bytes) | 814 +-----------------------------------------------+ 815 | ......................... | 816 +-----------------------------------------------+ 817 | ECT - VID Tuples (N) (6 bytes) | 818 +-----------------------------------------------+ 820 o Type: sub-TLV Type, set to Base-VLAN-ID sub-TLV 5 [TBD]. 822 o Length: The size of the value is ECT-VID Tuples*6 bytes. Each 823 6-byte part of the ECT-VID tuple is formatted as follows: 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | ECT - Algorithm (32 bits) | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Base VID (12 bits) |U|M|RES| 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 o ECT-ALGORITHM (4 bytes) The ECT-ALGORITHM is advertised when the 832 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 833 Base VID 835 o Base VID (12-bits) The Base-VID that is associated with the SPT 836 Set. 838 o Use-Flag (1-bit) The Use-flag is set if this bridge, or any bridge 839 that this bridge sees is currently using this ECTALGORITHM and 840 Base VID. 842 o M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode. 844 The Base VLAN-Identifier sub-TLV is carried within the MT-PORT-CAP 845 TLV and this is carried in a IIH PDU. 847 2.3.6. SPB Digest sub-TLV 849 This sub-TLV is added to an IIH PDU to indicate the digest for 850 Multiple spanning tree configuration Digests (MCID) and the IS-IS 851 agreement Digest. This information should be the same on all bridges 852 in the topology identified by MT-PORT-CAP TLV it is being carried. 853 These digest indicate when the configuration and the topology are 854 synchronized and are used to control the updating of forwarding 855 information. The MCID is controlled solely by configuration and is a 856 digest of the allocated VIDs to various protocols. Two MCIDs are 857 carried to allow transitions when the configuration changes are non- 858 critical. During the propagation of LSPs the agreement digest will 859 vary between neighbors until the LSPs are common. During that period 860 switches or bridges running SPB will not allow multicast forwarding 861 between neighbors that have differing digests. Discrepancies between 862 neighbours with respect to this sub-TLV are temporarily allowed but 863 the Base-VID must agree and use a spanning tree algorithm. 865 +-+-+-+-+-+-+-+-+ 866 |Type =SPBDigest| 867 +-+-+-+-+-+-+-+-+ 868 | Length | (1 byte) 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | MCID (50 Bytes) | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Aux MCID (50 Bytes) | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Agreement Digest (32 Bytes) | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 |RES | A | D| 877 +-+-+-+-+-+-+-+-+ 879 o Type: sub-TLV Type, set to SPB Digest sub-TLV 6 [TBD]. 881 o Length: The size of the value defined below. 883 o MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which 884 identifies an SPT Region. 886 o Aux MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which 887 identifies an SPT Region. The aux MCID allows SP Regions to be 888 migrated allocating new VLAN to FID Mappings. 890 o Agreement Digest (32-bytes) This digest is use to determine when 891 IS-IS is synchronized between neighbors. 893 o A (2 bits) The agreement number 0-3 which aligns with BPDUs 894 agreement number concept. When the Agreement Digest for this node 895 changes this number is updated and sent in the hello. 897 o D (2 bits) The discarded agreement number 0-3 which aligns with 898 BPDUs agreement number concept. When the Agreement Digest for 899 this node changes this number is updated. Once an Agreement has 900 been sent it is considered outstanding until a matching or more 901 recent Discarded Agreement Number is received. 903 The SPB Digest sub-TLV is carried within the MT-PORT-CAP TLV and this 904 is carried in a IIH PDU. 906 2.3.7. Site Identifier sub-TLV 908 The site identifier sub-TLV carries information about the site this 909 device belongs to. 911 +-+-+-+-+-+-+-+-+ 912 |Type = SiteCap | 913 +-+-+-+-+-+-+-+-+ 914 | Length | (1 byte) 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | System ID (6 bytes) | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Cluster ID (2 bytes) | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Flags (1 byte)| 921 +-+-+-+-+-+-+-+-+ 923 o Type: sub-TLV Type, set to Site Identifier sub-TLV 250 [TBD]. 925 o Length: The size of the value. 927 o System Id: The system-id of the site. 929 o Cluster Id: The cluster-id within the site. 931 o Flags: Indicates unicast reachability. 933 The Site Capability sub-TLV is carried within the MT-PORT-CAP TLV and 934 this is carried in a Hello PDU. 936 2.3.8. Site Group IPv4 sub-TLV 938 +-+-+-+-+-+-+-+-+ 939 |Type=SiteGrpIP | 940 +-+-+-+-+-+-+-+-+ 941 | Length | (1 byte) 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | IPv4 address (4 bytes) | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | .................. | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | IPv4 address (4 bytes) | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 o Type: sub-TLV Type, set to Site Group IP sub-TLV 251 [TBD]. 952 o Length: The size of the value. 954 o Value: The list of IPv4 addresses used by the site. 956 The Site Group IP sub-TLV is carried within the MT-PORT-CAP TLV and 957 this is carried in a Hello PDU. 959 2.3.9. Site Group IPv6 sub-TLV 961 +-+-+-+-+-+-+-+-+ 962 |Type=SiteGrpIPv6| 963 +-+-+-+-+-+-+-+-+ 964 | Length | (1 byte) 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | IPv6 address (16 bytes) | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | .................. | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | IPv6 address (16 bytes) | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 o Type: sub-TLV Type, set to Site Group IPv6 sub-TLV 252 [TBD]. 975 o Length: The size of the value. 977 o Value: The list of IPv6 addresses used by the site. 979 The Site Group IPv6 sub-TLV is carried within the MT-PORT-CAP TLV and 980 this is carried in a Hello PDU. 982 2.3.10. Adjacency Server IPv4 sub-TLV 984 +-+-+-+-+-+-+-+-+ 985 |Type = ASIPv4 | 986 +-+-+-+-+-+-+-+-+ 987 | Length | (1 byte) 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | IPv4 address (4 bytes) | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Flags(1 byte)| 992 +-+-+-+-+-+-+-+-+ 994 o Type: sub-TLV Type, set to Adjacency Server IP sub-TLV 253 [TBD]. 996 o Length: The size of the value. 998 o Value: The list of IPv4 addresses used by the site. 1000 o Flags: Indicates unicast reachability. 1002 The Adjacency Server IP sub-TLV is carried within the MT-PORT-CAP TLV 1003 and this is carried in a Hello PDU. 1005 2.3.11. Adjacency Server IPv6 sub-TLV 1007 +-+-+-+-+-+-+-+-+ 1008 |Type = ASIPv6 | 1009 +-+-+-+-+-+-+-+-+ 1010 | Length | (1 byte) 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | IPv6 address (16 bytes) | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Flags(1 byte)| 1015 +-+-+-+-+-+-+-+-+ 1017 o Type: sub-TLV Type, set to Adjacency Server IPv6 sub-TLV 254 1018 [TBD]. 1020 o Length: The size of the value. 1022 o Value: The list of IPv6 addresses used by the site. 1024 o Flags: Indicates unicast reachability. 1026 The Adjacency Server IPv6 sub-TLV is carried within the MT-PORT-CAP 1027 TLV and this is carried in a Hello PDU. 1029 2.4. Sub-TLVs for the Router Capability TLV 1031 The Router Capability TLV is an optional TLV [RFC 4971] that may be 1032 generated by the originating Intermediate System. We specify these 1033 additional sub-TLVs that can be carried in it. These sub-TLVs 1034 announce the capabilities of the Intermediate System to the entire 1035 IS-IS routing domain. 1037 2.4.1. The TRILL Version sub-TLV 1039 The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL 1040 Versions. The device announces the maximum version of TRILL, it is 1041 capable of supporting, including lower versions. In the event, this 1042 sub-TLV is missing, this implies that the node can only support the 1043 base version of the protocol. 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Type | Length | Reserved | Max-version | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 o Type: sub-TLV Type, set to 5 (TRILL-VER). 1052 o Length: 2 - Total number of bytes contained in the value. 1054 o Reserved: Set to zero on transmission and ignored on receipt. 1056 o Max-version: Set to application dependent values. 1058 2.4.2. The Nickname sub-TLV 1060 The Nickname (NICKNAME) sub-TLV carries information about the 1061 nicknames of the advertising device, along with information about its 1062 priority to hold those nicknames. The Nickname sub-TLV MUST be 1063 carried within a Router CAPABILITY TLV in a level-1 LSP generated by 1064 the originating IS. Multiple instances of this sub-TLV are allowed 1065 to be carried. 1067 +-+-+-+-+-+-+-+-+ 1068 |Type = NICKNAME| 1069 +-+-+-+-+-+-+-+-+ 1070 | Length | (1 byte) 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | NICKNAME RECORDS (1) | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | ................. | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | NICKNAME RECORDS (N) | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 where each nickname record is of the form: 1081 +-+-+-+-+-+-+-+-+-+ 1082 |Nickname Priority| (1 byte) 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Tree Root Priority | (2 byte) 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Nickname | (2 bytes) 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 o Type: sub-TLV Type, set to 6 (NICKNAME). 1090 o Length: 5*N, where N is the number of nickname records present. 1092 o Nickname Priority: This is an unsigned 8-bit integer that gives 1093 the priority with which this node holds this nickname. 1095 o Tree Root Priority: This is an unsigned 16-bit integer that gives 1096 the value of the priority with which this nickname wants to be the 1097 highest priority root node in the Layer-2 domain. 1099 o Nickname: This is an unsigned 16-bit integer that gives device 1100 identifier or alias. 1102 Each nickname record consists of a one-byte priority set to 1103 application dependent values, two bytes of tree root priority and two 1104 bytes of device identifier or alias (i.e., actual nickname). 1106 2.4.3. The Trees sub-TLV 1108 The Trees sub-TLV MUST occur only once and is carried within the 1109 Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by 1110 the originating IS. Each device announces three numbers: the number 1111 of trees it dictates that all other Intermediate Systems in the 1112 campus compute if it is the highest priority tree root; the maximum 1113 number of trees it is able to compute; and the number of distribution 1114 trees it wishes to be able to use in forwarding multi-destination 1115 traffic. 1117 All nodes run the same algorithm as described in [RBRIDGES] and the 1118 elected highest priority tree root dictates the number of 1119 distribution tree roots to be used in the network domain and can 1120 additionally list those roots in the tree roots identifier sub-TLV. 1122 +-+-+-+-+-+-+-+-+ 1123 |Type = TREE | 1124 +-+-+-+-+-+-+-+-+ 1125 | Length | (1 byte) 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Number of trees to compute | (2 byte) 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Maximum trees able to compute | (2 byte) 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Number of trees to use | (2 byte) 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 o Type: sub-TLV Type, set to 7 (TREE). 1135 o Length: 6 : Total number of bytes contained in the value field. 1137 o Number of trees to compute: This is an unsigned 16-bit integer 1138 that gives the requested number of distribution trees for multi- 1139 destination frames that will be in use in the Layer-2 domain, if 1140 this device becomes the highest priority tree root in the domain. 1142 o Maximum number of trees able to compute: This is an unsigned 16- 1143 bit integer that give the maximum number of threes that the 1144 originating IS is able to compute for the campus. 1146 o Number of trees to use: This is an unsigned 16-bit integer that 1147 gives the number of distribution trees the originating IS wishes 1148 to be able to use. 1150 2.4.4. The Tree Identifiers Sub-TLV 1152 The tree identifiers sub-TLV is an ordered list of nicknames. When 1153 originated by the Intermediate System which is the highest priority 1154 tree root, this list is the trees which the other Intermediate 1155 Systems are required to compute. If this information is spread 1156 across multiple sub-TLVs, the starting tree number is used to figure 1157 out the ordered list. It is carried within the Router CAPABILITY TLV 1158 in a level-1 non-pseudo-node LSP and is given as: 1160 +-+-+-+-+-+-+-+-+ 1161 |Type=TREE-RT-ID| 1162 +-+-+-+-+-+-+-+-+ 1163 | Length | (1 byte) 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 |Starting Tree Number | (2 bytes) 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Nickname (K-th root) | (2 bytes) 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Nickname (K+1 - th root) | (2 bytes) 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Nickname (...) | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 o Type: sub-TLV Type, set to 8 (TREE-RT-IDs). 1176 o Length: Total number of bytes contained in the value field. 1178 o Starting Tree Number: This identifies the starting tree number of 1179 the nicknames that are trees for the domain. This is set to 1 for 1180 the first sub-TLV. The starting value and the length field gives 1181 the number of nicknames being carried in the sub-TLV. In the 1182 event a tree identifier can be computed from two such sub-TLVs and 1183 are different, then it is assumed that this is a transient 1184 condition that will get cleared. 1186 o Nickname: The nickname on which this tree is based. 1188 2.4.5. The Trees Used Identifiers Sub-TLV 1190 This sub-TLV has the same structure as the Tree Identifiers sub-TLV 1191 specified in the above section. The only difference is that its sub- 1192 TLV type is set to 9 TBD (TREE-USE-IDs) and the trees listed are only 1193 those that the originating intermediate systems wishes to use. 1195 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV 1197 The value of this sub-TLV consists of a VLAN range, flags, and a 1198 variable length list of spanning tree root bridge IDs. This sub-TLV 1199 may appear zero, one, or many times. The union of the VLAN ranges in 1200 all occurrences MUST be precisely the set of VLANs for which the 1201 originating Intermediate System is appointed forwarder on at least 1202 one port and the VLAN ranges in multiple VLANs sub-TLVs for an 1203 Intermediate System MUST NOT overlap. That is, the intersection of 1204 the VLAN ranges for any pair of these sub-TLVs originated by an 1205 Intermediate System must be null. The value length is 10 + 6*n where 1206 n is the number of root bridge IDs. The TLV layout is as follows: 1208 +-+-+-+-+-+-+-+-+ 1209 |Type = INT-VLAN| 1210 +-+-+-+-+-+-+-+-+ 1211 | Length | (1 byte) 1212 +---------------+-----+ 1213 | Nickname | (2 bytes) 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Interested VLANS | (8 bytes) 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Root Bridges | (6*n bytes) 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 o Type: sub-TLV Type, set to 10 (INT-VLAN). 1222 o Length: Total number of bytes contained in the value field. 1224 o Nickname: If this is set to 0, then it applies to all device-ids 1225 generated by the node. It may alternatively be set to a specific 1226 nickname, in the event a node wants to segregate traffic using 1227 multiple device-ids. 1229 o Interested VLANS: In the Interested VLANs, as shown below, the M4 1230 bit indicates that there is an IPv4 multicast router on a link for 1231 which the originating Intermediate System is appointed forwarder 1232 for every VLAN in the indicated range. The M6 bit indicates the 1233 same for an IPv6 multicast router. The R and Reserved bits MUST 1234 be sent as zero and are ignored on receipt. The VLAN start and 1235 end IDs are inclusive. A range of one VLAN ID is indicated by 1236 setting them both to that VLAN ID value. The Appointed Forwarder 1237 Status Lost Counter is also included here. It is a count of how 1238 many times a port that was appointed forwarder for the VLANs in 1239 the range given has lost the status of being an appointed 1240 forwarder. It has the following format: 1241 0 1 2 3 4 - 15 16 - 19 20 - 31 1242 +----+----+----+----+------------+----------+------------+ 1243 | M4 | M6 | R | R | VLAN start | Reserved | VLAN end | 1244 +----+----+----+----+------------+----------+------------+ 1245 | Appointed Forwarder Status Lost Counter | 1246 +----+----+----+----+------------+----------+------------+ 1248 o Root Bridges: The list of zero or more spanning tree root bridge 1249 IDs is the set of root bridge IDs seen for all ports for which the 1250 Intermediate System is appointed forwarder for the VLANs in the 1251 range. This information is learned from BPDUs heard by the 1252 Intermediate System. If MSTP is in use on a link, the root bridge 1253 referred to is the CIST (common and internal spanning tree) root 1254 bridge. (While, of course, only one spanning tree root should be 1255 seen on any particular port, there may be multiple ports in the 1256 same VLAN connected to differed bridged LANs with different 1257 spanning tree roots.) If no spanning tree roots can be seen on 1258 any of the links in any of the VLANs in the range indicated for 1259 which the Intermediate System is appointed forwarder (for example 1260 all such links are point-to-point links to other Intermediate 1261 Systems or to end stations so no BPDUs are received) then the 1262 listed set of spanning tree root IDs will be null. 1264 If there are any two VLANs in the range indicated for which the value 1265 of the M4, or M6 bits or the Appointed Forwarder Status Lost Counter 1266 are different, the sub-TLV is incorrect and must be split into 1267 multiple sub-TLVs each indicating only VLANs with the same M4, M6, 1268 and Appointed Forwarder Status Lost Counter values. If there are any 1269 two VLANs in the range indicated for which the set of root bridge IDs 1270 see on all links for which the Intermediate System is appointed 1271 forwarder for the VLAN are not the same, the sub-TLV is incorrect and 1272 must be split into multiple subTLVs each indicating only VLANs with 1273 the same set of DRB seen root bridge IDs. It is always safe to use 1274 sub-TLVs with a "range" of one VLAN ID but this may be too verbose. 1276 Wherever possible, an implementation SHOULD advertise the update to a 1277 interested vlan and spanning tree roots sub-TLV in the same LSP 1278 fragment as the advertisement that it replaces. Where this is not 1279 possible, the two affected LSP fragments should be flooded as an 1280 atomic action. 1282 Systems that receive an update to an existing interested vlan and 1283 spanning tree roots sub-TLV can minimize the potential disruption 1284 associated with the update by employing a holddown time prior to 1285 processing the update so as to allow for the receipt of multiple LSP 1286 fragments associated with the same update prior to beginning 1287 processing. 1289 Where a receiving system has two copies of a interested vlan and 1290 spanning tree roots sub-TLV from the same system that have different 1291 settings for a given vlan, the procedure used to choose which copy 1292 shall be used is undefined (refer to RFC 4971, Section 3). 1294 This sub-TLV is carried within the CAPABILITY TLV in a level-1 non- 1295 pseudo-node LSP. 1297 2.4.7. The VLAN Group sub-TLV 1299 The VLAN Group sub-TLV consists of two or more 16-bit fields each of 1300 which has a VLAN ID in the low order 12 bits. The top 4 bits MUST be 1301 sent as zero and ignored on receipt. The first such VLAN ID is the 1302 primary, or may be zero if there is no primary. It is carried within 1303 the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is structured 1304 as follows: 1306 +-+-+-+-+-+-+-+-+ 1307 |Type=VLAN-GROUP| 1308 +-+-+-+-+-+-+-+-+ 1309 | Length | (1 byte) 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Primary VLAN ID (2 bytes) | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Secondary VLAN ID (2 bytes) | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | more Secondary VLAN IDs ... | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 o Type: TLV Type, set to 11 (VLAN-GROUPs). 1320 o Length: Total number of bytes contained in the value field, 4 + 1321 2*n, where n may be 0. 1323 o Primary VLAN-ID: This identifies the primary VLAN-ID. 1325 o Secondary VLAN-ID: This identifies the secondary VLAN-ID, address 1326 learning is shared at the Intermediate System that announces this 1327 sub-TLV. 1329 This sub-TLV may appear zero, one, or multiple times. It should be 1330 noted that all VLAN ID values described above have a 4 bit reserved 1331 section followed by a 12-bit value. It is carried within the 1332 CAPABILITY TLV. 1334 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-TLV 1336 By including this sub-TLV within one or more Router Capability TLVs 1337 in its LSPs, an RBridge can advertise the Ingress-to-Egress options 1338 it supports. This sub-TLV may appear zero or more times within a 1339 Router Capability TLV. By default, in the absence of any ITEOPT sub- 1340 TLVs, no Ingress-to-Egress options are supported. 1342 There are two types of Ingress-to-Egress option encoding within the 1343 TRILL Header: bit options and TLV encoded options. 1345 The bit-encoded options supported are indicated by an ITEOPT sub-TLV 1346 of length 3: an initial value byte of 0x00 followed by two bytes in 1347 which each bit indicates that the corresponding bit Ingress-to-Egress 1348 option is implemented. 1350 Other Ingress-to-Egress options are TLV encoded within the TRILL 1351 Header options area. The implementation of a TLV encoded option is 1352 indicated by an ITEOPT sub-TLV whose value starts with a byte equal 1353 to the first byte of the option. Such ITEOPT sub-TLVs may have 1354 additional value bytes further indicating how the option is supported 1355 as specified in the option's definition, for example a list of 1356 supported security algorithms. 1358 +-+-+-+-+-+-+-+-+ 1359 | Type = ITEOPT | 1360 +-+-+-+-+-+-+-+-+ 1361 | Length | (1 byte) 1362 +-+-+-+-+-+-+-+-+ 1363 | Option | (1 byte) 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | Option dependent variable length information | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 o Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12 1369 [TBD]. 1371 o Length: variable, minimum 1. 1373 o Value: The first byte of the option followed by option dependent 1374 information. 1376 2.4.9. VLAN Mapping (VMAP) sub-TLV 1378 The VLAN Mapping (VMAP) TLV carries information concerning VLAN 1379 mappings configured at the originating IS. VLAN mapping is used when 1380 an RBridge campus is divided into regions such that the same VLAN is 1381 represented by different VLAN IDs in different regions or there is a 1382 VLAN is one region that has no equivalent in another region. Each 1383 port on each of the border RBridges between two or more regions MUST 1384 be configured at to which region each port connects with. The 1385 numbering of regions is an arbitrary choice but all border RBridges 1386 in the campus MUST agree on the number of each region. 1388 +-+-+-+-+-+-+-+-+ 1389 | Type = VMAP | 1390 +-+-+-+-+-+-+-+-+ 1391 | Length | (1 byte) 1392 +-+-+-+-+-+-+-+-+----------...+ 1393 | Mapping 1 | (8 bytes) 1394 +-+-+-+-+-+-+-+------------... 1395 | Mapping N, etc.| 1396 +--------------------------... 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | Count | From VLAN ID | (2 bytes) 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 | From Region | (2 bytes) 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 | RESV | To VLAN ID | (2 bytes) 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 | To Region | (2 bytes) 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 o Type: sub-TLV Type, set to VLAN Mapping sub-TLV 13 [TBD]. 1410 o Length: variable, 8*N. 1412 o Value: Specific information on each VLAN mapping as diagrammed 1413 above and specified below: 1415 * Count: If this four bit unsigned integer is zero or 1, then the 1416 mapping of a single VLAN ID is being specified. If it is any 1417 value from 2 through 15, then a block of that many contiguous 1418 VLAN IDs starting with the From VLAN ID is mapped to a block of 1419 that many contiguous VLAN IDs starting with the To VLAN ID. 1421 * From VLAN ID: This is the VLAN ID that, when received on a port 1422 connect to the From Region on a frame being sent to the To 1423 Region, is mapped to the To VLAN ID. This must be a real VLAN 1424 ID, that is, the values 0x000 and 0xFFF are prohibited. 1426 * From Region: This is the region number, within the campus, such 1427 that frames received on a port connected to that region and 1428 destined to a port connected to the To Region have their VLAN 1429 ID mapped as specified by the From VLAN ID and To VLAN ID 1430 fields. 1432 * RESV: MUST be sent as zero and ignored on receipt. 1434 * To VLAN ID: This is the VLAN ID to be used on frames sent out a 1435 port connected to the To Region if they were received on a port 1436 connected to the From Region with the From VLAN ID; except that 1437 if the To VLAN ID is 0x000 the frame is dropped. The value 1438 invalid VLAN ID 0xFFF is prohibited in this field. 1440 * To Region: This is the region number, within the campus, such 1441 that frames sent on a port connected to this region from a port 1442 connected to the From Region have their VLAN ID mapped as 1443 specified by the From VLAN ID and To VLAN ID fields. 1445 2.5. Multi Topology Aware Capability TLV 1447 This section defines a new optional Intermediate System to 1448 Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of 1449 multiple sub-TLVs, which allows a router to announce its capabilities 1450 for a particular topology within an IS-IS level or the entire routing 1451 domain. This is different from Router Capability TLV defined in RFC 1452 4971, in the sense, the capabilities announced here are topology 1453 scoped. 1455 The Multi Topology Aware Capability (MT-CAPABILITY) is an optional 1456 IS-IS TLV type 144 [TBD], that may be generated by the originating IS 1457 and has the following format: 1458 0 1 2 3 1459 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 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 |Type=MTCAPABTLV| Length |O|R|R|R| Topology Identifier | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | sub-TLVs | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 o Type: TLV Type, set to MT-CAPABILITY TLV 144 [TBD]. 1468 o Length: Total number of bytes contained in the value field, 1469 including the length of the sub-TLVs carried in this TLV. 1471 o O bit: The overload bit that follows the semantics associated with 1472 an overloaded intermediate system. 1474 o Topology Identifier: MT ID is a 12-bit field containing the MT ID 1475 of the topology being announced. This field when set to zero 1476 implies that it is being used to carry base topology information. 1477 In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, 1478 it may be non-zero. 1480 o sub-TLVs: The MT aware Capabilities TLV value contains sub-TLVs 1481 formatted as described in [RFC5305]. They are defined in the next 1482 sections. 1484 The MT-CAPABILITY TLV MUST be carried only within a LSP PDU. It may 1485 occur multiple times in a LSP PDU. 1487 2.5.1. SPB Instance sub-TLV 1489 The SPB Instance sub-TLV gives the SPSourceID for this node/topology 1490 instance. This is the 20 bit value that is used in the formation of 1491 multicast DA addresses for packets originating from this node/ 1492 instance. The SPSourceID occupies the upper 20 bits of the multicast 1493 DA together with 4 other bits (see the SPB 802.1ah multicast DA 1494 address format section). 1496 This sub-TLV SHOULD be carried within the MT-Capability TLV in the 1497 fragment ZERO LSP. 1499 +-+-+-+-+-+-+-+-+ 1500 |Type = SPB-Inst| 1501 +-+-+-+-+-+-+-+-+ 1502 | Length | (1 byte) 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | CIST Root Identifier (4 bytes) | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | CIST Root Identifier (cont) (4 bytes) | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | CIST External ROOT Path Cost (4 bytes) | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 | Bridge Priority | (2 bytes) 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 |R R R R| SPS Flags |V| SPSOURCEID | (4 bytes) 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 | Num of Trees | (1 bytes) 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | VLAN-ID (1) Tuples (8 bytes) | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | VLAN-ID (N) Tuples (8 bytes) | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | ECT-Alg-Len | (1 bytes) 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | Opaque ECT Algorithm (32 bytes) | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | Opaque ECT Information (variable ) | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 where VLAN-ID tuples have the format as: 1529 0 1 2 3 1530 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 1531 +-+-+-+-+-+-+-+-+ 1532 |U|M|A| Res | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | ECT - Algorithm (32 bits) | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Base VID 12 bits) | SPTVID 12 bits) | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 o Type: sub-TLV Type, set to SPB Instance sub-TLV 1 [TBD]. 1541 o Length: Total number of bytes contained in the value field. 1543 o CIST Root Identifier (64-bits)The CIST Root Identifier is for SPB 1544 interworking with RSTO and MSTP at SPT RegionBoundaries. This is 1545 an imported value from a Spanning tree. 1547 o CIST External Root Path Cost (32-bits) The CIST External Root Path 1548 Cost is the cost from the Spanning tree algorithm to the Root. 1550 o Bridge Priority (16-bits) Bridge priority is the 16 bits that 1551 together with the low 6 bytes of the System ID form the Bridge 1552 Identifier. The Bridge Identifier is the Spanning tree compatible 1553 Bridge identifier. This is configured exactly as specified in 1554 IEEE802 [802.1D]. This allows SPB to build a compatible Spanning 1555 tree using link state by combining the Bridge Priority and the 1556 System ID to form the 8 byte Bridge Identifier. The 8 byte Bridge 1557 Identifier is also the input to the 16 pre-defined ECT tie breaker 1558 algorithms. 1560 o V bit (1-Bit) The V bit (SPBM) indicates this SPSourceID is auto 1561 allocated(27.11). If the V bit is clear the SPSourceID has been 1562 configured and must be unique. Allocation of SPSourceID is in 1563 [IEEE 802.1aq]. Bridges running SPBM will allocate an SPSourceID 1564 if they are not configured with an explicit SPSourceID. The V Bit 1565 allows neighbor bridges to determine if the auto allocation was 1566 enabled. In the rare chance of a collision of SPsourceID the 1567 bridge with the highest priority Bridge Identifier will win 1568 conflicts and the lower priority Bridge will be re-allocated or if 1569 the lower priority Bridge is configured it will not be allowed to 1570 joint the SPT Region. 1572 o The SPSOURCEID is a 20 bit value used to construct multicast DA's 1573 as described below for multicast packets originating from the 1574 origin (SPB node) of the link state packet (LSP) that contains 1575 this TLV. More details are in [IEEE 802.1aq]. 1577 o Number of Trees (8-bits) The Number of Trees is be set to the 1578 number of [ECT-ALGORITHM, Base-VID plus flags] sub TLV's that 1579 follow. Each ECT-ALGORITHM has an Base VID, an SPVID and some 1580 flags described below. This must be set to at least one ECT. 1581 These define the standard ECTs. 1583 o Each VID Tuple consists of: 1585 * U-Bit (1-bit) The Use flag is set if this bridge is currently 1586 using this ECT-ALGORITHM for I-SIDs it sources or sinks. This 1587 is a bit different than the U-bit found in the Hello, which 1588 will set the Use-Flag if it sees other nodal Use-Flags are set 1589 OR it sources or sinks itself. 1591 * M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode. 1593 * A bit, The A bit (SPB) when set declares this is an SPVID with 1594 auto allocation. The VID allocation logic details are in [IEEE 1595 802.1aq]. Since SPVIDs are from a small pool of resources 1596 (1000 or less) the chances of collision are high. To allow 1597 auto allocation LSPs are exchanged with the allocated bridge 1598 setting the SPVID to 0. 1600 o ECT-ALG-LEN (1 byte): This gives the length of the ECT Algorithm. 1602 o ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is advertised when the 1603 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 1604 VID. This declaration must match the declaration in the Hello PDU 1605 originating from the same bridge. The ECT-ALGORITHM, BASE-VID 1606 should match what is generated in the Hellos of the same node. 1607 The ECT-ALGORITHM, BASE-VIDs pairs can come in any order however. 1609 o Base VID (12-bits) The Base-VID that associated the SPT Set via 1610 the ECT-ALGORITHM. 1612 o SPVID (12-bits) The SPVID is the Shortest Path VID when using SPBV 1613 mode. It is not defined for SPBM Mode and should be 0 in SPBM 1614 mode. 1616 o an opaque ECT Data TLV (type TBD) whose first 32 bits are the ECT- 1617 ALGORITHM which this data applies to. 1619 2.5.2. SPBM Service Identifier and Unicast Address sub-TLV 1621 The SPBM Service Identifier and Unicast Address sub-TLV is used to 1622 introduce service group membership on the originating node and/or to 1623 advertise an additional B-MAC unicast address present on, or 1624 reachable by the node. 1626 +-+-+-+-+-+-+-+-+ 1627 |Type = SPBM-SI | 1628 +-+-+-+-+-+-+-+-+ 1629 | Length | (1 byte) 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | B-MAC ADDRESS (6 bytes) | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Res. | Base-VID | ( 2 bytes) 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 |T|R| Reserved | ISID #1 | (1+3 bytes) 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 |T|R| Reserved | ISID #2 | (1+3 bytes) 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 |T|R| Reserved | ISID #n | (1+3 bytes) 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 o Type: sub-TLV Type, set to SPBM Service Identifier and Unicast 1642 Address sub-TLV 2 [TBD]. 1644 o Length: Total number of bytes contained in the value field. 1646 o B-MAC ADDRESS is a unicast address of this node. It may be either 1647 the single nodal address, or may address a port or any other level 1648 of granularity relative to the node. In the case where the node 1649 only has one B-MAC address this should be the same as the SYS-ID 1650 of the node. To add multiple B-MACs this TLV must be repeated per 1651 additional B-MAC. 1653 o ISID #1 .. #N are 24 bit service group membership identifiers. If 1654 two nodes have an ISID in common, intermediate nodes on the unique 1655 shortest path between them will create forwarding state for the 1656 related B-MAC addresses and will also construct multicast 1657 forwarding state using the ISID and the node's SPSOURCEID to 1658 construct a multicast DA as described in IEEE 802.1aq LSB. Each 1659 ISID has a Transmit(T) and Receive(R) bit which indicates if the 1660 membership is as a Transmitter/Receiver or both (with both bits 1661 set). In the case where the Transmit(T) and Receive(R) bits are 1662 both zero, the ISID is ignored. If more ISIDs are associated with 1663 a particular B-MAC than can fit in a single TLV, this TLV can be 1664 repeated with the same B-MAC but with different ISID values. 1666 2.6. Sub-TLVs of the Extended Reachability TLV 1668 This section specifies two new sub-TLVs that appear only within the 1669 Extended Reachability TLV (type 22). 1671 2.6.1. SPB Link Metric sub-TLV 1673 The SPB Link Metric sub-TLV occurs nested as within the Extended 1674 Reachability TLV (type 22), or the Multi Topology Intermediate System 1675 TLV (type 222). If this sub TLV is not present for an ISIS adjacency 1676 then that adjacency MUST NOT carry SPB traffic for the given topology 1677 instance. 1679 +-+-+-+-+-+-+-+-+ 1680 |Type=SPB-Metric| 1681 +-+-+-+-+-+-+-+-+ 1682 | Length | (1 byte) 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | SPB-LINK-METRIC | (3 bytes) 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 | Num of ports | (1 byte) 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | Port Identifier | ( 2 bytes) 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Opaque ECT Algorithm (32 bytes) | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Opaque ECT Information (variable ) | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 o Type: TLV Type, set to SPB Link Metric sub-TLV 5 [TBD]. 1697 o Length: Total number of bytes contained in the value field. 1699 o SPB-LINK-METRIC indicates the administrative cost or weight of 1700 using this link as a 24 bit unsigned number. Smaller numbers 1701 indicate lower weights and are more likely to carry SPB traffic. 1702 Only one metric is allowed per SPB instance per link. If multiple 1703 metrics are required multiple SPB instances are required, either 1704 within IS-IS or within several independent IS-IS instances. 1706 o Num of Ports is the number of ports associated with this link. 1708 o Port Identifier is the standard IEEE port identifier used to build 1709 a spanning tree associated with this link. 1711 o an opaque ECT Data TLV (type TBD) whose first 32 bits are the ECT- 1712 ALGORITHM to which this data applies. 1714 2.6.2. MTU sub-TLV 1716 The MTU sub-TLV is used to optionally announce the MTU of a link. It 1717 occurs nested as within the Extended Reachability TLV (type 22). 1719 +-+-+-+-+-+-+-+-+ 1720 | Type = MTU | 1721 +-+-+-+-+-+-+-+-+ 1722 | Length | (1 byte) 1723 +-+-+-+-+-+-+-+-+ 1724 |F| Reserved | (1 byte) 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | MTU | (2 bytes) 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 o Type: TLV Type, set to MTU sub-TLV 6 [TBD]. 1731 o Length: Total number of bytes contained in the value field. 1733 o Failed: This bit is a one if MTU testing on this link failed at 1734 the required campus-wide MTU. 1736 o MTU: This field is set to the largest successfully tested MTU size 1737 for this link or zero if it has not been tested. 1739 2.7. TRILL Neighbor TLV 1741 The TRILL Neighbor TLV is used in the TRILL-Hello PDU in place of the 1742 IS Neighbor TLV. It differs in that MTU information is provided per 1743 neighbor and provision is made for fragmentation, so that not all 1744 neighbors need be reported in each TRILL-Hello, to support the hard 1745 limit on the size of TRILL-Hellos. This TLV can occur zero, one, or 1746 multiple times in a TRILL-Hello PDU. The structure of the TRILL 1747 Neighbor TLV is as follows: 1749 +-+-+-+-+-+-+-+-+ 1750 | Type = TNeigh | 1751 +-+-+-+-+-+-+-+-+ 1752 | Length | (1 byte) 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 |S|L| Reserved | (2 bytes) 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Neighbor RECORDS (1) | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | ................. | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Neighbor RECORDS (N) | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 The list of neighbors MUST be ordered by MAC address, considering 1764 each 6-byte MAC address to be an unsigned integer, starting with the 1765 smallest. The information present for each neighbor is as follows: 1767 +-+-------------------+ 1768 |F| Reserved | (2 bytes) 1769 +-+-------------------+ 1770 | MTU | (2 bytes) 1771 +--------------------------------------------------------+ 1772 | MAC Address | (6 bytes) 1773 +--------------------------------------------------------+ 1774 o Type: TLV Type, set to TRILL-Neighbor TLV XX [TBD]. 1776 o Length: Total number of bytes contained in the value field, 2 + 1777 10*n, where n is the number of neighbor records. 1779 o S: smallest flag. If this bit is a one, then the list of 1780 neighbors includes the neighbor with the smallest MAC address. 1782 o L: largest flag. If this bit is a one, then the list of neighbors 1783 includes the neighbor with the largest MAC address. 1785 o Reserved: These bits are reserved for future use and MUST be set 1786 to zero on transmission and ignored on receipt. 1788 o F: failed. This bit is a one if MTU testing to their neighbor 1789 (see Section 3.3) failed at the required campus-wide MTU 1791 o MTU: This field is set to the largest successfully tested MTU size 1792 for this neighbor or zero if it has not been tested. 1794 o MAC Address: The MAC address of the neighbor as in the IS Neighbor 1795 RLV (#6). 1797 2.8. The Group Membership Active Source TLV 1799 The Group Active Source (GMAS) TLV is IS-IS TLV type 146 [TBD] and 1800 has the following format: 1802 +-+-+-+-+-+-+-+-+ 1803 | Type = GMAS | (1 byte) 1804 +-+-+-+-+-+-+-+-+ 1805 | Length | (1 byte) 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | sub-TLVs (variable bytes) | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 o Type: TLV Type, set to GMAS-TLV 146 [TBD]. 1812 o Length: Total number of bytes contained in the value field, which 1813 includes the length of the sub-TLVs carried in this TLV. 1815 o sub-TLVs: The Group Active Source TLV value contains sub-TLVs 1816 formatted as described in [RFC5305]. The sub-TLVs for this TLV 1817 are specified in the following subsections. 1819 The GMAS TLV is carried within Multicast Group Level 1 link state 1820 PDU. 1822 2.8.1. The Group MAC Active Source sub-TLV 1824 The Group MAC Source (GMAS-MAC) sub-TLV is IS-IS sub-TLV type 1 1825 within the GMAS TLV and has the following format: 1827 +-+-+-+-+-+-+-+-+ 1828 | Type=GMAS-MAC | (1 byte) 1829 +-+-+-+-+-+-+-+-+ 1830 | Length | (1 byte) 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 |D|D| R | Vlan ID | (2 byte) 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | Address family | (2 bytes) 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Length | (1 byte) 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | Delivery group (afi scoped number of bytes) | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | Delivery Source (afi scoped number of bytes) | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 |Num Group Recs | (1 byte) 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 | GROUP RECORDS (1) | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | ................. | 1847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 | GROUP RECORDS (N) | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 where each group record is of the form: 1853 +-+-+-+-+-+-+-+-+ 1854 | RESERVED | (1 byte) 1855 +-+-+-+-+-+-+-+-+ 1856 | Num of Sources| (1 byte) 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Group Address (6 bytes) | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Source 1 Address (6 bytes) | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Source 2 Address (6 bytes) | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | Source M Address (6 bytes) | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 o Type: sub-TLV Type, set to 1 (GMAS-MAC) of length 1 byte. 1868 o Length: Total number of bytes contained in the value field. 1870 o Confidence: This carries an 8-bit quantity indicating the 1871 confidence level in the MAC addresses being transported. Whether 1872 this field is used, and its semantics if used, are further defined 1873 by the specific protocol using Layer-2-IS-IS. If not used, it 1874 MUST be set to zero on transmission and be ignored on receipt. 1876 o Topology-Id/Nickname : Depending on the technology in which it is 1877 used, this carries the topology-id or nickname. When this field 1878 is set to zero this implies that the MAC addresses are reachable 1879 across all topologies or across all nicknames of the originating 1880 IS. 1882 o RESERVED: Must be sent as zero on transmission and is ignored on 1883 receipt. 1885 o G: Delivery Group is set 1887 o S: Delivery Source is set 1889 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 1890 all subsequent MAC addresses in this TLV, or the value zero if no 1891 VLAN is specified. 1893 o Number of Group Records: This is of length 1 byte and lists the 1894 number of group records in this TLV. 1896 o Group Record: Each group record has a one byte reserved space and 1897 the next byte carries the number of sources. It then has a 48-bit 1898 multicast Group Address followed by 48-bit source MAC addresses. 1899 An address being a group multicast address or unicast source 1900 address can be checked using the multicast bit in the address. If 1901 the number of sources do not fit in a single sub-TLV, it is 1902 permitted to have the same group address repeated with different 1903 source addresses in another sub-TLV of another instance of the 1904 Group Active Source TLV. 1906 The GMAS-MAC sub-TLV is carried within the GMAS TLV and MUST be 1907 carried in a standard Level 1 link state MGROUP PDU. 1909 2.8.2. The Group IP Active Source sub-TLV 1911 The Group IP Address (GMAS-IP) sub-TLV is IS-IS TLV type 2 and has 1912 the following format: 1914 +-+-+-+-+-+-+-+-+ 1915 | Type=GMAS-IP | (1 byte) 1916 +-+-+-+-+-+-+-+-+ 1917 | Length | (1 byte) 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 |D|D| R | Vlan ID | (2 byte) 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | Address family | (2 bytes) 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Length | (1 byte) 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | Delivery group (afi scoped number of bytes) | 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Delivery Source (afi scoped number of bytes) | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 |Num Group Recs | (1 byte) 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | GROUP RECORDS (1) | 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | ................. | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | GROUP RECORDS (N) | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1938 where each group record is of the form: 1940 +-+-+-+-+-+-+-+-+ 1941 | RESERVED | (1 byte) 1942 +-+-+-+-+-+-+-+-+ 1943 | Num of Sources| (1 byte) 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | Group Address (4 bytes) | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | Source 1 Address (4 bytes) | 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | Source 2 Address (4 bytes) | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | Source M Address (4 bytes) | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 o Type: sub-TLV Type, set to 2 (GIP-ADDR). 1956 o Length: Total number of bytes contained in the value field of the 1957 TLV. 1959 o Confidence: This carries an 8-bit quantity indicating the 1960 confidence level in the IP addresses being transported. Whether 1961 this field is used, and its semantics if used, are further defined 1962 by the specific protocol using Layer-2-IS-IS. If not used, it 1963 must be set to zero on transmission and be ignored on receipt. 1965 o Topology-Id/Nickname : Depending on the technology in which it is 1966 used, this carries the topology-id or nickname. When this field 1967 is set to zero this implies that the MAC addresses are reachable 1968 across all topologies or across all nicknames of the originating 1969 IS. 1971 o RESERVED: Must be sent as zero on transmission and is ignored on 1972 receipt. 1974 o G: Delivery Group is set 1976 o S: Delivery Source is set 1978 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 1979 all subsequent MAC addresses in this TLV, or the value zero if no 1980 VLAN is specified. 1982 o Number of Group Records: This is of length 1 byte and lists the 1983 number of group records in this TLV. 1985 o Group Record: Each group record has a one byte reserved space and 1986 the next byte carries the number of sources. It is followed by a 1987 32-bit IPv4 Group Address followed by 32-bit source IPv4 1988 addresses. If the number of sources do not fit in a single sub- 1989 TLV, it is permitted to have the same group address repeated with 1990 different source addresses repeated in another sub-TLV of another 1991 instance of the Group Active Source TLV. 1993 The GMAS-IP TLV is carried within the GMAS TLV and MUST be carried in 1994 a standard Level 1 link state MGROUP PDU. 1996 2.8.3. The Group IPv6 Active Source sub-TLV 1998 The Group IPv6 Active Source (GMAS-IPv6) TLV is IS-IS sub-TLV type 3 1999 and has the following format: 2001 +-+-+-+-+-+-+-+-+ 2002 | Type=GMAS-IP | (1 byte) 2003 +-+-+-+-+-+-+-+-+ 2004 | Length | (1 byte) 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 |D|D| R | Vlan ID | (2 byte) 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | Address family | (2 bytes) 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | Length | (1 byte) 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | Delivery group (afi scoped number of bytes) | 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 | Delivery Source (afi scoped number of bytes) | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 |Num Group Recs | (1 byte) 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | GROUP RECORDS (1) | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | ................. | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | GROUP RECORDS (N) | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 where each group record is of the form: 2027 +-+-+-+-+-+-+-+-+ 2028 | RESERVED | (1 byte) 2029 +-+-+-+-+-+-+-+-+ 2030 | Num of Sources| (1 byte) 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2032 | Group Address (16 bytes) | 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Source 1 Address (16 bytes) | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Source 2 Address (16 bytes) | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | Source M Address (16 bytes) | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 o Type: sub-TLV Type, set to 3 (GIPV6-ADDR). 2043 o Length: Total number of bytes contained in the value field. 2045 o Confidence: This carries an 8-bit quantity indicating the 2046 confidence level in the IPv6 addresses being transported. Whether 2047 this field is used, and its semantics if used, are further defined 2048 by the specific protocol using Layer-2-IS-IS. If not used, it 2049 must be set to zero on transmission and be ignored on receipt. 2051 o Topology-Id/Nickname : Depending on the technology in which it is 2052 used, this carries the topology-id or nickname. When this field 2053 is set to zero this implies that the MAC addresses are reachable 2054 across all topologies or across all nicknames of the originating 2055 IS. 2057 o RESERVED: Must be sent as zero on transmission and is ignored on 2058 receipt. 2060 o G: Delivery Group is set 2062 o S: Delivery Source is set 2064 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 2065 all subsequent MAC addresses in this TLV, or the value zero if no 2066 VLAN is specified. 2068 o Number of Group Records: This of length 1 byte and lists the 2069 number of group records in this TLV. 2071 o Group Record: Each group record has a one byte reserved space and 2072 the next byte carries the number of sources. It is followed by a 2073 128-bit multicast IPv6 Group Address followed by 128-bit source 2074 IPv6 addresses. If the number of sources do not fit in a single 2075 sub-TLV, it is permitted to have the same group address repeated 2076 with different source addresses repeated in another sub-TLV in 2077 another instance of the Group Address TLV. 2079 The GMAS-IPv6 sub-TLV is carried within the GMAS TLV and MUST be 2080 carried in a standard Level 1 link state MGROUP PDU. 2082 2.9. PDU Extensions to IS-IS 2084 2.9.1. The Multicast Group PDU 2086 The systems that this document is concerned with want to carry not 2087 only layer-2 unicast information in the link state protocols, but 2088 also multicast information. This section specifies three new IS-IS 2089 PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of 2090 attached or joined multicast groups. The Multicast Group Complete 2091 Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial 2092 Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used 2093 with the new MGROUP-PDU to perform database exchange on the MGROUP 2094 PDU packets. 2096 In the Layer-2 environment, it is expected the join/leave frequency 2097 of the multicast members will be much higher than unicast topology 2098 changes. It is efficient to separate the updates for the group 2099 membership change information from the remainder of the information 2100 by placing this information in a separate PDU. This enables 2101 reachability information, that would trigger an SPF, to be not 2102 impacted at all. Furthermore, during SPF runs, TLVs being on 2103 different PDUs which do not affect SPF need not be inspected during 2104 processing. 2106 The choice of a different PDU also opens the LSP-space to another 256 2107 fragments to carry a large number of groups. This additional space 2108 can be used judiciously to carry only multicast information. 2110 The Multicast Group (MGROUP) PDU can be used to advertise a set of 2111 attached, or joined, multicast groups. The MGROUP PDU is formatted 2112 identical to a Level 1 Link State PDU, as described in Section 9.3 of 2113 [IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify 2114 this PDU is carrying multicast group information, rather than unicast 2115 reachability information. 2117 The Multicast Group PDU carries TLVs indicating multicast membership 2118 information. There are three sub-TLVs of the GADDR TLV defined in 2119 this document, that MAY be present in this PDU, namely, GMAC-ADDR, 2120 GIP-ADDR, and GIPV6-ADDR TLVs. 2122 One or more TLVs MAY be carried in a single MGROUP PDU. Future 2123 multicast address TLVs MAY be defined using other type codes, and be 2124 carried in an MGROUP PDU. 2126 The information carried in this PDU is processed in a similar fashion 2127 as described in [RFC 1584]. 2129 2.9.1.1. The Multicast Group Partial Sequence Number PDU 2131 The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used 2132 to reliably flood the MGROUP PDU following the base protocol 2133 specifications. 2135 2.9.1.2. The Multicast Group Complete Sequence Number PDU 2137 The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is 2138 used to reliably flood the MGROUP PDU following the base protocol 2139 specifications. 2141 2.9.1.3. Enhancements to the flooding process 2143 This document specifies that the information contained in the MGROUP- 2144 PDU is in a parallel database and its update mechanisms mimic that of 2145 the regular database. Nodes running IS-IS in an L2 domain MUST 2146 support these additional MGROUP PDUs defined in this document. In 2147 general, the flooding of the MGROUP-PDU in tandem with the MGROUP- 2148 PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined 2149 for the regular LSP, PSNP, and CSNP PDUs. 2151 For example, on P2P links CSNP is exchanged on the formation of an 2152 adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged 2153 between the neighbors at the same time. This gets the initial 2154 MGROUP-database synchronization going. After this similar actions of 2155 the base protocol specifications for the regular database 2156 synchronization will be maintained to keep the MGROUP-database 2157 synchronized. 2159 Similarly, on LAN links the DIS is responsible for sending periodic 2160 CSNP transmissions. The DIS in the L2 IS-IS network domain will also 2161 be responsible for sending periodic MGROUP-CSNP transmissions. The 2162 update and flooding process will work in parallel for the two 2163 databases and there is no further synchronization between them. 2165 In general, the database synchronization is performed in parallel 2166 with no interactions between the messages. However, the initial 2167 triggers that start a CSNP exchange are correlated, in the sense it 2168 also triggers a MGROUP-CSNP exchange. For example, during graceful 2169 restart [RFC 5306], the normal hello operations as described in the 2170 RFC will be followed. The enhancements will take place such that 2171 CSNP and PSNP triggers will necessitate a parallel MGROUP-CSNP and 2172 MGROUP-PSNP exchange and update process will be triggered in parallel 2173 for the MGROUP-PDUs. After both databases containing the regular 2174 PDUs and MGROUP-PDUs have been obtained, the restart process is 2175 deemed complete. 2177 2.9.1.4. Enhancements to the maximum sequence number reached 2179 In the event, LSPs reach the maximum sequence number, ISO/IEC 10589 2180 states the rules for the process to shut down and its duration. With 2181 the introduction of the MGROUP-PDU, the same process now applies when 2182 LSPs from either database reach the maximum sequence number. 2184 2.9.2. The TRILL-Hello PDU 2186 A different Hello PDU is required for TRILL links because it is 2187 necessary that a single Designated RBridge (DIS) be elected on each 2188 link based just on priority and MAC address regardless of two-way 2189 connectivity. However, RBridge reachability is reported by RBridges 2190 in their LSP on the same basis as layer 3 Intermediate Systems report 2191 reachability, that is, if and only if two-way connectivity exists. 2193 The TRILL-Hello PDU has the same general structure as an IS-IS LAN 2194 PDU. An RBridge (an Intermediate System supporting TRILL) sends this 2195 PDU, with the same timing as the IS-IS LAN Hello PDU. More 2196 specifically, in a TRILL-Hello PDU the IS-IS Common Header and the 2197 fixed PDU Header are the same as a Level 1 IS-IS LAN Hello except 2198 that a new PDU Type number is used as listed in Section 7. The 2199 circuit type field, of course, is always equal to one. A TRILL-Hello 2200 PDU SHOULD not be padded and MUST NOT exceed a length limit equal to 2201 42 bytes shorter than the reasonable lower bound for the link MTU. 2202 For example, for an 802.3 Ethernet link, the MTU SHOULD be assumed to 2203 be 1512 bytes for the purpose of determining the maximum size of 2204 TRILL-Hello PDUs on that link. Thus, for such a link, TRILL-Hellos 2205 MUST NOT exceed 1470 bytes. 2207 The following MUST appear in every TRILL-Hello PDU: a Port Capability 2208 TLV (see Section 2.3) containing a Special VLANs and Flags sub-TLV. 2210 Additional TLVs/sub-TLVs MAY appear in a TRILL-Hello including the 2211 TRILL Neighbor TLV specified in Section 2.7 and the following sub- 2212 TLVs specified in Section 2.3: Enabled VLANs sub-TLV, Appointed 2213 Forwarders sub-TLV, and Hop-by-Hop Options sub-TLV. 2215 The Padding TLV (#8) SHOULD NOT appear in a TRILL-Hello. 2217 The IS-IS Neighbor TLV (#6) MUST NOT appear in a TRILL-Hello. 2218 Instead, it uses the TRILL Neighbor TLV (see Section 2.7). 2220 2.9.3. The MTU PDU 2222 The MTU-probe and MTU-ack PDUs are used to determine the MTU on a 2223 link between intermediate systems. An MTU-probe MUST be padded to 2224 the size being tested with the Padding TLV (#8). The ability to send 2225 an MTU-probe PDU is optional but an Intermediate System that supports 2226 TRILL MUST send an MTU-ack in response to an MTU-probe and that MTU- 2227 ack MUST be padded to the size of the MTU-probe. 2229 The MTU PDUs have the standard IS-IS common header with two new PDU 2230 Type numbers, one each, as listed in Section 7. They also have a 20- 2231 byte common fixed MTU PDU header as shown below. 2233 +------------+ 2234 | PDU Length | (2 bytes) 2235 +------------+-------------------------+ 2236 | Probe ID | (6 bytes) 2237 +--------------------------------------+ 2238 | Probe Source ID | (6 bytes) 2239 +--------------------------------------+ 2240 | Ack Source ID | (6 bytes) 2241 +--------------------------------------+ 2243 As with other IS-IS PDUs, the PDU length contains length of the 2244 entire IS-IS packet starting with and including the IS-IS common 2245 header. 2247 The Probe ID field is an arbitrary 48-bit quantity set by the 2248 Intermediate System issuing an MTU-probe and copied by the responding 2249 system into the corresponding MTU-ack. For example, an Intermediate 2250 System creating an MTU-probe could compose this quantity from a port 2251 identifier and probe sequence number relative to that port. 2253 The Probe Source ID is set by an Intermediate system issuing an MTU- 2254 probe to its System ID and copied by the responding system into the 2255 corresponding MTU-ack. 2257 The Ack Source ID is set to zero in MTU-probe PDUs. An Intermediate 2258 System issuing an MTU-ack set this field to its System ID. 2260 The TLV area follows the MTU PDU header area. This area MAY contain 2261 an Authentication TLV and MUST be padded to the size being tested 2262 with the Padding TLV. 2264 3. Acknowledgements 2266 The authors would like to thank Les Ginsberg and Mike Shand for their 2267 useful comments. 2269 4. Security Considerations 2271 This document adds no additional security risks to IS-IS, nor does it 2272 provide any additional security for IS-IS. 2274 5. IANA Considerations 2276 This document creates six new PDU types, namely the MCAST PDU, MCAST- 2277 CSNP PDU, the MCAST-PSNP PDU, TRILL-HELLO-PDU, MTU-PROBE-PDU, and 2278 MTU-ACK-PDU. IANA SHOULD assign a new PDU type to the level-1 PDUs 2279 described above and reflect it in the PDU registry. 2281 MCAST-PDU Level-1 PDU Type: 19 2282 MCAST-CSNP-PDU Level-1 PDU Type: 22 2283 MCAST-PSNP-PDU Level-1 PDU Type: 29 2284 TRILL-HELLO-PDU Level-1 PDU Type: 21 2285 MTU-PROBE-PDU Level-1 PDU Type: 23 2286 MTU-ACK-PDU Level-1 PDU Type: 28 2288 This document specifies the definition a set of new IS-IS TLVs, the 2289 MAC-Reachability TLV (type 141), the Group Address TLV (type 142), 2290 the Port-Capability TLV (type 143), the MT-Capability TLV (type 144), 2291 and the Trill-Neighbor TLV (type 145), and Group Member Active Source 2292 TLV (type 146) that needs to be reflected in the IS-IS TLV code-point 2293 registry. 2295 This document creates a number of new sub-TLVs in the numbering space 2296 for the Group Address TLV, the MT Port Capability TLV, the Extended 2297 Reachability TLV, the MT-Capability TLV, and the Capability TLV. The 2298 TLV and sub-TLVs are given below along with technologies that use 2299 them. 2301 IIH LSP SNP MCAST MCAST TRILL/ 2302 LSP SNP IEEE 2303 MAC-RI TLV (141) - X - - - T/I 2305 GADDR-TLV (142) - - - X - -/I 2306 GADDR-TLV.GMAC-ADDR sub-TLV 1 - - - X - T/I 2307 GADDR-TLV.GMAC-IP sub-TLV 2 - - - X - T/I 2308 GADDR-TLV.GMAC-IPV6 sub-TLV 3 - - - X - T/I 2309 GADDR-TLV.SPBV-MAC-ADDR sub-TLV 4 - - - X - -/I 2311 MT-Port-Cap-TLV (143) X - - - - T/- 2312 PortCap.VLAN and Flags sub-TLV 1 X - - - - T/- 2313 PortCap.Enabled-VLANs sub-TLV 2 X - - - - T/- 2314 PortCap.AppointedFwrdrs sub-TLV 3 X - - - - T/- 2315 PortCap.HBHOPT sub-TLV 4 X - - - - T/- 2316 PortCap.BaseVLANID sub-TLV 5 X - - - - -/I 2317 PortCap.SPBDigest sub-TLV 6 X - - - - -/I 2318 PortCap.SiteIdentifier sub-TLV 250 X - - - - -/- 2319 PortCap.SiteGroupIP sub-TLV 251 X - - - - -/- 2320 PortCap.SiteGroupIPv6 sub-TLV 252 X - - - - -/- 2321 PortCap.AdjServerIP sub-TLV 253 X - - - - -/- 2322 PortCap.AdjServerIPv6 sub-TLV 254 X - - - - -/- 2324 CAPABILITY.Trill-Version sub-TLV 5 - X - - - T/- 2325 CAPABILITY.Nickname sub-TLV 6 - X - - - T/- 2326 CAPABILITY.Tree sub-TLV 7 - X - - - T/- 2327 CAPABILITY.Tree Id sub-TLV 8 - X - - - T/- 2328 CAPABILITY.TreeUseRootId sub-TLV 9 - X - - - T/- 2329 CAPABILITY.Int-VLANs sub-TLV 10 - X - X - T/- 2330 CAPABILITY.VLAN-Groups sub-TLV 11 - X - - - T/- 2331 CAPABILITY.ITEOPT sub-TLV 12 - X - - - T/- 2332 CAPABILITY.VMAP sub-TLV 13 - X - - - T/- 2334 MT-Capability-TLV (144) - X - - - -/I 2335 MT-Cap.SPB Instance sub-TLV 1 - X - - - -/I 2336 MT-Cap.Service Id. sub-TLV 2 - X - - - -/I 2338 TRILL-Nieghbor TLV (145) X - - - - T/- 2340 EXT-IS.SPB Link Metric sub-TLV 5 - X - - - -/I 2341 EXT-IS.MTU sub-TLV 6 - X - - - T/- 2342 MT-EXT-IS.SPB LinkMetric sub-TLV 5 - X - - - -/I 2344 Group Mem Active Source TLV (146) - - - X - -/- 2345 GMAS-TLV.GMAS-MAC sub-TLV 1 - - - X - -/- 2346 GMAS-TLV.GMAS-IP sub-TLV 2 - - - X - -/- 2347 GMAS-TLV.GMAS-IPV6 sub-TLV 3 - - - X - -/- 2348 IANA SHOULD manage the remaining space using the IETF Review method 2349 [RFC 5226]. 2351 6. Contributing Authors 2353 David Ward 2354 Juniper Networks 2355 1194 N. Mathilda Ave. 2356 Sunnyvale, California 94089-1206 USA 2357 Phone: +1-408-745-2000 2358 Email: dward@juniper.net 2360 Russ White 2361 Cisco Systems 2362 170 W Tasman Drive 2363 San Jose, CA 95138 2364 US 2366 Email: riw@cisco.com 2368 Dino Farinacci 2369 Cisco Systems 2370 170 W Tasman Drive 2371 San Jose, CA 95138 2372 US 2374 Email: dino@cisco.com 2376 Radia Perlman 2377 Intel Labs 2378 2200 Mission College Blvd. 2379 Santa Clara, CA 95054-1549 2380 US 2382 Phone: +1-408-765-8080 2383 Email: Radia@alum.mit.edu 2385 Donald E. Eastlake 3rd 2386 Stellar Switches 2387 155 Beaver Street 2388 Milford, MA 07157 2389 US 2391 Phone: +1-508-333-2270 2392 Email: d3e3e3@gmail.com 2394 Peter Ashwood-Smith 2395 Huawei Technologies Canada Co. Ltd. 2396 411 Legget Drive, Suite 503 2397 Kanta, Ontario K2K 3C9 2398 CANADA 2400 Email: Peter.AshwoodSmith@huawei.com 2402 Don Fedyk 2403 Alcatel-Lucent 2404 220 Hayden Road 2405 Groton, MA 01450 2406 US 2408 Email: Donald.Fedyk@alcatel-lucent.com 2410 7. References 2412 7.1. Normative References 2414 [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System 2415 Intra-Domain Routing Exchange Protocol for use in 2416 Conjunction with the Protocol for Providing the 2417 Connectionless-mode Network Service (ISO 8473)", 2005. 2419 [RFC 1195] 2420 Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 2421 Dual Environments", 1990. 2423 [RFC 4971] 2424 Vasseur, JP. and N. Shen, "Intermediate System to 2425 Intermediate System (IS-IS) Extensions for Advertising 2426 Router Information", 2007. 2428 [RFC 5305] 2429 Li, T. and H. Smit, "IS-IS Extensions for Traffic 2430 Engineering", 2008. 2432 [RFC 5306] 2433 Shand, M. and L. Ginsberg, "Restart Signaling for 2434 Intermediate System to Intermediate System (IS-IS)", 2004. 2436 7.2. Informative References 2438 [IEEE 802.1aq] 2439 "Standard for Local and Metropolitan Area Networks / 2440 Virtual Bridged Local Area Networks / Amendment 9: 2441 Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008. 2443 [RBRIDGES] 2444 Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 2445 Ghanwani, "RBridges: Base Protocol Specification", 2010. 2447 [RFC 1584] 2448 Moy, J., "Multicast Extensions to OSPF", March 1994. 2450 Author's Address 2452 Ayan Banerjee (editor) 2453 Cisco Systems 2454 170 W Tasman Drive 2455 San Jose, CA 95138 2456 US 2458 Email: ayabaner@cisco.com