RFC 7727
Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP)
RFC 7727: Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) 🎀
okay bestie, this one is ICCP with an STP application, and it's giving multihoming glow-up 💅✨. It was written by M. Zhang and H. Wen from Huawei, and J. Hu from China Telecom. It's a Standards Track document (ISSN 2070-1721), published in January 2016. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🦋.
Abstract 🌸
okay so ICCP is the thing that does inter-chassis redundancy so networks stay highly available 🫶. In this doc, a bunch of PE devices in a Redundancy Group (RG) running ICCP team up to give an STP network multihomed connectivity, which makes that STP network way more available 💖. It also defines the ICCP TLVs and how they get used for the ICCP STP application 🧚.
Status of This Memo 📜
this is an Internet Standards Track document 💜.
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) ✨. if you want more info on Internet Standards, check Section 2 of RFC 5741. you can also find the current status, errata, and feedback info at http://www.rfc-editor.org/info/rfc7727 🔥.
Copyright Notice 🌈
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🍓.
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the publication date. read them carefully, bestie, because they explain your rights and restrictions with respect to this document 💅. any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶.
Table of Contents 📑
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
2. Use Case ........................................................5
3. Spanning Tree Protocol Application TLVs .........................6
3.1. STP Connect TLV ............................................6
3.2. STP Disconnect TLV .........................................7
3.2.1. STP Disconnect Cause Sub-TLV ........................8
3.3. STP Configuration TLVs .....................................8
3.3.1. STP System Config ...................................9
3.3.2. STP Region Name ....................................10
3.3.3. STP Revision Level .................................10
3.3.4. STP Instance Priority ..............................11
3.3.5. STP Configuration Digest ...........................12
3.4. STP State TLVs ............................................12
3.4.1. STP Topology Changed Instances .....................12
3.4.2. STP CIST Root Time Parameters ......................14
3.4.3. STP MSTI Root Time Parameter .......................15
3.5. STP Synchronization Request TLV ...........................16
3.6. STP Synchronization Data TLV ..............................17
4. Operations .....................................................18
4.1. Common AC Procedures ......................................18
4.1.1. Remote PE Node Failure or Isolation ................19
4.1.2. Local PE Isolation .................................19
4.2. ICCP STP Application Procedures ...........................19
4.2.1. Initial Setup ......................................19
4.2.2. Configuration Synchronization ......................20
4.2.3. State Synchronization ..............................21
4.2.4. Failure and Recovery ...............................22
5. Security Considerations ........................................22
6. IANA Considerations ............................................23
7. References .....................................................23
7.1. Normative References ......................................23
7.2. Informative References ....................................24
Acknowledgements ................................................. 24
Authors' Addresses ............................................... 251. Introduction ✨
okay so ICCP (ICCP [RFC7275]) is a multi-chassis redundancy mechanism 🦋. It lets Provider Edge (PE) devices sitting in a multi-chassis setup act as one single Redundancy Group (RG) 💖.
so with the Spanning Tree Protocol (STP), a spanning tree gets built over connected bridges by blocking some links, and that's how forwarding loops get avoided 🌸. this doc adds STP as a brand-new application of ICCP 🧚. when a bridged STP network hooks up to an RG, the STP application lets the RG members act as one single root bridge that takes part in STP operations 👑.
STP-relevant info has to get exchanged and synced across the RG members 🫶. the new ICCP TLVs for the ICCP STP application are specified for exactly that job 💅.
and from the customer's point of view, the Service Provider is giving them a Virtual Private LAN Service (VPLS) [RFC4762] 🌈.
1.1. Conventions Used in This Document 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💜.
1.2. Terminology 📖
ICCP: Inter-Chassis Communication ProtocolVPLS: Virtual Private LAN ServiceSTP: Spanning Tree ProtocolMSTP: Multiple Spanning Tree ProtocolMST: Multiple Spanning TreesCIST: Common and Internal Spanning Tree ([802.1q], Section 3.27)MSTI: Multiple Spanning Tree Instance ([802.1q], Section 3.138)BPDU: Bridge Protocol Data Unit
in this doc, unless it's explicitly noted otherwise, the term "STP" also covers MSTP 🍓.
2. Use Case 🧚
customers love Ethernet as an access technology [RFC4762] 💖. it's super common for one customer's Local Area Network (LAN) to have several bridges hooked up to a carrier's network at different locations, all for reliability 🫶. the requirements for this use case are listed below 👑.
- Customers want to balance the load across their available connections to the carrier's network, so all the connections need to be active 🔥.
- When one connection to the carrier network fails, customers need a connection in another location to keep working after STP reconverges, instead of wrecking the whole STP network 😭. the failure might be caused by the PE, the attachment circuit (AC), or even the Customer Edge (CE) device itself 💀.
to meet these requirements, the 'ICCP-STP' model gets proposed 🦋. it brings in STP as a new application of ICCP ✨.
+--------------+ +=============+
| | | |
| | | |
| +---+ | | +-----+|<--|--Pseudowire-->|
| +---+CE1+<6>-------<5>+ PE1 || | |
| <1> +---+ | | +-----+|<--|--Pseudowire-->|
| +-+-+ | | || |
| |CE3| | | ||ICCP |--> Towards the Core
| +-+-+ | | || |
| <2> +---+ | | +-----+|<--|--Pseudowire-->|
| +---+CE2+<3>-------<4>+ PE2 || | |
| +---+ | | +-----+|<--|--Pseudowire-->|
| | | |
| Multihomed | | Redundancy |
| STP Network | | Group |
+--------------+ +=============+Figure 1: A STP network is multihomed to an RG running ICCP
figure 1 shows an example topology for this model 🌈. with ICCP, the whole RG gets virtualized into a single bridge 💖. each RG member has its own BridgeIdentifier (the MAC address) 🌸. the numerically lowest one becomes the BridgeIdentifier of the 'virtualized root bridge' 👑. the RG acts as if the ports hooked up to the STP network (ports <4> and <5>) all belong to the same root bridge ✨. every one of those ports sends the configuration BPDU with the highest root priority, which kicks off building the spanning tree 🔥. the link between the peering PEs is invisible to the bridge domains of the STP network 🙈. so STP always breaks any possible loop inside the multihomed STP network by splitting the whole network into separate islands, each attached to one PE 🧚. that forces every PE in the RG to be active 💅. this is different from a generic VPLS [RFC4762], where the root bridge lives in the customer network and the multihomed PEs run in active-standby mode 🫶. the VPLS spec stays the same apart from this operation 🎀. for example, a full-mesh of pseudowires (PWs) gets set up between PEs, and the "split horizon" rule still does the loop-breaking through the core 💜.
3. Spanning Tree Protocol Application TLVs 🦋
this section specifies the ICCP TLVs for the ICCP STP application 💖. the Unknown TLV bit (U-bit) and the Forward unknown TLV bit (F-bit) of the following TLVs MUST be sent as cleared, and they get processed on receipt as specified in [RFC7275] 🔥.
3.1. STP Connect TLV 🎀
this TLV is included in the RG Connect Message to signal the start of an ICCP STP application connection 🌈.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2000 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type: set to
0x2000for the "STP Connect TLV" 💜. - Length: the length of the TLV in octets, not counting the U-bit, F-bit, Type, and Length fields 🍓.
- Protocol Version: the version of the ICCP STP application protocol. this document defines version
0x0001✨. - A bit: the Acknowledgement Bit 🫶. it's set to 1 if the sender has received an STP Connect TLV from the recipient, and set to 0 otherwise 🔥.
- Reserved: reserved for future use 🙈. these bits MUST be sent as 0 and ignored on receipt 😭.
- Optional Sub-TLVs: there are no optional Sub-TLVs defined for this version of the protocol 💅.
part 1 done, bestie! 🌈💖 part 2 is coming next 🧚
3.2. STP Disconnect TLV 💔
Okay bestie, this TLV only shows up in the RG Disconnect Message 📨. Its whole job is to say "we're done here" and tell the ICCP STP connection to shut down 🥀.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type
- Set to
0x2001for "STP Disconnect TLV"
- Set to
- Length
- The length of the TLV in octets. It does not count the U-bit, F-bit, Type, or Length fields.
- Optional Sub-TLVs
- The only optional Sub-TLV defined for this version of the protocol is the "STP Disconnect Cause" sub-TLV, which is defined below:
3.2.1. STP Disconnect Cause Sub-TLV 🗣️
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200C | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type
- Set to
0x200Cfor "STP Disconnect Cause TLV"
- Set to
- Length
- The length of the TLV in octets. It does not count the U-bit, F-bit, Type, or Length fields.
- Disconnect Cause String
- A variable-length string that explains why the disconnect happened. It is encoded in UTF-8 [RFC3629] format and is used for operational purposes 🛠️.
3.3. STP Configuration TLVs ⚙️
The STP Configuration TLVs get sent in the RG Application Data Message 📬. When a peer RG member gets an STP Config TLV, that member MUST synchronize with the configuration info inside it 🤝. Sections 3.3.1 to 3.3.5 define the specific config info.
3.3.1. STP System Config 🖥️
This TLV announces the local node's STP System Parameters to its RG peers 📣.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type
- Set to
0x2002for "STP System Config TLV"
- Set to
- Length
- The length of the ROID plus the MAC address, in octets. It is always set to
14.
- The length of the ROID plus the MAC address, in octets. It is always set to
- ROID
- Redundant Object Identifier. Its format is defined in Section 6.1.3 of [RFC7275].
- MAC Address
- The MAC address of the sender. This MAC address is set to the BridgeIdentifier of the sender, as defined in [802.1q], Section 13.26.2. The numerically lowest 48-bit unsigned value of BridgeIdentifier is used as the MAC address of the Virtual Root Bridge mentioned in Section 2 🌉.
3.3.2. STP Region Name 🗺️
This TLV carries the value of the Region Name 🏷️.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type
- Set to
0x2003for "STP Region Name TLV"
- Set to
- Length
- The length of the TLV in octets. It does not count the U-bit, F-bit, Type, or Length fields.
- Region Name
- The Name of the MST Region, as specified in [802.1q], Section 3.142.
3.3.3. STP Revision Level 🔢
This TLV carries the value of the Revision Level 🎯.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revision Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type
- Set to
0x2004for "STP Revision Level TLV".
- Set to
- Length
- The length of the TLV in octets. It does not count the U-bit, F-bit, Type, or Length fields. It is always set to
2.
- The length of the TLV in octets. It does not count the U-bit, F-bit, Type, or Length fields. It is always set to
- Revision Level
- The Revision Level, as specified in [802.1q], Section 13.8, item c.
3.3.4. STP Instance Priority 🥇
This TLV carries the value of the Instance Priority to the other members of the RG 🫶.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2005 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri | InstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type
- Set to
0x2005for "STP Instance Priority TLV"
- Set to
- Length
- The length of the TLV in octets. It does not count the U-bit, F-bit, Type, or Length fields.
- Pri
- The Instance Priority. It is read as an unsigned integer, and a higher value means a higher priority 🚀.
- InstanceID
- The 12-bit Instance Identifier of the CIST or MSTI. For an MSTI, this parameter takes a value in the range 1 through 4094 (as defined in [802.1q], Section 12.8.1.2.2). For the CIST, it takes a value of 0.
3.3.5. STP Configuration Digest 🔐
This TLV carries the value of the STP VLAN Instance Mapping 🗂️.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2006 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Configuration Digest |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type
- Set to
0x2006for "STP Configuration Digest TLV"
- Set to
- Length
- The length of the STP Configuration Digest, in octets. It is always set to
16.
- The length of the STP Configuration Digest, in octets. It is always set to
- Configuration Digest
- As specified in [802.1q], Section 13.8, item d.
3.4. STP State TLVs 📊
The STP State TLVs get sent in the RG Application Data Message 💌. A PE device uses them to report its STP status to the other members of the RG. The specific TLVs are in the subsections below.
3.4.1. STP Topology Changed Instances 🌀
This TLV reports the Topology Changed Instances to the other members of the RG 📢. The sender keeps an eye on Topology Change Notification (TCN) messages and builds this list 👀. The receiving RG member MUST start the Topology Change event. That means sending a BPDU with the Topology Change flag set to 1 out of the designated port(s) of the Topology Changed bridge domains of the STP network, and flushing the MAC addresses that belong to the instances in this TLV 🧹.
If the PE device supports MAC Address Withdrawal (see Section 6.2 of [RFC4762]), it SHOULD send a Label Distribution Protocol (LDP) Address Withdraw Message with the list of MAC addresses toward the core over the matching LDP sessions. There's no need to send that message to PEs in the same RG, because they should already have flushed their MAC address tables when they got the STP Topology Changed Instances TLV 🙌.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InstanceID List |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0- Type
- Set to
0x2007for "STP Topology Changed Instances TLV"
- Set to
- Length
- The length of the TLV in octets. It does not count the U-bit, F-bit, Type, or Length fields.
- InstanceID List
- The list of InstanceIDs for the CIST or MSTIs whose topologies have changed, as indicated by the TCN messages in [802.1q], Section 13.14. Each InstanceID value is padded out to a 16-bit boundary, and the list is laid out as shown below. The bits in the "R" fields MUST be sent as 0 and ignored on receipt 🫧.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R| InstanceID#1 |R|R|R|R| InstanceID#2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.4.2. STP CIST Root Time Parameters ✨
okay bestie, this TLV is how we tell the other members of the RG what the CIST Root Time Parameters are ([802.1q], Section 13.26.7) 🫶 every time value is in seconds, with a granularity of 1. if you want the ranges and defaults, go check [802.1d1998] Section 8.10.2 Table 8-3, [802.1d2004] Section 17.14 Table 17-1, and [802.1q] Section 13.26.7 💅
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxAge | MessageAge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdDelay | HelloTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RemainingHops |
+-+-+-+-+-+-+-+-+U=F=0🎀- Type: set to
0x2008for "STP CIST Root Time TLV" 💜 - Length: the length of the TLV in octets, not counting the U-bit, F-bit, Type, and Length fields. it's always
9🌸 - MaxAge: the Max Age of the CIST. it's the maximum age of the information the bridge sends when it's the Root Bridge ([802.1d2004], Section 17.13.8) 🦋
- MessageAge: the Message Age of the CIST (see [802.1q], Section 13.26.7) ✨
- FwdDelay: the Forward Delay of the CIST. it's the delay STP Bridges use to move Root and Designated Ports into Forwarding ([802.1d2004], Section 17.13.5) 🔥
- HelloTime: the Hello Time of the CIST. it's the interval between the periodic Configuration Message transmissions from Designated Ports ([802.1d2004], Section 17.13.6) 🧚
- RemainingHops: the remainingHops of the CIST ([802.1q], Section 13.26.7) 👑
3.4.3. STP MSTI Root Time Parameter 🦋
this TLV reports the MSTI Root Time parameter value to the other RG members. like [802.1q] Section 13.26.7 says, it's the value of remainingHops for the given MSTI 💖
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x2009 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri | InstanceID | RemainingHops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0🎀- Type: set to
0x2009for "STP MSTI Root Time TLV" 💜 - Length: the length of the TLV in octets, not counting the U-bit, F-bit, Type, and Length fields. it's always
3🌸 - Pri: the Instance Priority. it's read as an unsigned integer, and a higher value means a higher priority 👑
- InstanceID: the 12-bit Instance Identifier of the Multiple Spanning Tree Instance (MSTID). as [802.1q] Section 12.8.1.2.2 defines it, this parameter takes a value from
1through4094✨ - RemainingHops: the remainingHops of the MSTI. it's encoded the same way as in [802.1q], Section 14.4.1, item f 🔥
3.5. STP Synchronization Request TLV 🫶
the STP Synchronization Request TLV goes in the RG Application Data Message. a device uses it to ask its peer to retransmit configuration or operational state 💅 it can ask for:
- configuration and/or state of the STP system,
- configuration and/or state for a given list of instances.
here's the format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| InstanceID List |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0🎀- Type: set to
0x200Afor "STP Synchronization Request TLV" 💜 - Length: the length of the TLV in octets, not counting the U-bit, F-bit, Type, and Length fields. it's always
4🌸 - Request Number: 2 octets. it's an unsigned integer that uniquely identifies the request, so the matching response can find it again 🦋 the value
0is reserved for unsolicited synchronization, and it MUST NOT be used in the STP Synchronization Request TLV 🚫 as [RFC7275] says, TCP is in play here, so there are no issues with the Request Number wrapping around ✨ - C-bit: set to
1if the request is for configuration data. otherwise, set it to0👑 - S-bit: set to
1if the request is for running state data. otherwise, set it to0🔥 - Request Type: 14 bits that specify the request type, encoded like this:
0x00 Request System Data
0x01 Request data of the listed instances
0x3FFF Request System Data and data of all instances- InstanceID List: the InstanceIDs of the CIST or MSTIs. the format is specified in Section 3.4.1 🧚
3.6. STP Synchronization Data TLV 💜
the pair of STP Synchronization Data TLVs is how the sender wraps up a set of TLVs being sent in response to an STP Synchronization Request TLV 🎀 the delimiters mark where the synchronization data starts and ends, and they tie the response to its request through the Request Number field 💖 it's REQUIRED that each pair of STP Synchronization Data TLVs occur in the same fragment. when the TLVs you want to send are bigger than the maximal fragment size, these TLVs MUST be divided into multiple sets, each wrapped in its own pair of STP Synchronization Data TLVs, and then packed into multiple fragments 📦 with the Request Number, you can spot lost fragments and ask for them again 🔁
the STP Synchronization Data TLVs are also used for unsolicited advertisements of complete STP configuration and operational state data. in that case the Request Number field MUST be set to 0 🌈
here's the format of the STP Synchronization Data TLV:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type=0x200B | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Reserved |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+U=F=0🎀- Type: set to
0x200Bfor "STP Synchronization Data TLV" 💜 - Length: the length of the TLV in octets, not counting the U-bit, F-bit, Type, and Length fields. it's always
4🌸 - Request Number: 2 octets. it's an unsigned integer that identifies the Request Number of the "STP Synchronization Request TLV" that started this synchronization data response 🦋
- Reserved: reserved bits for future use. these MUST be sent as
0and ignored on receipt 🚫 - S:
S = 0: Synchronization Data Start;S = 1: Synchronization Data End ✨
4. Operations 🌷
the operational procedures for AC redundancy applications are in Section 9.2 of [RFC7275] 📖 the ICCP STP application's operational procedures should follow those, with the changes laid out in this section 💅
4.1. Common AC Procedures 🧁
these are the changes to the generic AC redundancy procedures defined in Section 9.2.1 of [RFC7275] 🦋
4.1.1. Remote PE Node Failure or Isolation 💥
when a local PE device notices that a remote PE device in the same RG can't be reached anymore (using the mechanisms in Section 5 of [RFC7275]), the local PE device checks whether it has redundancy ACs for the affected services. if redundant ACs exist, and the local PE device has the new highest bridge priority, the local PE device becomes the virtual root bridge for the corresponding ACs 👑
4.1.2. Local PE Isolation 🏝️
when a PE device finds out it's been cut off from the core network, it needs to make sure its AC redundancy mechanism flips every active AC to standby 😭 the AC redundancy application SHOULD then send an RG Application Data Message to trigger failover to another active PE device in the RG 🚨 heads up: this only works with dedicated interconnect (Sections 3.2.1 and 3.2.3), since ICCP will still have a path to the peer even though the PE device is cut off from the MPLS core 🫶
4.2. ICCP STP Application Procedures 🎀
this section defines the ICCP STP application procedures that apply to Ethernet ACs 💖
4.2.1. Initial Setup
Okay bestie, so when an RG gets set up on a system that supports the ICCP STP application ✨, that system MUST send an RG Connect Message with an STP Connect TLV to every PE device in the RG 💖. The sending PE device MUST set the A bit to 1 in that TLV if it has already received a matching STP Connect TLV from its peer PE 🫶. Otherwise, the sending PE device MUST set the A bit to 0 🙈. If a PE device gets an STP Connect TLV from its peer after it already sent its own with the A bit set to 0, it MUST resend the TLV with the A bit set to 1 💅.
A system counts the ICCP STP application connection as operational once it has both sent and received STP Connect TLVs with the A bit set to 1 🎀. After a pair of PEs gets there, the two devices can start swapping RG Application Data Messages for the ICCP STP application 🦋. Part of that is each PE advertising its STP configuration and operational state in an unsolicited way, so no asking first, just vibes 🌸. A PE device SHOULD follow this order when advertising its STP state during initial application connection setup:
- Advertise the STP System Config TLV
- Advertise remaining Configuration TLVs
- Advertise State TLVs
The State TLVs depend on the Configuration TLVs, so sending in that order means the two peers can start updating STP state as early as possible, even while they're still trading these TLVs 🧚. Literally so smart.
A PE device MUST use a pair of STP Synchronization Data TLVs to delimit the entire set of TLVs sent as part of this unsolicited advertisement 🎀.
If a system receives an RG Connect Message with an STP Connect TLV that has a differing Protocol Version, it MUST follow the procedures outlined in Section 4.4.1 ("Application Versioning") of [RFC7275]. That's the rulebook for version mismatches, babe 👑.
After the ICCP STP application connection has been established, every PE device MUST communicate its system-level configuration to its peers using the STP System Config TLV 💜.
When the ICCP STP application is administratively disabled on the PE, or on that particular RG, the system MUST send an RG Disconnect Message containing an STP Disconnect TLV 😭.
4.2.2. Configuration Synchronization
A system that supports the ICCP STP application MUST synchronize the configuration with the other RG members 🤝. This happens through STP Configuration TLVs. The PEs in the RG MUST all agree on the common MAC address that goes with the virtual root bridge. You can get there with consistent configuration across member PEs, but in order to protect against possible misconfigurations, a virtual root bridge identifier MUST be set to the MAC address advertised by the PE device with the numerically lowest BridgeIdentifier (i.e., the MAC address of the bridge) in the RG 👑. Lowest wins, no drama.
Furthermore, for a given ICCP STP application, an implementation MUST advertise the configuration before it advertises the matching state 📋. If a PE device receives any STP State TLV it hadn't learned about before through an appropriate STP Configuration TLV, then the PE device MUST request synchronization of the configuration and state from its peer 🙋♀️. If a PE device receives a State TLV it hasn't learned before during that synchronization, then the PE device MUST send a NAK TLV for that particular TLV 🚫. And here's the key part: the PE device MUST NOT request resynchronization in this case. No spam, no loops 🦋.
4.2.3. State Synchronization
PEs within the RG need to synchronize their state for proper STP operation 🌈. Each system does this by advertising its running state in STP State TLVs. Whenever any STP parameter, on the CE side or the PE side, changes, the system MUST transmit an updated TLV for the affected STP instances 📣. Moreover, when the administrative or operational state changes, the system MUST transmit an updated State TLV to its peers 💅.
A PE device MAY request its peer to retransmit previously advertised state. This is super useful if the PE is recovering from a soft failure and trying to relearn state 🧠. To ask for those retransmissions, a PE device MUST send a set of one or more STP Synchronization Request TLVs 🎀.
A PE device MUST respond to an STP Synchronization Request TLV by sending the requested data in a set of one or more STP Configuration or State TLVs, delimited by a pair of STP Synchronization Data TLVs 🫶.
The response might span multiple RG Application Data Messages, for example when MTU limits are exceeded 📦. However, the ordering above MUST be retained across messages, and only a single pair of Synchronization Data TLVs MUST be used to delimit the response across all RG Application Data Messages. One pair, full stop 🛑.
A PE device MAY readvertise its STP state in an unsolicited manner. It does this by sending the appropriate State TLVs, delimited by a pair of STP Synchronization Data TLVs, with a Request Number of 0 🌸.
While a PE device has a synchronization request out for a particular PE device, it SHOULD silently ignore all TLVs that come from that node, were received before the synchronization response, and carry the same type of information being requested 🙈. This saves the system from updating state that's about to get overwritten anyway, which is honestly a mercy. TLVs about other systems should keep getting processed normally 💖.
If a PE device receives a synchronization request for an instance that doesn't exist or isn't known to the PE, then it MUST trigger the unsolicited synchronization of all information by restarting the initialization 🔄.
If during the synchronization operation a PE device receives an advertisement with a Node ID value that's different from the one previously advertised, then the PE device MUST purge all state data it previously received from that peer, prior to the last synchronization 🗑️. Bye bye, old tea ☕.
4.2.4. Failure and Recovery
When a PE device that's active for the ICCP STP application runs into a core isolation fault [RFC7275], it SHOULD attempt to fail over to a peer PE device that hosts the same RG 😬. The default failover procedure is for the failed PE device to bring down the link(s) toward the multihomed STP network. That makes the STP network reconverge and use the other links connected to the other PE devices in the RG 🔀. Other ways to trigger failover are possible, but they're outside the scope of this document, so not my problem here 💅.
If the isolated PE device is the one with the numerically lowest BridgeIdentifier, PEs in the RG MUST synchronize STP Configuration and State TLVs and determine a new virtual root bridge, as specified in Section 4.2.2 👑.
Upon recovery from a previous fault, a PE device SHOULD NOT reclaim the virtual root role for the STP network, even if it has the numerically lowest BridgeIdentifier among the RG 🙅♀️. This minimizes traffic disruption, and that's the whole point 🫶.
Whenever the virtual root bridge changes, the STP Topology Changed Instances TLV lists the instances affected by the change 📢. These instances MUST undergo an STP reconvergence procedure when this TLV is received, as defined in Section 3.4.1 🔥.
5. Security Considerations 🚨
Okay this part is serious, so listen up 🥹. This document specifies an application running on the channel provided by ICCP [RFC7275]. The security considerations on ICCP apply to this document too.
For the ICCP STP application, an attack on a channel (running in the provider's network) can break more than just the ability to deliver traffic across the provider's network. It can also break the ability to route traffic within the customer's network 😱. A careful attack on a channel, such as the DoS attacks described in [RFC7275], can break STP within the customer network. Implementations need to provide mechanisms to mitigate these types of attacks. For example, the port between the PE device and the malicious CE device may be blocked 🛡️. Stay safe out there, bestie 💀.
6. IANA Considerations 🦋
The IANA maintains a top-level registry called "Pseudowire Name Spaces (PWE3)". It has a subregistry called "ICC RG Parameter Types" 🎀.
IANA has made 13 allocations from this registry, as shown below. IANA allocated the codepoints from the range marked for assignment by IETF Review (0x2000-0x2FFF) [RFC5226]. Each assignment references this document ✨.
Parameter Type Description
-------------- ---------------------------------
0x2000 STP Connect TLV
0x2001 STP Disconnect TLV
0x2002 STP System Config TLV
0x2003 STP Region Name TLV
0x2004 STP Revision Level TLV
0x2005 STP Instance Priority TLV
0x2006 STP Configuration Digest TLV
0x2007 STP Topology Changed Instances TLV
0x2008 STP CIST Root Time TLV
0x2009 STP MSTI Root Time TLV
0x200A STP Synchronization Request TLV
0x200B STP Synchronization Data TLV
0x200C STP Disconnect Cause TLV7. References 📚
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual
Private LAN Service (VPLS) Using Label Distribution
Protocol (LDP) Signaling", RFC 4762,
DOI 10.17487/RFC4762, January 2007,
<http://www.rfc-editor.org/info/rfc4762>.
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M.,
Matsushima, S., and T. Nadeau, "Inter-Chassis
Communication Protocol for Layer 2 Virtual Private
Network (L2VPN) Provider Edge (PE) Redundancy",
RFC 7275, DOI 10.17487/RFC7275, June 2014,
<http://www.rfc-editor.org/info/rfc7275>.
[802.1q] IEEE, "IEEE Standard for Local and Metropolitan Area
Networks -- Bridges and Bridged Networks", IEEE Std
802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, 2014.
[802.1d1998] IEEE, "Information technology -- Telecommunications and
information exchange between systems -- Local and
metropolitan area networks -- Common specifications --
Part 3: Media Access Control (MAC) Bridges", ANSI/IEEE
Std 802.1D-1998, DOI 10.1109/IEEESTD.1998.95619, 1998.
[802.1d2004] IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges", IEEE
Std 802.1D-2004, DOI 10.1109/ieeestd.2004.94569, 2004.7.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.Acknowledgements 🫶
The authors would like to thank the comments and suggestions from Ignas Bagdonas, Adrian Farrel, Andrew G. Malis, Gregory Mirsky, and Alexander Vainshtein 💜🌈.
Authors' Addresses 💌
okay bestie, the last stop is the squad list 🫶 the three humans who wrote this spec and where to find them. Mingui Zhang, Huafeng Wen, and Jie Hu. Huawei and China Telecom really brought the receipts 💅
Mingui Zhang 🦋
Mingui Zhang
Huawei Technologies
No. 156 Beiqing Rd. Haidian District,
Beijing 100095
China
Email: zhangmingui@huawei.comHuafeng Wen 🌸
Huafeng Wen
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Email: wenhuafeng@huawei.comJie Hu 🧚
Jie Hu
China Telecom
Beijing Information Science & Technology Innovation Park
Beiqijia Town Changping District,
Beijing 102209
China
Email: hujie@ctbri.com.cnand that's the whole RFC, bestie!! 🎀✨ you made it through all five parts of the ICCP for PE Redundancy spec, and I'm so proud of us 😭💖
📦 where this page comes from
- ietf: rfc7727 2016-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms