Network Working Group A. Farrel
Request for Comments: 3612 Old Dog Consulting
Category: Informational September 2003
Applicability Statement for Restart Mechanisms
for the Label Distribution Protocol (LDP)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP".
この文書では、ラベル配布プロトコル（LDP）の再起動メカニズムのいくつかのフォームを実装するために、どのアプローチがより適切であるかもしれないことをお勧めしたときにガイダンスを提供します。この文書で説明する問題と拡張はRFC 3212、「LDPを使用して制約ベースのLSPのセットアップ」にも同様に適用可能です。
Multiprotocol Label Switching (MPLS) systems are used in core networks where system downtime must be kept to a minimum. Similarly, where MPLS is at the network edges (e.g., in Provider Edge (PE) routers) [RFC2547], system downtime must also be kept to a minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks.
（MPLS）システムをマルチプロトコルラベルスイッチングは、システムのダウンタイムを最小限に保たなければならないコアネットワークで使用されています。 MPLSネットワークのエッジ（例えば、プロバイダエッジで（PE）ルータ）である。同様に、[RFC2547]、システムのダウンタイムも最小限に抑えなければなりません。多くのMPLSラベルスイッチングルータ（LSRの）は、従って、コアネットワークの高可用性を提供するために、フォールトトレラント（FT）ハードウェアやソフトウェアを利用することができます。
The details of how FT is achieved for the various components of an FT LSR, including the switching hardware and the TCP stack, are implementation specific. How the software module itself chooses to implement FT for the state created by the LDP is also implementation specific. However, there are several issues in the LDP specification [RFC3036] that make it difficult to implement an FT LSR using the LDP protocols without some extensions to those protocols.
FTは、スイッチングハードウェアとTCPスタックを含むFT LSRの様々な構成要素、達成される方法の詳細は、実装固有です。ソフトウェアモジュール自体はLDPによって作成された状態のためにFTを実装することを選択する方法も実装固有のものです。しかし、それは難しい、これらのプロトコルにいくつかの拡張機能なしでLDPプロトコルを使用して、FTのLSRを実装するために作るLDP仕様[RFC3036]でいくつかの問題があります。
Proposals have been made in [RFC3478] and [RFC3479] to address these issues.
提案は、これらの問題に対処するために、[RFC3478]と[RFC3479]で行われています。
Many MPLS LSRs may exploit FT hardware or software to provide high availability (HA) of core networks. In order to provide HA, an MPLS system needs to be able to survive a variety of faults with minimal disruption to the Data Plane, including the following fault types:
多くのMPLSのLSRは、コアネットワークの高可用性（HA）を提供するFTのハードウェアまたはソフトウェアを利用することができます。 HAを提供するために、MPLSシステムは、以下の障害タイプを含むデータプレーンに最小限の中断で障害の様々な存続できるようにする必要があります。
- failure/hot-swap of the switching fabric in an LSR,
- LSRのスイッチング・ファブリックの障害/ホットスワップ、
- failure/hot-swap of a physical connection between LSRs,
- LSRの間の物理的な接続の不良/ホットスワップ、
- failure of the TCP or LDP stack in an LSR,
- LSRでのTCPまたはLDPスタックの故障、
- software upgrade to the TCP or LDP stacks in an LSR.
- LSRでのTCPまたはLDPスタックへのソフトウェア・アップグレード。
The first two examples of faults listed above may be confined to the Data Plane. Such faults can be handled by providing redundancy in the Data Plane which is transparent to LDP operating in the Control Plane. However, the failure of the switching fabric or a physical link may have repercussions in the Control Plane since signaling may be disrupted.
上記障害の最初の2つの例は、データプレーンに制限されてもよいです。そのような障害は、LDPコントロールプレーンで動作に対して透過的であるデータプレーンの冗長性を提供することによって扱うことができます。しかし、スイッチングファブリック又は物理リンクの障害を破壊することができるので、シグナリング制御プレーンにおける影響を有することができます。
The third example may be caused by a variety of events including processor or other hardware failure, and software failure.
第三の例では、プロセッサまたは他のハードウェアの故障、ソフトウェアの故障などさまざまなイベントによって引き起こされ得ます。
Any of the last three examples may impact the Control Plane and will require action in the Control Plane to recover. Such action should be designed to avoid disrupting traffic in the Data Plane. Since many recent router architectures can separate the Control and Data Planes, it is possible that forwarding can continue unaffected by recovery action in the Control Plane.
最後の3例はいずれも、コントロールプレーンに影響を与えるかもしれないし、回復するには、コントロールプレーンでのアクションが必要になります。このような行動は、データプレーンのトラフィックの中断を避けるために設計されなければなりません。最近の多くのルータ・アーキテクチャは、コントロールプレーンとデータプレーンを分離することができますので、転送が制御プレーンの回復作用により影響を受けずに継続することが可能です。
In other scenarios, the Data and Control Planes may be impacted by a fault, but the needs of HA require the coordinated recovery of the Data and Control Planes to a state that existed before the fault.
他のシナリオでは、データと制御プレーンは、障害によって影響を受ける可能性があるが、HAのニーズは、故障前の状態にデータおよび制御プレーンの協調回復を必要とします。
The provision of protection paths for MPLS LSP and the protection of links, IP routes or tunnels through the use of protection LSPs is outside the scope of this document. See [RFC3469] for further information.
MPLS LSP保護LSPの使用を介してリンク、IP経路またはトンネルを保護するための保護パスの規定は、この文書の範囲外です。詳細については、[RFC3469]を参照してください。
In order for the Data and Control Plane states to be successfully recovered after a fault, procedures are required to ensure that the state held on a pair of LDP peers (at least one of which was affected directly by the fault) are synchronized. Such procedures must be implemented in the Control Plane software modules on the peers using Control Plane protocols.
正常障害後に回復されるデータ及び制御プレーンの状態のために、手順は（少なくとも一方が故障により直接影響を受けた）LDPピアの対に保持された状態が同期されていることを確認する必要があります。そのような手順は、コントロールプレーンのプロトコルを使用してピアにコントロールプレーンソフトウェアモジュールに実装されなければなりません。
The required actions may operate fully after the failure (reactive recovery) or may contain elements that operate before the fault in order to minimize the actions taken after the fault (proactive recovery). It is rare to implement actions that operate solely in advance of the failure and do not require any further processing after the failure (preventive recovery) - this is because of the dynamic nature of signaling protocols and the unpredictability of fault timing.
必要なアクションは失敗（反応性回復）した後、完全に動作させることができるか、障害（積極的な回復）後に撮影されたアクションを最小限に抑えるために、障害の前に作動する要素を含んでいてもよいです。これは、シグナリングプロトコルの動的な性質と、故障時期の予測不可能である - 障害の前にのみ動作し、故障（予防回復）した後、任意の更なる処理を必要としないアクションを実装することは稀です。
Reactive recovery actions may include full re-signaling of state and re-synchronization of state between peers and synchronization based on checkpointing.
反応性回復アクションは、完全な状態の再シグナリングとチェックポイントに基づいてピアと同期間の状態の再同期を含むことができます。
Proactive recovery actions may include hand-shaking state transitions and checkpointing.
積極的な回復アクションは、手振っ状態遷移とチェックポイントを含むことができます。
LDP uses TCP to provide reliable connections between LSRs to exchange protocol messages to distribute labels and to set up LSPs. A pair of LSRs that have such a connection are referred to as LDP peers.
自民党は、ラベルを配布するプロトコルメッセージを交換すると、LSPを設定するためのLSR間で信頼性の高い接続を提供するためにTCPを使用しています。そのような接続を持っているのLSR一対のLDPピアと呼ばれます。
TCP enables LDP to assume reliable transfer of protocol messages. This means that some of the messages do not need to be acknowledged (e.g., Label Release).
TCPはプロトコルメッセージの信頼性の高い転送を前提とする自民党を可能にします。これは、メッセージの一部が（例えば、ラベル解放）が確認する必要がないことを意味します。
LDP is defined such that if the TCP connection fails, the LSR should immediately tear down the LSPs associated with the session between the LDP peers, and release any labels and resources assigned to those LSPs.
自民党は、TCP接続が失敗した場合、LSRはすぐLDPピア間のセッションに関連付けられているLSPを取り壊す、およびそれらのLSPに割り当てられた任意のラベルとリソースを解放すべきであるように定義されます。
It is notoriously difficult to provide a Fault Tolerant implementation of TCP. To do so might involve making copies of all data sent and received. This is an issue familiar to implementers of other TCP applications, such as BGP.
TCPのフォールトトレラントな実装を提供するために、悪名高い困難です。そうするためには、送受信されるすべてのデータのコピーを作成することを伴うかもしれません。これは、BGPなど、他のTCPアプリケーションの実装にはおなじみの問題です。
During failover affecting the TCP or LDP stacks, therefore, the TCP connection may be lost. Recovery from this position is made worse by the fact that LDP control messages may have been lost during the connection failure. Since these messages are unconfirmed, it is possible that LSP or label state information will be lost.
TCPまたはLDPスタックに影響を与えるフェイルオーバー中、このため、TCP接続が失われる可能性があります。この位置からの回復はLDP制御メッセージは、接続障害時に失われている可能性があるという事実によって悪化しています。これらのメッセージは未確認なので、LSPまたはラベルの状態情報が失われる可能性があります。
At the very least, the solution to this problem must include a change to the basic requirements of LDP so that the failure of an LDP session does not require that associated LDP or forwarding state be torn down.
LDPセッションの障害は、関連するLDPまたは転送状態が切断されることを必要としないように、最低でも、この問題を解決するには、自民党の基本的な要件への変更を含める必要があります。
Any changes made to LDP in support of recovery processing must meet the following requirements:
リカバリ処理のサポートに自民党に加えられた変更は、次の要件を満たす必要があります。
- offer backward-compatibility with LSRs that do not implement the extensions to LDP,
- 、LDPの拡張機能を実装していないのLSRとの下位互換性を提供します
- preserve existing protocol rules described in [RFC3036] for handling unexpected duplicate messages and for processing unexpected messages referring to unknown LSPs/labels.
- 予期しない重複したメッセージを処理するために、未知のLSP /ラベルを参照して、予期しないメッセージを処理するために[RFC3036]に記載の既存のプロトコルルールを保存します。
Ideally, any solution applicable to LDP should be equally applicable to CR-LDP.
理想的には、LDPに適用可能な任意の溶液は、CR-LDPにも等しく適用可能であるべきです。
LDP Fault Tolerance extensions are described in [RFC3479]. This approach involves:
LDPフォールトトレランス機能拡張は、[RFC3479]で説明されています。このアプローチは、以下のものを含みます：
- negotiation between LDP peers of the intent to support extensions to LDP that facilitate recovery from failover without loss of LSPs,
- LSPの損失なしにフェイルオーバーからの回復を促進するLDPへの拡張をサポートする意図のLDPピア間の交渉、
- selection of FT survival on a per LSP/label basis or for all labels on a session,
- LSP /ラベルごとに、またはセッション上のすべてのラベルのためのFT生存の選択、
- sequence numbering of LDP messages to facilitate acknowledgement and checkpointing,
- LDPメッセージのシーケンス番号を確認し、チェックポイントを容易にするために、
- acknowledgement of LDP messages to ensure that a full handshake is performed on those messages either frequently (such as per message) or less frequently as in checkpointing,
- 完全なハンドシェイクがいずれかの頻繁に（例えば、メッセージの通り）またはより少ない頻度でチェックポイントのように、それらのメッセージに対して実行されることを保証するLDPメッセージの確認応答、
- solicitation of up-to-date acknowledgement (checkpointing) of previous LDP messages to ensure the current state is secured, with an additional option that allows an LDP partner to request that state is flushed in both directions if graceful shutdown is required,
- 現在の状態は正常なシャットダウンが必要な場合は、LDPパートナーは状態が両方向にフラッシュされることを要求することを可能にする追加のオプションを使用して、確保されていることを確認するために、以前の自民党メッセージの最新の受信確認（チェックポイント）の勧誘、
- a timer to control how long LDP and forwarding state should be retained after the LDP session failure, but before being discarded if LDP communications are not re-established,
- タイマーは、LDPおよび転送状態はLDPセッションが失敗した後、しかし、LDP通信が再確立されていない場合は、廃棄される前に保持する必要があるどのくらいの時間を制御します
- exchange of checkpointing information on LDP session recovery to establish what state has been retained by recovering LDP peers,
- どのような状態を確立するために、LDPセッションの回復についての情報をチェックポイントの交換はLDPピアを回収することによって保持されています、
- re-issuing lost messages after failover to ensure that LSP/label state is correctly recovered after reconnection of the LDP session.
- 再発行LSP /ラベル状態が正しくLDPセッションの再接続後に回収されることを保証するために、フェイルオーバー後の失われたメッセージを。
The FT procedures in [RFC3479] concentrate on the preservation of label state for labels exchanged between a pair of adjacent LSRs when the TCP connection between those LSRs is lost. There is no intention within these procedures to support end-to-end protection for LSPs.
それらのLSR間のTCP接続が失われたときにラベルが隣接のLSRの対の間で交換するために[RFC3479]でFT手順は、ラベル状態の維持に集中します。 LSPのためのエンドツーエンドの保護をサポートするために、これらの手順内の意図はありません。
LDP graceful restart extensions are defined in [RFC3478]. This approach involves:
LDPグレースフルリスタート機能拡張は、[RFC3478]で定義されています。このアプローチは、以下のものを含みます：
- negotiation between LDP peers of the intent to support extensions to LDP that facilitate recovery from failover without loss of LSPs,
- LSPの損失なしにフェイルオーバーからの回復を促進するLDPへの拡張をサポートする意図のLDPピア間の交渉、
- a mechanism whereby an LSR that restarts can relearn LDP state by resynchronization with its peers,
- 再起動機構れるLSRは、そのピアと再同期することによってLDP状態を再学習することができ、
- use of the same mechanism to allow LSRs recovering from an LDP session failure to resynchronize LDP state with their peers provided that at least one of the LSRs has retained state across the failure or has itself resynchronized state with its peers,
- それらのピアとLDP状態を再同期するためのLDPセッションの障害からの回復のLSRがLSRのうちの少なくとも一方が故障を横切って状態を保持しているか、それ自体が、そのピアとの状態を再同期していることを条件とすることを可能にする同様のメカニズムを使用します
- a timer to control how long LDP and forwarding state should be retained after the LDP session failure, but before being discarded if LDP communications are not re-established,
- タイマーは、LDPおよび転送状態はLDPセッションが失敗した後、しかし、LDP通信が再確立されていない場合は、廃棄される前に保持する必要があるどのくらいの時間を制御します
- a timer to control the length of the resynchronization period between adjacent peers should be completed.
- 隣接ピア間の再同期期間の長さを制御するためのタイマーが終了されるべきです。
The procedures in [RFC3478] are applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without. LSRs that can not preserve their MPLS forwarding state across the LDP restart would impact MPLS traffic during restart. However, by implementing a subset of the mechanisms in [RFC3478] they can minimize the impact if their neighbor(s) are capable of preserving their forwarding state across the restart of their LDP sessions or control planes by implementing the mechanism in [RFC3478].
[RFC3478]の手順は、全てのLSR、LDP再始動時転送状態を維持する能力を有するものと有さないものの両方に適用可能です。自民党の再起動間で彼らのMPLSフォワーディング状態を保存することができないのLSRは、再起動時にMPLSトラフィックに影響を与えるでしょう。その隣人（s）は[RFC3478]メカニズムを実装することにより、それらのLDPセッションまたはコントロールプレーンの再起動を横切って彼らの転送状態を維持することが可能である場合は、[RFC3478]での機構のサブセットを実装することによって、彼らが影響を最小限に抑えることができます。
This section considers the applicability of fault tolerance schemes within LDP networks and considers issues that might lead to the choice of one method or another. Many of the points raised below should be viewed as implementation issues rather than specific drawbacks of either solution.
このセクションでは、自民党のネットワーク内のフォールトトレランススキームの適用可能性を考慮し、一つの方法または別の選択肢につながる可能性のある問題を検討します。以下上げポイントの多くは、実装上の問題ではなく、どちらかの解決策の具体的な欠点として表示する必要があります。
The procedures described in [RFC3478] and [RFC3479] are intended to cover two distinct scenarios. In Session Failure, the LDP peers at the ends of a session remain active, but the session fails and is restarted. Note that session failure does not imply failure of the data channel even when using an in-band control channel. In Node Failure, the session fails because one of the peers has been restarted (or at least, the LDP component of the node has been restarted). These two scenarios have different implications for the ease of retention of LDP state within an individual LSR, and are described in sections below.
[RFC3478]及び[RFC3479]に記載の手順は、2つの異なるシナリオをカバーすることを意図しています。セッション失敗では、セッションの両端のLDPピアがアクティブなままですが、セッションが失敗し、再起動されます。セッション障害がインバンド制御チャネルを用いた場合でも、データチャネルの障害を意味するものではないことに留意されたいです。ピアの1つが再起動されている（または少なくとも、ノードのLDPコンポーネントが再起動されている）ので、ノード障害では、セッションは失敗します。これら2つのシナリオは、個々のLSR内LDP状態の保持を容易にするために異なった意味を有し、以下のセクションに記載されています。
These techniques are only applicable in LDP networks where at least one LSR has the capability to retain LDP signaling state and the associated forwarding state across LDP session failure and recovery. In [RFC3478], the LSRs retaining state do not need to be adjacent to the failed LSR or session.
これらの技術は、少なくとも一つのLSRは、LDPセッション障害と回復を横切っLDPシグナリング状態と関連した転送状態を保持する能力を有するLDPネットワークにのみ適用可能です。 [RFC3478]で、状態を維持するのLSRは、失敗したLSRまたはセッションに隣接している必要はありません。
If traffic is not to be impacted, both LSRs at the ends of an LDP session must at least preserve forwarding state. Preserving LDP state is not a requirement to preserve traffic.
トラフィックが影響を受けてはならない場合には、LDPセッションの両端の両方のLSRは、少なくとも転送状態を保持する必要があります。自民党の状態を保存すると、トラフィックを保存するための必要条件ではありません。
[RFC3479] requires that the LSRs at both ends of the session implement the procedures that it describes. Thus, either traffic is preserved and recovery resynchronizes state, or no traffic is preserved and the LSP fails.
[RFC3479]は、セッションの両端のLSRは、それが記述する手順を実装することを必要とします。このように、どちらかのトラフィックは保存され、回復は状態を再同期、またはトラフィックが保存されていないとLSPに障害が発生しました。
Further, to use the procedures of [RFC3479] to recover state on a session, both LSRs must have a mechanism for maintaining some session state and a way of auditing the forwarding state and the resynhcronized control state.
さらに、セッションに状態を回復するために、[RFC3479]の手順を使用するように、両方のLSRは、いくつかのセッション状態と転送状態とresynhcronized制御状態を監査する方法を維持するための機構を有していなければなりません。
[RFC3478] is scoped to support preservation of traffic if both LSRs implement the procedures that it describes. Additionally, it functions if only one LSR on the failed session supports retention of forwarding state, and implements the mechanisms in the document. In this case, traffic will be impacted by the session failure, but the forwarding state will be recovered on session recovery. Further, in the event of simultaneous failures, [RFC3478] is capable of
[RFC3478]は、両方のLSRは、それが記述する手順を実装する場合、トラフィックの保存をサポートするようにスコープされています。失敗したセッションに一つだけLSRがフォワーディングステートの保持をサポートし、文書内のメカニズムを実装している場合また、それが機能します。この場合、トラフィックは、セッションの失敗によって影響されますが、転送状態は、セッションの回復に回復されます。さらに、同時故障の場合には、[RFC3478]は可能です
relearning and redistributing state across multiple LSRs by combining its mechanisms with the usual LDP message exchanges of [RFC3036].
[RFC3036]の通常のLDPメッセージ交換とそのメカニズムを組み合わせることによって、複数のLSR間で状態を再学習し、再配布します。
In Session Failure, an LDP session between two peers fails and is restarted. There is no restart of the LSRs at either end of the session and LDP continues to function on those nodes.
セッション失敗で、2つのピア間のLDPセッションが失敗し、再起動されます。そこのLSRのない再起動は、セッションのどちらかの端にありませんし、自民党は、それらのノードで機能し続けます。
In these cases, it is simple for LDP implementations to retain the LDP state associated with the failed session and to associate the state with the new session when it is established. Housekeeping may be applied to determine that the failed session is not returning and to release the old LDP state. Both [RFC3478] and [RFC3479] handle this case.
LDP実装に失敗したセッションに関連付けられたLDP状態を保持するために、それが確立されると、新しいセッションに状態を関連付けるために、これらのケースでは、それは簡単です。ハウスキーピングは失敗したセッションが戻っていないと、古い自民党の状態を解除することを決定するために適用することができます。両方の[RFC3478]及び[RFC3479]はこのケースを扱います。
Applicability of [RFC3478] and [RFC3479] to the Session Failure scenario should be considered with respect to the availability of the data plane.
セッション失敗シナリオに[RFC3478]及び[RFC3479]の適用は、データプレーンの可用性に関して考慮されるべきです。
In some cases the failure of the LDP session may be independent of any failure of the physical (or virtual) link(s) between adjacent peers; for example, it might represent a failure of the TCP/IP stack. In these cases, the data plane is not impacted and both [RFC3478] and [RFC3479] are applicable to preserve or restore LDP state.
いくつかのケースではLDPセッションの失敗は、隣接ピア間の物理的（または仮想）リンク（単数または複数）の故障の独立していてもよいです。例えば、それは、TCP / IPスタックの失敗を表すことができます。これらの場合に、データプレーンは、影響を受けて、[RFC3478]及び[RFC3479]の両方が保存又はLDPの状態を復元するために適用されていません。
LDP signaling may also operate out of band; that is, it may use different links from the data plane. In this case, a failure of the LDP session may be a result of a failure of the control channel, but there is no implied failure of the data plane. For this scenario [RFC3478] and [RFC3479] are both applicable to preserve or restore LDP state.
LDPシグナリングはまた、帯域外で動作することができます。つまり、それは、データプレーンとは別のリンクを使用することができます。この場合、LDPセッションの失敗は、制御チャネルの失敗の結果であってもよいが、データプレーンのない暗黙の障害はありません。このシナリオでは[RFC3478]及び[RFC3479]は、両方のLDP状態を保存または復元に適用可能です。
In the case where the failure of the LDP session also implies the failure of the data plane, it may be an implementation decision whether LDP peers retain forwarding state, and for how long. In such situations, if forwarding state is retained, and if the LDP session is re-established, both [RFC3478] and [RFC3479] are applicable to preserve or restore LDP state.
LDPセッションの障害は、データプレーンの障害を暗示する場合には、LDPピアが状態を転送し、そしてどのくらいのために保持するかどうかを実装決定であってもよいです。転送状態が保持されている場合、およびLDPセッションが再確立された場合、このような状況では、両方の[RFC3478]及び[RFC3479]はLDPの状態を保存または復元に適用可能です。
When the data plane has been disrupted an objective of a recovery implementation might be to restore data traffic as quickly as possible.
データプレーンが中断された場合には、回復の実装の目的は、可能な限り迅速にデータトラフィックを復元するかもしれません。
In some circumstances, the LSRs may know in advance that an LDP session is going fail (e.g., perhaps a link is going to be taken out of service).
いくつかの状況では、のLSRは、LDPセッションが（例えば、おそらくリンクがサービスから取り出されようとしている）が失敗が起こっていることを事前に知ることができます。
[RFC3036] includes provision for controlled shutdown of a session. [RFC3478] and [RFC3479] allow resynchronization of LDP state upon re-establishment of the session.
[RFC3036]は、セッションの制御されたシャットダウンの提供を含みます。 [RFC3478]及び[RFC3479]は、セッションの再確立時にLDP状態の再同期を可能にします。
[RFC3479] offers the facility to both checkpoint all LDP states before the shut-down, and to quiesce the session so that no new state changes are attempted between the checkpoint and the shut-down. This means that on recovery, resynchronization is simple and fast.
[RFC3479]は、すべてのLDP状態、シャットダウンする前に、両方のチェックポイントに施設を提供し、新たな状態変化をチェックポイントとシャットダウンの間で試行されませんようにセッションを休止します。これは、回復には、再同期は、シンプルで早いのが特長であることを意味します。
[RFC3478] resynchronizes all state on recovery regardless of the nature of the shut-down.
[RFC3478]は関係なく、シャットダウンの自然の回復にすべての状態を再同期します。
Node Failure describes events where a whole node is restarted or where the component responsible for LDP signaling is restarted. Such an event will be perceived by the LSR's peers as session failure, but the restarting node sees the restart as full re-initialization.
ノード障害は、全ノードが再起動されるか、またはLDPシグナリングを担当するコンポーネントが再起動されるイベントを記載しています。このようなイベントは、セッションの失敗としてLSRのピアによって知覚されますが、再起動ノードは、完全な再初期化と再起動を見ています。
The basic requirement is that the forwarding state is retained, otherwise the data plane will necessarily be interrupted. If forwarding state is not retained, it may be relearned from the saved control state in [RFC3479]. [RFC3478] does not utilize or expect a saved control state. If a node restarts without preserved forwarding state it informs its neighbors, which immediately delete all label-FEC bindings previously received from the restarted node.
基本的な要件は、そうでなければ、データプレーンは必ずしも中断され、転送状態が保持されることです。転送状態が保持されていない場合は、[RFC3479]に保存された制御状態から再学習することができます。 [RFC3478]は保存された制御状態を利用か期待していません。ノードが保持フォワーディングステートなしで再起動した場合には、直前に再起動したノードから受信したすべてのラベル-FECバインディングを削除し、その隣人を、通知します。
The ways to retain a forwarding and control state are numerous and implementation specific. It is not the purpose of this document to espouse one mechanism or another, nor even to suggest how this might be done. If state has been preserved across the restart, synchronization with peers can be carried out as though recovering from Session Failure as in the previous section. Both [RFC3478] and [RFC3479] support this case.
転送および制御状態を保持する方法は多数あり、実装固有です。これは、1つのメカニズムや他を支持するために、またしてもこれが行われるかもしれない方法を提案するために、このドキュメントの目的ではありません。状態は再起動に渡って保持されている場合は、ピアとの同期は、前節のようにセッション失敗から回復しているかのように行うことができます。両方の[RFC3478]及び[RFC3479]はこのケースをサポートします。
How much control state is retained is largely an implementation choice, but [RFC3479] requires that at least small amount of per-session control state be retained. [RFC3478] does not require or expect control state to be retained.
どのくらいの制御状態が保持され、主に実装の選択肢ですが、[RFC3479]はセッションごとの制御状態の少なくとも少量が保持されている必要があります。 [RFC3478]は維持されるように制御状態を必要とするか、または期待していません。
It is also possible that the restarting LSR has not preserved any state. In this case, [RFC3479] is of no help. [RFC3478] however,
再起動LSRがどのような状態を保っていないことも可能です。この場合は、[RFC3479]は役に立たないのです。 [RFC3478]しかしながら、
allows the restarting LSR to relearn state from each adjacent peer through the processes for resynchronizing after Session Failure. Further, in the event of simultaneous failure of multiple adjacent nodes, the nodes at the edge of the failure zone can recover state from their active neighbors and distribute it to the other recovering LSRs without any failed LSR having to have saved state.
再起動LSRがセッション失敗後の再同期のための工程を経て各隣接ピアから状態を再学習することを可能にします。さらに、複数の隣接ノードが同時に故障した場合に、破損ゾーンの端にあるノードは、それらのアクティブネイバーから状態を回復することができ、任意のLSRが状態を保存しているせ失敗することなく、他の回復のLSRに配布します。
In some cases (hardware repair, software upgrade, etc.), node failure may be predictable. In these cases all sessions with peers may be shutdown and existing state retention may be enhanced by special actions.
場合によっては（ハードウェアの修復、ソフトウェアのアップグレードなど）において、ノード障害が予測可能であってもよいです。これらのケースではピアとのすべてのセッションは、シャットダウンすることができ、既存の状態の保持は、特別なアクションによって高めることができます。
[RFC3479] checkpointing and quiesce may be applied to all sessions so that state is up-to-date.
状態が最新であるように[RFC3479]チェックポイントと静止は、すべてのセッションに適用されてもよいです。
As above, [RFC3478] does not require that state is retained by the restarting node, but can utilize it if it is.
上記のように、[RFC3478]は、その状態が再起動ノードにより保持される必要がないが、それがある場合、それを利用することができます。
Speed of recovery is impacted by the amount of signaling required.
回復の速度が要求されるシグナリングの量によって影響されます。
If forwarding state is preserved on both LSRs on the failed session, then the recovery time is constrained by the time to resynchronize the state between the two LSRs.
転送状態が失敗したセッションの両方のLSRに保存されている場合は、回復時間は、2つのLSRの間の状態を再同期化する時間によって制約されます。
[RFC3479] may resynchronize very quickly. In a stable network, this resolves to a handshake of a checkpoint. At the most, resynchronization involves this handshake plus an exchange of messages to handle state changes since the checkpoint was taken. Implementations that support only the periodic checkpointing subset of [RFC3479] are more likely to have additional state to resynchronize.
[RFC3479]は非常に迅速に再同期することがあります。安定したネットワークでは、これは、チェックポイントの握手に解決されます。せいぜい、再同期は、このハンドシェイクプラスチェックポイントが取られたので、状態の変更を処理するためのメッセージの交換を伴います。 [RFC3479]の唯一の定期的なチェックポイントのサブセットをサポートする実装は、再同期するための追加の状態を持っている可能性があります。
[RFC3478] must resynchronize state for all label mappings that have been retained. At the same time, resources that have been retained by a restarting upstream LSR but are not actually required, because they have been released by the downstream LSR (perhaps because it was in the process of releasing the state), they must be held for the full resynchronization time to ensure that they are not needed.
[RFC3478]は維持されているすべてのラベルマッピングの状態を再同期する必要があります。同時に、再起動する上流のLSRによって保持されているが、それらは、下流LSR（おそらくそれは状態を解除する過程であったため）でリリースされているので、実際には、必要とされていないリソースは、彼らが保持しなければなりません彼らを必要としないことを確実にするために、完全な再同期時間。
The impact of recovery time will vary according to the use of the network. Both [RFC3478] and [RFC3479] allow advertisement of new labels while resynchronization is in progress. Issues to consider are re-availability of falsely retained resources and conflict between retained label mappings and newly advertised ones. This may cause incorrect forwarding of data (since labels are advertised from downstream), an LSR upstream of a failure may continue to forward data for one FEC on an old label while the recovering downstream LSR might re-assign that label to another FEC and advertise it. For this reason, restarting LSRs may choose to not advertise new labels until resynchronization with their peers has completed, or may decide to use special techniques to cover the short period of overlap between resynchronization and new LSP setup.
回復時間の影響は、ネットワークの使用に応じて変化します。再同期化が進行している間、両方の[RFC3478]と[RFC3479]は、新しいラベルの広告を許可します。考慮すべき問題は、誤って保持資源の再利用可能性および保持ラベルのマッピングと、新たに公示するものとの間に矛盾しています。これは、（ラベルは下流から広告されているので）データの不正確な転送を引き起こす可能性が回復し、下流LSRが別のFECにそのラベルを再割り当て、広告を出すかもしれないが、故障の上流のLSRは、古いラベルの上に1つのFECのためにデータを転送し続けることができそれ。このため、再起動のLSRは、仲間との再同期が完了するまで、新しいラベルを宣伝しないように選択することができ、または再同期と新しいLSPセットアップの間の重複の短い期間をカバーするために特別な技術を使用することもできます。
Scalability is largely the same issue as speed of recovery and is governed by the number of LSPs managed through the failed session(s).
スケーラビリティは、主の回復の速度と同じ問題であり、失敗したセッション（複数可）を介して管理LSPの数によって支配されています。
Note that there are limits to how small the resynchronization time in [RFC3478] may be made given the capabilities of the LSRs, the throughput on the link between them, and the number of labels that must be resynchronized.
LSRの機能、それらの間のリンク上のスループット、および再同期されなければならないラベルの数与えられてもよい方法小さな[RFC3478]に再同期時間に制限があることに留意されたいです。
Impact on normal operation should also be considered.
通常動作への影響も考慮しなければなりません。
[RFC3479] requires acknowledgement of all messages. These acknowledgements may be deferred as for checkpointing described in section 4, or may be frequent. Although acknowledgements can be piggy-backed on other state messages, an option for frequent acknowledgement is to send a message solely for the purpose of acknowledging a state change message. Such an implementation would clearly be unwise in a busy network.
[RFC3479]は、すべてのメッセージの確認を必要とします。これらの肯定応答は、セクション4で説明したチェックポイントのためのように延期することができる、または頻繁であってもよいです。確認応答が他の状態メッセージにピギーバックすることができますが、頻繁に確認のためのオプションは、状態変更メッセージを認めるの目的のためだけにメッセージを送信することです。このような実装は明らかに忙しいネットワークに賢明だろう。
[RFC3478] has no impact on normal operations.
[RFC3478]は通常の動作に影響を及ぼしません。
Some networks do not show a high degree of change over time, such as those using targeted LDP sessions; others change the LDP forwarding state frequently, perhaps reacting to changes in routing information on LDP discovery sessions.
ネットワークによっては、このような目標とLDPセッションを使用しているような経時変化、高度を表示しません。他の人は、おそらくLDPディスカバリセッションで情報をルーティングの変化に反応し、頻繁にLDPフォワーディング状態を変更します。
Rate of change of LDP state exchanged over an LDP session depends on the application for which the LDP session is being used. LDP sessions used for exchanging <FEC, label> bindings for establishing hop by hop LSPs will typically exchange state reacting to IGP changes. Such exchanges could be frequent. On the other hand, LDP sessions established for exchanging MPLS Layer 2 VPN FECs will typically exhibit a smaller rate of state exchange.
自民党の状態の変化率は、LDPセッション上で交換LDPセッションが使用されているアプリケーションに依存します。交換するために使用LDPセッション<FECは、ラベル>ホップのLSPでホップを確立するためのバインディングは通常状態はIGPの変化に反応し交換させていただきます。このような交流は頻繁である可能性があります。一方、LDPセッションは、MPLSレイヤ2 VPNのFECは、通常の状態交換の小さな割合を示すであろう交換するために設立しました。
In [RFC3479], two options exist. The first uses a frequent (up to per-message) acknowledgement system which is most likely to be applicable in a more dynamic system where it is desirable to preserve the maximum amount of state over a failure to reduce the level of resynchronization required and to speed the recovery time.
[RFC3479]では、2つのオプションが存在します。最初は、必要な再同期化のレベルを低減し、高速化するために、障害の上に状態の最大量を保持することが望ましい場合、より動的なシステムに適用可能である可能性が最も高い（メッセージごとまで）頻繁な確認応答システムを使用し回復時間。
The second option in [RFC3479] uses a less-frequent acknowledgement scheme known as checkpointing. This is particularly suitable to networks where changes are infrequent or bursty.
[RFC3479]での第2のオプションは、チェックポイントとして知られているあまり頻繁に確認応答方式を使用します。これは、変更がまれまたはバースト性であるネットワークに特に適しています。
[RFC3478] resynchronizes all state on recovery regardless of the rate of change of the network before the failure. This consideration is thus not relevant to the choice of [RFC3478].
[RFC3478]は関係なく、障害が発生する前に、ネットワークの変化率の回復にすべての状態を再同期します。この考慮事項は、このように、[RFC3478]の選択には関係ありません。
Both [RFC3478] and [RFC3479] are suitable for use with Downstream Unsolicited label distribution.
両方の[RFC3478]及び[RFC3479]は下流迷惑ラベル配布と共に使用するのに適しています。
[RFC3478] describes Downstream-On-Demand as an area for future study and is therefore not applicable for a network in which this label distribution mode is used. It is possible that future examination of this issue will reveal that once a label has been distributed in either distribution mode, it can be redistributed by [RFC3478] upon session recovery.
[RFC3478]は、将来の研究のための領域のような下流オンデマンドを説明し、したがって、このラベル配布モードが使用されているネットワークには適用できません。この問題の今後の検査はラベルが配布モードのいずれかで配布された後、それはセッションの回復時に[RFC3478]で再配布することができることを明らかにすることは可能です。
[RFC3479] is suitable for use in a network that uses Downstream-On-Demand label distribution.
[RFC3479]はダウンストリームオンデマンドラベル配布を使用するネットワークでの使用に適しています。
In theory, and according to [RFC3036], even in networks configured to utilize Downstream Unsolicited label distribution, there may be occasions when the use of Downstream-On-Deman distribution is desirable. The use of the Label Request message is not prohibited in a Downstream Unsolicited label distribution LDP network.
理論的に、および[RFC3036]によれば、さらに下流迷惑ラベル配布を利用するように構成されたネットワークでは、ダウンストリームオンDeman分布の使用が望ましい場合機会があってもよいです。ラベル要求メッセージの使用は、下流迷惑ラベル配布LDPネットワークで禁止されていません。
Opinion varies as to whether there is a practical requirement for the use of the Label Request message in a Downstream Unsolicited label distribution LDP network. Current deployment experience suggests that there is no requirement.
意見は、下流迷惑ラベル分配LDPネットワークにおけるラベル要求メッセージを使用するための実用的な要件があるかどうかに応じて変化します。現在の展開の経験は必要がないことを示唆しています。
Implementation complexity has consequences for the implementer and also for the deployer since complex software is more error prone and harder to manage.
実装の複雑さは、実装者のためにも複雑なソフトウェアは、より多くのエラーが発生しやすく、管理が困難であるため、配備者のための結果を持っています。
[RFC3479] is a more complex solution than [RFC3478]. In particular, [RFC3478] does not require any modification to the normal signaling and processing of LDP state changing messages.
[RFC3479]は[RFC3478]より複雑な解決策です。具体的には、[RFC3478]はLDP状態変更メッセージの正常なシグナリングおよび処理への変更を必要としません。
[RFC3479] implementations may be simplified by implementing only the checkpointing subset of the functionality.
[RFC3479]の実装は、機能のチェックポイントのみのサブセットを実装することによって簡略化することができます。
In addition to the implication for robustness associated with complexity of the solutions, consideration should be given to the effects of state preservation on robustness.
ソリューションの複雑さに関連したロバスト性のための含意に加えて、考慮事項は、堅牢で、状態保存の効果を与えられるべきです。
If state has become incorrect for whatever reason, then state preservation may retain incorrect state. In extreme cases, it may be that the incorrect state is the cause of the failure in which case preserving that state would be inappropriate.
状態が何らかの理由で正しくないとなっている場合には、状態の保存が間違った状態を保持することができます。極端なケースでは、それは間違った状態が状態が不適切であることを維持した場合には障害の原因である可能性があります。
When state is preserved, the precise amount that is retained is an implementation issue. The basic requirement is that forwarding state is retained (to preserve the data path) and that that state can be accessed by the LDP software component.
状態が保存されている場合、保持されている正確な量は、実装上の問題です。基本的な要件は、転送状態を保持（データパスを保持するために）、その状態がLDPソフトウェアコンポーネントによってアクセスすることができることであるということです。
In both solutions, if the forwarding state is incorrect and is retained, it will continue to be incorrect. Both solutions have a mechanism to housekeep and free the unwanted state after resynchronization is complete. [RFC3478] may be better at eradicating incorrect forwarding state, because it replays all message exchanges that caused the state to be populated.
転送状態が誤っていると、保持されている場合、両方のソリューションでは、それは正しくないであり続けるだろう。どちらのソリューションは、housekeepと再同期が完了した後、不要な状態を解放するためのメカニズムを持っています。それは状態が移入される原因となったすべてのメッセージ交換を再生するので、[RFC3478]は、誤った転送状態を根絶に良好であってもよいです。
In [RFC3478], no more data than the forwarding state needs to have been saved by the recovering node. All LDP state may be relearned by message exchanges with peers. Whether those exchanges may cause the same incorrect state to arise on the recovering node is an obvious concern.
[RFC3478]で、転送状態を超えないデータを回復するノードによって保存されている必要があります。全てのLDP状態はピアとのメッセージ交換によって再学習することができます。これらの交換が回復したノード上で発生すると、同じ間違った状態を引き起こす可能性かどうかは明らかに懸念されます。
In [RFC3479], the forwarding state must be supplemented by a small amount of state specific to the protocol extensions. LDP state may be retained directly or reconstructed from the forwarding state. The same issues apply when reconstructing state but are mitigated by the fact that this is likely a different code path. Errors in the retained state specific to the protocol extensions will persist.
[RFC3479]で、転送状態は、プロトコル拡張に特定状態の少量によって補完されなければなりません。 LDP状態を直接保持または転送状態から再構成することができます。同じ問題は、状態を再構築する際に適用されますが、これはおそらく異なるコード・パスであるという事実によって軽減されています。特定のプロトコルの拡張に保持した状態のエラーが持続します。
It is important that new additions to LDP interoperate with existing implementations at least in provision of the existing levels of function.
自民党への新規追加は、少なくとも機能の既存レベルの提供に既存の実装と相互運用することが重要です。
Both [RFC3478] and [RFC3479] do this through rules for handling the absence of the FT optional negotiation object during session initialization.
どちらも[RFC3478]と[RFC3479]は、セッションの初期化中にFTオプションのネゴシエーションオブジェクトの不在を処理するためのルールを介してこれを行います。
Additionally, [RFC3478] is able to perform limited recovery (i.e., redistribution of state) even when only one of the participating LSRs supports the procedures. This may offer considerable advantages in interoperation with legacy implementations.
また、[RFC3478]は限られた回復を行うことができる（すなわち、状態の再分配）参加のLSRのも一つだけが手順をサポートします。これは、従来の実装との相互運用にかなりの利点を提供することができます。
Many LDP LSRs also run other label distribution mechanisms. These include management interfaces for configuration of static label mappings, other distinct instances of LDP, and other label distribution protocols. The last example includes traffic engineering label distribution protocol that are used to construct tunnels through which LDP LSPs are established.
多くの自民党のLSRは、他のラベル配布メカニズムを実行します。これらは、管理静的ラベルマッピングの構成のためのインターフェース、LDPの他の異なるインスタンス、及び他のラベル配布プロトコルを含みます。最後の例では、自民党のLSPが確立されてトンネルを構築するために使用されているトラフィックエンジニアリングラベル配布プロトコルを含んでいます。
As with re-use of individual labels by LDP within a restarting LDP system, care must be taken to prevent labels that need to be retained by a restarting LDP session or protocol component from being used by another label distribution mechanism. This might compromise data security, amongst other things.
再始動LDPシステム内LDPによって個々のラベルの再利用と同様に、注意が別のラベル配布メカニズムによって使用されてから再始動LDPセッションまたはプロトコルコンポーネントによって保持される必要があるラベルを防止するために注意しなければなりません。これは、とりわけ、データのセキュリティを危険にさらす可能性があります。
It is a matter for implementations to avoid this issue through the use of techniques, such as a common label management component or segmented label spaces.
実装は、このような共通のラベル管理コンポーネントまたはセグメント化されたラベルスペースなどの技術の使用により、この問題を回避することが問題です。
CR-LDP [RFC3212] utilizes Downstream-On-Demand label distribution. [RFC3478] describes Downstream-On-Demand as an area for future study and is therefore not applicable for CR-LDP. [RFC3479] is suitable for use in a network entirely based on CR-LDP or in one that is mixed between LDP and CR-LDP.
CR-LDP [RFC3212]はダウンストリームオンデマンドラベル配布を利用しています。 [RFC3478]は、将来の研究のための領域のような下流オンデマンドを説明し、したがって、CR-LDPのために適用されません。 [RFC3479]は、完全CR-LDPまたはLDPやCR-LDPとの間に混合されるかに基づいて、ネットワークでの使用に適しています。
This document is informational and introduces no new security concerns.
この文書は情報提供で、新たなセキュリティ上の懸念を導入していません。
The security considerations pertaining to the original LDP protocol [RFC3036] remain relevant.
オリジナルのLDPプロトコル[RFC3036]に関連するセキュリティ上の考慮事項は、関連残ります。
[RFC3478] introduces the possibility of additional denial-of- service attacks. 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].
[RFC3478]は、追加のサービス拒否攻撃の可能性を紹介します。これらの攻撃の全ては、[LDP]に概説MD5ベースの方式としてLDPピア間の認証スキームを使用することによって対抗することができます。
In MPLS, a data mis-delivery security issue can arise if an LSR continues to use labels after expiration of the session that first caused them to be used. Both [RFC3478] and [RFC3479] are open to this issue.
LSRは、最初にそれらを使用される原因となったセッションの満了後にラベルを使用し続ける場合MPLSでは、データの誤配信のセキュリティ問題が発生する可能性があります。どちらも[RFC3478]と[RFC3479]は、この問題に開放されています。
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専務に情報を扱ってください。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[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月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC3478] Leelanivas, M., Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism for LDP", RFC 3478, February 2003.
[RFC3478] Leelanivas、M.、Rekhter、Y.及びR.アガルワル、 "LDPのためのグレースフルリスタート機構"、RFC 3478、2003年2月。
[RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]、RFC 3479、2003年2月ファレル、A.、エディタ、 "ラベル配布プロトコル（LDP）のためのフォールトトレランス"。
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[RFC2547]ローゼン、E.およびY. Rekhter、 "BGP / MPLS VPNの"、RFC 2547、1999年3月。
[RFC3212] Jamoussi, B., Editor, Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B.、エディタ、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、 Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.およびA. Malis、 "LDPを使用して、制約ベースLSPセットアップ"、RFC 3212、2002年1月。
[RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[RFC3469]シャルマ、V.、エド。、およびF. Hellstrandは、エド。、RFC 3469、2003年2月、 "マルチプロトコルラベルのためのフレームワークは、回復をベーススイッチング（MPLS）"。
The author would like to thank the authors of [RFC3478] and [RFC3479] for their work on fault tolerance of LDP. Many thanks to Yakov Rekhter, Rahul Aggarwal, Manoj Leelanivas and Andrew Malis for their considered input to this applicability statement.
著者は、自民党のフォールトトレランスに自分の仕事のために[RFC3478]と[RFC3479]の著者に感謝したいと思います。この適用性声明に自分と考えの入力のためのヤコフ・レックター、ラウール・アガーウォール、ManojさんLeelanivasとアンドリューMalisに感謝します。
Adrian Farrel Old Dog Consulting
エードリアンファレル古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
電話：+44（0）1978 860944 Eメール：adrian@olddog.co.uk
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。