Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy
Extracted elements (27)
An optional dedicated Redundancy Group LDP session (using a separate TCP/IP session with a non-zero label space identifier) is defined to distribute load across processors and avoid head-of-line blocking to other LDP applications when large volumes of RG information must be exchanged rapidly.
ICCP is built as a secondary protocol running within LDP, exploiting LDP session mechanisms, TCP transport, and TCP-based security already required for pseudowire operation. This avoids duplicating infrastructure that L2VPN PEs must already support.
The ROID is a 64-bit opaque identifier deliberately agnostic to the nature (physical or virtual) and implementation specifics of the protected entity. This design guarantees interoperability without constraining how individual systems internally represent protected objects.
A device MUST reject an incoming RG Connect message if the PE is not a member of the specified RG or if the maximum number of simultaneous ICCP connections is exceeded. Otherwise the PE MUST bring up the connection by responding with an appropriate RG Connect.
A PE MUST send a Notification message to reject an Application Connection if the application is not configured for that RG or if the Application Connection count exceeds the PE's capabilities. Upon receiving such a rejection, the remote PE MUST stop attempting to bring up the Application Connection until it receives a new request.
ICCP MUST allow a single node to be a member of multiple RGs simultaneously; a PE that is a member of multiple RGs MUST send separate RG Connect messages for each RG even when communicating to the same peer.
ICCP MUST ensure transport security between RG devices; ICCP MUST NOT accept connections arbitrarily from any device, and means to prevent source address spoofing MUST be in place. This leverages TCP-based security mechanisms already required for LDP operation, and is especially critical when RG members communicate over a shared PSN.
ICCP SHOULD achieve sub-second detection of loss of a remote PE node (approximately 50–150 ms) in order to give client redundancy applications enough reaction time to achieve sub-second service restoration times.
If an application receives an Application Connect TLV with a version number higher than its own, it MUST send a Notification message with a NAK TLV indicating 'Incompatible Protocol Version' and supplying its locally supported version. If the received version is lower, it MAY respond with a matching version or reject with NAK.
The ICCP connection for an RG MUST be operational before any client application can make use of ICCP services in that RG. A PE that receives a NAK TLV rejecting its RG Connect MUST stop attempting to bring up the connection immediately.
The Redundant Object Identifier (ROID) MUST match between all RG members for the same protected object, providing a common implementation-agnostic handle for objects such as multi-chassis LAGs, pseudowires, or VLANs. The ROID value 0 is reserved.
When an RG is enabled on a PE, an LDP session to every remote PE in that RG MUST be created if one does not already exist, and the ICCP capability MUST then be advertised to all LDP peers in that RG per RFC 5561. If the peer does not support dynamic capability advertisements, the ICCP Capability TLV MUST be included in LDP initialization.
ICCP reuses existing fault detection mechanisms—Bidirectional Forwarding Detection (BFD, RFC 5880) or IP Reachability Monitoring via IGP/BGP—rather than defining its own keep-alive, to notify client applications of remote PE failure or isolation. Loss of the LDP session alone is explicitly not a reliable indicator of remote PE failure.
The NAK TLV (Type=0x0002) carries an ICCP Status Code, Rejected Message ID, and optional echoed TLVs. Defined status codes are: Unknown ICCP RG (0x00010001), Connection Count Exceeded (0x00010002), Application Connection Count Exceeded (0x00010003), Application not in RG (0x00010004), Incompatible Protocol Version (0x00010005), Rejected Message (0x00010006), and Administratively Disabled (0x00010007).
The PW-RED Config TLV (Type=0x0012) conveys pseudowire redundancy configuration including: ROID (8 octets), PW Priority (2 octets; lower value is higher priority; ties broken by numerically lower PE IP address), and Flags encoding operational mode (Independent, Independent with Request Switchover, Master, Slave) and synchronization completion.
The PW-RED Connect TLV (Type=0x0010) is carried in an RG Connect message to establish a Pseudowire Redundancy Application Connection. It contains a Protocol Version (0x0001 for this version) and an A-bit set to 1 when the sender has already received a PW-RED Connect TLV from the recipient.
The RG Application Data message (type 0x0703) transports application-specific TLVs between PEs in an RG. All Application TLVs in one message MUST belong to a single application but MAY reference different Redundant Objects.
The RG Connect message (type 0x0700) establishes the ICCP RG connection and optionally one Application Connection simultaneously. It carries a mandatory ICC Sender Name TLV (UTF-8 hostname, max 80 octets) and zero or one Application Connect TLV. All implementations MUST support receipt of a message combining RG and single Application Connection setup.
The RG Disconnect message (type 0x0701) carries a Disconnect Code TLV (Type=0x0004) with status 'ICCP RG Removed' or 'ICCP Application Removed from RG'. If status is 'RG Removed', the message MUST NOT contain Application Disconnect TLVs; if 'Application Removed from RG', it MUST contain exactly one Application Disconnect TLV.
The RG Notification message (type 0x0702) rejects ICCP/Application connections or individual messages/TLVs via a NAK TLV (Type=0x0002). It MUST only be sent to a PE already in an RG and MUST contain TLVs for at most one ICCP application per message.
RFC 7275 establishes four IANA registries: Message Type Name Space (LDP message types 0x0700–0x070F allocated for ICCP), TLV Type Name Space (ICC parameter types), ICC RG Parameter Type Space (RG-level parameter types including RG ID type 0x0005), and Status Code Name Space (ICCP status codes including the 0x0001xxxx range defined herein).
ICCP inherits TCP-based security from LDP and requires that connections not be accepted from arbitrary devices and that source address spoofing be prevented. These controls are critical in geo-redundant deployments where RG members communicate over a shared network, where a compromised ICCP session could disrupt client application state machines.
The Application Connection State Machine has six states: NONEXISTENT, RESET, CONNSENT, CONNREC, CONNECTING, and OPERATIONAL. It is triggered by Application Connect/Disconnect TLVs, NAK TLVs, and ICCP connection establishment or teardown; the A-bit in Connect TLVs signals mutual acknowledgment.
The ICCP Connection State Machine has six states: NONEXISTENT, INITIALIZED, CAPSENT, CAPREC, CONNECTING, and OPERATIONAL. Transitions are driven by LDP session establishment/teardown, LDP ICCP capability advertisement and receipt, and RG Connect/Disconnect message exchange; unexpected ICCP messages in pre-OPERATIONAL states trigger a NAK TLV.
ICC Parameters use a TLV encoding with a 1-bit U-bit (if clear and TLV unknown, notification MUST be returned and entire message MUST be ignored; if set, unknown TLV MUST be silently ignored), 1-bit F-bit (controls forwarding of unknown TLVs), 14-bit Type, 16-bit Length, and variable content.
The ICC Header consists of a 1-bit U-bit, 15-bit Message Type (range 0x0700–0x070F), 16-bit Message Length (excluding U-bit/Type/Length), 32-bit Message ID, and a mandatory ICC RG ID TLV (Type=0x0005, Length=4, 32-bit RG ID value; 0x00000000 is reserved), followed by Mandatory and Optional ICC Parameters.
The Redundant Object Identifier (ROID) is encoded as an 8-octet (64-bit) unsigned integer carried within application-specific TLVs. The value 0 is reserved and MUST NOT be used.