idnits 2.17.1 draft-ietf-pwe3-iccp-stp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2015) is 3120 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Proposed Standard Huafeng Wen 4 Expires: April 11, 2016 Huawei 5 Jie Hu 6 China Telecom 7 October 9, 2015 9 Spanning Tree Protocol (STP) Application 10 of Inter-Chassis Communication Protocol (ICCP) 11 draft-ietf-pwe3-iccp-stp-05.txt 13 Abstract 15 Inter-Chassis Communication Protocol (ICCP) supports an inter-chassis 16 redundancy mechanism which is used to support high network 17 availability. 19 In this document, Provider Edge (PE) devices in a Redundancy Group 20 (RG) running ICCP are used to offer multi-homed connectivity to 21 Spanning Tree Protocol (STP) networks to improve availability of the 22 STP networks. The ICCP TLVs and usage for the ICCP STP application 23 are defined. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Conventions used in this document . . . . . . . . . . . . . 4 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Spanning Tree Protocol Application TLVs . . . . . . . . . . . . 6 68 3.1. STP Connect TLV . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. STP Disconnect TLV . . . . . . . . . . . . . . . . . . . . 7 70 3.2.1. STP Disconnect Cause sub-TLV . . . . . . . . . . . . . 7 71 3.3. STP Config TLVs . . . . . . . . . . . . . . . . . . . . . . 8 72 3.3.1. STP System Config . . . . . . . . . . . . . . . . . . . 8 73 3.3.2. STP Region Name . . . . . . . . . . . . . . . . . . . . 9 74 3.3.3. STP Revision Level . . . . . . . . . . . . . . . . . . 10 75 3.3.4. STP Instance Priority . . . . . . . . . . . . . . . . . 11 76 3.3.5. STP Configuration Digest . . . . . . . . . . . . . . . 11 77 3.4. STP State TLVs . . . . . . . . . . . . . . . . . . . . . . 12 78 3.4.1. STP Topology Changed Instances . . . . . . . . . . . . 12 79 3.4.2. STP CIST Root Time Parameters . . . . . . . . . . . . . 13 80 3.4.3. STP MSTI Root Time Parameter . . . . . . . . . . . . . 15 81 3.5. STP Synchronization Request TLV . . . . . . . . . . . . . . 15 82 3.6. STP Synchronization Data TLV . . . . . . . . . . . . . . . 17 83 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 4.1. Common AC Procedures . . . . . . . . . . . . . . . . . . . 18 85 4.1.1. Remote PE Node Failure or Isolation . . . . . . . . . . 18 86 4.1.2. Local PE Isolation . . . . . . . . . . . . . . . . . . 18 87 4.2. ICCP STP Application Procedures . . . . . . . . . . . . . . 19 88 4.2.1. Initial Setup . . . . . . . . . . . . . . . . . . . . . 19 89 4.2.2. Configuration Synchronization . . . . . . . . . . . . . 20 90 4.2.3. State Synchronization . . . . . . . . . . . . . . . . . 20 91 4.2.4. Failure and Recovery . . . . . . . . . . . . . . . . . 21 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 22 94 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 97 7.2. Informative References . . . . . . . . . . . . . . . . . . 23 98 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 100 1. Introduction 102 Inter-Chassis Communication Protocol (ICCP [RFC7275]) specifies a 103 multi-chassis redundancy mechanism which enables Provider Edge (PE) 104 devices located in a multi-chassis arrangement to act as a single 105 Redundancy Group (RG). 107 With the Spanning Tree Protocol (STP), a spanning tree will be formed 108 over connected bridges by blocking some links between these bridges 109 so that forwarding loops are avoided. This document introduces 110 support of STP as a new application of ICCP. This STP application of 111 ICCP supports when a bridged STP network is connected to a RG, the RG 112 members act as a single root bridge participating in the operations 113 of STP protocol. 115 STP relevant information needs to be exchanged and synchronized among 116 the RG members. New ICCP TLVs for the ICCP STP application are 117 specified for this purpose. 119 From the point of view of the customer, the Service Provider is 120 providing a Virtual Private LAN Service (VPLS) [RFC4762]. 122 1.1. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 1.2. Terminology 130 ICCP: Inter-Chassis Communication Protocol 131 VPLS: Virtual Private LAN Service 132 STP: Spanning Tree Protocol 133 MSTP: Multiple Spanning Tree Protocol 134 MST: Multiple Spanning Trees 135 CIST: Common and Internal Spanning Tree ([802.1q] Section 3.27) 136 MSTI: Multiple Spanning Tree Instance ([802.1q] Section 3.138) 137 BPDU: Bridge Protocol Data Unit 139 In this document, unless otherwise explicitly noted, the term STP 140 also covers MSTP. 142 2. Use Case 144 Customers widely use Ethernet as an access technology [RFC4762]. It's 145 common that one customer's Local Area Network (LAN) has multiple 146 bridges connected to a carrier's network at different locations for 147 reliability purposes. Requirements for this use case are listed as 148 follows. 150 o Customers desire to balance the load among their available 151 connections to the carrier's network, therefore all the 152 connections need to be active. 154 o When one connection to the carrier network fails, customers 155 require a connection in another location to continue to work after 156 the re-convergence of the STP rather than compromising the whole 157 STP network. The failure of the connection may be due to the 158 failure of the PE, the attachment circuit (AC) or even the 159 Customer Edge (CE) device itself. 161 In order to meet these requirements, the 'ICCP-STP' model is 162 proposed. It introduces STP as a new application of ICCP. 164 +--------------+ +=============+ 165 | | | | 166 | | | | 167 | +---+ | | +-----+|<--|--Pseudowire-->| 168 | +---+CE1+<6>-------<5>+ PE1 || | | 169 | <1> +---+ | | +-----+|<--|--Pseudowire-->| 170 | +-+-+ | | || | 171 | |CE3| | | ||ICCP |--> Towards the Core 172 | +-+-+ | | || | 173 | <2> +---+ | | +-----+|<--|--Pseudowire-->| 174 | +---+CE2+<3>-------<4>+ PE2 || | | 175 | +---+ | | +-----+|<--|--Pseudowire-->| 176 | | | | 177 | Multi-homed | | Redundancy | 178 | STP Network | | Group | 179 +--------------+ +=============+ 181 Figure 2.1: A STP network is multihomed to RG running ICCP. 183 Figure 2.1 shows an example topology of this model. With ICCP, the 184 whole RG will be virtualized to be a single bridge. Each RG member 185 has its BridgeIdentifier (the MAC address). The numerically lowest 186 one is used as the BridgeIdentifier of the 'virtualized root bridge'. 187 The RG acts as if the ports connected to the STP network (port <4>, 188 <5>) are for the same root bridge. All these ports send the 189 configuration BPDU with the highest root priority to trigger the 190 construction of the spanning tree. The link between the peering PEs 191 is not visible to the bridge domains of the STP network. In this way, 192 the STP will always break a possible loop within the multi-homed STP 193 network by breaking the whole network into separate islands so that 194 each is attached to one PE. That forces all PEs in the RG to be 195 active. This is different from a generic VPLS [RFC4762] where the 196 root bridge resides in the customer network and the multi-homed PEs 197 act in the active-standby mode. Note that the specification of VPLS 198 remains unchanged other than for this operation. For instance, a 199 full-mesh of pseudowires (PWs) is established between PEs, and split- 200 horizon is still used to perform the loop-breaking through the core. 202 3. Spanning Tree Protocol Application TLVs 204 This section specifies the ICCP TLVs for the ICCP STP application. 205 The Unknown TLV bit (U-bit) and the Forward unknown TLV bit (F-bit) 206 of the following TLVs MUST be sent as cleared and processed on 207 receipt as specified in [RFC7275]. 209 3.1. STP Connect TLV 211 This TLV is included in the RG Connect message to signal the 212 initiation of ICCP STP application connection. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |U|F| Type=TBA1 | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Protocol Version |A| Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Optional Sub-TLVs | 222 ~ ~ 223 | | 224 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | ... | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 - U=F=0 230 - Type 232 set to TBA1 (value to be assigned by IANA) for "STP Connect TLV" 234 - Length 236 Length of the TLV in octets excluding the U-bit, F-bit, Type, 237 and Length fields. 239 - Protocol Version 241 The version of STP ICCP application protocol. This document 242 defines version 0x0001. 244 - A bit 246 Acknowledgement Bit. Set to 1 if the sender has received a STP 247 Connect TLV from the recipient. Otherwise, set to 0. 249 - Reserved 251 Reserved for future use. These bits MUST be sent as zero and 252 ignored on receipt. 254 - Optional Sub-TLVs 256 There are no optional Sub-TLVs defined for this version of the 257 protocol. 259 3.2. STP Disconnect TLV 261 This TLV is used in RG Disconnect Message to indicate that the 262 connection for the ICCP STP application is to be terminated. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |U|F| Type=TBA2 | Length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Optional Sub-TLVs | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 - U=F=0 274 - Type 276 set to TBA2 for "STP Disconnect TLV" 278 - Length 280 Length of the TLV in octets excluding the U-bit, F-bit, Type, 281 and Length fields. 283 - Optional Sub-TLVs 285 The only optional Sub-TLV defined for this version of the 286 protocol is the "STP Disconnect Cause" sub-TLV, defined below: 288 3.2.1. STP Disconnect Cause sub-TLV 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 |U|F| Type=TBA13 | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Disconnect Cause String | 295 ~ ~ 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 - U=F=0 300 - Type 302 set to TBA13 for "STP Disconnect Cause TLV" 304 - Length 306 Length of the TLV in octets excluding the U-bit, F-bit, Type, 307 and Length fields. 309 - Disconnect Cause String 311 Variable length string specifying the reason for the disconnect, 312 encoded in UTF-8 [RFC3629] format. Used for operational 313 purposes. 315 3.3. STP Config TLVs 317 The STP Config TLVs are sent in the RG Application Data message. When 318 STP Config TLV is received by a peer RG member, it MUST synchronize 319 the configuration information contained in the TLV. TLVs specified 320 from Section 3.3.1 through Section 3.3.5 defines specific 321 configuration information. 323 3.3.1. STP System Config 325 This TLV announces the local node's STP System Parameters to the RG 326 peers. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 |U|F| Type=TBA3 | Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | ROID | 334 + + 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | MAC Address | 338 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 - U=F=0 344 - Type 346 set to TBA3 for "STP System Config" 348 - Length 350 Length of the ROID plus the MAC address in octets. Always set to 351 14. 353 -ROID 355 Redundant Object Identifier, format defined in Section 6.1.3 of 356 [RFC7275]. 358 - MAC Address 360 The MAC address of the sender. This MAC address is set to the 361 BridgeIdentifier of the sender, as defined in [802.1q] Section 362 13.26.2. The numerically lowest 48 bit unsigned value of 363 BridgeIdentifier is used as the MAC address of the Virtual Root 364 Bridge mentioned in Section 2. 366 3.3.2. STP Region Name 368 This TLV carries the value of Region Name. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |U|F| Type=TBA4 | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Region Name | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 - U=F=0 380 - Type 382 set to TBA4 for "STP Region Name" 384 - Length 386 Length of the TLV in octets excluding the U-bit, F-bit, Type, 387 and Length fields. 389 - Region Name 391 The Name of the MST Region as specified in [802.1q] Section 392 3.142. 394 3.3.3. STP Revision Level 396 This TLV carries the value of Revision Level. 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 |U|F| Type=TBA5 | Length | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Revision Level | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 - U=F=0 408 - Type 410 Set to TBA5 for "STP Revision Level". 412 - Length 414 Length of the TLV in octets excluding the U-bit, F-bit, Type, 415 and Length fields. Always set to 2. 417 - Revision Level 418 The Revision Level as specified in [802.1q] Section 13.8 bullet 419 c)); 421 3.3.4. STP Instance Priority 423 This TLV carries the value of Instance Priority to other members in 424 the RG. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |U|F| Type=TBA6 | Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Pri | InstanceID | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 - U=F=0 436 - Type 438 set to TBA6 for "STP Instance Priority" 440 - Length 442 Length of the TLV in octets excluding the U-bit, F-bit, Type, 443 and Length fields. 445 - Pri 447 The Instance Priority. It is interpreted as unsigned integer 448 with higher value indicating a higher priority. 450 - InstanceID 452 The 12 bits Instance Identifier of the CIST or MSTI. This 453 parameter takes a value in the range 1 through 4094 for MSTI as 454 defined in [802.1q] Section 12.8.1.2.2 and takes value of 0 for 455 CIST. 457 3.3.5. STP Configuration Digest 459 This TLV carries the value of STP VLAN Instance Mapping. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 |U|F| Type=TBA7 | Length | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Configuration Digest | 467 ~ ~ 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 - U=F=0 472 - Type 474 set to TBA7 for "STP Configuration Digest" 476 - Length 478 Length of the STP Configuration Digest. Always set to 16 479 octets. 481 - Configuration Digest 483 As specified in [802.1q] Section 13.8 bullet d)). 485 3.4. STP State TLVs 487 The STP State TLVs are sent in the RG Application Data message. They 488 are used by a PE device to report its STP status to other members in 489 the RG. Such TLVs are specified in the following subsections. 491 3.4.1. STP Topology Changed Instances 493 This TLV is used to report the Topology Changed Instances to other 494 members of the RG. The sender monitors TCN messages and generates 495 this list. The receiving RG member MUST initiate the Topology Change 496 event, including sending BPDU with the Topology Change flag set to 1 497 out of the designated port(s) of the Topology Changed bridge domains 498 of the STP network, flushing out of MAC addresses relevant to the 499 instances listed in this TLV. 501 If the PE device supports MAC Address Withdrawal (see Section 6.2 of 502 [RFC4762]), it SHOULD send an Label Distribution Protocol (LDP) 503 Address Withdraw Message with the list of MAC addresses towards the 504 core over the corresponding LDP sessions. It is not necessary to send 505 such a message to PEs of the same RG since the flushing of their MAC 506 address tables should have been performed upon the receipt of "STP 507 Topology Changed Instances" TLV. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 |U|F| Type=TBA8 | Length | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | InstanceID List | 515 ~ ~ 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 - U=F=0 520 - Type 522 set to TBA8 for "STP Topology Changed Instances" 524 - Length 526 Length of the TLV in octets excluding the U-bit, F-bit, Type, 527 and Length fields. 529 - InstanceID List 531 The list of the InstanceIDs of CIST or MSTIs whose topologies 532 have changed as indicated by the Topology Change Notification 533 (TCN) Messages as specified in [802.1q] Section 13.14. The list 534 is formatted by padding Instance ID value to 16 bit boundary as 535 follows, where the bits in the "R" fields MUST be sent as zero 536 and ignored on receipt. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |R|R|R|R| InstanceID#1 |R|R|R|R| InstanceID#2 | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 ~ ... ... ~ 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 3.4.2. STP CIST Root Time Parameters 547 This TLV is used to report the Value of CIST Root Time Parameters 548 ([802.1q] Section 13.26.7) to other members of the RG. All time 549 parameter values are in seconds with a granularity of 1. For ranges 550 and default values of these parameter values, refer to [802.1d1998] 551 Section 8.10.2 Table 8-3, [802.1d2004] Section 17.14 Table 17-1, and 552 [802.1q] Section 13.26.7. 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 |U|F| Type=TBA9 | Length | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | MaxAge | MessageAge | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | FwdDelay | HelloTime | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | RemainingHops | 564 +-+-+-+-+-+-+-+-+ 566 - U=F=0 568 - Type 570 set to TBA9 for "STP CIST Root Time" 572 - Length 574 Length of the TLV in octets excluding the U-bit, F-bit, Type, 575 and Length fields. Always set to 9. 577 - MaxAge 579 The Max Age of the CIST. It is the maximum age of the 580 information transmitted by the bridge when it is the Root Bridge 581 ([802.1d2004] Section 17.13.8). 583 - MessageAge 585 The Message Age of the CIST (see [802.1q] Section 13.26.7). 587 - FwdDelay 589 The Forward Delay of the CIST. It is the delay used by STP 590 Bridges to transition Root and Designated Ports to Forwarding 591 ([802.1d2004] Section 17.13.5). 593 - HelloTime 595 The Hello Time of the CIST. It is the interval between periodic 596 transmissions of Configuration Messages by Designated Ports 597 ([802.1d2004] Section 17.13.6). 599 - RemainingHops 601 The remainingHops of the CIST ([802.1q] Section 13.26.7) . 603 3.4.3. STP MSTI Root Time Parameter 605 This TLV is used to report the parameter value of MSTI Root Time to 606 other members of the RG. As defined in [802.1q] Section 13.26.7, it 607 is the value of remainingHops for the given MSTI. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |U|F| Type=TBA10 | Length | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Pri | InstanceID | RemainingHops | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 - U=F=0 619 - Type 621 set to TBA10 for "STP MSTI Root Time" 623 - Length 625 Length of the TLV in octets excluding the U-bit, F-bit, Type, 626 and Length fields. Always set to 3. 628 - Pri 630 The Instance Priority. It is interpreted as an unsigned integer 631 with higher value indicating a higher priority. 633 - InstanceID 635 The 12 bits Instance IDentifier of the Multiple Spanning Tree 636 Instance (MSTID). As defined in [802.1q] Section 12.8.1.2.2, 637 this parameter takes a value in the range 1 through 4094. 639 - RemainingHops 641 The remainingHops of the MSTI. It is encoded in the same way as 642 in [802.1q] Section 14.4.1 bullet f). 644 3.5. STP Synchronization Request TLV 646 The STP Synchronization Request TLV is used in the RG Application 647 Data message. This TLV is used by a device to request from its peer 648 to re-transmit configuration or operational state. The following 649 information can be requested: 651 - configuration and/or state of the STP system, 652 - configuration and/or state for a given list of instances. 653 The format of the TLV is as follows: 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 |U|F| Type=TBA11 | Length | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Request Number |C|S| Request Type | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | InstanceID List | 663 ~ ~ 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 - U=F=0 668 - Type 670 set to TBA11 for "STP Synchronization Request TLV" 672 - Length 674 Length of the TLV in octets excluding the U-bit, F-bit, Type, 675 and Length fields. Always set to 4. 677 - Request Number 679 2 octets. Unsigned integer uniquely identifying the request. 680 Used to match the request with a corresponding response. The 681 value of 0 is reserved for unsolicited synchronization, and MUST 682 NOT be used in the STP Synchronization Request TLV. As indicated 683 in [RFC7275], given the use of TCP, there are no issues 684 associated with the wrap-around of the Request Number. 686 - C-bit 688 Set to 1 if the request is for configuration data. Otherwise, 689 set to 0. 691 - S-bit 693 Set to 1 if the request is for running state data. Otherwise, 694 set to 0. 696 - Request Type 697 14-bits specifying the request type, encoded as follows: 699 0x00 Request System Data 700 0x01 Request data of the listed instances 701 0x3FFF Request System Data and data of all instances 703 - InstanceID List 705 The InstanceIDs of CIST or MSTIs, format specified in Section 706 3.4.1. 708 3.6. STP Synchronization Data TLV 710 The pair of STP Synchronization Data TLVs are used by sender to 711 delimit a set of TLVs that are being transmitted in response to an 712 STP Synchronization Request TLV. The delimiting TLVs signal the start 713 and end of the synchronization data, and associate the response with 714 its corresponding request via the 'Request Number' field. It's 715 REQUIRED that each pair of STP Synchronization Data TLVs occur in the 716 same fragment. When the total size of the TLVs to be transmitted 717 exceeds the maximal size of a fragment, these TLVs MUST be divided 718 into multiple sets, delimited by multiple pairs of STP 719 Synchronization Data TLVs, and filled into multiple fragments. With 720 the Request Number lost fragments can be identified and re- 721 requested. 723 The STP Synchronization Data TLVs are also used for unsolicited 724 advertisements of complete STP configuration and operational state 725 data. The 'Request Number' field MUST be set to 0 in this case. 727 STP Synchronization Data TLV has the following format: 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 |U|F| Type=TBA12 | Length | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Request Number | Reserved |S| 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 - U=F=0 739 - Type 741 set to TBA12 for "STP Synchronization Data TLV" 743 - Length 744 Length of the TLV in octets excluding the U-bit, F-bit, Type, 745 and Length fields. Always set to 4. 747 - Request Number 749 2 octets. Unsigned integer identifying the Request Number of the 750 "STP Synchronization Request TLV" which initiated this 751 synchronization data response. 753 - Reserved 755 Reserved bits for future use. These MUST be sent as zero and 756 ignored on receipt. 758 -S 760 S = 0: Synchronization Data Start 761 S = 1: Synchronization Data End 763 4. Operations 765 Operational procedures for AC redundancy applications have been 766 specified in Section 9.2 of [RFC7275]. The operational procedures of 767 ICCP STP application should follow these procedures except the 768 changes presented in this section. 770 4.1. Common AC Procedures 772 For the generic procedures of AC redundancy applications defined in 773 Section 9.2.1 of [RFC7275], the following changes are introduced. 775 4.1.1. Remote PE Node Failure or Isolation 777 When a local PE device detects that a remote PE device that is a 778 member of the same RG is no longer reachable (using the mechanisms 779 described in Section 5 of [RFC7275]), the local PE device checks if 780 it has redundancy ACs for the affected services. In case of redundant 781 ACs present, and if the local PE device has the new highest bridge 782 priority, the local PE device becomes the virtual root bridge for 783 corresponding ACs. 785 4.1.2. Local PE Isolation 787 When a PE device detects that it has been isolated from the core 788 network, then it need ensure that its AC redundancy mechanism will 789 change the status of all active ACs to standby. The AC redundancy 790 application SHOULD then send ICCP "Application Data" message in order 791 to trigger failover to another active PE device in the RG. Note that 792 this works only in the case of dedicated interconnect (Sections 3.2.1 793 and 3.2.3), since ICCP will still have the path to the peer, even 794 though the PE device is isolated from the MPLS core network. 796 4.2. ICCP STP Application Procedures 798 This section defines the procedures that are specific to the ICCP STP 799 application which are applicable for Ethernet ACs. 801 4.2.1. Initial Setup 803 When a RG is configured on a system that supports the ICCP STP 804 application, such systems MUST send an "RG Connect" message with "STP 805 Connect TLV" to each PE device that is member of the RG. The sending 806 PE device MUST set the A bit to 1 in that TLV if it has received a 807 corresponding "STP Connect TLV" from its peer PE; otherwise, the 808 sending PE device MUST set the A bit to 0. If a PE device receives an 809 "STP Connect TLV" from its peer after sending its own TLV with the A 810 bit set to 0, it MUST resend the TLV with the A bit set to 1. A 811 system considers the ICCP STP application connection to be 812 operational when it has both sent and received "STP Connect TLVs" 813 with the A bit set to 1. When the ICCP STP application connection 814 between a pair of PEs is operational, the two devices can start 815 exchanging "RG Application Data" messages for the ICCP STP 816 application. This involves having each PE device advertise its STP 817 configuration and operational state in an unsolicited manner. A PE 818 device SHOULD follow the following order when advertising its STP 819 state upon initial application connection setup: 821 - Advertise system configuration TLV 822 - Advertise remaining configuration TLVs 823 - Advertise state TLVs 825 The update of the information contained in the State TLVs depends on 826 that in the configuration TLVs. By sending the TLVs in the above 827 order, the two peers may begin to update STP state as early as 828 possible in the middle of exchanging these TLVs. 830 A PE device MUST use a pair of "STP Synchronization Data TLVs" to 831 delimit the entire set of TLVs that are being sent as part of this 832 unsolicited advertisement. 834 If a system receives an "RG Connect" message with "STP Connect TLV" 835 that has a differing Protocol Version, it MUST follow the procedures 836 outlined in the "Application Versioning" Section of [RFC7275]. 838 After the ICCP STP application connection has been established, every 839 PE device MUST communicate its system level configuration to its 840 peers via the use of "STP System Config TLV". 842 When the ICCP STP application is administratively disabled on the PE, 843 or on the particular RG, the system MUST send an "RG Disconnect" 844 message containing "STP Disconnect TLV". 846 4.2.2. Configuration Synchronization 848 A system that supports ICCP STP application MUST synchronize the 849 configuration with other RG members. This is achieved via the use of 850 "STP Config TLVs". The PEs in the RG MUST all agree on the common MAC 851 address to be associated with the virtual root bridge. It is possible 852 to achieve this via consistent configuration on member PEs. However, 853 in order to protect against possible misconfigurations, a virtual 854 root bridge identifier MUST be set to the MAC address advertised by 855 the PE device with the numerically lowest BridgeIdentifier (i.e., the 856 MAC address of the bridge) in the RG. 858 Furthermore, for a given ICCP STP application, an implementation MUST 859 advertise the configuration prior to advertising its corresponding 860 state. If a PE device receives any STP State TLV that it had not 861 learned of before via an appropriate STP Config TLV, then the PE 862 device MUST request synchronization of the configuration and state 863 from its peer. If during such synchronization a PE device receives a 864 State TLV that it has not learned before, then the PE device MUST 865 send a NAK TLV for that particular TLV. The PE device MUST NOT 866 request resynchronization in this case. 868 4.2.3. State Synchronization 870 PEs within the RG need to synchronize their state for proper STP 871 operation. This is achieved by having each system advertise its 872 running state in STP State TLVs. Whenever any STP parameter either on 873 the CE or PE side is changed, the system MUST transmit an updated TLV 874 for the affected STP instances. Moreover, when the administrative or 875 operational state changes, the system MUST transmit an updated state 876 TLV to its peers. 878 A PE device MAY request its peer to retransmit previously advertised 879 state. This is useful in case of the PE device recovering from a soft 880 failure and attempting to relearn state. To request such 881 retransmissions, a PE device MUST send a set of one or more "STP 882 Synchronization Request TLVs". 884 A PE device MUST respond to a "STP Synchronization Request TLV" by 885 sending the requested data in a set of one or more STP configuration 886 or state TLVs delimited by a pair of "STP Synchronization Data 887 TLVs". 889 Note that the response may span across multiple RG Application Data 890 messages, for example when MTU limits are exceeded; however, the 891 above ordering MUST be retained across messages, and only a single 892 pair of Synchronization Data TLVs MUST be used to delimit the 893 response across all Application Data Messages. 895 A PE device MAY readvertise its STP state in an unsolicited manner. 896 This is done by sending the appropriate State TLVs delimited by a 897 pair of "STP Synchronization Data TLVs" and using a 'Request Number' 898 of 0. 900 While a PE device has sent out a synchronization request for a 901 particular PE device, it SHOULD silently ignore all TLVs from that 902 node, that are received prior to the synchronization response and 903 which carry the same type of information being requested. This saves 904 the system from the burden of updating state that will ultimately be 905 overwritten by the synchronization response. Note that TLVs 906 pertaining to other systems should continue to be processed normally. 908 If a PE device receives a synchronization request for an instance 909 that doesn't exist or is not known to the PE, then it MUST trigger 910 the unsolicited synchronization of all information by restarting the 911 initialization. 913 If during the synchronization operation a PE device receives an 914 advertisement of a Node ID value which is different from the value 915 previously advertised, then the PE device MUST purge all state data 916 previously received from that peer prior to the last synchronization. 918 4.2.4. Failure and Recovery 920 When a PE device that is active for the ICCP STP application 921 encounters a core isolation fault [RFC7275], it SHOULD attempt to 922 fail-over to a peer PE device which hosts the same RG. The default 923 fail-over procedure is to have the failed PE device bring down the 924 link(s) towards the multi-homed STP network. This will cause the STP 925 network to reconverge and to use the other links that are connected 926 to the other PE devices in the RG. Other procedures for triggering 927 fail-over are possible, and are outside the scope of this document. 929 If the isolated PE device is the one that has the numerically lowest 930 BridgeIdentifier, PEs in the RG MUST synchronize STP configuration 931 and state TLVs and determine a new virtual root bridge as specified 932 in Section 4.2.2. 934 Upon recovery from a previous fault, a PE device SHOULD NOT reclaim 935 the role of the virtual root for the STP network even if it has the 936 numerically lowest BridgeIdentifier among the RG. This minimizes 937 traffic disruption. 939 Whenever the virtual root bridge changes, the STP Topology Changed 940 Instances TLV lists the instances that are affected by the change. 941 These instances MUST undergo a STP reconvergence procedure when this 942 TLV is received as defined in Section 3.4.1. 944 5. Security Considerations 946 This document specifies an application running on the channel 947 provided by ICCP [RFC7275]. The security considerations on ICCP apply 948 in this document as well. 950 For the ICCP STP application, an attack on a channel (running in the 951 provider's network) can break not only the ability to deliver traffic 952 across the provider's network, but also the ability to route traffic 953 within the customer's network. That is, a careful attack on a channel 954 (such as the DOS attacks as described in [RFC7275]) can break STP 955 within the customer network. Implementations need provide mechanisms 956 to mitigate these types of attacks. For example, the port between the 957 PE device and the malicious CE device may be blocked. 959 6. IANA Considerations 961 The IANA maintains a top-level registry called "Pseudowire Name 962 Spaces (PWE3)". It has a sub-registry called "ICC RG Parameter 963 Types". 965 IANA is requested to make 13 allocations from this registry as shown 966 below. IANA is requested to allocate the codepoints in sequential 967 block starting from the next available value in the range marked for 968 assignment by IETF review (0x2000-0x2FFF) [RFC5226]. All assignments 969 should reference this document. 971 Parameter Type Description 972 -------------- --------------------------------- 973 TBA1 STP Connect TLV 974 TBA2 STP Disconnect TLV 975 TBA3 STP System Config TLV 976 TBA4 STP Region Name TLV 977 TBA5 STP Revision Level TLV 978 TBA6 STP Instance Priority TLV 979 TBA7 STP Configuration Digest TLV 980 TBA8 STP Topology Changed Instances TLV 981 TBA9 STP STP CIST Root Time TLV 982 TBA10 STP MSTI Root Time TLV 983 TBA11 STP Synchronization Request TLV 984 TBA12 STP Synchronization Data TLV 985 TBA13 STP Disconnect Cause TLV 987 Acknowledgements 989 Authors would like to thank the comments and suggestions from Ignas 990 Bagdonas, Adrian Farrel, Andrew G. Malis, Gregory Mirsky and 991 Alexander Vainshtein. 993 7. References 995 7.1. Normative References 997 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 998 Requirement Levels", BCP 14, RFC 2119, March 1997. 1000 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 1001 STD 63, RFC 3629, November 2003. 1003 [RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private 1004 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1005 Signaling", RFC 4762, January 2007. 1007 [RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., Matsushima, 1008 S., and T. Nadeau, "Inter-Chassis Communication Protocol for 1009 Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) 1010 Redundancy", RFC 7275, June 2014. 1012 [802.1q] "IEEE Standard for Local and Metropolitan Area Networks--- 1013 Virtual Bridged Local Area Networks". IEEE Std 802.1 Q-2014, 1014 November 11, 2014. 1016 [802.1d1998] "Information technology---Telecommunications and 1017 information exchange between systems---Local and metropolitan 1018 area networks---Common specifications--Part 3: Media Access 1019 Control (MAC) Bridges". ANSI/IEEE Std 802.1D, 1998 Edition. 1021 [802.1d2004] "IEEE Standard for Local and metropolitan area networks- 1022 -- Media Access Control (MAC) Bridges". IEEE Std 802.1 D-2004. 1024 7.2. Informative References 1026 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1027 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 1028 2008. 1030 Author's Addresses 1032 Mingui Zhang 1033 Huawei Technologies 1034 No. 156 Beiqing Rd. Haidian District, 1035 Beijing 100095 1036 P.R. China 1038 EMail: zhangmingui@huawei.com 1040 Huafeng Wen 1041 Huawei Technologies 1042 101 Software Avenue, 1043 Nanjing 210012 1044 P.R. China 1046 EMail: wenhuafeng@huawei.com 1048 Jie Hu 1049 China Telecom 1051 EMail: hujie@ctbri.com.cn