RFC 5918 - Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5918
タイトル : RFC 5918 - ラベル分布プロトコル（LDP）「タイプされたワイルドカード」フォワード等価クラス（FEC）
翻訳編集 : 自動生成

[要約] RFC 5918は、LDPの'Typed Wildcard' FECに関する仕様です。目的は、LDPのFECをより柔軟に定義し、ネットワークリソースの効率的な利用を可能にすることです。

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)

ラベル分布プロトコル（LDP）「タイプされたワイルドカード」フォワード等価クラス（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要素と関連する手順を定義することにより、これらの制限に対処します。さらに、後方互換性に対処するための新しい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/rfc5918.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5918で取得できます。

著作権表示

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
   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

1. Introduction

1. はじめに

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）を転送するためのラベルを配布しています。LDPは、LDPメッセージのFEC TLVを使用してFECを指定します。LDP FEC TLVには、1つ以上の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タイプを指定します。たとえば、[RFC447]および[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:

WildCard 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) WildCard 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) WildCard 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.

- Label RequestメッセージでタイプされたWildCard 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要素に指定された手順を変更しないことに注意してください。

2. Specification Language

2. 仕様言語

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]に記載されているように解釈される。

LDP - Label Distribution Protocol

LDP-ラベル分布プロトコル

FEC - Forwarding Equivalence Class

FEC-転送等価クラス

TLV - Type Length Value

TLV-タイプの長さ値

LSR - Label Switching Router

LSR-ラベルスイッチングルーター

3. The Typed Wildcard FEC Element

3. タイプされたワイルドカードFEC要素

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要素タイプ（0x05）。

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要素タイプを指定するOne-OCTET 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.

新しいFEC要素タイプ（RFC 5036で定義されていない）を指定する（将来）ドキュメントは、そのFEC要素タイプに型付けされたワイルドカードが必要かどうかを処方する必要があります。

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.

LEN 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.

任意のFEC要素タイプにタイプされたワイルドカードを指定する（将来）ドキュメントは、追加のFECタイプ固有の情報の長さと形式を指定する必要があります（含まれている場合）。

This document specifies one FEC Element Type instance (e.g., Prefix FEC) for the 'Typed Wildcard FEC Element' in Section 6.

このドキュメントは、セクション6の「タイプされたワイルドカードFEC要素」の1つのFEC要素タイプインスタンス（例：プレフィックスFEC）を指定します。

4. Procedures for the Typed Wildcard FEC Element

4. タイプされたワイルドカード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にタイプ付きWildCard FEC要素が含まれている場合、タイプされたWildCard 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.

タイプされたWildCard FEC要素をサポートするLDP実装は、ラベルリクエスト、ラベル引き出し、およびラベルリリースメッセージでの使用をサポートする必要があります。

An LDP implementation that supports the Typed Wildcard FEC Element MUST support it for every FEC Element Type defined in [RFC5036].

[RFC5036]で定義されているすべてのFEC要素タイプに対して、タイプされたWildCard FEC要素をサポートするLDP実装はそれをサポートする必要があります。

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: 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.

タイプされたワイルドカードFEC要素をサポートするLDP実装は、タイプされたワイルドカードFECがラベル引き出しまたはラベルリリースメッセージに表示される場合に次の制約をサポートする必要があります。指定されたラベルにバインドされた指定されたFECタイプの。

2) If the message has no Label TLV, the Typed Wildcard FEC Element refers to all FECs of the specified FEC type.

2) メッセージにラベルTLVがない場合、タイプされたワイルドカード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で定義されたFEC手順によって保証されます。RFC5036から引用してください。

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を含むメッセージの処理を中止し、「不明なFEC」通知メッセージをLDPピアにエラーを信号するように送信する必要があります。

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を含むメッセージ、および「不明なFEC」通知メッセージをLDPピアに送信して、エラーを知らせます。

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を受信するルーターは、[RFC5919]で定義されたメカニズムを活用することもできます（要求されたFECタイプなど、ゼロラベル結合があった場合）。

5. Typed Wildcard FEC Capability

5. タイプされたワイルドカードFEC機能

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プロシージャは、タイプされたワイルドカードFEC要素をサポートしていないLSRとの後方互換性を提供します。ただし、タイプされたワイルドカード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.

タイプされたWildCard FEC要素をサポートするLDPスピーカーは、初期化メッセージのみに型付けされたWildCard FEC要素機能パラメーター[RFC5561]を含めることにより、ピアにサポートを通知する必要があります。

The Capability Parameter for the Typed Wildcard FEC capability is a TLV with the following format:

タイプされたWildCard 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-bit：1でなければなりません（機能が宣伝されていることを示します）。

6. Typed Wildcard FEC Element for Prefix FEC Element

6. 接頭辞FEC要素の型式ワイルドカードFEC要素

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要素タイプ：「プレフィックス」FEC要素（0x02、RFC 5036あたり）。

Len FEC Type Info: Two octets. It MUST be set to 0x0002.

LEN FECタイプ情報：2オクテット。0x0002に設定する必要があります。

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ワイルドカード処理に適用されます。

7. Typed Wildcard FEC Element for Host and Wildcard FEC Elements

7. ホストおよびワイルドカードFEC要素のためのタイプされたワイルドカード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要素、RFC 5036で指定されたワイルドカードFEC要素については、[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要素タイプ」フィールドは、0x01または0x03であってはなりません。

8. IANA Considerations

8. IANAの考慮事項

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要素」コードポイント（0x05）を割り当てました。[RFC5036]は、FECタイプ名スペースを3つの地域に分割します：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）を割り当てました。[RFC5036] TLVタイプ名スペースを3つの領域に分割します：IETFコンセンサス地域、ベンダープライベート使用地域、および実験的使用地域。コードポイント0x050Bは、IETFコンセンサス範囲からのものです。

9. Security Considerations

9. セキュリティに関する考慮事項

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.

ベースLDP仕様[RFC5036]に適用され、[RFC5920]でさらに説明されているものを超えたセキュリティ上の考慮事項は、このドキュメントで説明されているタイプされたワイルドカード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).

タイプ付きWildCard FEC要素を使用したLDPスピーカーは、特定のタイプのすべてのラベルマッピング（特定のアドレスファミリ識別子（特定のアドレス識別子）を要求、撤回、またはリリースすることができるため、このドキュメントによってセキュリティ露出が減少すると推測できます。たとえば、AFI））、ベースLDP仕様[RFC5036]で定義されているワイルドカードFEC要素を使用するLDPスピーカーは、すべてのタイプのすべてのラベルマッピングを要求、撤回、またはリリースするために単一のメッセージを使用できます（すべてAFIS、例えば）。

10. Acknowledgments

10. 謝辞

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の制限に対処することを提案してくれたYakov Rekhterに感謝したいと思います。また、この文書の広範なレビューをしてくれたAdrian Farrel、Kamran Raza、およびRichard L. Barnesに感謝します。

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

[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月。

11.2. Informative References

11.2. 参考引用

[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。、およびB. Thomas、「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] Martini、L.、Ed。、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、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.、Mighei、I。、およびB. Thomas、「シグナリングLDPラベル広告の完了」、RFC 5919、2010年8月。

[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月。

[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] Misei、I.、ed。、Kompella、K.、Wijnands、I.、ed。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチパスのラベル分布プロトコル拡張式」、進行中の作業、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

Ina Minei Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: ina@juniper.net

Ina Misei Juniper Networks 1194 North Mathilda Ave. Sunnyvale、CA 94089メール：ina@juniper.net

Bob Thomas EMail: bobthomas@alum.mit.edu

ボブ・トーマス・メール：bobthomas@alum.mit.edu