Network Working Group M. Leelanivas
Request for Comments: 3478 Y. Rekhter
Category: Standards Track Juniper Networks
R. Aggarwal
Redback Networks
February 2003
Graceful Restart Mechanism for Label Distribution Protocol
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's (LSR's) control plane restart, specifically by the restart of its Label Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart.
この文書では、MPLSを維持することができるのLSRに特にそのラベル配布プロトコル（LDP）コンポーネントの再起動により、ルータの（LSRの）コントロールプレーンの再起動をラベルスイッチングに起因するMPLSトラフィックに対する悪影響を最小限に抑えることができますメカニズムを説明します再起動の間で部品を転送します。
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.
（後者のニーズが本書で説明されたメカニズムのサブセットのみを実装するが）、この文書で説明されたメカニズムは、全てのLSR、LDP再始動時転送状態を維持する能力を有するものと有さないものの両方に適用可能です。 （再起動を横切って彼らのMPLS転送状態を保存することができないのLSRによってここで説明されたメカニズムは、それらの制御プレーンの再起動によって引き起こされるMPLSトラフィックへの悪影響を低減しないであろう（のサブセット）を支持するが、それらの隣接場合には影響を最小にします単数または複数）は、それらの制御プレーンの再起動を横切って転送状態を維持することができ、ここで説明されたメカニズムを実装します。
The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart.
メカニズムは、再起動に渡って保持する必要があるかについて最小限の仮定を行う - のメカニズムは、実際のMPLSフォワーディングステートを保存する必要があることを想定しています。メカニズムは、再起動に渡って保持することがLDP関連の状態のいずれかを必要としません。
The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study.
このドキュメントで説明する手順は、下流迷惑ラベル配布に適用されます。オンデマンドラベル配布の下流にこれらの手順を拡張することは、今後の検討課題です。
Specification of Requirements
要件の仕様
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
For the sake of brevity in the context of this document, by "the control plane" we mean "the LDP component of the control plane".
この文書の文脈では簡潔にするために、「コントロールプレーン」によって、私たちは、「コントロールプレーンのLDPコンポーネント」を意味します。
For the sake of brevity in the context of this document, by "MPLS forwarding state" we mean either <incoming label -> (outgoing label, next hop)> (non-ingress case), or <FEC->(outgoing label, next hop)> (ingress case) mapping.
することで、この文書の文脈で簡潔にするは、「MPLSフォワーディング状態は」私たちは意味のいずれか<着信ラベル - >（出力ラベル、ネクストホップ）>（非侵入の場合）、または<FEC - >（出力ラベル、ネクストホップ）>（入力の場合）マッピング。
In the case where a Label Switching Router (LSR) could preserve its MPLS forwarding state across restart of its control plane, specifically its LDP component [LDP], it is desirable not to perturb the LSPs going through that LSR (specifically, the LSPs established by LDP). In this document, we describe a mechanism, termed "LDP Graceful Restart", that allows the accomplishment of this goal.
ラベルスイッチングルータ（LSR）は、その制御プレーン、特にそのLDP成分[LDP]の再起動を横切ってそのMPLS転送状態を保存できた場合には、具体的には、LSPを確立そのLSR（経由するLSPを混乱させないことが望ましいです）LDPによります。この文書では、我々は、この目標の達成を可能にする「LDPグレースフルリスタート」と呼ばれるメカニズムを、説明します。
The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter need to implement only a subset of the mechanism described in this document). Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here.
本書で説明されたメカニズムは、全てのLSR、LDP再始動時転送状態を維持する能力を有するものと、（本書では説明されたメカニズムのサブセットのみを実装する後者の必要が）ないものの両方に適用可能です。 （再起動を横切って彼らのMPLS転送状態を保存することができないのLSRによってここで説明されたメカニズムは、それらの制御プレーンの再起動によって引き起こされるMPLSトラフィックへの悪影響を低減しないであろう（のサブセット）を支持するが、それらの隣接場合には影響を最小にします単数または複数）は、それらの制御プレーンの再起動を横切って転送状態を維持することができ、ここで説明されたメカニズムを実装します。
The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actual MPLS forwarding state has to be preserved. Clearly this is the minimum amount of state that has to be preserved across the restart in order not to perturb the LSPs traversing a restarting LSR. The mechanism does not require any of the LDP-related states to be preserved across the restart.
メカニズムは、再起動に渡って保持する必要があるものに最小限の仮定を作る - のメカニズムは、実際のMPLSフォワーディングステートを保存する必要があることを前提としています。これは明らかに再起動LSRを横断するLSPを撹乱しないようにするために再起動に渡って保持する必要がある状態の最小量です。メカニズムは、再起動に渡って保持することがLDP関連の状態のいずれかを必要としません。
In the scenario where label binding on an LSR is created/maintained not just by the LDP component of the control plane, but by other protocol components as well (e.g., BGP, RSVP-TE), and the LSR supports restart of the individual components of the control plane that create/maintain label binding (e.g., restart of LDP, but no restart of BGP), the LSR needs to preserve across the restart the information about which protocol has assigned which labels.
LSRに結合ラベルが作成されたシナリオで/ならびに制御プレーンのLDPコンポーネントによって、他のプロトコルコンポーネントによってだけでは維持（例えば、BGP、RSVP-TE）、およびLSRは、個々のコンポーネントの再起動をサポート（例えば、LDPの再起動が、BGPの無再起動）ラベルバインディングを維持/作成コントロールプレーンの、LSRは、再起動間でプロトコルがラベルを割り当てたかについての情報を保存する必要があります。
The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study.
このドキュメントで説明する手順は、下流迷惑ラベル配布に適用されます。オンデマンドラベル配布の下流にこれらの手順を拡張することは、今後の検討課題です。
An LSR indicates that it is capable of supporting LDP Graceful Restart, as defined in this document, by including the Fault Tolerant (FT) Session TLV as an Optional Parameter in the LDP Initialization message. The format of the FT Session TLV is defined in [FT-LDP]. The L (Learn from Network) flag MUST be set to 1, which indicates that the procedures in this document are used. The rest of the FT flags are set to 0 by a sender and ignored on receipt.
LSRは、LDP初期化メッセージにオプションパラメータとして、フォールトトレラント（FT）セッションTLVを含むことによって、本文書で定義されるように、それは、LDPグレースフルリスタートをサポートすることが可能であることを示しています。 FTセッションTLVのフォーマットは、[FT-LDP]で定義されています。 L（ネットワークから学ぶ）フラグは、この文書に記載されている手順を使用していることを示す、1に設定しなければなりません。 FTフラグの残りの部分は、送信者によって0に設定して、領収書の上で無視されます。
The value field of the FT Session TLV contains two components that are used by the mechanisms defined in this document: FT Reconnect Timeout, and Recovery Time.
FT再接続タイムアウト、および回復時間：FTセッションTLVの値フィールドは、この文書で定義されたメカニズムによって使用される2つのコンポーネントが含まれています。
The FT Reconnect Timeout is the time (in milliseconds) that the sender of the TLV would like the receiver of that TLV to wait after the receiver detects the failure of LDP communication with the sender. While waiting, the receiver SHOULD retain the MPLS forwarding state for the (already established) LSPs that traverse a link between the sender and the receiver. The FT Reconnect Timeout should be long enough to allow the restart of the control plane of the sender of the TLV, and specifically its LDP component to bring it to the state where the sender could exchange LDP messages with its neighbors.
FT再接続タイムアウトは、TLVの送信者が受信者が送信者とのLDP通信の障害を検出した後に待機することTLVの受信を希望時間（ミリ秒）です。待っている間、受信機は、送信機と受信機との間のリンクをトラバース（既に確立）のLSPのためのMPLS転送状態を保持すべきです。 FT再接続タイムアウトは、TLVの送信者のコントロールプレーンの再起動を可能にする十分な長さでなければならず、特にそのLDPコンポーネントは、送信者はその隣人とLDPメッセージを交換することができ状態にそれを持参します。
Setting the FT Reconnect Timeout to 0 indicates that the sender of the TLV will not preserve its forwarding state across the restart, yet the sender supports the procedures, defined in Section 3.3, "Restart of LDP communication with a neighbor LSR" of this document, and therefore could take advantage if its neighbor to preserve its forwarding state across the restart.
0にFT再接続タイムアウトを設定すると、このドキュメントの「隣接LSRとのLDP通信の再起動」、TLVの送信側は、再起動を渡る転送状態を保存しないであろうことを示して、まだ送信者は、セクション3.3で定義され、手続きをサポートしていますその隣には、再起動を渡る転送状態を維持するためならば、したがって、利点を取ることができます。
For a restarting LSR, the Recovery Time carries the time (in milliseconds) the LSR is willing to retain its MPLS forwarding state that it preserved across the restart. The time is from the moment the LSR sends the Initialization message that carries the FT Session
再起動LSRの場合は、回復時間は、LSRは、それが再起動に渡って保持することをそのMPLSフォワーディングステートを維持していく所存です（ミリ秒単位）を運びます。時間はLSRがFTセッションを運ぶ初期設定メッセージを送信した瞬間からです
TLV after restart. Setting this time to 0 indicates that the MPLS forwarding state was not preserved across the restart (or even if it was preserved, is no longer available).
再起動後TLV。 0にこの時間を設定すると、MPLSフォワーディングステートを再起動しても保持されなかったことを示している（それが保存された場合でも、または、利用できなくなりました）。
The Recovery Time SHOULD be long enough to allow the neighboring LSR's to re-sync all the LSP's in a graceful manner, without creating congestion in the LDP control plane.
回復時間は、LDPコントロールプレーンでの混雑を作成することなく、すべてのLSPの優雅な方法で、隣接LSRの再同期することを可能にするのに十分な長さであるべきです。
An LSR that supports functionality described in this document advertises this to its LDP neighbors by carrying the FT Session TLV in the LDP Initialization message.
この文書で説明した機能をサポートしていLSRは、LDP初期化メッセージにFTセッションTLVを運ぶことによって、そのLDPの隣人にこれを通知します。
This document assumes that in certain situations, as specified in section 3.1.2, "Egress LSR", in addition to the MPLS forwarding state, an LSR can also preserve its IP forwarding state across the restart. Procedures for preserving an IP forwarding state across the restart are defined in [OSPF-RESTART], [ISIS-RESTART], and [BGP-RESTART].
この文書は、特定の状況では、セクション3.1.2で指定されるように、「出力LSR」は、MPLS転送状態に加えて、LSRはまた、再起動を横切ってそのIP転送状態を保持することができることを前提としています。再起動を横切るIP転送状態を保存するための手順は、[OSPF-RESTART]、[ISIS-RESTART]、および[BGP-RESTART]で定義されています。
After an LSR restarts its control plane, the LSR MUST check whether it was able to preserve its MPLS forwarding state from prior to the restart. If not, then the LSR sets the Recovery Time to 0 in the FT Session TLV the LSR sends to its neighbors.
LSRは、その制御プレーンを再起動した後に、LSRは、再起動する前からそのMPLS転送状態を保存することができたかどうかをチェックしなければなりません。そうでない場合、LSRはLSRが隣人に送るFTセッションTLVで0に回復時間を設定します。
If the forwarding state has been preserved, then the LSR starts its internal timer, called MPLS Forwarding State Holding timer (the value of that timer SHOULD be configurable), and marks all the MPLS forwarding state entries as "stale". At the expiration of the timer, all the entries still marked as stale SHOULD be deleted. The value of the Recovery Time advertised in the FT Session TLV is set to the (current) value of the timer at the point in which the Initialization message carrying the FT Session TLV is sent.
転送状態が保存されている場合、LSRは、MPLSフォワーディングステートホールディングタイマー（そのタイマの値が設定可能であるべきである）と呼ばれるその内部タイマを開始し、マーク「古くなった」など、すべてのMPLSフォワーディングステートエントリを。タイマーの満了時に、まだ古いとしてマークされたすべてのエントリを削除する必要があります。 FTセッションTLVでアドバタイズ復旧時間の値は、FTセッションTLVを運ぶ初期化メッセージが送信された時点でタイマーの（現在の）値に設定されています。
We say that an LSR is in the process of restarting when the MPLS Forwarding State Holding timer is not expired. Once the timer expires, we say that the LSR completed its restart.
私たちは、LSRがMPLSフォワーディングステートホールディングタイマーが満了していないときに再起動のプロセスであると言います。タイマーの期限が切れると、私たちは、LSRが再起動を完了したことを言います。
The following procedures apply when an LSR is in the process of restarting.
LSRが再開の過程にある場合は、次の手順が適用されます。
If the label carried in the newly received Mapping message is not an Implicit NULL, the LSR searches its MPLS forwarding state for an entry with the outgoing label equal to the label carried in the message, and the next hop equal to one of the addresses (next hops) received in the Address message from the peer. 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 <FEC, (outgoing label, next hop)>), the LSR associates the incoming label from that entry with the FEC received in the Label Mapping message, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures. (Note that this paragraph describes the scenario where the restarting LSR is neither the egress, nor the penultimate hop that uses penultimate hop popping for a particular LSP. Note also that this paragraph covers the case where the restarting LSR is the ingress.)
新たに受信されたマッピング・メッセージで運ばれたラベルが暗黙NULLでない場合、LSRは、メッセージで運ばれたラベルに等しい発信ラベルを持つエントリのためのMPLS転送状態を検索し、アドレスの1に等しい次のホップ（次ホップ）は、ピアからのアドレスメッセージで受信しました。そのようなエントリが見つかった場合、LSRはもはや古くなったとしてエントリをマークしていません。エントリが（むしろ<FEC、（出力ラベル、ネクストホップ）>より）タイプ<着信ラベル、（出力ラベル、ネクストホップ）>である場合、FECは受信して加えて、LSRはそのエントリからの着信ラベルを関連付けますLabel Mappingメッセージ、および（LDP経由）をアドバタイズする<着信ラベル、FEC>で隣国へ。見つかったエントリは、着信ラベルを持っていない場合、またはエントリが見つからない場合、LSRは通常のLDPの手順に従います。 （この段落は再起動LSRが出ず、また、特定のLSPのために飛び出る最後から二番目のホップを使用して最後から二番目のホップでもないシナリオを説明しています。この段落は、再起動LSRが侵入した場合をカバーすることにも注意してください。）
If the label carried in the Mapping message is an Implicit NULL label, the LSR searches its MPLS forwarding state for an entry that indicates Label pop (means no outgoing label), and the next hop equal to one of the addresses (next hops) received in the Address message from the peer. If such an entry is found, the LSR no longer marks the entry as stale, the LSR associates the incoming label from that entry with the FEC received in the Label Mapping message from the neighbor, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures. (Note that this paragraph describes the scenario where the restarting LSR is a penultimate hop for a particular LSP, and this LSP uses penultimate hop popping.)
マッピングメッセージで運ばれたラベルが暗黙NULL標識である場合、LSRは、ラベルポップを示すエントリ（無発信ラベルを意味しない）ために、そのMPLS転送状態を検索し、アドレスの1に等しい次のホップ（次のホップ）を受信しましたピアからのアドレスメッセージインチそのようなエントリが見つかった場合、LSRはもはや失効としてエントリをマークし、LSRは、FECとそのエントリからの着信ラベルが隣人からLabel Mappingメッセージで受信関連付けない、及び（LDPを介して）をアドバタイズ<着信ラベル、FEC >その隣人へ。見つかったエントリは、着信ラベルを持っていない場合、またはエントリが見つからない場合、LSRは通常のLDPの手順に従います。 （この段落は再起動LSRが特定のLSPのために最後から二番目のホップであり、このLSPは、最後から二番目のホップのポッピングを使用するシナリオを記述していることに注意してください。）
The description in the above paragraph assumes that the restarting LSR generates the same label for all the LSPs that terminate on the same LSR (different from the restarting LSR), and for which the restarting LSR is a penultimate hop. If this is not the case, and the restarting LSR generates a unique label per each such LSP, then the LSR needs to preserve across the restart, not just the <incoming label, (outgoing label, next hop)> mapping, but also the FEC associated with this mapping. In such case, the LSR searches its MPLS forwarding state for an entry that (a) indicates Label pop (means no outgoing label), (b) indicates the next hop equal to one of the addresses (next hops) received in the Address message from the peer, and (c) has the same FEC as the one received in the Label Mapping message. If such an entry is found, the LSR no longer marks the entry as stale, the LSR associates the incoming label from that entry with the FEC received in the Label Mapping message from the neighbor, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures.
上記段落の説明は再起動LSRが同じLSRで終端する全てのLSP（再開LSRとは異なる）のために同一のラベルを生成することを前提とし、そのため再起動LSRは最後から二番目のホップです。このケースではありません、そして再起動LSRは、このような各LSPごとに一意のラベルを生成する場合、LSRは再起動だけでなく、<着信ラベル、（出力ラベル、ネクストホップ）>マッピングを横切って保存する必要があるだけでなく、 FECはこのマッピングに関連付けられています。このような場合、LSRは、（a）はアドレスメッセージで受信し、（b）はアドレスのいずれか（次のホップ）に等しい次のホップを示すラベルポップは（何発信ラベルを意味する）を示していることを入力するためのMPLS転送状態を検索しますピアから、及び（c）は、Label Mappingメッセージで受信したものと同じFECを有しています。そのようなエントリが見つかった場合、LSRはもはや失効としてエントリをマークし、LSRは、FECとそのエントリからの着信ラベルが隣人からLabel Mappingメッセージで受信関連付けない、及び（LDPを介して）をアドバタイズ<着信ラベル、FEC >その隣人へ。見つかったエントリは、着信ラベルを持っていない場合、またはエントリが見つからない場合、LSRは通常のLDPの手順に従います。
If an LSR determines that it is an egress for a particular FEC, the LSR is configured to generate a non-NULL label for that FEC, and that the LSR is configured to generate the same (non-NULL) label for all the FECs that share the same next hop and for which the LSR is an egress, the LSR searches its MPLS forwarding state for an entry that indicates Label pop (means no outgoing label), and the next hop equal to the next hop for that FEC. (Determining the next hop for the FEC depends on the type of the FEC. For example, when the FEC is an IP address prefix, the next hop for that FEC is determined from the IP forwarding table.) If such an entry is found, the LSR no longer marks this entry as stale, the LSR associates the incoming label from that entry with the FEC, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures.
LSRは、それが特定のFECのための出口であると判断した場合、LSRはそのFECのための非NULLラベルを生成するように構成されており、LSRは、その全てのFECのために同じ（非NULL）ラベルを生成するように構成されていること同一の次のホップを共有し、LSRが出口であり、LSRがラベルポップ（無発信ラベルを意味する）を示すエントリを、そのMPLS転送状態を検索し、そのFECのための次のホップに等しいネクストホップれます。 （FECのための次のホップを決定することは、FECのタイプに依存する。例えば、FECは、IPアドレスプレフィックスである場合、そのFECのための次のホップがIP転送テーブルから決定される。）そのようなエントリが見つかった場合、 LSRはもう古い、このエントリは、LSRはFECとそのエントリからの着信ラベルを関連付けマークしないと、その隣に（LDP経由）をアドバタイズする<着信ラベル、FEC>。見つかったエントリは、着信ラベルを持っていない場合、またはエントリが見つからない場合、LSRは通常のLDPの手順に従います。
If an LSR determines that it is an egress for a particular FEC, the LSR is configured to generate a non-NULL label for that FEC, and that the LSR is configured to generate a unique label for each such FEC, then the LSR needs to preserve across the restart, not just the <incoming label, (outgoing label, next hop)> mapping, but also the FEC associated with this mapping. In such case, the LSR would search its MPLS forwarding state for an entry that indicates Label pop (means no outgoing label), and the next hop equal to the next hop for that FEC associated with the entry (Determining the next hop for the FEC depends on the type of the FEC. For example, when the FEC is an IP address prefix, the next hop for that FEC is determined from the IP forwarding table.) If such an entry is found, the LSR no longer marks this entry as stale, the LSR associates the incoming label from that entry with the FEC, and advertises (via LDP) <incoming label, FEC> to its neighbors. If the found entry has no incoming label, or if no entry is found, the LSR follows the normal LDP procedures.
LSRは、それが特定のFECのための出口であると判断した場合、LSRはそのFECのための非NULLラベルを生成するように構成されており、LSRは、このような各FECのために一意のラベルを生成するように構成されていることを、次いでLSRをする必要があります、再起動の間でだけではなく、<着信ラベル、（出力ラベル、ネクストホップ）>マッピングするだけでなく、FECはこのマッピングに関連付けられているを維持します。このような場合、LSRは、ラベルポップ（無発信ラベルを意味する）を示すエントリ、およびFECのための次のホップを決定するエントリに関連付けられたそのFECのための次のホップに等しい次のホップ（のためにそのMPLS転送状態を検索するであろうFECのタイプに依存する。例えば、FECは、IPアドレスプレフィックスである場合、そのFECのための次のホップがIP転送テーブルから決定される。）そのようなエントリが見つかった場合、LSRはもはやマークこのエントリは、AS古い、LSRは隣人への着信FECとそのエントリからラベル、および（LDP経由）をアドバタイズする<着信ラベル、FEC>を関連付けます。見つかったエントリは、着信ラベルを持っていない場合、またはエントリが見つからない場合、LSRは通常のLDPの手順に従います。
If an LSR determines that it is an egress for a particular FEC, and the LSR is configured to generate a NULL (either Explicit or Implicit) label for that FEC, the LSR just advertises (via LDP) such label (together with the FEC) to its neighbors.
LSRは、それが特定のFECのための出口であると判断し、LSRがそのFECのために（明示的または暗黙的のいずれか）ラベルをNULLを生成するように構成されている場合、LSRは、ちょうど（FECと共に）（LDPを介して）、そのようなラベルをアドバタイズその隣人へ。
In this section we describe an alternative to the procedures described in Section 3.1, "Procedures for the restarting LSR".
このセクションでは、「再起動LSRのための手順」、3.1節で説明した手順の代替を説明します。
The procedures described in this section assumes that the restarting LSR has (at least) as many unallocated as allocated labels. The latter form the MPLS forwarding state that the LSR managed to preserve across the restart.
このセクションで説明する手順は、再起動LSRが割り当てられたラベルのような多くの未割り当てとして（少なくとも）を有していることを前提としています。後者の形式LSRが再開の間維持するために管理することをMPLS転送状態。
After an LSR restarts its control plane, the LSR MUST check whether it was able to preserve its MPLS forwarding state from prior to the restart. If no, then the LSR sets the Recovery Time to 0 in the FT Session TLV the LSR sends to its neighbors.
LSRは、その制御プレーンを再起動した後に、LSRは、再起動する前からそのMPLS転送状態を保存することができたかどうかをチェックしなければなりません。ノーならば、LSRはLSRが隣人に送るFTセッションTLVで0に回復時間を設定します。
If the forwarding state has been preserved, then the LSR starts its internal timer, called MPLS Forwarding State Holding timer (the value of that timer SHOULD be configurable), and marks all the MPLS forwarding state entries as "stale". At the expiration of the timer, all the entries still marked as stale SHOULD be deleted. The value of the Recovery Time advertised in the FT Session TLV is set to the (current) value of the timer at the point when the Initialization message carrying the FT Session TLV is sent.
転送状態が保存されている場合、LSRは、MPLSフォワーディングステートホールディングタイマー（そのタイマの値が設定可能であるべきである）と呼ばれるその内部タイマを開始し、マーク「古くなった」など、すべてのMPLSフォワーディングステートエントリを。タイマーの満了時に、まだ古いとしてマークされたすべてのエントリを削除する必要があります。 FTセッションTLVでアドバタイズ復旧時間の値は、FTセッションTLVを運ぶ初期化メッセージが送信された時点でタイマーの（現在の）値に設定されています。
We say that an LSR is in the process of restarting when the MPLS Forwarding State Holding timer is not expired. Once the timer expires, we say that the LSR completed its restart.
私たちは、LSRがMPLSフォワーディングステートホールディングタイマーが満了していないときに再起動のプロセスであると言います。タイマーの期限が切れると、私たちは、LSRが再起動を完了したことを言います。
While an LSR is in the process of restarting, the LSR creates local label binding by following the normal LDP procedures.
LSRが再開の過程にあるものの、LSRは通常のLDP手順を実行することで、結合ローカルラベルを作成します。
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 FEC - 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. Both of these bindings though would have the same outgoing label (and the same next hop).
LSRは、再起動の処理中に、LSRはないものを持っている場合がありますが、与えられたFECのための2つのローカルラベルバインディング - 再起動後に作成された再起動する前から保持されたもの、そしてもう一つ。 LSRは、その再起動を完了すると、前者が削除されます。これらのバインディングの両方は、しかし、同じ出ラベル（と同じネクストホップ）を持っています。
When an LSR detects that its LDP session with a neighbor went down, and the LSR knows that the neighbor is capable of preserving its MPLS forwarding state across the restart (as was indicated by the FT Session TLV in the Initialization message received from the neighbor), the LSR retains the label-FEC bindings received via that session (rather than discarding the bindings), but marks them as "stale".
LSRはネイバーとのLDPセッションがダウンしたことを検出し、LSRが（ネイバーから受信した初期化メッセージにFTセッションTLVによって示されたように）ネイバーが再起動を横切ってそのMPLS転送状態を保存することが可能であることを知っている場合、LSRは（むしろバインディングを破棄するよりも）そのセッションを介して受信したラベル-FECバインディングを保持しているが、「古い」としてそれらをマークします。
After detecting that the LDP session with the neighbor went down, the LSR tries to re-establish LDP communication with the neighbor following the usual LDP procedures.
隣人とのLDPセッションがダウンしたことを検出した後、LSRは通常のLDPの手順に従って、ネイバーとLDP通信を再確立しようとします。
The amount of time the LSR keeps its stale label-FEC bindings is set to the lesser of the FT Reconnect Timeout, as was advertised by the neighbor, and a local timer, called the Neighbor Liveness Timer. If within that time the LSR still does not establish an LDP session with the neighbor, all the stale bindings SHOULD be deleted. The Neighbor
隣人、および近隣ライブネスタイマーと呼ばれる地元のタイマーによってアドバタイズされたとして、LSRはその古いラベル-FECバインディングを続ける時間の量は、FT再接続タイムアウトの小さい方に設定されています。その時間内にLSRはまだネイバーとLDPセッションを確立していない場合は、すべての古いバインディングが削除されるべきです。隣人
Liveness Timer is started when the LSR detects that its LDP session with the neighbor went down. The value of the Neighbor Liveness timer SHOULD be configurable.
LSRが、隣人とのLDPセッションがダウンしたことを検出したときにライブネスタイマーが開始されます。近隣ライブネスタイマーの値が設定可能であるべきです。
If the LSR re-establishes an LDP session with the neighbor within the lesser of the FT Reconnect Timeout and the Neighbor Liveness Timer, and the LSR determines that the neighbor was not able to preserve its MPLS forwarding state, the LSR SHOULD immediately delete all the stale label-FEC bindings received from that neighbor. If the LSR determines that the neighbor was able to preserve its MPLS forwarding state (as was indicated by the non-zero Recovery Time advertised by the neighbor), the LSR SHOULD further keep the stale label-FEC bindings, received from the neighbor, for as long as the lesser of the Recovery Time advertised by the neighbor, and a local configurable value, called Maximum Recovery Time, allows.
LSRのFT再接続タイムアウトおよび近隣ライブネスタイマーの小さい内隣人とのLDPセッションを再確立し、LSRは隣人がMPLSフォワーディング状態を保存することができなかったと判断した場合、LSRはすぐにすべて削除する必要があります古いラベル-FECバインディングがそのネイバーから受信します。 LSRはネイバーが（ネイバーによってアドバタイズ非ゼロの回復時間によって示されたように）、LSRはさらに失効ラベル-FECバインディングを維持すべきである、そのMPLS転送状態を保存することができたと判断した場合、のために、近隣から受信限り、回復時間の少ない方が、隣人、および最大回復時間と呼ばれるローカル設定可能な値で宣伝として、ことができます。
The LSR SHOULD try to complete the exchange of its label mapping information with the neighbor within 1/2 of the Recovery Time, as specified in the FT Session TLV received from the neighbor.
LSRはネイバーから受信FTセッションTLVで指定され、回復時間の1/2以内に隣人とのラベルマッピング情報の交換を完了してみてください。
The LSR handles the Label Mapping messages received from the neighbor by following the normal LDP procedures, except that (a) it treats the stale entries in its Label Information Base (LIB) as if these entries have been received over the (newly established) session, (b) if the label-FEC binding carried in the message is the same as the one that is present in the LIB, but is marked as stale, the LIB entry is no longer marked as stale, and (c) if for the FEC in the label-FEC binding carried in the message there is already a label-FEC binding in the LIB that is marked as stale, and the label in the LIB binding is different from the label carried in the message, the LSR just updates the LIB entry with the new label.
これらのエントリは、（新たに設立された）セッションを介して受信されたかのように、その（a）は、そのラベル情報ベース（LIB）で古いエントリを扱う以外LSRは、通常のLDP手順を実行することで、隣人から受け取ったラベルマッピングメッセージを処理します以下のための場合、（B）メッセージで運ば結合ラベル-FECは、LIBに存在するものと同じでない場合と同様であるが失効とマークされ、LIBエントリーはもはやとして失効マークされ、および（c）ラベル-FECでのFECはラベル-FEC失効としてマークされていることをLIBに結合し、LIB内のラベルが結合すると、メッセージで運ばれたラベルは異なっているが、すでにそこにあるメッセージで運ばれ、LSRはちょうど更新バインディング新しいラベルとLIBエントリー。
An LSR, once it creates a <label, FEC> binding, 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, 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 mis-routing 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 SHOULD NOT re-use this label for advertising a <label, FEC> binding to a neighbor that supports graceful restart for at least the sum of the FT Reconnect Timeout plus Recovery Time, as advertised by the neighbor to the LSR.
バインディング<FECは、ラベル>新しいを作成するときに、ラベルの変更によって引き起こされる潜在的なミスルーティングを最小限に抑えるために、LSRは、最低使用ラベルを拾うべきです。 LSRがラベルを解放すると、LSRは、このラベルはによってアドバタイズとして、FT再接続タイムアウトプラス回復時間の少なくとも合計のためのグレースフルリスタートをサポートしている隣人に結合<ラベル、FEC>を広告するために再使用しません。 LSRへの隣人。
The security considerations pertaining to the original LDP protocol [RFC3036] remain relevant.
オリジナルのLDPプロトコル[RFC3036]に関連するセキュリティ上の考慮事項は、関連残ります。
In addition, LSRs that implement the mechanism described here are subject to to additional denial-of-service attacks as follows:
また、ここで説明するメカニズムを実装のLSRは、次のように追加のサービス拒否攻撃への対象となっています。
An intruder may impersonate an LDP peer in order to force a failure and reconnection of the TCP connection, but where the intruder sets the Recovery Time to 0 on reconnection. This forces all labels received from the peer to be released.
侵入者は、TCP接続の障害と再接続を強制するために、LDPピアを偽装かもしれないが、侵入者は、再接続に0に回復時間を設定します場所。これは、ピアから受信したすべてのラベルが解放されるように強制します。
An intruder could intercept the traffic between LDP peers and override the setting of the Recovery Time to be set to 0. This forces all labels received from the peer to be released.
侵入者はLDPピア間のトラフィックを傍受し、回復時間の設定は、これは、ピアから受信したすべてのラベルを解放するために強制的に0に設定されるようにオーバーライドすることができます。
All of these attacks may be countered by use of an authentication scheme between LDP peers, such as the MD5-based scheme outlined in [LDP].
これらの攻撃の全ては、[LDP]に概説MD5ベースの方式としてLDPピア間の認証スキームを使用することによって対抗することができます。
As with LDP, a security issue may exist if an LDP implementation continues to use labels after expiration of the 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 mis-routing data to other than intended destinations, and it is conceivable that these behaviors may be deliberately exploited to either obtain services without authorization or to deny services to others.
自民党の実装は、最初にそれらを使用される原因となったセッションの満了後にラベルを使用し続けた場合、自民党と同じように、セキュリティ上の問題が存在してもよいです。上流のLSRが川下のLSRがリリースしているとラベルを再使用後にセッションの障害を検出した場合、これが発生する可能性があります。問題は、プラットフォーム全体のラベルスペースで最も明白であり、他意図したよりも宛先に誤ルーティングデータにつながる可能性があり、これらの行動が故意に承認なしのサービスを取得したり、他の人にサービスを拒否するかのいずれかに悪用されることが考えられます。
In this document, the validity of the session may be extended by the Reconnect Timeout, and the session may be re-established in this period. After the expiry of the Reconnection Timeout, the session must be considered to have failed and the same security issue applies as described above.
この文書では、セッションの有効性を再接続タイムアウトによって拡張することができる、とのセッションは、この期間内に再確立することができます。再接続タイムアウトの満了後、セッションは失敗したとみなされ、上記と同様のセキュリティ上の問題が適用されなければなりません。
However, the downstream LSR may declare the session as failed before the expiration of its Reconnection Timeout. 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 not be re-used until at least the sum of Reconnect Timeout plus Recovery Time.
その再接続タイムアウトの満了前に失敗したとしてしかし、下流LSRはセッションを宣言することがあります。これは、アップストリームLSRがラベルの古い使用を使用してデータを送信し続けながら下流LSRがラベルを再割り当て可能性のある期間を増加させます。この問題を軽減するために、このドキュメントでは、ラベルは再接続タイムアウトプラス回復時間の少なくとも合計まで再使用できないことが必要です。
This section is taken from Section 10.4 of [RFC2026].
このセクションは、[RFC2026]のセクション10.4から取られます。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
We would like to thank Loa Andersson, Chaitanya Kodeboyina, Ina Minei, Nischal Sheth, Enke Chen, and Adrian Farrel for their contributions to this document.
私たちは、この文書への貢献のためのLoaアンデション、Chaitanya Kodeboyina、伊那Minei、Nischal Sheth、エンケ陳、およびエードリアンファレルに感謝したいと思います。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
[LDP]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "ラベル配布プロトコル"、RFC 3036、2001年1月。
[FT-LDP] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
、RFC 3479、2003年2月[FT-LDP]ファレル、A.、 "ラベル配布プロトコル（LDP）のためのフォールトトレランス"。
[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月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[OSPF-RESTART] "Hitless OSPF Restart", Work in Progress.
[OSPF-RESTART] "ヒットレスOSPFの再起動" が進行中で働いています。
[ISIS-RESTART] "Restart signaling for ISIS", Work in Progress.
[ISIS-RESTART "ISISのためのシグナリングを再起動"、ProgressのWork。
[BGP-RESTART] "Graceful Restart Mechanism for BGP", Work in Progress.
[BGP-RESTART] "BGPのためのグレースフルリスタートメカニズム" が進行中で働いています。
Manoj Leelanivas Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
1194年におけるManojさんLilnivasジュニパーネットワークスではありません。 94089のマチルダアベニューサニーベール、
EMail: manoj@juniper.net
メールアドレス：manoj@juniper.net
Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Rahul Aggarwal Redback Networks 350 Holger Way San Jose, CA 95134
ラウール・アガーウォールレッドバック・ネットワーク350ホルガー・ウェイサンノゼ、CA 95134
EMail: rahul@redback.com
メールアドレス：rahul@redback.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。