Network Working Group S. Yasukawa
Request for Comments: 4687 NTT Corporation
Category: Informational A. Farrel
Old Dog Consulting
D. King
Aria Networks Ltd.
T. Nadeau
Cisco Systems, Inc.
September 2006
Network Working Group S. Yasukawa
Request for Comments: 4687 NTT Corporation
Category: Informational A. Farrel
Old Dog Consulting
D. King
Aria Networks Ltd.
T. Nadeau
Cisco Systems, Inc.
September 2006
Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks
点对多点MPLS网络的操作和管理（OAM）要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.
多协议标签交换（MPLS）已经扩展到包括点对多点（P2MP）标签交换路径（LSP）。与点对点MPLS LSP一样，检测、处理和诊断控制和数据平面缺陷的需求至关重要。
For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.
对于部署基于P2MP MPLS LSP的服务的运营商来说，如何处理这些缺陷的检测和规范非常重要，因为这些缺陷不仅可能影响MPLS网络的基础，还可能影响其网络客户的服务级别规范承诺。
This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs.
本文件描述了P2MP MPLS LSP的数据平面操作和管理要求。这些要求适用于所有形式的P2MP MPLS LSP，包括P2MP流量工程（TE）LSP和多播LSP。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Conventions Used in This Document ..........................3
2.2. Terminology ................................................3
2.3. Acronyms ...................................................3
3. Motivations .....................................................4
4. General Requirements ............................................4
4.1. Detection of Label Switch Path Defects .....................5
4.2. Diagnosis of a Broken Label Switch Path ....................6
4.3. Path Characterization ......................................6
4.4. Service Level Agreement Measurement ........................7
4.5. Frequency of OAM Execution .................................8
4.6. Alarm Suppression, Aggregation, and Layer Coordination .....8
4.7. Support for OAM Interworking for Fault Notification ........8
4.8. Error Detection and Recovery ...............................9
4.9. Standard Management Interfaces .............................9
4.10. Detection of Denial of Service Attacks ...................10
4.11. Per-LSP Accounting Requirements ..........................10
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
7. Acknowledgements ...............................................12
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Conventions Used in This Document ..........................3
2.2. Terminology ................................................3
2.3. Acronyms ...................................................3
3. Motivations .....................................................4
4. General Requirements ............................................4
4.1. Detection of Label Switch Path Defects .....................5
4.2. Diagnosis of a Broken Label Switch Path ....................6
4.3. Path Characterization ......................................6
4.4. Service Level Agreement Measurement ........................7
4.5. Frequency of OAM Execution .................................8
4.6. Alarm Suppression, Aggregation, and Layer Coordination .....8
4.7. Support for OAM Interworking for Fault Notification ........8
4.8. Error Detection and Recovery ...............................9
4.9. Standard Management Interfaces .............................9
4.10. Detection of Denial of Service Attacks ...................10
4.11. Per-LSP Accounting Requirements ..........................10
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
7. Acknowledgements ...............................................12
This document describes requirements for data plane operations and management (OAM) for point-to-multipoint (P2MP) Multi-Protocol Label Switching (MPLS). This document specifies OAM requirements for P2MP MPLS, as well as for applications of P2MP MPLS.
本文档描述了点对多点（P2MP）多协议标签交换（MPLS）的数据平面操作和管理（OAM）要求。本文件规定了P2MP MPLS以及P2MP MPLS应用程序的OAM要求。
These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs [RFC4461] and [P2MP-RSVP], as well as multicast LDP LSPs [MCAST-LDP].
这些要求适用于所有形式的P2MP MPLS LSP，包括P2MP流量工程（TE）LSP[RFC4461]和[P2MP-RSVP]，以及多播LDP LSP[MCAST-LDP]。
Note that the requirements for OAM for P2MP MPLS build heavily on the requirements for OAM for point-to-point MPLS. These latter requirements are described in [RFC4377] and are not repeated in this document.
请注意，P2MP MPLS的OAM需求主要基于点对点MPLS的OAM需求。[RFC4377]中描述了后一种要求，本文件不再重复。
For a generic framework for OAM in MPLS networks, refer to [RFC4378].
有关MPLS网络中OAM的通用框架，请参阅[RFC4378]。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The requirements in this document apply to OAM mechanism and protocol development, as opposed to the usual application of RFC 2119 requirements to an actual protocol, as this document does not specify a protocol.
本文件中的要求适用于OAM机制和协议开发，而不是通常将RFC 2119要求应用于实际协议，因为本文件未指定协议。
Definitions of key terms for MPLS OAM are found in [RFC4377] and the reader is assumed to be familiar with those definitions, which are not repeated here.
MPLS OAM关键术语的定义见[RFC4377]，假定读者熟悉这些定义，此处不再重复。
[RFC4461] includes some important definitions and terms for use within the context of P2MP MPLS. The reader should be familiar with at least the terminology section of that document.
[RFC4461]包括一些在P2MP MPLS上下文中使用的重要定义和术语。读者应至少熟悉该文件的术语部分。
The following acronyms are used in this document.
本文件中使用了以下首字母缩略词。
CE: Customer Edge DoS: Denial of service ECMP: Equal Cost Multipath
CE:客户边缘DoS:拒绝服务ECMP:等成本多路径
LDP: Label Distribution Protocol LSP: Label Switched Path LSR: Label Switching Router OAM: Operations and Management RSVP: Resource reSerVation Protocol P2MP: Point-to-Multipoint SP: Service Provider TE: Traffic Engineering
LDP:标签分发协议LSP:标签交换路径LSR:标签交换路由器OAM:操作和管理RSVP:资源预留协议P2MP:点对多点SP:服务提供商TE:流量工程
OAM for MPLS networks has been established as a fundamental requirement both through operational experience and through its documentation in numerous Internet Drafts. Many such documents (for example, [RFC4379], [RFC3812], [RFC3813], [RFC3814], and [RFC3815]) developed specific solutions to individual issues or problems. Coordination of the full OAM requirements for MPLS was achieved by [RFC4377] in recognition of the fact that the previous piecemeal approach could lead to inconsistent and inefficient applicability of OAM techniques across the MPLS architecture, and might require significant modifications to operational procedures and systems in order to provide consistent and useful OAM functionality.
MPLS网络的OAM已被确定为一项基本要求，这是通过运营经验和在众多互联网草案中的文档记录而实现的。许多此类文件（例如，[RFC4379]、[RFC3812]、[RFC3813]、[RFC3814]和[RFC3815]）针对个别问题制定了具体的解决方案。[RFC4377]对MPLS的完整OAM需求进行了协调，这是因为认识到以前的零碎方法可能导致整个MPLS体系结构中OAM技术的适用性不一致且效率低下，并且可能需要对操作过程和系统进行重大修改，以提供一致且有用的OAM功能。
This document builds on these realizations and extends the statements of MPLS OAM requirements to cover the new area of P2MP MPLS. That is, this document captures the requirements for P2MP MPLS OAM in advance of the development of specific solutions.
本文档以这些实现为基础，并扩展了MPLS OAM需求的陈述，以涵盖P2MP MPLS的新领域。也就是说，本文档在开发特定解决方案之前捕获了P2MP MPLS OAM的需求。
Nevertheless, at the time of writing, some effort had already been expended to extend existing MPLS OAM solutions to cover P2MP MPLS (for example, [P2MP-LSP-PING]). While this approach of extending existing solutions may be reasonable, in order to ensure a consistent OAM framework it is necessary to articulate the full set of requirements in a single document. This will facilitate a uniform set of MPLS OAM solutions spanning multiple MPLS deployments and concurrent applications.
然而，在撰写本文时，已经花费了一些精力来扩展现有的MPLS OAM解决方案，以覆盖P2MP MPLS（例如，[P2MP-LSP-PING]）。虽然这种扩展现有解决方案的方法可能是合理的，但为了确保OAM框架的一致性，有必要在一个文档中阐明整套需求。这将促进跨多个MPLS部署和并发应用程序的一组统一的MPLS OAM解决方案。
The general requirements described in this section are similar to those described for point-to-point MPLS in [RFC4377]. The subsections below do not repeat material from [RFC4377], but simply give references to that document.
本节中描述的一般要求与[RFC4377]中描述的点对点MPLS类似。下面的小节不重复[RFC4377]中的内容，而只是引用该文件。
However, where the requirements for P2MP MPLS OAM differ from or are more extensive than those expressed in [RFC4377], additional text is supplied.
但是，如果P2MP MPLS OAM的要求与[RFC4377]中的要求不同或更广泛，则提供额外的文本。
In general, it should be noted that P2MP LSPs introduce a scalability issue with respect to OAM that is not present in point-to-point MPLS. That is, an individual P2MP LSP will have more than one egress and the path to those egresses will very probably not be linear (for example, it may have a tree structure). Since the number of egresses for a single P2MP LSP is unknown and not bounded by any small number, it follows that all mechanisms defined for OAM support MUST scale well with the number of egresses and the complexity of the path of the LSP. Mechanisms that are able to deal with individual egresses will scale no worse than similar mechanisms for point-to-point LSPs, but it is desirable to develop mechanisms that are able to leverage the fact that multiple egresses are associated with a single LSP, and so achieve better scaling.
一般来说，应该注意，P2MP lsp引入了一个关于OAM的可伸缩性问题，这在点到点MPLS中并不存在。也就是说，单个P2MP LSP将具有多个出口，并且到这些出口的路径很可能不是线性的（例如，它可能具有树结构）。由于单个P2MP LSP的出口数量未知且不受任何小数量的限制，因此，为OAM支持定义的所有机制都必须与出口数量和LSP路径的复杂性很好地伸缩。能够处理单个出口的机制的可伸缩性不会比点到点LSP的类似机制差，但希望开发能够利用多个出口与单个LSP关联这一事实的机制，从而实现更好的可伸缩性。
The ability to detect defects in a P2MP LSP SHOULD not require manual, hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP, and SHOULD rely on proactive OAM procedures (such as continuous path connectivity and Service Level Agreement (SLA) measurement mechanisms). Any solutions SHOULD either extend or work in close conjunction with existing solutions developed for point-to-point MPLS, such as those specified in [RFC4379] where this requirement is not contradicted by the other requirements in this section. This will leverage existing software and hardware deployments.
检测P2MP LSP中缺陷的能力不应要求对用于切换该LSP流量的每个LSR进行手动逐跳故障排除，而应依赖于主动式OAM过程（如连续路径连接和服务级别协议（SLA）测量机制）。任何解决方案应扩展或与为点对点MPLS开发的现有解决方案紧密结合，如[RFC4379]中规定的解决方案，其中该要求与本节中的其他要求不矛盾。这将利用现有的软件和硬件部署。
Note that P2MP LSPs may introduce additional scaling concerns for LSP probing by tools such as [RFC4379]. As the number of leaves of a P2MP LSP increases it potentially becomes more expensive to inspect the LSP to detect defects. Any tool developed for this purpose MUST be cognitive of this issue and MUST include techniques to reduce the scaling impact of an increase in the number of leaves. Nevertheless, it should also be noted that the introduction of additional leaves may mean that the use of techniques such as [RFC4379] are less appropriate for defect detection with P2MP LSPs, while the technique may still remain useful for defect diagnosis as described in the next section.
请注意，P2MP LSP可能会通过[RFC4379]等工具为LSP探测引入额外的缩放问题。随着P2MP LSP叶片数量的增加，检查LSP以检测缺陷的成本可能会增加。为此目的开发的任何工具都必须认识到这一问题，并且必须包括减少叶片数量增加对缩放影响的技术。然而，还应注意的是，引入额外叶片可能意味着使用[RFC4379]等技术不太适合P2MP LSP的缺陷检测，而该技术仍可用于下一节所述的缺陷诊断。
Due to the above scaling concerns, LSRs or other network resources MUST NOT be overwhelmed by the operation of normal proactive OAM procedures, and measures taken to protect LSRs and network resources against being overwhelmed MUST NOT degrade the operational value or responsiveness of proactive OAM procedures. Note that reactive OAM may violate these limits (i.e., cause visible traffic degradation) if it is necessary or useful to try to fix whatever has gone wrong.
由于上述扩展问题，LSR或其他网络资源不得因正常主动式OAM过程的运行而被淹没，并且为保护LSR和网络资源免受淹没而采取的措施不得降低主动式OAM过程的操作价值或响应能力。请注意，如果有必要或有用地尝试修复任何出错的问题，那么反应式OAM可能会违反这些限制（即，导致可见的流量降级）。
By "overwhelmed" we mean that it MUST NOT be possible for an LSR to be so busy handling proactive OAM that it is unable to continue to process control or data plane traffic at its advertised rate. Similarly, a network resource (such as a data link) MUST NOT be carrying so much proactive OAM traffic that it is unable to carry the advertised data rate. At the same time, it is important to configure proactive OAM, if it is in use, not to raise alarms caused by the failure to receive an OAM message if the component responsible for processing the messages is unable to process because other components are consuming too many system resources -- such alarms might turn out to be false.
所谓“不知所措”，我们的意思是，LSR不可能忙于处理主动OAM，以至于无法继续以其公布的速率处理控制或数据平面流量。类似地，网络资源（如数据链路）不得承载过多的主动OAM流量，以致无法承载公布的数据速率。同时，配置主动式OAM（如果正在使用）很重要，如果负责处理消息的组件由于其他组件消耗了太多的系统资源而无法处理，则不要发出由于接收OAM消息失败而导致的警报——这些警报可能是错误的。
In practice, of course, the requirements in the previous paragraph may be met by careful specification of the anticipated data throughput of LSRs or data links. However, it should be recalled that proactive OAM procedures may be scaled linearly with the number of LSPs, and the number of LSPs is not necessarily a function of the available bandwidth in an LSR or on a data link.
当然，在实践中，可以通过仔细指定LSR或数据链路的预期数据吞吐量来满足上一段中的要求。然而，应当回顾，主动OAM过程可以与lsp的数量线性地缩放，并且lsp的数量不一定是LSR中或数据链路上的可用带宽的函数。
The ability to diagnose a broken P2MP LSP and to isolate the failed component (i.e., link or node) in the path is REQUIRED. These functions include a path connectivity test that can test all branches and leaves of a P2MP LSP for reachability, as well as a path tracing function. Note that this requirement is distinct from the requirement to detect errors or failures described in the previous section. In practice, Detection and Diagnosis/Isolation MAY be performed by separate or the same mechanisms according to the way in which the other requirements are met.
需要能够诊断损坏的P2MP LSP并隔离路径中的故障组件（即链路或节点）。这些功能包括一个路径连接测试，可以测试P2MP LSP的所有分支和叶的可达性，以及一个路径跟踪功能。请注意，此要求与前一节中描述的检测错误或故障的要求不同。在实践中，根据满足其他要求的方式，可通过单独或相同的机制执行检测和诊断/隔离。
It MUST be possible for the operator (or an automated process) to stipulate a timeout after which the failure to see a response shall be flagged as an error.
操作员（或自动过程）必须能够规定一个超时时间，在此时间后，未能看到响应应标记为错误。
Any mechanism developed to perform these functions is subject to the scalability concerns expressed in section 4.
为执行这些功能而开发的任何机制都会受到第4节中所述的可伸缩性问题的影响。
The path characterization function [RFC4377] is the ability to reveal details of LSR forwarding operations for P2MP LSPs. These details can then be compared later during subsequent testing relevant to OAM functionality. Therefore, LSRs supporting P2MP LSPs MUST provide mechanisms that allow operators to interrogate and characterize P2MP paths.
路径特征函数[RFC4377]能够揭示P2MP LSP的LSR转发操作的细节。这些细节随后可以在与OAM功能相关的后续测试中进行比较。因此，支持P2MP LSP的LSR必须提供允许操作员查询和描述P2MP路径的机制。
Since P2MP paths are more complex than the paths of point-to-point LSPs, the scaling concerns expressed in section 4 apply.
由于P2MP路径比点到点LSP的路径更复杂，因此第4节中表达的缩放问题适用。
Note that path characterization SHOULD lead to the operator being able to determine the full tree for a P2MP LSP. That is, it is not sufficient to know the list of LSRs in the tree, but it is important to know their relative order and where the LSP branches.
注意，路径特征化应使操作员能够确定P2MP LSP的完整树。也就是说，只知道树中的LSR列表是不够的，但知道它们的相对顺序以及LSP分支的位置很重要。
Since, in some cases, the control plane state and data paths may branch at different points from the control plane and data plane topologies (for example, Figure 1), it is not sufficient to present the order of LSRs, but it is important that the branching points on that tree are clearly identified.
由于在某些情况下，控制平面状态和数据路径可能在不同于控制平面和数据平面拓扑的点上分支（例如，图1），因此仅表示LSR的顺序是不够的，但必须清楚地标识树上的分支点。
E
/
A---B---C===D
\
F
E
/
A---B---C===D
\
F
Figure 1. An example P2MP tree where the data path and control plane state branch at C, but the topology branches at D.
图1。示例P2MP树，其中数据路径和控制平面状态在C处分支，但拓扑在D处分支。
A diagnostic tool that meets the path characterization requirements SHOULD collect information that is easy to process to determine the P2MP tree for a P2MP LSP, rather than provide information that must be post-processed with some complexity.
满足路径特征化要求的诊断工具应收集易于处理的信息，以确定P2MP LSP的P2MP树，而不是提供必须以某种复杂性进行后处理的信息。
Mechanisms are required to measure the diverse aspects of Service Level Agreements for services that utilize P2MP LSPs. The aspects are listed in [RFC4377].
对于使用P2MP LSP的服务，需要机制来度量服务级别协议的各个方面。[RFC4377]中列出了这些方面。
Service Level Agreements are often measured in terms of the quality and rate of data delivery. In the context of P2MP MPLS, data is delivered to multiple egress nodes. The mechanisms MUST, therefore, be capable of measuring the aspects of Service Level Agreements as they apply to each of the egress points to a P2MP LSP. At the same time, in order to diagnose issues with meeting Service Level Agreements, mechanisms SHOULD be provided to measure the aspects of the agreements at key points within the network such as at branch nodes on the P2MP tree.
服务级别协议通常根据数据交付的质量和速率来衡量。在P2MP MPLS的上下文中，数据被传送到多个出口节点。因此，这些机制必须能够测量服务级别协议的各个方面，因为它们适用于P2MP LSP的每个出口点。同时，为了诊断与满足服务级别协议有关的问题，应提供机制来测量网络内关键点（如P2MP树上的分支节点）的协议方面。
As stipulated in [RFC4377], the operator MUST have the flexibility to configure OAM parameters to meet their specific operational requirements. This requirement is potentially more important in P2MP deployments where the effects of the execution of OAM functions can be potentially much greater than in a non-P2MP configuration. For example, a mechanism that causes each egress of a P2MP LSP to respond could result in a large burst of responses to a single OAM request.
按照[RFC4377]的规定，运营商必须具有配置OAM参数的灵活性，以满足其特定的运营要求。此要求在P2MP部署中可能更为重要，在P2MP部署中，执行OAM功能的影响可能比非P2MP配置中的影响大得多。例如，导致P2MP LSP的每个出口响应的机制可能导致对单个OAM请求的大量响应。
Therefore, solutions produced SHOULD NOT impose any fixed limitations on the frequency of the execution of any OAM functions.
因此，生成的解决方案不应对任何OAM功能的执行频率施加任何固定限制。
As described in [RFC4377], network elements MUST provide alarm suppression and aggregation mechanisms to prevent the generation of superfluous alarms within or across network layers. The same time constraint issues identified in [RFC4377] also apply to P2MP LSPs.
如[RFC4377]所述，网元必须提供报警抑制和聚合机制，以防止在网络层内或跨网络层生成多余报警。[RFC4377]中确定的时间约束问题也适用于P2MP LSP。
A P2MP LSP also brings the possibility of a single fault causing a larger number of alarms than for a point-to-point LSP. This can happen because there are a larger number of downstream LSRs (for example, a larger number of egresses). The resultant multiplier in the number of alarms could cause swamping of the alarm management systems to which the alarms are reported, and serves as a multiplier to the number of potentially duplicate alarms raised by the network.
与点对点LSP相比，P2MP LSP还可能导致单个故障导致更多报警。这可能是因为下游LSR数量较多（例如，出口数量较多）。警报数量的结果乘数可能导致报告警报的警报管理系统被淹没，并作为网络引发的潜在重复警报数量的乘数。
Alarm aggregation or limitation techniques MUST be applied within any solution, or be available within an implementation, so that this scaling issue can be reduced. Note that this requirement introduces a second dimension to the concept of alarm aggregation. Where previously it applied to the correlation and suppression of alarms generated by different network layers, it now also applies to similar techniques applied to alarms generated by multiple downstream LSRs.
报警聚合或限制技术必须应用于任何解决方案中，或在实现中可用，以便减少此扩展问题。请注意，此要求为报警聚合的概念引入了第二个维度。以前它适用于不同网络层生成的报警的关联和抑制，现在它也适用于应用于多个下游LSR生成的报警的类似技术。
[RFC4377] specifies that an LSR supporting the interworking of one or more networking technologies over MPLS MUST be able to translate an MPLS defect into the native technology's error condition. This also applies to any LSR supporting P2MP LSPs. However, careful attention to the requirements for alarm suppression stipulated therein and in section 4.6 SHOULD be observed.
[RFC4377]规定，支持MPLS上一种或多种网络技术互通的LSR必须能够将MPLS缺陷转化为本机技术的错误条件。这也适用于任何支持P2MP LSP的LSR。但是，应仔细注意其中和第4.6节中规定的报警抑制要求。
Note that the time constraints for fault notification and alarm propagation affect the solutions that might be applied to the scalability problem inherent in certain OAM techniques applied to
请注意，故障通知和警报传播的时间限制会影响可能应用于特定OAM技术中固有的可伸缩性问题的解决方案
P2MP LSPs. For example, a solution to the issue of a large number of egresses all responding to some form of probe request at the same time might be to make the probes less frequent -- but this might affect the ability to detect and/or report faults.
P2MP LSP。例如，大量出口同时响应某种形式的探测请求的问题的解决方案可能是降低探测频率——但这可能会影响检测和/或报告故障的能力。
Where fault notification to the egress is required, there is the possibility that a single fault will give rise to multiple notifications, one to each egress node of the P2MP that is downstream of the fault. Any mechanisms MUST manage this scaling issue while still continuing to deliver fault notifications in a timely manner.
在需要向出口发出故障通知的情况下，单个故障可能会引起多个通知，一个通知发送给故障下游的P2MP的每个出口节点。任何机制都必须在继续及时提供故障通知的同时管理此扩展问题。
Where fault notification to the ingress is required, the mechanisms MUST ensure that the notification identifies the egress nodes of the P2MP LSP that are impacted (that is, those downstream of the fault) and does not falsely imply that all egress nodes are impacted.
当需要向入口发出故障通知时，这些机制必须确保该通知识别受影响的P2MP LSP的出口节点（即故障下游节点），并且不会错误地暗示所有出口节点都受到影响。
Recovery from a fault by a network element can be facilitated by MPLS OAM procedures. As described in [RFC4377], these procedures will detect a broad range of defects, and SHOULD be operable where MPLS P2MP LSPs span multiple routing areas or multiple Service Provider domains.
通过MPLS OAM过程，可以促进网元从故障中恢复。如[RFC4377]所述，这些程序将检测范围广泛的缺陷，并且在MPLS P2MP LSP跨越多个路由区域或多个服务提供商域时应可操作。
The same requirements as those expressed in [RFC4377] with respect to automatic repair and operator intervention ahead of customer detection of faults apply to P2MP LSPs.
与[RFC4377]中表达的关于客户检测故障前自动维修和操作员干预的要求相同，适用于P2MP LSP。
It should be observed that faults in P2MP LSPs MAY be recovered through techniques described in [P2MP-RSVP].
应注意，P2MP LSP中的故障可通过[P2MP-RSVP]中所述的技术进行恢复。
The widespread deployment of MPLS requires common information modeling of management and control of OAM functionality. This is reflected in the integration of standard MPLS-related MIBs [RFC3812], [RFC3813], [RFC3814], [RFC3815] for fault, statistics, and configuration management. These standard interfaces provide operators with common programmatic interface access to operations and management functions and their status.
MPLS的广泛部署要求对OAM功能的管理和控制进行公共信息建模。这反映在标准MPLS相关MIB[RFC3812]、[RFC3813]、[RFC3814]、[RFC3815]的集成中，用于故障、统计和配置管理。这些标准接口为操作员提供对操作和管理功能及其状态的公共编程接口访问。
The standard MPLS-related MIB modules [RFC3812], [RFC3813], [RFC3814], and [RFC3815] SHOULD be extended wherever possible, to support P2MP LSPs, the associated OAM functions on these LSPs, and the applications that utilize P2MP LSPs. Extending them will facilitate the reuse of existing management software both in LSRs and in management systems. In cases where the existing MIB modules cannot be extended, then new MIB modules MUST be created.
应尽可能扩展与MPLS相关的标准MIB模块[RFC3812]、[RFC3813]、[RFC3814]和[RFC3815]，以支持P2MP LSP、这些LSP上的相关OAM功能以及利用P2MP LSP的应用程序。扩展它们将有助于在LSR和管理系统中重用现有的管理软件。如果无法扩展现有MIB模块，则必须创建新的MIB模块。
The ability to detect denial of service (DoS) attacks against the data or control planes that signal P2MP LSPs MUST be part of any security management related to MPLS OAM tools or techniques.
检测针对发送P2MP LSP信号的数据或控制平面的拒绝服务（DoS）攻击的能力必须是与MPLS OAM工具或技术相关的任何安全管理的一部分。
In an MPLS network where P2MP LSPs are in use, Service Providers can measure traffic from an LSR to the egress of the network using some MPLS-related MIB modules (see section 4.9), for example. Other interfaces MAY exist as well and enable the creation of traffic matrices so that it is possible to know how much traffic is traveling from where to where within the network.
例如，在使用P2MP LSP的MPLS网络中，服务提供商可以使用一些与MPLS相关的MIB模块（参见第4.9节）测量从LSR到网络出口的流量。其他接口也可能存在，并允许创建流量矩阵，以便能够知道有多少流量在网络中从何处流向何处。
Analysis of traffic flows to produce a traffic matrix is more complicated where P2MP LSPs are deployed because there is no simple pairing relationship between an ingress and a single egress. Fundamental to understanding traffic flows within a network that supports P2MP LSPs will be the knowledge of where the traffic is branched for each LSP within the network, that is, where within the network the branch nodes for the LSPs are located and what their relationship is to links and other LSRs. Traffic flow and accounting tools MUST take this fact into account.
由于入口和单个出口之间没有简单的配对关系，因此在部署P2MP LSP的情况下，分析流量以生成流量矩阵更为复杂。了解支持P2MP LSP的网络中的流量流的基础是了解网络中每个LSP的流量分支位置，即LSP的分支节点在网络中的位置以及它们与链路和其他LSR的关系。交通流和会计工具必须考虑到这一事实。
This document introduces no new security issues compared with [RFC4377]. It is worth highlighting, however, that any tool designed to satisfy the requirements described in this document MUST include provisions to prevent its unauthorized use. Likewise, these tools MUST provide a means by which an operator can prevent denial of service attacks if those tools are used in such an attack. LSP mis-merging is described in [RFC4377] where it is pointed out that it has security implications beyond simply being a network defect. It needs to be stressed that it is in the nature of P2MP traffic flows that any erroneous delivery (such as caused by LSP mis-merging) is likely to have more far-reaching consequences since the traffic will be mis-delivered to multiple receivers.
与[RFC4377]相比，本文档没有引入新的安全问题。然而，值得强调的是，为满足本文件所述要求而设计的任何工具必须包括防止其未经授权使用的规定。同样，如果在此类攻击中使用这些工具，则这些工具必须提供一种手段，使运营商能够防止拒绝服务攻击。LSP错误合并在[RFC4377]中进行了描述，其中指出它不仅仅是一个网络缺陷，还具有安全含义。需要强调的是，P2MP业务流的性质是，任何错误交付（如LSP错误合并导致的错误交付）都可能产生更深远的后果，因为业务将错误交付给多个接收器。
As with the OAM functions described in [RFC4377], the performance of diagnostic functions and path characterization may involve the extraction of a significant amount of information about network construction. The network operator MAY consider this information private and wish to take steps to secure it, but further, the volume of this information may be considered as a threat to the integrity of
与[RFC4377]中描述的OAM功能一样，诊断功能和路径表征的性能可能涉及提取大量有关网络构造的信息。网络运营商可以将该信息视为私有的，并希望采取措施来保护它，但进一步地，该信息的量可以被认为是对完整性的威胁。
the network if it is extracted in bulk. This issue may be greater in P2MP MPLS because of the potential for a large number of receivers on a single LSP and the consequent extensive path of the LSP.
如果网络是批量提取的，则为网络。这个问题在P2MP MPLS中可能更严重，因为单个LSP上可能有大量的接收机，并且LSP的路径会随之扩展。
[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月。
[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，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[MCAST-LDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, June 2006.
[MCAST-LDP]Minei，I.，Ed.，Kompella，K.，Wijnands，I.，Ed.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，正在进行的工作，2006年6月。
[P2MP-LSP-PING] Yasukawa, S., Farrel, A., Ali, Z., and B. Fenner, "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", Work in Progress, April 2006.
[P2MP-LSP-PING]Yasukawa，S.，Farrel，A.，Ali，Z.，和B.Fenner，“在点对多点MPLS流量工程中检测数据平面故障-LSP-PING的扩展”，正在进行的工作，2006年4月。
[P2MP-RSVP] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to RSVP-TE for Point to Multipoint TE LSPs", Work in Progress, July 2006.
[P2MP-RSVP]Aggarwal，R.，Papadimitriou，D.，和S.Yasukawa，“点对多点TE LSP的RSVP-TE扩展”，正在进行的工作，2006年7月。
[RFC3812] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", RFC3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.和T.Nadeau，“使用SMIv2的MPLS流量工程管理信息库”，RFC3812，2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switch Router Management Information Base Using SMIv2", RFC3813, June 2004.
[RFC3813]Srinivasan，C.，Viswanathan，A.和T.Nadeau，“使用SMIv2的MPLS标签交换机路由器管理信息库”，RFC3813，2004年6月。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base", RFC3814, June 2004.
[RFC3814]Nadeau，T.，Srinivasan，C.，和A.Viswanathan，“多协议标签交换（MPLS）FEC到NHLFE（FTN）管理信息库”，RFC38142004年6月。
[RFC3815] Cucchiara, J., Sjostrand, H., and Luciani, J., "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815]Cucchiara，J.，Sjostrand，H.，和Luciani，J.，“多协议标签交换（MPLS）管理对象的定义，标签分发协议（LDP）”，RFC 3815，2004年6月。
[RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378]Allan，D.和T.Nadeau，“多协议标签交换（MPLS）操作和管理（OAM）框架”，RFC 4378，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，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
The authors wish to acknowledge and thank the following individuals for their valuable comments on this document: Rahul Aggarwal, Neil Harrison, Ben Niven-Jenkins, and Dimitri Papadimitriou.
作者希望感谢以下个人对本文件的宝贵意见：Rahul Aggarwal、Neil Harrison、Ben Niven Jenkins和Dimitri Papadimitriou。
Authors' Addresses
作者地址
Seisho Yasukawa NTT Corporation (R&D Strategy Department) 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
日本东京千代田町大町2号3-1，靖川正雄NTT公司（研发战略部）100-8116
Phone: +81 3 5205 5341
EMail: s.yasukawa@hco.ntt.co.jp
Phone: +81 3 5205 5341
EMail: s.yasukawa@hco.ntt.co.jp
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Daniel King Aria Networks Ltd.
丹尼尔·金·阿里亚网络有限公司。
Phone: +44 (0)1249 665923
EMail: daniel.king@aria-networks.com
Phone: +44 (0)1249 665923
EMail: daniel.king@aria-networks.com
Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719
Thomas D.Nadeau Cisco Systems，Inc.马萨诸塞州Boxborough大道1414号，邮编01719
EMail: tnadeau@cisco.com
EMail: tnadeau@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。