[要約] RFC 7412は、MPLS-TP共有メッシュ保護の要件を定義しています。その目的は、MPLS-TPネットワークでの信頼性と回復力を向上させることです。
Internet Engineering Task Force (IETF) Y. Weingarten
Request for Comments: 7412
Category: Informational S. Aldrin
ISSN: 2070-1721 Huawei Technologies
P. Pan
Infinera
J. Ryoo
ETRI
G. Mirsky
Ericsson
December 2014
Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection
MPLSトランスポートプロファイル（MPLS-TP）共有メッシュ保護の要件
Abstract
概要
This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.
このドキュメントでは、コントロールプレーンサポートに基づいていない、共有メッシュ保護（SMP）の動作に関する基本的なネットワーク目標について説明します。このドキュメントでは、RFC 5654（「MPLSトランスポートプロファイルの要件」）およびRFC 6372（「MPLSトランスポートプロファイル（MPLS-TP）存続性フレームワーク」）で提示されている基本要件の拡張について説明します。このドキュメントでは、データプレーンに保護スイッチの調整を委任するネットワークで、MPLS-TPのSMPデータパスを実装するために使用されるメカニズムの要件を示します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション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/rfc7412.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7412で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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
2. Terminology and Notation ........................................3
2.1. Acronyms and Terminology ...................................4
3. Shared Mesh Protection Reference Model ..........................4
3.1. Protection or Restoration ..................................5
3.2. Scope of Document ..........................................5
3.2.1. Relationship to MPLS ................................5
4. SMP Architecture ................................................6
4.1. Coordination of Resources ..................................8
4.2. Control Plane or Data Plane ................................8
5. SMP Network Objectives ..........................................9
5.1. Resource Reservation and Coordination ......................9
5.1.1. Checking Resource Availability for Multiple
Protection Paths ....................................9
5.2. Multiple Triggers .........................................10
5.2.1. Soft Preemption ....................................10
5.2.2. Hard Preemption ....................................10
5.3. Notification ..............................................11
5.4. Reversion .................................................11
5.5. Protection Switching Time .................................11
5.6. Timers ....................................................12
5.7. Communication Channel and Fate-Sharing ....................12
6. Manageability Considerations ...................................13
7. Security Considerations ........................................13
8. Normative References ...........................................13
Acknowledgements ..................................................15
Contributors ......................................................15
Authors' Addresses ................................................16
The MPLS Transport Profile (MPLS-TP) is described in [RFC5921]. [RFC6372] provides a survivability framework for MPLS-TP and is the foundation for this document.
MPLSトランスポートプロファイル（MPLS-TP）は、[RFC5921]で説明されています。 [RFC6372]はMPLS-TPの存続可能性フレームワークを提供し、このドキュメントの基礎となります。
Terminology for recovery of connectivity in networks is provided in [RFC4427] and includes the concept of surviving network faults (survivability) through the use of re-established connections (restoration) and switching of traffic to pre-established backup paths (protection). MPLS provides control-plane tools to support various survivability schemes, some of which are identified in [RFC4426]. In addition, recent efforts in the IETF have started providing for data-plane tools to address aspects of data protection. In particular, [RFC6378] and [RFC7271] define a set of triggers and coordination protocols for 1:1 and 1+1 linear protection of point-to-point paths.
ネットワークの接続を回復するための用語は[RFC4427]で提供されており、再確立された接続（復元）と事前に確立されたバックアップパスへのトラフィックの切り替え（保護）を使用して、ネットワークの障害（存続可能性）に耐えるという概念が含まれています。 MPLSは、さまざまな存続可能性スキームをサポートするためのコントロールプレーンツールを提供します。その一部は[RFC4426]で特定されています。さらに、IETFでの最近の取り組みにより、データ保護の側面に対処するデータプレーンツールの提供が開始されました。特に、[RFC6378]および[RFC7271]は、ポイントツーポイントパスの1：1および1 + 1線形保護のためのトリガーと調整プロトコルのセットを定義します。
When considering a full-mesh network and the protection of different paths that traverse the mesh, it is possible to provide an acceptable level of protection while conserving the amount of protection resources needed to protect the different data paths. As pointed out in [RFC6372] and [RFC4427], applying 1+1 protection requires that resources are allocated for use by both the working and protection paths. Applying 1:1 protection requires that the same resources are allocated but allows the resources of the protection path to be utilized for preemptible extra traffic. Extending this to 1:n or m:n protection allows the resources of the protection path to be shared in the protection of several working paths. However, 1:n or m:n protection architecture is limited by the restriction that all of the n+1 or m+n paths must have the same endpoints. m:n protection architecture provides m protection paths to protect n working paths, where m or n can be 1.
フルメッシュネットワークと、メッシュを通過するさまざまなパスの保護を検討する場合、さまざまなデータパスを保護するために必要な保護リソースの量を節約しながら、許容レベルの保護を提供できます。 [RFC6372]と[RFC4427]で指摘されているように、1 + 1保護を適用するには、現用パスと保護パスの両方で使用するためにリソースを割り当てる必要があります。 1：1保護を適用するには、同じリソースを割り当てる必要がありますが、保護パスのリソースをプリエンプティブルの追加トラフィックに利用できます。これを1：nまたはm：n保護に拡張すると、保護パスのリソースを複数の現用パスの保護で共有できます。ただし、1：nまたはm：n保護アーキテクチャーは、すべてのn + 1またはm + nパスが同じエンドポイントを持つ必要があるという制限によって制限されます。 m：n保護アーキテクチャは、n個の動作パスを保護するためのm個の保護パスを提供します。ここで、mまたはnは1です。
This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane.
このドキュメントでは、データプレーンに保護スイッチの調整を委任するネットワークで、MPLS-TPのSMPデータパスを実装するために使用されるメカニズムの要件を示します。
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]で説明されているように解釈されます。
Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
このドキュメントはプロトコル仕様ではありませんが、この言語を使用することで、このドキュメントに記載されている要件を満たすソリューションを作成するプロトコル設計者への指示が明確になります。
The terminology used in this document is based on the terminology defined in the MPLS-TP Survivability Framework document [RFC6372], which in turn is based on [RFC4427].
このドキュメントで使用されている用語は、MPLS-TP Survivability Frameworkドキュメント[RFC6372]で定義されている用語に基づいており、さらに[RFC4427]に基づいています。
This document uses the following acronyms:
このドキュメントでは、次の頭字語を使用しています。
LSP Label Switched Path SLA Service Level Agreement SMP Shared Mesh Protection SRLG Shared Risk Link Group
LSPラベルスイッチドパスSLAサービスレベルアグリーメントSMP共有メッシュ保護SRLG共有リスクリンクグループ
This document defines the following term:
このドキュメントでは、次の用語を定義しています。
SMP Protection Group: the set of different protection paths that share a common segment.
SMP保護グループ：共通セグメントを共有するさまざまな保護パスのセット。
As described in [RFC6372], SMP supports the sharing of protection resources, while providing protection for multiple working paths that need not have common endpoints and do not share common points of failure. Note that some protection resources may be shared, while some others may not be. An example of data paths that employ SMP is shown in Figure 1. It shows two working paths -- <ABCDE> and <VWXYZ> -- that are protected employing 1:1 linear protection by protection paths <APQRE> and <VPQRZ>, respectively. The two protection paths that traverse segment <PQR> share the protection resources on this segment.
[RFC6372]で説明されているように、SMPは保護リソースの共有をサポートし、共通のエンドポイントを必要とせず、共通の障害点を共有しない複数の現用パスを保護します。一部の保護リソースは共有される場合がありますが、共有されない場合もあります。 SMPを使用するデータパスの例を図1に示します。保護パス<APQRE>および<VPQRZ>によって1：1線形保護を使用して保護されている2つの現用パス（<ABCDE>および<VWXYZ>）を示しています。それぞれ。セグメント<PQR>を通過する2つの保護パスは、このセグメントの保護リソースを共有します。
A----B----C----D----E
\ /
\ /
\ /
P-----Q-----R
/ \
/ \
/ \
V----W----X----Y----Z
Figure 1: Basic SMP Architecture
図1：基本的なSMPアーキテクチャ
[RFC6372], based upon the definitions in [RFC4427], differentiates between "protection" and "restoration", depending on the dynamism of the resource allocation. The same distinction is used in [RFC3945], [RFC4426], and [RFC4428].
[RFC6372]は、[RFC4427]の定義に基づいて、リソース割り当てのダイナミズムに応じて、「保護」と「復元」を区別します。 [RFC3945]、[RFC4426]、および[RFC4428]でも同じ区別が使用されます。
This document also uses the same distinction between protection and restoration as the distinction stated in [RFC6372].
このドキュメントでも、[RFC6372]で述べられている区別と同じ保護と復元の区別を使用しています。
[RFC5654] establishes that MPLS-TP SHOULD support shared protection (Requirement 68) and that MPLS-TP MUST support sharing of protection resources (Requirement 69). This document presents the network objectives and a framework for applying SMP within an MPLS network, without the use of control-plane protocols. Although there are existing control-plane solutions for SMP within MPLS, a data-plane solution is required for networks that do not employ a full control-plane operation for some reason (e.g., service provider preferences or limitations) or require service restoration faster than is achievable with control-plane mechanisms.
[RFC5654]は、MPLS-TPが共有保護をサポートする必要がある（要件68）ことと、MPLS-TPが保護リソースの共有をサポートする必要がある（要件69）ことを確立します。このドキュメントでは、コントロールプレーンプロトコルを使用せずに、MPLSネットワーク内でSMPを適用するためのネットワークの目的とフレームワークについて説明します。 MPLS内のSMPには既存のコントロールプレーンソリューションがありますが、何らかの理由（たとえば、サービスプロバイダーの設定または制限）で完全なコントロールプレーン操作を採用していない、またはサービスの復元がコントロールプレーンメカニズムで実現可能です。
The network objectives will also address possible additional restrictions on the behavior of SMP in networks that delegate protection switching for resiliency to the data plane. Definitions of logic and specific protocol messaging are out of scope for this document.
ネットワークの目的は、データプレーンへの回復力の保護切り替えを委任するネットワークでのSMPの動作に対する可能な追加の制限にも対処します。ロジックおよび特定のプロトコルメッセージングの定義は、このドキュメントの範囲外です。
While some of the restrictions presented by this document originate from the properties of transport networks, nothing prevents the information presented here from being applied to MPLS networks outside the scope of the Transport Profile of MPLS.
このドキュメントで提示されている制限の一部はトランスポートネットワークのプロパティに起因していますが、ここで提示される情報がMPLSのトランスポートプロファイルの範囲外のMPLSネットワークに適用されることを妨げるものはありません。
Figure 1 shows a very basic configuration of working and protection paths that may employ SMP. We may consider a slightly more complex configuration, such as the one in Figure 2 in order to illustrate characteristics of a mesh network that implements SMP.
図1は、SMPを使用する可能性のある現用パスと保護パスの非常に基本的な構成を示しています。 SMPを実装するメッシュネットワークの特性を示すために、図2のようなもう少し複雑な構成を検討する場合があります。
A----B----C----D----E---N
\ / / \
\ M ---/-- \
\ / \ \
P-----Q-----R-----S----T
/| \ \ \ \
/ F---G---H J--K---L \
/ \
V------W-------X-------Y-------Z
Figure 2: Example of a Larger SMP Architecture
図2：大規模なSMPアーキテクチャの例
Consider the network presented in Figure 2. There are five working paths:
図2に示すネットワークについて考えてみます。5つの有効なパスがあります。
- <ABCDE>
- <ABCDE>
- <MDEN>
- <マダン>
- <FGH>
- <FGH>
- <JKL>
- <JKL>
- <VWXYZ>
- <VWXYZ>
Each of these has a corresponding protection path:
これらのそれぞれに対応する保護パスがあります。
- <APQRE> (p1)
- <APQRE>（p1）
- <MSTN> (p2)
- <MSTN>（p2）
- <FPQH> (p3)
- <FPQH>（p3）
- <JRSL> (p4)
- <JRSL>（p4）
- <VPQRSTZ> (p5)
- <VPQRSTZ>（p5）
The following segments are shared by two or more of the protection
paths -- <PQ> is shared by p1, p3, and p5; <QR> is shared by p1 and
p5; <RS> is shared by p4 and p5; and <ST> is shared by p2 and p5. In
Figure 2, we have the following SMP Protection Groups -- {p1, p3, p5}
for <PQ>, {p1, p5} for <QR>, {p4, p5} for <RS>, and {p2, p5}
for <ST>.
We assume that the available protection resources for these shared segments are not sufficient to support the complete traffic capacity of the respective working paths that may use the protection paths. We can further observe that with a method of coordinating sharing and preemption, there are no co-routing constraints on shared components at the segment level.
これらの共有セグメントに使用できる保護リソースは、保護パスを使用する可能性のあるそれぞれの現用パスの完全なトラフィック容量をサポートするには不十分であると想定しています。さらに、共有とプリエンプションを調整する方法を使用すると、セグメントレベルで共有コンポーネントにルーティングに関する制約がないことがわかります。
The use of preemption in the network is typically a business or policy decision such that when protection resources are contested, priority can be applied to determine which parties utilize the protection resources.
ネットワークでのプリエンプションの使用は、通常、ビジネスまたはポリシーの決定であり、保護リソースが競合する場合、どのリソースが保護リソースを利用するかを決定するために優先度を適用できます。
As opposed to the case of simple linear protection, where the relationship between the working and protection paths is defined and the resources for the protection path are fully dedicated, the protection path in the case of SMP consists of segments that are used for the protection of the related working path and also segments that are shared with other protection paths such that typically the protection resources are oversubscribed to support working paths that do not share common points of failure. What is required is a preemption mechanism to implement business priority when multiple failure scenarios occur. As such, the protection resources may be allocated but would not be utilized until requested and resolved in relation to other members of the SMP Protection Group as part of a protection switchover.
単純な線形保護の場合とは対照的に、現用パスと保護パスの関係が定義されており、保護パスのリソースが完全に専用である場合、SMPの場合の保護パスは、保護に使用されるセグメントで構成されます。関連する現用パスと、他の保護パスと共有されるセグメント。これにより、通常、保護リソースがオーバーサブスクライブされて、共通の障害点を共有しない現用パスをサポートします。複数の障害シナリオが発生したときにビジネス優先順位を実装するためのプリエンプションメカニズムが必要です。このように、保護リソースは割り当てられる可能性がありますが、保護切り替えの一部としてSMP保護グループの他のメンバーに関連して要求および解決されるまで使用されません。
[RFC6372] defines two types of preemption that can be considered for how the resources of SMP Protection Groups are shared: "soft preemption", where traffic of lower-priority paths is degraded; and "hard preemption", where traffic of lower-priority paths is completely blocked. The traffic of lower-priority paths in this document can be viewed as the extra traffic being preempted, as described in [RFC6372]. "Hard preemption" requires the programming of selectors at the ingress of each shared segment to specify the priorities of backup paths, so that traffic of lower-priority paths can be preempted. When any protection mechanism where the protection endpoint may have a choice of protection paths (e.g., m:n or m:1) is deployed, the shared segment selectors require coordination with the protection endpoints as well.
[RFC6372]は、SMP保護グループのリソースがどのように共有されるかを考慮できる2つのタイプのプリエンプションを定義しています。「ソフトプリエンプション」。優先度の低いパスのトラフィックが低下します。優先度の低いパスのトラフィックが完全にブロックされる「ハードプリエンプション」。このドキュメントで優先度の低いパスのトラフィックは、[RFC6372]で説明されているように、優先される追加のトラフィックと見なすことができます。 「ハードプリエンプション」では、バックアップパスの優先順位を指定するために、各共有セグメントの入口でセレクターをプログラミングする必要があるため、優先順位の低いパスのトラフィックをプリエンプトできます。保護エンドポイントに保護パスの選択（たとえば、m：nまたはm：1）がある保護メカニズムが展開されている場合、共有セグメントセレクターも保護エンドポイントとの調整が必要です。
Typical deployment of services that use SMP requires various network planning activities. These include the following:
SMPを使用するサービスの一般的な展開には、さまざまなネットワーク計画アクティビティが必要です。これらには以下が含まれます。
o Determining the number of working and protection paths required to achieve resiliency targets for the service.
o サービスの回復力目標を達成するために必要なワーキングパスと保護パスの数を決定する。
o Reviewing network topology to determine which working or protection paths are required to be disjoint from each other, and excluding specified resources such as links, nodes, or shared risk link groups (SRLGs).
o ネットワークトポロジを確認して、相互に分離する必要がある作業パスまたは保護パスを決定し、リンク、ノード、共有リスクリンクグループ（SRLG）などの指定されたリソースを除外します。
o Determining the size (bandwidth) of the shared resource.
o 共有リソースのサイズ（帯域幅）を決定します。
When a protection switch is triggered, the SMP network performs two operations -- switching data traffic over to a protection path and coordinating the utilization of the associated shared resources. Both operations should occur at the same time, or as close together as possible, to provide fast protection. The resource utilization coordination is dependent upon their availability at each of the shared segments.
保護切り替えがトリガーされると、SMPネットワークは2つの操作を実行します。データトラフィックを保護パスに切り替え、関連する共有リソースの使用を調整します。高速保護を提供するには、両方の操作を同時に、またはできるだけ近づけて行う必要があります。リソース使用率の調整は、各共有セグメントでの可用性に依存しています。
When the reserved resources of the shared segments are utilized by a particular protection path, there may not be sufficient resources available for an additional protection path. This then implies that if another working path of the SMP domain triggers a protection switch, the resource utilization coordination may fail. The different working paths in the SMP network are involved in the resource utilization coordination, which is a part of a whole SMP protection switching coordination.
共有セグメントの予約済みリソースが特定の保護パスによって利用されている場合、追加の保護パスに使用できる十分なリソースがない可能性があります。これは、SMPドメインの別の現用パスが保護切り替えをトリガーした場合、リソース使用率の調整が失敗する可能性があることを意味します。 SMPネットワーク内のさまざまな現用パスは、リソース使用率調整に関与します。これは、SMP保護スイッチング調整全体の一部です。
As stated in both [RFC6372] and [RFC4428], full control of SMP, including both configuration and the coordination of the protection switching, is potentially very complex. Therefore, it is suggested that this be carried out under the control of a dynamic control plane based on Generalized MPLS (GMPLS) [RFC3945]. Implementations for SMP with GMPLS exist, and the general principles of its operation are well known, if not fully documented.
[RFC6372]と[RFC4428]の両方で述べられているように、構成と保護切り替えの調整の両方を含むSMPの完全な制御は、潜在的に非常に複雑です。したがって、これはGeneralized MPLS（GMPLS）[RFC3945]に基づくダイナミックコントロールプレーンの制御下で実行することをお勧めします。 GMPLSを使用したSMPの実装が存在し、完全に文書化されていない場合でも、その動作の一般原則はよく知られています。
However, there are operators, in particular in the transport sector, that do not operate their MPLS-TP networks under the control of a control plane or for other reasons have delegated executive action for resilience to the data plane, and require the ability to utilize SMP protection. For such networks, it is imperative that it be possible to perform all required coordination of selectors and endpoints for SMP via data-plane operations.
ただし、特にトランスポートセクターでは、コントロールプレーンの制御下でMPLS-TPネットワークを運用していない、または他の理由でデータプレーンへの回復力のために実行アクションを委任しているオペレーターがいます。 SMP保護。このようなネットワークでは、データプレーン操作を介して、SMPのセレクターとエンドポイントの必要なすべての調整を実行できることが不可欠です。
SMP is based on pre-configuration of the working paths and the corresponding protection paths. This configuration may be based on either a control protocol or static configuration by the management system. However, even when the configuration is performed by a control protocol, e.g., GMPLS, the control protocol SHALL NOT be used as the primary mechanism for detecting or reporting network failures, or for initiating or coordinating protection switchover. That is, it SHALL NOT be used as the primary resilience mechanism.
SMPは、現用パスと対応する保護パスの事前設定に基づいています。この構成は、管理システムによる制御プロトコルまたは静的構成に基づいている場合があります。ただし、構成がGMPLSなどの制御プロトコルによって実行される場合でも、制御プロトコルは、ネットワーク障害を検出または報告したり、保護切り替えを開始または調整したりするための主要なメカニズムとして使用してはなりません。つまり、主要な回復力メカニズムとして使用することはできません。
The protection relationship between the working and protection paths SHOULD be configured, and the shared segments of the protection path MUST be identified prior to use of the protection paths. Relative priority for working paths to be used to resolve contention for protection path usage by multiple working paths MAY also be specified ahead of time.
現用パスと保護パスの間の保護関係を設定する必要があります。また、保護パスを使用する前に、保護パスの共有セグメントを特定する必要があります。複数の現用パスによる保護パスの使用の競合を解決するために使用される現用パスの相対的な優先順位も、事前に指定できます。
When a protection switch is triggered by any fault condition or operator command, the SMP network MUST perform two operations -- switch data traffic over to a protection path, and coordinate the utilization of the associated shared resources. To provide fast protection, both operations MUST occur at the same time or as close to the same time as possible.
障害状態またはオペレーターコマンドによって保護切り替えがトリガーされると、SMPネットワークは2つの操作を実行する必要があります-データトラフィックを保護パスに切り替え、関連する共有リソースの使用を調整します。高速な保護を提供するには、両方の操作を同時にまたは可能な限り同時に行う必要があります。
In the case of multiple working paths failing, the shared resource utilization coordination SHALL be between the different working paths in the SMP network.
複数の現用パスに障害が発生した場合、共有リソース使用率調整は、SMPネットワークの異なる現用パス間に存在する必要があります（SHALL）。
In a hard-preemption scenario, when an endpoint identifies a protection switching trigger and has more than one potential action (e.g., m:1 protection), it MUST verify that the necessary protection resources are available on the selected protection path. The resources may not be available because they have already been utilized for the protection of, for example, one or more higher-priority working paths.
ハードプリエンプションのシナリオでは、エンドポイントが保護切り替えトリガーを識別し、潜在的なアクションが複数ある場合（m：1保護など）、必要な保護リソースが選択した保護パスで利用可能であることを確認する必要があります。リソースは、たとえば1つ以上の優先順位の高い現用パスの保護にすでに使用されているため、使用できない場合があります。
If more than one working path is triggering a protection switch such that a protection segment is oversubscribed, there are two different actions that the SMP network can choose -- soft preemption and hard preemption [RFC6372].
複数の現用パスが保護切り替えをトリガーして保護セグメントがオーバーサブスクライブされる場合、SMPネットワークが選択できる2つの異なるアクションがあります-ソフトプリエンプションとハードプリエンプション[RFC6372]。
For networks that support multiplexing packets over the shared segments, the requirement is as follows:
共有セグメントでのパケットの多重化をサポートするネットワークの場合、要件は次のとおりです。
o All of the protection paths MAY be allowed to share the resources of the shared segments.
o すべての保護パスは、共有セグメントのリソースを共有できる場合があります。
There are networks that require the exclusive use of the protection resources when a protection segment is oversubscribed. Traffic of lower-priority paths is completely blocked. These include networks that support the requirements in [RFC5654], and in particular support Requirement 58. For such networks, the following requirements apply:
保護セグメントがオーバーサブスクライブされている場合に、保護リソースを排他的に使用する必要があるネットワークがあります。優先度の低いパスのトラフィックは完全にブロックされます。これらには、[RFC5654]の要件をサポートするネットワーク、特に要件58をサポートするネットワークが含まれます。このようなネットワークには、次の要件が適用されます。
1. Relative priority MAY be assigned to each of the working paths of an SMP domain. If the priority is not assigned, the working paths are assumed to have equal priority.
1. 相対優先順位は、SMPドメインの各現用パスに割り当てられる場合があります。優先順位が割り当てられていない場合、現用パスの優先順位は同じであると見なされます。
2. Resources of the shared segments SHALL be utilized by the protection path according to the highest priority amongst those requesting use of the resources.
2. 共有セグメントのリソースは、リソースの使用を要求するリソースの中で最も高い優先順位に従って、保護パスによって利用されるものとします（SHALL）。
3. If multiple protection paths of equal priority are requesting the shared resources, the resources SHALL be utilized on a first come first served basis. Traffic of the protection paths that request the shared resources late SHALL be preempted. In order to cover the situation where the first come first served principle cannot resolve the contention among multiple equal-priority requests, i.e., when the requests occur simultaneously, tie-breaking rules SHALL be defined in the scope of an SMP domain.
3. 同じ優先度の複数の保護パスが共有リソースを要求している場合、リソースは先着順で利用されるものとします（SHALL）。共有リソースを後で要求する保護パスのトラフィックは、横取りされる必要があります。先着順の原則が複数の同じ優先度のリクエスト間の競合を解決できない状況をカバーするために、つまり、リクエストが同時に発生する場合、タイブレイキングルールをSMPドメインのスコープで定義する必要があります。
4. If a higher-priority path requires the protection resources that are being utilized by a lower-priority path, the resources SHALL be utilized by the higher-priority path. Traffic with the lower priority SHALL be preempted.
4. 優先度の高いパスに、優先度の低いパスで使用されている保護リソースが必要な場合、リソースは優先度の高いパスで使用されるものとします（SHALL）。プライオリティの低いトラフィックはプリエンプトされる必要があります。
5. Once resources of shared segments have been successfully utilized by a protection path, the traffic on that protection path SHALL NOT be interrupted by any protection traffic whose priority is equal to or lower than the protecting path currently in use.
5. 共有セグメントのリソースが保護パスによって正常に利用されると、その保護パス上のトラフィックは、現在使用中の保護パスと同じかそれよりも低い優先度の保護トラフィックによって中断されないものとします。
6. During preemption, shared segment resources MAY be used by both existing traffic (that is being preempted) and higher-priority traffic.
6. プリエンプション中、共有セグメントリソースは、既存のトラフィック（プリエンプトされている）と優先順位の高いトラフィックの両方で使用される場合があります。
When a working path endpoint has a protection switch triggered, it SHOULD attempt to switch the traffic to the protection path and request the coordination of the shared resource utilization. If the necessary shared resources are unavailable, the endpoints of the requesting working path SHALL be notified of protection switchover failure, and switchover will not be completed.
現用パスエンドポイントで保護切り替えがトリガーされた場合、トラフィックを保護パスに切り替えて、共有リソースの使用率の調整を要求する必要があります（SHOULD）。必要な共有リソースが利用できない場合は、要求している現用パスのエンドポイントに保護スイッチオーバーの失敗が通知されなければならず（SHALL）、スイッチオーバーは完了しません。
Similarly, if preemption is supported and the resources currently utilized by a particular working path are being preempted, then the endpoints of the affected working path whose traffic is being preempted SHALL be notified that the resources are being preempted. As described in [RFC6372], the event of preemption may be detected by Operations, Administration, and Maintenance (OAM) and reported as a fault or a degradation of traffic delivery.
同様に、プリエンプションがサポートされており、特定の現用パスによって現在利用されているリソースがプリエンプションされている場合、トラフィックがプリエンプションされている影響を受ける現用パスのエンドポイントに、リソースがプリエンプトされていることを通知する必要があります。 [RFC6372]で説明されているように、プリエンプションのイベントは、運用、管理、および保守（OAM）によって検出され、障害またはトラフィック配信の低下として報告される場合があります。
When the condition that triggered the protection switch is cleared, it is possible to either revert to using the working path resources or continue to utilize the protection resources. Continuing the use of protection resources allows the operator to delay the disruption of service caused by the switchover until periods of lighter traffic. The switchover would need to be performed via an explicit operator command, unless the protection resources are preempted by a higher-priority fault. Hence, both automatic and manual revertive behaviors MUST be supported for hard preemption in an SMP domain. Normally, the network should revert to use of the working path resources in order to clear the protection resources for protection of other path triggers. However, the protocol MUST support non-revertive configurations.
保護切り替えをトリガーした条件がクリアされると、現用パスリソースの使用に戻るか、保護リソースを引き続き使用できます。保護リソースの使用を継続することにより、オペレーターは、トラフィックの軽い期間まで、スイッチオーバーによって引き起こされるサービスの中断を遅らせることができます。優先度の高い障害によって保護リソースが優先されない限り、明示的なオペレーターコマンドを介してスイッチオーバーを実行する必要があります。したがって、SMPドメインのハードプリエンプションでは、自動と手動の両方のリバーティブ動作をサポートする必要があります。通常、ネットワークは、他のパストリガーの保護のために保護リソースをクリアするために、現用パスリソースの使用に戻る必要があります。ただし、プロトコルは非リバーティブ構成をサポートする必要があります。
Protection switching time refers to the transfer time (Tt) defined in [G.808.1] and recovery switching time defined in [RFC4427], and is defined as the interval after a switching trigger is identified until the traffic begins to be transmitted on the protection path. This time does not include the time needed to initiate the protection switching process after a failure occurred, and the time needed to complete preemption of existing traffic on the shared segments as described in Section 4.2. The time needed to initiate the protection switching process, which is known as detection time or correlation time in [RFC4427], is related to the OAM or management process, but the time needed to complete preemption is related to the actions within an SMP domain. Support for a protection switching time of 50 ms is dependent upon the initial switchover to the protection path, but the preemption time SHOULD also be taken into account to minimize total service interruption time.
保護切り替え時間とは、[G.808.1]で定義されている転送時間（Tt）および[RFC4427]で定義されている回復切り替え時間を指し、切り替えトリガーが識別されてからトラフィックが保護で送信され始めるまでの間隔として定義されます。道。この時間には、障害発生後に保護切り替えプロセスを開始するために必要な時間と、セクション4.2で説明されている共有セグメント上の既存のトラフィックのプリエンプションを完了するために必要な時間は含まれません。 [RFC4427]では検出時間または相関時間と呼ばれる、保護切り替えプロセスの開始に必要な時間は、OAMまたは管理プロセスに関連していますが、プリエンプションを完了するのに必要な時間は、SMPドメイン内のアクションに関連しています。 50 msの保護切り替え時間のサポートは、保護パスへの最初の切り替えに依存しますが、総サービス中断時間を最小限に抑えるために、プリエンプション時間も考慮する必要があります（SHOULD）。
When triggered, protection switching action SHOULD be initiated immediately to minimize service interruption time.
トリガーされると、サービスの中断時間を最小限に抑えるために、保護切り替えアクションをすぐに開始する必要があります。
In order to prevent multiple switching actions for a single switching trigger, when there are multiple layers of networks, SMP SHOULD be controlled by a hold-off timer that would allow lower-layer mechanisms to complete their switching actions before invoking SMP protection actions as described in [RFC6372].
単一のスイッチングトリガーで複数のスイッチングアクションが発生しないようにするために、ネットワークのレイヤーが複数ある場合、SMPはホールドオフタイマーによって制御する必要があります（SHOULD）。 [RFC6372]。
In order to prevent an unstable recovering working path from invoking intermittent switching operations, SMP SHOULD employ a Wait-To-Restore timer during any reversion switching, as described in [RFC6372].
[RFC6372]で説明されているように、不安定な回復中の作業パスが断続的な切り替え操作を呼び出すのを防ぐために、SMPは、復元切り替え中にWait-To-Restoreタイマーを使用する必要があります（SHOULD）。
SMP SHOULD provide a communication channel, along the protection path, between the endpoints of the protection path, to support fast protection switching.
SMPは、高速保護切り替えをサポートするために、保護パスのエンドポイント間で、保護パスに沿った通信チャネルを提供する必要があります（SHOULD）。
SMP in hard-preemption mode SHOULD include support for communicating information to coordinate the use of the shared protection resources among multiple working paths. The message encoding and communication channel between the nodes of the shared protection resource and the endpoints of the protection path are out of the scope of this document.
ハードプリエンプションモードのSMPは、複数の現用パス間で共有された保護リソースの使用を調整するための通信情報のサポートを含む必要があります（SHOULD）。共有保護リソースのノードと保護パスのエンドポイント間のメッセージエンコーディングと通信チャネルは、このドキュメントの範囲外です。
Bidirectional protection switching SHOULD be supported in SMP.
双方向保護スイッチングはSMPでサポートされるべきです（SHOULD）。
The network management architecture and requirements for MPLS-TP are specified in [RFC5951]. They derive from the generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. This document does not introduce any new manageability requirements beyond those covered in those documents.
MPLS-TPのネットワーク管理アーキテクチャと要件は、[RFC5951]で指定されています。これらは、ITU-T G.7710 / Y.1701 [G.7710]で説明されているトランスポートテクノロジーの一般的な仕様に基づいています。このドキュメントでは、それらのドキュメントでカバーされているものを超える新しい管理要件は紹介していません。
General security considerations for MPLS-TP are covered in [RFC5921]. The security considerations for the generic associated control channel are described in [RFC5586].
MPLS-TPの一般的なセキュリティの考慮事項は、[RFC5921]でカバーされています。一般的な関連制御チャネルのセキュリティに関する考慮事項は、[RFC5586]で説明されています。
Security considerations for any proposed solution should consider exhaustion of resources related to preemption, especially by a malicious actor as a threat vector against which the resources should be protected. Protections should also be considered to prevent a malicious actor from attempting to create an alternate path on which to force traffic from a sensor/device, thereby enabling pervasive monitoring [RFC7258].
提案されたソリューションのセキュリティに関する考慮事項では、プリエンプションに関連するリソースの枯渇を考慮する必要があります。特に、リソースを保護する必要がある脅威ベクトルとして、悪意のあるアクターによるものです。悪意のある攻撃者がセンサー/デバイスからのトラフィックを強制する代替パスを作成しようとするのを防ぎ、それによって広範囲にわたる監視を可能にするために、保護も検討する必要があります[RFC7258]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、2004年10月、<http://www.rfc-editor.org/info/rfc3945>。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, March 2006, <http://www.rfc-editor.org/info/rfc4426>.
[RFC4426] Lang、J。、編、Rajagopalan、B。、編、およびD. Papadimitriou、編、「一般化マルチプロトコルラベルスイッチング（GMPLS）リカバリ機能仕様」、RFC 4426、2006年3月、<http ：//www.rfc-editor.org/info/rfc4426>。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006, <http://www.rfc-editor.org/info/rfc4427>.
[RFC4427] Mannie、E.、Ed。およびD. Papadimitriou、Ed。、 "Recovery（Protection and Restoration）Terminology for Generalized Multi-Protocol Label Switching（GMPLS）"、RFC 4427、2006年3月、<http：// www.rfc-editor.org/info/rfc4427>。
[RFC4428] Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", RFC 4428, March 2006, <http://www.rfc-editor.org/info/rfc4428>.
[RFC4428] Papadimitriou、D。、編、およびE. Mannie、編、「Analysis of Generalized Multi-Protocol Label Switching（GMPLS）-based Recovery Mechanisms（protection and Restoration）を含む」、RFC 4428、2006年3月、< http://www.rfc-editor.org/info/rfc4428>。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, 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、June 2009、<http：//www.rfc-editor .org / info / rfc5586>。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009, <http://www.rfc-editor.org/info/rfc5654>.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、and S. Ueno、 "Requirements of an MPLS Transport Profile"、RFC 5654 、2009年9月、<http://www.rfc-editor.org/info/rfc5654>。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010, <http://www.rfc-editor.org/info/rfc5921>.
[RFC5921] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、and L. Berger、 "A Framework for MPLS in Transport Networks"、RFC 5921、 2010年7月、<http://www.rfc-editor.org/info/rfc5921>。
[RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, September 2010, <http://www.rfc-editor.org/info/rfc5951>.
[RFC5951]ラム、K。、マンスフィールド、S。、およびE.グレイ、「MPLSベースのトランスポートネットワークのネットワーク管理要件」、RFC 5951、2010年9月、<http://www.rfc-editor.org/info / rfc5951>。
[RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011, <http://www.rfc-editor.org/info/rfc6372>.
[RFC6372] Sprecher、N.、Ed。、and A. Farrel、Ed。、 "MPLS Transport Profile（MPLS-TP）Survivability Framework"、RFC 6372、September 2011、<http://www.rfc-editor.org / info / rfc6372>。
[RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, 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、 2011年10月、<http://www.rfc-editor.org/info/rfc6378>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258>。
[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, 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、2014年6月、<http://www.rfc-editor.org/info/rfc7271>。
[G.7710] International Telecommunication Union, "Common equipment management function requirements", ITU-T Recommendation G.7710/Y.1701, February 2012.
[G.7710]国際電気通信連合、「一般的な機器管理機能要件」、ITU-T勧告G.7710 / Y.1701、2012年2月。
[G.808.1] International Telecommunication Union, "Generic Protection Switching - Linear trail and subnetwork protection", ITU-T Recommendation G.808.1, May 2014.
[G.808.1] International Telecommunication Union、「Generic Protection Switching-Linear Trail and subnetwork protection」、ITU-T Recommendation G.808.1、2014年5月。
Acknowledgements
謝辞
This document is the outcome of discussions on Shared Mesh Protection for MPLS-TP. The authors would like to thank all contributors to these discussions, and especially Eric Osborne for facilitating them.
このドキュメントは、MPLS-TPの共有メッシュ保護に関する議論の結果です。著者はこれらの議論へのすべての貢献者、特にそれらを促進するためのエリック・オズボーンに感謝したいと思います。
We would also like to thank Matt Hartley for working on the English review and Lou Berger for his valuable comments and suggestions on this document.
また、英語のレビューに取り組んだMatt Hartleyと、このドキュメントに対する貴重なコメントと提案を提供してくれたLou Bergerにも感謝します。
Contributors
貢献者
David Allan Ericsson EMail: david.i.allan@ericsson.com
デビッドアランエリクソンEメール：david.i.allan@ericsson.com
Daniel King Old Dog Consulting EMail: daniel@olddog.co.uk
Daniel King Old Dog Consulting Eメール：daniel@olddog.co.uk
Taesik Cheung ETRI EMail: cts@etri.re.kr
Taesik Cheung ETRI Eメール：cts@etri.re.kr
Authors' Addresses
著者のアドレス
Yaacov Weingarten 34 Hagefen St. Karnei Shomron, 4485500 Israel
Yaacov Weingarten 34 Hagefen St. Karnei Shomron、4485500 Israel
EMail: wyaacov@gmail.com
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 United States
Sam Aldrin Huawei Technologies 2330 Central Expressway Santa Clara、CA 95050アメリカ合衆国
EMail: aldrin.ietf@gmail.com
Ping Pan Infinera
ピンパンインフィネラ
EMail: ppan@infinera.com
Jeong-dong Ryoo ETRI 218 Gajeongno Yuseong, Daejeon 305-700 South Korea
Jeong-dong Ryoo ETRI 218 Gajeongno Yuseong、Daejeon 305-700 South Korea
EMail: ryoo@etri.re.kr
Greg Mirsky Ericsson
グレッグ・ミルスキー・エリクソン
EMail: gregory.mirsky@ericsson.com