Network Working Group Y. Rekhter
Request for Comments: 4781 R. Aggarwal
Category: Standards Track Juniper Networks
January 2007
Graceful Restart Mechanism for BGP with MPLS
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2007).
著作権（C）インターネット協会（2007）。
Abstract
抽象
A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism for BGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's (LSR's) control plane restart, and specifically by the restart of its BGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.
BGPの再起動によって引き起こされるルーティングに負の影響を最小限に抑えることができますBGPのメカニズムは既に開発されており、別の文書（「BGPのためのグレースフルリスタート機構」）に記載されています。この文書では、ルータの（LSRの）コントロールプレーンの再起動をラベルスイッチングによって引き起こされるMPLS転送にマイナスの影響を最小限に抑えるために、このメカニズムを拡張し、特にそのBGP成分の再起動によってBGPはMPLSラベルを運ぶために使用されたときLSRは維持することが可能です再起動の間でMPLSフォワーディングステート。
The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network Layer Reachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried in BGP (e.g., IPv4, IPv6, etc.).
この文書で説明するメカニズムは、BGPネットワーク層到達可能性情報（NLRI）分野で運ばれたアドレスの種類に関して不可知論者です。このように、BGPに実施することができるアドレスファミリー（例えば、IPv4の、IPv6の、等）のいずれかと連携して動作します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
2. General Requirements ............................................3
3. Capability Advertisement ........................................4
4. Procedures for the Restarting LSR ...............................4
4.1. Case 1 .....................................................4
4.2. Case 2 .....................................................5
4.3. Case 3 .....................................................5
5. Alternative Procedures for the Restarting LSR ...................6
6. Procedures for a Neighbor of a Restarting LSR ...................6
7. Comparison between Alternative Procedures for the
Restarting LSR ..................................................7
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
In the case where a Label Switching Router (LSR) could preserve its MPLS forwarding state across restart of its control plane, and specifically its BGP component, and BGP is used to carry MPLS labels (e.g., as specified in [RFC3107]), it may be desirable not to perturb the LSPs going through that LSR (and specifically, the LSPs established by BGP) after failure or restart of the BGP component of the control plane. In this document, we describe a mechanism that allows this goal to be accomplished. The mechanism described in this document works in conjunction with the mechanism specified in [RFC4724]. The mechanism described in this document places no restrictions on the types of addresses (address families) that it can support.
ラベルスイッチングルータ（LSR）は、その制御プレーンの再起動を横切ってそのMPLS転送状態を保存し、特にそのBGP成分、およびBGPは、MPLSラベルを搬送するために使用されることができた場合には（で指定され、例えば、[RFC3107]）、それを望ましいことがLSRを経由するLSPを混乱させない（具体的には、BGPによって確立されたLSP）制御プレーンのBGP構成要素の故障又は再起動後。この文書では、我々は、この目標を達成することを可能にするメカニズムを説明します。本書で説明されたメカニズムは、[RFC4724]で指定された機構と連携して動作します。この文書で説明するメカニズムは、それがサポートできるアドレス（アドレスファミリ）の種類に制限を課すません。
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during BGP restart and those without it (although the latter need to implement only a subset of this mechanism). Supporting a subset of the mechanism described here by the LSRs that cannot preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart. However, the impact would be minimized if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane, and if they implement the mechanism described here. The subset includes all the procedures described in this document, except the procedures in Sections 4.1, 4.2, 4.3, and 5.
本書で説明されたメカニズムは、全てのLSR、BGPの再起動時に転送状態を維持する能力を有するものとないものの両方（この機構のサブセットのみを実装する後者の必要が）にも適用可能です。それらの制御プレーンの再起動によって引き起こされるMPLSトラフィックにマイナスの影響を減らすない再起動を横切って彼らのMPLS転送状態を保存することができないのLSRによってここで説明されたメカニズムのサブセットをサポートします。その隣人（s）は、それらの制御プレーンの再起動を横切って転送状態を維持することができる、と彼らはここで説明されたメカニズムを実装する場合である場合は、影響を最小限に抑えることになります。サブセットは、セクション4.1、4.2、4.3、及び5の手順を除き、本書に記載されているすべての手順を含みます。
For the sake of brevity, by "MPLS forwarding state" we mean one of the following mappings: <incoming label -> (outgoing label, next hop)> <Forwarding Equivalence Class (FEC) -> (outgoing label, next hop)> <incoming label -> label pop, next hop> <incoming label, label pop>
（出力ラベル、ネクストホップ）> <転送等価クラス（FEC） - >（出力ラベル、ネクストホップ）> - <着信ラベル>：「MPLSフォワーディング状態」我々は、以下のマッピングの1つを意味することにより、簡潔さのため、用<着信ラベル - >ラベルポップ、ネクストホップ> <入ラベル、ラベルポップ>
In the context of this document, the forwarding state that is referred to in [RFC4724] means MPLS forwarding state, as defined above. The term "next hop" refers to the next hop as advertised in BGP.
上記で定義した本明細書の文脈では、[RFC4724]で言及された転送状態は、MPLS転送状態を意味します。 BGPでアドバタイズされる用語「次のホップは、」次のホップを指します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
First of all, an LSR MUST implement the Graceful Restart Mechanism for BGP, as specified in [RFC4724]. Second, the LSR SHOULD be capable of preserving its MPLS forwarding state across the restart of its control plane (including the restart of BGP). Third, for the <Forwarding Equivalence Class (FEC) -> label> bindings distributed via BGP, the LSR SHOULD be able either (a) to reconstruct the same bindings as the LSR had prior to the restart (see Section 4), or (b) to create new <FEC -> label> bindings after restart, while temporarily maintaining MPLS forwarding state corresponding to both the bindings prior to the restart, as well as to the newly created bindings (see Section 5). Fourth, as long as the LSR retains the MPLS forwarding state that the LSR preserved across the restart, the labels from that state cannot be used to create new local label bindings (but could be used to reconstruct the existing bindings, as per procedures in Section 4). Finally, for each next hop, if the next hop is reachable via a Label Switched Path (LSP), then the restarting LSR MUST be able to preserve the MPLS forwarding state associated with that LSP across the restart.
[RFC4724]で指定されるようにまず、LSRは、BGPのためのグレースフルリスタートメカニズムを実装しなければなりません。第二に、LSRは、（BGPの再起動を含む）、その制御プレーンの再起動を横切ってそのMPLS転送状態を保存することができなければなりません。 BGPを介して配布ラベル>バインディング、LSRはどちらか（a）のLSRは、再起動前に持っていたのと同じバインディングを再構築することができるべきである（セクション4を参照）、または（ - <転送等価クラス（FEC）>のために、サードB）を作成する新しい<FEC - >ラベル>再起動後にバインディング、一時的に前再起動するバインディングの両方に対応するMPLS転送状態を維持したまま、ならびに新たに作成されたバインディングに（セクション5を参照）。第四に、限り、LSRはLSRが再起動に渡って保持することをMPLSフォワーディングステートを保持して、その状態からラベルが（新しいローカルラベルバインディングを作成するために使用することはできませんが、セクションの手順に従って、既存のバインディングを再構築するために使用することができ4）。次ホップがラベルスイッチパス（LSP）を介して到達可能である場合、最終的に、各次のホップのために、次に再起動LSRは、再起動を横切るそのLSPに関連付けられたMPLS転送状態を保存できなければなりません。
In the scenario where label binding on an LSR is created/maintained not only by the BGP component of the control plane, but also by other protocol components (e.g., LDP, RSVP-TE), and where the LSR supports restart of the individual components of the control plane that create/maintain label binding (e.g., restart of BGP, but no restart of LDP), the LSR MUST be able to preserve across the restart the information about which protocol has assigned which labels.
ラベルが作成されるLSRに結合シナリオでは/制御プレーンのBGP成分によってだけでなく、他のプロトコルのコンポーネントによってのみならず、維持（例えば、LDP、RSVP-TE）、およびLSRは、個々のコンポーネントの再起動をサポート/維持作成制御プレーンのラベル結合（例えば、BGPの再起動が、LDPのない再起動）、LSRは、再起動を横切っプロトコルがラベル割り当てられたかについての情報を保存できなければなりません。
After the LSR restarts, it MUST follow the procedures as specified in [RFC4724]. In addition, if the LSR is able to preserve its MPLS forwarding state across the restart, the LSR SHOULD advertise this to its neighbors by appropriately setting the Flag for Address Family field in the Graceful Restart Capability for all applicable AFI/SAFI pairs.
[RFC4724]で指定されるようにLSRの再起動後、手順に従わなければなりません。また、LSRが再起動渡ってそのMPLS転送状態を保存することができる場合、LSRは適切に適用されるすべてのAFI / SAFIペアのグレースフルリスタート機能でアドレスファミリフィールドのフラグを設定することにより、その隣にこれを宣伝すべきです。
An LSR that supports the mechanism described in this document advertises this to its peer by using the Graceful Restart Capability, as specified in [RFC4724]. The Subsequent Address Family Identifier (SAFI) in the advertised capability MUST indicate that the Network Layer Reachability Information (NLRI) field carries not only addressing Information, but also labels (see [RFC3107] for an example of where NLRI carries labels).
[RFC4724]で指定されるように本書で説明されたメカニズムをサポートするLSRは、グレースフルリスタート機能を使用してピアにこれをアドバタイズ。アドバタイズされた機能で次のアドレスファミリ識別子（SAFI）は、ネットワーク層到達可能性情報（NLRI）分野だけではなく運ぶ情報に対処するだけでなく、ラベル（NLRIがラベルを運ぶ場所の例については、[RFC3107]を参照）こと。指示しなければなりません
Procedures in this section apply when a restarting LSR is able to reconstruct the same <FEC -> label> bindings as the LSR had prior to the restart.
LSRは、再起動前に持っていたとしてラベル>バインディング - 再起動LSRが同じ<FEC>を再構築することが可能であるとき、このセクションの手順が適用されます。
The procedures described in this section are conceptual and do not have to be implemented precisely as described, as long as the implementations support the described functionality and their externally visible behavior is the same.
このセクションで説明する手順は、概念的なものであり、限り実装が説明された機能性をサポートし、それらの外部から見える現象が同じであるように、説明したように正確に実施される必要はありません。
Once the LSR completes its route selection (as specified in Section 4.1, "Procedures for the Restarting Speaker", of [RFC4724]), then in addition to the those procedures, the LSR performs one of the following:
LSRがそのルート選択（セクション4.1で指定されるように、[RFC4724]の「再起動スピーカーのための手順」）完了すると、それらの手順に加えて、LSRは、次のいずれかを実行します。
The following applies when (a) the best route selected by the LSR was received with a label, (b) that label is not an Implicit NULL, and (c) the LSR advertises this route with itself as the next hop.
LSRによって選択された（a）の最適なルートがラベルで受信されたときに、次の（b）は、そのラベルが暗黙のNULLでない、および（c）LSRは、ネクストホップとしてそれ自体とこのルートをアドバタイズし、適用します。
In this case, the LSR searches its MPLS forwarding state (the one preserved across the restart) for an entry with <outgoing label, next hop> equal to the one in the received route. If such an entry is found, the LSR no longer marks the entry as stale. In addition, if the entry is of type <incoming label, (outgoing label, next hop)> rather than <Forwarding Equivalence Class (FEC), (outgoing label, next hop)>, the LSR uses the incoming label from the entry when advertising the route to its neighbors. If the found entry has no incoming label, or if no such entry is found, the LSR allocates a new label when advertising the route to its neighbors (assuming that there are neighbors to which the LSR has to advertise the route with a label).
この場合、LSRは、受信した経路内の1つに等しい<発信ラベル、ネクストホップ>のエントリのためのMPLS転送状態（再起動を横切って保存もの）を検索します。そのようなエントリが見つかった場合、LSRはもはや古くなったとしてエントリをマークしていません。エントリがなく、タイプ<着信ラベル、（出力ラベル、ネクストホップ）>である場合に加えて、<転送等価クラス（FEC）、（出力ラベル、ネクストホップ）が>、LSRは、エントリしてから入ってくるラベルを使用します隣国へのルートをアドバタイズします。見つかったエントリは、着信ラベルを持っていない、またはそのようなエントリが見つからない場合はその隣人へのルートをアドバタイズするときに、LSRが新しいラベルを割り当てた場合（LSRがラベルを持つルートをアドバタイズするために持っているに隣人があると仮定して）。
The following applies when (a) the best route selected by the LSR was received either without a label, with an Implicit NULL label, or the route is originated by the LSR; (b) the LSR advertises this route with itself as the next hop; and (c) the LSR has to generate a (non-Implicit NULL) label for the route.
（a）は、LSRによって選択された最適な経路のいずれか受信された場合、次は、暗黙的NULLラベルと、ラベルなしで適用される、または経路がLSRによって発信されます。 （b）は、LSRは、ネクストホップとしてそれ自体とこのルートをアドバタイズします。および（c）LSRはルートの（非暗黙NULL）ラベルを生成しなければなりません。
In this case, the LSR searches its MPLS forwarding state for an entry that indicates that the LSR has to perform label pop, and the next hop equal to the next hop of the route in consideration. If such an entry is found, then the LSR uses the incoming label from the entry when advertising the route to its neighbors. If no such entry is found, the LSR allocates a new label when advertising the route to its neighbors.
この場合、LSRはLSRがラベルポップを実行しなければならないことを示しているエントリ、および考慮した経路の次のホップに等しい次のホップのためにそのMPLS転送状態を検索します。そのようなエントリが見つかった場合、その隣人へのルートをアドバタイズするときに、その後、LSRは、エントリからの着信ラベルを使用しています。そのようなエントリが見つからない場合はその隣人へのルートをアドバタイズするときに、LSRが新しいラベルを割り当てます。
The description in the above paragraph assumes that the LSR generates the same label for all the routes with the same next hop. If this is not the case and the LSR generates a unique label per each such route, then the LSR needs to preserve across the restart not only <incoming label, (outgoing label, next hop)> mapping, but also the Forwarding Equivalence Class (FEC) associated with this mapping. In such a case the LSR would search its MPLS forwarding state for an entry that (a) indicates label pop (means no outgoing label), (b) indicates that the next hop equal to the next hop of the route, and (c) has the same FEC as the route. If such an entry is found, then the LSR uses the incoming label from the entry when advertising the route to its neighbors. If no such entry is found, the LSR allocates a new label when advertising the route to its neighbors.
上記段落の説明はLSRが同じ次のホップを持つすべてのルートのための同じラベルを生成することを想定しています。このケースではなく、LSRは、このような各経路ごとに一意のラベルを生成する場合、LSRは、再起動するだけでなく、<着信ラベル、（出力ラベル、ネクストホップ）>マッピングを横切って保存する必要があるだけでなく、転送等価クラス（このマッピングに関連付けられているFEC）。 LSRが（何発信ラベルを意味しない）（a）はラベルポップを示しているエントリを、そのMPLS転送状態を検索することになるような場合には、（b）は、ルートのネクストホップへの次ホップが等しい示し、および（c）ルートと同じFECを持っています。そのようなエントリが見つかった場合、その隣人へのルートをアドバタイズするときに、その後、LSRは、エントリからの着信ラベルを使用しています。そのようなエントリが見つからない場合はその隣人へのルートをアドバタイズするときに、LSRが新しいラベルを割り当てます。
The following applies when the LSR does not set BGP next hop to self.
以下は、LSRが自己のBGPネクストホップを設定していない場合に適用されます。
In this case, the LSR, when advertising its best route for a particular NLRI, just uses the label that was received with that route. And if the route was received with no label, the LSR advertises the route with no label as well. Either way, the LSR does not allocate a label for that route.
この場合、LSRは、特定のNLRIのための最適なルートをアドバタイズするときに、ちょうどそのルートで受信されたラベルを使用しています。ルートがラベルなしで受信された場合や、LSRは、同様にラベルなしのルートをアドバタイズします。いずれにせよ、LSRは、そのルートにラベルを割り当てることはありません。
In this section, we describe an alternative to the procedures described in Section "Procedures for the restarting LSR".
このセクションでは、「再起動LSRのための手順」セクションで説明した手順の代替を説明します。
Procedures in this section apply when a restarting LSR does not reconstruct the same <FEC -> label> bindings as the LSR had prior to the restart, but instead creates new <FEC -> label> bindings after restart, while temporarily maintaining MPLS forwarding state corresponding to both the bindings prior to the restart, as well as to the newly created bindings.
一時的にMPLSフォワーディングステートを維持したまま、再起動後>ラベル>バインディング - LSRが再起動前に持っていたが、代わりに新しい<FECを作成してラベル>バインディング - 再起動LSRが同じ<FEC>を再構築していない場合、このセクションの手順が適用されます再起動前に、だけでなく、新たに作成されたバインディングにバインディングの両方に対応します。
The procedures described in this section require that for the use by BGP graceful restart, the LSR SHOULD have (at least) as many unallocated labels as labels allocated for the <FEC -> label> bindings distributed by BGP. The latter forms the MPLS forwarding state that the LSR managed to preserve across the restart. The former is used for allocating labels after the restart.
BGPによって分配ラベル>バインディング - このセクションで説明する手順は、BGPグレースフルリスタートが使用するために、LSRは<FEC>のために割り当てられたラベルのような多くの未割り当てのラベルとして（少なくとも）を有するべきであることを必要とします。後者の形態LSRが再開の間維持するために管理することをMPLS転送状態。前者は再起動後にラベルを割り当てるために使用されます。
To create (new) local label bindings after the restart, the LSR uses unallocated labels (this is pretty much the normal procedure).
再起動後（新）ローカルラベルバインディングを作成するには、LSRが（これはかなり通常の手順である）未割り当てのラベルを使用しています。
The LSR SHOULD retain the MPLS forwarding state that the LSR preserved across the restart at least until the LSR sends an End-of-RIB marker to all of its neighbors (by that time the LSR already completed its route selection process, and also advertised its Adj-RIB-Out to its neighbors). The LSR MAY retain the forwarding state even a bit longer (the amount of extra time MAY be controlled by configuration on the LSR), so as to allow the neighbors to receive and process the routes that have been advertised by the LSR. After that, the LSR SHOULD delete the MPLS forwarding state that it preserved across the restart.
LSRはLSRが、隣人のすべてにエンドの-RIBマーカーを送信し、少なくともまで、LSRが再起動に渡って保持することをMPLSフォワーディングステートを保持しなければならない（その時によってLSRは、すでにそのルート選択プロセスを完了し、またそのを宣伝その隣にADJ-RIBアウト）。ネイバーがLSRによってアドバタイズされたルートを受信して処理することを可能にするようにLSRは、（余分な時間の量は、LSRの設定によって制御されてもよい）も少し長め転送状態を保持することができます。その後、LSRは、それが再起動に渡って保持することをMPLSフォワーディングステートを削除する必要があります。
Note that while an LSR is in the process of restarting, the LSR may have not one, but two local label bindings for a given BGP route -- one that was retained from prior to restart, and another that was created after the restart. Once the LSR completes its restart, the former will be deleted. However, both of these bindings would have the same outgoing label (and the same next hop).
LSRが再開の処理中に、LSRはないものを持っている場合がありますが、与えられたBGPルートの2つのローカルラベルバインディング - 再起動する前から保持されたもの、および再起動後に作成された別の。 LSRは、その再起動を完了すると、前者が削除されます。しかし、これらのバインディングの両方が同じ出ラベル（と同じネクストホップ）を持っています。
The neighbor of a restarting LSR (the receiving router terminology used in [RFC4724]) follows the procedures specified in [RFC4724]. In addition, the neighbor treats the MPLS labels received from the restarting LSR the same way that it treats the routes received from the restarting LSR (both prior and after the restart).
再開LSR（[RFC4724]で使用される受信ルータの用語）の隣人は、[RFC4724]で指定された手順に従います。また、隣人は、MPLSラベルは、それが（従来との両方再起動後に）再起動LSRから受信したルートを扱うこと再開LSRから同じように受信扱い。
Replacing the stale routes by the routing updates received from the restarting LSR involves replacing/updating the appropriate MPLS labels.
再起動LSRから受信したルーティング更新によって古いルートを交換する適切なMPLSラベルを更新/置換することを含みます。
In addition, if the Flags in the Graceful Restart Capability received from the restarting LSR indicate that the LSR wasn't able to retain its MPLS state across the restart, the neighbor SHOULD immediately remove all the NLRI and the associated MPLS labels that it previously acquired via BGP from the restarting LSR.
また、グレースフルリスタート機能のフラグが再起動LSRから受信した場合LSRが再起動渡ってそのMPLS状態を維持することができなかったことを示している、隣人はすぐにすべてのNLRIを削除し、それが以前に取得した関連するMPLSラベルをすべきですBGPを経由して再起動LSRから。
An LSR, once it creates a binding between a label and a Forwarding Equivalence Class (FEC), SHOULD keep the value of the label in this binding for as long as the LSR has a route to the FEC in the binding. If the route to the FEC disappears and then re-appears again later, then this may result in using a different label value, as when the route re-appears, the LSR would create a new <label, FEC> binding.
それが作成したらLSRは、ラベルと転送等価クラス（FEC）との結合を、限りLSRはバインディングにFECへのルートを持っているとして、このバインディングでラベルの値を維持する必要があります。 FECへのルートが消え後にもう一度再表示された場合、これはルートが再表示されたときのように、異なるラベル値を使用してをもたらすことができる、そして、LSRはバインディング新しい<ラベル、FEC>を作成します。
To minimize the potential misrouting caused by the label change, when creating a new <label, FEC> binding, the LSR SHOULD pick up the least recently used label. Once an LSR releases a label, the LSR SHALL NOT re-use this label for advertising a <label, FEC> binding to a neighbor that supports graceful restart for at least the Restart Time, as advertised by the neighbor to the LSR. This rule SHALL apply to any label release at any time.
新しい作成するときにラベルの変更によって引き起こされる可能性misroutingを最小限に抑えるために、<ラベル、FEC>は結合、LSRは、最低使用ラベルを拾うべきです。 LSRがラベルを解放すると、LSRは、このラベルはLSRに隣人によってアドバタイズとして、少なくとも再起動時間のためのグレースフルリスタートをサポートしている隣人に結合<ラベル、FEC>を広告するために再使用してはなりません。このルールは、いつでも任意のラベルのリリースに適用しなければなりません。
Procedures described in Section 4 involve more computational overhead on the restarting router than do the procedures described in Section 5.
第5節で説明した手順を行うよりも、第4節で説明する手順は、再起動するルータ上のより多くの計算のオーバーヘッドを伴います。
Procedures described in Section 5 require twice as many labels as those described in Section 4.
第5節で説明する手順は、第4章に記載されているものの2倍のラベルが必要です。
Procedures described in Section 4 cause fewer changes to the MPLS forwarding state in the neighbors of the restarting router than the procedures described in Section 5.
項で説明する手順5節で説明する手順よりも、再起動ルータの隣人でMPLSフォワーディングステートに4原因少ないの変更を。
In principle, it is possible for an LSR to use procedures described in Section 4 for some AFI/SAFI(s) and procedures described in Section 5 for other AFI/SAFI(s).
LSRは、いくつかのAFI / SAFI（S）及び他のAFI / SAFI（S）については、セクション5に記載された手順については、セクション4で説明した手順を使用するため、原理的に、それが可能です。
The security considerations pertaining to the BGP protocol [RFC4271] remain relevant.
BGPプロトコル[RFC4271]に関連するセキュリティ上の考慮事項は、関連残ります。
In addition, the mechanism described here renders LSRs that implement it vulnerable to additional denial-of-service attacks as follows:
また、ここで説明するメカニズムは次のように追加のサービス拒否攻撃に対して脆弱にそれを実装するのLSRをレンダリングします：
An intruder may impersonate a BGP peer in order to force a failure and reconnection of the TCP connection, where the intruder sets the Forwarding State (F) bit (as defined in [RFC4724]) to 0 on reconnection. This forces all labels received from the peer to be released.
侵入者は、侵入者が再接続に0（[RFC4724]で定義されるように）転送状態（F）ビットを設定し、TCP接続の失敗や再接続を強制するために、BGPピアを偽装することができます。これは、ピアから受信したすべてのラベルが解放されるように強制します。
An intruder could intercept the traffic between BGP peers and override the setting of the Forwarding State (F) bit to be set to 0. This forces all labels received from the peer to be released.
侵入者は、BGPピア間のトラフィックを傍受し、これは、ピアから受信したすべてのラベルを解放するために強制的に0に設定することがフォワーディングステート（F）ビットの設定をオーバーライドすることができます。
All of these attacks may be countered by use of an authentication scheme between BGP peers, such as the scheme outlined in [RFC2385].
これらの攻撃の全ては、[RFC2385]に概説方式としてBGPピアとの間の認証スキームを使用することによって対抗することができます。
As with BGP carrying labels, a security issue may exist if a BGP implementation continues to use labels after expiration of the BGP session that first caused them to be used. This may arise if the upstream LSR detects the session failure after the downstream LSR has released and re-used the label. The problem is most obvious with the platform-wide label space and could result in misrouting of data to destinations other than those intended; and it is conceivable that these behaviors may be deliberately exploited, either to obtain services without authorization or to deny services to others.
BGPの実装では、最初にそれらを使用することが原因とBGPセッションの有効期限後にラベルを使用し続けた場合、BGPラベルを運ぶと同様に、セキュリティ上の問題が存在してもよいです。上流のLSRが川下のLSRがリリースしているとラベルを再使用後にセッションの障害を検出した場合、これが発生する可能性があります。問題は、プラットフォーム全体のラベルスペースで最も明白であると意図されたもの以外の目的地へのデータのmisroutingにつながる可能性。そして、これらの行動が故意に悪用されることがあり、いずれかの許可なしにサービスを取得したり、他の人にサービスを拒否することも考えられます。
In this document, the validity of the BGP session may be extended by the Restart Time, and the session may be re-established in this period. After the expiry of the Restart Time, the session must be considered to have failed, and the same security issue applies as described above.
この文書では、BGPセッションの有効性は、再起動時間によって拡張することができる、とのセッションは、この期間内に再確立することができます。再起動時間の満了後、セッションが失敗したとみなされ、上記と同様のセキュリティ上の問題が適用されなければなりません。
However, the downstream LSR may declare the session as failed before the expiration of its Restart Time. This increases the period during which the downstream LSR might reallocate the label while the upstream LSR continues to transmit data using the old usage of the label. To reduce this issue, this document requires that labels are not re-used until at least the Restart Time.
その再起動時間の満了前に失敗したとしてしかし、下流LSRはセッションを宣言することがあります。これは、アップストリームLSRがラベルの古い使用を使用してデータを送信し続けながら下流LSRがラベルを再割り当て可能性のある期間を増加させます。この問題を軽減するために、このドキュメントでは、ラベルは、少なくとも再起動時まで再使用されていないことが必要です。
We would like to thank Chaitanya Kodeboyina and Loa Andersson for their review and comments. The approach described in Section 5 is based on the idea suggested by Manoj Leelanivas.
我々は彼らのレビューとコメントをChaitanya Kodeboyinaとロア・アンダーソンに感謝したいと思います。第5節で説明したアプローチは、ManojさんLeelanivasによって提案されたアイデアに基づいています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[RFC4724]サングリ、S.、チェン、E.、フェルナンド、R.、スカダー、J.、およびY. Rekhter、 "BGPのためのグレースフルリスタート機構"、RFC 4724、2007年1月。
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.
[RFC3107] Rekhter、Y.、およびE.ローゼン、 "BGP-4でラベル情報を運ぶ"、RFC 3107、2001年5月。
Authors' Addresses
著者のアドレス
Yakov Rekhter Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークス1194 N.Mathildaアベニューサニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Rahul Aggarwal Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089
ラウール・アガーウォールジュニパーネットワークス1194 N.Mathildaアベニューサニーベール、CA 94089
EMail: rahul@juniper.net
メールアドレス：rahul@juniper.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。