RFC4863 日本語訳

Network Working Group                                         L. Martini
Request for Comments: 4863                                    G. Swallow
Category: Standards Track                            Cisco Systems, Inc.
                                                                May 2007

コメントを求めるワーキンググループL.マティーニ要求をネットワークでつないでください: 4863年のG.ツバメカテゴリ: 標準化過程シスコシステムズInc.2007年5月

                        Wildcard Pseudowire Type

ワイルドカードPseudowireタイプ

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

Pseudowireシグナリングは、Pseudowire Type(PW Type)が両方の方向と同じであることを必要とします。 あるアプリケーションにおいて、PW Typeの構成は、ちょうど1つのPW終点でこの情報を構成することによって、最も容易に達成されます。 どんなフォームの自由民主党ベースのシグナリングではも、それぞれのPW終点は単方向LSPの創造を開始しなければなりません。 これらの2LSPsの開始が独立性を確保するのを許容するために、PW終点(PW Typeに関する先験的な欠いている知識)がLSPの創造を開始するのを許容するのに手段が必要です。 このドキュメントは、この需要を満たすためにWildcard PW Typeを定義します。

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

1. 序論…2 1.1. コンベンションと用語…2 2. ワイルドカードPWはタイプします…3 3. 手順…3 3.1. 手順、ワイルドカードFECを送るとき…3 3.2. 手順、ワイルドカードFECを受けるとき…3 4. セキュリティ問題…4 5. IANA問題…4 6. 参照…4 6.1. 標準の参照…4 6.2. 有益な参照…4

Martini & Swallow           Standards Track                     [Page 1]

RFC 4863                Wildcard Pseudowire Type                May 2007

マティーニとツバメ標準化過程[1ページ]RFC4863ワイルドカードPseudowireは2007年5月にタイプします。

1.  Introduction

1. 序論

   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.

Pseudowireシグナリングは、Pseudowire Type(PW Type)が両方の方向と同じであることを必要とします。 あるアプリケーションにおいて、PW Typeの構成は、ちょうど1つのPW終点でこの情報を構成することによって、最も容易に達成されます。 どんなフォームの自由民主党ベースのシグナリングではも、それぞれの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]の手順で、両方のLabel MappingメッセージはPWタイプを運ばなければなりません、そして、2つの単方向のマッピングメッセージが合意しているに違いありません。 したがって、現在の手順の中では、構成を欠いているPW終点は、PW Typeを学ぶためにLabel Mappingメッセージを受け取るのを待たなければなりません、単方向LSPに合図する前に。

   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.

あるアプリケーションのために、これは特に煩わしくなることができます。 例えば、イングレスProvider Edge(PE)が層2のネットワークと層の間のゲートウェイ機能の一部としてリモートPEsの上の2個の付属サーキットに役立っていると仮定してください。 初期のセットアップが、2がネットワークでつなぐ層から開始される必要がありますが、層2のシグナリングが十分な情報を含まないとさらに仮定して、PW Typeを決定してください。 しかしながら、この情報は、狙っている付属サーキットを支えながら、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.

この状況で、pseudowireを構成する2LSPsの開始が独立性を確保するのを許容するのはしばしば望ましいです。 PW終点(PW Typeに関する先験的な欠いている知識)がLSPの創造を開始するのを許容するのに手段が必要です。 このドキュメントはこれを満たすPW Typeが定義しなければならないワイルドカードを定義します。

1.1.  Conventions and Terminology

1.1. コンベンションと用語

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?

   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]とRFC3985に含まれた用語、「疑似ワイヤのエミュレーションの縁から縁(PWE3)への構造」[ARCH]に詳しいと仮定します。

Martini & Swallow           Standards Track                     [Page 2]

RFC 4863                Wildcard Pseudowire Type                May 2007

マティーニとツバメ標準化過程[2ページ]RFC4863ワイルドカードPseudowireは2007年5月にタイプします。

2.  Wildcard PW Type

2. ワイルドカードPWタイプ

   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がpseudowireタイプを知らないでpseudowireへのシグナリング交換を起こすのを許容するために、新しいPW Typeは定義されます。 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 Type(両方の指示のための)を決定して、Label Mappingメッセージで開始している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. [CONTROL]の手順において、このPW Typeは、それ自体以外のどんなPW Typeも合わせるために解釈されます。 すなわち、狙っているPEはワイルドカードPW Type以外のどんな有効なPW Typeと共にも応じるかもしれません。

3.  Procedures

3. 手順

3.1.  Procedures When Sending the Wildcard FEC

3.1. 手順、ワイルドカードFECを送ります。

   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.

特定のpseudowireに特定のPW Typeを使用するために構成されないPEがそのpseudowireのためにLSPに合図したがっているとき、それは「ワイルドカード」にPW Typeを設定します。 これは、目標PEがこのpseudowireのためにPW Typeを決定するはずであるのを示します。

   When a Label Mapping message is received for the pseudowire, the PE
   checks the PW Type.

pseudowireのためにLabel Mappingメッセージを受け取るとき、PEはPW Typeをチェックします。

   If the PW Type can be supported, the PE uses this as the PW Type for
   both directions.

PW Typeを支持できるなら、PEは両方の指示にPW Typeとしてこれを使用します。

   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 Typeが支持できませんし、「ワイルドカード」であるなら、それは「一般的なMisconfiguration誤り」の自由民主党Status Codeと共にLabel Releaseメッセージでこのメッセージに応じなければなりません。 さらなる動作は、このドキュメントの範囲を超えていますが、関連するアプリケーション(もしあれば)に通知するか、またはネットワークマネージメントに通知するのを含むかもしれません。

3.2.  Procedures When Receiving the Wildcard FEC

3.2. 手順、ワイルドカードFECを受けます。

   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 Typeを示すLabel Mappingメッセージを受け取るとき、それはAttachment Group Identifier(AGI)とTarget Attachment Individual Identifier(TAII)値をチェックするための正常な手順に従います。 狙っているPEが特定の、そして、非ワイルドカードのPW Typeを使用するために構成されないなら、それは「一般的なMisconfiguration誤り」の自由民主党Status Codeと共にLabel Releaseメッセージでこのメッセージに応じなければなりません。

   Otherwise, it treats the Label Mapping message as if it had indicated
   the PW Type it is configured to use.

さもなければ、それはまるで使用するのが構成されているPW Typeを示したかのようにLabel Mappingメッセージを扱います。

Martini & Swallow           Standards Track                     [Page 3]

RFC 4863                Wildcard Pseudowire Type                May 2007

マティーニとツバメ標準化過程[3ページ]RFC4863ワイルドカードPseudowireは2007年5月にタイプします。

4.  Security Considerations

4. セキュリティ問題

   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つの減の情報を必要とするでしょう。 これを困難にするために、明らかである場合にだけタイプSHOULDがセットアップで続かせるワイルドカードFECを含む要求を受け取るpseudowireコントロール実体はTAIの特定のAIのためにそうするのを構成されました。 一般に、さらに、読者は[CONTROL]のセキュリティ問題に注意するべきです。そして、Generalized PWid FEC Elementに特に関係するもの。

5.  IANA Considerations

5. IANA問題

   IANA has made the following allocation from the IETF consensus range
   of the "Pseudowire Type" registry as defined in [IANA].

IANAは[IANA]で定義されるように「Pseudowireタイプ」登録のIETFコンセンサス範囲から以下の配分をしました。

         PW Type        Description

PW型記述

         0x7FFF         Wildcard

0x7FFFワイルドカード

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.

[コントロール]マティーニ、L.(エド)、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。

   [IANA]       Martini, L., "IANA Allocations for Pseudowire Edge to
                Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

[IANA] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。

6.2.  Informative References

6.2. 有益な参照

   [ARCH]       Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire
                Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985,
                March 2005.

[アーチ形に曲げます] ブライアント、S.、エド、P.頭、エド、「疑似ワイヤのエミュレーションの縁から縁(PWE3)への構造」、RFC3985、3月2005日

Martini & Swallow           Standards Track                     [Page 4]

RFC 4863                Wildcard Pseudowire Type                May 2007

マティーニとツバメ標準化過程[4ページ]RFC4863ワイルドカードPseudowireは2007年5月にタイプします。

Authors' Addresses

作者のアドレス

   Luca Martini
   Cisco Systems
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112

ルカマティーニシスコシステムズ9155のEastニコルズAvenue、イングルウッド、Suite400CO 80112

   EMail: lmartini@cisco.com

メール: lmartini@cisco.com

   George Swallow
   Cisco Systems
   1414 Massachusetts Ave,
   Boxborough, MA 01719

Boxborough、MA ジョージツバメシスコシステムズ1414マサチューセッツAve、01719

   EMail: swallow@cisco.com

メール: swallow@cisco.com

Martini & Swallow           Standards Track                     [Page 5]

RFC 4863                Wildcard Pseudowire Type                May 2007

マティーニとツバメ標準化過程[5ページ]RFC4863ワイルドカードPseudowireは2007年5月にタイプします。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Martini & Swallow           Standards Track                     [Page 6]

マティーニとツバメ標準化過程[6ページ]