[要約] RFC 5919は、LDP（Label Distribution Protocol）ラベル広告の完了を通知するための信号化に関する仕様です。このRFCの目的は、LDPセッションの確立とラベル広告の完了を効率的に行うための手順を提供することです。
Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 5919 P. Mohapatra
Category: Standards Track Cisco Systems
ISSN: 2070-1721 E. Chen
Huawei Technologies
B. Thomas
August 2010
Signaling LDP Label Advertisement Completion
シグナリングLDPラベル広告の完了
Abstract
概要
There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment.
ラベル配布プロトコル（LDP）セッションの確立に続いて、LDPスピーカーがピアがいつすべてのラベルを宣伝したかを知ることが役立つ状況があります。LDP仕様は、LDPスピーカーがそのピアの初期ラベル広告を完了したときにピアに通知するメカニズムを提供しません。このドキュメントは、LDPスピーカーがセッションの確立後の初期ラベル広告の信号完了を信号するための手段を指定します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5919.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5919で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability - Label Advertisement Mode ...................3
2. Specification Language ..........................................3
3. Unrecognized Notification Capability ............................4
4. Signaling Completion of Label Advertisement .....................4
4.1. Missing Expected End-of-LIB Notifications ..................5
5. Usage Guidelines ................................................6
5.1. LDP-IGP Sync ...............................................6
5.2. LDP Graceful Restart .......................................7
5.3. Wildcard Label Request .....................................7
6. Security Considerations .........................................8
7. IANA Considerations .............................................8
8. Acknowledgments .................................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................9
There are situations following LDP session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of the labels from its Label Information Base (LIB). For example, when an LDP speaker is using LDP-IGP synchronization procedures [RFC5443], it would be useful for the speaker to know when its peer has completed advertisement of its IP label bindings. Similarly, after an LDP session is re-established when LDP Graceful Restart [RFC3478] is in effect, it would be helpful for each peer to signal the other after it has advertised all its label bindings.
LDPセッションの確立に続いて、LDPスピーカーがピアがラベル情報ベース（LIB）からすべてのラベルを宣伝したことを知ることが役立つ状況があります。たとえば、LDPスピーカーがLDP-IGP同期手順[RFC5443]を使用している場合、スピーカーがピアがIPラベルバインディングの広告を完了したことをスピーカーが知ることは役立ちます。同様に、LDPのGraceful Restart [RFC3478]が有効になったときにLDPセッションが再確立された後、すべてのラベルバインディングを宣伝した後、各ピアが他のピアに信号を送るのに役立ちます。
The LDP specification [RFC5036] provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer.
LDP仕様[RFC5036]は、LDPスピーカーがそのピアの初期ラベル広告を完了したときにピアに通知するメカニズムを提供しません。
This document specifies use of a Notification message with the End-of-LIB Status Code for an LDP speaker to signal completion of its label advertisements following session establishment.
このドキュメントは、セッション設立後のラベル広告の信号完了を信号するために、LDPスピーカーのLDPスピーカーの終了ステータスコードを使用した通知メッセージの使用を指定します。
RFC 5036 implicitly assumes that new Status Codes will be defined over the course of time. However, it does not explicitly define the behavior of an LDP speaker that does not understand the Status Code in a Notification message. To avoid backward compatibility issues, this document specifies use of the LDP capability mechanism [RFC5561] at session establishment time for informing a peer that an LDP speaker is capable of handling a Notification message that carries an unrecognized Status Code.
RFC 5036は、新しいステータスコードが時間の経過とともに定義されることを暗黙的に想定しています。ただし、通知メッセージのステータスコードを理解していないLDPスピーカーの動作を明示的に定義していません。後方互換性の問題を回避するために、このドキュメントは、LDPスピーカーが認識されていないステータスコードを持つ通知メッセージを処理できることをピアに通知するために、セッションの確立時間でLDP機能メカニズム[RFC5561]の使用を指定します。
The mechanisms specified in this document are deemed useful to LDP peering using the 'Downstream Unsolicited' label advertisement mode [RFC5036]. They are not deemed useful to any LDP peering using the 'Downstream on Demand' label advertisement mode since the LDP speaker would request particular label binding(s) from the peer anyway and know when it has received them.
このドキュメントで指定されたメカニズムは、「下流の未承諾」ラベル広告モード[RFC5036]を使用してLDPピアリングに役立つとみなされます。LDPスピーカーはとにかくピアから特定のラベルバインディングを要求し、いつ受け取ったかを知っているため、「ダウンストリームオンデマンド」ラベル広告モードを使用して、LDPのピアリングに役立つとはみなされません。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
An LDP speaker MAY include a Capability Parameter [RFC5561] in the Initialization message to inform a peer that it ignores Notification Messages that carry a Status Type-Length-Value (TLV) with a non-fatal Status Code unknown to it.
LDPスピーカーには、初期化メッセージに機能パラメーター[RFC5561]を含めることができ、ピアに、ステータスタイプ長値（TLV）が不明なステータスコードを持つステータスタイプ長値（TLV）を運ぶ通知メッセージを無視することが含まれます。
The Capability Parameter for the Unrecognized Notification capability is a TLV with the following format:
認識されていない通知機能の機能パラメーターは、次の形式の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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Unrecognized Noti (0x0603)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1: Unrecognized Notification Capability Format
図1：認識されていない通知機能形式
Where:
ただし：
U- and F-bits: MUST be 1 and 0, respectively, as per Section 3 of LDP Capabilities [RFC5561].
U-およびFビット：LDP機能のセクション3 [RFC5561]に従って、それぞれ1および0でなければなりません。
Unrecognized Notif: 0x0603
認識されていないNotif：0x0603
S-bit: MUST be 1 (indicates that capability is being advertised).
s-bit：1でなければなりません（機能が宣伝されていることを示します）。
Upon receiving a Notification with an unrecognized Status Code, an LDP speaker MAY generate a console or system log message for trouble shooting purposes.
認識されていないステータスコードを使用して通知を受信すると、LDPスピーカーは、トラブルシューティングの目的でコンソールまたはシステムログメッセージを生成する場合があります。
An LDP speaker that conforms to this specification SHOULD signal completion of its label advertisements to a peer by means of a Notification message, if its peer has advertised the Unrecognized Notification capability during session establishment. The LDP speaker SHOULD send the Notification message (per Forwarding Equivalence Class (FEC) Type) to a peer even if the LDP speaker has zero Label bindings to advertise to that peer.
この仕様に準拠するLDPスピーカーは、ピアがセッションの確立中に認識されていない通知機能を宣伝した場合、通知メッセージによってラベル広告の完了をピアに通知することを示す必要があります。LDPスピーカーは、LDPスピーカーがそのピアに宣伝するためにゼロラベルバインディングを持っている場合でも、通知メッセージ（転送等価クラス（FEC）タイプ）をピアに送信する必要があります。
Such a Notification message MUST carry:
このような通知メッセージは、次のことを伝える必要があります。
- A status TLV (with TLV E- and F-bits set to zero) that carries an End-of-LIB Status Code (0x0000002F).
- lib end-of-libステータスコード（0x0000002f）を搭載したステータスTLV（ゼロに設定）。
- A FEC TLV with the Typed Wildcard FEC Element [RFC5918] that identifies the FEC type for which initial label advertisements have been completed. In terms of Section 3.5.1 of RFC 5036, this TLV is an "Optional Parameter" of the Notification message.
- タイプされたWildCard FEC要素[RFC5918]を備えたFEC TLVは、初期ラベル広告が完了したFECタイプを識別します。RFC 5036のセクション3.5.1に関しては、このTLVは通知メッセージの「オプションのパラメーター」です。
An LDP speaker MUST NOT send a Notification that carries a Status TLV with the End-of-LIB Status Code to a peer unless the peer has advertised the Unrecognized Notification capability during session establishment.
LDPスピーカーは、ピアがセッションの確立中に認識されていない通知機能を宣伝していない限り、PeerがピアにステータスTLVを搭載する通知を送信してはなりません。
This applies to any LDP peers discovered via either basic discovery or extended discovery mechanisms (per Section 2.4 of [RFC5036]).
これは、基本的な発見または拡張された発見メカニズム（[RFC5036]のセクション2.4ごと）を介して発見されたLDPピアに適用されます。
There is no guarantee that an LDP speaker will receive (or send) an End-of-LIB Notification from (or to) a peer even if the LDP speaker has signaled the Unrecognized Notification capability (Section 3).
LDPスピーカーが、LDPスピーカーが認識されていない通知機能を合図した場合でも、PEERからLDPの通知を受け取る（または送信）するという保証はありません（セクション3）。
Although it is expected that an LDP speaker supporting the Unrecognized Notification capability would support sending and receiving an End-of-LIB Notification, it is not mandatory by definition.
認識されていない通知機能をサポートするLDPスピーカーは、LIBの終了通知の送信と受信をサポートすることが予想されますが、定義により必須ではありません。
Please note that this is not a concern since the LDP speaker would simply ignore the received Notification with an End-of-LIB status code (or any status code) that is not recognized or supported, by definition.
LDPスピーカーは、定義上、認識またはサポートされていないLIBエンドステータスコード（またはステータスコード）で受信された通知を単純に無視するため、これは懸念事項ではないことに注意してください。
To deal with the possibility of missing End-of-LIB Notifications after the LDP session establishment, an LDP speaker MAY time out receipt of an expected End-of-LIB Notification. An LDP speaker SHOULD start a per-peer internal timer, called 'EOL Notification' timer (the default value of 60 seconds is RECOMMENDED, though the value of this timer SHOULD be configurable) immediately following the LDP session establishment.
LDPセッションの確立後にLDPの終了通知が欠落している可能性に対処するために、LDPスピーカーは、予想されるLIB終了通知の受信をタイムアウトする場合があります。LDPスピーカーは、「EOL通知」タイマーと呼ばれるピアごとの内部タイマー（60秒のデフォルト値が推奨されますが、このタイマーの値は設定可能である必要があります）を開始する必要があります。
This timer is reset by the subsequent label advertisement, and stopped by the End-of-LIB Notification message. Lacking any label advertisement from the peer, the timer would expire, causing the LDP speaker to behave as if it had received the End-of-LIB notification from the peer.
このタイマーは、後続のラベル広告によってリセットされ、LIBの終了通知メッセージによって停止されます。ピアからのラベル広告がないため、タイマーは期限切れになり、LDPスピーカーはピアからLIBの終了通知を受け取ったかのように振る舞います。
If the End-of-LIB Notification message is received after the timer expires, then the message SHOULD be ignored.
タイマーの有効期限が切れた後にLIBの終了通知メッセージが受信された場合、メッセージは無視する必要があります。
The FECs known to an LDP speaker and the labels the speaker has bound to those FECs may change over the course of time. This makes it difficult to determine when an LDP speaker has advertised "all" of its label bindings for a given FEC type. Ultimately, this determination is a judgment call the LDP speaker makes. The following guidelines may be useful.
LDPスピーカーに知られているFECとスピーカーがそれらのFECに縛られているラベルは、時間の経過とともに変化する可能性があります。これにより、LDPスピーカーが特定のFECタイプのラベルバインディングの「すべて」を宣伝した時期を判断することが困難になります。最終的に、この決定は、LDPスピーカーが行う判断の呼びかけです。次のガイドラインが役立つ場合があります。
An LDP speaker is assumed to "know" a set of FECs. Depending on a variety of criteria, such as:
LDPスピーカーは、FECのセットを「知っている」と想定されています。次のようなさまざまな基準に応じて、
- the label distribution control mode in use (Independent or Ordered);
- 使用中のラベル配布制御モード（独立または順序付け）;
- the set of FECs to which the speaker has bound local labels;
- スピーカーがローカルラベルをバインドするFECのセット。
- configuration settings that may constrain which label bindings the speaker may advertise to peers.
- スピーカーがピアに宣伝できるラベルバインディングを制約する可能性のある構成設定。
The speaker can determine the set of bindings for a given FEC type that it is permitted to advertise to a given peer.
スピーカーは、特定のピアに宣伝することが許可されている特定のFECタイプのバインディングのセットを決定できます。
LDP-IGP Sync, LDP Graceful Restart, and the response to a Wildcard Label Request [RFC5918] are situations that would benefit from End-of-LIB Notification. In these situations, after an LDP speaker completes its label binding advertisements to a peer, sending an End-of-LIB Notification to the peer makes their outcome deterministic. The following subsections further explain each of these situations one by one.
LDP-IGP Sync、LDP Graceful Restart、およびWildCardラベルリクエストに対する応答[RFC5918]は、LIB終了通知の恩恵を受ける状況です。これらの状況では、LDPスピーカーがラベルのバインディング広告をピアに完了した後、ピアにLIBの終了通知を送信すると、結果が決定論的になります。次のサブセクションでは、これらの各状況をさらに1つずつ説明します。
The LDP-IGP Synchronization [RFC5443] specifies a mechanism by which directly connected LDP speakers may delay the use of the link (between them) for transit IP traffic forwarding until the labels required to support IP-over-MPLS traffic forwarding have been distributed and installed.
LDP-IGP同期[RFC5443]は、直接接続されたLDPスピーカーが、IP-over-MPLSトラフィック転送をサポートするために必要なラベルが配布され、輸送IPトラフィック転送のリンク（それらの間）の使用を遅らせるメカニズムを指定します。インストール。
Without an End-of-LIB Notification, the speaker must rely on some heuristic to determine when it has received all of its peer's label bindings. The heuristic chosen could cause LDP to signal the IGP too soon (in which case, the likelihood that traffic will be dropped increases) or too late (in which case, traffic is kept on sub-optimal paths longer than necessary).
LIBの終了通知がなければ、スピーカーは、ピアのラベルバインディングをすべて受け取ったことを決定するために、いくつかのヒューリスティックに依存する必要があります。選択されたヒューリスティックにより、LDPがIGPを早く知らせすぎる可能性があります（この場合、トラフィックが減少する可能性が増加する可能性が高くなります）または遅すぎる（その場合、必要以上に最適なパスにトラフィックが維持されます）。
Following session establishment, with a directly connected peer that has advertised the Unrecognized Notification capability, an LDP speaker using LDP-IGP Sync may send the peer an End-of-LIB Notification after it completes advertisement of its IP label bindings to the peer. Similarly, the LDP speaker may use the End-of-LIB Notification received from a directly connected peer to determine when the peer has completed advertisement of its label bindings for IP prefixes. After receiving the notification, the LDP speaker should consider LDP to be fully operational for the link and should signal the IGP to start advertising the link with normal cost.
セッションの確立に続いて、認識されていない通知機能を宣伝した直接接続されたピアを備えたLDP-IGP同期を使用したLDPスピーカーは、ピアへのIPラベルバインディングの広告を完了した後、ピアにlibの通知を送信する場合があります。同様に、LDPスピーカーは、直接接続されたピアから受信したLIBの終了通知を使用して、ピアがIPプレフィックスのラベルバインディングの広告を完了した時期を判断することができます。通知を受け取った後、LDPスピーカーはLDPがリンクの完全に動作することを検討する必要があり、IGPが通常のコストでリンクの宣伝を開始するように信号を送信する必要があります。
LDP Graceful Restart [RFC3478] helps to reduce the loss of MPLS traffic caused by the restart of a router's LDP component. It defines procedures that allow routers capable of preserving MPLS forwarding state across the restart to continue forwarding MPLS traffic using forwarding state installed prior to the restart for a configured time period.
LDP Graceful Restart [RFC3478]は、ルーターのLDPコンポーネントの再起動によって引き起こされるMPLSトラフィックの損失を減らすのに役立ちます。再起動全体でMPLS転送状態を保存できるルーターを可能にする手順を定義し、設定された期間の再起動前にインストールされた転送状態を使用してMPLSトラフィックを転送し続けます。
The current behavior without End-of-LIB Notification is as follows: the restarting router and its peers consider the preserved forwarding state to be usable but stale until it is refreshed by receipt of new label advertisements following re-establishment of new LDP sessions or until the time period expires. When the time period expires, any remaining stale forwarding state is removed by the router.
LIBの終了通知のない現在の動作は次のとおりです。再起動ルーターとそのピアは、保存された転送状態を使用できると考えていますが、新しいLDPセッションの再確立後または新しいラベル広告を受け取ることで更新されるまで古くなっていると考えています。期間が期限切れになります。期間が切れると、残りの古い転送状態はルーターによって削除されます。
Receiving End-of-LIB Notification from a peer in an LDP Graceful Restart scenario enables an LDP speaker to stop using stale forwarding information learned from that peer and to recover the resources it requires without having to wait until the time period expiry. The time period expiry can still be used if the End-of-LIB Notification message is not received.
LDPの優雅な再起動シナリオでピアからLIBの終了通知を受け取ることで、LDPスピーカーはそのピアから学んだ古い転送情報の使用を停止し、期限が切れるまで待つことなく必要なリソースを回復することができます。LIBの終了通知メッセージが受信されない場合、期間の期限が引き続き使用できます。
When an LDP speaker receives a Label Request message for a Typed Wildcard FEC (e.g., a particular FEC Element Type) from a peer, the LDP speaker determines the set of bindings (as per any local filtering policy) to advertise to the peer for the FEC type specified by the request. Assuming the peer had advertised the Unrecognized Notification capability at session initialization time, the speaker should send the peer an End-of-LIB Notification for the FEC type when it completes advertisement of the permitted bindings.
LDPスピーカーがピアからタイプされたワイルドカードFEC（特定のFEC要素タイプなど）のラベル要求メッセージを受信すると、LDPスピーカーは（ローカルフィルタリングポリシーに従って）バインディングのセットを決定し、ピアに宣伝します。リクエストによって指定されたFECタイプ。ピアがセッションの初期化時間に認識されていない通知機能を宣伝したと仮定すると、スピーカーは、許可されたバインディングの広告を完了したときに、ピアにFECタイプのLIBの終了通知を送信する必要があります。
As in the previous applications, receipt of the Notification eliminates uncertainty as to when the peer has completed its advertisements of label bindings for the requested Wildcard FEC Element Type.
以前のアプリケーションと同様に、通知の受領は、ピアが要求されたワイルドカードFEC要素タイプのラベルバインディングの広告を完了した時期に関する不確実性を排除します。
No security considerations beyond those that apply to the base LDP specification [RFC5036] and that are further described in [RFC5920] apply to signaling the End-of-LIB condition as described in this document.
ベースLDP仕様[RFC5036]に適用され、[RFC5920]でさらに説明されているものを超えたセキュリティ上の考慮事項は、このドキュメントに記載されているように、LIBの終了状態のシグナル伝達に適用されます。
This document introduces a new LDP Status Code and a new LDP Capability.
このドキュメントでは、新しいLDPステータスコードと新しいLDP機能を紹介します。
IANA has assigned the 'End-of-LIB' status code (0x0000002F) from the Status Code Name Space. [RFC5036] partitions the Status Code Name Space into 3 regions: IETF Consensus region, First Come First Served region, and Private Use region. The code point 0x0000002F is from the IETF Consensus range.
IANAは、ステータスコード名スペースから「LIBの終了」ステータスコード（0x0000002F）を割り当てました。[RFC5036]ステータスコード名スペースを3つの地域に分割します：IETFコンセンサス地域、最初に提供される地域、および私的使用地域。コードポイント0x0000002Fは、IETFコンセンサス範囲からのものです。
IANA has assigned the 'Unrecognized Notification' capability (0x0603) from the TLV Type name space. [RFC5036] partitions the TLV Type name space into 3 regions: IETF Consensus region, Vendor Private Use region, and Experimental Use region. The code point 0x0603 is from the IETF Consensus range.
IANAは、TLVタイプ名スペースから「認識されていない通知」機能（0x0603）を割り当てました。[RFC5036] TLVタイプ名スペースを3つの領域に分割します：IETFコンセンサス地域、ベンダープライベート使用地域、および実験的使用地域。コードポイント0x0603は、IETFコンセンサス範囲からのものです。
The authors would like to recognize Kamran Raza, who helped to formulate this draft.
著者は、このドラフトの策定を手伝ったKamran Razaを認識したいと考えています。
The authors would like to thank Ina Minei, Alia Atlas, Yakov Rekhter, Loa Andersson, and Luyuan Fang for their valuable feedback and contributions.
著者は、Ina Minei、Alia Atlas、Yakov Rekhter、Loa Andersson、Luyuan Fangに貴重なフィードバックと貢献について感謝したいと思います。
[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月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561] Thomas、B.、Raza、K.、Aggarwal、S.、Aggarwal、R。、およびJl。Le Roux、「LDP機能」、RFC 5561、2009年7月。
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010.
[RFC5918] ASATI、R.、MINEI、I。、およびB. Thomas、「ラベル分布プロトコル（LDP） 'タイプされたワイルドカード「フォワード等価クラス（FEC）」、RFC 5918、2010年8月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478] Leelanivas、M.、Rekhter、Y。、およびR. Aggarwal、「ラベル分布プロトコルの優雅な再起動メカニズム」、RFC 3478、2003年2月。
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009.
[RFC5443] Jork、M.、Atlas、A。、およびL. Fang、「LDP IGP同期」、RFC 5443、2009年3月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
Authors' Addresses
著者のアドレス
Rajiv Asati Cisco Systems 7025-6 Kit Creek Rd. Research Triangle Park, NC 27709-4987 EMail: rajiva@cisco.com
Rajiv Asati Cisco Systems 7025-6 Kit Creek Rd。研究トライアングルパーク、NC 27709-4987メール：rajiva@cisco.com
Pradosh Mohapatra Cisco Systems 3750 Cisco Way San Jose, CA 95134 EMail: pmohapat@cisco.com
Pradosh Mohapatra Cisco Systems 3750 Cisco Way San Jose、CA 95134メール：pmohapat@cisco.com
Emily Chen Huawei Technologies No. 5 Street, Shangdi Information, Haidian Beijing, China EMail: chenying220@huawei.com
Emily Chen Huawei Technologies No. 5 Street、Shangdi Information、Haidian Beijing、China Email：chenying220@huawei.com
Bob Thomas EMail: bobthomas@alum.mit.edu
ボブ・トーマス・メール：bobthomas@alum.mit.edu