RFC 8185 - Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8185
タイトル : RFC 8185 - MPLSトランスポートプロファイル（MPLS-TP）疑似配線保護のデュアルホーミング調整
翻訳編集 : 自動生成

[要約] RFC 8185は、MPLS-TP疑似ワイヤ保護のためのデュアルホーミング調整に関する規格です。このRFCの目的は、MPLS-TPネットワークでの疑似ワイヤ保護のためのデュアルホーミングの仕組みを提供することです。

Internet Engineering Task Force (IETF)                          W. Cheng
Request for Comments: 8185                                       L. Wang
Category: Standards Track                                          H. Li
ISSN: 2070-1721                                             China Mobile
                                                                 J. Dong
                                                     Huawei Technologies
                                                         A. D'Alessandro
                                                          Telecom Italia
                                                               June 2017

Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection

MPLSトランスポートプロファイル（MPLS-TP）疑似配線保護のデュアルホーミング調整

Abstract

概要

In some scenarios, MPLS Transport Profile (MPLS-TP) pseudowires (PWs) (RFC 5921) may be statically configured when a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the Packet Switched Network (PSN). The framework and typical scenarios of dual-homing PW local protection are described in RFC 8184. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs that is used for state exchange and switchover coordination between the dual-homing PEs for dual-homing PW local protection.

一部のシナリオでは、動的なコントロールプレーンが利用できない場合、MPLSトランスポートプロファイル（MPLS-TP）疑似配線（PW）（RFC 5921）が静的に構成されます。接続回線（AC）の障害、プロバイダーエッジ（PE）の障害、またはパケット交換ネットワーク（PSN）の障害から保護するには、MPLS-TP PWの高速保護メカニズムが必要です。デュアルホーミングPWローカル保護のフレームワークと典型的なシナリオは、RFC 8184で説明されています。このドキュメントでは、デュアルホーミングPE間の状態交換とスイッチオーバー調整に使用されるMPLS-TP PWのデュアルホーミング調整メカニズムを提案します。 PWローカル保護のホーミング。

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/rfc8185.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8185で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents

このドキュメントは、BCP 78およびIETFドキュメントに関連するIETFトラストの法的規定の対象です。

(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.

（http://trustee.ietf.org/license-info）このドキュメントの発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview of the Proposed Solution . . . . . . . . . . . . . .   4
   4.  Protocol Extensions for Dual-Homing MPLS-TP PW Protection . .   5
     4.1.  Information Exchange Between Dual-Homing PEs  . . . . . .   5
     4.2.  Protection Procedures . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction

1. はじめに

[RFC6372], [RFC6378], and [RFC7771] describe the framework and mechanism of MPLS Transport Profile (MPLS-TP) linear protection, which can provide protection for the MPLS Label Switched Path (LSP) and pseudowires (PWs) between the edge nodes. These mechanisms cannot protect against the failure of the Attachment Circuit (AC) or the edge nodes. [RFC6718] and [RFC6870] specify the PW redundancy framework and mechanism for protecting the AC or edge node against failure by adding one or more edge nodes, but it requires PW switchover in case of an AC failure; also, PW redundancy relies on Packet Switched Network (PSN) protection mechanisms to protect against the failure of PW.

[RFC6372]、[RFC6378]、および[RFC7771]は、MPLSラベルスイッチドパス（LSP）およびエッジ間の疑似配線（PW）を保護できるMPLSトランスポートプロファイル（MPLS-TP）線形保護のフレームワークとメカニズムを説明しています。ノード。これらのメカニズムでは、接続回路（AC）またはエッジノードの障害から保護できません。 [RFC6718]と[RFC6870]は、1つ以上のエッジノードを追加してACまたはエッジノードを障害から保護するためのPW冗長フレームワークとメカニズムを指定していますが、AC障害の場合はPWスイッチオーバーが必要です。また、PWの冗長性は、PWの障害から保護するためにパケット交換網（PSN）保護メカニズムに依存しています。

In some scenarios such as mobile backhauling, the MPLS PWs are provisioned with dual-homing topology in which at least the Customer Edge (CE) node on one side is dual-homed to two Provider Edge (PE) nodes. If a failure occurs in the primary AC, operators usually prefer to perform local switchover in the dual-homing PE side and keep the working pseudowire unchanged, if possible. This is to avoid massive PW switchover in the mobile backhaul network due to AC failure in the mobile core site; such massive PW switchover may in turn lead to congestion caused by migrating traffic away from the preferred paths of network planners. Similarly, as multiple PWs share the physical AC in the mobile core site, it is preferable to keep using the working AC when one working PW fails in the PSN to potentially avoid unnecessary switchover for other PWs. To meet the above requirements, a fast dual-homing PW protection mechanism is needed to protect against failure in the AC, the PE node, and the PSN.

モバイルバックホールなどの一部のシナリオでは、MPLS PWは、少なくとも片側のカスタマーエッジ（CE）ノードが2つのプロバイダーエッジ（PE）ノードにデュアルホーム接続されるデュアルホーミングトポロジでプロビジョニングされます。プライマリACで障害が発生した場合、オペレータは通常、デュアルホーミングPE側でローカルスイッチオーバーを実行し、可能であれば、作業中の疑似配線を変更しないようにします。これは、モバイルコアサイトでのAC障害によるモバイルバックホールネットワークでの大規模なPWスイッチオーバーを回避するためです。そのような大規模なPWスイッチオーバーは、ネットワークプランナーの優先パスからトラフィックを移動することによって引き起こされる輻輳につながる可能性があります。同様に、複数のPWがモバイルコアサイトで物理ACを共有しているため、PSNで1つの動作中のPWに障害が発生しても、他のPWの不要なスイッチオーバーを回避するために、動作中のACを使い続けることが望ましいです。上記の要件を満たすには、AC、PEノード、およびPSNの障害から保護するための高速デュアルホーミングPW保護メカニズムが必要です。

[RFC8184] describes a framework and several scenarios of dual-homing PW local protection. This document proposes a dual-homing coordination mechanism for static MPLS-TP PWs; the mechanism is used for information exchange and switchover coordination between the dual-homing PEs for the dual-homing PW local protection. The proposed mechanism has been implemented and deployed in several mobile backhaul networks that use static MPLS-TP PWs for the backhauling of mobile traffic from the radio access sites to the core site.

[RFC8184]は、フレームワークとデュアルホーミングPWローカル保護のいくつかのシナリオについて説明しています。このドキュメントでは、静的MPLS-TP PWのデュアルホーミング調整メカニズムを提案しています。このメカニズムは、デュアルホーミングPWローカル保護のためのデュアルホーミングPE間の情報交換とスイッチオーバー調整に使用されます。提案されているメカニズムは、無線アクセスサイトからコアサイトへのモバイルトラフィックのバックホールに静的MPLS-TP PWを使用するいくつかのモバイルバックホールネットワークに実装および導入されています。

2. Requirements Language

2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Overview of the Proposed Solution

3. 提案されたソリューションの概要

Linear protection mechanisms for the MPLS-TP network are defined in [RFC6378], [RFC7271], and [RFC7324]. When such mechanisms are applied to PW linear protection [RFC7771], both the working PW and the protection PW are terminated on the same PE node. In order to provide dual-homing protection for MPLS-TP PWs, some additional mechanisms are needed.

MPLS-TPネットワークの線形保護メカニズムは、[RFC6378]、[RFC7271]、および[RFC7324]で定義されています。このようなメカニズムがPW線形保護[RFC7771]に適用されると、現用PWと保護PWの両方が同じPEノードで終了します。 MPLS-TP PWにデュアルホーミング保護を提供するには、いくつかの追加メカニズムが必要です。

In MPLS-TP PW dual-homing protection, the linear protection mechanism (as defined in [RFC6378], [RFC7271], and [RFC7324]) on the single-homing PE (e.g., PE3 in Figure 1) is not changed, while on the dual-homing side, the working PW and protection PW are terminated on two dual-homing PEs (e.g., PE1 and PE2 in Figure 1), respectively, to protect against a failure occurring in a PE or a connected AC. As described in [RFC8184], a dedicated Dual-Node Interconnection (DNI) PW is used between the two dual-homing PE nodes to forward the traffic. In order to utilize the linear protection mechanism [RFC7771] in the dual-homing PEs scenario, coordination between the dual-homing PE nodes is needed so that the dual-homing PEs can switch the connection between the AC, the service PW, and the DNI-PW properly in a coordinated fashion by the forwarder.

MPLS-TP PWデュアルホーミング保護では、シングルホーミングPE（たとえば、図1のPE3）の線形保護メカニズム（[RFC6378]、[RFC7271]、および[RFC7324]で定義）は変更されませんが、デュアルホーミング側では、PEまたは接続されたACで発生する障害から保護するために、2つのデュアルホーミングPE（たとえば、図1のPE1とPE2）でそれぞれ現用PWと保護PWが終端されます。 [RFC8184]で説明されているように、トラフィックを転送するために、2つのデュアルホーミングPEノード間で専用のデュアルノード相互接続（DNI）PWが使用されます。デュアルホーミングPEシナリオで線形保護メカニズム[RFC7771]を利用するには、デュアルホーミングPEがAC、サービスPW、およびサービス間の接続を切り替えられるように、デュアルホーミングPEノード間の調整が必要です。フォワーダーによる調整された方法で適切にDNI-PW。

         +----------------------------------+
         |                PE1               |
         +----------------------------------+             +----+
         |                 |                |   Working   |    |
         X    Forwarder    +     Service    X-------------X    |
        /|                 |       PW       | Service PW1 |    |
   AC1 / +--------+--------+                |             |    |
      /  |     DNI-PW      |                |             |    |
 +---*   +--------X--------+----------------+             |    |   +---+
 |   |            ^                                       |    |   |   |
 |CE1|            |  DNI-PW                               |PE3 +---|CE2|
 |   |            |                                       |    |   |   |
 |   |            V                                       |    |   |   |
 +---*   +--------X--------+----------------+             |    |   +---+
      \  |     DNI-PW      |                |             |    |
   AC2 \ +--------+--------+                | Protection  |    |
        \|                 |     Service    X-------------X    |
         X    Forwarder    +       PW       | Service PW2 |    |
         |                 |                |             +----+
         +----------------------------------+
         |                PE2               |
         +----------------------------------+

Figure 1: Dual-Homing Protection with DNI-PW

図1：DNI-PWによるデュアルホーミング保護

4. Protocol Extensions for Dual-Homing MPLS-TP PW Protection

4. デュアルホーミングMPLS-TP PW保護のプロトコル拡張

In dual-homing MPLS-TP PW local protection, the forwarding states of the dual-homing PEs are determined by the forwarding state machine in Table 1.

デュアルホーミングMPLS-TP PWローカル保護では、デュアルホーミングPEの転送状態は、表1の転送状態マシンによって決定されます。

          +-----------+---------+--------+---------------------+
          |Service PW |   AC    | DNI-PW | Forwarding Behavior |
          +-----------+---------+--------+---------------------+
          |  Active   | Active  |   Up   |Service PW <-> AC    |
          +-----------+---------+--------+---------------------+
          |  Active   | Standby |   Up   |Service PW <-> DNI-PW|
          +-----------+---------+--------+---------------------+
          |  Standby  | Active  |   Up   |    DNI-PW <-> AC    |
          +-----------+---------+--------+---------------------+
          |  Standby  | Standby |   Up   |  Drop all packets   |
          +-----------+---------+--------+---------------------+
          |  Active   | Active  |  Down  |Service PW <-> AC    |
          +-----------+---------+--------+---------------------+
          |  Active   | Standby |  Down  |  Drop all packets   |
          +-----------+---------+--------+---------------------+
          |  Standby  | Active  |  Down  |  Drop all packets   |
          +-----------+---------+--------+---------------------+
          |  Standby  | Standby |  Down  |  Drop all packets   |
          +-----------+---------+--------+---------------------+

Table 1: Dual-Homing PE Forwarding State Machine

表1：デュアルホーミングPEフォワーディングステートマシン

In order to achieve dual-homing MPLS-TP PW protection, coordination between the dual-homing PE nodes is needed to exchange the PW status and protection coordination requests.

デュアルホーミングMPLS-TP PW保護を実現するには、PWステータスと保護調整要求を交換するために、デュアルホーミングPEノード間の調整が必要です。

4.1. Information Exchange Between Dual-Homing PEs

4.1. デュアルホーミングPE間の情報交換

The coordination information will be sent on the DNI-PW over the Generic Associated Channel (G-ACh) as described in [RFC5586]. A new G-ACh channel type is defined for the dual-homing coordination between the dual-homing PEs of MPLS-TP PWs. This channel type can be used for the exchange of different types of information between the dual-homing PEs. This document uses this channel type for the exchange of PW status and switchover coordination between the dual-homing PEs. Other potential usages of this channel type are for further study and are out of the scope of this document.

[RFC5586]で説明されているように、調整情報はGeneric Associated Channel（G-ACh）を介してDNI-PWで送信されます。 MPLS-TP PWのデュアルホーミングPE間のデュアルホーミング調整用に、新しいG-AChチャネルタイプが定義されています。このチャネルタイプは、デュアルホーミングPE間の異なるタイプの情報の交換に使用できます。このドキュメントでは、デュアルホーミングPE間のPWステータスおよびスイッチオーバー調整の交換にこのチャネルタイプを使用します。このチャネルタイプの他の潜在的な使用法は、今後の調査のためであり、このドキュメントの範囲外です。

The MPLS-TP Dual-Homing Coordination (DHC) message is sent on the DNI-PW between the dual-homing PEs. The format of the MPLS-TP DHC message is shown below:

MPLS-TPデュアルホーミング調整（DHC）メッセージは、デュアルホーミングPE間のDNI-PWで送信されます。 MPLS-TP DHCメッセージのフォーマットを以下に示します。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Version|   Reserved    |         DHC Channel Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Dual-Homing PEs Group ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         TLV  Length           |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                              TLVs                             ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: MPLS-TP Dual-Homing Coordination Message

図2：MPLS-TPデュアルホーミング調整メッセージ

The first 4 octets is the common G-ACh header as specified in [RFC5586]. The DHC Channel Type is the G-ACh channel type code point assigned by IANA (0x0009).

最初の4オクテットは、[RFC5586]で指定されている一般的なG-AChヘッダーです。 DHCチャネルタイプは、IANAによって割り当てられたG-AChチャネルタイプコードポイントです（0x0009）。

The Dual-Homing Group ID is a 4-octet unsigned integer to identify the dual-homing group to which the dual-homing PEs belong. It MUST be the same at both PEs in the same group.

デュアルホーミンググループIDは、デュアルホーミングPEが属するデュアルホーミンググループを識別するための4オクテットの符号なし整数です。同じグループ内の両方のPEで同じでなければなりません。

The TLV Length field specifies the total length in octets of the subsequent TLVs.

TLV長さフィールドは、後続のTLVの合計長さをオクテットで指定します。

In this document, two TLVs are defined in the MPLS-TP Dual-Homing Coordination message for dual-homing MPLS-TP PW protection:

このドキュメントでは、2つのTLVがMPLS-TPデュアルホーミング調整メッセージで定義されており、デュアルホーミングMPLS-TP PW保護用です。

Type Description Length 1 PW Status 20 bytes 2 Dual-Node Switching 16 bytes

タイプ説明長さ1 PWステータス20バイト2デュアルノードスイッチング16バイト

The PW Status TLV is used by a dual-homing PE to report its service PW status to the other dual-homing PE in the same dual-homing group.

PWステータスTLVは、デュアルホーミングPEがそのサービスPWステータスを同じデュアルホーミンググループ内の他のデュアルホーミングPEに報告するために使用します。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type=1 (PW Status)         |          Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Destination Dual-Homing PE Node_ID               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Source Dual-Homing PE Node_ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         DNI-PW ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Flags                               |P|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Service PW Status                    |D|F|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: PW Status TLV

図3：PWステータスTLV

The Length field specifies the length in octets of the value field of the TLV.

長さフィールドは、TLVの値フィールドの長さをオクテットで指定します。

The Destination Dual-Homing PE Node_ID is the 32-bit identifier of the receiver PE [RFC6370], which supports both IPv4 and IPv6 environments. Usually it is the same as the Label Switching Router ID (LSR ID) of the receiver PE.

Destination Dual-Homing PE Node_IDは、IPv4とIPv6の両方の環境をサポートする受信側PE [RFC6370]の32ビットの識別子です。通常、これは受信側PEのラベルスイッチングルータID（LSR ID）と同じです。

The Source Dual-Homing PE Node_ID is the 32-bit identifier of the sending PE [RFC6370], which supports both IPv4 and IPv6 environments. Usually it is the same as the LSR ID of the sending PE.

Source Dual-Homing PE Node_IDは、送信PE [RFC6370]の32ビットの識別子であり、IPv4とIPv6の両方の環境をサポートしています。通常、これは送信側PEのLSR IDと同じです。

The DNI-PW ID field contains the 32-bit PW ID [RFC8077] of the DNI-PW.

DNI-PW IDフィールドには、DNI-PWの32ビットPW ID [RFC8077]が含まれています。

The Flags field contains 32-bit flags, in which:

Flagsフィールドには、32ビットのフラグが含まれています。

o The P (Protection) bit indicates whether the Source Dual-Homing PE is the working PE (P=0) or the protection PE (P=1).

o P（保護）ビットは、ソースデュアルホーミングPEが現用PE（P = 0）であるか、保護PE（P = 1）であるかを示します。

o Other bits are reserved for future use, which MUST be set to 0 on transmission and MUST be ignored upon receipt.

o 他のビットは将来の使用のために予約されており、送信時に0に設定する必要があり、受信時に無視する必要があります。

The Service PW Status field indicates the status of the service PW between the sending PE and the remote PE. Currently, two bits are defined in the Service PW Status field:

Service PW Statusフィールドは、送信側PEとリモートPE間のサービスPWのステータスを示します。現在、2つのビットがService PW Statusフィールドで定義されています。

o F bit: If set, it indicates Signal Fail (SF) [RFC6378] on the service PW. It can be either a local request generated by the PE itself or a remote request received from the remote PE.

o Fビット：設定されている場合、サービスPWでシグナル障害（SF）[RFC6378]を示します。これは、PE自体によって生成されたローカル要求、またはリモートPEから受信したリモート要求のいずれかです。

o D bit: If set, it indicates Signal Degrade (SD) [RFC6378] on the service PW. It can be either a local request or a remote request received from the remote PE.

o Dビット：設定されている場合、サービスPWの信号劣化（SD）[RFC6378]を示します。ローカル要求またはリモートPEから受信したリモート要求のいずれかになります。

o Other bits are reserved for future use, which MUST be set to 0 on transmission and MUST be ignored upon receipt.

o 他のビットは将来の使用のために予約されており、送信時に0に設定する必要があり、受信時に無視する必要があります。

The Dual-Node Switching TLV is used by one dual-homing PE to send protection state coordination to the other PE in the same dual-homing group.

デュアルノードスイッチングTLVは、1つのデュアルホーミングPEによって使用され、同じデュアルホーミンググループ内の他のPEに保護状態の調整を送信します。

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type=2 (Dual-Node Switching) |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Destination Dual-Homing PE Node_ID               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Source Dual-Homing PE Node_ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         DNI-PW ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Flags                            |S|P|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Dual-Node Switching TLV

図4：デュアルノードスイッチングTLV

The Length field specifies the length in octets of the value field of the TLV.

長さフィールドは、TLVの値フィールドの長さをオクテットで指定します。

The Destination Dual-Homing PE Node_ID is the 32-bit identifier of the receiver PE [RFC6370]. Usually it is the same as the LSR ID of the receiver PE.

Destination Dual-Homing PE Node_IDは、受信側PE [RFC6370]の32ビットの識別子です。通常、これは受信側PEのLSR IDと同じです。

The Source Dual-Homing PE Node_ID is the 32-bit identifier of the sending PE [RFC6370]. Usually it is the same as the LSR ID of the sending PE.

Source Dual-Homing PE Node_IDは、送信側PE [RFC6370]の32ビットの識別子です。通常、これは送信側PEのLSR IDと同じです。

The DNI-PW ID field contains the 32-bit PW-ID [RFC8077] of the DNI-PW.

DNI-PW IDフィールドには、DNI-PWの32ビットPW-ID [RFC8077]が含まれています。

The Flags field contains 32-bit flags, in which:

Flagsフィールドには、32ビットのフラグが含まれています。

o The P (Protection) bit indicates whether the Source Dual-Homing PE is the working PE (P=0) or the protection PE (P=1).

o P（保護）ビットは、ソースデュアルホーミングPEが現用PE（P = 0）であるか、保護PE（P = 1）であるかを示します。

o The S (PW Switching) bit indicates which service PW is used for forwarding traffic. It is set to 0 when traffic will be transported on the working PW, and it is set to 1 if traffic will be transported on the protection PW. The value of the S bit is determined by the protection coordination mechanism between the dual-homing PEs and the remote PE.

o S（PWスイッチング）ビットは、トラフィックの転送に使用されるサービスPWを示します。トラフィックが現用PWで転送される場合は0に設定され、保護PWで転送される場合は1に設定されます。 Sビットの値は、デュアルホーミングPEとリモートPE間の保護調整メカニズムによって決定されます。

o Other bits are reserved for future use, which MUST be set to 0 on transmission and MUST be ignored upon receipt.

o 他のビットは将来の使用のために予約されており、送信時に0に設定する必要があり、受信時に無視する必要があります。

When a change of service PW status is detected by one of the dual-homing PEs, it MUST be reflected in the PW Status TLV and sent to the other dual-homing PE as quickly as possible to allow for fast protection switching using three consecutive DHC messages. This set of three messages allows for fast protection switching even if one or two of these packets are lost or corrupted. After the transmission of the three rapid messages, the dual-homing PE MUST send the most recently transmitted service PW status periodically to the other dual-homing PE on a continual basis using the DHC message.

デュアルホーミングPEの1つによってサービスPWステータスの変更が検出された場合、PWステータスTLVに反映され、他のデュアルホーミングPEにできるだけ早く送信して、3つの連続したDHCを使用した高速保護スイッチングを可能にする必要があります。メッセージ。この3つのメッセージのセットにより、これらのパケットの1つまたは2つが失われたり破損したりした場合でも、高速保護切り替えが可能になります。 3つの高速メッセージの送信後、デュアルホーミングPEは、DHCメッセージを使用して、最後に送信されたサービスPWステータスを継続的に他のデュアルホーミングPEに定期的に送信する必要があります。

When one dual-homing PE determines that the active service PW needs to be switched from the working PW to the protection PW, it MUST send the Dual-Node Switching TLV to the other dual-homing PE as quickly as possible to allow for fast protection switching using three consecutive DHC messages. After the transmission of the three messages, the protection PW would become the active service PW, and the dual-homing PE MUST send the most recently transmitted Dual-Node Switching TLV periodically to the other dual-homing PE on a continual basis using the DHC message.

1つのデュアルホーミングPEが、アクティブサービスPWを現用PWから保護PWに切り替える必要があると判断した場合、高速保護を可能にするために、デュアルノードスイッチングTLVを他のデュアルホーミングPEにできるだけ早く送信する必要があります。 3つの連続したDHCメッセージを使用した切り替え。 3つのメッセージの送信後、保護PWはアクティブサービスPWになり、デュアルホーミングPEは、DHCを使用して、最後に送信されたデュアルノードスイッチングTLVを継続的に他のデュアルホーミングPEに定期的に送信する必要があります。メッセージ。

It is RECOMMENDED that the default interval of the first three rapid DHC messages be 3.3 ms, similar to [RFC6378], and the default interval of the subsequent messages is 1 second. Both the default interval of the three consecutive messages as well as the default interval of the periodic messages SHALL be configurable by the operator.

[RFC6378]と同様に、最初の3つの高速DHCメッセージのデフォルトの間隔は3.3 msであり、後続のメッセージのデフォルトの間隔は1秒であることが推奨されます。 3つの連続するメッセージのデフォルトの間隔と定期的なメッセージのデフォルトの間隔の両方が、オペレーターによって設定可能である必要があります。

4.2. Protection Procedures

4.2. 保護手順

The dual-homing MPLS-TP PW protection mechanism can be deployed with the existing AC redundancy mechanisms. On the PSN side, a PSN tunnel protection mechanism is not required, as the dual-homing PW protection can also protect if a failure occurs in the PSN.

デュアルホーミングMPLS-TP PW保護メカニズムは、既存のAC冗長性メカニズムとともに展開できます。 PSN側では、PSNで障害が発生した場合にデュアルホーミングPW保護も保護できるため、PSNトンネル保護メカニズムは不要です。

This section uses the one-side dual-homing scenario as an example to describe the dual-homing PW protection procedures; the procedures for a two-side dual-homing scenario would be similar.

このセクションでは、片側デュアルホーミングシナリオを例として使用して、デュアルホーミングPW保護手順を説明します。両側デュアルホーミングシナリオの手順も同様です。

On the dual-homing PE side, the role of working and protection PE are set by the management system or local configuration. The service PW connecting to the working PE is the working PW, and the service PW connecting to the protection PE is called the protection PW.

デュアルホーミングPE側では、動作中のPEおよび保護PEの役割は、管理システムまたはローカル構成によって設定されます。稼働中のPEに接続するサービスPWは稼働中のPWであり、保護PEに接続するサービスPWは保護PWと呼ばれます。

On the single-homing PE side, it treats the working PW and protection PW as if they terminate on the same remote PE node, thus normal MPLS-TP protection coordination procedures still apply on the single-homing PE.

シングルホーミングPE側では、ワーキングPWと保護PWが同じリモートPEノードで終端するかのように処理されるため、通常のMPLS-TP保護調整手順がシングルホーミングPEにも適用されます。

The forwarding behavior of the dual-homing PEs is determined by the components shown in the figure below:

デュアルホーミングPEの転送動作は、次の図に示すコンポーネントによって決まります。

             +---------------------------------+          +-----+
             |        PE1 (Working PE)         |          |     |
             +---------------------------------+    PW1   |     |
             |                 |               |  Working |     |
             +    Forwarder    +    Service    X<-------->X     |
            /|                 |      PW       |          |     |
           / +--------+--------+               |          |     |
     AC1  /  |     DNI-PW      |               |          |     |
         /   +--------X--------+---------------+          |     |
 +-----+/   AC        ^    DNI-PW                         |     |  +---+
 | CE1 |redundancy    |                                   | PE3 +--|CE2|
 +-----+ mechanism    |  DHC message                      |     |  +---+
        \             V   exchange                        |     |
     AC2 \   +--------X--------+---------------+          |     |
          \  |     DNI-PW      |               |          |     |
           \ +--------+--------+               |    PW2   |     |
            \|                 |     Service   |Protection|     |
             +    Forwarder    +       PW      X<-------->X     |
             |                 |               |   PSC    |     |
             +---------------------------------+  message |     |
             |        PE2 (Protection PE)      | exchange |     |
             +---------------------------------+          +-----+

Figure 5: Components of One-Side Dual-Homing PW Protection

図5：片側デュアルホーミングPW保護のコンポーネント

In Figure 5, for each dual-homing PE, the service PW is the PW used to carry service between the dual-homing PE and the remote PE. The state of the service PW is determined by the Operation, Administration, and Maintenance (OAM) mechanisms between the dual-homing PEs and the remote PE.

図5では、各デュアルホーミングPEのサービスPWは、デュアルホーミングPEとリモートPEの間でサービスを伝送するために使用されるPWです。サービスPWの状態は、デュアルホーミングPEとリモートPE間の運用、管理、および保守（OAM）メカニズムによって決定されます。

The DNI-PW is provisioned between the two dual-homing PE nodes. It is used to bridge traffic when a failure occurs in the PSN or in the ACs. The state of the DNI-PW is determined by the OAM mechanism between the dual-homing PEs. Since the DNI-PW is used to carry both the DHC messages and the service traffic during protection switching, it is important to ensure the robustness of the DNI-PW. In order to avoid the DNI-PW failure due to the failure of a particular link, it is RECOMMENDED that multiple diverse links be deployed between the dual-homing PEs and the underlying Label Switched Path (LSP) protection mechanism SHOULD be enabled.

DNI-PWは、2つのデュアルホーミングPEノード間にプロビジョニングされます。これは、PSNまたはACで障害が発生したときにトラフィックをブリッジするために使用されます。 DNI-PWの状態は、デュアルホーミングPE間のOAMメカニズムによって決定されます。 DNI-PWは、保護切り替え時にDHCメッセージとサービストラフィックの両方を伝送するために使用されるため、DNI-PWの堅牢性を確保することが重要です。特定のリンクの障害によるDNI-PW障害を回避するために、デュアルホーミングPEと基になるラベルスイッチドパス（LSP）保護メカニズムの間に複数の多様なリンクを配置することを推奨します。

The AC is the link that connects a dual-homing PE to the dual-homed CE. The status of AC is determined by the existing AC redundancy mechanisms; this is out of the scope of this document.

ACは、デュアルホーミングPEをデュアルホームCEに接続するリンクです。 ACのステータスは、既存のAC冗長メカニズムによって決定されます。これはこのドキュメントの範囲外です。

In order to perform dual-homing PW local protection, the service PW status and Dual-Node Switching coordination requests are exchanged between the dual-homing PEs using the DHC message defined in Section 4.1.

デュアルホーミングPWローカル保護を実行するために、サービスPWステータスとデュアルノードスイッチング調整要求は、セクション4.1で定義されたDHCメッセージを使用して、デュアルホーミングPE間で交換されます。

Whenever a change of service PW status is detected by a dual-homing PE, it MUST be reflected in the PW Status TLV and sent to the other dual-homing PE immediately using the three consecutive DHC messages. After the transmission of the three rapid messages, the dual-homing PE MUST send the most recently transmitted service PW status periodically to the other dual-homing PE on a continual basis using the DHC message. This way, both dual-homing PEs have the status of the working and protection PW consistently.

デュアルホーミングPEによってサービスPWステータスの変更が検出されると、それは常にPWステータスTLVに反映され、3つの連続したDHCメッセージを使用して他のデュアルホーミングPEにすぐに送信される必要があります。 3つの高速メッセージの送信後、デュアルホーミングPEは、DHCメッセージを使用して、最後に送信されたサービスPWステータスを継続的に他のデュアルホーミングPEに定期的に送信する必要があります。このようにして、両方のデュアルホーミングPEは、動作しているPWと保護PWのステータスを一貫して持っています。

When there is a switchover request either generated locally or received on the protection PW from the remote PE, based on the status of the working and protection service PW along with the local and remote request of the protection coordination between the dual-homing PEs and the remote PE, the active/standby state of the service PW can be determined by the dual-homing PEs. As the remote protection coordination request is transmitted over the protection path, in this case the active/standby status of the service PW is determined by the protection PE in the dual-homing group.

ローカルで生成された、またはリモートPEから保護PWで受信された切り替え要求がある場合、デュアルホーミングPEとリモートPEの場合、サービスPWのアクティブ/スタンバイ状態は、デュアルホーミングPEによって決定できます。リモート保護調整要求は保護パスを介して送信されるため、この場合、サービスPWのアクティブ/スタンバイステータスは、デュアルホーミンググループ内の保護PEによって決定されます。

If it is determined on one dual-homing PE that switchover of the service PW is needed, this dual-homing PE MUST set the S bit in the Dual-Node Switching TLV and send it to the other dual-homing PE immediately using the three consecutive DHC messages. With the exchange of service PW status and the switching request, both dual-homing PEs are consistent on the active/standby forwarding status of the working and protection service PWs. The status of the DNI-PW is determined by PW OAM mechanism as defined in [RFC5085], and the status of ACs is determined by existing AC redundancy mechanisms: both are out of the scope of this document. The forwarding behavior on the dual-homing PE nodes is determined by the forwarding state machine as shown in Table 1.

1つのデュアルホーミングPEでサービスPWのスイッチオーバーが必要であると判断された場合、このデュアルホーミングPEは、デュアルノードスイッチングTLVのSビットを設定し、3つを使用してそれを他のデュアルホーミングPEに直ちに送信する必要があります。連続したDHCメッセージ。サービスPWステータスとスイッチング要求の交換により、両方のデュアルホーミングPEは、現用および保護サービスPWのアクティブ/スタンバイ転送ステータスで一貫しています。 DNI-PWのステータスは[RFC5085]で定義されているPW OAMメカニズムによって決定され、ACのステータスは既存のAC冗長メカニズムによって決定されます。どちらもこのドキュメントの範囲外です。デュアルホーミングPEノードの転送動作は、表1に示すように、転送ステートマシンによって決定されます。

Using the topology in Figure 5 as an example, in normal state, the working PW (PW1) is in active state, the protection PW (PW2) is in standby state, the DNI-PW is up, and AC1 is in active state according to the AC redundancy mechanism. According to the forwarding state machine in Table 1, traffic will be forwarded through the working PW (PW1) and the primary AC (AC1). No traffic will go through the protection PE (PE2) or the DNI-PW, as both the protection PW (PW2) and the AC connecting to PE2 are in standby state.

例として図5のトポロジを使用すると、通常の状態では、動作しているPW（PW1）がアクティブ状態になり、保護PW（PW2）はスタンバイ状態になり、DNI-PWが起動し、AC1がアクティブ状態になります。 AC冗長メカニズムに。表1のフォワーディングステートマシンによれば、トラフィックは、機能しているPW（PW1）とプライマリAC（AC1）を介して転送されます。保護PW（PW2）とPE2に接続しているACの両方がスタンバイ状態であるため、トラフィックは保護PE（PE2）またはDNI-PWを通過しません。

If a failure occurs in AC1, the state of AC2 changes to active according to the AC redundancy mechanism, while there is no change in the state of the working and protection PWs. According to the forwarding state machine in Table 1, PE1 starts to forward traffic between the working PW and the DNI-PW, and PE2 starts to forward traffic between AC2 and the DNI-PW. It should be noted that in this case only AC switchover takes place; in the PSN, traffic is still forwarded using the working PW.

AC1で障害が発生すると、AC冗長メカニズムに従ってAC2の状態がアクティブに変わりますが、稼働中のPWと保護PWの状態は変化しません。表1のフォワーディングステートマシンによれば、PE1は現用PWとDNI-PW間のトラフィックの転送を開始し、PE2はAC2とDNI-PW間のトラフィックの転送を開始します。この場合、ACスイッチオーバーのみが発生することに注意してください。 PSNでは、トラフィックは引き続き現用PWを使用して転送されます。

If a failure in the PSN brings PW1 down, the failure can be detected by PE1 or PE3 using existing OAM mechanisms. If PE1 detects the failure of PW1, it MUST inform PE2 of the state of the working PW using the PW Status TLV in the DHC messages and change the forwarding status of PW1 to standby. On receipt of the DHC message, PE2 SHOULD change the forwarding status of PW2 to active. Then, according to the forwarding state machine in Table 1, PE1 SHOULD set up the connection between the DNI-PW and AC1, and PE2 SHOULD set up the connection between PW2 and the DNI-PW. According to the linear protection mechanism [RFC6378], PE2 also sends an appropriate protection coordination message [RFC6378] over the protection PW (PW2) to PE3 for the remote side to switchover from PW1 to PW2. If PE3 detects the failure of PW1, according to the linear protection mechanism [RFC6378], it sends a protection coordination message on the protection PW (PW2) to inform PE2 of the failure on the working PW. Upon receipt of the message, PE2 SHOULD change the forwarding status of PW2 to active and set up the connection according to the forwarding state machine in Table 1. PE2 SHOULD send a DHC message to PE1 with the S bit set in the Dual-Node Switching TLV to coordinate the switchover on PE1 and PE2. This is useful for a unidirectional failure that cannot be detected by PE1.

PSNの障害によりPW1がダウンした場合、既存のOAMメカニズムを使用してPE1またはPE3で障害を検出できます。 PE1がPW1の障害を検出した場合、DHCメッセージのPWステータスTLVを使用して、動作しているPWの状態をPE2に通知し、PW1の転送ステータスをスタンバイに変更する必要があります。 DHCメッセージを受信すると、PE2はPW2の転送ステータスをアクティブに変更する必要があります（SHOULD）。次に、表1のフォワーディングステートマシンに従って、PE1はDNI-PWとAC1間の接続を設定する必要があり（SHOULD）、PE2はPW2とDNI-PW間の接続を設定する必要があります（SHOULD）。線形保護メカニズム[RFC6378]によると、リモート側がPW1からPW2に切り替えるために、PE2は適切な保護調整メッセージ[RFC6378]を保護PW（PW2）経由でPE3に送信します。 PE3がPW1の障害を検出すると、線形保護メカニズム[RFC6378]に従って、保護PW（PW2）で保護調整メッセージを送信して、稼働中のPWでの障害をPE2に通知します。メッセージを受信すると、PE2 SHOULDはPW2の転送ステータスをアクティブに変更し、表1の転送ステートマシンに従って接続を設定します。PE2SHOULDは、デュアルノードスイッチングで設定されたSビットを使用してDHCメッセージをPE1に送信する必要があります（SHOULD）。 PE1およびPE2のスイッチオーバーを調整するTLV。これは、PE1で検出できない単一方向の障害に役立ちます。

If a failure brings the working PE (PE1) down, the failure can be detected by both PE2 and PE3 using existing OAM mechanisms. Both PE2 and PE3 SHOULD change the forwarding status of PW2 to active and send a protection coordination message [RFC6378] on the protection PW (PW2) to inform the remote side to switchover. According to the existing AC redundancy mechanisms, the status of AC1 changes to standby and the state of AC2 changes to active. According to the forwarding state machine in Table 1, PE2 starts to forward traffic between the PW2 and AC2.

障害によって稼働中のPE（PE1）がダウンした場合、既存のOAMメカニズムを使用して、PE2とPE3の両方で障害を検出できます。 PE2とPE3の両方は、PW2の転送ステータスをアクティブに変更し、保護PW（PW2）で保護調整メッセージ[RFC6378]を送信して、リモート側にスイッチオーバーを通知する必要があります。既存のAC冗長性メカニズムに従って、AC1のステータスはスタンバイに変わり、AC2の状態はアクティブに変わります。表1のフォワーディングステートマシンによれば、PE2はPW2とAC2間のトラフィックの転送を開始します。

5. IANA Considerations

5. IANAに関する考慮事項

IANA has assigned a new channel type for the "MPLS-TP Dual-Homing Coordination Message" from the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" subregistry within the "Generic Associated Channel (G-ACh) Parameters" registry.

IANAは、「一般的な関連付けられたチャネル（G- ACh）パラメータ」レジストリ。

Value Description Reference 0x0009 MPLS-TP Dual-Homing Coordination message RFC 8185

値説明参照0x0009 MPLS-TPデュアルホーミング調整メッセージRFC 8185

IANA has created a new subregistry called "MPLS-TP DHC TLVs" within the "Generic Associated Channel (G-ACh) Parameters" registry. The registry has the following fields and initial allocations:

IANAは、「Generic Associated Channel（G-ACh）Parameters」レジストリ内に「MPLS-TP DHC TLVs」と呼ばれる新しいサブレジストリを作成しました。レジストリには次のフィールドと初期割り当てがあります。

Type Description Length Reference 0x0000 Reserved 0x0001 PW Status 20 Bytes RFC 8185 0x0002 Dual-Node Switching 16 Bytes RFC 8185

タイプ説明長さリファレンス0x0000予約済み0x0001 PWステータス20バイトRFC 8185 0x0002デュアルノードスイッチング16バイトRFC 8185

The allocation policy for this registry is IETF Review, as specified in [RFC8126].

このレジストリの割り当てポリシーは、[RFC8126]で指定されているIETFレビューです。

6. Security Considerations

6. セキュリティに関する考慮事項

MPLS-TP is a subset of MPLS and so builds upon many of the aspects of the MPLS security model. Please refer to [RFC5920] for generic MPLS security issues and methods for securing traffic privacy and integrity.

MPLS-TPはMPLSのサブセットであるため、MPLSセキュリティモデルの多くの側面に基づいています。トラフィックのプライバシーと整合性を保護するための一般的なMPLSセキュリティの問題と方法については、[RFC5920]を参照してください。

The DHC message defined in this document contains control information. If it is injected or modified by an attacker, the dual-homing PEs might not agree on which PE should be used to deliver the CE traffic, and this could be used as a denial-of-service attack against the CE. It is important that the DHC message be used within a trusted MPLS-TP network domain as described in [RFC6941].

このドキュメントで定義されているDHCメッセージには、制御情報が含まれています。攻撃者によって挿入または変更された場合、デュアルホーミングPEはCEトラフィックの配信にどのPEを使用すべきかについて合意しない可能性があり、これはCEに対するサービス拒否攻撃として使用される可能性があります。 [RFC6941]で説明されているように、DHCメッセージが信頼できるMPLS-TPネットワークドメイン内で使用されることが重要です。

The DHC message is carried in the G-ACh [RFC5586], so it is dependent on the security of the G-ACh itself. The G-ACh is a generalization of the Associated Channel defined in [RFC4385]. Thus, this document relies on the security mechanisms provided for the Associated Channel as described in those two documents.

DHCメッセージはG-ACh [RFC5586]で伝送されるため、G-ACh自体のセキュリティに依存しています。 G-AChは、[RFC4385]で定義されている関連チャネルの一般化です。したがって、このドキュメントは、これらの2つのドキュメントで説明されているように、関連チャネルに提供されるセキュリティメカニズムに依存しています。

As described in the Security Considerations section of [RFC6378], the G-ACh is essentially connection oriented, so injection or modification of control messages requires the subversion of a transit node. Such subversion is generally considered hard in connection-oriented MPLS networks and impossible to protect against at the protocol level. Management-level techniques are more appropriate. The procedures and protocol extensions defined in this document do not affect the security model of MPLS-TP linear protection as defined in [RFC6378].

[RFC6378]のセキュリティに関する考慮事項のセクションで説明されているように、G-AChは基本的に接続指向であるため、制御メッセージの挿入または変更にはトランジットノードの破壊が必要です。このような転覆は、一般に、接続指向のMPLSネットワークでは困難であると見なされており、プロトコルレベルでは保護できません。管理レベルの手法がより適切です。このドキュメントで定義されている手順とプロトコル拡張は、[RFC6378]で定義されているMPLS-TP線形保護のセキュリティモデルに影響を与えません。

Uniqueness of the identifiers defined in this document is guaranteed by the assigner (e.g., the operator). Failure by an assigner to use unique values within the specified scoping for any of the identifiers defined herein could result in operational problems. Please refer to [RFC6370] for more details about the uniqueness of the identifiers.

このドキュメントで定義されている識別子の一意性は、割り当て者（オペレーターなど）によって保証されています。ここで定義されている識別子のいずれかについて、指定されたスコープ内で一意の値を使用するための割り当て者による失敗は、操作上の問題を引き起こす可能性があります。識別子の一意性の詳細については、[RFC6370]を参照してください。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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>。

[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>.

[RFC5085]ナドー、T。、エド。およびC. Pignataro、編、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、RFC 5085、DOI 10.17487 / RFC5085、2007年12月、<http://www.rfc-editor.org/info / rfc5085>。

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <http://www.rfc-editor.org/info/rfc5586>.

[RFC5586] Bocci、M.、Ed。、Vigoureux、M.、Ed。、and S. Bryant、Ed。、 "MPLS Generic Associated Channel"、RFC 5586、DOI 10.17487 / RFC5586、June 2009、<http：// www.rfc-editor.org/info/rfc5586>。

[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, DOI 10.17487/RFC6370, September 2011, <http://www.rfc-editor.org/info/rfc6370>.

[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、DOI 10.17487 / RFC6370、2011年9月、<http：//www.rfc- editor.org/info/rfc6370>。

[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011, <http://www.rfc-editor.org/info/rfc6378>.

[RFC6378] Weingarten、Y。、編、Bryant、S.、Osborne、E.、Sprecher、N。、およびA. Fulignoli、編、「MPLS Transport Profile（MPLS-TP）Linear Protection」、RFC 6378、 DOI 10.17487 / RFC6378、2011年10月、<http://www.rfc-editor.org/info/rfc6378>。

[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, <http://www.rfc-editor.org/info/rfc7271>.

[RFC7271] Ryoo、J.、Ed。、Gray、E.、Ed。、van Helvoort、H.、D'Alessandro、A.、Cheung、T。、およびE. Osborne、「MPLS Transport Profile（MPLS-TP ）同期デジタル階層、光トランスポートネットワーク、およびイーサネットトランスポートネットワークオペレーターの運用上の期待に一致する線形保護」、RFC 7271、DOI 10.17487 / RFC7271、2014年6月、<http://www.rfc-editor.org/info/ rfc7271>。

[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear Protection", RFC 7324, DOI 10.17487/RFC7324, July 2014, <http://www.rfc-editor.org/info/rfc7324>.

[RFC7324] Osborne、E。、「Updates to MPLS Transport Profile Linear Protection」、RFC 7324、DOI 10.17487 / RFC7324、2014年7月、<http://www.rfc-editor.org/info/rfc7324>。

[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <http://www.rfc-editor.org/info/rfc8077>.

[RFC8077]マティーニ、L。、エド。およびG. Heron、Ed。、「ラベル配布プロトコル（LDP）を使用した疑似配線のセットアップとメンテナンス」、STD 84、RFC 8077、DOI 10.17487 / RFC8077、2017年2月、<http://www.rfc-editor.org/ info / rfc8077>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。

7.2. Informative References

7.2. 参考引用

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <http://www.rfc-editor.org/info/rfc4385>.

[RFC4385]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、RFC 4385、DOI 10.17487 / RFC4385、2006年2月、<http://www.rfc-editor.org/info/rfc4385>。

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.

[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。

[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, DOI 10.17487/RFC6372, September 2011, <http://www.rfc-editor.org/info/rfc6372>.

[RFC6372] Sprecher、N.、Ed。 A.ファレル編、「MPLSトランスポートプロファイル（MPLS-TP）サバイバビリティフレームワーク」、RFC 6372、DOI 10.17487 / RFC6372、2011年9月、<http://www.rfc-editor.org/info/rfc6372>。

[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy", RFC 6718, DOI 10.17487/RFC6718, August 2012, <http://www.rfc-editor.org/info/rfc6718>.

[RFC6718] Muley、P.、Aissaoui、M。、およびM. Bocci、「Pseudowire Redundancy」、RFC 6718、DOI 10.17487 / RFC6718、2012年8月、<http://www.rfc-editor.org/info/rfc6718 >。

[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>。

[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2013, <http://www.rfc-editor.org/info/rfc6941>.

[RFC6941] Fang、L.、Ed。、Niven-Jenkins、B.、Ed。、Mansfield、S.、Ed。、and R. Graveman、Ed。、 "MPLS Transport Profile（MPLS-TP）Security Framework"、 RFC 6941、DOI 10.17487 / RFC6941、2013年4月、<http://www.rfc-editor.org/info/rfc6941>。

[RFC7771] Malis, A., Ed., Andersson, L., van Helvoort, H., Shin, J., Wang, L., and A. D'Alessandro, "Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires", RFC 7771, DOI 10.17487/RFC7771, January 2016, <http://www.rfc-editor.org/info/rfc7771>.

[RFC7771] Malis、A.、Ed。、Andersson、L.、van Helvoort、H.、Shin、J.、Wang、L。、およびA. D'Alessandro、「Switching Provider Edge（S-PE）Protection for MPLS and MPLS Transport Profile（MPLS-TP）Static Multi-Segment Pseudowires」、RFC 7771、DOI 10.17487 / RFC7771、2016年1月、<http://www.rfc-editor.org/info/rfc7771>。

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <http://www.rfc-editor.org/info/rfc8126>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<http：// www .rfc-editor.org / info / rfc8126>。

[RFC8184] Cheng, W., Wang, L., Li, H., Davari, S., and J. Dong, "Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires", RFC 8184, DOI 10.17487/RFC8184, June 2017.

[RFC8184] Cheng、W.、Wang、L.、Li、H.、Davari、S。、およびJ. Dong、「MPLSおよびMPLSトランスポートプロファイル（MPLS-TP）疑似配線のデュアルホーミング保護」、RFC 8184 、DOI 10.17487 / RFC8184、2017年6月。

Contributors

貢献者

The following individuals substantially contributed to the content of this document:

次の個人は、このドキュメントの内容に大きく貢献しました。

Kai Liu Huawei Technologies Email: alex.liukai@huawei.com

かいぃうふあうぇいてｃｈのぉぎえｓえまいｌ：あぇｘ。ぃうかい＠ふあうぇい。こｍ

Shahram Davari Broadcom Corporation Email: davari@broadcom.com

Shahram Davari Broadcom Corporationメール：davari@broadcom.com

Authors' Addresses

著者のアドレス

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

Lei Wang China Mobile No.32 Xuanwumen West Street Beijing 100053 China

Lei Wang China Mobile No.32 Xuanwumen West Street北京100053中国

   Email: Wangleiyj@chinamobile.com

Han Li China Mobile No.32 Xuanwumen West Street Beijing 100053 China

はんぃちなもびぇの。３２ぅあんうめんうぇｓｔＳｔれえｔべいじんｇ１０００５３ちな

   Email: Lihan@chinamobile.com

Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China

J IEドンhu Aはテクノロジーhu Aはキャンパス、第156 be i青RD北京100095中国

   Email: jie.dong@huawei.com

Alessandro D'Alessandro Telecom Italia via Reiss Romoli, 274 Torino 10148 Italy

アレッサンドロダレッサンドロテレコムイタリアvia Reiss Romoli、274トリノ10148イタリア

   Email: alessandro.dalessandro@telecomitalia.it