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）IETFトラスト（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タイプの構成は、最も簡単に一つだけPW終点でこの情報を設定することによって達成されます。 LDPベースのシグナリングの任意の形態で、各PWエンドポイントは一方向LSPの作成を開始しなければなりません。これら二つのLSPの開始が独立したままにできるようにするために、手段は、LSPの作成を開始する（PWタイプの先験的な知識を欠いている）PWエンドポイントを可能にするために必要とされます。この文書では、このニーズを満たすためにワイルドカード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タイプの構成は、最も簡単に一つだけ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.
[CONTROL]の手順では、両方のラベルマッピングメッセージは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）は、リモートのPE上のレイヤ2ネットワークとレイヤ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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
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].
この文書は、新しい用語を紹介しません。しかし、読者が[CONTROL]に含まれている用語及びRFC 3985、「擬似ワイヤエミュレーションエッジ・ツー・エッジ（PWE3）アーキテクチャ」[ARCH]に精通していることを前提としています。
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タイプが定義されています。コードポイントは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.
標的PE 1.、この値は、それが（両方向について）PWタイプを決定し、バック開始PEにLabel Mappingメッセージにそれを知らせるためであることを示しています。
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. [CONTROL]の手順については、この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.
Label Mappingメッセージが疑似回線用に受信されると、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.
この文書では、[CONTROL]のセキュリティ面にほとんど影響しません。メッセージ交換は同じままです。しかし、アクセス回線に接続しようとする悪意のあるエージェントが情報の1以下枚が必要となります。明示的にTAI内の特定のAIのためにそうするように構成されている場合、このを軽減するには、ワイルドカードFECタイプを含む要求を受信し、擬似回線制御エンティティは、セットアップを進めるべきです。さらに、読者は、一般的には、[CONTROL]のセキュリティ上の考慮事項に注意する必要があり、特に一般PWID FEC要素に関連するものを、。
IANA has made the following allocation from the IETF consensus range of the "Pseudowire Type" registry as defined in [IANA].
[IANA]で定義されるようにIANAは、「疑似回線種別」のレジストリの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.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
[CONTROL]、RFC 4447マティーニ、L.、エド。、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス" 、2006年4月。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[IANA]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーション（PWE3）への擬似回線EdgeのIANAの割り当て"。
[ARCH] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[ARCH]ブライアント、S.、エド。、およびP.パテ、エド。、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
Authors' Addresses
著者のアドレス
Luca Martini Cisco Systems 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112
ルカ・マティーニシスコシステムズ9155東ニコルズアベニュー、スイート400イングルウッド、CO、80112
EMail: lmartini@cisco.com
メールアドレス：lmartini@cisco.com
George Swallow Cisco Systems 1414 Massachusetts Ave, Boxborough, MA 01719
ジョージツバメシスコシステムズ1414年マサチューセッツアベニュー、ボックスボロー、MA 01719
EMail: swallow@cisco.com
メールアドレス：swallow@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。