[要約] RFC 3479は、Label Distribution Protocol（LDP）の障害耐性に関する要件とガイドラインを提供する。目的は、LDPの信頼性と可用性を向上させ、ネットワークの障害に対する耐性を確保することである。
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)
ラベル分布プロトコル（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.
Copyright（c）The Internet Society（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.
この仕様には、MPLS LDP制御トラフィックを運ぶTCP接続の障害検出とフェールオーバーの手順が含まれているため、新しいTCP接続に切り替えることができます。複数のTCP接続を使用して、この種の断層トレランスを提供する一般的なアプローチは提供されません。この仕様には、TCP接続フォールトトレランス手順に関連するタイマーおよび再試行値の選択に関する適切なガイダンスがありません。仕様は、将来のドキュメントのTCP接続フォールトトレランス設計のモデルとして機能するものではなく、ユーザーは、この仕様に基づいて、早期フェールオーバーなどの問題について非常に慎重に構成をテストすることをお勧めします。
Abstract
概要
Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS Label Switching Routers (LSRs) may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks.
マルチプロトコルラベルスイッチング（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.
ラベル分布プロトコル（LDP）、スイッチングハードウェア、TCPなど、FT LSRのさまざまなコンポーネントでFTがどのように達成されるかの詳細は、実装固有です。このドキュメントは、RFC 3036のLDP仕様「LDP仕様」の問題を特定し、現在のLDPプロトコルを使用してFT LSRを実装することを困難にし、LDP仕様の強化を定義してFT LSR実装を容易にします。
The issues and extensions described here are equally applicable to RFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP).
ここで説明する問題と拡張機能は、RFC 3212、「LDPを使用した制約ベースのLSPセットアップ」（CR-LDP）に等しく適用できます。
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：an 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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％（5 9S）の可用性レベルを達成した場合、高可用性（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：1）でプロビジョニングされることがあり、時には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.
LDPはTCPを使用して、LSR間の信頼性の高い接続を提供し、プロトコルメッセージを交換してラベルを配布し、LSPをセットアップします。このような接続を持つLSRのペアは、LDPピアと呼ばれます。
TCP enables LDP to assume reliable transfer of protocol messages. This means that some of the messages do not need to be acknowledged (for example, Label Release).
TCPにより、LDPはプロトコルメッセージの信頼できる転送を引き受けることができます。これは、一部のメッセージを確認する必要がないことを意味します（たとえば、ラベルのリリース）。
LDP is defined such that if the TCP connection fails, the LSR should immediately tear down the LSPs associated with the session between the LDP peers, and release any labels and resources assigned to those LSPs.
LDPは、TCP接続が失敗した場合、LSRがLDPピア間のセッションに関連付けられたLSPを直ちに取り壊し、それらのLSPに割り当てられたラベルとリソースをリリースするように定義されています。
It is notoriously 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.
- 以前のLDPメッセージの最新の承認（チェックポイント）の勧誘は、現在の状態がディスク/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.
- これらの拡張機能をLDPに実装していないLSRを使用して、後方互換性を提供します。
- preserve existing protocol rules described in [RFC3036] for handling unexpected duplicate messages and for processing unexpected messages referring to unknown LSPs/labels.
- [RFC3036]に記載されている既存のプロトコルルールを保存し、予期しない重複メッセージを処理し、不明なLSP/ラベルを参照する予期しないメッセージを処理します。
- avoid full state refresh solutions (such as those present in RSVP: see [RFC2205], [RFC2961], [RFC3209] and [RFC3478]) whether they be continual, or limited to post-failover recovery.
- 完全な状態リフレッシュソリューション（RSVPに存在するもの：[RFC2205]、[RFC2961]、[RFC3209]、[RFC3478]を参照）を避けてください。
Note that this document concentrates on the preservation of label state for labels exchanged between a pair of adjacent LSRs when the TCP connection between those LSRs is lost. This is a requirement for Fault Tolerant operation of LSPs, but a full implementation of end-to-end protection for LSPs requires that this be combined with other techniques that are outside the scope of this document.
このドキュメントは、これらの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 address how to provide automatic layer 2 or layer 3 protection switching for a label or LSP, which is a separate area for study.
特に、このドキュメントでは、[RFC3214]でカバーされているラベルまたはLSPに割り当てられたLSPまたはリソースのルーティングを変更する方法を説明しようとしていません。また、このドキュメントでは、ラベルまたは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.
- LDP初期化メッセージで交換されたFTの再接続タイムアウトは、TCP接続の障害後にピアLSRがFTラベル状態を保持する最大時間を示すことを示します。
- 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.
- LDPラベルに影響を与える操作を特定するために使用されるFT保護TLV。FT保護TLVを運ぶすべてのLDPメッセージを保護する必要があり（たとえば、NVRAMに）、LDPピアを送信するために、LDPセッションの再接続後にシーケンス番号のFTラベルの状態を正しく回復できるようにする必要があります。
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操作を確認するために、KeepAliveメッセージで使用することもできます。これにより、セッション中または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セッション中にLDP FTの拡張機能を使用しないでください。これらの場合に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.
- ソケット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ラベルを脱プログラムするなど、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ピアは、LDPセッションで交換されるFTラベルに関連する州の情報とリソースを保持する必要があります。両方の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セッションに適用する予定です。LDP初期化メッセージのFTセッションTLVで行われます。両方のLDPピアは、LDP初期化交換から提案された2つのタイムアウト値のより低いタイムアウト間隔に対応する値を使用する必要があります。ここで、ゼロの値は正の無限として扱われます。
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のFT再接続フラグを1に設定する必要があります。それ以外の場合は、FTの再接続フラグを0に設定する必要があります。
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ピアがFTの再接続フラグを0に設定するか、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ピアがFTの再接続フラグを1に設定した場合、両方の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の再接続フラグをクリアして送信した初期化メッセージに応じてFT再接続フラグを使用してLDP初期化メッセージを受信した場合、セッションではどちらのピアによっても状態が保持されていないかのように動作する必要があります。
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セッションの再接続または時期順に再接続すると、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ラベル上の通常の操作では、謝辞は通常の処理中に延期され、定期的にのみ送信される場合があります。チェックポイントは、そのメッセージと以前のすべてのメッセージの承認を要求するKeepaliveメッセージにシーケンス番号を含めることにより、ピアからの確認のフラッシュに使用できます。この場合、すべてのシーケンス番号付き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.
これにより、謝辞をすべてのメッセージに送信したり、頻繁に送信したりする必要はありませんが、KeepAliveメッセージに掲載されたリクエストに応じてチェックポイントとしてのみ送信されるアプローチが提供されます。このようなアプローチは、時間の経過とともに高度な変化を示さず（ターゲットを絞った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.
ただし、これは一方向での確認のみを提供し、終了しているノードには、ピアが送信したすべての状態を確保したことを確認する必要があります。これは、KeepAliveメッセージで追加のTLV（コルクTLV）によって要求されるチェックポイントの3方向の握手によって達成されます。
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に適用できます。トンネル付きLSPは、パスに沿った各ホップの別のLDPセッションでトンネルが管理されている一方で、単一のLDPセッションで管理されていることを思い出してください。それにもかかわらず、トンネルを管理するセッションの1つでの休憩は、トンネルLSPを管理するセッションの休憩に対応する可能性があります。これは確かに、LDP交換が失敗したリンクを共有している場合に当てはまりますが、LDPメッセージがトンネルのパスとは異なるパスに沿ってルーティングされている場合、またはトンネル内の障害が原因である場合はそうではありません。Transit 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]の手順の1つを使用する必要があります。
It is perfectly acceptable to mix the restart procedures used for the tunnel and the tunneled LSP. For example, the tunnel could be set up using just check-pointing because it is a stable LSP, but the tunneled LSPs might use full FT procedures so that they can recover active state.
トンネルとトンネルLSPに使用される再起動手順を混合することは完全に受け入れられます。たとえば、トンネルは安定したLSPであるため、単なるチェックポイントを使用してセットアップできますが、トンネル付き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セッションが確立されたら、セクション4.1「FT LDPセッションの確立」で説明されているセッション初期化メッセージのFTセッションTLVのSビットを使用して、両方のLDPピアがこのセクションで説明した手順をFTに適用する必要があります。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 Protection TLVを運ぶKeepAliveメッセージを使用して、完全なラベル転送状態の定期的な保存を実現することを望んでいる実装の好みのオプションかもしれません。
If a label is a Sequence Numbered FT Label, all LDP messages affecting that label MUST carry the FT Protection TLV so that the state of the label can be recovered after a failure of the LDP session.
ラベルがシーケンス番号付き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ラベルになっていないことです。この場合、KeepAliveメッセージを使用したチェックポイントは、セッションで交換されたすべてのメッセージに適用されます。
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が存在または存在しない場合があります。
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ラベルにプラットフォーム全体のラベルスペースが使用されている場合、ラベルが渡されたすべてのLDP FTピアが、明示的なラベルの撤回/ラベルのリリースによってFTラベルの引き出しを認めているまで、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ピアはすべてのアドレスが撤回されたと考える必要があります。LDPピアは、[RFC3036]で指定されているように、すべての有効なアドレスに対して新しいアドレスメッセージを発行する必要があります。
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.
LDPでは、下流の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は、LSR Aがメッセージを受信して安全な状態をクリアしたことを確認できるように、通知 - ラベルリソースでシーケンス番号を使用する必要があります。
However, the following options also exist:
ただし、次のオプションも存在します。
- The downstream LSR may choose to not include a sequence number on Notification - Label Resources Available. This means that on session re-establishment it does not know what its peer thinks the LSR's resource state is, because the Notification may or may not have been delivered. Such an implementation MUST begin recovered sessions by sending an additional Notification - Label Resources Available to reset its peer.
- ダウンストリームLSRは、通知 - ラベルリソースにシーケンス番号を含めないことを選択できます。これは、セッションの再確立で、通知が配信された場合とそうでない可能性があるため、ピアが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 ACK TLVに渡されたFTシーケンス番号によるものです。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 LDPメッセージ（つまり、FT保護TLVを含む）ごとに1つずつ増加します。FTシーケンス番号が関連付けられているFT LDPセッションでこのLSRによって発行されます。
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を含むメッセージを受信した場合、このメッセージ（またはメッセージの処理から派生した状態情報）を確保するための手順を取る必要があります。メッセージが固定されたら、Ackedにする必要があります。ただし、LSRにはこのACKをすぐに送信する必要はありません。
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メッセージを受信した場合、シーケンス番号4を備えた単一のACKを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（同じシーケンス番号を認める2つの連続したメッセージ）は許容されます。
If an LDP peer discovers that its sequence number space for a specific session is full of un-acknowledged sequence numbers (because its partner on the session has not acknowledged them in a timely way), it cannot allocate a new sequence number for any further FT LPD message. It SHOULD send a Notification message with the status code 'FT Seq Numbers Exhausted'.
LDPピアが、特定のセッションのシーケンス番号スペースが未承認のシーケンス番号でいっぱいであることを発見した場合（セッションのパートナーがタイムリーにそれらを認めていないため）LPDメッセージ。ステータスコード「Ft seq番号が使い果たされた」で通知メッセージを送信する必要があります。
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ピアは、TCP接続が失敗したときにそのLDPセッションで交換されるFTラベルに関連する状態情報とリソースをリリースしてはなりません。これは[RFC3036]に反しますが、TCP接続の再接続後にFTラベルのラベル操作を完了することができます。
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ラベルに関連付けられたリソース（特に帯域幅）をリリースする必要があります。上流のLDPピアは、TCP接続が中断された場合にラベル操作を再発行する必要があるため、ラベルに関連付けられたリソースをリリースしても、シーケンス番号付き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ピアは、州の情報の完全性の喪失の内部知識、またはLDP操作を抑える（またはキュー）継続できないことに関する内部知識に基づいて州情報を公開することを選択することができます（セクション5.4.1、「TCP障害中のLDP操作」で説明されています。）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がステータスコードにeビットセットを使用してステータスTLVを受信し、TCP接続を閉じる原因となる場合、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].
非FTラベルに関連する州の情報とリソースのリリースは、[RFC3036]に記載されているとおりです。
Note that a Label Release and the acknowledgement to a Label Withdraw may be received by a downstream LSR in any order. The downstream LSR MAY release its resources upon receipt of the first message and MUST release its resources upon receipt of the second message.
ラベルのリリースとラベルの撤回に対する謝辞は、任意の順序で下流の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接続の障害を発見または通知した場合、FT再接続タイマーを起動して、LDPピア間のTCP接続の再接続を可能にする必要があります。
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ピア間のネットワークの性質、およびTCP接続の以前のインスタンス化で選択したFT再接続タイムアウトを考慮に入れることをお勧めします（ある場合）。
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.
FT再接続タイムアウト期間内にTCP接続を再確立できない場合、このタイムアウトを検出するLSRは、失敗したLDPセッションのために保存されたすべての状態をリリースするはずです。その後、TCP接続が再確立された場合（たとえば、新しいLDPセッションをセットアップするためのHello Exchangeの後）、LSRは、このタイムアウトイベントの保存状態情報をリリースした場合、FT再接続フラグを0に設定する必要があります。
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".
FT再接続タイムアウト内でTCP接続が正常に再確立された場合、両親はTCP接続障害によって中断されたLDP操作を再発行する必要があります。この手順は、セクション5.5「TCP再接続後のFT手順」で説明されています。
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接続が現在失敗しているLDPピアに新しいFT LDP操作を発行する必要があると判断した場合、TCP接続時にLDPピアで操作（例えばキュー）を抑制し、その操作を完了する必要があります。TCP接続の障害中にその後の追加操作によってラベル操作がオーバーライドされない限り、復元されます（TCP再接続後のセクション5.5「FT手順」を参照）。
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は、操作を抑えることができない（または不本意）可能性があります。たとえば、LDPピア間でTCPが動作できない間に主要なルーティング遷移が発生した場合、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操作を受け取ったFT LDP操作をすぐに処理できます（ラベル操作を転送するのに十分な状態が保持される場合）上流または下流に正しく転送されます。既存のFTラベルの操作は、TCPセッションの障害中に失敗してはなりません。
It is RECOMMENDED that Label Request operations for new FT Labels not be pended awaiting the re-establishment of TCP connection that is awaiting recovery at the time the LSR determines that it needs to issue the Label Request message. Instead, such Label Request operations SHOULD be failed and, if necessary, a notification message containing the 'No LDP Session' status code sent upstream.
新しいFTラベルのラベルリクエスト操作は、LSRがラベルリクエストメッセージを発行する必要があると判断したときに回復を待っているTCP接続の再確立を待っていないことをお勧めします。代わりに、そのようなラベル要求操作は失敗し、必要に応じて、「LDPなしセッションなし」ステータスコードを含む通知メッセージが上流に送信されます。
Label Requests for new non-FT Labels MUST be rejected during TCP connection failure, as specified in [RFC3036].
[RFC3036]で指定されているように、TCP接続障害中に新しい非FTラベルのラベル要求は拒否する必要があります。
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再接続タイムアウトの手順は、TCP障害中に発生した操作を抑えることができない（または不本意な）いずれかのLDPピアが発生することができない（または、セクション5.4.1、「TCP障害中のLDP操作」）の結果として呼び出された可能性があります。
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.
何らかの理由で、LSRがセクション5.4.1「TCP障害中のLDP操作」に記載されているように、LSRがLDPピアに関して操作を行うことができなかった場合、LSRはFTの再接続フラグを再接続フラグに設定する必要があります。そのLDPピアへの接続は、FT状態が保存されていないことを示しています。
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ピアによってアクセスされないメッセージを再発行するための次のルールにつながります。
- 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接続障害中のPENDIND（セクション5.4.1、「TCP障害中のLDP操作」を参照）を参照）は、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.
上記のルールに従って「Net-Zero」FTラベル操作の決定は、キューリソースの使用を最適化するために、TCP接続が再確立される前に、PEDNEDメッセージで実行される場合があります。TCP接続障害の前にLDPピアに送信されたメッセージ、またはそれらとペアになったペンディングメッセージは、FT ACK TLVが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がKeepAliveメッセージで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がKeepAliveの前に受信したチェック可能なメッセージ（またはそれらのメッセージに起因する状態の変更）の確保を完了するとすぐに、KeepAliveメッセージのシーケンス番号に確認を送信する必要があります。
In the case where the FT procedures are in use and acknowledgements have been stored up, this may occur immediately upon receipt of the Keepalive.
FT手順が使用されており、謝辞が保存されている場合、これはKeepAliveの受信後すぐに発生する可能性があります。
An example message flow showing this use of the Keepalive message to perform a periodic check-point of state is shown in section 9.2, "Use of Check-Pointing With FT Procedures".
状態の定期的なチェックポイントを実行するためのキープライブメッセージのこの使用を示すメッセージフローは、セクション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手順なしでチェックポイントの使用を示すメッセージフローの例は、セクション9.5「FT手順なしのチェックポイント」に示されています。
If the Keepalive Message also contains the FT Cork TLV, this indicates that the peer LSR wishes to quiesce the session prior to a graceful restart.
KeepaliveメッセージにFT Cork TLVも含まれている場合、これはピアLSRが優雅な再起動の前にセッションをQuiesceしたいことを示しています。
It is RECOMMENDED that upon receiving a Keepalive with the FT CORK TLV, an LSR should cease to send any further label or address related messages on the session until it has been disconnected and reconnected, other than messages generated while processing and securing previously unacknowledged messages received from the peer requesting the quiesce. It should also attempt to complete this processing and return a Keepalive with the FT ACK TLV as soon as possible in order to allow the session to be quiesced.
FT Cork TLVでKeepaliveを受信すると、LSRは、以前に未装備されていないメッセージを処理および保護する際に生成されたメッセージ以外に、セッションでさらにラベルまたはアドレス関連のメッセージをセッションに送信することを停止することをお勧めします。Quiesceを要求するピアから。また、この処理を完了し、セッションをQuiessedにするために、できるだけ早くFT ACK TLVでKeepAliveを返しようとする必要があります。
An example message flow showing this use of the FT Cork TLV to achieve a three-way handshake of state synchronization between two LDP peers is given in section 9.4, "Temporary Shutdown With FT Procedures and Check-Pointing".
FTコルクTLVの使用を示すメッセージフローの例は、2つのLDPピア間の3方向の握手を達成するための3方向の握手を達成することを示しています。
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
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メッセージを指定します。このTLVは、FT再接続フラグがFTセッションTLVに設定されている場合にのみ存在します。この場合、このTLVを存在する必要があります。
The LDP FT enhancements add the following optional parameters to a LDP Keepalive message:
LDP FTの機能強化により、LDP KeepAliveメッセージに次のオプションパラメーターを追加します。
Optional Parameter Length Value
オプションのパラメーターの長さ値
FT Protection TLV 4 See below
FT Cork TLV 0 See below
FT ACK TLV 4 See below
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シーケンス番号を指定します。KeepAliveメッセージに存在する場合、これは、シーケンス番号を含む以前のすべてのLDPメッセージに対する謝辞の勧誘のフラッシュを示し、同じセッションでKeepAliveの送信者によって発行されます。
FT Cork TLV Indicates that the remote LSR wishes to quiesce the LDP session. See section 5, "FT Operations", for the recommended action in such cases.
FT Cork TLVは、リモートLSRがLDPセッションをQuiesceしたいことを示しています。このような場合の推奨アクションについては、セクション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
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ピアによってAckedの最新の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-BITの設定は、ステータスTLVを発信するLSRの裁量であることに注意してください。ただし、メッセージの重複はホップごとの動作に制限される必要があるため、「LDPセッションなし」を除き、「LDPセッションなし」を除き、ステータスコードを含む通知メッセージにFビットを設定しないことをお勧めします。
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
FT Seq Numbers Exhausted 1 0x00000021 FT Session parameters / 1 0x00000022 changed Unexpected FT Cork TLV 1 0x00000023
ft seq数値排出された1 0x00000021 ftセッションパラメーター / 1 0x00000022
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 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初期化メッセージに新しいオプションパラメーターであるFTセッションTLVを使用して、LDPセッションが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ラベルの状態とリソースを保存し、それ以外の場合は0に設定されている場合、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の使用がチェックポイントに使用されるKeepAliveメッセージ以外のメッセージでサポートされている場合、1に設定します（C BITを参照）。つまり、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：セッションのすべてのラベルをシーケンス番号付きFTラベルとして扱う必要がある場合、All-Label Protectionが1にセットが必要です。これにより、ノードから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.
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ビットが設定されている場合、これは、最近失敗したFT LDPセッションの以前のインスタンス化で交換されたFTラベルの状態とリソースを送信する期間を示します。タイムアウトは、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フラグフィールドで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ピアはFT保護TLVを使用して、LDPメッセージにFTラベル操作が含まれていることを示します。
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セッションで流れるメッセージで使用してはなりません。そのようなメッセージにおけるその存在は、「FT」ステータスコードではなく「予期しないTLVセッション」で通知メッセージを送信する必要がある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の存在は、受信LDPピアによってプロトコルエラーとして扱われ、「FTではなく「予期しないTLVラベル」ステータスコードで通知メッセージを送信する必要があります。
Where a Label Withdraw or Label Release message contains only an FEC TLV and does not identify a single specific label, the FT TLV should be included in the message if any label affected by the message is a Sequence Numbered FT Label. If there is any doubt as to whether an FT TLV should be present, it is RECOMMENDED that the sender add the TLV.
ラベルの撤回またはラベルのリリースメッセージに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が存在する場合、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セッションがFTセッションTLVの存在によって決定されたFTセッションであり、LDP初期化メッセージにSビットが設定されている場合、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.
- KeepAliveメッセージについて。
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つずつ増加します。このフィールドは、0xffffffffffから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 Operation Acks」を参照してください。
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保護TLVがシーケンス番号付きFTラベルであると考えているラベルに影響を与えるメッセージを受信した場合、「欠落している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 ACK TLVを使用してFTラベル操作を確認します。
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をすべてのFT KeepAliveメッセージに含めることをお勧めします。
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ピアから受け取った最新のFTラベルメッセージのシーケンス番号。送信中のピアがメッセージを完全に処理する前に完全に処理する必要はありません。たとえば、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は累積的です。FT ACKシーケンス番号12を持つFT ACK TLVを含むLDPメッセージの受信は、1〜12のすべてのメッセージの承認として扱われます（LDPセッションが1のシーケンス番号で開始されたと仮定）。
This field MUST be set to 0 if the LSR sending the FT ACK TLV has not received any FT label operations on this LDP session. This applies to LDP sessions, to new LDP peers or after an LSR determines that it must drop all state for a failed TCP connection.
FT ACK TLVを送信するLSRがこのLDPセッションでFTラベル操作を受信していない場合、このフィールドを0に設定する必要があります。これは、LDPセッション、新しいLDPピア、またはLSRが故障したTCP接続のためにすべての状態をドロップする必要があると判断した後に適用されます。
See section 5.2, "FT Operation Acks" for details of how this field is used.
このフィールドの使用方法の詳細については、セクション5.2「FT Operation Acks」を参照してください。
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ピアは、FT KeepAliveメッセージでFT Cork TLVを使用して、制御プレーンソフトウェアのアップグレード中に、制御されたシャットダウンと再起動の前にLDPセッションをQuiesceしたいことを示します。
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 Cork TLVおよびFT Protection TLVを使用してKeepAliveメッセージを受信すると、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.
- KeepAliveメッセージの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).
- FTコルクTLVとFT ACK TLVを含むピアにキープライブメッセージを送信して、元のKeepAliveメッセージに等しいFT ACKシーケンス番号を指定します（つまり、すべてのメッセージをそのポイントまでアクセスします）。
- 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に送信されるKeepAliveにFT保護TLVも含めます。これは、地元のLSRがQuiesceより前に州を救ったことをリモートピアに伝えていますが、リモートピアが州を救ったことの確認をまだ待っています。
- Cease sending any further state changing messages on this LDP session until it has been disconnected and recovered.
- このLDPセッションが切断されて回復されるまで、この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 Cork TLVを運んだ以前に送信されたKeepAliveを認めるFT ACK TLVとのKeepAliveメッセージを受け取ったとき、LSRはQuiesceが完了したことを知っています。受信したKeepAliveにFT保護TLVも運ばれた場合、LSRは3方向の握手を完了するためにさらにKeepAliveで応答する必要があります。「一時的なシャットダウン」通知メッセージを送信し、TCPセッションを切断し、このセッションのシャットダウンが必要なコントロールプレーンアクションを実行する必要があります。
An example of such a 3-way handshake for controlled shutdown is given in section section 9.4, "Temporary Shutdown With FT Procedures and Check-Pointing".
制御されたシャットダウンのためのこのような3ウェイハンドシェイクの例は、セクション9.4「FT手順とチェックポイントによる一時的なシャットダウン」に記載されています。
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 Cork TLVがFT保護またはFT ACK TLVのいずれかのいずれかが存在しないKeepaliveメッセージで使用されている場合、LDP Peerを含む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.
2つのLDPピア、P1とP2を考慮して、それらを接続するTCP接続と以下に示すメッセージフローを介してLDPを実装します。
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.
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は、L1の下流からラベルマッピングを受け取り、P1に転送します。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は、L2のラベルマッピングを受信し、P1に転送します。今回は、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に4番目のラベルリクエストも送信します
(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のラベルマッピング用のACKが含まれているP2にKeepAliveメッセージを送信します。これは、KeepAliveが送信された時点でP1が受け取って保護した最新のメッセージです。
(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.
（11）TCPセッションがダウンしている間、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セッションは再接続され、P1およびP2は回復したセッションでLDPの初期化メッセージを交換します。
(13) From the LDP Init exchange, P1 determines that it needs to re-issue the Label request for L4.
（13）LDP Init Exchangeから、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.
注（1）から（7）は、逆方向のメッセージに謝辞が袋に入れられていないことに注意することを除いて、前の例のようです。これは、注（8）では、両方のリンクに両方向に延期された謝辞があることを意味します。
(8) P1 wishes to synchronize state with P2. It sends a Keepalive message containing an FT Protection TLV with sequence number 31. Since it is not interested in P2's perception of the state that it has stored, it does not include an FT ACK TLV.
(8) P1は、状態をP2と同期させたいと考えています。シーケンス番号31を備えたFT保護TLVを含むKeepAliveメッセージを送信します。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は、受信したKeepAliveのシーケンス番号を認識しているKeepaliveですぐに応答します。これは、P2がこのセッションで以前に受信したすべての状態/メッセージを保存していることをP1に伝えています。
(10) The downstream node wishes to synchronize state with P2. It sends a Keepalive message containing an FT Protection TLV with sequence number 59. P3 also takes this opportunity to get up to date with its acknowledgements to P2 by including an FT ACK TLV acknowledging up to sequence number 124.
（10）下流ノードは、状態をP2と同期させたいと考えています。シーケンス番号59のFT保護TLVを含むKeepAliveメッセージを送信します。P3は、FT ACK TLVがシーケンス番号124に承認することを含めることにより、P2への謝辞を最新の状態にします。
(11) P2 responds at once with a Keepalive acknowledging the sequence number on the received Keepalive.
（11）P2は、受信したKeepAliveのシーケンス番号を認識しているKeepAliveで一度に応答します。
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）、（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.
ラベルは（7）でこのキープライブと交差するため、（8）P2は、これまでに受信したすべてのメッセージを認めるキープライブを送信しますが、FT保護とFTコルクTLVも含まれて、認められるべきメッセージがまだあることを示すことを示しています。。
P1 is then able to complete the 3-way handshake at (9) and close the TCP session at (10).
P1は（9）で3ウェイハンドシェイクを完了し、（10）でTCPセッションを閉じることができます。
Upon recovery at (11), there are no messages to be re-sent because the KeepAlives flushed the acknowledgements. The only messages sent after recovery is the Label Withdraw that was pended during the TCP session failure.
（11）で回復すると、keepalivesが謝辞を洗い流したため、再セントするメッセージはありません。回復後に送信されたメッセージは、TCPセッションの障害中にpedindされたラベル撤回です。
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）、および（3）FTシーケンス番号のないラベル分布を表示します。
(4) A check-Point request from P1. It carries the sequence number of the check-point request.
(4) P1からのチェックポイント要求。チェックポイントリクエストのシーケンス番号が搭載されています。
(5) P1 immediately starts a new label distribution request.
(5) P1はすぐに新しいラベル配布要求を開始します。
(6) P2 confirms that it has secured all previous transactions.
(6) P2は、以前のすべてのトランザクションを確保したことを確認します。
(7) The subsequent (un-acknowledged) label distribution completes.
(7) 後続の（承認されていない）ラベル分布が完了します。
(8) The session fails and is restarted. Initialization messages confirm the sequence numbers of the secured check-points.
(8) セッションが失敗し、再起動されます。初期化メッセージは、保護されたチェックポイントのシーケンス番号を確認します。
(9) P1 recommences the unacknowledged label distribution request.
(9) P1は、承認されていないラベル配布要求を推奨します。
(10) P2 recommences an unacknowledged label distribution request.
（10）P2は、未承認のラベル配布要求を推奨します。
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）、および（3）FTシーケンス番号のないラベル分布を表示します。
(4) A check-point request from P1. It carries the sequence number of the check-point request and a Cork TLV.
(4) P1からのチェックポイント要求。チェックポイントリクエストのシーケンス番号とコルクTLVを運びます。
(5) P1 has sent a Cork TLV so quieces.
(5) P1はコルクTLVを送信しました。
(6) P2 confirms the check-point and continues the three-way handshake by including a Cork TLV itself.
(6) P2はチェックポイントを確認し、コルクTLV自体を含めることにより、3方向の握手を継続します。
(7) P1 completes the three-way handshake. All operations have now been check-pointed and the session is quiesced.
(7) P1は3方向の握手を完了します。現在、すべての操作がチェックされており、セッションはQuiescedになっています。
(8) The session is gracefully shut down.
(8) セッションは優雅にシャットダウンされています。
(9) The session recovers and the peers exchange the sequence numbers of the last secured check-points.
(9) セッションが回復し、ピアは最後の保護されたチェックポイントのシーケンス番号を交換します。
(10) P1 starts a new label distribution request.
（10）P1は、新しいラベル配布要求を開始します。
(11) P1 continues processing a previously received label distribution request.
（11）P1は、以前に受信したラベル分布要求の処理を継続します。
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の機能強化により、確立されたラベルの属性を完全に交換することなく、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ピア間のトラフィックを傍受し、FTラベルフラグの設定をすべてのラベルで0に設定することができます。
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.
LDPと同様に、LDPの実装により、最初に使用されたセッションの有効期限が切れた後もラベルを使用し続ける場合、セキュリティの問題が存在する可能性があります。下流の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、P2のLDPピアであるLSR、P1を考えてみましょう。P2がP1とP2の間でLDPセッションを提供するハードウェアまたはソフトウェアに障害を発生させると、ピア間のTCP接続に失敗する可能性があります。接続が回復すると、両方のLSRがFT回復手順をLDPセッションに適用していた場合にのみ、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 Acksは、LSRで大量の未把持された状態の変更を構築しないように、実行可能な限りすぐに送信LSRに戻す必要があります。ただし、即時の1対1の謝辞は、帯域幅を不必要に無駄にします。
A possible implementation strategy for sending ACKs to FT LDP messages is as follows:
ACKをFT LDPメッセージに送信するための可能な実装戦略は次のとおりです。
- An LSR secures received messages in order and tracks the sequence number of the most recently secured message, Sr.
- LSRは受信したメッセージを順番に保護し、最近保護されたメッセージのシーケンス番号、Sr。
- On each LDP KeepAlive that the LSR sends, it attaches an FT ACK TLV listing Sr.
- LSRが送信する各LDP KeepAliveで、FT ACK TLVリストシニアを取り付けます。
- Optionally, the LSR may attach an FT ACK TLV to any other LDP message sent between Keepalive messages if, for example, Sr has increased by more than a threshold value since the last ACK sent.
- オプションで、LSRは、たとえば、SRが最後のACKが送信されて以来しきい値を超えて増加した場合、KeepAliveメッセージ間で送信される他のLDPメッセージにFT ACK TLVを添付する場合があります。
This implementation combines the bandwidth benefits of accumulating ACKs while still providing timely ACKs.
この実装は、タイムリーなAckを提供しながらAcksを蓄積することの帯域幅の利点を組み合わせています。
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.
チェックポイントは、KeepAliveメッセージの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メッセージのシーケンス番号を追跡する必要がないため、実装をかなり簡素化する場合があります。ただし、KeepAliveのシーケンス番号を確認する前に、受信したすべてのメッセージ（またはその結果の状態変更）が確保されることを確認する必要があります。
This approach may be considered optimal in systems that do not show a high degree of change over time (such as targeted LDP sessions) and that are prepared to risk loss of state for the most recent LDP exchanges. More dynamic systems (such as LDP discovery sessions) are more likely to want to acknowledge state changes more frequently so that the maximum amount of state can be preserved over a failure.
このアプローチは、時間の経過とともに高度な変化を示さず（ターゲットを絞った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.
多くのLDP LSRは、他のラベル分布メカニズムも実行されます。これらには、静的ラベルマッピングの構成、LDPのその他の異なるインスタンス、およびその他のラベル分布プロトコルの管理インターフェイスが含まれます。最後の例には、LDP LSPが確立されるトンネルを構築するために使用されるトラフィックエンジニアリングラベル分布プロトコルが含まれます。
As with re-use of individual labels by LDP within a restarting LDP system, care must be taken to prevent labels that need to be retained by a restarting LDP session or protocol component from being used by another label distribution mechanism 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]の著者によって表現されたLDPのアイデアに基づいています。
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セッションを再起動するためのDavid WardとJohn Scudderの提案に触発されました。
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。マニカンタン、アダム・シェパード、アラン・デイビー、イフテカー・フセイン、ロア・アンダーソンの慎重なレビューとコメントを認めたいと思います。
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] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification, RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、 "LDP仕様、RFC 3036、2001年1月。
[RFC3478] Leelanivas, M., Rekhter, Y. and R. 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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tomassi、F。and 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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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.、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A.、Girish、M.、Gray、E.、Heinanen、J.、Kilty、T。、およびA. Malis、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月。
[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] Ash、G.、Lee、Y.、Ashwood-Smith、P.、Jamoussi、B.、Fedyk、D.、Skalecki、D。、およびL. Li、「Cr-LDPを使用したLSP修正」、RFC 3214、2001年1月。
[BGP-RESTART] Sangli, S., et al., Graceful Restart Mechanism for BGP, Work in Progress.
[BGP-Restart] Sangli、S.、et al。、BGPの優雅な再起動メカニズム、進行中の作業。
Adrian Farrel (editor) Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102
Adrian Farrel（編集者）Movaz Networks、Inc。7926 Jones Branch Drive、Suite 615 McLean、VA 22102
Phone: +1 703-847-1867
EMail: afarrel@movaz.com
Paul Brittain Data Connection Ltd. Windsor House, Pepper Street, Chester, Cheshire CH1 1DF, UK
Paul Brittain Data Connection Ltd. Windsor House、Pepper Street、Chester、Cheshire CH1 1DF、英国
Phone: +44-(0)20-8366-1177 EMail: pjb@dataconnection.com Philip Matthews Hyperchip 1800 Rene-Levesque Blvd W Montreal, Quebec H3H 2H2 Canada
電話：44-（0）20-8366-1177メール：pjb@dataconnection.com Philip Matthews Hyperchip 1800 Rene-Levesque Blvd W Montreal、Quebec H3H 2H2カナダ
Phone: +1 514-906-4965
EMail: pmatthews@hyperchip.com
Eric Gray
エリック・グレイ
EMail: ewgray@GraIyMage.com
Jack Shaio Vivace Networks 2730 Orchard Parkway San Jose, CA 95134
Jack Shaio Vivace Networks 2730 Orchard Parkway San Jose、CA 95134
Phone: +1 408 432 7623
EMail: jack.shaio@vivacenetworks.com
Toby Smith Laurel Networks, Inc. 1300 Omega Drive Pittsburgh, PA 15205
トビー・スミス・ローレル・ネットワークス・インク1300オメガ・ドライブ・ピッツバーグ、ペンシルバニア州15205
EMail: tob@laurelnetworks.com
Andrew G. Malis Vivace Networks 2730 Orchard Parkway San Jose, CA 95134
Andrew G. Malis Vivace Networks 2730 Orchard Parkway San Jose、CA 95134
Phone: +1 408 383 7223
EMail: andy.malis@vivacenetworks.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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エディター機能の資金は現在、インターネット協会によって提供されています。