[要約] RFC 3612は、ラベル配布プロトコル（LDP）の再起動メカニズムの適用性に関する声明であり、LDPの再起動に関するガイドラインを提供します。このRFCの目的は、ネットワークの信頼性と安定性を向上させるために、LDPの再起動手順を明確化することです。
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)
ラベル分布プロトコル（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.
Copyright（c）The Internet Society（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.
スイッチングハードウェアやTCPスタックなど、FT LSRのさまざまなコンポーネントでFTがどのように達成されるかの詳細は、実装固有です。ソフトウェアモジュール自体がLDPによって作成された状態のFTを実装することを選択する方法も実装固有です。ただし、LDP仕様[RFC3036]には、これらのプロトコルへの拡張機能なしでLDPプロトコルを使用してFT LSRを実装することを困難にするいくつかの問題があります。
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は、FTハードウェアまたはソフトウェアを活用して、コアネットワークの高可用性（HA）を提供する場合があります。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.
3番目の例は、プロセッサやその他のハードウェアの障害やソフトウェアの障害など、さまざまなイベントによって引き起こされる場合があります。
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ピアのペア（少なくとも1つは障害によって直接影響を受ける）に保持されている状態が同期されるように手順が必要です。このような手順は、コントロールプレーンプロトコルを使用して、ピアのコントロールプレーンソフトウェアモジュールに実装する必要があります。
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.
LDPはTCPを使用して、LSR間の信頼できる接続を提供して、プロトコルメッセージを交換してラベルを配布し、LSPをセットアップします。このような接続を持つ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はプロトコルメッセージの信頼できる転送を引き受けることができます。これは、一部のメッセージを確認する必要がないことを意味します（ラベルのリリースなど）。
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.
LDPは、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または転送状態を取り壊す必要がないように、LDPの基本要件の変更を含める必要があります。
Any changes made to LDP in support of recovery processing must meet the following requirements:
回復処理をサポートするLDPに加えられた変更は、次の要件を満たす必要があります。
- 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.
- [RFC3036]に記載されている既存のプロトコルルールを保存し、予期しない重複メッセージを処理し、不明なLSP/ラベルを参照する予期しないメッセージを処理するために保存します。
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メッセージの最新の確認（チェックポイント）の勧誘して、現在の状態が確保されるようにします。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.
[RFC3479]のFT手順は、これらのLSR間のTCP接続が失われたときに、隣接するLSRのペア間で交換されるラベルのラベル状態の保存に集中します。これらの手順には、LSPのエンドツーエンドの保護をサポートする意図はありません。
LDP graceful restart extensions are defined in [RFC3478]. This approach involves:
LDP Graceful Restart拡張機能は[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の少なくとも1つが障害全体で状態を保持しているか、それ自体が同業他社と再同期していることを条件とします。
- 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]の手順は、LDPの再起動中に転送状態を保存する能力を持つすべてのLSRに適用できます。LDPの再起動全体でMPLS転送状態を保存できないLSRは、再起動中のMPLSトラフィックに影響を与えます。ただし、[RFC3478]にメカニズムのサブセットを実装することにより、隣人が[RFC3478]のメカニズムを実装することにより、LDPセッションの再起動または統制平面全体で転送状態を保存できる場合、影響を最小限に抑えることができます。
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.
このセクションでは、LDPネットワーク内のフォールトトレランススキームの適用性を考慮し、何らかの方法を選択する可能性のある問題を検討します。以下で提起されたポイントの多くは、いずれかのソリューションの特定の欠点ではなく、実装の問題と見なす必要があります。
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.
これらの手法は、少なくとも1つのLSRがLDPシグナル伝達状態を保持し、LDPセッションの障害と回復全体で関連する転送状態を保持する機能を備えているLDPネットワークでのみ適用可能です。[RFC3478]では、LSRS保持状態は、失敗した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は、少なくとも転送状態を保持する必要があります。LDP状態の保存は、トラフィックを維持するための要件ではありません。
[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には、セッション状態を維持するためのメカニズムと、転送状態とResynhccronized Control状態を監査する方法が必要です。
[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 relearning and redistributing state across multiple LSRs by combining its mechanisms with the usual LDP message exchanges of [RFC3036].
[RFC3478]は、両方のLSRが説明する手順を実装した場合、トラフィックの保存をサポートするためにスコープされます。さらに、失敗したセッションで1つのLSRのみが転送状態の保持をサポートし、ドキュメント内のメカニズムを実装する場合に機能します。この場合、トラフィックはセッションの失敗の影響を受けますが、転送状態はセッションの回復時に回復されます。さらに、同時障害が発生した場合、[RFC3478]は、そのメカニズムを通常のLDPメッセージ交換と[RFC3036]と組み合わせることにより、複数の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の再起動はなく、LDPはこれらのノードで機能し続けます。
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状態を保持し、州を確立されたときに新しいセッションに関連付けることが簡単です。ハウスキーピングを適用して、失敗したセッションが戻っていないことを判断し、古い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).
状況によっては、LSRSは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状態のすべてのチェックポイントに機能を提供し、セッションをQuiesceして、チェックポイントとシャットダウンの間に新しい状態の変更が試みられないようにします。これは、回復時に再同期がシンプルで高速であることを意味します。
[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, 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の再起動がいかなる状態を保持していない可能性もあります。この場合、[RFC3479]は役に立ちません。ただし、[RFC3478]が、セッションの失敗後に再同期するために、プロセスを通じて、隣接する各ピアから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]チェックポイントとQuiesceをすべてのセッションに適用できるため、状態は最新のものです。
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は古いラベルで1つのFECのデータを転送し続ける可能性がありますが、回復中の下流LSRはそのラベルに別の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.
[RFC3478]の再同時期化時間がどれだけ小さいか、LSRの機能、それらの間のリンクのスループット、および再同期に必要なラベルの数を考えると、制限があることに注意してください。
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セッションが使用されているアプリケーションに依存します。LSPによるホップを確立するための<FEC、ラベル>バインディングの交換に使用されるLDPセッションは、通常、IGPの変更に反応する状態を交換します。そのような交換は頻繁に起こる可能性があります。一方、MPLSレイヤー2 VPN FECを交換するために確立されたLDPセッションは、通常、州の交換率が少ないことを示します。
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つのオプションが存在します。1つ目は、より動的なシステムに適用される可能性が最も高い頻繁な（最大）承認システムを使用します。回復時間。
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]によれば、下流の未承諾ラベル分布を利用するように構成されたネットワークであっても、ダウンストリームオンデマンの分布の使用が望ましい場合があります。ラベルリクエストメッセージの使用は、下流の未承諾ラベルディストリビューション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.
両方のソリューションで、転送状態が正しくなく、保持されている場合、引き続き正しくありません。両方のソリューションには、再同期が完了した後、不要な状態を家に保ち、解放するメカニズムがあります。[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.
LDPへの新しい追加が、少なくとも既存の機能レベルの提供において、既存の実装と相互運用することが重要です。
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の1つだけが手順をサポートしている場合でも、限られた回復（つまり、状態の再分配）を実行できます。これは、レガシーの実装との相互操作にかなりの利点を提供する可能性があります。
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.
多くのLDP LSRは、他のラベル分布メカニズムも実行されます。これらには、静的ラベルマッピングの構成、LDPのその他の異なるインスタンス、およびその他のラベル分布プロトコルの管理インターフェイスが含まれます。最後の例には、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.
MPLSでは、LSRが最初に使用されたセッションの満了後もLSRがラベルを使用し続けると、データの誤った配信セキュリティの問題が発生する可能性があります。[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] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「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. Aggarwal、「LDPの優雅な再起動メカニズム」、RFC 3478、2003年2月。
[RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479] Farrel、A.、編集者、「ラベル分布プロトコル（LDP）のフォールトトレランス」、RFC 3479、2003年2月。
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[RFC2547] Rosen、E。およびY. Rekhter、「BGP/MPLS VPNS」、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.、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。、および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] Sharma、V.、ed。、およびF. Hellstrand、ed。、「マルチプロトコルラベルスイッチング（MPLS）ベースの回復のフレームワーク」、RFC 3469、2003年2月。
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]の著者にLDPの断層許容度に関する研究について感謝したいと思います。Yakov Rekhter、Rahul Aggarwal、Manoj Leelanivas、およびAndrew Malisに、この適用性声明への入力に感謝します。
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
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 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エディター機能の資金は現在、インターネット協会によって提供されています。