]> Huawei

Bantian, Longgang district Shenzhen 518129 China jiangyuanlong@huawei.com

Huawei

Bantian, Longgang district Shenzhen 518129 China dennis.luoyong@huawei.com

Charter Communications

4145 S. Falkenburg Road Tampa FL 33578 United States of America edwin.mallette@gmail.com

Juniper Networks

10 Technology Park Drive Westford MA 01886 United States of America yshen@juniper.net

China Mobile

No.32 Xuanwumen West Street Beijing 100053 China chengweiqiang@chinamobile.com

Routing Area Network Working Group PON Protection Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes. Separately, network access nodes such as Passive Optical Network (PON) Optical Line Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multihoming support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-Chassis Communication Protocol (ICCP) extension to support it.

Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks, as is described in the multi-segment pseudowires (PWs) with Passive Optical Network (PON) access use case . Combining MPLS with Optical Line Termination (OLT) access further facilitates a low-cost, multi-service convergence. Tens of millions of Fiber-to-the-x (FTTx) (x = H for home, P for premises, C for curb) lines have been deployed over the years, with many of those lines being some PON variant. PON provides operators a cost-effective solution for delivering high bandwidth (1 Gbps or even 10 Gbps) to a dozen or more subscribers simultaneously. In the past, access technologies such as PON and Digital Subscriber Line (DSL) are usually used for subscribers, and no redundancy is provided in their deployment. But, with the rapid growth of mobile data traffic, more and more Long Term Evolution (LTE) small cells and Wi-Fi hotspots are deployed. PON is considered a viable low-cost backhaul solution for these mobile services. Besides its high bandwidth and scalability, PON further provides frequency and time-synchronization features, e.g., SyncE and IEEE 1588v2 functionality, which can fulfill synchronization needs of mobile backhaul services. The Broadband Forum specifies reference architecture for mobile backhaul networks using MPLS transport in where PON can be the access technology. Unlike typical residential service where a single or handful of end- users hang off a single PON OLT port in a physical optical distribution network, a PON port that supports a dozen LTE small cells or Wi-Fi hotspots could be providing service to hundreds of simultaneous subscribers. Small-cell backhaul often demands the economics of a PON first mile and yet expects first-mile protection commonly available in a point-to-point access portfolio. Some optical layer protection mechanisms, such as Trunk and Tree protection, are specified in to avoid a single point of failure in the access. They are called Type B and Type C protection, respectively, in . Trunk protection architecture is an economical PON resiliency mechanism, where the working OLT and the working link between the working splitter port and the working OLT (i.e., the working trunk fiber) is protected by a redundant protection OLT and a redundant trunk fiber between the protection splitter port and the protection OLT; however, it only protects a portion of the optical path from OLT to Optical Network Units (ONUs). This is different from the more complex and costly Tree protection architecture where there is a working optical distribution network path from the working OLT and a complete protected optical distribution network path from the protection OLT to the ONUs. Figure 1 depicts a typical scenario of Trunk protection.

| | |<--Optical Distribution Network->| | | | branch trunk +-----+ +-----+ fibers fibers | | Base ------| | | | . OLT | Stations ------| ONU |\ | | ,'`| A | ------| | \ V V -` +-----+ +-----+ \ .' . \ +----------+ ,-` +-----+ . \| -` Working Base ------| | . | Optical | Stations ------| ONU |---------| Splitter | ------| | . /| -, Protection +-----+ . / +----------+ `'., / `-, +-----+ +-----+ / `'.,| | Base ------| |/ | OLT | Stations ------| ONU | | B | ------| | +-----+ +-----+ Figure 1: Trunk Protection Architecture in PON

Besides small-cell backhaul, this protection architecture can also be applicable to other services, for example, DSL and Multiple System Operator (MSO) services. In that case, an ONU in Figure 1 can play the similar role as a Digital Subscriber Line Access Multiplexer (DSLAM) or a Data Over Cable Service Interface Specification (DOCSIS) Remote Physical Layer (PHY) device , and it may further be attached with dozens of Customer Premises devices. In some deployments, it is also possible that only some ONUs need to be protected. The PON architecture as depicted in Figure 1 can provide redundancy in its physical topology; however, all traffic, including link Operation Administration and Maintenance (OAM), is blocked on the protection link, which frustrates end-to-end protection mechanisms such as those specified in ITU-T G.8031 . Therefore, some standard signaling mechanisms are needed between OLTs to exchange information, for example, PON link status, registered ONU information, and network status, so that protection and restoration can be done rapidly and reliably, especially when the OLTs also support MPLS. ICCP provides a framework for inter-chassis synchronization of state and configuration data between a set of two or more Provider Edges (PEs). Currently, ICCP only defines application-specific messages for Pseudowire Redundancy (PW-RED) and Multi-Chassis LACP (mLACP), but it can be easily extended to support PON as an Attachment Circuit (AC) redundancy. This document proposes the extension of ICCP to support multi- chassis PON protection in MPLS.

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 .

Digital Subscriber Line Fiber-to-the-x (FTTx) (x = H for home, P for premises, C for curb) Inter-Chassis Communication Protocol Optical Line Termination Optical Network Unit Multiprotocol Label Switching Passive Optical Network Redundancy Group

A set of MC-PON application Type-Length-Values (TLVs) are defined in the following subsections.

This TLV is included in the RG Connect message to signal the establishment of PON application connection.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x200D | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Sub-TLVs | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U and F bits: both are set to 0. Type: set to 0x200D for "PON 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 PON-specific protocol for the purposes of inter-chassis communication. This is set to 0x0001. A bit: Acknowledgement bit. It MUST be set to 1 if the sender has received a PON Connect TLV from the recipient. Otherwise, set to 0. Reserved: reserved for future use and MUST be set to zero. Optional Sub-TLVs: there are no optional Sub-TLVs defined for this version of the protocol. The structure of optional Sub-TLVs is defined 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| Sub-TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U bit: set to 1. The unknown Sub-TLV is silently ignored. F bit: set to 0. The optional Sub-TLV Type values will be allocated by IANA in a registry named "ICC RG Parameter Types" for Pseudowire Name Spaces (PWE3). Length: length of the TLV in octets, excluding the U-bit, F-bit, Type, and Length fields.

This TLV is included in the RG Disconnect message to indicate that the connection for the PON application is 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=0x200E | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U and F bits: both are set to 0. Type: set to 0x200E for "PON Disconnect TLV". Length: length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. Optional Sub-TLVs: there are no optional Sub-TLVs defined for this version of the protocol.

The "PON Configuration TLV" is included in the "RG Application Data" message and announces an OLT's system parameters to other members in the same RG.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x200F | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System ID | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System Priority | Port ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U and F bits: both are set to 0. Type: set to 0x200F for "PON Configuration TLV". Length: length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. System ID: 8 octets encoding the System ID used by the OLT, which is the chassis Media Access Control (MAC) address. If a 6-octet System ID is used, the least significant 2 octets of the 8-octet field will be encoded as 0000. System Priority: a 2-octet value assigned by management or administration policy; the OLT with the numerically lower value of System Priority has the higher priority. Port ID: 2-octet PON Port ID.

The "PON State TLV" is included in the "RG Application Data" message and used by an OLT to report its PON states to other members in the same RG.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type=0x2010 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ROID | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local PON Port State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote PON Port State | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

U and F bits: both are set to 0. Type: set to 0x2010 for "PON State TLV". Length: length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields. ROID: Redundant Object ID (ROID) as defined in Section 4.3 of . Local PON Port State: the status of the local PON port as determined by the sending OLT (PE). The last bit is defined as Fault indication of the PON Port associated with this PW (1 - in fault; 0 - in normal). Remote PON Port State: the status of the remote PON port as determined by the remote peer of the sending OLT (i.e., the sending PE). The last bit is defined as Fault indication of the PON Port associated with this PW (1 - in fault; 0 - in normal).

Without an effective mechanism to communicate the registered ONUs between the working and protection OLT, all registered ONUs would be de-registered and go through re-registration during a switchover, which would significantly increase protection time. To enable faster switchover capability, the working and protection OLTs need to know about the protected ONUs. To enable service continuity, a mechanism needs to be employed such that the operational state and significant configuration data of both the protected ONU and the services provisioned to it can be distributed to the working and protection OLT. The specific ONU's configuration and operational data can be synchronized by some policy mechanism or provisioned in the management plane. Alternatively, said synchronization could occur by some other signaling options. Describing how to synchronize the configuration objects associated with both protected ONU as well as the services constructed to the ONU (e.g., ONU MAC address, IPv4 addresses, IPv6 addresses, VLAN identifiers, etc.) is outside of the scope of this document.

Two typical MPLS protection network architectures for PON access are depicted in Figures 2 and 3 (their PON access segments are the same as in Figure 1 and thus omitted for simplification). OLTs with MPLS functionality are connected to a single PE (Figure 2) or dual-homing PEs (Figure 3), respectively, i.e., the working OLT to PE1 by a working PW and the protection OLT to PE1 or PE2 by a protection PW; thus, these devices constitute an MPLS network that provides PW transport services between ONUs and a Customer Edge (CE), and the PWs can provide protection for each other.

+-----+ | | |OLT -, | A | `., +-----+ ', PW1 `', `., +-----+ +-----+ ', | | | | `. PE1 ------------ CE | .'`| | | | ,-` +-----+ +-----+ .` +-----+ .'` PW2 | | ,-` |OLT -` | B | +-----+ Figure 2: An MPLS Network with a Single PE

+-----+ +-----+ | | PW1 | | |OLT ----------------- PE1 -, | A | | | ', +-----+ +--/--+ ', | `. | `. +-----+ | `' | | | CE | | . | | ,'+-----+ | ,-` +-----+ +--\--+ ,' | | PW2 | | .` |OLT ----------------- PE2 -` | B | | | +-----+ +-----+ Figure 3: An MPLS Network with Dual-Homing PEs

Faults may be encountered in PON access links or in the MPLS network (including the working OLT). Procedures for these cases are described in this section (it is assumed that both OLTs and PEs are working in the independent mode of PW redundancy ).

When a fault is detected on a working PON link, a working OLT switches to the corresponding protection PON link attached with its protection OLT, i.e., the working OLT turns off its faulty PON interface so that the protection trunk link to its protection OLT can be activated. Then, the working OLT MUST send an LDP fault notification message (i.e., with the status bit "Local AC (ingress) Receive Fault" being set) to its peer PE on the remote end of the PW. At the same time, the working OLT MUST send an ICCP message with PON State TLV with Local PON Port State being set to notify the protection OLT of the PON fault. Upon receiving a PON state TLV where Local PON Port State is set, a protection OLT MUST activate the protection PON link in the protection group and advertise a notification message for the protection PW with the Preferential Forwarding status bit of active to the remote PE. According to , the remote PE(s) can match the local and remote Preferential Forwarding status and select PW2 as the new active PW over which data traffic is sent.

Usually, MPLS networks have their own protection mechanism such as Label Switched Path (LSP) protection or Fast Reroute (FRR). But, in a link-sparse access or aggregation network where protection for a PW is impossible in its LSP layer, the following PW layer protection procedures can be enabled. When a fault is detected on its working PW (e.g., by Virtual Circuit Connectivity Verification (VCCV) Bidirectional Forwarding Detection (BFD)), a working OLT SHOULD turn off its associated PON interface and then send an ICCP message with PON State TLV with Local PON Port State being set to notify the protection OLT of the PON fault. Upon receiving a PON state TLV where Local PON Port State is set, the protection OLT MUST activate its PON interface to the protection trunk fiber. At the same time, the protection OLT MUST send a notification message for the protection PW with the Preferential Forwarding status bit of active to the remote PE, so that traffic can be switched to the protection PW.

As depicted in Figure 2, a service is provisioned with a working PW and a protection PW, and both PWs are terminated on PE1. If PE1 lost its connection to the working OLT, it SHOULD send an LDP notification message on the protection PW with the Request Switchover bit set. Upon receiving an LDP notification message from its remote PE with the Request Switchover bit set, a protection OLT MUST activate its optical interface to the protection trunk fiber and activate the associated protection PW, so that traffic can be reliably switched to the protection trunk PON link and the protection PW.

In the case of Figure 3, the PW-RED State TLV as described in Section 7.1 of can be used by PE1 to notify PE2 of the faults in all the scenarios, and PE2 operates the same as described in Sections to of this document.

Similar to ICCP itself, this ICCP application SHOULD only be used in well-managed and highly monitored service provider PON access networks in a single administrative domain, including the implementation of rogue ONU attachment detection and mitigation via device authentication. Thus, many of the security considerations as described in apply here as well. Again, similar to ICCP, activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks. In many passive optical networks, the optical paths between OLT and ONUs traverse publicly accessible facilities including public attachments (e.g., telephone poles), which opens up the risk of excessive link bouncing by optical layer impairment. While ICCP for MC-PON interconnects in the MPLS domain and does not traverse the PON network, risks do include introduction of a malicious ONU that could cause, for example, excessive link bouncing. This link bouncing could result in increased ICCP exchanges similar to the malicious CE case described in . Operators of such networks should take additional care to restrict unauthorized ONUs and to limit the impact of link bouncing at the OLT, as these could result in service impairment.

IANA maintains a top-level registry called "Pseudowire Name Spaces (PWE3)". It has a subregistry called "ICC RG Parameter Types". The following values have been allocated from this subregistry:

0x200D PON Connect TLV 0x200E PON Disconnect TLV 0x200F PON Configuration TLV 0x2010 PON State TLV

&RFC2119; &RFC6870; &RFC7275; International Telecommunications Union International Telecommunications Union International Telecommunications Union IEEE IEEE The Broadband Forum CableLabs &RFC6456;

The authors would like to thank Min Ye, Hongyu Li, Wei Lin, Xifeng Wan, Yannick Legoff, Shrinivas Joshi, Alexey Melnikov, and Stephen Farrell for their valuable discussions and comments.

The following people made significant contributions to this document:

Chengbin Shen China Telecom 1835 South Pudong Road Shanghai 200122, China Email: shencb@sttri.com.cn Guangtao Zhou China Unicom No.9 Shouti South Road Beijing 100048, China Email: zhouguangtao@chinaunicom.cn