Network Working Group T. Nadeau
Request for Comments: 4377 M. Morrow
Category: Informational G. Swallow
Cisco Systems, Inc.
D. Allan
Nortel Networks
S. Matsushima
Japan Telecom
February 2006
Network Working Group T. Nadeau
Request for Comments: 4377 M. Morrow
Category: Informational G. Swallow
Cisco Systems, Inc.
D. Allan
Nortel Networks
S. Matsushima
Japan Telecom
February 2006
Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (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
摘要
This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks.
本文档规定了多协议标签交换（MPLS）以及MPLS应用（如伪有线语音和虚拟专用网络服务）的操作和管理（OAM）要求。这些要求是从具有部署MPLS网络丰富经验的网络运营商处收集的。
Table of Contents
目录
1. Introduction ....................................................2
2. Document Conventions ............................................2
3. Motivations .....................................................4
4. Requirements ....................................................4
5. Security Considerations ........................................11
6. References .....................................................12
7. Acknowledgements ...............................................13
1. Introduction ....................................................2
2. Document Conventions ............................................2
3. Motivations .....................................................4
4. Requirements ....................................................4
5. Security Considerations ........................................11
6. References .....................................................12
7. Acknowledgements ...............................................13
This document describes requirements for user and data plane Operations and Management (OAM) for Multi-Protocol Label Switching (MPLS). These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. This document specifies OAM requirements for MPLS, as well as for applications of MPLS.
本文档描述了多协议标签交换（MPLS）的用户和数据平面操作和管理（OAM）要求。这些要求是从具有部署MPLS网络丰富经验的网络运营商处收集的。本文档规定了MPLS以及MPLS应用程序的OAM要求。
Currently, there are no specific mechanisms proposed to address these requirements. The goal of this document is to identify a commonly applicable set of requirements for MPLS OAM at this time. Specifically, a set of requirements that apply to the most common set of MPLS networks deployed by service provider organizations at the time this document was written. These requirements can then be used as a base for network management tool development and to guide the evolution of currently specified tools, as well as the specification of OAM functions that are intrinsic to protocols used in MPLS networks.
目前，没有针对这些要求提出的具体机制。本文档的目标是确定目前MPLS OAM的一组普遍适用的需求。具体来说，这是一组要求，适用于编写本文档时服务提供商组织部署的最常见的一组MPLS网络。然后，这些需求可以用作网络管理工具开发的基础，并指导当前指定工具的发展，以及MPLS网络中使用的协议固有的OAM功能的规范。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Queuing/buffering Latency: The delay caused by packet queuing (value is variable since it is dependent on the packet arrival rate, the packet length, and the link throughput).
排队/缓冲延迟：数据包排队引起的延迟（值是可变的，因为它取决于数据包到达率、数据包长度和链路吞吐量）。
Probe-based-detection: Active measurement tool that can measure the consistency of an LSP [RFC4379].
基于探针的检测：可以测量LSP一致性的主动测量工具[RFC4379]。
Defect: Any error condition that prevents a Label Switched Path (LSP) from functioning correctly. For example, loss of an Interior Gateway Protocol (IGP) path will most likely result in an LSP not being able to deliver traffic to its destination. Another example is the interruption of the path for a TE tunnel. These may be due to physical circuit failures or failure of switching nodes to operate as expected.
缺陷：任何妨碍标签交换路径（LSP）正常运行的错误情况。例如，丢失内部网关协议（IGP）路径很可能会导致LSP无法将流量传送到其目的地。另一个例子是TE隧道的路径中断。这可能是由于物理电路故障或交换节点无法按预期运行造成的。
Multi-vendor/multi-provider network operation typically requires agreed upon definitions of defects (when it is broken and when it is not) such that both recovery procedures and service level specification impact can be specified.
多供应商/多供应商网络运营通常需要商定的缺陷定义（当缺陷被破坏或未被破坏时），以便可以指定恢复程序和服务级别规范影响。
Head-end Label Switching Router (LSR): The beginning of an LSP. A head-end LSR is also referred to as an ingress LSR.
前端标签交换路由器（LSR）：LSP的开始。前端LSR也称为入口LSR。
Tail-end Label Switching Router (LSR): The end of an LSP. A tail-end LSR is also referred to as an egress LSR.
尾端标签交换路由器（LSR）：LSP的末端。尾端LSR也称为出口LSR。
Propagation Latency: The delay added by the propagation of the packet through the link (fixed value that depends on the distance of the link and the propagation speed).
传播延迟：数据包通过链路传播所增加的延迟（取决于链路距离和传播速度的固定值）。
Transmission Latency: The delay added by the transmission of the packet over the link, i.e., the time it takes to put the packet over the media (value that depends on the link throughput and packet length).
传输延迟：通过链路传输数据包所增加的延迟，即将数据包置于媒体上所需的时间（取决于链路吞吐量和数据包长度的值）。
Processing Latency: The delay added by all the operations related to the switching of labeled packets (value is node implementation specific and may be considered fixed and constant for a given type of equipment).
处理延迟：与交换标记数据包相关的所有操作所增加的延迟（该值是特定于节点实现的，对于给定类型的设备可能被视为固定不变）。
Node Latency: The delay added by the network element resulting from of the sum of the transmission, processing, and queuing/buffering latency.
节点延迟：由于传输、处理和排队/缓冲延迟总和的增加，网元增加的延迟。
One-hop Delay: The fixed delay experienced by a packet to reach the next hop resulting from the of the propagation latency, the transmission latency, and the processing latency.
一跳延迟：数据包到达下一跳所经历的固定延迟，由传播延迟、传输延迟和处理延迟的变化引起。
Minimum Path Latency: The sum of the one-hop delays experienced by the packet when traveling from the ingress to the egress LSR.
最小路径延迟：数据包从入口传输到出口LSR时经历的一跳延迟的总和。
Variable Path Latency: The variation in the sum of the delays experienced by packets transiting the path, otherwise know as jitter.
可变路径延迟：通过路径传输的数据包所经历的延迟总和的变化，也称为抖动。
ASBR: Autonomous System Border Router
自治系统边界路由器
CE: Customer Edge
行政长官：顾客优势
PE: Provider Edge
PE：提供程序边缘
SP: Service Provider
SP：服务提供商
ECMP: Equal-Cost Multi-path
ECMP：等成本多路径
LSP: Label Switched Path
标签交换路径
LSP Ping: Label Switched Path Ping
LSP Ping：标签交换路径Ping
LSR: Label Switching Router
标签交换路由器
OAM: Operations and Management
OAM：运营和管理
RSVP: Resource reSerVation Protocol
资源预留协议
LDP: Label Distribution Protocol
标签分发协议
DoS: Denial of Service
拒绝服务
This document was created to provide requirements that could be used to create consistent and useful OAM functionality that meets operational requirements of those service providers (SPs) who have deployed or are deploying MPLS.
创建本文档的目的是提供可用于创建一致且有用的OAM功能的需求，以满足已部署或正在部署MPLS的服务提供商（SP）的运营需求。
The following sections enumerate the OAM requirements gathered from service providers who have deployed MPLS and services based on MPLS networks. Each requirement is specified in detail to clarify its applicability. Although the requirements specified herein are defined by the IETF, they have been made consistent with requirements gathered by other standards bodies such as the ITU [Y1710].
以下各节列举了从已部署MPLS和基于MPLS网络的服务提供商处收集的OAM需求。详细说明了每项要求，以阐明其适用性。尽管本文规定的要求由IETF定义，但它们与其他标准机构（如ITU[Y1710]）收集的要求一致。
The ability to detect defects in a broken LSP MUST not require manual hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP. For example, it is not desirable to manually visit each LSR along the data plane path transited by an LSP; instead, this function MUST be automated and able to be performed at some operator specified frequency from the origination point of that LSP. This implies solutions that are interoperable to allow for such automatic operation.
检测损坏LSP中的缺陷的能力不需要对用于切换该LSP流量的每个LSR进行手动逐跳故障排除。例如，不希望沿LSP传输的数据平面路径手动访问每个LSR；相反，该功能必须是自动化的，并且能够从LSP的起始点以操作员指定的频率执行。这意味着解决方案是可互操作的，以允许这种自动操作。
Furthermore, the automation of path liveliness is desired in cases where large numbers of LSPs might be tested. For example, automated ingress LSR to egress LSR testing functionality is desired for some LSPs. The goal is to detect LSP path defects before customers do, which requires detection and correction of LSP defects in a manner that is both predictable and within the constraints of the service level agreement under which the service is being offered. Simply put, the sum of the time it takes an OAM tool to detect a defect and the time needed for an operational support system to react to this defect, by possibly correcting it or notifying the customer, must fall within the bounds of the service level agreement in question.
此外，在可能测试大量LSP的情况下，需要路径活性的自动化。例如，一些LSP需要自动进入LSR到出口LSR测试功能。目标是在客户之前检测LSP路径缺陷，这要求以可预测的方式检测和纠正LSP缺陷，并且在提供服务的服务级别协议的约束范围内。简言之，OAM工具检测缺陷所需的时间和运营支持系统通过可能的纠正或通知客户对此缺陷作出反应所需的时间之和必须在相关服务级别协议的范围内。
Synchronization of detection time bounds by tools used to detect broken LSPs is required. Failure to specify defect detection time bounds may result in an ambiguity in test results. If the time to detect broken LSPs is known, then automated responses can be specified with respect and regard to resiliency and service level specification reporting. Further, if synchronization of detection time bounds is possible, an operational framework can be established to guide the design and specification of MPLS applications.
需要通过用于检测破损LSP的工具同步检测时间界限。未能指定缺陷检测时间界限可能导致测试结果不明确。如果已知检测损坏的LSP的时间，则可以根据弹性和服务级别规范报告指定自动响应。此外，如果检测时间界限的同步是可能的，则可以建立操作框架来指导MPLS应用程序的设计和规范。
Although an ICMP-based ping [RFC792] can be sent through an LSP as an IP payload, the use of this tool to verify the defect-free operation of an LSP has the potential of returning erroneous results (both positive and negative) for a number of reasons. For example, in some cases, because the ICMP traffic is based on legally addressable IP addressing, it is possible for ICMP messages that are originally transmitted inside of an LSP to "fall out of the LSP" at some point along the path. In these cases, since ICMP packets are routable, a falsely positive response may be returned. In other cases, where the data plane of a specific LSP needs to be tested, it is difficult to guarantee that traffic based on an ICMP ping header is parsed and hashed to the same equal-cost multi-paths (ECMP) as the data traffic.
尽管基于ICMP的ping[RFC792]可以作为IP有效负载通过LSP发送，但由于多种原因，使用此工具验证LSP的无缺陷操作有可能返回错误结果（正面和负面）。例如，在某些情况下，由于ICMP流量基于合法可寻址的IP寻址，因此最初在LSP内部传输的ICMP消息可能在路径上的某个点“脱离LSP”。在这些情况下，由于ICMP数据包是可路由的，因此可能会返回错误的肯定响应。在其他情况下，在需要测试特定LSP的数据平面的情况下，很难保证基于ICMP ping报头的流量被解析并散列到与数据流量相同的等成本多路径（ECMP）。
Any detection mechanisms that depend on receiving the status via a return path SHOULD provide multiple return options with the expectation that one of them will not be impacted by the original
任何依赖于通过返回路径接收状态的检测机制都应该提供多个返回选项，期望其中一个不会受到原始路径的影响
defect. An example of a case where a false negative might occur would be a mechanism that requires a functional MPLS return path. Since MPLS LSPs are unidirectional, it is possible that although the forward LSP, which is the LSP under test, might be functioning, the response from the destination LSR might be lost, thus giving the source LSR the false impression that the forward LSP is defective. However, if an alternate return path could be specified -- say IP for example -- then the source could specify this as the return path to the destination, and in this case, would receive a response indicating that the return LSP is defective.
缺点可能出现假阴性的情况的一个示例是需要功能性MPLS返回路径的机制。由于MPLS LSP是单向的，因此尽管前向LSP（即被测LSP）可能正在工作，但来自目的地LSR的响应可能丢失，从而给源LSR留下前向LSP有缺陷的错误印象。但是，如果可以指定备用返回路径（例如IP），则源可以将其指定为到目标的返回路径，在这种情况下，将收到一个指示返回LSP有缺陷的响应。
The OAM packet MUST follow the customer data path exactly in order to reflect path liveliness used by customer data. Particular cases of interest are forwarding mechanisms, such as ECMP scenarios within the operator's network, whereby flows are load-shared across parallel paths (i.e., equal IGP cost). Where the customer traffic may be spread over multiple paths, the ability to detect failures on any of the path permutations is required. Where the spreading mechanism is payload specific, payloads need to have forwarding that is common with the traffic under test. Satisfying these requirements introduces complexity into ensuring that ECMP connectivity permutations are exercised and that defect detection occurs in a reasonable amount of time.
OAM数据包必须严格遵循客户数据路径，以反映客户数据使用的路径活跃性。感兴趣的特定情况是转发机制，例如运营商网络中的ECMP场景，其中流在并行路径上共享负载（即，相等的IGP成本）。当客户流量可能分布在多条路径上时，需要能够检测任何路径排列上的故障。如果扩展机制是特定于有效负载的，则有效负载需要具有与被测业务相同的转发。满足这些要求会增加复杂性，从而确保执行ECMP连接置换，并在合理的时间内进行缺陷检测。
The ability to diagnose a broken LSP and to isolate the failed component (i.e., link or node) in the path is required. For example, note that specifying recovery actions for mis-branching defects in an LDP network is a particularly difficult case. Diagnosis of defects and isolation of the failed component is best accomplished via a path trace function that can return the entire list of LSRs and links used by a certain LSP (or at least the set of LSRs/links up to the location of the defect). The tracing capability SHOULD include the ability to trace recursive paths, such as when nested LSPs are used. This path trace function MUST also be capable of diagnosing LSP mis-merging by permitting comparison of expected vs. actual forwarding behavior at any LSR in the path. The path trace capability SHOULD be capable of being executed from the head-end Label Switching Router (LSR) and may permit downstream path components to be traced from an intermediate mid-point LSR. Additionally, the path trace function MUST have the ability to support ECMP scenarios described in Section 4.1.
需要能够诊断损坏的LSP并隔离路径中的故障组件（即链路或节点）。例如，请注意，为LDP网络中的错误分支缺陷指定恢复操作是一个特别困难的情况。故障诊断和故障部件隔离最好通过路径跟踪功能来完成，该功能可以返回特定LSP使用的LSR和链路的完整列表（或至少返回到故障位置的LSR/链路集）。跟踪功能应该包括跟踪递归路径的功能，例如当使用嵌套LSP时。此路径跟踪功能还必须能够通过允许比较路径中任何LSR处的预期转发行为与实际转发行为来诊断LSP错误合并。路径跟踪能力应能够从前端标签交换路由器（LSR）执行，并允许从中间点LSR跟踪下游路径组件。此外，路径跟踪功能必须能够支持第4.1节中描述的ECMP场景。
The path characterization function is the ability to reveal details of LSR forwarding operations. These details can then be compared during subsequent testing relevant to OAM functionality. This includes but is not limited to:
路径表征功能能够揭示LSR转发操作的细节。然后，可以在与OAM功能相关的后续测试期间比较这些详细信息。这包括但不限于：
- consistent use of pipe or uniform time to live (TTL) models by an LSR [RFC3443].
- LSR一致使用管道或统一生存时间（TTL）模型[RFC3443]。
- sufficient details that allow the test origin to exercise all path permutations related to load spreading (e.g., ECMP).
- 足够详细的信息，允许测试原点执行与负载扩展相关的所有路径排列（例如ECMP）。
- stack operations performed by the LSR, such as pushes, pops, and TTL propagation at penultimate hop LSRs.
- LSR执行的堆栈操作，如倒数第二跳LSR的推送、pops和TTL传播。
Mechanisms are required to measure the diverse aspects of Service Level Agreements, which include:
需要各种机制来衡量服务级别协议的各个方面，其中包括：
- latency - amount of time required for traffic to transit the network
- 延迟-流量通过网络所需的时间量
- packet loss
- 丢包
- jitter - measurement of latency variation
- 抖动-延迟变化的测量
- defect free forwarding - the service is considered to be available, or the service is unavailable and other aspects of performance measurement do not have meaning.
- 无缺陷转发-服务被视为可用，或服务不可用，而性能度量的其他方面没有意义。
Such measurements can be made independently of the user traffic or via a hybrid of user traffic measurement and OAM probing.
这样的测量可以独立于用户流量进行，或者通过用户流量测量和OAM探测的混合进行。
At least one mechanism is required to measure the number of OAM packets. In addition, the ability to measure the quantitative aspects of LSPs, such as jitter, delay, latency, and loss, MUST be available in order to determine whether the traffic for a specific LSP is traveling within the operator-specified tolerances.
至少需要一种机制来测量OAM数据包的数量。此外，为了确定特定LSP的流量是否在运营商规定的公差范围内移动，必须具备测量LSP定量方面（如抖动、延迟、延迟和丢失）的能力。
Any method considered SHOULD be capable of measuring the latency of an LSP with minimal impact on network resources. See Section 2.1 for definitions of the various quantitative aspects of LSPs.
所考虑的任何方法都应该能够在对网络资源影响最小的情况下测量LSP的延迟。LSP各定量方面的定义见第2.1节。
The operator MUST have the flexibility to configure OAM parameters to meet their specific operational requirements.
运营商必须具有配置OAM参数的灵活性，以满足其特定的运营要求。
This includes the frequency of the execution of any OAM functions. The ability to synchronize OAM operations is required to permit a consistent measurement of service level agreements. To elaborate, there are defect conditions, such as mis-branching or misdirection of traffic, for which probe-based detection mechanisms that incur significant mismatches in their detection frequency may result in flapping. This can be addressed either by synchronizing the rate or having the probes self-identify their probe rate. For example, when the probing mechanisms are bootstrapping, they might negotiate and ultimately agree on a probing rate, therefore providing a consistent probing frequency and avoiding the aforementioned problems.
这包括任何OAM功能的执行频率。同步OAM操作的能力是允许一致测量服务级别协议所必需的。更详细地说，存在缺陷条件，例如错误的分支或错误的流量方向，对于这些缺陷条件，基于探针的检测机制会导致其检测频率的严重不匹配，从而导致抖动。这可以通过同步速率或让探测器自行识别其探测速率来解决。例如，当探测机制处于自举状态时，它们可能会协商并最终商定探测速率，从而提供一致的探测频率并避免上述问题。
One observation would be that wide-spread deployment of MPLS, common implementation of monitoring tools, and the need for inter-carrier synchronization of defect and service level specification handling will drive specification of OAM parameters to commonly agreed on values. Such values will have to be harmonized with the surrounding technologies (e.g., SONET/SDH, ATM) to be useful. This will become particularly important as networks scale and mis-configuration can result in churn, alarm flapping, etc.
一个观察结果是，MPLS的广泛部署、监控工具的通用实现以及缺陷和服务级别规范处理的载波间同步需求将促使OAM参数的规范达到共同商定的值。这些值必须与周围的技术（如SONET/SDH、ATM）协调，才能发挥作用。这将变得特别重要，因为网络规模和错误配置可能导致客户流失、警报抖动等。
Network elements MUST provide alarm suppression functionality that prevents the generation of a superfluous generation of alarms by simply discarding them (or not generating them in the first place), or by aggregating them together, thereby greatly reducing the number of notifications emitted. When viewed in conjunction with the requirement in Section 4.7 below, this typically requires fault notification to the LSP egress that may have specific time constraints if the application using the LSP independently implements path continuity testing (for example, ATM I.610 Continuity check (CC)[I610]). These constraints apply to LSPs that are monitored. The nature of MPLS applications allows for the possibility of having multiple MPLS applications attempt to respond to defects simultaneously, e.g., layer-3 MPLS VPNs that utilize Traffic Engineered tunnels where a failure occurs on the LSP carrying the Traffic Engineered tunnel. This failure would affect the VPN traffic that uses the tunnel's LSP. Mechanisms are required to coordinate network responses to defects.
网络元件必须提供报警抑制功能，通过简单地丢弃报警（或不首先生成报警）或将其聚合在一起，从而大大减少发出的通知数量，从而防止生成多余的报警。当结合下面第4.7节中的要求查看时，这通常需要向LSP出口发出故障通知，如果使用LSP的应用程序独立地执行路径连续性测试（例如，ATM I.610连续性检查（CC）[I610]），则LSP出口可能具有特定的时间限制。这些约束适用于受监视的LSP。MPLS应用程序的性质允许多个MPLS应用程序尝试同时响应缺陷的可能性，例如，第3层MPLS VPN利用流量工程隧道，其中在承载流量工程隧道的LSP上发生故障。此故障将影响使用隧道LSP的VPN流量。需要机制来协调网络对缺陷的响应。
An LSR supporting the inter-working of one or more networking technologies over MPLS MUST be able to translate an MPLS defect into the native technology's error condition. For example, errors occurring over an MPLS transport LSP that supports an emulated ATM VC MUST translate errors into native ATM OAM Alarm Indication Signal (AIS) cells at the termination points of the LSP. The mechanism SHOULD consider possible bounded detection time parameters, e.g., a "hold off" function before reacting to synchronize with the OAM functions.
支持MPLS上一种或多种网络技术交互工作的LSR必须能够将MPLS缺陷转化为本机技术的错误状况。例如，在支持模拟ATM VC的MPLS传输LSP上发生的错误必须在LSP的终止点将错误转换为本机ATM OAM报警指示信号（AIS）信元。该机制应考虑可能的有界检测时间参数，例如，在与OAM功能同步之前，先进行“暂存”功能。
One goal would be alarm suppression by the upper layer using the LSP. As observed in Section 4.5, this requires that MPLS perform detection in a bounded timeframe in order to initiate alarm suppression prior to the upper layer independently detecting the defect.
一个目标是上层使用LSP抑制报警。如第4.5节所述，这要求MPLS在限定的时间范围内执行检测，以便在上层独立检测缺陷之前启动报警抑制。
Recovery from a fault by a network element can be facilitated by MPLS OAM procedures. These procedures will detect a broader range of defects than that of simple link and node failures. Since MPLS LSPs may span multiple routing areas and service provider domains, fault recovery and error detection should be possible in these configurations as well as in the more simplified single-area/domain configurations.
通过MPLS OAM过程，可以促进网元从故障中恢复。这些程序将检测到比简单链路和节点故障更广泛的缺陷。由于MPLS LSP可能跨越多个路由区域和服务提供商域，因此在这些配置以及更简化的单区域/域配置中，故障恢复和错误检测应该是可能的。
Recovery from faults SHOULD be automatic. It is a requirement that faults SHOULD be detected (and possibly corrected) by the network operator prior to customers of the service in question detecting them.
故障恢复应该是自动的。要求网络运营商在相关服务的客户检测到故障之前检测（并可能纠正）故障。
The wide-spread deployment of MPLS requires common information modeling of management and control of OAM functionality. Evidence of this is reflected in the standard IETF MPLS-related MIB modules (e.g., [RFC3813][RFC3812][RFC3814]) for fault, statistics, and configuration management. These standard interfaces provide operators with common programmatic interface access to Operations and Management functions and their statuses. However, gaps in coverage of MIB modules to OAM and other features exist; therefore, MIB modules corresponding to new protocol functions or network tools are required.
MPLS的广泛部署要求对OAM功能的管理和控制进行公共信息建模。故障、统计和配置管理的标准IETF MPLS相关MIB模块（例如，[RFC3813][RFC3812][RFC3814]）反映了这一点。这些标准接口为操作员提供对操作和管理功能及其状态的公共编程接口访问。然而，MIB模块对OAM和其他功能的覆盖范围存在差距；因此，需要与新协议功能或网络工具相对应的MIB模块。
The ability to detect denial of service (DoS) attacks against the data or control planes MUST be part of any security management related to MPLS OAM tools or techniques.
检测针对数据或控制平面的拒绝服务（DoS）攻击的能力必须是与MPLS OAM工具或技术相关的任何安全管理的一部分。
In an MPLS network, service providers can measure traffic from an LSR to the egress of the network using some MPLS related MIBs, for example. This means that it is reasonable to know how much traffic is traveling from location to location (i.e., a traffic matrix) by analyzing the flow of traffic. Therefore, traffic accounting in an MPLS network can be summarized as the following three items:
在MPLS网络中，例如，服务提供商可以使用一些与MPLS相关的mib来测量从LSR到网络出口的流量。这意味着，通过分析交通流，了解从一个位置到另一个位置（即交通矩阵）的交通量是合理的。因此，MPLS网络中的流量计费可以概括为以下三项：
(1) Collecting information to design network
(1) 收集信息设计网络
For the purpose of optimized network design, a service provider may offer the traffic information. Optimizing network design needs this information.
为了优化网络设计，服务提供商可以提供流量信息。优化网络设计需要这些信息。
(2) Providing a Service Level Specification
(2) 提供服务级别规范
Providers and their customers MAY need to verify high-level service level specifications, either to continuously optimize their networks, or to offer guaranteed bandwidth services. Therefore, traffic accounting to monitor MPLS applications is required.
提供商及其客户可能需要验证高级服务级别规范，以持续优化其网络，或提供有保证的带宽服务。因此，需要使用流量计费来监控MPLS应用程序。
(3) Inter-AS environment
(3) 内部AS环境
Service providers that offer inter-AS services require accounting of those services.
提供内部AS服务的服务提供商需要对这些服务进行核算。
These three motivations need to satisfy the following:
这三个动机需要满足以下要求：
- In (1) and (2), collection of information on a per-LSP basis is a minimum level of granularity for collecting accounting information at both of ingress and egress of an LSP.
- 在（1）和（2）中，基于每个LSP的信息收集是在LSP入口和出口收集会计信息的最小粒度级别。
- In (3), SP's ASBR carry out interconnection functions as an intermediate LSR. Therefore, identifying a pair of ingress and egress LSRs using each LSP is needed to determine the cost of the service that a customer is using.
- 在（3）中，SP的ASBR作为中间LSR执行互连功能。因此，需要使用每个LSP识别一对入口和出口lsr来确定客户正在使用的服务的成本。
Accounting on a per-LSP basis encompasses the following set of functions:
按LSP记账包括以下一组功能：
(1) At an ingress LSR, accounting of traffic through LSPs that begin at each egress in question.
(1) 在入口LSR处，通过LSP的流量核算，该LSP从所讨论的每个出口开始。
(2) At an intermediate LSR, accounting of traffic through LSPs for each pair of ingress to egress.
(2) 在中间LSR，对每对进出口通过LSP的流量进行核算。
(3) At egress LSR, accounting of traffic through LSPs for each ingress.
(3) 在出口LSR处，对每个入口通过LSP的流量进行核算。
(4) All LSRs containing LSPs that are being measured need to have a common identifier to distinguish each LSP. The identifier MUST be unique to each LSP, and its mapping to LSP SHOULD be provided whether from manual or automatic configuration.
(4) 所有包含正在测量的LSP的LSR都需要有一个公共标识符来区分每个LSP。标识符对于每个LSP都必须是唯一的，无论是手动配置还是自动配置，都应提供其到LSP的映射。
In the case of non-merged LSPs, this can be achieved by simply reading traffic counters for the label stack associated with the LSP at any LSR along its path. However, in order to measure merged LSPs, an LSR MUST have a means to distinguish the source of each flow so as to disambiguate the statistics.
在非合并LSP的情况下，这可以通过简单地读取与LSP路径上任何LSR处的LSP相关联的标签堆栈的流量计数器来实现。然而，为了测量合并的LSP，LSR必须有一种方法来区分每个流的来源，以便消除统计数据的歧义。
It is not realistic for LSRs to perform the described operations on all LSPs that exist in a network. At a minimum, per-LSP based accounting SHOULD be performed on the edges of the network -- at the edges of both LSPs and the MPLS domain.
LSR在网络中存在的所有LSP上执行所述操作是不现实的。至少，基于每LSP的计费应该在网络边缘执行——在LSP和MPLS域的边缘。
Provisions to any of the network mechanisms designed to satisfy the requirements described herein are required to prevent their unauthorized use. Likewise, these network mechanisms MUST provide a means by which an operator can prevent denial of service attacks if those network mechanisms are used in such an attack.
需要对任何设计为满足本文所述要求的网络机制作出规定，以防止其未经授权的使用。同样，这些网络机制必须提供一种手段，如果在此类攻击中使用这些网络机制，则运营商可以通过这种手段防止拒绝服务攻击。
LSP mis-merging has security implications beyond that of simply being a network defect. LSP mis-merging can happen due to a number of potential sources of failure, some of which (due to MPLS label stacking) are new to MPLS.
LSP错误合并的安全影响不仅仅是网络缺陷。LSP错误合并可能是由于许多潜在的故障源造成的，其中一些（由于MPLS标签堆叠）是MPLS所不熟悉的。
The performance of diagnostic functions and path characterization involve extracting a significant amount of information about network construction that the network operator MAY consider private.
诊断功能和路径特性的性能涉及提取网络运营商可以考虑私有的关于网络构建的大量信息。
[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月。
[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月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）标签交换路由器（LSR）管理信息库（MIB）”，RFC 38132004年6月。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004.
[RFC3814]Nadeau，T.，Srinivasan，C.，和A.Viswanathan，“多协议标签交换（MPLS）转发等价类到下一跳标签转发条目（FEC到NHLFE）管理信息库（MIB）”，RFC 3814，2004年6月。
[Y1710] ITU-T Recommendation Y.1710, "Requirements for OAM Functionality In MPLS Networks"
[Y1710]ITU-T建议Y.1710，“MPLS网络中的OAM功能要求”
[I610] ITU-T Recommendation I.610, "B-ISDN operations and maintenance principles and functions", February 1999
[I610]ITU-T建议I.610，“B-ISDN操作和维护原则及功能”，1999年2月
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
The authors wish to acknowledge and thank the following individuals for their valuable comments to this document: Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. Ikejiri, NTT Communications; and Mr. Kumaki, KDDI. Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan Fang, AT&T; Danny McPherson, TCB; Dr. Ken Nagami, Ikuo Nakagawa, Intec Netcore, and David Meyer.
作者希望感谢以下个人对本文件的宝贵意见：Adrian Smith，英国电信；周兰博,SBC,；Ikejiri先生，NTT通信公司；和KDDI Kumaki先生。Hari Rakotoranto、Miya Kohno、思科系统公司；美国电话电报公司(AT&T)方绿园,；丹尼·麦克弗森，TCB；Ken Nagami博士、Ikuo Nakagawa、Intec Netcore和David Meyer。
Authors' Addresses
作者地址
Comments should be made directly to the MPLS mailing list at mpls@lists.ietf.org.
应直接向MPLS邮件列表提出意见，地址为mpls@lists.ietf.org.
Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719
Thomas D.Nadeau Cisco Systems，Inc.马萨诸塞州Boxboro市比弗布鲁克路300号，邮编01719
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Monique Jeanne Morrow Cisco Systems, Inc. Glatt-Com, 2nd Floor CH-8301 Switzerland
Monique Jeanne Morrow思科系统有限公司Glatt Com二楼瑞士CH-8301
Phone: (0)1 878-9412 EMail: mmorrow@cisco.com
电话：（0）1878-9412电子邮件：mmorrow@cisco.com
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719
乔治·斯沃诺思科系统公司，地址：马萨诸塞州博克斯博罗市比弗布鲁克路300号，邮编01719
Phone: +1-978-936-1398
EMail: swallow@cisco.com
Phone: +1-978-936-1398
EMail: swallow@cisco.com
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
加拿大安大略省渥太华卡林大道3500号北电网络公司
Phone: 1-613-763-6362 EMail: dallan@nortel.com
电话：1-613-763-6362电子邮件：dallan@nortel.com
Satoru Matsushima Japan Telecom 1-9-1, Higashi-Shinbashi, Minato-ku Tokyo, 105-7316 Japan
松岛佐藤日本电信1-9-1，东新桥，东京弥敦区，105-7316
Phone: +81-3-6889-1092
EMail: satoru@ft.solteria.net
Phone: +81-3-6889-1092
EMail: satoru@ft.solteria.net
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）提供。