[要約] RFC 8131は、GMPLSのエンドツーエンドの復旧とリソース共有のためのRSVP-TEシグナリング手順に関するものです。このRFCの目的は、ネットワークの復旧とリソースの効率的な利用を可能にするために、RSVP-TEプロトコルの拡張を提供することです。
Internet Engineering Task Force (IETF) X. Zhang
Request for Comments: 8131 H. Zheng, Ed.
Category: Informational Huawei Technologies
ISSN: 2070-1721 R. Gandhi, Ed.
Z. Ali
Cisco Systems, Inc.
P. Brzozowski
ADVA Optical
March 2017
RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing
エンドツーエンドのGMPLS復元とリソース共有のためのRSVP-TEシグナリング手順
Abstract
概要
In non-packet transport networks, there are requirements where the Generalized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.
非パケット転送ネットワークでは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）のエンドツーエンドリカバリ方式で、復元されたLSPのリソースを保持しながら、復元されたラベルスイッチドパス（LSP）を採用する必要がある要件があります。障害発生後のネットワーク。
This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature.
このドキュメントでは、リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）シグナリングを使用してLSPアソシエーションがGMPLSエンドツーエンド回復スキームのコンテキストでどのように提供されるかをレビューします。さらに、このドキュメントでは、LSPのリソース共有ベースのセットアップとティアダウン、およびLSP復帰手順について説明します。このドキュメントでは新しいシグナリング拡張機能は定義されておらず、本質的に情報提供のみを目的としています。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8131.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8131で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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. Conventions Used in This Document ...............................4
2.1. Terminology ................................................4
2.2. Abbreviations ..............................................4
3. Overview ........................................................4
3.1. Examples of Restoration Schemes ............................5
3.1.1. 1+R Restoration .....................................5
3.1.2. 1+1+R Restoration ...................................6
3.1.2.1. 1+1+R Restoration - Variants ...............7
3.2. Resource Sharing by Restoration LSP ........................7
4. RSVP-TE Signaling Procedure .....................................8
4.1. Restoration LSP Association ................................8
4.2. Resource Sharing-Based Restoration LSP Setup ...............8
4.3. LSP Reversion .............................................10
4.3.1. Make-While-Break Reversion .........................10
4.3.2. Make-Before-Break Reversion ........................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................13
Acknowledgements .................................................14
Contributors ......................................................14
Authors' Addresses ................................................15
Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] defines a set of protocols, including Open Shortest Path First - Traffic Engineering (OSPF-TE) [RFC4203] and Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3473]. These protocols can be used to set up Label Switched Paths (LSPs) in non-packet transport networks. The GMPLS protocol extends MPLS to support interfaces capable of Time Division Multiplexing (TDM), Lambda Switching and Fiber Switching. These switching technologies provide several protection schemes [RFC4426] [RFC4427] (e.g., 1+1, 1:N, and M:N).
Generalized Multiprotocol Label Switching（GMPLS）[RFC3945]は、Open Shortest Path First-Traffic Engineering（OSPF-TE）[RFC4203]およびResource Reservation Protocol-Traffic Engineering（RSVP-TE）[RFC3473]を含む一連のプロトコルを定義します。これらのプロトコルを使用して、非パケット転送ネットワークにラベルスイッチドパス（LSP）を設定できます。 GMPLSプロトコルはMPLSを拡張して、時分割多重（TDM）、ラムダスイッチング、およびファイバースイッチングが可能なインターフェースをサポートします。これらのスイッチング技術は、いくつかの保護スキームを提供します[RFC4426] [RFC4427]（たとえば、1 + 1、1：N、およびM：N）。
RSVP-TE signaling has been extended to support various GMPLS recovery schemes, such as end-to-end recovery [RFC4872] and segment recovery [RFC4873]. As described in [RFC6689], an ASSOCIATION object with Association Type "Recovery" [RFC4872] can be signaled in the RSVP Path message to identify the LSPs for restoration. Also, an ASSOCIATION object with Association Type "Resource Sharing" [RFC4873] can be signaled in the RSVP Path message to identify the LSPs for resource sharing. Section 2.2 of [RFC6689] reviews the procedure for providing LSP associations for GMPLS end-to-end recovery, and Section 2.4 of that document reviews the procedure for providing LSP associations for sharing resources.
RSVP-TEシグナリングは、エンドツーエンドのリカバリ[RFC4872]やセグメントのリカバリ[RFC4873]など、さまざまなGMPLSリカバリスキームをサポートするように拡張されています。 [RFC6689]で説明されているように、アソシエーションタイプ "Recovery" [RFC4872]のASSOCIATIONオブジェクトをRSVPパスメッセージで通知して、復元するLSPを識別できます。また、関連タイプ「リソース共有」[RFC4873]のASSOCIATIONオブジェクトをRSVPパスメッセージで通知して、リソース共有のLSPを識別することができます。 [RFC6689]のセクション2.2は、GMPLSエンドツーエンド回復のためのLSPアソシエーションを提供する手順をレビューし、そのドキュメントのセクション2.4は、リソースを共有するためのLSPアソシエーションを提供する手順をレビューします。
Generally, GMPLS end-to-end recovery schemes have the restoration LSP set up after the failure has been detected and notified on the working LSP. For a recovery scheme with revertive behavior, a restoration LSP is set up while the working LSP and/or protecting LSP are not torn down in the control plane due to a failure. In non-packet transport networks, because working LSPs are typically set up over preferred paths, service providers would like to keep resources associated with the working LSPs reserved. This is to make sure that the service can be reverted to the preferred path (working LSP) when the failure is repaired to provide deterministic behavior and a guaranteed Service Level Agreement (SLA).
一般に、GMPLSエンドツーエンドリカバリスキームでは、障害が検出され、動作中のLSPで通知された後に、復元LSPがセットアップされます。復元動作のあるリカバリスキームの場合、障害のために機能しているLSPや保護しているLSPがコントロールプレーンで切断されない間に、復元LSPがセットアップされます。非パケット転送ネットワークでは、通常、作業LSPは優先パスを介して設定されるため、サービスプロバイダーは、作業LSPに関連付けられたリソースを予約したままにしておきたいと考えています。これは、障害が修復されて確定的な動作と保証されたサービスレベルアグリーメント（SLA）が提供されたときに、サービスを優先パス（正常なLSP）に戻すことができるようにするためです。
In this document, we review procedures for GMPLS LSP associations, resource-sharing-based LSP setup, teardown, and LSP reversion for non-packet transport networks, including the following:
このドキュメントでは、GMPLS LSPアソシエーション、リソース共有ベースのLSPセットアップ、ティアダウン、および以下を含む非パケット転送ネットワークのLSP復帰の手順を確認します。
o The procedure for providing LSP associations for the GMPLS end-to-end recovery using restoration LSP where working and protecting LSPs are not torn down and resources are kept reserved in the network after the failure.
o 障害が発生した後、LSPの機能と保護が解除されず、ネットワーク内でリソースが予約されたままの状態で、復元LSPを使用してGMPLSエンドツーエンド回復にLSPアソシエーションを提供する手順。
o The procedure for resource sharing using the Shared Explicit (SE) flag in conjunction with an ASSOCIATION object. In [RFC3209], the Make-Before-Break (MBB) method assumes the old and new LSPs share the SESSION object and signal SE flag in the SESSION_ATTRIBUTE object for sharing resources. According to [RFC6689], an ASSOCIATION object with Association Type "Resource Sharing" in the Path message enables the sharing of resources across LSPs with different SESSION objects.
o ASSOCIATIONオブジェクトと共にShared Explicit（SE）フラグを使用したリソース共有の手順。 [RFC3209]では、Make-Before-Break（MBB）メソッドは、新旧のLSPがSESSIONオブジェクトを共有し、リソースを共有するためにSESSION_ATTRIBUTEオブジェクトのSEフラグを通知することを想定しています。 [RFC6689]によれば、Pathメッセージにアソシエーションタイプ「Resource Sharing」を持つASSOCIATIONオブジェクトは、異なるSESSIONオブジェクトを持つLSP間でリソースを共有できるようにします。
o The procedures for LSP reversion and resource sharing, when using end-to-end recovery scheme with revertive behavior.
o LSP復帰とリソース共有の手順。復帰動作でエンドツーエンドのリカバリスキームを使用する場合。
This document is strictly informative in nature and does not define any RSVP-TE signaling extensions.
このドキュメントは、本質的に情報を提供するものであり、RSVP-TEシグナリング拡張を定義していません。
The reader is assumed to be familiar with the terminology in [RFC3209], [RFC3473], [RFC4872], and [RFC4873]. The terminology for GMPLS recovery is defined in [RFC4427].
読者は、[RFC3209]、[RFC3473]、[RFC4872]、および[RFC4873]の用語に精通していることを前提としています。 GMPLS回復の用語は、[RFC4427]で定義されています。
GMPLS: Generalized Multiprotocol Label Switching
GMPLS：汎用マルチプロトコルラベルスイッチング
LSP: Label Switched Path
LSP：ラベルスイッチドパス
MBB: Make-Before-Break
MBB：Make-Before-Break
MPLS: Multiprotocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
RSVP: Resource Reservation Protocol
RSVP：リソース予約プロトコル
SE: Shared Explicit (flag)
SE：明示的な共有（フラグ）
TDM: Time Division Multiplexing
TDM：時分割多重化
TE: Traffic Engineering
て： Ｔらっふぃｃ えんぎねえりんｇ
The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and discussed in this document, switches normal traffic to an alternate LSP that is not even partially established only after the working LSP failure occurs. The new alternate route is selected at the LSP head-end node, it may reuse resources of the failed LSP at intermediate nodes and may include additional intermediate nodes and/or links.
[RFC4872]で定義され、このドキュメントで説明されているGMPLSエンドツーエンドリカバリスキームは、正常なトラフィックを、動作中のLSP障害が発生した後にのみ部分的に確立されない代替LSPに切り替えます。新しい代替ルートはLSPヘッドエンドノードで選択され、中間ノードで障害が発生したLSPのリソースを再利用し、追加の中間ノードやリンクを含めることができます。
Two forms of end-to-end recovery schemes, 1+R restoration and 1+1+R restoration, are described in the following sections. Other forms of end-to-end recovery schemes also exist, and they can use these signaling techniques.
次のセクションでは、2つの形式のエンドツーエンド回復スキーム（1 + R復元と1 + 1 + R復元）について説明します。エンドツーエンドの回復スキームには他の形式も存在し、これらのシグナリング技術を使用できます。
One example of the recovery scheme considered in this document is 1+R recovery. The 1+R recovery scheme is exemplified in Figure 1. In this example, a working LSP on path A-B-C-Z is pre-established. Typically, after a failure detection and notification on the working LSP, a second LSP on path A-H-I-J-Z is established as a restoration LSP. Unlike a protecting LSP, which is set up before the failure, a restoration LSP is set up when needed, after the failure.
このドキュメントで検討されている回復スキームの一例は、1 + R回復です。 1 + Rリカバリスキームを図1に示します。この例では、パスA-B-C-Zで動作するLSPが事前に確立されています。通常、動作中のLSPで障害を検出して通知した後、パスA-H-I-J-Z上の2番目のLSPが復元LSPとして確立されます。障害の前にセットアップされる保護LSPとは異なり、障害後、必要に応じて復元LSPがセットアップされます。
+-----+ +-----+ +-----+ +-----+
| A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+
\ /
\ /
+--+--+ +-----+ +--+--+
| H +-------+ I +--------+ J |
+-----+ +-----+ +-----+
Figure 1: An Example of 1+R Recovery Scheme
図1：1 + Rリカバリスキームの例
During failure switchover with 1+R recovery scheme, in general, working LSP resources are not released so that working and restoration LSPs coexist in the network. Nonetheless, working and restoration LSPs can share network resources. Typically, when the failure has recovered on the working LSP, the restoration LSP is no longer required and is torn down while the traffic is reverted to the original working LSP.
1 + Rリカバリスキームを使用した障害スイッチオーバー中は、通常、動作中のLSPリソースは解放されないため、ネットワーク内で動作中のLSPと復元LSPが共存します。それでも、動作中のLSPと復元LSPはネットワークリソースを共有できます。通常、機能しているLSPで障害が回復すると、復元LSPは不要になり、トラフィックが元の機能しているLSPに戻されるときに破棄されます。
Another example of the recovery scheme considered in this document is 1+1+R. In 1+1+R, a restoration LSP is set up for the working LSP and/or the protecting LSP after the failure has been detected; this recovery scheme is exemplified in Figure 2.
このドキュメントで検討されている回復スキームの別の例は、1 + 1 + Rです。 1 + 1 + Rでは、障害が検出された後、現用LSPまたは保護LSP、あるいはその両方に復元LSPが設定されます。この回復スキームは、図2に例示されています。
+-----+ +-----+ +-----+
| D +-------+ E +--------+ F |
+--+--+ +-----+ +--+--+
/ \
/ \
+--+--+ +-----+ +-----+ +--+--+
| A +----+ B +-----+ C +-----+ Z |
+--+--+ +-----+ +-----+ +--+--+
\ /
\ /
+--+--+ +-----+ +--+--+
| H +-------+ I +--------+ J |
+-----+ +-----+ +-----+
Figure 2: An Example of 1+1+R Recovery Scheme
In this example, a working LSP on path A-B-C-Z and a protecting LSP on path A-D-E-F-Z are pre-established. After a failure detection and notification on the working LSP or protecting LSP, a third LSP on path A-H-I-J-Z is established as a restoration LSP. The restoration LSP, in this case, provides protection against failure of both the working and protecting LSPs. During failure switchover with the 1+1+R recovery scheme, in general, failed LSP resources are not released so that working, protecting, and restoration LSPs coexist in the network. The restoration LSP can share network resources with the working LSP, and it can share network resources with the protecting LSP. Typically, the restoration LSP is torn down when the traffic is reverted to the original LSP and is no longer needed.
この例では、パスA-B-C-Zの現用LSPとパスA-D-E-F-Zの保護LSPが事前に確立されています。動作中のLSPまたは保護LSPで障害を検出して通知した後、パスA-H-I-J-Z上の3番目のLSPが復元LSPとして確立されます。この場合、復元LSPは、機能しているLSPと保護しているLSPの両方の障害に対する保護を提供します。 1 + 1 + Rリカバリスキームを使用した障害スイッチオーバー中は、通常、障害が発生したLSPリソースは解放されないため、ネットワーク内でLSPが機能し、保護され、復元されます。復元LSPは、ネットワークリソースを現用LSPと共有でき、ネットワークリソースを保護LSPと共有できます。通常、復元LSPは、トラフィックが元のLSPに戻されて不要になったときに破棄されます。
There are two possible models when using a restoration LSP with 1+1+R recovery scheme:
1 + 1 + Rリカバリスキームで復元LSPを使用する場合、2つの可能なモデルがあります。
o A restoration LSP is set up after either a working or a protecting LSP fails. Only one restoration LSP is present at a time.
o 動作中または保護中のLSPに障害が発生した後、復元LSPがセットアップされます。復元LSPは一度に1つだけ存在します。
o A restoration LSP is set up after both the working and protecting LSPs fail. Only one restoration LSP is present at a time.
o 機能しているLSPと保護しているLSPの両方が失敗した後、復元LSPがセットアップされます。復元LSPは一度に1つだけ存在します。
Two other possible variants exist when using a restoration LSP with 1+1+R recovery scheme:
1 + 1 + Rリカバリスキームで復元LSPを使用する場合、他に2つの変形が考えられます。
o A restoration LSP is set up after either a working or protecting LSP fails. Two different restoration LSPs may be present, one for the working LSP and one for the protecting LSP.
o 動作中または保護中のLSPに障害が発生した後、復元LSPがセットアップされます。 2つの異なる復元LSPが存在する場合があります。1つは現用LSP用で、もう1つは保護LSP用です。
o Two different restoration LSPs are set up after both working and protecting LSPs fail, one for the working LSP and one for the protecting LSP.
o 機能しているLSPと保護しているLSPの両方に障害が発生すると、2つの異なる復元LSPがセットアップされます。
In all these models, if a restoration LSP also fails, it is torn down and a new restoration LSP is set up.
これらすべてのモデルで、復元LSPも失敗した場合、それは破棄され、新しい復元LSPがセットアップされます。
+-----+ +-----+
| F +------+ G +--------+
+--+--+ +-----+ |
| |
| |
+-----+ +-----+ +--+--+ +-----+ +--+--+
| A +----+ B +-----+ C +--X---+ D +-----+ E |
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 3: Resource Sharing in 1+R Recovery Scheme
図3：1 + Rリカバリスキームでのリソース共有
Using the network shown in Figure 3 as an example using 1+R recovery scheme, LSP1 (A-B-C-D-E) is the working LSP; assume it allows for resource sharing when the LSP traffic is dynamically restored. Upon detecting the failure of a link along the LSP1, e.g., Link C-D, node A needs to decide which alternative path it will use to signal restoration LSP and reroute traffic. In this case, A-B-C-F-G-E is chosen as the restoration LSP path, and the resources on the path segment A-B-C are reused by this LSP. The working LSP is not torn down and coexists with the restoration LSP. When the head-end node A signals the restoration LSP, nodes C, F, G, and E reconfigure the resources (as listed in Table 1 of this document) to set up the LSP by sending cross-connection command to the data plane.
1 + Rリカバリスキームを使用する例として図3に示すネットワークを使用すると、LSP1（A-B-C-D-E）が現用LSPになります。 LSPトラフィックが動的に復元されるときに、リソース共有が可能であると想定します。 LSP1に沿ったリンクの障害（リンクC-Dなど）を検出すると、ノードAは、復元LSPのシグナリングとトラフィックの再ルーティングに使用する代替パスを決定する必要があります。この場合、A-B-C-F-G-Eが復元LSPパスとして選択され、パスセグメントA-B-CのリソースがこのLSPによって再利用されます。機能しているLSPは破棄されず、復元LSPと共存します。ヘッドエンドノードAが復元LSPに信号を送ると、ノードC、F、G、およびEは、リソース（このドキュメントの表1に記載）を再構成して、クロスコネクトコマンドをデータプレーンに送信してLSPをセットアップします。
In the recovery scheme employing revertive behavior, after the failure is repaired, the resources on nodes C and E need to be reconfigured to set up the working LSP (using a procedure described in Section 4.3 of this document) by sending cross-connection command to the data plane. The traffic is then reverted back to the original working LSP.
リバーティブ動作を使用するリカバリスキームでは、障害が修復された後、ノードCおよびEのリソースを再構成して、（このドキュメントのセクション4.3で説明されている手順を使用して）動作中のLSPをセットアップし、クロスコネクトコマンドをに送信する必要があります。データプレーン。その後、トラフィックは元の現用LSPに戻されます。
Where GMPLS end-to-end recovery scheme needs to employ a restoration LSP while keeping resources for the working and/or protecting LSPs reserved in the network after the failure, the restoration LSP is set up with an ASSOCIATION object that has the Association Type set to "Recovery" [RFC4872], the Association ID and the Association Source set to the corresponding Association ID and the Association Source signaled in the Path message of the LSP it is restoring. For example, when a restoration LSP is signaled for a failed working LSP, the ASSOCIATION object in the Path message of the restoration LSP contains the Association ID and Association Source set to the Association ID and Association Source signaled in the working LSP for the "Recovery" Association Type. Similarly, when a restoration LSP is set up for a failed protecting LSP, the ASSOCIATION object in the Path message of the restoration LSP contains the Association ID and Association Source is set to the Association ID and Association Source signaled in the protecting LSP for the "Recovery" Association Type.
GMPLSエンドツーエンドリカバリスキームで、障害後にネットワークで予約された現用または保護LSPのリソースを維持しながら復元LSPを使用する必要がある場合、復元LSPは、関連付けタイプが設定されたASSOCIATIONオブジェクトで設定されます。 "Recovery" [RFC4872]の場合、アソシエーションIDとアソシエーションソースは、対応するアソシエーションIDに設定され、アソシエーションソースは、復元するLSPのパスメッセージで通知されます。たとえば、障害が発生した動作中のLSPに対して復元LSPが通知されると、復元LSPのPathメッセージ内のASSOCIATIONオブジェクトには、「Recovery "関連タイプ。同様に、失敗した保護LSPに対して復元LSPが設定されると、復元LSPのPathメッセージ内のASSOCIATIONオブジェクトにはアソシエーションIDが含まれ、Association Sourceは、保護LSPで通知されたAssociation IDとAssociation Sourceに設定され、リカバリー」関連付けタイプ。
The procedure for signaling the PROTECTION object is specified in [RFC4872]. Specifically, the restoration LSP used for a working LSP is set up with the P bit cleared in the PROTECTION object in the Path message of the restoration LSP and the restoration LSP used for a protecting LSP is set up with the P bit set in the PROTECTION object in the Path message of the restoration LSP.
PROTECTIONオブジェクトをシグナリングする手順は、[RFC4872]で指定されています。具体的には、現用LSPに使用される復元LSPは、復元LSPのPathメッセージのPROTECTIONオブジェクトでPビットがクリアされて設定され、保護LSPに使用される復元LSPは、PROTECTIONで設定されたPビットで設定されます。復元LSPのPathメッセージ内のオブジェクト。
GMPLS LSPs can share resources during LSP setup if they have the Shared Explicit (SE) flag set in the SESSION_ATTRIBUTE objects [RFC3209] in the Path messages that create them and:
GMPLS LSPは、それらを作成するPathメッセージのSESSION_ATTRIBUTEオブジェクト[RFC3209]でShared Explicit（SE）フラグが設定されている場合、LSPセットアップ中にリソースを共有できます。
o As defined in [RFC3209], LSPs have identical SESSION objects, and/or
o [RFC3209]で定義されているように、LSPは同一のSESSIONオブジェクトを持っています。
o As defined in [RFC6689], LSPs have matching ASSOCIATION objects with the Association Type set to "Resource Sharing" signaled in their Path messages. In this case, LSPs can have different SESSION objects i.e., a different Tunnel ID, Source and/or Destination signaled in their Path messages.
o [RFC6689]で定義されているように、LSPには、対応するASSOCIATIONオブジェクトがあり、Association TypeがPathメッセージで通知される「Resource Sharing」に設定されています。この場合、LSPは異なるSESSIONオブジェクトを持つことができます。つまり、Pathメッセージでシグナリングされる異なるトンネルID、送信元、および/または宛先です。
As described in Section 2.5 of [RFC3209], the purpose of make-before-break is not to disrupt traffic, or adversely impact network operations while TE tunnel rerouting is in progress. In non-packet transport networks, during the RSVP-TE signaling procedure, the nodes set up cross-connections along the LSP accordingly. Because the cross-connection cannot simultaneously connect a shared resource to different resources in two alternative LSPs, nodes may not be able to fulfill this request when LSPs share resources.
[RFC3209]のセクション2.5で説明されているように、make-before-breakの目的は、TEトンネルの再ルーティングの進行中にトラフィックを中断したり、ネットワーク運用に悪影響を与えたりすることではありません。非パケット転送ネットワークでは、RSVP-TEシグナリング手順中に、ノードはLSPに沿って相互接続を設定します。クロスコネクトは2つの代替LSP内の異なるリソースに共有リソースを同時に接続できないため、LSPがリソースを共有している場合、ノードはこの要求を満たすことができない場合があります。
For LSP restoration upon failure, as explained in Section 11 of [RFC4872], the reroute procedure may reuse existing resources. The action of the intermediate nodes during the rerouting process to reconfigure cross-connections does not further impact the traffic since it has been interrupted due to the already failed LSP.
[RFC4872]のセクション11で説明されているように、障害時のLSP復元では、転送手順で既存のリソースを再利用できます。クロスコネクトを再構成するための再ルーティングプロセス中の中間ノードのアクションは、すでに失敗したLSPが原因で中断されているため、トラフィックにさらに影響を与えることはありません。
The node actions for setting up the restoration LSP can be categorized into the following:
復元LSPを設定するためのノードアクションは、次のように分類できます。
-----------------------------------+---------------------------------
| Category | Action |
-----------------------------------+---------------------------------
| Reusing existing resource on | This type of node needs to |
| both input and output interfaces | reserve the existing resources |
| (nodes A & B in Figure 3). | and no cross-connection |
| | command is needed. |
-----------------------------------+---------------------------------
| Reusing an existing resource only| This type of node needs to |
| on one of the interfaces, either | reserve the resources and send |
| input or output interfaces, and | the reconfiguration |
| using new resource on the | cross-connection command to its|
| other interfaces. | corresponding data plane |
| (nodes C & E in Figure 3). | node on the interfaces where |
| | new resources are needed, and |
| | it needs to reuse the existing |
| | resources on the other |
| | interfaces. |
-----------------------------------+---------------------------------
| Using new resources on both | This type of node needs to |
| interfaces. | reserve the new resources |
| (nodes F & G in Figure 3). | and send the cross-connection |
| | command on both interfaces. |
-----------------------------------+---------------------------------
Table 1: Node Actions during Restoration LSP Setup
表1：復元LSPセットアップ中のノードアクション
Depending on whether or not the resource is reused, the node actions differ. This deviates from normal LSP setup, since some nodes do not need to reconfigure the cross-connection. Also, the judgment of whether the control plane node needs to send a cross-connection setup or modification command to its corresponding data plane node(s) relies on the check whether the LSPs are sharing resources.
リソースが再利用されるかどうかによって、ノードのアクションは異なります。一部のノードは相互接続を再構成する必要がないため、これは通常のLSPセットアップとは異なります。また、コントロールプレーンノードが対応するデータプレーンノードにクロスコネクトセットアップまたは変更コマンドを送信する必要があるかどうかの判断は、LSPがリソースを共有しているかどうかのチェックに依存します。
If the end-to-end LSP recovery scheme employs the revertive behavior, as described in Section 3 of this document, traffic can be reverted from the restoration LSP to the working or protecting LSP after its failure is recovered. The LSP reversion can be achieved using two methods:
このドキュメントのセクション3で説明されているように、エンドツーエンドのLSPリカバリスキームがリバーティブ動作を採用している場合、障害が回復した後、トラフィックを復元LSPから現用または保護LSPに戻すことができます。 LSP復帰は、次の2つの方法を使用して実現できます。
1. Make-While-Break Reversion: resources associated with a working or protecting LSP are reconfigured while removing reservations for the restoration LSP.
1. Make-While-Break Reversion：動作中または保護中のLSPに関連付けられたリソースは、復元LSPの予約を削除するときに再構成されます。
2. Make-Before-Break Reversion: resources associated with a working or protecting LSP are reconfigured before removing reservations for the restoration LSP.
2. Make-Before-Break Reversion：動作中または保護中のLSPに関連付けられたリソースは、復元LSPの予約を削除する前に再構成されます。
In non-packet transport networks, both of the above reversion methods will result in some traffic disruption when the restoration LSP and the LSP being restored are sharing resources and the cross-connections need to be reconfigured on intermediate nodes.
非パケット転送ネットワークでは、復元LSPと復元中のLSPがリソースを共有していて、中間ノードでクロスコネクトを再構成する必要がある場合、上記の両方の復帰方法でトラフィックが中断されます。
In this reversion method, restoration LSP is simply requested to be deleted by the head-end. Removing reservations for restoration LSP triggers reconfiguration of resources associated with a working or protecting LSP on every node where resources are shared. The working or protecting LSP state was not removed from the nodes when the failure occurred. Whenever reservation for restoration LSP is removed from a node, data plane configuration changes to reflect reservations of working or protecting LSP as signaling progresses. Eventually, after the whole restoration LSP is deleted, data plane configuration will fully match working or protecting LSP reservations on the whole path. Thus, reversion is complete.
この復帰方法では、復元LSPは単にヘッドエンドによって削除されるように要求されます。復元LSPの予約を削除すると、リソースが共有されているすべてのノードで、動作中または保護中のLSPに関連付けられているリソースの再構成がトリガーされます。障害が発生したときに、LSPの動作状態または保護状態がノードから削除されていませんでした。復元LSPの予約がノードから削除されると、シグナリングの進行に応じて、データプレーン構成が変更され、動作中または保護中のLSPの予約が反映されます。最終的に、復元LSP全体が削除された後、データプレーン構成は、パス全体で機能しているLSP予約または保護LSP予約と完全に一致します。したがって、復帰は完了です。
Make-while-break, while being relatively simple in its logic, has a few limitations as follows which may not be acceptable in some networks:
Make-while-breakは、そのロジックは比較的単純ですが、一部のネットワークでは受け入れられない可能性がある次のようないくつかの制限があります。
o No rollback
o の ろっｌばｃｋ
If, for some reason, reconfiguration of the data plane on one of the nodes, to match working or protecting LSP reservations, fails, falling back to restoration LSP is no longer an option, as its state might have already been removed from other nodes.
何らかの理由で、いずれかのノードのデータプレーンの再構成が機能しているLSP予約を保護するために失敗した場合、その状態が他のノードから既に削除されている可能性があるため、復元LSPへのフォールバックは選択肢ではなくなりました。
o No completion guarantee
o 完了保証なし
Deletion of an LSP provides no guarantees of completion. In particular, if RSVP packets are lost due to a node or link failure, it is possible for an LSP to be only partially deleted. To mitigate this, RSVP could maintain soft state reservations and, hence, eventually remove remaining reservations due to refresh timeouts. This approach is not feasible in non-packet transport networks, however, where control and data channels are often separated; hence, soft state reservations are not useful.
LSPの削除は、完了を保証するものではありません。特に、ノードまたはリンクの障害が原因でRSVPパケットが失われた場合、LSPが部分的にしか削除されない可能性があります。これを軽減するために、RSVPはソフト状態の予約を維持し、その結果、リフレッシュタイムアウトにより残りの予約を最終的に削除できます。このアプローチは、制御チャネルとデータチャネルが分離されていることが多い非パケット転送ネットワークでは実現できません。したがって、ソフトステート予約は役に立ちません。
Finally, one could argue that graceful LSP deletion [RFC3473] would provide a guarantee of completion. While this is true for most cases, many implementations will time out graceful deletion if LSP is not removed within certain amount of time, e.g., due to a transit node fault. After that, deletion procedures that provide no completion guarantees will be attempted. Hence, in corner cases a completion guarantee cannot be provided.
最後に、優雅なLSP削除[RFC3473]が完了の保証を提供すると主張することができます。これはほとんどの場合に当てはまりますが、トランジットノードの障害などにより、LSPが特定の時間内に削除されない場合、多くの実装は正常な削除をタイムアウトします。その後、完了を保証しない削除手順を試みます。したがって、まれなケースでは、完了保証を提供できません。
o No explicit notification of completion to head-end node
o ヘッドエンドノードへの完了の明示的な通知なし
In some cases, it may be useful for a head-end node to know when the data plane has been reconfigured to match working or protecting LSP reservations. This knowledge could be used for initiating operations like enabling alarm monitoring, power equalization, and others. Unfortunately, for the reasons mentioned above, make-while-break reversion lacks such explicit notification.
場合によっては、ヘッドエンドノードが、データプレーンが再構成されてLSP予約が機能するか保護されるかを確認するのに役立つ場合があります。この知識は、アラームの監視や電力の均等化などの操作を開始するために使用できます。残念ながら、上記の理由により、ブレーク時の復帰にはそのような明示的な通知がありません。
This reversion method can be used to overcome limitations of make-while-break reversion. It is similar in spirit to the MBB concept used for re-optimization. Instead of relying on deletion of the restoration LSP, the head-end chooses to establish a new reversion LSP that duplicates the configuration of the resources on the working or protecting LSP and uses identical ASSOCIATION and PROTECTION objects in the Path message of that LSP. Only if the setup of this LSP is successful will other (restoration and working or protecting) LSPs be deleted by the head-end. MBB reversion consists of two parts:
この復帰方法を使用すると、ブレーク時の復帰の制限を克服できます。これは、再最適化に使用されるMBBの概念と精神が似ています。ヘッドエンドは、復元LSPの削除に依存する代わりに、現用または保護LSP上のリソースの設定を複製し、そのLSPのパスメッセージで同一のASSOCIATIONおよびPROTECTIONオブジェクトを使用する新しい復帰LSPを確立することを選択します。このLSPのセットアップが成功した場合のみ、他の（復元および動作中または保護中の）LSPがヘッドエンドによって削除されます。 MBB復帰は2つの部分で構成されます。
A) Make part:
A）パーツを作る：
Creating a new reversion LSP following working or protecting the LSP. The reversion LSP shares all of the resources of the working or protecting LSP and may share resources with the restoration LSP. As the reversion LSP is created, resources are reconfigured to match its reservations. Hence, after the reversion LSP is created, data plane configuration reflects working or protecting LSP reservations.
LSPを機能または保護した後、新しい復帰LSPを作成します。復帰LSPは、現用または保護LSPのすべてのリソースを共有し、復元LSPとリソースを共有する場合があります。復帰LSPが作成されると、リソースはその予約に一致するように再構成されます。したがって、復帰LSPが作成された後、データプレーン構成は、LSP予約の機能または保護を反映します。
B) Break part:
B）部分を分割：
After the "make" part is finished, the original working or protecting and restoration LSPs are torn down, and the reversion LSP becomes the new working or protecting LSP. Removing reservations for working or restoration LSPs does not cause any resource reconfiguration on the reversion LSP -- nodes follow same procedures for the "break" part of any MBB operation. Hence, after working or protecting and restoration LSPs are removed, the data plane configuration is exactly the same as before starting restoration. Thus, reversion is complete.
「make」部分が完了すると、元の動作または保護および復元LSPが破棄され、復帰LSPが新しい動作または保護LSPになります。作業用または復元用のLSPの予約を削除しても、復帰LSPでリソースが再構成されることはありません。ノードは、MBB操作の「中断」部分について同じ手順に従います。したがって、作業中または保護中のLSPが削除された後のデータプレーン構成は、復元を開始する前とまったく同じです。したがって、復帰は完了です。
MBB reversion uses make-before-break characteristics to overcome challenges related to make-while-break reversion as follow:
MBB復帰は、make-before-break特性を使用して、以下のようにmake-while-break復帰に関連する課題を克服します。
o Rollback
o ロールバック
If the "make" part fails, the (existing) restoration LSP will still be used to carry existing traffic as the restoration LSP state was not removed. Same logic applies here as for any MBB operation failure.
「make」部分が失敗した場合、（既存の）復元LSPは、復元LSP状態が削除されなかったため、既存のトラフィックの伝送に引き続き使用されます。ここでも、MBB操作の失敗と同じロジックが適用されます。
o Completion guarantee
o 完了保証
LSP setup is resilient against RSVP message loss, as Path and Resv messages are refreshed periodically. Hence, given that the network recovers from node and link failures eventually, reversion LSP setup is guaranteed to finish with either success or failure.
PathメッセージとResvメッセージは定期的に更新されるため、LSPセットアップはRSVPメッセージの損失に対して回復力があります。したがって、ネットワークがノードとリンクの障害から最終的に回復するとすれば、復帰LSPセットアップは、成功または失敗のいずれかで終了することが保証されます。
o Explicit notification of completion to head-end node
o ヘッドエンドノードへの完了の明示的な通知
The head-end knows that the data plane has been reconfigured to match working or protecting LSP reservations on the intermediate nodes when it receives a Resv message for the reversion LSP.
ヘッドエンドは、復帰LSPのResvメッセージを受信したときに、データプレーンが中間ノードの動作中または保護LSP予約に一致するように再構成されたことを認識しています。
This document reviews procedures defined in [RFC3209], [RFC4872], [RFC4873], and [RFC6689] and does not define any new procedures. This document does not introduce any new security issues; security issues were already covered in [RFC3209], [RFC4872], [RFC4873], and [RFC6689].
このドキュメントでは、[RFC3209]、[RFC4872]、[RFC4873]、および[RFC6689]で定義されている手順を確認し、新しい手順は定義していません。このドキュメントでは、新しいセキュリティの問題は紹介されていません。セキュリティ問題はすでに[RFC3209]、[RFC4872]、[RFC4873]、および[RFC6689]でカバーされています。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<http://www.rfc-editor.org/info/rfc3209>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<http： //www.rfc-editor.org/info/rfc3473>。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, <http://www.rfc-editor.org/info/rfc4872>.
[RFC4872] Lang、J。、編、Rekhter、Y。、編、およびD. Papadimitriou、編、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリをサポートするRSVP-TE拡張"、RFC 4872、DOI 10.17487 / RFC4872、2007年5月、<http://www.rfc-editor.org/info/rfc4872>。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <http://www.rfc-editor.org/info/rfc4873>.
[RFC4873] Berger、L.、Bryskin、I.、Papadimitriou、D。、およびA. Farrel、「GMPLS Segment Recovery」、RFC 4873、DOI 10.17487 / RFC4873、2007年5月、<http：//www.rfc-editor .org / info / rfc4873>。
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, DOI 10.17487/RFC6689, July 2012, <http://www.rfc-editor.org/info/rfc6689>.
[RFC6689] Berger、L。、「Usage of the RSVP ASSOCIATION Object」、RFC 6689、DOI 10.17487 / RFC6689、2012年7月、<http://www.rfc-editor.org/info/rfc6689>。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <http://www.rfc-editor.org/info/rfc3945>.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、DOI 10.17487 / RFC3945、2004年10月、<http://www.rfc-editor.org/info/ rfc3945>。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K。、編、およびY. Rekhter、編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<http： //www.rfc-editor.org/info/rfc4203>。
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification", RFC 4426, DOI 10.17487/RFC4426, March 2006, <http://www.rfc-editor.org/info/rfc4426>.
[RFC4426] Lang、J。、編、Rajagopalan、B。、編、およびD. Papadimitriou、編、「一般化マルチプロトコルラベルスイッチング（GMPLS）リカバリ機能仕様」、RFC 4426、DOI 10.17487 / RFC4426、 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, DOI 10.17487/RFC4427, March 2006, <http://www.rfc-editor.org/info/rfc4427>.
[RFC4427] Mannie、E.、Ed。、and D. Papadimitriou、Ed。、 "Recovery（Protection and Restoration）Terminology for Generalized Multi-Protocol Label Switching（GMPLS）"、RFC 4427、DOI 10.17487 / RFC4427、March 2006、 <http://www.rfc-editor.org/info/rfc4427>。
Acknowledgements
謝辞
The authors would like to thank:
著者は感謝したいと思います：
- George Swallow for the discussions on the GMPLS restoration.
- GMPLS復元に関する議論を行うGeorge Swallow。
- Lou Berger for the guidance on this work.
- この作業のガイダンスについては、Lou Berger氏。
- Lou Berger, Vishnu Pavan Beeram, and Christian Hopps for reviewing this document and providing valuable comments.
- このドキュメントをレビューして貴重なコメントを提供してくださったLou Berger、Vishnu Pavan Beeram、およびChristian Hopps。
A special thanks to Dale Worley for his thorough review of this document.
この文書を徹底的にレビューしてくれたDale Worleyに特に感謝します。
Contributors
貢献者
Gabriele Maria Galimberti Cisco Systems, Inc.
Gabriele Maria Galimberti Cisco Systems、Inc.
Email: ggalimbe@cisco.com
Authors' Addresses
著者のアドレス
Xian Zhang Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China
X Ian Zhang hu AはテクノロジーF3-1-br＆Dセンター、hu Aは基本禁止日、長いギャング地区は非常に現実的です518129中国
Email: zhang.xian@huawei.com
Haomian Zheng (editor) Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China
ha o face Z Heng（編集者）hu AはテクノロジーF3-1-br＆Dセンター、hu Aは基本禁止日、長いギャング地区は非常に現実的518129中国
Email: zhenghaomian@huawei.com
Rakesh Gandhi (editor) Cisco Systems, Inc.
Rakesh Gandhi（編集者）Cisco Systems、Inc.
Email: rgandhi@cisco.com
Zafar Ali Cisco Systems, Inc.
Zafar Ali Cisco Systems、Inc.
Email: zali@cisco.com
Pawel Brzozowski ADVA Optical
パヴェル・ブロゾフスキーADVAオプティカル
Email: PBrzozowski@advaoptical.com