Network Working Group A. Farrel, Ed.
Request for Comments: 3479 Movaz Networks, Inc.
Category: Standards Track February 2003
Fault Tolerance for the Label Distribution Protocol (LDP)
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この仕様は、それが新しいTCP接続に切り替えることができるように、MPLS LDP制御トラフィックを運ぶ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.
マルチプロトコルラベルスイッチング（MPLS）システムは、システムのダウンタイムを最小限に保たなければならないコアネットワークに使用されます。多くのMPLSラベルスイッチングルータ（LSRの）は、従って、コアネットワークの高可用性を提供するために、フォールトトレラント（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は、ラベル配布プロトコル（LDP）、スイッチングハードウェア及びTCPを含むFT LSRの様々な構成要素、達成される方法の詳細は、実装固有です。この文書は、RFC 3036でLDP仕様の問題を特定し、それが困難な現在のLDPプロトコルを使用してFT LSRを実装し、そのようなFT LSRの実装を容易にするために、LDP仕様に拡張を定義するために行う、「LDP仕様」、。
The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP).
ここで説明する問題と拡張は、（CR-LDP）RFC 3212、「LDPを使用して制約ベースのLSPのセットアップ」にも同様に適用可能です。
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
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
Definitions of key words and terms applicable to LDP and CR-LDP are inherited from [RFC3212] and [RFC3036].
LDPやCR-LDPに適用キーワードと用語の定義は、[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].
用語「FTラベルは、」いくつかのフォールトトレラント操作が使用されるラベルを示すために、本書で紹介しています。 「非FTラベルは、」フォールトトレラントではなく、[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ラベルは、」この文書で説明FT保護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.
用語「チェックポイント可能FTラベル」は、この文書で説明するチェックポインティング技術を使用して保護されたFTラベルを示すために使用されます。
The extensions to LDP specified in this document are collectively referred to as the "LDP FT enhancements".
この文書で指定されたLDPの拡張を総称して「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.
本文書の文脈において、「チェック・ポインティング」は、特定のプロトコル・メッセージの受信及び処理（またはセキュアストレージ）を確認するメッセージ交換のプロセスを指します。
When talking about the individual bits in the 16-bit FT Flag Field, the words "bit" and "flag" are used interchangeably.
16ビットFTフラグ・フィールドにおける各ビットについて話すとき、単語「ビット」および「フラグ」は互換的に使用されます。
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：LDPピア。例えば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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
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、「著者のアドレス」に記載された共著者によって寄贈されました。
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％（ファイブ・ナイン）の可用性レベルを達成したときに高可用性（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への通常のアプローチは、ハードウェアおよび/またはソフトウェアのプロビジョニング、バックアップ・コピーを必要とします。プライマリコピーが失敗した場合、処理は、バックアップ・コピーに切り替えられます。フェイルオーバーと呼ばれるこのプロセスは、データプレーンの中断を最小限に抑え生じるはずです。
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）、時々一対多（1：N）、そして時にはとして多対多（M：N） 。プロビジョニングが行われたどのようなバックアップ、システムは、プライマリの障害時に自動的にバックアップに切り替える必要があり、バックアップ中にソフトウェアとハードウェアの状態は、障害が発生した時点で、主に状態を再現するように設定する必要があります。
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のLSRは、従って、コアネットワークの高可用性を提供するために、FTのハードウェアまたはソフトウェアを利用することができます。
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システムは、以下の障害タイプを含むデータプレーンに最小限の中断で障害の様々な存続できるようにする必要があります。
- failure/hot-swap of a physical connection between LSRs.
- LSRの間の物理的な接続の不良/ホットスワップ。
- failure/hot-swap of the switching fabric in an LSR.
- LSRのスイッチング・ファブリックの障害/ホットスワップ。
- failure of the TCP or LDP stack in an LSR.
- LSRでのTCPまたはLDPスタックの失敗。
- software upgrade to the TCP or LDP stacks in an LSR.
- LSRでのTCPまたはLDPスタックへのソフトウェア・アップグレード。
The first two examples of faults listed above 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つの例は、データプレーンに限定されます。そのような障害は、LDPコントロールプレーンで動作に対して透過的であるデータプレーンの冗長性を提供することによって扱うことができます。障害の最後の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.
自民党は、彼らがラベルを配布し、LSPを設定するためのプロトコルメッセージを交換する上でのLSR間で信頼性の高い接続を提供するためにTCPを使用しています。そのような接続を持っているのLSR一対のLDPピアと呼ばれます。
TCP enables LDP to assume reliable transfer of protocol messages. This means that some of the messages do not need to be acknowledged (for example, Label Release).
TCPはプロトコルメッセージの信頼性の高い転送を前提とする自民党を可能にします。これは、メッセージのいくつかは（例えば、ラベル解放）が確認する必要がないことを意味します。
LDP is defined such that if the TCP connection fails, the LSR should immediately tear down the LSPs associated with the session between the LDP peers, and release any labels and resources assigned to those LSPs.
自民党は、TCP接続が失敗した場合、LSRはすぐLDPピア間のセッションに関連付けられているLSPを取り壊す、およびそれらのLSPに割り当てられた任意のラベルとリソースを解放すべきであるように定義されます。
It is notoriously 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のフォールトトレラントな実装を提供するために、悪名高い困難です。そうするためには、送受信されるすべてのデータのコピーを作成することを伴うかもしれません。これは、BGPなど、他のTCPアプリケーションの実装にはおなじみの問題です。
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またはLDPスタックに影響を与えるフェイルオーバー中、TCP接続が失われる可能性があります。この位置からの回復はLDP制御メッセージは、接続障害時に失われている可能性があるという事実によって悪化しています。これらのメッセージは未確認なので、LSPまたはラベルの状態情報が失われる可能性があります。
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.
- LSPの損失なしにフェイルオーバーからの回復を促進するLDPへの拡張をサポートする意図のLDPピア間の交渉。
- selection of FT survival on a per LSP/label basis.
- LSP /ラベルごとに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.
- 完全なハンドシェイクがいずれかの頻繁に（例えば、メッセージの通り）またはより少ない頻度でチェックポインティングと同様にそれらのメッセージに対して実行されることを保証するLDPメッセージの肯定応答。
- 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 /ラベル状態が正しくLDPセッションの再接続後に回収されることを保証するために、フェイルオーバー後の失われたメッセージを。
The issues and objectives described above are equally applicable to CR-LDP.
上述した課題及び目的は、CR-LDPに等しく適用可能です。
Other objectives of this document are to:
このドキュメントの他の目的は次のとおりです。
- offer backward-compatibility with LSRs that do not implement these extensions to LDP.
- 自民党にこれらの拡張機能を実装していないのLSRとの下位互換性を提供します。
- preserve existing protocol rules described in [RFC3036] for handling unexpected duplicate messages and for processing unexpected messages referring to unknown LSPs/labels.
- 予期しない重複したメッセージを処理するために、未知のLSP /ラベルを参照して、予期しないメッセージを処理するために[RFC3036]に記載の既存のプロトコルルールを保存します。
- 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.
彼らは継続的、またはポストフェイルオーバ回復に限定されるかどうか： - （[RFC2205]、[RFC2961]、[RFC3209]及び[RFC3478]を参照そのようなRSVP中に存在するもののような）フル状態リフレッシュソリューションを回避します。
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.
この文書は、それらのLSR間のTCP接続が失われたときに隣接のLSRのペア間で交換ラベルのラベルの状態の保存に集中することに注意してください。このことは、LSPのフォールトトレラント動作のために必要であるが、LSPのためのエンドツーエンドの保護の完全な実装は、これがこの文書の範囲外である他の技術と組み合わされることを必要とします。
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のルーティングまたは[RFC3214]で覆われているラベルまたはLSPに割り当てられたリソースを変更する方法を説明しようとしません。また、このドキュメントではありません
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の動作を使用することはありません。復元されたデータを処理するときと同じクラッシュがすぐに発生することなく、少なくとも可能性 - ここに一覧表示するにはあまりにも数多くの潜在的な問題があること、しかし、注意してください。
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.
- LDP初期化メッセージのFTセッション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セッションTLV（Rビット）におけるFT再接続フラグLSRは、TCP接続の失敗を横切っFTラベル状態を維持しているか否かを示します。
- 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.
- FT再接続タイムアウトは、TCP接続の失敗後にFTラベルの状態を保存する最大時間ピアのLSRを示すLDP初期化メッセージ、上で交換しました。
- 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保護TLVは、LDPラベルに影響を与える操作を識別するために使用されます。 FT保護TLVを運ぶすべてのLDPメッセージがシーケンス番号付きFTラベルのための状態を正しくLDPセッションの再接続後に回収することができるように送信するLDPピアに（例えば、NVRAMに）を確保し、ACKされる必要があります。
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システム内の実装は、この文書で開いたままにしていることに注意してください。実装は、シーケンス番号付きFTラベルに関連するメッセージ全体を保護するために選択することができ、またはそれだけで、関連する状態情報を確保することができます。
- 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保護TLVを使用して固定してもよいです。これは、アドレスの非常に大きな数であってもよいものを再宣伝しなくても、LDPセッションの再接続後の回復を可能にします。
- 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保護TLVはまた、以前のすべてのFT操作の確認応答をフラッシュするためにキープアライブメッセージに使用されてもよいです。これは半ばセッション中またはその前LDPセッションの正常なシャットダウンのいずれか、今後の回復のためのチェックポイントを有効にします。この手順は、将来の回復のために（つまり、FTと非FTの両方である）の操作をすべての点を確認するために使用することができます。
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.
本書では説明LDP [RFC3036]の拡張は、LDPピアの対の間のLDPセッションで正常に使用することができるようにするために、それらはLDP FTの強化は、LDPセッションで使用されることを交渉しなければなりません。
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セッションTLVを使用してLDP初期化メッセージ交換で行われます。このTLVの存在は、ピアが保護やリカバリ処理のいくつかのフォームをサポートするために望んでいることを示しています。このTLV内のSビットは、ピアがこのLDPセッションで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.
両方のLDPピアがLDP初期化メッセージにFTセッションTLVを含み、S又はCビットの同じ設定を持っている場合、関連するLDP FTの強化は、LDPセッションではサポートされなければなりません。
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.
いずれかのLDPピアは、FTセッションTLV LDP初期化メッセージが含まれていない場合、ピア間SとCのビットの一致がない場合、または、LDP FTの強化は、このLDPセッション中に使用してはいけません。これらの場合における送信LDPピアによってLDP FT拡張機能の使用は、セッションが終了させる重大なプロトコルエラーとして受信LDPピアによって解釈されなければなりません。
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.
LSRは、これらの接続は、同じLDPピア間のLDPセッションの連続したインスタンス化されている場合でも、別のTCP接続で異なるFT /非FT行動を提示することができます。
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.
LDP初期化メッセージにFTセッションTLVは、Uビットを運びます。 LSRは、任意の保護や回復メカニズムをサポートしていない場合、それはこのTLVを無視します。こうしたパートナーはまた、FTセッションTLVを含んでいないので、そのようなのLSRへのすべてのLDPセッションが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セッションが明示的に別段の記載がある場合を除き、LDP FTの機能強化をサポートするLSRの間にあることを前提としています。
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接続障害が検出され、様々な方法でLDPコンポーネントに報告することができます。これらはすべて、LDPコンポーネントによって同じように扱われるべきです。
- 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.
- ソケットキープアライブタイムアウト。
- Sockets send failure.
- ソケット失敗を送信します。
- New (incoming) Socket opened.
- 新（受信）ソケットをオープンしました。
- LDP protocol timeout.
- LDPプロトコルのタイムアウト。
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の強化がLDPセッションで使用されていない場合は、TCP接続の障害にLDPピアのアクションは、[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].
すべての状態情報と非FTラベルに関連付けられているリソースは、スイッチングハードウェアから非FTラベルをdeprogramming含め、TCP接続の障害に解放されなければなりません。これは、[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の強化がLDPセッションで使用されている場合は、両方のLDPピアは、FTのラベルに関連付けられた状態情報とリソースを保存すべきLDPセッション上で交換。どちらのLDPピアは、TCP接続が合理的な期間内に復元されていない場合は、保存状態情報とFT-ラベルに関連付けられたリソースを解放するためにタイマーを使用すべきです。このタイマーが満了した挙動は、[RFC3036]で説明LDPセッションの障害時の動作と同じです。
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再接続タイムアウト各LDPピアは、LDP初期化メッセージにFTセッションTLVで運ばれるLDPセッションに適用する予定。両方のLDPピアはゼロの値が正の無限大として扱われるLDP初期交換、から二提案タイムアウト値の小さいタイムアウト間隔に対応する値を使用しなければなりません。
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の強化を実現するLSRは、フェイルオーバーを横切って、スイッチングハードウェアのプログラミングを保存するべきです。これは、データ転送がLSRの間の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ネットワークを使用しているアプリケーションに受け入れられない場合は、このドキュメントで説明LDP FTの強化を使用しないでください。
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接続が確立されると、LDPピアは、LDP初期化メッセージを交換しなければなりません。新しいTCP接続が失敗した後に確立されると、LDPピアは、LDP初期化メッセージを再交換する必要があります。
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.
LDPピアがLDPセッションの新しいインスタンスのためのLDP初期化メッセージに設定されたビットSとのFTセッションTLVが含まれている場合、それはまた、ラベルの状態を維持することができたか否かに係るFT再接続フラグを設定する必要があります。 FT再接続フラグがFTセッション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.
LDPピアがLDPセッションの以前のインスタンス化のためにすべての状態情報を保存している場合、それはFTセッションTLV 1にFT再接続フラグを設定する必要があります。それ以外の場合は、0にFT再接続フラグを設定する必要があります。
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.
LDPピアのいずれかが0にFT再接続フラグを設定し、又はFTセッションTLVを省略した場合、両方のLDPピアは、FTラベル状態とアドレスを含む同じLDPピア間のLDPセッションの前のインスタンスに関連する任意の状態情報とリソースを解放しなければなりません。これは、LDPピアがコールドスタートを受けることを余儀なくされている場合、ネットワークリソースが永久的に1つのLSRによって失われないことを保証します。
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.
LDPピアは、前のインスタンスから（例えば、ラベル空間の境界）は、任意のセッションパラメータを変更した場合、任意の保存標識の性質が変更されていてもよいです。具体的には、以前に割り当てられたラベルは今範囲外であってもよいです。障害が発生する前のセッションで使用されていたように、このような理由から、セッションの再接続は、同じパラメータを使用しなければなりません。パラメータは、他のピアによって変更されたLDPピア通知は、それはFTセッションパラメータを変更 "ステータスコードで通知メッセージを送信する必要がある場合。
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.
両方のLDPピアが1にFT再接続フラグを設定した場合、両方のLDPピアは、LDPセッションの障害によって中断されたシーケンス番号付きFTラベル上の任意のラベル操作を完了するには、この文書に示された手順を使用しなければなりません。
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.
LDPピアは、それが自身の初期化メッセージを送信する前に設定FT再接続旗とLDP初期化メッセージを受信しますが、セッションの以前のバージョンに関する情報を保持していなければ、それは明らかFT再接続フラグと初期化メッセージで応じなければなりません。 LDPピアは、FT再接続フラグでLDP初期化メッセージを受信した場合に何状態は、セッションのいずれかピアによって保持されなかったかのように、それが行動しなければならないFT再接続フラグクリアで送信された初期化メッセージに応答してセット。
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.
シーケンス番号付きFTラベル上のラベルの操作は、シーケンス番号付きFTラベルに影響を与えるすべてのLDPメッセージの確認応答を提供することにより、フォールトトレラントを作られています。謝辞これらのLDPメッセージのシーケンス番号によって達成されています。
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、「FT操作」に詳述されています。
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.
LDPピアは、LDPピア間のLDPセッションの再接続や、時限的にいずれか、すべてのシーケンス番号付きFTラベルの状態の完全な再同期を実行するために、これらの承認や手順を使用して、それが必要ではありません。
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.
チェックポインティングは、ノードは、彼らがLDPメッセージを確認するために必要な処理量を低減することを可能にする便利な機能です。 FTセッション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.
シーケンス番号付きFTラベル上の通常の操作では、確認応答は、通常の処理中に延期とだけ定期的に送信することができます。チェックポインティングされたメッセージと以前のすべてのメッセージの肯定応答を要求するキープアライブメッセージにシーケンス番号を含めることによって、ピアからの肯定応答をフラッシュするために使用することができます。この場合、すべてのシーケンス番号付きFTラベルはチェックポイント可能FTラベルです。
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ビットが合意されていない場合は、チェック・ポインティングをまだ使用することができます。このケースでは、ピア間で交換されるすべてのメッセージを確認するために使用され、すべてのラベルには、チェックポイント可能なFTラベルです。
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.
これは、確認応答は、すべてのメッセージに送信する必要がない、あるいは頻繁に、だけキープアライブメッセージに担持された要求に応じて、チェックポイントとして送信されたアプローチを提供しています。このようなアプローチは、（目標とLDPセッションなど）時間変化の高度を示さないシステムに最適と考えられるし、最新のLDP交換の状態の損失を危険に用意されていることがあります。 （例えばLDPディスカバリセッションなど）よりダイナミックなシステムが状態の最大量は、障害の上に保存することができるように、より頻繁に状態の変化を確認したい可能性が高くなります。
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対1でメッセージを認め、延期確認応答をノードということであることに注意してください、とチェックポインティングに頼るのノードは、すべてのシームレスおよびセッションの初期化を超えたプロトコルネゴシエーションなしで相互運用する必要があります。
Further discussion of this feature is provided in section 5, "FT Operations".
この機能のさらなる議論はセクション5、「FT操作」で提供されています。
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.
これらの場合にセッションを終了しようとするノードは、上述したように、チェックポイントの要求を使用して肯定応答をフラッシュすることができます。送信者は、その保存された状態の整合性を維持するために、シャットダウンチェックポインティングを要求した後、さらにラベルまたはアドレスに関連したメッセージを送信するべきではありません。
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.
しかしながら、これは、一方向にのみ確認応答を提供し、また、終了しているノードは、ピアによって送信されたすべての状態を確保していることの検証が必要となります。これは、キープアライブメッセージに追加のTLV（TLVコルク）によって要求されたチェックポイントの三方手ぶれによって達成されます。
Further discussion of this feature is provided in section 5, "FT Operations".
この機能のさらなる議論はセクション5、「FT操作」で提供されています。
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.
それはより多くの利用可能なラベルを持っていないので、LDPピアは、ラベル要求メッセージを満たすことができない場合は、ステータスコード「いいえラベルリソースを」運ぶ通知メッセージを送信します。これは、その後のラベル要求メッセージも同じ理由で失敗する可能性がある要求するLDPピアを警告しています。セッションの回復後に送信されるラベル要求メッセージが同じ応答を受け取ることになりますので、このメッセージは、FTの目的のために承認される必要はありません。しかし、「いいえラベルリソースの通知を受けたLDPピアは、それがラベルリソース利用できる「通知メッセージを受信するまでラベル要求メッセージの送信を停止します。この迷惑通知は、セッションの障害時に失われる可能性がありますので、それは、この文書に記載されている手順を使用して保護することができます。
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.
別のアプローチは、実装は常にセッションが再確立されたときにラベルが利用可能であると仮定してもよいということができます。この場合、セッションの前の化身から「いいえラベルリソースの情報を捨てることや失敗したセッションの再確立にLDPメッセージのバッチを送信することができ、それは失敗するだろう知っていた可能性があることことは可能です。
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.
「ラベル資源利用可能」の送信者通知メッセージは、受信確認を要求するシーケンス番号を追加するかどうかを選択することがあります。逆に、「ラベル資源利用できる」通知メッセージの受信者は、実際にどのような状態を保存せずにメッセージを確認することもできます。
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.
これはオプションの通知メッセージにFTパラメータを作ることによって可能になった実装の選択です。彼らは逆のアプローチを取る場合、実装は完全に相互運用しますが、追加のLDPメッセージは、セッションの回復に不必要に送信されることがあります。
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.
この文書に記載された手順は、トンネルされたLSPおよびトンネルによって運ばれるのLSPに適用することができます。トンネルが経路に沿った各ホップのために異なるLDPセッションによって管理されている間LSPをトンネリングリコールは、端に端を実行する単一のLDPセッションによって管理されています。それにもかかわらず、トンネルを管理セッションの1つの区切りは、トンネルLSPを管理セッションの中断に対応する可能性があります。これは確かに自民党の交換が失敗したリンクを共有する場合ですが、LDPメッセージはトンネルのものとは異なるパスに沿って配線されている場合、またはトンネルの障害は、ANによって引き起こされている場合場合である必要はありませんトランジットLSRのLDPのソフトウェア障害。
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].
トンネリングされたLSPの転送経路が保存されるようにするために、トンネル自体の転送経路が保存されなければなりません。これは、その経路に沿った任意のセッションに障害があった場合、トンネルが切断されてはならないことを意味します。これを達成するために、トンネルの経路に沿ってLDPピアの各ペア間のラベル交換は、この文書に記載されているか、[RFC3478]の手順のいずれかを使用しなければなりません。
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であるが、彼らはアクティブな状態を回復することができるように、トンネリングのLSPがフル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の保護を持っていないトンネル化LSPを運ぶために許容されます。
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セッションが確立されると、セッション初期化メッセージにFTセッションTLVのSビットを使用して、両方のLDPピアは、FTのため、このセクションで説明した手順を適用しなければなりません「FT LDPセッションの確立」、セクション4.1で説明したようにLDPメッセージ交換。
If the LDP session has been negotiated to not use the LDP FT enhancements, these procedures MUST NOT be used.
LDPセッションがLDP FT拡張を使用しないように交渉されている場合は、これらの手順を使用してはいけません。
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.
ラベルは、そのラベルに関連する最初のラベル要求またはラベルマッピングメッセージがFT保護TLVを運ぶ場合は、シーケンス番号付きFTラベルとして識別されます。
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.
これは、フラグに有効な実装オプションシーケンス番号付きFTラベルとしてすべてのラベルです。確かにこれは、定期的な達成するためにFT保護TLVを運ぶキープアライブメッセージを使用したいの実装のための好ましい選択肢かもしれ完全なラベル転送状態で保存されます。
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.
ラベルは、シーケンス番号付きFTラベルの場合、ラベルの状態は、LDPセッションの障害が発生した後に回収することができるように、そのラベルに影響を与えるすべてのLDPメッセージがFT保護TLVを運ばなければなりません。
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.
何のラベルがシーケンス番号付きFTラベルがないようにするためのさらなる有効なオプションがあります。この場合は、チェックポインティングをキープアライブメッセージを使用すると、すべてのメッセージに適用されますが、セッション上で交換しました。
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状態の範囲は、LDPピアの対の間のLDPメッセージ交換に制限されます。
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.
順序制御では、メッセージは、下流または上流転送されるとき、TLVは、メッセージを送信LSRの要件に応じて存在するか又は存在しなくてもよいです。
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ラベルに使用されている場合は、FTのラベル値は、/ LABELのRELEASE WITHDRAW、明示的なラベルで、ラベルはFTラベルの撤退を認めている渡された先のすべてのLDP FTピアまで再利用してはいけません、LDPセッションが失敗した後が、FT再接続フラグを設定せずに再接続されている場合、暗黙的に交換又は。それは他のいくつかのセッションで使用中でない場合は、セッションが再接続タイムアウト以内に再確立されていない場合には、ラベルは再使用のために利用可能になることがあります。
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セッションがLDP FTの強化を使用している場合は、以下に説明するように、両方のLDPピアは、FT操作ACKを使用してメッセージを撤回アドレスと住所を確保しなければなりません。これは、LDPセッションが再接続された後、アドレスがまだ有効であるかどうかを介して任意のあいまいさを避けることができます。
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は、それが回復しLDPセッションの前のインスタンス化に送られたアドレスメッセージがもはや有効であると判断していない場合、それが明示的にセッションが再接続されたときに、アドレスがそのアドレスに対して撤回発行しなければなりません。
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再接続フラグ（すなわち、状態が保存されていない）LDPセッションの再接続時に双方LDPピアによって設定されていない場合、両方のLDPピアは、すべてのアドレスが引き抜かれたと考慮しなければなりません。 [RFC3036]で指定されたLDPピアは、すべての有効なアドレスのための新しいアドレスメッセージを発行する必要があります。
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がラベル要求に応えるために利用可能なラベルを持っていない可能性があります。ノーラベルリソースのメッセージ - この場合は、RFC 3036で指定されているように、下流LSRは通知で応答しなければなりません。下流のLSRからラベルリソース利用可能なメッセージ - 上流のLSRは、それが通知を受信するまで、新しいラベルを求めて中断します。
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拡張がセッションで使用されている場合は、実装はそのピアのラベルリソースの状態を確保するかどうかを選択できます。この選択に影響を与え、誤ってセッションの再確立に枯渇資源でピアにルーティングされますが、それ以外の相互運用性に影響を与えないLDPメッセージの数。
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は、フェイルオーバーを越えラベル可用性状態を保持する必要があります。
- The upstream LSR must recall the label availability state across failover so that it can optimize not sending Label Requests when it recovers.
- それは、それが回復したときにラベル要求を送信しない最適化することができるように上流のLSRは、フェイルオーバーを越えラベル可用性状態をリコールしなければなりません。
- 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 Aがそれを受け取ったずに回復した場合、それはLSR Aがメッセージを受信したことを確認し、そのセキュアな状態をクリアする、またはメッセージを再送することができるようにラベルリソースが利用可能 - - 下流LSRは、通知にシーケンス番号を使用する必要があります。
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は、通知のシーケンス番号を含めないことを選択できます。これは、通知がまたは配信されていない場合がありますので、セッションの再確立にそれは、そのピアがLSRのリソースの状態がどう思うか知らないことを意味します。そのピアをリセットするために利用できるラベルのリソース - このような実装では、追加の通知を送信することにより回収セッションを開始する必要があります。
- 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.
- 上流のノードは、そのピアのリソース状態についての情報を保護しないこともできます。これは、通知認めるだろう - 使用可能なラベルリソースのが、情報を保存しないでしょう。このような実装は、そのピアのリソースの状態はセッションが再確立されたときに利用可能なリソースにラベルを付けるためにリセットされたと仮定しなければなりません。
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再接続フラグが（つまり、状態が保存されていない）LDPセッションの再接続時に両方のLDPピアによって設定されていない場合は、セッションがために設定されていたかのように、両方のLDPピアがリセットされているために、ラベルの可用性の状態を考慮する必要があります初めて。
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メッセージのハンドシェイクは、ACKの使用によって達成されます。元のメッセージとACKの間の相関は、FT保護TLVに含まれるFTシーケンス番号によってであり、そしてFT ACK TLVに戻さ。 FT ACK TLVは、LDPピア間のTCP接続上で送信される任意のLDPメッセージに担持されてもよいです。
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.
LDPピアは、それが参加している各LDPセッションの別FTシーケンス番号を維持します。 FTシーケンス番号はFTシーケンス番号が関連付けられているFT LDPセッションでこのLSRによって発行された（すなわち、FT保護TLVを含む）各FT LDPメッセージの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.
LDPピアは、FT保護TLVを含むメッセージを受信すると、このメッセージ（またはメッセージの処理に由来する状態情報）を確保するためのステップを取る必要があります。メッセージが固定されると、それがACKされなければなりません。しかし、すぐにこの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.
ACKはLDPピア間のメッセージの流れを減少させるために蓄積することができます。 LSRは、配列番号1、2、3、4とFT LDPメッセージを受信した場合、それはすべてのこれらのメッセージの確保、ACKの受信に配列番号4を有する単一のACKを送信することができます。蓄積されたACKの数、または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.
これは、蓄積されたACKの使用と不適合であるACKは、順序が狂って送ってはいけません。重複ACK（すなわち、同じシーケンス番号を確認二つの連続するメッセージである）、許容可能です。
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'.
（セッションにそのパートナーがタイムリーな方法でそれらを認めていないため）LDPピアは、特定のセッションのためにそのシーケンス番号空間が非を認めシーケンス番号の完全であることを発見した場合、それはそれ以上のFTのための新しいシーケンス番号を割り当てることができませんLPDメッセージ。これは、ステータスコード「疲れFT配列番号」で通知メッセージを送信する必要があります。
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の強化がLDPセッションで使用されている場合は、各LDPピアは、FTのラベルに関連付けられた状態情報とリソースを解放すべきではないTCP接続が失敗したときにそのLDPセッション上で交換。これは、[RFC3036]に反しているが、FTラベル上のラベル操作はTCPコネクションの再接続後に完了することができます。
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の拡張を使用してLDPセッションの両方LDPピアは、以下に説明するように、彼らはそのLDPセッションのために保持する状態情報及びリソースを保存するべきです。
- 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.
- 上流のLDPピアは、それがラベルのラベルリリースまたはラベルアボートメッセージを開始する場合のシーケンス番号付きFTラベルに関連付けられている（特定の帯域幅で）リソースを解放すべきです。 TCP接続が中断された場合、それはラベル操作を再発行する必要があるかもしれないとして、上流のLDPピアは、それがラベルに関連付けられたリソースを解放した場合でも、シーケンス番号付きFTラベルの状態情報を保存しなければなりません。
- 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.
- それはラベルに送信されたメッセージを中止ラベルリリースまたは標識に肯定応答を受信したとき、上流LDPピアは、シーケンス番号付きFTラベルに関連付けられた状態情報とリソースを解放する必要があり、またはそれは、に応じてラベル解放メッセージを送信する場合ラベルは、下流のLDPピアから受信したメッセージを撤回します。
- 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.
- それはそれはまだ上流のLDPピアは、ラベルを使用してデータを送信するために停止したことの確認を受信していないとしてラベルがラベルにメッセージを撤回送信するときに、下流LDPピアはシーケンス番号付きFTラベルに関連付けられているリソースを解放すべきではありません。下流のLDPピアが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.
- それはラベルのメッセージを撤回標識に肯定応答を受信したとき、下流LDPピアは、シーケンス番号付きFTラベルに関連付けられたリソースおよび状態情報を解放しなければなりません。
- 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再接続タイムアウトが経過すると、LSRは（永久）の前のインスタンスからすべての状態情報とリソースを解放する必要がありLDPセッションを失敗しました。
- 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.
- LDPピアのいずれかが、状態情報またはPEND（またはキュー）にできないことLDP操作（の完全性の損失の内部知識セクション5.4.1に記載されているように、「LDP操作TCP障害時に基づいて、状態情報を解放することを選択することができます「）TCP障害時。これは、ピアが状態を解除する前にFT再接続タイムアウトの期間を待つ必要はありませんされます。タイムアウトは、状態の永続性に上限を提供します。しかし、ピア解放状態再接続タイムアウトの満了前に、それは再接続タイムアウトが経過するまでのセッションで使用されていた任意のラベルを再使用してはならないイベントインチ
- 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ビットセットとステータスTLVを受信した場合、LSRは、セッションに関連するすべての状態情報とリソースを解放しなければなりません。 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.
「一時停止」ステータスコードは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が、それはそのラベルが交換されたTCP接続の障害時に、任意の単一のFTラベルの状態を解放しなければならないと判断した場合、それは、LDPセッション上のすべてのラベルのためのすべての状態を解除しなければなりません。
The release of state information and resources associated with non-FT labels is as described in [RFC3036].
[RFC3036]に記載されているように、状態情報と非FTラベルに関連付けられたリソースの解放です。
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.
ラベルリリースとラベルに承認撤回は任意の順序で下流のLSRによって受信することができることに注意してください。下流LSRは、最初のメッセージを受信すると、そのリソースを解放し、第2のメッセージを受信すると、そのリソースを解放しなければなりません。
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接続の失敗が通知されると、それは、LDPピア間のTCP接続の再接続のための期間を許可するFT再接続タイマーを開始する必要があります。
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.
このタイマーの推奨されるデフォルト値は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).
LDPピア間のTCP接続が失敗したら、アクティブなLSRは、TCPコネクションを再確立しようとすべきです。 TCPコネクションを再確立するためのメカニズム、タイマーおよび再試行回数は、実装上の選択です。接続を再確立しようとするが、ピアLSRに考慮LDPピア間のネットワークの性質を、必要なフェイルオーバ処理を取ることが推奨され、FT再接続タイムアウトは、TCPコネクションの前のインスタンス化（上選択します）があれば。
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再接続タイムアウト期間内に再確立することができない場合は、このタイムアウトを検出するLSRは、失敗したLDPセッションのために保存、すべての状態を解除すべきです。 TCP接続が（例えば、こんにちはさらに交換後の新しいLDPセッションを設定するために）、その後再確立されている場合は、このタイムアウトイベントに保存された状態情報をリリースしている場合、LSRは0にFT再接続フラグを設定する必要があります。
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再接続タイムアウト時間内に再確立されている場合は、両方のピアがTCP接続障害（つまり、結果として非を認めている）によって中断された再発行LDP操作しなければなりません。この手順は、「TCP再接続した後FT手順」セクション5.5に記載されています。
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.
FT再接続タイマが動作している間FT LDPセッションのホールドタイマ（[RFC3036]セクション2.5.5を参照）は無視されるべきです。 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の強化がLDPセッションのために使用されている場合は、LSRが、それはLDPピアにLDPメッセージを送信する必要があると判断することが可能ですが、そのピアへのTCP接続は現在ダウンしていること。これらのラベル操作が失敗したTCP接続のために保存FTラベルの状態に影響を与えるので、TCP接続が復元されたときに状態変化がLDPピアに渡されることが重要です。
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").
LSRは、それがどのTCP接続が現在失敗したために、それは必要があります（たとえば、キューに）操作を保留とするとき、TCP接続LDPピアとその操作を完了LDPピアに新しいFT LDP操作を発行する必要があると判断した場合ラベル操作がTCP接続の失敗時以降の追加の操作によってオーバーライドされない限り、復元される（セクション5.5を参照して、「FT処置の後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.
、TCPの障害時に、LSRはそれがない保留操作、それは単に失敗することはできませんすることができたと判断した場合、それは前のLDPセッションを再確立することを試みてはいけません（例えば、ラベルは撤回、リリースまたは操作を中止します）。 LSRは、再接続タイマーの期限が切れているかのように振る舞うとLDPピアに対するすべての状態情報を解放する必要があります。 LSRは、保留操作にできない（または望まない）であってもよいです。 TCPは、LDPピア間動作不能であった主要なルーティング遷移が発生した場合、例えば、それはFT LDP操作の過大な数をもたらすかもしれません。再接続タイムアウトの満了前の状態を解除するLSRは、再接続タイムアウトが経過するまでのセッションで使用されていた任意のラベルを再使用してはなりません。
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接続に失敗した転送できないFT LDP動作は（提供十分な状態がラベル操作を転送するために維持される）、または処理のために保留以降TCP接続が復元されるときに動作ができ、すぐに処理することができる受信正しく上流または下流に転送します。既存のFTラベルに対する操作は、TCPセッションの失敗時に失敗したことがない（SHOULD NOT）。
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ラベル用ラベル要求操作がLSRは、それがラベル要求メッセージを発行する必要があると判断時点での回復を待っているTCP接続の再確立を待って保留しないことをお勧めします。その代わりに、必要に応じてそのようなラベル要求操作は、失敗すべきであり、「いいえLDPセッションのステータスコードを含む通知メッセージが上流に送られます。
Label Requests for new non-FT Labels MUST be rejected during TCP connection failure, as specified in [RFC3036].
[RFC3036]で指定された新たな非FTラベルのラベルの要求は、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操作ハンドシェイクがシーケンス番号付きFTラベルとアドレスメッセージのすべての状態の変化が確認されたり、各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.
LDPピア間のTCP接続が失敗したが、FT再接続タイムアウト時間内に再接続されており、両方のLSRは、彼らが前のLDPセッションを再確立されます示されている場合は、接続の両方のLDPピアは、FT番号順のための任意のラベル操作を完了する必要があります故障やTCPコネクションの再接続によって中断されたラベル。
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再接続タイムアウトのための手順は、LDPピアがTCP障害（セクション5.4.1で説明したように、「LDP操作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.
セクション5.4.1に記載したように、何らかの理由で、LSRは、LDPピアに対して保留操作することができなかった、場合は、「LDP操作TCP障害時」、LSRが再上0にFT再接続フラグを設定する必要があります全くFT状態が維持されていないことを示すことLDPピアへの接続。
Label operations are completed using the following procedure.
ラベルの操作は、次の手順を使用して完成されています。
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.
LDPピア間のTCP接続の復元時には、理由はTCP接続に失敗した失われたシーケンス番号付きFTラベルのための任意のLDPメッセージが再発行されます。再発行されたメッセージを受信したLDPピアが初めて受信されたかのようにメッセージを処理します。
"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.
メッセージの「ネット・ゼロ」の組み合わせは、LDPピア間のTCP接続の再確立後に再発行する必要はありません。これは、TCPセッションの再接続後にLDP初期化メッセージ交換のLDPピアによってACKされていない再発行のメッセージについては、以下の規則につながります。
- A Label Request message MUST be re-issued unless a Label Abort would be re-issued for the same Sequence Numbered FT Label.
- ラベルの中止は、同じシーケンス番号付きFTラベルのために再発行されない限りラベル要求メッセージを再発行する必要があります。
- A Label Mapping message MUST be re-issued unless a Label Withdraw message would be re-issued for the same Sequence Numbered FT Label.
- ラベル撤回メッセージがFTラベル番号付き同じシーケンスのために再発行されない限りラベルマッピングメッセージを再発行する必要があります。
- 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保護TLVを実施したLDPセッション上の他のすべてのメッセージを再発行する必要があります。
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接続の障害時に（「TCP障害時LDP操作」、セクション5.4.1を参照してください）保留された任意のFTラベル操作はまた、彼らは「NET-の一部を形成する場合を除いて、LDPセッションの再確立時に発行する必要があります上記の規則に従ってメッセージのゼロ」組み合わせ。
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ラベル操作の判定は、キューリソースの使用を最適化するためにTCPコネクションの再確立する前に保留メッセージに対して実行することができます。 FT ACK TLVは、LDPピアから受信されるまで、TCP接続の障害が発生する前にLDPピアに送信される、またはそれらとペアにされたメッセージを保留されたメッセージは、このような最適化の対象にはなりません。このACKは、LSRは、TCP接続の失敗の前LDPピアによって受信されたメッセージを識別することを可能にします。
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.
チェックポインティングは、セッション初期化メッセージにFTセッションTLVのCビットを使用して、上記FT手順から独立して選択することができます。ノートは、しかし、そのチェックポインティングは、FT法の不可欠な部分です。 SとCビットをセットすると、ちょうどSビットを設定するのと同じ機能を実現します。
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ビットがセットされていない場合、ラベルはFTラベル番号順ではありません。代わりに、すべてのラベルには、チェックポイント可能なFTラベルです。チェックポインティングは、すべてのラベル交換を同期するために使用されます。いいえメッセージは、離れたチェックポイントの要求と肯定応答から、能動シーケンス番号を運びません。 （セッション初期化メッセージは、チェックポイントが所定の位置にあることを確認するためにシーケンス番号を運ぶことができることに留意されたいです）。
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ビットが設定されている両方の場合には、チェックポインティングは、シーケンス番号付きFTラベルにのみ適用され、メッセージに対処します。
The set of all messages check-pointed in this way is called the Check-Pointable Messages.
このように、チェックポイント全てのメッセージのセットは、チェックポイント可能なメッセージと呼ばれています。
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は、キープアライブメッセージにFT保護TLVを受信した場合、これは、セッションのすべての以前に受信したチェックポイント可能なメッセージの確認応答をフラッシュするための要求です。
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は、チェックポイント可能メッセージ（又はそれらのメッセージの結果としての状態変化）を確保完了したようにキープアライブ前に受信、それはキープアライブメッセージのシーケンス番号に確認応答を送信しなければなりません。
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手順が使用され、確認応答がアップ記憶されている場合には、これは、キープアライブを受信するとすぐに起こり得ます。
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".
状態の定期的なチェックポイントを実行するためのキープアライブメッセージのこの使用を示す例示的なメッセージフローは、セクション9.2の「チェックポインティングFTの手順の使用」を示しています。
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手続きなしにチェックポインティングの使用を示す一例のメッセージ・フロー「は、チェックポインティングFT手順なし」、セクション9.5に示されています。
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.
キープアライブメッセージは、FTコークTLVが含まれている場合、これは、ピアLSR前グレースフルリスタートにセッションを休止したいことを示しています。
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コルクTLVでキープアライブを受信すると、LSRは、セッション上の任意の更なるラベルまたはアドレスに関連するメッセージを送信するために生成されるメッセージ以外を停止することが推奨されていますピアからの静止を要求します。また、この処理を完了しようとすると、セッションが静止することができるようにするために、できるだけ早くFT ACK TLVでキープアライブを返す必要があります。
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".
2つのLDPピア間の状態同期の3ウェイハンドシェイクを達成するために、FTコークTLVのこの使用を示す例のメッセージフローは、「FTの手続きを一時停止し、チェックポインティングを」、セクション9.4に記載されています。
The LDP FT enhancements add the following optional parameters to a LDP Initialization message:
LDP FTの機能強化は、LDP初期化メッセージに次のオプションパラメータを追加します。
Optional Parameter Length Value
オプションのパラメータ長さ値
FT Session TLV 4 See Below FT ACK TLV 4 See Below
FTセッションTLVは、下記を参照してください。4フィートACK TLVは、以下を参照してください4
The encoding for these TLVs is found in Section 8, "New Fields and Values".
これらのTLVのエンコーディングは、第8節で「新しいフィールドと値を」発見されました。
FT Session TLV If present, specifies the FT behavior of the LDP session.
FTセッションTLVが存在する場合、LDPセッションの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が存在する場合、送信LDPピアが前LDPセッションの前のインスタンス化の失敗に確保することができた最後のFTメッセージを指定します。 FT再接続フラグがこのTLVが存在しなければならない場合にFTセッションTLVに設定されている場合は、このTLVにのみ存在します。
The LDP FT enhancements add the following optional parameters to a LDP Keepalive message:
LDP FTの機能強化は、LDPキープアライブメッセージに次のオプションパラメータを追加します。
Optional Parameter Length Value
オプションのパラメータ長さ値
FT Protection TLV 4 See below FT Cork TLV 0 See below FT ACK TLV 4 See below
FT保護TLVは、下記を参照してください4フィートACK TLVの下を参照してください0 FTコークTLVの下4参照します
The encoding for these TLVs is found in Section 8, "New Fields and Values".
これらのTLVのエンコーディングは、第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保護TLVが存在する場合、LDPメッセージのFTシーケンス番号を指定します。ときにキープアライブメッセージに存在し、これは、シーケンス番号を含むと同じセッションにキープアライブの送信者によって発行されたすべての以前のLDPメッセージに確認応答の募集フラッシュを示します。
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.
FTコークTLVは、リモートLSRは、LDPセッションを休止したいことを示します。そのような場合に推奨される処置のためのセクション5、「FT操作」を参照してください。
FT ACK TLV If present, specifies the most recent FT message that the sending LDP peer has been able to secure.
FT ACK TLVが存在する場合、送信LDPピアが確保できるようになりました最新のFTメッセージを指定します。
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の機能強化は、LDP初期化メッセージの後にLDPセッション上を流れる他のすべてのメッセージタイプに次のオプションパラメータを追加します
Optional Parameter Length Value
オプションのパラメータ長さ値
FT Protection TLV 4 See below FT ACK TLV 4 See below
FT保護TLVは、下記を参照してください4フィートACK TLVの下4参照します
The encoding for these TLVs is found in section 8, "New Fields and Values".
これらのTLVのエンコードは、セクション8に「新しいフィールドと値を」発見されました。
FT Protection TLV If present, specifies the FT Sequence Number for the LDP message.
FT保護TLVが存在する場合、LDPメッセージのFTシーケンス番号を指定します。
FT ACK TLV If present, identifies the most recent FT LDP message ACKed by the sending LDP peer.
FT ACK TLVが存在する場合、送信LDPピアによってACKさ最新のFT LDPメッセージを識別します。
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の強化に特有の様々な条件を示すために定義されています。これらのステータスコードは、通知メッセージのステータス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」の欄には、ステータスコードE-ビットの必要な設定です。 「ステータスデータ」欄には、ステータスコードTLVで30ビットのステータスデータフィールドの値です。
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.
ステータスコードFビットの設定はステータスTLVを発信するLSRの裁量であることに注意してください。しかし、メッセージの重複をホップ単位動作であることに限定する必要がありますので、Fビットが「いいえLDPセッション」以外のステータスコードを含む通知メッセージに設定されていないことが推奨されます。
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
ノーLDPセッション0 0x0000001AゼロFTのSEQNUM 1 0x0000001B予期しないTLV / 1 0x0000001Cセッション未FT予期しないTLV / 1 0x0000001Dラベル未FTミッシングFT保護TLV 1 0x0000001EをFT ACKシーケンスエラー1 0x0000001F一時停止0 0x00000020
FT Seq Numbers Exhausted 1 0x00000021 FT Session parameters / 1 0x00000022 changed Unexpected FT Cork TLV 1 0x00000023
FT配列番号は1つの0x00000021 FTセッションパラメータを使い果たし/ 1 0x00000022は、予期しないFTコルクTLVを変更し1 0x00000023
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.
それはFTを維持することができるように期待し、そのLDPピアに通知することを希望をシャットダウンされているLSR場合「一時停止」状態コードは、（Eビットがセットされている）「シャットダウン」ステータスコードの代わりに使用されてくださいラベルの状態とFT再接続タイマーの期限が切れる前にサービスに戻ります。
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.
LDPピアは、それらの間のLDPセッションがLDP初期化メッセージに、新しいオプションパラメータ、FTセッションTLVを使用してFT拡張をサポートしているかどうかを交渉することができます。
The FT Session TLV is encoded as follows.
次のようにFTセッション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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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フラグFTフラグ：さまざまな属性にこのLDPセッションの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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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：FT再接続フラグ。送付LSRは、の詳細については、同じLDPピア間の前のLDPセッション以降のすべてのFT-ラベルの状態とリソースを保存しており、それ以外の場合は、「FT手順TCP失敗した後、」0を参照してくださいセクション5.4に設定されている場合は1に設定しますどのようにこのフラグが使用されています。
If the FT Reconnect Flag is set, the sending LSR MUST include an FT ACK TLV on the LDP Initialization message.
FT再接続フラグが設定されている場合、送信LSRは、LDP初期化メッセージに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保護TLVの使用はチェックポインティングのために使用されるキープアライブメッセージ以外のメッセージ（Cビットを参照）に支持されている場合は1に設定。すなわち、SビットがセッションにいくつかのラベルがFTラベル番号順であってもよいことを示しています。
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 treating some labels as FT Labels and some labels as non-FT Labels.
A：全ラベルの保護に必要なセット1へのセッション上のすべてのラベルには、シーケンス番号付きFTラベルとして扱われなければならない場合。これは、ノードから非FTラベルとしてFTラベルおよび一部のラベルとして、いくつかのラベルを治療するためのオプションが削除されます。
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のビットがチェックポインティングのみシーケンス番号付きFTラベルに適用されることを示しています。
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ビットがチェックポインティングは、すべてのラベルに適用されることを示している - すべてのラベルがチェックポイント可能なFTラベルです。
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]の障害復旧手順は、ネットワークからの再学習の状態で使用される場合は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.
この分野における他のすべてのビットは、現在予約されており、変速機にゼロに設定し、受信時に無視されるべきです。
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.
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再接続タイムアウトFTのフラグ欄にSビットまたはCビットがセットされている場合、これは送信LSRがFTラベルの状態や資源を保護する時間の期間を示すが、最近失敗したFT LDPセッションの前のインスタンス化に交換しました。タイムアウトは、ミリ秒の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].
LビットはFTフラグに設定されている場合、復旧時間ザ・リカバリ時間は意味があります。意味は[RFC3478]で定義されています。
LDP peers use the FT Protection TLV to indicate that an LDP message contains an FT label operation.
LDPピアは、LDPメッセージがFTラベル操作が含まれていることを示すために、FT保護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.
FT保護TLVは、LDP FTの強化をサポートしていないLDPセッションに流れるメッセージに使用してはいけません。そのようなメッセージ中のその存在は、「予期しないTLVセッションていないFT」状態コードと通知メッセージを送るべきで受信LDPピアによりプロトコルエラーとして扱われます。このTLVを認識しないのLSRは、「不明なTLV」ステータスコードと通知メッセージで応答する必要があります。
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保護TLVは、LDP初期化メッセージの最初の交換の後LDPセッションに運ばLDPメッセージに対して実行することができます。特に、このTLVは、必要に応じて次のメッセージ上に存在することができます。
- Label Request Messages in downstream on-demand distribution mode.
- 下流のオンデマンド配信モードでのラベル要求メッセージ。
- Label Mapping messages in downstream unsolicited mode.
- 下流迷惑モードでのラベルマッピングメッセージ。
- Keepalive messages used to request flushing of acknowledgement of all previous messages that contained this TLV.
- このTLVを含まれているすべての以前のメッセージの確認応答のフラッシュを要求するために使用されるキープアライブメッセージ。
If a label is to be a Sequence Numbered FT Label, then the Protection TLV MUST be present:
ラベルはFTラベル番号順にする場合は、その後、保護TLVが存在しなければなりません。
- on the Label Request message in downstream on-demand distribution mode.
- 下流におけるラベル要求メッセージのオンデマンド配信モード。
- on the Label Mapping message in in downstream unsolicited distribution mode.
- 下流迷惑分散モードでのラベルマッピングメッセージに上。
- 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.
ここに、このラベルに関する後続のメッセージは、「そのラベルTLVまたはラベル要求メッセージID TLVは、最初のラベル要求メッセージを指定し、このラベルを指定する任意のメッセージを意味します。
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.
ラベルはFTラベル番号順ではないことがある場合は、保護TLVはラベルに関連するこれらのメッセージのいずれにも存在してはなりません。非FTラベルに関連するメッセージにFT TLVの存在は、「予期しないTLVラベルはありませんFT」状態コードと通知メッセージを送るべきで受信LDPピアによりプロトコルエラーとして扱われます。
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.
どこにラベル撤回またはラベルリリースメッセージは、FEC TLVが含まれており、メッセージによって影響を受ける任意のラベルは、シーケンス番号付きFTラベルである場合、単一の特定のラベル、FT TLVがメッセージに含まれるべき識別されません。 FT TLVが存在するかどうかに関してご不明な点がある場合、送信者がTLVを追加することをお勧めします。
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.
LDPピアは、ラベルが唯一のFECを含むメッセージやラベル解放メッセージを撤回受信すると、それは関係なく、それが影響したラベルの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.
LDPセッションがLDP初期化メッセージに設定されたSビットとFTセッションTLVの存在によって決定されるFTセッションがある場合は、FT保護TLVは、セッション上のすべてのアドレスのメッセージに存在しなければなりません。
If the session is an FT session, the FT Protection TLV may also optionally be present:
セッションは、FTセッションである場合、FT保護TLVはまた、必要に応じて存在してもよいです。
- on Notification messages on the session that have the status code 'Label Resources Available'.
- ステータスコード「ラベル・リソースが利用できる」持っているセッションの通知メッセージに。
- on Keepalive messages.
- キープアライブメッセージの。
The FT Protection TLV is encoded as follows.
次のようにFT保護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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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シーケンス番号このシーケンス番号付きFTラベル操作のシーケンス番号。シーケンス番号は32ビットの符号なし整数として符号化されます。新しいLDPセッションでこのフィールドの初期値は0x00000001のであり、このLDPセッションに送るLSRによって発行された各FT LDPメッセージを1つインクリメントします。このフィールドには0xFFFFFFFFのからは0x00000001に折り返すことがあります。
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.
いずれかのLDPピアがTCP接続の再確立時にFT再接続フラグを設定しない場合、このフィールドは0x00000001のにリセットする必要があります。
See section 5.2, "FT Operation Acks" for details of how this field is used.
このフィールドの使用方法の詳細については、セクション5.2、「FT操作ACKを」を参照してください。
The special use of 0x00000000 is discussed in the section 8.4, "FT ACK TLV" below.
0x00000000の特別な使用は、セクション8.4、以下、「FT ACK TLV」で説明されています。
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 LDPの拡張機能をサポートしていないセッションにFT保護TLVを受信した場合、それは予期しないTLV、セッション未FTのステータスコードを含むそのLDPピアへの通知メッセージを送信する必要があります。このTLVを認識しないのLSRは、「不明なTLV」ステータスコードと通知メッセージで応答する必要があります。
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ラベルであると考えているラベルに影響を与える操作上のFT保護TLVを受信した場合、それは予期しないTLV、ラベル未FTのステータスコードを含むそのLDPピアへの通知メッセージを送信する必要があります。
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ラベルであると考えているラベルに影響を与えるFT保護TLVなしでメッセージを受信した場合、それは行方不明FT保護TLVのステータスコードを含むそのLDPピアへの通知メッセージを送信する必要があります。
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がゼロFTシーケンス番号を含むFT保護TLVを受信した場合、それはゼロFT SEQNUM 'ステータスコードを含むそのLDPピアに通知メッセージを送るべきです。
LDP peers use the FT ACK TLV to acknowledge FT Label operations.
LDPピアはFTラベル操作を確認するために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は、LDP FTの強化をサポートしていないLDPセッションに流れるメッセージに使用してはいけません。このようなメッセージにその存在が受信LDPピアによりプロトコルエラーとして扱われます。
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は初期LDP初期化メッセージの後にLDPセッション上で交換任意のLDPメッセージ上に存在することができます。 FT ACK TLVは、LDPピアが未確認の状態情報の大規模なバックログを構築していないことを保証するために、すべてのFTキープアライブメッセージに含まれることが推奨されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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シーケンス番号送信LDPピアが受信LDPピアから受信したLDPセッションの障害が発生しないように固定している最新のFTラベルメッセージのシーケンス番号。送信ピアは完全にそれを肯定応答（ACK）する前に、メッセージを処理していることが必要ではありません。例えば、LSRは、できるだけ早くそれがしっかりとそれが応答したラベルマッピングメッセージを送ることができるまで待つことなく、メッセージを記録しているようにラベル要求メッセージをACKするかもしれません。
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).
ACKが累積されます。 12のFT ACKシーケンス番号を有するFT ACK TLVを含むLDPメッセージの受信は、（LDPセッションが1のシーケンス番号で開始と仮定して）1から12まで含めたすべてのメッセージの確認応答として扱われます。
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はこのLDPセッション上の任意のFTラベル操作を受信していない場合、このフィールドは0に設定しなければなりません。これは、新しいLDPピアまたはLSRが、それが失敗したTCP接続のためにすべての状態をドロップする必要があると判断した後、LDPセッションに適用されます。
See section 5.2, "FT Operation Acks" for details of how this field is used.
このフィールドの使用方法の詳細については、セクション5.2、「FT操作ACKを」を参照してください。
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シーケンス番号よりも小さいFT ACKシーケンス番号が含まれているFT ACK TLVを受信した場合、それは「FT ACKを含むそのLDPピアへの通知メッセージを送信する必要があります（ラッピングを考慮して覚えます）シーケンスエラー」ステータスコード。
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.
LDPピアは、彼らがコントロールプレーンソフトウェアのアップグレード中に、たとえば、前制御シャットダウンと再起動にLDPセッションを休止したいことを示すためにFTキープアライブメッセージにFTコークTLVを使用します。
The FT Cork TLV is encoded as follows.
次のようにFTコーク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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upon receipt of a Keepalive message with the FT Cork TLV and the FT Protection TLV, an LSR SHOULD perform the following actions:
FTコークTLVとFT保護TLVとキープアライブメッセージを受信すると、LSRは次のアクションを実行する必要があります。
- 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保護TLVに含まれる（ラップを占める）よりも小さいシーケンス番号を有するピア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).
- 元のキープアライブメッセージ（すなわち、その時点までにすべてのメッセージを肯定応答（ACK））と同等FT ACKシーケンス番号を指定FTコークTLV及びFT ACK TLVを含むピアにキープアライブメッセージを送信します。
- 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.
- このLSRはまだそれがFT保護TLVを含む送信されたすべてのメッセージにFT ACKを受信していない場合、また、ピアLSRに送られたキープアライブにFT保護TLVが含まれます。これは、ローカルLSRが静止する前の状態を保存しているが、まだリモートピアが状態を保存していることの確認を待っていることをリモートピアに伝えます。
- Cease sending any further state changing messages on this LDP session until it has been disconnected and recovered.
- それは切断され、回収されるまで、このLDPセッション上の任意の更なる状態変更メッセージを送信を停止。
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 now send a "Temporary Shutdown" Notification message, disconnect the TCP session and perform whatever control plane actions required this session shutdown.
FTコークTLVを実施し、以前に送信されたキープアライブを認めるFTコークTLVとFT ACK TLVとキープアライブメッセージを受信すると、LSRは完全な静止であることを知っています。受信キープアライブもFT保護TLVを運ぶ場合、LSRは、3ウェイハンドシェイクを完了するために、さらにキープアライブで応答しなければなりません。今では、「一時停止」の通知メッセージを送信する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ウェイハンドシェイクの例は、「FTの手続きを一時停止し、チェックポインティングを」、セクションセクション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コークTLVを運ぶべきではないメッセージを受信し、又はFTコークTLVをFT保護またはFT ACKのTLVの存在なしでキープアライブメッセージに使用される場合、それが含有するそのLDPピアに通知メッセージを送信する必要がある場合「予期しないFTコークTLV」ステータスコード。
Consider two LDP peers, P1 and P2, implementing LDP over a TCP connection that connects them, and the message flow shown below.
それらを接続するTCP接続、及び以下に示すメッセージ・フロー上LDPを実現二LDPピア、P1とP2を考えます。
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.
A「 - 」FT ACK番号のは、FT ACK TLVは、そのメッセージに含まれていないことを意味します。 「N / A」、問題のパラメータは、メッセージのタイプに適用されないことを意味します。
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確保または処理のためにメモを参照。
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,-)
<---------------------------
(10) ===== TCP Session lost =====
:
(11) : Label Withdraw(L1,59,-)
: <--------------------------
:
(12) === TCP Session restored ===
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,-)
<---------------------------
Notes: ======
注：======
(1) Assume that the LDP session has already been initialized. P1 issues 2 new Label Requests using the next sequence numbers.
（1）LDPセッションがすでに初期化されていると仮定します。 P1は、次のシーケンス番号を使用して2つの新しいラベル要求を発行します。
(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にラベル要求を発行します。この要求を送信する時に、P2はP1からL1のラベル要求の受信を確保しているので、そのメッセージに対するACKを含みます。
(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のラベルの要求を処理し、下流に転送します。下流の処理の詳細は、上記の図に示されていません。
(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は、P1に転送L1、のために下流からラベルマッピングを受け取ります。そのメッセージは、現在確保して処理されているように、それは、L2用ラベル要求に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は、P1に転送さL2のラベルマッピングを受け取ります。それはP1から任意のメッセージをさらに受信していないので、この時間は、それはACKが含まれていません。
(6) Meanwhile, P1 sends a new Address Message to P2.
（6）一方、P1はP2に新しいアドレスメッセージを送信します。
(7) P1 also sends a fourth Label Request to P2
（7）P1も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は、キープアライブが送信された時点で受信され、固定された最新メッセージP1であるL1のラベルマッピングのためのACKを含む上P2にキープアライブメッセージを送信します。
(9) P2 issues a Label Abort for L3.
（9）P2は、L3のラベルアボートを発行します。
(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.
TCPセッションがダウンしている間（11）、P2は、ラベルは、それがキュー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セッションが再接続され、それぞれ受信され、前の失敗に固定ピア最後のメッセージのACKを含む回収セッションにP1とP2交換LDP初期化メッセージ、。
(13) From the LDP Init exchange, P1 determines that it needs to re-issue the Label request for L4.
（13）LDP初期交換から、P1は、L4の再発行ラベル要求する必要があると判断します。
(14) Similarly, P2 determines that it needs to re-issue the Label Mapping for L2 and the Label Abort.
（14）同様に、P2は、それが再発行L2とラベルアボートのラベルマッピングをする必要があると判断します。
(15) P2 issues the queued Label Withdraw to P1.
（15）P2は、キューに入れられたラベルは、P1に撤退発行します。
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:
======
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.
（7）を介してノート（1）は、確認応答がピギーバック逆方向メッセージでないことに注意を除いて、前の例のようです。これは、ノート（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保護TLVを含むキープアライブメッセージを送信し、それが格納された状態のP2の知覚に興味がないので、それはFT ACK TLVを含んでいません。
(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）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と状態を同期することを望みます。それはP3もFT ACK TLVは、シーケンス番号124まで認める含むことによって、P2への謝辞と最新に取得するには、この機会を取るシーケンス番号59とFT保護TLVを含むキープアライブメッセージを送信します。
(11) P2 responds at once with a Keepalive acknowledging the sequence number on the received Keepalive.
（11）P2は、受信されたキープアライブにシーケンス番号を確認応答キープアライブで一度に応答します。
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,-)
<---------------------------
(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,-)
<---------------------------
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は、それが実行されているソフトウェアまたはハードウェアをアップグレードする必要があります。これは、LDPセッションを終了するには、通知メッセージを発行し、これは致命的なエラーではないことをP2を知らせるための「一時的なシャットダウン」などのステータスコードを設定し、P2は、FTの状態を維持する必要があります。 TCP接続も（それが再確立する必要があります。その場合には）LDPセッションがダウンしている期間中に失敗する可能性がありますが、TCP接続が維持されることも可能です。
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,-)
<---------------------------
Notes: ======
注：======
This example operates much as the previous one. However, at (1), (2), (3), (4) and (5), no acknowledgements are made.
この例では、前の1ほどを運営しています。ただし、で（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）では、P1は、正常なシャットダウンが必要であると判断し、すべての以前に受信したメッセージを承認キープアライブを送信し、それ自体がFT保護TLV番号及びFTコークTLVを含みます。
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.
（8）P2は、すべてのメッセージがこれまでに受け取っ認めキープアライブを送信するだけでなく、認知される未処理のメッセージが残っていることを示すためにFT保護とFTコークTLVを含んでなるラベルは、（7）このキープアライブと交差で中止します。
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）で回復すると、キープアライブが確認応答をフラッシュするので、再送信するメッセージはありません。復旧後に送信されたメッセージだけではラベルはそれがTCPセッションの障害時に保留された引き出しです。
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)
<---------------------------
Notes: ======
注：======
(1), (2) and (3) show label distribution without FT sequence numbers.
（1）、（2）及びFTシーケンス番号なし（3）を表示するラベル配布。
(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は未確認ラベル配布要求を再開する。
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)
--------------------------->
Notes: ======
注：======
(1), (2) and (3) show label distribution without FT sequence numbers.
（1）、（2）及びFTシーケンス番号なし（3）を表示するラベル配布。
(4) A check-point request from P1. It carries the sequence number of the check-point request and a Cork TLV.
（4）P1からチェックポイントの要求を。それは、チェック・ポイントの要求とコルクTLVのシーケンス番号を運びます。
(5) P1 has sent a Cork TLV so quieces.
（5）P1はquiecesようコルクTLVを送信しました。
(6) P2 confirms the check-point and continues the three-way handshake by including a Cork TLV itself.
（6）P2がチェックポイントを確認し、コークTLV自体を含むことにより、スリーウェイハンドシェイクを続行します。
(7) P1 completes the three-way handshake. All operations have now been check-pointed and the session is quiesced.
（7）P1は、スリーウェイハンドシェイクを完了する。すべての操作は現在、チェックポイントとなっていると、セッションが静止しています。
(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は、以前に受信したラベル配布要求の処理を継続します。
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の強化などの追加サービス拒否攻撃に脆弱この文書で指定された拡張を実装するのLSRをレンダリング確立ラベルの属性の完全な再交換、なしのLDPピア間のTCP接続の再確立を許可します次のとおりです。
- 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.
- 侵入者は、TCP接続の失敗および再接続を強制するために、LDPピアになりすますことができるが、ここで、侵入者は、再接続時にFT再接続フラグを設定しません。これは、すべての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再接続フラグを設定することができます。
- 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.
- 侵入者はLDPピア間のトラフィックをインターセプトし、すべてのラベルのために0に設定するFTラベルフラグの設定をオーバーライドすることができます。
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ベースの方式としてLDPピア間の認証スキームを使用することによって対抗することができます。
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ピアのための代替認証スキームは、この文書の範囲外ですが、LDPおよび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が川下の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再接続タイムアウトによって拡張することができる、とのセッションは、この期間内に再確立することができます。再接続タイムアウトの満了後、セッションは失敗したとみなされ、上記と同様のセキュリティ上の問題が適用されなければなりません。
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はセッションを宣言することがあります。これは、アップストリームLSRがラベルの古い使用を使用してデータを送信し続けながら下流LSRがラベルを再割り当て可能性のある期間を増加させます。この問題を軽減するために、この文書は再接続タイムアウトが経過するまでのラベルが再使用されないことが必要です。
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再接続タイムアウトの満了前に再使用されたが、これは、この文書により禁止されている場合は、さらに問題が適用される場合があります。
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.
ラベルの再利用の問題は、他のラベル配布プロトコルを介した直接管理アプリケーションを通じて構成や分布などの他のメカニズムを介して管理ラベルに及びます。この問題を回避することは実装上の問題（下記参照）、それはいくつかの他のメカニズムを使用して確立されたLSPと、この文書に記載された方法を用いて回収し、それらの間でデータの誤転送をもたらす可能性が確認に失敗すると解釈されてもよいです。
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.
ネットワーク内のLSRの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を考慮し、それは完全にトレラントLSRフォールト、P2のLDPピアです。 P2はP1とP2の間にLDPセッションを提供していますハードウェアまたはソフトウェアに障害が発生した場合、それはピア間のTCP接続を失敗することがあります。接続が回復したとき、両方のLSRは、LDPセッションにFT回復手順を適用した場合、P1とP2との間のLSP /ラベルのみを回収することができます。
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 ACKはLSRで未確認の状態変化を大量に構築避けるために実用的であるとすぐに送信LSRに返されるべきです。しかし、すぐに1対1の確認応答が不必要な帯域幅を浪費することになります。
A possible implementation strategy for sending ACKs to FT LDP messages is as follows:
次のようにFT LDPメッセージにACKを送信するための可能な実装戦略は次のとおりです。
- An LSR secures received messages in order and tracks the sequence number of the most recently secured message, Sr.
- LSRが順番に受信したメッセージを確保し、最近で固定したメッセージ、シニアのシーケンス番号を追跡
- On each LDP KeepAlive that the LSR sends, it attaches an FT ACK TLV listing Sr.
- LSRが送信する各LDPキープアライブで、それはシニアをリスト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.
- 最後のACKが送信されるので、例えば、Srが閾値を超えて増加した場合など必要に応じて、LSRは、キープアライブメッセージの間で送信される任意の他のLDPメッセージにFT ACK TLVを取り付けることができます。
This implementation combines the bandwidth benefits of accumulating ACKs while still providing timely ACKs.
この実装はまだタイムリーなACKを提供しながら、ACKを蓄積する帯域幅の利点を兼ね備えています。
If check-pointing is in use, the LSRs need not be concerned with sending ACKs in such a timely manner.
チェックポインティングを使用している場合、のLSRは、適時にACKを送ることを心配する必要はありません。
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.
チェックポイントは、キープアライブメッセージにFT保護TLV内のシーケンス番号として搬送肯定応答するための要請です。このようなチェックポイント要求は変更にかなりの量の後、タイマーに発行された、またはセッションの制御シャットダウンの前にすることができます。
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.
それはすべての受信LDPメッセージのシーケンス番号を追跡する必要はありませんので、チェックポインティングの使用はかなりの実装を簡素化することができます。それは、しかし、まだすべての受信メッセージ（あるいはその結果としての状態変化）がキープアライブのシーケンス番号を確認する前に固定されていることを確認する必要があります。
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.
このアプローチは、（LDPセッションを目標など）および最新のLDP交換のための状態の損失を危険にさらして準備されていること経時変化の高度を示さないシステムに最適と考えることができます。 （例えばLDPディスカバリセッションなど）よりダイナミックなシステムが状態の最大量は、障害の上に保存することができるように、より頻繁に状態の変化を確認したい可能性が高くなります。
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.
多くの自民党のLSRは、他のラベル配布メカニズムを実行します。これらは、管理静的ラベルマッピングの構成のためのインターフェース、LDPの他の異なるインスタンス、及び他のラベル配布プロトコルを含みます。最後の例では、LDPのLSPが確立されるときに通過するトンネルを構築するために使用されるトラフィックエンジニアリングラベル配布プロトコルを含みます。
As with re-use of individual labels by LDP within a restarting LDP system, care must be taken to prevent labels that need to be retained by a restarting LDP session or protocol component from being used by another label distribution mechanism since that might compromise data security amongst other things.
再起動LDPシステム内のLDPによって、個々のラベルの再利用と同様に、ケアは、データのセキュリティを危険にさらす可能性があるので、別のラベル分配機構で使用されてから再起動するLDPセッションまたはプロトコルコンポーネントによって保持する必要のあるラベルを防ぐために注意する必要がありますそのことなど。
It is a matter for implementations to avoid this issue through the use of techniques such as a common label management component or segmented label spaces.
実装は、このような共通のラベル管理コンポーネントまたはセグメント化されたラベルスペースなどの技術を使用してこの問題を回避することが問題です。
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].
この文書で使用されているACKスキームは今[BGP-RESTART]に含まBGPセッションを再開するためのデビッド・ウォードとジョン・スカダーの提案に触発されました。
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.
著者らはまた、慎重に検討し、ニック・雑草、埠頭フィンレイソン、ティム・ハリソン、ダンカンアーチャー、ピーター・アッシュウッド・スミス、ボブ・トーマス、S. Manikantan、アダム・シェパード、アラン・デイヴィー、イフテックハーフセインとロア・アンダーソンのコメントを確認したいと思います。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
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は、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification, RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、「LDP仕様、RFC 3036、2001年1月。
[RFC3478] Leelanivas, M., Rekhter, Y. and R. Aggrawal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478] Leelanivas、M.、Rekhter、Y.、およびR. Aggrawal、 "ラベル配布プロトコルのためのグレースフルリスタートメカニズム"、RFC 3478、2003年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、機能仕様"、RFC 2205、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リフレッシュ縮小拡張"、RFC 2961、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.、スリニバサン、V.およびG.ツバメ、 "LSPトンネルのためのRSVPの拡張"、RFC 3209、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.、Worster、T.、フェルドマン、N.、Fredette、A.、Girish、 M.、グレー、E.、Heinanen、J.、Kilty、T.およびA. Malis、 "LDPを使用して、制約ベースLSPセットアップ"、RFC 3212、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.、アッシュウッド・スミス、P.、Jamoussi、B.、Fedyk、D.、Skalecki、D.およびL.リー、 "CR-LDPを使用してLSP変更"、RFC 3214 、2001年1月。
[BGP-RESTART] Sangli, S., et al., Graceful Restart Mechanism for BGP, Work in Progress.
[BGP-RESTART]サングリ、S.、ら。、BGP、進行中の作業のためのグレースフルリスタートメカニズム。
Adrian Farrel (editor) Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
エイドリアン・ファレル（エディタ）Movazネットワークス株式会社7926ジョーンズ支店ドライブ、スイート615マクリーン、VA 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
ポール・ブリテインデータ接続株式会社ウィンザーハウス、ペッパーストリート、チェスター、チェシャーCH1 1DF、英国
Phone: +44-(0)20-8366-1177 EMail: pjb@dataconnection.com
電話：+ 44-（0）20-8366-1177 Eメール：pjb@dataconnection.com
Philip Matthews Hyperchip 1800 Rene-Levesque Blvd W Montreal, Quebec H3H 2H2 Canada
フィリップ・マシューズHyperchip 1800ルネ・レベスクブルバード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オーチャードパークウェイサンノゼ、CA 95134
Phone: +1 408 432 7623 EMail: jack.shaio@vivacenetworks.com
電話：+1 408 432 7623 Eメール：jack.shaio@vivacenetworks.com
Toby Smith Laurel Networks, Inc. 1300 Omega Drive Pittsburgh, PA 15205
トビー・スミスローレルネットワークス株式会社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オーチャードパークウェイサンノゼ、CA 95134
Phone: +1 408 383 7223 EMail: andy.malis@vivacenetworks.com
電話：+1 408 383 7223 Eメール：andy.malis@vivacenetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。