[要約] RFC 4863は、Wildcard Pseudowire Type（WPT）を定義し、異なるPseudowireタイプ間の相互運用性を向上させるための仕様です。WPTは、異なるPseudowireタイプ間での柔軟な接続を可能にし、ネットワークの効率性と柔軟性を向上させることを目的としています。
Network Working Group L. Martini
Request for Comments: 4863 G. Swallow
Category: Standards Track Cisco Systems, Inc.
May 2007
Wildcard Pseudowire Type
ワイルドカードの擬似型タイプ
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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these two LSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need.
擬似ワイヤーシグナル伝達では、擬似ワイヤータイプ（PWタイプ）が両方向に同一であることを要求しています。特定のアプリケーションでは、PWタイプの構成は、この情報を1つのPWエンドポイントで構成することで最も簡単に実現できます。あらゆる形態のLDPベースのシグナル伝達では、各PWエンドポイントは単方向LSPの作成を開始する必要があります。これら2つのLSPの開始を独立したままにするためには、PWエンドポイント（PWタイプの先験的な知識がない）がLSPの作成を開始できるようにするための手段が必要です。このドキュメントでは、このニーズを満たすためにワイルドカードPWタイプを定義しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions and Terminology ................................2
2. Wildcard PW Type ................................................3
3. Procedures ......................................................3
3.1. Procedures When Sending the Wildcard FEC ...................3
3.2. Procedures When Receiving the Wildcard FEC .................3
4. Security Considerations .........................................4
5. IANA Considerations .............................................4
6. References ......................................................4
6.1. Normative References .......................................4
6.2. Informative References .....................................4
Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form of LDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP.
擬似ワイヤーシグナル伝達では、擬似ワイヤータイプ（PWタイプ）が両方向に同一であることを要求しています。特定のアプリケーションでは、PWタイプの構成は、この情報を1つのPWエンドポイントで構成することで最も簡単に実現できます。あらゆる形態のLDPベースのシグナル伝達では、各PWエンドポイントは単方向LSPの作成を開始する必要があります。
By the procedures of [CONTROL], both Label Mapping messages must carry the PW type, and the two unidirectional mapping messages must be in agreement. Thus within the current procedures, the PW endpoint that lacks configuration must wait to receive a Label Mapping message in order to learn the PW Type, prior to signaling its unidirectional LSP.
[コントロール]の手順により、両方のラベルマッピングメッセージがPWタイプを伝達する必要があり、2つの単方向マッピングメッセージが一致する必要があります。したがって、現在の手順内で、構成がないPWエンドポイントは、単方向LSPを信号する前に、PWタイプを学習するためにラベルマッピングメッセージを受信するのを待つ必要があります。
For certain applications this can become particularly onerous. For example, suppose that an ingress Provider Edge (PE) is serving as part of a gateway function between a layer 2 network and layer 2 attachment circuits on remote PEs. Suppose further that the initial setup needs to be initiated from the layer 2 network, but the layer 2 signaling does not contain sufficient information to determine the PW Type. However, this information is known at the PE supporting the targeted attachment circuit.
特定のアプリケーションでは、これは特に面倒になります。たとえば、イングレスプロバイダーのエッジ（PE）が、レイヤー2ネットワークとリモートPEのレイヤー2アタッチメント回路の間のゲートウェイ関数の一部として機能しているとします。さらに、初期セットアップをレイヤー2ネットワークから開始する必要があるが、レイヤー2シグナル伝達にはPWタイプを決定するのに十分な情報が含まれていないと仮定します。ただし、この情報は、ターゲットアタッチメント回路をサポートするPEで知られています。
In this situation, it is often desirable to allow the initiation of the two LSPs that compose a pseudowire to remain independent. A means is needed for allowing a PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a wildcard PW Type to satisfy this need.
この状況では、疑似具体を構成する2つのLSPの開始を可能にすることがしばしば望ましいです。LSPの作成を開始するためにPWエンドポイント（PWタイプの先験的な知識がない）を許可するには、手段が必要です。このドキュメントでは、このニーズを満たすためにワイルドカードPWタイプを定義しています。
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 RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
This document introduces no new terminology. However, it assumes that the reader is familiar with the terminology contained in [CONTROL] and RFC 3985, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture" [ARCH].
このドキュメントでは、新しい用語を紹介しません。ただし、読者は[コントロール]およびRFC 3985、「擬似ワイヤエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」に含まれる用語に精通していると想定しています。
In order to allow a PE to initiate the signaling exchange for a pseudowire without knowing the pseudowire type, a new PW Type is defined. The codepoint is 0x7FFF. The semantics are the following:
PEが擬似ワイヤのタイプを知らずに擬似具のシグナリング交換を開始できるようにするために、新しいPWタイプが定義されています。CodePointは0x7fffです。セマンティクスは次のとおりです。
1. To the targeted PE, this value indicates that it is to determine the PW Type (for both directions) and signal that in a Label Mapping message back to the initiating PE.
1. ターゲットを絞ったPEに、この値は、PWタイプ（両方の方向）を決定し、ラベルマッピングメッセージで開始PEに戻ることを示すことを示しています。
2. For the procedures of [CONTROL], this PW Type is interpreted to match any PW Type other than itself. That is, the targeted PE may respond with any valid PW Type other than the wildcard PW Type.
2. [コントロール]の手順では、このPWタイプはそれ自体以外のPWタイプに一致すると解釈されます。つまり、ターゲットPEは、ワイルドカードPWタイプ以外の有効なPWタイプで応答する場合があります。
When a PE that is not configured to use a specific PW Type for a particular pseudowire wishes to signal an LSP for that pseudowire, it sets the PW Type to "wildcard". This indicates that the target PE should determine the PW Type for this pseudowire.
特定の擬似ワイヤーに特定のPWタイプを使用するように構成されていないPEが、その擬似化のLSPを信号することを望んでいる場合、PWタイプを「ワイルドカード」に設定します。これは、ターゲットPEがこの擬似ワイヤのPWタイプを決定する必要があることを示しています。
When a Label Mapping message is received for the pseudowire, the PE checks the PW Type.
PSEUDOWIREに対してラベルマッピングメッセージが受信されると、PEはPWタイプをチェックします。
If the PW Type can be supported, the PE uses this as the PW Type for both directions.
PWタイプをサポートできる場合、PEはこれを両方向のPWタイプとして使用します。
If the PW Type cannot be supported or is "wildcard", it MUST respond to this message with a Label Release message with an LDP Status Code of "Generic Misconfiguration Error". Further actions are beyond the scope of this document, but could include notifying the associated application (if any) or notifying network management.
PWタイプをサポートできない、または「ワイルドカード」である場合、「一般的なミスコンスミュレーションエラー」のLDPステータスコードを使用したラベルリリースメッセージでこのメッセージに応答する必要があります。さらなるアクションはこのドキュメントの範囲を超えていますが、関連するアプリケーションの通知（もしあれば）またはネットワーク管理の通知を含めることができます。
When a targeted PE receives a Label Mapping message indicating the wildcard PW Type, it follows the normal procedures for checking the Attachment Group Identifier (AGI) and Target Attachment Individual Identifier (TAII) values. If the targeted PE is not configured to use a specific, non-wildcard PW Type, it MUST respond to this message with a Label Release message with an LDP Status Code of "Generic Misconfiguration Error".
ターゲットを絞ったPEがワイルドカードPWタイプを示すラベルマッピングメッセージを受信すると、アタッチメントグループ識別子（AGI）とターゲットアタッチメント個体識別子（TAII）値をチェックするための通常の手順に従います。ターゲットを絞ったPEが特定の非ワイルドカードPWタイプを使用するように構成されていない場合、「一般的なミスコンスフィラーエラー」のLDPステータスコードを使用して、ラベルリリースメッセージでこのメッセージに応答する必要があります。
Otherwise, it treats the Label Mapping message as if it had indicated the PW Type it is configured to use.
それ以外の場合は、使用するように構成されているPWタイプを示しているかのように、ラベルマッピングメッセージを扱います。
This document has little impact on the security aspects of [CONTROL]. The message exchanges remain the same. However, a malicious agent attempting to connect to an access circuit would require one less piece of information. To mitigate against this, a pseudowire control entity receiving a request containing the wildcard FEC type SHOULD only proceed with setup if explicitly configured to do so for the particular AI in the TAI. Further, the reader should note the security considerations of [CONTROL], in general, and those pertaining to the Generalized PWid FEC Element, in particular.
このドキュメントは、[コントロール]のセキュリティの側面にほとんど影響を与えません。メッセージ交換は同じままです。ただし、アクセス回路に接続しようとする悪意のあるエージェントには、1つの少ない情報が必要です。これに対して緩和するために、WildCard FECタイプを含むリクエストを受信する擬似ワイヤ制御エンティティは、TAIの特定のAIに対して明示的に設定されている場合にのみセットアップを続行する必要があります。さらに、読者は[コントロール]のセキュリティ上の考慮事項と、特に一般化されたPWID FEC要素に関係するセキュリティに関する考慮事項に注意する必要があります。
IANA has made the following allocation from the IETF consensus range of the "Pseudowire Type" registry as defined in [IANA].
IANAは、[IANA]で定義されているように、「Pseudowire Type」レジストリのIETFコンセンサス範囲から次の割り当てを行いました。
PW Type Description
PWタイプの説明
0x7FFF Wildcard
0x7fffワイルドカード
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[CONTROL] 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.
[コントロール] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「Pseudowireのセットアップとラベル分布プロトコル（LDP）を使用したメンテナンス」、RFC 4447、2006年4月。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[IANA] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[ARCH] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[Arch] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture」、RFC 3985、2005年3月。
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
Luca Martini Cisco Systems 9155 East Nichols Avenue、Suite 400 Englewood、Co、80112
EMail: lmartini@cisco.com
George Swallow Cisco Systems 1414 Massachusetts Ave, Boxborough, MA 01719
ジョージスワローシスコシステム1414マサチューセッツアベニュー、ボックスボロー、マサチューセッツ州01719
EMail: swallow@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。