idnits 2.17.1 draft-ietf-isis-layer2-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 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 2441 has weird spacing: '...d Flags sub-T...' == Line 2442 has weird spacing: '...d-VLANs sub-...' == Line 2447 has weird spacing: '...ntifier sub-T...' == Line 2458 has weird spacing: '...-Groups sub-...' == Line 2464 has weird spacing: '...gorithm sub-T...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found '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 5. 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 (April 30, 2010) is 5107 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 135, but not defined == Missing Reference: 'TBD' is mentioned on line 2226, but not defined == Missing Reference: 'RFC5305' is mentioned on line 1928, but not defined == Missing Reference: 'RFC 5226' is mentioned on line 2481, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'RFC 1195' is defined on line 2492, but no explicit reference was found in the text == Unused Reference: 'RFC 5305' is defined on line 2501, 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) == Outdated reference: A later version (-04) exists of draft-hasmit-otv-00 Summary: 4 errors (**), 0 flaws (~~), 15 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 D. Ward 5 Expires: November 1, 2010 Juniper Networks 6 R. White 7 D. Farinacci 8 Cisco Systems 9 R. Perlman 10 Intel Labs 11 D. Eastlake 12 Stellar Switches 13 P. Ashwood-Smith 14 Huawei 15 D. Fedyk 16 Alcatel-Lucent 17 April 30, 2010 19 Extensions to IS-IS for Layer-2 Systems 20 draft-ietf-isis-layer2-05 22 Abstract 24 This document specifies the IS-IS extensions necessary to support 25 multi-link IPv4 and IPv6 networks, as well as to provide true link 26 state routing to any protocols running directly over layer 2. While 27 supporting this concept involves several pieces, this document only 28 describes extensions to IS-IS. We leave it to the systems using 29 these IS-IS extensions to explain how the information carried in 30 IS-IS is used. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 1, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. PDU, TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . 5 69 2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 5 70 2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6 71 2.2.1. The Group MAC Address sub-TLV . . . . . . . . . . . . 6 72 2.2.2. The Group IP Address sub-TLV . . . . . . . . . . . . . 8 73 2.2.3. The Group IPv6 Address sub-TLV . . . . . . . . . . . . 10 74 2.3. Multi Topology aware Port Capability TLV . . . . . . . . . 12 75 2.3.1. The Special VLANs and Flags sub-TLV . . . . . . . . . 13 76 2.3.2. Enabled VLANs sub-TLV . . . . . . . . . . . . . . . . 14 77 2.3.3. Appointed Forwarders sub-TLV . . . . . . . . . . . . . 15 78 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV . . . . . . . . . 16 79 2.3.5. Base VLAN-Identifiers sub-TLV . . . . . . . . . . . . 17 80 2.3.6. SPB Digest sub-TLV . . . . . . . . . . . . . . . . . . 18 81 2.3.7. Site Identifier sub-TLV . . . . . . . . . . . . . . . 20 82 2.3.8. Site Group IPv4 sub-TLV . . . . . . . . . . . . . . . 20 83 2.3.9. Site Group IPv6 sub-TLV . . . . . . . . . . . . . . . 21 84 2.3.10. Adjacency Server IPv4 sub-TLV . . . . . . . . . . . . 22 85 2.3.11. Adjacency Server IPv6 sub-TLV . . . . . . . . . . . . 22 86 2.4. Sub-TLVs for the Router Capability TLV . . . . . . . . . . 23 87 2.4.1. The TRILL Version sub-TLV . . . . . . . . . . . . . . 23 88 2.4.2. The Nickname sub-TLV . . . . . . . . . . . . . . . . . 24 89 2.4.3. The Trees sub-TLV . . . . . . . . . . . . . . . . . . 25 90 2.4.4. The Tree Identifiers Sub-TLV . . . . . . . . . . . . . 26 91 2.4.5. The Trees Used Identifiers Sub-TLV . . . . . . . . . . 27 92 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV . . . 27 93 2.4.7. The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 29 94 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-TLV . . . . 30 95 2.4.9. VLAN Mapping (VMAP) sub-TLV . . . . . . . . . . . . . 31 97 2.5. Multi Topology Aware Capability TLV . . . . . . . . . . . 32 98 2.5.1. SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 33 99 2.5.2. SPB Opaque ECT Algorithm sub-TLV . . . . . . . . . . . 36 100 2.5.3. SPBM Service Identifier and Unicast Address sub-TLV . 37 101 2.5.4. The SPBV MAC Address sub-TLV . . . . . . . . . . . . . 38 102 2.6. Sub-TLVs of the Extended Reachability TLV . . . . . . . . 39 103 2.6.1. SPB Link Metric sub-TLV . . . . . . . . . . . . . . . 39 104 2.6.2. SPB Opaque ECT Algorithm sub-TLV . . . . . . . . . . . 40 105 2.6.3. MTU sub-TLV . . . . . . . . . . . . . . . . . . . . . 40 106 2.7. TRILL Neighbor TLV . . . . . . . . . . . . . . . . . . . . 41 107 2.8. The Group Membership Active Source TLV . . . . . . . . . . 42 108 2.8.1. The Group MAC Active Source sub-TLV . . . . . . . . . 43 109 2.8.2. The Group IP Active Source sub-TLV . . . . . . . . . . 45 110 2.8.3. The Group IPv6 Active Source sub-TLV . . . . . . . . . 47 111 2.9. PDU Extensions to IS-IS . . . . . . . . . . . . . . . . . 49 112 2.9.1. The Multicast Group PDU . . . . . . . . . . . . . . . 49 113 2.9.2. The Multicast Group Partial Sequence Number PDU . . . 50 114 2.9.3. The Multicast Group Complete Sequence Number PDU . . . 50 115 2.9.4. MGROUP PDU related changes to Base protocol . . . . . 50 116 2.9.4.1. Enhancements to the flooding process . . . . . . . 50 117 2.9.4.2. Enhancements to Graceful Restart . . . . . . . . . 51 118 2.9.4.3. Enhancements to the maximum sequence number 119 reached . . . . . . . . . . . . . . . . . . . . . 51 120 2.9.4.4. Enhancements to the SPF . . . . . . . . . . . . . 51 121 2.9.5. The TRILL-Hello PDU . . . . . . . . . . . . . . . . . 51 122 2.9.6. The MTU PDU . . . . . . . . . . . . . . . . . . . . . 52 123 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 124 4. Security Considerations . . . . . . . . . . . . . . . . . . . 55 125 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 126 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 127 6.1. Normative References . . . . . . . . . . . . . . . . . . . 58 128 6.2. Informative References . . . . . . . . . . . . . . . . . . 58 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 131 1. Overview 133 There are a number of systems (for example, [RBRIDGES], [802.1aq], 134 [OTV]) that use layer 2 addresses carried in a link state routing 135 protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer 136 2 routing. This document specifies a set of TLVs and sub-TLVs to be 137 added to [IS-IS] level 1 PDUs, and six new PDU types, to support 138 these proposed systems. Some of these TLVs are generic layer 2 139 additions and some are specific to [RBRIDGES] or [802.1aq] or [OTV]. 140 This draft does not propose any new forwarding mechanisms using this 141 additional information carried within IS-IS. 143 This document specifies additional TLVs and sub-TLVs, to carry 144 unicast and multicast attached address information. It also 145 specifies additional TLVs and sub-TLVs to carry information as 146 required by the IETF TRILL, IEEE 802.1aq and OTV protocols. 148 This document specifies six new IS-IS PDUs. The Multicast Group 149 (MGROUP) PDU, for carrying a list of attached or joined multicast 150 groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) 151 PDU and the Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU 152 packets are also defined to be used with the new MGROUP-PDU to 153 perform database exchange on the MGROUP PDUs. The TRILL-Hello PDU 154 provides the subnet specific layer of IS-IS for TRILL links. The 155 MTU-probe and MTU-ack PDUs provide a means of testing link MTU. 157 1.1. Terminology 159 The term "Hello" or "Hello PDU" in this document, when not further 160 qualified, includes the TRILL IIH PDU, the LAN IIH PDU and the P2P 161 IIH PDU. 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119. 167 2. PDU, TLV and sub-TLV Enhancements to IS-IS 169 In this section we specify the enhancements for the PDUs, TLVs and 170 sub-TLVs as needed by Layer-2 technologies. 172 2.1. The MAC-Reachability TLV 174 The MAC-Reachability (MAC-RI) TLV is IS-IS TLV type 141 and has the 175 following format: 177 +-+-+-+-+-+-+-+-+ 178 | Type= MAC-RI | (1 byte) 179 +-+-+-+-+-+-+-+-+ 180 | Length | (1 byte) 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Topology-Id/ Nickname | (2 bytes) 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Confidence | (1 byte) 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | RESV | VLAN-ID | (2 bytes) 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | MAC (1) (6 bytes) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | ................. | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | MAC (N) (6 bytes) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 o Type: TLV Type, set to 141 (MAC-RI). 197 o Length: Total number of bytes contained in the value field given 198 by 5 + 6*n bytes. 200 o Topology-Id/Nickname : Depending on the technology in which it is 201 used, this carries the topology-id or nickname. When this field 202 is set to zero this implies that the MAC addresses are reachable 203 across all topologies or across all nicknames of the originating 204 IS. 206 o Confidence: This carries an 8-bit quantity indicating the 207 confidence level in the MAC addresses being transported. Whether 208 this field is used, and its semantics if used, are further defined 209 by the specific protocol using Layer-2-IS-IS. If not used, it 210 MUST be set to zero on transmission and be ignored on receipt. 212 o RESV: Must be sent as zero on transmission and is ignored on 213 receipt. 215 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 216 all subsequent MAC addresses in this TLV, or the value zero if no 217 VLAN is specified. 219 o MAC(i): This is the 48-bit MAC address reachable from the IS that 220 is announcing this TLV. 222 The MAC-RI TLV is carried in a standard Level 1 link state PDU. It 223 MUST contain only unicast addresses. 225 2.2. The Group Address TLV 227 The Group Address (GADDR) TLV is IS-IS TLV type 142 [TBD] and has the 228 following format: 230 +-+-+-+-+-+-+-+-+ 231 | Type=GADDRTLV | (1 byte) 232 +-+-+-+-+-+-+-+-+ 233 | Length | (1 byte) 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | sub-TLVs (variable bytes) | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 o Type: TLV Type, set to GADDR-TLV 142 [TBD]. 240 o Length: Total number of bytes contained in the value field, which 241 includes the length of the sub-TLVs carried in this TLV. 243 o sub-TLVs: The Group Address TLV value contains sub-TLVs formatted 244 as described in [RFC5305]. The sub-TLVs for this TLV are 245 specified in the following subsections. 247 The GADDR TLV is carried only within a Multicast Group Level 1 link 248 state PDU. 250 2.2.1. The Group MAC Address sub-TLV 252 The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS sub-TLV type 1 253 within the GADDR TLV and has the following format: 255 +-+-+-+-+-+-+-+-+ 256 | Type=GMAC-ADDR| (1 byte) 257 +-+-+-+-+-+-+-+-+ 258 | Length | (1 byte) 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Topology-Id/ Nickname | (2 bytes) 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Confidence | (1 byte) 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | RESV | VLAN-ID | (2 bytes) 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |Num Group Recs | (1 byte) 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | GROUP RECORDS (1) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | ................. | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | GROUP RECORDS (N) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 where each group record is of the form: 277 +-+-+-+-+-+-+-+-+ 278 | RESERVED | (1 byte) 279 +-+-+-+-+-+-+-+-+ 280 | Num of Sources| (1 byte) 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Group Address (6 bytes) | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Source 1 Address (6 bytes) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Source 2 Address (6 bytes) | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Source M Address (6 bytes) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 o Type: sub-TLV Type, set to 1 (GMAC-ADDR) of length 1 byte. 293 o Length: Total number of bytes contained in the value field. 295 o Topology-Id/Nickname : Depending on the technology in which it is 296 used, this carries the topology-id or nickname. When this field 297 is set to zero this implies that the MAC addresses are reachable 298 across all topologies or across all nicknames of the originating 299 IS. 301 o Confidence: This carries an 8-bit quantity indicating the 302 confidence level in the MAC addresses being transported. Whether 303 this field is used, and its semantics if used, are further defined 304 by the specific protocol using Layer-2-IS-IS. If not used, it 305 MUST be set to zero on transmission and be ignored on receipt. 307 o RESERVED: Must be sent as zero on transmission and is ignored on 308 receipt. 310 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 311 all subsequent MAC addresses in this sub-TLV, or the value zero if 312 no VLAN is specified. 314 o Number of Group Records: This is of length 1 byte and lists the 315 number of group records in this sub-TLV. 317 o Group Record: Each group record has a one byte reserved space and 318 the next byte carries the number of sources. It then has a 48-bit 319 multicast Group Address followed by 48-bit source MAC addresses. 320 An address being a group multicast address or unicast source 321 address can be checked using the multicast bit in the address. If 322 the number of sources do not fit in a single sub-TLV, it is 323 permitted to have the same group address repeated with different 324 source addresses in another sub-TLV of another instance of the 325 Group Address TLV. 327 The GMAC-ADDR sub-TLV is carried only within a GADDR TLV and MUST be 328 carried in a standard Level 1 link state MGROUP PDU. 330 2.2.2. The Group IP Address sub-TLV 332 The Group IP Address (GIP-ADDR) sub-TLV IS-IS sub-TLV type 2 within 333 the GADDR TLV and has the following format: 335 +-+-+-+-+-+-+-+-+ 336 | Type=GIP-ADDR | 337 +-+-+-+-+-+-+-+-+ 338 | Length | (1 byte) 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Topology-Id/ Nickname | (2 bytes) 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Confidence | (1 byte) 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | RESV | VLAN-ID | (2 bytes) 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 |Num Group Recs | (1 byte) 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | GROUP RECORDS (1) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | ................. | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | GROUP RECORDS (N) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 where each group record is of the form: 357 +-+-+-+-+-+-+-+-+ 358 | RESERVED | (1 byte) 359 +-+-+-+-+-+-+-+-+ 360 | Num of Sources| (1 byte) 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Group Address (4 bytes) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Source 1 Address (4 bytes) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Source 2 Address (4 bytes) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Source M Address (4 bytes) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 o Type: sub-TLV Type, set to 2 (GIP-ADDR). 373 o Length: Total number of bytes contained in the value field of the 374 sub-TLV. 376 o Topology-Id/Nickname : Depending on the technology in which it is 377 used, this carries the topology-id or nickname. When this field 378 is set to zero this implies that the addresses are reachable 379 across all topologies or across all nicknames of the originating 380 IS. 382 o Confidence: This carries an 8-bit quantity indicating the 383 confidence level in the IP addresses being transported. Whether 384 this field is used, and its semantics if used, are further defined 385 by the specific protocol using Layer-2-IS-IS. If not used, it 386 must be set to zero on transmission and be ignored on receipt. 388 o RESERVED: Must be sent as zero on transmission and is ignored on 389 receipt. 391 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 392 all subsequent addresses in this sub-TLV, or the value zero if no 393 VLAN is specified. 395 o Number of Group Records: This is of length 1 byte and lists the 396 number of group records in this sub-TLV. 398 o Group Record: Each group record has a one byte reserved space and 399 the next byte carries the number of sources. It is followed by a 400 32-bit IPv4 Group Address followed by 32-bit source IPv4 401 addresses. If the number of sources do not fit in a single sub- 402 TLV, it is permitted to have the same group address repeated with 403 different source addresses repeated in another sub-TLV of another 404 instance of the Group Address TLV. 406 The GIP-ADDR sub-TLV is carried only within a GADDR TLV and MUST be 407 carried in a standard Level 1 link state MGROUP PDU. 409 2.2.3. The Group IPv6 Address sub-TLV 411 The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3 412 and has the following format: 414 +-+-+-+-+-+-+-+-+ 415 |Type=GIPv6-ADDR| 416 +-+-+-+-+-+-+-+-+ 417 | Length | (1 byte) 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Topology-Id/ Nickname | (2 bytes) 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Confidence | (1 byte) 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | RESV | VLAN-ID | (2 bytes) 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 |Num Group Recs | (1 byte) 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | GROUP RECORDS (1) | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | ................. | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | GROUP RECORDS (N) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 where each group record is of the form: 436 +-+-+-+-+-+-+-+-+ 437 | RESERVED | (1 byte) 438 +-+-+-+-+-+-+-+-+ 439 | Num of Sources| (1 byte) 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Group Address (16 bytes) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Source 1 Address (16 bytes) | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Source 2 Address (16 bytes) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Source M Address (16 bytes) | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 o Type: sub-TLV Type, set to 3 (GIPV6-ADDR). 452 o Length: Total number of bytes contained in the value field. 454 o Confidence: This carries an 8-bit quantity indicating the 455 confidence level in the IPv6 addresses being transported. Whether 456 this field is used, and its semantics if used, are further defined 457 by the specific protocol using Layer-2-IS-IS. If not used, it 458 must be set to zero on transmission and be ignored on receipt. 460 o Topology-Id/Nickname : Depending on the technology in which it is 461 used, this carries the topology-id or nickname. When this field 462 is set to zero this implies that the addresses are reachable 463 across all topologies or across all nicknames of the originating 464 IS. 466 o RESERVED: Must be sent as zero on transmission and is ignored on 467 receipt. 469 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 470 all subsequent addresses in this sub-TLV, or the value zero if no 471 VLAN is specified. 473 o Number of Group Records: This of length 1 byte and lists the 474 number of group records in this sub-TLV. 476 o Group Record: Each group record has a one byte reserved space and 477 the next byte carries the number of sources. It is followed by a 478 128-bit multicast IPv6 Group Address followed by 128-bit source 479 IPv6 addresses. If the number of sources do not fit in a single 480 sub-TLV, it is permitted to have the same group address repeated 481 with different source addresses repeated in another sub-TLV in 482 another instance of the Group Address TLV. 484 The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV and MUST be 485 carried in a standard Level 1 link state MGROUP PDU. 487 2.3. Multi Topology aware Port Capability TLV 489 The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS 490 TLV type 143 [TBD], and has the following format: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 |Type=MT PORTCAP| Length |O|R|R|R| Topology Identifier | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | sub-TLVs | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 o Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD]. 501 o Length: Total number of bytes contained in the value field, 502 including the length of the sub-TLVs carried in this TLV. 504 o O bit: The overload bit that follows the semantics associated with 505 an overloaded intermediate system. 507 o Topology Identifier: MT ID is a 12-bit field containing the MT ID 508 of the topology being announced. This field when set to zero 509 implies that it is being used to carry base topology information. 511 In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, 512 it may be non-zero. 514 o sub-TLVs: The MT aware Port Capabilities TLV value contains sub- 515 TLVs formatted as described in [RFC5305]. They are defined in the 516 next sections. 518 The MT-PORT-CAP TLV may occur multiple times, and is carried only 519 within a Hello PDU. 521 2.3.1. The Special VLANs and Flags sub-TLV 523 The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST only appear 524 in a MT-PORT-CAP TLV. It is carried exactly once in every TRILL IIH 525 PDU. It has the following format: 527 +-+-+-+-+-+-+-+-+ 528 |Type=VLAN Flags| (1 byte) 529 +-+-+-+-+-+-+-+-+ 530 | Length | (1 byte) 531 +--------------------------------+ 532 | Port ID | (2 bytes) 533 +--------------------------------+ 534 | Sender Nickname | (2 bytes) 535 +--+--+--+--+--------------------+ 536 |AF|AC|VM|BY| Outer.VLAN | (2 bytes) 537 +-----------+--------------------+ 538 |Reserved | Desig.VLAN | (2 bytes) 539 +-----------+--------------------+ 541 o Type: sub-TLV Type, set to VLAN and Flags sub-TLV 1 [TBD]. 543 o Length: 8 - Number of bytes contained in the value field. 545 o Port ID: An ID for the port on which the enclosing TRILL IIH PDU 546 is being sent. The transmitting RBridge assigns this ID such that 547 each of its ports has an ID different from all of its other ports. 549 o Sender nickname: If the sending intermediate system is holding any 550 nicknames, one MUST be included here. Otherwise, the field is set 551 to zero. This field is to support intelligent end stations that 552 determine the egress RBridge for unicast data through a directory 553 service or the like and need a nickname for their first hop to 554 insert as the ingress nickname to correctly format a TRILL 555 encapsulated data frame. 557 o The fifth and sixth bytes have a copy of the Outer VLAN ID 558 associated with the Hello frame when it was sent. The lower 4 559 bits of the fifth byte give the upper ID bits of the VLAN ID and 560 the sixth byte gives the lower VLAN ID bits. 562 o The upper 4 bits of the fifth byte are flag bits as shown. The AF 563 bit, if one, indicates that the sending Intermediate System 564 believes it is Appointed Forwarder for the VLAN and port on which 565 the Hello was sent. The AC bit, if one, indicates that the 566 sending port is configured as an access port. The VM bit, if a 567 one, indicates that the sending Intermediate System has detected 568 VLAN mapping within the link. The BY bit, if set, indicates 569 bypass psuedonode. 571 o The seventh and eighth bytes give the Designated VLAN for the 572 link. The lower 4 bits of the seventh byte give the upper ID bits 573 of the Designated VLAN and the eighth byte gives the lower VLAN ID 574 bits. The upper 4 bits of the seventh byte are reserved and MUST 575 be sent as zero and ignored on receipt. 577 The VLAN and Flags sub-TLV is carried within the MT-PORT-CAP TLV. It 578 MUST be carried exactly once in a TRILL IIH PDU. It MUST NOT be 579 carried within a LAN or a P2P IIH PDU. 581 2.3.2. Enabled VLANs sub-TLV 583 The Enabled VLAN sub-TLV specifies the VLANs enabled for end station 584 service at the port on which the Hello was sent. It has the 585 following format: 587 +-+-+-+-+-+-+-+-+ 588 |Type=EnabledVLAN| 589 +-+-+-+-+-+-+-+-+ 590 | Length | (1 byte) 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 |Resv | Start Vlan Id | (2 bytes) 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Vlan bit-map.... 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 o Type: sub-TLV Type, set to Enabled VLANs sub-TLV 2 [TBD]. 599 o Length: variable, depending on contents described next. 601 o The minimum size of the value is 3 bytes. The third and 602 subsequent bytes provide a bit map of enabled VLANs starting at 603 the VLAN ID indicated in the first two bytes. The lower order 604 four bits of the first byte give the upper bits of the starting 605 VLAN ID and the second byte gives the lower bits of that VLAN ID. 606 The upper four bits of the first byte are reserved and MUST be 607 sent as zero and ignored on receipt. The highest order bit of the 608 third byte indicates the VLAN equal to the starting ID while the 609 lowest order bit of the third byte indicates that ID plus 7. For 610 example, VLANs 1 and 14 being enabled for end station service 611 could be encoded in 4-bytes value 0x00 0x01 0x80 0x04 or, 612 alternatively, as 0x00 0x00 0x40 0x02. 614 This sub-TLV may occur more than once in a Hello and a VLAN is 615 enabled for end station service on the port where the Hello was sent 616 if this is indicated by any occurrence in the Hello. For example, a 617 receiver could allocate a 512-byte buffer and, with appropriate 618 shifting operations, OR in the enabled bits for each sub-TLV of this 619 type it finds in a Hello to derive the complete bit map of these 620 VLANs. 622 The Enabled VLAN sub-TLV is carried only within the MT-PORT-CAP TLV. 623 If present, it MUST be carried in TRILL IIH PDU. It MUST NOT be 624 carried within a LAN IIH or a P2P IIH PDU. 626 2.3.3. Appointed Forwarders sub-TLV 628 The Appointed Forwarder sub-TLV provides the mechanism by which the 629 Designated Intermediate System can inform other Intermediate Systems 630 on the link that they are the designated VLAN-x forwarder for that 631 link for one or more ranges of VLAN IDs. It has the following 632 format: 634 +-+-+-+-+-+-+-+-+ 635 |Type=App Frwrdr| 636 +-+-+-+-+-+-+-+-+ 637 | Length | (1 byte) 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Appointment Information (1) | (6 bytes) 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | ................. | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Appointment Information (N) | (6 bytes) 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 where each appointment information is of the form: 648 +---------------------------+ 649 | Appointee Nick | (2 bytes) 650 +---------------------------+ 651 | Res | Start VLAN ID | (2 bytes) 652 +---------------------------+ 653 | Res | End VLAN ID | (2 bytes) 654 +---------------------------+ 655 o Type: sub-TLV Type, set to Appointed Forwarders sub-TLV 3 [TBD]. 657 o Length: The size of the value is 6*n bytes where there are n 658 appointments. 660 o The appointed forwarder Intermediate System is specified by its 661 nickname in the first two bytes. 663 o The "Res" fields of 4 bits each are reserved and MUST be sent as 664 zero and ignored on receipt. 666 The VLAN range given is inclusive. To specify a single VLAN, that 667 VLAN ID appears as both the start and end VLAN. The Intermediate 668 System whose nickname is given is appointed forwarder for those VLANs 669 for which it has end station service enabled (see item 2 above) in 670 the inclusive range. For example, assume an Intermediate System with 671 end station service enabled on VLANs 100, 101, 199, and 200 (and 672 possibly other VLANs less than 100 or greater than 200), but not 673 enabled for VLANs 102 through 198. It could be appointed forwarder 674 for these four VLANs through either (1) a single 6-byte value 675 sequence with start and end VLAN IDs of 100 and 200, or (2) a 12-byte 676 value sequence with start and end VLAN IDs of 100 and 101 in the 677 first part and 199 and 200 in the second part. 679 An Intermediate System's nickname may occur as appointed forwarder 680 for multiple VLAN ranges within the same or different Port Capability 681 TLVs within a TRILL Hello. In the absence of appointed forwarder 682 sub-TLVs referring to a VLAN, the Designated Intermediate System acts 683 as the appointed forwarder for that VLAN if end station service is 684 enabled. 686 The Appointed Forwarder sub-TLV is carried within the MT-PORT-CAP 687 TLV. If present, it MUST be carried in a TRILL IIH PDU. This MUST 688 NOT be carried in a LAN IIH PDU or a P2P IIH PDU. 690 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV 692 By including this sub-TLV within one or more MT aware Port Capability 693 TLVs in its Hellos, an Intermediate System can advertise the Hop-by- 694 Hop options it supports on the port through which it sends the Hello. 695 This sub-TLV may appear zero or more times within a MT aware Port 696 Capability TLV. By default, in the absence of any HBHOPT sub-TLVs, 697 no Hop-by-Hop options are supported. 699 There are two types of Hop-by-Hop option encodings within the TRILL 700 Header: bit options and TLV encoded options. 702 The bit-encoded options supported are indicated by an HBHOPT sub-TLV 703 of length 3: an initial value byte of 0x00 followed by two bytes in 704 which each bit indicates that the corresponding bit option is 705 implemented; in those two bytes the top two bits (0xC000) are 706 critical option summary bits that all RBridges MUST understand; 707 therefore support for these bits need not be advertised. Those two 708 bits are reserved in the HBHOPT sub-TLV and must be sent as zero and 709 are ignored on receipt. 711 The implementation of the type of option encoded in a TRILL Header as 712 a TLV is indicated by an HBHOPT sub-TLV whose value starts with a 713 byte equal to the first byte of the option. Such HBHOPT sub-TLVs may 714 have additional value bytes further indicating how the option is 715 supported as specified with the option's definition, for example a 716 list of supported security algorithms. 718 +-+-+-+-+-+-+-+-+ 719 | Type = HBHOPT | 720 +-+-+-+-+-+-+-+-+ 721 | Length | (1 byte) 722 +-+-+-+-+-+-+-+-+ 723 | Option | (1 byte) 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Option dependent variable length information | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 o Type: sub-TLV Type, set to Hop-by-Hop sub-TLV 4 [TBD]. 730 o Length: variable, minimum 1. 732 o Value: Either 0x00 followed by implementation information for bit 733 encoded options or a non-zero option type byte followed by option 734 dependent information for that option. 736 2.3.5. Base VLAN-Identifiers sub-TLV 738 This sub-TLV is added to an IIH PDU to indicate the algorithms for 739 the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) that 740 are in use. This information should be the same on all bridges in 741 the topology identified by MT-PORT-CAP TLV it is being carried. 742 Discrepancies between neighbors with respect to this sub-TLV are 743 temporarily allowed but at least the active the Base-VID must agree 744 and use the same ECT-ALGORITHM. 746 +-+-+-+-+-+-+-+-+ 747 |Type = B-VID | 748 +-+-+-+-+-+-+-+-+ 749 | Length | (1 byte) 750 +-+-+-+-+-+-+-+-+-------------------------------- 751 | ECT - VID Tuple (1) (6 bytes) | 752 +-----------------------------------------------+ 753 | ......................... | 754 +-----------------------------------------------+ 755 | ECT - VID Tuples (N) (6 bytes) | 756 +-----------------------------------------------+ 758 o Type: sub-TLV Type, set to Base-VLAN-ID sub-TLV 5 [TBD]. 760 o Length: The size of the value is ECT-VID Tuples*6 bytes. Each 761 6-byte part of the ECT-VID tuple is formatted as follows: 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | ECT - Algorithm (32 bits) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Base VID (12 bits) |U|M|RES| 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 o ECT-ALGORITHM (4 bytes) The ECT-ALGORITHM is advertised when the 770 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 771 Base VID 773 o Base VID (12-bits) The Base-VID that is associated with the SPT 774 Set. 776 o Use-Flag (1-bit) The Use-flag is set if this bridge, or any bridge 777 that this bridge sees is currently using this ECT-ALGORITHM and 778 Base VID. 780 o M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode. 782 The Base VLAN-Identifier sub-TLV is carried within the MT-PORT-CAP 783 TLV and this is carried in a IIH PDU. 785 2.3.6. SPB Digest sub-TLV 787 This sub-TLV is added to an IIH PDU to indicate the digest for 788 Multiple spanning tree configuration Digests (MCID) and the IS-IS 789 agreement Digest. This information should be the same on all bridges 790 in the topology identified by MT-PORT-CAP TLV it is being carried. 791 These digests indicate when the configuration and the topology are 792 synchronized and are used to control the updating of forwarding 793 information. The MCID is controlled solely by configuration and is a 794 digest of the allocated VIDs to various protocols. Two MCIDs are 795 carried to allow transitions when the configuration changes are non- 796 critical. During the propagation of LSPs the agreement digest will 797 vary between neighbors until the LSPs are common. The digest is a 798 summarized means of determining agreement between nodes on the 799 distance to all multicast roots, hence is essential for loop 800 prevention. During the propagation of LSPs the agreement digest will 801 vary between neighbors until the required portions of LSPs are 802 common. For each shortest path tree where it has been determined the 803 distance to the root has changed, multicast forwarding is blocked 804 until the exchanged digests match. Discrepancies between neighbors 805 with respect to this sub-TLV are temporarily allowed but the Base-VID 806 must agree and use a spanning tree algorithm. 808 +-+-+-+-+-+-+-+-+ 809 |Type =SPBDigest| 810 +-+-+-+-+-+-+-+-+ 811 | Length | (1 byte) 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | MCID (50 Bytes) | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Aux MCID (50 Bytes) | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Agreement Digest (32 Bytes) | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 |RES | A | D| 820 +-+-+-+-+-+-+-+-+ 822 o Type: sub-TLV Type, set to SPB Digest sub-TLV 6 [TBD]. 824 o Length: The size of the value defined below. 826 o MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which 827 identifies an SPT Region. 829 o Aux MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which 830 identifies an SPT Region. The aux MCID allows SP Regions to be 831 migrated allocating new VLAN to FID Mappings. 833 o Agreement Digest (32-bytes) This digest is use to determine when 834 IS-IS is synchronized between neighbors. 836 o A (2 bits) The agreement number 0-3 which aligns with BPDUs 837 agreement number concept. When the Agreement Digest for this node 838 changes this number is updated and sent in the hello. 840 o D (2 bits) The discarded agreement number 0-3 which aligns with 841 BPDUs agreement number concept. When the Agreement Digest for 842 this node changes this number is updated. Once an Agreement has 843 been sent it is considered outstanding until a matching or more 844 recent Discarded Agreement Number is received. 846 The SPB Digest sub-TLV is carried within the MT-PORT-CAP TLV and this 847 is carried in a IIH PDU. 849 2.3.7. Site Identifier sub-TLV 851 The site identifier sub-TLV carries information about the site this 852 device belongs to. This is used in OTV [OTV] to aid in Authoritative 853 Edge Device election. It has the following format: 855 +-+-+-+-+-+-+-+-+ 856 |Type = SiteCap | 857 +-+-+-+-+-+-+-+-+ 858 | Length | (1 byte) 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | System ID (6 bytes) | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Cluster ID (2 bytes) | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 |Resv (7bits) |U| (1 byte) 865 +-+-+-+-+-+-+-+-+ 867 o Type: sub-TLV Type, set to Site Identifier sub-TLV 250 [TBD]. 869 o Length: The size of the value. 871 o System Id: The system-id of the site. 873 o Cluster Id: The cluster-id within the site. 875 o Reserved: Must be sent as zero on transmission and is ignored on 876 receipt. 878 o U bit: Denotes if the site is a unicast only site. 880 The Site Capability sub-TLV is carried only within the MT-PORT-CAP 881 TLV and this is carried in a Hello PDU. There must be only one 882 occurrence of this sub-TLV in the Hello PDU. 884 2.3.8. Site Group IPv4 sub-TLV 886 The Site Group IPv4 sub-TLV carries information about the overlays 887 active on this device. This is used in OTV [OTV] to aid in 888 Authoritative Edge Device election. It has the following format: 890 +-+-+-+-+-+-+-+-+ 891 |Type=SiteGrpIP | 892 +-+-+-+-+-+-+-+-+ 893 | Length | (1 byte) 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | IPv4 address (4 bytes) | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | .................. | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | IPv4 address (4 bytes) | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 o Type: sub-TLV Type, set to Site Group IP sub-TLV 251 [TBD]. 904 o Length: The size of the value. 906 o Value: The list of IPv4 addresses used by the site. 908 The Site Group IPv4 sub-TLV is carried within the MT-PORT-CAP TLV and 909 this is carried in a Hello PDU. There may be more than one 910 occurrence of this sub-TLV in the Hello PDU. 912 2.3.9. Site Group IPv6 sub-TLV 914 The Site Group IPv6 sub-TLV carries information about the overlays 915 active on this device. This is used in OTV [OTV] to aid in 916 Authoritative Edge Device election. It has the following format: 918 +-+-+-+-+-+-+-+-+ 919 |Type=SiteGrpIPv6| 920 +-+-+-+-+-+-+-+-+ 921 | Length | (1 byte) 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | IPv6 address (16 bytes) | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | .................. | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | IPv6 address (16 bytes) | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 o Type: sub-TLV Type, set to Site Group IPv6 sub-TLV 252 [TBD]. 932 o Length: The size of the value. 934 o Value: The list of IPv6 addresses used by the site. 936 The Site Group IPv6 sub-TLV is carried within the MT-PORT-CAP TLV and 937 this is carried in a Hello PDU. There may be more than one 938 occurrence of this sub-TLV in the Hello PDU. 940 2.3.10. Adjacency Server IPv4 sub-TLV 942 The Adjacency Server IPv4 sub-TLV carries information about the 943 capability of the sites in OTV [OTV]. It has the following format: 945 +-+-+-+-+-+-+-+-+ 946 |Type = ASIPv4 | 947 +-+-+-+-+-+-+-+-+ 948 | Length | (1 byte) 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Adjacency IPv4 Information (1) | (5 bytes) 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | ................. | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Adjacency IPv4 Information (N) | (5 bytes) 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 where each adjacency IPv4 information is of the form: 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | IPv4 address (4 bytes) | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 |Resv (7bits) |U| (1 byte) 963 +-+-+-+-+-+-+-+-+ 965 o Type: sub-TLV Type, set to Adjacency Server IP sub-TLV 253 [TBD]. 967 o Length: The size of the value, 5*n, where there are n adjacency 968 server information blocks. 970 o IPv4 Address: The IPv4 addresses used by the sites. 972 o Reserved: Must be sent as zero on transmission and is ignored on 973 receipt. 975 o U bit: Denotes if the site is a unicast only site. 977 The Adjacency Server IPv4 sub-TLV is carried within the MT-PORT-CAP 978 TLV and this is carried in a Hello PDU. 980 2.3.11. Adjacency Server IPv6 sub-TLV 982 The Adjacency Server IPv6 sub-TLV carries information about the 983 capability of the sites in OTV [OTV]. It has the following format: 985 +-+-+-+-+-+-+-+-+ 986 |Type = ASIPv6 | 987 +-+-+-+-+-+-+-+-+ 988 | Length | (1 byte) 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Adjacency IPv6 Information (1) | (17 bytes) 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | ................. | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Adjacency IPv6 Information (N) | (17 bytes) 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 where each adjacency IPv6 information is of the form: 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | IPv6 address (16 bytes) | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 |Resv (7bits) |U| (1 byte) 1003 +-+-+-+-+-+-+-+-+ 1005 o Type: sub-TLV Type, set to Adjacency Server IPv6 sub-TLV 254 1006 [TBD]. 1008 o Length: The size of the value. 1010 o Value: The IPv6 addresses used by the sites. 1012 o Reserved: Must be sent as zero on transmission and is ignored on 1013 receipt. 1015 o U bit: Denotes if the site is a unicast only site. 1017 The Adjacency Server IPv6 sub-TLV is carried within the MT-PORT-CAP 1018 TLV and this is carried in a Hello PDU. Multiple such TLVs may be 1019 carried in a IIH PDU. 1021 2.4. Sub-TLVs for the Router Capability TLV 1023 The Router Capability TLV is an optional TLV [RFC 4971] that may be 1024 generated by the originating Intermediate System. We specify these 1025 additional sub-TLVs that can be carried in it. These sub-TLVs 1026 announce the capabilities of the Intermediate System to the entire 1027 IS-IS routing domain. 1029 2.4.1. The TRILL Version sub-TLV 1031 The TRILL Version (TRILL-VER) sub-TLV indicates support of TRILL 1032 Versions. The device announces the maximum version of TRILL, it is 1033 capable of supporting, including lower versions. In the event, this 1034 sub-TLV is missing, this implies that the node can only support the 1035 base version of the protocol. 1036 0 1 2 3 1037 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 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Type | Length | Reserved | Max-version | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 o Type: sub-TLV Type, set to 5 (TRILL-VER). 1044 o Length: 2 - Total number of bytes contained in the value. 1046 o Reserved: Set to zero on transmission and ignored on receipt. 1048 o Max-version: Set to application dependent values. 1050 2.4.2. The Nickname sub-TLV 1052 The Nickname (NICKNAME) sub-TLV carries information about the 1053 nicknames of the advertising device, along with information about its 1054 priority to hold those nicknames. The Nickname sub-TLV MUST be 1055 carried within a Router CAPABILITY TLV in a level-1 LSP generated by 1056 the originating IS. Multiple instances of this sub-TLV are allowed 1057 to be carried. 1059 +-+-+-+-+-+-+-+-+ 1060 |Type = NICKNAME| 1061 +-+-+-+-+-+-+-+-+ 1062 | Length | (1 byte) 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | NICKNAME RECORDS (1) | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | ................. | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | NICKNAME RECORDS (N) | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 where each nickname record is of the form: 1073 +-+-+-+-+-+-+-+-+-+ 1074 |Nickname Priority| (1 byte) 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Tree Root Priority | (2 byte) 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Nickname | (2 bytes) 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 o Type: sub-TLV Type, set to 6 (NICKNAME). 1082 o Length: 5*N, where N is the number of nickname records present. 1084 o Nickname Priority: This is an unsigned 8-bit integer that gives 1085 the priority with which this node holds this nickname. 1087 o Tree Root Priority: This is an unsigned 16-bit integer that gives 1088 the priority of this nickname to become a distribution tree root. 1090 o Nickname: This is an unsigned 16-bit integer that gives device 1091 identifier or alias. 1093 Each nickname record consists of a one-byte priority set to 1094 application dependent values, two bytes of tree root priority and two 1095 bytes of device identifier or alias (i.e., actual nickname). 1097 2.4.3. The Trees sub-TLV 1099 The Trees sub-TLV MUST occur only once and is carried within the 1100 Router CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by 1101 the originating IS. Each device announces three numbers: the number 1102 of trees it dictates that all other Intermediate Systems in the 1103 campus compute if it is the highest priority tree root; the maximum 1104 number of trees it is able to compute; and the number of distribution 1105 trees it wishes to be able to use in forwarding multi-destination 1106 traffic. 1108 All nodes run the same algorithm as described in [RBRIDGES] and the 1109 elected highest priority tree root dictates the number of 1110 distribution tree roots to be used in the network domain and can 1111 additionally list those roots in the tree roots identifier sub-TLV. 1113 +-+-+-+-+-+-+-+-+ 1114 |Type = TREE | 1115 +-+-+-+-+-+-+-+-+ 1116 | Length | (1 byte) 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Number of trees to compute | (2 byte) 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Maximum trees able to compute | (2 byte) 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Number of trees to use | (2 byte) 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 o Type: sub-TLV Type, set to 7 (TREE). 1127 o Length: 6 : Total number of bytes contained in the value field. 1129 o Number of trees to compute: This is an unsigned 16-bit integer 1130 that gives the requested number of distribution trees for multi- 1131 destination frames that will be in use in the Layer-2 domain, if 1132 this device becomes the highest priority tree root in the domain. 1134 o Maximum number of trees able to compute: This is an unsigned 16- 1135 bit integer that give the maximum number of threes that the 1136 originating IS is able to compute for the campus. 1138 o Number of trees to use: This is an unsigned 16-bit integer that 1139 gives the number of distribution trees the originating IS wishes 1140 to use. 1142 2.4.4. The Tree Identifiers Sub-TLV 1144 The tree identifiers sub-TLV is an ordered list of nicknames. When 1145 originated by the Intermediate System which is the highest priority 1146 tree root, this list is the trees which the other Intermediate 1147 Systems are required to compute. If this information is spread 1148 across multiple sub-TLVs, the starting tree number is used to to 1149 allow the ordered lists to be correctly concatenated. It is carried 1150 within the Router CAPABILITY TLV in a level-1 non-pseudo-node LSP and 1151 is given as: 1153 +-+-+-+-+-+-+-+-+ 1154 |Type=TREE-RT-ID| 1155 +-+-+-+-+-+-+-+-+ 1156 | Length | (1 byte) 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 |Starting Tree Number | (2 bytes) 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Nickname (K-th root) | (2 bytes) 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Nickname (K+1 - th root) | (2 bytes) 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Nickname (...) | 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 o Type: sub-TLV Type, set to 8 (TREE-RT-IDs). 1169 o Length: Total number of bytes contained in the value field. 1171 o Starting Tree Number: This identifies the starting tree number of 1172 the nicknames that are trees for the domain. This is set to 1 for 1173 the first sub-TLV. Subsequent sub-TLVs will have the starting 1174 number of the ordered list. In the event a tree identifier can be 1175 computed from two such sub-TLVs and are different, then it is 1176 assumed that this is a transient condition that will get cleared. 1177 During this transient time, such trees cannot be computed. 1179 o Nickname: The nickname on which this tree is based. 1181 2.4.5. The Trees Used Identifiers Sub-TLV 1183 This sub-TLV has the same structure as the Tree Identifiers sub-TLV 1184 specified in the above section. The only difference is that its sub- 1185 TLV type is set to 9 TBD (TREE-USE-IDs) and the trees listed are only 1186 those that the originating intermediate systems wishes to use. 1188 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV 1190 The value of this sub-TLV consists of a VLAN range, flags, and a 1191 variable length list of spanning tree root bridge IDs. This sub-TLV 1192 may appear zero, one, or many times. The union of the VLAN ranges in 1193 all occurrences MUST be precisely the set of VLANs for which the 1194 originating Intermediate System is appointed forwarder on at least 1195 one port and the VLAN ranges in multiple VLANs sub-TLVs for an 1196 Intermediate System MUST NOT overlap. That is, the intersection of 1197 the VLAN ranges for any pair of these sub-TLVs originated by an 1198 Intermediate System must be null. The value length is 10 + 6*n where 1199 n is the number of root bridge IDs. The TLV layout is as follows: 1201 +-+-+-+-+-+-+-+-+ 1202 |Type = INT-VLAN| 1203 +-+-+-+-+-+-+-+-+ 1204 | Length | (1 byte) 1205 +---------------+-----+ 1206 | Nickname | (2 bytes) 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Interested VLANS | (8 bytes) 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | Root Bridges | (6*n bytes) 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 o Type: sub-TLV Type, set to 10 (INT-VLAN). 1215 o Length: Total number of bytes contained in the value field. 1217 o Nickname: If this is set to 0, then it applies to all nicknames 1218 generated by the node. It may alternatively be set to a specific 1219 nickname, in the event a node wants to segregate traffic using 1220 multiple nicknames. 1222 o Interested VLANS: In the Interested VLANs, as shown below, the M4 1223 bit indicates that there is an IPv4 multicast router on a link for 1224 which the originating Intermediate System is appointed forwarder 1225 for every VLAN in the indicated range. The M6 bit indicates the 1226 same for an IPv6 multicast router. The R and Reserved bits MUST 1227 be set as zero and are ignored on receipt. The VLAN start and end 1228 IDs are inclusive. A range of one VLAN ID is indicated by setting 1229 them both to that VLAN ID value. The Appointed Forwarder Status 1230 Lost Counter is also included here. It is a count of how many 1231 times a port that was appointed forwarder for the VLANs in the 1232 range given has lost the status of being an appointed forwarder. 1233 It has the following format: 1234 0 1 2 3 4 - 15 16 - 19 20 - 31 1235 +----+----+----+----+------------+----------+------------+ 1236 | M4 | M6 | R | R | VLAN start | Reserved | VLAN end | 1237 +----+----+----+----+------------+----------+------------+ 1238 | Appointed Forwarder Status Lost Counter | 1239 +----+----+----+----+------------+----------+------------+ 1241 o Root Bridges: The list of zero or more spanning tree root bridge 1242 IDs is the set of root bridge IDs seen for all ports for which the 1243 Intermediate System is appointed forwarder for the VLANs in the 1244 range. This information is learned from BPDUs heard by the 1245 Intermediate System. If MSTP is in use on a link, the root bridge 1246 referred to is the CIST (common and internal spanning tree) root 1247 bridge. (While, of course, only one spanning tree root should be 1248 seen on any particular port, there may be multiple ports in the 1249 same VLAN connected to differed bridged LANs with different 1250 spanning tree roots.) If no spanning tree roots can be seen on 1251 any of the links in any of the VLANs in the range indicated for 1252 which the Intermediate System is appointed forwarder (for example 1253 all such links are point-to-point links to other Intermediate 1254 Systems or to end stations so no BPDUs are received) then the 1255 listed set of spanning tree root IDs will be null. 1257 If there are any two VLANs in the range indicated for which the value 1258 of the M4, or M6 bits or the Appointed Forwarder Status Lost Counter 1259 are different, the sub-TLV is incorrect and must be split into 1260 multiple sub-TLVs each indicating only VLANs with the same M4, M6, 1261 and Appointed Forwarder Status Lost Counter values. If there are any 1262 two VLANs in the range indicated for which the set of root bridge IDs 1263 see on all links for which the Intermediate System is appointed 1264 forwarder for the VLAN are not the same, the sub-TLV is incorrect and 1265 must be split into multiple sub-TLVs each indicating only VLANs with 1266 the same set of DRB seen root bridge IDs. It is always safe to use 1267 sub-TLVs with a "range" of one VLAN ID but this may be too verbose. 1269 Wherever possible, an implementation SHOULD advertise the update to a 1270 interested vlan and spanning tree roots sub-TLV in the same LSP 1271 fragment as the advertisement that it replaces. Where this is not 1272 possible, the two affected LSP fragments should be flooded as an 1273 atomic action. 1275 Systems that receive an update to an existing interested vlan and 1276 spanning tree roots sub-TLV can minimize the potential disruption 1277 associated with the update by employing a holddown time prior to 1278 processing the update so as to allow for the receipt of multiple LSP 1279 fragments associated with the same update prior to beginning 1280 processing. 1282 Where a receiving system has two copies of a interested vlan and 1283 spanning tree roots sub-TLV from the same system that have different 1284 settings for a given vlan, the procedure used to choose which copy 1285 shall be used is undefined (refer to RFC 4971, Section 3). 1287 This sub-TLV is carried within the CAPABILITY TLV in a level-1 1288 multicast group PDU. 1290 2.4.7. The VLAN Group sub-TLV 1292 The VLAN Group sub-TLV consists of two or more 16-bit fields each of 1293 which has a VLAN ID in the low order 12 bits. The top 4 bits MUST be 1294 set as zero and ignored on receipt. The first such VLAN ID is the 1295 primary, or may be zero if there is no primary. It is carried within 1296 the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is structured 1297 as follows: 1299 +-+-+-+-+-+-+-+-+ 1300 |Type=VLAN-GROUP| 1301 +-+-+-+-+-+-+-+-+ 1302 | Length | (1 byte) 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Primary VLAN ID (2 bytes) | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Secondary VLAN ID (2 bytes) | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | more Secondary VLAN IDs ... | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 o Type: TLV Type, set to 11 (VLAN-GROUPs). 1313 o Length: Total number of bytes contained in the value field, 4 + 1314 2*n, where n may be 0. 1316 o Primary VLAN-ID: This identifies the primary VLAN-ID. 1318 o Secondary VLAN-ID: This identifies a secondary VLAN in the VLAN 1319 Group. 1321 This sub-TLV indicates that shared VLAN learning is occurring at the 1322 announcing Intermediate System between the listed VLANs. This sub- 1323 TLV may appear zero, one, or multiple times. It should be noted that 1324 all VLAN ID values described above have a 4 bit reserved section 1325 followed by a 12-bit value. It is carried within the CAPABILITY TLV. 1327 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-TLV 1329 By including this sub-TLV within one or more Router Capability TLVs 1330 in its LSPs, an RBridge can advertise the Ingress-to-Egress options 1331 it supports. This sub-TLV may appear zero or more times within a 1332 Router Capability TLV. By default, in the absence of any ITEOPT sub- 1333 TLVs, no Ingress-to-Egress options are supported. 1335 There are two types of Ingress-to-Egress option encoding within the 1336 TRILL Header: bit options and TLV encoded options. 1338 The bit-encoded options supported are indicated by an ITEOPT TLV of 1339 length 3: an initial value byte of 0x00 followed by two bytes in 1340 which each bit indicates that the corresponding bit Ingress-to-Egress 1341 option is implemented. 1343 Other Ingress-to-Egress options are TLV encoded within the TRILL 1344 Header options area. The implementation of a TLV encoded option is 1345 indicated by an ITEOPT sub-TLV whose value starts with a byte equal 1346 to the first byte of the option. Such ITEOPT sub-TLVs may have 1347 additional value bytes further indicating how the option is supported 1348 as specified in the option's definition, for example a list of 1349 supported security algorithms. 1351 +-+-+-+-+-+-+-+-+ 1352 | Type = ITEOPT | 1353 +-+-+-+-+-+-+-+-+ 1354 | Length | (1 byte) 1355 +-+-+-+-+-+-+-+-+ 1356 | Option | (1 byte) 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | Option dependent variable length information | 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 o Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12 1362 [TBD]. 1364 o Length: variable, minimum 1. 1366 o Value: Either 0x00 followed by implementation information for bit 1367 encoded options or a non-zero option type byte followed by option 1368 dependent information for that option. 1370 2.4.9. VLAN Mapping (VMAP) sub-TLV 1372 The VLAN Mapping (VMAP) sub-TLV carries information concerning VLAN 1373 mappings configured at the originating IS. VLAN mapping is used when 1374 an RBridge campus is divided into regions such that the same VLAN is 1375 represented by different VLAN IDs in different regions or there is a 1376 VLAN is one region that has no equivalent in another region. Each 1377 port on each of the border RBridges between two or more regions MUST 1378 be configured as to which region each port connects with. The 1379 numbering of regions is an arbitrary choice but all border RBridges 1380 in the campus MUST agree on the number of each region. 1382 +-+-+-+-+-+-+-+-+ 1383 | Type = VMAP | 1384 +-+-+-+-+-+-+-+-+ 1385 | Length | (1 byte) 1386 +-+-+-+-+-+-+-+-+----------...+ 1387 | Mapping 1 | (8 bytes) 1388 +-+-+-+-+-+-+-+------------... 1389 | Mapping N, etc.| 1390 +--------------------------... 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Count | From VLAN ID | (2 bytes) 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | From Region | (2 bytes) 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 | RESV | To VLAN ID | (2 bytes) 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | To Region | (2 bytes) 1400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 o Type: sub-TLV Type, set to VLAN Mapping sub-TLV 13 [TBD]. 1404 o Length: variable, 8*N. 1406 o Value: Specific information on each VLAN mapping as diagrammed 1407 above and specified below: 1409 * Count: If this four bit unsigned integer is zero or 1, then the 1410 mapping of a single VLAN ID is being specified. If it is any 1411 value from 2 through 15, then a block of that many contiguous 1412 VLAN IDs starting with the From VLAN ID is mapped to a block of 1413 that many contiguous VLAN IDs starting with the To VLAN ID. 1415 * From VLAN ID: This is the VLAN ID that, when received on a port 1416 connect to the From Region on a frame being sent to the To 1417 Region, is mapped to the To VLAN ID. This must be a real VLAN 1418 ID, that is, the values 0x000 and 0xFFF are prohibited and 1419 mappings in which they occur are ignored. 1421 * From Region: This is the region number, within the campus, such 1422 that frames received on a port connected to that region and 1423 destined to a port connected to the To Region have their VLAN 1424 ID mapped as specified by the From VLAN ID and To VLAN ID 1425 fields. 1427 * RESV: MUST be sent as zero and ignored on receipt. 1429 * To VLAN ID: This is the VLAN ID to be used on frames sent out a 1430 port connected to the To Region if they were received on a port 1431 connected to the From Region with the From VLAN ID; except that 1432 if the To VLAN ID is 0x000 the frame is dropped. The value 1433 invalid VLAN ID 0xFFF is prohibited in this field and if it 1434 occurs the mapping is ignored. 1436 * To Region: This is the region number, within the campus, such 1437 that frames sent on a port connected to this region from a port 1438 connected to the From Region have their VLAN ID mapped as 1439 specified by the From VLAN ID and To VLAN ID fields. 1441 2.5. Multi Topology Aware Capability TLV 1443 This section defines a new optional Intermediate System to 1444 Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of 1445 multiple sub-TLVs, which allows a router to announce its capabilities 1446 for a particular topology within an IS-IS level or the entire routing 1447 domain. This is different from Router Capability TLV defined in RFC 1448 4971, in the sense that the capabilities announced here are topology 1449 scoped. 1451 The Multi Topology Aware Capability (MT-CAPABILITY) is an optional 1452 IS-IS TLV type 144 [TBD], that may be generated by the originating IS 1453 and has the following format: 1454 0 1 2 3 1455 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 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 |Type=MTCAPABTLV| Length |O|R|R|R| Topology Identifier | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 | sub-TLVs | 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 o Type: TLV Type, set to MT-CAPABILITY TLV 144 [TBD]. 1463 o Length: Total number of bytes contained in the value field, 1464 including the length of the sub-TLVs carried in this TLV. 1466 o O bit: The overload bit that follows the semantics associated with 1467 an overloaded intermediate system. 1469 o Reserved (3 bits): Must be sent as zero on transmission and is 1470 ignored on receipt. 1472 o Topology Identifier: MT ID is a 12-bit field containing the MT ID 1473 of the topology being announced. This field when set to zero 1474 implies that it is being used to carry base topology information. 1475 In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, 1476 it may be non-zero. 1478 o sub-TLVs: The MT aware Capabilities TLV value contains sub-TLVs 1479 formatted as described in [RFC5305]. They are defined in the next 1480 sections. 1482 The MT-CAPABILITY TLV MUST be carried only within a LSP PDU. It may 1483 occur multiple times in a LSP PDU. 1485 2.5.1. SPB Instance sub-TLV 1487 The SPB Instance sub-TLV gives the SPSourceID for this node/topology 1488 instance. This is the 20 bit value that is used in the formation of 1489 multicast DA addresses for packets originating from this node/ 1490 instance. The SPSourceID occupies the upper 20 bits of the multicast 1491 DA together with 4 other bits (see the SPB 802.1ah multicast DA 1492 address format section). 1494 This sub-TLV MUST be carried within the MT-Capability TLV in the 1495 fragment ZERO LSP. If there was an additional SPB instance it MUST 1496 be declared under a separate MT-Topology and also carried 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 where VLAN-ID tuples have the format as: 1523 0 1 2 3 1524 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 1525 +-+-+-+-+-+-+-+-+ 1526 |U|M|A| Res | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | ECT - Algorithm (32 bits) | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | Base VID (12 bits) | SPVID (12 bits) | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 o Type: sub-TLV Type, set to SPB Instance sub-TLV 1 [TBD]. 1535 o Length: Total number of bytes contained in the value field. 1537 o CIST Root Identifier (64-bits)The CIST Root Identifier is for SPB 1538 interworking with RSTO and MSTP at SPT RegionBoundaries. This is 1539 an imported value from a Spanning tree. 1541 o CIST External Root Path Cost (32-bits) The CIST External Root Path 1542 Cost is the cost from the Spanning tree algorithm to the Root. 1544 o Bridge Priority (16-bits) Bridge priority is the 16 bits that 1545 together with the low 6 bytes of the System ID form the Bridge 1546 Identifier. The Bridge Identifier is the Spanning tree compatible 1547 Bridge identifier. This is configured exactly as specified in 1548 IEEE802 [802.1D]. This allows SPB to build a compatible Spanning 1549 tree using link state by combining the Bridge Priority and the 1550 System ID to form the 8 byte Bridge Identifier. The 8 byte Bridge 1551 Identifier is also the input to the 16 pre-defined ECT tie breaker 1552 algorithms. 1554 o V bit (1-Bit) The V bit (SPBM) indicates this SPSourceID is auto 1555 allocated(27.11). If the V bit is clear the SPSourceID has been 1556 configured and must be unique. Allocation of SPSourceID is 1557 defined in [IEEE 802.1aq]. Bridges running SPBM will allocate an 1558 SPSourceID if they are not configured with an explicit SPSourceID. 1559 The V Bit allows neighbor bridges to determine if the auto 1560 allocation was enabled. In the rare chance of a collision of 1561 SPsourceID the bridge with the highest priority Bridge Identifier 1562 will win conflicts and the lower priority Bridge will be re- 1563 allocated or if the lower priority Bridge is configured it will 1564 not be allowed to joint the SPT Region. 1566 o The SPSOURCEID is a 20 bit value used to construct multicast DA's 1567 as described below for multicast packets originating from the 1568 origin (SPB node) of the link state packet (LSP) that contains 1569 this TLV. More details are in [IEEE 802.1aq]. 1571 o Number of Trees (8-bits) The Number of Trees is be set to the 1572 number of [ECT-ALGORITHM, Base-VID plus flags] sub TLV's that 1573 follow. Each ECT-ALGORITHM has a Base VID, an SPVID and some 1574 flags described below. This must be set to at least one ECT. 1575 These define the standard ECTs. 1577 o Each VID Tuple consists of: 1579 * U-Bit (1-bit) The Use flag is set if this bridge is currently 1580 using this ECT-ALGORITHM for I-SIDs it sources or sinks. This 1581 is a bit different than the U-bit found in the Hello, which 1582 will set the Use-Flag if it sees other nodal Use-Flags are set 1583 OR it sources or sinks itself. 1585 * M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode. 1587 * A bit, The A bit (SPB) when set declares this is an SPVID with 1588 auto allocation. The VID allocation logic details are in [IEEE 1589 802.1aq]. Since SPVIDs are from a small pool of resources 1590 (1000 or less) the chances of collision are high. To allow 1591 auto allocation LSPs are exchanged with the allocated bridge 1592 setting the SPVID to 0. 1594 * ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is advertised when the 1595 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 1596 VID. This declaration must match the declaration in the Hello 1597 PDU originating from the same bridge. The ECT-ALGORITHM, BASE- 1598 VID should match what is generated in the Hellos of the same 1599 node. The ECT-ALGORITHM, BASE-VIDs pairs can come in any order 1600 however. 1602 * Base VID (12-bits) The Base-VID that associated the SPT Set via 1603 the ECT-ALGORITHM. 1605 * SPVID (12-bits) The SPVID is the Shortest Path VID when using 1606 SPBV mode. It is not defined for SPBM Mode and should be 0 in 1607 SPBM mode. 1609 2.5.2. SPB Opaque ECT Algorithm sub-TLV 1611 There are multiple ECT algorithms defined for SPB, however for the 1612 future additional algorithms may be defined. These algorithms would 1613 use this optional TLV to define new algorithm tie breaking data. 1614 There are two broad classes of algorithm, one which uses nodal data 1615 to break ties and one which uses link data to break ties, as a result 1616 this TLV can associate opaque data with a node or an adjacency or 1617 both. 1619 This sub-TLV SHOULD be carried within the MT-Capability TLV. (along 1620 with a valid SPB Instance sub-TLV (2.5.1)) and/or this sub-TLV SHOULD 1621 be carried within the Extended Reachability TLV (type 22). Multiple 1622 copies of this sub-TLV may be carried for different ECT-ALGORITHMs 1623 both for a node and for an adjacency. 1625 +-+-+-+-+-+-+-+-+ 1626 |Type = SPB-OALG| 1627 +-+-+-+-+-+-+-+-+ 1628 | Length | (1 byte) 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Opaque ECT Algorithm (4 bytes) | 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Opaque ECT Information (variable) | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 o Type: sub-TLV Type, set to SPB OALG sub-TLV 2 [TBD]. 1637 o Length: Total number of bytes contained in the value field. 1639 o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge 1640 supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. 1642 o ECT Information: ECT-ALGORITHM Information of variable length. 1644 2.5.3. SPBM Service Identifier and Unicast Address sub-TLV 1646 The SPBM Service Identifier and Unicast Address sub-TLV is used to 1647 introduce service group membership on the originating node and/or to 1648 advertise an additional B-MAC unicast address present on, or 1649 reachable by the node. 1651 +-+-+-+-+-+-+-+-+ 1652 |Type = SPBM-SI | 1653 +-+-+-+-+-+-+-+-+ 1654 | Length | (1 byte) 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | B-MAC ADDRESS (6 bytes) | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | Res. | Base-VID | ( 2 bytes) 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 |T|R| Reserved | ISID #1 | (1+3 bytes) 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 |T|R| Reserved | ISID #2 | (1+3 bytes) 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 |T|R| Reserved | ISID #n | (1+3 bytes) 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 o Type: sub-TLV Type, set to SPBM Service Identifier and Unicast 1668 Address sub-TLV 3 [TBD]. 1670 o Length: Total number of bytes contained in the value field. 1672 o B-MAC ADDRESS is a unicast address of this node. It may be either 1673 the single nodal address, or may address a port or any other level 1674 of granularity relative to the node. In the case where the node 1675 only has one B-MAC address this should be the same as the SYS-ID 1676 of the node. To add multiple B-MACs this TLV must be repeated per 1677 additional B-MAC. 1679 o ISID #1 .. #N are 24 bit service group membership identifiers. If 1680 two nodes have an ISID in common, intermediate nodes on the unique 1681 shortest path between them will create forwarding state for the 1682 related B-MAC addresses and will also construct multicast 1683 forwarding state using the ISID and the node's SPSOURCEID to 1684 construct a multicast DA as described in IEEE 802.1aq LSB. Each 1685 ISID has a Transmit(T) and Receive(R) bit which indicates if the 1686 membership is as a Transmitter/Receiver or both (with both bits 1687 set). In the case where the Transmit(T) and Receive(R) bits are 1688 both zero, the ISID is ignored. If more ISIDs are associated with 1689 a particular B-MAC than can fit in a single sub-TLV, this sub-TLV 1690 can be repeated with the same B-MAC but with different ISID 1691 values. 1693 The SPBM Service Identifier sub-TLV SHOULD be carried within the MT- 1694 Capability TLV and can occur multiple times in any LSP fragment. 1696 2.5.4. The SPBV MAC Address sub-TLV 1698 The SPBV MAC Address (SPBV-MAC-ADDR) sub-TLV is IS-IS sub-TLV type 4 1699 and has the following format: 1701 +-+-+-+-+-+-+-+-+ 1702 | Type=SPBV-ADDR| (1 byte) 1703 +-+-+-+-+-+-+-+-+ 1704 | Length | (1 byte) 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 |R|R|S|R| SPVID | (2 bytes) 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 |T|R| Reserved | MAC 1 Address | (1+6 bytes) 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | ... | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 |T|R| Reserved | MAC N Address | (1+6 bytes) 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 o Type: sub-TLV Type, set to 4 (SPBV-MAC-ADDR). 1717 o Length: Total number of bytes contained in the value field. The 1718 number of MAC address associated with the SPVID is computed by 1719 (Length - 2)/7. 1721 o SR bits (2-bits) The SR bits are the service requirement parameter 1722 from MMRP. The service requirement parameters have the value 0 1723 (Forward all Groups) and 1 (Forward All Unregistered Groups) 1724 defined. However this attribute may also be missing. So the SR 1725 bits are defined as 0 not declared, 1 Forward all Groups and 2 1726 Forward All Unregistered Groups. These bits have two Reserved 1727 bits set before them. 1729 o SPVID (12-bits) The SPVID and by association Base VID and the ECT- 1730 ALGORITHM and SPT Set that the MAC addresses defined below will 1731 use. If the SPVID is not allocated the SPVID Value is 0. Note 1732 that if the ECT-Algorithm in use is Spanning Tree Algorithm this 1733 value should be populated with the Base VID and the MAC can be 1734 populated. 1736 o T Bit (1-bit) This is the Transmit allowed Bit for the following 1737 group MAC address. This is an indication that SPBV Group MAC 1738 Address with SPVID of source should be populated (for the bridge 1739 advertising this Group MAC), and installed in the FDB of transit 1740 bridges, when the bridge computing the trees is on the 1741 corresponding ECT-ALGORITHM shortest path between the bridge 1742 advertising this MAC with the T bit set, and any receiver of this 1743 Group MAC Address. A bridge that does not advertise this bit set 1744 for an Group MAC Address should have no forwarding state installed 1745 for traffic originating from that bridge on other transit bridges 1746 in the network. 1748 o R Bit (1-bit) This is the Receive allowed Bit for the following 1749 Group MAC Address. This is an indication that SPBV Group MAC 1750 Addresses as receiver should be populated (for bridges advertising 1751 this Group MAC Address with the T bit set) and installed when the 1752 bridge computing the trees lies on the corresponding shortest path 1753 for this ECT-ALGORITHM between this receiver and any transmitter 1754 on this Group MAC Address. An entry that does not have this bit 1755 set for a Group MAC Address is prevented from receiving on this 1756 Group MAC Address because transit bridges will not install 1757 multicast forwarding state towards it in their FDBs or the traffic 1758 is explicitly filtered. 1760 o MAC Address (48-bits) The MAC is address is either a group address 1761 or an individual address. Individual addresses are optional and 1762 normal MAC learning can be used. When the MAC address is a group 1763 address it declares this bridge as part of the multicast interest 1764 for this destination MAC address. Multicast trees can be 1765 efficiently constructed for destination by populating multicast 1766 FDB entries for the subset of the shortest path tree that connects 1767 the bridges supporting the multicast address. This replaces the 1768 function of MMRP for SPTs. The T and R bits above have meaning if 1769 this is a group address. Individual addresses are populated only 1770 as if the R bit was not set. 1772 The SPBV-MAC-ADDR sub-TLV SHOULD be carried within the MT-Capability 1773 TLV and can occur multiple times in any LSP fragment. 1775 2.6. Sub-TLVs of the Extended Reachability TLV 1777 This section specifies three new sub-TLVs that appear only within the 1778 Extended Reachability TLV (type 22). 1780 2.6.1. SPB Link Metric sub-TLV 1782 The SPB Link Metric sub-TLV occurs within the Extended Reachability 1783 TLV (type 22), or the Multi Topology Intermediate System TLV (type 1784 222). If this sub TLV is not present for an ISIS adjacency then that 1785 adjacency MUST NOT carry SPB traffic for the given topology instance. 1787 +-+-+-+-+-+-+-+-+ 1788 |Type=SPB-Metric| 1789 +-+-+-+-+-+-+-+-+ 1790 | Length | (1 byte) 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | SPB-LINK-METRIC | (3 bytes) 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | Num of ports | (1 byte) 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Port Identifier | ( 2 bytes) 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 o Type: sub-TLV Type, set to SPB Link Metric sub-TLV 5 [TBD]. 1801 o Length: Total number of bytes contained in the value field. 1803 o SPB-LINK-METRIC indicates the administrative cost or weight of 1804 using this link as a 24 bit unsigned number. Smaller numbers 1805 indicate lower weights and are more likely to carry SPB traffic. 1806 Only one metric is allowed per SPB instance per link. If multiple 1807 metrics are required multiple SPB instances are required, either 1808 within IS-IS or within several independent IS-IS instances. 1810 o Num of Ports is the number of ports associated with this link. 1812 o Port Identifier is the standard IEEE port identifier used to build 1813 a spanning tree associated with this link. 1815 o an opaque ECT Data sub-TLV (type TBD) whose first 32 bits are the 1816 ECT-ALGORITHM to which this data applies. 1818 2.6.2. SPB Opaque ECT Algorithm sub-TLV 1820 This sub-TLV is identical in format and type as the 2.5.2 SPB Opaque 1821 ECT Algorithm sub-TLV and carries future opaque data for the purpose 1822 of extending ECT behavior. Multiple copies of the sub-TLV may occur 1823 for different ECT-ALGORITHMs. 1825 2.6.3. MTU sub-TLV 1827 The MTU sub-TLV is used to optionally announce the MTU of a link. It 1828 occurs nested as within the Extended Reachability TLV (type 22). 1830 +-+-+-+-+-+-+-+-+ 1831 | Type = MTU | 1832 +-+-+-+-+-+-+-+-+ 1833 | Length | (1 byte) 1834 +-+-+-+-+-+-+-+-+ 1835 |F| Reserved | (1 byte) 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | MTU | (2 bytes) 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 o Type: sub-TLV Type, set to MTU sub-TLV 6 [TBD]. 1842 o Length: Total number of bytes contained in the value field. 1844 o F: Failed. This bit is a one if MTU testing on this link failed 1845 at the required campus-wide MTU. 1847 o MTU: This field is set to the largest successfully tested MTU size 1848 for this link or zero if it has not been tested. 1850 2.7. TRILL Neighbor TLV 1852 The TRILL Neighbor TLV is used in the TRILL-Hello PDU in place of the 1853 IS Neighbor TLV. It differs in that MTU information is provided per 1854 neighbor and provision is made for fragmentation, so that not all 1855 neighbors need be reported in each TRILL-Hello, to support the hard 1856 limit on the size of TRILL-Hellos. This TLV can occur zero, one, or 1857 multiple times in a TRILL-Hello PDU. The structure of the TRILL 1858 Neighbor TLV is as follows: 1860 +-+-+-+-+-+-+-+-+ 1861 | Type = TNeigh | 1862 +-+-+-+-+-+-+-+-+ 1863 | Length | (1 byte) 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 |S|L| Reserved | (2 bytes) 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | Neighbor RECORDS (1) | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | ................. | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Neighbor RECORDS (N) | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 The list of neighbors MUST be ordered by MAC address, considering 1875 each 6-byte MAC address to be an unsigned integer, starting with the 1876 smallest. The information present for each neighbor is as follows: 1878 +-+-------------------+ 1879 |F| Reserved | (2 bytes) 1880 +-+-------------------+ 1881 | MTU | (2 bytes) 1882 +--------------------------------------------------------+ 1883 | MAC Address | (6 bytes) 1884 +--------------------------------------------------------+ 1886 o Type: TLV Type, set to TRILL-Neighbor TLV 145 [TBD]. 1888 o Length: Total number of bytes contained in the value field, 2 + 1889 10*n, where n is the number of neighbor records. 1891 o S: smallest flag. If this bit is a one, then the list of 1892 neighbors includes the neighbor with the smallest MAC address. 1894 o L: largest flag. If this bit is a one, then the list of neighbors 1895 includes the neighbor with the largest MAC address. 1897 o Reserved: These bits are reserved for future use and MUST be set 1898 to zero on transmission and ignored on receipt. 1900 o F: failed. This bit is a one if MTU testing to their neighbor 1901 (see Section 2.9.6) failed at the required campus-wide MTU 1903 o MTU: This field is set to the largest successfully tested MTU size 1904 for this neighbor or zero if it has not been tested. 1906 o MAC Address: The MAC address of the neighbor as in the IS Neighbor 1907 RLV (#6). 1909 2.8. The Group Membership Active Source TLV 1911 The Group Active Source (GMAS) TLV is IS-IS TLV type 146 [TBD] and 1912 has the following format: 1914 +-+-+-+-+-+-+-+-+ 1915 | Type = GMAS | (1 byte) 1916 +-+-+-+-+-+-+-+-+ 1917 | Length | (1 byte) 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | sub-TLVs (variable bytes) | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 o Type: TLV Type, set to GMAS-TLV 146 [TBD]. 1924 o Length: Total number of bytes contained in the value field, which 1925 includes the length of the sub-TLVs carried in this TLV. 1927 o sub-TLVs: The Group Active Source TLV value contains sub-TLVs 1928 formatted as described in [RFC5305]. The sub-TLVs for this TLV 1929 are specified in the following subsections. 1931 The GMAS TLV is carried within Multicast Group Level 1 link state 1932 PDU. 1934 2.8.1. The Group MAC Active Source sub-TLV 1936 The Group MAC Source (GMAS-MAC) sub-TLV is IS-IS sub-TLV type 1 1937 within the GMAS TLV. It is used in OTV [OTV] to create multicast 1938 distribution trees and has the following format: 1940 +-+-+-+-+-+-+-+-+ 1941 | Type=GMAS-MAC | (1 byte) 1942 +-+-+-+-+-+-+-+-+ 1943 | Length | (1 byte) 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 |G|S| R | Vlan ID | (2 byte) 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | Address family | (2 bytes) 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | Length | (1 byte) 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | Delivery group (afi scoped number of bytes) | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 | Delivery Source (afi scoped number of bytes) | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 |Num Group Recs | (1 byte) 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | GROUP RECORDS (1) | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | ................. | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | GROUP RECORDS (N) | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 where each group record is of the form: 1966 +-+-+-+-+-+-+-+-+ 1967 | RESERVED | (1 byte) 1968 +-+-+-+-+-+-+-+-+ 1969 | Num of Sources| (1 byte) 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | Group Address (6 bytes) | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Source 1 Address (6 bytes) | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Source 2 Address (6 bytes) | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | Source M Address (6 bytes) | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 o Type: sub-TLV Type, set to 1 (GMAS-MAC) of length 1 byte. 1982 o Length: Total number of bytes contained in the value field. 1984 o G (1 bit): Delivery Group is set 1986 o S (1 bit): Delivery Source is set 1988 o RESERVED (2 bits) : Must be sent as zero on transmission and is 1989 ignored on receipt. 1991 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 1992 all subsequent MAC addresses in this sub-TLV, or the value zero if 1993 no VLAN is specified. 1995 o Address Family: Describes the Address family of the Delivery 1996 Source/Group information. 1998 o Length: Gives the length of the Delivery Source and Delivery Group 1999 field. 2001 o Delivery Group: Describes the group used to deliver packets. 2003 o Delivery Source: Describes the source address used to deliver 2004 packets. 2006 o Number of Group Records: This is of length 1 byte and lists the 2007 number of group records in this sub-TLV. 2009 o Group Record: Each group record has a one byte reserved space and 2010 the next byte carries the number of sources. It then has a 48-bit 2011 multicast Group Address followed by 48-bit source MAC addresses. 2012 An address being a group multicast address or unicast source 2013 address can be checked using the multicast bit in the address. If 2014 the number of sources do not fit in a single sub-TLV, it is 2015 permitted to have the same group address repeated with different 2016 source addresses in another sub-TLV of another instance of the 2017 Group Active Source TLV. 2019 The GMAS-MAC sub-TLV is carried within the GMAS TLV and MUST be 2020 carried in a standard Level 1 link state MGROUP PDU. 2022 2.8.2. The Group IP Active Source sub-TLV 2024 The Group IP Address (GMAS-IP) sub-TLV is IS-IS TLV type 2. It is 2025 used in OTV [OTV] to create multicast distribution trees and has the 2026 following format: 2028 +-+-+-+-+-+-+-+-+ 2029 | Type=GMAS-IP | (1 byte) 2030 +-+-+-+-+-+-+-+-+ 2031 | Length | (1 byte) 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 |G|S| R | Vlan ID | (2 byte) 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Address family | (2 bytes) 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Length | (1 byte) 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | Delivery group (afi scoped number of bytes) | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Delivery Source (afi scoped number of bytes) | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 |Num Group Recs | (1 byte) 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | GROUP RECORDS (1) | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | ................. | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | GROUP RECORDS (N) | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 where each group record is of the form: 2054 +-+-+-+-+-+-+-+-+ 2055 | RESERVED | (1 byte) 2056 +-+-+-+-+-+-+-+-+ 2057 | Num of Sources| (1 byte) 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | Group Address (4 bytes) | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Source 1 Address (4 bytes) | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Source 2 Address (4 bytes) | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Source M Address (4 bytes) | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 o Type: sub-TLV Type, set to 2 (GIP-ADDR). 2070 o Length: Total number of bytes contained in the value field of the 2071 sub-TLV. 2073 o G (1 bit): Delivery Group is set 2075 o S (1 bit): Delivery Source is set 2077 o RESERVED (2 bits) : Must be sent as zero on transmission and is 2078 ignored on receipt. 2080 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 2081 all subsequent MAC addresses in this sub-TLV, or the value zero if 2082 no VLAN is specified. 2084 o Address Family: Describes the Address family of the Delivery 2085 Source/Group information. 2087 o Length: Gives the length of the Delivery Source and Delivery Group 2088 field. 2090 o Delivery Group: Describes the group used to deliver packets. 2092 o Delivery Source: Describes the source address used to deliver 2093 packets. 2095 o Number of Group Records: This is of length 1 byte and lists the 2096 number of group records in this sub-TLV. 2098 o Group Record: Each group record has a one byte reserved space and 2099 the next byte carries the number of sources. It is followed by a 2100 32-bit IPv4 Group Address followed by 32-bit source IPv4 2101 addresses. If the number of sources do not fit in a single sub- 2102 TLV, it is permitted to have the same group address repeated with 2103 different source addresses repeated in another sub-TLV of another 2104 instance of the Group Active Source TLV. 2106 The GMAS-IP TLV is carried within the GMAS TLV and MUST be carried in 2107 a standard Level 1 link state MGROUP PDU. 2109 2.8.3. The Group IPv6 Active Source sub-TLV 2111 The Group IPv6 Active Source (GMAS-IPv6) sub-TLV is IS-IS sub-TLV 2112 type 3. It is used in OTV [OTV] to create multicast distribution 2113 trees and has the following format: 2115 +-+-+-+-+-+-+-+-+ 2116 | Type=GMAS-IP | (1 byte) 2117 +-+-+-+-+-+-+-+-+ 2118 | Length | (1 byte) 2119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2120 |G|S| R | Vlan ID | (2 byte) 2121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2122 | Address family | (2 bytes) 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | Length | (1 byte) 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | Delivery group (afi scoped number of bytes) | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | Delivery Source (afi scoped number of bytes) | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 |Num Group Recs | (1 byte) 2131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2132 | GROUP RECORDS (1) | 2133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 | ................. | 2135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2136 | GROUP RECORDS (N) | 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 where each group record is of the form: 2141 +-+-+-+-+-+-+-+-+ 2142 | RESERVED | (1 byte) 2143 +-+-+-+-+-+-+-+-+ 2144 | Num of Sources| (1 byte) 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | Group Address (16 bytes) | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Source 1 Address (16 bytes) | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | Source 2 Address (16 bytes) | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | Source M Address (16 bytes) | 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 o Type: sub-TLV Type, set to 3 (GIPV6-ADDR). 2157 o Length: Total number of bytes contained in the value field. 2159 o G (1 bit): Delivery Group is set 2161 o S (1 bit): Delivery Source is set 2163 o RESERVED (2 bits) : Must be sent as zero on transmission and is 2164 ignored on receipt. 2166 o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for 2167 all subsequent MAC addresses in this sub-TLV, or the value zero if 2168 no VLAN is specified. 2170 o Address Family: Describes the Address family of the Delivery 2171 Source/Group information. 2173 o Length: Gives the length of the Delivery Source and Delivery Group 2174 field. 2176 o Delivery Group: Describes the group used to deliver packets. 2178 o Delivery Source: Describes the source address used to deliver 2179 packets. 2181 o Number of Group Records: This of length 1 byte and lists the 2182 number of group records in this sub-TLV. 2184 o Group Record: Each group record has a one byte reserved space and 2185 the next byte carries the number of sources. It is followed by a 2186 128-bit multicast IPv6 Group Address followed by 128-bit source 2187 IPv6 addresses. If the number of sources do not fit in a single 2188 sub-TLV, it is permitted to have the same group address repeated 2189 with different source addresses repeated in another sub-TLV in 2190 another instance of the Group Address TLV. 2192 The GMAS-IPv6 sub-TLV is carried within the GMAS TLV and MUST be 2193 carried in a standard Level 1 link state MGROUP PDU. 2195 2.9. PDU Extensions to IS-IS 2197 2.9.1. The Multicast Group PDU 2199 The systems that this document is concerned with want to carry not 2200 only layer-2 unicast information in the link state protocols, but 2201 also multicast information. This section specifies three new IS-IS 2202 PDUs, the Multicast Group (MGROUP) PDU, for carrying a list of 2203 attached or joined multicast groups. The Multicast Group Complete 2204 Sequence Number (MGROUP-CSNP) PDU and the Multicast Group Partial 2205 Sequence Number (MGROUP-PSNP) PDU packets are also defined to be used 2206 with the new MGROUP-PDU to perform database exchange on the MGROUP 2207 PDU packets. 2209 In the Layer-2 environment, it is expected the join/leave frequency 2210 of the multicast members will be much higher than unicast topology 2211 changes. It is efficient to separate the updates for the group 2212 membership change information from the remainder of the information 2213 by placing this information in a separate PDU. This enables 2214 reachability information, that would trigger an SPF, to be not 2215 impacted at all. Furthermore, during SPF runs, TLVs being on 2216 different PDUs which do not affect SPF need not be inspected during 2217 processing. 2219 The choice of a different PDU also opens the LSP-space to another 256 2220 fragments to carry a large number of groups. This additional space 2221 can be used judiciously to carry only multicast information. 2223 The Multicast Group (MGROUP) PDU can be used to advertise a set of 2224 attached, or joined, multicast groups. The MGROUP PDU is formatted 2225 identical to a Level 1 Link State PDU, as described in Section 9.3 of 2226 [IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify 2227 this PDU is carrying multicast group information, rather than unicast 2228 reachability information. 2230 The Multicast Group PDU carries TLVs indicating multicast membership 2231 information. There are three sub-TLVs of the GADDR TLV defined in 2232 this document, that MAY be present in this PDU, namely, GMAC-ADDR, 2233 GIP-ADDR, and GIPV6-ADDR sub-TLVs. Furthermore, it MAY carry the 2234 interested vlan sub-TLV of the Capability TLV. 2236 One or more TLVs MAY be carried in a single MGROUP PDU. Future 2237 multicast address TLVs MAY be defined using other type codes, and be 2238 carried in an MGROUP PDU. 2240 The information carried in this PDU is processed in a similar fashion 2241 as described in [RFC 1584]. 2243 2.9.2. The Multicast Group Partial Sequence Number PDU 2245 The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used 2246 to reliably flood the MGROUP PDU following the base protocol 2247 specifications. 2249 2.9.3. The Multicast Group Complete Sequence Number PDU 2251 The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is 2252 used to reliably flood the MGROUP PDU following the base protocol 2253 specifications. 2255 2.9.4. MGROUP PDU related changes to Base protocol 2257 In this section, we describe the changes to the base protocol due to 2258 the introduction of the MGROUP, MGROUP-PSNP, MGROUP-CNSP PDUs. 2260 2.9.4.1. Enhancements to the flooding process 2262 This document specifies that the information contained in the MGROUP- 2263 PDU is in a parallel database and its update mechanisms mimic that of 2264 the regular database. Nodes running IS-IS in an L2 domain MUST 2265 support these additional MGROUP PDUs defined in this document. In 2266 general, the flooding of the MGROUP-PDU in tandem with the MGROUP- 2267 PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined 2268 for the regular LSP, PSNP, and CSNP PDUs. 2270 For example, on P2P links CSNP is exchanged on the formation of an 2271 adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged 2272 between the neighbors at the same time. This gets the initial 2273 MGROUP-database synchronization going. After this similar actions of 2274 the base protocol specifications for the regular database 2275 synchronization will be maintained to keep the MGROUP-database 2276 synchronized. There need not be any more correlation between the 2277 updates of the regular PDU and the MGROUP-PDU. 2279 Similarly, on LAN links the DIS is responsible for sending periodic 2280 CSNP transmissions. The DIS in the L2 IS-IS network domain will also 2281 be responsible for sending periodic MGROUP-CSNP transmissions. The 2282 update and flooding process will work in parallel for the two 2283 databases and there is no further synchronization between them. 2285 In general, the database synchronization is performed in parallel 2286 with no interactions between the messages. However, the initial 2287 triggers that start a CSNP exchange are correlated, in the sense it 2288 also triggers a MGROUP-CSNP exchange. 2290 2.9.4.2. Enhancements to Graceful Restart 2292 During graceful restart [RFC 5306], the normal hello operations as 2293 described in the RFC will be followed. The enhancements will take 2294 place such that CSNP and PSNP triggers will necessitate a parallel 2295 MGROUP-CSNP and MGROUP-PSNP exchange and update process will be 2296 triggered in parallel for the MGROUP-PDUs. After both databases 2297 containing the regular PDUs and MGROUP-PDUs have been obtained, the 2298 restart process is deemed complete. 2300 2.9.4.3. Enhancements to the maximum sequence number reached 2302 In the event, LSPs reach the maximum sequence number, ISO/IEC 10589 2303 states the rules for the process to shut down and its duration. With 2304 the introduction of the MGROUP-PDU, the same process now applies when 2305 LSPs from either database reach the maximum sequence number. 2307 2.9.4.4. Enhancements to the SPF 2309 The MGROUP-PDU advertises a set of attached, or joined, multicast 2310 groups. These groups act as leaves of the advertising nodes. As a 2311 result, there are no new requirements of running a SPF if only 2312 information within the MGROUP-PDU changes. 2314 2.9.5. The TRILL-Hello PDU 2316 A different Hello PDU is required for TRILL links because it is 2317 necessary that a single Designated RBridge (DIS) be elected on each 2318 link based just on priority and MAC address regardless of two-way 2319 connectivity. However, RBridge reachability is reported by RBridges 2320 in their LSP on the same basis as layer 3 Intermediate Systems report 2321 reachability, that is, if and only if two-way connectivity exists. 2323 The TRILL-Hello PDU has the same general structure as an IS-IS LAN 2324 PDU. An RBridge (an Intermediate System supporting TRILL) sends this 2325 PDU, with the same timing as the IS-IS LAN Hello PDU. More 2326 specifically, in a TRILL-Hello PDU the IS-IS Common Header and the 2327 fixed PDU Header are the same as a Level 1 IS-IS LAN Hello except 2328 that a new PDU Type number is used as listed in Section 5. The 2329 circuit type field, of course, is always equal to one. A TRILL-Hello 2330 PDU SHOULD not be padded and MUST NOT exceed a length limit equal to 2331 42 bytes shorter than the reasonable lower bound for the link MTU. 2332 For example, for an 802.3 Ethernet link, the MTU SHOULD be assumed to 2333 be 1512 bytes for the purpose of determining the maximum size of 2334 TRILL-Hello PDUs on that link. Thus, for such a link, TRILL-Hellos 2335 MUST NOT exceed 1470 bytes. 2337 The following MUST appear in every TRILL-Hello PDU: a Port Capability 2338 TLV (see Section 2.3) containing a Special VLANs and Flags sub-TLV. 2340 Additional TLVs/sub-TLVs MAY appear in a TRILL-Hello including the 2341 TRILL Neighbor TLV specified in Section 2.7 and the following sub- 2342 TLVs specified in Section 2.3: Enabled VLANs sub-TLV, Appointed 2343 Forwarders sub-TLV, and Hop-by-Hop Options sub-TLV. 2345 The Padding TLV (#8) SHOULD NOT appear in a TRILL-Hello. 2347 The IS-IS Neighbor TLV (#6) MUST NOT appear in a TRILL-Hello. 2348 Instead, it uses the TRILL Neighbor TLV (see Section 2.7). 2350 2.9.6. The MTU PDU 2352 The MTU-probe and MTU-ack PDUs are used to determine the MTU on a 2353 link between intermediate systems. An MTU-probe MUST be padded to 2354 the size being tested with the Padding TLV (#8). The ability to send 2355 an MTU-probe PDU is optional but an Intermediate System that supports 2356 TRILL MUST send an MTU-ack in response to an MTU-probe and that MTU- 2357 ack MUST be padded to the size of the MTU-probe. 2359 The MTU PDUs have the standard IS-IS common header with two new PDU 2360 Type numbers, one each, as listed in Section 5. They also have a 20- 2361 byte common fixed MTU PDU header as shown below. 2363 +------------+ 2364 | PDU Length | (2 bytes) 2365 +------------+-------------------------+ 2366 | Probe ID | (6 bytes) 2367 +--------------------------------------+ 2368 | Probe Source ID | (6 bytes) 2369 +--------------------------------------+ 2370 | Ack Source ID | (6 bytes) 2371 +--------------------------------------+ 2373 As with other IS-IS PDUs, the PDU length contains length of the 2374 entire IS-IS packet starting with and including the IS-IS common 2375 header. 2377 The Probe ID field is an arbitrary 48-bit quantity set by the 2378 Intermediate System issuing an MTU-probe and copied by the responding 2379 system into the corresponding MTU-ack. For example, an Intermediate 2380 System creating an MTU-probe could compose this quantity from a port 2381 identifier and probe sequence number relative to that port. 2383 The Probe Source ID is set by an Intermediate system issuing an MTU- 2384 probe to its System ID and copied by the responding system into the 2385 corresponding MTU-ack. 2387 The Ack Source ID is set to zero in MTU-probe PDUs. An Intermediate 2388 System issuing an MTU-ack set this field to its System ID. 2390 The TLV area follows the MTU PDU header area. This area MAY contain 2391 an Authentication TLV and MUST be padded to the size being tested 2392 with the Padding TLV. 2394 3. Acknowledgements 2396 The authors would like to thank Les Ginsberg and Mike Shand for their 2397 useful comments. 2399 4. Security Considerations 2401 This document adds no additional security risks to IS-IS, nor does it 2402 provide any additional security for IS-IS. 2404 5. IANA Considerations 2406 This document creates six new PDU types, namely the MGROUP PDU, 2407 MGROUP-CSNP PDU, the MGROUP-PSNP PDU, TRILL-HELLO-PDU, MTU-PROBE-PDU, 2408 and MTU-ACK-PDU. IANA SHOULD assign a new PDU type to the level-1 2409 PDUs described above and reflect it in the PDU registry. 2411 MGROUP-PDU Level-1 PDU Type: 19 2412 MGROUP-CSNP-PDU Level-1 PDU Type: 22 2413 MGROUP-PSNP-PDU Level-1 PDU Type: 29 2414 TRILL-HELLO-PDU Level-1 PDU Type: 21 2415 MTU-PROBE-PDU Level-1 PDU Type: 23 2416 MTU-ACK-PDU Level-1 PDU Type: 28 2418 This document specifies the definition of a set of new IS-IS TLVs, 2419 the MAC-Reachability TLV (type 141), the Group Address TLV (type 2420 142), the Port-Capability TLV (type 143), the MT-Capability TLV (type 2421 144), and the Trill-Neighbor TLV (type 145), and Group Member Active 2422 Source TLV (type 146) that need to be reflected in the IS-IS TLV 2423 code-point registry. 2425 This document creates a number of new sub-TLVs in the numbering space 2426 for the Group Address TLV, the MT Port Capability TLV, the Extended 2427 Reachability TLV, the MT-Capability TLV, and the Capability TLV. The 2428 TLV and sub-TLVs are given below along with technologies that use 2429 them. 2431 IIH LSP SNP MGROUP MGROUP TRILL/ 2432 LSP SNP IEEE/OTV 2433 MAC-RI TLV (141) - X - - - T/I/O 2435 GADDR-TLV (142) - - - X - T/-/O 2436 GADDR-TLV.GMAC-ADDR sub-TLV 1 - - - X - T/-/O 2437 GADDR-TLV.GMAC-IP sub-TLV 2 - - - X - T/-/O 2438 GADDR-TLV.GMAC-IPV6 sub-TLV 3 - - - X - T/-/O 2440 MT-Port-Cap-TLV (143) X - - - - T/I/O 2441 PortCap.VLAN and Flags sub-TLV 1 X - - - - T/-/- 2442 PortCap.Enabled-VLANs sub-TLV 2 X - - - - T/-/- 2443 PortCap.AppointedFwrdrs sub-TLV 3 X - - - - T/-/- 2444 PortCap.HBHOPT sub-TLV 4 X - - - - T/-/- 2445 PortCap.BaseVLANID sub-TLV 5 X - - - - -/I/- 2446 PortCap.SPBDigest sub-TLV 6 X - - - - -/I/- 2447 PortCap.SiteIdentifier sub-TLV 250 X - - - - -/-/O 2448 PortCap.SiteGroupIP sub-TLV 251 X - - - - -/-/O 2449 PortCap.SiteGroupIPv6 sub-TLV 252 X - - - - -/-/O 2450 PortCap.AdjServerIP sub-TLV 253 X - - - - -/-/O 2451 PortCap.AdjServerIPv6 sub-TLV 254 X - - - - -/-/O 2452 CAPABILITY.Trill-Version sub-TLV 5 - X - - - T/-/- 2453 CAPABILITY.Nickname sub-TLV 6 - X - - - T/-/- 2454 CAPABILITY.Tree sub-TLV 7 - X - - - T/-/- 2455 CAPABILITY.Tree Id sub-TLV 8 - X - - - T/-/- 2456 CAPABILITY.TreeUseRootId sub-TLV 9 - X - - - T/-/- 2457 CAPABILITY.Int-VLANs sub-TLV 10 - - - X - T/-/- 2458 CAPABILITY.VLAN-Groups sub-TLV 11 - X - - - T/-/- 2459 CAPABILITY.ITEOPT sub-TLV 12 - X - - - T/-/- 2460 CAPABILITY.VMAP sub-TLV 13 - X - - - T/-/- 2462 MT-Capability-TLV (144) - X - - - -/I/- 2463 MT-Cap.SPB Instance sub-TLV 1 - X - - - -/I/- 2464 MT-Cap.Opaque Algorithm sub-TLV 2 - X - - - -/I/- 2465 MT-Cap.Service Id. sub-TLV 3 - X - - - -/I/- 2466 MT-Cap.SPBV-MAC-ADDR sub-TLV 4 - X - - - -/I/- 2468 TRILL-Nieghbor TLV (145) X - - - - T/-/- 2470 EXT-IS.SPB Link Metric sub-TLV 5 - X - - - -/I/- 2471 EXT-IS.MTU sub-TLV 6 - X - - - T/-/- 2473 MT-EXT-IS.SPB LinkMetric sub-TLV 5 - X - - - -/I/- 2475 Group Mem Active Source TLV (146) - - - X - -/-/O 2476 GMAS-TLV.GMAS-MAC sub-TLV 1 - - - X - -/-/O 2477 GMAS-TLV.GMAS-IP sub-TLV 2 - - - X - -/-/O 2478 GMAS-TLV.GMAS-IPV6 sub-TLV 3 - - - X - -/-/O 2480 IANA SHOULD manage the remaining space using the IETF Review method 2481 [RFC 5226]. 2483 6. References 2485 6.1. Normative References 2487 [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System 2488 Intra-Domain Routing Exchange Protocol for use in 2489 Conjunction with the Protocol for Providing the 2490 Connectionless-mode Network Service (ISO 8473)", 2005. 2492 [RFC 1195] 2493 Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 2494 Dual Environments", 1990. 2496 [RFC 4971] 2497 Vasseur, JP. and N. Shen, "Intermediate System to 2498 Intermediate System (IS-IS) Extensions for Advertising 2499 Router Information", 2007. 2501 [RFC 5305] 2502 Li, T. and H. Smit, "IS-IS Extensions for Traffic 2503 Engineering", 2008. 2505 [RFC 5306] 2506 Shand, M. and L. Ginsberg, "Restart Signaling for 2507 Intermediate System to Intermediate System (IS-IS)", 2004. 2509 6.2. Informative References 2511 [IEEE 802.1aq] 2512 "Standard for Local and Metropolitan Area Networks / 2513 Virtual Bridged Local Area Networks / Amendment 9: 2514 Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008. 2516 [OTV] Grover, H., Farinacci, D., and D. Rao, "OTV: Overlay 2517 Transport Virtualization", draft-hasmit-otv-00, 2010. 2519 [RBRIDGES] 2520 Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. 2521 Ghanwani, "RBridges: Base Protocol Specification", 2010. 2523 [RFC 1584] 2524 Moy, J., "Multicast Extensions to OSPF", March 1994. 2526 Authors' Addresses 2528 Ayan Banerjee (editor) 2529 Cisco Systems 2530 170 W Tasman Drive 2531 San Jose, CA 95138 2532 US 2534 Email: ayabaner@cisco.com 2536 David Ward 2537 Juniper Networks 2538 1194 N. Mathilda Ave. 2539 Sunnyvale, CA 94089-1206 2540 USA 2542 Phone: +1-408-745-2000 2543 Email: dward@juniper.net 2545 Russ White 2546 Cisco Systems 2547 170 W Tasman Drive 2548 San Jose, CA 95138 2549 US 2551 Email: riw@cisco.com 2553 Dino Farinacci 2554 Cisco Systems 2555 170 W Tasman Drive 2556 San Jose, CA 95138 2557 US 2559 Email: dino@cisco.com 2561 Radia Perlman 2562 Intel Labs 2563 2200 Mission College Blvd. 2564 Santa Clara, CA 95054 2565 US 2567 Phone: +1-408-765-8080 2568 Email: Radia.Perlman@alum.mit.edu 2569 Donald E. Eastlake 3rd 2570 Stellar Switches 2571 155 Beaver Street 2572 Milford, MA 07157 2573 US 2575 Phone: +1-508-333-2270 2576 Email: d3e3e3@gmail.com 2578 Peter Ashwood-Smith 2579 Huawei Technologies Canada Co. Ltd. 2580 411 Legget Drive, Suite 503 2581 Kanta, Ontario K2K 3C9 2582 CANADA 2584 Email: Peter.AshwoodSmith@huawei.com 2586 Don Fedyk 2587 Alcatel-Lucent 2588 220 Hayden Road 2589 Groton, MA 01450 2590 US 2592 Email: Donald.Fedyk@alcatel-lucent.com