RFC 7275
Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy
Internet Engineering Task Force (IETF) | 📜 Standards Track | Published June 2014 | ISSN 2070-1721
RFC 7275: Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy 💖
Okay bestie, let's start with the title block so you know who's behind this! ✨ The authors are L. Martini, S. Salam, A. Sajassi (all from Cisco), M. Bocci (Alcatel-Lucent), S. Matsushima (Softbank Telecom), and T. Nadeau (Brocade). It's on the Standards Track 🎀, it came out in June 2014, and it's published under ISSN 2070-1721. Its title says it all: it's the Inter-Chassis Communication Protocol for L2VPN PE redundancy. 🦋
Tbh the title block doesn't say anything about obsoletes or updates, so there's nothing to report there. 🙈
Abstract ✨
Okay so this doc specifies an Inter-Chassis Communication Protocol (ICCP) 🧚, and its whole job is to make Provider Edge (PE) device redundancy work for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) 💅. The protocol runs across a set of two or more PEs that form a Redundancy Group, and it's used to sync data between those systems. It works with multi-chassis attachment circuit redundancy mechanisms AND pseudowire redundancy mechanisms, so it's giving versatile energy 🔥.
Status of This Memo 🌸
This is an Internet Standards Track document. 💜
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741. 📚
You can find the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7275. 🫶
Copyright Notice 🎀
Copyright (c) 2014 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 were in effect on the day this document was published. Please read these carefully, because they explain your rights and restrictions with respect to this document. 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 without warranty as described in the Simplified BSD License. 🙈
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exception is formatting it for publication as an RFC or translating it into languages other than English. 🌈
Table of Contents 🍓
1. Introduction ....................................................5
2. Specification of Requirements ...................................5
3. ICCP Overview ...................................................5
3.1. Redundancy Model and Topology ..............................5
3.2. ICCP Interconnect Scenarios ................................7
3.2.1. Co-located Dedicated Interconnect ...................7
3.2.2. Co-located Shared Interconnect ......................8
3.2.3. Geo-redundant Dedicated Interconnect ................8
3.2.4. Geo-redundant Shared Interconnect ...................9
3.3. ICCP Requirements .........................................10
4. ICC LDP Protocol Extension Specification .......................11
4.1. LDP ICCP Capability Advertisement .........................12
4.2. RG Membership Management ..................................12
4.2.1. ICCP Connection State Machine ......................13
4.3. Redundant Object Identification ...........................17
4.4. Application Connection Management .........................17
4.4.1. Application Versioning .............................18
4.4.2. Application Connection State Machine ...............19
4.5. Application Data Transfer .................................22
4.6. Dedicated Redundancy Group LDP Session ....................22
5. ICCP PE Node Failure / Isolation Detection Mechanism ...........22
6. ICCP Message Formats ...........................................23
6.1. Encoding ICC into LDP Messages ............................23
6.1.1. ICC Header .........................................24
6.1.2. ICC Parameter Encoding .............................26
6.1.3. Redundant Object Identifier Encoding ...............27
6.2. RG Connect Message ........................................27
6.2.1. ICC Sender Name TLV ................................28
6.3. RG Disconnect Message .....................................29
6.4. RG Notification Message ...................................31
6.4.1. Notification Message TLVs ..........................32
6.5. RG Application Data Message ...............................35
7. Application TLVs ...............................................35
7.1. Pseudowire Redundancy (PW-RED) Application TLVs ...........35
7.1.1. PW-RED Connect TLV .................................36
7.1.2. PW-RED Disconnect TLV ..............................37
7.1.2.1. PW-RED Disconnect Cause TLV ...............38
7.1.3. PW-RED Config TLV ..................................39
7.1.3.1. Service Name TLV ..........................41
7.1.3.2. PW ID TLV .................................42
7.1.3.3. Generalized PW ID TLV .....................43
7.1.4. PW-RED State TLV ...................................44
7.1.5. PW-RED Synchronization Request TLV .................45
7.1.6. PW-RED Synchronization Data TLV ....................46
7.2. Multi-Chassis LACP (mLACP) Application TLVs ...............48
7.2.1. mLACP Connect TLV ..................................48
7.2.2. mLACP Disconnect TLV ...............................49
7.2.2.1. mLACP Disconnect Cause TLV ................50
7.2.3. mLACP System Config TLV ............................51
7.2.4. mLACP Aggregator Config TLV ........................52
7.2.5. mLACP Port Config TLV ..............................54
7.2.6. mLACP Port Priority TLV ............................56
7.2.7. mLACP Port State TLV ...............................58
7.2.8. mLACP Aggregator State TLV .........................60
7.2.9. mLACP Synchronization Request TLV ..................61
7.2.10. mLACP Synchronization Data TLV ....................63
8. LDP Capability Negotiation .....................................65
9. Client Applications ............................................66
9.1. Pseudowire Redundancy Application Procedures ..............66
9.1.1. Initial Setup ......................................66
9.1.2. Pseudowire Configuration Synchronization ...........66
9.1.3. Pseudowire Status Synchronization ..................67
9.1.3.1. Independent Mode ..........................69
9.1.3.2. Master/Slave Mode .........................69
9.1.4. PE Node Failure or Isolation .......................70
9.2. Attachment Circuit Redundancy Application Procedures ......70
9.2.1. Common AC Procedures ...............................70
9.2.1.1. AC Failure ................................70
9.2.1.2. Remote PE Node Failure or Isolation .......70
9.2.1.3. Local PE Isolation ........................71
9.2.1.4. Determining Pseudowire State ..............71
9.2.2. Multi-Chassis LACP (mLACP) Application Procedures ..72
9.2.2.1. Initial Setup .............................72
9.2.2.2. mLACP Aggregator and Port Configuration ...74
9.2.2.3. mLACP Aggregator and Port Status
Synchronization ...........................75
9.2.2.4. Failure and Recovery ......................77
10. Security Considerations .......................................78
11. Manageability Considerations ..................................79
12. IANA Considerations ...........................................79
12.1. Message Type Name Space ..................................79
12.2. TLV Type Name Space ......................................79
12.3. ICC RG Parameter Type Space ..............................80
12.4. Status Code Name Space ...................................81
13. Acknowledgments ...............................................81
14. References ....................................................81
14.1. Normative References .....................................81
14.2. Informative References ...................................821. Introduction 🌷
Okay so network availability is literally a make-or-break metric for service providers 💀, because it hits their profits directly. Outages mean lost revenue AND possible penalties from contracts with customers running mission-critical apps that need tight Service Level Agreements (SLAs). This is true for any carrier network, and networks using Layer 2 Virtual Private Network (L2VPN) tech are no exception 😭. You can get high availability by using intra-chassis and inter-chassis redundancy mechanisms. This doc is all about the latter 🫶.
This document defines an Inter-Chassis Communication Protocol (ICCP) that syncs state and configuration data between a set of two or more Provider Edge nodes (PEs) forming a Redundancy Group (RG). The protocol supports multi-chassis redundancy mechanisms that can run on either the attachment circuits or the pseudowires (PWs). The formal definition of "chassis" is in [RFC2922], but for this doc, a chassis is just an L2VPN PE node 🧚.
This document assumes it's normal to run the Label Distribution Protocol (LDP) between the PEs in the RG, and that LDP components will be on the PEs anyway to set up and maintain pseudowires. So ICCP is built as a secondary protocol running inside LDP 🦋. It takes advantage of the LDP session mechanisms, plus the underlying TCP transport mechanisms and the TCP-based security mechanisms that LDP already needs 💅.
2. Specification of Requirements 💜
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]. 📌
3. ICCP Overview 🎀
(Continued in Part 2.) 🌈
3.1. Redundancy Model and Topology ✨
okay so bestie, this is where we get into PE node redundancy, which is the main focus of this doc 💅 The setup is that the operator picks two or more PE nodes to form an RG (Redundancy Group) 🫶 All the members of an RG sit under one administration (like a service provider), and they use a shared redundancy mechanism towards the access (attachment circuits or access pseudowires) and/or towards the core (pseudowires) for any given service instance. It's giving unity 🎀 Members can totally use different redundancy mechanisms for disjoint services though, which is so flexible 🦋 The PEs can offer any type of L2VPN service, so either VPWS (Virtual Private Wire Service) or VPLS (Virtual Private LAN Service) 🌈 Also, ngl, ICCP might even be useful for Layer 3 service redundancy, but that's outside the scope of this document 🙈
The PEs in an RG give multi-homed connectivity to either individual devices (like a CE (Customer Edge) or a DSLAM (Digital Subscriber Line Access Multiplexer)) or entire networks (like an access network) 💖 Here's the picture:
+=================+
| |
Multi-homed +----+ | +-----+ |
Node ------------> | CE |-------|--| PE1 ||<------|---Pseudowire-->|
| |--+ -|--| ||<------|---Pseudowire-->|
+----+ | / | +-----+ |
| / | || |
|/ | || ICCP |--> Towards Core
+-------------+ / | || |
| | /| | +-----+ |
| Access |/ +----|--| PE2 ||<------|---Pseudowire-->|
| Network |-------|--| ||<------|---Pseudowire-->|
| | | +-----+ |
| | | |
+-------------+ | Redundancy |
^ | Group |
| +=================+
|
Multi-homed Network
Figure 1: Generic Multi-Chassis Redundancy ModelIn Figure 1, the redundancy mechanism toward the access node/network can be one of a bunch of technologies, like IEEE 802.1AX Link Aggregation Groups with the Link Aggregation Control Protocol (LACP) or Synchronous Optical Network Automatic Protection Switching (SONET APS) 🔥 The specifics of that mechanism are outside this doc's scope. But the PEs in the RG are required to talk to each other so the access redundancy mechanism can work properly. So an inter-chassis communication protocol MUST be run among the PEs in the RG, so they can sync configuration and/or running state data 👑
Having that inter-chassis channel also makes the pseudowire redundancy mechanism way simpler 🧚 The PEs can run an arbitration algorithm to elect which pseudowire(s) should be active or standby for a given service instance. Then they just advertise the result to the remote-end PE(s), instead of having to bake a handshake into the pseudowire redundancy status mechanism and every other possible Layer 2 status mechanism 💅✨
3.2. ICCP Interconnect Scenarios 🦋
When this section says "interconnect," we mean the links or networks that carry Inter-Chassis Communication Protocol messages, not the normal data traffic between PEs 🌸 The PEs in an RG can be co-located or geo-redundant 💜 And the physical interconnect that ICCP runs over can be either dedicated back-to-back links or a shared connection through the packet switched network (PSN), like an MPLS core network 🫶 That gives us a matrix of four interconnect scenarios, which we'll go through in the subsections below 🎀
3.2.1. Co-located Dedicated Interconnect 🍓
So in this one, the PEs in an RG are in the same physical spot, like a point of presence (POP) or central office (CO) 🏢 Dedicated links provide the ICCP interconnect between them 💖
+=================+ +-----------------+
|CO | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | | | | |
| +-----+ | | |
| || | | |
| || ICCP | | Core |
| || | | Network |
| +-----+ | | |
| | PE2 |________|_____| |
| | | | | |
| +-----+ | | |
| | | |
+=================+ +-----------------+
Figure 2: ICCP Co-located PEs Dedicated Interconnect ScenarioSince the PEs are connected back-to-back here, it's possible to lean on Layer 2 redundancy mechanisms to keep the ICCP interconnect robust 🧚 For example, if the interconnect is IEEE 802.3 Ethernet links, you can get link redundancy with IEEE 802.1AX Link Aggregation Groups 🔥
3.2.2. Co-located Shared Interconnect 💅
This time the PEs in an RG are still co-located (POP, CO) 🏢 But unlike the last scenario, there are no dedicated links between the PEs 🙈 The ICCP interconnect goes through the core network the PEs are connected to instead. Figure 3 shows this model 🌈
+=================+ +-----------------+
|CO | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | |<=================+ |
| +-----+ ICCP | | || |
| | | || |
| | | || Core |
| | | || Network |
| +-----+ | | || |
| | PE2 |________|_____| || |
| | |<=================+ |
| +-----+ | | |
| | | |
+=================+ +-----------------+
Figure 3: ICCP Co-located PEs Shared Interconnect ScenarioSince the PEs in the RG are connected over the PSN, you can use PSN Layer mechanisms to keep the interconnect resilient against connectivity failures 💖 For example, RSVP Label Switched Paths (LSPs) with Fast Reroute (FRR) and/or end-to-end backup LSPs are an option 🦋
3.2.3. Geo-redundant Dedicated Interconnect 🌸
Here the PEs in an RG are in different physical locations for geographic redundancy 🌍 That might be handy for protecting against natural disasters or stuff like that ⭐ A dedicated interconnect links the PEs, but ngl it's a costly option, especially if you want several of these links for interconnect robustness 💀 The resiliency mechanisms for the interconnect are similar to the co-located counterpart 💜
+=================+ +-----------------+
|CO 1 | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | | | | |
| +-----+ | | |
+=====||==========+ | |
|| ICCP | Core |
+=====||==========+ | Network |
| +-----+ | | |
| | PE2 |________|_____| |
| | | | | |
| +-----+ | | |
|CO 2 | | |
+=================+ +-----------------+
Figure 4: ICCP Geo-redundant PEs Dedicated Interconnect Scenario3.2.4. Geo-redundant Shared Interconnect 🫶
In this scenario the PEs of an RG are in different physical locations, and the ICCP interconnect runs over the PSN the PEs are connected to 🌐 This is the option most likely to be used for geo-redundancy, since it's way more economically appealing than the geo-redundant dedicated interconnect 💸 The resiliency mechanisms that can guarantee ICCP transport robustness are PSN Layer mechanisms, same as described in Section 3.2.2 above 👑
+=================+ +-----------------+
|CO 1 | | |
| +-----+ | | |
| | PE1 |________|_____| |
| | |<=================+ |
| +-----+ ICCP | | || |
+=================+ | || |
| || Core |
+=================+ | || Network |
| +-----+ | | || |
| | PE2 |________|_____| || |
| | |<=================+ |
| +-----+ | | |
|CO 2 | | |
+=================+ +-----------------+
Figure 5: ICCP Geo-redundant PEs Shared Interconnect ScenarioThat wraps up Section 3! Next up is the rest of the doc 🎀✨
3.3. ICCP Requirements 📋✨
okay so bestie, here's the wishlist ICCP has to hit. Each requirement is labeled with a roman numeral so we can keep track 💅 The BCP 14 words are the important part, so don't skip them 🫶
- i. ICCP MUST give you a control channel so the PEs in a Redundancy Group (RG) can talk to each other 📡 PE nodes can be co-located or remote (peep Section 3.2 above 👀). Client apps that use ICCP MUST only use this channel for control info, and not for data traffic 🚫 So the protocol SHOULD be relatively low bandwidth, low delay, and highly reliable message transfer 💜
- ii. ICCP MUST be able to handle multiple client apps (like multi-chassis LACP, PW redundancy, and SONET APS) 🎀 That means the messages SHOULD be extensible (TLV-based is giving 🧚), and the protocol SHOULD have a robust application registration and versioning scheme 🌸
- iii. ICCP MUST provide reliable message transport and in-order delivery between nodes in an RG, with secure authentication mechanisms built into the protocol 🔐 The redundancy apps that are clients of ICCP expect reliable transfer, so they'll assume the protocol handles flow control and retransmissions 😭 Also, since these apps use ICCP to sync state machines on different nodes, it is critical that ICCP guarantees in-order delivery. Lost or out-of-sequence messages would seriously mess up the client apps 💀
- iv. ICCP MUST have a common way to actively monitor the health of PEs in an RG 🩺 This is how it detects PE node failure (or isolation from the MPLS network in the case of shared interconnect) and tells the client apps. The apps need the mechanism to trigger failover according to the procedures of the redundancy protocol on the attachment circuit (AC) and PW 🔄 The solution SHOULD achieve sub-second detection of loss of remote node (~50-150 msec), so the redundancy mechanisms get enough reaction time to hit sub-second service restoration ⚡
- v. ICCP SHOULD provide asynchronous, event-driven state updates, independent of periodic messages, so client state changes get noticed immediately 🦋 In other words, messages carrying application data SHOULD go out on-demand rather than on a timer, to keep inter-chassis state sync delay as low as possible ⏩
- vi. ICCP MUST accommodate multi-link and multi-hop interconnects between nodes 🌐 When RG devices sit in different physical locations, the interconnect between them is a network, not a single link. So ICCP MUST handle the case where the interconnect involves multiple hops. It's also possible to have multiple (redundant) paths or interconnects between a given pair of devices, and that's true for both co-located and geo-redundant setups. ICCP MUST handle this too 🫶
- vii. ICCP MUST ensure transport security between devices in an RG 🔒 This matters most when RG members are in different places and connected over a shared network (like a PSN) 🌍 Specifically, ICCP MUST NOT accept connections arbitrarily from any device, or the state of the client apps could get compromised 😱 Even if a connection request looks like it's from an eligible device, the source address may have been spoofed, so some means of preventing source address spoofing MUST be in place 🕵️
Security tea: a request that looks legit can still be faked. Spoofing protection is not optional here, bestie 🚨
- viii. ICCP MUST let the operator statically configure members of an RG ⚙️ Auto-discovery may be considered in the future 🔮
- ix. ICCP SHOULD allow flexible RG membership 🧩 Only two nodes in an RG will cover most redundancy apps in common deployments, but ICCP SHOULD NOT preclude supporting more than two nodes in an RG by design 🙌 And ICCP MUST allow a single node to be a member of multiple RGs at the same time 👑
4. ICC LDP Protocol Extension Specification 🧚💖
To hit the requirements from the last section, ICCP is modeled as three layers 🍰
- i. Application Layer: This is the interface to the redundancy apps that use ICCP's services. ICCP only defines the common connection management procedures and the message formats at this layer. Beyond that, it doesn't put any restrictions on the procedures or state machines of the clients, since those are application specific and outside ICCP's scope 🙈 This keeps implementations interoperable without forcing any unnecessary constraints on internal design 🫶
- ii. Inter-Chassis Communication (ICC) Layer: This layer implements the common set of services ICCP offers to client apps 💅 It handles protocol versioning, RG membership, Redundant Object identification, PE node identification, and ICCP connection management 📋
- iii. Transport Layer: This layer provides the actual ICCP message transport 🚚 It's responsible for addressing, route resolution, flow control, reliable and in-order message delivery, connectivity resiliency/redundancy, and, finally, PE node failure detection 💪 The Transport layer may differ depending on the Physical Layer of the interconnect 🔧
4.1. LDP ICCP Capability Advertisement 📣
okay so when an RG gets enabled on a PE, an LDP session to every remote PE in that RG MUST be created, if one doesn't already exist 🤝 Then the ability to support ICCP MUST be advertised to all of those LDP peers in that RG 📢 This is done using the methods in [RFC5561] by advertising the "ICCP capability TLV" 🎀 If an LDP peer supports dynamic capability advertisement, this can be done by sending a new capability message with the S-bit set for the "ICCP capability TLV" when the first RG is enabled on the PE ✨ If the peer does not support dynamic capability advertisements, then the "ICCP TLV" MUST be included in the LDP initialization procedures in the capability parameter [RFC5561] 📝
4.2. RG Membership Management 👯♀️💜
ICCP has a mechanism that lets PE nodes manage their RG membership, and it's giving main character energy 👑 When a PE is configured as a member of an RG, it first advertises the ICCP capability to its peers 📣 After that, the PE sends an "RG Connect" message to the peers that have also advertised ICCP capability 📨 Then it waits for those peers to send their own "RG Connect" messages, if they haven't already 🕰️ For a given RG, the ICCP connection between two devices is only operational once both devices have sent and received ICCP "RG Connect" messages for that RG 🎉
If a PE sent an "RG Connect" message and doesn't get back a matching RG Connect (or a Notification message rejecting the connection) from a destination, it stays in a state of expecting the matching "RG Connect" message (or Notification message) 👀 The RG won't become operational until that matching "RG Connect" message arrives ⏳ And if a PE that sent an "RG Connect" message gets a Notification message rejecting the connection, with a NAK TLV (Negative Acknowledgement TLV) (Section 6.4.1), it stops trying to bring up the ICCP connection right away 🛑
A device MUST reject an incoming "RG Connect" message if at least one of the following conditions is satisfied 🚫
- i. the PE is not a member of the RG;
- ii. the maximum number of simultaneous ICCP connections that the PE can handle is exceeded.
Otherwise, the PE MUST bring up the connection by responding to the incoming "RG Connect" message with an appropriate RG Connect ✅
A PE sends an "RG Disconnect" message to tear down the ICCP connection for a given RG 👋 This is a unilateral move, so it doesn't need an acknowledgement from the other PEs 🙌 Also, the ICCP connection for an RG MUST be operational before any client application can use ICCP services in that RG 🫶
4.2.1. ICCP Connection State Machine ✨
okay so every PE keeps its own ICCP Connection state machine instance for every ICCP connection with a remote peer in the RG 🫶 and this one is totally separate from any Application Connection state machine (Section 4.4.2). ngl the ICCP Connection state machine only pays attention to "RG Connect", "RG Disconnect", and "RG Notification" messages that don't have any "Application TLVs" in them 💅. Whatever happens in the Application Connection state machines has no effect on it, so they stay in their own lane 🌸
The ICCP Connection state machine has six states, and here's the tea:
- NONEXISTENT: this is where the state machine starts ✨. It means there's no ICCP connection yet and no LDP session set up between the PEs.
- INITIALIZED: an LDP session exists between the PEs, but they haven't swapped LDP ICCP capability info yet 🧚
- CAPSENT: an LDP session exists, and the local PE has advertised its LDP ICCP capability to its peer 📤
- CAPREC: an LDP session exists, and the local PE has both received and advertised LDP ICCP capability, to and from its peer 🙌
- CONNECTING: the local PE started an ICCP connection to its peer and is waiting on a response 👀
- OPERATIONAL: the ICCP connection is up and running ✅
the state transition table and the state transition diagram come next, so get ready 🦋
ICCP Connection State Transition Table
STATE EVENT NEW STATE
--------------------------------------------------------------------
NONEXISTENT LDP session established INITIALIZED
INITIALIZED Transmit LDP ICCP capability CAPSENT
Receive LDP ICCP capability CAPREC
Action: Transmit LDP ICCP capability
LDP session torn down NONEXISTENT
CAPSENT Receive LDP ICCP capability CAPREC
LDP session torn down NONEXISTENT
CAPREC Transmit RG Connect message CONNECTING
Receive acceptable RG Connect message OPERATIONAL
Action: Transmit RG Connect message
Receive any other ICCP message CAPREC
Action: Transmit NAK TLV in RG
Notification message
LDP session torn down NONEXISTENT
CONNECTING Receive acceptable RG Connect message OPERATIONAL
Receive any other ICCP message CAPREC
Action: Transmit NAK TLV in RG
Notification message
LDP session torn down NONEXISTENT
OPERATIONAL Receive acceptable RG Disconnect message CAPREC
Transmit RG Disconnect message CAPREC
LDP session torn down NONEXISTENT ICCP Connection State Transition Diagram
+------------+
| |
+------------------>|NONEXISTENT | LDP session torn down
| | |<--------------------------+
| +------------+ |
| LDP session | ^ LDP session |
| established | | torn down |
| V | |
| +-----------+ |
LDP | | | Tx LDP ICCP |
session| |INITIALIZED| capability |
torn | +---| |---------------+ |
down | Rx other | +-----------+ | |
| ICCP msg/ |Rx LDP ICCP | |
| Tx NAK TLV | capability/ | |
| +---+ |Tx LDP ICCP capability | |
| | | | | |
| V | V V |
| +-----------+ Rx LDP ICCP +--------+ |
+---| | capability | | |
|CAPREC |<----------------------|CAPSENT |---------->+
+---| |-------------------+ | | |
| +-----------+ | +--------+ |
| ^ ^ | |
Tx | | | | |
RG | | |Rx RG Disconnect msg | |
Connect| | | or |Rx RG Connect msg/ |
msg | | |Tx RG Disconnect msg | Tx RG Connect msg |
| | | V |
| | | +------------+ |
| | +--------------------| | |
| | |OPERATIONAL |------------>+
| | | | |
| |Rx other ICCP msg/ +------------+ |
| | Tx NAK TLV ^ |
| | | |
| +----------+ Rx RG Connect msg | |
| | |---------------------+ |
+----->|CONNECTING| |
| |----------------------------------------->+
+----------+4.3. Redundant Object Identification 🎀
okay so ICCP gives its client apps one uniform way to identify links, ports, forwarding constructs, and basically any object (interfaces, pseudowires, VLANs, you name it) that's being protected in a redundant setup 🔐. These are called Redundant Objects (ROs). An example is a multi-chassis link-aggregation group that spans two PEs 🍓 ICCP introduces a 64-bit opaque identifier to uniquely identify ROs in an RG. This one is called the Redundant Object ID (ROID), and it MUST match between RG members for the protected object in question 💖 That's the magic bit, because it lets separate systems in an RG use one shared handle to reference the protected entity, no matter what it is (physical or virtual) and without caring about implementation specifics 🧚 Client apps that need to sync state for a particular RO SHOULD embed the matching ROID in their TLVs 🫶
4.4. Application Connection Management 👑
ICCP gives apps on one PE a shared set of procedures to connect to their counterparts on another PE, all for inter-chassis communication within a given RG ✨ Before any of that can happen, you need an operational ICCP RG connection between the two endpoints. It's assumed that which apps go with which RGs is already known a priori, like through device configuration 🛠️ Then ICCP sends an "Application Connect TLV" (carried in an "RG Connect" message) for each client app, to every remote PE in the RG 📨 The client can piggyback app-specific info onto that "Connect TLV" too, which can be used to negotiate parameters or attributes before the actual Application Connection comes up 🎀
Bringing up an Application Connection works like the ICCP connection: it's only up once both nodes have sent and received "RG Connect" messages with the proper "Application Connect TLVs" 🦋 A PE MUST send a Notification message to reject an Application Connection request if one of these conditions shows up 🙅♀️
- i. the application doesn't exist or isn't configured for that RG;
- ii. the Application Connection count goes over what the PE can handle.
When a PE gets one of those rejection notifications, it MUST stop trying to bring up the Application Connection until it gets a new Application Connection request from the remote PE 😤 The way to respond is with an appropriate "RG Connect" message (carrying a corresponding "Application Connect TLV") in reply to the incoming "RG Connect" message carrying an "Application Connect TLV" 💌
When an application is stopped on a device, or it's no longer associated with an RG, it MUST signal ICCP to trigger sending an "Application Disconnect TLV" (in the "RG Disconnect" message) 📴 This is a unilateral notification to the other PEs in an RG, so it doesn't trigger any response 🌈
4.4.1. Application Versioning 🦋
so during Application Connection setup, an app on one PE can negotiate the right application version to use with its counterpart on a peer PE 💬 If no common version gets agreed on, the Application Connection just doesn't come up 💀 This all runs on the following rules:
- If an application gets an "Application Connect TLV" with a version number higher than its own, it MUST send a Notification message with a "NAK TLV" indicating status code "Incompatible Protocol Version" and supplying the version that's locally supported by the PE 🚫
- If an application gets an "Application Connect TLV" with a version number lower than its own, it MAY respond with an RG Connect that has an "Application Connect TLV" using the same version that was received 🫧 Alternatively, the application MAY respond with a Notification message to reject the request using the "Incompatible Protocol Version" code and supply the version that's supported. This lets an app work in either backwards-compatible or incompatible mode, which is so smart 🧠✨
- If an application gets an "Application Connect TLV" with a version equal to its own, then the application MUST honor or reject the request based on whether it's configured for the RG in question and whether or not the Application Connection count has been exceeded 🍭
4.4.2. Application Connection State Machine ✨
okay bestie, so each PE runs its own Application Connection state machine for every ICCP application, for every ICCP connection with a remote PE in the RG 💅 and each little machine only pays attention to the "RG Connect", "RG Disconnect", and "RG Notification" messages that carry an "Application TLV" naming its application 🎀. no crossing the streams 🙈
the Application Connection state machine has six states 🧚:
- NONEXISTENT: this one means the Application Connection doesn't exist yet, because there's no ICCP connection between the PEs at all 💀
- RESET: an ICCP connection is up between the PEs, but the Application Connection hasn't been initialized yet or has been resent 🌸
- CONNSENT: the local PE asked its peer to start an Application Connection and is still waiting to hear back 🫶
- CONNREC: the local PE got a request from its peer to start an Application Connection and hasn't replied yet 💜
- CONNECTING: the local PE sent its peer an "Application Connection" message with the A-bit set to 1 and is waiting for the peer's answer ✨
- OPERATIONAL: the Application Connection is up and running, periodt 👑
here's the state transition table and the state transition diagram, bestie 🦋
ICCP Application Connection State Transition Table
STATE EVENT NEW STATE
-------------------------------------------------------------------
NONEXISTENT ICCP connection established RESET
RESET ICCP connection torn down NONEXISTENT
Transmit Application Connect TLV CONNSENT
Receive Application Connect TLV CONNREC
Receive any other Application TLV RESET
Action: Transmit NAK TLV
CONNSENT Receive NAK TLV RESET
Receive Application Connect TLV OPERATIONAL
with A-bit=1
Action: Transmit Application Connect
TLV with A-bit=1
Receive any other Application TLV RESET
Action: Transmit NAK TLV
ICCP connection torn down NONEXISTENT
CONNREC Transmit NAK TLV RESET
Transmit Application Connect TLV CONNECTING
with A-bit=1
Receive Application Connect TLV CONNREC
Receive any Application TLV except RESET
Connect
Action: Transmit NAK TLV
ICCP connection torn down NONEXISTENT
CONNECTING Receive Application Connect TLV OPERATIONAL
with A-bit=1
Receive any other Application TLV RESET
Action: Transmit NAK TLV
ICCP connection torn down NONEXISTENT
OPERATIONAL Receive Application Disconnect TLV RESET
Transmit Application Disconnect TLV RESET
ICCP connection torn down NONEXISTENT ICCP Application Connection State Transition Diagram
+------------+
| |
+---------------->|NONEXISTENT | ICCP connection torn down
| | |<--------------------------+
| +------------+ |
| ICCP connection| ^ ICCP connection |
| established | | torn down |
| | | |
| V | Rx other App TLV/ |
| +-----------+<-----+ Tx NAK TLV |
ICCP | Rx App | | | |
connect| Connect TLV | RESET |------+ |
torn | +-------------| |---------------+ |
down | | +-----------+ Tx App | |
| | ^ ^ ^ ^ Connect TLV| |
| | Tx NAK | | | | | |
| | or | | | | | |
| | Rx non- | | | | | |
| | Connect | | | | | |
| V TLV/Tx NAK | | |Rx NAK TLV V |
| +-----------+ | | | |or +--------+ |
+-| |---+ | | +---------| | |
|CONNREC | | | Rx other |CONNSENT|---------->+
+-| |-+ | | App TLV/ | | |
| +-----------+ | | | Tx NAK +--------+ |
| ^---+ | | |Rx App Connect |
| Rx App | | |TLV (A=1)/ |
| Connect TLV | |Rx App Disconn | Tx App |
| | |or | Connect TLV |
| Tx App Connect | |Tx App Disconn V (A=1) |
| TLV (A=1) | | +------------+ |
| | +------| | |
| Rx other App | |OPERATIONAL |------------>+
| TLV/Tx NAK | | | |
| +------+ +------------+ |
| | ^ Rx App Connect |
| +----------+ | TLV (A=1) |
| | |---------------------+ |
+--->|CONNECTING| |
| |----------------------------------------->+
+----------+4.5. Application Data Transfer 🍓
okay so when an application has info to send over ICCP, it kicks off an "Application Data" message 💌 ICCP guarantees the data arrives in order and nothing gets lost, literally the dream 😭 an application can reject a message, or a set of one or more TLVs inside a message, by using the Notification message with a "NAK TLV" 🙅♀️ and if it wants, an application can build its own ACK mechanism by defining an application-specific TLV that rides along in an "Application Data" message 🦋 but ngl, this document does NOT define a common ACK mechanism for applications, so that's on the apps 💅
now, if a PE gets a "NAK TLV" back after sending an "Application Data" message, the application decides what happens next 🧠 sometimes it's better for the PE that sent the NAK to explicitly ask for a retransmission, and other times it makes more sense for the original sender of the "Application Data" message to handle retransmissions when a NAK comes in 🔁 ICCP supports both models, iykyk 🎀
4.6. Dedicated Redundancy Group LDP Session 🌈
so for certain ICCP applications, a pretty big chunk of RG info has to get exchanged in a super short amount of time ⏱️ to spread the load across a multiple-processor system, and to keep other LDP applications from getting stuck behind it (head-of-line blocking, yikes 😭), starting a separate TCP/IP session between the two LDP speakers might be needed 🫧
this procedure is OPTIONAL and doesn't change how LDP or ICCP work 🌸
when a PE needs a separate LDP session, it advertises a separate LDP adjacency with a non-zero label space identifier ✨ that makes the remote peer open a separate LDP session for that label space 💜 no labels need to be advertised in this label space, since it's only used for one or a set of ICCP RGs 🧚 and all the relevant LDP and ICCP procedures still apply, as described in [RFC5036] and this document 📚
5. ICCP PE Node Failure / Isolation Detection Mechanism 🔍
ICCP gives its client applications a notification when a remote PE that's a member of the RG is no longer reachable 🚨 with a dedicated interconnect, that means the remote PE node has failed, but with a shared interconnect it means the remote PE node has either failed or got isolated from the MPLS network 💀 the client applications use this info to trigger failover, following the procedures of the redundancy protocol used on the AC and PW 🔥 ICCP doesn't define its own Keep-Alive mechanism for checking the health of remote PE nodes, it just reuses existing fault detection mechanisms, which is so smart 👑 ICCP may use the following mechanisms to detect PE node failure:
- Bidirectional Forwarding Detection (BFD)
run a BFD session [RFC5880] between the PEs that are members of a given RG and use that to detect PE node failure 🦋 this assumes resiliency mechanisms are in place to protect connectivity to the remote PE nodes, so losing BFD periodic messages from a given PE node can only mean the node itself has failed 💅
- IP Reachability Monitoring
a PE can monitor IP-layer connectivity to other RG members that are participating in IGP/BGP 🌐 when connectivity to a given PE is lost, the local PE reads that as loss of the remote PE node 🫶 this technique assumes resiliency mechanisms are in place to protect the route to the remote PE nodes, so losing IP reachability to a node can only mean the node itself has failed 💜
one important tea ☕: losing the LDP session with a PE in an RG is NOT a reliable sign that the remote PE is down 🙅♀️ for example, the remote PE could hit a local event that resets the LDP session while the PE node stays totally operational for traffic forwarding 🌸
6. ICCP Message Formats 💌
this section defines the messages exchanged at the Application and ICC layers ✨
6.1. Encoding ICC into LDP Messages 🧚
ICCP needs reliable, in-order, stateful message delivery, plus capability negotiation between PEs 🫶 LDP offers all of these features and is already widely used in the applications that would also need the ICCP protocol extensions, so ICCP takes advantage of the LDP protocol infrastructure that's already defined 🎀
[RFC5036], Section 3.5 defines a generic LDP message structure 📚 a new set of LDP message types is defined to carry the ICCP information, and LDP message types in the range 0x0700 to 0x070F will be used for ICCP 🔥
message types have been allocated by IANA, see Section 12 below for details 💅
6.1.1. ICC Header ✨
Okay bestie, every ICCP message starts with an ICC-specific LDP Header, and then the message data comes after it 🎀. Here's the layout:
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| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional ICC Parameters |
~ ~
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit 🦋 The unknown message bit. When a message comes in that isn't recognised, a clear U (=0) means a notification goes back to whoever sent it. A set U (=1) means the unknown message just gets silently ignored 🙈. Later sections that define messages give the U-bit its value.
- Message Type 💅 This tells you what kind of ICCP message it is. It has to sit somewhere in 0x0700 to 0x070F.
- Message Length 📏 A 2-octet integer with the total length of the message in octets. It doesn't count the "U-bit", "Message Type", or "Length" fields.
- Message ID 🔖 A 4-octet value that identifies this message. The sending PE uses it to match up "RG Notification" messages that might be about this message. A PE that sends an "RG Notification" in reply to this message SHOULD put this Message ID in the "NAK TLV" of that "RG Notification" message. See Section 6.4.
- ICC RG ID TLV 🌸 A TLV of type 0x0005 with length 4. It holds a 4-octet unsigned integer that names the Redundancy Group the sending device belongs to. The RG ID value 0x00000000 is reserved by the protocol, so hands off that one 🙅♀️.
- Mandatory ICC Parameters 🧚 A variable-length set of required message parameters. Some messages don't have any required parameters. For messages that do have required parameters, the required parameters MUST appear in the order given by each message's own specification in the sections that follow.
- Optional ICC Parameters ✨ A variable-length set of optional message parameters. Lots of messages don't have any optional ones. For messages that do have optional parameters, those can show up in any order.
6.1.2. ICC Parameter Encoding
Every ICC parameter follows this general 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV(s) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit 🦋 The unknown TLV bit. If you get an unknown TLV and U is clear (=0), a notification MUST be sent back to the message originator, and the entire message MUST be ignored. If U is set (=1), the unknown TLV MUST be silently ignored, and the rest of the message gets processed as though that TLV never existed. Later sections that define TLVs give the U-bit its value.
- F-bit 🍓 The forward unknown TLV bit. This one only matters when the U-bit is set and the LDP message holding the unknown TLV is going to be forwarded. If F is clear (=0), the unknown TLV doesn't get forwarded along with the LDP message. If F is set (=1), it does get forwarded. Later sections that define TLVs give the F-bit its value. Setting both the U- and F-bits lets a TLV ride through nodes that don't recognise it as opaque data, which is honestly iconic 👑.
- Type 🎀 14 bits that show the ICC Parameter type.
- Length 📐 The length of the TLV in octets. It doesn't count the "U-bit", "F-bit", "Type", or "Length" fields.
- TLV(s) 🫶 A set of 0 or more TLVs. What's in here depends on the message type.
6.1.3. Redundant Object Identifier Encoding
The Redundant Object Identifier (ROID) is a generic opaque handle that uniquely identifies a Redundant Object (for example a link, a bundle, or a VLAN) that's being protected in an RG. Here's how it's encoded 🦋:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The ROID is an 8-octet field encoded as an unsigned integer. The ROID value of 0 is reserved, so skip that one 🙅♀️.
The ROID gets carried inside application-specific TLVs.
6.2. RG Connect Message
Okay so the "RG Connect" message is what sets up the ICCP RG connection, and it can also set up individual Application Connections between PEs in an RG 🔥. An "RG Connect" message with no "Application Connect TLV" means the ICCP RG connection is being set up. An "RG Connect" message with a valid "Application Connect TLV" means an Application Connection is being set up too, as long as the ICCP RG connection isn't already up.
An implementation MAY send a dedicated "RG Connect" message to set up the ICCP RG connection, plus a separate "RG Connect" message for each client application. However, every implementation MUST support receiving an "RG Connect" message that sets up the ICCP RG connection and a single Application Connection at the same time 💖.
A PE sends an "RG Connect" message to declare that it's a member of a Redundancy Group. One of these should go to each PE that's in the same RG. The set of PEs that should get "RG Connect" messages comes from configuration or an auto-discovery mechanism, and that mechanism is outside the scope of this specification. If a device is in multiple RGs, it MUST send a separate "RG Connect" message for each RG, even when the receiving device or devices are the same ones 👯♀️.
The "RG Connect" message is laid out like this:
i. ICC Header with Message type = "RG Connect Message" (0x0700)
ii. ICC Sender Name TLV
iii. Zero or one "Application Connect TLV"
The Application Connect TLVs defined so far are:
- PW-RED Connect TLV (Section 7.1.1)
- mLACP Connect TLV (Section 7.2.1)
The details of these TLVs are covered in Section 7.
The "RG Connect" message can have zero or one "Application Connect TLV" 🌈.
6.2.1. ICC Sender Name TLV
The "ICC Sender Name TLV" carries the hostname of the sender, encoded in UTF-8 [RFC3629] format. It's mainly there to help manage the RG and make network operations easier 🧚. 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 = 0x0001 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Name |
+ +-+-+-+-+-+-+-+-+-+
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U=F=0 🔒
- Type 🎀 Set to 0x0001, taken from the ICC parameter name space.
- Length 📐 The length of the TLV in octets. It doesn't count the "U-bit", "F-bit", "Type", or "Length" fields.
- Sender Name 🌸 An administratively assigned name for the sending device. It's encoded in UTF-8 format and limited to a maximum of 80 octets. The field doesn't include a terminating null character 💅.
6.3. RG Disconnect Message ✨
okay so the "RG Disconnect" message has a double life 💅 It can mean "this one Application Connection is closing inside an RG" or "the whole ICCP RG connection is getting disconnected because the PE wants to leave the RG" 🫶 Here's the layout:
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| Message Type = 0x0701 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0005 (ICC RG ID) | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICC RG ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Code TLV |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Application Disconnect TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameter TLVs |
+ +
| |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit
U=0
- Message Type
- The message type for the "RG Disconnect" message is set to
0x0701.
- The message type for the "RG Disconnect" message is set to
- Length
- Length of the TLV in octets, excluding the "U-bit", "Message Type", and "Message Length" fields.
- Message ID
- Defined in Section 6.1.1 above.
- ICC RG ID
- Defined in Section 6.1.1 above.
- Disconnect Code TLV
- The format of this TLV is as follows:
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 = 0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit
- Both are set to
0.
- Both are set to
- Type
- Set to "Disconnect Code TLV" (
0x0004).
- Set to "Disconnect Code TLV" (
- Length
- Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- ICCP Status Code
- A status code that reflects the reason for the disconnect message. Allowed values are "ICCP RG Removed" and "ICCP Application Removed from RG".
- Optional Application Disconnect TLV
- Zero or one "Application Disconnect TLV" (defined in Sections 7.1.2 and 7.2.2). If the "RG Disconnect" message has a status code of "RG Removed", then it MUST NOT contain any "Application Disconnect TLVs", as the sending PE is signaling that it has left the RG and thus is disconnecting the ICCP RG connection with all associated client Application Connections. If the message has a status code of "Application Removed from RG", then it MUST contain exactly one "Application Disconnect TLV", as the sending PE is only tearing down the connection for the specified application. Other applications, and the ICCP RG connection, are not to be affected.
- Optional Parameter TLVs
- None are defined for this message in this document. This is specified to allow for future extensions.
6.4. RG Notification Message 🙈
so a PE sends an "RG Notification" message to say one of four things: reject an ICCP connection, reject an Application Connection, reject a whole message, or reject one or more TLVs inside a message 🔥 And the Notification message MUST only be sent to a PE that is already part of an RG. No cheating allowed 😤
The "RG Notification" message MUST only be used to reject messages or TLVs corresponding to a single ICCP application. In other words, there is a limit of at most a single ICCP application per "RG Notification" message.
The format of the "RG Notification" message goes like this:
i. ICC Header with Message type = "RG Notification Message" (0x0702)
ii. Notification Message TLVs
The currently defined Notification message TLVs are:
i. ICC Sender Name TLV
ii. Negative Acknowledgement (NAK) TLV
6.4.1. Notification Message TLVs 🎀
the "ICC Sender Name TLV" uses the exact same format as the one in the "RG Connect" message, which we already covered above 🫶
the "NAK TLV" looks like this:
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 = 0x0002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ICCP Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional TLV(s) |
+ +
| |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit
- Both are set to
0.
- Both are set to
- Type
- Set to "NAK TLV" (
0x0002).
- Set to "NAK TLV" (
- Length
- Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- ICCP Status Code
- A status code that reflects the reason for the "NAK TLV". Allowed values are as follows:
- i. Unknown ICCP RG (
0x00010001)- This code is used to reject a new incoming ICCP connection for an RG that is not configured on the local PE. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message.
- ii. ICCP Connection Count Exceeded (
0x00010002)- This is used to reject a new incoming ICCP connection that would cause the local PE's ICCP connection count to exceed its capabilities. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message.
- iii. ICCP Application Connection Count Exceeded (
0x00010003)- This is used to reject a new incoming Application Connection that would cause the local PE's ICCP connection count to exceed its capabilities. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
- iv. ICCP Application not in RG (
0x00010004)- This is used to reject a new incoming Application Connection when the local PE doesn't support the application or the application is not configured in the RG. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
- v. Incompatible ICCP Protocol Version (
0x00010005)- This is used to reject a new incoming Application Connection when the local PE has an incompatible version of the application. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Connect" message and the corresponding "Application Connect TLV" MUST be included in the "Optional TLV".
- vi. ICCP Rejected Message (
0x00010006)- This is used to reject an "RG Application Data" message, or one or more TLVs within the message. When this code is used, the "Rejected Message ID" field MUST contain the message ID of the rejected "RG Application Data" message.
- vii. ICCP Administratively Disabled (
0x00010007)- This is used to reject any ICCP messages from a peer from which the PE is not allowed to exchange ICCP messages due to local administrative policy.
- i. Unknown ICCP RG (
- A status code that reflects the reason for the "NAK TLV". Allowed values are as follows:
- Rejected Message ID
- If non-zero, a 4-octet value that identifies the peer message to which the "NAK TLV" refers. If zero, no specific peer message is being identified.
- Optional TLV(s)
- A set of one or more optional TLVs. If the status code is "Rejected Message", then this field contains the TLV or TLVs that were rejected. If the entire message is rejected, all of its TLVs MUST be present in this field; otherwise, the subset of TLVs that were rejected MUST be echoed in this field.
If the status code is "Incompatible Protocol Version", then this field contains the original "Application Connect TLV" sent by the peer, in addition to the "Requested Protocol Version TLV" defined below:
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 = 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Reference | Requested Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit
- Both are set to
0.
- Both are set to
- Type
- Set to
0x0003for "Requested Protocol Version TLV".
- Set to
- Length
- Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Connection Reference
- Set to the "Type" field of the "Application Connect TLV" that was rejected because of incompatible version.
- Requested Version
- The version of the application supported by the transmitting device. For this version of the protocol, it is set to
0x0001.
- The version of the application supported by the transmitting device. For this version of the protocol, it is set to
6.5. RG Application Data Message 💖
the "RG Application Data" message is how application data gets carried between PEs within an RG 🚀 One message can only carry data from one application, but you can stuff multiple Application TLVs into it as long as they all belong to that same application ✨ The format of the "Application Data" message is:
i. ICC Header with Message type = "RG Application Data Message" (0x0703)
ii. Application-specific TLVs
The details of these TLVs are discussed in Section 7. All application-specific TLVs in one "RG Application Data" message MUST belong to a single application but MAY reference different ROs.
7. Application TLVs 👑
7.1. Pseudowire Redundancy (PW-RED) Application TLVs 🦋
this section talks about the "ICCP TLVs" for the Pseudowire Redundancy application 🧚
7.1.1. PW-RED Connect TLV ✨
okay bestie, this TLV is the one that tags along inside the "RG Connect" message to say "hey, let's start a PW-RED Application Connection" 💖 it's giving handshake energy 🤝
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 = 0x0010 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 💅
- Type Set to
0x0010for "PW-RED Connect TLV". 🎀 - Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Protocol Version The version of this particular protocol for the purposes of ICCP. This is set to
0x0001. 🌸 - A-bit Acknowledgement bit. Set to 1 if the sender has received a "PW-RED Connect TLV" from the recipient. Otherwise, set to 0. 🫶 this is the "yes I got your message" bit, and it's so iconic
- Reserved Reserved for future use. 🔮
- Optional Sub-TLVs There are no optional sub-TLVs defined for this version of the protocol. This document does not impose any restrictions on the length of the sub-TLVs. 🧚
7.1.2. PW-RED Disconnect TLV 💔
this one is used in an "RG Disconnect" message to say the PW-RED application connection is getting terminated. it's the "we're done here" TLV, and honestly? iconic closure energy 🥀
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 = 0x0011 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 💅
- Type Set to
0x0011for "PW-RED Disconnect TLV". 🦋 - Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Optional Sub-TLVs The only optional sub-TLV defined for this version of the protocol is the "PW-RED Disconnect Cause TLV" defined in Section 7.1.2.1. ✨
7.1.2.1. PW-RED Disconnect Cause TLV 🙈
the sub-TLV that explains why the disconnect happened. very important for network management, so no skipping it, bestie 📋
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 = 0x0019 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 💅
- Type Set to
0x0019for "PW-RED Disconnect Cause TLV". 🌈 - Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Disconnect Cause String Variable-length string specifying the reason for the disconnect, encoded in UTF-8 format. The string does not include a terminating null character. Used for network management. 🧾
7.1.3. PW-RED Config TLV ⚙️💜
this is the big one bestie, the TLV that carries the actual PW-RED configuration inside the "RG Application Data" message. it's packed with goodies, so let's go 🍓
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 = 0x0012 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW Priority | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID TLV or Generalized PW ID TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 💅
- Type Set to
0x0012for "PW-RED Config TLV". 🎀 - Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- ROID As defined in Section 6.1.3. 🔗
- PW Priority 2 octets. Pseudowire Priority. Used to indicate which PW has better priority to go into active state. Numerically lower numbers are better priority. In case of a tie, the PE with the numerically lower identifier (i.e., IP Address) has better priority. 👑 lower number = more main character energy
- Flags Valid values are as follows:
- i. Synchronized (
0x01) Indicates that the sender has concluded transmitting all pseudowire configuration for a given service. ✅ - ii. Purge Configuration (
0x02) Indicates that the pseudowire is no longer configured for PW-RED operation. 🧹 - iii. Independent Mode (
0x04) Indicates that the pseudowire is configured for redundancy using the Independent Mode of operation, per Section 5.1 of [RFC6870]. 🌿 - iv. Independent Mode with Request Switchover (
0x08) Indicates that the pseudowire is configured for redundancy using the Independent Mode of operation with the use of the "Request Switchover" bit, per Section 6.3 of [RFC6870]. 🔁 - v. Master Mode (
0x10) Indicates that the pseudowire is configured for redundancy using the Master/Slave Mode of operation, with the advertising PE acting as Master, per Section 5.2 of [RFC6870]. 🫅 - vi. Slave Mode (
0x20) Indicates that the pseudowire is configured for redundancy using the Master/Slave Mode of operation, with the advertising PE acting as Slave, per Section 5.2 of [RFC6870]. 🥈
- i. Synchronized (
- Sub-TLVs The "PW-RED Config TLV" includes the following two sub-TLVs:
- i. Service Name TLV
- ii. One of the following: PW ID TLV or Generalized PW ID TLV
The format of the sub-TLVs is defined in Sections 7.1.3.1 through 7.1.3.3. 📦
7.1.3.1. Service Name TLV 🏷️
the name of the L2VPN service instance, basically the label on the box 📦✨
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 = 0x0013 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 💅
- Type Set to
0x0013for "Service Name TLV". 🌷 - Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Service Name The name of the L2VPN service instance, encoded in UTF-8 format and up to 80 octets in length. The string does not include a terminating null character. 🔤
7.1.3.2. PW ID TLV 🆔
this TLV is used to communicate the configuration of PWs for VPWS, so it's the VPWS-flavoured one 💅
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 = 0x0014 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 💅
- Type Set to
0x0014for "PW ID TLV". 🍒 - Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Peer ID 4-octet LDP Router ID of the peer at the far end of the PW. 🛰️
- Group ID Same as Group ID in [RFC4447], Section 5.2. 👯
- PW ID Same as PW ID in [RFC4447], Section 5.2. 🪪
7.1.3.3. Generalized PW ID TLV 🌐
and this is the VPLS version! it's used to communicate the configuration of PWs for VPLS, so it's the one for the bigger, multi-point crew 🫧
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 = 0x0015 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (continued) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 💅
- Type Set to
0x0015for "Generalized PW ID TLV". 🦄 - Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- AGI, AII, SAII, and TAII Defined in [RFC4447], Section 5.3.2. 🧩
7.1.4. PW-RED State TLV 💖
okay so the "PW-RED State TLV" 🎀 rides along inside the "RG Application Data" message, and a device uses it to spill its PW status to everyone else in the RG. it's basically a status update in the group chat 💅
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 = 0x0016 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote PW State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🙈
Both are set to 0.
- Type 🧚
Set to 0x0016 for "PW-RED State TLV".
- Length 🍓
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- ROID ✨
As defined in Section 6.1.3.
- Local PW State 🌸
The status of the PW as determined by the sending PE, encoded in the same format as the "Status Code" field of the "PW Status TLV" defined in [RFC4447] and extended in [RFC6870].
- Remote PW State 🦋
The status of the PW as determined by the remote peer of the sending PE. Encoded in the same format as the "Status Code" field of the "PW Status TLV" defined in [RFC4447] and extended in [RFC6870].
7.1.5. PW-RED Synchronization Request TLV 🔥
the "PW-RED Synchronization Request TLV" also lives in the "RG Application Data" message, and this is how a device asks its peer to resend configuration or operational state 🙌 you can ask for:
- configuration and/or state for one or more pseudowires
- configuration and/or state for all pseudowires
- configuration and/or state for all pseudowires in a given service
here's the layout 👑
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 = 0x0017 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🙈
Both are set to 0.
- Type 🧚
Set to 0x0017 for "PW-RED Synchronization Request TLV".
- Length 🍓
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Request Number 💜
2 octets. Unsigned integer uniquely identifying the request. Used to match the request with a response. The value of 0 is reserved for unsolicited synchronization and MUST NOT be used in the "PW-RED Synchronization Request TLV". Given the use of TCP, there are no issues associated with the wrap-around of the Request Number.
- C-bit 🌈
Set to 1 if the request is for configuration data. Otherwise, set to 0.
- S-bit ⭐
Set to 1 if the request is for running state data. Otherwise, set to 0.
- Request Type 🍓
14 bits specifying the request type, encoded as follows:
0x00 Request Data for specified pseudowire(s)
0x01 Request Data for all pseudowires in specified service(s)
0x3FFF Request All Data- Optional Sub-TLVs 🎀
A set of zero or more TLVs, as follows:
If the "Request Type" field is set to 0x00, then this field contains one or more "PW ID TLVs" or "Generalized PW ID TLVs". If the "Request Type" field is set to 0x01, then this field contains one or more "Service Name TLVs". If the "Request Type" field is set to 0x3FFF, then this field MUST be empty. This document does not impose any restrictions on the length of the sub-TLVs.
7.1.6. PW-RED Synchronization Data TLV 🌸
the "PW-RED Synchronization Data TLV" is used in the "RG Application Data" message 🫶 a pair of these TLVs is used by a device to wrap up a bunch of TLVs that get sent back in response to a "PW-RED Synchronization Request TLV". the first one marks where the sync data starts, the second marks where it ends, and the "Request Number" field is how the response gets matched to its request.
these TLVs also get used for unsolicited advertisements of complete PW-RED configuration and operational state data. in that case, the "Request Number" field MUST be set to 0.
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 = 0x0018 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🙈
Both are set to 0.
- Type 🧚
Set to 0x0018 for "PW-RED Synchronization Data TLV".
- Length 🍓
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Request Number 💜
2 octets. Unsigned integer identifying the Request Number from the "PW-RED Synchronization Request TLV" that solicited this synchronization data response.
- Flags ⭐
2 octets. Response flags encoded as follows:
0x00 Synchronization Data Start
0x01 Synchronization Data End7.2. Multi-Chassis LACP (mLACP) Application TLVs 🦋
this section is all about the "ICCP TLVs" for Ethernet attachment circuit redundancy using the multi-chassis LACP (mLACP) application 🌈
7.2.1. mLACP Connect TLV 🎀
this TLV gets included in the "RG Connect" message to signal that an mLACP Application Connection is being set up ✨
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 = 0x0030 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🙈
Both are set to 0.
- Type 🧚
Set to 0x0030 for "mLACP Connect TLV".
- Length 🍓
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Protocol Version 💖
The version of this particular protocol for the purposes of ICCP. This is set to 0x0001.
- A-bit 🌸
Acknowledgement bit. Set to 1 if the sender has received an "mLACP Connect TLV" from the recipient. Otherwise, set to 0.
- Reserved 🫶
Reserved for future use.
- Optional Sub-TLVs 🔥
There are no optional sub-TLVs defined for this version of the protocol.
7.2.2. mLACP Disconnect TLV 😭
this TLV is used in an "RG Disconnect" message to say the connection for the mLACP application is about to be terminated 💀
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 = 0x0031 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🙈
Both are set to 0.
- Type 🧚
Set to 0x0031 for "mLACP Disconnect TLV".
- Length 🍓
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Optional Sub-TLVs 👑
The only optional sub-TLV defined for this version of the protocol is the "mLACP Disconnect Cause TLV" defined in Section 7.2.2.1.
7.2.2.1. mLACP Disconnect Cause 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 = 0x003A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Disconnect Cause String |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🙈
Both are set to 0.
- Type 🧚
Set to 0x003A for "mLACP Disconnect Cause TLV".
- Length 🍓
Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Disconnect Cause String 🎀
Variable-length string specifying the reason for the disconnect. Used for network management.
7.2.3. mLACP System Config TLV ✨
Okay so the mLACP System Config TLV rides along inside the "RG Application Data" message 📬. Its whole job is to announce the local node's LACP system parameters to the RG peers, so everyone knows who's who 🎀
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 = 0x0032 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node ID |
+-+-+-+-+-+-+-+-+- U-bit and F-bit 🌸: Both are set to 0.
- Type 🍓: Set to 0x0032 for "mLACP System Config TLV".
- Length 📏: Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- System ID 🔑: A 6-octet field encoding the System ID used by LACP, as specified in [IEEE-802.1AX], Section 5.3.2.
- System Priority ⭐: 2 octets encoding the LACP System Priority, as defined in [IEEE-802.1AX], Section 5.3.2.
- Node ID 🧚: 1 octet. This is the LACP Node ID, used to make sure the LACP Port Numbers are unique across all devices in an RG. Valid values are in the range 0-7. Uniqueness of the LACP Port Numbers across RG members is ensured by encoding the Port Numbers as follows:
- Most significant bit always set to 1
- The next 3 most significant bits set to Node ID
- Remaining 12 bits freely assigned by the system
7.2.4. mLACP Aggregator Config TLV ✨
The mLACP Aggregator Config TLV also goes in the "RG Application Data" message 💌. It's how a node tells its RG peers about the local configuration state of an Aggregator, which is basically its whole group-chat profile 💅
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 = 0x0036 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ROID |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Member Ports Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Agg Name Len | Aggregator Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🌸: Both are set to 0.
- Type 🍓: Set to 0x0036 for "mLACP Aggregator Config TLV".
- Length 📏: Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- ROID 🦋: Defined in Section 6.1.3 above.
- Aggregator ID 🎀: 2 octets. This is the LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
- MAC Address 💜: 6 octets encoding the Aggregator Media Access Control (MAC) address.
- Actor Key 🔥: 2 octets. This is the LACP Actor Key for the corresponding Aggregator, as specified in [IEEE-802.1AX], Section 5.3.5.
- Member Ports Priority 👑: 2 octets. This is the LACP administrative port priority associated with all interfaces bound to the Aggregator. This field is valid only when the "Flags" field has "Priority Set" asserted.
- Flags 🚩: Valid values are as follows:
- i. Synchronized (0x01): Indicates that the sender has concluded transmitting all Aggregator configuration information.
- ii. Purge Configuration (0x02): Indicates that the Aggregator is no longer configured for mLACP operation.
- iii. Priority Set (0x04): Indicates that the "Member Ports Priority" field is valid.
- Agg Name Len 🧾: 1 octet. Length of the "Aggregator Name" field in octets.
- Aggregator Name 🏷️: The aggregator name, encoded in UTF-8 format, up to a maximum of 20 octets. It's used for ease of management, and the string does not include a terminating null character.
7.2.5. mLACP Port Config TLV ✨
Next up is the mLACP Port Config TLV, which also rides in the "RG Application Data" message 🦋. This one is how a node tells RG peers about the local configuration state of a port, so it's very much the port's glow-up announcement 🌟
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 = 0x0033 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number | MAC Address |
+-------------------------------+ +
| |
+---------------------------------------------------------------+
| Actor Key | Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Port Name Len | Port Name |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🌸: Both are set to 0.
- Type 🍓: Set to 0x0033 for "mLACP Port Config TLV".
- Length 📏: Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- Port Number 🔢: 2 octets. This is the LACP Port Number for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. The Port Number MUST be encoded with the Node ID, as discussed above.
- MAC Address 💜: 6 octets encoding the port MAC address.
- Actor Key 🔥: 2 octets. This is the LACP Actor Key for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.5.
- Port Priority ⭐: 2 octets. This is the LACP administrative port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. This field is valid only when the "Flags" field has "Priority Set" asserted.
- Port Speed 🚀: A 4-octet integer encoding the port's current bandwidth in units of 1,000,000 bits per second. This field corresponds to the ifHighSpeed object of the IF-MIB [RFC2863].
- Flags 🚩: Valid values are as follows:
- i. Synchronized (0x01): Indicates that the sender has concluded transmitting all member link port configurations for a given Aggregator.
- ii. Purge Configuration (0x02): Indicates that the port is no longer configured for mLACP operation.
- iii. Priority Set (0x04): Indicates that the "Port Priority" field is valid.
- Port Name Len 🧾: 1 octet. Length of the "Port Name" field in octets.
- Port Name 🏷️: Corresponds to the ifName object of the IF-MIB [RFC2863]. It's encoded in UTF-8 format and truncated to 20 octets. Port Name does not include a terminating null character.
7.2.6. mLACP Port Priority TLV ✨
Last but not least, the mLACP Port Priority TLV, which also goes in the "RG Application Data" message 💖. A device uses this one either to advertise its operational Port Priority to other members in the RG, or to authoritatively request that a particular member of an RG change its port priority. Very main character energy 👑
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 = 0x0034 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aggregator ID | Last Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit 🌸: Both are set to 0.
- Type 🍓: Set to 0x0034 for "mLACP Port Priority TLV".
- Length 📏: Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields.
- OpCode 🎯: 2 octets identifying the operational code point for the TLV, encoded as follows:
- 0x00: Local Priority Change Notification
- 0x01: Remote Request for Priority Change
- Port Number 🔢: A 2-octet field representing the LACP Port Number, as specified in [IEEE-802.1AX], Section 5.3.4. When the value of this field is 0, it denotes all ports bound to the Aggregator specified in the "Aggregator ID" field. When non-zero, the Port Number MUST be encoded with the Node ID, as discussed above.
- Aggregator ID 🎀: 2 octets. This is the LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6.
- Last Port Priority ⏪: 2 octets. This is the LACP port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. For local ports, this field encodes the previous operational value of port priority. For remote ports, this field encodes the operational port priority last known to the PE via notifications received from its peers in the RG.
- Current Port Priority ⏩: 2 octets. This is the LACP port priority for the corresponding interface, as specified in [IEEE-802.1AX], Section 5.3.4. For local ports, this field encodes the new operational value of port priority being advertised by the PE. For remote ports, this field specifies the new port priority being requested by the PE.
7.2.7. mLACP Port State TLV ✨
okay so the "mLACP Port State TLV" lives in the "RG Application Data" message 💖 a device uses it to tell the rest of the RG what its LACP port is up to. it's basically the group chat update: "hey, here's my port status, bestie" 🫶
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 = 0x0035 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Port Number | Partner Port Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Partner State | Actor State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Port Number | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Selected | Port State | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 🌸
- Type Set to 0x0035 for "mLACP Port State TLV". 🎀
- Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields. 💅
- Partner System ID 6 octets. This is the LACP Partner System ID for the corresponding interface, encoded as a MAC address as specified in [IEEE-802.1AX], Section 5.4.2.2, item r. 🦋
- Partner System Priority A 2-octet field specifying the LACP Partner System Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item q. ✨
- Partner Port Number 2 octets encoding the LACP Partner Port Number, as specified in [IEEE-802.1AX], Section 5.4.2.2, item u. The Port Number MUST be encoded with the Node ID, as discussed above. 🫶
- Partner Port Priority A 2-octet field encoding the LACP Partner Port Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item t. 💖
- Partner Key A 2-octet field representing the LACP Partner Key, as defined in [IEEE-802.1AX], Section 5.4.2.2, item s. 🧚
- Partner State A 1-octet field encoding the LACP Partner State Variable, as defined in [IEEE-802.1AX], Section 5.4.2.2, item v. 🍓
- Actor State 1 octet encoding the LACP Actor State Variable for the port, as specified in [IEEE-802.1AX], Section 5.4.2.2, item m. 💜
- Actor Port Number A 2-octet field representing the LACP Actor Port Number, as specified in [IEEE-802.1AX], Section 5.3.4. The Port Number MUST be encoded with the Node ID, as discussed above. 🌈
- Actor Key A 2-octet field encoding the LACP Actor Operational Key, as specified in [IEEE-802.1AX], Section 5.3.5. 🔥
- Selected 1 octet encoding the LACP "Selected" variable, defined in [IEEE-802.1AX], Section 5.4.8 as follows:
0x00 SELECTED
0x01 UNSELECTED
0x02 STANDBY- Port State 1 octet encoding the operational state of the port as follows:
0x00 Up
0x01 Down
0x02 Administratively Down
0x03 Test (e.g., IEEE 802.3ah OAM Intrusive Loopback mode)- Aggregator ID 2 octets. This is the LACP Aggregator Identifier that the port is bound to, based on the outcome of the LACP selection logic. 👑
7.2.8. mLACP Aggregator State TLV 🦋
the "mLACP Aggregator State TLV" is also used in the "RG Application Data" message. a device uses it to report its Aggregator status to the other members in the RG. so it's the Aggregator's version of the same update, and honestly iconic 💅
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 = 0x0037 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner System ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Partner System Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Partner Key | Aggregator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Actor Key | Agg State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 🌸
- Type Set to 0x0037 for "mLACP Aggregator State TLV". 🎀
- Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields. 💅
- Partner System ID 6 octets. This is the LACP Partner System ID for the corresponding interface, encoded as a MAC address as specified in [IEEE-802.1AX], Section 5.4.2.2, item r. 🦋
- Partner System Priority A 2-octet field specifying the LACP Partner System Priority, as specified in [IEEE-802.1AX], Section 5.4.2.2, item q. ✨
- Partner Key A 2-octet field representing the LACP Partner Key, as defined in [IEEE-802.1AX], Section 5.4.2.2, item s. 🧚
- Aggregator ID 2 octets. This is the LACP Aggregator Identifier, as specified in [IEEE-802.1AX], Section 5.4.6. 🍓
- Actor Key A 2-octet field encoding the LACP Actor Operational Key, as specified in [IEEE-802.1AX], Section 5.3.5. 💜
- Agg State 1 octet encoding the operational state of the Aggregator as follows:
0x00 Up
0x01 Down
0x02 Administratively Down
0x03 Test (e.g., IEEE 802.3ah OAM Intrusive Loopback mode)7.2.9. mLACP Synchronization Request TLV 🔥
the "mLACP Synchronization Request TLV" is used in the "RG Application Data" message. this is how a device asks its peer to resend configuration or operational state, like "bestie, can you resend that? I missed it" 🙈 the following information can be requested:
- system configuration and/or state
- configuration and/or state for a specific port
- configuration and/or state for all ports with a specific LACP Key
- configuration and/or state for all mLACP ports
- configuration and/or state for a specific Aggregator
- configuration and/or state for all Aggregators with a specific LACP Key
- configuration and/or state for all mLACP Aggregators
the format of the TLV is as follows:
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 = 0x0038 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number |C|S| Request Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number / Aggregator ID | Actor Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 🌸
- Type Set to 0x0038 for "mLACP Synchronization Request TLV". 🎀
- Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields. 💅
- Request Number 2 octets. This is an unsigned integer that uniquely identifies the request, so the response can be matched back to it. The value of 0 is reserved for unsolicited synchronization and MUST NOT be used in the "mLACP Synchronization Request TLV". 🚫
- C-bit Set to 1 if the request is for configuration data. Otherwise, set to 0. ⚙️
- S-bit Set to 1 if the request is for running state data. Otherwise, set to 0. 🦋
- Request Type 14 bits specifying the request type, encoded as follows:
0x00 Request System Data
0x01 Request Aggregator Data
0x02 Request Port Data
0x3FFF Request All Data- Port Number / Aggregator ID 2 octets. When the "Request Type" field is set to "Request Port Data", this field encodes the LACP Port Number for the requested port. When the "Request Type" field is set to "Request Aggregator Data", this field encodes the Aggregator ID of the requested Aggregator. When the value of this field is 0, it denotes that information for all ports (or Aggregators) whose LACP Key is specified in the "Actor Key" field is being requested. 🧚
- Actor Key 2 octets. This is the LACP Actor Key for the corresponding port or Aggregator. When the value of this field is 0 (and the Port Number / Aggregator ID field is 0 as well), it denotes that information for all ports or Aggregators in the system is being requested. 🍓
7.2.10. mLACP Synchronization Data TLV 💜
the "mLACP Synchronization Data TLV" is used in the "RG Application Data" message. a pair of these TLVs wraps up a set of TLVs that are sent back in response to an "mLACP Synchronization Request TLV". the pair marks where the sync data starts and ends, and the "Request Number" field ties the response to the request it answers. very organized, very slay 💅
the "mLACP Synchronization Data TLVs" are also used for unsolicited advertisements of complete mLACP configuration and operational state data. in that case, the "Request Number" field MUST be set to 0. for this unsolicited sync, the PE MUST advertise all system, Aggregator, and port information, the same way it does during the initialization sequence. no one gets left out 🫶
this TLV has the following 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 = 0x0039 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Number | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit and F-bit Both are set to 0. 🌸
- Type Set to 0x0039 for "mLACP Synchronization Data TLV". 🎀
- Length Length of the TLV in octets, excluding the "U-bit", "F-bit", "Type", and "Length" fields. 💅
- Request Number 2 octets. This is an unsigned integer identifying the Request Number from the "mLACP Synchronization Request TLV" that asked for this synchronization data response. 🧚
- Flags 2 octets. These are response flags, encoded as follows:
0x00 Synchronization Data Start
0x01 Synchronization Data End8. LDP Capability Negotiation ✨
okay so [RFC5561] says we need this, so the following TLV gets defined to flag the ICCP capability 💅🎀
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| TLV Code Point = 0x0700 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Reserved | Ver/Maj | Ver/Min |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- U-bit: SHOULD be 1 (ignore if not understood) 🫶
- F-bit: SHOULD be 0 (don't forward if not understood) 🙈
- TLV Code Point: the TLV type, which identifies a specific capability. The ICCP code point is listed in Section 12 below. 🦋
- S-bit: State bit. Indicates whether the sender is advertising or withdrawing the ICCP capability. The State bit is used as follows:
1- The TLV is advertising the capability specified by the TLV Code Point. ✨0- The TLV is withdrawing the capability specified by the TLV Code Point. 💀
Ver/Maj: The major version revision of ICCP. This document specifies 1.0, and so this field is set to 1. 👑Ver/Min: The minor version revision of ICCP. This document specifies 1.0, and so this field is set to 0. 🌸
ICCP capability is advertised to an LDP peer if there is at least one RG enabled on the local PE. 🧚
9. Client Applications 💖
9.1. Pseudowire Redundancy Application Procedures
okay bestie, this section lays out the rules for the Pseudowire Redundancy (PW-RED) application 🌈
It should be noted that the PW-RED application SHOULD NOT be enabled together with an AC redundancy application for the same service instance. This simplifies the operation of the multi-chassis redundancy solution (Figure 1) and eliminates the possibility of deadlock conditions between the AC and PW redundancy mechanisms. not me being impressed by the no-deadlock energy 😭✨
9.1.1. Initial Setup
when an RG is configured on a system and multi-chassis pseudowire redundancy is enabled in that RG, the PW-RED application MUST send an RG Connect message with a PW-RED Connect TLV to each PE that is a member of the same RG. The sending PE MUST set the A-bit to 1 if it has already received a PW-RED Connect TLV from its peer; otherwise, the PE MUST set the A-bit to 0. If a PE that has sent the TLV with the A-bit set to 0 receives a PW-RED Connect TLV from a peer, it MUST repeat its advertisement with the A-bit set to 1. The PW-RED Application Connection is considered to be operational when both PEs have sent and received PW-RED Connect TLVs with the A-bit set to 1. Once the Application Connection becomes operational, the two devices can start exchanging RG Application Data messages for the PW-RED application. 🤝💜
If a system receives an RG Connect message with a PW-RED Connect TLV that has a different Protocol Version, it must follow the procedures outlined in Section 4.4.1 above. 🙃
When the PW-RED application is disabled on the device or is unconfigured for the RG in question, the system MUST send an RG Disconnect message with a PW-RED Disconnect TLV. 🫠
9.1.2. Pseudowire Configuration Synchronization
A system MUST advertise its local PW configuration to other PEs that are members of the same RG. This lets the PEs build a view of the redundant nodes and pseudowires that are protecting the same service instances. The advertisement MUST be initiated when the PW-RED Application Connection first comes up. To that end, the system sends RG Application Data messages with PW-RED Config TLVs as part of an unsolicited synchronization. A PE MUST use a pair of PW-RED Synchronization Data TLVs to delimit the set of TLVs that are being sent as part of this unsolicited advertisement. 📦
In the case of a configuration change, a PE MUST re-advertise the most up-to-date information for the affected pseudowires. 🔄
As part of the configuration synchronization, a PE advertises the ROID associated with the pseudowire. This is used to correlate the pseudowires that are protecting each other on different PEs. A PE also advertises the configured PW redundancy mode. This can be one of the following four options: Master Mode, Slave Mode, Independent Mode, or Independent Mode with Request Switchover. If the received redundancy mode does not match the locally configured mode for the same ROID, then the PE MUST respond with an RG Notification message to reject the PW-RED Config TLV. The PE MUST disable the associated local pseudowire until a satisfactory PW-RED Config TLV is received from the peer. This guarantees that device misconfiguration does not lead to network-wide problems (e.g., by creating forwarding loops). The PE SHOULD also raise an alarm to alert the operator. If a PE receives a NAK TLV for an advertised PW-RED Config TLV, it MUST disable the associated pseudowire and SHOULD raise an alarm to alert the operator. 🚨
Furthermore, a PE advertises in its PW-RED Config TLVs a priority value that is used to determine the precedence of a given pseudowire to assume the active role in a redundant setup. A PE also advertises a Service Name that is global in the context of an RG and is used to identify which pseudowires belong to the same service. Finally, a PE also advertises the pseudowire identifier as part of this synchronization. 🎀
9.1.3. Pseudowire Status Synchronization
PEs that are members of an RG synchronize pseudowire status for the purpose of identifying, on a per-ROID basis, which pseudowire will be actively used for forwarding and which pseudowire(s) will be placed in standby state. 👑
Synchronization of pseudowire status is done by sending the PW-RED State TLV whenever the pseudowire state changes on a PE. This includes changes to the local end as well as the remote end of the pseudowire. ✨
A PE may request that its peer retransmit previously advertised PW-RED state. This is useful, for instance, when the PE is recovering from a soft failure. To request such a retransmission, a PE MUST send a set of one or more PW-RED Synchronization Request TLVs. 🔁
A PE MUST respond to a PW-RED Synchronization Request TLV by sending the requested data in a set of one or more PW-RED TLVs delimited by a pair of PW-RED Synchronization Data TLVs. The TLVs comprising the response MUST be ordered such that the Synchronization Response TLV with the Synchronization Data Start flag precedes the various other PW-RED TLVs encoding the requested data. These, in turn, MUST precede the Synchronization Data TLV with the Synchronization Data End flag. It is worth noting that the response may span multiple RG Application Data messages; however, the above TLV ordering MUST be retained across messages, and only a single pair of Synchronization Data TLVs must be used to delimit the response across all Application Data messages. the ordering rules are very strict and very iconic 🫶💅
A PE MAY re-advertise its PW-RED state in an unsolicited manner. This is done by sending the appropriate Config and State TLVs delimited by a pair of PW-RED Synchronization Data TLVs and using a Request Number of 0. 📣
While a PE has a pending synchronization request for a pseudowire or a service, it SHOULD silently ignore all TLVs for said pseudowire or service that are received prior to the synchronization response and that carry the same type of information being requested. This saves the system from the burden of updating state that will ultimately be overwritten by the synchronization response. Note that TLVs pertaining to other pseudowires or services are to continue to be processed per normal procedures in the interim. 🙈
If a PE receives a synchronization request for a pseudowire or service that doesn't exist or is not known to the PE, then it MUST trigger an unsolicited synchronization of all pseudowire information (i.e., replay the initialization sequence). 🔥
In the subsections that follow, we describe the details of pseudowire status synchronization for each of the PW redundancy modes defined in [RFC6870]. 🌸
9.1.3.1. Independent Mode
This section covers the operation in Independent Mode with or without Request Switchover capability. 🦋
In this mode, the operator must ensure that for a given RO the PW Priority values configured for all associated pseudowires on a given PE are collectively higher (or lower) than those configured on other PEs in the same RG. If this condition is not satisfied after the PEs have exchanged PW-RED State TLVs, a PE MUST disable the associated pseudowire(s) and SHOULD raise an alarm to alert the operator. Note that the PW Priority MAY be the same as the PW Precedence as defined in [RFC6870]. ⚠️
For a given RO, after all of the PEs in an RG have exchanged their PW-RED State TLVs, the PE with the best PW Priority (i.e., least numeric value) advertises active Preferential Forwarding status in LDP on all of its associated pseudowires, whereas all other PEs in the RG advertise standby Preferential Forwarding status in LDP on their associated pseudowires. 🏆
If the service is VPWS, then only a single pseudowire per service will be selected for forwarding. This is the pseudowire that is independently advertised with active Preferential Forwarding status on both endpoints, as described in [RFC6870]. 💜
If the service is VPLS, then one or multiple pseudowires per service will be selected for forwarding. These are the pseudowires that are independently advertised with active Preferential Forwarding status on both PW endpoints, as described in [RFC6870]. 🌈
9.1.3.2. Master/Slave Mode
In this mode, the operator must ensure that for a given RO the PW Priority values configured for all associated pseudowires on a given PE are collectively higher (or lower) than those configured on other PEs in the same RG. If this condition is not satisfied after the PEs have exchanged PW-RED State TLVs, a PE MUST disable the associated pseudowire(s) and SHOULD raise an alarm to alert the operator. Note that the PW Priority MAY be the same as the PW Precedence as defined in [RFC6870]. In addition, the operator must ensure that for a given RO all of the PEs in the RG are consistently configured as Master or Slave. 🧐
In the context of a given RO, if the PEs in the RG are acting as Master, then the PE with the best PW Priority (i.e., least numeric value) advertises active Preferential Forwarding status in LDP on only a single pseudowire, following the procedures in Sections 5.2 and 6.2 of [RFC6870], whereas all of the other pseudowires on other PEs in the RG are advertised with standby Preferential Forwarding status in LDP. 👑🍓
9.1.4. PE Node Failure or Isolation
When a PE node detects that a remote PE that is a member of the same RG is no longer reachable (using the mechanisms described in Section 5), the local PE determines if it has redundant PWs for the affected services. If the local PE has the highest priority (after the failed PE), then it becomes the active node for the services in question and subsequently activates its associated PW(s). 🆘💖
9.2. Attachment Circuit Redundancy Application Procedures
9.2.1. Common AC Procedures
This section describes generic procedures for AC redundancy applications, independent of the type of the AC (ATM, FR, or Ethernet). ✨🧚
9.2.1.1. AC Failure 💥
Okay bestie, when the AC redundancy mechanism on the active PE notices its AC has failed, it should send an ICCP Application Data message 📨 to tell the redundant PEs it's their time to take over 👑. AC failures come in three flavours:
- Failure of CE interface connecting to PE
- Failure of CE uplink to PE
- Failure of PE interface connecting to CE
9.2.1.2. Remote PE Node Failure or Isolation 🫣
When a PE notices that a remote PE in the same RG is no longer reachable (using the mechanisms in Section 5 🔍), the local PE checks whether it has redundant ACs for the affected services. If the local PE has the highest priority (after the failed PE), then it becomes the active node for those services and activates its associated ACs. Main character energy 🦋
9.2.1.3. Local PE Isolation 🏝️
If a PE realises it's been cut off from the core network (all core-facing interfaces/links are not operational 📉), then it should make sure its AC redundancy mechanism flips any active ACs to standby 😬. The AC redundancy application SHOULD then send ICCP Application Data messages to trigger failover to a standby PE. Note that this only works with dedicated interconnect (Sections 3.2.1 and 3.2.3), because ICCP still has a path to the peer even though the PE is isolated from the MPLS core 🧠.
9.2.1.4. Determining Pseudowire State 🔮
If the PEs in an RG are running an AC redundancy application over ICCP, then the Independent Mode of PW redundancy, as defined in [RFC6870], MUST be used 🙅♀️. On a given PE, the Preferential Forwarding status of the PW (active or standby) is derived from the state of the associated AC(s). This simplifies the operation of the multi-chassis redundancy solution (Figure 1) and eliminates the possibility of deadlock conditions between the AC and PW redundancy mechanisms. The rules for deriving PW status from AC status are as follows:
- VPWS For VPWS, there's a single AC per service instance. If the AC is active, then the PW status should be active. If the AC is standby, then the PW status should be standby.
- VPLS For VPLS, there could be multiple ACs per service instance (i.e., Virtual Switch Instance (VSI) [RFC4026]). If AT LEAST ONE AC is active, then the PW status should be active. If ALL ACs are standby, then the PW status should be standby.
In this case, the PW-RED application is not used to synchronize PW status between PEs 🙅. Instead, the AC redundancy application should synchronize AC status between PEs, so they can figure out which AC (and therefore which PE) is active or standby for a given service. Once that's determined, each PE derives its local PW's state using the rules above. The Preferential Forwarding status bit, described in [RFC6870], is used to advertise PW status to the remote peers 📣.
9.2.2. Multi-Chassis LACP (mLACP) Application Procedures 🧩
This section defines the procedures specific to the multi-chassis LACP (mLACP) application, which applies to Ethernet ACs 🫶.
9.2.2.1. Initial Setup 🌱
Okay so when an RG is configured on a system and mLACP is enabled in that RG, the mLACP application MUST send an RG Connect message with an mLACP Connect TLV to each PE that is a member of the same RG 🤝. The sending PE MUST set the A-bit to 1 in said TLV if it has received a corresponding mLACP Connect TLV from its peer PE; otherwise, the sending PE MUST set the A-bit to 0. If a PE receives an mLACP Connect TLV from its peer after sending said TLV with the A-bit set to 0, it MUST resend the TLV with the A-bit set to 1 ✨. A system considers the mLACP Application Connection to be operational when it has sent and received mLACP Connect TLVs with the A-bit set to 1 🥳. Once the mLACP Application Connection between a pair of PEs is operational, the two devices can start exchanging RG Application Data messages for the mLACP application. This involves each PE advertising its mLACP configuration and operational state in an unsolicited manner (aka without being asked 🙃). A PE SHOULD use the following sequence when advertising its mLACP state upon initial Application Connection setup:
- Advertise system configuration
- Advertise Aggregator configuration
- Advertise port configuration
- Advertise Aggregator state
- Advertise port state
A PE MUST use a pair of mLACP Synchronization Data TLVs to delimit the entire set of TLVs that are being sent as part of this unsolicited advertisement 🎀.
If a system receives an RG Connect message with an mLACP Connect TLV that has a different Protocol Version, it MUST follow the procedures outlined in Section 4.4.1 above 🙅.
After the mLACP Application Connection has been established, every PE MUST communicate its system-level configuration to its peers via the mLACP System Config TLV. This lets every PE discover the Node ID and the locally configured System ID and System Priority values of its peers 🔎.
If a PE receives an mLACP System Config TLV from a remote peer advertising the same Node ID value as the local system, then the PE MUST respond with an RG Notification message to reject the mLACP System Config TLV. The PE MUST suspend the mLACP application until a satisfactory mLACP System Config TLV is received from the peer. It SHOULD also raise an alarm to alert the operator 🚨. Furthermore, if a PE receives a NAK TLV for an mLACP System Config TLV that it has advertised, the PE MUST suspend the mLACP application and SHOULD raise an alarm to alert the network operator of potential device misconfiguration 💀.
If a PE receives an mLACP System Config TLV from a new peer advertising the same Node ID value as another existing peer with which the local system has an established mLACP Application Connection, then the PE MUST respond to the new peer with an RG Notification message to reject the mLACP System Config TLV, and MUST ignore the offending TLV 🙈.
If the Node ID of a particular PE changes due to administrative configuration action, the PE MUST then inform its peers to purge the configuration of all previously advertised ports and/or Aggregators, and MUST replay the initialization sequence by sending an unsolicited synchronization of the system configuration, Aggregator configuration, port configuration, Aggregator state, and port state 🔁.
It is necessary for all PEs in an RG to agree upon the System ID and System Priority values to be used ubiquitously. To achieve this, every PE MUST use the values for the two parameters that are supplied by the PE with the numerically lowest value (among RG members) of System Aggregation Priority. This guarantees that the PEs always agree on uniform values that yield the highest System Priority 👑.
When the mLACP application is disabled on the device or is unconfigured for the RG in question, the system MUST send an RG Disconnect message with an mLACP Disconnect TLV 👋.
9.2.2.2. mLACP Aggregator and Port Configuration 🎛️
A system MUST synchronize the configuration of its mLACP-enabled Aggregators and ports with other RG members 🧑🤝🧑. This is achieved via the use of mLACP Aggregator Config TLVs and mLACP Port Config TLVs, respectively. An implementation MUST advertise the configuration of Aggregators prior to advertising the configuration of any of their associated member ports.
The PEs in an RG MUST all agree on the MAC address to be associated with a given Aggregator. It is possible to achieve this via consistent configuration on member PEs. However, to protect against possible misconfiguration, a system MUST use, for any given Aggregator, the MAC address supplied by the PE with the numerically lowest System Aggregation Priority in the RG 🛡️.
A system that receives an mLACP Aggregator Config TLV with a ROID-to-Key association that is different from its local association MUST reject the corresponding TLV and disable the Aggregator with the same ROID. Furthermore, it SHOULD raise an alarm to alert the operator. Similarly, a system that receives a NAK TLV in response to a transmitted mLACP Aggregator Config TLV MUST disable the associated Aggregator and SHOULD raise an alarm to alert the network operator 📢.
A system MAY enforce a restriction that all ports to be bundled together on a given PE share the same Port Priority value. If so, the system MUST advertise this common priority in the mLACP Aggregator Config TLV and assert the Priority Set flag in that TLV. Furthermore, the system in this case MUST NOT advertise individual Port Priority values in the associated mLACP Port Config TLVs (i.e., the Priority Set flag in these TLVs should be 0) 🙅♀️.
A system MAY support individual Port Priority values to be configured on ports that are to be bundled together on a PE. If so, the system MUST advertise the individual Port Priority values in the appropriate mLACP Port Config TLVs, and MUST NOT assert the Priority Set flag in the corresponding mLACP Aggregator Config TLV 💅.
When the configurations of all ports for member links associated with a given Aggregator have been sent by a device, it asserts that fact by setting the Synchronized flag in the last port's mLACP Port Config TLV. If an Aggregator doesn't have any candidate member ports configured, this is indicated by asserting the Synchronized flag in its mLACP Aggregator Config TLV ✅.
Furthermore, for a given port/Aggregator, an implementation MUST advertise the port/Aggregator configuration prior to advertising its state (via the mLACP Port State TLV or mLACP Aggregator State TLV). If a PE receives an mLACP Port State TLV or mLACP Aggregator State TLV for a port or Aggregator that it had not previously learned via an appropriate Port Config TLV or Aggregator Config TLV, then the PE MUST request synchronization of the configuration and state of all mLACP ports, as well as all mLACP Aggregators, from its respective peer. During a synchronization (solicited or unsolicited), if a PE receives a State TLV for a port or Aggregator that it has not learned before, then the PE MUST send a NAK TLV for the offending TLV. The PE MUST NOT request resynchronization in this case 🙃.
When mLACP is unconfigured on a port/Aggregator, a PE MUST send a Port/Aggregator Config TLV with the Purge Configuration flag asserted. This allows receiving PEs to purge any state maintained for the decommissioned port/Aggregator. If a PE receives a Port/Aggregator Config TLV with the Purge Configuration flag asserted and the PE is not maintaining any state for that port/Aggregator, then it MUST silently discard the TLV 🫥.
9.2.2.3. mLACP Aggregator and Port Status Synchronization ✨
bestie, the PEs in an RG need to keep their state machines in sync 🫶 so mLACP actually works with a multi-homed device. The way they do it is that each system advertises its Aggregators and ports' running state in "mLACP Aggregator State TLVs" and "mLACP Port State TLVs", respectively. Whenever any LACP parameter for an Aggregator or a port changes (whether it's on the Partner side, meaning the multi-homed device, or the Actor side, meaning the PE), a system MUST transmit an updated TLV for the affected Aggregator and/or port. And when the administrative or operational state of an Aggregator or port changes, the system MUST transmit an updated Aggregator or Port State TLV to its peers. Sync or it's not happening 💅
If a PE receives an Aggregator or Port State TLV where the Actor Key doesn't match what it got before in a corresponding "Aggregator Config TLV" or "Port Config TLV", the PE MUST then request synchronization of the configuration and state of the affected Aggregator or port. If that mismatch shows up between the Config and State TLVs during a synchronization (solicited or unsolicited), the PE MUST send a "NAK TLV" for the "State TLV". Also, if a PE gets a "Port State TLV" with the "Aggregator ID" set to a value that doesn't map to any Aggregator the PE learned about from a previous "Aggregator Config TLV", the PE MUST request synchronization of the configuration and state of all Aggregators and ports. If that anomaly happens during a synchronization, the PE MUST send a "NAK TLV" for the offending "Port State TLV". 😭 so many checks, but that's the vibe.
A PE MAY request that its peer retransmit previously advertised state. This is useful, for example, when the PE is recovering from a soft failure and trying to relearn state 🧚. To ask for those retransmissions, a PE MUST send a set of one or more "mLACP Synchronization Request TLVs".
A PE MUST respond to an "mLACP Synchronization Request TLV" by sending the requested data in a set of one or more mLACP TLVs, wrapped by a pair of "mLACP Synchronization Data TLVs". The TLVs in the response MUST be ordered in the "RG Application Data" message(s) so that the "Synchronization Response TLV" with the "Synchronization Data Start" flag comes first. The various other mLACP TLVs encoding the requested data MUST come next, and then the "Synchronization Data TLV" with the "Synchronization Data End" flag. Note that the response may span multiple "RG Application Data" messages (for example, when MTU limits are exceeded). 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 "Application Data" messages. Ordering is everything here, iykyk 🎀
A PE device MAY re-advertise its mLACP state in an unsolicited manner. It does this by sending the appropriate Config and State TLVs, delimited by a pair of "mLACP Synchronization Data TLVs", and using a "Request Number" of 0.
While a PE has a pending synchronization request for a system, Aggregator, or port, it SHOULD silently ignore all TLVs for that system, Aggregator, or port that were received before the synchronization response and that carry the same type of information being requested. This saves the system from the burden of updating state that's going to get overwritten by the synchronization response anyway 🙈. Note that TLVs about other systems, Aggregators, or ports keep getting processed per normal procedures in this case.
If a PE receives a synchronization request for an Aggregator, port, or key that doesn't exist or isn't known to the PE, then it MUST trigger an unsolicited synchronization of all system, Aggregator, and port information (basically, replay the initialization sequence) 🔁.
If a PE learns, as part of a synchronization operation from its peer, that the peer is advertising a Node ID value different from the one previously advertised, then the PE MUST purge all Port/Aggregator data it previously learned from that peer prior to the last synchronization. Old data gets yeeted, no debate 💀
9.2.2.4. Failure and Recovery 🌸
When a PE that's active for a multi-chassis link aggregation group runs into a core isolation fault, it SHOULD attempt to fail over to a peer PE that hosts the same RO. The default failover procedure is for the failed PE to bring down the link or links toward the multi-homed CE (for example, by bringing down the line protocol). That makes the CE fail over to the other member link or links of the bundle that connect to the other PE(s) in the RG. Other procedures for triggering failover are possible, but they're outside the scope of this document 🤷♀️.
When recovering from a previous fault, a PE MAY reclaim the active role for a multi-chassis link aggregation group if it's configured for revertive protection. Otherwise, the recovering PE may take on the standby role when it's configured for non-revertive protection. In the revertive scenario, a PE SHOULD take the active role within the RG by sending an "mLACP Port Priority TLV" to the currently active PE. That TLV asks the active PE to change its port priority to a value that's lower (numerically larger) for the Aggregator in question 👑.
If a system is running in a mode where different ports of a bundle have different Port Priorities configured, the system MUST NOT advertise or request changes of Port Priority values for aggregated ports collectively (that is, by using a "Port Number" of 0 in the "mLACP Port Priority TLV"). This keeps things from getting ambiguous when it comes to reading the "Last Port Priority" field 🧐.
If a PE receives an "mLACP Port Priority TLV" that requests a priority change for a port or Aggregator that isn't local to the device, the PE MUST re-advertise the local configuration of the system, as well as the configuration and state of all of its mLACP ports and Aggregators.
If a PE receives an "mLACP Port Priority TLV" in which the remote system advertises a priority change for a port or Aggregator that the local PE had not previously learned about via an appropriate "Port Config TLV" or "Aggregator Config TLV", then the PE MUST request synchronization of the configuration and state of all mLACP ports, as well as all mLACP Aggregators, from its respective peer. ✨
10. Security Considerations 🔐
ICCP SHOULD only be used in well-managed and highly monitored networks. It ought not be deployed on or over the public Internet. ICCP is not intended to be applicable when the Redundancy Group spans PEs in different administrative domains.
The security considerations described in [RFC5036] and [RFC4447] that apply to the base LDP specification and to the PW LDP control protocol extensions also apply to the capability mechanism described in this document. In particular, ICCP implementations MUST provide a mechanism to select which LDP peers the ICCP capability will be advertised to, and which LDP peers ICCP messages will be accepted from. Therefore, an incoming ICCP connection request MUST NOT be accepted unless its source IP address is known to be the source of an "eligible" ICCP peer. The set of eligible peers could be preconfigured (as a list of either IP addresses or address/mask combinations), or it could be discovered dynamically via some secure discovery protocol. The TCP Authentication Option (TCP-AO), as defined in [RFC5925], SHOULD be used. It provides integrity and authentication for the ICCP messages and eliminates the possibility of source address spoofing 🕵️♀️. However, for backwards compatibility and/or to make migration easier, the LDP MD5 authentication key option, as described in Section 2.9 of [RFC5036], MAY be used instead.
The security framework and considerations for MPLS in general, and for LDP in particular, as described in [RFC5920] apply to this document. Moreover, the recommendations of [RFC6952] and the mechanisms of [LDP-CRYPTO] aimed at addressing LDP's vulnerabilities are applicable as well.
Okay this section is serious, bestie. Activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks. For example, a malicious CE implementation may trigger continuously varying LACP messages that lead to excessive ICCP exchanges. Excessive link bouncing of the attachment circuits may also lead to the same effect. Similar arguments apply to the inter-PE MPLS links. Implementations SHOULD provide mechanisms to perform control-plane policing and mitigate these types of attacks. 🚨💀
11. Manageability Considerations 🛠️
Implementations SHOULD generally minimize the number of parameters required to configure ICCP, so it's easier to use 🍓. Implementations SHOULD allow the user to control the RGID via configuration, since this is required to support flexible grouping of PEs in RGs. Implementations SHOULD also provide mechanisms to troubleshoot the correct operation of ICCP, which includes mechanisms to diagnose ICCP connections as well as Application Connections. Implementations MUST provide a means for the user to indicate the IP addresses of remote PEs that are to be members of a given RG. Automatic discovery of RG membership MAY be supported; this topic is outside the scope of this specification.
12. IANA Considerations 📋
12.1. Message Type Name Space
This document uses several new LDP message types. IANA maintains the "Message Type Name Space" registry as defined by [RFC5036]. The following values have been assigned:
Message Type Description
------------- ----------------------------
0x0700 RG Connect Message
0x0701 RG Disconnect Message
0x0702 RG Notification Message
0x0703 RG Application Data Message
0x0704-0x070F Reserved for future ICCP use12.2. TLV Type Name Space
This document uses a new LDP TLV type. IANA maintains the "TLV Type Name Space" registry as defined by [RFC5036]. The following value has been assigned:
TLV Type Description
-------- -------------------
0x0700 ICCP capability TLV12.3. ICC RG Parameter Type Space 🎀
okay so IANA made a registry called "ICC RG Parameter Types" 💖 and it lives inside the "Pseudowire Name Spaces (PWE3)" registry 🦋. ICC RG parameter types are 14-bit values ✨.
Parameter Type values 1 through 0x003A are specified in this document 📝. Values 0x003B through 0x1FFF get assigned by IANA using the "Expert Review" policy from [RFC5226] 🧚. Values 0x2000 through 0x2FFF, 0x3FFF, and 0 are allocated using the "IETF Review" policy from [RFC5226] 👑. And 0x3000 through 0x3FFE are reserved for vendor proprietary extensions 💅, assigned by IANA with the "First Come First Served" policy from [RFC5226] 🌈.
The initial ICC parameter type allocations look like this 🍓:
Parameter Type Description
-------------- ----------------------------------
0x0001 ICC Sender Name
0x0002 NAK TLV
0x0003 Requested Protocol Version TLV
0x0004 Disconnect Code TLV
0x0005 ICC RG ID TLV
0x0006-0x000F Reserved
0x0010 PW-RED Connect TLV
0x0011 PW-RED Disconnect TLV
0x0012 PW-RED Config TLV
0x0013 Service Name TLV
0x0014 PW ID TLV
0x0015 Generalized PW ID TLV
0x0016 PW-RED State TLV
0x0017 PW-RED Synchronization Request TLV
0x0018 PW-RED Synchronization Data TLV
0x0019 PW-RED Disconnect Cause TLV
0x001A-0x002F Reserved
0x0030 mLACP Connect TLV
0x0031 mLACP Disconnect TLV
0x0032 mLACP System Config TLV
0x0033 mLACP Port Config TLV
0x0034 mLACP Port Priority TLV
0x0035 mLACP Port State TLV
0x0036 mLACP Aggregator Config TLV
0x0037 mLACP Aggregator State TLV
0x0038 mLACP Synchronization Request TLV
0x0039 mLACP Synchronization Data TLV
0x003A mLACP Disconnect Cause TLV12.4. Status Code Name Space 🌸
this document uses a bunch of new Status codes ✨. IANA keeps track of them in the "Status Code Name Space" registry, which is defined by [RFC5036] 💜. Here are the values that got assigned, and the "E" column tells you what the Status Code E-bit has to be set to 🙈.
Range/Value E Description
------------ ----- ------------------------------------------
0x00010001 0 Unknown ICCP RG
0x00010002 0 ICCP Connection Count Exceeded
0x00010003 0 ICCP Application Connection Count Exceeded
0x00010004 0 ICCP Application not in RG
0x00010005 0 Incompatible ICCP Protocol Version
0x00010006 0 ICCP Rejected Message
0x00010007 0 ICCP Administratively Disabled
0x00010010 0 ICCP RG Removed
0x00010011 0 ICCP Application Removed from RG13. Acknowledgments 🫶
the authors want to shout out Dennis Cai, Neil McGill, Amir Maleki, Dan Biagini, Robert Leger, Sami Boutros, Neil Ketley, and Mark Christopher Sains 💖. They were genuinely important to this work, no cap 👑.
the authors also thank Daniel Cohn, Lizhong Jin, and Ran Chen for their valuable input, discussions, and comments 🌈. Thank you all, you're iconic ✨.
14. References 📚
14.1. Normative References 💖
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[IEEE-802.1AX]
IEEE Std. 802.1AX-2008, "IEEE Standard for Local and
metropolitan area networks--Link Aggregation", IEEE
Computer Society, November 2008.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC6870] Muley, P., Ed., and M. Aissaoui, Ed., "Pseudowire
Preferential Forwarding Status Bit", RFC 6870,
February 2013.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.14.2. Informative References 🦋
[RFC2922] Bierman, A. and K. Jones, "Physical Topology MIB",
RFC 2922, September 2000.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[LDP-CRYPTO]
Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
Cryptographic Authentication", Work in Progress,
June 2014.Authors' Addresses 💌
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
United States
EMail: lmartini@cisco.com
Samer Salam
Cisco Systems, Inc.
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1
Canada
EMail: ssalam@cisco.com
Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
United States
EMail: sajassi@cisco.com
Matthew Bocci
Alcatel-Lucent
Voyager Place
Shoppenhangers Road
Maidenhead
Berks, SL6 2PJ
UK
EMail: matthew.bocci@alcatel-lucent.com
Satoru Matsushima
Softbank Telecom
1-9-1, Higashi-Shinbashi, Minato-ku
Tokyo 105-7304
Japan
EMail: satoru.matsushima@g.softbank.co.jp
Thomas Nadeau
Brocade
EMail: tnadeau@brocade.comthat's the whole RFC, bestie!! 🌈💖✨
📦 where this page comes from
- ietf: rfc7275 2014-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms