Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. 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. この文書は LSR のコントロールプレーンの再開の間 MPLS 転送コンポーネントの 状態を保存可能な LSR において、特に LDP コンポーネントの再開によって 引き起こされる 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. この文書に示される仕組みは、LDP 再開の間に転送状態を保存できる LSR、また 保存できない LSR、両方に適用可能である（しかし後者は本文書に記述されている 仕組みを部分的に実装しなければならない）。ここに記されている仕組みを（部分的 にでも）再開の間 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 関連の状態をも再開の間に渡って保存することは要求しない。 Leelanivas, et al. Standards Track [Page 1]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 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. この文書に記された手続きは DU (downstream unsolicited) ラベル配布方式に 適用される。これらの手続きを DOD (downstream on demand) ラベル配布方式に 拡張することは今後の研究による。 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]. 1. Motivation 動機 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 (outgoing label, next hop)> (non-ingress case), or (outgoing label, next hop)> (ingress case) mapping. この文書の文脈中では簡潔にするために、「MPLS 転送状態」とは次のいずれかの 対応付けを意味することとする。 <入力ラベル -> (出力ラベル、ネクストホップ)>（入接でない場合）または (出力ラベル、ネクストホップ)>（入接の場合） 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 構成部分の再開の間に MPLS 転送状態を保存できる場合には、その LSR を通る LSP（特に LDP によって確立 された LSP）を乱すべきではない。本文書では、この目的を果たす為の "LDP Graceful Restart" と呼ばれる仕組みを述べる。 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. この文書に示される仕組みは、LDP 再開の間に転送状態を保存できる LSR、また 保存できない LSR、両方に適用可能である（しかし後者は本文書に記述されている 仕組みを部分的に実装しなければならない）。ここに記されている仕組みを（部分的 にでも）再開の間 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 関連の状態をも再開の間に渡って保存することは要求しない。 Leelanivas, et al. Standards Track [Page 2]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 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. この文書に記された手続きは DU (downstream unsolicited) ラベル配布方式に 適用される。これらの手続きを DOD (downstream on demand) ラベル配布方式に 拡張することは今後の研究による。 2. LDP Extension LDP 拡張 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. 本文書に定義される LDP Graceful Restart をサポートする LSR は、その LDP 初期化 メッセージ中に、オプションパラメータとして耐障害 (FT) セッション TLV を 含むことにより、そのサポートを表す。耐障害 (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) セッション TLV は、この文書で定義される仕組みで使われる二つの値を 含む：耐障害再接続タイムアウト (FT Reconnect Timeout) と復旧時間 (Recovery Time) である。 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. 耐障害再接続タイムアウト（単位はミリ秒）は、この TLV を受信した側が、 この TLV の送信側との LDP 通信障害を検知した後に待つ時間である。 セッションの回復を待つ間、受信側は送信側と受信側の間で既に確立済みの LSP に 関する MPLS 転送状態を保存すべきである。耐障害再接続タイムアウトは、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 にセットすることは、この TLV の送信側は 再開の間に転送状態を保存しないことを示す。しかしそれでも、本文書の セクション 3.3「隣接 LSR との LDP 通信再開」に定義される手順を送信側が サポートし、その隣接が転送状態の保存をサポートすれば利点を利用することが できるかもしれない。 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 Leelanivas, et al. Standards Track [Page 3]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 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). 復旧時間（単位はミリ秒）再開する LSR が MPLS 転送状態を保存する時間である。 この時間は、再開後、LSR が耐障害セッション 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. 復旧時間は、隣接する LSR 同士が LDP コントロールプレーンを輻輳させること無しに すべての LSP を再同期するのに十分な長さであるべきである。 3. Operations 動作 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 初期化メッセージ中に 耐障害セッション 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 転送状態のみならず、IP 転送状態をも保存できることを仮定している。 IP 転送状態を保存する手続きは [OSPF-RESTART], [ISIS-RESTART], そして [BGP- RESTART] に定義されている。 3.1. Procedures for the restarting LSR 再開側 LSR の手続き 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 は隣接に送信する耐障害セッション 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 転送状態エントリを「古い」(stale) としてマークする。 このタイマが満了した時点で古いとマークされている全てのエントリは 削除されるべきである。耐障害セッション TLV 中で広告されている復旧時間の値は その 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. 我々は MPLS 転送状態保存タイマが満了していない場合を「LSR が再開処理の 過程にある」と言う。タイマが満了したら、「LSR は再開を完了した」と言う。 The following procedures apply when an LSR is in the process of restarting. LSR が再開処理を行う場合、以下の手続きに従う。 3.1.1. Non-egress LSR 出接でない 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 Leelanivas, et al. Standards Track [Page 4]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 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 (rather than ), the LSR associates the incoming label from that entry with the FEC received in the Label Mapping message, and advertises (via LDP) 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.) 新しく受信した Mapping メッセージ中のラベルが Implicit NULL でなければ、 LSR は MPLS 転送状態を検索し、受信したメッセージ中のラベルと等しい出力ラベルを 持ち、かつピアから受信した Address メッセージ中のネクストホップアドレスのうち どれかと同じネクストホップを持っているエントリを探す。そのようなエントリが 見つかったらLSR は最早そのエントリを「古い」とマークしない。 加えて、そのエントリが のタイプではなく <入力ラベル、(出力ラベル、ネクストホップ)> のタイプのエントリであった場合、 LSR は受信した Label Mapping メッセージ中の FEC と入力ラベルを関連づけ、 LDP によって <入力ラベル、FEC> を隣接へ広告する。 見つかったエントリに入力ラベルがなかった場合、またはエントリが存在しなかった 場合、LSR は通常の LDP の手続きに従う。 （この段落では再開している LSR が出接ではなく、また、ある LSP について PHP を行う出接の一段前のホップでもない場合のシナリオを記述していることに 注意。また、この段落の記述は再開している 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) 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.) もし Mapping メッセージ中のラベルが Implicit NULL であれば、LSR は MPLS 転送状態を検索して、ラベルポップ（つまり出力ラベルなし）を指示し、かつピアから 受信した Address メッセージ中のネクストホップアドレスのうちどれかと同じネクストホップを 持っているエントリを探す。そのようなエントリが見つかったら LSR は最早 そのエントリを「古い」とマークせず、LSR はそのエントリの入力ラベルと 隣接から受信した Label Mapping メッセージ中の FEC を関連づけ、 LDP によって 隣接へ <入力ラベル、FEC> を広告する。見つかったエントリに入力ラベルが なかった場合、またはエントリが存在しなかった場合、LSR は通常の LDP の手続きに 従う。（この段落では、再開している LSR がある LSP についての出接の 一段前のホップで、PHP を行っている場合のシナリオを記述していることに注意。） 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 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) 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 で終端する（終端している LSR は 再開しているものとは別）全ての LSP について同じラベルを生成し、また、 その再開している LSR が LSP の出接一段前のホップである、と仮定をしている。 もしそうでなければ、また再開している LSR が LSP にユニークなラベルを 生成するのであれば、LSR は再開の間 <入力ラベル、(出力ラベル、ネクストホップ)> の 組み合わせだけでなく、FEC もこの組み合わせに関連付けて保存する必要がある。 そのような場合には、LSR は MPLS 転送状態から、以下のようなエントリを検索する。 (a) ラベルポップを指示している（出力ラベルなし） (b) ネクストホップがピアから受信した Address メッセージ中のネクストホップのどれかと等しい (c) FEC が、受信した Label Mapping メッセージ中のものと同じ そのようなエントリが見つかったら LSR は最早そのエントリを「古い」とマークせず エントリの入力ラベルと隣接から受信した Label Mapping メッセージ中の FEC を 関連づけ、LDP によって <入力ラベル、FEC> を隣接へ広告する。 見つかったエントリに入力ラベルがなかった場合、またはエントリが存在しなかった 場合、LSR は通常の LDP の手続きに従う。 Leelanivas, et al. Standards Track [Page 5]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 3.1.2. Egress LSR 出接 LSR 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) 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 の出接であり、 その FEC に対し NULL でないラベルを生成するよう設定され、 同一のネクストホップを持つ全ての FEC に対して、またその LSR が出接である FEC に 対して、NULL でない同一のラベルを生成するよう設定されている場合、 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 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) 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 の出接であり、 その FEC に対し NULL でないラベルを生成するよう設定され、 そのような各 FEC に対してユニークなラベルを生成するよう設定されている場合、 LSR は再開の間<入力ラベル、(出力ラベル、ネクストホップ)>の対応付けだけでなく、 FEC もこの組み合わせに関連付けて保存する必要がある。このような場合には 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, 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 の出接であり、その FEC に対し NULL ラベル（Explicit でも Implicit でも）を生成するよう設定されているならば、LSR はそのラベルを FEC とともに LDP によって隣接へ広告する。 3.2. Alternative procedures for the restarting LSR 再開する LSR の別の手続き In this section we describe an alternative to the procedures described in Section 3.1, "Procedures for the restarting 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 は、割当済みのラベルと少なくとも 同量の未割当ラベルを持っているものと仮定する。割当済みラベルは、再開の間 保存しなければならない MPLS 転送状態を構成している。 Leelanivas, et al. Standards Track [Page 6]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 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 は隣接に送る耐障害セッション 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 転送状態エントリを「古い」(stale) としてマークする。 このタイマが満了した時点で古いとマークされている全てのエントリは 削除されるべきである。耐障害セッション TLV 中で広告されている復旧時間の値は その耐障害セッション 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. 我々は MPLS 転送状態保存タイマが満了していない場合を「LSR が再開処理の 過程にある」と言う。タイマが満了したら、「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 に対して一つではなく、二つの ローカルラベル結合を持つかもしれないことに注意。ひとつは再開前から 保存されたもの、もうひとつは再開後に作成されたものである。 LSR が再開を完了したら、前者は削除される。 しかし、これら二つの結合は同じ出力ラベルとネクストホップを持つ。 3.3. Restart of LDP communication with a neighbor LSR 隣接 LSR との LDP 通信の再開 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 セッションが落ちるのを検知し、かつその隣接が再開の間 MPLS 転送状態を保存できることを知っているならば（これは隣接から受信した 初期化メッセージ中の耐障害セッション TLV でわかる）、LSR はこのセッションで 受信したラベル−FEC の結合を（破棄しないで）保存するが、「古い」(stale) と マークする。 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. 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 Leelanivas, et al. Standards Track [Page 7]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 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 が「古い」ラベル−FEC 結合を保存しておく時間は、隣接から広告された 耐障害再接続タイムアウト値、および隣接生存タイマと呼ばれる自局タイマ値のふたつのうち、より小さい値にセットされる。 その時間内に隣接との LDP セッションが確立されなければ「古い」結合情報は 削除されるべきである。隣接生存タイマは隣接との 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 が耐障害再接続タイムアウト値および隣接生存タイマの小さいほうの時間内に 隣接と LDP セッションを再確立したならば、LSR は隣接が MPLS 転送状態を 保存できなかったかどうかを決定し、その隣接から受信した「古い」ラベル−FEC結合を 直ちに削除するべきである。LSR が、隣接が MPLS 転送状態を保存できた、と 決定したら（これは隣接からの回復時間パラメータが 0 でないことでわかる）、 LSR は隣接から広告された回復時間か 最大回復時間と呼ばれる自局側で設定可能な値 のどちらか小さいほうの時間だけ、隣接から受信した古いラベル−FEC 結合を 保存する。 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 は隣接から受信した耐障害セッション TLV 中に記されている回復時間の 半分の時間内に、隣接とラベルマッピング情報の交換を完了するようにすべきである。 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. LSR は以下の場合を除いて、隣接から受信した Label Mapping メッセージを 通常の LDP の手続きどおりに処理する。 a) LIB 中の古いエントリを（新しく確立した）セッションから受信したもので あるかのように扱う場合。 b) メッセージ中のラベル−FEC 結合が LIB の中に存在していて、それが「古い」と マークされていれば、その LIB エントリを最早「古い」とマークしない。 c) メッセージ中で伝達されたラベル−FEC の中のある FEC について、LIB 中に すでに「古い」とマークされたエントリがあり、かつ LIB 中のラベルと メッセージ中のラベルが異なる場合は、LSR は新しいラベルで LIB エントリを 更新する。 An LSR, once it creates a 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 binding. LSR はいったん <ラベル、FEC> の組み合わせを作成したら、FEC への経路が 存在している限り、そのラベルの値を使いつづけるべきである。その FEC への 経路が消失し、後に再び現れたら、異なるラベルの値を使って新しい <ラベル、 FEC> の組を作成するかもしれない。 To minimize the potential mis-routing caused by the label change when creating a new 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 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 は直近に使用したラベルの値を使うべきである。 いったんラベルを解放したらならば、少なくとも耐障害再接続タイムアウト＋ 回復時間の和の間は、graceful restart をサポートする隣接に広告する <ラベル、FEC> に、その解放したラベル値を再利用すべきではない。 Leelanivas, et al. Standards Track [Page 8]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 4. Security Consideration セキュリティ上の考察 The security considerations pertaining to the original LDP protocol [RFC3036] remain relevant. 元の LDP プロトコルに関係するセキュリティ上の考察はここでも関連性を持つ。 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. 侵入者は LDP ピアを装って TCP コネクションの失敗と再接続を強要し、再接続時に 回復時間を 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. LDP に関しては、その実装がそのラベルを最初に使ったセッションが終了したあとも そのラベルを使いつづければ、セキュリティ上の問題が存在する。これは、もし 下流の 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 がラベルを再割当するという期間が長くなってしまう。 この問題を低減する為に、本文書では最低でも再接続タイムアウト＋復旧時間の間、 ラベルを再利用しないよう要求している。 Leelanivas, et al. Standards Track [Page 9]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 5. Intellectual Property Considerations This section is taken from Section 10.4 of [RFC2026]. 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. 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. 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. 6. Acknowledgments We would like to thank Loa Andersson, Chaitanya Kodeboyina, Ina Minei, Nischal Sheth, Enke Chen, and Adrian Farrel for their contributions to this document. 7. Normative References [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001. [FT-LDP] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Leelanivas, et al. Standards Track [Page 10]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 8. Informative References [OSPF-RESTART] "Hitless OSPF Restart", Work in Progress. [ISIS-RESTART] "Restart signaling for ISIS", Work in Progress. [BGP-RESTART] "Graceful Restart Mechanism for BGP", Work in Progress. 9. Authors' Addresses Manoj Leelanivas Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: manoj@juniper.net Yakov Rekhter Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: yakov@juniper.net Rahul Aggarwal Redback Networks 350 Holger Way San Jose, CA 95134 EMail: rahul@redback.com Leelanivas, et al. Standards Track [Page 11]  RFC 3478 Graceful Restart Mechanism for LDP February 2003 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. 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. Leelanivas, et al. Standards Track [Page 12]