Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS
Extracted elements (24)
ICCP (RFC 7275) was chosen as the inter-chassis communication framework for MC-PON because it already provides a generic mechanism for synchronizing state and configuration between a set of PEs, and it only required application-specific TLV extensions rather than a new protocol.
ONU database synchronization (MAC addresses, IP addresses, VLAN identifiers, service configuration) is explicitly out of scope for this document; the document notes it can be handled by management plane policy or other signaling, avoiding over-specification of a complex dependency.
Trunk protection (Type B) was chosen as the target architecture over the more complex Tree protection (Type C) because it is more economical, protecting only the trunk fiber rather than requiring a complete redundant optical distribution network path to every ONU.
Both OLTs and PEs are assumed to operate in the independent mode of PW redundancy as defined in RFC 6870. The remote PE uses the Preferential Forwarding status bit to select the active PW after a switchover.
In the dual-homing PE scenario (Figure 3), PE1 uses the PW-RED State TLV defined in Section 7.1 of RFC 7275 to notify PE2 of faults; PE2 then executes the same protection procedures as described for the single-PE case.
Working PW fault detection is expected to be performed using VCCV BFD (Virtual Circuit Connectivity Verification / Bidirectional Forwarding Detection), which triggers the PW-failure protection procedure on the working OLT.
In the PON Connect TLV, the A bit MUST be set to 1 if the sender has already received a PON Connect TLV from the recipient; otherwise it MUST be set to 0.
In the single-PE scenario, if PE1 loses its connection to the working OLT, it SHOULD send an LDP notification message on the protection PW with the Request Switchover bit set.
The Reserved field in the PON Connect TLV MUST be set to zero.
Upon detecting a fault on the working PON link, the working OLT MUST simultaneously send an ICCP message with the PON State TLV with Local PON Port State set to notify the protection OLT of the fault.
Upon receiving a PON State TLV with Local PON Port State set in the PW-failure scenario, the protection OLT MUST activate its PON interface to the protection trunk fiber and MUST send a notification for the protection PW with Preferential Forwarding active so traffic switches to the protection PW.
Upon receiving an LDP notification with the Request Switchover bit set from the remote PE, the protection OLT MUST activate its optical interface to the protection trunk fiber and activate the associated protection PW.
When a fault is detected on the working PW (e.g., via VCCV BFD), the working OLT SHOULD turn off its associated PON interface and then send an ICCP message with PON State TLV with Local PON Port State set to notify the protection OLT.
The Acknowledgement (A) bit in the PON Connect TLV indicates whether the sender has previously received a PON Connect TLV from the recipient. It enables the two OLTs to confirm bidirectional PON application connectivity within the Redundancy Group.
The Local PON Port State and Remote PON Port State fields in the PON State TLV are each 4 octets. The least-significant bit indicates fault status of the PON port associated with the PW (1=in fault, 0=normal), enabling rapid inter-chassis fault notification.
The System ID field in the PON Configuration TLV is 8 octets encoding the OLT chassis MAC address. When a 6-octet MAC is used, the two least-significant octets are encoded as 0x0000, providing a uniform field width across implementations.
IANA allocated four new values in the 'ICC RG Parameter Types' subregistry under 'Pseudowire Name Spaces (PWE3)': 0x200D (PON Connect TLV), 0x200E (PON Disconnect TLV), 0x200F (PON Configuration TLV), and 0x2010 (PON State TLV).
Because PON optical paths traverse publicly accessible facilities (e.g., telephone poles), a malicious ONU can cause excessive link bouncing, which in turn increases ICCP message exchanges and may result in denial-of-service-like service impairment. Operators must restrict unauthorized ONUs and limit link-bouncing impact at the OLT.
MC-PON ICCP SHOULD only be deployed in well-managed, highly monitored service provider PON access networks within a single administrative domain, including implementation of rogue ONU attachment detection and mitigation via device authentication; the security considerations of RFC 7275 apply.
Protection switchover upon PON link failure: (1) fault detected on working PON link → working OLT deactivates faulty interface and sends LDP fault notification and ICCP PON State TLV; (2) protection OLT receives PON State TLV → activates protection PON link and advertises Preferential Forwarding active on protection PW; (3) remote PE selects protection PW as active forwarding path per RFC 6870.
PON Configuration TLV (Type=0x200F) is sent in the RG Application Data message to announce OLT system parameters. It contains an 8-octet System ID (chassis MAC address, with 6-octet IDs zero-padded to 8 octets), a 2-octet System Priority, and a 2-octet Port ID.
PON Connect TLV (Type=0x200D) is a variable-length TLV included in the RG Connect message. It carries a 2-octet Protocol Version (set to 0x0001), a 1-bit Acknowledgement flag (A bit), a Reserved field, and optional Sub-TLVs. U and F bits are both set to 0.
PON Disconnect TLV (Type=0x200E) is included in the RG Disconnect message to signal termination of the PON application connection. It carries only optional Sub-TLVs beyond the standard TLV header; U and F bits are both 0.
PON State TLV (Type=0x2010) is sent in the RG Application Data message to report PON port states. It contains an 8-octet ROID, a 4-octet Local PON Port State, and a 4-octet Remote PON Port State; the least-significant bit of each state field indicates fault (1=fault, 0=normal).