Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6005 LabN
Category: Standards Track D. Fedyk
ISSN: 2070-1721 Alcatel-Lucent
October 2010
Generalized MPLS (GMPLS) Support for Metro Ethernet Forum
and G.8011 User Network Interface (UNI)
Abstract
抽象
This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI.
この文書では、GMPLSベースのユーザネットワークインタフェース（UNI）を介して、イーサネットスイッチングの2つの特定のタイプを制御するための方法を記載しています。この文書では、メトロ・イーサネット・フォーラム（MEF）と国際電気通信連合（ITU）G.8011のコンテキストで定義されているイーサネットサービスに必要なスイッチングの種類をサポートしています。この文書は、「メトロ・イーサネット・フォーラムとG.8011イーサネットサービス交換のための一般化MPLS（GMPLS）サポート」へのUNIの仲間です。このドキュメントは、UNIをサポートするために使用される、基礎となるドメイン内または内部NNI（I-NNI）技術を定義または制限するものではありません。
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/rfc6005.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6005で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview ...................................................4
1.2. Conventions Used in This Document ..........................5
2. Common Signaling Support ........................................5
2.1. UNI Addressing .............................................5
2.2. Ethernet Endpoint (UNI) Identification .....................6
2.2.1. Address Resolution ..................................6
2.3. Connection Identification ..................................7
3. EPL Service .....................................................7
4. EVPL Service ....................................................7
4.1. Egress VLAN ID Control and VLAN ID Preservation ............7
5. IANA Considerations .............................................8
5.1. Error Value: Routing Problem/Unknown Endpoint ..............8
6. Security Considerations .........................................8
7. References ......................................................8
7.1. Normative References .......................................8
7.2. Informative References .....................................9
Acknowledgments ....................................................9
[MEF6] and [G.8011] provide parallel frameworks for defining network-oriented characteristics of Ethernet services in transport networks. The framework discusses general Ethernet connection characteristics, Ethernet User Network Interfaces (UNIs), and Ethernet Network-Network Interfaces (NNIs). Within this framework, [G.8011.1] defines the Ethernet Private Line (EPL) service and [G.8011.2] defines the Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both service types. [MEF10.1] defines service parameters and [MEF11] provides UNI requirements and framework.
【MEF6]および[G.8011]は、トランスポートネットワーク内のイーサネット・サービスのネットワーク指向の特性を定義するための平行なフレームワークを提供します。フレームワークは、一般的なイーサネット接続性、イーサネットユーザネットワークインタフェース（UNIの）について説明し、イーサネットネットワークネットワークインタフェース（NNIに）。この枠組みの中で、[G.8011.1]イーサネット専用回線（EPL）サービスを定義し、[G.8011.2]イーサネット仮想専用線（EVPL）サービスを定義します。 [MEF6]の両方のサービスの種類をカバーしています。 【MEF10.1]サービスパラメータを定義し、[MEF11] UNI要件およびフレームワークを提供します。
This document provides a method for GMPLS-based control of Label Switched Paths (LSPs) that support the transport services defined in the above documents at the UNI network reference points. This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. This document makes use of the GMPLS extensions defined in [RFC6004] and [RFC6002].
この文書は、ラベルのGMPLSベースの制御のための方法は、UNIネットワーク基準点で上記の文書で定義されたトランスポート・サービスをサポートするパス（LSPを）スイッチ提供します。このドキュメントは、UNIをサポートするために使用される、基礎となるドメイン内または内部NNI（I-NNI）技術を定義または制限するものではありません。この文書では、[RFC6004]と[RFC6002]で定義されたGMPLS拡張を使用しています。
The scope of this document covers Ethernet UNI applications, and it is intended to be consistent with the GMPLS overlay model presented in [RFC4208] and aligned with GMPLS Core Network signaling. The scope and reference model used in this document are represented in Figure 1, which is based on Figure 1 of [RFC4208].
この文書の範囲は、イーサネットUNIのアプリケーションをカバーし、[RFC4208]に提示し、GMPLSコアネットワークシグナリングと整列GMPLSオーバーレイモデルと一致するように意図されています。本書で使用される範囲と基準モデルは[RFC4208]の図1に基づいて、図1に示されています。
Figure 1 shows two core networks, each containing two core nodes. The core nodes are labeled 'CN'. Connected to each CN is an edge node. The edge nodes are labeled 'EN'. Each EN supports Ethernet Networks and use Ethernet services provided by the core nodes via a UNI. Two services are represented: one EPL and one EVPL type service. Signaling within the core network is out of scope of this document and may include any technology that supports overlay UNI services. The UNI function in the edge node can be referred to as the UNI client, or UNI-C, and in the CN as UNI network, or UNI-N.
図1は、それぞれが2つのコア・ノードを含む、2つのコアネットワークを示しています。コアノードは、「CN」標識されています。各CNに接続されたエッジノードです。エッジノードは「EN」標識されています。各ENは、イーサネット・ネットワークをサポートし、UNIを介してコア・ノードが提供するイーサネットサービスを使用します。 2つのサービスが表現されている：1つのEPLとEVPL 1型サービスを。コアネットワーク内のシグナル伝達は、この文書の範囲外であるとオーバーレイUNIサービスをサポートする任意の技術を含むことができます。エッジノードにおけるUNI機能はUNIクライアントと呼ばれる、またはUNI-C、およびUNIネットワークとしてCN、またはUNI-Nにすることができます。
Ethernet Ethernet
Network +----------+ +-----------+ Network
+---------+ | | | | +---------+
| +----+ | | +-----+ | | +-----+ | | +----+ |
------+ | | EPL | | | | | | | | EPL | | +------
------+ EN +-+-----+--+ CN +---------+ CN +--+-----+-+ EN +------
| | | | +--+--| +---+ | | +--+-----+-+ | |
| +----+ | | | +--+--+ | | | +--+--+ | | +----+ |
| | | | | | | | | | | |
+---------+ | | | | | | | | +---------+
| | | | | | | |
+---------+ | | | | | | | | +---------+
| | | | +--+--+ | | | +--+--+ | | |
| +----+ | | | | | | +-----+ | | | +----+ |
------+ +-+--+ | | CN +---------+ CN | | | | +------
------+ EN +-+-----+--+ | | | | +--+-----+-+ EN +------
| | | |EVPL | +-----+ | | +-----+ |EVPL | | | |
| +----+ | | | | | | +----+ |
| | +----------+ |-----------+ | |
+---------+ Core Network(s) +---------+
Ethernet UNI UNI Ethernet
Network <-----> <-----> Network
Scope of This Document
Legend: EN - Edge Node
CN - Core Node
Figure 1: Ethernet UNI Reference Model
図1：イーサネットUNI参照モデル
This document uses a common approach to supporting the switching implied by the Ethernet services defined in [MEF6], [G.8011.1], and [G.8011.2]. The approach builds on standard GMPLS mechanisms to deliver the required control capabilities. This document reuses the GMPLS mechanisms specified in [RFC6004], [RFC4208], and [RFC4974].
この文書では、[G.8011.1]、[MEF6]で定義されたイーサネットサービスによって暗示スイッチングをサポートする一般的なアプローチを使用し、[G.8011.2]。アプローチは、必要な制御機能を提供するために、標準GMPLSメカニズムに基づいています。この文書では、GMPLSの[RFC6004]で指定されたメカニズム、[RFC4208]及び[RFC4974]を再利用します。
Support for Point-to-Point (P2P) and Multipoint-to-Multipoint (MP2MP) service is required by [G.8011] and [MEF11]. P2P service delivery support is based on the GMPLS support for Ethernet services covered in [RFC6004]. As with [RFC6004], the definition of support for MP2MP service is left for future study and is not addressed in this document.
ポイントツーポイント（P2P）と多対多のサポートは（MP2MP）サービスは[G.8011]と[MEF11]によって必要とされます。 P2Pサービス提供のサポートは、[RFC6004]でカバーイーサネットサービスのためのGMPLSのサポートに基づいています。 [RFC6004]と同様に、MP2MPサービスのサポートの定義は今後の研究に残され、この文書で扱われていません。
[MEF11] defines multiple types of control for UNI Ethernet services. In MEF UNI Type 1, services are configured manually. In MEF UNI Type 2, services may be configured manually or via a link management interface. In MEF UNI Type 3, services may be established and managed via a signaling interface. As with [RFC6004], this document is aimed at supporting the MEF UNI Type 3 mode of operation (and not MEF UNI Types 1 and 2). As mentioned above, this document is limited to covering UNI-specific topics.
【MEF11] UNIイーサネットサービスのための制御の複数のタイプを定義します。 MEF UNIタイプ1では、サービスが手動で構成されています。 MEF UNIタイプ2では、サービスは、手動で、またはリンク管理インターフェースを介して構成することができます。 MEF UNIタイプ3では、サービスは、シグナリング・インターフェースを介して確立し、管理することができます。 [RFC6004]と同様に、この文書は、操作のMEF UNIタイプ3モード（およびいないMEF UNIタイプ1及び2）をサポートすることを目的とします。前述したように、このドキュメントは、UNI-特定のトピックをカバーするに限定されています。
Common procedures used to signal Ethernet connections are described in Section 2 of this document. Procedures related to signaling switching in support of EPL services are described in Section 3. Procedures related to signaling switching in support of EVPL services are described in Section 4.
イーサネット接続を知らせるために使用される一般的な手順は、このドキュメントのセクション2に記載されています。 EPLサービスのサポートに切り替えるシグナリングに関連する手順は、セクションに記載されているEVPLサービスのサポートに切り替えるシグナリングに関連する3手順はセクション4に記載されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section describes the common mechanisms for supporting a UNI reference point for LSPs that provide the Ethernet Services described in [RFC6004].
このセクションでは、[RFC6004]に記載のイーサネットサービスを提供するLSPのためのUNI基準点を支持するための共通のメカニズムを説明しています。
Except as specifically modified in this document, the procedures related to the processing of Resource ReSerVation Protocol (RSVP) objects is not modified by this document. The relevant procedures in existing documents, notably [RFC6002], [RFC6004], [RFC4208], and [RFC4974], MUST be followed in all cases not explicitly described in this document.
具体的には、この文書に変更を除いて、リソース予約プロトコル（RSVP）オブジェクトの処理に関する手順は、この文書によって変更されません。既存の文書に関連する手順、特に[RFC6002]、[RFC6004]、[RFC4208]、および[RFC4974]は、明示的にこの文書に記述されていないすべての場合に従わなければなりません。
LSPs providing Ethernet connections controlled via the mechanisms defined in this document MUST use the addressing and other procedures defined in [RFC4208]. Of note, this includes the use of the egress edge node's IP address in the endpoint address field in the SESSION object.
[RFC4208]で定義されたアドレス指定および他の手順を使用しなければなりません。この文書で定義されたメカニズムを介して制御イーサネット接続を提供するLSP。注目すべきは、これは、セッションオブジェクト内のエンドポイントアドレスフィールドに出口エッジノードのIPアドレスの使用を含みます。
One issue that presents itself with the addressing approach taken in [RFC4208] is that an ingress edge node may not receive the egress edge node's IP address as part of the management, or other, request that results in the initiation of a new Ethernet connection. This case is covered as described in Section 7.2 of [RFC4974] and modified below in Section 2.2.1.
[RFC4208]で取らアドレッシングアプローチで自身を提示する1つの問題は、入口エッジノードは、新しいイーサネット接続の開始をもたらすことを要求し、管理の一部、または他のように出口エッジノードのIPアドレスを受信しない可能性があることです。 [RFC4974]のセクション7.2に記載されセクション2.2.1において以下に修正され、この場合には、被覆されています。
UNI identification, except as noted below, MUST follow Ethernet endpoint (UNI) identification as defined in [RFC6004]. There is one additional case that is covered in this document where the scope of the Ethernet endpoint identifier is relevant beyond the typical case of just ingress and egress nodes.
[RFC6004]で定義されるようにUNIの識別は、以下に記載される場合を除き、イーサネットエンドポイント（UNI）の識別に従わなければなりません。イーサネットエンドポイント識別子の範囲がちょうど入口と出口ノードの典型的なケースを越えて関連する本文書で覆われている一つの追加の場合があります。
At the UNI reference point, it is possible for the ingress edge node to not have the egress edge node's IP address when initiating an LSP. This presents an issue as the egress edge node's IP address is carried in the SESSION object. This case is handled leveraging the approach described in Section 7.2 of [RFC4974] to address call ID assignment by the first core node.
UNI基準点で、LSPを開始するとき、入口エッジノードは、出口エッジノードのIPアドレスを持っていないことが可能です。出口エッジノードのIPアドレスはセッションオブジェクトに運ばれるように、これは問題を提示しています。この場合は、第一のコアノードによってコールIDの割り当てに対処するために、[RFC4974]のセクション7.2に記載の手法を活用処理されます。
When an edge node (the UNI-C) initiates an LSP and it has the egress Ethernet endpoint identifier, but does not have its IP address, the edge node MUST create a Notify message as described in [RFC4974]. The Notify message MUST include the CALL_ATTRIBUTES object with the Endpoint ID TLV defined [RFC6004]. The tunnel endpoint address field of the SESSION object in the Notify message MUST be set to zero (0). The message MUST be addressed and sent to an address associated with the first core node.
エッジノード（UNI-C）はLSPを開始し、それが出力イーサネット・エンドポイント識別子を有するが、そのIPアドレスを持っていない場合、[RFC4974]に記載されているように、エッジノードは、通知メッセージを作成しなければなりません。通知メッセージは、定義されたエンドポイントID TLV [RFC6004]とCALL_ATTRIBUTESオブジェクトを含まなければなりません。通知メッセージ内のセッションオブジェクトのトンネルエンドポイントアドレスフィールドがゼロ（0）に設定しなければなりません。メッセージは、アドレスと第一のコア・ノードに関連付けられたアドレスに送信されなければなりません。
When a core node, i.e., the node providing the network side of the UNI (the UNI-N), receives a Notify message with the tunnel endpoint address field of the SESSION object set to zero, it MUST locate the Endpoint ID TLV in the CALL_ATTRIBUTES object. If the object or TLV are not present, the node MUST discard the message. In this case, a Message ID Acknowledgment MUST NOT be sent for the Notify message.
コアノードは、即ち、UNI（UNI-N）のネットワーク側の提供ノードがゼロに設定されたセッション・オブジェクトのトンネルエンドポイントアドレスのフィールドに通知メッセージを受信すると、エンドポイントID TLVを見つけなければなりませんCALL_ATTRIBUTESオブジェクト。オブジェクトまたはTLVが存在しない場合、ノードは、メッセージを破棄しなければなりません。この場合、メッセージID確認応答は、通知メッセージを送ってはいけません。
When the Endpoint ID TLV is located, the node MUST map the Endpoint ID into an IP address associated with the egress edge node. If the node is unable to obtain an egress address, it MUST issue an error response Notify messages according to Section 6.2.2. of [RFC4974]. The Error code and value SHOULD be "Routing Problem/Unknown Endpoint" (Error code 24, Error value 35).
エンドポイントID TLVが配置されている場合、ノードは、出口エッジノードに関連付けられたIPアドレスにエンドポイントIDをマップする必要があります。ノードは出口アドレスを取得できない場合は、エラー応答が6.2.2によるNotifyメッセージを発行しなければなりません。 [RFC4974]の。エラーコード及び値は、「ルーティング問題/未知のエンドポイント」（エラーコード24、エラー値35）であるべきです。
When the node is able to obtain an egress address, the endpoint address field of the SESSION object MUST be set to the obtained address, and the Notify message should be sent according to the standard processing defined in [RFC4974]. The downstream nodes will then process the Notify according to standard processing rules.
ノードが出力アドレスを取得することが可能である場合、[RFC4974]で定義された標準処理によるセッションオブジェクトのエンドポイントアドレスフィールドは、取得したアドレスに設定しなければなりません、そして通知メッセージが送信されるべきです。下流ノードは、次いで、標準的な処理ルールに従って通知を処理します。
When the ingress receives the response Notify message, it SHOULD identify the call based on the Endpoint ID TLV and, when not set to zero on the corresponding setup Notify message, the short and long Call IDs. The endpoint address field of the SESSION object carried in the response Notify message will include the egress's IP address. This returned address MUST be used in all subsequent messages associated with the Ethernet connection.
入力応答通知メッセージを受信すると、メッセージ、ショート及びロングコールIDを通知し、対応する設定にゼロに設定されていないエンドポイントID TLVと、に基づいてコールを識別すべきです。応答で運ばSESSIONオブジェクトのエンドポイント・アドレス・フィールドは、出力のIPアドレスが含まれるメッセージを通知します。この返されたアドレスは、イーサネット接続に関連するすべての後続のメッセージに使用しなければなりません。
Note that the procedure described in this section MAY be used when the Call IDs are generated by the initiating UNI or generated by the first core node.
通話IDは開始UNIによって生成された、または第一のコアノードによって生成される場合、このセクションに記載された手順を使用してもよいことに留意されたいです。
With one exception, UNI signaling for Ethernet connections MUST follow the Connection Identification procedures defined in [RFC6004]. The exception is that the procedures defined in Section 7.2 of [RFC4974] MAY be used to provide support for allocation of Call IDs by the first core node rather than by the initiating edge node.
一つの例外を除いて、イーサネット接続のためのUNIシグナリングは[RFC6004]で定義された接続識別手順に従わなければなりません。例外は、[RFC4974]のセクション7.2で定義された手順は、第一のコアノードによってではなく、開始エッジノードによってコールIDの割り当てのためのサポートを提供するために使用され得ることです。
There are no additional UNI-specific requirements for signaling LSPs supporting Ethernet Private Line (EPL) services. The procedures defined in [RFC6004], as modified above, MUST be followed when signaling an LSPs supporting an EPL Service.
イーサネット専用線（EPL）サービスをサポートするLSPをシグナリングのための追加のUNI-固有の要件はありません。 EPLサービスを支援するLSPをシグナリングするとき、[RFC6004]で定義された手順は、上記修正され、従わなければなりません。
There is one additional UNI-specific requirement for signaling LSPs supporting an EVPL type service as described in Section 4.1. Except as modified above and by this section, the procedures defined in [RFC6004] MUST be followed when signaling an EVPL Service.
セクション4.1で説明したようにEVPL型サービスをサポートするLSPをシグナリングするための1つの追加のUNI-特定の要件があります。 EVPLシグナリングサービスをするとき、このセクションの上とで変更される以外は、[RFC6004]で定義された手順に従わなければなりません。
Per [MEF6], the mapping of the single VLAN ID used at the ingress UNI to a different VLAN ID at the egress UNI is allowed for EVPL services that do not support both bundling and VLAN ID preservation. Such a mapping MUST be requested and signaled based on the explicit label control mechanism defined in [RFC4208], and not the mechanisms defined in [RFC6004].
[MEF6]、出口UNIにおける異なるVLAN IDに入口UNIに使用される単一のVLAN IDのマッピングは、バンドルとVLAN ID保存の両方をサポートしていないEVPLサービスに許可されています。そのようなマッピングは、[RFC6004]で定義されたメカニズムを要求しなければならなくて、[RFC4208]で定義された明示的なラベル制御機構に基づいてシグナリング、およびありません。
As is the case in [RFC6004], when the explicit label control mechanism is not used VLAN IDs MUST be preserved, i.e., not modified, across the LSP.
[RFC6004]の場合のように、明示的なラベル制御機構は、VLAN IDが保存されなければならない使用されていない場合、すなわち、LSPを横切って、変更されません。
IANA has assigned new values for namespaces defined in this document and summarized in this section.
IANAは、この文書で定義された名前空間に新しい値を割り当てると、このセクションにまとめられています。
IANA has made the following assignment in the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "RSVP Parameters" registry located at http://www.iana.org:
IANAはhttp://www.iana.orgにある「RSVPパラメータ」レジストリの「エラーコードおよびグローバル定義のエラー値サブコード」セクションで、次の割り当てを行っています。
Error Code Meaning 24 Routing Problem [RFC3209]
24ルーティング問題[RFC3209]を意味エラーコード
Under "This Error Code has the following globally-defined Error Value sub-codes:"
下に「このエラーコードは、次のグローバル定義のエラー値サブコードを持っています」
35 = Unknown Endpoint [RFC6005]
35 =未知のエンドポイント[RFC6005]
This document makes use of the mechanisms defined in [RFC6004] and [RFC4974]. It does not in itself change the security models offered in each. (Note that the address resolution discussed in Section 2.2 above, parallels the replacement of information that occurs per Section 7.2 of [RFC4974].) See [RFC6004] and [RFC4974] for the security considerations that are relevant to and introduced by the base mechanisms used by this document.
このドキュメントは[RFC6004]及び[RFC4974]で定義されたメカニズムを利用します。それは自分自身で各で提供されるセキュリティモデルを変更しません。 [RFC6004]を参照してください（上記セクション2.2で説明したアドレス解決は、[RFC4974]のセクション7.2あたりの発生情報の交換と並行なお）と塩基機構によってに関連し、導入されたセキュリティ上の考慮事項のために[RFC4974]この文書で使用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208]ツバメ、G.、ドレイク、J.、石松、H.、およびY. Rekhter、「一般化マルチプロトコルラベルスイッチング（GMPLS）ユーザネットワークインタフェース（UNI）：リソース予約プロトコル - トラフィックエンジニアリング（RSVP-TE）オーバレイモデルのサポート」、RFC 4208、2005年10月。
[RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007.
[RFC4974] Papadimitriou、D.とA.ファレル、 "一般化MPLS（GMPLS）RSVP-TEコールのサポートでシグナリング拡張機能"、RFC 4974、2007年8月。
[RFC6002] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", RFC 6002, October 2010.
[RFC6002]バーガー、L.とD. Fedyk、 "一般化MPLS（GMPLS）データチャネルができるスイッチング（DCSC）とチャネルセットラベルの拡張機能"、RFC 6002、2010年10月。
[RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching", RFC 6004, October 2010.
[RFC6004]バーガー、L.とD. Fedyk、 "一般化MPLS（GMPLS）、メトロ・イーサネット・フォーラムとG.8011イーサネットサービス交換のサポート"、RFC 6004、2010年10月。
[G.8011] ITU-T G.8011/Y.1307, "Ethernet over Transport Ethernet services framework", August 2004.
"トランスポート・イーサネット・サービスのフレームワークオーバーイーサネット" [G.8011] ITU-T G.8011 / Y.1307、2004年8月。
[G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private line service", August 2004.
[G.8011.1] ITU-T G.G.8011.1 / Y.1307.1、 "イーサネット専用線サービス"、2004年8月。
[G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual private line service", September 2005.
[G.8011.2] ITU-T G.8011.2 / Y.1307.2、 "イーサネット仮想専用線サービス"、2005年9月。
[MEF6] The Metro Ethernet Forum, "Ethernet Services Definitions - Phase I", MEF 6, June 2004.
[MEF6]メトロ・イーサネット・フォーラム、 "イーサネットサービスの定義 - フェーズI"、MEF 6、2004年6月。
[MEF10.1] The Metro Ethernet Forum, "Ethernet Services Attributes Phase 2", MEF 10.1, November 2006.
[MEF10.1]メトロ・イーサネット・フォーラムは、MEF 10.1、2006年11月 "イーサネットサービスは、フェーズ2属性"。
[MEF11] The Metro Ethernet Forum , "User Network Interface (UNI) Requirements and Framework", MEF 11, November 2004.
[MEF11]メトロ・イーサネット・フォーラム、 "ユーザネットワークインターフェイス（UNI）の要件とフレームワーク"、MEF 11、2004年11月。
Acknowledgments
謝辞
Dimitri Papadimitriou provided substantial textual contributions to this document and coauthored earlier versions of this document.
ディミトリPapadimitriouは、この文書にかなりのテキスト貢献を提供し、このドキュメントの以前のバージョンを共著。
The authors would like to thank Evelyne Roch and Stephen Shew for their valuable comments.
作者は彼らの貴重なコメントをエヴリーヌRochのとスティーブン供えに感謝したいと思います。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、L.L.C.電話：+ 1-301-468-9228 Eメール：lberger@labn.net
Don Fedyk Alcatel-Lucent Groton, MA 01450 Phone: +1-978-467-5645 EMail: donald.fedyk@alcatel-lucent.com
ドン・ルブランアルカテル・ルーセント、グロトン、MA 01450電話：+ 1-978-467-5645 Eメール：donald.fedyk@alcatel-lucent.com