Network Working Group D. Allan, Ed.
Request for Comments: 4378 Nortel Networks
Category: Informational T. Nadeau, Ed.
Cisco Systems, Inc.
February 2006
Network Working Group D. Allan, Ed.
Request for Comments: 4378 Nortel Networks
Category: Informational T. Nadeau, Ed.
Cisco Systems, Inc.
February 2006
A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)
多协议标签交换（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 is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching (MPLS). The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS.
本文档是如何将数据平面协议应用于多协议标签交换（MPLS）的操作和维护过程的框架。本文档的结构旨在概述如何使用操作和管理（OAM）功能来帮助进行故障、配置、记帐、性能和安全管理（通常称为FCAPS）。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Fault Management ................................................2
3.1. Fault Detection ............................................2
3.2. Diagnosis ..................................................6
3.3. Availability ...............................................7
4. Configuration Management ........................................7
5. Accounting ......................................................7
6. Performance Management ..........................................7
7. Security Management .............................................8
8. Security Considerations .........................................9
9. Acknowledgements ................................................9
10. Normative References ...........................................9
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Fault Management ................................................2
3.1. Fault Detection ............................................2
3.2. Diagnosis ..................................................6
3.3. Availability ...............................................7
4. Configuration Management ........................................7
5. Accounting ......................................................7
6. Performance Management ..........................................7
7. Security Management .............................................8
8. Security Considerations .........................................9
9. Acknowledgements ................................................9
10. Normative References ...........................................9
This memo outlines in broader terms how data plane protocols can assist in meeting the Operations and Management (OAM) requirements outlined in [RFC4377] and [Y1710] and can apply to the management functions of fault, configuration, accounting, performance, and security (commonly known as FCAPS) for MPLS networks, as defined in [RFC3031]. The approach of the document is to outline functionality, the potential mechanisms to provide the function, and the required applicability of data plane OAM functions. Included in the discussion are security issues specific to use of tools within a provider domain and use for inter-provider Label Switched Paths (LSPs).
本备忘录从更广泛的角度概述了数据平面协议如何有助于满足[RFC4377]和[Y1710]中概述的运营和管理（OAM）要求，以及如何应用于[RFC3031]中定义的MPLS网络故障、配置、计费、性能和安全（通常称为FCAP）的管理功能。本文档的方法是概述功能、提供该功能的潜在机制以及数据平面OAM功能所需的适用性。讨论中包括特定于在提供程序域中使用工具和用于提供程序间标签交换路径（LSP）的安全问题。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
OAM Operations and Management
OAM运营和管理
FCAPS Fault management, Configuration management, Administration management, Performance management, and Security management
FCAPS故障管理、配置管理、管理管理、性能管理和安全管理
FEC Forwarding Equivalence Class
转发等价类
ILM Incoming Label Map
ILM传入标签映射
NHLFE Next Hop Label Forwarding Entry
NHLFE下一跳标签转发条目
MIB Management Information Base
MIB管理信息库
LSR Label Switching Router
标签交换路由器
RTT Round Trip Time
RTT往返时间
Fault detection encompasses the identification of all data plane failures between the ingress and egress of an LSP. This section will enumerate common failure scenarios and explain how one might (or might not) detect the situation.
故障检测包括识别LSP入口和出口之间的所有数据平面故障。本节将列举常见的故障场景，并解释如何检测（或不检测）这种情况。
Lower-layer faults:
下层断层：
Lower-layer faults are those in the physical or virtual link that impact the transport of MPLS labeled packets between adjacent LSRs at the specific level of interest. Some physical links (such as SONET/SDH) may have link-layer OAM functionality and detect and notify the LSR of link-layer faults directly. Some physical links (such as Ethernet) may not have this capability and require MPLS or IP layer heartbeats to detect failures. However, once detected, reaction to these fault notifications is often the same as those described in the first case.
较低层故障是指物理或虚拟链路中的故障，这些故障影响在特定关注级别的相邻LSR之间传输MPLS标记的数据包。某些物理链路（如SONET/SDH）可能具有链路层OAM功能，并直接检测和通知LSR链路层故障。某些物理链路（如以太网）可能没有此功能，需要MPLS或IP层心跳来检测故障。但是，一旦检测到，对这些故障通知的反应通常与第一种情况中描述的相同。
Node failures:
节点故障：
Node failures are those that impact the forwarding capability of a node component, including its entire set of links. This can be due to component failure, power outage, or reset of the control processor in an LSR employing a distributed architecture, etc.
节点故障是指影响节点组件（包括其整个链路集）转发能力的故障。这可能是由于采用分布式体系结构的LSR中的组件故障、断电或控制处理器复位等造成的。
MPLS LSP mis-forwarding:
MPLS LSP错误转发：
Mis-forwarding occurs when there is a loss of synchronization between the data and the control planes in one or more nodes. This can occur due to hardware failure, software failure, or configuration problems.
当一个或多个节点中的数据和控制平面之间失去同步时，会发生错误转发。这可能是由于硬件故障、软件故障或配置问题造成的。
It will manifest itself in one of two forms:
它将以两种形式之一表现出来：
- packets belonging to a particular LSP are cross-connected into an NHLFE for which there is no corresponding ILM at the next downstream LSR. This can occur in cases where the NHLFE entry is corrupted. Therefore, the packet arrives at the next LSR with a top label value for which the LSR has no corresponding forwarding information, and is typically dropped. This is a No Incoming Label Map (No ILM) condition and can be detected directly by the downstream LSR that receives the incorrectly labeled packet.
- 属于特定LSP的数据包交叉连接到NHLFE中，在下一个下游LSR没有相应的ILM。这可能发生在NHLFE条目损坏的情况下。因此，数据包到达下一个LSR时具有顶部标签值，对于该标签值，LSR没有相应的转发信息，并且通常被丢弃。这是一种无输入标签映射（无ILM）情况，可由接收错误标签数据包的下游LSR直接检测。
- packets belonging to a particular LSP are cross-connected into an incorrect NHLFE entry for which there is a corresponding ILM at the next downstream LSR, but is associated with a different LSP. This may be detected by the following:
- 属于特定LSP的数据包交叉连接到不正确的NHLFE条目中，该条目在下一个下游LSR处有相应的ILM，但与不同的LSP关联。这可通过以下方式检测到：
o some or all of the misdirected traffic is not routable at the egress node, or
o 部分或全部错误定向的流量在出口节点处不可路由，或
o OAM probing is able to detect the fault by detecting the inconsistency between the data path and the control plane state.
o OAM探测能够通过检测数据路径和控制平面状态之间的不一致性来检测故障。
Discontinuities in the MPLS Encapsulation
MPLS封装中的不连续性
The forwarding path of the FEC carried by an LSP may transit nodes or links for which MPLS is not configured. This may result in a number of behaviors that are undesirable and not easily detected.
LSP承载的FEC的转发路径可以传输未配置MPLS的节点或链路。这可能导致许多不受欢迎且不易检测的行为。
- if exposed, payload is not routable at the LSR, resulting in silent discard, OR
- 如果暴露，有效负载在LSR处不可路由，导致无声丢弃，或
- the exposed MPLS label was not offered by the LSR, which may result in either silent discard or mis-forwarding.
- LSR未提供公开的MPLS标签，这可能导致静默丢弃或错误转发。
Alternately, the payload may be routable and packets successfully delivered but may bypass associated MPLS instrumentation and tools.
或者，有效载荷可以是可路由的，并且分组可以成功交付，但是可以绕过相关的MPLS仪器和工具。
MTU problems
MTU问题
MTU problems occur when client traffic cannot be fragmented by intermediate LSRs and is dropped somewhere along the path of the LSP. MTU problems should appear as a discrepancy in the traffic count between the set of ingress LSRs and the egress LSRs for an FEC and will appear in the corresponding MPLS MIB performance tables in the transit LSRs as discarded packets.
当客户端流量不能被中间LSR分段，并沿着LSP路径的某个位置丢弃时，就会出现MTU问题。MTU问题应表现为FEC的入口LSR集和出口LSR之间的流量计数不一致，并将作为丢弃的数据包出现在传输LSR的相应MPLS MIB性能表中。
TTL Mishandling
错误处理
The implementation of TTL handling is inconsistent at penultimate hop LSRs. Tools that rely on consistent TTL processing may produce inconsistent results in any given network.
TTL处理的实现在倒数第二跳LSR上不一致。依赖一致TTL处理的工具可能在任何给定网络中产生不一致的结果。
Congestion
拥塞
Congestion occurs when the offered load on any interface exceeds the link capacity for sufficient time that the interface buffering is exhausted. Congestion problems will appear as a discrepancy in the traffic count between the set of ingress LSRs and the egress LSRs for an FEC and will appear in the MPLS MIB performance tables in the transit LSRs as discarded packets.
当任何接口上提供的负载超过链路容量足够长的时间，接口缓冲耗尽时，就会发生拥塞。拥塞问题将以FEC的入口LSR集和出口LSR之间的流量计数不一致的形式出现，并将作为丢弃的数据包出现在传输LSR的MPLS MIB性能表中。
Mis-ordering
错序
Mis-ordering of LSP traffic occurs when incorrect or inappropriate load sharing is implemented within an MPLS network. Load sharing typically takes place when multiple equal-cost paths exist between the ingress and egress of an LSP. In these cases, traffic is split among these equal-cost paths using a variety of algorithms. One such algorithm relies on splitting traffic between each path on a per-packet basis. When this is done, it is possible for some packets along the path to be delayed due to congestion or slower links, which may result in packets being received out of order at the egress. Detection and remedy of this situation may be left up to client applications that use the LSPs. For instance, TCP is capable of re-ordering packets belonging to a specific flow (although this may result in re-transmission of some of the mis-ordered packets).
当在MPLS网络中实现不正确或不适当的负载共享时，会发生LSP流量的错误排序。负载共享通常在LSP的入口和出口之间存在多个等成本路径时发生。在这些情况下，使用各种算法在这些成本相等的路径之间分配流量。一种这样的算法依赖于在每个分组的基础上在每个路径之间分割流量。当完成此操作时，路径上的一些分组可能由于拥塞或较慢的链路而被延迟，这可能导致分组在出口处被无序接收。这种情况的检测和补救可能由使用LSP的客户端应用程序决定。例如，TCP能够对属于特定流的数据包进行重新排序（尽管这可能会导致重新传输一些错误排序的数据包）。
Detection of mis-ordering can also be determined by sending probe traffic along the path and verifying that all probe traffic is indeed received in the order it was transmitted. This will only detect truly pathological problems as mis-ordering typically is an insufficiently predictable and repeatable problem.
还可以通过沿路径发送探测通信量并验证所有探测通信量确实按照发送顺序接收来确定是否存在误序。这将只检测真正的病理问题，因为错误排序通常是一个不可预测和可重复的问题。
LSRs do not normally implement mechanisms to detect mis-ordering of flows.
LSR通常不会实现检测流错误排序的机制。
Payload Corruption
有效负载损坏
Payload corruption may occur and may be undetected by LSRs. Such errors are typically detected by client payload integrity mechanisms.
负载损坏可能会发生，并且可能不会被LSR检测到。此类错误通常由客户端有效负载完整性机制检测。
The design of Service Level Agreements (SLAs) and management support systems requires that ample headroom be alloted in terms of their processing capabilities in order to process and handle all necessary fault conditions within the bounds stipulated in the SLA. This includes planning for event handling using a time budget that takes into account the over-all SLA and the time required to address any defects that arise. However, it is possible that some fault conditions may surpass this budget due to their catastrophic nature (e.g., fibre cut) or due to incorrect planning of the time processing budget.
服务水平协议（SLA）和管理支持系统的设计要求在其处理能力方面分配充足的净空，以便在SLA规定的范围内处理和处理所有必要的故障条件。这包括使用时间预算来规划事件处理，该预算考虑了总体SLA和解决出现的任何缺陷所需的时间。但是，由于灾难性（例如，纤维切割）或时间处理预算规划不正确，某些故障条件可能会超过此预算。
^ --------------
| | ^
| | |---- Time to notify NOC + process/correct
SLA | | v defect
Max - | -------------
Time | | ^
| | |----- Time to diagnose/isolate/correct
| | v
v -------------
^ --------------
| | ^
| | |---- Time to notify NOC + process/correct
SLA | | v defect
Max - | -------------
Time | | ^
| | |----- Time to diagnose/isolate/correct
| | v
v -------------
Figure 1: Fault Correction Budget
图1：故障修正预算
In figure 1, we represent the overall fault correction time budget by the maximum time as specified in an SLA for the service in question. This time is then divided into two subsections, the first encompassing the total time required to detect a fault and notify an operator (or optionally automatically correct the defect). This section may have an explicit maximum time to detect defects arising from either the application or a need to do alarm management (i.e., suppression), and this will be reflected in the frequency of OAM execution. The second section indicates the time required to notify the operational systems used to diagnose, isolate, and correct the defect (if they cannot be corrected automatically).
在图1中，我们用SLA中为所讨论的服务指定的最大时间来表示整个故障纠正时间预算。然后将该时间分为两个小节，第一小节包含检测故障和通知操作员（或可选地自动纠正缺陷）所需的总时间。本节可能有明确的最长时间来检测由应用程序或需要进行报警管理（即抑制）引起的缺陷，这将反映在OAM执行的频率中。第二部分说明了通知用于诊断、隔离和纠正缺陷的操作系统所需的时间（如果无法自动纠正）。
Characterization is defined as determining the forwarding path of a packet (which may not be necessarily known). Characterization may be performed on a working path through the network. For example, this is done to determine equal-cost multi-paths (ECMP), the MTU of a path, or simply to know the path occupied by a specific FEC. Characterization will be able to leverage mechanisms used for isolation.
特征化定义为确定分组的转发路径（不一定已知）。可以在通过网络的工作路径上执行特征化。例如，这样做是为了确定等成本多路径（ECMP）、路径的MTU，或者只是为了知道特定FEC占用的路径。表征将能够利用用于隔离的机制。
Isolation of a fault can occur in two forms. In the first case, the local failure is detected, and the node where the failure occurred is capable of issuing an alarm for such an event. The node should attempt to withdraw the defective resources and/or rectify the situation prior to raising an alarm. Active data plane OAM mechanisms may also detect the failure conditions remotely and issue their own alarms if the situation is not rectified quickly enough.
故障隔离有两种形式。在第一种情况下，检测到本地故障，并且发生故障的节点能够针对此类事件发出警报。在发出警报之前，节点应尝试撤回有缺陷的资源和/或纠正情况。主动数据平面OAM机制还可以远程检测故障条件，并在情况没有得到足够快的纠正时发出自己的警报。
In the second case, the fault has not been detected locally. In this case, the local node cannot raise an alarm, nor can it be expected to
在第二种情况下，未在本地检测到故障。在这种情况下，本地节点不能发出警报，也不能期望发出警报
rectify the situation. In this case, the failure may be detected remotely via data plane OAM. This mechanism should also be able to determine the location of the fault, perhaps on the basis of limited information such as a customer complaint. This mechanism may also be able to automatically remove the defective resources from the network and restore service, but should at least provide a network operator with enough information by which they can perform this operation. Given that detection of faults is desired to happen as quickly as possible, tools which possess the ability to incrementally test LSP health should be used to uncover faults.
纠正这种情况。在这种情况下，可通过数据平面OAM远程检测故障。该机制还应能够确定故障的位置，可能是基于有限的信息，如客户投诉。此机制还可以自动从网络中删除有缺陷的资源并恢复服务，但至少应为网络运营商提供足够的信息，以便他们执行此操作。鉴于希望尽快检测到故障，因此应使用能够增量测试LSP运行状况的工具来发现故障。
Availability is the measure of the percentage of time that a service is operating within a specification, often specified by an SLA.
可用性是服务在规范内运行的时间百分比的度量，通常由SLA指定。
MPLS has several forwarding modes (depending on the control plane used). As such, more than one model may be defined and more than one measurement technique may be required.
MPLS有几种转发模式（取决于所使用的控制平面）。因此，可以定义多个模型，并且可能需要多个测量技术。
Data plane OAM can assist in configuration management by providing the ability to verify the configuration of an LSP or of applications utilizing that LSP. This would be an ad-hoc data plane probe that should verify path integrity (a complete path exists) and that the path function is synchronized with the control plane. As part of the payload, the probe would carry relevant control plane information that the receiver would be able to compare with the local-control plane configuration.
数据平面OAM可以通过提供验证LSP或使用该LSP的应用程序的配置的能力来协助配置管理。这将是一个特殊的数据平面探测器，它应该验证路径完整性（存在完整的路径）以及路径功能是否与控制平面同步。作为有效载荷的一部分，探测器将携带相关的控制平面信息，接收器将能够与本地控制平面配置进行比较。
The requirements for accounting in MPLS networks, as specified in [RFC4377], do not place any requirements on data plane OAM.
[RFC4377]中规定的MPLS网络计费要求对数据平面OAM没有任何要求。
Performance management permits the information transfer characteristics of LSPs to be measured, perhaps in order to be compared against an SLA. This falls into two categories: latency (where jitter is considered a variation in latency) and information loss.
性能管理允许测量LSP的信息传输特性，也许是为了与SLA进行比较。这分为两类：延迟（抖动被认为是延迟的一种变化）和信息丢失。
Latency can be measured in two ways: one is to have precisely synchronized clocks at the ingress and egress such that time-stamps in PDUs flowing from the ingress to the egress can be compared. The other is to use an exchange of PING type PDUs that gives a round trip
延迟可以通过两种方式测量：一种是在入口和出口处精确同步时钟，以便可以比较从入口到出口的PDU中的时间戳。另一种是使用交换的PING类型的pdu，提供一个往返
time (RTT) measurement, and an estimate of the one-way latency that can be inferred with some loss of precision. Use of load spreading techniques, such as ECMP, mean that any individual RTT measurement is only representative of the typical RTT for an FEC.
时间（RTT）测量，以及在一定精度损失的情况下可以推断的单向延迟估计。使用负载分散技术，如ECMP，意味着任何单个RTT测量值仅代表FEC的典型RTT。
To measure information loss, a common practice is to periodically read ingress and egress counters (i.e., MIB module counters). This information may also be used for offline correlation. Another common practice is to send explicit probe traffic that traverses the data plane path in question. This probe traffic can also be used to measure jitter and delay.
为了测量信息丢失，通常的做法是定期读取入口和出口计数器（即MIB模块计数器）。此信息也可用于脱机关联。另一种常见的做法是发送穿越相关数据平面路径的显式探测通信量。该探测流量还可用于测量抖动和延迟。
Providing a secure OAM environment is required if MPLS specific network mechanisms are to be used successfully. To this end, operators have a number of options when deploying network mechanisms including simply filtering OAM messages at the edge of the MPLS network. Malicious users should not be able to use non-MPLS interfaces to insert MPLS-specific OAM transactions. Provider initiated OAM transactions should be able to be blocked from leaking outside the MPLS cloud.
如果要成功使用MPLS特定的网络机制，就需要提供安全的OAM环境。为此，运营商在部署网络机制时有许多选择，包括在MPLS网络边缘简单地过滤OAM消息。恶意用户不能使用非MPLS接口插入MPLS特定的OAM事务。提供商发起的OAM事务应该能够被阻止泄漏到MPLS云之外。
Finally, if a provider does wish to allow OAM messages to flow into (or through) their networks, for example, in a multi-provider deployment, authentication and authorization are required to prevent malicious and/or unauthorized access. Also, given that MPLS networks often run IP simultaneously, similar requirements apply to any native IP OAM network mechanisms in use. Therefore, authentication and authorization for OAM technologies is something that MUST be considered when designing network mechanisms that satisfy the framework presented in this document.
最后，如果提供商确实希望允许OAM消息流入（或通过）其网络，例如，在多提供商部署中，则需要身份验证和授权以防止恶意和/或未经授权的访问。此外，鉴于MPLS网络通常同时运行IP，类似的要求适用于正在使用的任何本机IP OAM网络机制。因此，在设计满足本文所述框架的网络机制时，必须考虑OAM技术的身份验证和授权。
OAM messaging can address some existing security concerns with the MPLS architecture. That is, through rigorous defect handling, operator's can offer their customers a greater degree of integrity protection that their traffic will not be incorrectly delivered (for example, by being able to detect leaking LSP traffic from a VPN).
OAM消息传递可以通过MPLS体系结构解决一些现有的安全问题。也就是说，通过严格的缺陷处理，运营商可以为其客户提供更大程度的完整性保护，使其流量不会被错误交付（例如，通过能够检测VPN泄漏的LSP流量）。
Support for inter-provider data plane OAM messaging introduces a number of security concerns as, by definition, portions of LSPs will not be within a single provider's network the provider has no control over who may inject traffic into the LSP, which can be exploited for denial of service attacks. OAM PDUs are not explicitly identified in the MPLS header and therefore are not typically inspected by transit LSRs. This creates opportunity for malicious or poorly behaved users to disrupt network operations.
对提供商间数据平面OAM消息传递的支持带来了许多安全问题，因为根据定义，LSP的部分将不在单个提供商的网络中。提供商无法控制谁可以向LSP注入流量，这可能会被利用来进行拒绝服务攻击。OAM PDU在MPLS报头中没有明确标识，因此通常不会由传输LSR进行检查。这为恶意或行为不良的用户提供了中断网络操作的机会。
Attempts to introduce filtering on target LSP OAM flows may be problematic if flows are not visible to intermediate LSRs. However, it may be possible to interdict flows on the return path between providers (as faithfulness to the forwarding path is to a return path requirement) to mitigate aspects of this vulnerability.
如果中间LSR看不到流，那么尝试在目标LSP OAM流上引入过滤可能会有问题。但是，可能会阻断提供者之间返回路径上的流（因为对转发路径的忠实性是对返回路径的要求），以缓解此漏洞的各个方面。
OAM tools may permit unauthorized or malicious users to extract significant amounts of information about network configuration. This would be especially true of IP based tools as, in many network configurations, MPLS does not typically extend to untrusted hosts, but IP does. For example, TTL hiding at ingress and egress LSRs will prevent external users from using TTL-based mechanisms to probe an operator's network. This suggests that tools used for problem diagnosis or which, by design, are capable of extracting significant amounts of information will require authentication and authorization of the originator. This may impact the scalability of such tools when employed for monitoring instead of diagnosis.
OAM工具可能允许未经授权或恶意用户提取有关网络配置的大量信息。这对于基于IP的工具尤其如此，因为在许多网络配置中，MPLS通常不会扩展到不受信任的主机，但IP会。例如，在入口和出口LSR处隐藏TTL将阻止外部用户使用基于TTL的机制来探测运营商的网络。这表明，用于问题诊断或设计上能够提取大量信息的工具将需要原始人的认证和授权。当用于监视而不是诊断时，这可能会影响此类工具的可伸缩性。
This document describes a framework for MPLS Operations and Management. Although this document discusses and addresses some security concerns in Section 7, it does not introduce any new security concerns.
本文档描述了MPLS操作和管理的框架。尽管本文件在第7节中讨论并解决了一些安全问题，但并未引入任何新的安全问题。
The editors would like to thank Monique Morrow from Cisco Systems and Harmen van Der Linde from AT&T for their valuable review comments on this document.
编辑们要感谢思科系统公司的莫妮克·莫罗和美国电话电报公司的哈门·范德林德对本文件的宝贵评论。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377]Nadeau，T.，Morrow，M.，Swallow，G.，Allan，D.，和S.Matsushima，“多协议标签交换（MPLS）网络的运营和管理（OAM）要求”，RFC 4377，2006年2月。
[Y1710] ITU-T Recommendation Y.1710(2002), "Requirements for OAM Functionality for MPLS Networks".
[Y1710]ITU-T建议Y.1710（2002），“MPLS网络的OAM功能要求”。
Authors' Addresses
作者地址
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
加拿大安大略省渥太华卡林大道3500号北电网络公司
Phone: +1-613-763-6362
EMail: dallan@nortel.com
Phone: +1-613-763-6362
EMail: dallan@nortel.com
Thomas D. Nadeau Cisco Systems 300 Beaver Brook Drive Boxborough, MA 01824
Thomas D.Nadeau思科系统公司马萨诸塞州博克斯伯勒市比弗布鲁克大道300号01824
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Phone: +1-978-936-1470
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）提供。