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
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）功能之一是故障定位。传输路径的在用、按需路径段监控功能是必不可少的，特别是当服务监控功能仅在端点之间激活时。然而，RFC 6371“基于MPLS的传输网络的操作、管理和维护框架”中为MPLS定义的当前段监控方法（包括MPLS传输配置文件（MPLS-TP））存在缺陷。本文档分析了用于路径段监控的现有MPLS-TP OAM机制，并提供了指导新OAM工具开发的需求，以支持无故障路径段监控（HPSM）。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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]，必须有机制向服务提供商发出影响其服务的故障或缺陷警报。此外，为了确保故障或服务降级可以被定位，操作员需要一个功能来诊断检测到的问题。为此目的使用端到端监控是不够的，因为操作员无法准确定位故障或服务降级。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
HPSM - Hitless Path Segment Monitoring
HPSM-无故障路径段监控
LSP - Label Switched Path
标签交换路径
LSR - Label Switching Router
标签交换路由器
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
光传送网
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.
[RFC5921]中定义了用于监测（以及保护和/或管理）MPLS-TP网段的子路径维护元件（SPME）功能。SPME在需要监视、保护或管理的传输路径段的边缘之间定义。根据[RFC3031]，通过堆叠垫片标头（MPLS标头）创建SPME；它被定义为堆叠标头的段。OAM消息可以在SPME的边缘启动。在每个节点模型的情况下，通过设置标签堆栈项（LSE）的TTL值和相应层次LSP级别的接口标识符值，可以将它们发送到SPME的对等边缘或沿SPME发送到MIP。
According to Section 3.8 of [RFC6371], MPLS-TP segment monitoring should satisfy two network objectives:
根据[RFC6371]第3.8节，MPLS-TP段监控应满足两个网络目标：
(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的标签。这意味着在设置SPME时，无法识别由受监控段内的节点对原始LSP标签的错误（或意外）处理引起的问题。这可能包括标签查找期间的硬件问题、配置错误等。因此，操作员必须特别注意正确设置和检查配置中原始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
(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'
(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并将其保持到传输路径寿命结束，则可以避免问题（P3）：但这不支持按需。此外，SMPE不能任意设置，因为路径段的重叠仅限于嵌套关系。因此，由于图1所示SPME的特性，即使SPME已预配置，原始传输路径段的可能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]中的先通后断程序支持根据框架文件[RFC5921]进行监控配置，但如果没有通信中断，SPME的配置就不可能不违反网络目标（N2）。[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.
此外，先通后断方法通常依赖于控制平面，需要管理系统的附加功能，以正确支持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实例化一个分层路径（引入MPLS标签堆叠），通过该路径可以发送OAM数据包。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
总而言之：问题陈述是，当前基于分层LSP（SPME）的子路径维护在通过层堆叠和标识符/地址增加托管对象数量方面存在预配置问题。SPME的按需配置是将这些问题的影响降至最低的可能方法之一。但是，当前的过程是不利的，因为监视的按需配置更改了原始监视路径的条件。为了避免或最小化上述缺点的影响，需要一种更有效的方法来操作MPLS-TP
transport network. A monitoring mechanism, named "Hitless Path Segment Monitoring" (HPSM), supporting on-demand path segment monitoring without traffic disruption is needed.
运输网络。需要一种称为“无故障路径段监控”（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层。
(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的主要问题之一是，它可能无法监视原始路径，并且在按需设置时可能会中断服务流量。
(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帧的长度、暴露的标签值等）。
(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
--- --- --- --- ---
| | | | | | | | | |
| 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
--- --- --- --- ---
| | | | | | | | | |
| 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
--- --- --- --- ---
| | | | | | | | | |
| 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处，并逐步改变段的长度。因此，可以使用取决于设备实现的粒度逐步监控所有路径。例如，图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
--- --- --- --- ---
| | | | | | | | | |
| 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
--- --- ---
--- | | | | | | ---
| 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
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值，由于工作路径路由（A-B-C-D-E:4跳）和保护路径路由（A-B-G-H-D-E:5跳）之间的跳数不同，HPSM的目标节点从E变为D。在这种情况下，HPSM的运行受到影响。
A - B - C - D - E - F
\ /
G - H
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）当一个或多个故障发生时，HPSM应避免监控非预期段。
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
有可能不同的解决方案来满足这样的要求。一种可能的解决方案是在网络恢复之前暂停HPSM监控。另一种可能的方法可以是将OAM分组中的节点/接口ID与在TTL终止时到达的节点处的节点/接口ID进行比较，如果这不匹配，则进行比较
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监测暂停。上述方法在任何情况下都是有效的，无论是对于受保护的还是未受保护的网络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）。
(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）当HPSM的维护点沿着传输路径在同一位置实例化时，MIPs和/或MEP使用的相同标识符应应用于HPSM的维护点。
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]中定义的MIPs和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可支持数据包延迟变化、吞吐量测量和其他性能监测和故障管理功能。
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节中进行了总结。
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传输配置文件的重要要求。本文档提供了一个问题陈述和需求，以指导开发新的OAM工具以支持HPSM。此类新工具必须遵循[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，“多协议标签交换体系结构”，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.，和M.Betts，Ed.“MPLS传输网络中的操作、管理和维护（OAM）要求”，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.，和L.Berger，“传输网络中MPLS的框架”，RFC 5921，DOI 10.17487/RFC59212010年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，Ed.，“基于MPLS的传输网络的运营、管理和维护框架”，RFC 6371，DOI 10.17487/RFC63711911年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.Farrel，Ed.，“MPLS传输配置文件（MPLS-TP）生存能力框架”，RFC 6372，DOI 10.17487/RFC6372，2011年9月<https://www.rfc-editor.org/info/rfc6372>.
Contributors
贡献者
Manuel Paul Deutsche Telekom AG
曼努埃尔·保罗德国电信公司
Email: manuel.paul@telekom.de
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.
作者还要感谢Alexander Vainstein、Dave Allan、Fei Zhang、Huub van Helvoort、Malcolm Betts、Italo Busi、Maarten Vissers、Jia He和Nurit Sprecher对文本的评论和改进。
Authors' Addresses
作者地址
Alessandro D'Alessandro Telecom Italia Via Reiss Romoli, 274 Torino 10148 Italy
Alessandro D'Alessandro Telecom Italia Via Reiss Romoli，274都灵10148意大利
Email: alessandro.dalessandro@telecomitalia.it
Email: alessandro.dalessandro@telecomitalia.it
Loa Andersson Huawei Technologies
安达信华为技术有限公司
Email: loa@pi.nu
Email: loa@pi.nu
Satoshi Ueno NTT Communications
Satoshi Ueno NTT通信公司
Email: ueno@nttv6.jp
Email: ueno@nttv6.jp
Kaoru Arai NTT
新界新界北考如
Email: arai.kaoru@lab.ntt.co.jp
Email: arai.kaoru@lab.ntt.co.jp
Yoshinori Koike NTT
小池吉诺里NTT
Email: y.koike@vcd.nttbiz.com
Email: y.koike@vcd.nttbiz.com