Internet Engineering Task Force (IETF) R. Asati
Request for Comments: 5918 Cisco Systems
Category: Standards Track I. Minei
ISSN: 2070-1721 Juniper Networks
B. Thomas
August 2010
Label Distribution Protocol (LDP) 'Typed Wildcard'
Forward Equivalence Class (FEC)
Abstract
抽象
The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility.
ワイルドカードフォワード等価クラス（FEC）要素のラベル配布プロトコル（LDP）仕様は、いくつかの制限があります。この文書では、型指定されたワイルドカードFEC要素とそれに関連する手順を定義することによって、これらの制限に対処しています。また、それは、下位互換性に対処するための新たな自民党の機能を定義します。
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/rfc5918.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5918で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification Language ..........................................4
3. The Typed Wildcard FEC Element ..................................4
4. Procedures for the Typed Wildcard FEC Element ...................5
5. Typed Wildcard FEC Capability ...................................6
6. Typed Wildcard FEC Element for Prefix FEC Element ...............7
7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements ...8
8. IANA Considerations .............................................8
9. Security Considerations .........................................8
10. Acknowledgments ................................................9
11. References .....................................................9
11.1. Normative References ......................................9
11.2. Informative References ....................................9
LDP [RFC5036] distributes labels for Forwarding Equivalence Classes (FECs). LDP uses FEC TLVs in LDP messages to specify FECs. An LDP FEC TLV includes one or more FEC elements. A FEC element includes a FEC type and an optional type-dependent value.
LDP [RFC5036]は転送等価クラス（のFEC）のラベルを配布します。自民党はのFECを指定するには、LDPメッセージにFEC TLVを使用しています。 LDP FEC TLVは、一つ以上のFEC要素を含んでいます。 FEC要素は、FECタイプおよびオプションのタイプに依存する値を含みます。
RFC 5036 specifies two FEC types (Prefix and Wildcard), and other documents specify additional FEC types; e.g., see [RFC4447] and [MLDP].
RFC 5036には、2種類のFEC（プレフィックスとワイルドカード）を指定し、他の文書には、追加のFECのタイプを指定します。例えば、[RFC4447]を参照し、[MLDP]。
As specified by RFC 5036, the Wildcard FEC Element refers to all FECs relative to an optional constraint. The only constraint RFC 5036 specifies is one that limits the scope of the Wildcard FEC Element to "all FECs bound to a given label".
RFC 5036で指定されるように、ワイルドカードFEC要素は、オプションの制約のすべてのFEC相対指します。 RFC 5036が指定する唯一の制約は、ワイルドカードFEC要素の範囲を「与えられたラベルにバインドされたすべてのFECを」制限です。
The RFC 5036 specification of the Wildcard FEC Element has the following deficiencies that limit its utility:
ワイルドカードFEC要素のRFC 5036仕様は、その有用性を制限し、次の欠点があります。
1) The Wildcard FEC Element is untyped. There are situations where it would be useful to be able to refer to all FECs of a given type (as another constraint).
1）ワイルドカードFEC要素が型なしです。 （別の制約として）指定されたタイプのすべてのFECを参照することができることは有用であろう状況があります。
2) Use of the Wildcard FEC Element is limited to Label Withdraw and Label Release messages only. There are situations where it would be useful to have a Wildcard FEC Element, with type constraint, in Label Request messages.
2）ワイルドカードFEC要素の使用は撤回とだけラベル解放メッセージ標識に限定されます。ラベル要求メッセージに、型制約で、ワイルドカードFEC要素を持つことが有用であろう状況があります。
This document:
このドキュメント：
- addresses the above limitations by defining a Typed Wildcard FEC Element and procedures for its use.
- その使用のために型指定されたワイルドカードFEC要素および手順を定義することによって、上記の制限に対処します。
- specifies use of the LDP capability mechanism [RFC5561] at session establishment time for informing a peer that an LDP speaker is capable of handling the Typed Wildcard FEC.
- LDPスピーカ入力したワイルドカードFECを処理することができるピアに通知するためのセッション確立時にLDP能力メカニズム[RFC5561]を使用することを指定します。
- specifies use of the Typed Wildcard FEC Element in a Label Request message.
- ラベル要求メッセージに入力されたワイルドカードFEC要素の使用を指定します。
- specifies the Typed Wildcard FEC Element for the Prefix FEC Element specified by RFC 5036.
- RFC 5036で指定されたプレフィックスFEC要素のために型指定されたワイルドカードFEC要素を指定します。
Note that this document does not change procedures specified for the LDP Wildcard FEC Element by RFC 5036.
この文書はRFC 5036でLDPワイルドカードFEC要素に対して指定された手順を変更しないことに注意してください。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
LDP - Label Distribution Protocol
LDP - ラベル配布プロトコル
FEC - Forwarding Equivalence Class
FEC - 転送等価クラス
TLV - Type Length Value
TLV - タイプ長さ値
LSR - Label Switching Router
LSR - ラベルスイッチングルータ
The Typed Wildcard FEC Element refers to all FECs of the specified type that meet the constraint. It specifies a 'FEC Element Type' and an optional constraint, which is intended to provide additional information.
型指定されたワイルドカードFEC要素は、制約を満たす指定されたタイプのすべてのFECを指します。それはFEC要素型 'と追加情報を提供することを目的とオプションの制約を指定します。
The format of the Typed Wildcard FEC Element is:
型指定されたワイルドカードFEC要素の形式は次のとおりです。
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed (0x05) | FEC Element | Len FEC Type | |
| Wildcard | Type | Info | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ Additional FEC Type-specific Information ~
| (Optional) |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Typed Wildcard FEC Element
図1：型指定されたワイルドカードFEC要素
Where:
どこ：
Typed Wildcard: One-octet FEC Element Type (0x05).
型指定されたワイルドカード：1オクテットFEC要素タイプ（0×05）。
FEC Element Type: One-octet FEC Element Type that specifies the FEC Element Type to be wildcarded. Please see Section 3.4.1 of RFC 5036.
FEC要素タイプ：ワイルドカードされるFEC要素の型を指定する1オクテットFEC要素タイプ。 RFC 5036のセクション3.4.1を参照してください。
Any (future) document specifying a new FEC Element Type (not
defined in RFC 5036) should prescribe whether typed
wildcarding is needed for that FEC Element Type.
Len FEC Type Info: One octet that specifies the length in octets of the FEC Type Specific information field. It MUST be set to 0 if there is no Additional FEC Type-specific Information.
レンFECタイプ情報：FECタイプ固有の情報フィールドのオクテットの長さを指定する1つのオクテット。追加のFECタイプ固有の情報が存在しない場合は0に設定しなければなりません。
Additional FEC Type-specific Information (Optional): Additional information that is specific to the FEC Element Type and that is required to fully specify the Typed Wildcard. If this field is absent, then all FECs of the specified FEC Type would be matched.
追加のFECタイプ固有の情報（オプション）：追加情報FEC要素タイプに特有のものであり、それは完全に型指定されたワイルドカードを指定する必要があります。このフィールドが存在しない場合は、指定されたFECタイプのすべてのFECを一致させるでしょう。
Any (future) document specifying Typed wildcarding for any
FEC Element Type should also specify the length and format
of Additional FEC Type Specific Information, if included.
This document specifies one FEC Element Type instance (e.g., Prefix FEC) for the 'Typed Wildcard FEC Element' in Section 6.
この文書では、第6章の「型付きワイルドカードFEC要素」のために（例えば、プレフィックスFEC）1つのFEC要素タイプのインスタンスを指定します。
When a FEC TLV contains a Typed Wildcard FEC Element, the Typed Wildcard FEC Element MUST be the only FEC Element in the TLV. If an LDP speaker receives a FEC TLV containing a Typed Wildcard FEC Element and any other FEC elements, then the LDP speaker should ignore the other FEC elements and continue processing as if the message only contains the Typed Wildcard FEC Element.
FEC TLVは、型指定されたワイルドカードFEC要素が含まれている場合は、型指定されたワイルドカードFEC要素は、TLVで唯一のFEC要素でなければなりません。 LDPスピーカ入力したワイルドカードFEC要素と他のFEC要素を含むFEC TLVを受信した場合、LDPスピーカーは他のFEC要素を無視し、メッセージのみ型付きワイルドカードFEC要素が含まれているかのように処理を継続すべきです。
An LDP implementation that supports the Typed Wildcard FEC Element MUST support its use in Label Request, Label Withdraw, and Label Release messages.
型指定されたワイルドカードFEC要素をサポートしている自民党の実装では、ラベル要求での使用をサポートしてラベル撤回、およびリリースメッセージにラベルを付ける必要があります。
An LDP implementation that supports the Typed Wildcard FEC Element MUST support it for every FEC Element Type defined in [RFC5036].
型指定されたワイルドカードFEC要素をサポートしている自民党の実装は、[RFC5036]で定義されたすべてのFEC要素タイプのためにそれをサポートしなければなりません。
Receipt of a Label Request message with a FEC TLV containing a Typed Wildcard FEC Element is interpreted as a request to send one or more Label Mappings for all FECs of the type specified by the FEC Element Type field in the Typed Wildcard FEC Element encoding.
型付きワイルドカードFEC元素を含むFEC TLVとラベル要求メッセージの受信は、型付きワイルドカードFEC要素符号化にFEC要素タイプフィールドによって指定されたタイプのすべてのFECための1つ以上のラベルマッピングを送信するための要求として解釈されます。
An LDP implementation that supports the Typed Wildcard FEC Element MUST support the following constraints whenever a Typed Wildcard FEC appears in a Label Withdraw or Label Release message:
型付きワイルドカードFECが撤回またはラベル解放メッセージラベルに表示されたときに型指定されたワイルドカードFEC要素をサポートしている自民党の実装では、次の制約をサポートする必要があります。
1) If the message carries an optional Label TLV, the Typed Wildcard FEC Element refers to all FECs of the specified FEC type bound to the specified label.
メッセージは、オプションのラベルTLVを運ぶ場合は1）、型付きワイルドカードFEC要素は、指定されたラベルに結合した指定されたFECタイプの全てのFECを指します。
2) If the message has no Label TLV, the Typed Wildcard FEC Element refers to all FECs of the specified FEC type.
メッセージはラベルなしTLVを持たない場合は2）、型付きワイルドカードFEC要素は、指定されたFECタイプの全てのFECを指します。
Backwards compatibility with a router not supporting the Typed Wildcard FEC element is ensured by the FEC procedures defined in RFC 5036. Quoting from RFC 5036:
下位ルータは型付きワイルドカードFEC要素をサポートしていないとの互換性は、RFC 5036から引用RFC 5036で定義されたFEC手順によって保証されます。
If it [an LSR] encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error.
それは[LSR]は、それがデコードできないFEC要素タイプに遭遇した場合、それは、FEC TLVを復号停止TLVを含むメッセージを処理中止し、エラーをシグナリングそのLDPピアに「不明FEC」通知メッセージを送信するべきです。
A router receiving a FEC TLV containing a Typed Wildcard FEC element for either a FEC Element Type that it doesn't support or for a FEC Element Type that doesn't support the use of wildcarding, MUST stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer to signal an error.
それはサポートしていないか、またはワイルドカードの使用をサポートしていないFEC要素タイプの、FEC TLVをデコード停止しなければならないのいずれかFEC要素タイプをそのための型付きワイルドカードFEC元素を含むFEC TLVを受信したルータは、処理をアボートTLVを含むメッセージ、およびエラーを通知するために、そのLDPピアに「不明FEC」通知メッセージを送信します。
A router receiving a FEC TLV containing a Typed Wildcard FEC element MAY also leverage mechanisms defined in [RFC5919] (say, if it had zero label binding for the requested FEC type, etc.).
型付きワイルドカードFEC元素を含むFEC TLVを受信したルータは、（それが要求されたFECタイプ、等に結合ゼロラベルを有する場合、例えば）[RFC5919]で定義され、またレバレッジ機構。
As noted above, RFC 5036 FEC procedures provide for backward compatibility with an LSR not supporting the Typed Wildcard FEC Element. However, they don't provide means for an LSR that wishes to use the Typed Wildcard FEC Element to determine whether a peer supports it other than to send a message that uses the FEC Element and to wait and see how the peer responds.
上述したように、RFC 5036 FEC手順は、LSRが入力ワイルドカードFEC素子を支持しないとの下位互換性を提供します。しかし、彼らはピアが、それは他のFEC要素を使用してメッセージを送信すると、待って、ピアがどのように応答するかを見るためよりも、サポートしているかどうかを判断するために型指定されたワイルドカードFEC要素を使用することを希望するLSRのための手段を提供していません。
An LDP speaker that supports the Typed Wildcard FEC Element MUST inform its peers of the support by including a Typed Wildcard FEC Element Capability Parameter [RFC5561] in its Initialization messages only.
型指定されたワイルドカードFEC要素をサポートしている自民党のスピーカーはその初期化メッセージに入力されたワイルドカードFEC要素の能力パラメータ[RFC5561]を含むことにより、支援のピアに通知しなければなりません。
The Capability Parameter for the Typed Wildcard FEC capability is a TLV with the following format:
型付きワイルドカードFEC機能のための能力パラメータは、次の形式の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|Typed WCard FEC Cap(0x050B)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 2: Typed Wildcard FEC Capability Format
図2：型指定されたワイルドカードFEC能力のフォーマット
Where:
どこ：
U and F bits: MUST be 1 and 0, respectively, as per Section 3 of LDP Capabilities [RFC5561].
U及びFビット：LDP機能[RFC5561]のセクション3に従って、それぞれ1と0でなければなりません。
Typed WCard FEC Cap: 0x050B
型付きWCard FECキャップ：0x050B
Length: Two octets. It MUST be set to 0x0001.
長さ：2つのオクテット。これは、0x0001のに設定しなければなりません。
S-bit: MUST be 1 (indicates that capability is being advertised).
Sビット：1でなければなりません（機能がアドバタイズされていることを示します）。
RFC 5036 defines the Prefix FEC Element, but it does not specify a Typed Wildcard for it. This section specifies the Typed Wildcard FEC Element for Prefix FEC Elements.
RFC 5036は、プレフィックスFEC要素を定義し、それはそれのために型指定されたワイルドカードを指定していません。このセクションでは、プレフィックスFEC要素のために型指定されたワイルドカードFEC要素を指定します。
The format of the Prefix FEC Typed Wildcard FEC Element ("Prefix FEC Wildcard" for short), based on Figure 1, is:
図1に基づいて、プレフィックスFEC型付きワイルドカードFEC要素（略して「プレフィックスFECワイルドカード」）のフォーマットは、次のとおりです。
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed Wcard | Type = Prefix | Len = 2 | Address... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...Family |
+-+-+-+-+-+-+-+-+
Figure 3: Format of Prefix FEC Element Using Typed Wildcard
図3：型付きワイルドカードを使用してプレフィックスFEC要素のフォーマット
Where:
どこ：
FEC Element Type: "Prefix" FEC Element (0x02, per RFC 5036).
FEC要素タイプ： "接頭辞"（RFC 5036あたり0x02の）FEC要素。
Len FEC Type Info: Two octets. It MUST be set to 0x0002.
レンFECタイプ情報：2つのオクテット。これは、0×0002に設定しなければなりません。
Address Family: Two-octet quantity containing a value from the "ADDRESS FAMILY NUMBERS" registry on http://www.iana.org.
家族アドレス：http://www.iana.orgの「アドレスファミリー番号」レジストリから値を含む2つのオクテットの数。
The procedures described in Section 4 apply to the Prefix FEC Wildcard processing.
セクション4に記載された手順は、プレフィックスFECワイルドカード処理に適用されます。
There is no need to specify Typed Wildcard FEC Elements for the Host FEC Element specified by [RFC3036], nor for the Wildcard FEC Element specified by RFC 5036. The [RFC3036] Host FEC Element has been removed from RFC 5036, and the Wildcard FEC Element is untyped by definition.
そこ[RFC3036]で指定されたホストFEC要素のために型指定されたワイルドカードFEC要素を指定する必要がなく、またワイルドカードFEC要素については、RFC 5036で指定された[RFC3036]ホストFEC要素は、RFC 5036、およびワイルドカードFECから削除されました要素は、定義上型なしです。
In other words, the 'FEC Element Type' field in 'Typed Wildcard FEC Element' MUST NOT be either 0x01 or 0x03.
言い換えれば、「型指定されたワイルドカードFEC要素」で「FEC要素タイプ」フィールドは0×01または0x03のどちらかにすることはできません。
This document introduces a new LDP FEC Element Type and a new LDP Capability, both of which have been assigned by IANA.
この文書は、新しいLDP FEC要素タイプと新しいLDP機能を紹介し、IANAによって割り当てられているどちらも。
IANA has assigned a 'Typed Wildcard FEC Element' code point (0x05) from the LDP FEC Type Name Space. [RFC5036] partitions the FEC Type Name Space into 3 regions: IETF Consensus region, First Come First Served region, and Private Use region. The code point 0x05 is from the IETF Consensus range.
IANAは、LDP FECタイプネームスペースから「型付きワイルドカードFEC要素」コード・ポイント（0×05）を割り当てました。 [RFC5036]は3つの領域にFECタイプネームスペースを仕切る：IETFコンセンサス領域、まず最初に添え地域、およびプライベート使用領域を、是非。コードポイント0x05のはIETFコンセンサス範囲です。
IANA has assigned a 'Typed Wildcard FEC Capability' code point (0x050B) 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 0x050B is from the IETF Consensus range.
IANAは、TLVタイプのネームスペースから「型指定されたワイルドカードFEC能力」コード・ポイント（0x050B）が割り当てられています。 IETFコンセンサス領域、ベンダーのプライベート使用領域、および実験的使用の地域：[RFC5036]は3つの領域にTLV TYPE名前空間を仕切ります。コードポイント0x050BはIETFコンセンサス範囲です。
No security considerations beyond those that apply to the base LDP specification [RFC5036] and that are further described in [RFC5920] apply to use of the Typed Wildcard FEC Elements as described in this document.
さらに、[RFC5920]に記載されてはセキュリティベースLDP仕様[RFC5036]に適用されるもの以外の考慮事項とは、この文書に記載されているように型付きワイルドカードFEC要素を使用するために適用されません。
One could deduce that the security exposure is reduced by this document, since an LDP speaker using the Typed Wildcard FEC Element could use a single message to request, withdraw, or release all the label mappings of a particular type (a particular Address Family Identifier (AFI), for example), whereas an LDP speaker using the Wildcard FEC Element, as defined in the base LDP specification [RFC5036], could use a single message to request, withdraw, or release all the label mappings of all types (all AFIs, for example).
型指定されたワイルドカードFEC要素を使用してLDPのスピーカーは、要求する単一のメッセージを使用して撤回する、または特定の型（特定のアドレスファミリ識別子（のすべてのラベルのマッピングを解除する可能性があるので一つは、セキュリティの暴露が、この文書で減少していることを推測することができ例えばAFI）は、）、ワイルドカードFEC素子を用いたLDPスピーカーに対し、ベースLDP仕様[RFC5036]で定義されるように、（すべてのAFISを要求撤回、またはすべてのタイプのすべてのラベルのマッピングを解放するために単一のメッセージを使用することができます、 例えば）。
The authors would like to thank Yakov Rekhter for suggesting that the limitations of the Wildcard FEC be addressed. Also, thanks to Adrian Farrel, Kamran Raza, and Richard L. Barnes for extensive review of this document.
著者は、ワイルドカードFECの制限に対処することを示唆しているためヤコフ・レックターに感謝したいと思います。また、この文書の大規模な見直しのためのエードリアンファレル、カムランラザ、そしてリチャード・L.バーンズのおかげ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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]トーマス、B.、ラザ、K.、アガルワル、S.、アガルワル、R.、およびJL。ル・ルー、 "LDP機能"、RFC 5561、2009年7月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、2006年4月。
[RFC5919] Asati, R., Mohapatra, P., Minei, I., and B. Thomas, "Signaling LDP Label Advertisement Completion", RFC 5919, August 2010.
[RFC5919] Asati、R.、Mohapatra、P.、Minei、I.、およびB.トーマス、 "シグナリングLDPラベル広告完了"、RFC 5919、2010年8月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、RFC 5920、2010年7月。
[MLDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, July 2010.
[MLDP] Minei、I.、エド。、Kompella、K.、Wijnands、I.、エド。、およびB.トーマス、「ラベル配布プロトコルの拡張ポイント・ツー・マルチポイントおよびマルチポイント・ツー・マルチポイントラベルは、パスの交換しました」 、進捗状況、2010年7月に作業。
Authors' Addresses
著者のアドレス
Rajiv Asati Cisco Systems 7025-6 Kit Creek Rd. Research Triangle Park, NC 27709-4987 EMail: rajiva@cisco.com
ラジブAsatiシスコシステムズ7025から6キットクリークRdを。リサーチトライアングルパーク、NC 27709-4987 Eメール：rajiva@cisco.com
Ina Minei Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: ina@juniper.net
伊那Mineiジュニパーネットワークスの1194北マチルダアベニュー。サニーベール、CA 94089 Eメール：ina@juniper.net
Bob Thomas EMail: bobthomas@alum.mit.edu
ボブトーマスEメール：bobthomas@alum.mit.edu