idnits 2.17.1 draft-ietf-isis-ieee-aq-04.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 (February 1, 2011) is 4827 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: August 1, 2011 Huawei 7 February 1, 2011 9 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging 10 draft-ietf-isis-ieee-aq-04.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...................................11 76 4.7. Data Path SPBV Multicast.................................12 77 5. SPBM Example..................................................12 78 6. SPBV Example..................................................14 79 7. SPB Supported Adjacency types.................................16 80 8. SPB IS-IS adjacency addressing................................16 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.......................23 89 14. Node information extensions..................................25 90 14.1. SPB Instance sub-TLV....................................25 91 14.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV..........28 92 15. Adjacency information extensions.............................29 93 15.1. SPB Link Metric sub-TLV.................................29 94 15.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV.........30 95 16. Service information extensions...............................31 96 16.1. SPBM Service Identifier and Unicast Address sub-TLV.....31 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 SPSourceID 20 bit identifier of the source of multicast frames. 184 SPVID SPBV: a C-VLAN or S-VLAN that identifies the source. 185 UNI User Network Interface: Customer to SPB attach point. 186 VID VLAN ID 12 bit logical identifier after MAC header. 187 VLAN Virtual LAN: A logical network in the control plane 189 3. Conventions used in this document 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in [RFC2119]. 195 The lower case forms "must", "must not", "shall", "shall not", 196 "should", "should not" and "may" in this document are to be 197 interpreted in the sense defined in [RFC2119], but are used where 198 the normative behavior is defined in documents published by SDOs 199 other than the IETF. 201 4. 802.1aq Overview 203 This section provides an overview of the behavior of [802.1aq] and 204 is not intended to be interpreted as normative text. For the 205 definitive behavior the reader should consult [802.1aq]. Nonetheless 206 lower case forms of the conventions in RFC2119 are used in this 207 section to give the reader an indication of the intended normative 208 behaviors as above. 210 802.1aq utilizes 802.1Q based Ethernet bridging. The filtering 211 database (FDB) is populated as a consequence of the topology 212 computed from the IS-IS database. For the reader unfamiliar with 213 IEEE terminology, the definition of Ethernet behavior is almost 214 entirely in terms of "filtering" (of broadcast traffic) rather than 215 "forwarding" (the explicit direction of unicast traffic). This 216 document uses the generic term "forwarding", and it has to be 217 understood that these two terms simply represent different ways of 218 expressing the same behaviors. 220 802.1aq supports multiple modes of operation depending on the type 221 of data plane and the desired behavior. For the initial two modes of 222 802.1aq (SPBV and SPBM), routes are shortest path, are forward and 223 reverse path symmetric with respect to any source / destination pair 224 within the SPB domain, and are congruent with respect to unicast and 225 multicast. Hence the shortest path tree (SPT) to a given node is 226 congruent with the multicast distribution tree (MDT) from a given 227 node. The MDT for a given VLAN is a pruned subset of the complete 228 MDT for a given node which is identical to its SPT. Symmetry and 229 congruency preserve packet ordering and proper fate sharing of OAM 230 flows by the forwarding path. Such modes are fully supported by 231 existing [802.1ag] and [Y.1731] OA&M mechanisms. 233 VLANs provide a natural delineation of service instances. 802.1aq 234 supports two modes, SPB VID (SPBV) and SPB MAC (SPBM). In SPBV 235 multiple VLANS can be used to distribute load on different shortest 236 path trees (each computed by a different tie breaking rule) on a 237 service basis. In SPBM service instances are delineated by I-SIDs 238 but VLANs again can be used to distribute load on different shortest 239 path trees. 241 There are two encapsulation methods supported. SPBM can be used in a 242 PBB network implementing PBB (802.1ah [PBB]) encapsulation. SPBV can 243 be used in PB networks implementing VLANs, PB (802.1aq [PB]) or PBB 244 encapsulation. The two modes can co-exist simultaneously in an SPB 245 network. 247 The practical design goals for SPBV and SPBM in the current 802.1aq 248 specification are networks of size 100 nodes and 1000 nodes 249 respectively. However since SPBV can be sparsely used in an SPB 250 Region it can simply span a large SPB region with a small number of 251 SPVIDs. 253 In SPBM and SPBV each bridge has at least one unique "known" MAC 254 address which is advertised by IS-IS in the SYS-ID. 256 In the forwarding plane, SPBM uses the combination of one or more B- 257 VIDs and "known" Backbone-MAC (B-MAC) addresses that have been 258 advertised in IS-IS. The term Backbone simply implies an 259 encapsulation that is often used in the backbone networks, but the 260 encapsulation is useful in other types of networks where hiding C- 261 MACs is useful. 263 The SPBM filtering database (FDB) is computed and installed for 264 unicast and multicast MAC addresses, while the SPBV filtering 265 database is computed and installed for unidirectional VIDs (referred 266 to as SPVIDs), after which MAC reachability is learned (exactly as 267 in bridged Ethernet) for unicast MACs. 269 Both SPBV and SPBM use source specific multicast trees. If they 270 share the same ECT-ALGORITHM (32 bit world wide unique definition of 271 the computation) the tree is the same SPT. For SPBV (S,G) is encoded 272 by a source-specific VID (the SPVID) and a standard Group MAC 273 address. For SPBM (S,G) is encoded in the destination B-MAC address 274 as the concatenation of a 20 bit SPB wide unique nodal nickname 275 (referred to as the SPSourceID) and the 24 bit I-SID together with 276 the B-VID which corresponds to the ECT-ALGORITHM network wide. 278 802.1aq supports membership attributes which are advertised with the 279 I-SID (SPBM) or Group Address (SPBV) that define the group. 280 Individual members can be transmitters (T) and/or receivers (R) 281 within the group and the multicast state is appropriately sized to 282 these requests. Multicast group membership is possible even without 283 transmit membership by performing head end replication to the 284 receivers thereby eliminating transit multicast state entirely. 286 Some highly connected mesh networks provide for path diversity by 287 offering multiple equal cost alternatives between nodes. Since 288 congruency and symmetry must be honored, a single tree may leave 289 some links under utilized. By using different deterministic tie 290 breakers, up to sixteen shortest paths of arbitrary diversity are 291 possible between any pair of nodes. This distributes the traffic on 292 a VLAN basis. SPBV and SPBM may share a single SPT with a single 293 ECT-ALGORITHM or use any combination of the 16 ECT-ALGORITHMs. An 294 extensible framework permits additional or alternative algorithms 295 with other properties and parameters (e.g. ECMP, (*,G) ) to also be 296 supported without any changes in this or the IEEE documents. 298 4.1. Multi Topology Support 300 SPB incorporates the multi topology features of [MT] thereby 301 allowing multiple logical SPB instances within a single IS-IS 302 instance. 304 To accomplish this, all SPB related information is either explicitly 305 or implicitly associated with a Multi Topology Identifier (MT-ID). 306 SPB information related to a given MT-ID thus forms a single logical 307 SPB instance. 309 Since SPB has its own adjacency metrics and those metrics are also 310 associated with an MT-ID it is not only possible to have different 311 adjacency metrics (or infinite metrics) for SPB adjacencies, 312 distinct from IP or other NLPIDs riding in this IS-IS instance, and 313 also distinct from those used by other SPB instances in the same IS- 314 IS instance. 316 Data plane traffic for a given MT-ID is intrinsically isolated by 317 the VLANs assigned to the SPB instance in question. Therefore VLANs 318 (represented by VIDs in TLVs and data plane) must not overlap 319 between SPB instances (regardless of how the control planes are 320 isolated). 322 The [MT] mechanism when applied to SPB allows different routing 323 metrics and topology subsets for different classes of services. 325 The use of [MT] other than the default MT-ID#0 is completely 326 optional. 328 The use of [MT] to separate SPB from other NLPIDs is also optional. 330 4.2. Data Path SPBM - Unicast 332 Unicast frames in SPBM are encapsulated as per 802.1ah [PBB]. A 333 Backbone Source Address (B-SA), Backbone Destination Address (B-DA), 334 Backbone VLAN ID (B-VID) and an I-Component Service Instance ID (I- 335 TAG) are used to encapsulate the Ethernet frame. The B-SA is a B-MAC 336 associated with the ingress 802.1aq bridge, usually the "known" B- 337 MAC of that entire bridge. The B-DA is one of the "known" B-MACs 338 associated with the egress 802.1aq bridge. The B-VID and I-TAG are 339 mapped based on the physical or logical UNI port (untagged, or 340 tagged either by S-TAG or C-TAG) being bridged. Normal learning and 341 broadcast to unknown C-MACs is applied as per [PBB] at the 342 ingress/egress SPBs only. 344 Unlike [PBB] on a (*,G) tree, the B-DA forwarding on tandem nodes 345 (NNI to NNI) is performed without learning. Instead the output of 346 802.1aq computations, based on the TLVs specified in this document, 347 are used to populate the filtering data bases (FDB). The FDB entries 348 map {B-DA, B-VID} to an outgoing interface and are only populated 349 from the IS-IS database and computations. 351 The B-SA/B-VID is checked on tandem nodes against the ingress port. 352 If the B-SA/B-VID (as a destination) entry in the FDB does not point 353 to the port on which the packet arrived the packet is discarded. 354 This is referred to as an Ingress Check and serves as a very 355 powerful loop mitigation mechanism. 357 4.3. Data Path SPBM - Multicast (Head End Replication) 359 Head end replication is supported for instances where there is a 360 sparse community of interest or a low likelihood of multicast 361 traffic. Head end replication requires no Multicast state in the 362 core. A UNI port wishing to use head end replication must not 363 advertise its I-SID membership with the TX bit set but instead must 364 locally and dynamically construct the appropriate unicast serial 365 replication to all the other receivers (RX) of the same I-SID. 367 When an unknown customer unicast or a multicast frame arrives at an 368 SPBM User to Network Interface (UNI) port which has been configured 369 to replicate only at the head end the packet is replicated once for 370 each receiver, encapsulated and sent as a unicast frame. The set of 371 receivers is determined by inspecting the IS-IS database for other 372 SPBs that have registered interest in the same I-SID with the RX 373 (receive) attribute set. This RX/I-SID pair is found in the SPBM 374 Service Identifier and Unicast Address sub-TLV. The packets are 375 encapsulated as per the SPBM Unicast forwarding above. 377 4.4. Data Path SPBM - Multicast (Tandem Replication) 379 Tandem replication uses the Shortest path Tree to replicate Frames 380 only where the tree forks and there is at least one receiver on each 381 branch. Tandem replication is bandwidth efficient but uses multicast 382 FDB entries (state) in core bridges which might be unnecessary if 383 there is little multicast traffic demand. The head end replication 384 mode is best suited for the case where there is little or no true 385 multicast traffic for an I-SID. Tandem replication is triggered on 386 transit nodes when the I-SID is advertised with the TX bit set. 388 Broadcast, unknown unicast or multicast frames arriving at an SPBM 389 UNI port are encapsulated with a B-DA multicast address which 390 uniquely identifies the encapsulating node (the root of the 391 Multicast Distribution Tree) and the I-SID scoping this multicast. 393 This B-DA address is a well formed multicast group address (as per 394 802.1Q and 802.1ah) which concatenates the SPSourceID A' with the I- 395 SID M (written as DA= and uniquely identifying the (S,G) 396 tree). This exact format is given in Figure 1 below: 398 0 1 2 3 399 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 401 M L TYP 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |1|1|0|0| SPSRC [8:19] | SPSRC [0:7] | ISID [16:23] | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | ISID [8:15] | ISID [0:7] | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Figure 1 SPBM Multicast Address format 410 o M is the multicast bit- always set to 1 for a multicast DA. 412 o L is the local bit- always set to 1 for a SPBM constructed 413 multicast DA. 415 o TYP is the SPSourceID type. Two values are supported. 00 for 416 statically assigned SPSourceID's and 01 for dynamic assignment. 418 o SPSRC (SPSourceID) is a 20 bit quantity that uniquely identifies 419 a SPBM node for all B-VIDs allocated to SPBM operation. This is 420 just the SPSourceID advertised in the SPB Instance sub-TLV. 422 o I-SID is the 24 bit I component Service ID advertised in the SPBM 423 Service Identifier TLV. It occupies the lower 24 bits of the SPBM 424 multicast DA. The I-SID value 0xfff is reserved for SPBM control 425 traffic(refer to the default I-SID in [802.1aq]). 427 This multicast address format is used as the DA on frames when they 428 are first encapsulated at ingress to the SPBM network. The DA is 429 also installed into the FDBs on all SPBM nodes that are on the 430 corresponding SPT between the source and other nodes that have 431 registered receiver interest in the same I-SID. 433 Just as with unicast forwarding, the B-SA/B-VID may be used to 434 perform an ingress check, but the SPSourceID encoded in the DA and 435 the "drop-on-unknown" functionality of the FDB in [PBB] achieve the 436 same effect. 438 The I-Component at the egress SPBM device has completely standard 439 [PBB] behavior and therefore will: 441 1) learn the remote C-SA to B-SA relationship and 442 2) bridge the original customer frame to the set of local UNI ports 443 that are associated with the I-SID. 445 4.5. Data Path SPBV Broadcast 447 When a packet for an unknown DA arrives at a SPBV UNI port VID 448 translation (or VID encapsulation for un-tagged Frames) with the 449 corresponding SPVID for this VLAN and ingress SPB is performed. 451 SPVID forwarding is simply an SPT that follows normal VLAN 452 forwarding behavior, with the exception that the SPVID is 453 unidirectional. As a result shared learning (SVL) is used between 454 the forward and reverse path SPVIDs associated with the same Base- 455 VID to allow SPBV unicast forwarding to operate in the normal 456 reverse learning fashion. 458 Ingress check is done by simply verifying that the bridge to which 459 the SPVID has been assigned is indeed "shortest path" reachable over 460 the link over which the packet tagged with that SPVID arrived. This 461 check is computed from the IS-IS database and is implied when the 462 SPVID is associated with a specific incoming port. 464 4.6. Data Path SPBV Unicast 466 Conversely when a packet for a known DA arrives at a SPBV UNI port 467 VID translation (or VID encapsulation for un-tagged Frames) with the 468 corresponding SPVID for this VLAN and ingress SPB is performed. 470 Since the SPVID will have been configured to follow a source 471 specific SPT and the DA is known the packet will follow the source 472 specific path towards the destination C-MAC. 474 Ingress check is as per the previous SPBV section. 476 4.7. Data Path SPBV Multicast 478 C-DA multicast addresses may be advertised from SPBV UNI ports. 479 These may be configured or learned through MMRP. The MMRP protocol 480 is terminated at the edge of the SPBV network and IS-IS carries the 481 multicast addresses. Tandem SPBV devices will check to see if they 482 are on the SPF tree between SPBV UNI ports advertising the same C-DA 483 multicast address, and if so will install multicast state to follow 484 the SPBV SPF trees. 486 Ingress check is as per the previous two SPBV sections. 488 5. SPBM Example 490 Consider the following small example network shown in Figure 2. 491 Nodes are drawn in boxes with the last nibble of their B-MAC address 492 :1..:7, the rest of the B-MAC address nibbles are 4455-6677-00xx. 493 Links are drawn as -- and / while the interface indexes are drawn as 494 numbers next to the links. UNI ports are shown as <==> with the 495 desired I-SID show at the end of the UNI ports as i1. 497 +----+ +----+ 498 | :4 | 2 ------1 | :5 | <==> i1 499 +----+ +----+ 500 1 3 3 2 501 / \ / \ 502 1 4 3 2 503 +----+ +----+ +----+ 504 i1 <==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> i1 505 +----+ +----+ +----+ 506 3 6 5 3 507 \ / \ / 508 3 2 1 2 509 +----+ +----+ 510 | :6 | 1-------3 | :7 | <==> i1 511 +----+ +----+ 513 Figure 2 - SPBM Example 7 node network 515 Using the default ECT-ALGORITHM (00-80-C2-01), which picks the equal 516 cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned 517 to B-VID 100. When all links have the same cost, then the 1 hop 518 shortest paths are all direct and the 2 hop shortest paths (which 519 are of course symmetric) are as follows: 521 { 1-2-3, 1-2-5, 1-2-7, 6-2-5, 522 4-2-7, 4-1-6, 5-2-7, 6-2-3, 4-2-3 } 524 Node :1's Unicast forwarding table therefore routes toward B-MACs 525 :7, :3 and :5 via interface/2 while its single hop paths are all 526 direct as can be seen from its FDB given in Figure 3. 528 Node :1 originates multicast since it is at the head of the MDT to 529 nodes :3, :5 and :7 and is a transmitter of I-SID 1 which nodes :3, 530 :5 and :7 all wish to receive. Node :1 therefore produces a 531 multicast forwarding entry who's DA contains its SPSourceID (in the 532 example the last 20 bits of the B-MAC) and the I-SID 1 and sends to 533 interface 2 with B-VID=100. Node :1's full unicast(U) and 534 multicast(M) table is shown in Figure 3. Note that the IN/IF 535 (incoming interface) field is not specified for unicast traffic and 536 for multicast traffic has to point back to the root of the tree, 537 unless it is the head of the tree in which case we use the 538 convention if/OO. Since Node :1 is not transit for any multicast it 539 only has a single entry for the root of its tree for I-SID=1. 541 +-------+-------------------+------+-----------------+ 542 | IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) | 543 +-------+-------------------+------+-----------------+ 544 U| if/** | 4455-6677-0002 | 0100 | {if/2 } 545 U| if/** | 4455-6677-0003 | 0100 | {if/2 } 546 U| if/** | 4455-6677-0004 | 0100 | {if/1 } 547 U| if/** | 4455-6677-0005 | 0100 | {if/2 } 548 U| if/** | 4455-6677-0006 | 0100 | {if/3 } 549 U| if/** | 4455-6677-0007 | 0100 | {if/2 } 550 M| if/00 | 7300-0100-0001 | 0100 | {if/2 } 552 Figure 3 - SPBM Node :1 FDB - Unicast(U) and Multicast(M) 554 Node :2, being at the center of the network, has direct 1 hop paths 555 to all other nodes, therefore its unicast FDB simply sends packets 556 with the given B-MAC/B-VID=100 to the interface directly to the 557 addressed node. This can be seen by looking at the unicast entries 558 (the first 6) shown in Figure 4. 560 +-------+-------------------+------+-----------------+ 561 | IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) | 562 +-------+-------------------+------+-----------------+ 563 U| if/** | 4455-6677-0001 | 0100 | {if/1 } 564 U| if/** | 4455-6677-0003 | 0100 | {if/2 } 565 U| if/** | 4455-6677-0004 | 0100 | {if/4 } 566 U| if/** | 4455-6677-0005 | 0100 | {if/3 } 567 U| if/** | 4455-6677-0006 | 0100 | {if/6 } 568 U| if/** | 4455-6677-0007 | 0100 | {if/5 } 569 M| if/01 | 7300-0100-0001 | 0100 | {if/2,if/3,if/5 } 570 M| if/02 | 7300-0300-0001 | 0100 | {if/1 } 571 M| if/03 | 7300-0500-0001 | 0100 | {if/1,if/5 } 572 M| if/05 | 7300-0700-0001 | 0100 | {if/1,if/3 } 574 Figure 4 - SPBM Node :2 FDB Unicast(U) and Multicast(M) 576 Node :2's multicast is more complicated since it is a transit node 577 for the 4 members of I-SID=1, therefore it requires 4 multicast FDB 578 entries depending on which member it is forwarding/replicating on 579 behalf of. For example, node :2 is on the shortest path between each 580 of nodes {:3,:5,:7} and :1. So it must replicate from node :1 I-SID 581 1 out on interfaces 2, 3 and 5 (to reach nodes :3, :5 and :7). It 582 therefore creates a multicast DA with the SPSourceID of node :1 583 together with I-SID=1 which it expects to receive over interface/1 584 and will replicate out interfaces/{2, 3 and 5}. This can be seen in 585 the first multicast entry in Figure 4. 587 Note that node :2 is not on the shortest path between nodes :3 and 588 :5 nor between nodes :3 and :7, however it still has to forward 589 packets to node :1 from node :3 for this I-SID, which results in the 590 second multicast forwarding entry in Figure 4. Likewise for packets 591 originating at nodes 5 or 7, node :2 only has to replicate twice, 592 which results in the last two multicast forwarding entries in Figure 593 4. 595 6. SPBV Example 597 Using the same example network as Figure 2, we will look at the FDBs 598 produced for SPBV mode forwarding. Nodes :1, :5, :3 and :7 wish to 599 transmit and receive the same multicast MAC traffic using multicast 600 address 0300-0000-000f and at the same time require congruent and 601 symmetric unicast forwarding. In SPBV mode the only encapsulation is 602 the C or S-TAG and the MAC addresses SA,DA are reverse-path learned, 603 as in traditional bridging. 605 +----+ +----+ 606 | :4 | 2 ------1 | :5 | <==> MMAC ..:f 607 +----+ +----+ 608 1 3 3 2 609 / \ / \ 610 1 4 3 2 611 +----+ +----+ +----+ 612 MMAC<==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> MMAC ..:f 613 ..:f +----+ +----+ +----+ 614 3 6 5 3 615 \ / \ / 616 3 2 1 2 617 +----+ +----+ 618 | :6 | 1-------3 | :7 | <==> MMAC ..:f 619 +----+ +----+ 621 Figure 5 - SPBV Example 7 node network 623 Assuming the same ECT-ALGORITHM (00-80-C2-01), which picks the equal 624 cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned 625 to Base-VID 100, and for each node the SPVID = Base-VID + Node Id 626 (i.e. 101, 102..107). When all links have the same cost, then the 1 627 hop shortest paths are all direct and the 2 hop shortest paths 628 (which are of course symmetric) are as previously given for Figure 629 2. 631 Node :1's SPT (Shortest Path Tree) for this ECT-ALGORITHM is 632 therefore (described as a sequence of unidirectional paths): 634 { 1->4, 1->6, 1->2->3, 1->2->5, 1->2->7 } 636 The FDBs therefore must have entries for the SPVID reserved for 637 packets originating from node :1 which in this case is VID=101. 639 Node :2 therefore has a FDB which looks like Figure 6. In particular 640 it takes packets from VID 101 on interface/01 and sends to nodes :3, 641 :5 and :7 via if/2, if/3 and if/5. It does not replicate anywhere 642 else because the other nodes :4 and :6 are reached by the SPT 643 directly from node :1. The rest of the FDB unicast entries follow a 644 similar pattern; recall that the shortest path between :4 and :6 is 645 via node :1, which explains replication onto only two interfaces 646 from if/4 and if/6. Note that the destination addresses are wild 647 cards and shared VLAN learning (SVL) exists between these SPVIDs, 648 because they are all associated with BASE VID = 100, which defines 649 the VLAN being bridged. 651 +-------+-------------------+------+-----------------+ 652 | IN/IF | DESTINATION ADDR | VID | OUT/IF(s) | 653 +-------+-------------------+------+-----------------+ 654 U| if/01 | ************** | 0101 | {if/2,if/3,if/5 } 655 U| if/02 | ************** | 0103 | {if/1,if/4,if/6 } 656 U| if/04 | ************** | 0104 | {if/2,if/5 } 657 U| if/03 | ************** | 0105 | {if/1,if/5,if/6 } 658 U| if/06 | ************** | 0106 | {if/2,if/3 } 659 U| if/05 | ************** | 0107 | {if/1,if/3,if/4 } 661 Figure 6 - SPBV Node :2 FDB unicast 663 Now, since nodes :5, :3, :7 and :1 are advertising membership in the 664 same multicast group address :f, Node 2 requires additional entries 665 to replicate just to these specific nodes for the given multicast 666 group address. These additional multicast entries are given below in 667 Figure 7. 669 +-------+-------------------+------+-----------------+ 670 | IN/IF | DESTINATION ADDR | VID | OUT/IF(s) | 671 +-------+-------------------+------+-----------------+ 672 M| if/01 | 0300-0000-000f | 0101 | {if/2,if/3,if/5 } 673 M| if/02 | 0300-0000-000f | 0103 | {if/1 } 674 M| if/03 | 0300-0000-000f | 0105 | {if/1,if/5 } 675 M| if/05 | 0300-0000-000f | 0107 | {if/1,if/3 } 677 Figure 7 - SPBV Node :2 FDB Multicast(M) 679 7. SPB Supported Adjacency types 681 IS-IS for SPB currently only supports P2P adjacencies. Other link 682 types are for future study. As a result pseudonodes and links 683 to/from pseudonodes are not considered as part of the IS-IS SPF 684 computations and will be avoided if present in the physical 685 topology. Other NLPIDs MAY of course use them as per normal. 687 IS-IS for SPB must use the IS-IS Three-Way handshake for IS-IS 688 Point-to-Point Adjacencies described in RFC 5303. 690 8. SPB IS-IS adjacency addressing 692 The default behavior of 802.1aq is to use the normal IS-IS Ethernet 693 multicast addresses for IS-IS. 695 There are however additional Ethernet multicast addresses that have 696 been assigned for 802.1aq for special use cases. These do not in 697 anyway change the state machinery or packet formats of IS-IS but 698 simply recommend and reserve different multicast addresses. Refer to 699 [802.1aq] for additional details. 701 9. IS-IS Area Address and SYSID 703 A stand-alone implementation (supporting ONLY the single NLPID=0xC1) 704 of SPB must use an IS-IS area address value of 0 and the SYSID must 705 be the well known MAC address of the SPB device. 707 Non stand-alone implementations (supporting other NLPIDs) MUST use 708 the normal IS-IS rules for the establishment of a level 1 domain 709 (i.e. multiple area addresses are allowed but where immediate 710 adjacencies share a common area address). Level 2 operations of 711 course place no such restriction on adjacent area addresses. 713 10. Level 1/2 Adjacency 715 SPBV and SPBM will operate either within an IS-IS level 1, or an 716 ISIS level 2. As a result, the TLVs specified here MAY propagate 717 either in level 1 or level 2 LSPs. IS-IS SPB implementations must 718 support level 1 and may support level 2 operations. Hierarchical SPB 719 is for further study therefore these TLV's should not be leaked 720 between level 1 and level 2. 722 11. Shortest Path Default Tie Breaking 724 (ECT-ALGORITHM = 00-80-C2-01) 725 Two mechanisms are used to ensure symmetry and determinism in the 726 shortest path calculations. 728 The first mechanism addresses the problem when different ends 729 (nodes) of an adjacency advertise different values for the SPB-LINK- 730 METRIC. To solve this SPB shortest path calculations must use the 731 maximum value of the two node's advertised SPB-LINK-METRICs when 732 accumulating and minimizing the (sub)path costs. 734 The second mechanism addresses the problem when two equal sums of 735 link metrics (sub)paths are found. To solve this, the (sub)path with 736 the fewest hops between the fork/join points must win the tie. 737 However, if both (sub)paths have the same number of hops between the 738 fork and join points then the default tie breaking must pick the 739 path traversing the intermediate node with the lower BridgeID. The 740 BridgeID is an 8 byte quantity whose upper 2 bytes are the node's 741 BridgePriority and the lower 6 bytes are the node's SYSID. 743 For example, consider the network in Figure 2 when a shortest path 744 computation is being done from node :1. Upon reaching node :7 two 745 competing sub-paths fork at node :1 and join at node :7. The first 746 via :2 and the second via :6. Assuming that all the nodes advertise 747 a Bridge Priority of 0, the default tie breaking rule causes the 748 path traversing node :2 to be selected since it has a lower BridgeID 749 {0...:2} than node :6 {0...:6}. Note that the operator may cause the 750 tie breaking logic to pick the alternate path by raising the Bridge 751 Priority of node :2 above that of node :6. 753 The above algorithm guarantees symmetric and deterministic results 754 in addition to having the critical property of transitivity 755 (shortest path is made up of sub-shortest paths). 757 12. Shortest Path ECT 759 (ECT-ALGORITHMs = 00-80-C2-01 .. 00-80-C2-10) 760 To create diversity in routing SPB defines 16 variations on the 761 above default tie breaking algorithm, these have world wide unique 762 designations 00-80-C2-01 through 00-80-C2-10. These designations 763 consist of the IEEE 802.1 OUI value 00-80-C2 concatenated with 764 indexes 0X01..0X10. These individual algorithms are implemented by 765 selecting the (sub) path with the lowest value of: 767 XOR BYTE BY BYTE(ECT-MASK{ECT-ALGORITHM.index},BridgeID) 769 Where: 771 ECT-MASK{17} = { 0x00, 0x00, 0xFF, 0x88, 772 0x77, 0x44, 0x33, 0xCC, 773 0xBB, 0x22, 0x11, 0x66, 774 0x55, 0xAA, 0x99, 0xDD, 775 0xEE }; 777 XOR BYTE BY BYTE - XORs BridgeID bytes with ECT-MASK 779 ECT-MASK{1} since it xor's with all 0's is just the same as the 780 default algorithm described above 00-80-C2-01, while ECT-MASK{0x02} 781 since it xor's with a mask of all 1's will invert the BridgeID 782 essentially picking the path traversing the largest Bridge ID. The 783 other ECT-MASKs produce diverse alternatives. In all cases the 784 BridgePriority, since it is the most significant part of the 785 BridgeID permits overriding the SYSID as the selection criteria and 786 gives the operator a degree of control on the chosen ECT paths. 788 To support many other tie breaking mechanisms in the future two 789 opaque ECT TLV's are defined which may be used to provide parameters 790 to ECT-ALGORITHMS outside of the currently defined space. 792 ECT-ALGORITHMS are mapped to VIDs and then services can be assigned 793 to those VIDs. This permits a degree of traffic engineering since 794 service assignment to VID is consistent end to end through the 795 network. 797 13. Hello (IIH) protocol extensions 799 IEEE 802.1aq can run in parallel with other Network Layer Protocols 800 such as IPV4 and IPV6, therefore failure for two SPB nodes to 801 establish an adjacency MUST NOT cause rejection of an adjacency for 802 the purposes of other Network Layer Protocols. 804 IEEE 802.1aq has been assigned the NLPID value 0xC1 [NLPID] which 805 MUST be used by shortest path bridges (SPBs) to indicate their 806 ability to run 802.1aq. This is done by including this NLPID value 807 in the IS-IS IIH PDU Protocols Supported TLV (type 129). 802.1aq 808 frames MUST only flow on adjacencies that advertise this NLPID in 809 both directions of the IIH PDUs. 802.1aq computations MUST consider 810 an adjacency that has not advertised 0xC1 NLPID in both directions 811 as non-existent (infinite link metric) and MUST ignore any IIH SPB 812 TLV's they receive over such adjacencies. 814 IEEE 802.1aq augments the normal IIH PDU with three new TLV's which 815 like all other SPB TLVs travel within multi topology [MT] TLVs, 816 therefore allowing multiple logical instances of SPB within a single 817 IS-IS protocol instance. 819 Since SPB can use many VIDs and must agree on which VIDs are used 820 for which purposes, the IIH PDU's carry a digest of all the used 821 VIDs (on the NNI's) referred to as the SPB-MCID TLV which uses a 822 common and compact encoding taken reused from 802.1Q. 824 SPB neighbors may support an optional mechanism to verify that the 825 contents of their topology databases are synchronized (for the 826 purposes of loop prevention). This is done by exchanging a digest of 827 SPB topology information (computed over all MTIDS) and taking 828 specific actions on forwarding entries when the digests indicate a 829 mismatch in topology. This digest is carried in the optional SPB 830 Digest sub-TLV. 832 Finally SPB needs to know which SPT sets (defined by ECT-ALGORITHMS) 833 are being used by which VIDs, and this is carried in the Base VLAN 834 Identifiers sub-TLV. 836 13.1. SPB MCID sub-TLV 838 This sub-TLV is added to an IIH PDU to indicate the digest for the 839 Multiple spanning tree configuration a.k.a MCID. This TLV is a 840 digest of local configuration of which VIDs are running which 841 protocols. (The information is not to the level of a specific 842 algorithm in the case of SPB). This information should be the same 843 on all bridges in the topology identified by the MT-Port-Cap TLV 844 [LAYER2] it is being carried within. The data used to generate the 845 MCID is populated by configuration and is a digest of the VIDs 846 allocated to various protocols. Two MCIDs are carried to allow non 847 disruptive transitions between configurations when the changes are 848 non-critical. 850 0 1 2 3 851 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 853 +-+-+-+-+-+-+-+-+ 854 |Type=SPB-MCID | = 6 855 +-+-+-+-+-+-+-+-+ 856 | Length | (1 byte) 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | MCID (51 Bytes) | 859 | ............... | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Aux MCID (51 Bytes) | 862 | ............... | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 o Type: sub-TLV Type = 6 (Pending IANA). 867 o Length: The size of the value defined below (102). 869 o MCID (51-bytes) The complete MCID defined in IEEE 802.1Q which 870 identifies an SPT Region on the basis of matching assignments of 871 VIDs to control regimes (xSTP, SPBV, SPBM, etc). Briefly, the 872 MCID consists of a 1 byte format selector, a 32 byte 873 configuration name, a 2 byte revision level and finally a 16 byte 874 signature of type HMAC-MD5 over an array of 4096 elements that 875 contain identifiers of the use of the corresponding VID. Refer to 876 section 13.8 of [802.1aq] for the exact format and procedure. 877 Note that the use of the VID does not include specification of a 878 specific SPB ECT-ALGORITHM, rather it is coarser grain. 880 o Aux MCID (51-bytes) The complete MCID defined in IEEE 802.1Q 881 which identifies an SPT Region. The aux MCID allows SPT Regions 882 to be migrated by the allocation of new VLAN to FDB Mappings 883 without interruption to existing traffic. 885 The SPB MCID sub-TLV is carried within the MT-Port-Cap TLV [LAYER2] 886 which in turn is carried in an IIH PDU. 888 13.2. SPB Digest sub-TLV 890 This sub-TLV is optionally added to an IIH PDU to indicate the 891 current SPB topology digest value. It is always carried in an MT- 892 Port-Cap TLV [LAYER2] with an MT-ID value of 0. This information 893 should settle to be the same on all bridges in an unchanging 894 topology. Matching digests indicate (with extremely high 895 probability) that the topology view between two SPBs is 896 synchronized, and is used to control the updating of forwarding 897 information. The SPB Agreement Digest is computed based on 898 contributions derived from the current topologies of all SPB MT 899 instances, and is designed to change when significant topology 900 changes occur within any SPB instance. 902 During the propagation of LSPs the Agreement Digest may vary between 903 neighbors until the key topology information in the LSPs are common. 904 The digest is therefore a summarized means of determining agreement 905 between nodes on database commonality, and hence infer agreement on 906 the distance to all multicast roots. When present it is used for 907 loop prevention as follows: For each shortest path tree where it 908 has been determined the distance to the root has changed, "unsafe" 909 multicast forwarding is blocked until the exchanged Agreement 910 Digests match while "safe" multicast forwarding is allowed to 911 continue despite the disagreement in digests and hence topology 912 views. [802.1aq] section 28.2 defines in detail what constitutes 913 "safe" vs. "unsafe". 915 0 1 2 3 916 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 918 +-+-+-+-+-+-+-+-+ 919 |Type=SPB-Digest| = 7 920 +-+-+-+-+-+-+-+-+ 921 | Length | (1 byte) 922 +-----+-+---+---+ 923 | Res |V| A | D | (1 byte) 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Agreement Digest (Length - 1) | 926 | ............... | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 o Type: sub-TLV Type = 7 (Pending IANA). 931 o Length: The size of the value. 933 o V - agreed digest valid bit. See [802.1aq] Sec 28.2. 935 o A (2 bits) The Agreement Number 0-3 which aligns with BPDUs 936 Agreement Number concept [802.1aq]. When the Agreement Digest 937 for this node changes this number is incremented. The node then 938 checks for Agreement Digest match (as below). The new local 939 Agreement Number and the updated local Discarded Agreement Number 940 are then transmitted with the new Agreement Digest to the node's 941 neighbors in the hello PDU. Once an Agreement Number has been 942 sent it is considered outstanding until a matching or more recent 943 Discarded Agreement Number is received from the neighbor. 945 o D (2 bits) The Discarded Agreement Number 0-3 which aligns with 946 BPDUs Agreement Number concept. When an Agreement Digest is 947 received from a neighbor, this number is set to the received 948 Agreement Number, to signify that this node has received this new 949 agreement and discarded any previous ones. The node then checks 950 whether the local and received Agreement Digests match. If they 951 do, this node then sets : 953 the local Discarded Agreement Number = received Agreement 954 Number + 1 956 If the Agreement Digests match, AND 957 received Discarded Agreement Number == local Agreement Number 958 + N (N = 0 || 1) 960 then the node has a topology matched to its neighbor. 962 Whenever the local Discarded Agreement Number relating to a 963 neighbor changes, the local Agreement Digest, Agreement Number, 964 and Discarded Agreement Number are transmitted. 966 o Agreement Digest. This digest is used to determine when SPB is 967 synchronized between neighbors for all SPB instances. The 968 agreement digest is a hash computed over the set of all SPB 969 adjacencies in all SPB instances. In other words, the digest 970 includes all VIDs and all adjacencies for all MT instances of SPB 971 (but not other network layer protocols). This reflects the fact 972 that all SPB nodes in a region must have identical VID 973 allocations (see 13.1), and so all SPB instances will contain the 974 same set of nodes. The size and exact procedure for computing the 975 Agreement Digest is defined in section 28.2 of [802.1aq]. 977 The SPB Digest sub-TLV is carried within the MT-Port-Cap TLV 978 [LAYER2] (with the MT-ID value 0) which in turn is carried in an IIH 979 PDU. 981 When supported, this sub-TLV MUST be carried on every IIH between 982 SPB neighbors, not just when a Digest changes. 984 When one peer supports this TLV and the other does not, loop 985 prevention by digest agreement must not be done by either side. 987 13.3. SPB Base VLAN-Identifiers sub-TLV 989 This sub-TLV is added to an IIH PDU to indicate the mappings between 990 ECT algorithms and Base-VIDs (and by implication the VID(s) used on 991 the forwarding path for each SPT Set for a VLAN identified by a Base 992 VID) that are in use. Under stable operational conditions, this 993 information should be the same on all bridges in the topology 994 identified by the MT-Port-Cap TLV [LAYER2] it is being carried 995 within. 997 0 1 2 3 998 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 1000 +-+-+-+-+-+-+-+-+ 1001 |Type= SPB-B-VID| = 8 1002 +-+-+-+-+-+-+-+-+ 1003 | Length | (1 byte) 1004 +-+-+-+-+-+-+-+-+-----------------------------------------------+ 1005 | ECT - VID Tuple (1) (6 bytes) | 1006 +---------------------------------+-----------------------------+ 1007 | ... | ECT-VID Tuple(2) (6 bytes) | 1008 +---------------------------------+-----------------------------+ 1009 | ..... | 1010 +---------------------------------------------------------------+ 1011 | ..... | 1012 | ..... | 1013 +---------------------------------------------------------------+ 1015 o Type: sub-TLV Type = 8 (Pending IANA). 1017 o Length: The size of the value is ECT-VID Tuples*6 bytes. Each 6- 1018 byte part of the ECT-VID tuple is formatted as follows: 1020 0 1 2 3 1021 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | ECT - Algorithm (32 bits) | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Base VID (12 bits) |U|M|RES| 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 o ECT-ALGORITHM (4 bytes) The ECT-ALGORITHM is advertised when the 1030 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 1031 Base-VID. There are 17 predefined IEEE algorithms for SPB with 1032 index values 0X00..0X10 occupying the low 8 bits and the IEEE 1033 OUI=00-80-C2 occupying the top 24 bits of the ECT-ALGORITHM. 1035 o Base-VID (12-bits) The Base-VID that is associated with the SPT 1036 Set. 1038 o Use-Flag (1-bit) The Use-flag is set if this bridge, or any 1039 bridge in the LSDB is currently using this ECT-ALGORITHM and 1040 Base-VID. Remote usage is discovered by inspection of the U-Bit 1041 in the SPB Instance sub-TLV of other SPB bridges (see section 1042 14.1) 1044 o M-Bit (1-bit) The M-bit indicates if this Base-VID operates in 1045 SPBM (M = 1) or SPBV (M = 0) mode. 1047 The SPB Base VLAN-Identifier sub-TLV is carried within the MT-Port- 1048 Cap TLV [LAYER2] which in turn is carried in an IIH PDU. 1050 14. Node information extensions 1052 All SPB nodal information extensions travel within a new multi 1053 topology capability TLV MT-Capability (type = 144). 1055 0 1 2 3 1056 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 1058 +-+-+-+-+-+-+-+-+ 1059 |Type = MT-CAP | = 144 1060 +-+-+-+-+-+-+-+-+ 1061 | Length | (1 byte) 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 |O R R R| MT ID | (2 bytes) 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 (sub-TLVs ... ) 1067 The format of this TLV is identical in its first 2 bytes to all 1068 current MT TLV's and carries the MT ID as defined in [MT]. 1070 The O (overload) bit carried in bit 16 has the same semantics as 1071 specified in [MT], but in the context of SPB adjacencies only. 1073 14.1. SPB Instance sub-TLV 1075 The SPB Instance sub-TLV gives the SPSourceID for this node/topology 1076 instance. This is the 20 bit value that is used in the formation of 1077 multicast DA addresses for frames originating from this 1078 node/instance. The SPSourceID occupies the upper 20 bits of the 1079 multicast DA together with 4 other bits (see the SPBM 802.1ah 1080 multicast DA address format section). This sub-TLV MUST be carried 1081 within the MT-Capability TLV in the fragment ZERO LSP. If there is 1082 an additional SPB instance it must be declared under a separate MT- 1083 Topology and also carried in the fragment ZERO LSP. 1085 0 1 2 3 1086 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 1088 +-+-+-+-+-+-+-+-+ 1089 |Type = SPB-Inst| = 1 1090 +-+-+-+-+-+-+-+-+ 1091 | Length | (1 byte) 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | CIST Root Identifier (4 bytes) | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | CIST Root Identifier (cont) (4 bytes) | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | CIST External ROOT Path Cost (4 bytes) | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Bridge Priority | (2 bytes) 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 |R R R R R R R R R R R|V| SPSourceID | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Num of Trees | (1 byte) 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | VLAN-ID (1) Tuples (8 bytes) | 1106 | ........................... | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 ........................... 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | VLAN-ID (N) Tuples (8 bytes) | 1111 | ........................... | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 where VLAN-ID tuples have the format as: 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+ 1119 |U|M|A| Res | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | ECT - Algorithm (32 bits) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Base-VID (12 bits) | SPVID (12 bits) | 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 o Type: sub-TLV Type 1 (Pending IANA). 1128 o Length: Total number of bytes contained in the value field. 1130 o CIST Root Identifier (64-bits)The CIST Root Identifier is for SPB 1131 interworking with RSTP and MSTP at SPT Region Boundaries. This 1132 is an imported value from a Spanning tree. 1134 o CIST External Root Path Cost (32-bits) The CIST External Root 1135 Path Cost is the cost to root, derived from the spanning tree 1136 algorithm. 1138 o Bridge Priority (16-bits) Bridge priority is the 16 bits that 1139 together with the 6 bytes of the System ID form the Bridge 1140 Identifier. This is configured exactly as specified in IEEE802 1141 [802.1D]. This allows SPB to build a compatible Spanning tree 1142 using link state by combining the Bridge Priority and the System 1143 ID to form the 8 byte Bridge Identifier. The 8 byte Bridge 1144 Identifier is also the input to the 16 pre-defined ECT tie 1145 breaker algorithms. 1147 o V bit (1-Bit) The V bit (SPBM) indicates this SPSourceID is auto 1148 allocated(27.11). If the V bit is clear the SPSourceID has been 1149 configured and must be unique. Allocation of SPSourceID is 1150 defined in IEEE [802.1aq]. Bridges running SPBM will allocate an 1151 SPSourceID if they are not configured with an explicit 1152 SPSourceID. The V Bit allows neighbor bridges to determine if the 1153 auto allocation was enabled. In the rare chance of a collision 1154 of SPsourceID allocation, the bridge with the highest priority 1155 Bridge Identifier will win conflicts and the lower priority 1156 Bridge will be re-allocated or if the lower priority Bridge is 1157 configured it will not be allowed to join the SPT Region. 1159 o The SPSourceID is a 20 bit value used to construct multicast DA's 1160 as described below for multicast frames originating from the 1161 origin (SPB node) of the link state packet (LSP) that contains 1162 this TLV. More details are in IEEE [802.1aq]. 1164 o Number of Trees (8-bits) The Number of Trees is set to the number 1165 of [ECT-ALGORITHM, Base-VID plus flags] tuples that follow. Each 1166 ECT-ALGORITHM has a Base-VID, an SPVID and flags described below. 1167 This must contain at least the one ECT-ALGORITMM (00-80-C2-01). 1169 Each VID Tuple consists of: 1171 o U-Bit (1-bit) The U-bit is set if this bridge is currently using 1172 this ECT-ALGORITHM for I-SIDs it sources or sinks. This is a 1173 strictly local indication; the semantics differ from the Use-flag 1174 found in the Hello, which will set the Use-Flag if it sees other 1175 nodal U-bits are set OR it sources or sinks itself. 1177 o M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode. 1178 When cleared the mode is SPBV and when set the mode is SPBM. 1180 o A bit, The A bit (SPB) when set declares this is an SPVID with 1181 auto allocation. The VID allocation logic details are in IEEE 1182 [802.1aq]. Since SPVIDs are allocated from a small pool of 12 1183 bit resources the chances of collision are high. To minimize 1184 collisions during auto allocation LSPs are initially advertised 1185 with the originating bridge setting the SPVID to 0. Only after 1186 learning the other bridges' SPVID allocations does this bridge 1187 re-advertise this sub-TLV with a non-zero SPVID. This will 1188 minimize but not eliminate the chance of a clash. In the event of 1189 a clash, the highest Bridge Identifier is used to select the 1190 winner, while the loser(s) with lower Bridge Identifier(s) must 1191 withdraw their SPVID allocation(s), and select an alternative 1192 candidate for another trial. SPVID may also be configured. When 1193 the A bit is set to not specify auto allocation and the SPVID is 1194 set to 0 this SPBV bridge is used for transit only within the SPB 1195 region. If a port is configured with the BASE-VID as a neighbor 1196 using RSTP or MSTP the bridge will act as an ingress filter for 1197 that VID. 1199 o ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is advertised when the 1200 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 1201 VID. This declaration must match the declaration in the Hello PDU 1202 originating from the same bridge. The ECT-ALGORITHM and BASE-VID 1203 must match what is generated in the IIHs of the same node. The 1204 ECT-ALGORITHM, BASE-VID tuples can come in any order however. 1205 There are currently 17 world wide unique 802.1aq defined ECT- 1206 ALGORITHMS given by values 00-80-C2-00 through 00-80-C2-10. 1208 o Base VID (12-bits) The Base-VID that associated the SPT Set via 1209 the ECT-ALGORITHM. 1211 o SPVID (12-bits) The SPVID is the Shortest Path VID assigned for 1212 the Base-VID to this node when using SPBV mode. It is not 1213 defined for SPBM Mode and must be 0 for SPBM mode B-VIDs. 1215 14.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV 1217 There are multiple ECT algorithms defined for SPB, however for the 1218 future additional algorithms may be defined including but not 1219 limited to ECMP / hash based behaviors and (*,G) multicast trees. 1220 These algorithms will use this optional TLV to define new algorithm 1221 parametric data. For tie breaking parameters there are two broad 1222 classes of algorithm, one which uses nodal data to break ties and 1223 one which uses link data to break ties, this TLV is used to 1224 associate opaque tie breaking data with a node. This sub-TLV, when 1225 present, MUST be carried within the MT-Capability TLV (along with a 1226 valid SPB Instance sub-TLV). Multiple copies of this sub-TLV MAY be 1227 carried for different ECT-ALGORITHMs relating to this node. 1229 There are of course many other uses of this opaque data which have 1230 yet to be defined. 1232 0 1 2 3 1233 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 1235 +-+-+-+-+-+-+-+-+ 1236 |Type=SPB-I-OALG| = 2 1237 +-+-+-+-+-+-+-+-+ 1238 | Length | (1 byte) 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Opaque ECT Algorithm (4 bytes) | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Opaque ECT Information (variable) | 1243 | ....................... | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 o Type: sub-TLV Type 2 (Pending IANA). 1248 o Length: Total number of bytes contained in the value field. 1250 o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge 1251 supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. 1253 o ECT Information: ECT-ALGORITHM Information of variable length 1254 which SHOULD be in sub-TLV format with an IANA numbering space 1255 where appropriate. 1257 15. Adjacency information extensions 1259 15.1. SPB Link Metric sub-TLV 1261 The SPB Link Metric sub-TLV (type = 12) occurs within the Multi 1262 Topology Intermediate System TLV (type 222) or within the Extended 1263 IS Reachability TLV (type 22). If this sub TLV is not present for 1264 an ISIS adjacency then that adjacency must not carry SPB traffic for 1265 the given topology instance. 1267 0 1 2 3 1268 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 1270 +-+-+-+-+-+-+-+-+ 1271 |Type=SPB-Metric| = 12 1272 +-+-+-+-+-+-+-+-+ 1273 | Length | (1 byte) 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | SPB-LINK-METRIC | (3 bytes) 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Num of ports | (1 byte) 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Port Identifier | ( 2 bytes) 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 o Type: sub-TLV Type 12 (Pending IANA). 1284 o Length: Total number of bytes contained in the value field. 1286 o SPB-LINK-METRIC indicates the administrative cost or weight of 1287 using this link as a 24 bit unsigned number. This metric applies 1288 to the use of this link for SPB traffic only. Smaller numbers 1289 indicate lower weights and are more likely to carry SPB traffic. 1290 Only one metric is allowed per SPB instance per link. If 1291 multiple metrics are required multiple SPB instances are 1292 required, either within IS-IS or within several independent IS-IS 1293 instances. If this metric is different at each end of a link, the 1294 maximum of the two values must be used in all SPB calculations 1295 for the weight of this link. The maximum SPB-LINK-METRIC value 1296 2^24 - 1 has a special significance; this value indicates that 1297 although the IS-IS adjacency has formed, incompatible values have 1298 been detected in parameters configured within SPB itself for 1299 example different regions, and the link must not be used for 1300 carrying SPB traffic. Full details are found in [802.1aq]. 1302 o Num of Ports is the number of ports associated with this link. 1304 o Port Identifier is the standard IEEE port identifier used to 1305 build a spanning tree associated with this link. 1307 15.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV 1309 There are multiple ECT algorithms defined for SPB, however for the 1310 future additional algorithms may be defined. The SPB Adjacency 1311 Opaque ECT-ALGORITHM sub-TLV occurs within the Multi Topology 1312 Intermediate System TLV (type 222) or the Extended IS Reachability 1313 TLV (type 22). Multiple copies of this sub-TLV MAY be carried for 1314 different ECT-ALGORITHMs related to this adjacency. 1316 0 1 2 3 1317 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 1319 +-+-+-+-+-+-+-+-+ 1320 |Type=SPB-A-OALG| = 13 1321 +-+-+-+-+-+-+-+-+ 1322 | Length | (1 byte) 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Opaque ECT Algorithm (4 bytes) | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Opaque ECT Information (variable) | 1327 | ......................... | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 o Type: sub-TLV Type = 13 (PENDING IANA). 1332 o Length: Total number of bytes contained in the value field. 1334 o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge 1335 supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. 1337 o ECT Information: ECT-ALGORITHM Information of variable length in 1338 sub-TLV format using new IANA type values as appropriate. 1340 16. Service information extensions 1342 16.1. SPBM Service Identifier and Unicast Address sub-TLV 1344 The SPBM Service Identifier and Unicast Address sub-TLV (type=3) is 1345 used to introduce service group membership on the originating node 1346 and/or to advertise an additional B-MAC unicast address present on, 1347 or reachable by the node. 1349 0 1 2 3 1350 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 1352 +-+-+-+-+-+-+-+-+ 1353 |Type = SPBM-SI | = 3 1354 +-+-+-+-+-+-+-+-+ 1355 | Length | (1 byte) 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | B-MAC ADDRESS | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | B-MAC ADDRESS (6 bytes) | Res. | Base-VID (12 bits) | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 |T|R| Reserved | ISID #1 | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 |T|R| Reserved | ISID #2 | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 ................. 1366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1367 |T|R| Reserved | ISID #n | 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 o Type: sub-TLV Type = 3 (Pending IANA) 1372 o Length: Total number of bytes contained in the value field. 1374 o B-MAC ADDRESS is a unicast address of this node. It may be 1375 either the single nodal address, or may address a port or any 1376 other level of granularity relative to the node. In the case 1377 where the node only has one B-MAC address this should be the same 1378 as the SYS-ID of the node. To add multiple B-MACs this TLV MUST 1379 be repeated per additional B-MAC. 1381 o Base VID (12-bits) The Base-VID associated with the B-BMAC this 1382 allows the linkage to the ECT-Algorithm and SPT Set defined in 1383 the SPB Instance sub-TLV. 1385 o ISID #1 .. #N are 24 bit service group membership identifiers. 1386 If two nodes have an I-SID in common, intermediate nodes on the 1387 unique shortest path between them will create forwarding state 1388 for the related B-MAC addresses and will also construct multicast 1389 forwarding state using the I-SID and the node's SPSourceID to 1390 construct a multicast DA as described in IEEE 802.1aq LSB. Each 1391 I-SID has a Transmit(T) and Receive(R) bit which indicates if the 1392 membership is as a Transmitter/Receiver or both (with both bits 1393 set). In the case where the Transmit(T) and Receive(R) bits are 1394 both zero, the I-SID instance is ignored for the purposes of 1395 distributed multicast computation, but the unicast B-MAC address 1396 must be processed and installed at nodes providing transit to 1397 that address. If more I-SIDs are associated with a particular B- 1398 MAC than can fit in a single sub-TLV, this sub-TLV can be 1399 repeated with the same B-MAC but with different I-SID values. 1401 o Note when the T bit is not set an SPB may still multicast to all 1402 the other receive members of this I-SID (those advertising with 1403 their R bits set), by configuring edge replication and serial 1404 unicast to each member locally. 1406 The SPBM Service Identifier sub-TLV, when present, MUST be carried 1407 within the MT Capability TLV and can occur multiple times in any LSP 1408 fragment. 1410 16.2. SPBV Mac Address sub-TLV 1412 The SPBV MAC Address (SPBV-MAC-ADDR) sub-TLV is IS-IS sub-TLV type 4 1413 (PENDING IANA). It should be used for advertisement of Group MAC 1414 Addresses in SPBV mode. Unicast MAC addresses will normally be 1415 distributed by reverse path learning, but carrying them in this TLV 1416 is not precluded. It has the following format : 1418 0 1 2 3 1419 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 1421 +-+-+-+-+-+-+-+-+ 1422 | Type=SPBV-ADDR| = 4 (1 byte) 1423 +-+-+-+-+-+-+-+-+ 1424 | Length | (1 byte) 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 |R|R|S-R| SPVID | (2 bytes) 1427 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+ 1428 |T|R| Reserved | MAC 1 Address | (1+6 bytes) 1429 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+ 1430 ... 1431 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+ 1432 |T|R| Reserved | MAC N Address | (1+6 bytes) 1433 +-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+ 1435 o Type: sub-TLV Type, set to 4. 1437 o Length: Total number of bytes contained in the value field. The 1438 number of MAC address associated with the SPVID is computed by 1439 (Length - 2)/7. 1441 o S-R bits (2-bits) The SR bits are the service requirement 1442 parameter from MMRP. The service requirement parameters have the 1443 value 0 (Forward all Groups) and 1 (Forward All Unregistered 1444 Groups) defined. However this attribute may also be missing. So 1445 the SR bits are defined as 0 not declared, 1 Forward all Groups 1446 and 2 Forward All Unregistered Groups. The two 'R' reserved bits 1447 immediately preceding these SR bits should be set to zero when 1448 originating this sub-TLV and ignored on receipt. 1450 o SPVID (12-bits) The SPVID and by association Base-VID and the 1451 ECT-ALGORITHM and SPT Set that the MAC addresses defined below 1452 will use. If the SPVID is not allocated the SPVID Value is 0. 1453 Note that if the ECT-Algorithm in use is Spanning Tree Algorithm 1454 this value must be populated with the Base-VID and the MAC must 1455 be populated. 1457 o T Bit (1-bit) This is the Transmit allowed Bit for a following 1458 group MAC address. This is an indication that the Group MAC 1459 Address in the context of the SPVID of the bridge advertising 1460 this Group MAC must be installed in the FDB of transit bridges, 1461 when the bridge computing the trees is on the corresponding ECT- 1462 ALGORITHM shortest path between the bridge advertising this MAC 1463 with the T bit set and any receiver of this Group MAC Address. A 1464 bridge that does not advertise this bit set for a MAC Address 1465 must not cause multicast forwarding state to be installed on 1466 other transit bridges in the network for traffic originating from 1467 that bridge. 1469 o R Bit (1-bit) This is the Receive allowed Bit for the following 1470 MAC Address. This is an indication that MAC Addresses as receiver 1471 must be populated and installed when the bridge computing the 1472 trees lies on the corresponding shortest path for this ECT- 1473 ALGORITHM between this receiver and any transmitter to this MAC 1474 Address. An entry that does not have this bit set for a Group 1475 MAC Address is prevented from receiving on this Group MAC Address 1476 because transit bridges must not install multicast forwarding 1477 state towards it in their FDBs, or the traffic must be explicitly 1478 filtered. 1480 o MAC Address (48-bits) The MAC address declares this bridge as 1481 part of the multicast interest for this destination MAC address. 1482 Multicast trees can be efficiently constructed for destination by 1483 populating FDB entries for the subset of the shortest path tree 1484 that connects the bridges supporting the MAC address. This 1485 replaces the function of MMRP for SPTs. The T and R bits above 1486 have meaning as specified above. 1488 The SPBV-MAC-ADDR sub-TLV, when present, MUST be carried within the 1489 MT-Capability TLV and can occur multiple times in any LSP fragment. 1491 17. Security Considerations 1493 This document adds no additional security risks to IS-IS, nor does 1494 it provide any additional security for IS-IS when used in a 1495 configured environment or a single operator domain such as a Data 1496 Center. 1498 However this protocol may be used in a zero configuration 1499 environment. Zero configuration may apply to the automatic detection 1500 and formation of an IS-IS adjacency (forming an NNI port). Likewise 1501 zero configuration may apply to the automatic detection of VLAN 1502 tagged traffic and the formation of a UNI port, with resultant ISID 1503 advertisements. 1505 If zero configuration methods are used to auto configure NNIs or 1506 UNIs there are intrinsic security concerns that should be mitigated 1507 with authentication procedures for the above cases. Such procedures 1508 are beyond the scope of this document. 1510 In addition, this protocol can create significant amounts of 1511 multicast state when an ISID is advertised with the TX bit set. 1512 Extra care should be taken to ensure that this cannot be used as a 1513 DOS attack in a zero configuration environment. 1515 18. IANA Considerations 1517 Note that the NLPID value 0xC1 [NLPID] used in the IIH PDUs has 1518 already been assigned by IANA for the purpose of 802.1aq therefore 1519 no further action is required for this code point. 1521 Since 802.1aq operates within the IS-IS Multi Topology framework 1522 every sub-TLV MUST occur in the context of the proper MT TLV (with 1523 the exception of the SPB Link Metric sub-TLV which MAY travel in TLV 1524 22 where its MT-ID is unspecified but implied to be 0). There are 1525 three Multi Topology TLV's in which 802.1aq requests allocation of 1526 sub-TLV's. These are the MT-Port-Cap TLV [LAYER2] used in the IIH, 1527 the MT-Capability TLV (new) used within the LSP and finally the MT- 1528 Intermediate-System TLV [MT] used to contain adjacency information 1529 within the LSP. 1531 This document creates the following TLVs & sub-TLV's within the IIH 1532 and LSP PDUs MT TLV's as described below. The '*' indicates IANA 1533 action is required. Other entries are shown to provide context only. 1534 A '?' next to a number indicates a requested but of course not 1535 necessarily the final assigned value. 1537 The MT-Capability TLV is the only TLV requiring a new sub-registry. 1538 Type value 144 (TBD) is requested, with a starting sub-TLV value of 1539 1, and managed by Standards Action. 1541 +-----+----+-----------------+--------+------+-------------+ 1542 | PDU |TLV | SUB-TLV | TYPE | TYPE | #OCCURRENCE | 1543 +-----+----+-----------------+--------+------+-------------+ 1544 IIH 1545 MT-Port-Cap 147? 1546 * SPB-MCID 6? 1 1547 * SPB-Digest 7? >=0 1548 * SPB-B-VID 8? 1 1550 LSP 1551 * MT-Capability 144? 1552 * SPB-Inst 1? 1 1553 * SPB-I-OALG 2? >=0 1554 * SPBM-SI 3? >=0 1555 * SPBV-ADDR 4? >=0 1557 MT-Intermediate-System 222 1558 or Extended IS Reachability 22 1559 * SPB-Metric 12? 1 1560 * SPB-A-OALG 13? >=0 1562 19. References 1564 19.1. Normative References 1566 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1567 Requirement Levels", BCP 14, RFC 2119, March 1997. 1569 [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System 1570 to Intermediate System Intra-Domain Routing Exchange 1571 Protocol for use in Conjunction with the Protocol for 1572 Providing the Connectionless-mode Network Service (ISO 1573 8473)", 2002. 1575 [MT] M-ISIS: Multi Topology (MT) Routing in Intermediate System 1576 to Intermediate Systems (IS-ISs), RFC 5120, February 2008. 1578 [802.1aq] "Standard for Local and Metropolitan Area Networks / 1579 Virtual Bridged Local Area Networks / Amendment: Shortest 1580 Path Bridging, Draft IEEE P802.6aq/3.2", 2010. 1582 [NLPID] www.ietf.org/id/draft-eastlake-nlpid-iana-considerations- 1583 04.txt 1585 [LAYER2] www.ietf.org/id/draft-ietf-isis-layer2-09.txt. 1587 19.2. Informative References 1589 [MMRP] "Standard for Local and Metropolitan Area Networks Virtual 1590 Bridged Local Area Networks - Amendment 07: Multiple 1591 Registration Protocol", IEEE STD 802.1ak, 2007 1593 [PB] "Standard for Local and Metropolitan Area Networks / 1594 Virtual Bridged Local Area Networks / Amendment 4: 1595 Provider Bridges, IEEE STD 802.1ad", 2005. 1597 [PBB] "Standard for Local and Metropolitan Area Networks / 1598 Virtual Bridged Local Area Networks / Amendment 7: 1599 Provider Backbone Bridges, IEEE STD 802.1ah", 2008. 1601 [802.1ag] "Standard for Local and Metropolitan Area Networks / 1602 Virtual Bridged Local Area Networks / Amendment 5: 1603 Connectivity Fault Management", IEEE STD 802.1ag, 2007 1605 [Y.1731] ITU-T Y.1731 (2006), "OAM Functions and Mechanisms for 1606 Ethernet based networks" 1608 20. Acknowledgments 1610 The authors would like to thank Ayan Banerjee, Mick Seaman, Janos 1611 Farkas, Les Ginsberg, Stewart Bryant , Donald Eastlake, Matthew 1612 Bocci and Mike Shand for contributions and/or detailed review. 1614 This document was prepared using 2-Word-v2.0.template.dot. 1616 21. Author's Addresses 1618 Don Fedyk 1619 Alcatel-Lucent 1620 Groton, MA, 01450, USA 1621 Email: Donald.Fedyk@alcatel-lucent.com 1623 Peter Ashwood-Smith 1624 Huawei Technologies Canada Ltd, 1625 303 Terry Fox Drive, Suite 400 1626 Kanata, Ontario, K2K 3J1, CANADA 1627 Email: Peter.AshwoodSmith@huawei.com 1628 Dave Allan 1629 Ericsson, 1630 300 Holger Way 1631 San Jose, CA 1632 95134 1633 Email: david.i.allan@ericsson.com 1635 Nigel Bragg 1636 Ciena Limited, 1637 Ciena House 1638 43-51 Worship Street 1639 London EC2A 2DX 1640 Email: nbragg@ciena.com 1642 Paul Unbehagen 1643 Alcatel-Lucent 1644 8742 Lucent Boulevard 1645 Highlands Ranch, CO 80129, USA 1646 Email: Paul.Unbehagen@alcatel-lucent.com 1648 22. Intellectual Property Statement 1650 The IETF Trust takes no position regarding the validity or scope of 1651 any Intellectual Property Rights or other rights that might be 1652 claimed to pertain to the implementation or use of the technology 1653 described in any IETF Document or the extent to which any license 1654 under such rights might or might not be available; nor does it 1655 represent that it has made any independent effort to identify any 1656 such rights. 1658 Copies of Intellectual Property disclosures made to the IETF 1659 Secretariat and any assurances of licenses to be made available, or 1660 the result of an attempt made to obtain a general license or 1661 permission for the use of such proprietary rights by implementers or 1662 users of this specification can be obtained from the IETF on-line 1663 IPR repository at http://www.ietf.org/ipr 1665 The IETF invites any interested party to bring to its attention any 1666 copyrights, patents or patent applications, or other proprietary 1667 rights that may cover technology that may be required to implement 1668 any standard or specification contained in an IETF Document. Please 1669 address the information to the IETF at ietf-ipr@ietf.org. 1671 23. Disclaimer of Liability 1673 This document and the information contained herein are provided on 1674 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1675 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1676 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1677 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not LIMITED TO ANY 1678 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not INFRINGE 1679 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS.