RFC3479 日本語訳
3479 Fault Tolerance for the Label Distribution Protocol (LDP). A.Farrel, Ed.. February 2003. (Format: TXT=115778 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Farrel, Ed. Request for Comments: 3479 Movaz Networks, Inc. Category: Standards Track February 2003
ワーキンググループのA.ファレル、エドをネットワークでつないでください。コメントのために以下を要求してください。 3479MovazはInc.カテゴリをネットワークでつなぎます: 標準化過程2003年2月
Fault Tolerance for the Label Distribution Protocol (LDP)
ラベル分配プロトコルのための耐障害性(自由民主党)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
IESG Note
IESG注意
This specification includes procedures for failure detection and failover for a TCP connection carrying MPLS LDP control traffic, so that it can be switched to a new TCP connection. It does not provide a general approach to using multiple TCP connections to provide this kind of fault tolerance. The specification lacks adequate guidance for the timer and retry value choices related to the TCP connection fault tolerance procedures. The specification should not serve as a model for TCP connection fault tolerance design for any future document, and users are advised to test configurations based on this specification very carefully for problems such as premature failovers.
この仕様はMPLS LDPコントロール交通を運ぶ失敗検出のための手順とTCP接続のためのフェイルオーバーを含んでいます、新しいTCP接続にそれを切り換えることができるように。 それはこの種類の耐障害性を提供するのに複数のTCP接続を使用することへの一般的方法を提供しません。 仕様はTCP接続耐障害性手順に関連するタイマと再試行値の選択のための十分な指導を欠いています。 仕様はどんな将来のドキュメントのためのTCP接続耐障害性デザインのためにも手本になるべきではありません、そして、ユーザが時期尚早なフェイルオーバーなどの問題によって非常に慎重にこの仕様に基づく構成をテストするようにアドバイスされます。
Abstract
要約
Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute 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 Label Switching Routers(LSRs)が、コアネットワークの高い有用性を提供するのにFault Tolerant(FT)ハードウェアかソフトウェアを利用するかもしれません。
The details of how FT is achieved for the various components of an FT LSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDP Specification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations.
FTがLabel Distributionプロトコル(自由民主党)、切り換えハードウェア、およびTCPを含むFT LSRの様々な部品のためにどう達成されるかに関する詳細は実現特有です。 このドキュメントは、RFC3036の自由民主党仕様、現在の自由民主党プロトコルを使用することでFT LSRを実行するのを難しくする「自由民主党仕様」で問題を特定して、そのようなFT LSR実現を緩和するために自由民主党仕様と増進を定義します。
Farrel Standards Track [Page 1] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[1ページ]。
The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP).
「規制ベースのLSPセットアップは自由民主党を使用し」て(CR-自由民主党)、ここで説明された問題と拡大は等しくRFC3212に適切です。
Table of Contents
目次
1. Conventions and Terminology used in this document..........3
2. Contributing Authors.......................................4
3. Introduction...............................................4
3.1. Fault Tolerance for MPLS..............................4
3.2. Issues with LDP.......................................5
4. Overview of LDP FT Enhancements............................7
4.1. Establishing an FT LDP Session........................8
4.1.1 Interoperation with Non-FT LSRs.................8
4.2. TCP Connection Failure................................9
4.2.1 Detecting TCP Connection Failures...............9
4.2.2 LDP Processing after Connection Failure.........9
4.3. Data Forwarding During TCP Connection Failure........10
4.4. FT LDP Session Reconnection..........................10
4.5. Operations on FT Labels..............................11
4.6. Check-Pointing.......................................11
4.6.1 Graceful Termination...........................12
4.7. Label Space Depletion and Replenishment..............13
4.8. Tunneled LSPs........................................13
5. FT Operations.............................................14
5.1. FT LDP Messages......................................14
5.1.1 Sequence Numbered FT Label Messages............14
5.1.2 FT Address Messages............................15
5.1.3 Label Resources Available Notifications........15
5.2. FT Operation ACKs....................................17
5.3. Preservation of FT State.............................17
5.4. FT Procedure After TCP Failure.......................19
5.4.1 FT LDP Operations During TCP Failure...........20
5.5. FT Procedure After TCP Re-connection.................21
5.5.1 Re-Issuing FT Messages.........................22
6. Check-Pointing Procedures.................................22
6.1 Check-Pointing with the Keepalive Message.............23
6.2 Quiesce and Keepalive.................................23
7. Changes to Existing Messages..............................24
7.1. LDP Initialization Message...........................24
7.2. LDP Keepalive Messages...............................25
7.3. All Other LDP Session Messages.......................25
8. New Fields and Values.....................................26
8.1. Status Codes.........................................26
8.2. FT Session TLV.......................................27
8.3. FT Protection TLV....................................29
8.4. FT ACK TLV...........................................32
8.5. FT Cork TLV..........................................33
9. Example Use...............................................34
1. このドキュメントで中古のコンベンションとTerminology…3 2. 作者を寄付します…4 3. 序論…4 3.1. MPLSのための欠点寛容…4 3.2. 自由民主党の問題…5 4. 自由民主党フィートの概観、増進…7 4.1. 自由民主党のセッションをフィート確立します…8 4.1 非フィートLSRsと.1Interoperation…8 4.2. TCP接続の故障…9 4.2 .1 TCP接続の故障を検出します…9 4.2 .2 接続失敗の後の自由民主党の処理…9 4.3. TCP接続の故障の間のデータ推進…10 4.4. フィート、自由民主党のセッション再接続…10 4.5. フィートにおける操作、ラベル…11 4.6. チェックを指します…11 4.6 .1 優雅な終了…12 4.7. 減少と補給とスペースをラベルしてください…13 4.8. LSPsにトンネルを堀ります…13 5. フィート、操作…14 5.1. フィート自由民主党は通信します…14 5.1 番号付の.1系列フィートはメッセージをラベルします…14 5.1 .2フィートのアドレスメッセージ…15 5.1 .3 利用可能な通知とリソースをラベルしてください…15 5.2. フィート操作ACKs…17 5.3. フィート州の保存…17 5.4. フィート、TCPの故障の後の手順…19 5.4 TCPの故障の間の.1フィートの自由民主党の操作…20 5.5. フィート、TCP再接続の後の手順…21 5.5 .1 フィートを再発行するのは通信します…22 6. チェック指す手順…22 6.1Keepaliveとのチェック指すメッセージ…23 6.2のQuiesceとKeepalive…23 7. 既存のメッセージへの変化…24 7.1. 自由民主党初期設定メッセージ…24 7.2. 自由民主党Keepaliveメッセージ…25 7.3. 他のすべての自由民主党セッションメッセージ…25 8. 新しい分野と値…26 8.1. 状態コード…26 8.2. フィートセッションTLV…27 8.3. フィート保護TLV…29 8.4. フィートACK TLV…32 8.5. フィートコルクTLV…33 9. 例の使用…34
Farrel Standards Track [Page 2] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[2ページ]。
9.1. Session Failure and Recovery - FT Procedures.........34
9.2. Use of Check-Pointing With FT Procedures.............37
9.3. Temporary Shutdown With FT Procedures................38
9.4. Temporary Shutdown With FT Procedures
and Check-Pointing...................................40
9.5. Check-Pointing Without FT Procedures.................42
9.6. Graceful Shutdown With Check-Pointing
But No FT Procedures.................................44
10. Security Considerations..................................45
11. Implementation Notes.....................................47
11.1. FT Recovery Support on Non-FT LSRs..................47
11.2. ACK generation logic................................47
11.2.1 Ack Generation Logic When Using
Check-Pointing...............................47
11.3 Interactions With Other Label Distribution
Mechanisms...........................................48
12. Acknowledgments..........................................48
13. Intellectual Property Consideration......................49
14. References...............................................49
14.1. Normative References................................49
14.2. Informative References..............................50
15. Authors' Addresses.......................................50
16. Full Copyright Statement.................................52
9.1. セッション失敗と回復--、フィート、手順…34 9.2. フィートとのチェック指す手順の使用…37 9.3. フィートとの一時的な閉鎖、手順…38 9.4. フィートとの一時的な閉鎖、手順とチェック指すこと…40 9.5. フィートのないチェック指す手順…42 9.6. チェック指すのにもかかわらずの、いいえフィート手順との優雅な閉鎖…44 10. セキュリティ問題…45 11. 実現注意…47 11.1. 回復が非フィートLSRsで支持するフィート…47 11.2. ACK世代論理…47 11.2.1 Ack世代論理、チェック指すことを使用するとき…他のラベル分配メカニズムとの47 11.3回の相互作用…48 12. 承認…48 13. 知的所有権の考慮…49 14. 参照…49 14.1. 標準の参照…49 14.2. 有益な参照…50 15. 作者のアドレス…50 16. 完全な著作権宣言文…52
1. Conventions and Terminology used in this document
1. 本書では使用されるコンベンションとTerminology
Definitions of key words and terms applicable to LDP and CR-LDP are inherited from [RFC3212] and [RFC3036].
自由民主党とCR-自由民主党に適切なキーワードと用語の定義は[RFC3212]と[RFC3036]から引き継がれます。
The term "FT Label" is introduced in this document to indicate a label for which some fault tolerant operation is used. A "non-FT Label" is not fault tolerant and is handled as specified in [RFC3036].
「フィートはラベルする」用語が、何らかのフォルト・トレラントの操作が使用されているラベルを示すために本書では紹介されます。 「非フィートラベル」は、フォルト・トレラントでなく、[RFC3036]で指定されるように扱われます。
The term "Sequence Numbered FT Label" is used to indicate an FT label which is secured using the sequence number in the FT Protection TLV described in this document.
「番号付のフィートがラベルする系列」という用語は、本書では説明されたFT Protection TLVで一連番号を使用することで固定されているFTラベルを示すのに使用されます。
The term "Check-Pointable FT Label" is used to indicate an FT label which is secured by using the check-pointing techniques described in this document.
「チェック-Pointableフィートはラベルする」用語が、本書では説明されたチェックを指すテクニックを使用することによって固定されているFTラベルを示すのに使用されます。
The extensions to LDP specified in this document are collectively referred to as the "LDP FT enhancements".
本書では指定された自由民主党への拡大は「LDP FT増進」とまとめて呼ばれます。
Within the context of this document, "Check-Pointing" refers to a process of message exchanges that confirm receipt and processing (or secure storage) of specific protocol messages.
このドキュメントの文脈の中では、「チェック指すこと」は領収書を確認する交換処理の過程と特定のプロトコルメッセージの処理(または、安全な格納)を示します。
Farrel Standards Track [Page 3] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[3ページ]。
When talking about the individual bits in the 16-bit FT Flag Field, the words "bit" and "flag" are used interchangeably.
FT Flag Field、16ビットの「ビット」という個々のビットに関する言葉を話して、「旗」が互換性を持って使用されるとき。
In the examples quoted, the following notation is used: Ln : An LSP. For example L1. Pn : An LDP peer. For example P1.
引用された例では、以下の記法は使用されています: Ln: LSP。 例えば、L1。 Pn: 自由民主党の同輩。 例えば、P1。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
2. Contributing Authors
2. 作者を寄付します。
This document was the collective work of several individuals over a period of several years. The text and content of this document was contributed by the editor and the co-authors listed in section 15, "Authors' Addresses".
このドキュメントは数年の期間にわたる何人かの個人の集合著作物でした。 このドキュメントのテキストと中身はエディタによって寄付されました、そして、「作者のアドレス」と、共著者はセクション15で記載しました。
3. Introduction
3. 序論
High Availability (HA) is typically claimed by equipment vendors when their hardware achieves availability levels of at least 99.999% (five 9s). To implement this, the equipment must be capable of recovering from local hardware and software failures through a process known as fault tolerance (FT).
彼らのハードウェアが少なくとも99.999%(5 9)の有用性レベルを実現するとき、高いAvailability(HA)は設備業者によって通常要求されます。 これを実行するために、設備はローカルのハードウェアとソフトウェア障害から耐障害性(FT)として知られている過程で回復できなければなりません。
The usual approach to FT involves provisioning backup copies of hardware and/or software. When a primary copy fails, processing is switched to the backup copy. This process, called failover, should result in minimal disruption to the Data Plane.
FTへの普通のアプローチは、ハードウェア、そして/または、ソフトウェアのバックアップコピーに食糧を供給することを伴います。 第一のコピーが失敗すると、処理はバックアップコピーに切り換えられます。 フェイルオーバーと呼ばれるこの過程はData Planeの最小量の分裂をもたらすべきです。
In an FT system, backup resources are sometimes provisioned on a one-to-one basis (1:1), sometimes as one-to-many (1:n), and occasionally as many-to-many (m:n). Whatever backup provisioning is made, the system must switch to the backup automatically on failure of the primary, and the software and hardware state in the backup must be set to replicate the state in the primary at the point of failure.
FTシステムで、バックアップリソースは時々多くへの1(1:n)として1〜1個のベース(1:1)と、時折多くへの多く(m: n)として時々食糧を供給されます。 食糧を供給することが作られているいかなるバックアップ、システムは自動的に予備選挙の失敗をバックアップに切り換えなければなりません、そして、失敗のポイントで予備選挙で状態を模写するようにバックアップのソフトウェアとハードウェア状態を設定しなければなりません。
3.1. Fault Tolerance for MPLS
3.1. MPLSのための耐障害性
MPLS is a technology that will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit FT hardware or software to provide high availability of core networks.
MPLSはシステム休止時間を絶対最小値まで保たなければならないコアネットワークに使用される技術です。 したがって、多くのMPLS LSRsが、コアネットワークの高い有用性を提供するのにFTハードウェアかソフトウェアを利用するかもしれません。
Farrel Standards Track [Page 4] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[4ページ]。
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:
HAを提供するために、MPLSシステムは、Data Planeの最小量の分裂におけるさまざまな欠点を乗り切ることができる必要があります、以下の欠点タイプを含んでいて:
- failure/hot-swap of a physical connection between LSRs.
- LSRsの間の物理接続の失敗/ホットスワップ。
- failure/hot-swap of the switching fabric in an LSR.
- LSRの切り換え織物の失敗/ホットスワップ。
- 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 are 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. The last two example types of fault require action in the Control Plane to recover from the fault without disrupting traffic in the Data Plane. This is possible because many recent router architectures separate the Control and Data Planes such that forwarding can continue unaffected by recovery action in the Control Plane.
上に記載された欠点に関する最初の2つの例がData Planeに限定されます。 Control Planeで作動しながら、自由民主党に透明なData Planeで冗長を提供することによって、そのような欠点を扱うことができます。 欠点の最後の2つの例のタイプが、欠点からData Planeの交通を中断しないで回復するためにControl Planeで動作を必要とします。 多くの最近のルータ建築が推進がControl Planeで回復動作で影響を受けない状態で続くことができるようにControlとDataプラネスを切り離すので、これは可能です。
3.2. Issues with LDP
3.2. 自由民主党の問題
LDP uses TCP to provide reliable connections between LSRs over which they exchange protocol messages to distribute labels and 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 (for example, 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 hard 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, 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 Standards Track [Page 5] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[5ページ]。
This document describes a solution which involves:
このドキュメントは以下にかかわる解決策を説明します。
- 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.
- LSP/ラベル基礎あたりのaにおけるFT生存の選択。
- 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 check-pointing.
- 完全な握手が頻繁(メッセージに従ってそのようなもの)かそれほど頻繁でなくチェック指さないようにそれらのメッセージに実行されるのを保証する自由民主党メッセージの承認。
- solicitation of up-to-date acknowledgement (check-pointing) of
previous LDP messages to ensure the current state is flushed to
disk/NVRAM, with an additional option that allows an LDP partner
to request that state is flushed in both directions if graceful
shutdown is required.
- 現状を確実にする前の自由民主党メッセージの最新の承認(チェックを指す)の懇願はディスク/NVRAMに洗い流されます、自由民主党のパートナーが、優雅な閉鎖が必要であるなら状態が両方の方向に洗い流されるよう要求できる追加オプションで。
- re-issuing lost messages after failover to ensure that LSP/label
state is correctly recovered after reconnection of the LDP
session.
- 確実にするLSP/ラベルが述べるフェイルオーバーが自由民主党のセッションの再接続の後に正しく回復された後に再発行はメッセージを失いました。
The issues and objectives described above are equally applicable to CR-LDP.
上で説明された問題と目的は等しくCR-自由民主党に適切です。
Other objectives of this document are to:
このドキュメントの他の目的は以下のことのためのことです。
- offer backward-compatibility with LSRs that do not implement these
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]で説明された既存のプロトコル規則を保存してください。
- avoid full state refresh solutions (such as those present in RSVP:
see [RFC2205], [RFC2961], [RFC3209] and [RFC3478]) whether they be
continual, or limited to post-failover recovery.
- それらが絶え間ないか否かに関係なく、解決策(RSVPに出席しているそれらなどのように: [RFC2205]、[RFC2961]、[RFC3209]、および[RFC3478]を見る)をリフレッシュするか、またはポストフェイルオーバー回復に制限されて、完全な状態を避けてください。
Note that this document concentrates on the preservation of label state for labels exchanged between a pair of adjacent LSRs when the TCP connection between those LSRs is lost. This is a requirement for Fault Tolerant operation of LSPs, but a full implementation of end- to-end protection for LSPs requires that this be combined with other techniques that are outside the scope of this document.
このドキュメントがそれらのLSRsの間のTCP接続が迷子になっているとき1組の隣接しているLSRsの間で交換されたラベルのためにラベル状態の保存に集中することに注意してください。 これはLSPsのFault Tolerant操作のための要件ですが、LSPsのための終わりまでの終わりの保護の完全な実施は、これがこのドキュメントの範囲の外にある他のテクニックに結合されるのを必要とします。
In particular, this document does not attempt to describe how to modify the routing of an LSP or the resources allocated to a label or LSP, which is covered by [RFC3214]. This document also does not
特に、このドキュメントは、ラベルに割り当てられたLSPかリソースのルーティングかLSPを変更する方法を説明するのを試みません。LSPは[RFC3214]で覆われています。 このドキュメントもそうしません。
Farrel Standards Track [Page 6] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[6ページ]。
address how to provide automatic layer 2 or layer 3 protection switching for a label or LSP, which is a separate area for study.
どう分離した部分であるラベルかLSPのために切り替わる自動層2か層3の保護を提供するかを研究に記述してください。
This specification does not preclude an implementation from attempting (or require it to attempt) to use the FT behavior described here to recover from a preemptive failure of a connection on a non-FT system due to, for example, a partial system crash. Note, however, that there are potential issues too numerous to list here - not least the likelihood that the same crash will immediately occur when processing the restored data.
例えば、部分的なシステムクラッシュのため非FTシステムの上で接続の先買いの失敗から回復するのにここで説明されたFTの振舞いを使用するのを試みるので(試みにそれを必要としてください)、この仕様は実現を排除しません。 しかしながら、ここに記載できないくらいの多数の潜在的問題があることに注意してください--すぐに回復しているデータを処理するとき、同じクラッシュが起こるという特に見込み。
4. Overview of LDP FT Enhancements
4. 自由民主党フィートの概観、増進
The LDP FT enhancements consist of the following main elements, which are described in more detail in the sections that follow.
LDP FT増進は以下の主な要素から成ります。(要素はさらに詳細に従うセクションで説明されます)。
- The presence of an FT Session TLV on the LDP Initialization
message indicates that an LSR supports some form of protection or
recovery from session failure. A flag bit within this TLV (the S
bit) indicates that the LSR supports the LDP FT enhancements on
this session. Another flag (the C bit) indicates that the check-
pointing procedures are to be used.
- 自由民主党初期設定メッセージのFT Session TLVの存在は、LSRがセッション失敗からの何らかのフォームの保護か回復を支持するのを示します。 このTLV(Sビット)の中のフラグビットは、LSRがこのセッションのときにLDP FT増進を支持するのを示します。 別の旗(Cビット)は、チェック指す手順が使用されていることであることを示します。
- An FT Reconnect Flag in the FT Session TLV (the R bit) indicates
whether an LSR has preserved FT Label state across a failure of
the TCP connection.
- FT Session TLV(Rビット)のFT Reconnect Flagは、LSRがTCP接続の失敗の向こう側にFT Label状態を保持したかどうかを示します。
- An FT Reconnection Timeout, exchanged on the LDP Initialization
message, that indicates the maximum time peer LSRs will preserve
FT Label state after a failure of the TCP connection.
- 最大の時間同輩LSRsを示す自由民主党初期設定メッセージで交換されたFT Reconnection TimeoutはTCP接続の失敗の後にFT Label状態を保持するでしょう。
- An FT Protection TLV used to identify operations that affect LDP
labels. All LDP messages carrying the FT Protection TLV need to
be secured (e.g. to NVRAM) and ACKed to the sending LDP peer so
that the state for Sequence Numbered FT Labels can be correctly
recovered after LDP session reconnection.
- FT Protection TLVは以前はよく自由民主党ラベルに影響する操作を特定していました。 FT Protection TLVを運ぶすべての自由民主党メッセージが、安全にされる(例えば、NVRAMに)必要があります、そして、送付自由民主党へのACKedは自由民主党のセッション再接続の後に正しくSequence Numbered FT Labelsのための状態を回復できるようにじっと見ます。
Note that the implementation within an FT system is left open by
this document. An implementation could choose to secure entire
messages relating to Sequence Numbered FT Labels, or it could
secure only the relevant state information.
FTシステムの中の実現がこのドキュメントによって開くままにされることに注意してください。 実現が、Sequence Numbered FT Labelsに関連する全体のメッセージを保証するのを選ぶかもしれませんか、またはそれは関連州の情報だけを保証するかもしれません。
- Address advertisement may also be secured by use of the FT
Protection TLV. This enables recovery after LDP session
reconnection without the need to re-advertise what may be a very
large number of addresses.
- また、FT Protection TLVの使用でアドレス広告を保証するかもしれません。 これは自由民主党のセッション再接続の後に非常に多くのアドレスであるかもしれないことの再広告を出す必要性なしで回復を可能にします。
Farrel Standards Track [Page 7] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[7ページ]。
- The FT Protection TLV may also be used on the Keepalive message to
flush acknowledgement of all previous FT operations. This enables
a check-point for future recovery, either in mid-session or prior
to graceful shutdown of an LDP session. This procedure may also
be used to check-point all (that is both FT and non-FT) operations
for future recovery.
- また、FT Protection TLVは前のすべてのFT操作の承認を洗い流すKeepaliveメッセージで使用されるかもしれません。 これは中間のセッションか今後の回復か、自由民主党のセッションの優雅な閉鎖の前に検査点を可能にします。 この手順はそうするかもしれません、また、検査点に使用されてください。未来の回復のためのすべての(それはFTと非FTの両方です)操作。
4.1. Establishing an FT LDP Session
4.1. 自由民主党のセッションをフィート確立します。
In order that the extensions to LDP [RFC3036] described in this document can be used successfully on an LDP session between a pair of LDP peers, they MUST negotiate that the LDP FT enhancements are to be used on the LDP session.
彼らは、1組の自由民主党の同輩の間の自由民主党のセッションのときに首尾よく本書では説明された自由民主党[RFC3036]への拡張子を使用できるように交渉しなければなりません。LDP FT増進は自由民主党のセッションのときに使用されることです。
This is done on the LDP Initialization message exchange using a new FT Session TLV. Presence of this TLV indicates that the peer wants to support some form of protection or recovery processing. The S bit within this TLV indicates that the peer wants to support the LDP FT enhancements on this LDP session. The C bit indicates that the peer wants to support the check-pointing functions described in this document. The S and C bits may be set independently.
自由民主党初期設定交換処理で新しいFT Session TLVを使用することでこれをします。 このTLVの存在は、同輩が何らかの形式の保護かリカバリ処理を支持したがっているのを示します。 このTLVの中のSビットは、同輩がこの自由民主党のセッションのときにLDP FT増進を支持したがっているのを示します。 Cビットは、同輩が本書では説明されたチェックを指す機能をサポートしたがっているのを示します。 SとCビットは独自に設定されるかもしれません。
The relevant LDP FT enhancements MUST be supported on an LDP session if both LDP peers include an FT Session TLV on the LDP Initialization message and have the same setting of the S or C bit.
両方の自由民主党の同輩が自由民主党初期設定メッセージのFT Session TLVを入れて、SかCビットの同じ設定を持っているなら、自由民主党のセッションのときに関連LDP FT増進を支持しなければなりません。
If either LDP Peer does not include the FT Session TLV LDP Initialization message, or if there is no match of S and C bits between the peers, the LDP FT enhancements MUST NOT be used during this LDP session. Use of LDP FT enhancements by a sending LDP peer in these cases MUST be interpreted by the receiving LDP peer as a serious protocol error causing the session to be terminated.
自由民主党PeerがFT Session TLV自由民主党初期設定メッセージを含んでいないか、または同輩の間には、SとCビットのマッチが全くなければ、この自由民主党のセッションの間、LDP FT増進を使用してはいけません。 受信自由民主党の同輩はセッションを終える重大なプロトコル誤りとしてこれらの場合における送付自由民主党の同輩によるLDP FT増進の使用を解釈しなければなりません。
An LSR MAY present different FT/non-FT behavior on different TCP connections, even if those connections are successive instantiations of the LDP session between the same LDP peers.
異なったTCP接続のLSR MAYの現在の異なった非FT/FTの振舞いそれらの接続が同じ自由民主党の同輩の間の自由民主党のセッションの連続した具体化であっても。
4.1.1 Interoperation with Non-FT LSRs
4.1.1 非フィートLSRsとInteroperation
The FT Session TLV on the LDP Initialization message carries the U- bit. If an LSR does not support any protection or recovery mechanisms, it will ignore this TLV. Since such partners also do not include the FT Session TLV, all LDP sessions to such LSRs will not use the LDP FT enhancements.
自由民主党初期設定メッセージのFT Session TLVはUビットを運びます。 LSRが少しの保護や回収機構もサポートしないと、それはこのTLVを無視するでしょう。 そのようなパートナーもFT Session TLVを入れないので、そのようなLSRsへのすべての自由民主党のセッションはLDP FT増進を使用しないでしょう。
The rest of this document assumes that the LDP sessions under discussion are between LSRs that support the LDP FT enhancements, except where explicitly stated otherwise.
このドキュメントの残りは、LDP FT増進を支持するLSRsの間には、議論している自由民主党のセッションがあると仮定します、別の方法で明らかに述べられているところを除いて。
Farrel Standards Track [Page 8] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[8ページ]。
4.2. TCP Connection Failure
4.2. TCP接続の故障
4.2.1 Detecting TCP Connection Failures
4.2.1 TCP接続の故障を検出すること。
TCP connection failures may be detected and reported to the LDP component in a variety of ways. These should all be treated in the same way by the LDP component.
TCP接続の故障は、さまざまな方法で自由民主党コンポーネントに検出されて、報告されるかもしれません。 同様に、これらは自由民主党コンポーネントによってすべて扱われるべきです。
- Indication from the management component that a TCP connection or
underlying resource is no longer active.
- 管理コンポーネントからのTCP接続か基本的なリソースがもう活発でないという指示。
- Notification from a hardware management component of an interface
failure.
- インタフェース失敗のハードウェア管理の部品からの通知。
- Sockets keepalive timeout.
- ソケットkeepaliveタイムアウト。
- Sockets send failure.
- ソケットは失敗を送ります。
- New (incoming) Socket opened.
- 新しい(入って来る)ソケットは開きました。
- LDP protocol timeout.
- 自由民主党プロトコルタイムアウト。
4.2.2 LDP Processing after Connection Failure
4.2.2 接続失敗の後の自由民主党の処理
If the LDP FT enhancements are not in use on an LDP session, the action of the LDP peers on failure of the TCP connection is as specified in [RFC3036].
LDP FT増進が自由民主党のセッションのときに使用中でないなら、TCP接続の失敗への自由民主党の同輩の動作が[RFC3036]で指定されるようにあります。
All state information and resources associated with non-FT Labels MUST be released on the failure of the TCP connection, including deprogramming the non-FT Label from the switching hardware. This is equivalent to the behavior specified in [RFC3036].
TCP接続の失敗ですべての州の情報と非FT Labelsに関連しているリソースを発表しなければなりません、切り換えハードウェアからの非FT Labelをデプログラムするのを含んでいて。 これは[RFC3036]で指定された振舞いに同等です。
If the LDP FT enhancements are in use on an LDP session, both LDP peers SHOULD preserve state information and resources associated with FT Labels exchanged on the LDP session. Both LDP peers SHOULD use a timer to release the preserved state information and resources associated with FT-labels if the TCP connection is not restored within a reasonable period. The behavior when this timer expires is equivalent to the LDP session failure behavior described in [RFC3036].
LDP FT増進が自由民主党のセッションのときに使用中であるなら、SHOULDが保存する両方の自由民主党の同輩は自由民主党のセッションのときに交換するFT Labelsに関連している情報とリソースを述べます。 ともに、TCP接続が相当期間以内に復元されないなら、自由民主党同輩SHOULDは、保存された州の情報とFT-ラベルに関連しているリソースを発表するのにタイマを使用します。 このタイマが期限が切れるとき、振舞いは[RFC3036]で説明された自由民主党のセッション失敗の振舞いに同等です。
The FT Reconnection Timeout each LDP peer intends to apply to the LDP session is carried in the FT Session TLV on the LDP Initialization messages. Both LDP peers MUST use the value that corresponds to the lesser timeout interval of the two proposed timeout values from the LDP Initialization exchange, where a value of zero is treated as positive infinity.
それぞれの自由民主党の同輩が自由民主党のセッションに適用するつもりであるFT Reconnection Timeoutは自由民主党初期設定メッセージでFT Session TLVで運ばれます。 両方の自由民主党の同輩は自由民主党の初期設定交換からのゼロの値が陽の無限として扱われる2つの提案されたタイムアウト値の、より少ないタイムアウト間隔に対応する値を使用しなければなりません。
Farrel Standards Track [Page 9] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[9ページ]。
4.3. Data Forwarding During TCP Connection Failure
4.3. TCP接続の間に失敗を進めるデータ
An LSR that implements the LDP FT enhancements SHOULD preserve the programming of the switching hardware across a failover. This ensures that data forwarding is unaffected by the state of the TCP connection between LSRs.
LDP FT増進SHOULDを実行するLSRはフェイルオーバーの向こう側に切り換えハードウェアのプログラミングを保存します。これはデータ推進が確実にLSRsの間のTCP接続の状態のそばで影響を受けなくなるようにします。
It is an integral part of FT failover processing in some hardware configurations that some data packets might be lost. If data loss is not acceptable to the applications using the MPLS network, the LDP FT enhancements described in this document SHOULD NOT be used.
いくつかのデータ・パケットがいくつかのハードウェア・コンフィギュレーションにおいてフェイルオーバー処理であるかもしれませんが、それはFTの不可欠の部分です。失われています。 データの損失が許容できないなら、MPLSネットワークを使用するアプリケーション、増進がこのドキュメントSHOULD NOTで説明したLDP FTに、使用されてください。
4.4. FT LDP Session Reconnection
4.4. フィート、自由民主党のセッション再接続
When a new TCP connection is established, the LDP peers MUST exchange LDP Initialization messages. When a new TCP connection is established after failure, the LDP peers MUST re-exchange LDP Initialization messages.
新しいTCP接続が確立されるとき、自由民主党の同輩は自由民主党初期設定メッセージを交換しなければなりません。 新しいTCP接続が失敗の後に確立されるとき、自由民主党の同輩は自由民主党初期設定メッセージを再交換しなければなりません。
If an LDP peer includes the FT Session TLV with the S bit set in the LDP Initialization message for the new instantiation of the LDP session, it MUST also set the FT Reconnect Flag according to whether it has been able to preserve label state. The FT Reconnect Flag is carried in the FT Session TLV.
また、自由民主党の同輩が自由民主党のセッションの新しい具体化への自由民主党初期設定メッセージに設定されたSビットがあるFT Session TLVを入れるなら、それは、それができているかどうかに従ったFT Reconnect Flagにラベル状態を保持するように設定しなければなりません。 FT Reconnect FlagはFT Session TLVで運ばれます。
If an LDP peer has preserved all state information for previous instantiations of the LDP session, then it SHOULD set the FT Reconnect Flag to 1 in the FT Session TLV. Otherwise, it MUST set the FT Reconnect Flag to 0.
保存されて、自由民主党の同輩がそうしたなら、すべてが自由民主党のセッションの前の具体化のための情報を述べて、次に、それはSHOULDです。FT Session TLVの1にFT Reconnect Flagを設定してください。 さもなければ、それは0にFT Reconnect Flagを設定しなければなりません。
If either LDP peer sets the FT Reconnect Flag to 0, or omits the FT Session TLV, both LDP peers MUST release any state information and resources associated with the previous instantiation of the LDP session between the same LDP peers, including FT Label state and Addresses. This ensures that network resources are not permanently lost by one LSR if its LDP peer is forced to undergo a cold start.
どちらの自由民主党の同輩も0にFT Reconnect Flagを設定するか、またはFT Session TLVを省略するなら、両方の自由民主党の同輩は同じ自由民主党の同輩の間の自由民主党のセッションの前の具体化に関連しているどんな州の情報とリソースも発表しなければなりません、FT Label状態とAddressesを含んでいて。 これは、自由民主党の同輩がやむを得ずコールドスタートを受けるならネットワーク資源が永久に1LSRによってなくされていないのを確実にします。
If an LDP peer changes any session parameters (for example, the label space bounds) from the previous instantiation, the nature of any preserved labels may have changed. In particular, previously allocated labels may now be out of range. For this reason, session reconnection MUST use the same parameters as were in use on the session before the failure. If an LDP peer notices that the parameters have been changed by the other peer, it SHOULD send a Notification message with the 'FT Session parameters changed' status code.
自由民主党の同輩がどんなセッションのときにも前の具体化からパラメタ(例えば、ラベルスペースはバウンドしている)を変えるなら、どんな保存されたラベルの自然も変化したかもしれません。 特にと、以前割り当てられたラベルは現在、範囲から脱しているかもしれません。 この理由のために、セッション再接続は失敗の前のセッションのときに使用中であったように同じパラメタを使用しなければなりません。 自由民主党の同輩通知であるなら、パラメタがもう片方の同輩によって変えられて、それがSHOULDであることは'パラメタが変えたFT Session'ステータスコードがあるNotificationメッセージを送ります。
Farrel Standards Track [Page 10] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[10ページ]。
If both LDP peers set the FT Reconnect Flag to 1, both LDP peers MUST use the procedures indicated in this document to complete any label operations on Sequence Numbered FT Labels that were interrupted by the LDP session failure.
両方の自由民主党の同輩が1にFT Reconnect Flagを設定するなら、両方の自由民主党の同輩は自由民主党のセッション失敗によって中断されたSequence Numbered FT Labelsにおけるどんなラベル操作も完了するために本書では示された手順を用いなければなりません。
If an LDP peer receives an LDP Initialization message with the FT Reconnect Flag set before it sends its own Initialization message, but has retained no information about the previous version of the session, it MUST respond with an Initialization message with the FT Reconnect Flag clear. If an LDP peer receives an LDP Initialization message with the FT Reconnect Flag set in response to an Initialization message that it has sent with the FT Reconnect Flag clear, it MUST act as if no state was retained by either peer on the session.
自由民主党の同輩がそれ自身の初期設定メッセージを送る前にFT Reconnect Flagセットで自由民主党初期設定メッセージを受け取りますが、セッションの旧バージョンに関して情報を全く保有していないなら、FT Reconnect Flagが明確な状態でそれは初期設定メッセージで応じなければなりません。 自由民主党の同輩がFT Reconnect FlagセットでFT Reconnect Flagが明確な状態で発信したという初期設定メッセージに対応して自由民主党初期設定メッセージを受け取るなら、まるで状態が全くセッションのときにどちらの同輩によっても保有されないかのようにそれは行動しなければなりません。
4.5. Operations on FT Labels
4.5. フィートにおける操作はラベルします。
Label operations on Sequence Numbered FT Labels are made Fault Tolerant by providing acknowledgement of all LDP messages that affect Sequence Numbered FT Labels. Acknowledgements are achieved by means of sequence numbers on these LDP messages.
Sequence Numbered FT Labelsに影響するすべての自由民主党メッセージの承認を提供することによって、Sequence Numbered FT Labelsにおけるラベル操作は人工のFault Tolerantです。 承認はこれらの自由民主党メッセージの一連番号によって達成されます。
The message exchanges used to achieve acknowledgement of label operations and the procedures used to complete interrupted label operations are detailed in section 5, "FT Operations".
交換処理が以前はよくラベル操作の承認を実現していて、中断しているラベル操作を完了するのに用いられた手順がセクション5で詳細である、「フィート、操作、」
Using these acknowledgements and procedures, it is not necessary for LDP peers to perform a complete re-synchronization of state for all Sequence Numbered FT Labels, either on re-connection of the LDP session between the LDP peers or on a timed basis.
これらの承認と手順を用いて、自由民主党の同輩が自由民主党の同輩の間の自由民主党のセッションの再接続の上、または、すべてのSequence Numbered FT Labelsか、調節ベースにおける状態の完全な再同期を実行するのは必要ではありません。
4.6. Check-Pointing
4.6. チェック指すこと
Check-pointing is a useful feature that allows nodes to reduce the amount of processing that they need to do to acknowledge LDP messages. The C bit in the FT Session TLV is used to indicate that check-pointing is supported.
チェック指すのはノードが彼らが自由民主党メッセージを承認するためにする必要がある処理の量を減少させることができる役に立つ特徴です。 FT Session TLVのCビットは、チェック指すことが支持されるのを示すのに使用されます。
Under the normal operation on Sequence Numbered FT Labels, acknowledgments may be deferred during normal processing and only sent periodically. Check-pointing may be used to flush acknowledgement from a peer by including a sequence number on a Keepalive message requesting acknowledgement of that message and all previous messages. In this case, all Sequence Numbered FT Labels are Check-Pointable FT Labels.
Sequence Numbered FT Labelsにおける通常操作で、承認を正常処理の間、延期して、定期的に送るだけであるかもしれません。 チェック指すことは、同輩からそのメッセージと前のすべてのメッセージの承認を要求しながらKeepaliveメッセージに一連番号を含んでいることによって承認を洗い流すのに使用されるかもしれません。 この場合、すべてのSequence Numbered FT LabelsがCheck-Pointable FT Labelsです。
Farrel Standards Track [Page 11] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[11ページ]。
If the S bit is not agreed upon, check-pointing may still be used. In this case it is used to acknowledge all messages exchanged between the peers, and all labels are Check-Pointable FT Labels.
Sビットが同意されないなら、チェック指すことはまだ使用されているかもしれません。 この場合、それは同輩の間で交換されたすべてのメッセージを承認するのに使用されます、そして、すべてのラベルがCheck-Pointable FT Labelsです。
This offers an approach where acknowledgements need not be sent to every message or even frequently, but are only sent as check-points in response to requests carried on Keepalive messages. Such an approach may be considered optimal in systems that do not show a high degree of change over time (such as targeted LDP sessions) and that are prepared to risk loss of state for the most recent LDP exchanges. More dynamic systems (such as LDP discovery sessions) are more likely to want to acknowledge state changes more frequently so that the maximum amount of state can be preserved over a failure.
要求に対応した検査点がKeepaliveメッセージで運ばれたので、これは承認が頻繁にあらゆるメッセージに送るか、または同等である必要はありませんが、送られるだけであるところにアプローチを提供します。 損失の危険を冒すアプローチが時間がたつにつれての高度の変化(狙っている自由民主党のセッションなどの)を見せていない、準備されたシステムで最適の状態で考えられるかもしれないそのようなものは最新の自由民主党のために交換を述べます。 よりダイナミックなシステム(自由民主党の発見セッションなどの)が、より頻繁に州の変化をより承認したそうであるので、失敗の上に最大の量の状態を保持できます。
Note that an important consideration of this document is that nodes acknowledging messages on a one-for-one basis, nodes deferring acknowledgements, and nodes relying on check-pointing, should all interoperate seamlessly and without protocol negotiation beyond session initialization.
このドキュメントの重要な考慮すべき事柄が個人的には1個のベースに関するメッセージを承認するノード(承認を延期するノード、およびチェック指すことを当てにするノード)がすべて、セッション初期化を超えて継ぎ目なくと議定書交渉なしで共同利用するはずであるということであることに注意してください。
Further discussion of this feature is provided in section 5, "FT Operations".
この特徴のさらなる議論をセクション5に提供する、「フィート、操作、」
4.6.1 Graceful Termination
4.6.1 優雅な終了
A feature that builds on check-pointing is graceful termination.
それがチェック指すときに築き上げる特徴は優雅な終了です。
In some cases, such as controlled failover or software upgrade, it is possible for a node to know in advance that it is going to terminate its session with a peer.
制御フェイルオーバーかソフトウェアの更新などのいくつかの場合では、ノードに、あらかじめ同輩とのセッションを終えるのを知るのは可能です。
In these cases the node that intends terminating the session can flush acknowledgement using a check-point request as described above. The sender SHOULD not send further label or address-related messages after requesting shutdown check-pointing in order to preserve the integrity of its saved state.
これらの場合では、セッションを終えることを意図するノードは、上で説明されるように検査点要求を使用することで承認を洗い流すことができます。 救われた状態の保全を保持するために閉鎖チェック指すことを要求した後に、送付者SHOULDは一層のラベルかアドレス関連のメッセージを送りません。
This, however, only provides for acknowledgement in one direction, and the node that is being terminated also requires verification that it has secured all state sent by its peer. This is achieved by a three-way hand shake of the check-point which is requested by an additional TLV (the Cork TLV) in the Keepalive message.
しかしながら、これは、一方向、およびまた、終えられるのが検証を必要とするということであるノードで同輩によって送られたすべての状態を保証したのを承認に前提とするだけです。 これはKeepaliveメッセージで追加TLV(Cork TLV)によって要求されている検査点の3者間の手の震動によって達成されます。
Further discussion of this feature is provided in section 5, "FT Operations".
この特徴のさらなる議論をセクション5に提供する、「フィート、操作、」
Farrel Standards Track [Page 12] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[12ページ]。
4.7. Label Space Depletion and Replenishment
4.7. ラベル宇宙減少と補給
When an LDP peer is unable to satisfy a Label Request message because it has no more available labels, it sends a Notification message carrying the status code 'No label resources'. This warns the requesting LDP peer that subsequent Label Request messages are also likely to fail for the same reason. This message does not need to be acknowledged for FT purposes since Label Request messages sent after session recovery will receive the same response. However, the LDP peer that receives a 'No label resources' Notification stops sending Label Request messages until it receives a 'Label resources available' Notification message. Since this unsolicited Notification might get lost during session failure, it may be protected using the procedures described in this document.
それ以上の利用可能なラベルを持っていないので自由民主党の同輩がLabel Requestメッセージを満たすことができないとき、それで、Notificationメッセージはステータスコード'ラベルなしリソース'を運びます。 これは、また、その後のLabel Requestメッセージも同じ理由から失敗しそうであると要求している自由民主党の同輩に警告します。 セッション回復が同じ応答を受けた後にLabel Requestメッセージが発信したので、FT目的のためにこのメッセージは承認される必要はありません。 しかしながら、'ラベルなしリソース'Notificationを受け取る自由民主党の同輩は、それが'利用可能なラベルリソース'Notificationメッセージを受け取るまでメッセージをLabel Requestに送るのを止めます。 この求められていないNotificationがセッション失敗の間、失せるかもしれないので、それは本書では説明された手順を用いることで保護されるかもしれません。
An alternative approach allows that an implementation may always assume that labels are available when a session is re-established. In this case, it is possible that it may throw away the 'No label resources' information from the previous incarnation of the session and may send a batch of LDP messages on session re-establishment that will fail and that it could have known would fail.
代替的アプローチで、実現は、いつもセッションが復職するとき、ラベルが利用可能であると仮定できるかもしれません。 この場合、セッションの前の肉体化から'ラベルなしリソース'情報を無駄にするかもしれなくて、それが失敗するのを知ったかもしれない失敗するセッション再建とそれに関する自由民主党メッセージのバッチを送るのは、可能です。
Note that the sender of a 'Label resources available' Notification message may choose whether to add a sequence number requesting acknowledgement. Conversely, the receiver of 'Label resources available' Notification message may choose to acknowledge the message without actually saving any state.
'利用可能なラベルリソース'Notificationメッセージの送付者が、承認を要求する一連番号を加えるかどうかを選ぶかもしれないことに注意してください。 逆に、'利用可能なラベルリソース'Notificationメッセージの受信機は、実際にどんな状態も節約しないでメッセージを承認するのを選ぶかもしれません。
This is an implementation choice made possible by making the FT parameters on the Notification message optional. Implementations will interoperate fully if they take opposite approaches, but additional LDP messages may be sent unnecessarily on session recovery.
これは選択がNotificationメッセージに関するFTパラメタを任意にすることによって可能にした実現です。 アプローチの反対側で取ると、実現は完全に共同利用するでしょうが、セッション回復で不必要に追加自由民主党メッセージを送るかもしれません。
4.8. Tunneled LSPs
4.8. トンネルを堀られたLSPs
The procedures described in this document can be applied to LSPs that are tunnels and to LSPs that are carried by tunnels. Recall that tunneled LSPs are managed by a single LDP session that runs end to end, while the tunnel is managed by a different LDP session for each hop along the path. Nevertheless, a break in one of the sessions that manages the tunnel is likely to correspond with a break in the session that manages the tunneled LSP. This is certainly the case when the LDP exchanges share a failed link, but need not be the case if the LDP messages have been routed along a path that is different from that of the tunnel, or if the failure in the tunnel is caused by an LDP software failure at a transit LSR.
トンネルであるLSPsと、そして、トンネルによって運ばれるLSPsに本書では説明された手順は適用できます。 トンネルを堀られたLSPsが走行が終わるために終わらせるただ一つの自由民主党のセッションで管理されたと思い出してください、トンネルは経路に沿った各ホップのための異なった自由民主党のセッションで管理されますが。 それにもかかわらず、トンネルを管理するセッションのひとりにおける中断はトンネルを堀られたLSPを管理するセッションにおける中断に相当しそうです。 自由民主党メッセージがトンネルのものと異なった経路に沿って発送されたか、またはトンネルでの失敗がトランジットLSRで自由民主党ソフトウェア障害によって引き起こされるならケースである必要はないのを除いて、自由民主党の交換が失敗したリンクを共有するとき、確かに、これはそうです。
Farrel Standards Track [Page 13] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[13ページ]。
In order that the forwarding path of a tunneled LSP be preserved, the forwarding path of the tunnel itself must be preserved. This means that the tunnel must not be torn down if there is any session failure along its path. To achieve this, the label exchanges between each pair of LDP peers along the path of the tunnel must use one of the procedures in this document or in [RFC3478].
aの推進経路がLSPにトンネルを堀ったには、保持されてください、そして、トンネル自体の推進経路を保持しなければなりません。 これは、経路に沿って失敗がどんなセッションのときにもあればトンネルを取りこわしてはいけないことを意味します。 これを達成するために、トンネルの経路に沿ったそれぞれの組の自由民主党の同輩の間のラベル交換はこのドキュメントか[RFC3478]の手順の1つを使用しなければなりません。
It is perfectly acceptable to mix the restart procedures used for the tunnel and the tunneled LSP. For example, the tunnel could be set up using just check-pointing because it is a stable LSP, but the tunneled LSPs might use full FT procedures so that they can recover active state.
トンネルとトンネルを堀られたLSPに用いられた再開手順を混合するのは完全に許容できます。 例えば、それが安定したLSPですが、トンネルを堀られたLSPsが活動的な状態を回復できるように完全なFT手順を用いるかもしれないのでまさしくチェック指すことを使用するのにトンネルを設定できました。
Lastly, it is permissible to carry tunneled LSPs that do not have FT protection in an LSP that has FT protection.
最後に、FT保護を持っているLSPにFT保護を持っていないトンネルを堀られたLSPsを運ぶのは許されています。
5. FT Operations
5. フィート、操作
Once an FT LDP session has been established, using the S bit in the FT Session TLV on the Session Initialization message as described in section 4.1, "Establishing an FT LDP Session", both LDP peers MUST apply the procedures described in this section for FT LDP message exchanges.
一度、FT LDPセッションは確立されたことがあって、「自由民主党のセッションをフィート確立し」て、セクション4.1で説明されるようにSession初期設定メッセージでFT Session TLVでSビットを使用して、両方の自由民主党の同輩はFT LDP交換処理のためにこのセクションで説明された手順を適用しなければなりません。
If the LDP session has been negotiated to not use the LDP FT enhancements, these procedures MUST NOT be used.
自由民主党のセッションがLDP FT増進を使用しないように交渉されたなら、これらの手順を用いてはいけません。
5.1. FT LDP Messages
5.1. フィート自由民主党は通信します。
5.1.1 Sequence Numbered FT Label Messages
5.1.1 系列番号付のフィートはメッセージをラベルします。
A label is identified as being a Sequence Numbered FT Label if the initial Label Request or Label Mapping message relating to that label carries the FT Protection TLV.
ラベルはそのラベルに関連する初期のLabel RequestかLabel MappingメッセージがFT Protection TLVを運ぶならSequence Numbered FT Labelであるとして特定されます。
It is a valid implementation option to flag all labels as Sequence Numbered FT Labels. Indeed this may be a preferred option for implementations wishing to use Keepalive messages carrying the FT Protection TLV to achieve periodic saves of the complete label forwarding state.
Sequence Numbered FT Labelsとしてすべてのラベルに旗を揚げさせるのは、有効な実現オプションです。 本当に、これは状態を進めながら完全なラベルの周期的なセーブを達成するためにFT Protection TLVを運びながらKeepaliveメッセージを使用したがっている実現のための都合のよいオプションであるかもしれません。
If a label is a Sequence Numbered FT Label, all LDP messages affecting that label MUST carry the FT Protection TLV so that the state of the label can be recovered after a failure of the LDP session.
そのラベルに影響するすべての自由民主党メッセージがラベルがSequence Numbered FT Labelであるなら、FT Protection TLVを運ばなければならないので、自由民主党のセッションの失敗の後にラベルの状態を回復できます。
Farrel Standards Track [Page 14] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[14ページ]。
A further valid option is for no labels to be Sequence Numbered FT Labels. In this case, check-pointing using the Keepalive message applies to all messages exchanged on the session.
ラベルなしはさらなる妥当な選択肢がSequence Numbered FT Labelsであることです。 この場合、Keepaliveメッセージを使用するチェック指すことがセッションのときに交換されたすべてのメッセージに適用されます。
5.1.1.1 Scope of FT Labels
5.1.1.1 フィートの範囲はラベルします。
The scope of the FT/non-FT status of a label is limited to the LDP message exchanges between a pair of LDP peers.
ラベルの非FT/FT状態の範囲は1組の自由民主党の同輩の間の自由民主党交換処理に制限されます。
In Ordered Control, when the message is forwarded downstream or upstream, the TLV may be present or absent according to the requirements of the LSR sending the message.
川下か上流へメッセージを転送するとき、Ordered Controlでは、メッセージを送るLSRの要件に従って、TLVは現在である、または欠けているかもしれません。
If a platform-wide label space is used for FT Labels, an FT Label value MUST NOT be reused until all LDP FT peers to which the label was passed have acknowledged the withdrawal of the FT Label, either by an explicit LABEL WITHDRAW/LABEL RELEASE, exchange or implicitly if the LDP session is reconnected after failure but without the FT Reconnect Flag set. In the event that a session is not re- established within the Reconnection Timeout, a label MAY become available for re-use if it is not still in use on some other session.
プラットホーム全体のラベルスペースがFT Labelsに使用されるなら、ラベルが渡されたすべてのLDP FT同輩がどちらか明白なLABEL WITHDRAW/LABEL RELEASE、交換でFT Labelの退出を承諾するか、または自由民主党のセッションが失敗の後に再接続されますが、FT Reconnect Flagなしでそれとなくセットするまで、FT Label値を再利用してはいけません。 それがまだ使用中でなく、またセッションがReconnection Timeoutの中で再確立されない場合、ラベルはある他のセッションのときに再使用に利用可能になるかもしれません。
5.1.2 FT Address Messages
5.1.2 フィートはメッセージを記述します。
If an LDP session uses the LDP FT enhancements, both LDP peers MUST secure Address and Address Withdraw messages using FT Operation ACKs, as described below. This avoids any ambiguity over whether an Address is still valid after the LDP session is reconnected.
自由民主党のセッションがLDP FT増進を使用するなら、FT Operation ACKsを使用して、両方の自由民主党の同輩はAddressとAddress Withdrawメッセージを固定しなければなりません、以下で説明されるように。 自由民主党のセッションが再接続された後にAddressがまだ有効であるかどうかに関してこれはどんなあいまいさも避けます。
If an LSR determines that an Address message it sent on a previous instantiation of a recovered LDP session is no longer valid, it MUST explicitly issue an Address Withdraw for that address when the session is reconnected.
セッションが再接続されるとき、LSRが、それが回復している自由民主党のセッションの前の具体化で送ったAddressメッセージがもう有効でないことを決定するなら、それはそのアドレスのために明らかにAddress Withdrawを発行しなければなりません。
If the FT Reconnect Flag is not set by both LDP peers upon reconnection of an LDP session (i.e. state has not been preserved), both LDP peers MUST consider all Addresses to have been withdrawn. The LDP peers SHOULD issue new Address messages for all their valid addresses, as specified in [RFC3036].
両方の自由民主党の同輩が自由民主党のセッションの再接続にFT Reconnect Flagを用意ができさせないなら(すなわち、状態は保持されていません)、両方の自由民主党の同輩は、すべてのAddressesが引っ込められたと考えなければなりません。 SHOULDが[RFC3036]で指定されるようにそれらのすべての有効なアドレスへの新しいAddressメッセージを発行する自由民主党の同輩。
5.1.3 Label Resources Available Notifications
5.1.3 利用可能な通知とリソースをラベルしてください。
In LDP, it is possible that a downstream LSR may not have labels available to respond to a Label Request. In this case, as specified in RFC 3036, the downstream LSR must respond with a Notification - No Label Resources message. The upstream LSR then suspends asking for new labels until it receives a Notification - Label Resources Available message from the downstream LSR.
自由民主党では、川下のLSRにはLabel Requestに反応するために利用可能なラベルがないのは、可能です。 この場合、RFC3036で指定されるように、川下のLSRはNotificationと共に応じなければなりません--Label Resourcesメッセージがありません。 次に、Notificationを受けるまで、上流のLSRは新しいラベルのための尋ねることを中断させます--川下のLSRからのラベルResources Availableメッセージ。
Farrel Standards Track [Page 15] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[15ページ]。
When the FT extensions are used on a session, implementations may choose whether or not to secure the label resource state of their peer. This choice impacts the number of LDP messages that will be incorrectly routed to a peer with depleted resources on session re- establishment, but does not otherwise impact interoperability.
FT拡張子がセッションのときに使用されるとき、実現は、彼らの同輩のラベルリソース状態を保証するかどうかを選ぶかもしれません。 この選択は、セッション再設立に関する使い果たされたリソースで不当に同輩に発送される自由民主党メッセージの数に影響を与えますが、そうでなければ、相互運用性は影響を与えません。
For full preservation of state:
状態の完全な保存のために:
- The downstream LSR must preserve the label availability state
across a failover so that it remembers to send Notification -
Label Resources Available when the resources become available.
- 川下のLSRがフェイルオーバーの向こう側にラベル有用性状態を保持しなければならないので、忘れずに通告を送っています--リソースが利用可能になったら、Resources Availableをラベルしてください。
- The upstream LSR must recall the label availability state across
failover so that it can optimize not sending Label Requests when
it recovers.
- 上流のLSRは、回復する場合Label Requestsを送らないことで最適化できるようにフェイルオーバーの向こう側にラベル有用性状態を思い出さなければなりません。
- The downstream LSR must use sequence numbers on Notification -
Label Resources Available so that it can check that LSR A has
received the message and clear its secured state, or resend the
message if LSR A recovers without having received it.
- 川下のLSRはNotificationで一連番号を使用しなければなりません--LSR Aがメッセージを受け取ったのをチェックして、安全にされた状態をきれいにすることができるように、Resources Availableをラベルするか、またはLSR Aがそれを受けていなくて回復するなら、メッセージを再送してください。
However, the following options also exist:
しかしながら、また、以下のオプションは存在しています:
- The downstream LSR may choose to not include a sequence number on
Notification - Label Resources Available. This means that on
session re-establishment it does not know what its peer thinks the
LSR's resource state is, because the Notification may or may not
have been delivered. Such an implementation MUST begin recovered
sessions by sending an additional Notification - Label Resources
Available to reset its peer.
- 川下のLSRは、Notificationの一連番号を含んでいないのを選ぶかもしれません--ラベルResources Available。 これは、セッション再建では、同輩が、考えるLSRのリソース状態が何であるかを知らないことを意味します、Notificationを届けたかもしれないので。 そのような実現は追加Notificationを送ることによって、回復しているセッションを始めなければなりません--Resources Availableをラベルして、同輩をリセットしてください。
- The upstream node may choose not to secure information about its
peer's resource state. It would acknowledge a Notification -
Label Resources Available, but would not save the information.
Such an implementation MUST assume that its peer's resource state
has been reset to Label Resources Available when the session is
re-established.
- 上流のノードは、同輩のリソース状態に関して情報を確保しないのを選ぶかもしれません。 それは、Notification--Resources Availableをラベルするように認めるでしょうが、情報を保存しないでしょう。 そのような実現は、セッションが復職するとき、同輩のリソース状態がLabel Resources Availableにリセットされたと仮定しなければなりません。
If the FT Reconnect Flag is not set by both LDP peers upon reconnection of an LDP session (i.e. state has not been preserved), both LDP peers MUST consider the label availability state to have been reset as if the session had been set up for the first time.
両方の自由民主党の同輩が自由民主党のセッションの再接続にFT Reconnect Flagを用意ができさせないなら(すなわち、状態は保持されていません)、まるでセッションが初めてセットアップされたかのように両方の自由民主党の同輩は、ラベル有用性状態がリセットされたと考えなければなりません。
Farrel Standards Track [Page 16] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[16ページ]。
5.2. FT Operation ACKs
5.2. フィート操作ACKs
Handshaking of FT LDP messages is achieved by use of ACKs. Correlation between the original message and the ACK is by means of the FT Sequence Number contained in the FT Protection TLV, and passed back in the FT ACK TLV. The FT ACK TLV may be carried on any LDP message that is sent on the TCP connection between LDP peers.
FT LDPメッセージのハンドシェイクはACKsの使用で達成されます。 オリジナルのメッセージとACKの間の相関関係がFT Protection TLVに含まれていて、FT ACK TLVで戻されたFT Sequence Numberによってあります。 FT ACK TLVは自由民主党の同輩の間のTCP接続に送られるどんな自由民主党メッセージでも運ばれるかもしれません。
An LDP peer maintains a separate FT sequence number for each LDP session in which it participates. The FT Sequence number is incremented by one for each FT LDP message (i.e. containing the FT Protection TLV) issued by this LSR on the FT LDP session with which the FT sequence number is associated.
自由民主党の同輩はそれが関与するそれぞれの自由民主党のセッションのために別々のFT一連番号を維持します。 FT Sequence番号はFT一連番号が関連しているFT LDPセッションのときにこのLSRによって発行されたそれぞれのFT LDPメッセージ(すなわち、FT Protection TLVを含んでいる)あたり1つ増加されます。
When an LDP peer receives a message containing the FT Protection TLV, it MUST take steps to secure this message (or the state information derived from processing the message). Once the message is secured, it MUST be ACKed. However, there is no requirement on the LSR to send this ACK immediately.
自由民主党の同輩がFT Protection TLVを含むメッセージを受け取るとき、それは、このメッセージを保証するために手を打たなければなりません(州の情報が処理にメッセージに由来していました)。 いったんメッセージを保証すると、それはACKedであるに違いありません。 しかしながら、すぐにこのACKを送るというLSRに関する要件が全くありません。
ACKs may be accumulated to reduce the message flow between LDP peers. For example, if an LSR received FT LDP messages with sequence numbers 1, 2, 3, 4, it could send a single ACK with sequence number 4 to ACK receipt, securing of all these messages. There is no protocol reason why the number of ACKs accumulated, or the time for which an ACK is deferred, should not be allowed to become relatively large.
ACKsは、自由民主党の同輩の間のメッセージ流動を減少させるために蓄積されるかもしれません。 例えば、LSRが一連番号1、2、3、4でFT LDPメッセージを受け取るなら、それは一連番号4と共にACK領収書、これらのすべてのメッセージを安全にするのに独身のACKを送るかもしれないでしょうに。 ACKsの数が蓄積した理由、またはACKが延期される時間が比較的大きくなることができないべきであるプロトコル理由が全くありません。
ACKs MUST NOT be sent out of sequence, as this is incompatible with the use of accumulated ACKs. Duplicate ACKs (that is two successive messages that acknowledge the same sequence number) are acceptable.
これが蓄積されたACKsの使用と非互換であるので、系列からACKsを送ってはいけません。 写しACKs(それは同じ一連番号を承認する2つの連続したメッセージである)は許容できます。
If an LDP peer discovers that its sequence number space for a specific session is full of un-acknowledged sequence numbers (because its partner on the session has not acknowledged them in a timely way), it cannot allocate a new sequence number for any further FT LPD message. It SHOULD send a Notification message with the status code 'FT Seq Numbers Exhausted'.
自由民主党の同輩が、特定のセッションのための一連番号スペースが不承認の一連番号でいっぱいであると発見するなら(セッションでのパートナーがタイムリーな方法でそれらを承認していないので)、それはどんなさらなるFT LPDメッセージのためにも新しい一連番号を割り当てることができません。 それ、SHOULDは'FT Seq民数記Exhausted'というステータスコードがあるNotificationメッセージを送ります。
5.3. Preservation of FT State
5.3. フィート州の保存
If the LDP FT enhancements are in use on an LDP session, each LDP peer SHOULD NOT release the state information and resources associated with FT Labels exchanged on that LDP session when the TCP connection fails. This is contrary to [RFC3036], but allows label operations on FT Labels to be completed after re-connection of the TCP connection.
LDP FT増進が自由民主党のセッションのときに使用中であるなら、各自由民主党同輩SHOULD NOTはTCP接続が失敗するその自由民主党のセッションのときに交換するFT Labelsに関連している州の情報とリソースを発表します。 これで、[RFC3036]とは逆にありますが、FT Labelsにおけるラベル操作はTCP接続の再接続の後に完了します。
Farrel Standards Track [Page 17] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[17ページ]。
Both LDP peers on an LDP session that is using the LDP FT enhancements SHOULD preserve the state information and resources they hold for that LDP session as described below.
LDP FT増進SHOULDを使用している自由民主党のセッションでの両方の自由民主党の同輩はそれらがその自由民主党のセッションのために以下で説明されるように保持する州の情報とリソースを保存します。
- An upstream LDP peer SHOULD release the resources (in particular
bandwidth) associated with a Sequence Numbered FT Label when it
initiates a Label Release or Label Abort message for the label.
The upstream LDP peer MUST preserve state information for the
Sequence Numbered FT Label, even if it releases the resources
associated with the label, as it may need to reissue the label
operation if the TCP connection is interrupted.
- それであるときにリソース(特に帯域幅)がSequence Numbered FT Labelに関連づけた上流の自由民主党の同輩SHOULDリリースはラベルへのLabel ReleaseかLabel Abortメッセージを開始します。 上流の自由民主党の同輩はSequence Numbered FT Labelのための州の情報を保存しなければなりません、ラベルに関連しているリソースを発表しても、TCP接続が遮られるならラベル操作を再発行するのが必要であるときに。
- An upstream LDP peer MUST release the state information and
resources associated with a Sequence Numbered FT Label when it
receives an acknowledgement to a Label Release or Label Abort
message that it sent for the label, or when it sends a Label
Release message in response to a Label Withdraw message received
from the downstream LDP peer.
- それがラベルのために発信したというLabel ReleaseかLabel Abortメッセージに承認を受けるか、または川下の自由民主党の同輩から受け取られたLabel Withdrawメッセージに対応してLabel Releaseメッセージを送るとき、上流の自由民主党の同輩はSequence Numbered FT Labelに関連している州の情報とリソースを発表しなければなりません。
- A downstream LDP peer SHOULD NOT release the resources associated
with a Sequence Numbered FT Label when it sends a Label Withdraw
message for the label as it has not yet received confirmation that
the upstream LDP peer has ceased to send data using the label.
The downstream LDP peer MUST NOT release the state information it
holds for the label as it may yet have to reissue the label
operation if the TCP connection is interrupted.
- まだ、上流の自由民主党の同輩が持っている確認を受け取っていないときラベルへのLabel Withdrawメッセージを送るとき、リソースがSequence Numbered FT Labelに関連づけた川下の自由民主党の同輩SHOULD NOTリリースは、ラベルを使用することでデータを送るのをやめました。 TCP接続が遮られるならまだラベル操作を再発行している必要はないかもしれないとき、川下の自由民主党の同輩はそれがラベルのために保持する州の情報を発表してはいけません。
- A downstream LDP peer MUST release the resources and state
information associated with a Sequence Numbered FT Label when it
receives an acknowledgement to a Label Withdraw message for the
label.
- ラベルへのLabel Withdrawメッセージに承認を受けるとき、川下の自由民主党の同輩はSequence Numbered FT Labelに関連しているリソースと州の情報を発表しなければなりません。
- When the FT Reconnection Timeout expires, an LSR SHOULD release
all state information and resources from previous instantiations
of the (permanently) failed LDP session.
- FT Reconnection Timeoutが期限が切れて、LSR SHOULDリリースが(永久に)失敗した自由民主党のセッションの前の具体化からのすべての州の情報とリソースであるときに。
- Either LDP peer MAY elect to release state information based on
its internal knowledge of the loss of integrity of the state
information or an inability to pend (or queue) LDP operations (as
described in section 5.4.1, "LDP Operations During TCP Failure")
during a TCP failure. That is, the peer is not required to wait
for the duration of the FT Reconnection Timeout before releasing
state; the timeout provides an upper limit on the persistence of
state. However, in the event that a peer releases state before
the expiration of the Reconnection Timeout, it MUST NOT re-use any
label that was in use on the session until the Reconnection
Timeout has expired.
- どちらの自由民主党の同輩も、TCPの故障の間に州の情報の保全かpend(列を作る)自由民主党の操作への無能(セクション5.4.1、「TCPの故障の間の自由民主党の操作」で説明されるように)の損失に関する内部の知識に基づく州の情報を発表するのを選ぶかもしれません。 状態をリリースする前に、すなわち、同輩はFT Reconnection Timeoutの持続時間を待つ必要はありません。 タイムアウトは状態の固執のときに上限を提供します。 しかしながら、同輩がReconnection Timeoutの満了の前に状態をリリースする場合、それはどんなReconnection Timeoutが期限が切れるまでセッションのときに使用中であったラベルも再使用してはいけません。
Farrel Standards Track [Page 18] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[18ページ]。
- When an LSR receives a Status TLV with the E-bit set in the status
code, which causes it to close the TCP connection, the LSR MUST
release all state information and resources associated with the
session. This behavior is mandated because it is impossible for
the LSR to predict the precise state and future behavior of the
partner LSR that set the E-bit without knowledge of the
implementation of that partner LSR.
- LSRがそれがTCP接続を終えるステータスコードで設定されたE-ビットでStatus TLVを受けるとき、LSR MUSTはすべての州の情報とセッションに関連しているリソースを発表します。 LSRがそのパートナーLSRの実現に関する知識なしでE-ビットを設定するパートナーLSRの正確な状態と今後の動きを予測するのが、不可能であるので、この振舞いは強制されます。
Note that the 'Temporary Shutdown' status code does not have the
E-bit set, and MAY be used during maintenance or upgrade
operations to indicate that the LSR intends to preserve state
across a closure and re-establishment of the TCP session.
'一時的なShutdown'ステータスコードがE-ビットを設定させないで、維持かアップグレード操作の間使用されるかもしれないことに注意して、LSRがTCPセッションの閉鎖と再建の向こう側に状態を保持するつもりであるのを示してください。
- If an LSR determines that it must release state for any single FT
Label during a failure of the TCP connection on which that label
was exchanged, it MUST release all state for all labels on the LDP
session.
- LSRが、どんな独身のFT Labelのためにもそのラベルが交換されたTCP接続の失敗の間状態をリリースしなければならないことを決定するなら、それは自由民主党のセッションでのすべてのラベルのためにすべての状態をリリースしなければなりません。
The release of state information and resources associated with non-FT labels is as described in [RFC3036].
非FTラベルに関連している州の情報とリソースのリリースが[RFC3036]で説明されるようにあります。
Note that a Label Release and the acknowledgement to a Label Withdraw may be received by a downstream LSR in any order. The downstream LSR MAY release its resources upon receipt of the first message and MUST release its resources upon receipt of the second message.
Label WithdrawへのLabel Releaseと承認が順不同な川下のLSRによって受けられるかもしれないことに注意してください。 川下のLSR MAYは最初のメッセージを受け取り次第リソースを発表して、2番目のメッセージを受け取り次第リソースを発表しなければなりません。
5.4. FT Procedure After TCP Failure
5.4. フィート、TCPの故障の後の手順
When an LSR discovers or is notified of a TCP connection failure it SHOULD start an FT Reconnection Timer to allow a period for re- connection of the TCP connection between the LDP peers.
LSRが発見するいつか、TCP接続の故障について通知される、それ、SHOULDは、自由民主党の同輩の間のTCP接続の再接続のための期間を許容するためにFT Reconnection Timerを始動します。
The RECOMMENDED default value for this timer is 5 seconds. During this time, failure must be detected and reported, new hardware may need to be activated, software state must be audited, and a new TCP session must be set up.
このタイマのためのRECOMMENDEDデフォルト値は5秒です。 この間に、失敗を検出されて、報告しなければなりません、そして、新しいハードウェアは、動かされる必要があるかもしれません、そして、ソフトウェア状態を監査しなければなりません、そして、新しいTCPセッションをセットアップしなければなりません。
Once the TCP connection between LDP peers has failed, the active LSR SHOULD attempt to re-establish the TCP connection. The mechanisms, timers and retry counts to re-establish the TCP connection are an implementation choice. It is RECOMMENDED that any attempt to re- establish the connection should take into account the failover processing necessary on the peer LSR, the nature of the network between the LDP peers, and the FT Reconnection Timeout chosen on the previous instantiation of the TCP connection (if any).
自由民主党の同輩の間のTCP接続がいったん失敗すると、アクティブなLSR SHOULDは、TCP接続を復職させるのを試みます。 TCP接続を復職させるメカニズム、タイマ、および再試行カウントは実現選択です。 接続を再確立するどんな試みも同輩LSR、自由民主党の同輩の間のネットワークの本質、およびTCP接続の前の具体化で選ばれたFT Reconnection Timeout(もしあれば)で必要なフェイルオーバー処理を考慮に入れるべきであるのは、RECOMMENDEDです。
Farrel Standards Track [Page 19] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[19ページ]。
If the TCP connection cannot be re-established within the FT Reconnection Timeout period, the LSR detecting this timeout SHOULD release all state preserved for the failed LDP session. If the TCP connection is subsequently re-established (for example, after a further Hello exchange to set up a new LDP session), the LSR MUST set the FT Reconnect Flag to 0 if it released the preserved state information on this timeout event.
TCP接続がFT Reconnection Timeoutの期間中に復職できないなら、このタイムアウトSHOULDを検出するLSRは失敗した自由民主党のセッションのために保持されたすべての状態をリリースします。 TCP接続が次に復職するなら(例えばさらなるHello交換のときに新しい自由民主党のセッションに設定する後)、それがこのタイムアウト出来事の保存された州の情報を発表したなら、LSR MUSTは0にFT Reconnect Flagを設定します。
If the TCP connection is successfully re-established within the FT Reconnection Timeout, both peers MUST re-issue LDP operations that were interrupted by (that is, un-acknowledged as a result of) the TCP connection failure. This procedure is described in section 5.5, "FT Procedure After TCP Re-connection".
TCP接続がFT Reconnection Timeoutの中で首尾よく復職するなら、両方の同輩は(それがそうです、その結果認められません)TCP接続の故障で中断された自由民主党の操作を再発行しなければなりません。 この手順がセクション5.5で説明される、「フィート、TCP再接続の後の手順、」
The Hold Timer for an FT LDP Session (see [RFC3036] section 2.5.5) SHOULD be ignored while the FT Reconnection Timer is running. The hold timer SHOULD be restarted when the TCP connection is re- established.
Hold Timer、FT LDP Session([RFC3036]セクション2.5.5を見る)SHOULDに関しては、FT Reconnection Timerが走りである間、無視されてください。 タイマがSHOULDであることを保持してください。TCP接続が再確立されるとき、再開されます。
5.4.1 FT LDP Operations During TCP Failure
5.4.1 フィート、TCPの故障の間の自由民主党の操作
When the LDP FT enhancements are in use for an LDP session, it is possible for an LSR to determine that it needs to send an LDP message to an LDP peer, but that the TCP connection to that peer is currently down. These label operations affect the state of FT Labels preserved for the failed TCP connection, so it is important that the state changes are passed to the LDP peer when the TCP connection is restored.
LDP FT増進が自由民主党のセッションのために使用中であるときに、LSRが、自由民主党メッセージを自由民主党の同輩に送るのが必要ですが、その同輩とのTCP接続が現在下にあることを決定するのは、可能です。 これらのラベル操作が失敗したTCP接続のために保存されたFT Labelsの州に影響するので、TCP接続が復元されるとき、州の変化が自由民主党の同輩に流れるのは、重要です。
If an LSR determines that it needs to issue a new FT LDP operation to an LDP peer to which the TCP connection is currently failed, it MUST pend the operation (e.g. on a queue) and complete that operation with the LDP peer when the TCP connection is restored, unless the label operation is overridden by a subsequent additional operation during the TCP connection failure (see section 5.5, "FT Procedure After TCP Re-connection").
TCP接続であることの自由民主党の同輩との操作は操作(例えば、待ち行列の)と完全なpendですが、回復していた状態でそうしなければなりません、LSRが、TCP接続が現在失敗される自由民主党の同輩に新しいFT LDP操作を発行するのが必要であることを決定して、ラベル操作がTCP接続の故障の間、その後の兼業でくつがえされない場合dmyである、(セクション5.5を見てください、「フィート、TCP再接続の後の手順、」、)
If, during TCP Failure, an LSR determines that it cannot pend an operation which it cannot simply fail (for example, a Label Withdraw, Release or Abort operation), it MUST NOT attempt to re-establish the previous LDP session. The LSR MUST behave as if the Reconnection Timer expired and release all state information with respect to the LDP peer. An LSR may be unable (or unwilling) to pend operations; for instance, if a major routing transition occurred while TCP was inoperable between LDP peers, it might result in excessively large numbers of FT LDP Operations. An LSR that releases state before the expiration of the Reconnection Timeout MUST NOT re-use any label that was in use on the session until the Reconnection Timeout has expired.
LSRが、TCP Failureの間、絶対に失敗できない操作(例えば、Label Withdraw、ReleaseまたはAbort操作)をpendすることができないことを決定するなら、それは、前の自由民主党のセッションを復職させるのを試みてはいけません。 LSR MUSTはまるでReconnection Timerが期限が切れるかのように振る舞って、自由民主党の同輩に関してすべての州の情報を発表します。 LSRはpend操作に(不本意)であるかもしれません。 例えば、TCPが自由民主党の同輩の間で手術不能でしたが、主要なルーティング変遷が起こるなら、それは多くのFT LDP Operationsをもたらすでしょうに。 Reconnection Timeoutの満了の前に状態をリリースするLSRはどんなReconnection Timeoutが期限が切れるまでセッションのときに使用中であったラベルも再使用してはいけません。
Farrel Standards Track [Page 20] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[20ページ]。
In ordered operation, received FT LDP operations that cannot be correctly forwarded because of a TCP connection failure MAY be processed immediately (provided sufficient state is kept to forward the label operation) or pended for processing when the onward TCP connection is restored and the operation can be correctly forwarded upstream or downstream. Operations on existing FT Labels SHOULD NOT be failed during TCP session failure.
命令された操作では、前方のTCP接続を復元して、正しく上流か川下に操作を送ることができるとき、TCP接続の故障のために正しく進めることができない容認されたFT LDP操作をすぐに(十分な状態がラベル操作を進めるために維持されるなら)、処理するか、または処理のために、pendedするかもしれません。 操作、既存のFT Labels SHOULDでは、TCPセッションの故障の間、失敗されないでください。
It is RECOMMENDED that Label Request operations for new FT Labels not be pended awaiting the re-establishment of TCP connection that is awaiting recovery at the time the LSR determines that it needs to issue the Label Request message. Instead, such Label Request operations SHOULD be failed and, if necessary, a notification message containing the 'No LDP Session' status code sent upstream.
新しいFT LabelsのためのLabel Request操作がLSRが、Label Requestメッセージを発行するのが必要であることを決定するとき回復を待っているTCP接続の再建を待ちながらpendedされないのは、RECOMMENDEDです。 代わりにそのようなLabel Request操作SHOULD、失敗されていて必要なら上流へ送られた'自由民主党Sessionがありません'ステータスコードを含む通知メッセージになってください。
Label Requests for new non-FT Labels MUST be rejected during TCP connection failure, as specified in [RFC3036].
TCP接続の故障の間、指定されるとして[RFC3036]で新しい非FT LabelsのためのラベルRequestsを拒絶しなければなりません。
5.5. FT Procedure After TCP Re-connection
5.5. フィート、TCP再接続の後の手順
The FT operation handshaking described above means that all state changes for Sequence Numbered FT Labels and Address messages are confirmed or reproducible at each LSR.
FT操作ハンドシェイクは、手段を超えてSequence Numbered FT Labelsのためのすべての州の変化とAddressメッセージが各LSRで確認されているか、または再現可能であると説明しました。
If the TCP connection between LDP peers fails but is re-connected within the FT Reconnection Timeout, and both LSRs have indicated they will be re-establishing the previous LDP session, both LDP peers on the connection MUST complete any label operations for Sequence Numbered FT Labels that were interrupted by the failure and re- connection of the TCP connection.
自由民主党の同輩の間のTCP接続が失敗しますが、FT Reconnection Timeoutの中で再接続されて、両方のLSRsが、彼らが前の自由民主党のセッションを復職させるのを示したなら、接続での両方の自由民主党の同輩はTCP接続の失敗と再接続によって中断されたSequence Numbered FT Labelsのためのどんなラベル操作も完了しなければなりません。
The procedures for FT Reconnection Timeout MAY have been invoked as a result of either LDP peer being unable (or unwilling) to pend operations which occurred during the TCP Failure (as described in section 5.4.1, "LDP Operations During TCP Failure").
FT Reconnection Timeoutのための手順はどちらかのTCP Failureの間に起こったpend操作に(不本意)である自由民主党の同輩の結果、呼び出されたかもしれません(セクション5.4.1、「TCPの故障の間の自由民主党の操作」で説明されるように)。
If, for any reason, an LSR has been unable to pend operations with respect to an LDP peer, as described in section 5.4.1, "LDP Operations During TCP Failure", the LSR MUST set the FT Reconnect Flag to 0 on re-connection to that LDP peer indicating that no FT state has been preserved.
どんな理由でも自由民主党の同輩に関してpend操作にLSRであることができなかったなら、セクション5.4.1、「TCPの故障の間の自由民主党の操作」で説明されるように、LSR MUSTはFT状態が全く保持されていないのを示すその自由民主党の同輩への再接続のときに0にFT Reconnect Flagを設定します。
Label operations are completed using the following procedure.
ラベル操作は、以下の手順を用いることで完了しています。
Farrel Standards Track [Page 21] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[21ページ]。
5.5.1 Re-Issuing FT Messages
5.5.1 フィートを再発行するのは通信します。
Upon restoration of the TCP connection between LDP peers, any LDP messages for Sequence Numbered FT Labels that were lost because of the TCP connection failure are re-issued. The LDP peer that receives a re-issued message processes the message as if received for the first time.
自由民主党の同輩の間のTCP接続の回復のときに、TCP接続の故障でなくされたSequence Numbered FT Labelsへのどんな自由民主党メッセージも再発行されます。 再発行されたメッセージを受け取る自由民主党の同輩はまるで初めて受け取るかのようにメッセージを処理します。
"Net-zero" combinations of messages need not be re-issued after re- establishment of the TCP connection between LDP peers. This leads to the following rules for re-issuing messages that are not ACKed by the LDP peer on the LDP Initialization message exchange after re- connection of the TCP session.
メッセージの「ネット-ゼロ」組み合わせが自由民主党の同輩の間のTCP接続の再設立の後に再発行される必要はありません。 これはTCPセッションの再接続の後に自由民主党初期設定交換処理の自由民主党の同輩でACKedでないメッセージを再発行するための以下の規則に通じます。
- A Label Request message MUST be re-issued unless a Label Abort
would be re-issued for the same Sequence Numbered FT Label.
- Label Abortが同じSequence Numbered FT Labelのために再発行されないなら、Label Requestメッセージを再発行しなければなりません。
- A Label Mapping message MUST be re-issued unless a Label Withdraw
message would be re-issued for the same Sequence Numbered FT
Label.
- Label Withdrawメッセージが同じSequence Numbered FT Labelのために再発行されないなら、Label Mappingメッセージを再発行しなければなりません。
- All other messages on the LDP session that were sent and carried
the FT Protection TLV MUST be re-issued if an acknowledgement was
not previously been received.
- 承認が再発行したなら、送られて、FT Protection TLVを運んだ自由民主党のセッションに関する他のすべてのメッセージを再発行しなければなりません。以前に、受け取られません。
Any FT Label operations that were pended (see section 5.4.1, "LDP Operations During TCP Failure") during the TCP connection failure MUST also be issued upon re-establishment of the LDP session, except where they form part of a "net-zero" combination of messages according to the above rules.
また、自由民主党のセッションの再建でTCP接続の故障の間にpendedされた(セクション5.4.1、「TCPの故障の間の自由民主党の操作」を見ます)どんなFT Label操作も発行しなければなりません、上の規則に従ってそれらがメッセージの「ネットのゼロ」組み合わせの一部を形成するところを除いて。
The determination of "net-zero" FT Label operations according to the above rules MAY be performed on pended messages prior to the re- establishment of the TCP connection in order to optimize the use of queue resources. Messages that were sent to the LDP peer before the TCP connection failure, or pended messages that were paired with them, MUST NOT be subject to such optimization until an FT ACK TLV is received from the LDP peer. This ACK allows the LSR to identify which messages were received by the LDP peer prior to the TCP connection failure.
上の規則に従った「ネットのゼロ」FT Label操作の決断は、TCP接続の再設立の前に待ち行列リソースの使用を最適化するためにpendedメッセージに実行されるかもしれません。 TCP接続の故障の前に自由民主党の同輩に送ったか、またはそれらと対にされたメッセージをpendedしたメッセージは自由民主党の同輩からFT ACK TLVを受け取るまでそのような最適化を受けることがあるはずがありません。 このACKはどのメッセージがTCP接続の故障の前に自由民主党の同輩によって受け取られたかをLSRを特定させます。
6. Check-Pointing Procedures
6. チェックを指す手順
Check-Pointing can be selected independently from the FT procedures described above by using the C bit in the FT Session TLV on the Session Initialization message. Note, however, that check-pointing is an integral part of the FT procedures. Setting the S and the C bit will achieve the same function as setting just the S bit.
上でSession初期設定メッセージでFT Session TLVでCビットを使用することによって説明されたFT手順からチェック指すことを独自に選択できます。 しかしながら、チェック指すのがFT手順の不可欠の部分であることに注意してください。 SとCビットを設定すると、ちょうどSビットを設定するのと同じ機能は獲得されるでしょう。
Farrel Standards Track [Page 22] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[22ページ]。
If the C bit is set, but the S bit is not set, no label is a Sequence Numbered FT Label. Instead, all labels are Check-Pointable FT Labels. Check-Pointing is used to synchronize all label exchanges. No message, apart from the check-point request and acknowledgement, carries an active sequence number. (Note that the Session Initialization message may carry a sequence number to confirm that the check-point is still in place).
Cビットが設定されますが、Sビットは設定されないなら、ラベルなしがSequence Numbered FT Labelです。 代わりに、すべてのラベルがCheck-Pointable FT Labelsです。 チェック指すことは、すべてのラベル交換を同時にさせるのに使用されます。 検査点要求と承認は別として、どんなメッセージもアクティブな一連番号を運びません。 (Session初期設定メッセージが検査点がまだ適所にあると確認するために一連番号を運ぶかもしれないことに注意します。)
It is an implementation matter to decide the ordering of received messages and check-point requests to ensure that check-point acknowledgements are secured.
受信されたメッセージと検査点承認が保証されるのを保証するという検査点要求の注文について決めるのは、実現問題です。
If the S and C bits are both set, or only the S bit is set, check- pointing applies only to Sequence Numbered FT Labels and to address messages.
SとCビットがともに設定されるか、またはSビットだけが設定されるなら、チェックの指すことはSequence Numbered FT Labelsだけと、そして、アドレスメッセージに適用されます。
The set of all messages check-pointed in this way is called the Check-Pointable Messages.
チェックでこのように先鋭なすべてのメッセージのセットはCheck-Pointable Messagesと呼ばれます。
6.1 Check-Pointing with the Keepalive Message
6.1 Keepaliveとのチェック指すメッセージ
If an LSR receives a FT Protection TLV on a Keepalive message, this is a request to flush the acknowledgements for all previously received Check-Pointable Messages on the session.
LSRがKeepaliveメッセージでFT Protection TLVを受けるなら、これはセッションでのすべての以前に容認されたCheck-Pointable Messagesのために承認を洗い流すという要求です。
As soon as the LSR has completed securing the Check-Pointable Messages (or state changes consequent on those messages) received before the Keepalive, it MUST send an acknowledgement to the sequence number of the Keepalive message.
LSRが、Keepaliveの前に受け取られたCheck-Pointable Messages(または、それらのメッセージの結果の州の変化)を固定するのを完了するとすぐに、それはKeepaliveメッセージの一連番号に承認を送らなければなりません。
In the case where the FT procedures are in use and acknowledgements have been stored up, this may occur immediately upon receipt of the Keepalive.
FT手順が使用中であり、承認が蓄えられた場合では、Keepaliveを受け取り次第これはすぐに、起こるかもしれません。
An example message flow showing this use of the Keepalive message to perform a periodic check-point of state is shown in section 9.2, "Use of Check-Pointing With FT Procedures".
状態の周期的な検査点を実行するKeepaliveメッセージのこの使用を示している例のメッセージ流動はセクション9.2、「フィートとのチェック指す手順の使用」で示されます。
An example message flow showing the use of check-pointing without the FT procedures is shown in section 9.5, "Check-Pointing Without FT Procedures".
FT手順なしでチェック指すことの使用を示している例のメッセージ流動はセクション9.5、「フィートのないチェック指す手順」で示されます。
6.2 Quiesce and Keepalive
6.2 QuiesceとKeepalive
If the Keepalive Message also contains the FT Cork TLV, this indicates that the peer LSR wishes to quiesce the session prior to a graceful restart.
また、Keepalive MessageがFT Cork TLVを含んでいるなら、これは、同輩LSRが優雅な再開の前にquiesceにセッションを願っているのを示します。
Farrel Standards Track [Page 23] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[23ページ]。
It is RECOMMENDED that upon receiving a Keepalive with the FT CORK TLV, an LSR should cease to send any further label or address related messages on the session until it has been disconnected and reconnected, other than messages generated while processing and securing previously unacknowledged messages received from the peer requesting the quiesce. It should also attempt to complete this processing and return a Keepalive with the FT ACK TLV as soon as possible in order to allow the session to be quiesced.
FT CORK TLVと共にKeepaliveを受けるときLSRが、どんな一層のラベルも送るのをやめるはずであるのが、RECOMMENDEDであるかそれが外されて、再接続されるまで、アドレスはセッションのときにメッセージについて話しました、quiesceを要求する同輩から受け取られる不承認のメッセージを処理して、以前に保証している間に発生するメッセージを除いて。 また、それは、できるだけ早くセッションがquiescedされるのを許容するためにこの処理を終了して、FT ACK TLVとKeepaliveを返すのを試みるべきです。
An example message flow showing this use of the FT Cork TLV to achieve a three-way handshake of state synchronization between two LDP peers is given in section 9.4, "Temporary Shutdown With FT Procedures and Check-Pointing".
セクション9.4で2人の自由民主党の同輩の間の州の同期の3方向ハンドシェイクを達成するためにFT Cork TLVのこの使用を示している例のメッセージ流動を与える、「フィートとの一時的な閉鎖、手順とチェック指す、」
7. Changes to Existing Messages
7. 既存のメッセージへの変化
7.1. LDP Initialization Message
7.1. 自由民主党初期設定メッセージ
The LDP FT enhancements add the following optional parameters to a LDP Initialization message:
LDP FT増進は以下の任意のパラメタを自由民主党初期設定メッセージに追加します:
Optional Parameter Length Value
任意のパラメタ長さの価値
FT Session TLV 4 See Below
FT ACK TLV 4 See Below
4が以下のACK TLV4が見るフィートより下で見るフィートセッションTLV
The encoding for these TLVs is found in Section 8, "New Fields and Values".
これらのTLVsのためのコード化はセクション8と、「新しい分野と値」で見つけられます。
FT Session TLV
If present, specifies the FT behavior of the LDP session.
FT Session TLV Ifプレゼント、自由民主党のセッションのFTの振舞いを指定します。
FT ACK TLV
If present, specifies the last FT message that the sending LDP
peer was able to secure prior to the failure of the previous
instantiation of the LDP session. This TLV is only present if the
FT Reconnect flag is set in the FT Session TLV, in which case this
TLV MUST be present.
FT ACK TLV Ifは自由民主党のセッションの前の具体化の失敗の前に安全な状態で提示して、送付自由民主党の同輩ができたという最後のFTメッセージを指定します。 FT Reconnect旗がその場合、FT Session TLV、このTLV MUSTに設定される場合にだけ、このTLVは存在しています。存在してください。
Farrel Standards Track [Page 24] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[24ページ]。
7.2. LDP Keepalive Messages
7.2. 自由民主党Keepaliveメッセージ
The LDP FT enhancements add the following optional parameters to a LDP Keepalive message:
LDP FT増進は以下の任意のパラメタを自由民主党Keepaliveメッセージに追加します:
Optional Parameter Length Value
任意のパラメタ長さの価値
FT Protection TLV 4 See below
FT Cork TLV 0 See below
FT ACK TLV 4 See below
以下の保護TLV4が、フィートより下でコルクTLV0が、フィートより下でACK TLV4が見るのを見るのを見るフィート
The encoding for these TLVs is found in Section 8, "New Fields and Values".
これらのTLVsのためのコード化はセクション8と、「新しい分野と値」で見つけられます。
FT Protection TLV
If present, specifies the FT Sequence Number for the LDP message.
When present on a Keepalive message, this indicates a solicited
flush of the acknowledgements to all previous LDP messages
containing sequence numbers and issued by the sender of the
Keepalive on the same session.
FT Protection TLV Ifプレゼント、自由民主党メッセージにFT Sequence Numberを指定します。 Keepaliveメッセージに存在しているとき、これは同じセッションのときにKeepaliveの送付者によって一連番号を含んで、発行された前のすべての自由民主党メッセージに承認の請求された水洗を示します。
FT Cork TLV
Indicates that the remote LSR wishes to quiesce the LDP session.
See section 5, "FT Operations", for the recommended action in such
cases.
リモートLSRがquiesceへの自由民主党のセッションを願っているFT Cork TLV Indicates。 セクション5を見てください、「フィート、操作、」、そのような場合におけるお勧めの動作のために。
FT ACK TLV
If present, specifies the most recent FT message that the sending
LDP peer has been able to secure.
FT ACK TLV Ifは安全な状態で提示して、送付自由民主党の同輩ができているという最新のFTメッセージを指定します。
7.3. All Other LDP Session Messages
7.3. 他のすべての自由民主党セッションメッセージ
The LDP FT enhancements add the following optional parameters to all other message types that flow on an LDP session after the LDP Initialization message
LDP FT増進は自由民主党初期設定メッセージの後に自由民主党のセッションに流れる他のすべてのメッセージタイプに以下の任意のパラメタを追加します。
Optional Parameter Length Value
任意のパラメタ長さの価値
FT Protection TLV 4 See below
FT ACK TLV 4 See below
以下の保護TLV4が、フィートより下でACK TLV4が見るのを見るフィート
The encoding for these TLVs is found in section 8, "New Fields and Values".
これらのTLVsのためのコード化はセクション8と、「新しい分野と値」で見つけられます。
FT Protection TLV
If present, specifies the FT Sequence Number for the LDP message.
FT Protection TLV Ifプレゼント、自由民主党メッセージにFT Sequence Numberを指定します。
Farrel Standards Track [Page 25] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[25ページ]。
FT ACK TLV
If present, identifies the most recent FT LDP message ACKed by the
sending LDP peer.
FT ACK TLV Ifプレゼント、送付自由民主党の同輩は最新のFT LDPメッセージACKedを特定します。
8. New Fields and Values
8. 新しい分野と値
8.1. Status Codes
8.1. ステータスコード
The following new status codes are defined to indicate various conditions specific to the LDP FT enhancements. These status codes are carried in the Status TLV of a Notification message.
以下の新しいステータスコードは、LDP FT増進に特定の様々な状態を示すために定義されます。 これらのステータスコードはNotificationメッセージのStatus TLVで運ばれます。
The "E" column is the required setting of the Status Code E-bit; the "Status Data" column is the value of the 30-bit Status Data field in the Status Code TLV.
「E」コラムはステータスコード電子ビットの必要な設定です。 「状態データ」コラムはStatus Code TLVの30ビットのStatus Data分野の値です。
Note that the setting of the Status Code F-bit is at the discretion of the LSR originating the Status TLV. However, it is RECOMMENDED that the F-bit is not set on Notification messages containing status codes except 'No LDP Session' because the duplication of messages SHOULD be restricted to being a per-hop behavior.
Status TLVを溯源するLSRの裁量にはStatus Code F-ビットの設定があることに注意してください。 しかしながら、F-ビットが'自由民主党Sessionがありません'を除いて、ステータスコードを含むNotificationメッセージのあらゆるセットであることがRECOMMENDEDでない、複製、メッセージSHOULDでは、1ホップあたりのaの振舞いに制限されてください。
Status Code E Status Data
ステータスコードE状態データ
No LDP Session 0 0x0000001A
Zero FT seqnum 1 0x0000001B
Unexpected TLV / 1 0x0000001C
Session Not FT
Unexpected TLV / 1 0x0000001D
Label Not FT
Missing FT Protection TLV 1 0x0000001E
FT ACK sequence error 1 0x0000001F
Temporary Shutdown 0 0x00000020
いいえ自由民主党Session 0 0x0000001A Zero FT seqnum 1 0x0000001B Unexpected TLV/1 0x0000001C Session Not FT Unexpected TLV/1 0x0000001D Label Not FT Missing FT Protection TLV 1 0x0000001E FT ACK系列誤り1 0x0000001F Temporary Shutdown0 0x00000020
FT Seq Numbers Exhausted 1 0x00000021
FT Session parameters / 1 0x00000022
changed
Unexpected FT Cork TLV 1 0x00000023
FT Seq民数記Exhausted1 0×00000021FT Sessionパラメタ/1 0×00000022はUnexpected FT Cork TLV1 0×00000023を変えました。
The 'Temporary Shutdown' status code SHOULD be used in place of the 'Shutdown' status code (which has the E-bit set) if the LSR that is shutting down wishes to inform its LDP peer that it expects to be able to preserve FT Label state and return to service before the FT Reconnection Timer expires.
'一時的なShutdown'状態はSHOULDをコード化します。'閉鎖'ステータスコード(E-ビットを設定させる)に代わって、停止しているLSRが、FT Reconnection Timerが期限が切れる前に、FT Label状態を保持して、サービスに戻ることができると予想することを自由民主党の同輩に知らせたいなら、使用されてください。
Farrel Standards Track [Page 26] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[26ページ]。
8.2. FT Session TLV
8.2. フィートセッションTLV
LDP peers can negotiate whether the LDP session between them supports FT extensions by using a new OPTIONAL parameter, the FT Session TLV, on LDP Initialization Messages.
彼らの間の自由民主党のセッションが新しいOPTIONALパラメタを使用することによってFT拡張子をサポートするか否かに関係なく、自由民主党の同輩は交渉できます、FT Session TLV、自由民主党初期設定Messagesで。
The FT Session TLV is encoded as follows.
FT Session TLVは以下の通りコード化されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| FT Session TLV (0x0503) | Length (= 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Reconnect Timeout (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Recovery Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| フィートセッションTLV(0×0503)| 長さ(= 12)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィートは弛みます。| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FT Reconnect Timeout(ミリセカンドによる)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 回復Time(ミリセカンドによる)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Flags
FT Flags: A 16 bit field that indicates various attributes the FT
support on this LDP session. This field is formatted as follows:
旗のフィートが旗を揚げさせるフィート: FTがこの自由民主党のセッションのときに支持する様々な属性を示す16ビットの分野。 この分野は以下の通りフォーマットされます:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |S|A|C|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| 予約されます。|S|A|C|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: FT Reconnect Flag.
Set to 1 if the sending LSR has preserved state and resources for
all FT-labels since the previous LDP session between the same LDP
peers, and is otherwise set to 0. See section 5.4, "FT Procedures
After TCP Failure", for details of how this flag is used.
R: フィートは旗を再接続します。 発信しているLSRが同じ自由民主党の同輩の間の前の自由民主党のセッション以来すべてのFT-ラベルのための状態とリソースを保持していて、別の方法で0に用意ができているなら、1にセットしてください。 セクション5.4を見てください、「フィート、TCPの故障の後の手順、」、この旗がどう使用されているかに関する詳細のために。
If the FT Reconnect Flag is set, the sending LSR MUST include an
FT ACK TLV on the LDP Initialization message.
FT Reconnect Flagが用意ができているなら、発信しているLSR MUSTは自由民主党初期設定メッセージのFT ACK TLVを含んでいます。
S: Save State Flag.
Set to 1 if the use of the FT Protection TLV is supported on
messages other than the KeepAlive message used for check-pointing
(see the C bit). I.e., the S bit indicates that some label on the
session may be a Sequence Numbered FT Label.
S: 州旗を保存してください。 FT Protection TLVの使用がチェック指すのに使用されるKeepAliveメッセージ以外のメッセージで支持されるなら(Cビットを見てください)、1にセットしてください。 すなわち、Sビットは、セッションでの、あるラベルがSequence Numbered FT Labelであるかもしれないことを示します。
A: All-Label Protection Required
Set to 1 if all labels on the session MUST be treated as Sequence
Numbered FT Labels. This removes from a node the option of
A: セッションでのすべてのラベルであるなら1へのオールLabel Protection Required SetをSequence Numbered FT Labelsとして扱わなければなりません。 これはaノードからのオプションを取り除きます。
Farrel Standards Track [Page 27] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[27ページ]。
treating some labels as FT Labels and some labels as non-FT
Labels.
非FT LabelsとしてFT Labelsといくつかのラベルとしていくつかのラベルを扱います。
Passing this information may be considered helpful to a peer since
it may allow it to make optimizations in its processing.
それで処理における最適化をすることができるかもしれないので、この情報を通過するのは同輩にとって役立っていると考えられるかもしれません。
The A bit only has meaning if the S bit is set.
Aビットには、Sビットが設定される場合にだけ、意味があります。
C: Check-Pointing Flag.
Set to 1 to indicate that the check-Pointing procedures in this
document are in use.
C: チェックを指す旗。 1にセットして、チェックを指す手順が本書では使用中であることを示してください。
If the S bit is also set to 1 then the C bit indicates that
check-pointing is applied only to Sequence Numbered FT Labels.
また、Sビットが1に設定されるなら、Cビットは、チェック指すことがSequence Numbered FT Labelsだけに適用されるのを示します。
If the S bit is set to 0 (zero) then the C bit indicates that
check-pointing applies to all labels - all labels are Check-
Pointable FT Labels.
Sビットが0(ゼロ)に設定されるなら、Cビットは、チェック指すことがすべてのラベルに適用されるのを示します--すべてのラベルがCheck- Pointable FT Labelsです。
L: Learn From Network Flag.
Set to 1 if the Fault Recovery procedures of [RFC3478] are to be
used to re-learn state from the network.
L: ネットワーク旗から、学んでください。 [RFC3478]のFault Recovery手順がネットワークから状態を再学ぶのに使用されることであるなら1にセットしてください。
It is not valid for all of the S, C and L bits to be zero.
優にS、C、およびLビットがゼロであることは有効ではありません。
It is not valid for both the L and either the S or C bits to be
set to 1.
LとSかCビットのどちらかの両方が1に設定されるのは、有効ではありません。
All other bits in this field are currently reserved and SHOULD be
set to zero on transmission and ignored upon receipt.
この分野の他のすべてのビットが現在予約される、SHOULD、トランスミッションのゼロに設定されて、領収書で無視されます。
The following table summarizes the settings of these bits.
以下のテーブルはこれらのビットの設定をまとめます。
S A C L Comments
=========================
0 x 0 0 Invalid
0 0 0 1 See [RFC3478]
0 1 0 1 Invalid
0 x 1 0 Check-Pointing of all labels
0 x 1 1 Invalid
1 0 0 0 Full FT on selected labels
1 1 0 0 Full FT on all labels
1 x 0 1 Invalid
1 x 1 0 Same as (S=1,A=x,C=0,L=0)
1 x 1 1 Invalid.
C Lが論評するS========================= 選択されるところのすべてのラベル0x1 1を0x0 0の無効の0 0 0 1See[RFC3478]0 1 0 1Invalid0x1 0のCheck-指すInvalid1 0 0 0Full FTは(S=1、A=x、Cは0、L=0と等しいです)1x1 1Invalidとして1x0 1Invalid1x1 0Sameとすべてのラベルの上の1 1 0 0Full FTをラベルします。
Farrel Standards Track [Page 28] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[28ページ]。
FT Reconnection Timeout
If the S bit or C bit in the FT Flags field is set, this indicates
the period of time the sending LSR will preserve state and
resources for FT Labels exchanged on the previous instantiation of
an FT LDP session that has recently failed. The timeout is
encoded as a 32-bit unsigned integer number of milliseconds.
FT Flags分野で噛み付かれたFT Reconnection Timeout IfのSビットかCが設定されます、とこれは発信しているLSRが最近失敗したFT LDPセッションの前の具体化で交換されたFT Labelsのための状態とリソースを保持する期間に示します。 タイムアウトは32ビットの符号のない整数番号のミリセカンドとしてコード化されます。
A value of zero in this field means that the sending LSR will
preserve state and resources indefinitely.
この分野のゼロの値は、発信しているLSRが状態とリソースを無期限に保持することを意味します。
See section 4.4 for details of how this field is used.
この分野がどう使用されているかに関する詳細に関してセクション4.4を見てください。
If the L bit is set to 1 in the FT Flags field, the meaning of
this field is defined in [RFC3478].
LビットがFT Flags分野の1に設定されるなら、この分野の意味は[RFC3478]で定義されます。
Recovery Time
The Recovery Time only has meaning if the L bit is set in the FT
Flags. The meaning is defined in [RFC3478].
回復Time Recovery Timeには、LビットがFT Flagsに設定される場合にだけ、意味があります。 意味は[RFC3478]で定義されます。
8.3. FT Protection TLV
8.3. フィート保護TLV
LDP peers use the FT Protection TLV to indicate that an LDP message contains an FT label operation.
自由民主党の同輩は、自由民主党メッセージがFTラベル操作を含むのを示すのにFT Protection TLVを使用します。
The FT Protection TLV MUST NOT be used in messages flowing on an LDP session that does not support the LDP FT enhancements. Its presence in such messages SHALL be treated as a protocol error by the receiving LDP peer which SHOULD send a Notification message with the 'Unexpected TLV Session Not FT' status code. LSRs that do not recognize this TLV SHOULD respond with a Notification message with the 'Unknown TLV' status code.
LDP FT増進を支持しない自由民主党のセッションに流れながら、メッセージでFT Protection TLVを使用してはいけません。 そのようなものでの存在は'予期していなかったTLV Session Not FT'ステータスコードで受信自由民主党の同輩によるSHOULDがNotificationメッセージを送るプロトコル誤りとして扱われた状態でSHALLを通信させます。 このTLV SHOULDを認識しないLSRsが'未知のTLV'ステータスコードがあるNotificationメッセージで応じます。
The FT Protection TLV MAY be carried on an LDP message transported on the LDP session after the initial exchange of LDP Initialization messages. In particular, this TLV MAY optionally be present on the following messages:
FT Protection TLVは自由民主党初期設定メッセージの初期の交換の後に自由民主党のセッションのときに輸送された自由民主党メッセージで運ばれるかもしれません。 特にこのTLV MAY、以下のメッセージに任意に存在してください:
- Label Request Messages in downstream on-demand distribution mode.
- 川下の要求次第の分配におけるRequest Messagesをモードとラベルしてください。
- Label Mapping messages in downstream unsolicited mode.
- 川下の求められていないモードによるMappingメッセージをラベルしてください。
- Keepalive messages used to request flushing of acknowledgement of
all previous messages that contained this TLV.
- Keepaliveメッセージは以前はよくこのTLVを含んだ前のすべてのメッセージの承認を洗い流すことを要求していました。
Farrel Standards Track [Page 29] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[29ページ]。
If a label is to be a Sequence Numbered FT Label, then the Protection TLV MUST be present:
ラベルによるSequence Numbered FT Labelであるつもりであるなら、Protection TLVは存在していなければなりません:
- on the Label Request message in downstream on-demand distribution
mode.
- 川下の要求次第の分配モードによるLabel Requestメッセージに関して。
- on the Label Mapping message in in downstream unsolicited
distribution mode.
- Label Mappingでは、中で川下の求められていない分配モードで通信してください。
- on all subsequent messages concerning this label.
- このラベルに関するすべてのその後のメッセージに関して。
Here 'subsequent messages concerning this label' means any message whose Label TLV specifies this label or whose Label Request Message ID TLV specifies the initial Label Request message.
ここで、'このラベルに関するその後のメッセージ'はLabel TLVがこのラベルを指定するか、またはLabel Request Message ID TLVが初期のLabel Requestメッセージを指定するどんなメッセージも意味します。
If a label is not to be a Sequence Numbered FT Label, then the Protection TLV MUST NOT be present on any of these messages that relate to the label. The presence of the FT TLV on a message relating to a non-FT Label SHALL be treated as a protocol error by the receiving LDP peer which SHOULD send a notification message with the 'Unexpected TLV Label Not FT' status code.
ラベルによるSequence Numbered FT Labelでないつもりであるなら、Protection TLVはラベルに関連するこれらのメッセージのいずれにも存在しているはずがありません。 SHOULDが'予期していなかったTLV Label Not FT'ステータスコードがある通知メッセージを送る受信によるプロトコル誤りとして扱われた非FT Label SHALL自由民主党の同輩に関連するメッセージのFT TLVの存在。
Where a Label Withdraw or Label Release message contains only an FEC TLV and does not identify a single specific label, the FT TLV should be included in the message if any label affected by the message is a Sequence Numbered FT Label. If there is any doubt as to whether an FT TLV should be present, it is RECOMMENDED that the sender add the TLV.
Label WithdrawかLabel ReleaseメッセージがFEC TLVだけを含んでいて、単一の特定のラベルを特定しないところでは、FT TLVはメッセージで影響を受けるどれかラベルがSequence Numbered FT Labelであるならメッセージに含まれるべきです。 FT TLVが存在しているべきであるかどうかに関して何か疑問があれば、送付者がTLVを加えるのは、RECOMMENDEDです。
When an LDP peer receives a Label Withdraw Message or Label Release message that contains only a FEC, it SHALL accept the FT TLV if it is present regardless of the FT status of the labels that it affects.
自由民主党がいつじっと見るかがFECだけを含むLabel Withdraw MessageかLabel Releaseメッセージを受け取って、それはSHALLです。それがそれが影響するラベルのFT状態にかかわらず存在しているなら、FT TLVを受け入れてください。
If an LDP session is an FT session as determined by the presence of the FT Session TLV, with the S bit set on the LDP Initialization messages, the FT Protection TLV MUST be present on all Address messages on the session.
自由民主党初期設定メッセージに設定されたSビットでFT Session TLVの存在によって決定されるように自由民主党のセッションがFTセッションであるなら、FT Protection TLVはセッションに関するすべてのAddressメッセージに存在していなければなりません。
If the session is an FT session, the FT Protection TLV may also optionally be present:
また、セッションがFTセッションであるなら、FT Protection TLVも任意に存在しているかもしれません:
- on Notification messages on the session that have the status code
'Label Resources Available'.
- Notificationでは、ステータスコードを持っているセッションに関するメッセージが'Resources Availableをラベルします'。
- on Keepalive messages.
- Keepaliveメッセージに関して。
Farrel Standards Track [Page 30] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[30ページ]。
The FT Protection TLV is encoded as follows.
FT Protection TLVは以下の通りコード化されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Protection (0x0203) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| フィート、保護(0×0203)| 長さ(= 4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィート、一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT Sequence Number
The sequence number for this Sequence Numbered FT Label operation.
The sequence number is encoded as a 32-bit unsigned integer. The
initial value for this field on a new LDP session is 0x00000001
and is incremented by one for each FT LDP message issued by the
sending LSR on this LDP session. This field may wrap from
0xFFFFFFFF to 0x00000001.
FT Sequence Number、このSequence Numbered FT Label操作のための一連番号。 一連番号は32ビットの符号のない整数としてコード化されます。 新しい自由民主党のセッションのこの分野への初期の値は、0×00000001であり、この自由民主党のセッションのときに発信しているLSRによって発行されたそれぞれのFT LDPメッセージあたり1つ増加されます。 この分野は0xFFFFFFFFから0×00000001に包装されるかもしれません。
This field MUST be reset to 0x00000001 if either LDP peer does not
set the FT Reconnect Flag upon re-establishment of the TCP
connection.
どちらの自由民主党の同輩もTCP接続の再建へFT Reconnect Flagを上に置かないなら、この分野を0×00000001にリセットしなければなりません。
See section 5.2, "FT Operation Acks" for details of how this field
is used.
この分野がどう使用されているかに関する詳細に関してセクション5.2、「フィート操作Acks」を見てください。
The special use of 0x00000000 is discussed in the section 8.4, "FT
ACK TLV" below.
以下でセクション8.4、「フィートACK TLV」で0×00000000の特別な使用について議論します。
If an LSR receives an FT Protection TLV on a session that does not support the FT LDP enhancements, it SHOULD send a Notification message to its LDP peer containing the 'Unexpected TLV, Session Not FT' status code. LSRs that do not recognize this TLV SHOULD respond with a Notification message with the 'Unknown TLV' status code.
LSRがそうしないセッションにFT Protection TLVを受けるなら、FT LDP増進を支持してください、それ。'予期していなかったTLV、Session Not FT'ステータスコードを含んでいて、SHOULDはNotificationメッセージを自由民主党の同輩に送ります。 このTLV SHOULDを認識しないLSRsが'未知のTLV'ステータスコードがあるNotificationメッセージで応じます。
If an LSR receives an FT Protection TLV on an operation affecting a label that it believes is a non-FT Label, it SHOULD send a Notification message to its LDP peer containing the 'Unexpected TLV, Label Not FT' status code.
LSRがFT Protection TLVを操作に受けるなら、それが信じているラベルに影響するのは、非FT Labelです、それ。'予期していなかったTLV、Label Not FT'ステータスコードを含んでいて、SHOULDはNotificationメッセージを自由民主党の同輩に送ります。
If an LSR receives a message without the FT Protection TLV affecting a label that it believes is a Sequence Numbered FT Label, it SHOULD send a Notification message to its LDP peer containing the 'Missing FT Protection TLV' status code.
LSRが受信するなら、信じているというFT Protection TLVがラベルに影響することのないメッセージはSequence Numbered FT Labelです、それ。'なくなったFT Protection TLV'ステータスコードを含んでいて、SHOULDはNotificationメッセージを自由民主党の同輩に送ります。
If an LSR receives an FT Protection TLV containing a zero FT Sequence Number, it SHOULD send a Notification message to its LDP peer containing the 'Zero FT Seqnum' status code.
LSRがaを含むFT Protection TLVを受けるなら、FT Sequence Numberのゼロを合わせてください、それ。'FT Seqnumがありません'ステータスコードを含んでいて、SHOULDはNotificationメッセージを自由民主党の同輩に送ります。
Farrel Standards Track [Page 31] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[31ページ]。
8.4. FT ACK TLV
8.4. フィートACK TLV
LDP peers use the FT ACK TLV to acknowledge FT Label operations.
自由民主党の同輩は、FT Label操作を承諾するのにFT ACK TLVを使用します。
The FT ACK TLV MUST NOT be used in messages flowing on an LDP session that does not support the LDP FT enhancements. Its presence on such messages SHALL be treated as a protocol error by the receiving LDP peer.
FT ACK TLV MUST NOT、LDP FT増進を支持しない自由民主党のセッションに流れながら、メッセージで使用されてください。 受信自由民主党の同輩によってプロトコル誤りとして扱われた状態で、そのようなものでの存在はSHALLを通信させます。
The FT ACK TLV MAY be present on any LDP message exchanged on an LDP session after the initial LDP Initialization messages. It is RECOMMENDED that the FT ACK TLV be included in all FT Keepalive messages in order to ensure that the LDP peers do not build up a large backlog of unacknowledged state information.
FT ACK TLV MAY、初期の自由民主党初期設定メッセージの後に自由民主党のセッションのときに交換されたあらゆる自由民主党メッセージに存在してください。 FT ACK TLVが自由民主党の同輩が不承認の州の情報の大きい予備を確立しないのを確実にするためにすべてのFT Keepaliveメッセージに含まれているのは、RECOMMENDEDです。
The FT ACK TLV is encoded as follows.
FT ACK TLVは以下の通りコード化されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT ACK (0x0504) | Length (= 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FT ACK Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| フィートACK(0×0504)| 長さ(= 4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フィート、ACK一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FT ACK Sequence Number
The sequence number for the most recent FT label message that the
sending LDP peer has received from the receiving LDP peer and
secured against failure of the LDP session. It is not necessary
for the sending peer to have fully processed the message before
ACKing it. For example, an LSR MAY ACK a Label Request message as
soon as it has securely recorded the message, without waiting
until it can send the Label Mapping message in response.
FT ACK Sequence Number、送付自由民主党の同輩が受信自由民主党の同輩から受け取って、自由民主党のセッションの失敗に対して保証した最新のFTラベルメッセージのための一連番号。 送付同輩がACKingの前でメッセージを完全に処理したのは必要ではありません。それ。 例えば、それの次第LSR MAY ACK a Label Requestメッセージはしっかりとメッセージを記録しました、応答におけるLabel Mappingメッセージを送ることができるまで待たないで。
ACKs are cumulative. Receipt of an LDP message containing an FT
ACK TLV with an FT ACK Sequence Number of 12 is treated as the
acknowledgement of all messages from 1 to 12 inclusive (assuming
the LDP session started with a sequence number of 1).
ACKsは累積しています。 12のFT ACK Sequence NumberとFT ACK TLVを含む自由民主党メッセージの領収書はすべてのメッセージの1〜12までの承認として包括的に扱われます(自由民主党のセッションを仮定すると、1の一連番号始まられました)。
This field MUST be set to 0 if the LSR sending the FT ACK TLV has
not received any FT label operations on this LDP session. This
applies to LDP sessions, to new LDP peers or after an LSR
determines that it must drop all state for a failed TCP
connection.
FT ACK TLVを送るLSRがこの自由民主党のセッションのときにまだFTラベル操作を受けていないなら、この分野を0に設定しなければなりません。 新しい自由民主党の同輩への自由民主党のセッションかLSRが、失敗したTCP接続のためにすべての状態を落とさなければならないことを決定した後にこれは適用されます。
See section 5.2, "FT Operation Acks" for details of how this field
is used.
この分野がどう使用されているかに関する詳細に関してセクション5.2、「フィート操作Acks」を見てください。
Farrel Standards Track [Page 32] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[32ページ]。
If an LSR receives an FT ACK TLV that contains an FT ACK Sequence Number that is less than the previously received FT ACK Sequence Number (remembering to take account of wrapping), it SHOULD send a Notification message to its LDP peer containing the 'FT ACK Sequence Error' status code.
LSRがFT ACK Sequence Numberを含むFT ACK TLVを受けるなら、それは以前に容認されたFT ACK Sequence Numberより少ないです(忘れずにラッピングを考慮に入れて)、それ。'FT ACK Sequence Error'ステータスコードを含んでいて、SHOULDはNotificationメッセージを自由民主党の同輩に送ります。
8.5. FT Cork TLV
8.5. フィートコルクTLV
LDP peers use the FT Cork TLV on FT Keepalive messages to indicate that they wish to quiesce the LDP session prior to a controlled shutdown and restart, for example during control-plane software upgrade.
自由民主党の同輩は制御閉鎖の前にquiesceに自由民主党のセッションを願って、再開するのを示すFT KeepaliveメッセージでFT Cork TLVを使用します、例えば、制御飛行機ソフトウェアの更新の間。
The FT Cork TLV is encoded as follows.
FT Cork TLVは以下の通りコード化されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| FT Cork (0x0505) | Length (= 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| フィートは(0×0505)の栓をします。| 長さ(= 0)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upon receipt of a Keepalive message with the FT Cork TLV and the FT Protection TLV, an LSR SHOULD perform the following actions:
FT Cork TLVがあるKeepaliveメッセージとFT Protection TLV、LSR SHOULDを受け取り次第、以下の動作を実行してください:
- Process and secure any messages from the peer LSR that have
sequence numbers less than (accounting for wrap) that contained in
the FT Protection TLV on the Keepalive message.
- FT Protection TLVに含まれた(包装のための会計)それほどKeepaliveメッセージに一連番号を持っていない同輩LSRからあらゆるメッセージを処理して、保証してください。
- Send a Keepalive message back to the peer containing the FT Cork
TLV and the FT ACK TLV specifying the FT ACK sequence number
equal to that in the original Keepalive message (i.e. ACKing all
messages up to that point).
- オリジナルのKeepaliveメッセージ(すなわち、それまでのすべてのメッセージが指すACKing)においてそれと等しいFT ACK一連番号を指定するFT Cork TLVとFT ACK TLVを含む同輩にKeepaliveメッセージを送り返してください。
- If this LSR has not yet received an FT ACK to all the messages it
has sent containing the FT Protection TLV, then also include an FT
Protection TLV on the Keepalive sent to the peer LSR. This tells
the remote peer that the local LSR has saved state prior to
quiesce but is still awaiting confirmation that the remote peer
has saved state.
- また、FT Protection TLVを含んでいて、このLSRがまだそれが送ったすべてのメッセージにFT ACKを受けていないなら、同輩LSRに送られたKeepaliveの上のFT Protection TLVを含めてください。 これは、地方のLSRがquiesceの前で状態を節約しましたが、まだ、リモート同輩が救った確認を待っているのが、状態であるとリモート同輩に言います。
- Cease sending any further state changing messages on this LDP
session until it has been disconnected and recovered.
- それが外されて、回復されるまで州にメッセージをこの自由民主党のセッションにこれ以上変えさせるのをやめてください。
On receipt of a Keepalive message with the FT Cork TLV and an FT ACK TLV that acknowledges the previously sent Keepalive that carried the FT Cork TLV, an LSR knows that quiesce is complete. If the received Keepalive also carries the FT Protection TLV, the LSR must respond with a further Keepalive to complete the 3-way handshake. It SHOULD
FT Cork TLVとFT Cork TLVを運んだ以前に送られたKeepaliveを承認するFT ACK TLVがあるKeepaliveメッセージを受け取り次第、LSRは、quiesceが完全であることを知っています。 また、容認されたKeepaliveがFT Protection TLVを運ぶなら、LSRは、3ウェイ握手を終了するために一層のKeepaliveと共に応じなければなりません。 それはそうするべきです。
Farrel Standards Track [Page 33] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[33ページ]。
now send a "Temporary Shutdown" Notification message, disconnect the TCP session and perform whatever control plane actions required this session shutdown.
今、「一時的な閉鎖」Notificationメッセージを送ってください、そして、TCPセッションを外してください、そして、このセッション閉鎖を必要としたどんなコントロール飛行機動作も実行してください。
An example of such a 3-way handshake for controlled shutdown is given in section section 9.4, "Temporary Shutdown With FT Procedures and Check-Pointing".
制御閉鎖のためのそのような3ウェイ握手に関する例がセクション部分9.4で出される、「フィートとの一時的な閉鎖、手順とチェック指す、」
If an LSR receives a message that should not carry the FT Cork TLV, or if the FT Cork TLV is used on a Keepalive message without one of the FT Protection or FT ACK TLVs present, it SHOULD send a Notification message to its LDP peer containing the 'Unexpected FT Cork TLV' status code.
LSRはFT Cork TLVを運ぶべきでないメッセージ、FT Cork TLVがKeepaliveメッセージでFT Protectionの1つなしで使用されるか、そして、またはFT ACK TLVsプレゼントを受け取ります、それ。'予期していなかったFT Cork TLV'ステータスコードを含んでいて、SHOULDはNotificationメッセージを自由民主党の同輩に送ります。
9. Example Use
9. 例の使用
Consider two LDP peers, P1 and P2, implementing LDP over a TCP connection that connects them, and the message flow shown below.
2人の自由民主党の同輩、P1、およびP2を考えてください、彼らを接続するTCP接続、および以下で見せられたメッセージ流動の上で自由民主党を実行して。
The parameters shown on each message below are as follows:
以下の各メッセージに示されたパラメタは以下の通りです:
message (label, senders FT sequence number, FT ACK number)
メッセージ(ラベル、送付者FT一連番号、FT ACK番号)
A "-" for FT ACK number means that the FT ACK TLV is not included
on that message. "n/a" means that the parameter in question is
not applicable to that type of message.
フィート「-」ACK番号は、フィートACK TLVがそのメッセージに含まれていないことを意味します。 「なし」は、問題のパラメタがそのタイプに関するメッセージに適切でないことを意味します。
In the diagrams below, time flows from top to bottom. The relative position of each message shows when it is transmitted. See the notes for a description of when each message is received, secured for FT or processed.
以下のダイヤグラムで、時間は上から下まで流れます。 それぞれのメッセージの相対的な位置は、それがいつ伝えられるかを示します。 各メッセージを受け取るか、FTに保証するか、または処理する時に関する記述のための注意を見てください。
9.1. Session Failure and Recovery - FT Procedures
9.1. セッション失敗と回復--、フィート、手順
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
P1 P2に注意します。===== == == (1) ラベル要求、(L1、27、-、)--------------------------->ラベル要求、(L2、28、-、)--------------------------->(2)ラベル要求(L3、93、27)<。--------------------------- (3) ラベル要求、(L1,123、-、)-------------------------->ラベル要求、(L2,124、-、)-------------------------->。
Farrel Standards Track [Page 34] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[34ページ]。
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,-,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
(10) ===== TCP Session lost =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
(12) === TCP Session restored ===
(4)ラベルマッピング、(L1、57、-、)、<。-------------------------- ラベルマッピング(L1、94、28)<。--------------------------- (5) ラベルマッピング、(L2、58、-、)、<。-------------------------- ラベルマッピング、(L2、95、-、)、<。--------------------------- (6) アドレス、(なし、29、-、)--------------------------->(7)ラベル要求、(L4、30、-、)--------------------------->(8)Keepalive、(なし、-、94)--------------------------->(9)ラベルアボート、(L3、96、-、)、<。--------------------------- (10) ===== TCP Sessionは損をしました。===== : (11) : ラベルが引き下がる、(L1、59、-、)、: <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- : (12) === 返されたTCP Session===
LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
自由民主党イニット(なし、なし、94)--------------------------->自由民主党イニット(なし、なし、29)<。--------------------------- (13) ラベル要求、(L4、30、-、)--------------------------->(14)ラベルマッピング、(L2、95、-、)、<。--------------------------- ラベルアボート(L3、96、30)<。--------------------------- (15) ラベルが引き下がる、(L1、97、-、)、<。---------------------------
Notes: ======
注意: ======
(1) Assume that the LDP session has already been initialized. P1
issues 2 new Label Requests using the next sequence numbers.
(1) 自由民主党のセッションが既に初期化されたと仮定してください。 P1は、次の一連番号を使用することで2新しいLabel Requestsを発行します。
(2) P2 issues a Label Request to P1. At the time of sending this
request, P2 has secured the receipt of the label request for L1
from P1, so it includes an ACK for that message.
(2) P2はP1にLabel Requestを発行します。 この要求を送る時点でP2がP1からL1を求めるラベル要求の領収書を固定したので、それはそのメッセージのためのACKを含んでいます。
Farrel Standards Track [Page 35] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[35ページ]。
(3) P2 processes the Label Requests for L1 and L2 and forwards them
downstream. Details of downstream processing are not shown in
the diagram above.
(3) P2はL1とL2のためにLabel Requestsを処理して、彼らを川下に送ります。 川下の処理の詳細は上のダイヤグラムで示されません。
(4) P2 receives a Label Mapping from downstream for L1, which it
forwards to P1. It includes an ACK to the Label Request for L2,
as that message has now been secured and processed.
(4) P2はL1のために川下からLabel Mappingを受けます。(それはL1をP1に送ります)。 今そのメッセージを保証されて、処理してあるとき、それはL2のためのLabel RequestにACKを含めます。
(5) P2 receives the Label Mapping for L2, which it forwards to P1.
This time it does not include an ACK as it has not received any
further messages from P1.
(5) P2はL2のためにLabel Mappingを受けます。(それはL2をP1に送ります)。 今回、P1からさらなるメッセージをまだ受け取っていないとき、それはACKを含んでいません。
(6) Meanwhile, P1 sends a new Address Message to P2.
(6) その間、P1は新しいAddress MessageをP2に送ります。
(7) P1 also sends a fourth Label Request to P2
(7) また、P1は第4のLabel RequestをP2に送ります。
(8) P1 sends a Keepalive message to P2, on which it includes an ACK
for the Label Mapping for L1, which is the latest message P1 has
received and secured at the time the Keepalive is sent.
(8) P1はKeepaliveメッセージをP2に送ります。そこでは、それがKeepaliveを送るときP1が受け取って、保証した最新のメッセージであるL1のためのLabel MappingのためのACKを含んでいます。
(9) P2 issues a Label Abort for L3.
(9) P2はL3のためにLabel Abortを発行します。
(10) At this point, the TCP session goes down.
(10) ここに、TCPセッションは落ちます。
(11) While the TCP session is down, P2 receives a Label Withdraw
Message for L1, which it queues.
(11) TCPセッションは下がっていますが、P2はL1のためにLabel Withdraw Messageを受けます。(それはL1を列に並ばせます)。
(12) The TCP session is reconnected and P1 and P2 exchange LDP
Initialization messages on the recovered session, which include
ACKS for the last message each peer received and secured prior
to the failure.
(12) TCPセッションは再接続されます、そして、P1とP2は回復しているセッションに関する自由民主党初期設定メッセージを交換します。(メッセージは各同輩が失敗の前に受け取って、保証した最後のメッセージのためのACKSを含んでいます)。
(13) From the LDP Init exchange, P1 determines that it needs to re-
issue the Label request for L4.
(13) 自由民主党のInit交換から、P1は、L4を求めるLabel要求を再出すのが必要であることを決定します。
(14) Similarly, P2 determines that it needs to re-issue the Label
Mapping for L2 and the Label Abort.
(14) 同様に、P2は、L2とLabel AbortのためにLabel Mappingを再発行するのが必要であることを決定します。
(15) P2 issues the queued Label Withdraw to P1.
(15) P2は列に並ばせられたLabel WithdrawをP1に発行します。
Farrel Standards Track [Page 36] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[36ページ]。
9.2. Use of Check-Pointing With FT Procedures
9.2. フィートとのチェック指す手順の使用
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,-)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,31,-)
--------------------------->
(9) Keepalive(n/a,-,31)
<---------------------------
(10) Keepalive(n/a,59,124)
<---------------------------
(11) Keepalive(n/a,-,59)
--------------------------->
Notes:
======
P1 P2に注意します。===== == == (1) ラベル要求、(L1、27、-、)--------------------------->ラベル要求、(L2、28、-、)--------------------------->(2)ラベル要求、(L3、93、-、)、<。--------------------------- (3) ラベル要求、(L1,123、-、)-------------------------->ラベル要求、(L2,124、-、)-------------------------->(4)ラベルマッピング、(L1、57、-、)、<。-------------------------- ラベルマッピング、(L1、94、-、)、<。--------------------------- (5) ラベルマッピング、(L2、58、-、)、<。-------------------------- ラベルマッピング、(L2、95、-、)、<。--------------------------- (6) アドレス、(なし、29、-、)--------------------------->(7)ラベル要求、(L4、30、-、)--------------------------->(8)Keepalive、(なし、31、-、)--------------------------->(9)Keepalive、(なし、-、31)<。--------------------------- (10) Keepalive(なし、5万9124)<。--------------------------- (11) Keepalive、(なし、-、59)--------------------------->注意: ======
Notes (1) through (7) are as in the previous example except note that no acknowledgements are piggy-backed on reverse direction messages. This means that at note (8) there are deferred acknowledgements in both directions on both links.
承認が逆の指示メッセージでいいえというメモ以外の前の例で背負われるように注意(1)から(7)があります。 これは、注意(8)には、両方のリンクに関する両方の方向には延期された承認があることを意味します。
(8) P1 wishes to synchronize state with P2. It sends a Keepalive
message containing an FT Protection TLV with sequence number 31.
Since it is not interested in P2's perception of the state that
it has stored, it does not include an FT ACK TLV.
(8) P1は状態をP2と同期させたがっています。 それは一連番号31と共にFT Protection TLVを含むKeepaliveメッセージを送ります。 P2のそれが格納した状態の認知に興味を持っていないので、それはFT ACK TLVを含んでいません。
Farrel Standards Track [Page 37] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[37ページ]。
(9) P2 responds at once with a Keepalive acknowledging the sequence
number on the received Keepalive. This tells P1 that P2 has
preserved all state/messages previously received on this
session.
(9) Keepaliveが容認されたKeepaliveで一連番号を承認していて、P2はすぐに、応じます。 これは、P2がこのセッションのときに以前に受け取られたすべての状態/メッセージを保存したとP1に言います。
(10) The downstream node wishes to synchronize state with P2. It
sends a Keepalive message containing an FT Protection TLV with
sequence number 59. P3 also takes this opportunity to get up to
date with its acknowledgements to P2 by including an FT ACK TLV
acknowledging up to sequence number 124.
(10) 川下のノードは状態をP2と同期させたがっています。 それは一連番号59と共にFT Protection TLVを含むKeepaliveメッセージを送ります。 また、P3は承認で一連番号124まで承認するFT ACK TLVを含んでいることによってP2に新しくするこの機会を取ります。
(11) P2 responds at once with a Keepalive acknowledging the sequence
number on the received Keepalive.
(11) Keepaliveが容認されたKeepaliveで一連番号を承認していて、P2はすぐに、応じます。
9.3. Temporary Shutdown With FT Procedures
9.3. フィートとの一時的な閉鎖、手順
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,27)
<---------------------------
(3) Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
(4) Label Mapping(L1,57,-)
<--------------------------
Label Mapping(L1,94,28)
<---------------------------
(5) Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(6) Address(n/a,29,-)
--------------------------->
(7) Label Request(L4,30,-)
--------------------------->
(8) Keepalive(n/a,-,94)
--------------------------->
(9) Label Abort(L3,96,-)
<---------------------------
P1 P2に注意します。===== == == (1) ラベル要求、(L1、27、-、)--------------------------->ラベル要求、(L2、28、-、)--------------------------->(2)ラベル要求(L3、93、27)<。--------------------------- (3) ラベル要求、(L1,123、-、)-------------------------->ラベル要求、(L2,124、-、)-------------------------->(4)ラベルマッピング、(L1、57、-、)、<。-------------------------- ラベルマッピング(L1、94、28)<。--------------------------- (5) ラベルマッピング、(L2、58、-、)、<。-------------------------- ラベルマッピング、(L2、95、-、)、<。--------------------------- (6) アドレス、(なし、29、-、)--------------------------->(7)ラベル要求、(L4、30、-、)--------------------------->(8)Keepalive、(なし、-、94)--------------------------->(9)ラベルアボート、(L3、96、-、)、<。---------------------------
Farrel Standards Track [Page 38] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[38ページ]。
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(12) LDP Init(n/a,n/a,94)
--------------------------->
LDP Init(n/a,n/a,29)
<---------------------------
(13) Label Request(L4,30,-)
--------------------------->
(14) Label Mapping(L2,95,-)
<---------------------------
Label Abort(L3,96,30)
<---------------------------
(15) Label Withdraw(L1,97,-)
<---------------------------
(10) 通知(一時的な閉鎖)--------------------------->=== TCP Session閉鎖===== : (11) : ラベルが引き下がる、(L1、59、-、)、: <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- : ===== 返されたTCP Session===== (12) 自由民主党イニット(なし、なし、94)--------------------------->自由民主党イニット(なし、なし、29)<。--------------------------- (13) ラベル要求、(L4、30、-、)--------------------------->(14)ラベルマッピング、(L2、95、-、)、<。--------------------------- ラベルアボート(L3、96、30)<。--------------------------- (15) ラベルが引き下がる、(L1、97、-、)、<。---------------------------
Notes: ======
注意: ======
Notes are as in the previous example except as follows.
同じくらい中に注意が以下の通りであります。
(10) P1 needs to upgrade the software or hardware that it is running.
It issues a Notification message to terminate the LDP session,
but sets the status code as 'Temporary shutdown' to inform P2
that this is not a fatal error, and P2 should maintain FT state.
The TCP connection may also fail during the period that the LDP
session is down (in which case it will need to be re-
established), but it is also possible that the TCP connection
will be preserved.
(10) P1は、それが動かしているソフトウェアかハードウェアをアップグレードさせる必要があります。 それは、自由民主党のセッションを終えるNotificationメッセージを発行しますが、'一時的な閉鎖'としてのステータスコードにこれが致命的な誤りでなく、P2がFT状態を維持するはずであることをP2に知らせるように設定します。 また、TCP接続は自由民主党のセッションが下がっていることの(その場合、それは、再設立される必要があるでしょう)期間失敗するかもしれませんが、また、TCP接続が保存されるのも、可能です。
Farrel Standards Track [Page 39] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[39ページ]。
9.4. Temporary Shutdown With FT Procedures and Check-Pointing
9.4. フィートとの一時的な閉鎖、手順とチェック指すこと。
notes P1 P2
===== == ==
(1) Label Request(L1,27,-)
--------------------------->
Label Request(L2,28,-)
--------------------------->
(2) Label Request(L3,93,-)
<---------------------------
Label Request(L1,123,-)
-------------------------->
Label Request(L2,124,-)
-------------------------->
Label Mapping(L1,57,-)
<--------------------------
(3) Label Mapping(L1,94,-)
<---------------------------
Label Mapping(L2,58,-)
<--------------------------
Label Mapping(L2,95,-)
<---------------------------
(4) Address(n/a,29,-)
--------------------------->
(5) Label Request(L4,30,-)
--------------------------->
(6) Keepalive(n/a,31,95) * with FT Cork TLV *
--------------------------->
(7) Label Abort(L3,96,-)
<---------------------------
(8) Keepalive(n/a,97,31) * with FT Cork TLV *
<---------------------------
(9) Keepalive(n/a,-,97) * with FT Cork TLV *
--------------------------->
(10) Notification(Temporary shutdown)
--------------------------->
===== TCP Session shutdown =====
:
: Label Withdraw(L1,59,-)
: <--------------------------
:
===== TCP Session restored =====
(11) LDP Init(n/a,n/a,96)
--------------------------->
LDP Init(n/a,n/a,31)
<---------------------------
Label Withdraw(L1,97,-)
<---------------------------
P1 P2に注意します。===== == == (1) ラベル要求、(L1、27、-、)--------------------------->ラベル要求、(L2、28、-、)--------------------------->(2)ラベル要求、(L3、93、-、)、<。--------------------------- ラベル要求、(L1,123、-、)-------------------------->ラベル要求、(L2,124、-、)-------------------------->ラベルマッピング、(L1、57、-、)、<。-------------------------- (3) ラベルマッピング、(L1、94、-、)、<。--------------------------- ラベルマッピング、(L2、58、-、)、<。-------------------------- ラベルマッピング、(L2、95、-、)、<。--------------------------- (4) アドレス、(なし、29、-、)--------------------------->(5)ラベル要求、(L4、30、-、)---------------------------フィートコルクTLV*がある>(6)Keepalive(なし、31、95)*--------------------------->(7)ラベルアボート、(L3、96、-、)、<。--------------------------- (8) フィートコルクTLV*<があるKeepalive(なし、97、31)*--------------------------- (9) Keepalive、(なし、-フィートがある97)*はTLV*の栓をします。--------------------------->(10)通知(一時的な閉鎖)--------------------------->=== TCP Session閉鎖===== : : ラベルが引き下がる、(L1、59、-、)、: <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- : ===== 返されたTCP Session===== (11) 自由民主党イニット(なし、なし、96)--------------------------->自由民主党イニット(なし、なし、31)<。--------------------------- ラベルが引き下がる、(L1、97、-、)、<。---------------------------
Farrel Standards Track [Page 40] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[40ページ]。
Notes: ======
注意: ======
This example operates much as the previous one. However, at (1), (2), (3), (4) and (5), no acknowledgements are made.
この例は前のものとして非常に作動します。 しかしながら、(1)、(2)、(3)、(4)、および(5)では、承認を全くしません。
At (6), P1 determines that graceful shutdown is required and sends a Keepalive acknowledging all previously received messages and itself containing an FT Protection TLV number and the FT Cork TLV.
(6)では、FT Protection TLV番号とFT Cork TLVを含んでいて、P1は優雅な閉鎖が必要であることを決定して、Keepaliveにすべてが以前にメッセージとそれ自体を受け取ったと認めさせます。
The Label abort at (7) crosses with this Keepalive, so at (8) P2 sends a Keepalive that acknowledges all messages received so far, but also includes the FT Protection and FT Cork TLVs to indicate that there are still messages outstanding to be acknowledged.
(7)でのLabelアボートは、P2が(8)で今までのところ受け取られているすべてのメッセージを承認するKeepaliveを送って、このKeepaliveを交配しますが、承認されているためには未払いのメッセージがまだあるのを示すためにFT ProtectionとFT Cork TLVsをまた含んでいます。
P1 is then able to complete the 3-way handshake at (9) and close the TCP session at (10).
P1は(9)で3ウェイ握手を終了して、その時、(10)でTCPセッションを終えることができます。
Upon recovery at (11), there are no messages to be re-sent because the KeepAlives flushed the acknowledgements. The only messages sent after recovery is the Label Withdraw that was pended during the TCP session failure.
(11)での回復には、KeepAlivesが承認を洗い流したので再送されるべきメッセージが全くありません。 回復がLabel WithdrawにTCPセッションの故障の間にpendedされたなった後に唯一のメッセージが発信しました。
Farrel Standards Track [Page 41] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[41ページ]。
9.5. Check-Pointing Without FT Procedures
9.5. フィートのないチェック指す手順
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,-)
--------------------------->
(5) Label Request(L3)
--------------------------->
(6) Keepalive(n/a,-,12)
<---------------------------
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(7) Label Mapping(L3)
<---------------------------
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(8) LDP Init(n/a,n/a,23)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(9) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(10) Label Mapping(L3)
<---------------------------
(11) Label Request(L2)
<---------------------------
P1 P2に注意します。===== == == (1) ラベル要求(L1)--------------------------->(2)ラベル要求(L2)<。--------------------------- ラベル要求(L1)-------------------------->ラベルマッピング(L1)<。-------------------------- (3) ラベルマッピング(L1)<。--------------------------- (4) Keepalive、(なし、12、-、)--------------------------->(5)ラベル要求(L3)--------------------------->(6)Keepalive、(なし、-、12)<。--------------------------- ラベル要求(L3)-------------------------->ラベルマッピング(L3)<。-------------------------- (7) ラベルマッピング(L3)<。--------------------------- ===== TCP Sessionの故障===== : : : ===== 返されたTCP Session===== (8) 自由民主党イニット(なし、なし、23)--------------------------->自由民主党イニット(なし、なし、12)<。--------------------------- (9) ラベル要求(L3)--------------------------->ラベル要求(L3)-------------------------->ラベルマッピング(L3)<。-------------------------- (10) ラベルマッピング(L3)<。--------------------------- (11) ラベル要求(L2)<。---------------------------
Farrel Standards Track [Page 42] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[42ページ]。
Notes: ======
注意: ======
(1), (2) and (3) show label distribution without FT sequence numbers.
(1)、(2)、および(3)はFT一連番号なしでラベル分配を示しています。
(4) A check-Point request from P1. It carries the sequence number
of the check-point request.
(4) P1からのチェックポイント要求。 それは検査点要求の一連番号を運びます。
(5) P1 immediately starts a new label distribution request.
(5) P1はすぐに、新しいラベル分配要求を始めます。
(6) P2 confirms that it has secured all previous transactions.
(6) P2は、前のすべての取引を保証したと確認します。
(7) The subsequent (un-acknowledged) label distribution completes.
(7) 分配が完成するその後(不承認の)のラベル。
(8) The session fails and is restarted. Initialization messages
confirm the sequence numbers of the secured check-points.
(8) セッションは、失敗して、再開されます。 初期設定メッセージは安全にされた検査点の一連番号を確認します。
(9) P1 recommences the unacknowledged label distribution request.
(9) P1は不承認のラベル分配要求を再開します。
(10) P2 recommences an unacknowledged label distribution request.
(10) P2は不承認のラベル分配要求を再開します。
Farrel Standards Track [Page 43] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[43ページ]。
9.6. Graceful Shutdown With Check-Pointing But No FT Procedures
9.6. チェック指すのにもかかわらずの、いいえフィート手順との優雅な閉鎖
notes P1 P2
===== == ==
(1) Label Request(L1)
--------------------------->
(2) Label Request(L2)
<---------------------------
Label Request(L1)
-------------------------->
Label Mapping(L1)
<--------------------------
(3) Label Mapping(L1)
<---------------------------
(4) Keepalive(n/a,12,23) * With Cork TLV *
--------------------------->
(5) :
:
:
(6) Keepalive(n/a,24,12) * With Cork TLV *
<---------------------------
(7) Keepalive(n/a,-,24) * With Cork TLV *
--------------------------->
(8) Notification(Temporary shutdown)
--------------------------->
===== TCP Session failure =====
:
:
:
===== TCP Session restored =====
(9) LDP Init(n/a,n/a,24)
--------------------------->
LDP Init(n/a,n/a,12)
<---------------------------
(10) Label Request(L3)
--------------------------->
Label Request(L3)
-------------------------->
Label Mapping(L3)
<--------------------------
(11) Label Mapping(L3)
<---------------------------
(12) Label Mapping(L2)
--------------------------->
P1 P2に注意します。===== == == (1) ラベル要求(L1)--------------------------->(2)ラベル要求(L2)<。--------------------------- ラベル要求(L1)-------------------------->ラベルマッピング(L1)<。-------------------------- (3) ラベルマッピング(L1)<。--------------------------- (4) コルクTLV*があるKeepalive(なし、12、23)*--------------------------->(5): : : (6) コルクTLV*<があるKeepalive(なし、24、12)*--------------------------- (7) Keepalive、(なし、-、コルクTLV*がある24)*--------------------------->(8)通知(一時的な閉鎖)--------------------------->=== TCP Sessionの故障===== : : : ===== 返されたTCP Session===== (9) 自由民主党イニット(なし、なし、24)--------------------------->自由民主党イニット(なし、なし、12)<。--------------------------- (10) ラベル要求(L3)--------------------------->ラベル要求(L3)-------------------------->ラベルマッピング(L3)<。-------------------------- (11) ラベルマッピング(L3)<。--------------------------- (12) ラベルマッピング(L2)--------------------------->。
Farrel Standards Track [Page 44] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[44ページ]。
Notes: ======
注意: ======
(1), (2) and (3) show label distribution without FT sequence numbers.
(1)、(2)、および(3)はFT一連番号なしでラベル分配を示しています。
(4) A check-point request from P1. It carries the sequence number
of the check-point request and a Cork TLV.
(4) P1からの検査点要求。 それは検査点要求とCork TLVの一連番号を運びます。
(5) P1 has sent a Cork TLV so quieces.
(5) P1はそうがquiecesするCork TLVを送りました。
(6) P2 confirms the check-point and continues the three-way
handshake by including a Cork TLV itself.
(6) P2は、Cork TLV自身を含むことによって、検査点を確認して、3方向ハンドシェイクを続けています。
(7) P1 completes the three-way handshake. All operations have now
been check-pointed and the session is quiesced.
(7) P1は3方向ハンドシェイクを終了します。 すべての操作が現在チェックで先鋭です、そして、セッションはquiescedされます。
(8) The session is gracefully shut down.
(8) セッションは優雅に止められます。
(9) The session recovers and the peers exchange the sequence numbers
of the last secured check-points.
(9) セッションは回復します、そして、同輩は最後に安全にされた検査点の一連番号を交換します。
(10) P1 starts a new label distribution request.
(10) P1は新しいラベル分配要求を始めます。
(11) P1 continues processing a previously received label distribution
request.
(11) P1は、以前に受信されたラベル分配要求を処理し続けています。
10. Security Considerations
10. セキュリティ問題
The LDP FT enhancements inherit similar security considerations to those discussed in [RFC3036].
LDP FT増進は[RFC3036]で議論したものに同様のセキュリティ問題を引き継ぎます。
The LDP FT enhancements allow the re-establishment of a TCP connection between LDP peers without a full re-exchange of the attributes of established labels, which renders LSRs that implement the extensions specified in this document vulnerable to additional denial-of-service attacks as follows:
LDP FT増進は確立したラベルの属性の完全な再交換なしで自由民主党の同輩の間のTCP接続の再建を許容します:(交換は以下の追加サービス不能攻撃に傷つきやすいこのドキュメントで指定された拡大を実行するLSRsをレンダリングします)。
- An intruder may impersonate an LDP peer in order to force a
failure and reconnection of the TCP connection, but where the
intruder does not set the FT Reconnect Flag upon re-connection.
This forces all FT labels to be released.
- 侵入者が再接続へFT Reconnect Flagを上に置かないところで侵入者は、TCP接続の失敗と再接続を強制するために自由民主党の同輩をまねるかもしれません。 これによって、すべてのFTラベルがやむを得ず放出されます。
- Similarly, an intruder could set the FT Reconnect Flag on re-
establishment of the TCP session without preserving the state and
resources for FT labels.
- 同様に、FTラベルのための状態とリソースを保持しないで、侵入者はTCPセッションの再設立にFT Reconnect Flagをけしかけることができました。
Farrel Standards Track [Page 45] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[45ページ]。
- An intruder could intercept the traffic between LDP peers and
override the setting of the FT Label Flag to be set to 0 for all
labels.
- 侵入者は、すべてのラベルのために0に設定されるために自由民主党の同輩の間の交通を妨害して、FT Label Flagの設定をくつがえすことができました。
All of these attacks may be countered by use of an authentication scheme between LDP peers, such as the MD5-based scheme outlined in [RFC3036].
これらの攻撃のすべてが自由民主党の同輩の間の認証計画の使用で打ち返されるかもしれません、[RFC3036]に概説されたMD5ベースの計画などのように。
Alternative authentication schemes for LDP peers are outside the scope of this document, but could be deployed to provide enhanced security to implementations of LDP and the LDP FT enhancements.
自由民主党の同輩の代替の認証計画をこのドキュメントの範囲の外にありますが、自由民主党の実現とLDP FT増進に警備の強化を提供するために配備できました。
As with LDP, a security issue may exist if an LDP implementation continues to use labels after expiration of the session that first caused them to be used. This may arise if the upstream LSR detects the session failure after the downstream LSR has released and re-used the label. The problem is most obvious with the platform-wide label space and could result in mis-forwarding of data to other than intended destinations and it is conceivable that these behaviors may be deliberately exploited to either obtain services without authorization or to deny services to others.
自由民主党なら、自由民主党の実現が、最初にそれらを使用したセッションの満了の後にラベルを使用し続けているなら、安全保障問題は存在するかもしれません。 ラベルを放出して、再使用した後に上流のLSRがセッション失敗を検出するなら、これは起こるかもしれません。 意図している目的地を除いて、データの誤推進が広さのプラットホームで、スペースをラベルして、中に結果として生じることができたのが明白な状態で問題はだいたいです、そして、これらの振舞いが認可なしでサービスを得るか、または他のものに対するサービスを否定するのに故意に利用されるのが想像できます。
In this document, the validity of the session may be extended by the FT Reconnection Timeout, and the session may be re-established in this period. After the expiry of the Reconnection Timeout, the session must be considered to have failed and the same security issue applies as described above.
本書では、セッションの正当性はFT Reconnection Timeoutによって広げられるかもしれません、そして、セッションはこの時代に復職するかもしれません。 Reconnection Timeoutの満期の後に、失敗したとセッションを考えなければなりません、そして、同じ安全保障問題は上で説明されるように申し込まれます。
However, the downstream LSR may declare the session as failed before the expiration of its Reconnection Timeout. This increases the period during which the downstream LSR might reallocate the label while the upstream LSR continues to transmit data using the old usage of the label. To reduce this issue, this document requires that labels not be re-used until the Reconnection Timeout has expired.
しかしながら、川下のLSRはReconnection Timeoutの満了の前に失敗されているとしてセッションを宣言するかもしれません。 これは上流のLSRが、ラベルの古い慣習を使用することでデータを送り続けている間の川下のLSRがラベルを再割当てするかもしれない期間、増加します。 この問題を減少させるために、このドキュメントは、Reconnection Timeoutが期限が切れるまでラベルが再使用されないのを必要とします。
A further issue might apply if labels were re-used prior to the expiration of the FT Reconnection Timeout, but this is forbidden by this document.
ラベルがFT Reconnection Timeoutの満了の前に再使用されるなら、さらなる問題は適用されるでしょうにが、これはこのドキュメントによって禁じられます。
The issue of re-use of labels extends to labels managed through other mechanisms including direct configuration through management applications and distribution through other label distribution protocols. Avoiding this problem may be construed as an implementation issue (see below), but failure to acknowledge it could result in the mis-forwarding of data between LSPs established using some other mechanism and those recovered using the methods described in this document.
ラベルの再使用の問題は他のラベル分配プロトコルを通して管理アプリケーションと分配でダイレクト構成を含んでいて、他のメカニズムを通して管理されたラベルに達します。 この問題を避けるのは導入問題に理解されるかもしれませんが(以下を見てください)、それを承認しない場合、ある他のメカニズムを使用することで設立されたLSPsと本書では説明された方法を使用することで回復されたものの間のデータの誤推進をもたらすかもしれません。
Farrel Standards Track [Page 46] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[46ページ]。
11. Implementation Notes
11. 実現注意
11.1. FT Recovery Support on Non-FT LSRs
11.1. 回復が非フィートLSRsで支持するフィート
In order to take full advantage of the FT capabilities of LSRs in the network, it may be that an LSR that does not itself contain the ability to recover from local hardware or software faults still needs to support the LDP FT enhancements described in this document.
ネットワークでLSRsのFT能力を最大限に利用するために、多分、それ自体をするというわけではないLSRがローカルのハードウェアから回復する能力を含んでいるか、またはソフトウェアはまだ本書では説明されたLDP FT増進を支持する必要性をとがめています。
Consider an LSR, P1, that is an LDP peer of a fully Fault Tolerant LSR, P2. If P2 experiences a fault in the hardware or software that serves an LDP session between P1 and P2, it may fail the TCP connection between the peers. When the connection is recovered, the LSPs/labels between P1 and P2 can only be recovered if both LSRs were applying the FT recovery procedures to the LDP session.
LSR、P1、すなわち、aの自由民主党の同輩を完全に考えてください。Fault Tolerant LSR、P2。 P2がP1とP2との自由民主党のセッションに役立つハードウェアかソフトウェアにおける欠点を経験するなら、それは同輩の間のTCP接続に失敗するかもしれません。 接続が回復されるとき、両方のLSRsがFTリカバリ手順を自由民主党のセッションに適用していた場合にだけ、P1とP2の間のLSPs/ラベルを回収できます。
11.2. ACK generation logic
11.2. ACK世代論理
FT ACKs SHOULD be returned to the sending LSR as soon as is practicable in order to avoid building up a large quantity of unacknowledged state changes at the LSR. However, immediate one- for-one acknowledgements would waste bandwidth unnecessarily.
FT ACKs SHOULD、同じくらいすぐ、LSRの多量の不承認の州の変化を確立するのを避けるためにそのままで発信しているLSRに実用的に返してください。 しかしながら、-1のための即座の1つの承認が不必要に帯域幅を浪費するでしょう。
A possible implementation strategy for sending ACKs to FT LDP messages is as follows:
FT LDPメッセージにACKsを送るための可能な実現戦略は以下の通りです:
- An LSR secures received messages in order and tracks the sequence
number of the most recently secured message, Sr.
- LSRは整然とした状態で受信されたメッセージを保証します、そして、Sr、大部分の一連番号の道は最近、メッセージを保証しました。
- On each LDP KeepAlive that the LSR sends, it attaches an FT ACK
TLV listing Sr.
- LSRが送るそれぞれの自由民主党KeepAliveに、それはSrを記載するFT ACK TLVを取り付けます。
- Optionally, the LSR may attach an FT ACK TLV to any other LDP
message sent between Keepalive messages if, for example, Sr has
increased by more than a threshold value since the last ACK sent.
- 任意に、LSRは最後のACKが発信して以来例えば、Srが閾値以上で増加しているならKeepaliveメッセージの間に送られたいかなる他の自由民主党メッセージにもFT ACK TLVを取り付けるかもしれません。
This implementation combines the bandwidth benefits of accumulating ACKs while still providing timely ACKs.
この実現はまだタイムリーなACKsを提供している間、蓄積しているACKsの帯域幅利益を結合します。
11.2.1 Ack Generation Logic When Using Check-Pointing
11.2.1、チェック指すことを使用するとき、世代論理をAckします。
If check-pointing is in use, the LSRs need not be concerned with sending ACKs in such a timely manner.
チェック指すのが使用中であるなら、LSRsはそのようなタイムリーな方法で送付ACKsに関係がある必要はありません。
Check-points are solicitations for acknowledgements conveyed as a sequence number in an FT Protection TLV on a Keepalive message. Such check-point requests could be issued on a timer, after a significant amount of change, or before controlled shutdown of a session.
検査点は一連番号としてKeepaliveメッセージでFT Protection TLVで伝えられた承認のための懇願です。 かなりの量の変化の後、またはタイマか、セッションの制御閉鎖の前にそのような検査点要求を出すことができました。
Farrel Standards Track [Page 47] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[47ページ]。
The use of check-pointing may considerably simplify an implementation since it does not need to track the sequence numbers of all received LDP messages. It must, however, still ensure that all received messages (or the consequent state changes) are secured before acknowledging the sequence number on the Keepalive.
すべての受信された自由民主党メッセージの一連番号を追跡する必要はないので、チェック指すことの使用は実現をかなり簡素化するかもしれません。 しかしながら、それは、Keepaliveで一連番号を承認する前にすべての受信されたメッセージ(または、結果の州の変化)が保証されるのをまだ確実にしなければなりません。
This approach may be considered optimal in systems that do not show a high degree of change over time (such as targeted LDP sessions) and that are prepared to risk loss of state for the most recent LDP exchanges. More dynamic systems (such as LDP discovery sessions) are more likely to want to acknowledge state changes more frequently so that the maximum amount of state can be preserved over a failure.
このアプローチは時間がたつにつれての高度の変化(狙っている自由民主党のセッションなどの)を示さないで、最新の自由民主党の交換のために状態の損失の危険を冒すように準備されるシステムで最適であると考えられるかもしれません。 よりダイナミックなシステム(自由民主党の発見セッションなどの)が、より頻繁に州の変化をより承認したそうであるので、失敗の上に最大の量の状態を保持できます。
11.3 Interactions With Other Label Distribution Mechanisms
他との11.3回の相互作用がメカニズムと分配をラベルします。
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 the traffic engineering label distribution protocol that is 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 since that 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.
実現が一般的なラベル管理の部品か区分されたラベル空間などのテクニックの使用でこの問題を避けるのは、問題です。
12. Acknowledgments
12. 承認
The work in this document is based on the LDP ideas expressed by the authors of [RFC3036].
仕事は本書では[RFC3036]の作者によって表された自由民主党考えに基づいています。
The ACK scheme used in this document was inspired by the proposal by David Ward and John Scudder for restarting BGP sessions now included in [BGP-RESTART].
[BGP-RESTART]に現在のBGPセッションを再開するためのScudderを含んでいて、本書では使用されるACK計画はデヴィッド・ウォードとジョンによる提案で奮い立たせられました。
The authors would also like to acknowledge the careful review and comments of Nick Weeds, Piers Finlayson, Tim Harrison, Duncan Archer, Peter Ashwood-Smith, Bob Thomas, S. Manikantan, Adam Sheppard, Alan Davey, Iftekhar Hussain and Loa Andersson.
また、作者はニックWeeds、Piersフィンリースン、ティム・ハリソン、ダンカン・アーチャー、ピーター・Ashwood-スミス、ボブ・トーマス、S.Manikantan、アダムシェパード、アラン・デーブ、Iftekharフセイン、およびLoaアンデションの慎重なレビューとコメントを承諾したがっています。
Farrel Standards Track [Page 48] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[48ページ]。
13. Intellectual Property Consideration
13. 知的所有権の考慮
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専務に情報を記述してください。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights.
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しくは、要求された権利のオンラインリストに相談してください。
14. References
14. 参照
14.1. Normative References
14.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. Aggrawal, "Graceful
Restart Mechanism for Label Distribution Protocol",
RFC 3478, February 2003.
[RFC3478] LeelanivasとM.とRekhterとY.とR.Aggrawal、「ラベル分配プロトコルのための優雅な再開メカニズム」、RFC3478、2003年2月。
Farrel Standards Track [Page 49] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[49ページ]。
14.2. Informative References
14.2. 有益な参照
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205,
September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1、機能的な仕様」、RFC2205、1997年9月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tomassi, F.
and S. Molendini, "RSVP Refresh Reduction Extensions",
RFC 2961, April 2001.
[RFC2961]のバーガー、L.、ガン、D.、ツバメ、G.、なべ、P.、Tomassi、F.、およびS.Molendini、「RSVPは減少拡大をリフレッシュします」、RFC2961、2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V. and G. Swallow, "Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3209]AwducheとD.とバーガーとL.とガンとD.と李とT.とSrinivasan、V.とG.ツバメ、「LSP TunnelsのためのRSVPへの拡大」RFC3209(2001年12月)。
[RFC3212] Jamoussi, B., 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月。
[RFC3214] Ash, G., Lee, Y., Ashwood-Smith, P., Jamoussi, B.,
Fedyk, D., Skalecki, D. and L. Li, "LSP Modification
Using CR-LDP", RFC 3214, January 2001.
[RFC3214]灰とG.とリーとY.、Ashwood-スミスとP.とJamoussiとB.とFedykとD.とSkaleckiとD.とL.李、「CR-自由民主党を使用するLSP変更」RFC3214(2001年1月)。
[BGP-RESTART] Sangli, S., et al., Graceful Restart Mechanism for
BGP, Work in Progress.
[BGP-RESTART] サーングリ、S.、他、BGPのためのGraceful Restart Mechanism、ProgressのWork。
15. Authors' Addresses
15. 作者のアドレス
Adrian Farrel (editor) Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
エードリアンファレル(エディタ)Movazはヴァージニア Inc.7926ジョーンズ支店Drive、Suite615マクリーン、22102をネットワークでつなぎます。
Phone: +1 703-847-1867 EMail: afarrel@movaz.com
以下に電話をしてください。 +1 703-847-1867 メールしてください: afarrel@movaz.com
Paul Brittain Data Connection Ltd. Windsor House, Pepper Street, Chester, Cheshire CH1 1DF, UK
ポールBrittainデータ接続株式会社ウインザー家、Pepper通り、チェスター、チェーシャー州CH1 1DF、イギリス
Phone: +44-(0)20-8366-1177 EMail: pjb@dataconnection.com
以下に電話をしてください。 +44 -(0) 20-8366-1177 メールしてください: pjb@dataconnection.com
Farrel Standards Track [Page 50] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[50ページ]。
Philip Matthews Hyperchip 1800 Rene-Levesque Blvd W Montreal, Quebec H3H 2H2 Canada
フィリップマシューズHyperchip1800レネイ-レベスク・Blvd WケベックH3H 2H2モントリオール(カナダ)
Phone: +1 514-906-4965 EMail: pmatthews@hyperchip.com
以下に電話をしてください。 +1 514-906-4965 メールしてください: pmatthews@hyperchip.com
Eric Gray
エリック・グレー
EMail: ewgray@GraIyMage.com
メール: ewgray@GraIyMage.com
Jack Shaio Vivace Networks 2730 Orchard Parkway San Jose, CA 95134
ジャックShaioの活発なネットワーク2730果樹園Parkwayサンノゼ(カリフォルニア)95134
Phone: +1 408 432 7623 EMail: jack.shaio@vivacenetworks.com
以下に電話をしてください。 +1 7623年の408 432メール: jack.shaio@vivacenetworks.com
Toby Smith Laurel Networks, Inc. 1300 Omega Drive Pittsburgh, PA 15205
トビー・スミス・ローレルはDriveピッツバーグ、Inc.1300オメガPA 15205をネットワークでつなぎます。
EMail: tob@laurelnetworks.com
メール: tob@laurelnetworks.com
Andrew G. Malis Vivace Networks 2730 Orchard Parkway San Jose, CA 95134
アンドリューG.のMalisの活発なネットワーク2730果樹園Parkwayサンノゼ(カリフォルニア)95134
Phone: +1 408 383 7223 EMail: andy.malis@vivacenetworks.com
以下に電話をしてください。 +1 7223年の408 383メール: andy.malis@vivacenetworks.com
Farrel Standards Track [Page 51] RFC 3479 Fault Tolerance for the LDP February 2003
ファレルStandardsは2003年2月に自由民主党のためにRFC3479耐障害性を追跡します[51ページ]。
16. Full Copyright Statement
16. 完全な著作権宣言文
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 assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Farrel Standards Track [Page 52]
ファレル標準化過程[52ページ]
一覧
スポンサーリンク
