[要約] RFC 3478は、ラベル配布プロトコルの優雅な再起動メカニズムに関するものであり、再起動中にネットワークの中断を最小限に抑えることを目的としています。
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.
Copyright（c）The Internet Society（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トラフィックへのマイナスの影響を軽減しませんが、隣人の場合の影響を最小限に抑えます（s）制御プレーンの再起動全体で転送状態を保存し、ここで説明するメカニズムを実装することができます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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転送状態を保持できる場合、そのLSRを通過するLSPを摂動しないことが望ましい（具体的には、LSPが確立されたことが望ましいLDPによって）。このドキュメントでは、この目標の達成を可能にする「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.
このドキュメントで説明されているメカニズムは、すべてのLSRに適用されます。両方とも、LDP再起動中に転送状態を保存する能力を持つものと、存在しないもの（後者はこのドキュメントに記載されているメカニズムのサブセットのみを実装する必要があります）。再起動全体でMPLS転送状態を保存できないLSRによってここで説明されているメカニズムをサポートする（サブセット）は、コントロールプレーンの再起動によって引き起こされるMPLSトラフィックへのマイナスの影響を軽減しませんが、隣人の場合の影響を最小限に抑えます（s）制御プレーンの再起動全体で転送状態を保存し、ここで説明するメカニズムを実装することができます。
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転送状態のみが保存されなければならないことを前提としています。明らかに、これは、再起動を横断して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初期化メッセージのオプションパラメーターとしてFault Tolerant（FT）セッションTLVを含めることにより、LDP Graceful Restartをサポートできることを示しています。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の値フィールドには、このドキュメントで定義されているメカニズムで使用される2つのコンポーネントが含まれています。FTの再接続タイムアウトと回復時間。
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コンポーネントを許可するのに十分な長さである必要があります。
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.
FTの再接続タイムアウトを0に設定すると、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 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の再起動の場合、回復時間には（ミリ秒単位で）時間が経過します。LSRは、再起動全体に保存されているMPLS転送状態を維持する意思があります。時間は、LSRが再起動後にFTセッション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を優雅な方法で再吸収できるようにするのに十分な長さである必要があります。
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で指定されている「Egress 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.
MPLS転送状態保持タイマーが期限切れになっていない場合、LSRは再起動の過程にあると言います。タイマーの有効期限が切れると、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.)
新しく受信したマッピングメッセージに掲載されたラベルが暗黙のヌルではない場合、LSRはMPLS転送状態を検索して、メッセージに等しいラベルに等しい発信ラベルを持つエントリを検索し、次のホップはアドレスのいずれかに等しくなります（次のホップ）ピアからのアドレスメッセージで受信しました。そのようなエントリが見つかった場合、LSRはもはやエントリを古くマークしません。さらに、エントリがタイプ<受信ラベル、（発信ラベル、次のホップ）>（<fec、（oungovering label、next hop）>）である場合、LSRはそのエントリの着信ラベルをFECを受け取ったFECに関連付けますラベルマッピングメッセージ、および（LDP経由）<受信ラベル、Fec>を隣人に宣伝します。発見されたエントリに着信ラベルがない場合、またはエントリが見つからない場合、LSRは通常のLDP手順に従います。（この段落は、LSRの再起動が出口でもないシナリオでも、特定のLSPに2番目のホップを使用する最後から2番目のホップでもないことに注意してください。
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.)
マッピングメッセージに掲載されたラベルが暗黙のヌルラベルである場合、LSRはMPLS転送状態を検索し、ラベルPOP（発信ラベルがないことを意味します）を示すエントリを検索し、次のホップは受信したアドレス（次のホップ）に等しくなりますピアからのアドレスメッセージ。そのようなエントリが見つかった場合、LSRはエントリを古くしているとマークしなくなり、LSRはそのエントリから次のラベルを隣接するラベルマッピングメッセージで受信したFECに関連付け、（LDP経由）<受信ラベル、FECを宣伝します。>隣人に。発見されたエントリに着信ラベルがない場合、またはエントリが見つからない場合、LSRは通常のLDP手順に従います。（この段落は、LSRの再起動が特定のLSPの最後から2番目のホップであり、このLSPが最後から2番目のホップポップを使用するシナリオについて説明していることに注意してください。）
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の再起動が最後から2番目のホップであると仮定しています。これが当てはまらない場合、再起動LSRがそのようなLSPごとに一意のラベルを生成する場合、LSRは<受信ラベルだけでなく（発信ラベル、次のホップ）>マッピングだけでなく、再起動全体に保存する必要があります。このマッピングに関連付けられているFEC。そのような場合、LSRは、（a）ラベルPOP（発信ラベルがないことを意味する）を示すエントリをMPLS転送状態に検索します（b）アドレスメッセージで受信したアドレス（次のホップ）の1つに等しいホップを示します。ピアから、および（c）は、ラベルマッピングメッセージで受信したFECと同じFECを持っています。そのようなエントリが見つかった場合、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 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の非ヌルラベルを生成するように構成され、LSRはすべてのFECに対して同じ（非ヌル）ラベルを生成するように構成されていることが構成されています。同じ次のホップを共有し、LSRが出口であるため、LSRはMPLS転送状態を検索し、ラベルPOP（発信ラベルがないことを意味します）を示すエントリを検索し、次のホップはその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の非ヌルラベルを生成するように構成されている場合、LSRはそのようなFECごとに一意のラベルを生成するように構成されている場合、LSRはする必要があります。<受信ラベル（発信ラベル、次のホップ）>マッピングだけでなく、このマッピングに関連付けられたFECだけでなく、再起動全体に保存します。そのような場合、LSRはMPLS転送状態を検索し、ラベルPOP（発信ラベルがないことを意味します）を示すエントリを検索し、次のホップはエントリに関連付けられたその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の出口であると判断し、LSRがそのFECのnull（明示的または暗黙的）ラベルを生成するように構成されている場合、LSRは（LDP経由で）そのようなラベル（FECと一緒に）を宣伝するだけですその隣人に。
In this section we describe an alternative to the procedures described in Section 3.1, "Procedures for the restarting LSR".
このセクションでは、セクション3.1で説明されている手順「LSRの再起動手順」に代わるものについて説明します。
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転送を形成します。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 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.
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には1つではなく、特定の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は隣人が再スタート全体でMPLS転送状態を保存できることを知っています（隣人から受信した初期化メッセージのFTセッションTLVで示されました）、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 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が古いラベルフェックバインディングを維持する時間は、近隣によって宣伝されたように、FTの再接続タイムアウトの少ないものに設定され、近隣のライデンスタイマーと呼ばれるローカルタイマーが設定されます。その時間内にLSRが依然として隣人とのLDPセッションを確立していない場合、すべての古いバインディングを削除する必要があります。LSRが隣人とのLDPセッションがダウンしたことを検出したとき、Neighbor Livensionタイマーは開始されます。Neighbor Livensionタイマーの値は構成可能である必要があります。
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の再接続タイムアウトと隣人のlivensionタイマーの低い範囲内の隣人とのLDPセッションを再確立し、LSRが隣人がMPLS転送状態を保存できないと判断した場合、LSRはすぐにすべてのすべてを削除する必要があります。その隣人から受け取った古いラベルフェックバインディング。LSRが、隣人がMPLS転送状態を保持できたと判断した場合（隣人が宣伝した非ゼロ回復時間で示されたように）、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は、近隣から受け取った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.
LSRは、（a）これらのエントリが（新しく確立された）セッションで受信されているかのように、（a）ラベル情報ベース（LIB）の古いエントリを扱うことを除いて、通常のLDP手順に従って隣人から受信したラベルマッピングメッセージを処理します。（b）メッセージに掲載されたラベルFECバインディングがlibに存在するものと同じであるが古いものとしてマークされている場合、libエントリはもはや古いものとしてマークされなくなり、（c）メッセージに掲載されたラベルFECバインディングのFECには、古いものとしてマークされたLIBにすでにラベルFECバインディングがあり、LIBバインディングのラベルはメッセージに掲載されたラベルとは異なります。新しいレーベルを使用した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の再接続タイムアウトと回復時間の合計のために優雅な再起動をサポートする隣人にバインディングするためにこのラベルを再利用してはなりません。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.
LDPと同様に、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がラベルの古い使用法を使用してデータを送信し続けます。この問題を減らすために、このドキュメントでは、少なくとも再接続タイムアウトと回復時間の合計まで、ラベルを再利用しないことが必要です。
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 Andersson、Chaitanya Kodeboyina、Ina Minei、Nischal Sheth、Enke Chen、およびAdrian Farrelに、この文書への貢献に感謝します。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
[LDP] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「Label Distribution Protocol」、RFC 3036、2001年1月。
[FT-LDP] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[FT-LDP] Farrel、A。、「ラベル分布プロトコル（LDP）に対するフォールトトレランス」、RFC 3479、2003年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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の信号を再起動する」、進行中の作業。
[BGP-RESTART] "Graceful Restart Mechanism for BGP", Work in Progress.
[BGP-Restart]「BGPの優雅な再起動メカニズム」、進行中の作業。
Manoj Leelanivas Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089
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
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
Rahul Aggarwal Redback Networks 350 Holger Way San Jose、CA 95134
EMail: rahul@redback.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。