doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc8024.txt b/doc/rfc/rfc8024.txt
new file mode 100644
index 0000000..43c5936
--- /dev/null
+++ b/doc/rfc/rfc8024.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     Y. Jiang, Ed.
+Request for Comments: 8024                                        Y. Luo
+Category: Standards Track                                         Huawei
+ISSN: 2070-1721                                         E. Mallette, Ed.
+                                                  Charter Communications
+                                                                 Y. Shen
+                                                        Juniper Networks
+                                                                W. Cheng
+                                                            China Mobile
+                                                           November 2016
+
+
+   Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS
+
+Abstract
+
+   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.
+
+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 has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8024.
+
+
+
+
+
+
+
+
+
+
+
+Jiang, et al.                Standards Track                    [Page 1]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Conventions Used in This Document . . . . . . . . . . . .   5
+     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
+   2.  ICCP Protocol Extensions  . . . . . . . . . . . . . . . . . .   6
+     2.1.  Multi-Chassis PON Application TLVs  . . . . . . . . . . .   6
+       2.1.1.  PON Connect TLV . . . . . . . . . . . . . . . . . . .   6
+       2.1.2.  PON Disconnect TLV  . . . . . . . . . . . . . . . . .   7
+       2.1.3.  PON Configuration TLV . . . . . . . . . . . . . . . .   8
+       2.1.4.  PON State TLV . . . . . . . . . . . . . . . . . . . .   9
+   3.  Considerations on PON ONU Database Synchronization  . . . . .   9
+   4.  Multi-Chassis PON Application Procedures  . . . . . . . . . .  10
+     4.1.  Protection Procedure upon PON Link Failures . . . . . . .  11
+     4.2.  Protection Procedure upon PW Failures . . . . . . . . . .  12
+     4.3.  Protection Procedure upon the Working OLT Failure . . . .  12
+     4.4.  Protection Procedure for a Dual-Homing PE . . . . . . . .  12
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+
+
+
+
+
+
+
+
+
+
+
+Jiang, et al.                Standards Track                    [Page 2]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+1.  Introduction
+
+   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 [RFC6456].
+   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 [G.8261] and IEEE 1588v2 [IEEE-1588] functionality, which can
+   fulfill synchronization needs of mobile backhaul services.
+
+   The Broadband Forum specifies reference architecture for mobile
+   backhaul networks using MPLS transport in [TR-221] 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 [IEEE-1904.1] to avoid a single point of
+   failure in the access.  They are called Type B and Type C protection,
+   respectively, in [G.983.1].
+
+   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
+
+
+
+
+
+Jiang, et al.                Standards Track                    [Page 3]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+   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 [remote-phy], 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
+
+
+
+Jiang, et al.                Standards Track                    [Page 4]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+   protection link, which frustrates end-to-end protection mechanisms
+   such as those specified in ITU-T G.8031 [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 [RFC7275] 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.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+1.2.  Terminology
+
+   DSL:  Digital Subscriber Line
+
+   FTTx: Fiber-to-the-x (FTTx) (x = H for home, P for premises, C for
+         curb)
+
+   ICCP: Inter-Chassis Communication Protocol
+
+   OLT:  Optical Line Termination
+
+   ONU:  Optical Network Unit
+
+   MPLS: Multiprotocol Label Switching
+
+   PON:  Passive Optical Network
+
+   RG:   Redundancy Group
+
+
+
+
+
+
+
+
+
+Jiang, et al.                Standards Track                    [Page 5]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+2.  ICCP Protocol Extensions
+
+2.1.  Multi-Chassis PON Application TLVs
+
+   A set of MC-PON application Type-Length-Values (TLVs) are defined in
+   the following subsections.
+
+2.1.1.  PON Connect TLV
+
+   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                          |
+      ~                                                               ~
+      |                                                               |
+      +                                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             ...                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   o  U and F bits: both are set to 0.
+
+   o  Type: set to 0x200D for "PON Connect TLV".
+
+   o  Length: length of the TLV in octets excluding the U-bit, F-bit,
+      Type, and Length fields.
+
+   o  Protocol Version: the version of this PON-specific protocol for
+      the purposes of inter-chassis communication.  This is set to
+      0x0001.
+
+   o  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.
+
+   o  Reserved: reserved for future use and MUST be set to zero.
+
+
+
+
+
+
+
+
+
+Jiang, et al.                Standards Track                    [Page 6]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+   o  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                    |
+       |                                                               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   o  U bit: set to 1.  The unknown Sub-TLV is silently ignored.
+
+   o  F bit: set to 0.
+
+   o  The optional Sub-TLV Type values will be allocated by IANA in a
+      registry named "ICC RG Parameter Types" for Pseudowire Name Spaces
+      (PWE3).
+
+   o  Length: length of the TLV in octets, excluding the U-bit, F-bit,
+      Type, and Length fields.
+
+2.1.2.  PON Disconnect TLV
+
+   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                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   o  U and F bits: both are set to 0.
+
+   o  Type: set to 0x200E for "PON Disconnect TLV".
+
+   o  Length: length of the TLV in octets excluding the U-bit, F-bit,
+      Type, and Length fields.
+
+   o  Optional Sub-TLVs: there are no optional Sub-TLVs defined for this
+      version of the protocol.
+
+
+
+
+
+Jiang, et al.                Standards Track                    [Page 7]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+2.1.3.  PON Configuration TLV
+
+   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           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   o  U and F bits: both are set to 0.
+
+   o  Type: set to 0x200F for "PON Configuration TLV".
+
+   o  Length: length of the TLV in octets excluding the U-bit, F-bit,
+      Type, and Length fields.
+
+   o  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.
+
+   o  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.
+
+   o  Port ID: 2-octet PON Port ID.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jiang, et al.                Standards Track                    [Page 8]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+2.1.4.  PON State TLV
+
+   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                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   o  U and F bits: both are set to 0.
+
+   o  Type: set to 0x2010 for "PON State TLV".
+
+   o  Length: length of the TLV in octets excluding the U-bit, F-bit,
+      Type, and Length fields.
+
+   o  ROID: Redundant Object ID (ROID) as defined in Section 4.3 of
+      [RFC7275].
+
+   o  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).
+
+   o  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).
+
+3.  Considerations on PON ONU Database Synchronization
+
+   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
+
+
+
+Jiang, et al.                Standards Track                    [Page 9]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+   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.
+
+4.  Multi-Chassis PON Application Procedures
+
+   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
+
+
+
+
+
+
+Jiang, et al.                Standards Track                   [Page 10]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+                     +-----+               +-----+
+                     |     |     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 [RFC6870]).
+
+4.1.  Protection Procedure upon PON Link Failures
+
+   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 [RFC6870], 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.
+
+
+
+
+Jiang, et al.                Standards Track                   [Page 11]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+4.2.  Protection Procedure upon PW Failures
+
+   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.
+
+4.3.  Protection Procedure upon the Working OLT Failure
+
+   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.
+
+4.4.  Protection Procedure for a Dual-Homing PE
+
+   In the case of Figure 3, the PW-RED State TLV as described in
+   Section 7.1 of [RFC7275] can be used by PE1 to notify PE2 of the
+   faults in all the scenarios, and PE2 operates the same as described
+   in Sections 4.1 to 4.3 of this document.
+
+
+
+
+
+
+
+
+
+
+
+Jiang, et al.                Standards Track                   [Page 12]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+5.  Security Considerations
+
+   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 [RFC7275] 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 [RFC7275].  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.
+
+6.  IANA Considerations
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jiang, et al.                Standards Track                   [Page 13]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6870]  Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire
+              Preferential Forwarding Status Bit", RFC 6870,
+              DOI 10.17487/RFC6870, February 2013,
+              <http://www.rfc-editor.org/info/rfc6870>.
+
+   [RFC7275]  Martini, L., Salam, S., Sajassi, A., Bocci, M.,
+              Matsushima, S., and T. Nadeau, "Inter-Chassis
+              Communication Protocol for Layer 2 Virtual Private Network
+              (L2VPN) Provider Edge (PE) Redundancy", RFC 7275,
+              DOI 10.17487/RFC7275, June 2014,
+              <http://www.rfc-editor.org/info/rfc7275>.
+
+7.2.  Informative References
+
+   [G.8031]   International Telecommunications Union, "Ethernet Linear
+              Protection Switching", ITU-T Recommendation G.8031,
+              January 2015.
+
+   [G.8261]   International Telecommunications Union, "Timing and
+              synchronization aspects in packet networks", ITU-T
+              Recommendation G.8261, August 2013.
+
+   [G.983.1]  International Telecommunications Union, "Broadband optical
+              access systems based on Passive Optical Networks (PON)",
+              ITU-T Recommendation G.983.1, January 2005.
+
+   [IEEE-1588]
+              IEEE, "IEEE Standard for a Precision Clock Synchronization
+              Protocol for Networked Measurement and Control Systems",
+              IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July
+              2008.
+
+   [IEEE-1904.1]
+              IEEE, "Standard for Service Interoperability in Ethernet
+              Passive Optical Networks (SIEPON)", IEEE Std 1904.1-2013,
+              DOI 10.1109/IEEESTD.2013.6605490, June 2013.
+
+
+
+
+
+
+Jiang, et al.                Standards Track                   [Page 14]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+   [remote-phy]
+              CableLabs, "Remote PHY Specification", DCN: CM-SP-R-PHY-
+              I05-160923, September 2016.
+
+   [RFC6456]  Li, H., Zheng, R., and A. Farrel, "Multi-Segment
+              Pseudowires in Passive Optical Networks", RFC 6456,
+              DOI 10.17487/RFC6456, November 2011,
+              <http://www.rfc-editor.org/info/rfc6456>.
+
+   [TR-221]   The Broadband Forum, "Technical Specifications for MPLS in
+              Mobile Backhaul Networks", BBF TR-221, October 2011.
+
+Acknowledgements
+
+   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.
+
+Contributors
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jiang, et al.                Standards Track                   [Page 15]
+
+RFC 8024                    MC-PON Protection              November 2016
+
+
+Authors' Addresses
+
+   Yuanlong Jiang (editor)
+   Huawei
+   Bantian, Longgang district
+   Shenzhen  518129
+   China
+
+   Email: jiangyuanlong@huawei.com
+
+
+   Yong Luo
+   Huawei
+   Bantian, Longgang district
+   Shenzhen  518129
+   China
+
+   Email: dennis.luoyong@huawei.com
+
+
+   Edwin Mallette (editor)
+   Charter Communications
+   4145 S. Falkenburg Road
+   Tampa, FL  33578
+   United States of America
+
+   Email: edwin.mallette@gmail.com
+
+
+   Yimin Shen
+   Juniper Networks
+   10 Technology Park Drive
+   Westford, MA  01886
+   United States of America
+
+   Email: yshen@juniper.net
+
+
+   Weiqiang Cheng
+   China Mobile
+   No.32 Xuanwumen West Street
+   Beijing   100053
+   China
+
+   Email: chengweiqiang@chinamobile.com
+
+
+
+
+
+
+Jiang, et al.                Standards Track                   [Page 16]
+