[要約] 要約：RFC 8024は、MPLSネットワークでのMulti-Chassis Passive Optical Network（MC-PON）の保護に関するガイドラインを提供しています。 目的：このRFCの目的は、MC-PONネットワークの信頼性と冗長性を向上させるために、MPLSネットワークでの保護メカニズムを定義することです。
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
MPLSのマルチシャーシパッシブ光ネットワーク（MC-PON）保護
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.
マルチプロトコルラベルスイッチング（MPLS）は、ネットワークアクセスノードを含むオペレーターネットワークのエッジにまで拡張されています。これとは別に、パッシブ光ネットワーク（PON）オプティカルラインターミネーション（OLT）などのネットワークアクセスノードは、ファーストマイルアクセス保護をサポートするように進化しており、1つ以上の物理OLTがカスタマーエッジにファーストマイルの多様性を提供します。 MPLS対応のPON OLTでは、提供されるサービスに回復力を提供するために、マルチホーミングのサポートが必要です。このドキュメントでは、MPLSのマルチシャーシPON（MC-PON）保護アーキテクチャについて説明し、それをサポートするためのシャーシ間通信プロトコル（ICCP）拡張も指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8024で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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.
マルチプロトコルラベルスイッチング（MPLS）は、パッシブ光ネットワーク（PON）アクセスのマルチセグメント疑似配線（PW）アクセスの使用例[RFC6456]で説明されているように、オペレーターネットワークのエッジに拡張されています。 MPLSと光回線終端（OLT）アクセスを組み合わせると、低コストのマルチサービスコンバージェンスがさらに容易になります。
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.
何千万ものファイバー・トゥ・ザ・エックス（FTTx）（x =家庭用H、構内用P、縁石用C）ラインが長年にわたって配備されており、これらのラインの多くはPONバリアントです。 PONは、高帯域幅（1 Gbpsまたは10 Gbps）を数十以上の加入者に同時に配信するためのコスト効率の高いソリューションを事業者に提供します。
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.
以前は、加入者には通常、PONやデジタル加入者線（DSL）などのアクセス技術が使用されており、その配備では冗長性が提供されていません。
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.
しかし、モバイルデータトラフィックの急速な成長に伴い、Long Term Evolution（LTE）スモールセルとWi-Fiホットスポットがますます導入されています。 PONは、これらのモバイルサービスの実行可能な低コストバックホールソリューションと見なされています。 PONは、その高い帯域幅とスケーラビリティに加えて、モバイルバックホールサービスの同期ニーズを満たすことができる、周波数および時間同期機能、たとえばSyncE [G.8261]およびIEEE 1588v2 [IEEE-1588]機能も提供します。
The Broadband Forum specifies reference architecture for mobile backhaul networks using MPLS transport in [TR-221] where PON can be the access technology.
ブロードバンドフォーラムは、[TR-221]でMPLSトランスポートを使用するモバイルバックホールネットワークのリファレンスアーキテクチャを規定しています。この場合、PONはアクセステクノロジーになります。
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.
物理的な光配信ネットワークで単一または少数のエンドユーザーが単一のPON OLTポートにぶら下がる一般的な住宅サービスとは異なり、12のLTEスモールセルまたはWi-FiホットスポットをサポートするPONポートは、数百の同時サービスにサービスを提供できます。加入者。スモールセルバックホールは、PONファーストマイルの経済性を要求することがよくありますが、ポイントツーポイントアクセスポートフォリオで一般的に利用可能なファーストマイル保護を期待しています。
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].
トランクやツリー保護などの一部の光レイヤー保護メカニズムは、アクセスの単一障害点を回避するために[IEEE-1904.1]で指定されています。これらは、[G.983.1]ではそれぞれタイプBおよびタイプC保護と呼ばれています。
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.
トランク保護アーキテクチャは経済的なPON復元力メカニズムであり、現用OLTと現用スプリッターポートと現用OLT（つまり現用トランクファイバー）の間の現用リンクは、冗長保護OLTと保護間の冗長トランクファイバーによって保護されます。スプリッターポートと保護OLT。ただし、OLTから光ネットワークユニット（ONU）への光パスの一部のみを保護します。これは、機能しているOLTから機能している光配信ネットワークパスがあり、保護OLTからONUまで完全に保護されている光配信ネットワークパスがある、より複雑でコストのかかるツリー保護アーキテクチャとは異なります。図1は、トランク保護の一般的なシナリオを示しています。
| |
|<--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
図1：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.
スモールセルバックホールに加えて、この保護アーキテクチャは、DSLやマルチシステムオペレーター（MSO）サービスなどの他のサービスにも適用できます。その場合、図1のONUは、デジタル加入者回線アクセスマルチプレクサー（DSLAM）またはデータオーバーケーブルサービスインターフェイス仕様（DOCSIS）リモート物理層（PHY）デバイス[リモートPHY]と同様の役割を果たすことができます。さらに、数十のCustomer Premisesデバイスを接続できます。
In some deployments, it is also possible that only some ONUs need to be protected.
一部の展開では、一部のONUのみを保護する必要がある場合もあります。
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 [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.
図1に示すPONアーキテクチャは、その物理トポロジに冗長性を提供できます。ただし、リンクの運用管理および保守（OAM）を含むすべてのトラフィックは保護リンクでブロックされ、ITU-T G.8031 [G.8031]で指定されているようなエンドツーエンドの保護メカニズムに不満を感じます。したがって、PONリンクステータス、登録されたONU情報、ネットワークステータスなどの情報を交換するために、OLT間でいくつかの標準シグナリングメカニズムが必要です。これにより、特にOLTが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.
ICCP [RFC7275]は、2つ以上のプロバイダーエッジ（PE）のセット間で状態と構成データをシャーシ間で同期するためのフレームワークを提供します。現在、ICCPは、疑似配線冗長（PW-RED）およびマルチシャーシLACP（mLACP）のアプリケーション固有のメッセージのみを定義していますが、アタッチメントサーキット（AC）冗長としてPONをサポートするように簡単に拡張できます。
This document proposes the extension of ICCP to support multi-chassis PON protection in MPLS.
このドキュメントでは、MPLSでマルチシャーシPON保護をサポートするためのICCPの拡張を提案します。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
DSL: Digital Subscriber Line
DSL：デジタル加入者線
FTTx: Fiber-to-the-x (FTTx) (x = H for home, P for premises, C for curb)
FTTx：Fiber-to-the-x（FTTx）（x =家庭用H、構内用P、縁石用C）
ICCP: Inter-Chassis Communication Protocol
ICCP：シャーシ間通信プロトコル
OLT: Optical Line Termination
OLT：光回線終端
ONU: Optical Network Unit
ONU：光ネットワークユニット
MPLS: Multiprotocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
PON: Passive Optical Network
PON：パッシブ光ネットワーク
RG: Redundancy Group
RG：冗長グループ
A set of MC-PON application Type-Length-Values (TLVs) are defined in the following subsections.
MC-PONアプリケーションのType-Length-Value（TLV）のセットは、次のサブセクションで定義されています。
This TLV is included in the RG Connect message to signal the establishment of PON application connection.
このTLVは、RG接続メッセージに含まれており、PONアプリケーション接続の確立を通知します。
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 UおよびFビット：どちらも0に設定されます。
o Type: set to 0x200D for "PON Connect TLV".
o タイプ：「PON Connect TLV」の場合は0x200Dに設定します。
o Length: length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
o 長さ：Uビット、Fビット、タイプ、および長さフィールドを除くオクテット単位のTLVの長さ。
o Protocol Version: the version of this PON-specific protocol for the purposes of inter-chassis communication. This is set to 0x0001.
o Protocol Version：シャーシ間通信を目的としたこのPON固有のプロトコルのバージョン。これは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 ビット：確認ビット。送信者が受信者からPONコネクトTLVを受信した場合は、1に設定する必要があります。それ以外の場合は0に設定します。
o Reserved: reserved for future use and MUST be set to zero.
o 予約済み：今後の使用のために予約されており、ゼロに設定する必要があります。
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:
o オプションのサブTLV：このバージョンのプロトコルには、オプションのサブTLVが定義されていません。オプションのサブ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| Sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o U bit: set to 1. The unknown Sub-TLV is silently ignored.
o Uビット：1に設定します。不明なSub-TLVは通知なく無視されます。
o F bit: set to 0.
o Fビット：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 オプションのサブTLVタイプ値は、疑似配線名前空間（PWE3）の「ICC RGパラメータタイプ」という名前のレジストリでIANAによって割り当てられます。
o Length: length of the TLV in octets, excluding the U-bit, F-bit, Type, and Length fields.
o 長さ：オクテット単位のTLVの長さ（Uビット、Fビット、タイプ、および長さフィールドを除く）。
This TLV is included in the RG Disconnect message to indicate that the connection for the PON application is to be terminated.
このTLVはRG Disconnectメッセージに含まれ、PONアプリケーションの接続が終了することを示します。
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 UおよびFビット：どちらも0に設定されます。
o Type: set to 0x200E for "PON Disconnect TLV".
o タイプ：「PON Disconnect TLV」の場合は0x200Eに設定します。
o Length: length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
o 長さ：Uビット、Fビット、タイプ、および長さフィールドを除くオクテット単位のTLVの長さ。
o Optional Sub-TLVs: there are no optional Sub-TLVs defined for this version of the protocol.
o オプションのサブTLV：このバージョンのプロトコルには、オプションのサブ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.
「PON Configuration TLV」は「RG Application Data」メッセージに含まれており、OLTのシステムパラメーターを同じ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 UおよびFビット：どちらも0に設定されます。
o Type: set to 0x200F for "PON Configuration TLV".
o タイプ：「PON Configuration TLV」の場合は0x200Fに設定します。
o Length: length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
o 長さ：Uビット、Fビット、タイプ、および長さフィールドを除くオクテット単位のTLVの長さ。
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 システムID：シャーシのメディアアクセス制御（MAC）アドレスである、OLTで使用されるシステムIDをエンコードする8オクテット。 6オクテットのシステムIDが使用される場合、8オクテットフィールドの最下位2オクテットは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 システム優先度：管理または管理ポリシーによって割り当てられた2オクテットの値。システムプライオリティの数値が小さいOLTは、プライオリティが高くなります。
o Port ID: 2-octet PON Port ID.
o ポートID：2オクテットのPONポート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.
「PON状態TLV」は「RGアプリケーションデータ」メッセージに含まれており、OLTがそのPON状態を同じ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 UおよびFビット：どちらも0に設定されます。
o Type: set to 0x2010 for "PON State TLV".
o タイプ：「PON State TLV」の場合は0x2010に設定します。
o Length: length of the TLV in octets excluding the U-bit, F-bit, Type, and Length fields.
o 長さ：Uビット、Fビット、タイプ、および長さフィールドを除くオクテット単位のTLVの長さ。
o ROID: Redundant Object ID (ROID) as defined in Section 4.3 of [RFC7275].
o ROID：[RFC7275]のセクション4.3で定義されている冗長オブジェクトID（ROID）。
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 ローカルPONポートの状態：送信OLT（PE）によって決定されるローカルPONポートのステータス。最後のビットは、このPWに関連付けられたPONポートの障害表示として定義されます（1-障害、0-正常）。
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).
o リモートPONポートの状態：送信OLTのリモートピア（つまり、送信PE）によって決定されたリモートPONポートのステータス。最後のビットは、このPWに関連付けられたPONポートの障害表示として定義されます（1-障害、0-正常）。
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.
登録済みONUを現用OLTと保護OLTの間で通信する効果的なメカニズムがないと、登録済みのすべてのONUが登録解除され、スイッチオーバー中に再登録が行われるため、保護時間が大幅に増加します。より高速なスイッチオーバー機能を有効にするには、現用および保護OLTが保護されたONUについて知る必要があります。サービスの継続性を有効にするには、保護されたONUとそれにプロビジョニングされたサービスの両方の運用状態と重要な構成データを稼働中のOLTと保護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.
特定のONUの構成および運用データは、ポリシーメカニズムによって同期するか、管理プレーンでプロビジョニングできます。あるいは、前記同期は、いくつかの他のシグナリングオプションによって発生する可能性がある。保護されたONUに関連付けられた構成オブジェクトと、ONUに構築されたサービス（ONU MACアドレス、IPv4アドレス、IPv6アドレス、VLAN識別子など）の両方を同期する方法については、このドキュメントの範囲外です。
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.
PONアクセスの2つの一般的なMPLS保護ネットワークアーキテクチャを図2および3に示します（これらのPONアクセスセグメントは図1と同じであり、簡略化のために省略されています）。 MPLS機能を備えたOLTは、それぞれ単一のPE（図2）またはデュアルホーミングPE（図3）に接続されます。つまり、現用のPWによって現用のOLTからPE1に、保護用のPWによって保護OLTからPE1またはPE2に接続されます。したがって、これらのデバイスは、ONUとカスタマーエッジ（CE）間のPWトランスポートサービスを提供するMPLSネットワークを構成し、PWは相互に保護を提供できます。
+-----+
| |
|OLT -,
| A | `.,
+-----+ ', PW1
`',
`., +-----+ +-----+
', | | | |
`. PE1 ------------ CE |
.'`| | | |
,-` +-----+ +-----+
.`
+-----+ .'` PW2
| | ,-`
|OLT -`
| B |
+-----+
Figure 2: An MPLS Network with a Single PE
図2：単一のPEを持つMPLSネットワーク
+-----+ +-----+
| | PW1 | |
|OLT ----------------- PE1 -,
| A | | | ',
+-----+ +--/--+ ',
| `.
| `. +-----+
| `' |
| | CE |
| . |
| ,'+-----+
| ,-`
+-----+ +--\--+ ,'
| | PW2 | | .`
|OLT ----------------- PE2 -`
| B | | |
+-----+ +-----+
Figure 3: An MPLS Network with Dual-Homing PEs
図3：デュアルホーミングPEを使用したMPLSネットワーク
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]).
PONアクセスリンクまたはMPLSネットワーク（稼働中のOLTを含む）で障害が発生する可能性があります。このセクションでは、これらのケースの手順について説明します（OLTとPEの両方がPW冗長性の独立モード[RFC6870]で動作していることを前提としています）。
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.
機能しているPONリンクで障害が検出されると、機能しているOLTは、保護OLTが接続されている対応する保護PONリンクに切り替わります。つまり、機能しているOLTは、障害のあるPONインターフェースをオフにして、保護OLTへの保護トランクリンクを活性化。次に、機能しているOLTは、LDP障害通知メッセージ（つまり、ステータスビット「ローカルAC（入力）受信障害」が設定されている）をPWのリモートエンド上のピアPEに送信する必要があります。同時に、現用のOLTは、PONフォルトを保護OLTに通知するように設定されたローカルPONポート状態を持つPON状態TLVを含むICCPメッセージを送信する必要があります。
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.
ローカルPONポート状態が設定されているPON状態TLVを受信すると、保護OLTは、保護グループ内の保護PONリンクをアクティブ化し、優先転送ステータスビットがアクティブの保護PWの通知メッセージをリモート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.
[RFC6870]によれば、リモートPEはローカルとリモートの優先転送ステータスを照合し、データトラフィックが送信される新しいアクティブなPWとしてPW2を選択できます。
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.
通常、MPLSネットワークには、ラベルスイッチドパス（LSP）保護や高速リルート（FRR）などの独自の保護メカニズムがあります。ただし、LSPレイヤーではPWの保護が不可能なリンクスパースアクセスまたは集約ネットワークでは、次のPWレイヤー保護手順を有効にできます。
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.
機能しているPWで障害が検出されると（たとえば、仮想回路接続検証（VCCV）双方向転送検出（BFD）によって）、機能しているOLTは関連するPONインターフェイスをオフにしてから、ローカルのPON状態TLVを含むICCPメッセージを送信する必要がありますPON障害を保護OLTに通知するように設定されているPONポート状態。
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.
ローカルPONポート状態が設定されているPON状態TLVを受信すると、保護OLTは保護トランクファイバーへのPONインターフェイスをアクティブ化する必要があります。同時に、保護OLTは、アクティブな優先転送ステータスビットを含む保護PWの通知メッセージをリモートPEに送信して、トラフィックを保護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.
図2に示すように、サービスは動作中のPWと保護PWでプロビジョニングされ、両方のPWがPE1で終了します。 PE1が動作中のOLTへの接続を失った場合、リクエストスイッチオーバービットが設定された保護PWでLDP通知メッセージを送信する必要があります。
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.
リクエストスイッチオーバービットが設定されたリモートPEからLDP通知メッセージを受信すると、保護OLTは、保護トランクファイバーへの光インターフェイスをアクティブにし、関連する保護PWをアクティブにする必要があります。これにより、トラフィックを確実に保護トランクPONリンクに切り替えることができます。そして保護PW。
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.
図3の場合、[RFC7275]のセクション7.1で説明されているPW-RED状態のTLVをPE1で使用して、すべてのシナリオで障害をPE2に通知でき、PE2はセクション4.1〜4.3で説明されているように動作します。このドキュメントの。
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.
ICCP自体と同様に、このICCPアプリケーションは、デバイス認証による不正なONU添付ファイルの検出と軽減の実装を含め、単一の管理ドメイン内の適切に管理され高度に監視されたサービスプロバイダーのPONアクセスネットワークでのみ使用する必要があります（SHOULD）。したがって、[RFC7275]で説明されているセキュリティの考慮事項の多くは、ここでも適用されます。
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.
ここでも、ICCPと同様に、接続回線でのアクティビティがセキュリティの脅威を引き起こしたり、サービス拒否攻撃を引き起こすために悪用される可能性があります。多くのパッシブ光ネットワークでは、OLTとONUの間の光パスは、パブリックアタッチメント（電柱など）を含む公的にアクセス可能な施設を通過するため、光レイヤーの障害による過度のリンクバウンスのリスクが生じます。 MPLSドメインのMC-PON相互接続用のICCPはPONネットワークを通過しませんが、リスクには、過度のリンクバウンスなどを引き起こす可能性のある悪意のあるONUの導入が含まれます。このリンクバウンスにより、[RFC7275]で説明されている悪意のあるCEのケースと同様にICCP交換が増える可能性があります。このようなネットワークのオペレーターは、許可されていないONUを制限し、OLTでのリンクバウンスの影響を制限するようにさらに注意を払う必要があります。
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:
IANAは、「Pseudowire Name Spaces（PWE3）」と呼ばれるトップレベルのレジストリを維持しています。 「ICC RGパラメータタイプ」と呼ばれるサブレジストリがあります。次の値は、このサブレジストリから割り当てられています。
0x200D PON Connect TLV 0x200E PON Disconnect TLV 0x200F PON Configuration TLV 0x2010 PON State TLV
0x200D PON接続TLV 0x200E PON切断TLV 0x200F PON構成TLV 0x2010 PON状態TLV
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC6870] Muley、P.、Ed。 M. Aissaoui編、「Pseudowire Preferential Forwarding Status Bit」、RFC 6870、DOI 10.17487 / RFC6870、2013年2月、<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>.
[RFC7275] Martini、L.、Salam、S.、Sajassi、A.、Bocci、M.、Matsushima、S。、およびT. Nadeau、「レイヤー2仮想プライベートネットワーク（L2VPN）プロバイダーエッジのシャーシ間通信プロトコル」 （PE）Redundancy」、RFC 7275、DOI 10.17487 / RFC7275、2014年6月、<http://www.rfc-editor.org/info/rfc7275>。
[G.8031] International Telecommunications Union, "Ethernet Linear Protection Switching", ITU-T Recommendation G.8031, January 2015.
[G.8031]国際電気通信連合、「イーサネット線形保護スイッチング」、ITU-T勧告G.8031、2015年1月。
[G.8261] International Telecommunications Union, "Timing and synchronization aspects in packet networks", ITU-T Recommendation G.8261, August 2013.
[G.8261]国際電気通信連合、「パケットネットワークのタイミングと同期の側面」、ITU-T勧告G.8261、2013年8月。
[G.983.1] International Telecommunications Union, "Broadband optical access systems based on Passive Optical Networks (PON)", ITU-T Recommendation G.983.1, January 2005.
[G.983.1]国際電気通信連合、「パッシブ光ネットワーク（PON）に基づくブロードバンド光アクセスシステム」、ITU-T勧告G.983.1、2005年1月。
[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-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、2008年7月。
[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.
[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。
[remote-phy] CableLabs, "Remote PHY Specification", DCN: CM-SP-R-PHY-I05-160923, September 2016.
[remote-phy] CableLabs、「Remote PHY Specification」、DCN：CM-SP-R-PHY-I05-160923、2016年9月。
[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>.
[RFC6456] Li、H.、Zheng、R。、およびA. Farrel、「パッシブ光ネットワークのマルチセグメント疑似配線」、RFC 6456、DOI 10.17487 / RFC6456、2011年11月、<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.
[TR-221]ブロードバンドフォーラム、「モバイルバックホールネットワークにおけるMPLSの技術仕様」、BBF TR-221、2011年10月。
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.
著者は、貴重な議論とコメントをしてくれたMin Ye、Hongyu Li、Wei Lin、Xifeng Wan、Yannick Legoff、Shrinivas Joshi、Alexey Melnikov、Stephen Farrellに感謝します。
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
Chengbin Shen China Telecom 1835 South Pudong Road Shanghai 200122、Chinaメール：shencb@sttri.com.cn
Guangtao Zhou China Unicom No.9 Shouti South Road Beijing 100048, China Email: zhouguangtao@chinaunicom.cn
GUケースG Suite Zhou China u伱com no.9 shout i south road Beijing 100048、China email：周广涛@China u伱com。
Authors' Addresses
著者のアドレス
Yuanlong Jiang (editor) Huawei Bantian, Longgang district Shenzhen 518129 China
人民元Long Jiang（編集者）hu AはBであり、長いGang地区は非常に現実的です518129中国
Email: jiangyuanlong@huawei.com
Yong Luo Huawei Bantian, Longgang district Shenzhen 518129 China
Yong luo hu Aは日によってB、長いギャング地区は非常に現実的です518129中国
Email: dennis.luoyong@huawei.com
Edwin Mallette (editor) Charter Communications 4145 S. Falkenburg Road Tampa, FL 33578 United States of America
Edwin Mallette（編集者）Charter Communications 4145 S. Falkenburg Roadタンパ、フロリダ州33578アメリカ合衆国
Email: edwin.mallette@gmail.com
Yimin Shen Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Yimin Shen Juniper Networks 10 Technology Park Drive Westford、MA 01886アメリカ合衆国
Email: yshen@juniper.net
Weiqiang Cheng China Mobile No.32 Xuanwumen West Street Beijing 100053 China
Wei Qiang Cheng China Mobile no.32 X u Press No Door west street Beijing 100053 China
Email: chengweiqiang@chinamobile.com