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
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正常なシャットダウン明示的にトラフィックエンジニアリング（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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5817で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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
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リンクのグループ、または全ノードを削除することを望むかもしれません。これらすべてのケースでは、目標は、行政手続きが開始される前に正常な流れを再ルーティングするように通知をトリガすることによって、ネットワーク内のTE LSPを介して搬送されるトラフィックへの影響を最小限に抑えることです。
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つのセット間の遅延を導入します。正常なシャットダウンイベントのトリガーは、正常なシャットダウンを開始ノードでローカルの問題です。一般的に、正常なシャットダウンは、このようなリンクのメンテナンスやソフトウェア/ハードウェアのアップグレードなどの管理上の理由のためにトリガされます。
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は、パケット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：リンク状態パケットISISルータによって生成され、それがルーティング情報を含んでいます。
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.
ヘッドエンドノード：イングレスLSRパスのためのシグナリングを開始しました。
Border node: Ingress LSR of a TE LSP segment (S-LSP).
ボーダーノード：TE LSPセグメントのイングレスLSR（S-LSP）。
PCE (Path Computation Element): An entity that computes the routes on behalf of its clients (PCC) [RFC4655].
PCE（パス計算エレメント）：そのクライアントに代わってルートを計算エンティティ（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ノード）の除去時に見つからない場合、リソースはからその宛先に到達するために「最後の手段」と呼ばれていますヘッドエンドノード所与。
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.
- 正常なシャットダウンを束ねTEリンク、TEリンクのセット、コンポーネントリンク、ラベルリソース、または全ノードの集合内の一の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）ノードでのラムダをシャットダウンし、ラベルのリソースをシャットダウンすることも可能です。
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-唯一の解決策は、エリア間とを扱うときには適用されないAS間トラフィックエンジニアリング、IGPフラッディングがIGPエリア/レベルに制限されます。 RSVPベースのソリューションは、複数のドメインにまたがるのTE LSPを処理するために、本文書で提案されています。また、シャットダウンされているリソースを介して新たなTEのLSPを確立するノードを阻止するために、既存の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に記載のシグナリングメカニズムを使用します。
This section describes the use of existing OSPF and IS-IS mechanisms for the graceful shutdown in GMPLS networks.
このセクションでは、既存のOSPFの使用を説明し、GMPLSネットワークにおける正常なシャットダウンのためのメカニズム-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の手順は、OSPFのグレースフルリスタートと同様であり、それぞれ、[RFC4203]及び[RFC5307]に記載されているように、です。具体的には、リンクの正常な停止が望まれるノードは、TE LSAを発信またはIS-IS-LSPは、未予約帯域幅として0xFFFFFFFFを、0にトラフィックエンジニアリングメトリックセットを正常にシャットダウン下リンクのリンクTLVを含みます。 TEリンクがそのスイッチング能力としてLSCまたはFSCを有する場合、それはまた、インターフェーススイッチング能力記述子（ISCD）サブTLVの「最大LSP帯域幅」フィールドに0を有しています。ノードは、同じISCDサブ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リンクの前のセクションで指定された手順に従います。
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のためのエラーコード「通知」とエラー値「必要なローカルリンク・メンテナンス」とのPathErrメッセージをトリガします。同様に、正常にシャットダウンされているノードは、すべてのTE LSPのためのエラーコード「通知」とエラー値「ローカルノードのメンテナンス必要」とのPathErrメッセージをトリガします。ノード、アンバンドルTEリンク、または全体束ねTEリンクの正常なシャットダウンのため、のPathErrメッセージは、[RFC2205]形式ERROR_SPECオブジェクトまたはIF_ID [RFC3473]形式ERROR_SPECオブジェクトのいずれかを含んでいてもよいです。いずれの場合も、ERROR_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].
[RFC4201]を束ねMPLS-TEリンクは、TE LSPがコンポーネントリンクまで固定されることを必要とします。したがって、バンドルTEリンクにおけるコンポーネントリンクの正常なシャットダウンをアンバンドルTEリンクまたはバンドル全体TEリンクの正常なシャットダウンとは異なります。成分のみリンクの部分集合全体ではなくバンドルTEリンクがシャットダウンされているとき、具体的に、前者の場合には、束ねTEリンクの残りのコンポーネントリンクがまだ新しいTEのLSPを認めることができるかもしれません。コンポーネントリンクの正常な停止が望まれるノードは、エラーコード「通知」と「必要なローカルリンク・メンテナンス」のエラー値とのPathErrメッセージをトリガします。 ERROR_SPECオブジェクトの残りは[RFC5710]で定義されたコンポーネントの再ルーティング要求手順を使用して構築されています。
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]で定義されたラベルの再ルーティング要求手順を使用して構築されています。
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.
ヘッドエンドノード、中継ノード、またはボーダーノードはエラーコード「通知」とエラー値「必要なローカルリンク・メンテナンス」または「必要なローカルノードのメンテナンス」とのPathErrメッセージを受信すると、[で定義された手順に従いますRFC5710]は正常にシャットダウンされたリソースの周りにトラフィックを再ルーティングします。新しいTE LSPのための経路計算を行う際に、ヘッドエンドノードまたはボーダーノードはERROR_SPECオブジェクトによって識別されたTEリソースを使用して回避します。 PCEは、経路計算に使用される場合、PCCとして作用するヘッドエンド（または境界）ノードは、経路計算が正常にシャットダウンされているリソースを避けなければならないPCEへのリクエストで指定します。ヘッドエンドノードまたはボーダーノードの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.
正常なシャットダウン手順を開始ノードが正常にシャットダウンされ、新しいトンネル使用して、リソースのパス設定要求を受信した場合、それは「通知」ERRORのSPECオブジェクト内のエラー・コードのタイプと一致するエラー値とのPathErrメッセージを送信しますリソースが正常にシャットダウンされています。既存のトンネルが正常にシャットダウンされているリソースを使用し続けた場合しかし、地元の決定に基づいて、正常なシャットダウン手順を開始するノードは、そのリソースが優雅に「最後の手段」として使用することがシャットダウンされる可能性があります。正常なシャットダウン手順を開始ノードは、送信者テンプレートとSessionオブジェクトを検査することにより、新規および既存のトンネルを区別することができます。
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]で定義された再ルーティング要求タイムアウトの手順に従います。
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リンクのために生成されるべきです。
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 LSAを改ざん/ IS-IS-LSPは、トラフィックエンジニアリング計算上の効果を有していてもよく、通常のLSAの伝送を確保するために使用される任意の機構が/ IS-IS-のLSPが全て不透明LSA / IS-に等しく適用されることが示唆されていますこのドキュメントが使用する-LSPをされています。 [RFC3630]で指定された既存のセキュリティ上の考慮事項、[RFC5305]、[RFC4203]、[RFC5307]、および[MPLS-GMPLS-SEC]は、関連するままにして十分。さらに、[RFC5710]及び[RFC4736]のセクション9におけるセキュリティの考慮事項のセクションでは、この文書で使用されるフォーマットとメカニズムに関連するセキュリティ問題を理解するために使用されるべきです。
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.
作者は彼の詳細なコメントと提案のためのエードリアンファレルに感謝したいと思います。著者らはまた、デビッド・ウォード、サミBoutros、およびディミトリPapadimitriouから有益なコメントを承認したいと思います。
[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]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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]バーガー、L.、Papadimitriou、D.、およびJP。 Vasseur、 "たPathErrメッセージがトリガMPLSとGMPLS LSP再ルーティング"、RFC 5710、2010年1月。
[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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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。、エド。、池尻、Y.、およびR.張は、 "マルチプロトコルラベルの再最適化スイッチング（MPLS）トラフィックエンジニアリング（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]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[RFC5305]李、T.とH.スミットは、RFC 5305、2008年10月 "トラフィックエンジニアリングのための拡張機能-IS IS"。
[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.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[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.、エド。、およびY. Rekhter、エド。、 "IS-ISの拡張一般化マルチプロトコルラベルスイッチング（GMPLS）の支援で"、RFC 5307、2008年10月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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]ファレル、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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループ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.、エド。、 "PLSとGMPLSネットワークのセキュリティフレームワーク" が進歩、2010年3月での作業。
Authors' Addresses
著者のアドレス
Zafar Ali Cisco systems, Inc., 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada EMail: zali@cisco.com
Zafarアリシスコシステムズ社、2000イノベーションドライブカナタ、オンタリオ、K2K 3E8カナダのEメール：zali@cisco.com
Jean Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA EMail: jpv@cisco.com
ジャン・フィリップVasseurシスコシステムズ社300ビーバーブルック・ロードボックスボロー、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シスコシステムズ株式会社2000年イノベーションドライブカナタ、オンタリオ、K2K 3E8カナダEメール：ancaz@cisco.com
Jonathan Newton Cable and Wireless EMail: jonathan.newton@cw.com
ジョナサン・ニュートンケーブル・アンド・ワイヤレスEメール：jonathan.newton@cw.com