RFC3612 日本語訳
3612 Applicability Statement for Restart Mechanisms for the LabelDistribution Protocol (LDP). A. Farrel. September 2003. (Format: TXT=35677 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Farrel Request for Comments: 3612 Old Dog Consulting Category: Informational September 2003
コメントを求めるワーキンググループA.ファレル要求をネットワークでつないでください: 3612年の古い犬のコンサルティングカテゴリ: 情報の2003年9月
Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)
ラベル分配プロトコルのための再開メカニズムのための適用性証明(自由民主党)
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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".
何らかのフォームのLabel Distributionプロトコル(自由民主党)再開メカニズムを実行するのがいつ賢明であるか、そして、どちらのアプローチが、より適当であるかもしれないかに関してこのドキュメントは指導を提供します。 「規制ベースのLSPセットアップは自由民主党を使用し」て、本書では説明された問題と拡大は等しくRFC3212に適切です。
1. Introduction
1. 序論
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.
Multiprotocol Label Switching(MPLS)システムはシステム休止時間を最小限に保たなければならないコアネットワークに使用されます。 また、同様に、MPLSがネットワーク縁(例えば、Provider Edge(PE)ルータにおける)[RFC2547]にあるところでは、システム休止時間を最小限に保たなければなりません。 したがって、多くのMPLS Label Switching Routers(LSRs)が、コアネットワークの高い有用性を提供するのにFault Tolerant(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の様々な部品のためにどう達成されるかに関する詳細は実現特有です。 また、ソフトウェア・モジュール自体が、自由民主党によって創設された状態にFTを実行するのをどう選ぶかも、実現特有です。 しかしながら、何らかの拡大なしでそれらのプロトコルに自由民主党プロトコルを使用することでFT LSRを実行するのを難しくする自由民主党仕様[RFC3036]にはいくつかの問題があります。
Proposals have been made in [RFC3478] and [RFC3479] to address these issues.
[RFC3478]と[RFC3479]でこれらの問題を記述するのを提案をしました。
Farrel Informational [Page 1] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[1ページ]のRFC3612Applicability
2. Requirements of an LDP FT System
2. 自由民主党フィートの要件、システム
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 LSRsが、コアネットワークの高可用性(HA)を提供するのにFTハードウェアかソフトウェアを利用するかもしれません。 HAを提供するために、MPLSシステムは、Data Planeの最小量の分裂におけるさまざまな欠点を乗り切ることができる必要があります、以下の欠点タイプを含んでいて:
- failure/hot-swap of the switching fabric in an LSR,
- LSRの切り換え織物の失敗/ホットスワップ
- failure/hot-swap of a physical connection between LSRs,
- LSRsの間の物理接続の失敗/ホットスワップ
- failure of the TCP or LDP stack in an LSR,
- LSRでのTCPか自由民主党スタックの失敗
- software upgrade to the TCP or LDP stacks in an LSR.
- TCPか自由民主党へのソフトウェアの更新はLSRで積み重ねられます。
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つの例がData Planeに限定されるかもしれません。 Control Planeで作動しながら、自由民主党に透明なData Planeで冗長を提供することによって、そのような欠点を扱うことができます。 しかしながら、シグナリングが混乱させられるかもしれないので、切り換え織物か物理的なリンクの失敗はControl Planeで波及するかもしれません。
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つの例のどれかは、Control Planeに影響を与えるかもしれなくて、回復するためにControl Planeで動作を必要とするでしょう。そのような動作は、Data Planeの交通を中断するのを避けるように設計されるべきです。 多くの最近のルータ建築がControlとDataプラネスを切り離すことができるので、推進がControl Planeで回復動作で影響を受けない状態で続くことができるのは、可能です。
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.
他のシナリオでは、欠点でDataとControlプラネスに影響を与えるかもしれませんが、HAの必要性はDataとControlプラネスの連携回復を欠点の前に存在した状態に必要とします。
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.
このドキュメントの範囲の外に保護LSPsの使用によるMPLS LSPのための保護経路の支給とリンク、IPルートまたはトンネルの保護があります。 詳細に関して[RFC3469]を見てください。
3. General Considerations
3. 一般問題
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
手順がDataとControl Plane州が欠点の後に首尾よく回収されるのに状態が1組の自由民主党の同輩の上で成立したのを保証するのに必要である、(少なくともそれの1つは影響を受けました。
Farrel Informational [Page 2] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[2ページ]のRFC3612Applicability
directly by the fault) are synchronized. Such procedures must be implemented in the Control Plane software modules on the peers using Control Plane protocols.
直接、欠点) 連動します。 Control Planeプロトコルを使用しながら、同輩の上でControl Planeソフトウェア・モジュールでそのような手順を実行しなければなりません。
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.
反応回復動作はcheckpointingに基づく同輩と同期の間の状態の完全な再シグナリングと状態の再同期を含むかもしれません。
Proactive recovery actions may include hand-shaking state transitions and checkpointing.
先を見越す回復動作は初期手順状態遷移とcheckpointingを含むかもしれません。
4. Specific Issues with the LDP Protocol
4. 自由民主党プロトコルの特定の問題
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.
自由民主党は、ラベルを分配して、LSPsをセットアップするプロトコルメッセージを交換するためにLSRsの間の頼もしい接続を提供するのにTCPを使用します。 そのような接続がある1組のLSRsが自由民主党の同輩と呼ばれます。
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は、自由民主党がプロトコルメッセージの信頼できる転送を仮定するのを可能にします。 これは、メッセージのいくつかが承認される必要はないことを(例えば、Label Release)意味します。
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はすぐに、自由民主党の同輩の間でセッションに関連しているLSPsを取りこわして、どんなラベルとリソースも割り当てたリリースをそれらのLSPsまで取りこわすべきです。
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のFault Tolerant実現を提供するのは悪名高く難しいです。 そうするのは、すべてのデータのコピーを送られて、受け取るように作ることを伴うかもしれません。 これはBGPなどの他のTCPアプリケーションのimplementersに身近な問題です。
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に影響するフェイルオーバーか自由民主党スタックの間、したがって、TCP接続は迷子になるかもしれません。 自由民主党コントロールメッセージが接続失敗の間失われているかもしれないという事実はこの位置からの回復をより悪くします。 これらのメッセージが未確認であるので、LSPかラベル州の情報が失われるのは、可能です。
Farrel Informational [Page 3] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[3ページ]のRFC3612Applicability
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.
少なくとも、この問題の解決が自由民主党に関する基本的な要件への変化を含まなければならないので、自由民主党のセッションの失敗は、関連自由民主党か推進状態が取りこわされるのを必要としません。
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,
- 自由民主党に拡大を実行しないLSRsとの後方の互換性を提供してください。
- preserve existing protocol rules described in [RFC3036] for handling unexpected duplicate messages and for processing unexpected messages referring to unknown LSPs/labels.
- 未知のLSPs/ラベルについて言及する予期していなかった写しメッセージを扱って、予期していなかったメッセージを処理するために[RFC3036]で説明された既存のプロトコル規則を保存してください。
Ideally, any solution applicable to LDP should be equally applicable to CR-LDP.
理想的に、自由民主党に適切などんな解決策も等しくCR-自由民主党に適切であるべきです。
5. Summary of the Features of LDP FT
5. 自由民主党フィートの特徴の概要
LDP Fault Tolerance extensions are described in [RFC3479]. This approach involves:
自由民主党Fault Tolerance拡張子は[RFC3479]で説明されます。 このアプローチは以下にかかわります。
- negotiation between LDP peers of the intent to support extensions to LDP that facilitate recovery from failover without loss of LSPs,
- 自由民主党へのLSPsの損失なしでフェイルオーバーからの回復を容易にする拡大を支持する意図の自由民主党の同輩の間の交渉
- selection of FT survival on a per LSP/label basis or for all labels on a session,
- LSP/ラベル基礎かセッションでのすべてのラベルのためのaにおけるFT生存の選択
- sequence numbering of LDP messages to facilitate acknowledgement and checkpointing,
- 承認とcheckpointingを容易にする自由民主党メッセージの系列付番
- 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,
- 完全な握手が頻繁(メッセージに従ってそのようなもの)かそれほど頻繁でなくcheckpointingしないことのようにそれらのメッセージに実行されるのを保証する自由民主党メッセージの承認
- 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,
- 現状を確実にする前の自由民主党メッセージの最新の承認(checkpointing)の懇願を保証します、自由民主党のパートナーが、優雅な閉鎖が必要であるなら状態が両方の方向に洗い流されるよう要求できる追加オプションで
- 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,
- 自由民主党のセッション失敗の、後にもかかわらず、自由民主党コミュニケーションが復職しないなら捨てられる前を除いて、どれくらい長い間制御するタイマは保有されるべきです自由民主党と推進が、述べる。
Farrel Informational [Page 4] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[4ページ]のRFC3612Applicability
- exchange of checkpointing information on LDP session recovery to establish what state has been retained by recovering LDP peers,
- どんな状態が自由民主党を回復することによって保有されたかを証明する自由民主党のセッション回復におけるcheckpointing情報の交換はじっと見ます。
- re-issuing lost messages after failover to ensure that LSP/label state is correctly recovered after reconnection of the LDP session.
- 確実にするLSP/ラベルが述べるフェイルオーバーが自由民主党のセッションの再接続の後に正しく回復された後に再発行はメッセージを失いました。
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手順はそれらのLSRsの間のTCP接続が迷子になっているとき1組の隣接しているLSRsの間で交換されたラベルのためにラベル状態の保存に集中します。 LSPsのために終わりから終わりへの保護を支持するために、これらの手順の中に意志は全くありません。
6. Summary of the Features of LDP Graceful Restart
6. 自由民主党の優雅な再開の特徴の概要
LDP graceful restart extensions are defined in [RFC3478]. This approach involves:
自由民主党の優雅な再開拡大は[RFC3478]で定義されます。 このアプローチは以下にかかわります。
- negotiation between LDP peers of the intent to support extensions to LDP that facilitate recovery from failover without loss of LSPs,
- 自由民主党へのLSPsの損失なしでフェイルオーバーからの回復を容易にする拡大を支持する意図の自由民主党の同輩の間の交渉
- a mechanism whereby an LSR that restarts can relearn LDP state by resynchronization with its peers,
- 再開するLSRが同輩と共に再同期で自由民主党状態を学び直すことができるメカニズム
- 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,
- 少なくともLSRsの1つに、失敗の向こう側の保有された状態を持っているか、またはそれ自体がいれば彼らの同輩と共に自由民主党状態を再連動させない自由民主党セッションのことから回復するLSRsを許容する同じメカニズムの使用は同輩と共に状態を再連動させました。
- 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,
- 自由民主党のセッション失敗の、後にもかかわらず、自由民主党コミュニケーションが復職しないなら捨てられる前を除いて、どれくらい長い間制御するタイマは保有されるべきです自由民主党と推進が、述べる。
- 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]の手順はすべてのLSRs(能力がある自由民主党の再開とそれらの間の推進状態を保持する両方のそれら)に適切です。 自由民主党の再開の向こう側に彼らのMPLS推進状態を保持できないLSRsが再開の間、MPLS交通に影響を与えるでしょう。 しかしながら、[RFC3478]のメカニズムの部分集合を実行することによって、彼らの隣人がそれらの自由民主党のセッションか制御飛行機の再開の向こう側に[RFC3478]のメカニズムを実行することによってそれらの推進状態を保持できるなら、それらは衝撃を最小にすることができます。
Farrel Informational [Page 5] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[5ページ]のRFC3612Applicability
7. Applicability Considerations
7. 適用性問題
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.
このセクションは、自由民主党ネットワークの中で耐障害性計画の適用性を考えて、何らかの方法の選択につながるかもしれない問題を考えます。 実現が解決策の特定の欠点よりむしろ発行するように以下に上げられたポイントの多くが見られるべきです。
7.1. General Applicability
7.1. 一般適用性
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つの異なったシナリオをカバーすることを意図します。 Session Failureでは、セッションの終わりの自由民主党の同輩がアクティブな状態で留まりますが、セッションは、失敗して、再開されます。 バンドの制御チャンネルを使用さえするとき、セッション失敗がデータ・チャンネルの失敗を含意しないことに注意してください。 Node Failureでは、同輩のひとりが再開されたので(少なくとも、ノードの自由民主党成分は再開されました)、セッションは失敗します。 これらの2つのシナリオが、個々のLSRの中に自由民主党状態の保有の容易さのための異なった意味を持って、下のセクションで説明されます。
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.
これらのテクニックは少なくとも1LSRが自由民主党のセッション失敗と回復の向こう側に自由民主党シグナリング州と関連推進状態を保有する能力を持っている自由民主党ネットワークだけで適切です。 [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.
交通が影響を与えられないことであるなら、自由民主党のセッションの終わりの両方のLSRsは推進状態を少なくとも保持しなければなりません。 自由民主党状態を保持するのは、交通を保持するという要件ではありません。
[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]は、セッションの両端のLSRsがそれが説明する手順を実行するのを必要とします。 したがって、交通は保持されます、そして、交通は全く保持されません、そして、回復が状態を再連動させるか、または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]の手順を用いるために、両方のLSRsには、何らかのセッションのときに推進を監査する状態と方法が州と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
両方のLSRsがそれが説明する手順を実行するなら、[RFC3478]は、交通の保存を支持するために見られます。 さらに、失敗したセッションでの1LSRだけが推進状態の保有を支持して、ドキュメントでメカニズムを実行するなら、それは機能します。 この場合、セッション失敗で交通に影響を与えるでしょうが、セッション回復で推進状態を回復するでしょう。 一層、同時の失敗の場合、[RFC3478]はできます。
Farrel Informational [Page 6] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[6ページ]のRFC3612Applicability
relearning and redistributing state across multiple LSRs by combining its mechanisms with the usual LDP message exchanges of [RFC3036].
複数のLSRsの向こう側に[RFC3036]の普通の自由民主党交換処理にメカニズムを結合することによって、状態を学び直して、再配付します。
7.2. Session Failure
7.2. セッション失敗
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.
Session Failureでは、2人の同輩の間の自由民主党のセッションは、失敗して、再開されます。 セッションのどちらの終わりにも、LSRsの再開が全くありません、そして、自由民主党はそれらのノードの上で機能し続けています。
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.
これらの場合では、自由民主党の実現が失敗したセッションに関連している自由民主党状態を保有して、それが設立される新しいセッションに状態を関連づけるのは簡単です。 家事は、失敗したセッションが戻っていないことを決定して、古い自由民主党状態をリリースするために適用されるかもしれません。 [RFC3478]と[RFC3479]の両方が本件を扱います。
Applicability of [RFC3478] and [RFC3479] to the Session Failure scenario should be considered with respect to the availability of the data plane.
Session Failureシナリオへの[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.
いくつかの場合、自由民主党のセッションの失敗は隣接している同輩の間の物理的で(仮想)のリンクのどんな失敗からも独立しているかもしれません。 例えば、それはTCP/IPスタックの失敗を表すかもしれません。 これらの場合では、データ飛行機は影響を与えられないで、[RFC3478]と[RFC3479]の両方が自由民主党状態を保持するか、または回復するのにおいて適切です。
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.
また、自由民主党シグナリングはバンドから作動するかもしれません。 すなわち、それはデータ飛行機と異なったリンクを使用するかもしれません。 この場合、自由民主党のセッションの失敗は制御チャンネルの失敗の結果であるかもしれませんが、データ飛行機のどんな暗示している失敗もありません。 このシナリオにおいて、[RFC3478]と[RFC3479]は自由民主党状態を保持するか、または回復するのにおいてともに適切です。
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.
また自由民主党のセッションの失敗がデータ飛行機の失敗を含意する場合では、それは、自由民主党の同輩が推進状態を保有するかどうかという実現決定であり、どれくらい長い間、そうであるかもしれないか。 そのような状況で、推進状態が保有されて、自由民主党のセッションが復職するなら、[RFC3478]と[RFC3479]の両方が自由民主党状態を保持するか、または回復するのにおいて適切です。
When the data plane has been disrupted an objective of a recovery implementation might be to restore data traffic as quickly as possible.
データ飛行機が混乱させられたとき、回復実現の目的はできるだけはやくデータ通信量を復元することであるかもしれません。
Farrel Informational [Page 7] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[7ページ]のRFC3612Applicability
7.3. Controlled Session Failure
7.3. 制御セッション失敗
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は、あらかじめ、自由民主党のセッションが失敗しに行くのを知るかもしれません(使われなくなっていた状態で恐らく例えばリンクを取るでしょう)。
[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]はセッションの再建の自由民主党状態の再同期を許容します。
[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]がすべての自由民主党が閉鎖の前に述べるチェックポイントとquiesceへのセッションの両方に施設を提供するので、どんな新しい州の変化もチェックポイントと閉鎖の間で試みられません。 これは、再同期が回復では、簡単であって、速いことを意味します。
[RFC3478] resynchronizes all state on recovery regardless of the nature of the shut-down.
[RFC3478]は閉鎖の本質にかかわらず回復のすべての状態を再連動させます。
7.4. Node Failure
7.4. ノード障害
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.
全体のノードが再開されるか、または自由民主党シグナリングに原因となるコンポーネントが再開されるところでノードFailureは出来事について説明します。 そのような出来事はセッション失敗として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.
推進とコントロール状態を保有する方法は、多数であって実現特有です。 何らかのメカニズムを信奉して、これがどのように完了しているかもしれないかを示すのさえ、このドキュメントの目的ではありません。 状態が再開の向こう側に保持されたなら、まるで前項のようにSession Failureから回復するかのように同輩との同期を行うことができます。 [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] しかしながら
Farrel Informational [Page 8] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[8ページ]のRFC3612Applicability
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がそれぞれの隣接している同輩からSession Failureの後に再連動するための過程で状態を学び直すのを許容します。 さらに、失敗ゾーンの縁のノードは、複数の隣接しているノードの同時の失敗の場合、状態を節約しなければならなかった少しも失敗したLSRなしでLSRsを回収しながら、彼らの活発な隣人から状態を取り戻して、もう片方にそれを分配できます。
7.5. Controlled Node Failure
7.5. 制御ノード障害
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] checkpointingとquiesceは、状態が最新であるように、すべてのセッションに適用されるかもしれません。
As above, [RFC3478] does not require that state is retained by the restarting node, but can utilize it if it is.
同じくらい上では、それが必要であるなら、[RFC3478]が、州が再開ノードによって保有されますが、それを利用できるのを必要としません。
7.6. Speed of Recovery
7.6. 回復の速度
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.
推進状態が失敗したセッションのときに両方のLSRsに保持されるなら、その時です。回復時間が2LSRsの間の状態を再連動させるのが抑制される
[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]の周期的なcheckpointing部分集合だけをサポートする実現は再連動させる追加状態をより持っていそうです。
[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
ネットワークの使用に従って、回復時間の衝撃は異なるでしょう。 再同期が進行している間、[RFC3478]と[RFC3479]の両方が新しいラベルの広告を許します。 考える問題は保有されたラベルマッピングと新たに広告を出したものとの間違って保有されたリソースと闘争の再の有用性です。 これはそうするかもしれません。
Farrel Informational [Page 9] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[9ページ]のRFC3612Applicability
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.
回復している川下のLSRが別のFECにそのラベルを再選任して、それの広告を出すかもしれませんが、古いラベルの上の1FECのためのデータを転送することをデータ(ラベルが川下から広告に掲載されるので)、失敗の上流が続けるかもしれないLSRの不正確な推進を引き起こします。 この理由、LSRsが選ぶかもしれない再開のために、彼らの同輩がいる再同期が広告を出すまで新しいラベルの広告を出さないのは、完了しているか、または再同期と新しいLSPセットアップの間のオーバラップの短期をカバーするのに特殊技術を使用すると決めるかもしれません。
7.7. Scalability
7.7. スケーラビリティ
Scalability is largely the same issue as speed of recovery and is governed by the number of LSPs managed through the failed session(s).
スケーラビリティは、回復の速度と主に同じ問題であり、失敗したセッションで管理されたLSPsの数によって治められます。
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.
LSRsの能力、彼らの間のリンクに関するスループット、および再連動しなければならないラベルの数を考えて、[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で説明されたcheckpointingのように延期されるかもしれないか、または頻繁であるかもしれません。 他の州のメッセージで承認を背負うことができますが、頻繁な承認のためのオプションは唯一州の変化メッセージを承認する目的へのメッセージを送ることです。 そのような実現は忙しいネットワークで明確に賢明でないでしょう。
[RFC3478] has no impact on normal operations.
[RFC3478]は通常操作に変化も与えません。
7.8. Rate of Change of LDP State
7.8. 自由民主党状態の増減率
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.
いくつかのネットワークは時間がたつにつれて、狙っている自由民主党のセッションを使用するものなどのように高度の変化を示しません。 恐らく自由民主党の発見セッションのルーティング情報における変化に反応して、他のものは頻繁に自由民主党推進状態を変えます。
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.
自由民主党のセッションの間に交換された自由民主党状態の増減率は自由民主党のセッションが使用されているアプリケーションに依存します。 <FECを交換するのに使用される自由民主党のセッション、ホップLSPsでホップを設立するためのラベル>結合はIGP変化に反応する州を通常交換するでしょう。 そのような交換は頻繁であるかもしれません。 他方では、MPLS Layer2VPN FECsを交換するために確立された自由民主党のセッションは州の交換の、よりわずかな速度を通常示すでしょう。
Farrel Informational [Page 10] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[10ページ]のRFC3612Applicability
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番目のオプションはcheckpointingするとして知られているそれほど頻繁でない承認計画を使用します。 これは特に変化が珍しいネットワークかburstyに適しています。
[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]の選択に関連していません。
7.9. Label Distribution Modes
7.9. ラベル分配モード
Both [RFC3478] and [RFC3479] are suitable for use with Downstream Unsolicited label distribution.
[RFC3478]と[RFC3479]の両方がDownstream Unsolicitedラベル分配によって使用に適しています。
[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]は、今後の研究のために要求でのDownstreamを領域として記述して、このラベル分配モードが使用されているネットワークには、したがって、適切ではありません。 この問題の今後の試験が、ラベルが分配モードでいったん分配されると、[RFC3478]がセッション回復でそれを再配付できるのを明らかにするのは、可能です。
[RFC3479] is suitable for use in a network that uses Downstream-On- Demand label distribution.
[RFC3479]はDownstream進行中の要求しているラベル分配を使用するネットワークにおける使用に適しています。
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]に従って、Downstream Unsolicitedラベル分配を利用するために構成されたネットワークではさえデーマンの上のDownstream分配の使用が望ましい時があるかもしれません。 Label Requestメッセージの使用はDownstream Unsolicitedラベル分配自由民主党ネットワークで禁止されていません。
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.
Downstream Unsolicitedラベル分配自由民主党ネットワークにおけるLabel Requestメッセージの使用のための実際的な要件があるかどうかに関して意見は異なります。 現在の展開経験は、要件が全くないのを示します。
7.10. Implementation Complexity
7.10. 実現の複雑さ
Implementation complexity has consequences for the implementer and also for the deployer since complex software is more error prone and harder to manage.
複雑なソフトウェアが管理するのが傾向があって、より困難であるより多くの誤りであるので、実現の複雑さに、implementerとデプロイヤのために結果がもあります。
Farrel Informational [Page 11] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[11ページ]のRFC3612Applicability
[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]はメッセージを変える自由民主党州の正常なシグナリングと処理への少しの変更も必要としません。
[RFC3479] implementations may be simplified by implementing only the checkpointing subset of the functionality.
[RFC3479]実現は、機能性のcheckpointing部分集合だけを実行することによって、簡素化されるかもしれません。
7.11. Implementation Robustness
7.11. 実現丈夫さ
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.
状態が保持されるとき、保有される正確な量は導入問題です。 基本的な要件は推進状態を保有して(データ経路を保持する)、自由民主党ソフトウェアコンポーネントからその状態にアクセスできるということです。
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]では、推進状態がデータでないことのようなどんなデータも、回復ノードによって救われた必要がありません。 すべての自由民主党状態が同輩と共に交換処理で学び直されるかもしれません。 同じ不正確な状態が回復ノードの上にそれらの交換で起こるかもしれないかどうかが、明白な関心です。
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]では、プロトコル拡大に特定の少量の州が推進状態を補わなければなりません。 自由民主党状態は、推進状態から直接保有されるか、または再建されるかもしれません。 同じ問題は、状態を再建するとき、適用しますが、これがありそうなa異なったコード経路であるという事実によって緩和されます。 プロトコル拡大に特定の保有された状態の誤りは持続するでしょう。
7.12. Interoperability and Backward Compatibility
7.12. 相互運用性と後方の互換性
It is important that new additions to LDP interoperate with existing implementations at least in provision of the existing levels of function.
自由民主党への新しい追加が少なくとも既存のレベルの関数の支給における既存の実現で共同利用するのは、重要です。
Farrel Informational [Page 12] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[12ページ]のRFC3612Applicability
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.
参加しているLSRsの唯一のひとりが手順を支持さえするとき、さらに、[RFC3478]は限られた回復(すなわち、状態の再分配)を実行できます。 これは遺産実現と共にinteroperationで相当の便宜を提供するかもしれません。
7.13. Interaction With Other Label Distribution Mechanisms
7.13. 他のラベル分配メカニズムとの相互作用
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.
また、多くの自由民主党LSRsが他のラベル分配メカニズムを動かします。これらは静的なラベルマッピング、自由民主党の他の異なった例、および他のラベル分配プロトコルの構成のための管理インタフェースを含んでいます。 最後の例は自由民主党LSPsが設立されるトンネルを建築するのに使用される交通工学ラベル分配プロトコルを含んでいます。
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.
再開している自由民主党システムの中の自由民主党による個々のラベルの再使用なら、再開している自由民主党のセッションかプロトコルコンポーネントによって保有される必要があるラベルが別のラベル分配メカニズムによって使用されるのを防ぐために注意しなければなりません。 これは他のものの中でデータ機密保護で妥協するかもしれません。
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.
実現がテクニックの使用でこの問題を避けるのは、問題です、一般的なラベル管理の部品や区分されたラベル空間のように。
7.14. Applicability to CR-LDP
7.14. CR-自由民主党への適用性
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-自由民主党[RFC3212]は要求でのDownstreamラベル分配を利用します。 [RFC3478]は、今後の研究のために要求でのDownstreamを領域として記述して、CR-自由民主党には、したがって、適切ではありません。 [RFC3479]はCR-自由民主党に完全に基づくネットワークか自由民主党とCR-自由民主党の間に混ぜられるものにおける使用に適しています。
8. Security Considerations
8. セキュリティ問題
This document is informational and introduces no new security concerns.
このドキュメントは、情報であり、どんな新しい安全上の配慮も導入しません。
The security considerations pertaining to the original LDP protocol [RFC3036] remain relevant.
オリジナルの自由民主党プロトコル[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]が追加否定の可能性を導入する、-、サービス攻撃について。 これらの攻撃のすべてが自由民主党の同輩の間の認証計画の使用で打ち返されるかもしれません、[自由民主党]に概説されたMD5ベースの計画などのように。
Farrel Informational [Page 13] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[13ページ]のRFC3612Applicability
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が、最初にそれらを使用したセッションの満了の後にラベルを使用し続けているなら、データ誤配送安全保障問題は起こることができます。 [RFC3478]と[RFC3479]の両方がこの問題に開かれています。
9. Intellectual Property Statement
9. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.トーマス、「自由民主党仕様」、RFC3036、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、「自由民主党のための優雅な再開メカニズム」、RFC3478、2003年2月。
[RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]ファレル、A.、エディタ、「ラベル分配プロトコル(自由民主党)のための耐障害性」、RFC3479、2003年2月。
Farrel Informational [Page 14] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[14ページ]のRFC3612Applicability
10.2. Informative References
10.2. 有益な参照
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
1999年の[RFC2547]ローゼンとE.とY.Rekhter、「BGP/MPLS VPNs」、RFC2547行進。
[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.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「自由民主党を使用して、規制ベースのLSPはセットアップします」、RFC3212、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、RFC3469、「マルチプロトコルラベルのための枠組みは(MPLS)ベースの回復を切り換えること」での2月2003日
11. Acknowledgements
11. 承認
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]の作者に感謝したがっています。 この適用性証明への彼らの考えられた入力のためにヤコフRekhter、Rahul Aggarwal、Manoj Leelanivas、およびアンドリューMalisをありがとうございます。
12. Author's Address
12. 作者のアドレス
Adrian Farrel Old Dog Consulting
エードリアンのファレルの古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
以下に電話をしてください。 +44 (0) 1978 860944はメールされます: adrian@olddog.co.uk
Farrel Informational [Page 15] RFC 3612 Applicability for LDP Restart Mechanisms September 2003
自由民主党再開メカニズム2003年9月のためのファレル情報[15ページ]のRFC3612Applicability
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Farrel Informational [Page 16]
ファレルInformationalです。[16ページ]
一覧
スポンサーリンク