idnits 2.17.1 draft-ietf-isis-ieee-aq-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2011) is 4791 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' -- Possible downref: Non-RFC (?) normative reference: ref. 'NLPID' -- Possible downref: Non-RFC (?) normative reference: ref. 'LAYER2' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Fedyk 3 Internet Draft Alcatel-Lucent 4 Intended status: Standards Track P.Ashwood-Smith 5 Expires: September 8, 2011 Huawei 7 March 8, 2011 9 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging 10 draft-ietf-isis-ieee-aq-05.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on August 1st 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 802.1aq Shortest Path Bridging (SPB) is being standardized by the 53 IEEE as the next step in the evolution of the various spanning tree 54 and registration protocols. 802.1aq allows for true shortest path 55 forwarding in a mesh Ethernet network context utilizing multiple 56 equal cost paths. This permits it to support much larger layer 2 57 topologies, with faster convergence, and vastly improved use of the 58 mesh topology. Combined with this is single point provisioning for 59 logical connectivity membership, which includes point-to-point, 60 point-to-multi-point and multi-point-to-multipoint variations. This 61 memo documents the IS-IS changes required to support this IEEE 62 protocol and provides some context and examples. 64 Table of Contents 66 1. Introduction...................................................4 67 2. Terminology....................................................4 68 3. Conventions used in this document..............................5 69 4. 802.1aq Overview...............................................6 70 4.1. Multi Topology Support....................................8 71 4.2. Data Path SPBM - Unicast..................................8 72 4.3. Data Path SPBM - Multicast (Head End Replication).........9 73 4.4. Data Path SPBM - Multicast (Tandem Replication)...........9 74 4.5. Data Path SPBV Broadcast.................................11 75 4.6. Data Path SPBV Unicast...................................12 76 4.7. Data Path SPBV Multicast.................................12 77 5. SPBM Example..................................................12 78 6. SPBV Example..................................................15 79 7. SPB Supported Adjacency types.................................17 80 8. SPB IS-IS adjacency addressing................................17 81 9. IS-IS Area Address and SYSID..................................17 82 10. Level 1/2 Adjacency..........................................17 83 11. Shortest Path Default Tie Breaking...........................17 84 12. Shortest Path ECT............................................18 85 13. Hello (IIH) protocol extensions..............................19 86 13.1. SPB MCID sub-TLV........................................20 87 13.2. SPB Digest sub-TLV......................................21 88 13.3. SPB Base VLAN-Identifiers sub-TLV.......................24 89 14. Node information extensions..................................25 90 14.1. SPB Instance sub-TLV....................................26 91 14.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV..........29 92 15. Adjacency information extensions.............................30 93 15.1. SPB Link Metric sub-TLV.................................30 94 15.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV.........31 95 16. Service information extensions...............................32 96 16.1. SPBM Service Identifier and Unicast Address sub-TLV.....32 97 16.2. SPBV Mac Address sub-TLV................................33 98 17. Security Considerations......................................35 99 18. IANA Considerations..........................................36 100 19. References...................................................37 101 19.1. Normative References....................................37 102 19.2. Informative References..................................38 103 20. Acknowledgments..............................................38 104 21. Author's Addresses...........................................38 105 22. Intellectual Property Statement..............................39 106 23. Disclaimer of Liability......................................40 108 1. Introduction 110 802.1aq Shortest Path Bridging (SPB) [802.1aq] is being standardized 111 by the IEEE as the next step in the evolution of the various 112 spanning tree and registration protocols. 802.1aq allows for true 113 shortest path forwarding in an Ethernet mesh network context 114 utilizing multiple equal cost paths. This permits SPB to support 115 much larger layer 2 topologies, with faster convergence, and vastly 116 improved use of the mesh topology. Combined with this is single 117 point provisioning for logical connectivity membership which 118 includes point-to-point (E-LINE), point-to-multi-point (E-TREE) and 119 multi-point-to-multipoint (E-LAN) variations. 121 The control protocol for 802.1aq is IS-IS [IS-IS] augmented with a 122 small number of TLVs and sub TLVs. This supports two Ethernet 123 encapsulating data paths, 802.1ad (Provider Bridges) [PB] and 124 802.1ah (Provider Backbone Bridges) [PBB]. This memo documents those 125 TLVs while providing some overview. 127 Note that 802.1aq requires no state machine or other substantive 128 changes to [IS-IS]. 802.1aq simply requires a new Network Layer 129 Protocol Identifier (NLPID) and set of TLVs. In the event of 130 confusion between this document and [IS-IS], [IS-IS] should be taken 131 as authoritative. 133 2. Terminology 135 In addition to well understood IS-IS terms, this memo uses 136 terminology from IEEE 802.1 and introduces a few new terms: 138 802.1ad Provider Bridging (PB) - Q-in-Q encapsulation 139 802.1ah Provider Backbone Bridges (PBB), MAC-IN-MAC 140 encapsulation 141 802.1aq Shortest Path Bridging (SPB) 142 Base-VID VID used to identify a VLAN in management operations 143 B-DA Backbone Destination Address 802.1ah PBB 144 B-MAC Backbone MAC Address 145 B-SA Backbone Source address in 802.1ah PBB header 146 B-VID Backbone VLAN ID in 802.1ah PBB header 147 B-VLAN Backbone Virtual LAN 148 BridgeID 64 bit quantity = (Bridge Priority:16)<<48 | SYSID:48 149 BridgePriority 16 bit relative priority of a node for tie breaking 150 C-MAC Customer MAC. Inner MAC in 802.1ah PBB header 151 C-VID Customer VLAN ID 152 C-VLAN Customer Virtual LAN 153 DA Destination Address 154 ECT-ALGORITHM 32 bit unique id of an SPF tie breaking set of rules. 155 ECT-MASK 64 bit mask XORed with BridgeID during tie breaking. 156 E-LAN Bidirectional Logical Connectivity between >2 UNIs. 157 E-LINE Bidirectional Logical Connectivity between two UNIs. 158 E-TREE Asymmetric Logical Connectivity between UNIs. 159 FDB Filtering Database: {DA/VID}->{next hops} 160 I-SID Logical Grouping Identifier for E-LAN/LINE/TREE UNIs. 161 LAN Local Area Network 162 LSDB Link State Database 163 LSP Link State Packet 164 MAC-IN-MAC Ethernet in Ethernet framing as per 802.1ah[PBB] 165 MDT Multicast Distribution Tree 166 MMRP Multiple Mac Registration Protocol 802.1ak[MMRP] 167 MT-ISIS Multi Topology IS-IS as used in [MT] 168 MT Multi Topology. As used in [MT] 169 MT-ID Multi Topology Identifier (12 bits). As used in [MT] 170 NLPID Network Layer Protocol Identifier: IEEE 802.1aq= 0xC1 171 Q-in-Q Additional S-VLAN after a C-VLAN (802.1ad)[PB] 172 PBB Provider Backbone Bridge - forwards using PBB 173 Ingress Check Source Forwarding Check - drops misdirected frames 174 (S,G) Source & Group - identity of a source specific tree 175 (*,G) Any Source & Group - identity of a shared tree 176 SA Source Address. 177 SPB Shortest Path Bridging - generally all of 802.1aq. 178 SPB Shortest Path Bridge - device implementing 802.1aq. 179 SPB-instance Logical SPB instance correlated by MT-ID. 180 SPBM Device implementing SPB MAC mode 181 SPBV Device implementing SPB VID mode 182 SPT Shortest Path Tree computed by one ECT-ALORITHM 183 SPT Region A set of SPBs with identical VID usage on their NNIs 184 SPSourceID 20 bit identifier of the source of multicast frames. 185 SPVID SPBV: a C-VLAN or S-VLAN that identifies the source. 186 UNI User Network Interface: Customer to SPB attach point. 187 VID VLAN ID 12 bit logical identifier after MAC header. 188 VLAN Virtual LAN: A logical network in the control plane 190 3. Conventions used in this document 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 The lower case forms with an initial capital "Must", "Must Not", 197 "Shall", "Shall Not", "Should", "Should Not", "May", and "Optional" 198 in this document are to be interpreted in the sense defined in 200 [RFC2119], but are used where the normative behavior is defined in 201 documents published by SDOs other than the IETF. 203 4. 802.1aq Overview 205 This section provides an overview of the behavior of [802.1aq] and 206 is not intended to be interpreted as normative text. For the 207 definitive behavior the reader should consult [802.1aq]. Nonetheless 208 lower case forms with initial capitalization of the conventions in 209 RFC2119 are used in this section to give the reader an indication of 210 the intended normative behaviors as above. 212 802.1aq utilizes 802.1Q based Ethernet bridging. The filtering 213 database (FDB) is populated as a consequence of the topology 214 computed from the IS-IS database. For the reader unfamiliar with 215 IEEE terminology, the definition of Ethernet behavior is almost 216 entirely in terms of "filtering" (of broadcast traffic) rather than 217 "forwarding" (the explicit direction of unicast traffic). This 218 document uses the generic term "forwarding", and it has to be 219 understood that these two terms simply represent different ways of 220 expressing the same behaviors. 222 802.1aq supports multiple modes of operation depending on the type 223 of data plane and the desired behavior. For the initial two modes of 224 802.1aq (SPBV and SPBM), routes are shortest path, are forward and 225 reverse path symmetric with respect to any source / destination pair 226 within the SPB domain, and are congruent with respect to unicast and 227 multicast. Hence the shortest path tree (SPT) to a given node is 228 congruent with the multicast distribution tree (MDT) from a given 229 node. The MDT for a given VLAN is a pruned subset of the complete 230 MDT for a given node which is identical to its SPT. Symmetry and 231 congruency preserve packet ordering and proper fate sharing of OAM 232 flows by the forwarding path. Such modes are fully supported by 233 existing [802.1ag] and [Y.1731] OA&M mechanisms. 235 VLANs provide a natural delineation of service instances. 802.1aq 236 supports two modes, SPB VID (SPBV) and SPB MAC (SPBM). In SPBV 237 multiple VLANS can be used to distribute load on different shortest 238 path trees (each computed by a different tie breaking rule) on a 239 service basis. In SPBM service instances are delineated by I-SIDs 240 but VLANs again can be used to distribute load on different shortest 241 path trees. 243 There are two encapsulation methods supported. SPBM can be used in a 244 PBB network implementing PBB (802.1ah [PBB]) encapsulation. SPBV can 245 be used in PB networks implementing VLANs, PB (802.1aq [PB]) or PBB 246 encapsulation. The two modes can co-exist simultaneously in an SPB 247 network. 249 The practical design goals for SPBV and SPBM in the current 802.1aq 250 specification are networks of size 100 nodes and 1000 nodes 251 respectively. However since SPBV can be sparsely used in an SPB 252 Region it can simply span a large SPB region with a small number of 253 SPVIDs. 255 In SPBM and SPBV each bridge has at least one unique "known" MAC 256 address which is advertised by IS-IS in the SYS-ID. 258 In the forwarding plane, SPBM uses the combination of one or more B- 259 VIDs and "known" Backbone-MAC (B-MAC) addresses that have been 260 advertised in IS-IS. The term Backbone simply implies an 261 encapsulation that is often used in the backbone networks, but the 262 encapsulation is useful in other types of networks where hiding C- 263 MACs is useful. 265 The SPBM filtering database (FDB) is computed and installed for 266 unicast and multicast MAC addresses, while the SPBV filtering 267 database is computed and installed for unidirectional VIDs (referred 268 to as SPVIDs), after which MAC reachability is learned (exactly as 269 in bridged Ethernet) for unicast MACs. 271 Both SPBV and SPBM use source specific multicast trees. If they 272 share the same ECT-ALGORITHM (32 bit world wide unique definition of 273 the computation) the tree is the same SPT. For SPBV (S,G) is encoded 274 by a source-specific VID (the SPVID) and a standard Group MAC 275 address. For SPBM (S,G) is encoded in the destination B-MAC address 276 as the concatenation of a 20 bit SPB wide unique nodal nickname 277 (referred to as the SPSourceID) and the 24 bit I-SID together with 278 the B-VID which corresponds to the ECT-ALGORITHM network wide. 280 802.1aq supports membership attributes which are advertised with the 281 I-SID (SPBM) or Group Address (SPBV) that define the group. 282 Individual members can be transmitters (T) and/or receivers (R) 283 within the group and the multicast state is appropriately sized to 284 these requests. Multicast group membership is possible even without 285 transmit membership by performing head end replication to the 286 receivers thereby eliminating transit multicast state entirely. 288 Some highly connected mesh networks provide for path diversity by 289 offering multiple equal cost alternatives between nodes. Since 290 congruency and symmetry Must be honored, a single tree may leave 291 some links under utilized. By using different deterministic tie 292 breakers, up to sixteen shortest paths of arbitrary diversity are 293 possible between any pair of nodes. This distributes the traffic on 294 a VLAN basis. SPBV and SPBM May share a single SPT with a single 295 ECT-ALGORITHM or use any combination of the 16 ECT-ALGORITHMs. An 296 extensible framework permits additional or alternative algorithms 297 with other properties and parameters (e.g. ECMP, (*,G) ) to also be 298 supported without any changes in this or the IEEE documents. 300 4.1. Multi Topology Support 302 SPB incorporates the multi topology features of [MT] thereby 303 allowing multiple logical SPB instances within a single IS-IS 304 instance. 306 To accomplish this, all SPB related information is either explicitly 307 or implicitly associated with a Multi Topology Identifier (MT-ID). 308 SPB information related to a given MT-ID thus forms a single logical 309 SPB instance. 311 Since SPB has its own adjacency metrics and those metrics are also 312 associated with an MT-ID it is not only possible to have different 313 adjacency metrics (or infinite metrics) for SPB adjacencies, 314 distinct from IP or other NLPIDs riding in this IS-IS instance, and 315 also distinct from those used by other SPB instances in the same IS- 316 IS instance. 318 Data plane traffic for a given MT-ID is intrinsically isolated by 319 the VLANs assigned to the SPB instance in question. Therefore VLANs 320 (represented by VIDs in TLVs and data plane) Must Not overlap 321 between SPB instances (regardless of how the control planes are 322 isolated). 324 The [MT] mechanism when applied to SPB allows different routing 325 metrics and topology subsets for different classes of services. 327 The use of [MT] other than the default MT-ID#0 is completely 328 OPTIONAL. 330 The use of [MT] to separate SPB from other NLPIDs is also OPTIONAL. 332 4.2. Data Path SPBM - Unicast 334 Unicast frames in SPBM are encapsulated as per 802.1ah [PBB]. A 335 Backbone Source Address (B-SA), Backbone Destination Address (B-DA), 336 Backbone VLAN ID (B-VID) and an I-Component Service Instance ID (I- 337 TAG) are used to encapsulate the Ethernet frame. The B-SA is a B-MAC 338 associated with the ingress 802.1aq bridge, usually the "known" B- 339 MAC of that entire bridge. The B-DA is one of the "known" B-MACs 340 associated with the egress 802.1aq bridge. The B-VID and I-TAG are 341 mapped based on the physical or logical UNI port (untagged, or 342 tagged either by S-TAG or C-TAG) being bridged. Normal learning and 343 broadcast to unknown C-MACs is applied as per [PBB] at the 344 ingress/egress SPBs only. 346 Unlike [PBB] on a (*,G) tree, the B-DA forwarding on tandem nodes 347 (NNI to NNI) is performed without learning. Instead the output of 348 802.1aq computations, based on the TLVs specified in this document, 349 are used to populate the filtering data bases (FDB). The FDB entries 350 map {B-DA, B-VID} to an outgoing interface and are only populated 351 from the IS-IS database and computations. 353 The B-SA/B-VID is checked on tandem nodes against the ingress port. 354 If the B-SA/B-VID (as a destination) entry in the FDB does not point 355 to the port on which the packet arrived the packet is discarded. 356 This is referred to as an Ingress Check and serves as a very 357 powerful loop mitigation mechanism. 359 4.3. Data Path SPBM - Multicast (Head End Replication) 361 Head end replication is supported for instances where there is a 362 sparse community of interest or a low likelihood of multicast 363 traffic. Head end replication requires no Multicast state in the 364 core. A UNI port wishing to use head end replication Must Not 365 advertise its I-SID membership with the TX bit set but instead Must 366 locally and dynamically construct the appropriate unicast serial 367 replication to all the other receivers (RX) of the same I-SID. 369 When an unknown customer unicast or a multicast frame arrives at an 370 SPBM User to Network Interface (UNI) port which has been configured 371 to replicate only at the head end the packet is replicated once for 372 each receiver, encapsulated and sent as a unicast frame. The set of 373 receivers is determined by inspecting the IS-IS database for other 374 SPBs that have registered interest in the same I-SID with the RX 375 (receive) attribute set. This RX/I-SID pair is found in the SPBM 376 Service Identifier and Unicast Address sub-TLV. The packets are 377 encapsulated as per the SPBM Unicast forwarding above. 379 4.4. Data Path SPBM - Multicast (Tandem Replication) 381 Tandem replication uses the Shortest path Tree to replicate Frames 382 only where the tree forks and there is at least one receiver on each 383 branch. Tandem replication is bandwidth efficient but uses multicast 384 FDB entries (state) in core bridges which might be unnecessary if 385 there is little multicast traffic demand. The head end replication 386 mode is best suited for the case where there is little or no true 387 multicast traffic for an I-SID. Tandem replication is triggered on 388 transit nodes when the I-SID is advertised with the TX bit set. 390 Broadcast, unknown unicast or multicast frames arriving at an SPBM 391 UNI port are encapsulated with a B-DA multicast address which 392 uniquely identifies the encapsulating node (the root of the 393 Multicast Distribution Tree) and the I-SID scoping this multicast. 395 This B-DA address is a well formed multicast group address (as per 396 802.1Q and 802.1ah) which concatenates the SPSourceID A' with the I- 397 SID M (written as DA= and uniquely identifying the (S,G) 398 tree). This exact format is given in Figure 1 below: 400 M L TYP 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 |1|1|0|0|SPSrcMS| SPSrc [8:15] | SPSrc [0:7] | ISID [16:23] | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | ISID [8:15] | ISID [0:7] | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 Figure 1 SPBM Multicast Address format 408 (SPSrcMS represents SPSrc [16:19]) 410 Note In Figure 1, the index numbering from less significant bit to 411 more significant bit within a byte or field within a byte gives 412 the wire order of the bits in the address consistent with the IETF 413 format in the rest of this document. (The IEEE convention for 414 number representation reverses the bits within an octet compared 415 with IETF practice). 417 o M is the multicast bit- always set to 1 for a multicast DA. (It 418 is the lowest bit in the most significant byte.) 420 o L is the local bit- always set to 1 for a SPBM constructed 421 multicast DA. 423 o TYP is the SPSourceID type. 00 is the only type supported at this 424 time. 426 o SPSRC (SPSourceID) is a 20 bit quantity that uniquely identifies 427 a SPBM node for all B-VIDs allocated to SPBM operation. This is 428 just the SPSourceID advertised in the SPB Instance sub-TLV. The 429 value SPSourceID = 0 has special significance; it is advertised 430 by an SPBM node which has been configured to assign its 431 SPSourceID dynamically, which requires LSDB synchronization, but 432 where the SPSourceID assignment has not yet completed. 434 o I-SID is the 24 bit I component Service ID advertised in the SPBM 435 Service Identifier TLV. It occupies the lower 24 bits of the SPBM 436 multicast DA. The I-SID value 0xfff is reserved for SPBM control 437 traffic(refer to the default I-SID in [802.1aq]). 439 This multicast address format is used as the DA on frames when they 440 are first encapsulated at ingress to the SPBM network. The DA is 441 also installed into the FDBs on all SPBM nodes that are on the 442 corresponding SPT between the source and other nodes that have 443 registered receiver interest in the same I-SID. 445 Just as with unicast forwarding, the B-SA/B-VID May be used to 446 perform an ingress check, but the SPSourceID encoded in the DA and 447 the "drop-on-unknown" functionality of the FDB in [PBB] achieve the 448 same effect. 450 The I-Component at the egress SPBM device has completely standard 451 [PBB] behavior and therefore will: 453 1) learn the remote C-SA to B-SA relationship and 454 2) bridge the original customer frame to the set of local UNI ports 455 that are associated with the I-SID. 457 4.5. Data Path SPBV Broadcast 459 When a packet for an unknown DA arrives at a SPBV UNI port VID 460 translation (or VID encapsulation for un-tagged Frames) with the 461 corresponding SPVID for this VLAN and ingress SPB is performed. 463 SPVID forwarding is simply an SPT that follows normal VLAN 464 forwarding behavior, with the exception that the SPVID is 465 unidirectional. As a result shared learning (SVL) is used between 466 the forward and reverse path SPVIDs associated with the same Base- 467 VID to allow SPBV unicast forwarding to operate in the normal 468 reverse learning fashion. 470 Ingress check is done by simply verifying that the bridge to which 471 the SPVID has been assigned is indeed "shortest path" reachable over 472 the link over which the packet tagged with that SPVID arrived. This 473 check is computed from the IS-IS database and is implied when the 474 SPVID is associated with a specific incoming port. 476 4.6. Data Path SPBV Unicast 478 Conversely when a packet for a known DA arrives at a SPBV UNI port 479 VID translation (or VID encapsulation for un-tagged Frames) with the 480 corresponding SPVID for this VLAN and ingress SPB is performed. 482 Since the SPVID will have been configured to follow a source 483 specific SPT and the DA is known the packet will follow the source 484 specific path towards the destination C-MAC. 486 Ingress check is as per the previous SPBV section. 488 4.7. Data Path SPBV Multicast 490 C-DA multicast addresses May be advertised from SPBV UNI ports. 491 These may be configured or learned through MMRP. The MMRP protocol 492 is terminated at the edge of the SPBV network and IS-IS carries the 493 multicast addresses. Tandem SPBV devices will check to see if they 494 are on the SPF tree between SPBV UNI ports advertising the same C-DA 495 multicast address, and if so will install multicast state to follow 496 the SPBV SPF trees. 498 Ingress check is as per the previous two SPBV sections. 500 5. SPBM Example 502 Consider the following small example network shown in Figure 2. 503 Nodes are drawn in boxes with the last nibble of their B-MAC address 504 :1..:7, the rest of the B-MAC address nibbles are 4455-6677-00xx. 505 Links are drawn as -- and / while the interface indexes are drawn as 506 numbers next to the links. UNI ports are shown as <==> with the 507 desired I-SID show at the end of the UNI ports as i1. 509 +----+ +----+ 510 | :4 | 2 ------1 | :5 | <==> i1 511 +----+ +----+ 512 1 3 3 2 513 / \ / \ 514 1 4 3 2 515 +----+ +----+ +----+ 516 i1 <==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> i1 517 +----+ +----+ +----+ 518 3 6 5 3 519 \ / \ / 520 3 2 1 2 521 +----+ +----+ 522 | :6 | 1-------3 | :7 | <==> i1 523 +----+ +----+ 525 Figure 2 - SPBM Example 7 node network 527 Using the default ECT-ALGORITHM (00-80-C2-01), which picks the equal 528 cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned 529 to B-VID 100. When all links have the same cost, then the 1 hop 530 shortest paths are all direct and the 2 hop shortest paths (which 531 are of course symmetric) are as follows: 533 { 1-2-3, 1-2-5, 1-2-7, 6-2-5, 534 4-2-7, 4-1-6, 5-2-7, 6-2-3, 4-2-3 } 536 Node :1's Unicast forwarding table therefore routes toward B-MACs 537 :7, :3 and :5 via interface/2 while its single hop paths are all 538 direct as can be seen from its FDB given in Figure 3. 540 Node :1 originates multicast since it is at the head of the MDT to 541 nodes :3, :5 and :7 and is a transmitter of I-SID 1 which nodes :3, 542 :5 and :7 all wish to receive. Node :1 therefore produces a 543 multicast forwarding entry who's DA contains its SPSourceID (in the 544 example the last 20 bits of the B-MAC) and the I-SID 1 and sends to 545 interface 2 with B-VID=100. Node :1's full unicast(U) and 546 multicast(M) table is shown in Figure 3. Note that the IN/IF 547 (incoming interface) field is not specified for unicast traffic and 548 for multicast traffic has to point back to the root of the tree, 549 unless it is the head of the tree in which case we use the 550 convention if/OO. Since Node :1 is not transit for any multicast it 551 only has a single entry for the root of its tree for I-SID=1. 553 +-------+-------------------+------+-----------------+ 554 | IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) | 555 +-------+-------------------+------+-----------------+ 556 U| if/** | 4455-6677-0002 | 0100 | {if/2 } 557 U| if/** | 4455-6677-0003 | 0100 | {if/2 } 558 U| if/** | 4455-6677-0004 | 0100 | {if/1 } 559 U| if/** | 4455-6677-0005 | 0100 | {if/2 } 560 U| if/** | 4455-6677-0006 | 0100 | {if/3 } 561 U| if/** | 4455-6677-0007 | 0100 | {if/2 } 562 M| if/00 | 7300-0100-0001 | 0100 | {if/2 } 564 Figure 3 - SPBM Node :1 FDB - Unicast(U) and Multicast(M) 566 Node :2, being at the center of the network, has direct 1 hop paths 567 to all other nodes, therefore its unicast FDB simply sends packets 568 with the given B-MAC/B-VID=100 to the interface directly to the 569 addressed node. This can be seen by looking at the unicast entries 570 (the first 6) shown in Figure 4. 572 +-------+-------------------+------+-----------------+ 573 | IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) | 574 +-------+-------------------+------+-----------------+ 575 U| if/** | 4455-6677-0001 | 0100 | {if/1 } 576 U| if/** | 4455-6677-0003 | 0100 | {if/2 } 577 U| if/** | 4455-6677-0004 | 0100 | {if/4 } 578 U| if/** | 4455-6677-0005 | 0100 | {if/3 } 579 U| if/** | 4455-6677-0006 | 0100 | {if/6 } 580 U| if/** | 4455-6677-0007 | 0100 | {if/5 } 581 M| if/01 | 7300-0100-0001 | 0100 | {if/2,if/3,if/5 } 582 M| if/02 | 7300-0300-0001 | 0100 | {if/1 } 583 M| if/03 | 7300-0500-0001 | 0100 | {if/1,if/5 } 584 M| if/05 | 7300-0700-0001 | 0100 | {if/1,if/3 } 586 Figure 4 - SPBM Node :2 FDB Unicast(U) and Multicast(M) 588 Node :2's multicast is more complicated since it is a transit node 589 for the 4 members of I-SID=1, therefore it requires 4 multicast FDB 590 entries depending on which member it is forwarding/replicating on 591 behalf of. For example, node :2 is on the shortest path between each 592 of nodes {:3,:5,:7} and :1. So it must replicate from node :1 I-SID 593 1 out on interfaces 2, 3 and 5 (to reach nodes :3, :5 and :7). It 594 therefore creates a multicast DA with the SPSourceID of node :1 595 together with I-SID=1 which it expects to receive over interface/1 596 and will replicate out interfaces/{2, 3 and 5}. This can be seen in 597 the first multicast entry in Figure 4. 599 Note that node :2 is not on the shortest path between nodes :3 and 600 :5 nor between nodes :3 and :7, however it still has to forward 601 packets to node :1 from node :3 for this I-SID, which results in the 602 second multicast forwarding entry in Figure 4. Likewise for packets 603 originating at nodes 5 or 7, node :2 only has to replicate twice, 604 which results in the last two multicast forwarding entries in Figure 605 4. 607 6. SPBV Example 609 Using the same example network as Figure 2, we will look at the FDBs 610 produced for SPBV mode forwarding. Nodes :1, :5, :3 and :7 wish to 611 transmit and receive the same multicast MAC traffic using multicast 612 address 0300-0000-000f and at the same time require congruent and 613 symmetric unicast forwarding. In SPBV mode the only encapsulation is 614 the C or S-TAG and the MAC addresses SA,DA are reverse-path learned, 615 as in traditional bridging. 617 +----+ +----+ 618 | :4 | 2 ------1 | :5 | <==> MMAC ..:f 619 +----+ +----+ 620 1 3 3 2 621 / \ / \ 622 1 4 3 2 623 +----+ +----+ +----+ 624 MMAC<==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> MMAC ..:f 625 ..:f +----+ +----+ +----+ 626 3 6 5 3 627 \ / \ / 628 3 2 1 2 629 +----+ +----+ 630 | :6 | 1-------3 | :7 | <==> MMAC ..:f 631 +----+ +----+ 633 Figure 5 - SPBV Example 7 node network 635 Assuming the same ECT-ALGORITHM (00-80-C2-01), which picks the equal 636 cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned 637 to Base-VID 100, and for each node the SPVID = Base-VID + Node Id 638 (i.e. 101, 102..107). When all links have the same cost, then the 1 639 hop shortest paths are all direct and the 2 hop shortest paths 640 (which are of course symmetric) are as previously given for Figure 641 2. 643 Node :1's SPT (Shortest Path Tree) for this ECT-ALGORITHM is 644 therefore (described as a sequence of unidirectional paths): 646 { 1->4, 1->6, 1->2->3, 1->2->5, 1->2->7 } 648 The FDBs therefore must have entries for the SPVID reserved for 649 packets originating from node :1 which in this case is VID=101. 651 Node :2 therefore has a FDB which looks like Figure 6. In particular 652 it takes packets from VID 101 on interface/01 and sends to nodes :3, 653 :5 and :7 via if/2, if/3 and if/5. It does not replicate anywhere 654 else because the other nodes :4 and :6 are reached by the SPT 655 directly from node :1. The rest of the FDB unicast entries follow a 656 similar pattern; recall that the shortest path between :4 and :6 is 657 via node :1, which explains replication onto only two interfaces 658 from if/4 and if/6. Note that the destination addresses are wild 659 cards and shared VLAN learning (SVL) exists between these SPVIDs, 660 because they are all associated with BASE VID = 100, which defines 661 the VLAN being bridged. 663 +-------+-------------------+------+-----------------+ 664 | IN/IF | DESTINATION ADDR | VID | OUT/IF(s) | 665 +-------+-------------------+------+-----------------+ 666 U| if/01 | ************** | 0101 | {if/2,if/3,if/5 } 667 U| if/02 | ************** | 0103 | {if/1,if/4,if/6 } 668 U| if/04 | ************** | 0104 | {if/2,if/5 } 669 U| if/03 | ************** | 0105 | {if/1,if/5,if/6 } 670 U| if/06 | ************** | 0106 | {if/2,if/3 } 671 U| if/05 | ************** | 0107 | {if/1,if/3,if/4 } 673 Figure 6 - SPBV Node :2 FDB unicast 675 Now, since nodes :5, :3, :7 and :1 are advertising membership in the 676 same multicast group address :f, Node 2 requires additional entries 677 to replicate just to these specific nodes for the given multicast 678 group address. These additional multicast entries are given below in 679 Figure 7. 681 +-------+-------------------+------+-----------------+ 682 | IN/IF | DESTINATION ADDR | VID | OUT/IF(s) | 683 +-------+-------------------+------+-----------------+ 684 M| if/01 | 0300-0000-000f | 0101 | {if/2,if/3,if/5 } 685 M| if/02 | 0300-0000-000f | 0103 | {if/1 } 686 M| if/03 | 0300-0000-000f | 0105 | {if/1,if/5 } 687 M| if/05 | 0300-0000-000f | 0107 | {if/1,if/3 } 689 Figure 7 - SPBV Node :2 FDB Multicast(M) 691 7. SPB Supported Adjacency types 693 IS-IS for SPB currently only supports P2P adjacencies. Other link 694 types are for future study. As a result pseudonodes and links 695 to/from pseudonodes are not considered as part of the IS-IS SPF 696 computations and will be avoided if present in the physical 697 topology. Other NLPIDs MAY of course use them as per normal. 699 IS-IS for SPB Must use the IS-IS Three-Way handshake for IS-IS 700 Point-to-Point Adjacencies described in RFC 5303. 702 8. SPB IS-IS adjacency addressing 704 The default behavior of 802.1aq is to use the normal IS-IS Ethernet 705 multicast addresses for IS-IS. 707 There are however additional Ethernet multicast addresses that have 708 been assigned for 802.1aq for special use cases. These do not in 709 anyway change the state machinery or packet formats of IS-IS but 710 simply recommend and reserve different multicast addresses. Refer to 711 [802.1aq] for additional details. 713 9. IS-IS Area Address and SYSID 715 A stand-alone implementation (supporting ONLY the single NLPID=0xC1) 716 of SPB Must use an IS-IS area address value of 0 and the SYSID Must 717 be the well known MAC address of the SPB device. 719 Non stand-alone implementations (supporting other NLPIDs) MUST use 720 the normal IS-IS rules for the establishment of a level 1 domain 721 (i.e. multiple area addresses are allowed but where immediate 722 adjacencies share a common area address). Level 2 operations of 723 course place no such restriction on adjacent area addresses. 725 10. Level 1/2 Adjacency 727 SPBV and SPBM will operate either within an IS-IS level 1, or an 728 ISIS level 2. As a result, the TLVs specified here MAY propagate 729 either in level 1 or level 2 LSPs. IS-IS SPB implementations Must 730 support level 1 and May support level 2 operations. Hierarchical SPB 731 is for further study therefore these TLV's Should Not be leaked 732 between level 1 and level 2. 734 11. Shortest Path Default Tie Breaking 736 (ECT-ALGORITHM = 00-80-C2-01) 737 Two mechanisms are used to ensure symmetry and determinism in the 738 shortest path calculations. 740 The first mechanism addresses the problem when different ends 741 (nodes) of an adjacency advertise different values for the SPB-LINK- 742 METRIC. To solve this SPB shortest path calculations Must use the 743 maximum value of the two node's advertised SPB-LINK-METRICs when 744 accumulating and minimizing the (sub)path costs. 746 The second mechanism addresses the problem when two equal sums of 747 link metrics (sub)paths are found. To solve this, the (sub)path with 748 the fewest hops between the fork/join points Must win the tie. 749 However, if both (sub)paths have the same number of hops between the 750 fork and join points then the default tie breaking Must pick the 751 path traversing the intermediate node with the lower BridgeID. The 752 BridgeID is an 8 byte quantity whose upper 2 bytes are the node's 753 BridgePriority and the lower 6 bytes are the node's SYSID. 755 For example, consider the network in Figure 2 when a shortest path 756 computation is being done from node :1. Upon reaching node :7 two 757 competing sub-paths fork at node :1 and join at node :7. The first 758 via :2 and the second via :6. Assuming that all the nodes advertise 759 a Bridge Priority of 0, the default tie breaking rule causes the 760 path traversing node :2 to be selected since it has a lower BridgeID 761 {0...:2} than node :6 {0...:6}. Note that the operator may cause the 762 tie breaking logic to pick the alternate path by raising the Bridge 763 Priority of node :2 above that of node :6. 765 The above algorithm guarantees symmetric and deterministic results 766 in addition to having the critical property of transitivity 767 (shortest path is made up of sub-shortest paths). 769 12. Shortest Path ECT 771 (ECT-ALGORITHMs = 00-80-C2-01 .. 00-80-C2-10) 772 To create diversity in routing SPB defines 16 variations on the 773 above default tie breaking algorithm, these have world wide unique 774 designations 00-80-C2-01 through 00-80-C2-10. These designations 775 consist of the IEEE 802.1 OUI value 00-80-C2 concatenated with 776 indexes 0X01..0X10. These individual algorithms are implemented by 777 selecting the (sub) path with the lowest value of: 779 XOR BYTE BY BYTE(ECT-MASK{ECT-ALGORITHM.index},BridgeID) 781 Where: 783 ECT-MASK{17} = { 0x00, 0x00, 0xFF, 0x88, 784 0x77, 0x44, 0x33, 0xCC, 785 0xBB, 0x22, 0x11, 0x66, 786 0x55, 0xAA, 0x99, 0xDD, 787 0xEE }; 789 XOR BYTE BY BYTE - XORs BridgeID bytes with ECT-MASK 791 ECT-MASK{1} since it xor's with all 0's is just the same as the 792 default algorithm described above 00-80-C2-01, while ECT-MASK{0x02} 793 since it xor's with a mask of all 1's will invert the BridgeID 794 essentially picking the path traversing the largest Bridge ID. The 795 other ECT-MASKs produce diverse alternatives. In all cases the 796 BridgePriority, since it is the most significant part of the 797 BridgeID permits overriding the SYSID as the selection criteria and 798 gives the operator a degree of control on the chosen ECT paths. 800 To support many other tie breaking mechanisms in the future two 801 opaque ECT TLV's are defined which may be used to provide parameters 802 to ECT-ALGORITHMS outside of the currently defined space. 804 ECT-ALGORITHMS are mapped to VIDs and then services can be assigned 805 to those VIDs. This permits a degree of traffic engineering since 806 service assignment to VID is consistent end to end through the 807 network. 809 13. Hello (IIH) protocol extensions 811 IEEE 802.1aq can run in parallel with other Network Layer Protocols 812 such as IPV4 and IPV6, therefore failure for two SPB nodes to 813 establish an adjacency MUST NOT cause rejection of an adjacency for 814 the purposes of other Network Layer Protocols. 816 IEEE 802.1aq has been assigned the NLPID value 0xC1 [NLPID] which 817 MUST be used by shortest path bridges (SPBs) to indicate their 818 ability to run 802.1aq. This is done by including this NLPID value 819 in the IS-IS IIH PDU Protocols Supported TLV (type 129). 802.1aq 820 frames MUST only flow on adjacencies that advertise this NLPID in 821 both directions of the IIH PDUs. 802.1aq computations MUST consider 822 an adjacency that has not advertised 0xC1 NLPID in both directions 823 as non-existent (infinite link metric) and MUST ignore any IIH SPB 824 TLV's they receive over such adjacencies. 826 IEEE 802.1aq augments the normal IIH PDU with three new TLV's which 827 like all other SPB TLVs travel within multi topology [MT] TLVs, 828 therefore allowing multiple logical instances of SPB within a single 829 IS-IS protocol instance. 831 Since SPB can use many VIDs and Must agree on which VIDs are used 832 for which purposes, the IIH PDU's carry a digest of all the used 833 VIDs (on the NNI's) referred to as the SPB-MCID TLV which uses a 834 common and compact encoding taken reused from 802.1Q. 836 SPB neighbors May support a mechanism to verify that the contents of 837 their topology databases are synchronized (for the purposes of loop 838 prevention). This is done by exchanging a digest of SPB topology 839 information (computed over all MTIDS) and taking specific actions on 840 forwarding entries when the digests indicate a mismatch in topology. 841 This digest is carried in the Optional SPB Digest sub-TLV. 843 Finally SPB needs to know which SPT sets (defined by ECT-ALGORITHMS) 844 are being used by which VIDs, and this is carried in the Base VLAN 845 Identifiers sub-TLV. 847 13.1. SPB MCID sub-TLV 849 This sub-TLV is added to an IIH PDU to indicate the digest for the 850 Multiple spanning tree configuration a.k.a MCID. This TLV is a 851 digest of local configuration of which VIDs are running which 852 protocols. (The information is not to the level of a specific 853 algorithm in the case of SPB). This information Must be the same on 854 all bridges in the SPT Region controlled by an IS-IS instance. The 855 data used to generate the MCID is populated by configuration and is 856 a digest of the VIDs allocated to various protocols. Two MCIDs are 857 carried to allow non disruptive transitions between configurations 858 when the changes are non-critical. 860 0 1 2 3 861 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 863 +-+-+-+-+-+-+-+-+ 864 |Type=SPB-MCID | = 6 865 +-+-+-+-+-+-+-+-+ 866 | Length | (1 byte) 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | MCID (51 Bytes) | 869 | ............... | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Aux MCID (51 Bytes) | 872 | ............... | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 o Type: sub-TLV Type = 6 (Pending IANA). 877 o Length: The size of the value defined below (102). 879 o MCID (51-bytes) The complete MCID defined in IEEE 802.1Q which 880 identifies an SPT Region on the basis of matching assignments of 881 VIDs to control regimes (xSTP, SPBV, SPBM, etc). Briefly, the 882 MCID consists of a 1 byte format selector, a 32 byte 883 configuration name, a 2 byte revision level and finally a 16 byte 884 signature of type HMAC-MD5 over an array of 4096 elements that 885 contain identifiers of the use of the corresponding VID. Refer to 886 section 13.8 of [802.1aq] for the exact format and procedure. 887 Note that the use of the VID does not include specification of a 888 specific SPB ECT-ALGORITHM, rather it is coarser grain. 890 o Aux MCID (51-bytes) The complete MCID defined in IEEE 802.1Q 891 which identifies an SPT Region. The aux MCID allows SPT Regions 892 to be migrated by the allocation of new VLAN to FDB Mappings 893 without interruption to existing traffic. 895 The SPB MCID sub-TLV is carried within the MT-Port-Cap TLV [LAYER2] 896 with the MT-ID value of 0, which in turn is carried in an IIH PDU. 898 13.2. SPB Digest sub-TLV 900 This sub-TLV is Optionally added to an IIH PDU to indicate the 901 current SPB topology digest value. It is always carried in an MT- 902 Port-Cap TLV [LAYER2] with an MT-ID value of 0. This information 903 should settle to be the same on all bridges in an unchanging 904 topology. Matching digests indicate (with extremely high 905 probability) that the topology view between two SPBs is 906 synchronized, and is used to control the updating of forwarding 907 information. The SPB Agreement Digest is computed based on 908 contributions derived from the current topologies of all SPB MT 909 instances, and is designed to change when significant topology 910 changes occur within any SPB instance. 912 During the propagation of LSPs the Agreement Digest may vary between 913 neighbors until the key topology information in the LSPs are common. 914 The digest is therefore a summarized means of determining agreement 915 between nodes on database commonality, and hence infer agreement on 916 the distance to all multicast roots. When present it is used for 917 loop prevention as follows: For each shortest path tree where it 918 has been determined the distance to the root has changed, "unsafe" 919 multicast forwarding is blocked until the exchanged Agreement 920 Digests match while "safe" multicast forwarding is allowed to 921 continue despite the disagreement in digests and hence topology 922 views. [802.1aq] section 28.2 defines in detail what constitutes 923 "safe" vs. "unsafe". 925 0 1 2 3 926 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 928 +-+-+-+-+-+-+-+-+ 929 |Type=SPB-Digest| = 7 930 +-+-+-+-+-+-+-+-+ 931 | Length | (1 byte) 932 +-----+-+---+---+ 933 | Res |V| A | D | (1 byte) 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Agreement Digest (Length - 1) | 936 | ............... | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 o Type: sub-TLV Type = 7 (Pending IANA). 941 o Length: The size of the value. 943 o V - agreed digest valid bit. See [802.1aq] Sec 28.2. 945 o A (2 bits) The Agreement Number 0-3 which aligns with BPDUs 946 Agreement Number concept [802.1aq]. When the Agreement Digest 947 for this node changes this number is incremented. The node then 948 checks for Agreement Digest match (as below). The new local 949 Agreement Number and the updated local Discarded Agreement Number 950 are then transmitted with the new Agreement Digest to the node's 951 neighbors in the hello PDU. Once an Agreement Number has been 952 sent it is considered outstanding until a matching or more recent 953 Discarded Agreement Number is received from the neighbor. 955 o D (2 bits) The Discarded Agreement Number 0-3 which aligns with 956 BPDUs Agreement Number concept. When an Agreement Digest is 957 received from a neighbor, this number is set to the received 958 Agreement Number, to signify that this node has received this new 959 agreement and discarded any previous ones. The node then checks 960 whether the local and received Agreement Digests match. If they 961 do, this node then sets : 963 the local Discarded Agreement Number = received Agreement 964 Number + 1 966 If the Agreement Digests match, AND 967 received Discarded Agreement Number == local Agreement Number 968 + N (N = 0 || 1) 970 then the node has a topology matched to its neighbor. 972 Whenever the local Discarded Agreement Number relating to a 973 neighbor changes, the local Agreement Digest, Agreement Number, 974 and Discarded Agreement Number are transmitted. 976 o Agreement Digest. This digest is used to determine when SPB is 977 synchronized between neighbors for all SPB instances. The 978 agreement digest is a hash computed over the set of all SPB 979 adjacencies in all SPB instances. In other words, the digest 980 includes all VIDs and all adjacencies for all MT instances of SPB 981 (but not other network layer protocols). This reflects the fact 982 that all SPB nodes in a region Must have identical VID 983 allocations (see 13.1), and so all SPB instances will contain the 984 same set of nodes. The size and exact procedure for computing the 985 Agreement Digest is defined in section 28.2 of [802.1aq]. 987 The SPB Digest sub-TLV is carried within the MT-Port-Cap TLV 988 [LAYER2] (with the MT-ID value 0) which in turn is carried in an IIH 989 PDU. 991 When supported, this sub-TLV MUST be carried on every IIH between 992 SPB neighbors, not just when a Digest changes. 994 When one peer supports this TLV and the other does not, loop 995 prevention by digest agreement Must Not be done by either side. 997 13.3. SPB Base VLAN-Identifiers sub-TLV 999 This sub-TLV is added to an IIH PDU to indicate the mappings between 1000 ECT algorithms and Base-VIDs (and by implication the VID(s) used on 1001 the forwarding path for each SPT Set for a VLAN identified by a Base 1002 VID) that are in use. Under stable operational conditions, this 1003 information should be the same on all bridges in the topology 1004 identified by the MT-Port-Cap TLV [LAYER2] it is being carried 1005 within. 1007 0 1 2 3 1008 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 1010 +-+-+-+-+-+-+-+-+ 1011 |Type= SPB-B-VID| = 8 1012 +-+-+-+-+-+-+-+-+ 1013 | Length | (1 byte) 1014 +-+-+-+-+-+-+-+-+-----------------------------------------------+ 1015 | ECT - VID Tuple (1) (6 bytes) | 1016 +---------------------------------+-----------------------------+ 1017 | ... | ECT-VID Tuple(2) (6 bytes) | 1018 +---------------------------------+-----------------------------+ 1019 | ..... | 1020 +---------------------------------------------------------------+ 1021 | ..... | 1022 | ..... | 1023 +---------------------------------------------------------------+ 1025 o Type: sub-TLV Type = 8 (Pending IANA). 1027 o Length: The size of the value is ECT-VID Tuples*6 bytes. Each 6- 1028 byte part of the ECT-VID tuple is formatted as follows: 1030 0 1 2 3 1031 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | ECT - Algorithm (32 bits) | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Base VID (12 bits) |U|M|RES| 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 o ECT-ALGORITHM (4 bytes) The ECT-ALGORITHM is advertised when the 1040 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 1041 Base-VID. There are 17 predefined IEEE algorithms for SPB with 1042 index values 0X00..0X10 occupying the low 8 bits and the IEEE 1043 OUI=00-80-C2 occupying the top 24 bits of the ECT-ALGORITHM. 1045 o Base-VID (12-bits) The Base-VID that is associated with the SPT 1046 Set. 1048 o Use-Flag (1-bit) The Use-flag is set if this bridge, or any 1049 bridge in the LSDB is currently using this ECT-ALGORITHM and 1050 Base-VID. Remote usage is discovered by inspection of the U-Bit 1051 in the SPB Instance sub-TLV of other SPB bridges (see section 1052 14.1) 1054 o M-Bit (1-bit) The M-bit indicates if this Base-VID operates in 1055 SPBM (M = 1) or SPBV (M = 0) mode. 1057 The SPB Base VLAN-Identifier sub-TLV is carried within the MT-Port- 1058 Cap TLV [LAYER2] which in turn is carried in an IIH PDU. 1060 14. Node information extensions 1062 All SPB nodal information extensions travel within a new multi 1063 topology capability TLV MT-Capability (type = 144). 1065 0 1 2 3 1066 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 1068 +-+-+-+-+-+-+-+-+ 1069 |Type = MT-CAP | = 144 1070 +-+-+-+-+-+-+-+-+ 1071 | Length | (1 byte) 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 |O R R R| MT ID | (2 bytes) 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 (sub-TLVs ... ) 1077 The format of this TLV is identical in its first 2 bytes to all 1078 current MT TLV's and carries the MT ID as defined in [MT]. 1080 The O (overload) bit carried in bit 16 has the same semantics as 1081 specified in [MT], but in the context of SPB adjacencies only. 1083 14.1. SPB Instance sub-TLV 1085 The SPB Instance sub-TLV gives the SPSourceID for this node/topology 1086 instance. This is the 20 bit value that is used in the formation of 1087 multicast DA addresses for frames originating from this 1088 node/instance. The SPSourceID occupies the upper 20 bits of the 1089 multicast DA together with 4 other bits (see the SPBM 802.1ah 1090 multicast DA address format section). This sub-TLV MUST be carried 1091 within the MT-Capability TLV in the fragment ZERO LSP. If there is 1092 an additional SPB instance it MUST be declared under a separate MT- 1093 Topology and also carried in the fragment ZERO LSP. 1095 0 1 2 3 1096 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 1098 +-+-+-+-+-+-+-+-+ 1099 |Type = SPB-Inst| = 1 1100 +-+-+-+-+-+-+-+-+ 1101 | Length | (1 byte) 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | CIST Root Identifier (4 bytes) | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | CIST Root Identifier (cont) (4 bytes) | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | CIST External ROOT Path Cost (4 bytes) | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Bridge Priority | (2 bytes) 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 |R R R R R R R R R R R|V| SPSourceID | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Num of Trees | (1 byte) 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | VLAN-ID (1) Tuples (8 bytes) | 1116 | ........................... | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 ........................... 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | VLAN-ID (N) Tuples (8 bytes) | 1121 | ........................... | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 where VLAN-ID tuples have the format as: 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+ 1128 |U|M|A| Res | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | ECT - Algorithm (32 bits) | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Base-VID (12 bits) | SPVID (12 bits) | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 o Type: sub-TLV Type 1 (Pending IANA). 1137 o Length: Total number of bytes contained in the value field. 1139 o CIST Root Identifier (64-bits)The CIST Root Identifier is for SPB 1140 interworking with RSTP and MSTP at SPT Region Boundaries. This 1141 is an imported value from a Spanning tree. 1143 o CIST External Root Path Cost (32-bits) The CIST External Root 1144 Path Cost is the cost to root, derived from the spanning tree 1145 algorithm. 1147 o Bridge Priority (16-bits) Bridge priority is the 16 bits that 1148 together with the 6 bytes of the System ID form the Bridge 1149 Identifier. This is configured exactly as specified in IEEE802 1150 [802.1D]. This allows SPB to build a compatible Spanning tree 1151 using link state by combining the Bridge Priority and the System 1152 ID to form the 8 byte Bridge Identifier. The 8 byte Bridge 1153 Identifier is also the input to the 16 pre-defined ECT tie 1154 breaker algorithms. 1156 o V bit (1-Bit) The V bit (SPBM) indicates this SPSourceID is auto 1157 allocated(27.11). If the V bit is clear the SPSourceID has been 1158 configured and Must be unique. Allocation of SPSourceID is 1159 defined in IEEE [802.1aq]. Bridges running SPBM will allocate an 1160 SPSourceID if they are not configured with an explicit 1161 SPSourceID. The V Bit allows neighbor bridges to determine if the 1162 auto allocation was enabled. In the rare chance of a collision 1163 of SPsourceID allocation, the bridge with the highest priority 1164 Bridge Identifier will win conflicts and the lower priority 1165 Bridge will be re-allocated or if the lower priority Bridge is 1166 configured it will not be allowed to join the SPT Region. 1168 o The SPSourceID is a 20 bit value used to construct multicast DA's 1169 as described below for multicast frames originating from the 1170 origin (SPB node) of the link state packet (LSP) that contains 1171 this TLV. More details are in IEEE [802.1aq]. 1173 o Number of Trees (8-bits) The Number of Trees is set to the number 1174 of [ECT-ALGORITHM, Base-VID plus flags] tuples that follow. Each 1175 ECT-ALGORITHM has a Base-VID, an SPVID and flags described below. 1176 This Must contain at least the one ECT-ALGORITMM (00-80-C2-01). 1178 Each VID Tuple consists of: 1180 o U-Bit (1-bit) The U-bit is set if this bridge is currently using 1181 this ECT-ALGORITHM for I-SIDs it sources or sinks. This is a 1182 strictly local indication; the semantics differ from the Use-flag 1183 found in the Hello, which will set the Use-Flag if it sees other 1184 nodal U-bits are set OR it sources or sinks itself. 1186 o M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode. 1187 When cleared the mode is SPBV and when set the mode is SPBM. 1189 o A bit, The A bit (SPB) when set declares this is an SPVID with 1190 auto allocation. The VID allocation logic details are in IEEE 1191 [802.1aq]. Since SPVIDs are allocated from a small pool of 12 1192 bit resources the chances of collision are high. To minimize 1193 collisions during auto allocation LSPs are initially advertised 1194 with the originating bridge setting the SPVID to 0. Only after 1195 learning the other bridges' SPVID allocations does this bridge 1196 re-advertise this sub-TLV with a non-zero SPVID. This will 1197 minimize but not eliminate the chance of a clash. In the event of 1198 a clash, the highest Bridge Identifier is used to select the 1199 winner, while the loser(s) with lower Bridge Identifier(s) Must 1200 withdraw their SPVID allocation(s), and select an alternative 1201 candidate for another trial. SPVID May also be configured. When 1202 the A bit is set to not specify auto allocation and the SPVID is 1203 set to 0 this SPBV bridge is used for transit only within the SPB 1204 region. If a port is configured with the BASE-VID as a neighbor 1205 using RSTP or MSTP the bridge will act as an ingress filter for 1206 that VID. 1208 o ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is advertised when the 1209 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 1210 VID. This declaration Must match the declaration in the Hello PDU 1211 originating from the same bridge. The ECT-ALGORITHM and BASE-VID 1212 Must match what is generated in the IIHs of the same node. The 1213 ECT-ALGORITHM, BASE-VID tuples can come in any order however. 1214 There are currently 17 world wide unique 802.1aq defined ECT- 1215 ALGORITHMS given by values 00-80-C2-00 through 00-80-C2-10. 1217 o Base VID (12-bits) The Base-VID that associated the SPT Set via 1218 the ECT-ALGORITHM. 1220 o SPVID (12-bits) The SPVID is the Shortest Path VID assigned for 1221 the Base-VID to this node when using SPBV mode. It is not 1222 defined for SPBM Mode and Must be 0 for SPBM mode B-VIDs. 1224 14.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV 1226 There are multiple ECT algorithms defined for SPB, however for the 1227 future additional algorithms may be defined including but not 1228 limited to ECMP / hash based behaviors and (*,G) multicast trees. 1229 These algorithms will use this Optional TLV to define new algorithm 1230 parametric data. For tie breaking parameters there are two broad 1231 classes of algorithm, one which uses nodal data to break ties and 1232 one which uses link data to break ties, this TLV is used to 1233 associate opaque tie breaking data with a node. This sub-TLV, when 1234 present, MUST be carried within the MT-Capability TLV (along with a 1235 valid SPB Instance sub-TLV). Multiple copies of this sub-TLV MAY be 1236 carried for different ECT-ALGORITHMs relating to this node. 1238 There are of course many other uses of this opaque data which have 1239 yet to be defined. 1241 0 1 2 3 1242 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 1244 +-+-+-+-+-+-+-+-+ 1245 |Type=SPB-I-OALG| = 2 1246 +-+-+-+-+-+-+-+-+ 1247 | Length | (1 byte) 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Opaque ECT Algorithm (4 bytes) | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Opaque ECT Information (variable) | 1252 | ....................... | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 o Type: sub-TLV Type 2 (Pending IANA). 1256 o Length: Total number of bytes contained in the value field. 1258 o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge 1259 supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. 1261 o ECT Information: ECT-ALGORITHM Information of variable length 1262 which SHOULD be in sub-TLV format with an IANA numbering space 1263 where appropriate. 1265 15. Adjacency information extensions 1267 15.1. SPB Link Metric sub-TLV 1269 The SPB Link Metric sub-TLV (type = 12) occurs within the Multi 1270 Topology Intermediate System TLV (type 222) or within the Extended 1271 IS Reachability TLV (type 22). If this sub TLV is not present for 1272 an ISIS adjacency then that adjacency Must not carry SPB traffic for 1273 the given topology instance. 1275 0 1 2 3 1276 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 1278 +-+-+-+-+-+-+-+-+ 1279 |Type=SPB-Metric| = 12 1280 +-+-+-+-+-+-+-+-+ 1281 | Length | (1 byte) 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | SPB-LINK-METRIC | (3 bytes) 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Num of ports | (1 byte) 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Port Identifier | ( 2 bytes) 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 o Type: sub-TLV Type 12 (Pending IANA). 1292 o Length: Total number of bytes contained in the value field. 1294 o SPB-LINK-METRIC indicates the administrative cost or weight of 1295 using this link as a 24 bit unsigned number. This metric applies 1296 to the use of this link for SPB traffic only. Smaller numbers 1297 indicate lower weights and are more likely to carry SPB traffic. 1298 Only one metric is allowed per SPB instance per link. If 1299 multiple metrics are required multiple SPB instances Must be 1300 used, either within IS-IS or within several independent IS-IS 1301 instances. If this metric is different at each end of a link, the 1302 maximum of the two values Must be used in all SPB calculations 1303 for the weight of this link. The maximum SPB-LINK-METRIC value 1304 2^24 - 1 has a special significance; this value indicates that 1305 although the IS-IS adjacency has formed, incompatible values have 1306 been detected in parameters configured within SPB itself for 1307 example different regions, and the link Must Not be used for 1308 carrying SPB traffic. Full details are found in [802.1aq]. 1310 o Num of Ports is the number of ports associated with this link. 1312 o Port Identifier is the standard IEEE port identifier used to 1313 build a spanning tree associated with this link. 1315 15.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV 1317 There are multiple ECT algorithms defined for SPB, however for the 1318 future additional algorithms may be defined. The SPB Adjacency 1319 Opaque ECT-ALGORITHM sub-TLV occurs within the Multi Topology 1320 Intermediate System TLV (type 222) or the Extended IS Reachability 1321 TLV (type 22). Multiple copies of this sub-TLV MAY be carried for 1322 different ECT-ALGORITHMs related to this adjacency. 1324 0 1 2 3 1325 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 1327 +-+-+-+-+-+-+-+-+ 1328 |Type=SPB-A-OALG| = 13 1329 +-+-+-+-+-+-+-+-+ 1330 | Length | (1 byte) 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Opaque ECT Algorithm (4 bytes) | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Opaque ECT Information (variable) | 1335 | ......................... | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 o Type: sub-TLV Type = 13 (PENDING IANA). 1340 o Length: Total number of bytes contained in the value field. 1342 o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge 1343 supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. 1345 o ECT Information: ECT-ALGORITHM Information of variable length in 1346 sub-TLV format using new IANA type values as appropriate. 1348 16. Service information extensions 1350 16.1. SPBM Service Identifier and Unicast Address sub-TLV 1352 The SPBM Service Identifier and Unicast Address sub-TLV (type=3) is 1353 used to introduce service group membership on the originating node 1354 and/or to advertise an additional B-MAC unicast address present on, 1355 or reachable by the node. 1357 0 1 2 3 1358 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 1360 +-+-+-+-+-+-+-+-+ 1361 |Type = SPBM-SI | = 3 1362 +-+-+-+-+-+-+-+-+ 1363 | Length | (1 byte) 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | B-MAC ADDRESS | 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 | B-MAC ADDRESS (6 bytes) | Res. | Base-VID (12 bits) | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 |T|R| Reserved | ISID #1 | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 |T|R| Reserved | ISID #2 | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 ................. 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 |T|R| Reserved | ISID #n | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 o Type: sub-TLV Type = 3 (Pending IANA) 1380 o Length: Total number of bytes contained in the value field. 1382 o B-MAC ADDRESS is a unicast address of this node. It may be 1383 either the single nodal address, or may address a port or any 1384 other level of granularity relative to the node. In the case 1385 where the node only has one B-MAC address this Should be the same 1386 as the SYS-ID of the node. To add multiple B-MACs this TLV MUST 1387 be repeated per additional B-MAC. 1389 o Base VID (12-bits) The Base-VID associated with the B-BMAC this 1390 allows the linkage to the ECT-Algorithm and SPT Set defined in 1391 the SPB Instance sub-TLV. 1393 o ISID #1 .. #N are 24 bit service group membership identifiers. 1394 If two nodes have an I-SID in common, intermediate nodes on the 1395 unique shortest path between them will create forwarding state 1396 for the related B-MAC addresses and will also construct multicast 1397 forwarding state using the I-SID and the node's SPSourceID to 1398 construct a multicast DA as described in IEEE 802.1aq LSB. Each 1399 I-SID has a Transmit(T) and Receive(R) bit which indicates if the 1400 membership is as a Transmitter/Receiver or both (with both bits 1401 set). In the case where the Transmit(T) and Receive(R) bits are 1402 both zero, the I-SID instance is ignored for the purposes of 1403 distributed multicast computation, but the unicast B-MAC address 1404 Must be processed and installed at nodes providing transit to 1405 that address. If more I-SIDs are associated with a particular B- 1406 MAC than can fit in a single sub-TLV, this sub-TLV can be 1407 repeated with the same B-MAC but with different I-SID values. 1409 o Note when the T bit is not set an SPB May still multicast to all 1410 the other receive members of this I-SID (those advertising with 1411 their R bits set), by configuring edge replication and serial 1412 unicast to each member locally. 1414 The SPBM Service Identifier sub-TLV, when present, MUST be carried 1415 within the MT Capability TLV and can occur multiple times in any LSP 1416 fragment. 1418 16.2. SPBV Mac Address sub-TLV 1420 The SPBV MAC Address (SPBV-MAC-ADDR) sub-TLV is IS-IS sub-TLV type 4 1421 (PENDING IANA). It Should be used for advertisement of Group MAC 1422 Addresses in SPBV mode. Unicast MAC addresses will normally be 1423 distributed by reverse path learning, but carrying them in this TLV 1424 is not precluded. It has the following format : 1426 0 1 2 3 1427 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 1429 +-+-+-+-+-+-+-+-+ 1430 | Type=SPBV-ADDR| = 4 (1 byte) 1431 +-+-+-+-+-+-+-+-+ 1432 | Length | (1 byte) 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 |R|R|S-R| SPVID | (2 bytes) 1435 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+ 1436 |T|R| Reserved | MAC 1 Address | (1+6 bytes) 1437 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+ 1438 ... 1439 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+ 1440 |T|R| Reserved | MAC N Address | (1+6 bytes) 1441 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+ 1443 o Type: sub-TLV Type, set to 4. 1445 o Length: Total number of bytes contained in the value field. The 1446 number of MAC address associated with the SPVID is computed by 1447 (Length - 2)/7. 1449 o S-R bits (2-bits) The SR bits are the service requirement 1450 parameter from MMRP. The service requirement parameters have the 1451 value 0 (Forward all Groups) and 1 (Forward All Unregistered 1452 Groups) defined. However this attribute May also be missing. So 1453 the SR bits are defined as 0 not declared, 1 Forward all Groups 1454 and 2 Forward All Unregistered Groups. The two 'R' reserved bits 1455 immediately preceding these SR bits Shall be set to zero when 1456 originating this sub-TLV and Shall be ignored on receipt. 1458 o SPVID (12-bits) The SPVID and by association Base-VID and the 1459 ECT-ALGORITHM and SPT Set that the MAC addresses defined below 1460 will use. If the SPVID is not allocated the SPVID Value is 0. 1461 Note that if the ECT-Algorithm in use is Spanning Tree Algorithm 1462 this value Must be populated with the Base-VID and the MAC Must 1463 be populated. 1465 o T Bit (1-bit) This is the Transmit allowed Bit for a following 1466 group MAC address. This is an indication that the Group MAC 1467 Address in the context of the SPVID of the bridge advertising 1468 this Group MAC Must be installed in the FDB of transit bridges, 1469 when the bridge computing the trees is on the corresponding ECT- 1470 ALGORITHM shortest path between the bridge advertising this MAC 1471 with the T bit set and any receiver of this Group MAC Address. A 1472 bridge that does not advertise this bit set for a MAC Address 1473 Must Not cause multicast forwarding state to be installed on 1474 other transit bridges in the network for traffic originating from 1475 that bridge. 1477 o R Bit (1-bit) This is the Receive allowed Bit for the following 1478 MAC Address. This is an indication that MAC Addresses as receiver 1479 Must be populated and installed when the bridge computing the 1480 trees lies on the corresponding shortest path for this ECT- 1481 ALGORITHM between this receiver and any transmitter to this MAC 1482 Address. An entry that does not have this bit set for a Group 1483 MAC Address is prevented from receiving on this Group MAC Address 1484 because transit bridges Must Not install multicast forwarding 1485 state towards it in their FDBs. 1487 o MAC Address (48-bits) The MAC address declares this bridge as 1488 part of the multicast interest for this destination MAC address. 1489 Multicast trees can be efficiently constructed for destination by 1490 populating FDB entries for the subset of the shortest path tree 1491 that connects the bridges supporting the MAC address. This 1492 replaces the function of MMRP for SPTs. The T and R bits above 1493 have meaning as specified above. 1495 The SPBV-MAC-ADDR sub-TLV, when present, MUST be carried within the 1496 MT-Capability TLV and can occur multiple times in any LSP fragment. 1498 17. Security Considerations 1500 This document adds no additional security risks to IS-IS, nor does 1501 it provide any additional security for IS-IS when used in a 1502 configured environment or a single operator domain such as a Data 1503 Center. 1505 However this protocol may be used in a zero configuration 1506 environment. Zero configuration may apply to the automatic detection 1507 and formation of an IS-IS adjacency (forming an NNI port). Likewise 1508 zero configuration may apply to the automatic detection of VLAN 1509 tagged traffic and the formation of a UNI port, with resultant ISID 1510 advertisements. 1512 If zero configuration methods are used to auto configure NNIs or 1513 UNIs there are intrinsic security concerns that should be mitigated 1514 with authentication procedures for the above cases. Such procedures 1515 are beyond the scope of this document, and are yet to be defined. 1517 In addition, this protocol can create significant amounts of 1518 multicast state when an ISID is advertised with the TX bit set. 1519 Extra care should be taken to ensure that this cannot be used in a 1520 Denial of Service attack [RFC4732] in a zero configuration 1521 environment. 1523 18. IANA Considerations 1525 Note that the NLPID value 0xC1 [NLPID] used in the IIH PDUs has 1526 already been assigned by IANA for the purpose of 802.1aq therefore 1527 no further action is required for this code point. 1529 Since 802.1aq operates within the IS-IS Multi Topology framework 1530 every sub-TLV MUST occur in the context of the proper MT TLV (with 1531 the exception of the SPB Link Metric sub-TLV which MAY travel in TLV 1532 22 where its MT-ID is unspecified but implied to be 0). There are 1533 three Multi Topology TLV's in which 802.1aq requests allocation of 1534 sub-TLV's. These are the MT-Port-Cap TLV [LAYER2] used in the IIH, 1535 the MT-Capability TLV (new) used within the LSP and finally the MT- 1536 Intermediate-System TLV [MT] used to contain adjacency information 1537 within the LSP. 1539 This document creates the following TLVs & sub-TLV's within the IIH 1540 and LSP PDUs MT TLV's as described below. The '*' indicates IANA 1541 action is required. Other entries are shown to provide context only. 1542 A '?' next to a number indicates a requested but of course not 1543 necessarily the final assigned value. 1545 The MT-Capability TLV is the only TLV requiring a new sub-registry. 1546 Type value 144 (TBD) is requested, with a starting sub-TLV value of 1547 1, and managed by Expert Review. 1549 +-----+----+-----------------+--------+------+-------------+ 1550 | PDU |TLV | SUB-TLV | TYPE | TYPE | #OCCURRENCE | 1551 +-----+----+-----------------+--------+------+-------------+ 1552 IIH 1553 MT-Port-Cap 147? 1554 * SPB-MCID 6? 1 1555 * SPB-Digest 7? >=0 1556 * SPB-B-VID 8? 1 1558 LSP 1559 * MT-Capability 144? 1560 * SPB-Inst 1? 1 1561 * SPB-I-OALG 2? >=0 1562 * SPBM-SI 3? >=0 1563 * SPBV-ADDR 4? >=0 1565 MT-Intermediate-System 222 1566 or Extended IS Reachability 22 1567 * SPB-Metric 12? 1 1568 * SPB-A-OALG 13? >=0 1570 19. References 1572 19.1. Normative References 1574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1575 Requirement Levels", BCP 14, RFC 2119, March 1997. 1577 [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System 1578 to Intermediate System Intra-Domain Routing Exchange 1579 Protocol for use in Conjunction with the Protocol for 1580 Providing the Connectionless-mode Network Service (ISO 1581 8473)", 2002. 1583 [MT] M-ISIS: Multi Topology (MT) Routing in Intermediate System 1584 to Intermediate Systems (IS-ISs), RFC 5120, February 2008. 1586 [802.1aq] "Standard for Local and Metropolitan Area Networks / 1587 Virtual Bridged Local Area Networks / Amendment: Shortest 1588 Path Bridging, IEEE P802.1aq Draft 3.6", 2011. 1590 [NLPID] www.ietf.org/id/draft-eastlake-nlpid-iana-considerations- 1591 04.txt 1593 [LAYER2] www.ietf.org/id/draft-ietf-isis-layer2-09.txt. 1595 19.2. Informative References 1597 [MMRP] "Standard for Local and Metropolitan Area Networks Virtual 1598 Bridged Local Area Networks - Amendment 07: Multiple 1599 Registration Protocol", IEEE STD 802.1ak, 2007 1601 [PB] "Standard for Local and Metropolitan Area Networks / 1602 Virtual Bridged Local Area Networks / Amendment 4: 1603 Provider Bridges, IEEE STD 802.1ad", 2005. 1605 [PBB] "Standard for Local and Metropolitan Area Networks / 1606 Virtual Bridged Local Area Networks / Amendment 7: 1607 Provider Backbone Bridges, IEEE STD 802.1ah", 2008. 1609 [802.1ag] "Standard for Local and Metropolitan Area Networks / 1610 Virtual Bridged Local Area Networks / Amendment 5: 1611 Connectivity Fault Management", IEEE STD 802.1ag, 2007 1613 [Y.1731] ITU-T Y.1731 (2006), "OAM Functions and Mechanisms for 1614 Ethernet based networks" 1616 [RFC4732] Handley, M., Ed, "Internet Denial-of-Service 1617 Considerations", RFC 4732, November 2006. 1619 20. Acknowledgments 1621 The authors would like to thank Ayan Banerjee, Mick Seaman, Janos 1622 Farkas, Les Ginsberg, Stewart Bryant , Donald Eastlake, Matthew 1623 Bocci and Mike Shand for contributions and/or detailed review. 1625 This document was prepared using 2-Word-v2.0.template.dot. 1627 21. Author's Addresses 1629 Don Fedyk 1630 Alcatel-Lucent 1631 Groton, MA, 01450, USA 1632 Email: Donald.Fedyk@alcatel-lucent.com 1633 Peter Ashwood-Smith 1634 Huawei Technologies Canada Ltd, 1635 303 Terry Fox Drive, Suite 400 1636 Kanata, Ontario, K2K 3J1, CANADA 1637 Email: Peter.AshwoodSmith@huawei.com 1639 Dave Allan 1640 Ericsson, 1641 300 Holger Way 1642 San Jose, CA 1643 95134 1644 Email: david.i.allan@ericsson.com 1646 Nigel Bragg 1647 Ciena Limited, 1648 Ciena House 1649 43-51 Worship Street 1650 London EC2A 2DX 1651 Email: nbragg@ciena.com 1653 Paul Unbehagen 1654 Alcatel-Lucent 1655 8742 Lucent Boulevard 1656 Highlands Ranch, CO 80129, USA 1657 Email: Paul.Unbehagen@alcatel-lucent.com 1659 22. Intellectual Property Statement 1661 The IETF Trust takes no position regarding the validity or scope of 1662 any Intellectual Property Rights or other rights that might be 1663 claimed to pertain to the implementation or use of the technology 1664 described in any IETF Document or the extent to which any license 1665 under such rights might or might not be available; nor does it 1666 represent that it has made any independent effort to identify any 1667 such rights. 1669 Copies of Intellectual Property disclosures made to the IETF 1670 Secretariat and any assurances of licenses to be made available, or 1671 the result of an attempt made to obtain a general license or 1672 permission for the use of such proprietary rights by implementers or 1673 users of this specification can be obtained from the IETF on-line 1674 IPR repository at http://www.ietf.org/ipr 1676 The IETF invites any interested party to bring to its attention any 1677 copyrights, patents or patent applications, or other proprietary 1678 rights that may cover technology that may be required to implement 1679 any standard or specification contained in an IETF Document. Please 1680 address the information to the IETF at ietf-ipr@ietf.org. 1682 23. Disclaimer of Liability 1684 This document and the information contained herein are provided on 1685 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1686 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1687 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1688 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not LIMITED TO ANY 1689 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not INFRINGE 1690 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS.