RFC 5817 - Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5817
タイトル : RFC 5817 - MPLSおよび一般化されたMPLSトラフィックエンジニアリングネットワークの優雅なシャットダウン
翻訳編集 : 自動生成

[要約] 要約：RFC 5817は、MPLSおよび一般化MPLSトラフィックエンジニアリングネットワークでの優雅なシャットダウンの方法について説明しています。目的：このRFCの目的は、ネットワークのシャットダウン時にトラフィックの喪失を最小限に抑えるための手法を提供することです。

Internet Engineering Task Force (IETF)                            Z. Ali
Request for Comments: 5817                                   JP. Vasseur
Category: Informational                                        A. Zamfir
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                               J. Newton
                                                      Cable and Wireless
                                                              April 2010

Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks

MPLSおよび一般化されたMPLSトラフィックエンジニアリングネットワークの優雅なシャットダウン

Abstract

概要

MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.

MPLS-TE Graceful Shutdownは、トラフィックエンジニアリング（TE）対応のネットワークでノードを明示的に通知する方法であり、リンクまたはラベルスイッチングルーター（LSR）全体のTE機能が無効になることを可能にします。MPLS-TEの優雅なシャットダウンメカニズムは、ネットワークで計画された停止に対処するために調整されています。

This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions.

このドキュメントは、ネットワークリソースの計画されたシャットダウンが発生した場合にトラフィックの中断を減らすか排除するための要件とプロトコルメカニズムを提供します。これらの操作は、MPLS-TEとその一般化されたMPLS（GMPLS）拡張機能の両方に等しく適用できます。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

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）の製品です。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/rfc5817.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5817で取得できます。

著作権表示

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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Requirements for Graceful Shutdown ..............................4
   4. Mechanisms for Graceful Shutdown ................................5
      4.1. OSPF / IS-IS Mechanisms for Graceful Shutdown ..............5
      4.2. RSVP-TE Signaling Mechanisms for Graceful Shutdown .........6
   5. Manageability Considerations ....................................8
   6. Security Considerations .........................................8
   7. Acknowledgments .................................................8
   8. References ......................................................9
      8.1. Normative References .......................................9
      8.2. Informative References .....................................9

1. Introduction

1. はじめに

When outages in a network are planned (e.g., for maintenance purposes), some mechanisms can be used to avoid traffic disruption. This is in contrast with unplanned network element failure, where traffic disruption can be minimized thanks to recovery mechanisms, but may not be avoided. Therefore, a Service Provider may desire to gracefully (temporarily or indefinitely) remove a TE link, a group of TE links, or an entire node for administrative reasons such as link maintenance, software/hardware upgrade at a node, or significant TE configuration changes. In all these cases, the goal is to minimize the impact on the traffic carried over TE LSPs in the network by triggering notifications so as to gracefully reroute such flows before the administrative procedures are started.

ネットワーク内の停止が計画されている場合（メンテナンスの目的など）、トラフィックの混乱を避けるためにいくつかのメカニズムを使用できます。これは、回復メカニズムのおかげでトラフィックの混乱を最小限に抑えることができるが、回避することはできませんが、計画外のネットワーク要素障害とは対照的です。したがって、サービスプロバイダーは、リンクのメンテナンス、ノードでのソフトウェア/ハードウェアアップグレード、または大幅なTE構成の変更などの管理上の理由で、TEリンク、TEリンクのグループ、またはノード全体を優雅に（一時的または無期限に）削除することを望む場合があります。。これらすべてのケースでは、目標は、管理手順が開始される前にそのようなフローを優雅に再ルーティングすることにより、通知をトリガーすることにより、ネットワーク内のTELSPを介したトラフィックへの影響を最小限に抑えることです。

These operations are equally applicable to both MPLS-TE [RFC3209] and its Generalized MPLS (GMPLS) extensions [RFC3471] [RFC3473].

これらの操作は、MPLS-TE [RFC3209]とその一般化MPLS（GMPLS）拡張[RFC3471] [RFC3473]の両方に等しく適用できます。

This document describes the mechanisms that can be used to gracefully shut down MPLS-TE / GMPLS-TE on a resource such as a TE link, a component link within a bundled TE link, a label resource, or an entire TE node.

このドキュメントでは、TEリンク、バンドルされたTEリンク内のコンポーネントリンク、ラベルリソース、またはTEノード全体などのリソースでMPLS-TE / GMPLS-TEを優雅にシャットダウンするために使用できるメカニズムについて説明します。

Graceful shutdown of a resource may require several steps. These steps can be broadly divided into two sets: disabling the resource in the control plane and disabling the resource in the data plane. The node initiating the graceful shutdown condition introduces a delay between the two sets to allow the control plane to gracefully divert the traffic away from the resource being gracefully shut down. The trigger for the graceful shutdown event is a local matter at the node initiating the graceful shutdown. Typically, graceful shutdown is triggered for administrative reasons, such as link maintenance or software/hardware upgrade.

リソースの優雅なシャットダウンには、いくつかのステップが必要になる場合があります。これらの手順は、コントロールプレーンのリソースを無効にし、データプレーンのリソースを無効にするという2つのセットに大きく分けることができます。優雅なシャットダウン条件を開始するノードは、2つのセット間に遅延を導入し、コントロールプレーンが優雅にシャットダウンされるリソースからトラフィックを優雅に迂回させることができます。優雅なシャットダウンイベントのトリガーは、優雅なシャットダウンを開始するノードのローカルな問題です。通常、リンクのメンテナンスやソフトウェア/ハードウェアのアップグレードなど、管理上の理由で優雅なシャットダウンがトリガーされます。

2. Terminology

2. 用語

LSR: Label Switching Router. The terms node and LSR are used interchangeably in this document.

LSR：ラベルスイッチングルーター。このドキュメントでは、ノードとLSRという用語が交換可能に使用されます。

GMPLS: The term GMPLS is used in this document to refer to packet MPLS-TE, as well as GMPLS extensions to MPLS-TE.

GMPLS：GMPLSという用語は、このドキュメントで使用され、Packet MPLS-TEとMPLS-TEへのGMPLS拡張を参照しています。

TE Link: The term TE link refers to a single link or a bundle of physical links or FA-LSPs (see below) on which traffic engineering is enabled.

TEリンク：TEリンクという用語は、トラフィックエンジニアリングが有効になっている単一のリンクまたは物理リンクまたはFA-LSPのバンドル（以下を参照）を指します。

TE LSP: A Traffic Engineered Label Switched Path.

TE LSP：トラフィックエンジニアリングラベルの切り替えパス。

S-LSP: A segment of a TE LSP.

s-lsp：te lspのセグメント。

FA-LSP (Forwarding Adjacency LSP): An LSP that is announced as a TE link into the same instance of the GMPLS control plane as the one that was used to create the LSP [RFC4206].

FA-LSP（転送隣接LSP）：LSP [RFC4206]を作成するために使用されたものと同じインスタンスのGMPLSコントロールプレーンと同じインスタンスへのTEリンクとして発表されるLSP。

ISIS-LSP: Link State Packet that is generated by IS-IS routers and that contains routing information.

ISIS-LSP：IS-ISルーターによって生成され、ルーティング情報が含まれるリンク状態パケット。

LSA: Link State Advertisement that is generated by OSPF routers and that contains routing information.

LSA：OSPFルーターによって生成され、ルーティング情報が含まれている状態広告をリンクします。

TE LSA / TE-IS-IS-LSP: The traffic engineering extensions to OSPF / IS-IS.

TE LSA / TE-IS-IS-LSP：OSPF / IS-ISのトラフィックエンジニアリング拡張。

Head-end node: Ingress LSR that initiated signaling for the Path.

ヘッドエンドノード：パスのシグナル伝達を開始したIngress LSR。

Border node: Ingress LSR of a TE LSP segment (S-LSP).

ボーダーノード：TE LSPセグメント（S-LSP）のIngress LSR。

PCE (Path Computation Element): An entity that computes the routes on behalf of its clients (PCC) [RFC4655].

PCE（PATH計算要素）：クライアントに代わってルートを計算するエンティティ（PCC）[RFC4655]。

Last-resort resource: If a path to a destination from a given head-end node cannot be found upon removal of a resource (e.g., TE link, TE node), the resource is called "last resort" to reach that destination from the given head-end node.

最終リゾートリソース：特定のヘッドエンドノードからの宛先へのパスがリソース（TEリンク、TEノードなど）を削除すると見つからない場合、リソースは「最後の手段」と呼ばれ、ヘッドエンドノードが与えられました。

3. Requirements for Graceful Shutdown

3. 優雅なシャットダウンの要件

This section lists the requirements for graceful shutdown in the context of GMPLS.

このセクションには、GMPLSのコンテキストでの優雅なシャットダウンの要件をリストします。

- Graceful shutdown is required to address graceful removal of one TE link, one component link within a bundled TE link, a set of TE links, a set of component links, label resources, or an entire node.

- 1つのTEリンクの優雅な削除、バンドルされたTEリンク内の1つのコンポーネントリンク、TEリンクのセット、コンポーネントリンクのセット、ラベルリソース、またはノード全体に対処するには、優雅なシャットダウンが必要です。

- Once an operator has initiated graceful shutdown of a network resource, no new TE LSPs may be set up that use the resource. Any signaling message for a new TE LSP that explicitly specifies the resource, or that would require the use of the resource due to local constraints, is required to be rejected as if the resource were unavailable.

- オペレーターがネットワークリソースの優雅なシャットダウンを開始すると、リソースを使用する新しいTE LSPをセットアップすることはできません。リソースを明示的に指定する新しいTE LSPのシグナリングメッセージ、またはローカルの制約のためにリソースの使用が必要な場合は、リソースが利用できないかのように拒否する必要があります。

- It is desirable for new TE LSP set-up attempts that would be rejected because of graceful shutdown of a resource (as described in the previous requirement) to avoid any attempt to use the resource by selecting an alternate route or other resources.

- 代替ルートまたは他のリソースを選択してリソースを使用しようとする試みを回避するために、リソースの優雅なシャットダウン（以前の要件で説明されている）のために拒否される新しいTE LSPセットアップの試みが望ましいです。

- If the resource being shut down is a last-resort resource, based on a local decision, the node initiating the graceful shutdown procedure can cancel the shutdown operation.

- シャットダウン中のリソースがローカルの決定に基づいて最後のリゾートリソースである場合、グレースフルシャットダウン手順を開始するノードはシャットダウン操作をキャンセルできます。

- It is required to give the ingress node the opportunity to take actions in order to reduce or eliminate traffic disruption on the TE LSPs that are using the network resources that are about to be shut down.

- 閉鎖されようとしているネットワークリソースを使用しているTE LSPのトラフィック破壊を減らすか排除するために、イングレスノードにアクションを実行する機会を与える必要があります。

- Graceful shutdown mechanisms are equally applicable to intra-domain TE LSPs and those spanning multiple domains, as defined in [RFC4726]. Examples of such domains include IGP areas and Autonomous Systems.

- [RFC4726]で定義されているように、優雅なシャットダウンメカニズムは、ドメイン内TE LSPおよび複数のドメインにまたがるものに等しく当てはまります。このようなドメインの例には、IGP領域と自律システムが含まれます。

- Graceful shutdown is equally applicable to packet and non-packet networks.

- 優雅なシャットダウンは、パケットおよび非パケットネットワークに等しく適用できます。

- In order to make rerouting effective, it is required that when a node initiates the graceful shutdown of a resource, it notifies all other network nodes about the TE resource under graceful shutdown.

- 再ルーティングを効果的にするためには、ノードがリソースの優雅なシャットダウンを開始するときに、優雅なシャットダウンの下でTEリソースに関する他のすべてのネットワークノードに通知する必要があります。

- Depending on switching technology, it may be possible to shut down a label resource, e.g., shutting down a lambda in a Lambda Switch Capable (LSC) node.

- スイッチングテクノロジーに応じて、ラベルリソースをシャットダウンすることができる場合があります。たとえば、ラムダスイッチの可能性（LSC）ノードでラムダをシャットダウンすることができます。

4. Mechanisms for Graceful Shutdown

4. 優雅なシャットダウンのメカニズム

An IGP-only solution based on [RFC3630], [RFC5305], [RFC4203] and [RFC5307] is not applicable when dealing with inter-area and inter-AS traffic engineering, as IGP flooding is restricted to IGP areas/levels. An RSVP-based solution is proposed in this document to handle TE LSPs spanning multiple domains. In addition, in order to discourage nodes from establishing new TE LSPs through the resources being shut down, existing IGP mechanisms are used for the shutdown notification.

[RFC3630]、[RFC5305]、[RFC4203]、[RFC5307]に基づくIGPのみのソリューションは、IGP洪水がIGPエリア/レベルに制限されているため、エリア間およびASトラフィックエンジニアリングを扱う場合は適用できません。このドキュメントでは、複数のドメインにまたがるTE LSPを処理するために、RSVPベースのソリューションが提案されています。さらに、シャットダウンされるリソースを介して新しいTELSPの確立を阻止するために、既存のIGPメカニズムがシャットダウン通知に使用されます。

A node where a link or the whole node is being shut down first triggers the IGP updates as described in Section 4.1 and then, with some delay to allow network convergence, uses the signaling mechanism described in Section 4.2.

リンクまたはノード全体がシャットダウンされているノードは、セクション4.1で説明されているようにIGPの更新を最初にトリガーし、次にネットワーク収束を許可するためのある程度の遅延で、セクション4.2で説明されたシグナルメカニズムを使用します。

4.1. OSPF / IS-IS Mechanisms for Graceful Shutdown

4.1. OSPF / IS-ISメカニズムは、優雅なシャットダウンのメカニズムです

This section describes the use of existing OSPF and IS-IS mechanisms for the graceful shutdown in GMPLS networks.

このセクションでは、GMPLSネットワークの優雅なシャットダウンのための既存のOSPFおよびIS-I-ISメカニズムの使用について説明します。

The OSPF and IS-IS procedures for graceful shutdown of TE links are similar to the graceful restart of OSPF and IS-IS as described in [RFC4203] and [RFC5307], respectively. Specifically, the node where graceful shutdown of a link is desired originates the TE LSA or IS-IS-LSP containing a Link TLV for the link under graceful shutdown with the Traffic Engineering metric set to 0xffffffff, 0 as unreserved bandwidth. If the TE link has LSC or FSC as its Switching Capability, then it also has 0 in the "Max LSP Bandwidth" field of the Interface Switching Capability Descriptor (ISCD) sub-TLV. A node may also specify a value that is greater than the available bandwidth in the "Minimum LSP bandwidth" field of the same ISCD sub-TLV. This would discourage new TE LSP establishment through the link under graceful shutdown.

TEリンクの優雅なシャットダウンのOSPFおよびIS-IS手順は、それぞれ[RFC4203]および[RFC5307]で説明されているように、OSPFおよびIS-ISの優雅な再起動に似ています。具体的には、リンクの優雅なシャットダウンが望まれているノードは、トラフィックエンジニアリングメトリックが0xffffffffffに設定されているグレースフルシャットダウンの下で、リンクのリンクTLVを含むTe LSAまたはIS-IS-LSPを、予約されていない帯域幅として0に由来します。TEリンクにスイッチング機能としてLSCまたはFSCがある場合、インターフェイススイッチング機能記述子（ISCD）サブTLVの「最大LSP帯域幅」フィールドに0があります。ノードは、同じISCD Sub-TLVの「最小LSP帯域幅」フィールドで利用可能な帯域幅よりも大きい値を指定することもできます。これにより、優雅なシャットダウンの下でのリンクを通じて、新しいTE LSPの確立が阻止されます。

If the graceful shutdown procedure is performed for a component link within a TE link bundle and it is not the last component link available within the TE link, the link attributes associated with the TE link are recomputed. Similarly, if the graceful shutdown procedure is performed on a label resource within a TE link, the link attributes associated with the TE link are recomputed. If the removal of the component link or label resource results in a significant bandwidth change event, a new LSA is originated with the new traffic parameters. If the last component link is being shut down, the routing procedure related to TE link removal is used.

TEリンクバンドル内のコンポーネントリンクに対して優雅なシャットダウン手順が実行され、TEリンク内で使用可能な最後のコンポーネントリンクではない場合、TEリンクに関連付けられたリンク属性が再計算されます。同様に、TEリンク内のラベルリソースで優雅なシャットダウン手順が実行される場合、TEリンクに関連付けられたリンク属性が再計算されます。コンポーネントリンクまたはラベルリソースの削除が重要な帯域幅変更イベントをもたらす場合、新しいLSAは新しいトラフィックパラメーターで発生します。最後のコンポーネントリンクがシャットダウンされている場合、TEリンクの削除に関連するルーティング手順が使用されます。

Neighbors of the node where graceful shutdown procedure is in progress continue to advertise the actual unreserved bandwidth of the TE links from the neighbors to that node, without any routing adjacency change.

グレースフルシャットダウン手順が進行中のノードの隣人は、ルーティングの隣接の変更なしに、隣人からそのノードへのTEリンクの実際の非予定の帯域幅を宣伝し続けています。

When graceful shutdown at node level is desired, the node in question follows the procedure specified in the previous section for all TE links.

ノードレベルでの優雅なシャットダウンが必要な場合、問題のノードは、すべてのTEリンクについて前のセクションで指定された手順に従います。

4.2 RSVP-TE Signaling Mechanisms for Graceful Shutdown

4.2 優雅なシャットダウンのためのRSVP-TEシグナル伝達メカニズム

As discussed in Section 3, one of the requirements for the signaling mechanism for graceful shutdown is to carry information about the resource under graceful shutdown. For this purpose, the graceful shutdown procedure uses TE LSP rerouting mechanism as defined in [RFC5710].

セクション3で説明したように、優雅なシャットダウンのシグナル伝達メカニズムの要件の1つは、優雅なシャットダウンの下でリソースに関する情報を伝えることです。この目的のために、優雅なシャットダウン手順では、[RFC5710]で定義されているように、TE LSPルースングメカニズムを使用します。

Specifically, the node where graceful shutdown of an unbundled TE link or an entire bundled TE link is desired triggers a PathErr message with the error code "Notify" and error value "Local link maintenance required", for all affected TE LSPs. Similarly, the node that is being gracefully shut down triggers a PathErr message with the error code "Notify" and error value "Local node maintenance required", for all TE LSPs. For graceful shutdown of a node, an unbundled TE link, or an entire bundled TE link, the PathErr message may contain either an [RFC2205] format ERROR_SPEC object or an IF_ID [RFC3473] format ERROR_SPEC object. In either case, it is the address and TLVs carried by the ERROR_SPEC object and not the error value that indicate the resource that is to be gracefully shut down.

具体的には、バンドルされていないTEリンクまたはバンドルされたTEリンク全体の優雅なシャットダウンが望ましいノードは、影響を受けるすべてのTE LSPに対して、エラーコード「Notify」およびエラー値「ローカルリンクのメンテナンス」を使用してPatherrメッセージをトリガーします。同様に、すべてのTE LSPに対して、エラーコード「Notify」とエラー値「ローカルノードメンテナンス」を備えたエラーコードとエラー値を使用して、優雅にシャットダウンされているノードがPatherrメッセージをトリガーします。ノードの優雅なシャットダウン、バンドルされていないTEリンク、またはバンドルされたTEリンク全体の場合、PATHERRメッセージには[RFC2205]フォーマットERROR_SPECオブジェクトまたはIF_ID [RFC3473]フォーマットERROR_SPECオブジェクトのいずれかを含めることができます。どちらの場合でも、エラー_SPECオブジェクトによって運ばれるアドレスとTLVであり、優雅にシャットダウンするリソースを示すエラー値ではありません。

MPLS-TE link bundling [RFC4201] requires that an TE LSP is pinned down to a component link. Consequently, graceful shutdown of a component link in a bundled TE link differs from graceful shutdown of unbundled TE link or entire bundled TE link. Specifically, in the former case, when only a subset of component links and not the entire bundled TE link is being shut down, the remaining component links of the bundled TE link may still be able to admit new TE LSPs. The node where graceful shutdown of a component link is desired triggers a PathErr message with the error code "Notify" and error value of "Local link maintenance required". The rest of the ERROR_SPEC object is constructed using Component Reroute Request procedure defined in [RFC5710].

MPLS-TEリンクバンドリング[RFC4201]には、TE LSPがコンポーネントリンクに固定される必要があります。その結果、バンドルされたTEリンクのコンポーネントリンクの優雅なシャットダウンは、バンドルされていないTEリンクまたはバンドルされたTEリンク全体の優雅なシャットダウンとは異なります。具体的には、前者のケースでは、バンドルされたTEリンク全体がシャットダウンされていないコンポーネントリンクのサブセットのみがシャットダウンされている場合、バンドルされたTEリンクの残りのコンポーネントリンクは、新しいTE LSPを認めることができる場合があります。コンポーネントリンクの優雅なシャットダウンが望まれているノードは、エラーコード「Notify」と「ローカルリンクメンテナンスが必要」のエラー値を使用してPatherrメッセージをトリガーします。ERROR_SPECオブジェクトの残りの部分は、[RFC5710]で定義されたコンポーネントREROUTE要求手順を使用して構築されます。

If graceful shutdown of a label resource is desired, the node initiating this action triggers a PathErr message with the error codes and error values of "Notify/Local link maintenance required". The rest of the ERROR_SPEC object is constructed using the Label Reroute Request procedure defined in [RFC5710].

ラベルリソースの優雅なシャットダウンが必要な場合、このアクションを開始するノードは、「通知/ローカルリンクメンテナンスが必要」のエラーコードとエラー値を使用してPatherrメッセージをトリガーします。ERROR_SPECオブジェクトの残りの部分は、[RFC5710]で定義されたラベルReroute要求手順を使用して構築されます。

When a head-end node, a transit node, or a border node receives a PathErr message with the error code "Notify" and error value "Local link maintenance required" or "Local node maintenance required", it follows the procedures defined in [RFC5710] to reroute the traffic around the resource being gracefully shut down. When performing path computation for the new TE LSP, the head-end node or border node avoids using the TE resources identified by the ERROR_SPEC object. If the PCE is used for path computation, the head-end (or border) node acting as PCC specifies in its requests to the PCE that path computation should avoid the resource being gracefully shut down. The amount of time the head-end node or border node avoids using the TE resources identified by the IP address contained in the PathErr is based on a local decision at that node.

ヘッドエンドノード、トランジットノード、またはボーダーノードがエラーコード「Notify」とエラー値「ローカルリンクメンテナンスが必要」または「ローカルノードメンテナンスが必要」を使用してPatherRメッセージを受信すると、[で定義された手順に従います。RFC5710]リソース周辺のトラフィックを優雅にシャットダウンすること。新しいTE LSPのパス計算を実行するとき、ヘッドエンドノードまたはボーダーノードは、ERROR_SPECオブジェクトによって識別されたTEリソースの使用を避けます。PCEがPATH計算に使用される場合、PCCとして機能するヘッドエンド（または境界）ノードは、PCHへの要求で、パス計算がリソースが優雅にシャットダウンされることを避ける必要があることを指定します。ヘッドエンドノードまたはボーダーノードがPATHERRに含まれるIPアドレスによって識別されたTEリソースの使用を避ける時間は、そのノードのローカル決定に基づいています。

If the node initiating the graceful shutdown procedure receives a path setup request for a new tunnel-using resource being gracefully shut down, it sends a PathErr message with "Notify" error code in the ERROR SPEC object and an error value consistent with the type of resource being gracefully shut down. However, based on a local decision, if an existing tunnel continues to use the resource being gracefully shut down, the node initiating the graceful shutdown procedure may allow that resource being gracefully shut down to be used as a "last resort". The node initiating the graceful shutdown procedure can distinguish between new and existing tunnels by inspecting the SENDER TEMPLATE and SESSION objects.

優雅なシャットダウン手順を開始するノードが、優雅にシャットダウンされる新しいトンネル使用リソースのパスセットアップ要求を受信した場合、エラー仕様オブジェクトの「通知」エラーコードとエラー値を含むPatherRメッセージを送信します。リソースが優雅にシャットダウンされています。ただし、ローカルの決定に基づいて、既存のトンネルが優雅にシャットダウンされているリソースを使用し続けている場合、優雅なシャットダウン手順を開始するノードは、そのリソースが「最後の手段」として使用されるように優雅にシャットダウンすることを可能にすることができます。優雅なシャットダウン手順を開始するノードは、送信者テンプレートとセッションオブジェクトを検査することにより、新しいトンネルと既存のトンネルを区別できます。

If the resource being shut down is a last-resort resource, it can be used; i.e., based on a local decision, the node initiating the graceful shutdown procedure can cancel the shutdown operation. Similarly, based on a local decision, the node initiating the graceful shutdown procedure can delay the actual removal of resource for forwarding. This is to give time to the network to move traffic from the resource being shut down. For this purpose, the node initiating graceful shutdown procedure follows the Reroute Request Timeout procedure defined in [RFC5710].

シャットダウンするリソースが最終リゾートリソースである場合、使用できます。つまり、ローカルの決定に基づいて、優雅なシャットダウン手順を開始するノードは、シャットダウン操作をキャンセルできます。同様に、ローカルの決定に基づいて、優雅なシャットダウン手順を開始するノードは、転送用のリソースの実際の削除を遅らせる可能性があります。これは、シャットダウン中のリソースからトラフィックを移動するためにネットワークに時間を与えることです。この目的のために、優雅なシャットダウン手順を開始するノードは、[RFC5710]で定義されているReroute要求タイムアウト手順に従います。

5. Manageability Considerations

5. 管理可能性の考慮事項

When a TE link is being shut down, a linkDown trap as defined in [RFC2863] should be generated for the TE link. Similarly, if a bundled TE link is being shut down, a linkDown trap as defined in [RFC2863] should be generated for the bundled TE link, as well as for each of its component links. If a TE node is being shut down, a linkDown trap as defined in [RFC2863] should be generated for all TE links at the node.

TEリンクがシャットダウンされている場合、[RFC2863]で定義されているリンクダウントラップをTEリンク用に生成する必要があります。同様に、バンドルされたTEリンクがシャットダウンされている場合、[RFC2863]で定義されているリンクダウントラップは、バンドルされたTEリンクとそのコンポーネントリンクごとに生成する必要があります。TEノードがシャットダウンされている場合、[RFC2863]で定義されているリンクダウントラップを、ノードのすべてのTEリンクに対して生成する必要があります。

6. Security Considerations

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

This document introduces no new security considerations as it describes usage of existing formats and mechanisms. This document relies on existing procedures for advertisement of TE LSA / IS-IS-LSPs containing Link TLVs. Tampering with TE LSAs / IS-IS-LSPs may have an effect on traffic engineering computations, and it is suggested that any mechanisms used for securing the transmission of normal LSAs / IS-IS-LSPs be applied equally to all Opaque LSAs / IS-IS-LSPs that this document uses. Existing security considerations specified in [RFC3630], [RFC5305], [RFC4203], [RFC5307], and [MPLS-GMPLS-SEC] remain relevant and suffice. Furthermore, the Security Considerations section in [RFC5710] and section 9 of [RFC4736] should be used for understanding the security considerations related to the formats and mechanisms used in this document.

このドキュメントでは、既存の形式とメカニズムの使用法を説明するため、新しいセキュリティ上の考慮事項は紹介されません。このドキュメントは、リンクTLVを含むTE LSA / IS-IS-LSPの広告の既存の手順に依存しています。TE LSAS / IS-IS-LSPの改ざんは、トラフィックエンジニアリング計算に影響を与える可能性があり、通常のLSA / IS-IS-IS-LSPの送信を確保するために使用されるメカニズムは、すべての不透明LSA / is-に等しく適用されることが示唆されています。このドキュメントが使用するIS-LSP。[RFC3630]、[RFC5305]、[RFC4203]、[RFC5307]、および[MPLS-GMPLS-SEC]で指定された既存のセキュリティ上の考慮事項は、関連性があり、十分です。さらに、[RFC5710]の[RFC5710]および[RFC4736]のセクション9のセクションセクションは、このドキュメントで使用される形式とメカニズムに関連するセキュリティ考慮事項を理解するために使用する必要があります。

7. Acknowledgments

7. 謝辞

The authors would like to thank Adrian Farrel for his detailed comments and suggestions. The authors would also like to acknowledge useful comments from David Ward, Sami Boutros, and Dimitri Papadimitriou.

著者は、彼の詳細なコメントと提案について、エイドリアン・ファレルに感謝したいと思います。著者はまた、David Ward、Sami Boutros、およびDimitri Papadimitriouからの有用なコメントを認めたいと考えています。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.

[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、9月1997年。

[RFC5710] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710, January 2010.

[RFC5710] Berger、L.、Papadimitriou、D。、およびJp。Vasseur、「PatherrメッセージはMPLSおよびGMPLS LSP Reroutesをトリガーしました」、RFC 5710、2010年1月。

8.2. Informative References

8.2. 参考引用

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。

[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.

[RFC4736] Vasseur、Jp。、ed。、ekejiri、Y。、およびR. Zhang、「マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）の再オプチミー化（TE）ゆるいルーティングラベルスイッチングパス（LSP）」、RFC 4736、2006年11月。

[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.

[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、RFC 3630、2003年9月。

[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.

[RFC5305] Li、T。およびH. Smit、「IS-IS Traffic Engineering for Traffic Engineering」、RFC 5305、2008年10月。

[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.

[RFC4203] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。

[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.

[RFC5307] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、2008年10月。

[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。

[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。

[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.

[RFC4726] Farrel、A.、Vasseur、J.-P。、およびA. Ayyangar、「ドメイン間マルチプロトコルラベルスイッチングトラフィックエンジニアリングのフレームワーク」、RFC 4726、2006年11月。

[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。

[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチドパス（LSP）階層」、2005年10月。

[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.

[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。

[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.

[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。

[MPLS-GMPLS-SEC] Luyuan F., Ed., "Security Framework for PLS and GMPLS Networks", Work in Progress, March 2010.

[MPLS-GMPLS-SEC] Luyuan F.、ed。、「PLSおよびGMPLSネットワークのセキュリティフレームワーク」、2010年3月、進行中の作業。

Authors' Addresses

著者のアドレス

Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada EMail: zali@cisco.com

Zafar Ali Cisco Systems、Inc.、2000イノベーションドライブカナタ、オンタリオ州、K2K 3E8カナダメール：zali@cisco.com

Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: jpv@cisco.com

Jean Philippe Vasseur Cisco Systems、Inc。300 Beaver Brook Road Boxborough、MA 01719 USAメール：jpv@cisco.com

Anca Zamfir Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada EMail: ancaz@cisco.com

Anca Zamfir Cisco Systems、Inc。2000イノベーションドライブカナタ、オンタリオ州、K2K 3E8カナダメール：ancaz@cisco.com

Jonathan Newton Cable and Wireless EMail: jonathan.newton@cw.com

Jonathan Newtonケーブルとワイヤレスメール：jonathan.newton@cw.com