[要約] RFC 7260は、GMPLS RSVP-TE拡張を使用してOAM構成を行うためのガイドラインです。このRFCの目的は、ネットワークの運用、管理、および保守のためのOAM機能を提供するための手法を提供することです。
Internet Engineering Task Force (IETF) A. Takacs
Request for Comments: 7260 Ericsson
Category: Standards Track D. Fedyk
ISSN: 2070-1721 Hewlett-Packard Company
J. He
Huawei
June 2014
GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration
GMPLS RSVP-TE Extensions for Operations、Administration、and Maintenance（OAM）Configuration
Abstract
概要
Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with Label Switched Path signaling.
運用、管理、および保守（OAM）は、トランスポート接続の不可欠な部分です。したがって、偽のアラームを回避して一貫した動作を保証するために、接続のコミッショニング/デコミッショニングと同期してOAM機能をアクティブ化/非アクティブ化する必要があります。特定のテクノロジーでは、接続がセットアップされるとOAMエンティティーが本質的に確立されますが、他のテクノロジーでは、OAMエンティティーを確立および構成するために追加の構成が必要です。このドキュメントでは、リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）の拡張を規定して、ラベルスイッチドパスシグナリングとともに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/rfc7260.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7260で入手できます。
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. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Technology-Specific OAM Requirements ............................4
3. RSVP-TE-Based OAM Configuration .................................6
3.1. Establishment of OAM Entities and Functions ................8
3.2. Adjustment of OAM Parameters ..............................10
3.3. Deleting OAM Entities .....................................11
4. RSVP-TE Extensions .............................................11
4.1. LSP Attribute Flags .......................................11
4.2. OAM Configuration TLV .....................................13
4.2.1. OAM Function Flags Sub-TLV .........................14
4.2.2. Technology-Specific Sub-TLVs .......................15
4.3. Administrative Status Information .........................15
4.4. Handling OAM Configuration Errors .........................16
4.5. Considerations on Point-to-Multipoint OAM Configuration ...16
5. IANA Considerations ............................................18
5.1. Admin_Status Object Bit Flags .............................18
5.2. LSP Attribute Flags .......................................18
5.3. New LSP Attributes ........................................19
5.4. RSVP Error Code ...........................................19
5.5. RSVP-TE OAM Configuration Registry ........................20
5.5.1. OAM Types Sub-Registry .............................20
5.5.2. OAM Sub-TLVs Sub-Registry ..........................20
5.5.3. OAM Function Flags Sub-Registry ....................21
6. Security Considerations ........................................21
7. Acknowledgements ...............................................21
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................22
GMPLS is designed as an out-of-band control plane supporting dynamic connection provisioning for any suitable data-plane technology, including spatial switching (e.g., incoming port or fiber to outgoing port or fiber); wavelength-division multiplexing (e.g., Dense Wavelength Division Multiplexing (DWDM)); time-division multiplexing (e.g., Synchronous Optical Networking and Synchronous Digital Hierarchy (SONET/SDH), G.709); and Ethernet Provider Backbone Bridging - Traffic Engineering (PBB-TE) and MPLS. In most of these technologies, there are Operations, Administration, and Maintenance (OAM) functions employed to monitor the health and performance of the connections and to trigger data plane (DP) recovery mechanisms. Similar to connection provisioning, OAM functions follow general principles but also have some technology-specific characteristics.
GMPLSは、空間スイッチング（例：着信ポートまたはファイバーから発信ポートまたはファイバー）を含む、適切なデータプレーンテクノロジーの動的接続プロビジョニングをサポートする帯域外コントロールプレーンとして設計されています。波長分割多重化（例：高密度波長分割多重化（DWDM））;時分割多重化（例：同期光ネットワークと同期デジタル階層（SONET / SDH）、G.709）;およびイーサネットプロバイダーバックボーンブリッジング-トラフィックエンジニアリング（PBB-TE）およびMPLS。これらのテクノロジのほとんどには、接続の正常性とパフォーマンスを監視し、データプレーン（DP）回復メカニズムをトリガーするために使用される運用、管理、および保守（OAM）機能があります。接続プロビジョニングと同様に、OAM機能は一般的な原則に従いますが、テクノロジー固有の特性もいくつか備えています。
OAM is an integral part of transport connections. Therefore, it is required that OAM functions be activated/deactivated in sync with connection commissioning/decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. In some situations, the use of OAM functions, such as Fault Management (FM) and Performance Management (PM), may be optional (based on network management policies). Hence, the network operator must be able to choose which set of OAM functions to apply to specific connections and which parameters should be configured and activated. To achieve this objective, OAM entities and specific functions must be selectively configurable.
OAMはトランスポート接続の不可欠な部分です。したがって、偽のアラームを回避して一貫した動作を保証するために、接続のコミッショニング/デコミッショニングと同期してOAM機能をアクティブ化/非アクティブ化する必要があります。特定のテクノロジーでは、接続がセットアップされるとOAMエンティティーが本質的に確立されますが、他のテクノロジーでは、OAMエンティティーを確立および構成するために追加の構成が必要です。状況によっては、障害管理（FM）やパフォーマンス管理（PM）などのOAM機能の使用がオプションになる場合があります（ネットワーク管理ポリシーに基づく）。したがって、ネットワークオペレーターは、特定の接続に適用するOAM機能のセットと、構成およびアクティブ化するパラメーターを選択できる必要があります。この目的を達成するには、OAMエンティティと特定の機能を選択的に構成できる必要があります。
In general, it is required that the management-plane and control-plane connection establishment mechanisms be synchronized with OAM establishment and activation. In particular, if the GMPLS control plane is employed, it is desirable to bind OAM setup and configuration to connection establishment signaling to avoid two separate management/configuration steps (connection setup followed by OAM configuration), as these separate steps increase delay and processing time; more importantly, they may be prone to misconfiguration errors. Once OAM entities are set up and configured, proactive as well as on-demand OAM functions can be activated via the management plane. On the other hand, it should be possible to activate/deactivate proactive OAM functions via the GMPLS control plane as well. In some situations, it may be possible to use the GMPLS control plane to control on-demand OAM functions too.
一般に、管理プレーンとコントロールプレーンの接続確立メカニズムは、OAMの確立とアクティブ化と同期する必要があります。特に、GMPLSコントロールプレーンが採用されている場合、OAMセットアップと構成を接続確立シグナリングにバインドして、2つの個別の管理/構成ステップ（接続セットアップとそれに続くOAM構成）を回避することが望ましい;さらに重要なのは、構成エラーが発生しやすいことです。 OAMエンティティをセットアップして構成すると、プロアクティブおよびオンデマンドのOAM機能を管理プレーン経由でアクティブ化できます。一方、GMPLSコントロールプレーンを介してプロアクティブOAM機能をアクティブ/非アクティブにすることもできるはずです。状況によっては、GMPLSコントロールプレーンを使用してオンデマンドOAM機能を制御することもできます。
This document describes requirements for OAM configuration and control via Resource Reservation Protocol - Traffic Engineering (RSVP-TE). Extensions to the RSVP-TE protocol are specified, providing a framework to configure and control OAM entities along with the capability to carry technology-specific information. Extensions can be grouped into generic elements that are applicable to any OAM solution and technology-specific elements that provide additional configuration parameters that may only be needed for a specific OAM technology. This document specifies the technology-agnostic elements and specifies the way that additional technology-specific OAM parameters are provided. This document addresses end-to-end OAM configuration, that is, the setup of OAM entities bound to an end-to-end Label Switched Path (LSP), and configuration and control of OAM functions running end-to-end in the LSP. Configuration of OAM entities for LSP segments and tandem connections is outside the scope of this document.
このドキュメントでは、リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）によるOAM構成と制御の要件について説明します。 RSVP-TEプロトコルの拡張が指定されており、OAMエンティティを構成および制御するためのフレームワークと、テクノロジー固有の情報を伝達する機能を提供します。拡張機能は、任意のOAMソリューションに適用可能な一般的な要素と、特定のOAMテクノロジでのみ必要になる可能性がある追加の構成パラメーターを提供するテクノロジ固有の要素にグループ化できます。このドキュメントでは、技術にとらわれない要素を指定し、追加の技術固有のOAMパラメータが提供される方法を指定します。このドキュメントでは、エンドツーエンドのOAM構成、つまり、エンドツーエンドのラベルスイッチドパス（LSP）にバインドされたOAMエンティティのセットアップ、およびLSPでエンドツーエンドで実行されているOAM機能の構成と制御について説明します。 LSPセグメントおよびタンデム接続のOAMエンティティの設定は、このドキュメントの範囲外です。
The mechanisms described in this document provide an additional option for bootstrapping OAM that is not intended to replace or deprecate the use of other technology-specific OAM bootstrapping techniques, e.g., LSP ping [RFC4379] for MPLS networks. The procedures specified in this document are intended only for use in environments where RSVP-TE signaling is used to set up the LSPs that are to be monitored using OAM.
このドキュメントで説明されているメカニズムは、OAMをブートストラップするための追加オプションを提供します。これは、MPLSネットワーク用のLSP ping [RFC4379]など、他のテクノロジー固有のOAMブートストラップ技術の使用を置き換えることや非推奨にすることを意図していません。このドキュメントで指定されている手順は、RSAM-TEシグナリングを使用して、OAMを使用して監視されるLSPをセットアップする環境での使用のみを目的としています。
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]で説明されているように解釈されます。
This section summarizes various technology-specific OAM requirements that can be used as a basis for an OAM configuration framework.
このセクションでは、OAM構成フレームワークの基礎として使用できる、さまざまなテクノロジー固有のOAM要件をまとめています。
MPLS OAM requirements are described in [RFC4377], which provides requirements to create consistent OAM functionality for MPLS networks. The following list is an excerpt of MPLS OAM requirements documented in [RFC4377] that bear direct relevance to the discussion set forth in this document:
MPLS OAM要件は[RFC4377]で説明されており、MPLSネットワークに一貫したOAM機能を作成するための要件を提供します。次のリストは、[RFC4377]で文書化されているMPLS OAM要件の抜粋であり、このドキュメントで説明されている議論に直接関連しています。
o It is desired that the automation of LSP defect detection be supported. It is especially important in cases where large numbers of LSPs might be tested.
o LSP欠陥検出の自動化がサポートされることが望まれます。これは、多数のLSPがテストされる可能性がある場合に特に重要です。
o In particular, some LSPs may require automated testing functionality from the ingress LSR (Label Switching Router) to the egress LSR, while others may not.
o 特に、一部のLSPには、入力LSR（ラベルスイッチングルーター）から出力LSRへの自動テスト機能が必要な場合と、そうでない場合があります。
o Mechanisms are required to coordinate network responses to defects. Such mechanisms may include alarm suppression, translating defect signals at technology boundaries, and synchronizing defect detection times by setting appropriately bounded detection time frames.
o 欠陥に対するネットワーク応答を調整するメカニズムが必要です。このようなメカニズムには、アラームの抑制、技術境界での欠陥信号の変換、適切に制限された検出時間フレームの設定による欠陥検出時間の同期などがあります。
The MPLS Transport Profile (MPLS-TP) defines a profile of MPLS targeted at transport applications [RFC5921]. This profile specifies the specific MPLS characteristics and extensions required to meet transport requirements, including providing additional OAM, survivability, and other maintenance functions not currently supported by MPLS. Specific OAM requirements for MPLS-TP are specified in [RFC5654] and [RFC5860]. MPLS-TP poses the following requirements on the control plane to configure and control OAM entities:
MPLSトランスポートプロファイル（MPLS-TP）は、トランスポートアプリケーションを対象としたMPLSのプロファイルを定義します[RFC5921]。このプロファイルは、追加のOAM、存続可能性、および現在MPLSでサポートされていないその他のメンテナンス機能の提供など、トランスポート要件を満たすために必要な特定のMPLS特性と拡張を指定します。 MPLS-TPの特定のOAM要件は、[RFC5654]および[RFC5860]で指定されています。 MPLS-TPは、OAMエンティティを構成および制御するために、コントロールプレーンに次の要件を課します。
o From [RFC5860]: OAM functions MUST operate and be configurable even in the absence of a control plane. Conversely, it SHOULD be possible to configure as well as enable/disable the capability to operate OAM functions as part of connectivity management, and it SHOULD also be possible to configure as well as enable/disable the capability to operate OAM functions after connectivity has been established.
o [RFC5860]から：OAM機能は、コントロールプレーンがない場合でも動作し、構成可能でなければなりません。逆に、接続管理の一部としてOAM機能を操作する機能を構成および有効/無効にすることが可能であるべきであり、接続が行われた後にOAM機能を操作する機能を構成および有効/無効にすることも可能であるべきです（SHOULD）。設立。
o From [RFC5654]: The MPLS-TP control plane MUST support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM when the transport path or transport service is established or modified.
o [RFC5654]から：MPLS-TPコントロールプレーンは、トランスポートパスまたはトランスポートサービスが確立または変更されたときのOAMメンテナンスポイントの構成と変更、およびOAMのアクティブ化/非アクティブ化をサポートする必要があります。
Ethernet Connectivity Fault Management (CFM) defines an adjunct OAM flow that monitors connectivity in order to check the liveliness of Ethernet networks [IEEE.802.1Q-2011]. With PBB-TE [IEEE.802.1Q-2011], Ethernet networks support explicitly routed Ethernet connections. CFM can be used to track the liveliness of PBB-TE connections and detect data-plane failures. In the IETF, the GMPLS Ethernet Label Switching (GELS) (see [RFC5828] and [RFC6060]) work extended the GMPLS control plane to support the establishment of PBB-TE data-plane connections. Without control-plane support, separate management commands would be needed to configure and start CFM.
イーサネット接続障害管理（CFM）は、イーサネットネットワークの稼働状況をチェックするために接続を監視する付属OAMフローを定義します[IEEE.802.1Q-2011]。 PBB-TE [IEEE.802.1Q-2011]により、イーサネットネットワークは明示的にルーティングされたイーサネット接続をサポートします。 CFMは、PBB-TE接続の活性を追跡し、データプレーンの障害を検出するために使用できます。 IETFでは、GMPLSイーサネットラベルスイッチング（GELS）（[RFC5828]および[RFC6060]を参照）が機能してGMPLSコントロールプレーンが拡張され、PBB-TEデータプレーン接続の確立がサポートされました。コントロールプレーンサポートがない場合、CFMを設定して開始するには、個別の管理コマンドが必要になります。
GMPLS-based OAM configuration and control need to provide a general framework to be applicable to a wide range of data-plane technologies and OAM solutions. There are three typical data-plane technologies used for transport applications: wavelength based, such as Wavelength Switched Optical Networks (WSON); Time-Division Multiplexing (TDM) based, such as Synchronous Digital Hierarchy (SDH) and Synchronous Optical Networking (SONET); and packet based, such as MPLS-TP [RFC5921] and Ethernet PBB-TE [IEEE.802.1Q-2011]. For all these data planes, the operator MUST be able to configure and control the following OAM functions:
GMPLSベースのOAM構成と制御は、広範なデータプレーンテクノロジーとOAMソリューションに適用できる一般的なフレームワークを提供する必要があります。トランスポートアプリケーションに使用される典型的なデータプレーンテクノロジーは3つあります。波長スイッチド光ネットワーク（WSON）などの波長ベース。同期デジタル階層（SDH）や同期光ネットワーク（SONET）などの時分割多重（TDM）ベース。 MPLS-TP [RFC5921]やイーサネットPBB-TE [IEEE.802.1Q-2011]などのパケットベース。これらすべてのデータプレーンについて、オペレーターは次のOAM機能を構成および制御できる必要があります。
o It MUST be possible to explicitly request the setup of OAM entities for the signaled LSP and provide specific information for the setup if this is required by the technology.
o シグナリングされたLSPのOAMエンティティのセットアップを明示的に要求し、テクノロジーで必要な場合は、セットアップの特定の情報を提供できる必要があります。
o Control of alarms is important to avoid false alarm indications and reporting to the management system. It MUST be possible to enable/disable alarms generated by OAM functions. In some cases, selective alarm control may be desirable when, for instance, the operator is only concerned about critical alarms. Therefore, alarms that do not affect service should be inhibited.
o アラームの制御は、誤ったアラーム表示や管理システムへの報告を回避するために重要です。 OAM機能によって生成されたアラームを有効/無効にできる必要があります。場合によっては、たとえば、オペレーターが重大なアラームのみを懸念している場合に、選択的なアラーム制御が望ましい場合があります。したがって、サービスに影響を与えないアラームは禁止する必要があります。
o When periodic messages are used for liveliness checks (Continuity Checks (CCs)) of LSPs, it MUST be possible to set the frequency of messages. This allows proper configuration for fulfilling the requirements of the service and/or meeting the detection time boundaries posed by possible congruent connectivity-check operations of higher-layer applications. For a network operator to be able to balance the trade-off between fast failure detection and data overhead, it is beneficial to configure the frequency of CC messages on a per-LSP basis.
o LSPの活性チェック（継続性チェック（CC））に定期的なメッセージが使用される場合、メッセージの頻度を設定できる必要があります。これにより、サービスの要件を満たすための適切な構成や、上位層アプリケーションの一致する可能性のある接続チェック操作によって生じる検出時間の境界を満たすことができます。ネットワークオペレータが高速障害検出とデータオーバーヘッドの間のトレードオフのバランスを取ることができるようにするには、LSPごとにCCメッセージの頻度を設定することが有益です。
o Proactive Performance Monitoring (PM) functions are used to continuously collect information about specific characteristics of the connection. For consistent measurement of Service Level Agreements (SLAs), it MUST be possible to set common configuration parameters for the LSP.
o プロアクティブパフォーマンスモニタリング（PM）機能は、接続の特定の特性に関する情報を継続的に収集するために使用されます。サービスレベルアグリーメント（SLA）の一貫した測定のために、LSPに共通の構成パラメーターを設定することが可能でなければなりません（MUST）。
o The extensions MUST allow the operator to use only a minimal set of OAM configuration and control features if supported by the OAM solution or network management policy. Generic OAM parameters, as well as parameters specific to data-plane technology or OAM technology, MUST be supported.
o 拡張機能は、OAMソリューションまたはネットワーク管理ポリシーでサポートされている場合、オペレーターがOAM構成および制御機能の最小セットのみを使用できるようにする必要があります。汎用OAMパラメーター、およびデータプレーンテクノロジーまたはOAMテクノロジーに固有のパラメーターをサポートする必要があります。
In general, two types of maintenance points can be distinguished: Maintenance Entity Group End Points (MEPs) and Maintenance Entity Group Intermediate Points (MIPs). MEPs reside at the ends of an LSP and are capable of initiating and terminating OAM messages for Fault Management (FM) and Performance Monitoring (PM). MIPs, on the other hand, are located at transit nodes of an LSP and are capable of reacting to some OAM messages but otherwise do not initiate messages. "Maintenance Entity" (ME) refers to an association of MEPs and MIPs that are provisioned to monitor an LSP.
一般に、2つのタイプのメンテナンスポイントを区別できます。メンテナンスエンティティグループのエンドポイント（MEP）とメンテナンスエンティティグループの中間ポイント（MIP）です。 MEPはLSPの両端にあり、障害管理（FM）およびパフォーマンスモニタリング（PM）のOAMメッセージを開始および終了できます。一方、MIPはLSPのトランジットノードにあり、一部のOAMメッセージに対応できますが、それ以外の場合はメッセージを開始しません。 「Maintenance Entity」（ME）は、LSPを監視するためにプロビジョニングされたMEPとMIPの関連付けを指します。
When an LSP is signaled, a forwarding association is established between endpoints and transit nodes via label bindings. This association creates a context for the OAM entities monitoring the LSP. On top of this association, OAM entities may be configured to unambiguously identify MEs.
LSPが通知されると、ラベルバインディングを介してエンドポイントと中継ノードの間に転送関連付けが確立されます。この関連付けにより、LSPを監視するOAMエンティティのコンテキストが作成されます。この関連付けに加えて、OAMエンティティはMEを明確に識別するように構成できます。
In addition to ME identification parameters, proactive OAM functions (e.g., CC and PM) may have additional parameters that require configuration as well. In particular, the frequency of periodic CC packets, and the measurement interval for loss and delay measurements, may need to be configured.
ME識別パラメーターに加えて、プロアクティブOAM機能（CCやPMなど）には、構成を必要とする追加のパラメーターがある場合があります。特に、定期的なCCパケットの頻度、および損失と遅延の測定の測定間隔を構成する必要がある場合があります。
The above parameters may be derived from information related to LSP provisioning; alternatively, pre-configured default values can be used. In the simplest case, the control plane MAY provide information on whether or not OAM entities need to be set up for the signaled LSP. If OAM entities are created, control-plane signaling MUST also provide a means to activate/deactivate OAM message flows and associated alarms.
上記のパラメータは、LSPプロビジョニングに関連する情報から取得できます。または、事前設定されたデフォルト値を使用できます。最も単純なケースでは、コントロールプレーンは、シグナリングされたLSPに対してOAMエンティティをセットアップする必要があるかどうかに関する情報を提供する場合があります。 OAMエンティティが作成される場合、コントロールプレーンシグナリングは、OAMメッセージフローおよび関連するアラームをアクティブ化/非アクティブ化する手段も提供する必要があります。
OAM identifiers, as well as the configuration of OAM functions, are technology specific (i.e., they vary, depending on the data-plane technology and the chosen OAM solution). In addition, for any given data-plane technology, a set of OAM solutions may be applicable. Therefore, the OAM configuration framework allows selecting a specific OAM solution to be used for the signaled LSP and provides means to carry detailed OAM configuration information in technology-specific TLVs.
OAM識別子とOAM機能の構成はテクノロジー固有です（つまり、データプレーンテクノロジーと選択したOAMソリューションに応じて異なります）。さらに、特定のデータプレーンテクノロジに対して、一連のOAMソリューションが適用できる場合があります。したがって、OAM設定フレームワークでは、シグナリングされたLSPに使用される特定のOAMソリューションを選択でき、テクノロジー固有のTLVで詳細なOAM設定情報を伝達する手段を提供します。
Administrative Status Information is carried in the Admin_Status object. Administrative Status Information is described in [RFC3471], and the Admin_Status object is specified for RSVP-TE in [RFC3473]. Two bits are allocated for the administrative control of OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled. When the "OAM Alarms Enabled" bit is set, OAM-triggered alarms are enabled and associated consequent actions MUST be executed, including the notification to the management system. When this bit is cleared, alarms are suppressed and no action SHOULD be executed, and the management system SHOULD NOT be notified.
管理ステータス情報は、Admin_Statusオブジェクトで伝達されます。管理ステータス情報は[RFC3471]で説明されており、Admin_Statusオブジェクトは[RFC3473]でRSVP-TEに指定されています。 OAM監視の管理制御用に、「OAMフロー有効」（M）および「OAMアラーム有効」（O）ビットの2ビットが割り当てられています。 「OAM Flows Enabled」ビットが設定されている場合、OAMメカニズムを有効にする必要があります。クリアされている場合は、OAMメカニズムを無効にする必要があります。 「OAMアラーム有効」ビットが設定されている場合、OAMトリガーアラームが有効になり、管理システムへの通知を含め、関連する後続のアクションを実行する必要があります。このビットがクリアされると、アラームは抑制され、アクションは実行されるべきではなく（SHOULD）、管理システムは通知されるべきではありません（SHOULD NOT）。
The LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to provide means to signal LSP attributes and options in the form of TLVs. Options and attributes signaled in the LSP_ATTRIBUTES object can be passed transparently through LSRs not supporting a particular option or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by each LSR. The "OAM MEP entities desired" bit is allocated in the Attribute Flags TLV [RFC5420] to be used in the LSP_ATTRIBUTES object. If the "OAM MEP entities desired" bit is set, it indicates that the establishment of OAM MEP entities is required at the endpoints of the signaled LSP. The "OAM MIP entities desired" bit is allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects. If the "OAM MIP entities desired" bit is set in the Attribute Flags TLV in the LSP_REQUIRED_ATTRIBUTES object, it indicates that the establishment of OAM MIP entities is required at every transit node of the signaled LSP.
LSP_ATTRIBUTESおよびLSP_REQUIRED_ATTRIBUTESオブジェクトは、[RFC5420]で定義されており、TLVの形式でLSP属性とオプションを通知する手段を提供します。 LSP_ATQUIBUTESオブジェクトで通知されたオプションと属性は、特定のオプションまたは属性をサポートしないLSRを透過的に渡すことができますが、LSP_REQUIRED_ATTRIBUTESオブジェクトの内容は、各LSRで検査および処理する必要があります。 「必要なOAM MEPエンティティ」ビットは、LSP_ATTRIBUTESオブジェクトで使用される属性フラグTLV [RFC5420]に割り当てられます。 「必要なOAM MEPエンティティ」ビットが設定されている場合は、シグナリングされたLSPのエンドポイントでOAM MEPエンティティの確立が必要であることを示します。 「必要なOAM MIPエンティティ」ビットは、LSP_ATTRIBUTESまたはLSP_REQUIRED_ATTRIBUTESオブジェクトで使用される属性フラグTLVに割り当てられます。 「必要なOAM MIPエンティティ」ビットがLSP_REQUIRED_ATTRIBUTESオブジェクトの属性フラグTLVに設定されている場合、シグナリングされたLSPのすべてのトランジットノードでOAM MIPエンティティの確立が必要であることを示します。
In order to avoid spurious alarms, OAM functions should be set up and enabled in the appropriate order. When using the GMPLS control plane for both LSP establishment and enabling OAM functions on the LSPs, the control of both processes is bound to RSVP-TE message exchanges.
偽のアラームを回避するには、OAM機能を適切な順序でセットアップして有効にする必要があります。 LSPの確立とLSPでのOAM機能の有効化の両方にGMPLSコントロールプレーンを使用すると、両方のプロセスの制御がRSVP-TEメッセージ交換にバインドされます。
An LSP may be signaled and established without OAM configuration first, and OAM entities may be added later with a subsequent re-signaling of the LSP. Alternatively, the LSP may be set up with OAM entities with the first signaling of the LSP. The procedures below apply to both cases.
LSPは、最初にOAM設定なしでシグナリングおよび確立され、OAMエンティティが後で追加され、LSPの後続の再シグナリングが行われます。あるいは、LSPは、LSPの最初のシグナリングでOAMエンティティを使用して設定できます。以下の手順はどちらの場合にも適用されます。
Before initiating a Path message with OAM configuration information, an initiating node MUST establish and configure the corresponding OAM entities locally. But until the LSP is established, OAM source functions MUST NOT start sending any OAM messages. In the case of bidirectional connections, in addition to the OAM source function, the initiator node MUST set up the OAM sink function and prepare it to receive OAM messages. During this time the OAM alarms MUST be suppressed (e.g., due to missing or unidentified OAM messages). To achieve OAM alarm suppression, Path messages MUST be sent with the "OAM Alarms Enabled" Admin_Status flag cleared.
OAM構成情報を含むパスメッセージを開始する前に、開始ノードは対応するOAMエンティティをローカルで確立および構成する必要があります。ただし、LSPが確立されるまで、OAMソース関数はOAMメッセージの送信を開始してはなりません。双方向接続の場合、OAMソース機能に加えて、イニシエーターノードはOAMシンク機能をセットアップし、OAMメッセージを受信できるように準備する必要があります。この間、OAMアラームは抑制される必要があります（たとえば、OAMメッセージの欠落または識別されていないため）。 OAMアラーム抑制を実現するには、「OAMアラームを有効にする」Admin_Statusフラグをクリアした状態でパスメッセージを送信する必要があります。
When the Path message arrives at the receiver, the remote end MUST establish and configure OAM entities according to the OAM information provided in the Path message. If this is not possible, a PathErr message SHOULD be sent, and neither the OAM entities nor the LSP SHOULD be established. If OAM entities are established successfully, the OAM sink function MUST be prepared to receive OAM messages but MUST NOT generate any OAM alarms (e.g., due to missing or unidentified OAM messages). In the case of bidirectional connections, in addition to the OAM sink function, an OAM source function MUST be set up and, according to the requested configuration, the OAM source function MUST start sending OAM messages. A Resv message MUST then be sent back, including the Attribute Flags TLV, with the appropriate setting of the "OAM MEP entities desired" and "OAM MIP entities desired" flags, and the OAM Configuration TLV that corresponds to the established and configured OAM entities and functions. Depending on the OAM technology, some elements of the OAM Configuration TLV MAY be updated/changed, i.e., if the remote end does not support a certain OAM configuration it may suggest an alternative setting, which may or may not be accepted by the initiator of the Path message. If it is accepted, the initiator will reconfigure its OAM functions according to the information received in the Resv message. If the alternate setting is not acceptable, a ResvErr message MAY be sent, tearing down the LSP. Details of this operation are technology specific and should be described in accompanying technology-specific documents.
Pathメッセージが受信者に到着すると、リモートエンドは、Pathメッセージで提供されるOAM情報に従ってOAMエンティティを確立および構成する必要があります。これが不可能な場合は、PathErrメッセージを送信する必要があり（SHOULD）、OAMエンティティもLSPも確立してはなりません（SHOULD）。 OAMエンティティが正常に確立された場合、OAMシンク機能はOAMメッセージを受信できるように準備する必要がありますが、OAMアラームを生成してはなりません（たとえば、OAMメッセージの欠落または未確認のため）。双方向接続の場合、OAMシンク機能に加えて、OAMソース機能をセットアップする必要があり、要求された構成に従って、OAMソース機能はOAMメッセージの送信を開始する必要があります。次に、「OAM MEPエンティティが必要」および「OAM MIPエンティティが必要」のフラグの適切な設定と、確立および構成されたOAMエンティティに対応するOAM構成TLVとともに、属性フラグTLVを含むResvメッセージを返信する必要があります。と機能。 OAMテクノロジーに応じて、OAM構成TLVの一部の要素が更新/変更される場合があります。つまり、リモートエンドが特定のOAM構成をサポートしていない場合は、代替設定を提案する可能性があります。パスメッセージ。受け入れられた場合、イニシエーターは、Resvメッセージで受信した情報に従ってOAM機能を再構成します。代替設定が受け入れられない場合、ResvErrメッセージが送信され、LSPが破棄される場合があります。この操作の詳細はテクノロジー固有であり、付随するテクノロジー固有のドキュメントに記載する必要があります。
When the initiating side receives the Resv message, it completes any pending OAM configuration and enables the OAM source function to send OAM messages.
開始側はResvメッセージを受信すると、保留中のOAM構成を完了し、OAMソース機能がOAMメッセージを送信できるようにします。
After this exchange, OAM entities are established and configured for the LSP, and OAM messages are exchanged. OAM alarms can now be enabled. During the period when OAM alarms are disabled, the initiator sends a Path message with the "OAM Alarms Enabled" Admin_Status flag set. The receiving node enables OAM alarms after processing the Path message. The initiator enables OAM alarms after it receives the Resv message. Data-plane OAM is now fully functional.
この交換後、LSP用にOAMエンティティが確立および設定され、OAMメッセージが交換されます。 OAMアラームを有効にできるようになりました。 OAMアラームが無効になっている間、イニシエーターは「OAMアラームが有効」のAdmin_Statusフラグが設定されたパスメッセージを送信します。受信ノードは、Pathメッセージの処理後にOAMアラームを有効にします。イニシエータは、Resvメッセージを受信した後、OAMアラームを有効にします。データプレーンOAMが完全に機能するようになりました。
If an egress LSR does not support the extensions defined in this document, according to [RFC5420], it will silently ignore the new LSP attribute flags as well as the TLVs carrying additional OAM configuration information, and therefore no error will be raised that would notify the ingress LSR about the missing OAM configuration actions on the egress side. However, as described above, an egress LSR conformant to the specification of this document will set the LSP attribute flags and include the OAM Configuration TLV in the Resv message indicating the configuration of the OAM mechanisms; therefore, by detecting the missing information in the Resv message, an ingress LSR will be able to recognize that the remote end does not support the OAM configuration functionality, and therefore it SHOULD tear down the LSP and, if appropriate, signal the LSP without any OAM configuration information.
[RFC5420]によると、出力LSRがこのドキュメントで定義されている拡張機能をサポートしていない場合、追加のOAM構成情報を伝達するTLVだけでなく、新しいLSP属性フラグも暗黙的に無視するため、通知するエラーは発生しません出力側で欠落しているOAM構成アクションに関する入力LSR。ただし、上記のように、このドキュメントの仕様に準拠した出力LSRはLSP属性フラグを設定し、OAMメカニズムの構成を示すResvメッセージにOAM構成TLVを含めます。したがって、Resvメッセージで欠落している情報を検出することにより、入力LSRはリモートエンドがOAM設定機能をサポートしていないことを認識できるため、LSPを破棄し、必要に応じて、LSPにシグナルを送信する必要があります。 OAM構成情報。
There may be a need to change the parameters of an already-established and configured OAM function during the lifetime of the LSP. To do so, the LSP needs to be re-signaled with the updated parameters. OAM parameters influence the content and timing of OAM messages and also identify the way that OAM defects and alarms are derived and generated. Hence, to avoid spurious alarms, it is important that both sides -- OAM sink and source -- are updated in a synchronized way. First, the alarms of the OAM sink function should be suppressed and only then should expected OAM parameters be adjusted. Subsequently, the parameters of the OAM source function can be updated. Finally, the alarms of the OAM sink side can be enabled again.
LSPの存続期間中に、すでに確立および設定されているOAM機能のパラメータを変更する必要がある場合があります。そのためには、更新されたパラメーターを使用してLSPに再シグナリングする必要があります。 OAMパラメータは、OAMメッセージの内容とタイミングに影響を与え、OAM障害とアラームが生成および生成される方法も識別します。したがって、偽のアラームを回避するには、OAMシンクとソースの両方が同期して更新されることが重要です。まず、OAMシンク機能のアラームを抑制し、その後にのみ、OAMパラメータを調整する必要があります。その後、OAMソース機能のパラメーターを更新できます。最後に、OAMシンク側のアラームを再び有効にすることができます。
In accordance with the above operation, the LSP MUST first be re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared, including the updated OAM Configuration TLV corresponding to the new parameter settings. The initiator MUST keep its OAM sink and source functions running unmodified, but it MUST suppress OAM alarms after the updated Path message is sent. The receiver MUST first disable all OAM alarms and then update the OAM parameters according to the information in the Path message and reply with a Resv message acknowledging the changes by including the OAM Configuration TLV. Note that the receiving side can adjust the requested OAM configuration parameters and reply with an updated OAM Configuration TLV in the Resv message, reflecting the values that are actually configured. However, in order to avoid an extensive negotiation phase, in the case of adjusting already-configured OAM functions, the receiving side SHOULD NOT update the parameters requested in the Path message to an extent that would provide lower performance (e.g., lower frequency of monitoring packets) than what had previously been in place.
上記の操作に従って、LSPは、新しいパラメーター設定に対応する更新されたOAM構成TLVを含め、「OAMアラーム有効」Admin_Statusフラグをクリアして、最初に再シグナリングする必要があります。イニシエーターは、OAMシンクとソース機能を変更せずに実行し続ける必要がありますが、更新されたパスメッセージが送信された後は、OAMアラームを抑制しなければなりません（MUST）。受信者は最初にすべてのOAMアラームを無効にしてから、Pathメッセージの情報に従ってOAMパラメータを更新し、OAM構成TLVを含めることで変更を確認するResvメッセージで応答する必要があります。受信側は、要求されたOAM構成パラメーターを調整し、Resvメッセージ内の更新されたOAM構成TLVで応答して、実際に構成されている値を反映できることに注意してください。ただし、大規模なネゴシエーションフェーズを回避するために、構成済みのOAM機能を調整する場合、受信側は、Pathメッセージで要求されたパラメーターを、パフォーマンスが低下する程度に更新しないでください（たとえば、監視の頻度が低い）。パケット）以前に配置されていたものよりも。
The initiator MUST only update its OAM sink and source functions after it receives the Resv message. After this Path/Resv message exchange (in both unidirectional and bidirectional LSP cases), the OAM parameters are updated, and OAM is running according to the new parameter settings. However, OAM alarms are still disabled. A subsequent Path/Resv message exchange with the "OAM Alarms Enabled" Admin_Status flag set is needed to enable OAM alarms again.
イニシエーターは、Resvメッセージを受信した後にのみ、OAMシンクおよびソース機能を更新する必要があります。このPath / Resvメッセージ交換（単方向と双方向のLSPの両方の場合）の後、OAMパラメータが更新され、OAMは新しいパラメータ設定に従って実行されます。ただし、OAMアラームは引き続き無効です。 OAMアラームを再度有効にするには、「OAMアラームが有効」のAdmin_Statusフラグセットを使用した後続のPath / Resvメッセージ交換が必要です。
In some cases, it may be useful to remove some or all OAM entities and functions from an LSP without actually tearing down the connection.
場合によっては、実際に接続を切断せずに、LSPから一部またはすべてのOAMエンティティと機能を削除すると便利なことがあります。
To avoid any spurious alarms, first the LSP MUST be re-signaled with the "OAM Alarms Enabled" Admin_Status flag cleared but with OAM configuration unchanged. Subsequently, the LSP is re-signaled with "OAM MEP entities desired" and "OAM MIP entities desired" LSP attribute flags cleared, and without the OAM Configuration TLV, this MUST result in the deletion of all OAM entities associated with the LSP. All control-plane and data-plane resources in use by the OAM entities and functions SHOULD be freed up. Alternatively, if only some OAM functions need to be removed, the LSP is re-signaled with the updated OAM Configuration TLV. Changes between the contents of the previously signaled OAM Configuration TLV and the currently received TLV represent which functions MUST be removed/added.
スプリアスアラームを回避するには、最初に「OAMアラームを有効にする」Admin_StatusフラグをクリアしてLSPを再シグナリングする必要がありますが、OAM設定は変更されていません。その後、LSPは「OAM MEPエンティティが必要」および「OAM MIPエンティティが必要」のLSP属性フラグがクリアされた状態で再シグナリングされ、OAM構成TLVがない場合、LSPに関連付けられているすべてのOAMエンティティが削除される必要があります。 OAMエンティティと機能によって使用されているすべてのコントロールプレーンとデータプレーンのリソースを解放する必要があります。または、一部のOAM機能のみを削除する必要がある場合、LSPは更新されたOAM構成TLVで再シグナリングされます。以前に通知されたOAM構成TLVの内容と現在受信されているTLVの内容の間の変更は、削除または追加する必要がある機能を表します。
OAM source functions MUST be deleted first, and only after the "OAM Alarms Disabled" can the associated OAM sink functions be removed; this will ensure that OAM messages do not leak outside the LSP. To this end, the initiator, before sending the Path message, MUST remove the OAM source, hence terminating the OAM message flow associated to the downstream direction. In the case of a bidirectional connection, it MUST leave in place the OAM sink functions associated to the upstream direction. The remote end, after receiving the Path message, MUST remove all associated OAM entities and functions and reply with a Resv message without an OAM Configuration TLV. The initiator completely removes OAM entities and functions after the Resv message arrives.
OAMソース機能は最初に削除する必要があり、「OAMアラームが無効」になって初めて、関連するOAMシンク機能を削除できます。これにより、OAMメッセージがLSPの外に漏れないようになります。このため、イニシエーターは、Pathメッセージを送信する前に、OAMソースを削除する必要があるため、ダウンストリーム方向に関連付けられたOAMメッセージフローを終了する必要があります。双方向接続の場合、アップストリーム方向に関連付けられたOAMシンク機能をそのままにしておく必要があります。リモートエンドは、Pathメッセージを受信した後、関連するすべてのOAMエンティティと機能を削除し、OAM構成TLVなしのResvメッセージで応答する必要があります。イニシエータは、Resvメッセージが到着した後、OAMエンティティと機能を完全に削除します。
In RSVP-TE, the Flags field of the SESSION_ATTRIBUTE object is used to indicate options and attributes of the LSP. The Flags field has 8 bits and hence is limited to differentiate only 8 options. [RFC5420] defines new objects for RSVP-TE messages to allow the signaling of arbitrary attribute parameters, making RSVP-TE easily extensible to support new applications. Furthermore, [RFC5420] allows options and attributes that do not need to be acted on by all Label Switching Routers (LSRs) along the path of the LSP. In particular, these options and attributes may apply only to key LSRs on the path, such as the ingress LSR and egress LSR. Options and attributes can be signaled transparently and only examined at those points that need to act on them. The LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects are defined in [RFC5420] to provide means to signal LSP attributes and options in the form of TLVs. Options and attributes signaled in the LSP_ATTRIBUTES object can be passed transparently through LSRs not supporting a particular option or attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES object MUST be examined and processed by each LSR. One TLV is defined in [RFC5420]: the Attribute Flags TLV.
RSVP-TEでは、SESSION_ATTRIBUTEオブジェクトのFlagsフィールドを使用して、LSPのオプションと属性を示します。 Flagsフィールドは8ビットであるため、8つのオプションのみを区別するように制限されています。 [RFC5420]は、RSVP-TEメッセージの新しいオブジェクトを定義して、任意の属性パラメータのシグナリングを可能にし、RSVP-TEを簡単に拡張して新しいアプリケーションをサポートできるようにします。さらに、[RFC5420]は、LSPのパスに沿ったすべてのラベルスイッチングルーター（LSR）が作用する必要のないオプションと属性を許可します。特に、これらのオプションと属性は、入力LSRと出力LSRなど、パス上の主要なLSRにのみ適用できます。オプションと属性は透過的に通知され、それらに作用する必要があるポイントでのみ検査されます。 LSP_ATTRIBUTESおよびLSP_REQUIRED_ATTRIBUTESオブジェクトは、[RFC5420]で定義されており、TLVの形式でLSP属性とオプションを通知する手段を提供します。 LSP_ATQUIBUTESオブジェクトで通知されたオプションと属性は、特定のオプションまたは属性をサポートしないLSRを透過的に渡すことができますが、LSP_REQUIRED_ATTRIBUTESオブジェクトの内容は、各LSRで検査および処理する必要があります。 [RFC5420]で1つのTLVが定義されています：属性フラグTLV。
One bit (bit number 10): "OAM MEP entities desired" is allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES object. If the "OAM MEP entities desired" bit is set, it indicates that the establishment of OAM MEP entities is required at the endpoints of the signaled LSP. If the establishment of MEPs is not supported, an error MUST be generated: "OAM Problem/MEP establishment not supported".
1ビット（ビット番号10）：「必要なOAM MEPエンティティ」は、LSP_ATTRIBUTESオブジェクトで使用される属性フラグTLVに割り当てられます。 「必要なOAM MEPエンティティ」ビットが設定されている場合は、シグナリングされたLSPのエンドポイントでOAM MEPエンティティの確立が必要であることを示します。 MEPの確立がサポートされていない場合は、「OAM問題/ MEPの確立はサポートされていません」というエラーを生成する必要があります。
If the "OAM MEP entities desired" bit is set and additional parameters need to be configured, an OAM Configuration TLV MAY be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
「必要なOAM MEPエンティティ」ビットが設定されていて、追加のパラメーターを構成する必要がある場合、OAM構成TLVをLSP_ATTRIBUTESまたはLSP_REQUIRED_ATTRIBUTESオブジェクトに含めることができます（MAY）。
One bit (bit number 11): "OAM MIP entities desired" is allocated in the Attribute Flags TLV to be used in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects. If the "OAM MEP entities desired" bit is not set, then this bit MUST NOT be set. If the "OAM MIP entities desired" bit is set in the Attribute Flags TLV in the LSP_REQUIRED_ATTRIBUTES object, it indicates that the establishment of OAM MIP entities is required at every transit node of the signaled LSP. If the establishment of a MIP is not supported, an error MUST be generated: "OAM Problem/MIP establishment not supported". If an intermediate LSR does not support the extensions defined in this document, it will not recognize the "OAM MIP entities desired" flag and, although the LSP_REQUIRED_ATTRIBUTES object was used, it will not configure MIP entities and will not raise any errors. If LSRs that do not support the extensions defined in this document are to be assumed as present in the network, the ingress LSR SHOULD collect per-hop information about the LSP attributes utilizing the LSP Attributes sub-object of the Record Route object (RRO) as defined in [RFC5420]. When the Record Route object is received, the ingress SHOULD check whether all intermediate LSRs set the "OAM MIP entities desired" flag indicating support of the function; if not, depending on operator policy, the LSP MAY need to be torn down.
1ビット（ビット番号11）：「必要なOAM MIPエンティティ」は、LSP_ATTRIBUTESまたはLSP_REQUIRED_ATTRIBUTESオブジェクトで使用される属性フラグTLVに割り当てられます。 「必要なOAM MEPエンティティ」ビットが設定されていない場合、このビットを設定してはならない（MUST NOT）。 「必要なOAM MIPエンティティ」ビットがLSP_REQUIRED_ATTRIBUTESオブジェクトの属性フラグTLVに設定されている場合、シグナリングされたLSPのすべてのトランジットノードでOAM MIPエンティティの確立が必要であることを示します。 MIPの確立がサポートされていない場合は、「OAM問題/ MIPの確立はサポートされていません」というエラーが生成される必要があります。中間LSRがこのドキュメントで定義されている拡張機能をサポートしていない場合、「OAM MIPエンティティーが望ましい」フラグを認識せず、LSP_REQUIRED_ATTRIBUTESオブジェクトが使用されていても、MIPエンティティーは構成されず、エラーは発生しません。このドキュメントで定義されている拡張をサポートしないLSRがネットワークに存在すると想定される場合、入力LSRは、レコードルートオブジェクト（RRO）のLSP属性サブオブジェクトを使用して、LSP属性に関するホップごとの情報を収集する必要があります（SHOULD）。 [RFC5420]で定義されています。レコードルートオブジェクトを受信すると、すべての中間LSRが「OAM MIPエンティティが必要」フラグを設定して機能のサポートを示すかどうかを入力SHOULDが確認する必要があります。そうでない場合は、オペレーターのポリシーに応じて、LSPを解体する必要があります。
This TLV provides information about which OAM technology/method should be used and carries sub-TLVs for any additional OAM configuration information. One OAM Configuration TLV MAY be carried in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and Resv messages. When carried in the LSP_REQUIRED_ATTRIBUTES object, it indicates that intermediate nodes MUST recognize and react on the OAM configuration information.
このTLVは、使用する必要があるOAMテクノロジー/メソッドに関する情報を提供し、追加のOAM構成情報のサブTLVを伝送します。 1つのOAM構成TLVは、PathおよびResvメッセージのLSP_ATTRIBUTESまたはLSP_REQUIRED_ATTRIBUTESオブジェクトで伝達される場合があります。 LSP_REQUIRED_ATTRIBUTESオブジェクトで運ばれるとき、それは中間ノードがOAM構成情報を認識してそれに反応しなければならないことを示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ sub-TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: indicates a new type: the OAM Configuration TLV (3).
タイプ：新しいタイプを示します：OAM構成TLV（3）。
OAM Type: specifies the technology-specific OAM method. When carried in the LSP_REQUIRED_ATTRIBUTES object, if the requested OAM method is not supported at any given node an error MUST be generated: "OAM Problem/Unsupported OAM Type". When carried in the LSP_ATTRIBUTES object, intermediate nodes not supporting the OAM Type pass the object forward unchanged as specified in [RFC5420]. Ingress and egress nodes that support the OAM Configuration TLV but that do not support a specific OAM Type MUST respond with an error indicating "OAM Problem/Unsupported OAM Type".
OAMタイプ：テクノロジー固有のOAMメソッドを指定します。 LSP_REQUIRED_ATTRIBUTESオブジェクトで実行される場合、要求されたOAMメソッドが特定のノードでサポートされていない場合は、「OAM問題/サポートされていないOAMタイプ」というエラーが生成されるはずです。 LSP_ATTRIBUTESオブジェクトで運ばれるとき、OAMタイプをサポートしない中間ノードは、[RFC5420]で指定されているようにオブジェクトを変更せずに転送します。 OAM構成TLVをサポートするが、特定のOAMタイプをサポートしない入力ノードと出力ノードは、「OAM問題/サポートされていないOAMタイプ」を示すエラーで応答する必要があります。
OAM Type Description
------------ --------------------
0-255 Reserved
This document defines no types. IANA maintains the values in a new "RSVP-TE OAM Configuration Registry".
このドキュメントではタイプを定義していません。 IANAは新しい「RSVP-TE OAM構成レジストリ」で値を維持します。
Length: indicates the total length of the TLV in octets. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
長さ：TLVの全長をオクテットで示します。 TLVはゼロパディングして、TLVが4オクテットに整列するようにする必要があります。
Two groups of TLVs are defined: generic sub-TLVs and technology-specific sub-TLVs. Generic sub-TLVs carry information that is applicable independent of the actual OAM technology, while technology-specific sub-TLVs are providing configuration parameters for specific OAM technologies. This document defines one generic sub-TLV (see Section 4.2.1), while it is foreseen that technology-specific sub-TLVs will be defined by separate documents.
TLVの2つのグループが定義されています。一般的なサブTLVとテクノロジー固有のサブTLVです。ジェネリックサブTLVは、実際のOAMテクノロジーとは関係なく適用可能な情報を伝達しますが、テクノロジー固有のサブTLVは、特定のOAMテクノロジーの構成パラメーターを提供します。このドキュメントでは、1つの一般的なサブTLV（セクション4.2.1を参照）を定義していますが、テクノロジー固有のサブTLVは別のドキュメントで定義される予定です。
The receiving node, based on the OAM Type, will check to see if a corresponding technology-specific OAM configuration sub-TLV is included in the OAM Configuration TLV. If the included technology-specific OAM configuration sub-TLV is different from what is specified in the OAM Type, an error MUST be generated: "OAM Problem/ OAM Type Mismatch". IANA maintains the sub-TLV space in the new "RSVP-TE OAM Configuration Registry".
受信ノードは、OAMタイプに基づいて、対応するテクノロジー固有のOAM構成サブTLVがOAM構成TLVに含まれているかどうかを確認します。含まれているテクノロジー固有のOAM構成サブTLVがOAMタイプで指定されているものと異なる場合は、「OAM問題/ OAMタイプの不一致」というエラーを生成する必要があります。 IANAは、新しい「RSVP-TE OAM構成レジストリ」でサブTLVスペースを維持します。
Note that there is a hierarchical dependency between the OAM configuration elements. First, the "OAM MEP entities desired" flag needs to be set. Only when that flag is set MAY an OAM Configuration TLV be included in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. When this TLV is present, based on the "OAM Type" field, it MAY carry a technology-specific OAM configuration sub-TLV. If this hierarchy is broken (e.g., "OAM MEP entities desired" flag is not set but an OAM Configuration TLV is present), an error MUST be generated: "OAM Problem/Configuration Error".
OAM構成要素間に階層的な依存関係があることに注意してください。最初に、「OAM MEPエンティティが必要です」フラグを設定する必要があります。そのフラグが設定されている場合のみ、OAM構成TLVをLSP_ATTRIBUTESまたはLSP_REQUIRED_ATTRIBUTESオブジェクトに含めることができます。このTLVが存在する場合、「OAMタイプ」フィールドに基づいて、テクノロジー固有のOAM構成サブTLVを保持できます。この階層が壊れている場合（たとえば、「OAM MEPエンティティが必要です」フラグが設定されていないが、OAM構成TLVが存在する場合）、エラーを生成する必要があります：「OAM問題/構成エラー」。
The OAM Configuration TLV MUST always include a single instance of the OAM Function Flags Sub-TLV, and it MUST always be the first sub-TLV. "OAM Function Flags" specifies which proactive OAM functions (e.g., connectivity monitoring, loss and delay measurement) and which fault management signals MUST be established and configured. If the selected OAM Function or Functions are not supported, an error MUST be generated: "OAM Problem/Unsupported OAM Function".
OAM構成TLVは常にOAM機能フラグサブTLVの単一のインスタンスを含む必要があり、常に最初のサブTLVである必要があります。 「OAM機能フラグ」は、どのプロアクティブOAM機能（接続監視、損失および遅延測定など）と、どの障害管理信号を確立して構成する必要があるかを指定します。選択した1つまたは複数のOAM機能がサポートされていない場合は、「OAM問題/サポートされていないOAM機能」というエラーを生成する必要があります。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ OAM Function Flags ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OAM Function Flags is a bitmap with extensible length based on the
Length field of the TLV. Bits are numbered from left to right. The
TLV is padded to 4-octet alignment. The Length field indicates the
size of the padded TLV in octets. IANA maintains the OAM Function
Flags in the new "RSVP-TE OAM Configuration Registry". This document
defines the following flags:
OAM Function Flag bit # Description
----------------------- ---------------------------------------------
0 Continuity Check (CC)
1 Connectivity Verification (CV)
2 Fault Management Signal (FMS)
3 Performance Monitoring/Loss (PM/Loss)
4 Performance Monitoring/Delay (PM/Delay)
5 Performance Monitoring/Throughput Measurement
(PM/Throughput)
If technology-specific configuration information is needed for a specific "OAM Type", then this information is carried in a technology-specific sub-TLV. Such sub-TLVs are OPTIONAL, and an OAM Configuration TLV MUST NOT contain more than one technology-specific sub-TLV. IANA maintains the OAM technology-specific sub-TLV space in the new "RSVP-TE OAM Configuration Registry".
特定の「OAMタイプ」にテクノロジー固有の構成情報が必要な場合、この情報はテクノロジー固有のサブTLVで伝達されます。そのようなサブTLVはオプションであり、OAM構成TLVに複数のテクノロジー固有のサブTLVを含めることはできません。 IANAは、OAMテクノロジー固有のサブTLVスペースを新しい「RSVP-TE OAM構成レジストリ」に維持します。
Administrative Status Information is carried in the Admin_Status object, which is specified for RSVP-TE in [RFC3473]. Administrative Status Information is described in [RFC3471].
管理ステータス情報は、[RFC3473]でRSVP-TEに指定されているAdmin_Statusオブジェクトで伝達されます。管理ステータス情報は、[RFC3471]で説明されています。
Two bits (bit numbers 23 and 24) are allocated by this document for the administrative control of OAM monitoring: the "OAM Flows Enabled" (M) and "OAM Alarms Enabled" (O) bits. When the "OAM Flows Enabled" bit is set, OAM mechanisms MUST be enabled; if it is cleared, OAM mechanisms MUST be disabled. When the "OAM Alarms Enabled" bit is set, OAM-triggered alarms are enabled and associated consequent actions MUST be executed, including the notification to the management system. When this bit is cleared, alarms are suppressed, and no action SHOULD be executed; additionally, the management system SHOULD NOT be notified. For a detailed description of the use of these flags, see Section 3.
このドキュメントでは、OAM監視の管理制御用に2ビット（ビット番号23および24）が割り当てられています。「OAMフロー有効」（M）および「OAMアラーム有効」（O）ビットです。 「OAM Flows Enabled」ビットが設定されている場合、OAMメカニズムを有効にする必要があります。クリアされている場合は、OAMメカニズムを無効にする必要があります。 「OAMアラーム有効」ビットが設定されている場合、OAMトリガーアラームが有効になり、管理システムへの通知を含め、関連する後続のアクションを実行する必要があります。このビットがクリアされると、アラームは抑制され、アクションは実行されるべきではありません。さらに、管理システムは通知されるべきではありません。これらのフラグの使用の詳細については、セクション3を参照してください。
To handle OAM configuration errors, a new Error Code "OAM Problem" (40) is introduced. To refer to specific problems, a set of Error Values are defined under the "OAM Problem" error code.
OAM構成エラーを処理するために、新しいエラーコード "OAM Problem"（40）が導入されました。特定の問題を参照するために、「OAM問題」エラーコードの下に一連のエラー値が定義されています。
If a node does not support the establishment of OAM MEP or MIP entities it MUST use the error value "MEP establishment not supported" or "MIP establishment not supported", respectively, in the PathErr message.
ノードがOAM MEPまたはMIPエンティティの確立をサポートしていない場合、PathErrメッセージでそれぞれエラー値 "MEP確立がサポートされていません"または "MIP確立がサポートされていません"を使用する必要があります。
If a node does not support a specific OAM technology/solution, it MUST use the error value "Unsupported OAM Type" in the PathErr message.
ノードが特定のOAMテクノロジー/ソリューションをサポートしていない場合は、PathErrメッセージでエラー値「Unsupported OAM Type」を使用する必要があります。
If a different technology-specific OAM Configuration TLV is included than what was specified in the OAM Type, an error MUST be generated with error value "OAM Type Mismatch" in the PathErr message.
OAMタイプで指定されたものとは異なるテクノロジー固有のOAM構成TLVが含まれている場合、PathErrメッセージでエラー値「OAM Type Mismatch」を含むエラーを生成する必要があります。
There is a hierarchy between the OAM configuration elements. If this hierarchy is broken, the error value "Configuration Error" MUST be used in the PathErr message.
OAM構成要素間に階層があります。この階層が壊れている場合、PathErrメッセージでエラー値「Configuration Error」を使用する必要があります。
If a node does not support a specific OAM Function, it MUST use the error value "Unsupported OAM Function" in the PathErr message.
ノードが特定のOAM関数をサポートしていない場合、PathErrメッセージでエラー値 "Unsupported OAM Function"を使用する必要があります。
RSVP-TE extensions for the establishment of point-to-multipoint (P2MP) LSPs are specified in [RFC4875]. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence, the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages.
ポイントツーマルチポイント（P2MP）LSPの確立のためのRSVP-TE拡張は、[RFC4875]で指定されています。 P2MP LSPは、複数のソースからリーフ（S2L）サブLSPで構成されます。これらのS2LサブLSPは、入力LSRと出力LSRの間に設定され、RSVPセマンティクスを使用してブランチLSRによって適切に結合され、P2MP TE LSPになります。 1つのパスメッセージは、単一のP2MP LSPの1つまたは複数のS2LサブLSPを通知する場合があります。したがって、P2MP LSPに属するS2LサブLSPは、1つのパスメッセージを使用してシグナリングするか、複数のパスメッセージに分割できます。
P2MP OAM mechanisms are very specific to the data-plane technology; therefore, in this document we only highlight the basic principles of P2MP OAM configuration. We consider only the root-to-leaf OAM flows, and as such, aspects of the configuration of return paths are outside the scope of our discussions. We also limit our consideration to the case where all leaves must successfully establish OAM entities with identical configuration in order for the P2MP OAM to be successfully established. In any case, the discussion set forth below provides only guidelines for P2MP OAM configuration. However, at a minimum, the procedures below SHOULD be specified for P2MP OAM configuration in a technology-specific document.
P2MP OAMメカニズムは、データプレーンテクノロジーに非常に固有です。したがって、このドキュメントでは、P2MP OAM構成の基本原則のみを強調します。ルートからリーフへのOAMフローのみを考慮しているため、リターンパスの構成の側面は、ここでは説明しません。また、P2MP OAMを正常に確立するために、すべてのリーフが同一の構成でOAMエンティティを正常に確立する必要がある場合に、検討を制限します。いずれの場合でも、以下で説明する説明は、P2MP OAM構成のガイドラインのみを提供します。ただし、少なくとも、以下の手順は、テクノロジー固有のドキュメントのP2MP OAM構成に対して指定する必要があります。
The root node may use a single Path message or multiple Path messages to set up the whole P2MP tree. In the case when multiple Path messages are used, the root node is responsible for keeping the OAM configuration information consistent in each of the sent Path messages, i.e., the same information MUST be included in all Path messages used to construct the multicast tree. Each branching node will propagate the Path message downstream on each of the branches; when constructing a Path message, the OAM configuration information MUST be copied unchanged from the received Path message, including the related Admin_Status bits, LSP attribute flags, and OAM Configuration TLV. The latter two also imply that the LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects MUST be copied for the upstream Path message to the subsequent downstream Path messages.
ルートノードは、単一のPathメッセージまたは複数のPathメッセージを使用して、P2MPツリー全体をセットアップできます。複数のPathメッセージが使用される場合、ルートノードは、送信された各PathメッセージでOAM構成情報の一貫性を保つ責任があります。つまり、同じ情報を、マルチキャストツリーの構築に使用されるすべてのPathメッセージに含める必要があります。各分岐ノードは、各分岐の下流でPathメッセージを伝播します。 Pathメッセージを作成する場合、関連するAdmin_Statusビット、LSP属性フラグ、およびOAM構成TLVを含む、OAM構成情報を受信したPathメッセージから変更せずにコピーする必要があります。後者の2つは、LSP_ATTRIBUTESおよびLSP_REQUIRED_ATTRIBUTESオブジェクトがアップストリームパスメッセージから後続のダウンストリームパスメッセージにコピーされる必要があることも意味します。
Leaves MUST create and configure OAM sink functions according to the parameters received in the Path message; for P2MP OAM configuration, there is no possibility for parameter negotiation on a per-leaf basis. This is due to the fact that the OAM source function, residing in the root of the tree, will operate with a single configuration, which then must be obeyed by all leaves. If a leaf cannot accept the OAM parameters, it MUST use the RRO Attributes sub-object [RFC5420] to notify the root about the problem. In particular, if the OAM configuration was successful, the leaf would set the "OAM MEP entities desired" flag in the RRO Attributes sub-object in the Resv message. On the other hand, if OAM entities could not be established, the Resv message should be sent with the "OAM MEP entities desired" bit cleared in the RRO Attributes sub-object. Branching nodes should collect and merge the received RROs according to the procedures described in [RFC4875]. This way, the root, when receiving the Resv message (or messages if multiple Path messages were used to set up the tree), will have clear information about which of the leaves could establish the OAM functions. If all leaves established OAM entities successfully, the root can enable the OAM message flow. On the other hand, if at some leaves the establishment was unsuccessful, additional actions will be needed before the OAM message flow can be enabled. Such action could be to set up two independent P2MP LSPs:
リーフは、Pathメッセージで受信したパラメーターに従ってOAMシンク機能を作成および構成する必要があります。 P2MP OAM設定の場合、リーフごとにパラメータネゴシエーションを行うことはできません。これは、ツリーのルートにあるOAMソース機能が単一の構成で動作するため、すべてのリーフが従う必要があるためです。リーフがOAMパラメータを受け入れることができない場合は、RRO属性サブオブジェクト[RFC5420]を使用して、問題についてルートに通知する必要があります。特に、OAM設定が成功した場合、リーフは、ResvメッセージのRRO属性サブオブジェクトに「OAM MEPエンティティが必要」フラグを設定します。一方、OAMエンティティを確立できなかった場合は、RRO属性サブオブジェクトの「OAM MEPエンティティが必要」ビットをクリアしてResvメッセージを送信する必要があります。分岐ノードは、[RFC4875]で説明されている手順に従って、受信したRROを収集してマージする必要があります。このように、ルートは、Resvメッセージ（または、ツリーの設定に複数のPathメッセージが使用された場合はメッセージ）を受信したときに、どのリーフがOAM機能を確立できるかについての明確な情報を持っています。すべての確立されたOAMエンティティが正常に終了すると、ルートはOAMメッセージフローを有効にできます。一方、一部のリーフで確立が失敗した場合、OAMメッセージフローを有効にする前に追加のアクションが必要になります。そのようなアクションは、2つの独立したP2MP LSPをセットアップすることです。
o One LSP with OAM configuration information towards leaves that can support the OAM function. This can be done by pruning from the previously signaled P2MP LSP the leaves that failed to set up OAM.
o OAM機能をサポートできるリーフに向けたOAM構成情報を持つ1つのLSP。これは、以前に通知されたP2MP LSPから、OAMのセットアップに失敗したリーフをプルーニングすることで実行できます。
o The other P2MP LSP could be constructed for leaves without OAM entities.
o 他のP2MP LSPは、OAMエンティティのないリーフ用に構築できます。
The exact procedures will be described in technology-specific documents.
正確な手順については、テクノロジー固有のドキュメントで説明します。
IANA maintains a registry called "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" with a sub-registry called "Administrative Status Information Flags".
IANAは、「一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリングパラメータ」と呼ばれるレジストリを、「管理ステータス情報フラグ」と呼ばれるサブレジストリで管理しています。
IANA has allocated two new flags as follows:
IANAは、次の2つの新しいフラグを割り当てました。
Bit Number | Hex Value | Name | Reference
-----------+------------+--------------------------+-----------
23 | 0x00000100 | OAM Flows Enabled (M) | [RFC7260]
24 | 0x00000080 | OAM Alarms Enabled (O) | [RFC7260]
IANA maintains a registry called "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attribute Flags".
IANAは、「リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）パラメータ」と呼ばれるレジストリを、「属性フラグ」と呼ばれるサブレジストリで管理しています。
IANA has allocated two new flags as follows:
IANAは、次の2つの新しいフラグを割り当てました。
Bit | | Attribute | Attribute | |
No. | Name | Flags Path | Flags Resv | RRO | Reference
----+------------------+------------+------------+-----+----------
10 | OAM MEP | | | |
| entities desired | Yes | Yes | Yes | [RFC7260]
| | | | |
11 | OAM MIP | | | |
| entities desired | Yes | Yes | Yes | [RFC7260]
IANA maintains a registry called "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attributes TLV Space".
IANAは、「Resource Reservation Protocol-Traffic Engineering（RSVP-TE）Parameters」と呼ばれるレジストリを、「Attributes TLV Space」と呼ばれるサブレジストリとともに維持しています。
IANA has allocated one new TLV type as follows:
IANAは、次のように1つの新しいTLVタイプを割り当てました。
| | |Allowed on |
| |Allowed on |LSP_REQUIRED_|
Type| Name |LSP_ATTRIBUTES|ATTRIBUTES |Reference
----+----------------------+--------------+-------------+---------
3 | OAM Configuration TLV| Yes | Yes |[RFC7260]
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Error Codes and Globally-Defined Error Value Sub-Codes".
IANAは、「リソース予約プロトコル（RSVP）パラメータ」と呼ばれるレジストリを、「エラーコードとグローバルに定義されたエラー値のサブコード」と呼ばれるサブレジストリで管理しています。
IANA has allocated one new Error Code as follows:
IANAは、次のように1つの新しいエラーコードを割り当てました。
Error Code | Meaning | Reference
-----------+-------------+-------------
40 | OAM Problem | [RFC7260]
The following Error Value sub-codes are defined for this new Error Code:
この新しいエラーコードには、次のエラー値サブコードが定義されています。
Value | Description | Reference
-----------+---------------------------------+--------------
0 | Reserved | [RFC7260]
1 | MEP establishment not supported | [RFC7260]
2 | MIP establishment not supported | [RFC7260]
3 | Unsupported OAM Type | [RFC7260]
4 | Configuration Error | [RFC7260]
5 | OAM Type Mismatch | [RFC7260]
6 | Unsupported OAM Function | [RFC7260]
7-32767 | Unassigned |
32768-65535| Reserved for Private Use | [RFC7260]
IANA has created a new registry called "RSVP-TE OAM Configuration Registry".
IANAは、「RSVP-TE OAM構成レジストリ」と呼ばれる新しいレジストリを作成しました。
IANA has created sub-registries as defined in the following subsections. The registration procedures specified are as defined in [RFC5226].
IANAは、以下のサブセクションで定義されているサブレジストリを作成しました。指定された登録手順は、[RFC5226]で定義されているとおりです。
IANA has created the "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows:
IANAは、「RSVP-TE OAM構成レジストリ」の「OAMタイプ」サブレジストリを次のように作成しました。
Range | Registration Procedures
-------+-------------------------
0-255 | IETF Review
There are no initial values in this registry. IANA shows the registry as follows:
このレジストリには初期値はありません。 IANAは次のようにレジストリを表示します。
OAM Type Number | OAM Type Description | Reference
----------------+----------------------+--------------
0-255 | Unassigned |
IANA has created the "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" as follows:
IANAは、「RSVP-TE OAM構成レジストリ」の「OAMサブTLV」サブレジストリを次のように作成しました。
Range | Note | Registration Procedures
------------+------------------------------|------------------------
0-31 | Generic Sub-TLVs | IETF Review
32-65534 | Technology-specific Sub-TLVs | IETF Review
65535-65536 | Experimental Sub-TLVs | Reserved for
| Experimental Use
IANA has populated the registry as follows:
IANAは次のようにレジストリにデータを入力しました。
Sub-TLV Type | Description | Reference
-------------+-------------------------------+----------
0 | Reserved | [RFC7260]
1 | OAM Function Flags Sub-TLV | [RFC7260]
2-65534 | Unassigned |
65535-65536 | Reserved for Experimental Use | [RFC7260]
IANA has created the "OAM Function Flags Sub-Registry" sub-registry of the "RSVP-TE OAM Configuration Registry".
IANAは、「RSVP-TE OAM構成レジストリ」の「OAM機能フラグサブレジストリ」サブレジストリを作成しました。
New values in the registry are allocated by IETF Review [RFC5226]. There is no top value to the range. Bits are counted from bit 0 as the first bit transmitted.
レジストリの新しい値は、IETFレビュー[RFC5226]によって割り当てられます。範囲に最高値はありません。ビットは、送信された最初のビットとしてビット0からカウントされます。
IANA has populated the registry as follows:
IANAは次のようにレジストリにデータを入力しました。
OAM Function Flag | Description
Bit Number |
------------------+----------------------------------------------
0 | Continuity Check (CC)
1 | Connectivity Verification (CV)
2 | Fault Management Signal (FMS)
3 | Performance Monitoring/Loss (PM/Loss)
4 | Performance Monitoring/Delay (PM/Delay)
5 | Performance Monitoring/Throughput Measurement
| (PM/Throughput)
>=6 | Unassigned
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 the Security Framework for MPLS and GMPLS Networks [RFC5920].
GMPLSセキュリティと攻撃軽減技術のより包括的な議論については、MPLSおよびGMPLSネットワークのセキュリティフレームワーク[RFC5920]を参照してください。
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に感謝します。
[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月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、2003年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
[RFC5420] Farrel、A.、Papadimitriou、D.、Vasseur、JP。、およびA. Ayyangarps、「Resource Reservation Protocol Traffic Engineering（RSVP-TE）を使用したMPLS LSP確立のための属性のエンコーディング」、RFC 5420、2009年2月。
[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 Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE Std 802.1Q、2011。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベイカー、F。、リンデル、B。、およびM.タルワー、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「Operations and Management（OAM）Requirements for Multi-Protocol Label Switched（MPLS）Networks」、RFC 4377 、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "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.、Papadimitriou、D。、およびS. Yasukawa、「リソース予約プロトコルの拡張-ポイントツーマルチポイントTEラベルスイッチドパス（LSP）のトラフィックエンジニアリング（RSVP-TE）」、RFC 4875、 2007年5月。
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「要件、MPLSトランスポートプロファイル」、RFC 5654、2009年9月。
[RFC5828] Fedyk, D., Berger, L., and L. Andersson, "Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010.
[RFC5828] Fedyk、D.、Berger、L。、およびL. Andersson、「Generalized Multiprotocol Label Switching（GMPLS）Ethernet Label Switching Architecture and Framework」、RFC 5828、2010年3月。
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC5860] Vigoureux、M.、Ward、D。、およびM. Betts、「MPLSトランスポートネットワークにおける運用、管理、および保守（OAM）の要件」、RFC 5860、2010年5月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[RFC5921] Bocci、M.、Bryant、S.、Frost、D.、Levrau、L。、およびL. Berger、「A Transport Framework in MPLS in MPLS」、RFC 5921、2010年7月。
[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.
[RFC6060] Fedyk、D.、Shah、H.、Bitar、N。、およびA. Takacs、「イーサネットプロバイダーバックボーントラフィックエンジニアリング（PBB-TE）の汎用マルチプロトコルラベルスイッチング（GMPLS）制御」、RFC 6060、2011年3月。
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
Don Fedyk Hewlett-Packard Company 153 Taylor Street Littleton, MA 01460 USA
Don Fedyk Hewlett-Packard Company 153 Taylor Street Littleton、MA 01460 USA
EMail: don.fedyk@hp.com
Jia He Huawei PR China
J IA heh UAはPR中国です
EMail: hejia@huawei.com