[要約] RFC 4816は、PWE3に関するATM透過セルトランスポートサービスについての標準仕様です。このRFCの目的は、ATMネットワーク上での仮想回線のエミュレーションを可能にするためのプロトコルを提供することです。

Network Working Group                                          A. Malis
Request for Comments: 4816                                      Verizon
Category: Standards Track                                    L. Martini
                                                          Cisco Systems
                                                             J. Brayley
                                                            ECI Telecom
                                                               T. Walsh
                                                       Juniper Networks
                                                          February 2007
        

Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service

Pseudowire Emulation Edge-to-Edge(PWE3)非同期転送モード(ATM)透明な細胞輸送サービス

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

概要

The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation.

このドキュメントでは、擬似ワイヤエミュレーションエッジツーエッジ(PWE3)非同期トランスファーモード(ATM)セルカプセル化のための「N-To-one」セルリレーモードを利用する透明なセル輸送サービスについて説明します。

1. Introduction
1. はじめに

This transparent cell transport service allows migration of ATM services to a PSN without having to provision the ATM subscriber or customer edge (CE) devices. The ATM CEs will view the ATM transparent cell transport service as if they were directly connected via a Time Division Multiplexer (TDM) leased line. This service is most likely to be used as an internal function in an ATM service provider's network as a way to connect existing ATM switches via a higher-speed PSN, or to provide ATM "backhaul" services for remote access to existing ATM networks.

この透明なセル輸送サービスにより、ATMサブスクライバーまたは顧客エッジ(CE)デバイスをプロビジョニングすることなく、ATMサービスをPSNに移行できます。ATM CESは、ATM透過セル輸送サービスを、まるでタイムディビジョンマルチプレクサ(TDM)リースラインを介して直接接続されているかのように表示されます。このサービスは、高速PSNを介して既存のATMスイッチを接続する方法として、または既存のATMネットワークへのリモートアクセスのためにATM「バックホール」サービスを提供する方法として、ATMサービスプロバイダーのネットワークの内部機能として使用される可能性が最も高くなります。

1.1. Specification of Requirements
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 [1].

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [1]に記載されているように解釈される。

2. Transparent Cell Transport Definition
2. 透明な細胞輸送の定義

The transparent port service is a natural application of the "N-to-one" Virtual Circuit Connection (VCC) cell transport mode for PWE3 ATM encapsulation described in [2], and MUST be used with pseudowires of type 0x0003, "ATM transparent cell transport" [4].

透明なポートサービスは、[2]で説明されているPWE3 ATMカプセル化の「N-To-One」仮想回路接続(VCC)セル輸送モードの自然なアプリケーションであり、タイプ0x0003の擬似ワイヤで使用する必要があります。輸送」[4]。

The ATM transparent port service emulates connectivity between two remote ATM ports. This service is useful when one desires to connect two CEs without processing or switching at the Virtual Path Connection (VPC) or VCC layer. The ingress PE discards any idle/unassigned cells received from the ingress ATM port, and maps all other received cells to a single pseudowire.

ATM透明なポートサービスは、2つのリモートATMポート間の接続をエミュレートします。このサービスは、仮想パス接続(VPC)またはVCCレイヤーで処理または切り替えずに2つのCEを接続したい場合に役立ちます。Ingress PEは、Ingress ATMポートから受信されたアイドル/割り当てられていないセルを破棄し、他のすべての受信したセルを単一の擬似ワイヤにマッピングします。

The egress PE does not change the Virtual Path Identifier (VPI), Virtual Circuit Identifier (VCI), Payload Type Identifier (PTI), or Cell Loss Priority (CLP) bits when it sends these cells on the egress ATM port. Therefore, the transparent port service appears to emulate an ATM transmission convergence layer connection between two ports. However, since the ingress PE discards idle/unassigned cells, this service benefits from statistical multiplexing bandwidth savings.

出力PEは、出力ATMポートにこれらのセルを送信するときに、仮想パス識別子(VPI)、仮想回路識別子(VCI)、ペイロードタイプ識別子(PTI)、またはセル損失優先順位(CLP)ビットを変更しません。したがって、透明なポートサービスは、2つのポート間のATM伝送収束層接続をエミュレートするように見えます。ただし、Ingress PEはアイドル/割り当てられていないセルを破棄するため、このサービスは統計的多重化帯域幅の節約から恩恵を受けます。

In accordance with [2], cell concatenation MAY be used for transparent cell-relay transport in order to save the PSN bandwidth. If used, it MUST be agreed between the ingress and egress PEs. In particular, if the Pseudo Wire has been set up using the PWE3 control protocol [3], the ingress PE MUST NOT exceed the value of the "Maximum Number of concatenated ATM cells" Pseudowire Interface Parameter Sub-TLV (Interface Parameter ID = 0x02 [4]) received in the Label Mapping message for the Pseudo Wire, and MUST NOT use cell concatenation if this parameter has been omitted by the egress PE.

[2]に従って、PSN帯域幅を保存するために、細胞連結を透明な細胞関連輸送に使用することができます。使用する場合は、侵入と出口の間で合意する必要があります。特に、pWe3コントロールプロトコル[3]を使用して擬似ワイヤがセットアップされている場合、侵入PEは「連結ATMセルの最大数」pseudowireインターフェイスパラメーターサブTLV(インターフェイスパラメーターid = 0x02の値を超えてはなりません。[4])擬似ワイヤのラベルマッピングメッセージで受信し、このパラメーターが出口PEによって省略されている場合、セル連結を使用しないでください。

ATM Operations and Management (OAM) cells MUST be transported transparently, and the PEs do not act on them. If the PEs detect a PSN or pseudowire failure between them, they do not generate any OAM cells, but rather bring down the ATM interfaces to the CEs (e.g., generating LOS on the ATM port), just as if it were a transmission layer failure.

ATMの動作と管理(OAM)細胞は透過的に輸送する必要があり、PEはそれらに作用しません。PESがPSNまたはそれらの間の擬似障害を検出した場合、それらはOAMセルを生成せず、むしろ透過層の故障であるかのように、CES(たとえば、ATMポートでLOSを生成する)にATMインターフェイスを下げます(たとえば、ATMポートでLOS)。

Similarly, ATM Integrated Local Management Interface (ILMI) signaling from the CEs, if any, MUST be transported transparently, and the PEs do not act on it. However, the PEs must act on physical interface failure by either withdrawing the PW labels or by using pseudowire status signaling to indicate the interface failure. The procedures for both alternatives are described in [3].

同様に、CESからのATM統合ローカル管理インターフェイス(ILMI)シグナル伝達がある場合は、透過的に輸送する必要があり、PEはそれに作用しません。ただし、PESは、PWラベルを撤回するか、擬似動物ステータスシグナル伝達を使用してインターフェイス障害を示すことにより、物理的なインターフェイス障害に作用する必要があります。両方の代替手順は[3]で説明されています。

3. Security Considerations
3. セキュリティに関する考慮事項

This document does not introduce any new security considerations beyond those in [2] and [3]. This document defines an application that utilizes the encapsulation specified in [2], and does not specify the protocols used to carry the encapsulated packets across the PSN. Each such protocol may have its own set of security issues, but those issues are not affected by the application specified herein. Note that the security of the transported ATM service will only be as good as the security of the PSN. This level of security might be less rigorous than a native ATM service.

このドキュメントでは、[2]および[3]の文書を超えた新しいセキュリティ上の考慮事項は導入されていません。このドキュメントでは、[2]で指定されたカプセル化を利用するアプリケーションを定義し、PSN全体でカプセル化されたパケットを運ぶために使用されるプロトコルを指定しません。このようなプロトコルには、独自のセキュリティ問題がある場合がありますが、これらの問題は、本明細書で指定されたアプリケーションの影響を受けません。輸送されたATMサービスのセキュリティは、PSNのセキュリティと同じくらい優れていることに注意してください。このレベルのセキュリティは、ネイティブATMサービスよりも厳密ではない場合があります。

4. Congestion Control
4. 混雑制御

Since this document discusses an application of the "N-to-one" VCC cell transport mode for PWE3 ATM encapsulation described in [2], the congestion control considerations are identical to those discussed in section 15 of [2]. The PWE3 Working Group is also undertaking additional work on ATM-related congestion issues, and implementers should anticipate that an RFC will be published describing additional congestion control techniques that should be applied to ATM emulation over pseudowires.

このドキュメントでは、[2]で説明されているPWE3 ATMカプセル化の「N-to-one」VCCセル輸送モードの適用について説明しているため、渋滞制御の考慮事項は[2]のセクション15で説明したものと同一です。PWE3ワーキンググループは、ATM関連の混雑問題に関する追加の作業も行っており、実装者はRFCがPSEUDOWIRESよりもATMエミュレーションに適用されるべき追加の混雑制御手法を説明することを公開することを予想する必要があります。

5. Normative References
5. 引用文献

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

[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[2] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and G. Koleyni, "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006.

[2] Martini、L.、Jayakumar、J.、Bocci、M.、El-Aawar、N.、Brayley、J.、およびG. Koleyni、「MPLSネットワーク上の非同期転送モード(ATM)の輸送のためのカプセル化方法」、RFC4717、2006年12月。

[3] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.

[3] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「ラベル分布プロトコル(LDP)を使用した擬似ワイヤーのセットアップとメンテナンス」、RFC 4447、2006年4月。

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

[4] Martini、L。、「Pseudowire Edge to Edge Emulation(PWE3)のIANAの割り当て」、BCP 116、RFC 4446、2006年4月。

Acknowledgments

謝辞

The authors would like to thank the members of the PWE3 working group for their assistance on this document, and Sasha Vainshtein of Axerra in particular for his comments and suggestions.

著者は、この文書での支援についてPWE3ワーキンググループのメンバーと、特に彼のコメントと提案についてAxerraのSasha Vainshteinに感謝したいと思います。

Author's Addresses

著者のアドレス

Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham, MA

Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham、MA

   EMail: andrew.g.malis@verizon.com
        

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

Luca Martini Cisco Systems、Inc。9155 East Nichols Avenue、Suite 400 Englewood、Co、80112

   EMail: lmartini@cisco.com
        

Jeremy Brayley ECI Telecom Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205

ジェレミーブレイリーECIテレコムオメガコーポレートセンター1300オメガドライブピッツバーグ、ペンシルバニア州15205

   EMail: jeremy.brayley@ecitele.com
        

Tom Walsh Juniper Networks 1194 N Mathilda Ave Sunnyvale, CA 94089

Tom Walsh Juniper Networks 1194 N Mathilda Ave Sunnyvale、CA 94089

   EMail: twalsh@juniper.net
        

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