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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

SMARTY_DIR定数 Smartyのクラスファイルのフルパス

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る