[要約] RFC 7369は、Ethernetの運用、管理、および保守（OAM）設定のためのGMPLS RSVP-TE拡張に関するものです。このRFCの目的は、GMPLS RSVP-TEプロトコルを使用してEthernetネットワークのOAM機能を設定するための拡張を提供することです。
Internet Engineering Task Force (IETF) A. Takacs
Request for Comments: 7369 B. Gero
Category: Standards Track Ericsson
ISSN: 2070-1721 H. Long
Huawei
October 2014
GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration
GMPLS RSVP-TE Extensions for Ethernet Operations、Administration、and Maintenance（OAM）Configuration
Abstract
概要
The work related to GMPLS Ethernet Label Switching (GELS) extended GMPLS RSVP-TE to support the establishment of Ethernet Label Switching Paths (LSPs). IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct Operations, Administration, and Maintenance (OAM) flow to check connectivity in Ethernet networks. CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAM Configuration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms.
GMPLSイーサネットラベルスイッチング（GELS）に関連する作業は、イーサネットラベルスイッチングパス（LSP）の確立をサポートするためにGMPLS RSVP-TEを拡張しました。 IEEEイーサネット接続障害管理（CFM）は、イーサネットネットワークの接続をチェックするための付属の運用、管理、および保守（OAM）フローを指定します。 CFMは、イーサネットLSPとともに使用して、障害を検出し、回復メカニズムをトリガーすることもできます。 ITU-T Y.1731仕様はCFMに基づいて構築され、イーサネットネットワーク用のパフォーマンスモニタリングを含む追加のOAMメカニズムを指定します。このドキュメントでは、イーサネットLSPの関連するイーサネットOAMエンティティのセットアップをサポートするGMPLS RSVP-TEプロトコルの拡張を指定し、GMPLS OAM構成フレームワークに基づいてイーサネットテクノロジー固有のTLVを定義します。このドキュメントは、IEEEおよびITU-T OAMメカニズムをサポートしますが、変更はしません。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc7369.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7369で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of Ethernet OAM Operation . . . . . . . . . . . . . 3
3. GMPLS RSVP-TE Extensions . . . . . . . . . . . . . . . . . . 5
3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 5
3.2. OAM Configuration TLV . . . . . . . . . . . . . . . . . . 7
3.3. Ethernet OAM Configuration Sub-TLV . . . . . . . . . . . 8
3.3.1. MD Name Sub-TLV . . . . . . . . . . . . . . . . . . . 9
3.3.2. Short MA Name Sub-TLV . . . . . . . . . . . . . . . . 10
3.3.3. MEP ID Sub-TLV . . . . . . . . . . . . . . . . . . . 11
3.3.4. Continuity Check (CC) Sub-TLV . . . . . . . . . . . . 12
3.4. Proactive Performance Monitoring . . . . . . . . . . . . 12
3.5. Summary of Ethernet OAM Configuration Errors . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. RSVP-TE OAM Configuration Registry . . . . . . . . . . . 14
4.2. Ethernet Sub-TLVs Sub-Registry . . . . . . . . . . . . . 15
4.3. RSVP Error Code . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Provider Backbone Bridging - Traffic Engineering (PBB-TE) [IEEE.802.1Q-2011] decouples the Ethernet data and control planes and allows external control and management mechanisms to create explicitly routed Ethernet connections. In addition, PBB-TE defines mechanisms for protection switching of bidirectional Ethernet connections. Ethernet Connectivity Fault Management (CFM) defines an adjunct connectivity-monitoring OAM flow to check the liveliness of Ethernet networks [IEEE.802.1Q-2011], including the monitoring of specific explicitly routed Ethernet connections. The ITU-T Recommendation Y.1731 [ITU-T.G.8013-2013] extended CFM and specified additional OAM functionality.
プロバイダーバックボーンブリッジング-トラフィックエンジニアリング（PBB-TE）[IEEE.802.1Q-2011]は、イーサネットデータとコントロールプレーンを分離し、外部制御および管理メカニズムが明示的にルーティングされたイーサネット接続を作成できるようにします。さらに、PBB-TEは双方向イーサネット接続の保護スイッチングのメカニズムを定義します。イーサネット接続障害管理（CFM）は、特定の明示的にルーティングされたイーサネット接続の監視を含む、イーサネットネットワーク[IEEE.802.1Q-2011]の稼働状況をチェックするための補助接続監視OAMフローを定義します。 ITU-T勧告Y.1731 [ITU-T.G.8013-2013]はCFMを拡張し、追加のOAM機能を指定しました。
In the IETF, the work related to GMPLS Ethernet Label Switching (GELS) extended the GMPLS control plane to support the establishment of explicitly routed Ethernet connections [RFC5828] [RFC6060]. We refer to GMPLS-established Ethernet connections as "Ethernet LSPs". GELS enables the application of MPLS-TE and GMPLS provisioning and recovery features in Ethernet networks.
IETFでは、GMPLSイーサネットラベルスイッチング（GELS）に関連する作業により、GMPLSコントロールプレーンが拡張され、明示的にルーティングされるイーサネット接続[RFC5828] [RFC6060]の確立がサポートされました。 GMPLSで確立されたイーサネット接続を「イーサネットLSP」と呼びます。 GELSは、イーサネットネットワークでのMPLS-TEおよびGMPLSプロビジョニングおよびリカバリ機能の適用を可能にします。
The use of GMPLS RSVP-TE to support the establishment and configuration of OAM entities with LSP signaling is defined in a technology-agnostic way in [RFC7260]. The purpose of this document is to specify the additional technology-specific OAM entities to support Ethernet connections.
LMPシグナリングを使用したOAMエンティティの確立と構成をサポートするためのGMPLS RSVP-TEの使用は、技術にとらわれない方法で[RFC7260]で定義されています。このドキュメントの目的は、イーサネット接続をサポートする追加のテクノロジー固有のOAMエンティティを指定することです。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
For the purposes of this document, we only discuss Ethernet OAM aspects that are relevant for proactive connectivity monitoring of Ethernet LSPs and assume that on-demand OAM functions will be supported by management-plane operations.
このドキュメントでは、イーサネットLSPの予防的な接続監視に関連するイーサネットOAMの側面のみを説明し、オンデマンドOAM機能が管理プレーン操作によってサポートされることを前提としています。
PBB-TE defines point-to-point Ethernet Switched Paths (ESPs) as a provisioned, traffic-engineered, unidirectional connectivity, identified by the 3-tuple [ESP-MAC DA, ESP-MAC SA, ESP-VID], where the ESP-MAC DA is the destination address of the ESP, the ESP-MAC SA is the source address of the ESP, and the ESP-VID is a VLAN identifier allocated for explicitly routed connections. To form a bidirectional PBB-TE connection, two co-routed point-to-point ESPs are combined. The combined ESPs must have the same ESP-MAC addresses but may have different ESP-VIDs. The formed co-routed bidirectional path is a path where the forward and backward directions follow the same route (links and nodes) across the network.
PBB-TEは、ポイントツーポイントのイーサネットスイッチドパス（ESP）を、3タプル[ESP-MAC DA、ESP-MAC SA、ESP-VID]で識別される、プロビジョニングされたトラフィックエンジニアリングの単方向接続として定義します。 ESP-MAC DAはESPの宛先アドレス、ESP-MAC SAはESPの送信元アドレス、ESP-VIDは明示的にルーティングされた接続に割り当てられたVLAN識別子です。双方向のPBB-TE接続を形成するには、2つの同じルートのポイントツーポイントESPを組み合わせます。結合されたESPは同じESP-MACアドレスを持つ必要がありますが、ESP-VIDが異なる場合があります。形成された同一経路の双方向パスは、順方向と逆方向がネットワーク全体で同じルート（リンクとノード）をたどるパスです。
Note that although it would be possible to use GMPLS to set up a single unidirectional ESP, the Ethernet OAM mechanisms are only fully functional when bidirectional connections are established with co-routed ESPs. Therefore, the scope of this document only covers bidirectional point-to-point PBB-TE connections.
GMPLSを使用して単一の単方向ESPを設定することは可能ですが、イーサネットOAMメカニズムが完全に機能するのは、双方向接続が共同ルーティングされたESPで確立されている場合のみです。したがって、このドキュメントの範囲は、双方向ポイントツーポイントPBB-TE接続のみを対象としています。
At both ends of the bidirectional point-to-point PBB-TE connection, one Maintenance Entity Group End Point (MEP) is configured. The MEPs monitoring a PBB-TE connection must be configured with the same Maintenance Domain Level (MD Level) and Maintenance Association Identifier (MAID). Each MEP has a unique identifier, the MEP ID. Besides these identifiers, a MEP monitoring a PBB-TE connection must be provisioned with the 3-tuples [ESP-MAC DA, ESP-MAC SA, ESP-VID] of the two ESPs.
双方向ポイントツーポイントPBB-TE接続の両端で、1つのメンテナンスエンティティグループエンドポイント（MEP）が構成されます。 PBB-TE接続を監視するMEPは、同じメンテナンスドメインレベル（MDレベル）とメンテナンスアソシエーション識別子（MAID）で構成する必要があります。各MEPには、一意の識別子であるMEP IDがあります。これらの識別子に加えて、PBB-TE接続を監視するMEPには、2つのESPの3タプル[ESP-MAC DA、ESP-MAC SA、ESP-VID]をプロビジョニングする必要があります。
In the case of point-to-point VLAN connections, the connection may be identified with a single VLAN or with two VLANs, one for each direction. Therefore, instead of the 3-tuples of the PBB-TE ESPs, MEPs must be provisioned with the proper VLAN identifiers.
ポイントツーポイントVLAN接続の場合、接続は単一のVLANまたは各方向に1つずつの2つのVLANで識別できます。したがって、PBB-TE ESPの3タプルではなく、MEPに適切なVLAN識別子をプロビジョニングする必要があります。
MEPs exchange Connectivity Check Messages (CCMs) periodically with fixed intervals. Eight distinct intervals are defined in [IEEE.802.1Q-2011]:
MEPは、一定の間隔で定期的に接続チェックメッセージ（CCM）を交換します。 [IEEE.802.1Q-2011]では、8つの異なる間隔が定義されています。
+---+--------------------+----------------+
| # | CCM Interval (CCI) | 3-Bit Encoding |
+---+--------------------+----------------+
| 0 | Reserved | 000 |
| | | |
| 1 | 3 1/3 ms | 001 |
| | | |
| 2 | 10 ms | 010 |
| | | |
| 3 | 100 ms | 011 |
| | | |
| 4 | 1 s | 100 |
| | | |
| 5 | 10 s | 101 |
| | | |
| 6 | 1 min | 110 |
| | | |
| 7 | 10 min | 111 |
+---+--------------------+----------------+
Table 1: CCM Interval Encoding
If three consecutive CCMs are lost, connectivity failure is declared. The MEP detecting the failure will signal the defect to the remote MEP in the subsequent CCMs it emits by setting the Remote Defect Indicator (RDI) bit in the CCM. If a MEP receives a CCM with the RDI bit set, it immediately declares failure. The detection of a failure may trigger protection switching mechanisms or may be signaled to a management system.
3つの連続したCCMが失われた場合、接続障害が宣言されます。障害を検出したMEPは、CMEのリモート障害インジケーター（RDI）ビットを設定することにより、障害が発生した後続のCCMのリモートMEPに障害を通知します。 MEPは、RDIビットが設定されたCCMを受信すると、すぐに障害を宣言します。障害の検出により、保護切り替えメカニズムがトリガーされるか、管理システムに通知されます。
At each transit node, Maintenance Entity Group Intermediate Points (MIPs) may be established to help failure localization, e.g., using link trace and loopback functions. MIPs need to be provisioned with a subset of the MEP identification parameters described above.
各トランジットノードで、メンテナンスエンティティグループ中間ポイント（MIP）を確立して、たとえばリンクトレースやループバック機能を使用して、障害の特定を支援できます。 MIPは、上記のMEP識別パラメーターのサブセットでプロビジョニングする必要があります。
To simplify the configuration of connectivity monitoring, the associated MEPs should be automatically established when an Ethernet LSP is signaled. To monitor an Ethernet LSP, a set of parameters must be provided to set up a Maintenance Association and related MEPs. Optionally, MIPs may be created at the transit nodes of the Ethernet LSP. The LSP Attribute Flags "OAM MEP entities desired" and "OAM MIP entities desired", as described in [RFC7260], are used to signal that the respective OAM entities must be established. An OAM Configuration TLV, as described in [RFC7260], is added to the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects specifying that Ethernet OAM is to be set up for the LSP. Information specific to Ethernet OAM, as described below, is carried in the new Ethernet OAM Configuration Sub-TLV (see Section 3.3) within the OAM Configuration TLV.
接続監視の構成を簡略化するには、イーサネットLSPが通知されたときに、関連付けられたMEPが自動的に確立される必要があります。イーサネットLSPを監視するには、メンテナンスアソシエーションと関連するMEPをセットアップするためのパラメータセットを提供する必要があります。オプションで、イーサネットLSPのトランジットノードでMIPを作成できます。 [RFC7260]で説明されているLSP属性フラグ「必要なOAM MEPエンティティ」および「必要なOAM MIPエンティティ」は、それぞれのOAMエンティティを確立する必要があることを示すために使用されます。 [RFC7260]で説明されているOAM構成TLVがLSP_ATTRIBUTESまたはLSP_REQUIRED_ATTRIBUTESオブジェクトに追加され、LSP用にイーサネットOAMがセットアップされることを指定します。以下で説明するように、イーサネットOAMに固有の情報は、OAM構成TLV内の新しいイーサネットOAM構成サブTLV（セクション3.3を参照）で伝達されます。
o A unique MAID must be allocated for the PBB-TE connection, and both MEPs must be configured with the same information. The MAID consists of an optional Maintenance Domain Name (MD Name) and a mandatory Short Maintenance Association Name (Short MA Name). Various formatting rules for these names have been defined in [IEEE.802.1Q-2011]. Since this information is also carried in all CCMs, the combined length of the MD Name and Short MA Name is limited to 44 bytes (see [IEEE.802.1Q-2011] for the details of the message format). How these parameters are determined is out of the scope of this document.
o PBB-TE接続に一意のMAIDを割り当て、両方のMEPに同じ情報を設定する必要があります。 MAIDは、オプションのメンテナンスドメイン名（MD名）と必須のショートメンテナンスアソシエーション名（短いMA名）で構成されます。これらの名前のさまざまなフォーマットルールが[IEEE.802.1Q-2011]で定義されています。この情報はすべてのCCMでも伝達されるため、MD名と短いMA名を組み合わせた長さは44バイトに制限されます（メッセージフォーマットの詳細については、[IEEE.802.1Q-2011]を参照してください）。これらのパラメータの決定方法は、このドキュメントの範囲外です。
o Each MEP must be provisioned with a MEP ID. The MEP ID uniquely identifies a given MEP within a Maintenance Association. That is, the combination of MAID and MEP ID must uniquely identify a MEP. How the value of the MEP ID is determined is out of the scope of this document.
o 各MEPには、MEP IDをプロビジョニングする必要があります。 MEP IDは、メンテナンスアソシエーション内の特定のMEPを一意に識別します。つまり、MAIDとMEP IDの組み合わせは、MEPを一意に識別する必要があります。 MEP IDの値の決定方法は、このドキュメントの範囲外です。
o The Maintenance Domain Level (MD Level) allows hierarchical separation of monitoring entities. [IEEE.802.1Q-2011] allows differentiation of eight levels. How the value of the MD Level is determined is out of the scope of this document. Note that probably for all Ethernet LSPs, a single (default) MD Level will be used within a network domain.
o メンテナンスドメインレベル（MDレベル）では、監視エンティティを階層的に分離できます。 [IEEE.802.1Q-2011]では、8つのレベルを区別できます。 MDレベルの値の決定方法は、このドキュメントの範囲外です。おそらくすべてのイーサネットLSPで、ネットワークドメイン内で単一（デフォルト）のMDレベルが使用されることに注意してください。
o The desired CCM Interval must be specified by the management system based on service requirements or operator policy. The same CCM Interval must be set in each of the MEPs monitoring a given Ethernet LSP. How the value of the CCM Interval is determined is out of the scope of this document.
o 必要なCCM間隔は、サービス要件またはオペレーターのポリシーに基づいて、管理システムによって指定する必要があります。特定のイーサネットLSPを監視する各MEPで同じCCM間隔を設定する必要があります。 CCM間隔の値を決定する方法は、このドキュメントの範囲外です。
o The desired forwarding priority to be set by MEPs for the CCM frames may be specified. The same CCM priority must be set in each of the MEPs monitoring a given Ethernet LSP. How CCM priority is determined is out of the scope of this document. Note that the highest priority should be used as the default CCM priority.
o CCMフレームのMEPによって設定される必要な転送優先度を指定できます。特定のイーサネットLSPを監視する各MEPに同じCCM優先度を設定する必要があります。 CCMの優先度の決定方法は、このドキュメントの範囲外です。最高の優先度をデフォルトのCCM優先度として使用する必要があることに注意してください。
o MEPs must be aware of their own reachability parameters and those of the remote MEP. In the case of bidirectional point-to-point PBB-TE connections, this requires that the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are configured in each MEP, where the ESP-MAC A is the same as the local MEP's Media Access Control (MAC) address and ESP-MAC B is the same as the remote MEP's MAC address. The GMPLS Ethernet Label format, as defined in [RFC6060], consists of the ESP-MAC DA and ESP-VID. Hence, the necessary reachability parameters for the MEPs can be obtained from the Ethernet Labels (i.e., carried in the downstream and upstream labels). In the case of point-to-point VLAN connections, MEPs need to be provisioned with the VLAN identifiers only, which can be derived similarly from the Ethernet Labels.
o MEPは、独自の到達可能性パラメータとリモートMEPの到達可能性パラメータを認識している必要があります。双方向ポイントツーポイントPBB-TE接続の場合、これには3タプル[ESP-MAC A、ESP-MAC B、ESP-VID1]および[ESP-MAC B、ESP-MAC A、ESP -VID2]は各MEPで構成され、ESP-MAC AはローカルMEPのメディアアクセス制御（MAC）アドレスと同じであり、ESP-MAC BはリモートMEPのMACアドレスと同じです。 [RFC6060]で定義されているGMPLSイーサネットラベル形式は、ESP-MAC DAおよびESP-VIDで構成されています。したがって、MEPに必要な到達可能性パラメータは、イーサネットラベルから取得できます（つまり、ダウンストリームラベルとアップストリームラベルで運ばれます）。ポイントツーポイントVLAN接続の場合、MEPにはVLAN識別子のみをプロビジョニングする必要があります。これは、イーサネットラベルから同様に取得できます。
Based on the procedures described in [RFC6060] for bidirectional PBB-TE Ethernet LSP establishment, the Ethernet OAM configuration procedures are as follows.
[RFC6060]で説明されている双方向PBB-TEイーサネットLSP確立の手順に基づいて、イーサネットOAM設定手順は次のとおりです。
When the RSVP-TE signaling is initiated for the bidirectional Ethernet LSP, the local node generates a Path message and:
RSVP-TEシグナリングが双方向イーサネットLSPに対して開始されると、ローカルノードはパスメッセージを生成し、次のことを行います。
o Allocates an upstream label formed by combining its MAC address (ESP-MAC A) and locally selected VID (ESP-VID1), which will be used to receive traffic;
o MACアドレス（ESP-MAC A）とローカルで選択されたVID（ESP-VID1）を組み合わせることによって形成されるアップストリームラベルを割り当てます。これらはトラフィックの受信に使用されます。
o MUST include the OAM Configuration TLV with OAM Type set to Ethernet OAM in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects;
o LSP_ATTRIBUTESまたはLSP_REQUIRED_ATTRIBUTESオブジェクトにイーサネットOAMに設定されたOAMタイプのOAM構成TLVを含める必要があります。
o MUST include the OAM Function Flags Sub-TLV in the OAM Configuration TLV and set the OAM function flags as needed;
o OAM構成TLVにOAM機能フラグサブTLVを含め、必要に応じてOAM機能フラグを設定する必要があります。
o MUST include an Ethernet OAM Configuration Sub-TLV in the OAM Configuration TLV that specifies the CCM Interval and MD Level;
o CCM間隔とMDレベルを指定するOAM構成TLVにイーサネットOAM構成サブTLVを含める必要があります。
o MAY add an MD Name Sub-TLV (optional) and MUST add a Short MA Name Sub-TLV (required) to the Ethernet OAM Configuration Sub-TLV, which will unambiguously identify a Maintenance Association for this specific PBB-TE connection. Note that values for these parameters may be derived from the GMPLS LSP identification parameters; and
o MD名サブTLV（オプション）を追加する場合があり、イーサネットOAM構成サブTLVにショートMA名サブTLV（必須）を追加する必要があります。これにより、この特定のPBB-TE接続のメンテナンスアソシエーションが明確に識別されます。これらのパラメータの値は、GMPLS LSP識別パラメータから導出される場合があることに注意してください。そして
o MUST include a MEP ID Sub-TLV in the Ethernet OAM Configuration Sub-TLV and select two distinct integer values to identify the local and remote MEPs within the Maintenance Association created for monitoring of the point-to-point PBB-TE connection.
o イーサネットOAM構成サブTLVにMEP IDサブTLVを含め、2つの異なる整数値を選択して、ポイントツーポイントPBB-TE接続の監視用に作成されたメンテナンスアソシエーション内のローカルおよびリモートMEPを識別する必要があります。
Once the remote node receives the Path message, it can use the UPSTREAM_LABEL to extract the reachability information of the initiator. Then, it allocates a Label by selecting a local MAC address (ESP-MAC B) and VID (ESP-VID2) that will be used to receive traffic. These parameters determine the reachability information of the local MEP. That is, the 3-tuples [ESP-MAC A, ESP-MAC B, ESP-VID1] and [ESP-MAC B, ESP-MAC A, ESP-VID2] are derived from the Ethernet Labels. In addition, the information received in the Ethernet OAM Configuration TLV is used to configure the local MEP.
リモートノードがPathメッセージを受信すると、UPSTREAM_LABELを使用してイニシエーターの到達可能性情報を抽出できます。次に、トラフィックの受信に使用されるローカルMACアドレス（ESP-MAC B）とVID（ESP-VID2）を選択して、ラベルを割り当てます。これらのパラメータは、ローカルMEPの到達可能性情報を決定します。つまり、3タプル[ESP-MAC A、ESP-MAC B、ESP-VID1]および[ESP-MAC B、ESP-MAC A、ESP-VID2]はイーサネットラベルから派生します。さらに、イーサネットOAM構成TLVで受信した情報は、ローカルMEPの構成に使用されます。
Once the Resv message successfully arrives to the initiator, this end can extract the remote side's reachability information from the Label object and therefore has all the information needed to properly configure its local MEP.
Resvメッセージがイニシエーターに正常に到着すると、このエンドはリモート側の到達可能性情報をLabelオブジェクトから抽出できるため、ローカルMEPを適切に構成するために必要なすべての情報を取得できます。
This TLV is specified in [RFC7260] and is used to select which OAM technology/method should be used for the LSP. In this document, a new OAM Type, Ethernet OAM, is defined. IANA has allocated OAM Type 1 for Ethernet OAM in the "RSVP-TE OAM Configuration Registry".
このTLVは[RFC7260]で指定されており、LSPに使用するOAMテクノロジー/メソッドを選択するために使用されます。このドキュメントでは、新しいOAMタイプであるイーサネットOAMが定義されています。 IANAは、「RSVP-TE OAM構成レジストリ」でイーサネットOAMにOAMタイプ1を割り当てました。
RSVP-TE OAM Configuration Registry
RSVP-TE OAM構成レジストリ
OAM Type Description
------------ ------------------
1 Ethernet OAM
When the Ethernet OAM Type is requested, the receiving node should look for the corresponding technology-specific Ethernet OAM Configuration Sub-TLV.
イーサネットOAMタイプが要求されると、受信ノードは対応するテクノロジー固有のイーサネットOAM構成サブTLVを探す必要があります。
The Ethernet OAM Configuration Sub-TLV (depicted below) is defined for configuration parameters specific to Ethernet OAM. The Ethernet OAM Configuration Sub-TLV, when used, MUST be carried in the OAM Configuration TLV. This new sub-TLV accommodates Ethernet OAM information and carries sub-TLVs.
イーサネットOAM構成サブTLV（以下に表示）は、イーサネットOAMに固有の構成パラメーターに対して定義されます。イーサネットOAM構成サブTLVを使用する場合は、OAM構成TLVに含める必要があります。この新しいサブTLVは、イーサネットOAM情報に対応し、サブ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 32 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |MD L.| Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Indicates a new type, the Ethernet OAM Configuration Sub-TLV. IANA has assigned the value 32 from the "OAM Sub-TLVs" space in the "RSVP-TE OAM Configuration Registry".
タイプ：新しいタイプ、イーサネットOAM構成サブTLVを示します。 IANAは、「RSVP-TE OAM構成レジストリ」の「OAMサブTLV」スペースから値32を割り当てました。
Length: Indicates the total length of the TLV including padding and including the Type and Length fields.
長さ：パディングを含み、タイプと長さフィールドを含むTLVの全長を示します。
Version: Identifies the CFM protocol version according to [IEEE.802.1Q-2011]. If a node does not support a specific CFM version, an error MUST be generated: "OAM Problem/Unsupported OAM Version".
バージョン：[IEEE.802.1Q-2011]に従ってCFMプロトコルのバージョンを識別します。ノードが特定のCFMバージョンをサポートしていない場合は、「OAM問題/サポートされていないOAMバージョン」というエラーを生成する必要があります。
MD L. (MD Level): Indicates the desired MD Level. Possible values are defined according to [IEEE.802.1Q-2011]. If a node does not support a specific MD Level, an error MUST be generated: "OAM Problem/Unsupported MD Level".
MD L.（MDレベル）：希望のMDレベルを示します。可能な値は[IEEE.802.1Q-2011]に従って定義されています。ノードが特定のMDレベルをサポートしていない場合は、「OAM問題/サポートされていないMDレベル」というエラーを生成する必要があります。
The optional MD Name Sub-TLV is depicted below. It MAY be used for MD naming.
オプションのMD Name Sub-TLVを以下に示します。 MDネーミングに使用される場合があります。
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 (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MD Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 1, MD Name Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
タイプ：1、MD Name Sub-TLV。 IANAは、イーサネットOAM構成サブTLVで伝送されるサブTLVタイプの「RSVP-TE OAM構成レジストリ」にイーサネットTLVタイプスペースを維持します。
Length: Indicates the total length of the TLV, including padding and the Type and Length fields.
長さ：TLVの全長を示します。パディング、タイプ、長さフィールドを含みます。
Format: According to [IEEE.802.1Q-2011].
フォーマット：[IEEE.802.1Q-2011]に準拠。
Name Length: The length of the MD Name field in bytes. This is necessary to allow non-4-byte padded MD Name lengths.
名前の長さ：MD名フィールドの長さ（バイト単位）。これは、4バイト以外の埋め込みMD名の長さを許可するために必要です。
MD Name: Variable-length field, formatted according to the format specified in the Format field.
MD名：「フォーマット」フィールドで指定されたフォーマットに従ってフォーマットされた可変長フィールド。
If an undefined Format is specified, an error MUST be generated: "OAM Problem/Unknown MD Name Format". Also, the combined length of MD Name and Short MA Name MUST be less than or equal to 44 bytes. If this is violated, an error MUST be generated: "OAM Problem/Name Length Problem". Note that it is allowed to have no MD Name; therefore, the MD Name Sub-TLV is optional. In this case, the MA Name must uniquely identify a Maintenance Association.
未定義の形式が指定されている場合、エラーが生成される必要があります：「OAM問題/不明なMD名の形式」。また、MD名とショートMA名を組み合わせた長さは44バイト以下でなければなりません。これに違反した場合は、「OAMの問題/名前の長さの問題」というエラーを生成する必要があります。 MD名は許可されないことに注意してください。したがって、MD Name Sub-TLVはオプションです。この場合、MA名はメンテナンスアソシエーションを一意に識別する必要があります。
The Short MA Name Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.
短いMA名のサブTLVを以下に示します。このサブTLVは、イーサネットOAM構成サブ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 (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Format | Name Length | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Short MA Name ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 2, Short MA Name Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
タイプ：2、短いMA名のサブTLV。 IANAは、イーサネットOAM構成サブTLVで伝送されるサブTLVタイプの「RSVP-TE OAM構成レジストリ」にイーサネットTLVタイプスペースを維持します。
Length: Indicates the total length of the TLV, including padding and the Type and Length fields.
長さ：TLVの全長を示します。パディング、タイプ、長さフィールドを含みます。
Format: According to [IEEE.802.1Q-2011].
フォーマット：[IEEE.802.1Q-2011]に準拠。
Name Length: The length of the Short MA Name field in bytes. This is necessary to allow non-4-byte padded MA Name lengths.
名前の長さ：ショートMA名フィールドの長さ（バイト単位）。これは、4バイト以外の埋め込みMA名の長さを許可するために必要です。
Short MA Name: Variable-length field formatted according to the format specified in the Format field.
ショートMA名：「フォーマット」フィールドで指定されたフォーマットに従ってフォーマットされた可変長フィールド。
If an undefined Format is specified, an error MUST be generated: "OAM Problem/Unknown MA Name Format". Also, the combined length of MD Name and Short MA Name MUST be less than or equal to 44 bytes. If this is violated, an error MUST be generated: "OAM Problem/Name Length Problem". Note that it is allowed to have no MD Name; in this case, the MA Name MUST uniquely identify a Maintenance Association.
未定義の形式が指定されている場合、エラーが生成される必要があります：「OAM問題/不明なMA名の形式」。また、MD名とショートMA名を組み合わせた長さは44バイト以下でなければなりません。これに違反した場合は、「OAMの問題/名前の長さの問題」というエラーを生成する必要があります。 MD名は許可されないことに注意してください。この場合、MA名はメンテナンスアソシエーションを一意に識別する必要があります。
The MEP ID Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.
MEP ID Sub-TLVを以下に示します。このサブTLVは、イーサネットOAM構成サブ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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote MEP ID |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3, MEP ID Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
タイプ：3、MEP IDサブTLV。 IANAは、イーサネットOAM構成サブTLVで伝送されるサブTLVタイプの「RSVP-TE OAM構成レジストリ」にイーサネットTLVタイプスペースを維持します。
Length: Indicates the total length of the TLV, including padding and the Type and Length fields.
長さ：TLVの全長を示します。パディング、タイプ、長さフィールドを含みます。
Local MEP ID: A 16-bit integer value in the range 1-8191 of the MEP ID on the initiator side.
ローカルMEP ID：イニシエーター側のMEP IDの1から8191の範囲の16ビット整数値。
Remote MEP ID: A 16-bit integer value in the range 1-8191 of the MEP ID to be set for the MEP established at the receiving side. This value is determined by the initiator node. This is possible since a new MAID is assigned to each PBB-TE connection, and MEP IDs must be only unique within the scope of the MAID.
リモートMEP ID：受信側で確立されたMEPに設定される、MEP IDの1〜8191の範囲の16ビット整数値。この値は、イニシエーターノードによって決定されます。新しいMAIDが各PBB-TE接続に割り当てられ、MEP IDはMAIDのスコープ内でのみ一意でなければならないため、これは可能です。
Two flags are defined: Transmit (T) and Receive (R). When T is set, the corresponding MEP MUST send OAM packets. When R is set, the corresponding MEP MUST expect to receive OAM packets. These flags are used to configure the role of MEPs.
送信（T）と受信（R）の2つのフラグが定義されています。 Tが設定されている場合、対応するMEPはOAMパケットを送信する必要があります。 Rが設定されている場合、対応するMEPはOAMパケットの受信を予期する必要があります。これらのフラグは、MEPの役割を構成するために使用されます。
The Continuity Check (CC) Sub-TLV is depicted below. This sub-TLV MUST be present in the Ethernet OAM Configuration Sub-TLV.
導通チェック（CC）サブTLVを以下に示します。このサブTLVは、イーサネットOAM構成サブ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 (4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prio | CCM I | Reserved (set to all 0s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4, Continuity Check (CC) Sub-TLV. IANA will maintain an Ethernet TLV Type space in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV.
タイプ：4、導通チェック（CC）サブTLV。 IANAは、イーサネットOAM構成サブTLVで伝送されるサブTLVタイプの「RSVP-TE OAM構成レジストリ」にイーサネットTLVタイプスペースを維持します。
Length: Indicates the total length of the TLV, including padding and the Type and Length fields.
長さ：TLVの全長を示します。パディング、タイプ、長さフィールドを含みます。
Prio: Indicates the priority to be set for CCM frames. In Ethernet, 3 bits carried in VLAN TAGs identify priority information. Setting the priority is optional. If the most significant bit is set to zero, the subsequent 3 priority bits will be ignored, and priority bits of the Ethernet CCM frame will be set based on default values specified in the Ethernet nodes. If the most significant bit is set to 1, the subsequent 3 bits will be used to set the priority bits of the Ethernet CCM frame.
Prio：CCMフレームに設定する優先度を示します。イーサネットでは、VLAN TAGで伝送される3ビットが優先順位情報を識別します。優先順位の設定はオプションです。最上位ビットがゼロに設定されている場合、後続の3つの優先度ビットは無視され、イーサネットCCMフレームの優先度ビットは、イーサネットノードで指定されたデフォルト値に基づいて設定されます。最上位ビットが1に設定されている場合、後続の3ビットはイーサネットCCMフレームの優先ビットを設定するために使用されます。
CCM I (CCM Interval): MUST be set according to the 3-bit encoding [IEEE.802.1Q-2011] shown in Table 1. As a consequence, the most significant bit will be set to 0. Four bits are allocated to support the configuration of CCM Intervals that may be specified in the future. If a node does not support the requested CCM Interval, an error MUST be generated: "OAM Problem/Unsupported CC Interval".
CCM I（CCM間隔）：表1に示す3ビットエンコーディング[IEEE.802.1Q-2011]に従って設定する必要があります。その結果、最上位ビットは0に設定されます。サポートするために4ビットが割り当てられます。将来指定される可能性のあるCCM間隔の構成。ノードが要求されたCCM間隔をサポートしない場合、エラーを生成しなければなりません：「OAM問題/サポートされていないCC間隔」。
Ethernet OAM functions for Performance Monitoring (PM) allow measurements of different performance parameters including Frame Loss Ratio, Frame Delay, and Frame Delay Variation as defined in [ITU-T.G.8013-2013]. Only a subset of PM functions are operated in a proactive fashion to monitor the performance of the connection continuously. Proactive PM supports Fault Management functions by providing an indication of decreased service performance and therefore may provide triggers to initiate recovery procedures.
パフォーマンスモニタリング（PM）のイーサネットOAM機能により、[ITU-T.G.8013-2013]で定義されているフレーム損失率、フレーム遅延、フレーム遅延変動などのさまざまなパフォーマンスパラメーターを測定できます。接続のパフォーマンスを継続的に監視するため、予防的方法でPM機能のサブセットのみが操作されます。プロアクティブPMは、サービスパフォーマンスの低下を示すことで障害管理機能をサポートしているため、回復手順を開始するトリガーを提供できます。
While on-demand PM functions are, for the purposes of this document, always initiated by management commands, for proactive PM, it may be desirable to utilize the control plane for configuration and activation together with Fault Management functions such as the Continuity Check.
このドキュメントでは、オンデマンドPM機能は常に管理コマンドによって開始されますが、予防型PMの場合は、構成チェックとアクティブ化にコントロールプレーンを使用して、継続性チェックなどの障害管理機能と併用することが望ましい場合があります。
[ITU-T.G.8013-2013] defines dual-ended Loss Measurement as proactive OAM for Performance Monitoring and as a PM function applicable to Fault Management. For dual-ended Loss Measurement, each MEP piggybacks transmitted and received frame counters on CC messages to support and synchronize bidirectional Loss Measurements at the MEPs. Dual-ended Loss Measurement is supported by setting the Performance Monitoring/Loss OAM Function Flag and the Continuity Check Flag in the OAM Function Flags Sub-TLV [RFC7260] and configuring the Continuity Check functionality by including the Ethernet OAM Configuration Sub-TLV. No additional configuration is required for this type of Loss Measurement.
[ITU-T.G.8013-2013]は、デュアルエンド損失測定をパフォーマンスモニタリング用のプロアクティブOAMとして、および障害管理に適用可能なPM機能として定義しています。デュアルエンド損失測定の場合、各MEPはCCメッセージでフレームカウンターを送受信し、MEPでの双方向損失測定をサポートおよび同期します。デュアルエンド損失測定は、OAM機能フラグサブTLV [RFC7260]でパフォーマンスモニタリング/損失OAM機能フラグと連続性チェックフラグを設定し、イーサネットOAM構成サブTLVを含めることで連続性チェック機能を構成することでサポートされます。このタイプの損失測定では、追加の構成は必要ありません。
In addition to the error values specified in [RFC7260], this document defines the following values for the "OAM Problem" Error Code.
[RFC7260]で指定されているエラー値に加えて、このドキュメントでは、「OAM問題」エラーコードに対して次の値を定義しています。
o If a node does not support a specific CFM version, an error MUST be generated: "OAM Problem/Unsupported OAM Version".
o ノードが特定のCFMバージョンをサポートしていない場合は、「OAM問題/サポートされていないOAMバージョン」というエラーを生成する必要があります。
o If a node does not support a specific MD Level, an error MUST be generated: "OAM Problem/Unsupported MD Level".
o ノードが特定のMDレベルをサポートしていない場合は、「OAM問題/サポートされていないMDレベル」というエラーを生成する必要があります。
o If an undefined MD name format is specified, an error MUST be generated: "OAM Problem/Unknown MD Name Format".
o 未定義のMD名の形式が指定されている場合、エラーが生成される必要があります：「OAM問題/不明なMD名の形式」。
o If an undefined MA name format is specified, an error MUST be generated: "OAM Problem/Unknown MA Name Format".
o 未定義のMA名の形式が指定されている場合、「OAM問題/不明なMA名の形式」というエラーが生成される必要があります。
o The combined length of MD Name and Short MA Name must be less than or equal to 44 bytes. If this is violated, an error MUST be generated: "OAM Problem/Name Length Problem".
o MD名とショートMA名を組み合わせた長さは、44バイト以下でなければなりません。これに違反した場合は、「OAMの問題/名前の長さの問題」というエラーを生成する必要があります。
o If a node does not support the requested CCM Interval, an error MUST be generated: "OAM Problem/Unsupported CC Interval".
o ノードが要求されたCCM間隔をサポートしない場合、エラーを生成しなければなりません：「OAM問題/サポートされていないCC間隔」。
IANA maintains the "RSVP-TE OAM Configuration Registry". IANA has assigned an "OAM Type" from this registry as follows:
IANAは「RSVP-TE OAM構成レジストリ」を維持しています。 IANAは、このレジストリから次のように「OAMタイプ」を割り当てました。
o "Ethernet OAM" has been allocated type 1 from the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry".
o 「イーサネットOAM」には、「RSVP-TE OAM構成レジストリ」の「OAMタイプ」サブレジストリからタイプ1が割り当てられています。
o "Ethernet OAM Configuration Sub-TLV" has been allocated type 32 from the technology-specific range of the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry".
o 「イーサネットOAM構成サブTLV」には、「RSVP-TE OAM構成レジストリ」の「OAMサブTLV」サブレジストリのテクノロジー固有の範囲からタイプ32が割り当てられています。
RSVP-TE OAM Configuration Registry
RSVP-TE OAM構成レジストリ
OAM Types
OAMタイプ
OAM Type Number | Description | Reference
-------------------------------------------
1 | Ethernet OAM | [RFC7369]
OAM Sub-TLVs
OAMサブTLV
Sub-TLV Type | Description | Ref.
-----------------------------------------------------------
32 |Ethernet OAM Configuration Sub-TLV| [RFC7369]
IANA will maintain an "Ethernet Sub-TLVs Sub-Registry" in the "RSVP-TE OAM Configuration Registry" for the sub-TLV types carried in the Ethernet OAM Configuration Sub-TLV. This document defines the following types.
IANAは、イーサネットOAM構成サブTLVで伝送されるサブTLVタイプの「RSVP-TE OAM構成レジストリ」に「イーサネットサブTLVサブレジストリ」を維持します。このドキュメントでは、次のタイプを定義しています。
Ethernet Sub-TLVs Sub-Registry
イーサネットサブTLVサブレジストリ
Range | Registration Procedures
------------+--------------------------
0-65534 | IETF Review
65535 | Experimental
Sub-TLV Type | Description | Ref.
---------------------------------------------------------
0 | Reserved | [RFC7369]
1 | MD Name Sub-TLV | [RFC7369]
2 | Short MA Name Sub-TLV | [RFC7369]
3 | MEP ID Sub-TLV | [RFC7369]
4 | Continuity Check Sub-TLV | [RFC7369]
5-65534 | Unassigned | [RFC7369]
65535 | Reserved for Experimental Use | [RFC7369]
IANA maintains an Error Code, "OAM Problem", in the "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry of the "Resource Reservation Protocol (RSVP) Parameters" registry. [RFC7260] defines a set of Error Value sub-codes for the "OAM Problem" Error Code. This document defines additional Error Value sub-codes for the "OAM Problem" Error Code as summarized below.
IANAは、「Resource Reservation Protocol（RSVP）Parameters」レジストリの「Error Codes and Globally-Defined Error Value Sub-Codes」サブレジストリに「OAM Problem」というエラーコードを保持しています。 [RFC7260]は、「OAM問題」エラーコードのエラー値サブコードのセットを定義します。このドキュメントでは、以下に要約する「OAM問題」エラーコードの追加のエラー値サブコードを定義します。
Value | Description | Reference
-------+---------------------------+-----------
7 | Unsupported OAM Version | [RFC7369]
8 | Unsupported MD Level | [RFC7369]
9 | Unknown MD Name Format | [RFC7369]
10 | Unknown MA Name Format | [RFC7369]
11 | Name Length Problem | [RFC7369]
12 | Unsupported CC Interval | [RFC7369]
This document does not introduce any additional security issues to those discussed in [RFC7260] and [RFC6060].
このドキュメントは、[RFC7260]と[RFC6060]で議論されたものに追加のセキュリティ問題を紹介しません。
The signaling of OAM-related parameters and the automatic establishment of OAM entities based on RSVP-TE messages add a new aspect to the security considerations discussed in [RFC3473]. In particular, a network element could be overloaded if a remote attacker targeted that element by sending frequent periodic messages requesting liveliness monitoring of a high number of LSPs. Such an attack can efficiently be prevented when mechanisms for message integrity and node authentication are deployed. Since the OAM configuration extensions rely on the hop-by-hop exchange of exiting RSVP-TE messages, procedures specified for RSVP message security in [RFC2747] can be used to mitigate possible attacks.
OAM関連パラメータのシグナリングとRSVP-TEメッセージに基づくOAMエンティティの自動確立は、[RFC3473]で説明されているセキュリティの考慮事項に新しい側面を追加します。特に、リモートの攻撃者が頻繁に定期的なメッセージを送信して大量のLSPの監視を要求することにより、ネットワーク要素を標的とすると、ネットワーク要素が過負荷になる可能性があります。このような攻撃は、メッセージの整合性とノード認証のメカニズムが導入されている場合に効率的に防止できます。 OAM構成拡張は、既存のRSVP-TEメッセージのホップバイホップ交換に依存しているため、[RFC2747]のRSVPメッセージセキュリティに指定された手順を使用して、起こり得る攻撃を緩和できます。
For a more comprehensive discussion of GMPLS security and attack mitigation techniques, please see "Security Framework for MPLS and GMPLS Networks" [RFC5920].
GMPLSのセキュリティおよび攻撃軽減技術のより包括的な説明については、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」[RFC5920]を参照してください。
[IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks--Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[IEEE.802.1Q-2011] IEEE、「IEEE Standard for Local and Metropolitan Area Network--Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE Std 802.1Q、2011。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC6060] Fedyk, D., Shah, H., Bitar, N., and A. Takacs, "Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE)", RFC 6060, March 2011, <http://www.rfc-editor.org/info/rfc6060>.
[RFC6060] Fedyk、D.、Shah、H.、Bitar、N。、およびA. Takacs、「イーサネットプロバイダーのバックボーントラフィックエンジニアリング（PBB-TE）の汎用マルチプロトコルラベルスイッチング（GMPLS）制御」、RFC 6060、2011年3月、<http://www.rfc-editor.org/info/rfc6060>。
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", RFC 7260, June 2014, <http://www.rfc-editor.org/info/rfc7260>.
[RFC7260] Takacs、A.、Fedyk、D。、およびJ. He、「運用、管理、および保守（OAM）構成のためのGMPLS RSVP-TE拡張機能」、RFC 7260、2014年6月、<http：// www。 rfc-editor.org/info/rfc7260>。
[ITU-T.G.8013-2013] International Telecommunications Union, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, November 2011.
[ITU-T.G.8013-2013]国際電気通信連合、「イーサネットベースのネットワークのOAM機能とメカニズム」、ITU-T勧告G.8013 / Y.1731、2011年11月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000, <http://www.rfc-editor.org/info/rfc2747>.
[RFC2747]ベイカー、F。、リンデル、B。、およびM.タルワー、「RSVP暗号化認証」、RFC 2747、2000年1月、<http://www.rfc-editor.org/info/rfc2747>。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、2003年1月、<http：//www.rfc-editor。 org / info / rfc3473>。
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010, <http://www.rfc-editor.org/info/rfc5828>.
[RFC5828] Fedyk、D.、Berger、L。、およびL. Andersson、「Generalized Multiprotocol Label Switching（GMPLS）Ethernet Label Switching Architecture and Framework」、RFC 5828、2010年3月、<http：//www.rfc-editor .org / info / rfc5828>。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月、<http://www.rfc-editor.org/info/rfc5920>。
Acknowledgements
謝辞
The authors would like to thank Francesco Fondelli, Adrian Farrel, Loa Andersson, Eric Gray, and Dimitri Papadimitriou for their useful comments.
著者は、有用なコメントを提供してくれたFrancesco Fondelli、Adrian Farrel、Loa Andersson、Eric Grey、およびDimitri Papadimitriouに感謝します。
Contributors
貢献者
Don Fedyk EMail: don.fedyk@hp.com
Don Fedyk Eメール：don.fedyk@hp.com
Dinesh Mohan EMail: dinmohan@hotmail.com
Dinesh Mohan Eメール：dinmohan@hotmail.com
Authors' Addresses
著者のアドレス
Attila Takacs Ericsson Konyves Kalman krt. 11. Budapest 1097 Hungary
Attila Takacs Ericsson Konyves Kalman krt。 11.ブダペスト1097ハンガリー
EMail: attila.takacs@ericsson.com
Balazs Peter Gero Ericsson Konyves Kalman krt. 11. Budapest 1097 Hungary
Balazs Peter Gero Ericsson Konyves Kalman krt。 11.ブダペスト1097ハンガリー
EMail: balazs.peter.gero@ericsson.com
Hao Long Huawei China
H AO long hu Aは中国です
EMail: lonho@huawei.com