idnits 2.17.1 draft-ietf-isis-ieee-aq-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([IS-IS], [PBB], [PB]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2010) is 4931 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' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Fedyk, Ed. 3 Internet Draft Alcatel-Lucent 4 Intended status: Standards Track P.Ashwood-Smith Ed. 5 Expires: April 2011 Huawei 7 October 24, 2010 9 IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging 10 draft-ietf-isis-ieee-aq-01.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 April 23 2011. 35 Copyright Notice 37 Copyright (c) 2010 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 network context utilizing multiple equal cost 56 paths. This permits it to support much larger layer 2 topologies, 57 with faster convergence, and vastly improved use of the mesh 58 topology. Combined with this is single point provisioning for 59 logical connectivity membership (E-LINE/E-LAN/E-TREE etc). 61 The control protocol for 802.1aq is IS-IS [IS-IS] augmented with a 62 small number of TLVs while the encapsulating data paths are 63 respectively 802.1ad (Provider Bridges) [PB] and 802.1ah (Provider 64 Backbone Bridges) [PBB]. This memo documents those TLVs while 65 providing some overview. 67 Note that 802.1aq requires no state machine or other substantive 68 changes to [IS-IS]. It is our intention that 802.1aq be simply a new 69 NLPID and set of TLVs. In the event of any confusion the reader 70 should take [IS-IS] as authoritative. 72 Table of Contents 74 1. Introduction...................................................4 75 2. Terminology....................................................4 76 3. Conventions used in this document..............................5 77 4. 802.1aq Overview...............................................5 78 4.1. Data Path SPBM - Unicast..................................7 79 4.2. Data Path SPBM - Multicast (Head End Replication).........7 80 4.3. Data Path SPBM - Multicast (Tandem Replication)...........8 81 4.4. Data Path SPBV Broadcast..................................9 82 4.5. Data Path SPBV Unicast....................................9 83 4.6. Data Path SPBV Multicast.................................10 84 5. SPBM Example..................................................10 85 6. SPBV Example..................................................12 86 7. SPB Supported Adjacency types.................................14 87 8. SPB IS-IS adjacency addressing................................14 88 9. IS-IS Area Address and SYSID..................................15 89 10. Level 1/2 Adjacency..........................................15 90 11. Shortest Path Default Tie Breaking...........................15 91 12. Shortest Path ECT............................................16 92 13. Hello (IIH) protocol extensions..............................17 93 13.1. SPB MCID sub-TLV........................................18 94 13.2. SPB Digest sub-TLV......................................19 95 13.3. SPB Base VLAN-Identifiers sub-TLV.......................21 96 14. Node information extensions..................................22 97 14.1. SPB Instance sub-TLV....................................22 98 14.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV..........25 99 15. Adjacency information extensions.............................26 100 15.1. SPB Link Metric sub-TLV.................................26 101 15.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV.........27 102 16. Service information extensions...............................28 103 16.1. SPBM Service Identifier and Unicast Address sub-TLV.....28 104 16.2. SPBV Mac Address sub-TLV................................29 105 17. Security Considerations......................................31 106 18. IANA Considerations..........................................31 107 19. References...................................................32 108 19.1. Normative References....................................32 109 19.2. Informative References..................................32 110 20. Acknowledgments..............................................33 111 21. Author's Addresses...........................................33 112 22. Intellectual Property Statement..............................33 113 23. Disclaimer of Liability......................................34 115 1. Introduction 117 2. Terminology 119 In addition to well understood IS-IS terms, this memo uses 120 terminology from IEEE 802.1 and introduces a few new terms: 122 802.1ad Provider Bridging (PB), Q-in-Q encapsulation) 123 802.1ah Provider Backbone Bridges (PBB), MAC-IN-MAC 124 encapsulation 125 802.1aq Shortest Path Bridging (SPB) 126 Base-VID VID used to identify a VLAN in management operations 127 B-DA Backbone Destination Address 802.1ah PBB 128 B-MAC Backbone MAC Address 129 B-SA Backbone Source address in 802.1ah PBB header 130 B-VID Backbone VLAN ID in 802.1ah PBB header 131 B-VLAN Backbone Virtual LAN 132 BridgeID 64 bit quantity = Bridge Priority:16 o SYSID:48 133 BridgePriority 16 bit relative priority of a node for tie breaking 134 C-MAC Customer MAC. Inner MAC in 802.1ah PBB header 135 C-VID Customer VLAN ID 136 C-VLAN Customer Virtual LAN 137 DA Destination Address 138 ECT-ALGORITHM 32 bit unique id of an SPF tie breaking set of rules. 139 ECT-MASK 64 bit mask XORed with BridgeID during tie breaking. 140 E-LAN Bidirectional Logical Connectivity between >2 UNIs. 141 E-LINE Bidirectional Logical Connectivity between two UNIs. 142 E-TREE Asymmetric Logical Connectivity between UNIs. 143 FDB Filtering Information Base: {DA/VID}->{next hops} 144 I-SID Logical Grouping Identifier for E-LAN/LINE/TREE UNIs. 145 LSDB Link State Database 146 LSP Link State Packet 147 MAC-IN-MAC Ethernet in Ethernet framing as per 802.1ah[PBB] 148 MDT Multicast Distribution Tree 149 MT-ISIS Multi Topology IS-IS as used in [MT] 150 MT Multi Topology. As used in [MT] 151 MT-ID Multi Topology Identifier (12 bits). As used in [MT] 152 NLPID Network Layer Protocol Identifier: IEEE 802.1aq= 0xC1 153 Q-in-Q Additional S-VLAN after a C-VLAN (802.1ad)[PB] 154 PBB Provider Backbone Bridge - forwards using PBB 155 Ingress Check Source Forwarding Check - drops misdirected frames 156 (S,G) Source & Group - identity of a source specific tree 157 (*,G) Any Source & Group - identity of a shared tree 158 SA Source Address. 159 SPB Shortest Path Bridging - generally all of 802.1aq. 160 SPB Shortest Path Bridge - device implementing 802.1aq. 161 SPBM Device implementing SPB MAC mode 162 SPBV Device implementing SPB VID mode 163 SPT Shortest Path Tree computed by one ECT-ALORITHM 164 SPSourceID 20 bit identifier of the source of multicast frames. 165 SPVID SPBV: a C-VLAN or S-VLAN that identifies the source. 166 UNI User Network Interface: Customer to SPB attach point. 167 VID VLAN ID 12 bit logical identifier after MAC header. 169 3. Conventions used in this document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 4. 802.1aq Overview 177 802.1aq utilizes 802.1Q based Ethernet bridging. The filtering 178 database (FDB) is populated as a consequence of the forwarding 179 computed from the IS-IS database. 181 802.1aq supports multiple modes of operation depending on the type 182 of data plane and the desired behavior. For the initial two modes of 183 802.1aq (SPBV and SPBM), routes are shortest path, are forward and 184 reverse path symmetric with respect to any source / destination pair 185 within the SPB domain, and are congruent with respect to unicast and 186 multicast. Hence the shortest path tree (SPT) to a given node is 187 congruent with the multicast distribution tree (MDT) from a given 188 node. The MDT for a given VLAN is a pruned subset of the complete 189 MDT for a given node which is identical to its SPT. Symmetry and 190 congruency preserve packet ordering and proper fate sharing of OAM 191 flows by the forwarding path. Such modes are fully supported by 192 existing 802.1ag and Y.1731 OA&M mechanisms. 194 VLANs provide a natural delineation of service instances. 802.1aq 195 supports two modes, SPB VID (SPBV) and SPB MAC (SPBM). In SPBV 196 multiple VLANS can be used to distribute load on different shortest 197 path trees (each computed by a different tie breaking rule) on a 198 service basis. In SPBM service instances are delineated by I-SIDs 199 but VLANs again can be used to distribute load on different shortest 200 path trees. 202 There are two encapsulation methods supported. SPBM can be used in a 203 PBB network implementing PBB (802.1ah [PBB]) encapsulation. SPBV can 204 be used in PB networks implementing VLANs, PB (802.1aq [PB]) or PBB 205 encapsulation. The two modes can co-exist simultaneously in an SPB 206 network. 208 The practical design goals for SPBV and SPBM in the current 802.1aq 209 specification are networks of size 100 nodes and 1000 nodes 210 respectively. However since SPBV can be sparsely used in an SPB 211 Region it can simply span a large SPB region with a small number of 212 SPVIDs. 214 In SPBM and SPBV each bridge has at least one unique "known" MAC 215 address which is advertised by IS-IS in the SYS-ID. 217 In the forwarding plane, SPBM uses the combination of one or more B- 218 VIDs and "known" Backbone-MAC (B-MAC) addresses that have been 219 advertised in IS-IS. The term Backbone simply implies an 220 encapsulation that is often used in the backbone networks, but the 221 encapsulation is useful in other types of networks where hiding C- 222 MACs is useful. 224 The SPBM filtering database (FDB) is computed and installed for 225 unicast and multicast MAC addresses, while the SPBV filtering 226 database is computed and installed for unidirectional VLAN-IDs 227 (referred to as SPVIDs), while MAC filtering is learned for unicast. 229 Both SPBV and SPBM use source specific multicast trees. If they 230 share the same ECT-ALGORITHM (32 bit world wide unique definition of 231 the computation) the tree is the same SPT. For SPBV (S,G) is encoded 232 by a source-specific S-VLAN (the SPVID) and a standard Group MAC 233 address. For SPBM (S,G) is encoded in the destination B-MAC address 234 as the concatenation of a 20 bit SPB wide unique nodal nickname 235 (referred to as the SPSourceID) and the 24 bit I-SID together with 236 the B-VLAN which corresponds to the ECT-ALGORITHM network wide. 238 802.1aq supports membership attributes which are advertised with the 239 I-SID (SPBM) or Group Address (SPBV) that define the group. 240 Individual members can be transmitters (T) and/or receivers (R) 241 within the group and the multicast state is appropriately sized to 242 these requests. Multicast group membership is possible even without 243 transmit membership by performing head end replication to the 244 receivers thereby eliminating transit multicast state entirely. 246 Some highly connected mesh networks provide for path diversity by 247 offering multiple equal cost alternatives between nodes. Since 248 congruency and symmetry must be honored, a single tree may leave 249 some links under utilized. By using different deterministic tie 250 breakers, up to sixteen shortest paths of arbitrary diversity are 251 possible between any pair of nodes. This distributes the traffic on 252 a VLAN basis. SPBV and SPBM may share a single SPT with a single 253 ECT-ALGORITHM or use any combination of the 16 ECT-ALGORITHMs. An 254 extensible framework permits additional or alternative algorithms 255 with other properties and parameters (eg ECMP, (*,G) ) to also be 256 supported without any changes in this or the IEEE documents. 258 4.1. Data Path SPBM - Unicast 260 Unicast frames in SPBM are encapsulated as per 802.1ah [PBB]. A 261 Backbone Source Address (B-SA), Backbone Destination Address (B-DA), 262 Backbone VLAN ID (B-VID) and an I-Component Service Instance ID (I- 263 TAG) are used to encapsulate the Ethernet frame. The B-SA is a B-MAC 264 associated with the ingress 802.1aq bridge, usually the "known" B- 265 MAC of that entire bridge. The B-DA is one of the "known" B-MACs 266 associated with the egress 802.1aq bridge. The B-VID and I-TAG are 267 mapped based on the physical or logical UNI port (untagged, or 268 tagged either by S-TAG or C-TAG) being bridged. Normal learning and 269 broadcast to unknown C-MACs is applied as per [PBB] at the 270 ingress/egress SPBs only. 272 Unlike [PBB] on a (*,G) tree, the B-DA forwarding on tandem nodes 273 (NNI to NNI) is performed without learning. Instead the output of 274 802.1aq computations, based on the TLVs specified in this document, 275 are used to populate the Filtering Data Bases (FDB). The FDB entries 276 map {B-DA, B-VID} to an outgoing interface and are only populated 277 from the IS-IS database and computations. 279 The B-SA/B-VID is checked on tandem nodes against the ingress port. 280 If the B-SA/B-VID (as a destination) entry in the FDB does not point 281 to the port on which the packet arrived the packet is discarded. 282 This is referred to as an Ingress Check and serves as a very 283 powerful loop mitigation mechanism. 285 4.2. Data Path SPBM - Multicast (Head End Replication) 287 Head end replication is supported for instances where there is a 288 sparse community of interest or a low likelihood of multicast 289 traffic. Head end replication requires no Multicast state in the 290 core. A UNI port wishing to use head end replication MUST NOT 291 advertise its I-SID membership with the TX bit set but instead must 292 locally and dynamically construct the appropriate unicast serial 293 replication to all the other receivers (RX) of the same I-SID. 295 When an unknown customer unicast or a multicast frame arrives at an 296 SPBM User to Network Interface (UNI) port which has been configured 297 to replicate only at the head end the packet is replicated once for 298 each receiver, encapsulated and sent as a unicast frame. The set of 299 receivers is determined by inspecting the IS-IS database for other 300 SPBs that have registered interest in the same I-SID with the RX 301 (receive) attribute set. This RX/I-SID pair is found in the SPBM 302 Service Identifier and Unicast Address sub-TLV. The packets are 303 encapsulated as per the SPBM Unicast forwarding above. 305 4.3. Data Path SPBM - Multicast (Tandem Replication) 307 Tandem replication uses the Shortest path Tree to replicate Frames 308 only where the tree forks and there is at least one receiver on each 309 branch. Tandem replication is bandwidth efficient but uses multicast 310 FDB entries (state) in core bridges which might be unnecessary if 311 there is little multicast traffic demand. The head end replication 312 mode is best suited for the case where there is little or no true 313 multicast traffic for an I-SID. Tandem replication is triggered on 314 transit nodes when the I-SID is advertised with the TX bit set. 316 Broadcast, unknown unicast or multicast frames arriving at an SPBM 317 UNI port are encapsulated with a B-DA multicast address which 318 uniquely identifies the encapsulating node (the root of the 319 Multicast Distribution Tree) and the I-SID scoping this multicast. 321 This B-DA address is a well formed multicast group address (as per 322 802.1Q and 802.1ah) which concatenates the SPSourceID A' with the I- 323 SID M (written as DA= and uniquely identifying the (S,G) 324 tree). This exact format is given in Figure 1 below: 326 SPSRC TYP L M 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 |[16:19]|0|0|1|1| SPSRC [0:15] | ISID [16:23] | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | ISID [0:15] | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 1 SPBM Multicast Address format 335 o M is the multicast bit- always set to 1 for a multicast DA. 337 o L is the local bit- always set to 1 for a SPBM constructed 338 multicast DA. 340 o TYP is the SPSourceID type. Two values are supported. 00 for 341 statically assigned SPSourceID's and 01 for dynamic assignment. 343 o SPSRC (SPSourceID) is a 20 bit quantity that uniquely identifies 344 a SPBM node for all B-VIDs allocated to SPBM operation. This is 345 just the SPSourceID advertised in the SPB Instance sub-TLV. 347 o I-SID is the 24 bit I component Service ID advertised in the SPBM 348 Service Identifier TLV. It occupies the lower 24 bits of the SPBM 349 multicast DA. The I-SID value 0xfff is reserved for SPBM control 350 traffic(refer to the default I-SID in [802.1aq]). 352 This multicast address format is used as the DA on frames when they 353 are first encapsulated at ingress to the SPBM network. The DA is 354 also installed into the FDBs on all SPBM nodes that are on the 355 corresponding SPT between the source and other nodes that have 356 registered receiver interest in the same I-SID. 358 Just as with unicast forwarding, the B-SA/B-VID may be used to 359 perform an ingress check, but the SPSourceID encoded in the DA and 360 the "drop-on-unknown" functionality of the FDB in [PBB] achieve the 361 same effect. 363 The I-Component at the egress SPBM device has completely standard 364 [PBB] behavior and therefore will: 366 1) learn the remote C-SA to B-SA relationship and 367 2) bridge the original customer frame to the set of local UNI ports 368 that are associated with the I-SID. 370 4.4. Data Path SPBV Broadcast 372 When a packet for an unknown DA arrives at a SPBV UNI port VID 373 translation (or VID encapsulation for un-tagged Frames) with the 374 corresponding SPVID for this VLAN and ingress SPB is performed. 376 SPVID forwarding is simply an SPT that follows normal VLAN 377 forwarding behavior, with the exception that the SPVID is 378 unidirectional. As a result shared learning (SVL) is used between 379 the forward and reverse path SPVIDs associated with the same Base 380 VID to allow SPBV unicast forwarding to operate in the normal 381 reverse learning fashion. 383 Ingress check is done by simply verifying that the bridge to which 384 the SPVID has been assigned is indeed "shortest path" reachable over 385 the link over which the packet tagged with that SPVID arrived. This 386 check is computed from the IS-IS database and is implied when the 387 SPVID is associated with a specific incoming port. 389 4.5. Data Path SPBV Unicast 391 Conversely when a packet for a known DA arrives at a SPBV UNI port 392 VID translation (or VID encapsulation for un-tagged Frames) with the 393 corresponding SPVID for this VLAN and ingress SPB is performed. 395 Since the SPVID will have been configured to follow a source 396 specific SPT and the DA is known the packet will follow the source 397 specific path towards the destination C-MAC. 399 Ingress check is as per the previous SPBV section. 401 4.6. Data Path SPBV Multicast 403 C-DA multicast addresses may be advertised from SPBV UNI ports. 404 These may be configured or learned through MMRP. The MMRP protocol 405 is terminated at the edge of the SPBV network and IS-IS carries the 406 multicast addresses. Tandem SPBV devices will check to see if they 407 are on the SPF tree between SPBV UNI ports advertising the same C-DA 408 multicast address, and if so will install multicast state to follow 409 the SPBV SPF trees. 411 Ingress check is as per the previous two SPBV sections. 413 5. SPBM Example 415 Consider the following small example network shown in Figure 2. 416 Nodes are drawn in boxes with the last nibble of their B-MAC address 417 :1..:7, the rest of the B-MAC address nibbles are 4455-6677-00xx. 418 Links are drawn as -- and / while the interface indexes are drawn as 419 numbers next to the links. UNI ports are shown as <==> with the 420 desired I-SID show at the end of the UNI ports as i1. 422 +----+ +----+ 423 | :4 | 2 ------1 | :5 | <==> i1 424 +----+ +----+ 425 1 3 3 2 426 / \ / \ 427 1 4 3 2 428 +----+ +----+ +----+ 429 i1 <==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> i1 430 +----+ +----+ +----+ 431 3 6 5 3 432 \ / \ / 433 3 2 1 2 434 +----+ +----+ 435 | :6 | 1-------3 | :7 | <==> i1 436 +----+ +----+ 438 Figure 2 - SPBM Example 7 node network 440 Using the default ECT-ALGORITHM (00-80-C2-01), which picks the equal 441 cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned 442 to B-VID 100. When all links have the same cost, then the 1 hop 443 shortest paths are all direct and the 2 hop shortest paths (which 444 are of course symmetric) are as follows: 446 { 1-2-3, 1-2-5, 1-2-7, 6-2-5, 447 4-2-7, 4-1-6, 5-2-7, 6-2-3, 4-2-3 } 449 Node :1's Unicast forwarding table therefore routes toward B-MACs 450 :7, :3 and :5 via interface/2 while its single hop paths are all 451 direct as can be seen from its FDB given in Figure 3. 453 Node :1 originates multicast since it is at the head of the MDT to 454 nodes :3, :5 and :7 and is a transmitter of I-SID 1 which nodes :3, 455 :5 and :7 all wish to receive. Node :1 therefore produces a 456 multicast forwarding entry who's DA contains its SPSourceID (in the 457 example the last 20 bits of the B-MAC) and the I-SID 1 and sends to 458 interface 2 with B-VID=100. Node :1's full unicast(U) and 459 multicast(M) table is shown in Figure 3. Note that the IN/IF 460 (incoming interface) field is not specified for unicast traffic and 461 for multicast traffic has to point back to the root of the tree, 462 unless it is the head of the tree in which cast we use the 463 convention if/OO. Since Node :1 is not transit for any multicast it 464 only has a single entry for the root of its tree for I-SID=1. 466 +-------+-------------------+------+-----------------+ 467 | IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) | 468 +-------+-------------------+------+-----------------+ 469 U| if/** | 4455-6677-0002 | 0100 | {if/2 } 470 U| if/** | 4455-6677-0003 | 0100 | {if/2 } 471 U| if/** | 4455-6677-0004 | 0100 | {if/1 } 472 U| if/** | 4455-6677-0005 | 0100 | {if/2 } 473 U| if/** | 4455-6677-0006 | 0100 | {if/3 } 474 U| if/** | 4455-6677-0007 | 0100 | {if/2 } 475 M| if/00 | 7300-0100-0001 | 0100 | {if/2 } 477 Figure 3 - SPBM Node :1 FDB - Unicast(U) and Multicast(M) 479 Node :2, being at the center of the network, has direct 1 hop paths 480 to all other nodes, therefore its unicast FDB simply sends packets 481 with the given B-MAC/B-VID=100 to the interface directly to the 482 addressed node. This can be seen by looking at the unicast entries 483 (the first 6) shown in Figure 4. 485 +-------+-------------------+------+-----------------+ 486 | IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) | 487 +-------+-------------------+------+-----------------+ 488 U| if/** | 4455-6677-0001 | 0100 | {if/1 } 489 U| if/** | 4455-6677-0003 | 0100 | {if/2 } 490 U| if/** | 4455-6677-0004 | 0100 | {if/4 } 491 U| if/** | 4455-6677-0005 | 0100 | {if/3 } 492 U| if/** | 4455-6677-0006 | 0100 | {if/6 } 493 U| if/** | 4455-6677-0007 | 0100 | {if/5 } 494 M| if/01 | 7300-0100-0001 | 0100 | {if/2,if/3,if/5 } 495 M| if/02 | 7300-0300-0001 | 0100 | {if/1 } 496 M| if/03 | 7300-0500-0001 | 0100 | {if/1,if/5 } 497 M| if/05 | 7300-0700-0001 | 0100 | {if/1,if/3 } 499 Figure 4 - SPBM Node :2 FDB Unicast(U) and Multicast(M) 501 Node :2's multicast is more complicated since it is a transit node 502 for the 4 members of I-SID=1, therefore it requires 4 multicast FDB 503 entries depending on which member it is forwarding/replicating on 504 behalf of. For example, node :2 is on the shortest path between each 505 of nodes {:3,:5,:7} and :1. So it must replicate from node :1 I-SID 506 1 out on interfaces 2, 3 and 5 (to reach nodes :3, :5 and :7). It 507 therefore creates a multicast DA with the SPSourceID of node :1 508 together with I-SID=1 which it expects to receive over interface/1 509 and will replicate out interfaces/{2, 3 and 5}. This can be seen in 510 the first multicast entry in Figure 4. 512 Note that node :2 is not on the shortest path between nodes :3 and 513 :5 nor between nodes :3 and :7, however it still has to forward 514 packets to node :1 from node :3 for this I-SID, which results in the 515 second multicast forwarding entry in Figure 4. Likewise for packets 516 originating at nodes 5 or 7, node :2 only has to replicate twice, 517 which results in the last two multicast forwarding entries in Figure 518 4. 520 6. SPBV Example 522 Using the same example network as Figure 2, we will look at the FDBs 523 produced for SPBV mode forwarding. Nodes :1, :5, :3 and :7 wish to 524 transmit and receive the same multicast MAC traffic using multicast 525 address 0300-0000-000f and at the same time require congruent and 526 symmetric unicast forwarding. In SPBV mode the only encapsulation is 527 the C or S-TAG and the MAC addresses SA,DA are reverse-path learned, 528 as in traditional bridging. 530 +----+ +----+ 531 | :4 | 2 ------1 | :5 | <==> MMAC ..:f 532 +----+ +----+ 533 1 3 3 2 534 / \ / \ 535 1 4 3 2 536 +----+ +----+ +----+ 537 MMAC<==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> MMAC ..:f 538 ..:f +----+ +----+ +----+ 539 3 6 5 3 540 \ / \ / 541 3 2 1 2 542 +----+ +----+ 543 | :6 | 1-------3 | :7 | <==> MMAC ..:f 544 +----+ +----+ 546 Figure 5 - SPBV Example 7 node network 548 Assuming the same ECT-ALGORITHM (00-80-C2-01), which picks the equal 549 cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned 550 to Base Vid 100, and for each node the SPVID = Base Vid + Node Id 551 (i.e. 101, 102..107). When all links have the same cost, then the 1 552 hop shortest paths are all direct and the 2 hop shortest paths 553 (which are of course symmetric) are as previously given for Figure 554 2. 556 Node :1's SPT (Shortest Path Tree) for this ECT-ALGORITHM is 557 therefore (described as a sequence of unidirectional paths): 559 { 1->4, 1->6, 1->2->3, 1->2->5, 1->2->7 } 561 The FDBs therefore must have entries for the SPVID reserved for 562 packets originating from node :1 which in this case is VID=101. 564 Node :2 therefore has a FDB which looks like Figure 6. In particular 565 it takes packets from VID 101 on interface/01 and sends to nodes :3, 566 :5 and :7 via if/2, if/3 and if/5. It does not replicate anywhere 567 else because the other nodes :4 and :6 are reached by the SPT 568 directly from node :1. The rest of the FDB unicast entries follow a 569 similar pattern; recall that the shortest path between :4 and :6 is 570 via node :1, which explains replication onto only two interfaces 571 from if/4 and if/6. Note that the destination addresses are wild 572 cards and shared VLAN learning (SVL) exists between these SPVIDs, 573 because they are all associated with BASE VID = 100, which defines 574 the VLAN being bridged. 576 +-------+-------------------+------+-----------------+ 577 | IN/IF | DESTINATION ADDR | VID | OUT/IF(s) | 578 +-------+-------------------+------+-----------------+ 579 U| if/01 | ************** | 0101 | {if/2,if/3,if/5 } 580 U| if/02 | ************** | 0103 | {if/1,if/4,if/6 } 581 U| if/04 | ************** | 0104 | {if/2,if/5 } 582 U| if/03 | ************** | 0105 | {if/1,if/5,if/6 } 583 U| if/06 | ************** | 0106 | {if/2,if/3 } 584 U| if/05 | ************** | 0107 | {if/1,if/3,if/4 } 586 Figure 6 - SPBV Node :2 FDB unicast 588 Now, since nodes :5, :3, :7 and :1 are advertising membership in the 589 same multicast group address :f, Node 2 requires additional entries 590 to replicate just to these specific nodes for the given multicast 591 group address. These additional multicast entries are given below in 592 Figure 7. 594 +-------+-------------------+------+-----------------+ 595 | IN/IF | DESTINATION ADDR | VID | OUT/IF(s) | 596 +-------+-------------------+------+-----------------+ 597 M| if/01 | 0300-0000-000f | 0101 | {if/2,if/3,if/5 } 598 M| if/02 | 0300-0000-000f | 0103 | {if/1 } 599 M| if/03 | 0300-0000-000f | 0105 | {if/1,if/5 } 600 M| if/05 | 0300-0000-000f | 0107 | {if/1,if/3 } 602 Figure 7 - SPBV Node :2 FDB Multicast(M) 604 7. SPB Supported Adjacency types 606 IS-IS for SPB currently only supports P2P adjacencies. Other link 607 types are for future study. As a result pseudonodes and links 608 to/from pseudonodes are not considered as part of the IS-IS SPF 609 computations and will be avoided if present in the physical 610 topology. Other NLPIDs may of course use them as per normal. 612 IS-IS for SPB MUST use the IS-IS Three-Way handshake for IS-IS 613 Point-to-Point Adjacencies described in RFC 5303. 615 8. SPB IS-IS adjacency addressing 617 The default behavior of 802.1aq is to use the normal IS-IS Ethernet 618 multicast addresses for IS-IS. 620 There are however additional Ethernet multicast addresses that have 621 been assigned for 802.1aq for special use cases. These do not in 622 anyway change the state machinery or packet formats of IS-IS but 623 simply recommend and reserve different multicast addresses. Refer to 624 [802.1aq] for additional details. 626 9. IS-IS Area Address and SYSID 628 A stand-alone implementation (supporting ONLY the single NLPID=0x1C) 629 of SPB MUST use an IS-IS area address value of 0 and the SYSID MUST 630 be the well known MAC address of the SPB device. 632 Non stand-alone implementations (supporting other NLPIDs) MUST use 633 the normal IS-IS rules for the establishment of a level 1 domain 634 (i.e. multiple area addresses are allowed but where immediate 635 adjaciencies share a common area address). Level 2 operations of 636 course place no such restriction on adjacent area addresses. 638 10. Level 1/2 Adjacency 640 SPBV and SPBM will operate either within an IS-IS level 1, or an 641 ISIS level 2. As a result the TLVs specified here may propagate 642 either in level 1 or level 2 LSPs. IS-IS SPB implementations MUST 643 support level 1 and MAY support level 2 operations. Hierarchical SPB 644 is for further study therefore these TLV's MUST NOT be leaked 645 between level 1 and level 2. 647 11. Shortest Path Default Tie Breaking 649 (ECT-ALGORITHM = 00-80-C2-01) 650 Two mechanisms are used to ensure symmetry and determinism in the 651 shortest path calculations. 653 The first mechanism addresses the problem when different ends 654 (nodes) of an adjacency advertise different values for the SPB-LINK- 655 METRIC. To solve this the SPB shortest path calculations MUST use 656 the maximum value of the two node's advertised SPB-LINK-METRICs when 657 accumulating and minimizing the (sub)path costs. 659 The second mechanism addresses the problem when two equal sum of 660 link metrics (sub)paths are found. To solve this the (sub)path with 661 the fewest hops between the fork/join points MUST win the tie. 662 However, if both (sub)paths have the same number of hops between the 663 fork and join points then the default tie breaking MUST pick the 664 path traversing the intermediate node with the lower BridgeID. The 665 BridgeID is an 8 byte quantity who's upper 2 bytes are the node's 666 BridgePriority and the lower 6 bytes are the node's SYSID. 668 For example, consider the network in Figure 2 when a shortest path 669 computation is being done from node :1. Upon reaching node :7 two 670 competing sub-paths fork at node :1 and join at node :7. The first 671 via :2 and the second via :6. Assuming that all the nodes advertise 672 a Bridge Priority of 0, the default tie breaking rule causes the 673 path traversing node :2 to be selected since it has a lower BridgeID 674 {0...:2} than node :6 {0...:6}. Note that the operator may cause the 675 tie breaking logic to pick the alternate path by raising the Bridge 676 Priority of node :2 above that of node :6. 678 The above algorithm guarantees symmetric and deterministic results 679 in addition to having the critical property of transitivity 680 (shortest path is made up of sub-shortest paths). 682 12. Shortest Path ECT 684 (ECT-ALGORITHMs = 00-80-C2-01 .. 00-80-C2-10) 685 To create diversity in routing SPB defines 16 variations on the 686 above default tie breaking algorithm, these have world wide unique 687 designations 00-80-C2-01 through 00-80-C2-10. These designations 688 consist of the IEEE 802.1 OUI value 00-80-C2 concatenated with 689 indexes 0X01..0X10. These individual algorithms are implemented by 690 selecting the (sub) path with the lowest value of: 692 XOR BYTE BY BYTE(ECT-MASK{ECT-ALGORITHM.index},BridgeID) 694 Where: 696 ECT-MASK{17} = { 0x00, 0x00, 0xFF, 0x88, 697 0x77, 0x44, 0x33, 0xCC, 698 0xBB, 0x22, 0x11, 0x66, 699 0x55, 0xAA, 0x99, 0xDD, 700 0xEE }; 702 XOR BYTE BY BYTE - XORs BridgeID bytes with ECT-MASK 704 ECT-MASK{1} since it xor's with all 0's is just the same as the 705 default algorithm described above 00-80-C2-01, while ECT-MASK{0x02} 706 since it xor's with a mask of all 1's will invert the BridgeID 707 essentially picking the path traversing the largest Bridge ID. The 708 other ECT-MASKs produce diverse alternatives. In all cases the 709 BridgePriority, since it is the most significant part of the 710 BridgeID permits overriding the SYSID as the selection criteria and 711 gives the operator a degree of control on the chosen ECT paths. 713 To support many other tie breaking mechanisms in the future two 714 opaque ECT TLV's are defined which may be used to provide parameters 715 to ECT-ALGORITHMS outside of the currently defined space. 717 ECT-ALGORITHMS are mapped to VIDs and then services can be assigned 718 to those VIDs. This permits a degree of traffic engineering since 719 service assignment to VID is consistent end to end through the 720 network. 722 13. Hello (IIH) protocol extensions 724 IEEE 802.1aq can run in parallel with other Network Layer Protocols 725 such as IPV4 and IPV6, therefore failure for two SPB nodes to 726 establish an adjacency MUST NOT cause rejection of an adjacency for 727 the purposes of other Network Layer Protocols. 729 IEEE 802.1aq has been assigned the NLPID value 0xC1 [NLPID] which 730 MUST be used by shortest path bridges (SPBs) to indicate their 731 ability to run 802.1aq. This is done by including this NLPID value 732 in the IS-IS IIH PDU Protocols Supported TLV (type 129). 802.1aq 733 frames MUST only flow on adjacencies that advertise this NLPID in 734 both directions of the IIH PDUs. 802.1aq computations MUST consider 735 an adjacency that has not advertised 0xC1 NLPID in both directions 736 as non-existent (infinite link metric) and MUST ignore any SPB TLV's 737 they receive over such adjacencies. 739 IEEE 802.1aq augments the normal IIH PDU with three new TLV's which 740 like all other SPB TLVs travel within multi topology [MT] TLVs, 741 therefore allowing multiple logical instances of SPB within a single 742 IS-IS protocol instance. 744 Since SPB can use many VIDs and must agree on which VIDs are used 745 for which purposes, the IIH PDU's carry a digest of all the used 746 VIDs (on the NNI's) referred to as the SPB-MCID TLV which uses a 747 common and compact encoding taken reused from 802.1Q. 749 SPB neighbors MAY support an optional mechanism to verify that the 750 contents of their topology databases are synchronized (for the 751 purposes of loop prevention). This is done by exchanging a digest of 752 the topology information and taking specific actions on forwarding 753 entries when the digests indicate a mismatch in topology. This 754 digest is carried in the optional SPB Digest sub-TLV. 756 Finally SPB needs to know which SPT sets (defined by ECT-ALGORITHMS) 757 are being used by which VIDs, and this is carried in the Base VLAN 758 Identifiers sub-TLV. 760 13.1. SPB MCID sub-TLV 762 This sub-TLV is added to an IIH PDU to indicate the digest for the 763 Multiple spanning tree configuration a.k.a MCID. This TLV is a 764 digest of local configuration of which VIDs are running which 765 protocols. (The information is not to the level of a specific 766 algorithm in the case of SPB). This information should be the same 767 on all bridges in the topology identified by the MT-Port-Capability 768 TLV it is being carried within. The data used to generate the MCID 769 is populated by configuration and is a digest of the VIDs allocated 770 to various protocols. Two MCIDs are carried to allow non disruptive 771 transitions between configurations when the changes are non- 772 critical. 774 +-+-+-+-+-+-+-+-+ 775 |Type=SPB-MCID | = 6 776 +-+-+-+-+-+-+-+-+ 777 | Length | (1 byte) 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | MCID (50 Bytes) | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Aux MCID (50 Bytes) | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 o Type: sub-TLV Type = 6 (Pending IANA). 786 o Length: The size of the value defined below (100). 788 o MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which 789 identifies an SPT Region on the basis of matching assignments of 790 VIDs to control regimes (xSTP, SPBV, SPBM, etc). Briefly, the 791 MCID consists of a 1 byte format selector, a 32 byte 792 configuration name, a 2 byte revision level and finally a 16 byte 793 signature of type HMAC-MD5 over an array of 4096 elements that 794 contain identifiers of the use of the corresponding VID. Refer to 795 section 13.8 of [802.1aq] for the exact format and procedure. 796 Note that the use of the VID does not include specification of a 797 specific SPB ECT-ALGORITHM, rather it is coarser grain. 799 o Aux MCID (50-bytes) The complete MCID defined in IEEE 802.1Q 800 which identifies an SPT Region. The aux MCID allows SPT Regions 801 to be migrated by the allocation of new VLAN to FDB Mappings 802 without interruption to existing traffic. 804 The SPB MCID sub-TLV is carried within the MT-Port-Capability TLV 805 which in turn is carried in an IIH PDU. 807 13.2. SPB Digest sub-TLV 809 This sub-TLV is optionally added to an IIH PDU to indicate the 810 current topology digest value. This information should settle to be 811 the same on all bridges in an unchanging topology (identified by the 812 MT-Port-Capability TLV it is being carried within). Matching digests 813 indicate (with extremely high probability) that the topology view 814 between two bridges is synchronized, and is used to control the 815 updating of forwarding information. The IS-IS Agreement Digest is 816 computed based on currently topology and is designed to change only 817 when significant topology changes occur. 819 During the propagation of LSPs the Agreement Digest may vary between 820 neighbors until the key topology information in the LSPs are common. 821 The digest is therefore a summarized means of determining agreement 822 between nodes on database commonality, and hence infer agreement on 823 the distance to all multicast roots. When present it is used for 824 loop prevention as follows: For each shortest path tree where it 825 has been determined the distance to the root has changed, "unsafe" 826 multicast forwarding is blocked until the exchanged Agreement 827 Digests match while "safe" multicast forwarding is allowed to 828 continue despite the disagreement in digests and hence topology 829 views. [802.1aq] section 28.2 defines in detail what constitutes 830 "safe" v.s. "unsafe". 832 +-+-+-+-+-+-+-+-+ 833 |Type=SPB-Digest| = 7 834 +-+-+-+-+-+-+-+-+ 835 | Length | (1 byte) 836 +-----+-+---+---+ 837 | Res |V| A | D | (1 byte) 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Agreement Digest (Length - 1) | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 o Type: sub-TLV Type = 7 (Pending IANA). 844 o Length: The size of the value. 846 o V - agreed digest valid bit. See [802.1aq] Sec 28.2. 848 o A (2 bits) The Agreement Number 0-3 which aligns with BPDUs 849 Agreement Number concept [802.1aq]. When the Agreement Digest 850 for this node changes this number is incremented. The node then 851 checks for Agreement Digest match (as below). The new local 852 Agreement Number and the updated local Discarded Agreement Number 853 are then transmitted with the new Agreement Digest to the node's 854 neighbors in the hello PDU. Once an Agreement Number has been 855 sent it is considered outstanding until a matching or more recent 856 Discarded Agreement Number is received from the neighbor. 858 o D (2 bits) The Discarded Agreement Number 0-3 which aligns with 859 BPDUs Agreement Number concept. When an Agreement Digest is 860 received from a neighbor, this number is set to the received 861 Agreement Number, to signify that this node has received this new 862 agreement and discarded any previous ones. The node then checks 863 whether the local and received Agreement Digests match. If they 864 do, this node then sets : 866 the local Discarded Agreement Number = received Agreement 867 Number + 1 869 If the Agreement Digests match, AND 870 received Discarded Agreement Number == local Agreement Number 871 + N (N = 0 || 1) 873 then the node has a topology matched to its neighbor. 875 Whenever the local Discarded Agreement Number relating to a 876 neighbor changes, the local Agreement Digest, Agreement Number, 877 and Discarded Agreement Number are transmitted. 879 o Agreement Digest. This digest is use to determine when IS-IS is 880 synchronized between neighbors relative to the MT-Port-Capability 881 instance. The agreement digest is a hash computed over the set of 882 all SPB adjacencies (all edges) in all SPB Multi Topology 883 instances. In other words, the digest includes all VIDs and all 884 adjacencies for all MT instances of SPB. This reflects the fact 885 that all SPB nodes in a region must have identical VID 886 allocations (see 13.1), and so all SPB MT instances will contain 887 the same set of nodes. The size and exact procedure for computing 888 the Agreement Digest is defined in section 28.2 of [802.1aq]. 890 The SPB Digest sub-TLV is carried within the MT-Port-Capability TLV 891 which in turn is carried in an IIH PDU. 893 When supported, this sub-TLV MUST be carried on every IIH between 894 SPB neighbors, not just when a Digest changes. 896 When one peer supports this TLV and the other does not, loop 897 prevention by digest agreement MUST NOT be done by either side. 899 13.3. SPB Base VLAN-Identifiers sub-TLV 901 This sub-TLV is added to an IIH PDU to indicate the mappings between 902 ECT algorithms and Base VIDs (and by implication the VID(s) used on 903 the forwarding path for each SPT Set identified by a Base VID) that 904 are in use. Under stable operational conditions, this information 905 should be the same on all bridges in the topology identified by the 906 MT-PORT-CAP TLV it is being carried within. 908 +-+-+-+-+-+-+-+-+ 909 |Type= SPB-B-VID| = 8 910 +-+-+-+-+-+-+-+-+ 911 | Length | (1 byte) 912 +-+-+-+-+-+-+-+-+-------------------------------+ 913 | ECT - VID Tuple (1) (6 bytes) | 914 +-----------------------------------------------+ 915 | ......................... | 916 +-----------------------------------------------+ 917 | ECT - VID Tuples (N) (6 bytes) | 918 +-----------------------------------------------+ 920 o Type: sub-TLV Type = 8 (Pending IANA). 922 o Length: The size of the value is ECT-VID Tuples*6 bytes. Each 6- 923 byte part of the ECT-VID tuple is formatted as follows: 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | ECT - Algorithm (32 bits) | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Base VID (12 bits) |U|M|RES| 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 o ECT-ALGORITHM (4 bytes) The ECT-ALGORITHM is advertised when the 932 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 933 Base VID. There are 17 predefined IEEE algorithms for SPB with 934 index values 0X00..0X10 occupying the low 8 bits and the IEEE 935 OUI=00-80-C2 occupying the top 24 bits of the ECT-ALGORITHM. 937 o Base VID (12-bits) The Base-VID that is associated with the SPT 938 Set. 940 o Use-Flag (1-bit) The Use-flag is set if this bridge, or any 941 bridge in the LSDB is currently using this ECT-ALGORITHM and Base 942 VID. 944 o M-Bit (1-bit) The M-bit indicates if this Base VID operates in 945 SPBM (M = 1) or SPBV (M = 0) mode. 947 The SPB Base VLAN-Identifier sub-TLV is carried within the MT-Port- 948 Capability TLV which in turn is carried in an IIH PDU. 950 14. Node information extensions 952 All SPB nodal information extensions travel within a new multi 953 topology capability TLV MT-Capability (type = 144). 955 +-+-+-+-+-+-+-+-+ 956 |Type = MT-CAP | = 144 957 +-+-+-+-+-+-+-+-+ 958 | Length | (1 byte) 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 |R R R R| MT ID | (2 bytes) 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 (sub-TLVs ... ) 964 The format of this TLV is identical in its first 2 bytes to all 965 current MT TLV's and carries the MT ID as defined in [MT]. 967 14.1. SPB Instance sub-TLV 969 The SPB Instance sub-TLV gives the SPSourceID for this node/topology 970 instance. This is the 20 bit value that is used in the formation of 971 multicast DA addresses for frames originating from this 972 node/instance. The SPSourceID occupies the upper 20 bits of the 973 multicast DA together with 4 other bits (see the SPBM 802.1ah 974 multicast DA address format section). This sub-TLV MUST be carried 975 within the MT-Capability TLV in the fragment ZERO LSP. If there is 976 an additional SPB instance it MUST be declared under a separate MT- 977 Topology and also carried in the fragment ZERO LSP. 979 +-+-+-+-+-+-+-+-+ 980 |Type = SPB-Inst| = 1 981 +-+-+-+-+-+-+-+-+ 982 | Length | (1 byte) 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | CIST Root Identifier (4 bytes) | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | CIST Root Identifier (cont) (4 bytes) | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | CIST External ROOT Path Cost (4 bytes) | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Bridge Priority | (2 bytes) 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 |R R R R R R R R R R R|V| SPSourceID | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Num of Trees | (1 byte) 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | VLAN-ID (1) Tuples (8 bytes) | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | VLAN-ID (N) Tuples (8 bytes) | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 where VLAN-ID tuples have the format as: 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+ 1006 |U|M|A| Res | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | ECT - Algorithm (32 bits) | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Base VID (12 bits) | SPVID (12 bits) | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 o Type: sub-TLV Type 1 (Pending IANA). 1015 o Length: Total number of bytes contained in the value field. 1017 o CIST Root Identifier (64-bits)The CIST Root Identifier is for SPB 1018 interworking with RSTP and MSTP at SPT Region Boundaries. This 1019 is an imported value from a Spanning tree. 1021 o CIST External Root Path Cost (32-bits) The CIST External Root 1022 Path Cost is the cost to root, derived from the spanning tree 1023 algorithm. 1025 o Bridge Priority (16-bits) Bridge priority is the 16 bits that 1026 together with the 6 bytes of the System ID form the Bridge 1027 Identifier. This is configured exactly as specified in IEEE802 1028 [802.1D]. This allows SPB to build a compatible Spanning tree 1029 using link state by combining the Bridge Priority and the System 1030 ID to form the 8 byte Bridge Identifier. The 8 byte Bridge 1031 Identifier is also the input to the 16 pre-defined ECT tie 1032 breaker algorithms. 1034 o V bit (1-Bit) The V bit (SPBM) indicates this SPSourceID is auto 1035 allocated(27.11). If the V bit is clear the SPSourceID has been 1036 configured and must be unique. Allocation of SPSourceID is 1037 defined in IEEE [802.1aq]. Bridges running SPBM will allocate an 1038 SPSourceID if they are not configured with an explicit 1039 SPSourceID. The V Bit allows neighbor bridges to determine if the 1040 auto allocation was enabled. In the rare chance of a collision 1041 of SPsourceID allocation, the bridge with the highest priority 1042 Bridge Identifier will win conflicts and the lower priority 1043 Bridge will be re-allocated or if the lower priority Bridge is 1044 configured it will not be allowed to join the SPT Region. 1046 o The SPSourceID is a 20 bit value used to construct multicast DA's 1047 as described below for multicast frames originating from the 1048 origin (SPB node) of the link state packet (LSP) that contains 1049 this TLV. More details are in IEEE [802.1aq]. 1051 o Number of Trees (8-bits) The Number of Trees is set to the number 1052 of [ECT-ALGORITHM, Base-VID plus flags] tuples that follow. Each 1053 ECT-ALGORITHM has a Base VID, an SPVID and flags described below. 1054 This must contain at least the one ECT-ALGORITMM (00-80-C2-01). 1056 Each VID Tuple consists of: 1058 o U-Bit (1-bit) The Use flag is set if this bridge is currently 1059 using this ECT-ALGORITHM for I-SIDs it sources or sinks. This is 1060 a strictly local indication; the semantics differ from the U-bit 1061 found in the Hello, which will set the Use-Flag if it sees other 1062 nodal Use-Flags are set OR it sources or sinks itself. 1064 o M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode. 1065 When cleared the mode is SPBV and when set the mode is SPBM. 1067 o A bit, The A bit (SPB) when set declares this is an SPVID with 1068 auto allocation. The VID allocation logic details are in IEEE 1069 [802.1aq]. Since SPVIDs are from a small pool of resources 1070 (typically 1000 or less) the chances of collision are high. To 1071 allow auto allocation LSPs are exchanged with the allocated 1072 bridge setting the SPVID to 0 and the allocating bridge sets the 1073 SPVID when it learns the allocated space. SPVID may also be 1074 configured. When the A bit is set to not specify auto allocation 1075 and the SPVID is set to 0 this SPBV bridge is used for transit 1076 only within the SPB region. If a port is configured with the 1077 BASE-VID as an neighbor using RSTP or MSTP the bridge will act as 1078 an ingress filter for that VID. 1080 o ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is advertised when the 1081 bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given 1082 VID. This declaration must match the declaration in the Hello PDU 1083 originating from the same bridge. The ECT-ALGORITHM, BASE-VID 1084 should match what is generated in the Hellos of the same node. 1085 The ECT-ALGORITHM, BASE-VID tuples can come in any order however. 1086 There are currently 17 world wide unique 802.1aq defined ECT- 1087 ALGORITHMS given by values 00-80-C2-00 through 00-80-C2-10. 1089 o Base VID (12-bits) The Base-VID that associated the SPT Set via 1090 the ECT-ALGORITHM. 1092 o SPVID (12-bits) The SPVID is the Shortest Path VID assigned for 1093 the Base VID to this node when using SPBV mode. It is not 1094 defined for SPBM Mode and MUST be 0 for SPBM mode B-VIDs. 1096 14.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV 1098 There are multiple ECT algorithms defined for SPB, however for the 1099 future additional algorithms may be defined including but not 1100 limited to ECMP / hash based behaviors and (*,G) multicast trees. 1101 These algorithms will use this optional TLV to define new algorithm 1102 parametric data. For tie breaking parameters there are two broad 1103 classes of algorithm, one which uses nodal data to break ties and 1104 one which uses link data to break ties, as a result this TLV can 1105 associate opaque data with a node or an adjacency or both. This sub- 1106 TLV, when present, MUST be carried within the MT-Capability TLV 1107 (along with a valid SPB Instance sub-TLV). Multiple copies of this 1108 sub-TLV may be carried for different ECT-ALGORITHMs relating to this 1109 node. 1111 There are of course many other uses of this opaque data which have 1112 yet to be defined. 1114 +-+-+-+-+-+-+-+-+ 1115 |Type=SPB-I-OALG| = 2 1116 +-+-+-+-+-+-+-+-+ 1117 | Length | (1 byte) 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Opaque ECT Algorithm (4 bytes) | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Opaque ECT Information (variable) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 o Type: sub-TLV Type 2 (Pending IANA). 1126 o Length: Total number of bytes contained in the value field. 1128 o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge 1129 supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. 1131 o ECT Information: ECT-ALGORITHM Information of variable length 1132 which should be in sub-TLV format with an IANA numbering space 1133 where appropriate. 1135 15. Adjacency information extensions 1137 15.1. SPB Link Metric sub-TLV 1139 The SPB Link Metric sub-TLV (type = 12) occurs within the Multi 1140 Topology Intermediate System TLV (type 222) or within the Extended 1141 IS Reachability TLV (type 22). If this sub TLV is not present for 1142 an ISIS adjacency then that adjacency MUST NOT carry SPB traffic for 1143 the given topology instance. 1145 +-+-+-+-+-+-+-+-+ 1146 |Type=SPB-Metric| = 12 1147 +-+-+-+-+-+-+-+-+ 1148 | Length | (1 byte) 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | SPB-LINK-METRIC | (3 bytes) 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Num of ports | (1 byte) 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | Port Identifier | ( 2 bytes) 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 o Type: sub-TLV Type 12 (Pending IANA). 1159 o Length: Total number of bytes contained in the value field. 1161 o SPB-LINK-METRIC indicates the administrative cost or weight of 1162 using this link as a 24 bit unsigned number. Smaller numbers 1163 indicate lower weights and are more likely to carry SPB traffic. 1164 Only one metric is allowed per SPB instance per link. If 1165 multiple metrics are required multiple SPB instances are 1166 required, either within IS-IS or within several independent IS-IS 1167 instances. If this metric is different at each end of a link, the 1168 maximum of the two values MUST be used in all SPB calculations 1169 for the weight of this link. 1171 o Num of Ports is the number of ports associated with this link. 1173 o Port Identifier is the standard IEEE port identifier used to 1174 build a spanning tree associated with this link. 1176 15.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV 1178 There are multiple ECT algorithms defined for SPB, however for the 1179 future additional algorithms may be defined. The SPB Adjacency 1180 Opaque ECT-ALGORITHM sub-TLV occurs within the Multi Topology 1181 Intermediate System TLV (type 222) or the Extended IS Reachability 1182 TLV (type 22). Multiple copies of this sub-TLV may be carried for 1183 different ECT-ALGORITHMs related to this adjacency. 1185 +-+-+-+-+-+-+-+-+ 1186 |Type=SPB-A-OALG| = 13 1187 +-+-+-+-+-+-+-+-+ 1188 | Length | (1 byte) 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Opaque ECT Algorithm (4 bytes) | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Opaque ECT Information (variable) | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 o Type: sub-TLV Type = 13 (PENDING IANA). 1197 o Length: Total number of bytes contained in the value field. 1199 o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge 1200 supports a given ECT-ALGORITHM (by OUI/Index) on a given VID. 1202 o ECT Information: ECT-ALGORITHM Information of variable length in 1203 sub-TLV format using new IANA type values as appropriate. 1205 16. Service information extensions 1207 16.1. SPBM Service Identifier and Unicast Address sub-TLV 1209 The SPBM Service Identifier and Unicast Address sub-TLV (type=3) is 1210 used to introduce service group membership on the originating node 1211 and/or to advertise an additional B-MAC unicast address present on, 1212 or reachable by the node. 1214 +-+-+-+-+-+-+-+-+ 1215 |Type = SPBM-SI | = 3 1216 +-+-+-+-+-+-+-+-+ 1217 | Length | (1 byte) 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | B-MAC ADDRESS | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | B-MAC ADDRESS (6 bytes) | Res. | Base-VID (12 bits) | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 |T|R| Reserved | ISID #1 | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 |T|R| Reserved | ISID #2 | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 |T|R| Reserved | ISID #n | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 o Type: sub-TLV Type = 3 (Pending IANA) 1232 o Length: Total number of bytes contained in the value field. 1234 o B-MAC ADDRESS is a unicast address of this node. It may be 1235 either the single nodal address, or may address a port or any 1236 other level of granularity relative to the node. In the case 1237 where the node only has one B-MAC address this should be the same 1238 as the SYS-ID of the node. To add multiple B-MACs this TLV must 1239 be repeated per additional B-MAC. 1241 o ISID #1 .. #N are 24 bit service group membership identifiers. 1242 If two nodes have an I-SID in common, intermediate nodes on the 1243 unique shortest path between them will create forwarding state 1244 for the related B-MAC addresses and will also construct multicast 1245 forwarding state using the I-SID and the node's SPSourceID to 1246 construct a multicast DA as described in IEEE 802.1aq LSB. Each 1247 I-SID has a Transmit(T) and Receive(R) bit which indicates if the 1248 membership is as a Transmitter/Receiver or both (with both bits 1249 set). In the case where the Transmit(T) and Receive(R) bits are 1250 both zero, the I-SID instance is ignored for the purposes of 1251 distributed multicast computation, but the unicast B-MAC address 1252 must be processed and installed at nodes providing transit to 1253 that address. If more I-SIDs are associated with a particular B- 1254 MAC than can fit in a single sub-TLV, this sub-TLV can be 1255 repeated with the same B-MAC but with different I-SID values. 1257 o Note when the T bit is not set an SPB MAY still multicast to all 1258 the other receive members of this I-SID (those advertising with 1259 their R bits set), by configuring edge replication and serial 1260 unicast to each member locally. 1262 The SPBM Service Identifier sub-TLV, when present, MUST be carried 1263 within the MT Capability TLV and can occur multiple times in any LSP 1264 fragment. 1266 16.2. SPBV Mac Address sub-TLV 1268 The SPBV MAC Address (SPBV-MAC-ADDR) sub-TLV is IS-IS sub-TLV type 4 1269 (PENDING IANA). It SHOULD be used for advertisement of Group MAC 1270 Addresses in SPBV mode. Unicast MAC addresses will normally be 1271 distributed by reverse path leaning, but carrying them in this TLV 1272 is not precluded. It has the following format : 1274 +-+-+-+-+-+-+-+-+ 1275 | Type=SPBV-ADDR| = 4 (1 byte) 1276 +-+-+-+-+-+-+-+-+ 1277 | Length | (1 byte) 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 |R|R|S-R| SPVID | (2 bytes) 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 |T|R| Reserved | MAC 1 Address | (1+6 bytes) 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | ... | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 |T|R| Reserved | MAC N Address | (1+6 bytes) 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 o Type: sub-TLV Type, set to 4. 1289 o Length: Total number of bytes contained in the value field. The 1290 number of MAC address associated with the SPVID is computed by 1291 (Length - 2)/7. 1293 o S-R bits (2-bits) The SR bits are the service requirement 1294 parameter from MMRP. The service requirement parameters have the 1295 value 0 (Forward all Groups) and 1 (Forward All Unregistered 1296 Groups) defined. However this attribute may also be missing. So 1297 the SR bits are defined as 0 not declared, 1 Forward all Groups 1298 and 2 Forward All Unregistered Groups. The two 'R' reserved bits 1299 immediately preceding these SR bits should be set to zero when 1300 originating this sub-TLV and ignored on receipt. 1302 o SPVID (12-bits) The SPVID and by association Base VID and the 1303 ECT-ALGORITHM and SPT Set that the MAC addresses defined below 1304 will use. If the SPVID is not allocated the SPVID Value is 0. 1305 Note that if the ECT-Algorithm in use is Spanning Tree Algorithm 1306 this value should be populated with the Base VID and the MAC can 1307 be populated. 1309 o T Bit (1-bit) This is the Transmit allowed Bit for a following 1310 group MAC address. This is an indication that the Group MAC 1311 Address in the context of the SPVID of the bridge advertising 1312 this Group MAC should be installed in the FDB of transit bridges, 1313 when the bridge computing the trees is on the corresponding ECT- 1314 ALGORITHM shortest path between the bridge advertising this MAC 1315 with the T bit set, and any receiver of this Group MAC Address. 1316 A bridge that does not advertise this bit set for a MAC Address 1317 should cause no multicast forwarding state to be installed for 1318 traffic originating from that bridge on other transit bridges in 1319 the network. 1321 o R Bit (1-bit) This is the Receive allowed Bit for the following 1322 MAC Address. This is an indication that MAC Addresses as receiver 1323 should be populated and installed when the bridge computing the 1324 trees lies on the corresponding shortest path for this ECT- 1325 ALGORITHM between this receiver and any transmitter to this MAC 1326 Address. An entry that does not have this bit set for a Group 1327 MAC Address is prevented from receiving on this Group MAC Address 1328 because transit bridges will not install multicast forwarding 1329 state towards it in their FDBs, or the traffic is explicitly 1330 filtered. 1332 o MAC Address (48-bits) The MAC address declares this bridge as 1333 part of the multicast interest for this destination MAC address. 1334 Multicast trees can be efficiently constructed for destination by 1335 populating FDB entries for the subset of the shortest path tree 1336 that connects the bridges supporting the MAC address. This 1337 replaces the function of MMRP for SPTs. The T and R bits above 1338 have meaning as specified above. 1340 The SPBV-MAC-ADDR sub-TLV, when present, MUST be carried within the 1341 MT-Capability TLV and can occur multiple times in any LSP fragment. 1343 17. Security Considerations 1345 This document adds no additional security risks to IS-IS, nor does 1346 it provide any additional security for IS-IS. 1348 18. IANA Considerations 1350 Note that the NLPID value 0xC1 [NLPID] used in the IIH PDUs has 1351 already been assigned by IANA for the purpose of 802.1aq therefore 1352 no further action is required for this code point. 1354 Since 802.1aq operates within the IS-IS Multi Topology framework 1355 every sub-tlv MUST occur in the context of the proper MT TLV. There 1356 are three Multi Topology TLV's in which 802.1aq requests allocation 1357 of sub-TLV's. These are the MT-Port-Capability used in the IIH, the 1358 MT-Capability (new) used within the LSP and finally the MT- 1359 Intermediate-System TLV used to contain adjacency information within 1360 the LSP. 1362 This document creates the following TLVs & sub-TLV's within the IIH 1363 and LSP PDUs MT TLV's as described below. The '*' indicates IANA 1364 action is required. Other entries are shown to provide context only. 1365 A '?' next to a number indicates a requested but of course not 1366 necessarily the final assigned value. 1368 The MT-Capability TLV is the only TLV requiring a new sub-registry. 1369 Type value 144 is requested with a starting sub-tlv value of 1. 1371 +-----+----+-----------------+--------+------+-------------+ 1372 | PDU |TLV | SUB-TLV | TYPE | TYPE | #OCCURRENCE | 1373 +-----+----+-----------------+--------+------+-------------+ 1374 IIH 1375 MT-Port-Capability 143 1376 * SPB-MCID 6? 1 1377 * SPB-Digest 7? >=0 1378 * SPB-B-VID 8? 1 1380 LSP 1381 * MT-Capability 144? 1382 * SPB-Inst 1? 1 1383 * SPB-I-OALG 2? >=0 1384 * SPBM-SI 3? >=0 1385 * SPBV-ADDR 4? >=0 1387 MT-Intermediate-System 222 1388 or Extended IS Reachability 22 1389 * SPB-Metric 12? 1 1390 * SPB-A-OALG 13? >=0 1392 19. References 1394 19.1. Normative References 1396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1397 Requirement Levels", BCP 14, RFC 2119, March 1997. 1399 [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System 1400 to Intermediate System Intra-Domain Routing Exchange 1401 Protocol for use in Conjunction with the Protocol for 1402 Providing the Connectionless-mode Network Service (ISO 1403 8473)", 2002. 1405 [MT] M-ISIS: Multi Topology (MT) Routing in Intermediate System 1406 to Intermediate Systems (IS-ISs), RFC 5120, February 2008. 1408 [NLPID] IANA registry at: 1409 http://www.iana.org/assignments/nlpids/nlpids.xhtml 1411 19.2. Informative References 1413 [PB] "Standard for Local and Metropolitan Area Networks / 1414 Virtual Bridged Local Area Networks / Amendment 4: 1415 Provider Bridges, IEEE STD 802.1ad", 2005. 1417 [PBB] "Standard for Local and Metropolitan Area Networks / 1418 Virtual Bridged Local Area Networks / Amendment 7: 1419 Provider Backbone Bridges, IEEE STD 802.1ah", 2008. 1421 [802.1aq] "Standard for Local and Metropolitan Area Networks / 1422 Virtual Bridged Local Area Networks / Amendment: Shortest 1423 Path Bridging, Draft IEEE P802.6aq/3.2", 2010. 1425 20. Acknowledgments 1427 The authors would like to thank Ayan Banerjee, Mick Seaman, Janos 1428 Farkas, Les Ginsberg and Mike Shand for contributions and/or 1429 detailed review. 1431 This document was prepared using 2-Word-v2.0.template.dot. 1433 21. Author's Addresses 1435 Don Fedyk 1436 Alcatel-Lucent 1437 Groton, MA, 01450, USA 1438 Donald.Fedyk@alcatel-lucent.com 1440 Peter Ashwood-Smith 1441 Huawei Technologies Canada Ltd, 1442 Ottawa, Ontario, CANADA 1443 Peter.AshwoodSmith@huawei.com 1445 Dave Allan 1446 Ericsson, CANADA 1447 Email: david.i.allan@ericsson.com 1449 Nigel Bragg 1450 Ciena 1451 Email: nbragg@ciena.com 1453 Paul Unbehagen 1454 Alcatel-Lucent 1455 8742 Lucent Boulevard 1456 Highlands Ranch, CO 80129, USA 1457 Paul.Unbehagen@alcatel-lucent.com 1459 22. Intellectual Property Statement 1461 The IETF Trust takes no position regarding the validity or scope of 1462 any Intellectual Property Rights or other rights that might be 1463 claimed to pertain to the implementation or use of the technology 1464 described in any IETF Document or the extent to which any license 1465 under such rights might or might not be available; nor does it 1466 represent that it has made any independent effort to identify any 1467 such rights. 1469 Copies of Intellectual Property disclosures made to the IETF 1470 Secretariat and any assurances of licenses to be made available, or 1471 the result of an attempt made to obtain a general license or 1472 permission for the use of such proprietary rights by implementers or 1473 users of this specification can be obtained from the IETF on-line 1474 IPR repository at http://www.ietf.org/ipr 1476 The IETF invites any interested party to bring to its attention any 1477 copyrights, patents or patent applications, or other proprietary 1478 rights that may cover technology that may be required to implement 1479 any standard or specification contained in an IETF Document. Please 1480 address the information to the IETF at ietf-ipr@ietf.org. 1482 23. Disclaimer of Liability 1484 This document and the information contained herein are provided on 1485 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1486 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1487 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1488 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1489 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1490 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS.