[要約] RFC 8256は、MPLSパスセグメントの監視におけるヒットレス要件についての要約です。その目的は、ネットワークの可用性を向上させるために、MPLSネットワークでのパスセグメントの監視をヒットレスに行うための要件を定義することです。
Internet Engineering Task Force (IETF) A. D'Alessandro
Request for Comments: 8256 Telecom Italia
Category: Informational L. Andersson
ISSN: 2070-1721 Huawei Technologies
S. Ueno
NTT Communications
K. Arai
Y. Koike
NTT
October 2017
Requirements for Hitless MPLS Path Segment Monitoring
ヒットレスMPLSパスセグメントモニタリングの要件
Abstract
概要
One of the most important Operations, Administration, and Maintenance (OAM) capabilities for transport-network operation is fault localization. An in-service, on-demand path segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between endpoints. However, the current segment monitoring approach defined for MPLS (including the MPLS Transport Profile (MPLS-TP)) in RFC 6371 "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of new OAM tools to support Hitless Path Segment Monitoring (HPSM).
トランスポートネットワークの運用における最も重要な運用、管理、および保守（OAM）機能の1つは、障害の局所化です。トランスポートパスのインサービスのオンデマンドパスセグメントモニタリング機能は、特にエンドポイント間でのみサービスモニタリング機能がアクティブ化されている場合に不可欠です。ただし、RFC 6371「MPLSベースのトランスポートネットワークの運用、管理、およびメンテナンスフレームワーク」でMPLS（MPLSトランスポートプロファイル（MPLS-TP）を含む）に対して定義されている現在のセグメントモニタリングアプローチには欠点があります。このドキュメントでは、パスセグメントモニタリング用の既存のMPLS-TP OAMメカニズムの分析を提供し、ヒットレスパスセグメントモニタリング（HPSM）をサポートする新しいOAMツールの開発を導くための要件を提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8256.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8256で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements for HPSM . . . . . . . . . . . . . . . . . . . . 8
4.1. Backward Compatibility . . . . . . . . . . . . . . . . . 8
4.2. Non-Intrusive Segment Monitoring . . . . . . . . . . . . 8
4.3. Monitoring Multiple Segments . . . . . . . . . . . . . . 9
4.4. Monitoring Single and Multiple Levels . . . . . . . . . . 9
4.5. HPSM and End-to-End Proactive Monitoring Independence . . 10
4.6. Monitoring an Arbitrary Segment . . . . . . . . . . . . . 10
4.7. Fault while HPSM Is Operational . . . . . . . . . . . . . 11
4.8. HPSM Manageability . . . . . . . . . . . . . . . . . . . 13
4.9. Supported OAM Functions . . . . . . . . . . . . . . . . . 13
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
According to the MPLS-TP OAM requirements [RFC5860], mechanisms MUST be available for alerting service providers of faults or defects that affect their services. In addition, to ensure that faults or service degradation can be localized, operators need a function to diagnose the detected problem. Using end-to-end monitoring for this purpose is insufficient in that an operator will not be able to localize a fault or service degradation accurately.
MPLS-TP OAM要件[RFC5860]に従って、サービスに影響を与える障害または欠陥をサービスプロバイダーに警告するためのメカニズムが利用可能でなければなりません（MUST）。さらに、障害やサービスの低下を確実に特定できるようにするには、オペレーターは検出された問題を診断する機能を必要とします。この目的でエンドツーエンドの監視を使用することは、オペレーターが障害やサービスの低下を正確に特定できないという点で不十分です。
A segment monitoring function that can focus on a specific segment of a transport path and that can provide a detailed analysis is indispensable to promptly and accurately localize the fault. A function for monitoring path segments has been defined to perform this task for MPLS-TP. However, as noted in the MPLS-TP OAM Framework [RFC6371], the current method for segment monitoring of a transport path has implications that hinder the usage in an operator network.
輸送経路の特定のセグメントに焦点を当て、詳細な分析を提供できるセグメント監視機能は、障害を迅速かつ正確に特定するために不可欠です。 MPLS-TPに対してこのタスクを実行するために、パスセグメントを監視する機能が定義されています。ただし、MPLS-TP OAMフレームワーク[RFC6371]で述べられているように、トランスポートパスのセグメント監視の現在の方法には、オペレーターネットワークでの使用を妨げる影響があります。
After elaborating on the problem statement for the path segment monitoring function as it is currently defined, this document provides requirements for an on-demand path segment monitoring function without traffic disruption. Further works are required to evaluate how proposed requirements match with current MPLS architecture and to identify possible solutions.
現在定義されているパスセグメントモニタリング機能の問題ステートメントについて詳しく説明した後、このドキュメントでは、トラフィックを中断せずにオンデマンドパスセグメントモニタリング機能の要件を提供します。提案された要件が現在のMPLSアーキテクチャとどのように一致するかを評価し、可能な解決策を特定するには、さらなる作業が必要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
HPSM - Hitless Path Segment Monitoring
HPSM-ヒットレスパスセグメントモニタリング
LSP - Label Switched Path
LSP-ラベルスイッチドパス
LSR - Label Switching Router
LSR-ラベルスイッチングルーター
ME - Maintenance Entity
ME-メンテナンスエンティティ
MEG - Maintenance Entity Group
MEG-メンテナンスエンティティグループ
MEP - Maintenance Entity Group End Point
MEP-メンテナンスエンティティグループのエンドポイント
MIP - Maintenance Entity Group Intermediate Point
MIP-メンテナンスエンティティグループ中間ポイント
OTN - Optical Transport Network
OTN-光伝送ネットワーク
TCM - Tandem Connection Monitoring
TCM-タンデム接続モニタリング
SPME - Sub-Path Maintenance Element
SPME-サブパスメンテナンス要素
A Sub-Path Maintenance Element (SPME) function to monitor (and to protect and/or manage) MPLS-TP network segments is defined in [RFC5921]. The SPME is defined between the edges of the segment of a transport path that needs to be monitored, protected, or managed. SPME is created by stacking the shim header (MPLS header), according to [RFC3031]; it is defined as the segment where the header is stacked. OAM messages can be initiated at the edge of the SPME. They can be sent to the peer edge of the SPME or to a MIP along the SPME by setting the TTL value of the Label Stack Entry (LSE) and interface identifier value at the corresponding hierarchical LSP level in case of a per-node model.
MPLS-TPネットワークセグメントを監視（および保護および/または管理）するためのサブパスメンテナンスエレメント（SPME）関数は、[RFC5921]で定義されています。 SPMEは、監視、保護、または管理する必要があるトランスポートパスのセグメントのエッジ間に定義されます。 [RFC3031]に従って、SPMEはシムヘッダー（MPLSヘッダー）をスタックすることによって作成されます。ヘッダーがスタックされるセグメントとして定義されます。 OAMメッセージは、SPMEのエッジで開始できます。ノードごとのモデルの場合は、対応する階層型LSPレベルでラベルスタックエントリ（LSE）のTTL値とインターフェース識別子の値を設定することにより、SPMEのピアエッジまたはSPMEに沿ったMIPに送信できます。
According to Section 3.8 of [RFC6371], MPLS-TP segment monitoring should satisfy two network objectives:
[RFC6371]のセクション3.8によると、MPLS-TPセグメントモニタリングは次の2つのネットワーク目標を満たしている必要があります。
(N1) The monitoring and maintenance of current transport paths has to be conducted in-service without traffic disruption.
（N1）現在の輸送経路の監視と保守は、交通を中断することなく供用中に実施する必要があります。
(N2) Segment monitoring must not modify the forwarding of the segment portion of the transport path.
（N2）セグメント監視は、トランスポートパスのセグメント部分の転送を変更してはなりません。
The SPME function that is defined in [RFC5921] has the following drawbacks:
[RFC5921]で定義されているSPME関数には、次の欠点があります。
(P1) It increases network management complexity, because a new sub-layer and new MEPs and MIPs have to be configured for the SPME.
（P1）SPME用に新しいサブレイヤーと新しいMEPおよびMIPを構成する必要があるため、ネットワーク管理の複雑さが増します。
(P2) Original conditions of the path change.
（P2）パスの元の状態が変化します。
(P3) The client traffic over a transport path is disrupted if the SPME is configured on-demand.
（P3）SPMEがオンデマンドで構成されている場合、トランスポートパス上のクライアントトラフィックが中断されます。
Problem (P1) is related to the management of each additional sub-layer required for segment monitoring in an MPLS-TP network. When an SPME is applied to administer on-demand OAM functions in MPLS-TP networks, a rule for operationally differentiating those SPMEs will be required at least within an administrative domain. This forces operators to implement at least an additional layer into the management systems that will only be used for on-demand path segment monitoring. From the perspective of operation, increasing the number of managed layers and managed addresses/identifiers is not desirable in view of keeping the management systems as simple as possible. Moreover, using the currently defined methods, on-demand setting of SPMEs causes problems (P2) and (P3) due to additional label stacking.
問題（P1）は、MPLS-TPネットワークでのセグメント監視に必要な追加の各サブレイヤーの管理に関連しています。 SPMEを適用してMPLS-TPネットワークのオンデマンドOAM機能を管理する場合、少なくとも管理ドメイン内でそれらのSPMEを運用上区別するためのルールが必要になります。これにより、オペレーターは、オンデマンドパスセグメントの監視にのみ使用される追加のレイヤーを管理システムに実装する必要があります。運用の観点からは、管理システムと管理アドレス/識別子の数を増やすことは、管理システムをできるだけ単純に保つという観点からは望ましくありません。さらに、現在定義されている方法を使用すると、SPMEのオンデマンド設定により、追加のラベルスタッキングが原因で問題（P2）および（P3）が発生します。
Problem (P2) arises because the MPLS-exposed label value and MPLS frame length change. The monitoring function should monitor the status without changing any condition of the target segment or of the target transport path. Changing the settings of the original shim header should not be allowed, because this change corresponds to creating a new segment of the original transport path that differs from the original one. When the conditions of the path change, the measured values or observed data will also change. This may make the monitoring meaningless because the result of the measurement would no longer reflect the performance of the connection where the original fault or degradation occurred. As an example, setting up an on-demand SPME will result in the LSRs within the monitoring segment only looking at the added (stacked) labels and not at the labels of the original LSP. This means that problems stemming from incorrect (or unexpected) treatment of labels of the original LSP by the nodes within the monitored segment cannot be identified when setting up SPME. This might include hardware problems during label lookup, misconfiguration, etc. Therefore, operators have to pay extra attention to correctly setting and checking the label values of the original LSP in the configuration. Of course, the reverse of this situation is also possible; for example, an incorrect or unexpected treatment of SPME labels can result in false detection of a fault where no problem existed originally.
問題（P2）は、MPLSに公開されたラベル値とMPLSフレーム長が変更されるために発生します。監視機能は、ターゲットセグメントまたはターゲットトランスポートパスの状態を変更せずにステータスを監視する必要があります。元のシムヘッダーの設定の変更は、元のトランスポートパスとは異なる元のトランスポートパスの新しいセグメントの作成に対応するため、許可しないでください。パスの状態が変化すると、測定値や観測データも変化します。これは、測定結果が元の障害または劣化が発生した接続のパフォーマンスを反映しなくなるため、監視が無意味になる可能性があります。例として、オンデマンドSPMEを設定すると、監視セグメント内のLSRは追加された（スタックされた）ラベルのみを参照し、元のLSPのラベルは参照しなくなります。つまり、監視対象セグメント内のノードによる元のLSPのラベルの誤った（または予期しない）処理に起因する問題は、SPMEの設定時に識別できません。これには、ラベルルックアップ中のハードウェアの問題、設定ミスなどが含まれる可能性があります。したがって、オペレーターは、設定内の元のLSPのラベル値を正しく設定およびチェックすることに特別な注意を払う必要があります。もちろん、この状況の逆も可能です。たとえば、SPMEラベルの誤ったまたは予期しない処理は、元々問題が存在していなかった障害を誤って検出する可能性があります。
Figure 1 shows an example of SPME settings. In the figure, "X" is the label value of the original path expected at the tail end of node D. "210" and "220" are label values allocated for SPME. The label values of the original path are modified as are the values of the stacked labels. As shown in Figure 1, SPME changes both the length of MPLS frames and the label value(s). In particular, performance monitoring measurements (e.g., Delay Measurement and Packet Loss Measurement) are sensitive to these changes. As an example, increasing the packet length may impact packet loss due to MTU settings; modifying the label stack may introduce packet loss, or it may fix packet loss depending on the configuration status. Such changes influence packet delay, too, even if, from a practical point of view, it is likely that only a few services will experience a practical impact.
図1は、SPME設定の例を示しています。この図では、「X」はノードDの末尾で予期される元のパスのラベル値です。「210」と「220」はSPMEに割り当てられたラベル値です。元のパスのラベル値は、スタックされたラベルの値と同様に変更されます。図1に示すように、SPMEはMPLSフレームの長さとラベル値の両方を変更します。特に、パフォーマンス監視測定（遅延測定やパケット損失測定など）は、これらの変化に敏感です。例として、パケット長を増やすと、MTU設定が原因でパケット損失に影響を与える可能性があります。ラベルスタックを変更すると、パケット損失が発生したり、構成ステータスによってはパケット損失が修正される場合があります。このような変更はパケットの遅延にも影響を及ぼしますが、実際的な観点からは、ごく少数のサービスのみが実際的な影響を被る可能性があります。
(Before SPME settings)
--- --- --- --- ---
| | | | | | | | | |
| | | | | | | | | |
--- --- --- --- ---
A--100--B--110--C--120--D--130--E <= transport path
MEP MEP
(After SPME settings)
--- --- --- --- ---
| | | | | | | | | |
| | | | | | | | | |
--- --- --- --- ---
A--100--B-----------X---D--130--E <= transport path
MEP MEP
210--C--220 <= SPME
MEP' MEP'
Figure 1: SPME Settings Example
図1：SPME設定の例
Problem (P3) can be avoided if the operator sets SPMEs in advance and maintains them until the end of life of a transport path: but this does not support on-demand. Furthermore, SMPEs cannot be set arbitrarily because overlapping of path segments is limited to nesting relationships. As a result, possible SPME configurations of segments of an original transport path are limited due to the characteristic of the SPME shown in Figure 1, even if SPMEs are preconfigured.
オペレーターが事前にSPMEを設定し、トランスポートパスの寿命が尽きるまでSPMEを維持すれば、問題（P3）を回避できますが、これはオンデマンドをサポートしていません。さらに、パスセグメントのオーバーラップはネスト関係に制限されるため、SMPEを任意に設定することはできません。その結果、元のトランスポートパスのセグメントの可能なSPME構成は、SPMEが事前に構成されている場合でも、図1に示すSPMEの特性により制限されます。
Although the make-before-break procedure in the survivability document [RFC6372] supports configuration for monitoring according to the framework document [RFC5921], without traffic disruption the configuration of an SPME is not possible without violating the network objective (N2). These concerns are described in Section 3.8 of [RFC6371].
存続可能性ドキュメント[RFC6372]のmake-before-break手順は、フレームワークドキュメント[RFC5921]に従って監視の構成をサポートしますが、トラフィックの中断なしに、ネットワーク目標（N2）に違反しない限り、SPMEの構成は不可能です。これらの懸念事項は、[RFC6371]のセクション3.8で説明されています。
Additionally, the make-before-break approach typically relies on a control plane and requires additional functionalities for a management system to properly support SPME creation and traffic switching from the original transport path to the SPME.
さらに、make-before-breakアプローチは通常コントロールプレーンに依存しており、SPMEの作成と元のトランスポートパスからSPMEへのトラフィックの切り替えを適切にサポートするには、管理システムに追加の機能が必要です。
As an example, the old and new transport resources (e.g., LSP tunnels) might compete with each other for resources that they have in common. Depending on availability of resources, this competition can cause admission control to prevent the new LSP tunnel from being established as this bandwidth accounting deviates from the traditional (non-control plane) management-system operation. While SPMEs can be applied in any network context (single-domain, multi-domain, single-carrier, multi-carrier, etc.), the main applications are in inter-carrier or inter-domain segment monitoring where they are typically preconfigured or pre-instantiated. SPME instantiates a hierarchical path (introducing MPLS-label stacking) through which OAM packets can be sent. The SPME monitoring function is also mainly important for protecting bundles of transport paths and the carriers' carrier solutions within an administrative domain.
例として、新旧のトランスポートリソース（LSPトンネルなど）は、共通のリソースを求めて互いに競合する可能性があります。リソースの可用性に応じて、この競合によりアドミッション制御が発生し、この帯域幅アカウンティングが従来の（非コントロールプレーン）管理システムの動作から逸脱するため、新しいLSPトンネルが確立されない場合があります。 SPMEは任意のネットワークコンテキスト（シングルドメイン、マルチドメイン、シングルキャリア、マルチキャリアなど）で適用できますが、主なアプリケーションは、キャリア間またはドメイン間セグメントの監視で、通常は事前に構成されています。事前インスタンス化。 SPMEは、OAMパケットを送信できる階層パス（MPLSラベルスタッキングの導入）をインスタンス化します。 SPME監視機能は、主に、管理ドメイン内のトランスポートパスのバンドルとキャリアのキャリアソリューションを保護するためにも重要です。
The analogy for SPME in other transport technologies is Tandem Connection Monitoring (TCM). TCM is used in Optical Transport Networks (OTNs) and Ethernet transport networks. It supports on-demand but does not affect the path. For example, in OTNs, TCM allows the insertion and removal of performance monitoring overhead within the frame at intermediate points in the network. It is done such that their insertion and removal do not change the conditions of the path. Though, as the OAM overhead is part of the frame (designated overhead bytes), it is constrained to a predefined number of monitoring segments.
他のトランスポートテクノロジーにおけるSPMEの類推は、タンデム接続モニタリング（TCM）です。 TCMは、光トランスポートネットワーク（OTN）およびイーサネットトランスポートネットワークで使用されます。オンデマンドをサポートしますが、パスには影響しません。たとえば、OTNでは、TCMを使用すると、ネットワークの中間点でフレーム内にパフォーマンスモニタリングオーバーヘッドを挿入および削除できます。それらの挿入と削除がパスの状態を変更しないように行われます。ただし、OAMオーバーヘッドはフレームの一部（指定されたオーバーヘッドバイト）であるため、事前定義された数の監視セグメントに制限されます。
To summarize: the problem statement is that the current sub-path maintenance based on a hierarchical LSP (SPME) is problematic for preconfiguration in terms of increasing the number of managed objects by layer stacking and identifiers/addresses. An on-demand configuration of SPME is one of the possible approaches for minimizing the impact of these issues. However, the current procedure is unfavorable because the on-demand configuration for monitoring changes the condition of the original monitored path. To avoid or minimize the impact of the drawbacks discussed above, a more efficient approach is required for the operation of an MPLS-TP transport network. A monitoring mechanism, named "Hitless Path Segment Monitoring" (HPSM), supporting on-demand path segment monitoring without traffic disruption is needed.
要約すると、問題のステートメントは、階層LSP（SPME）に基づく現在のサブパスメンテナンスは、レイヤースタッキングと識別子/アドレスによって管理対象オブジェクトの数を増やすという点で、事前構成に問題があるということです。 SPMEのオンデマンド構成は、これらの問題の影響を最小限に抑えるための可能なアプローチの1つです。ただし、現在の手順では、監視のためのオンデマンド構成が元の監視対象パスの状態を変更するため、好ましくありません。上記の欠点の影響を回避または最小化するには、MPLS-TPトランスポートネットワークの運用に、より効率的なアプローチが必要です。トラフィックを中断することなくオンデマンドパスセグメントモニタリングをサポートする、「Hitlessパスセグメントモニタリング」（HPSM）という名前のモニタリングメカニズムが必要です。
In the following sections, mandatory (M) and optional (O) requirements for the HPSM function are listed.
次のセクションでは、HPSM機能の必須（M）およびオプション（O）の要件を示します。
HPSM would be an additional OAM tool that would not replace SPME. As such:
HPSMは、SPMEに置き換わらない追加のOAMツールです。など：
(M1) HPSM MUST be compatible with the usage of SPME.
（M1）HPSMはSPMEの使用と互換性がなければなりません。
(O1) HPSM SHOULD be applicable at the SPME layer too.
（O1）HPSMはSPMEレイヤーにも適用できる必要があります（SHOULD）。
(M2) HPSM MUST support both the per-node and per-interface model as specified in [RFC6371].
（M2）HPSMは、[RFC6371]で指定されているように、ノードごととインターフェイスごとの両方のモデルをサポートする必要があります。
One of the major problems of legacy SPME highlighted in Section 3 is that it may not monitor the original path and it could disrupt service traffic when set up on demand.
セクション3でハイライトされたレガシーSPMEの主要な問題の1つは、元のパスを監視しない可能性があり、オンデマンドで設定するとサービストラフィックを中断する可能性があることです。
(M3) HPSM MUST NOT change the original conditions of the transport path (e.g., the length of MPLS frames, the exposed label values, etc.).
（M3）HPSMは、トランスポートパスの元の状態（MPLSフレームの長さ、公開されたラベル値など）を変更してはなりません（MUST NOT）。
(M4) HPSM MUST support on-demand provisioning without traffic disruption.
（M4）HPSMは、トラフィックを中断せずにオンデマンドプロビジョニングをサポートする必要があります。
Along a transport path, there may be the need to support monitoring multiple segments simultaneously.
トランスポートパスに沿って、複数のセグメントの同時監視をサポートする必要がある場合があります。
(M5) HPSM MUST support configuration of multiple monitoring segments along a transport path.
（M5）HPSMは、トランスポートパスに沿った複数の監視セグメントの構成をサポートする必要があります。
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
*------* *----* *--------------* <=three HPSM monit. instances
Figure 2: Multiple HPSM Instances Example
図2：複数のHPSMインスタンスの例
HPSM would apply mainly for on-demand diagnostic purposes. With the currently defined approach, the most serious problem is that there is no way to locate the degraded segment of a path without changing the conditions of the original path. Therefore, as a first step, a single-level, single-segment monitoring not affecting the monitored path is required for HPSM. Monitoring simultaneous segments on multiple levels is the most powerful tool for accurately diagnosing the performance of a transport path. However, in the field, a single-level, multiple-segment approach would be less complex for management and operations.
HPSMは主にオンデマンド診断の目的に適用されます。現在定義されているアプローチでは、最も深刻な問題は、元のパスの条件を変更せずにパスの劣化したセグメントを特定する方法がないことです。したがって、最初のステップとして、監視対象パスに影響を与えない単一レベルの単一セグメント監視がHPSMに必要です。複数のレベルで同時にセグメントを監視することは、トランスポートパスのパフォーマンスを正確に診断するための最も強力なツールです。ただし、現場では、単一レベルの複数セグメントのアプローチは、管理と運用にとってそれほど複雑ではありません。
(M6) HPSM MUST support single-level segment monitoring.
（M6）HPSMは、単一レベルのセグメント監視をサポートする必要があります。
(O2) HPSM MAY support multi-level segment monitoring.
（O2）HPSMはマルチレベルセグメントモニタリングをサポートする場合があります。
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
*-----------------* <=On-demand HPSM level 1
*-------------* <=On-demand HPSM level 2
*-* <=On-demand HPSM level 3
Figure 3: Multi-Level HPSM Example
図3：マルチレベルHPSMの例
There is a need for simultaneously using existing end-to-end proactive monitoring and on-demand path segment monitoring. Normally, the on-demand path segment monitoring is configured on a segment of a maintenance entity of a transport path. In such an environment, on-demand single-level monitoring should be performed without disrupting the proactive monitoring of the targeted end-to-end transport path to avoid affecting monitoring of user traffic performance.
既存のエンドツーエンドの予防的監視とオンデマンドパスセグメント監視を同時に使用する必要があります。通常、オンデマンドパスセグメントモニタリングは、トランスポートパスのメンテナンスエンティティのセグメントに設定されます。このような環境では、ユーザーのトラフィックパフォーマンスの監視に影響を与えないように、対象となるエンドツーエンドのトランスポートパスの予防的な監視を中断することなく、オンデマンドの単一レベルの監視を実行する必要があります。
(M7) HPSM MUST support the capability of being operated concurrently to, and independently of, the OAM function on the end-to-end path.
（M7）HPSMは、エンドツーエンドパス上のOAM機能に対して同時に、独立して動作する機能をサポートする必要があります。
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Proactive end-to-end mon.
*------------------* <= On-demand HPSM
Figure 4: Independence between Proactive End-to-End Monitoring and On-Demand HPSM
図4：プロアクティブなエンドツーエンド監視とオンデマンドHPSM間の独立性
The main objective for on-demand path segment monitoring is to diagnose the fault locations. A possible realistic diagnostic procedure is to fix one endpoint of a segment at the MEP of the transport path under observation and progressively change the length of the segments. It is, therefore, possible to monitor all the paths, step-by-step, with a granularity that depends on equipment implementations. For example, Figure 5 shows the case where the granularity is at the interface level (i.e., monitoring is at each input interface and output interface of each piece of equipment).
オンデマンドパスセグメントモニタリングの主な目的は、障害の場所を診断することです。可能な現実的な診断手順は、観察中の輸送経路のMEPでセグメントの1つの端点を固定し、セグメントの長さを徐々に変更することです。したがって、機器の実装に応じた細かさですべてのパスを段階的に監視できます。たとえば、図5は、粒度がインターフェースレベルである（つまり、監視が各機器の各入力インターフェースと出力インターフェースで行われる）場合を示しています。
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Proactive end-to-end mon.
*-----* <= 1st on-demand HPSM
*-------* <= 2nd on-demand HPSM
| |
| |
*-----------------------* <= 4th on-demand HPSM
*-----------------------------* <= 5th on-demand HPSM
Figure 5: Localization of a Defect by Consecutive On-Demand Path Segment Monitoring Procedure
図5：連続したオンデマンドパスセグメントモニタリング手順による欠陥の特定
Another possible scenario is depicted in Figure 6. In this case, the operator wants to diagnose a transport path starting at a transit node because the end nodes (A and E) are located at customer sites and consist of small boxes supporting only a subset of OAM functions. In this case, where the source entities of the diagnostic packets are limited to the position of MEPs, on-demand path segment monitoring will be ineffective because not all the segments can be diagnosed (e.g., segment monitoring HPSM 3 in Figure 6 is not available, and it is not possible to determine the fault location exactly).
別の可能なシナリオを図6に示します。この場合、エンドノード（AおよびE）は顧客サイトにあり、サブセットのみをサポートする小さなボックスで構成されているため、オペレーターはトランジットノードから始まるトランスポートパスを診断する必要があります。 OAM機能。この場合、診断パケットのソースエンティティがMEPの位置に制限されると、すべてのセグメントを診断できるわけではないため、オンデマンドパスセグメントモニタリングは無効になります（たとえば、図6のHPSM 3のセグメントモニタリングは利用できません） 、および障害の場所を正確に特定することはできません）。
(M8) It SHALL be possible to provision HPSM on an arbitrary segment of a transport path.
（M8）トランスポートパスの任意のセグメントにHPSMをプロビジョニングできる必要があります。
--- --- ---
--- | | | | | | ---
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Proactive end-to-end mon.
*-----* <= On-demand HPSM 1
*-----------------------* <= On-demand HPSM 2
*---------* <= On-demand HPSM 3
Figure 6: HPSM Configuration at Arbitrary Segments
図6：任意のセグメントでのHPSM構成
Node or link failures may occur while HPSM is active. In this case, if no resiliency mechanism is set up on the subtended transport path, there is no particular requirement for HPSM. If the transport path is protected, the HPSM function may monitor unintended segments. The following examples are provided for clarification.
HPSMがアクティブなときに、ノードまたはリンクの障害が発生する可能性があります。この場合、サブテンドトランスポートパスに復元メカニズムが設定されていなければ、HPSMに特別な要件はありません。トランスポートパスが保護されている場合、HPSM機能は意図しないセグメントを監視する場合があります。以下の例は、明確にするために提供されています。
Protection scenario A is shown in Figure 7. In this scenario, a working LSP and a protection LSP are set up. HPSM is activated between nodes A and E. When a fault occurs between nodes B and C, the operation of HPSM is not affected by the protection switch and continues on the active LSP.
保護シナリオAを図7に示します。このシナリオでは、現用LSPと保護LSPがセットアップされます。 HPSMはノードAとEの間でアクティブになります。ノードBとCの間で障害が発生しても、HPSMの動作は保護スイッチの影響を受けず、アクティブLSPで続行されます。
A - B - C - D - E - F
\ /
G - H - I - L
Where: - end-to-end LSP: A-B-C-D-E-F - working LSP: A-B-C-D-E-F - protection LSP: A-G-H-I-L-F - HPSM: A-E
ここで：-エンドツーエンドLSP：A-B-C-D-E-F-動作中のLSP：A-B-C-D-E-F-保護LSP：A-G-H-I-L-F-HPSM：A-E
Figure 7: Protection Scenario A
図7：保護シナリオA
Protection scenario B is shown in Figure 8. The difference with scenario A is that only a portion of the transport path is protected. In this case, when a fault occurs between nodes B and C on the working sub-path B-C-D, traffic will be switched to protection sub-path B-G-H-D. Assuming that OAM packet termination depends only on the TTL value of the MPLS label header, the target node of the HPSM changes from E to D due to the difference of hop counts between the working path route (A-B-C-D-E: 4 hops) and protection path route (A-B-G-H-D-E: 5 hops). In this case, the operation of HPSM is affected.
保護シナリオBを図8に示します。シナリオAとの違いは、トランスポートパスの一部のみが保護されることです。この場合、現用サブパスB-C-DのノードBとCの間で障害が発生すると、トラフィックは保護サブパスB-G-H-Dに切り替えられます。 OAMパケットの終了がMPLSラベルヘッダーのTTL値にのみ依存すると仮定すると、HPSMのターゲットノードは、現用パスルート（ABCDE：4ホップ）と保護パスルートの間のホップカウントの違いにより、EからDに変わります。 （ABGHDE：5ホップ）。この場合、HPSMの動作が影響を受けます。
A - B - C - D - E - F
\ /
G - H
- end-to-end LSP: A-B-C-D-E-F - working sub-path: B-C-D - protection sub-path: B-G-H-D - HPSM: A-E
- エンドツーエンドLSP：A-B-C-D-E-F-現用サブパス：B-C-D-保護サブパス：B-G-H-D-HPSM：A-E
Figure 8: Protection Scenario B
図8：保護シナリオB
(M9) The HPSM SHOULD avoid monitoring an unintended segment when one or more failures occur.
（M9）1つ以上の障害が発生した場合、HPSMは意図しないセグメントの監視を回避する必要があります（SHOULD）。
There are potentially different solutions to satisfy such a requirement. A possible solution may be to suspend HPSM monitoring until network restoration takes place. Another possible approach may be to compare the node/interface ID in the OAM packet with that at the node reached at TTL termination and, if this does not match, a suspension of HPSM monitoring should be triggered. The above approaches are valid in any circumstance, both for protected and unprotected networks LSPs. These examples should not be taken to limit the design of a solution.
そのような要件を満たすために、潜在的に異なるソリューションがあります。可能な解決策は、ネットワークの復元が行われるまでHPSMの監視を一時停止することです。別の可能なアプローチは、OAMパケットのノード/インターフェイスIDを、TTL終了時に到達したノードのIDと比較することです。これが一致しない場合は、HPSMモニタリングの一時停止をトリガーする必要があります。上記のアプローチは、保護されているネットワークと保護されていないネットワークの両方のLSPに対して、どのような状況でも有効です。これらの例は、ソリューションの設計を制限するものではありません。
From a managing perspective, increasing the number of managed layers and managed addresses/identifiers is not desirable in view of keeping the management systems as simple as possible.
管理の観点から見ると、管理対象のレイヤーと管理対象のアドレス/識別子の数を増やすことは、管理システムをできるだけ単純に保つという観点からは望ましくありません。
(M10) HPSM SHOULD NOT be based on additional transport layers (e.g., hierarchical LSPs).
（M10）HPSMは、追加のトランスポート層（たとえば、階層型LSP）に基づくべきではありません（SHOULD NOT）。
(M11) The same identifiers used for MIPs and/or MEPs SHOULD be applied to maintenance points for the HPSM when they are instantiated in the same place along a transport path.
（M11）MIPやMEPに使用されているものと同じ識別子が、トランスポートパスに沿って同じ場所にインスタンス化されている場合、HPSMのメンテナンスポイントに適用する必要があります（SHOULD）。
Maintenance points for the HPSM may be different from the functional components of MIPs and MEPs as defined in the OAM framework document [RFC6371]. Investigating potential solutions for satisfying HPSM requirements may lead to identifying new functional components; these components need to be backward compatible with MPLS architecture. Solutions are outside the scope of this document.
HPSMのメンテナンスポイントは、OAMフレームワークドキュメント[RFC6371]で定義されているMIPおよびMEPの機能コンポーネントとは異なる場合があります。 HPSM要件を満たすための潜在的なソリューションを調査すると、新しい機能コンポーネントの特定につながる可能性があります。これらのコンポーネントは、MPLSアーキテクチャとの下位互換性が必要です。解決策はこのドキュメントの範囲外です。
A maintenance point supporting the HPSM function has to be able to generate and inject OAM packets. OAM functions that may be applicable for on-demand HPSM are basically the on-demand performance monitoring functions that are defined in the OAM framework document [RFC6371]. The "on-demand" attribute is typically temporary for maintenance operation.
HPSM機能をサポートするメンテナンスポイントは、OAMパケットを生成および挿入できる必要があります。オンデマンドHPSMに適用できるOAM機能は、基本的に、OAMフレームワークドキュメント[RFC6371]で定義されているオンデマンドパフォーマンスモニタリング機能です。 「オンデマンド」属性は、通常、メンテナンス操作のための一時的なものです。
(M12) HPSM MUST support Packet Loss and Packet Delay measurement.
（M12）HPSMは、パケット損失およびパケット遅延測定をサポートする必要があります。
These functions are normally only supported at the endpoints of a transport path. If a defect occurs, it might be quite hard to locate the defect or degradation point without using the segment monitoring function. If an operator cannot locate or narrow down the cause of the fault, it is quite difficult to take prompt actions to solve the problem.
これらの機能は通常、トランスポートパスのエンドポイントでのみサポートされます。不具合が発生した場合、セグメント監視機能を使用しないと不具合箇所や劣化箇所の特定が困難な場合があります。オペレーターが障害の原因を特定または絞り込むことができない場合、問題を解決するために迅速なアクションを取ることは非常に困難です。
Other on-demand monitoring functions (e.g., Delay Variation measurement) are desirable but not as necessary as the functions mentioned above.
他のオンデマンドモニタリング機能（遅延変動測定など）は望ましいですが、上記の機能ほど必要ではありません。
(O3) HPSM MAY support Packet Delay variation, Throughput measurement, and other performance monitoring and fault management functions.
（O3）HPSMは、パケット遅延変動、スループット測定、その他のパフォーマンス監視および障害管理機能をサポートする場合があります（MAY）。
Support of out-of-service on-demand performance-management functions (e.g., Throughput measurement) is not required for HPSM.
HPSMでは、アウトオブサービスのオンデマンドパフォーマンス管理機能（スループット測定など）のサポートは必要ありません。
A new HPSM mechanism is required to provide on-demand path segment monitoring without traffic disruption. It shall meet the two network objectives described in Section 3.8 of [RFC6371] and summarized in Section 3 of this document.
トラフィックを中断することなくオンデマンドパスセグメントを監視するには、新しいHPSMメカニズムが必要です。 [RFC6371]のセクション3.8に記載され、このドキュメントのセクション3に要約されている2つのネットワーク目標を満たしている必要があります。
The mechanism should minimize the problems described in Section 3, i.e., (P1), (P2), and (P3).
このメカニズムは、セクション3で説明されている問題、つまり（P1）、（P2）、および（P3）を最小限に抑える必要があります。
The solution for the on-demand path segment monitoring without traffic disruption needs to cover both the per-node model and the per-interface model specified in [RFC6371].
トラフィックを中断せずにオンデマンドパスセグメントを監視するソリューションは、[RFC6371]で指定されているノードごとのモデルとインターフェイスごとのモデルの両方をカバーする必要があります。
The on-demand path segment monitoring without traffic disruption solution needs to support on-demand Packet Loss Measurement and Packet Delay Measurement functions and optionally other performance monitoring and fault management functions (e.g., Throughput measurement, Packet Delay variation measurement, Diagnostic test, etc.).
トラフィック中断ソリューションを使用しないオンデマンドパスセグメントモニタリングは、オンデマンドのパケット損失測定機能とパケット遅延測定機能、およびオプションで他のパフォーマンスモニタリング機能と障害管理機能（スループット測定、パケット遅延変動測定、診断テストなど）をサポートする必要があります。 ）。
Security is a significant requirement of the MPLS Transport Profile. This document provides a problem statement and requirements to guide the development of new OAM tools to support HPSM. Such new tools must follow the security considerations provided in OAM Requirements for MPLS-TP in [RFC5860].
セキュリティは、MPLSトランスポートプロファイルの重要な要件です。このドキュメントでは、HPSMをサポートする新しいOAMツールの開発をガイドするための問題ステートメントと要件を提供します。そのような新しいツールは、[RFC5860]のMPLS-TPのOAM要件で提供されているセキュリティの考慮事項に従う必要があります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https://www.rfc-editor.org/info / rfc3031>。
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, DOI 10.17487/RFC5860, May 2010, <https://www.rfc-editor.org/info/rfc5860>.
[RFC5860] Vigoureux、M.、Ed。、Ward、D.、Ed。、and M. Betts、Ed。、 "Requirements for Operations、Administration、and Maintenance（OAM）in MPLS Transport Networks"、RFC 5860、DOI 10.17487 / RFC5860、2010年5月、<https://www.rfc-editor.org/info/rfc5860>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, <https://www.rfc-editor.org/info/rfc5921>.
[RFC5921] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、and L. Berger、 "A Framework for MPLS in Transport Networks"、RFC 5921、 DOI 10.17487 / RFC5921、2010年7月、<https://www.rfc-editor.org/info/rfc5921>。
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, <https://www.rfc-editor.org/info/rfc6371>.
[RFC6371] Busi、I.、Ed。およびD. Allan編、「MPLSベースのトランスポートネットワークの運用、管理、およびメンテナンスフレームワーク」、RFC 6371、DOI 10.17487 / RFC6371、2011年9月、<https://www.rfc-editor.org/info/ rfc6371>。
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, DOI 10.17487/RFC6372, September 2011, <https://www.rfc-editor.org/info/rfc6372>.
[RFC6372] Sprecher、N.、Ed。 A.ファレル編、「MPLSトランスポートプロファイル（MPLS-TP）サバイバビリティフレームワーク」、RFC 6372、DOI 10.17487 / RFC6372、2011年9月、<https://www.rfc-editor.org/info/rfc6372>。
Contributors
貢献者
Manuel Paul Deutsche Telekom AG
マヌエルポールドイツテレコムAG
Email: manuel.paul@telekom.de
Acknowledgements
謝辞
The authors would also like to thank Alexander Vainshtein, Dave Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi, Maarten Vissers, Jia He, and Nurit Sprecher for their comments and enhancements to the text.
著者はまた、テキストへのコメントと拡張について、アレクサンダーヴァインシュテイン、デイブアラン、フェイチャン、フーブファンヘルフォールト、マルコムベッツ、イタロブシ、マールテンヴィッサーズ、ジアヘ、ニューリットシュプレーチャーに感謝します。
Authors' Addresses
著者のアドレス
Alessandro D'Alessandro Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy
アレッサンドロダレッサンドロテレコムイタリアVia Reiss Romoli、274トリノ10148イタリア
Email: alessandro.dalessandro@telecomitalia.it
Loa Andersson Huawei Technologies
Loa Andersson Huawei Technologies
Email: loa@pi.nu
Satoshi Ueno NTT Communications
さとし うえの んっｔ こっむにかちおんｓ
Email: ueno@nttv6.jp
Kaoru Arai NTT
かおる あらい んっｔ
Email: arai.kaoru@lab.ntt.co.jp
Yoshinori Koike NTT
よしのり こいけ んっｔ
Email: y.koike@vcd.nttbiz.com