[要約] RFC 6004は、Metro Ethernet ForumとG.8011 Ethernet Service SwitchingのためのGeneralized MPLS（GMPLS）サポートに関する要約です。このRFCの目的は、GMPLSを使用してEthernetサービスのスイッチングをサポートするためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6004 LabN
Category: Standards Track D. Fedyk
ISSN: 2070-1721 Alcatel-Lucent
October 2010
Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching
メトロイーサネットフォーラムおよびG.8011イーサネットサービススイッチングの一般化されたMPL（GMPLS）サポート
Abstract
概要
This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF- and ITU-defined parameters is also covered.
このドキュメントでは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）を介して2つの特定のタイプのイーサネットスイッチングを制御する方法について説明します。このドキュメントは、Metro Ethernet Forum（MEF）およびInternational Telecommunication Union（ITU）G.8011のコンテキストで定義されているイーサネットサービスに対応するスイッチングの種類をサポートしています。具体的には、イーサネットのプライベートラインとイーサネットの仮想プライベートラインサービスをサポートする切り替えがカバーされています。MEFおよびITU定義のパラメーターのサポートもカバーされています。
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/rfc6004.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6004で取得できます。
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 ...................................................3
1.2. Conventions Used in This Document ..........................4
2. Common Signaling Support ........................................5
2.1. Ethernet Endpoint Identification ...........................5
2.1.1. Endpoint ID TLV .....................................5
2.1.1.1. Procedures .................................6
2.2. Connection Identification ..................................6
2.2.1. Procedures ..........................................6
2.3. Traffic Parameters .........................................7
2.3.1. L2 Control Protocol TLV .............................7
2.4. Bundling and VLAN Identification ...........................9
3. EPL Service .....................................................9
3.1. EPL Service Parameters .....................................9
4. EVPL Service ...................................................10
4.1. EVPL Generalized Label Format .............................10
4.2. Egress VLAN ID Control and VLAN ID Preservation ...........11
4.3. Single Call - Single LSP ..................................11
4.4. Single Call - Multiple LSPs ...............................11
5. IANA Considerations ............................................12
5.1. Endpoint ID Attributes TLV ................................12
5.2. Line LSP Encoding .........................................12
5.3. Ethernet Virtual Private Line (EVPL) Switching Type .......12
6. Security Considerations ........................................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Acknowledgments ...................................................14
[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の要件とフレームワークを提供します。
[MEF6] and [G.8011] are focused on service interfaces and not the underlying technology used to support the service. For example, [G.8011] refers to the defined services being transported over one of several possible "server layers". This document focuses on the types of switching that may directly support these services and provides a method for GMPLS-based control of such switching technologies. This document defines the GMPLS extensions needed to support such switching, but does not define the UNI or External NNI (E-NNI) reference points. See [RFC6005] for a description of the UNI reference point. This document makes use of the traffic parameters defined in [RFC6003] and the generic extensions defined in [RFC6002].
[MEF6]および[G.8011]は、サービスをサポートするために使用される基礎となる技術ではなく、サービスインターフェイスに焦点を当てています。たとえば、[g.8011]は、いくつかの可能な「サーバーレイヤー」の1つで輸送されている定義されたサービスを指します。このドキュメントは、これらのサービスを直接サポートする可能性のあるスイッチングの種類に焦点を当て、そのようなスイッチング技術のGMPLSベースの制御の方法を提供します。このドキュメントでは、このようなスイッチングをサポートするために必要なGMPLS拡張機能を定義しますが、UNIまたは外部NNI（E-NNI）参照ポイントを定義しません。UNI参照ポイントの説明については、[RFC6005]を参照してください。このドキュメントでは、[RFC6003]で定義されているトラフィックパラメーターと[RFC6002]で定義されている汎用拡張機能を使用しています。
This document uses a common approach to supporting the switching corresponding to 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 [RFC3473] and [RFC4974]. The document uses the extensions defined in [RFC6002].
この文書は、[MEF6]、[G.8011.1]、および[G.8011.2]で定義されたイーサネットサービスに対応するスイッチングをサポートするための一般的なアプローチを使用します。このアプローチは、標準のGMPLSメカニズムに基づいて、必要な制御機能を提供します。この文書は、[RFC3473]および[RFC4974]で指定されたGMPLSメカニズムを再利用します。このドキュメントでは、[RFC6002]で定義された拡張機能を使用します。
Two types of connectivity between Ethernet endpoints are defined in [MEF6] and [G.8011]: point-to-point (P2P) and multipoint-to-multipoint (MP2MP). [MEF6] uses the term Ethernet Line (E-line) to refer to point-to-point virtual connections, and Ethernet LAN (E-LAN) to refer to multipoint-to-multipoint virtual connections. [G.8011] also identifies point-to-multipoint (P2MP) as an area for "further study". Within the context of GMPLS, support is defined for point-to-point unidirectional and bidirectional Traffic Engineering Label Switched Paths (TE LSPs), see [RFC3473], and unidirectional point-to-multipoint TE LSPs, see [RFC4875].
イーサネットエンドポイント間の2種類の接続性は、[MEF6]と[G.8011]で定義されています：ポイントツーポイント（P2P）とマルチポイントツーマルチポイント（MP2MP）。[MEF6]は、イーサネットライン（E-Line）という用語を使用して、ポイントツーポイント仮想接続を参照し、イーサネットLAN（E-LAN）を参照して、マルチポイントツーマルチポイント仮想接続を参照します。[G.8011]は、ポイントツーマルチポイント（P2MP）を「さらなる研究」の領域として識別します。GMPLSのコンテキスト内で、サポートは、ポイントツーポイントの単方向および双方向トラフィックエンジニアリングラベルスイッチドパス（TE LSP）、[RFC3473]、および一方向からマルチポイントTE LSPを参照して定義されます。[RFC4875]を参照してください。
Support for P2P and MP2MP services is defined by [G.8011] and required by [MEF11]. Note that while [MEF11] and [G.8011] discuss MP2MP, [G.8011.1] and [G.8011.2] only define support for P2P. There is a clear correspondence between E-Line/P2P service and GMPLS P2P TE LSPs, and support for such LSPs is included in the scope of this document. There is no such clear correspondence between E-LAN/MP2MP service and GMPLS TE LSPs. Although, it is possible to emulate this service using multiple P2P or P2MP TE LSPs, the definition of support for MP2MP service is left for future study and is not addressed in this document.
P2PおよびMP2MPサービスのサポートは[G.8011]によって定義され、[MEF11]によって必要です。[MEF11]および[G.8011]はMP2MPについて議論している一方で、[G.8011.1]と[G.8011.2]はP2Pのサポートのみを定義していることに注意してください。E-Line/P2PサービスとGMPLS P2P TE LSPの間には明確な対応があり、このようなLSPのサポートはこのドキュメントの範囲に含まれています。E-LAN/MP2MPサービスとGMPLS TE LSPの間には、そのような明確な対応はありません。複数のP2PまたはP2MP TE LSPを使用してこのサービスをエミュレートすることは可能ですが、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. From the MEF perspective, this document, along with [RFC6005], is aimed at the network control needed to support the MEF UNI Type 3 mode of operation.
[MEF11]は、UNIイーサネットサービスの複数のタイプの制御を定義します。MEF UNIタイプ1では、サービスは手動で構成されています。MEF UNIタイプ2では、サービスは手動で、またはリンク管理インターフェイスを介して構成できます。MEF UNIタイプ3では、信号インターフェイスを介してサービスを確立および管理できます。MEFの観点から見ると、このドキュメントは[RFC6005]とともに、MEF UNIタイプ3の動作モードをサポートするために必要なネットワーク制御を対象としています。
[G.8011.1], [G.8011.2], and [MEF11], together with [MEF10.1], define a set of service attributes that are associated with each Ethernet connection. Some of these attributes are based on the provisioning of the local physical connection and are not modifiable or selectable per connection. Other attributes are specific to a particular connection or must be consistent across the connection. The approach taken in this document to communicate these attributes is to exclude the static class of attributes from signaling. This class of attributes will not be explicitly discussed in this document. The other class of attributes is communicated via signaling and will be reviewed in the sections below. The major attributes that will be supported in signaling include:
[G.8011.1]、[G.8011.2]、および[MEF11]は、[MEF10.1]とともに、各イーサネット接続に関連付けられた一連のサービス属性を定義します。これらの属性の一部は、ローカルの物理的接続のプロビジョニングに基づいており、接続ごとに変更可能または選択可能ではありません。他の属性は特定の接続に固有であるか、接続全体で一貫している必要があります。これらの属性を通知するためにこのドキュメントで採用されたアプローチは、シグナリングから静的クラスの属性を除外することです。このクラスの属性については、このドキュメントでは明示的に説明しません。他のクラスの属性はシグナリングを介して伝達され、以下のセクションでレビューされます。シグナリングでサポートされる主要な属性は次のとおりです。
- Endpoint identifiers - Connection identifiers - Traffic parameters (see [RFC6003]) - Bundling / VLAN IDs map (EVPL only) - VLAN ID Preservation (EVPL only)
- エンドポイント識別子 - 接続識別子 - トラフィックパラメーター（[RFC6003]を参照） - バンドリング / VLAN IDSマップ（EVPLのみ） - VLAN ID保存（EVPLのみ）
Common procedures used to support Ethernet LSPs are described in Section 2 of this document. Procedures related to the signaling of switching in support of EPL services are described in Section 3. Procedures related to the signaling of switching in support of EVPL services are described in Section 4.
イーサネットLSPをサポートするために使用される一般的な手順は、このドキュメントのセクション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 GMPLS signaled control of LSPs that provide Ethernet connections as defined in [MEF11], [G.8011.1], and [G.8011.2].
このセクションでは、[MEF11]、[G.8011.1]、および[G.8011.2]で定義されているイーサネット接続を提供するLSPのシグナル伝達をサポートするための一般的なメカニズムについて説明します。
Except as specifically modified in this document, the procedures related to the processing of RSVP objects are not modified by this document. The relevant procedures in existing documents, such as [RFC3473], MUST be followed in all cases not explicitly described in this document.
このドキュメントで具体的に変更されている場合を除き、RSVPオブジェクトの処理に関連する手順は、このドキュメントによって変更されません。[RFC3473]などの既存のドキュメントの関連手順は、このドキュメントで明示的に説明されていないすべての場合に従う必要があります。
Ethernet endpoint identifiers, as they are defined in [G.8011] and [MEF10.1], differ significantly from the identifiers used by GMPLS. Specifically, the Ethernet endpoint identifiers are character based as opposed to the GMPLS norm of being IP address based.
イーサネットエンドポイント識別子は、[G.8011]および[MEF10.1]で定義されているため、GMPLSが使用する識別子とは大きく異なります。具体的には、イーサネットエンドポイント識別子は、IPアドレスベースであるというGMPLSノルムとは対照的に、文字ベースです。
The approach taken by this document to address this disparity leverages the solution used for connection identification, see Section 2.2 and [RFC4974], and a new CALL_ATTRIBUTES TLV defined in this document. The solution makes use of the [RFC4974] short Call ID, and supports the Ethernet endpoint identifier similar to how [RFC4974] supports the long Call ID. That is, the SENDER_TEMPLATE and SESSION objects carry IP addresses and a short Call ID, and long identifiers are carried in the CALL_ATTRIBUTES object. As with the long Call ID, the Ethernet endpoint identifier is typically only relevant at the ingress and egress nodes.
このドキュメントがこの格差に対処するために採用されたアプローチは、接続識別に使用されるソリューションを活用しています。セクション2.2および[RFC4974]、およびこのドキュメントで定義されている新しいCALL_ATTRIBUTES TLVを参照してください。このソリューションは、[RFC4974]ショートコールIDを使用し、[RFC4974]が長いコールIDをサポートする方法と同様のイーサネットエンドポイント識別子をサポートします。つまり、sender_templateおよびセッションオブジェクトはIPアドレスと短い呼び出しIDを持ち、call_attributesオブジェクトに長い識別子が運ばれます。長いコールIDと同様に、イーサネットエンドポイント識別子は通常、イングレスノードと出力ノードにのみ関連します。
As defined below, the Ethernet endpoint identifier is carried in the CALL_ATTRIBUTES object in a new TLV. The new TLV is referred to as the Endpoint ID TLV. The processing of the Endpoint ID TLV parallels the processing of the long Call ID in [RFC4974]. This processing requires the inclusion of the CALL_ATTRIBUTES object in a Notify message.
以下に定義するように、イーサネットエンドポイント識別子は、新しいTLVのcall_attributesオブジェクトに運ばれます。新しいTLVは、エンドポイントID TLVと呼ばれます。エンドポイントID TLVの処理は、[RFC4974]の長いコールIDの処理と類似しています。この処理には、通話メッセージにcall_attributesオブジェクトを含める必要があります。
The Endpoint ID TLV follows the Attributes TLV format defined in
[RFC6001]. The Endpoint ID TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (30) | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint ID |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type and Length fields are defined in [RFC6001]. Note that as defined in [RFC6001], the Length field is set to length of the whole TLV including the Type, Length, and Endpoint ID fields.
タイプと長さのフィールドは[RFC6001]で定義されています。[RFC6001]で定義されているように、長さフィールドは、タイプ、長さ、およびエンドポイントIDフィールドを含むTLV全体の長さに設定されていることに注意してください。
Endpoint ID
エンドポイントID
The Endpoint ID field is a variable-size field that carries an endpoint identifier, see [MEF10.1] and [G.8011]. This field MUST be null padded as defined in [RFC6001].
エンドポイントIDフィールドは、エンドポイント識別子を搭載する可変サイズフィールドです。[MEF10.1]および[G.8011]を参照してください。このフィールドは、[RFC6001]で定義されているようにヌルパッドで締められなければなりません。
The use of the Endpoint ID TLV is required during Call management. When a Call is established or torn down per [RFC4974], a CALL_ATTRIBUTES object containing an Endpoint ID TLV MUST be included in the Notify message along with the long Call ID.
コール管理中にエンドポイントID TLVの使用が必要です。[RFC4974]ごとに通話が確立または取り壊される場合、エンドポイントID TLVを含むCALL_ATTRIBUTESオブジェクトを、長いコールIDとともにNotifyメッセージに含める必要があります。
Short Call ID processing, including those procedures related to Call and connection processing, is not modified by this document and MUST proceed according to [RFC4974].
コールおよび接続処理に関連する手順を含む短いコールID処理は、このドキュメントによって変更されず、[RFC4974]に従って進める必要があります。
Signaling for Ethernet connections follows the procedures defined in [RFC4974]. In particular, the Call-related mechanisms are used to support endpoint identification. In the context of Ethernet connections, a Call is only established when one or more LSPs (connections in [RFC4974] terms) are needed. An LSP will always be established within the context of a Call and, typically, only one LSP will be used per Call. See Section 4.4 for the case where more than one LSP may exist within a Call.
イーサネット接続のシグナル伝達は、[RFC4974]で定義されている手順に従います。特に、コール関連のメカニズムは、エンドポイントの識別をサポートするために使用されます。イーサネット接続のコンテキストでは、1つ以上のLSP（[rfc4974]項の接続）が必要な場合にのみ、呼び出しが確立されます。LSPは常に呼び出しのコンテキスト内で確立され、通常、通話ごとに1つのLSPのみが使用されます。コール内に複数のLSPが存在する場合については、セクション4.4を参照してください。
Any node that supports Ethernet connections MUST be able to accept and process Call setups per [RFC4974]. Ethernet connections established according to this document MUST treat the Ethernet (virtual) connection identifier as the long "Call identifier (ID)", described in [RFC4974]. The short Call ID MUST be used as described in [RFC4974]. Use of the LINK_CAPABILITY object is OPTIONAL. Both network-initiated and user-initiated Calls MUST be supported.
イーサネット接続をサポートするノードは、[RFC4974]ごとにコールセットアップを受け入れて処理できる必要があります。このドキュメントに従って確立されたイーサネット接続は、[RFC4974]で説明されている長い「コール識別子（ID）」としてイーサネット（仮想）接続識別子を扱う必要があります。[RFC4974]に記載されているように、短い呼び出しIDを使用する必要があります。link_capabilityオブジェクトの使用はオプションです。ネットワーク開始コールとユーザー開始コールの両方をサポートする必要があります。
When establishing an Ethernet connection, the initiator MUST first establish a Call per the procedures defined in [RFC4974]. LSP management, including removal and addition, then follows [RFC4974]. As stated in [RFC4974], once a Call is established, the initiator SHOULD establish at least one Ethernet LSP. Also, when the last LSP associated with a Call is removed, the Call SHOULD be torn down per the procedures in [RFC4974].
イーサネット接続を確立するとき、イニシエーターは最初に[RFC4974]で定義された手順に従って呼び出しを確立する必要があります。除去と追加を含むLSP管理は、[RFC4974]に従います。[RFC4974]に記載されているように、呼び出しが確立されると、イニシエーターは少なくとも1つのイーサネットLSPを確立する必要があります。また、呼び出しに関連付けられた最後のLSPが削除されると、[RFC4974]の手順に従ってコールを取り壊す必要があります。
Several types of service attributes are carried in the traffic parameters defined in [RFC6003]. These parameters are carried in the FLOWSPEC and TSPEC objects as discussed in [RFC6003]. The service attributes that are carried are:
[RFC6003]で定義されているトラフィックパラメーターには、いくつかのタイプのサービス属性が掲載されています。これらのパラメーターは、[RFC6003]で説明されているように、FlowsPecおよびTSPECオブジェクトに搭載されています。運ばれるサービス属性は次のとおりです。
- Bandwidth Profile - VLAN Class of Service (CoS) Preservation - Layer 2 Control Protocol (L2CP) Processing (see Section 2.3.1)
- 帯域幅プロファイル-VLANサービスのクラス（COS）保存-Layer2コントロールプロトコル（L2CP）処理（セクション2.3.1を参照）
Ethernet connections established according to this document MUST use the traffic parameters defined in [RFC6003] in the FLOWSPEC and TSPEC objects. Additionally, the Switching Granularity field of the Ethernet SENDER_TSPEC object MUST be set to zero (0).
このドキュメントに従って確立されたイーサネット接続は、FlowsPecおよびTSPECオブジェクトの[RFC6003]で定義されているトラフィックパラメーターを使用する必要があります。さらに、イーサネットsender_tspecオブジェクトのスイッチング粒度フィールドは、ゼロ（0）に設定する必要があります。
[MEF10.1], [G.8011.1], and [G.8011.2] define service attributes that impact the layer two (L2) control protocol processing at the ingress and egress. [RFC6003] does not define support for these service attributes, but does allow the attributes to be carried in a TLV. This section defines the L2CP TLV to carry the L2CP-processing-related service attributes.
[MEF10.1]、[G.8011.1]、および[G.8011.2]は、イングレスと出口でのレイヤー2（L2）制御プロトコル処理に影響を与えるサービス属性を定義します。[RFC6003]は、これらのサービス属性のサポートを定義するものではありませんが、属性をTLVに携帯することを可能にします。このセクションでは、L2CP TLVを定義して、L2CP処理関連のサービス属性を運びます。
The format of the L2 Control Protocol (L2CP) TLV is as follows:
L2コントロールプロトコル（L2CP）TLVの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=3 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IL2CP | EL2CP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
See [RFC6003] for a description of the Type and Length fields.
Per [RFC6003], the Type field MUST be set to three (3), and the
Length field MUST be set to eight (8) for the L2CP TLV.
Ingress Layer 2 Control Processing (IL2CP): 4 bits
イングレス層2コントロール処理（IL2CP）：4ビット
This field controls processing of Layer 2 Control Protocols on a receiving interface. Valid usage is service specific, see [MEF10.1], [G.8011.1], and [G.8011.2].
このフィールドは、受信インターフェイス上のレイヤー2制御プロトコルの処理を制御します。有効な使用法はサービス固有です。[MEF10.1]、[G.8011.1]、および[G.8011.2]を参照してください。
Permitted values are:
許可された値は次のとおりです。
Value Description Reference
----- ----------- ---------
0 Reserved
1 Discard/Block [MEF10.1], [G.8011.1], and [G.8011.2]
2 Peer/Process [MEF10.1], [G.8011.1], and [G.8011.2]
3 Pass to EVC/Pass [MEF10.1], [G.8011.1], and [G.8011.2]
4 Peer and Pass to EVC [MEF10.1]
Egress Layer 2 Control Processing (EL2CP): 4 bits
出力層2制御処理（EL2CP）：4ビット
This field controls processing of Layer 2 Control Protocols on a transmitting interface. When MEF services are used a value of 1 MUST be used, other valid usage is service specific, see [G.8011.1] and [G.8011.2].
このフィールドは、送信インターフェイス上のレイヤー2制御プロトコルの処理を制御します。MEFサービスを使用する場合、1の値を使用する必要があります。その他の有効な使用法はサービス固有です。[G.8011.1]および[G.8011.2]を参照してください。
Permitted values are:
許可された値は次のとおりです。
Value Description Reference
----- ----------- ---------
0 Reserved
1 Based on IL2CP Value [MEF10.1]
2 Generate [G.8011.1] and [G.8011.2]
3 None [G.8011.1] and [G.8011.2]
4 Reserved
Reserved: 24 bits
予約済み：24ビット
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. This field SHOULD be passed unmodified by transit nodes.
このフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。このフィールドは、トランジットノードによって変更されずに渡される必要があります。
Ethernet connections established according to this document MUST include the L2CP TLV in the [RFC6003] traffic parameters carried in the FLOWSPEC and TSPEC objects.
このドキュメントに従って確立されたイーサネット接続には、FlowsPecおよびTSPECオブジェクトに運ばれる[RFC6003]トラフィックパラメーターにL2CP TLVを含める必要があります。
The control of bundling and listing of VLAN identifiers is only supported for EVPL services. EVPL service specific details are provided in Section 4.
バンドルの制御とVLAN識別子のリストは、EVPLサービスに対してのみサポートされています。EVPLサービス固有の詳細は、セクション4に記載されています。
Both [MEF6] and [G.8011.1] define an Ethernet Private Line (EPL) service. In the words of [G.8011.1], EPL services carry "Ethernet characteristic information over dedicated bandwidth, point-to-point connections, provided by SDH, ATM, MPLS, PDH, ETY or OTH server layer networks". [G.8011.1] defines two types of Ethernet Private Line (EPL) services. Both types present a service where all data presented on a port is transported to the corresponding connected port. The types differ in that EPL type 1 service operates at the MAC frame layer, while EPL type 2 service operates at the line (e.g., 8B/10B) encoding layer. [MEF6] only defines one type of EPL service, and it matches [G.8011.1] EPL type 1 service. Signaling for LSPs that support both types of EPL services are detailed below.
[MEF6]と[G.8011.1]の両方が、イーサネットプライベートライン（EPL）サービスを定義します。[G.8011.1]の言葉では、EPLサービスは、SDH、ATM、MPLS、PDH、ETY、またはOTHサーバーレイヤーネットワークによって提供される専用の帯域幅、ポイントツーポイント接続にわたって「イーサネット特性情報」を運びます。[G.8011.1] 2種類のイーサネットプライベートライン（EPL）サービスを定義します。どちらのタイプも、ポートに提示されたすべてのデータが対応する接続ポートに輸送されるサービスを提示します。タイプは、EPLタイプ1サービスがMACフレームレイヤーで動作し、EPLタイプ2サービスがライン（8B/10Bなど）エンコードレイヤーで動作するという点で異なります。[MEF6]は、EPLサービスの1つのタイプのみを定義し、[G.8011.1] EPLタイプ1サービスと一致します。両方のタイプのEPLサービスをサポートするLSPのシグナリングを以下に詳しく説明します。
Signaling for the EPL service types only differ in the LSP Encoding Type used. The LSP Encoding Type used for each are:
EPLサービスタイプのシグナリングは、使用されるLSPエンコードタイプでのみ異なります。それぞれに使用されるLSPエンコードタイプは次のとおりです。
EPL Service LSP Encoding Type (Value) Reference
----------- ------------------------- ---------
Type 1/MEF Ethernet (2) [RFC3471]
Type 2 Line (e.g., 8B/10B)(14) [RFC6004]
The other LSP parameters specific to EPL Service are:
EPLサービスに固有の他のLSPパラメーターは次のとおりです。
Parameter Name (Value) Reference
-------------- ----------------- ------------------
Switching Type DCSC (125) [RFC6002]
G-PID Ethernet PHY (33) [RFC3471][RFC4328]
The parameters defined in this section MUST be used when establishing and controlling LSPs that provide EPL service type Ethernet switching. The procedures defined in Section 2 and the other procedures defined in [RFC3473] for the establishment and management of bidirectional LSPs MUST be followed when establishing and controlling LSPs that provide EPL service type Ethernet switching.
このセクションで定義されているパラメーターは、EPLサービスタイプのイーサネットスイッチングを提供するLSPを確立および制御するときに使用する必要があります。セクション2で定義されている手順と、EPLサービスタイプのイーサネットスイッチングを提供するLSPを確立および制御する際に、双方向LSPの確立と管理のために[RFC3473]で定義されたその他の手順を実行する必要があります。
EVPL service is defined within the context of both [G.8011.2] and [MEF6]. EVPL service allows for multiple Ethernet connections per port, each of which supports a specific set of VLAN IDs. The service attributes identify different forms of EVPL services, e.g., bundled or unbundled. Independent of the different forms, LSPs supporting EVPL Ethernet type switching are signaled using the same mechanisms to communicate the one or more VLAN IDs associated with a particular LSP (Ethernet connection).
EVPLサービスは、[G.8011.2]と[MEF6]の両方のコンテキスト内で定義されます。EVPLサービスにより、ポートごとに複数のイーサネット接続が可能になり、それぞれがVLAN IDの特定のセットをサポートします。このサービス属性は、さまざまな形式のEVPLサービスを識別します。たとえば、バンドルまたはバンドルされていません。さまざまな形式とは無関係に、EVPLイーサネットタイプのスイッチングをサポートするLSPは、同じメカニズムを使用して特定のLSPに関連付けられた1つ以上のVLAN IDを通信します（イーサネット接続）。
The relevant [RFC3471] parameter values that MUST be used for EVPL connections are:
EVPL接続に使用する必要がある関連[RFC3471]パラメーター値は次のとおりです。
Parameter Name (Value) Reference
-------------- ----------------- ------------------
Switching Type EVPL (30) [RFC6004]
LSP Encoding Type Ethernet (2) [RFC3471]
G-PID Ethernet PHY (33) [RFC3471][RFC4328]
As with EPL, the procedures defined in Section 2 and the other procedures defined in [RFC3473] for the establishment and management of bidirectional LSPs MUST be followed when establishing and controlling LSPs that provide EVPL service type Ethernet switching.
EPLと同様に、EVPLサービスタイプのイーサネットスイッチングを提供するLSPを確立および制御する際には、セクション2で定義されている手順および双方向LSPの確立と管理のために[RFC3473]で定義されている他の手順に従う必要があります。
LSPs that provide EVPL service type Ethernet switching MUST use the EVPL Generalized Label Format per Section 4.1, and the Generalized Channel_Set Label Objects per [RFC6002]. A notable implication of bundled EVPL services and carrying multiple VLAN IDs is that a Path message may grow to be larger than a single (fragmented or non-fragmented) IP packet. The basic approach to solving this is to allow for multiple LSPs which are associated with a single Call, see Section 2.2. The specifics of this approach are describe below in Section 4.4.
EVPLサービスタイプのイーサネットスイッチングを提供するLSPは、セクション4.1ごとにEVPL一般化ラベル形式、および[RFC6002]ごとに一般化されたチャネル_セットラベルオブジェクトを使用する必要があります。バンドルされたEVPLサービスと複数のVLAN IDを運ぶことの顕著な意味は、パスメッセージが単一の（断片化されていないまたは非フラグメントされていない）IPパケットよりも大きくなる可能性があることです。これを解決するための基本的なアプローチは、単一の呼び出しに関連付けられている複数のLSPを許可することです。セクション2.2を参照してください。このアプローチの詳細については、以下にセクション4.4で説明します。
Bundled EVPL services require the use of a service-specific label, called the EVPL Generalized Label. For consistency, non-bundled EVPL services also use the same label.
バンドルされたEVPLサービスには、EVPL一般化ラベルと呼ばれるサービス固有のラベルを使用する必要があります。一貫性のために、バンドルされていないEVPLサービスも同じラベルを使用します。
The format for the Generalized Label (Label Type value 2) used with EVPL services is:
EVPLサービスで使用される一般化ラベル（ラベルタイプ値2）の形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 4 bits
予約済み：4ビット
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. This field SHOULD be passed unmodified by transit nodes.
このフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。このフィールドは、トランジットノードによって変更されずに渡される必要があります。
VLAN ID: 12 bits
VLAN ID：12ビット
A VLAN identifier.
VLAN識別子。
When an EVPL service is not configured for both bundling and VLAN ID preservation, [MEF6] allows VLAN ID mapping. In particular, the single VLAN ID used at the incoming interface of the ingress may be mapped to a different VLAN ID at the outgoing interface at the egress UNI. Such mapping MUST be requested and signaled based on the explicit label control mechanism defined in [RFC3473] and clarified in [RFC4003].
BundlingとVLAN IDの保存の両方に対してEVPLサービスが構成されていない場合、[MEF6]はVLAN IDマッピングを許可します。特に、侵入の着信インターフェイスで使用される単一のVLAN IDは、Egress Uniの発信インターフェイスで別のVLAN IDにマッピングできます。このようなマッピングは、[RFC3473]で定義され、[RFC4003]で明確にされた明示的なラベル制御メカニズムに基づいて要求および信号を送信する必要があります。
When the explicit label control mechanism is not used, VLAN IDs MUST be preserved, i.e., not modified, across an LSP.
明示的なラベル制御メカニズムを使用しない場合、VLAN IDを保存する必要があります。つまり、LSP全体で変更されません。
For simplicity in management, a single LSP SHOULD be used for each EVPL type LSP whose Path and Resv messages fit within a single unfragmented IP packet. This allows the reuse of all standard LSP modification procedures. Of particular note is the modification of the VLAN IDs associated with the Ethernet connection. Specifically, [RFC6002], make-before-break procedures SHOULD be used to modify the Channel_Set LABEL object.
管理を簡単にするには、単一のEVPLタイプLSPに単一のLSPを使用する必要があります。そのパスとRESVメッセージは、単一のフラージメントされていないIPパケット内に適合します。これにより、すべての標準のLSP変更手順を再利用できます。特に注目すべきは、イーサネット接続に関連付けられたVLAN IDの変更です。具体的には、[RFC6002]、Make-Be-Be-Be-Be-Be-Be-Be-Be-Be-Be-Set Labelオブジェクトを変更するために使用する必要があります。
Multiple LSPs MAY be used to support an EVPL service connection. All such LSPs MUST be established within the same Call and follow Call-related procedures, see Section 2.2. The primary purpose of multiple LSPs is to support the case in which the related objects result in a Path message being larger than a single unfragmented IP packet.
EVPLサービス接続をサポートするために、複数のLSPを使用できます。そのようなすべてのLSPは、同じ呼び出し内で確立され、コール関連の手順に従う必要があります。セクション2.2を参照してください。複数のLSPの主な目的は、関連するオブジェクトが単一のフラージメントされていないIPパケットよりも大きいパスメッセージを作成する場合をサポートすることです。
When using multiple LSPs, all LSPs associated with the same Call/EVPL connection MUST be signaled with the same LSP objects with the exception of the SENDER_TEMPLATE, SESSION, and label-related objects. All such LSPs SHOULD share resources. When using multiple LSPs, VLAN IDs MAY be added to the EVPL connection using either a new LSP or make-before-break procedures, see [RFC3209]. Make-before-break procedures on individual LSPs SHOULD be used to remove VLAN IDs.
複数のLSPを使用する場合、Sender_Template、セッション、およびラベル関連オブジェクトを除き、同じコール/EVPL接続に関連付けられたすべてのLSPを同じLSPオブジェクトで信号する必要があります。そのようなLSPはすべてリソースを共有する必要があります。複数のLSPを使用する場合、新しいLSPまたはブレイク前の手順のいずれかを使用してVLAN IDをEVPL接続に追加できます。[RFC3209]を参照してください。個々のLSPのブレイク前の手順を使用して、VLAN IDを削除するために使用する必要があります。
To change other service parameters it is necessary to re-signal all LSPs associated with the Call via make-before-break procedures.
他のサービスパラメーターを変更するには、ブレイク前の手順を介してコールに関連付けられたすべてのLSPを再燃させる必要があります。
IANA has assigned new values for namespaces defined in this document and summarized in this section. The registries are available from http://www.iana.org.
IANAは、このドキュメントで定義され、このセクションで要約されている名前空間に新しい値を割り当てています。レジストリはhttp://www.iana.orgから入手できます。
IANA has made the following assignment in the "Call Attributes TLV" section of the "RSVP Parameters" registry.
IANAは、「RSVPパラメーター」レジストリの「呼び出し属性TLV」セクションで次の割り当てを行いました。
Type Name Reference
---- ----------- ---------
2 Endpoint ID [RFC6004]
IANA has made the following assignment in the "LSP Encoding Types" section of the "GMPLS Signaling Parameters" registry.
IANAは、「GMPLSシグナリングパラメーター」レジストリの「LSPエンコードタイプ」セクションで次の割り当てを行いました。
Value Type Reference
----- --------------------------- ---------
14 Line (e.g., 8B/10B) [RFC6004]
IANA has made the following assignment in the "Switching Types" section of the "GMPLS Signaling Parameters" registry.
IANAは、「GMPLSシグナリングパラメーター」レジストリの「スイッチングタイプ」セクションで次の割り当てを行いました。
Value Type Reference
----- ------------------------------------ ---------
30 Ethernet Virtual Private Line (EVPL) [RFC6004]
The assigned value has been reflected in IANAGmplsSwitchingTypeTC of the IANA-GMPLS-TC-MIB available from http://www.iana.org.
割り当てられた値は、http：//www.iana.orgから入手可能なiana-gmpls-tc-mibのianagmplsswitchingtypetcに反映されています。
This document introduces new message object formats for use in GMPLS signaling [RFC3473]. It does not introduce any new signaling messages, nor change the relationship between Label Switching Routers (LSRs) that are adjacent in the control plane. As such, this document introduces no additional security considerations to those discussed in [RFC3473].
このドキュメントでは、GMPLSシグナル伝達[RFC3473]で使用する新しいメッセージオブジェクト形式を導入します。新しいシグナリングメッセージは導入されたり、制御面に隣接するラベルスイッチングルーター（LSR）間の関係を変更しません。そのため、この文書では、[RFC3473]で議論されているものに追加のセキュリティ上の考慮事項は導入されていません。
[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年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005.
[RFC4003] Berger、L。、「GMPLS Signaling Procedure for Eugress Control」、RFC 4003、2005年2月。
[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月。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D. and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC6001] Papadimitriou、D.、Vigoureux、M.、Shiomoto、K.、Brungard、D。およびJl。Le Roux、「マルチレイヤーおよびマルチリージョンネットワーク（MLN/MRN）の一般化MPLS（GMPLS）プロトコル拡張」、RFC 6001、2010年10月。
[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月。
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters," RFC 6003, October 2010.
[RFC6003] Papadimitriou、D。、「イーサネットトラフィックパラメーター」、RFC 6003、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月。
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
[RFC4328] Papadimitriou、D.、ed。、「G.709光学輸送ネットワーク制御用の一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング拡張」、RFC 4328、2006年1月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、ed。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（LSP） "、RFC 4875、2007年5月。
[RFC6005] Berger, L. and D. Fedyk,"Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)", RFC 6005, October 2010.
[RFC6005] Berger、L。およびD. Fedyk、「メトロイーサネットフォーラムおよびG.8011ユーザーネットワークインターフェイス（UNI）の一般化MPLS（GMPLS）サポート」、RFC 6005、2010年10月。
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, Stephen Shew, and Yoav Cohen for their valuable comments.
著者は、Evelyne Roch、Stephen Shew、およびYoav Cohenの貴重なコメントに感謝したいと思います。
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