[要約] RFC 6005は、Metro Ethernet ForumとG.8011 User Network Interface（UNI）のためのGeneralized MPLS（GMPLS）サポートに関する要約と目的を提供します。
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)
メトロイーサネットフォーラムおよびG.8011ユーザーネットワークインターフェイス（UNI）の一般化されたMPL（GMPLS）サポート
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つの特定のタイプのイーサネットスイッチングを制御する方法について説明します。このドキュメントは、Metro Ethernet Forum（MEF）およびInternational Telecommunication Union（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]は、輸送ネットワークにおけるイーサネットサービスのネットワーク指向の特性を定義するための並列フレームワークを提供します。フレームワークでは、一般的なイーサネット接続特性、イーサネットユーザーネットワークインターフェイス（UNIS）、およびイーサネットネットワークネットワークインターフェイス（NNIS）について説明します。このフレームワーク内で、[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].
このドキュメントは、UNIネットワーク参照ポイントの上記のドキュメントで定義されている輸送サービスをサポートするラベルスイッチ付きパス（LSP）のGMPLSベースの制御の方法を提供します。このドキュメントは、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を介してコアノードが提供するイーサネットサービスを使用します。1つのEPLと1つのEVPLタイプサービスの2つのサービスが表されています。コアネットワーク内のシグナリングは、このドキュメントの範囲外であり、オーバーレイUNIサービスをサポートするテクノロジーが含まれる場合があります。EdgeノードのUNI関数は、UNIクライアント、またはUNI-Cと呼ばれ、CNではUNIネットワーク、または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
凡例：en-エッジノードCN-コアノード
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].
この文書は、[MEF6]、[G.8011.1]、および[G.8011.2]で定義されたイーサネットサービスによって暗示されるスイッチングをサポートするための一般的なアプローチを使用します。このアプローチは、標準のGMPLSメカニズムに基づいて、必要な制御機能を提供します。この文書は、[RFC6004]、[RFC4208]、および[RFC4974]で指定されたGMPLSメカニズムを再利用します。
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.
[G.8011]および[MEF11]では、ポイントツーポイント（P2P）およびMultipoint-to-MultiPoint（MP2MP）サービスのサポートが必要です。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サービスをサポートするシグナリングスイッチングに関連する手順は、セクション3で説明されています。EVPLサービスをサポートするシグナリングスイッチングに関連する手順については、セクション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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
このドキュメントで定義されているメカニズムを介して制御されるイーサネット接続を提供するLSPは、[RFC4208]で定義されているアドレス指定およびその他の手順を使用する必要があります。注目すべきは、これには、セッションオブジェクトのエンドポイントアドレスフィールドにEgress Edgeノードの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つは、イングレスエッジノードが管理の一部としてEgress Edgeノードの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.
以下に示すように、UNIの識別は、[RFC6004]で定義されているイーサネットエンドポイント（UNI）識別に従う必要があります。このドキュメントでは、イーサネットエンドポイント識別子の範囲が、ノードと出口ノードの典型的なケースを超えて関連する追加のケースが1つあります。
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を開始するときに、Ingress EdgeノードがEgress EdgeノードのIPアドレスを持たない可能性があります。これは、出口エッジノードのIPアドレスがセッションオブジェクトに掲載されるため、問題を提示します。このケースは、[RFC4974]のセクション7.2で説明されているアプローチを活用して、最初のコアノードによるコールID割り当てに対処する処理されます。
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.
Edgeノード（UNI-C）がLSPを開始し、Egress Ethernet Endpoint Identifierを搭載しているが、IPアドレスがない場合、エッジノードは[RFC4974]で説明されているように通知メッセージを作成する必要があります。Notifyメッセージには、Endpoint ID TLVが定義された[RFC6004]を搭載したcall_attributesオブジェクトを含める必要があります。Notifyメッセージのセッションオブジェクトのトンネルエンドポイントアドレスフィールドは、ゼロ（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が存在しない場合、ノードはメッセージを破棄する必要があります。この場合、Notifyメッセージにメッセージ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が配置されている場合、ノードはエンドポイントIDを出力エッジノードに関連付けられたIPアドレスにマッピングする必要があります。ノードが出口アドレスを取得できない場合、セクション6.2.2に従ってメッセージがメッセージを通知するエラー応答を発行する必要があります。[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 TLVに基づいて呼び出しを識別し、対応するセットアップ通知メッセージでゼロに設定されていない場合、短いコールIDと長い呼び出しIDが必要です。応答に掲載されたセッションオブジェクトのエンドポイントアドレスフィールドNotifyメッセージには、出口の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.
1つの例外を除き、イーサネット接続の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固有の要件はありません。上記で修正された[RFC6004]で定義されている手順は、EPLサービスをサポートするLSPをシグナル伝えるときに従う必要があります。
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を信号するための追加のUNI固有の要件が1つあります。上記とこのセクションで修正された場合を除き、[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]によると、Egress UniでIngress Uniで使用される単一のVLAN IDのマッピングは、バンドリングとVLAN IDの両方の保存をサポートしないEVPLサービスに許可されています。このようなマッピングは、[RFC4208]で定義された明示的なラベル制御メカニズムに基づいて要求および信号を送信する必要があり、[RFC6004]で定義されたメカニズムではありません。
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]で定義されているメカニズムを使用しています。それ自体がそれぞれで提供されるセキュリティモデルを変更するわけではありません。（上記のセクション2.2で説明されているアドレス解決は、[RFC4974]のセクション7.2に従って発生する情報の置換と平行していることに注意してください。）ベースメカニズムによって関連し、導入されたセキュリティに関する考慮事項については、[RFC6004]および[RFC4974]を参照してください。このドキュメントで使用されます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP Tunnelsの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] Swallow、G.、Drake、J.、Ishimatsu、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. Farrel、「一般化された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] Berger、L。およびD. Fedyk、「Generalized 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] Berger、L。およびD. Fedyk、「メトロイーサネットフォーラムおよびG.8011イーサネットサービススイッチングの一般化MPLS（GMPLS）サポート」、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、「Ethernet Over Transport Ethernet Services Framework」、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]メトロイーサネットフォーラム、「イーサネットサービスはフェーズ2」、MEF 10.1、2006年11月。
[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.
Dimitri Papadimitriouは、このドキュメントに実質的なテキスト貢献を提供し、このドキュメントの以前のバージョンを共著しました。
The authors would like to thank Evelyne Roch and Stephen Shew for their valuable comments.
著者は、Evelyne RochとStephen Shewの貴重なコメントに感謝したいと思います。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger Labn Consulting、L.L.C。電話：1-301-468-9228メール：lberger@labn.net
Don Fedyk Alcatel-Lucent Groton, MA 01450 Phone: +1-978-467-5645 EMail: donald.fedyk@alcatel-lucent.com
Don Fedyk Alcatel-Lucent Groton、MA 01450電話：1-978-467-5645メール：donald.fedyk@alcatel-lucent.com