Network Working Group                                            H. Ohta
Request for Comments: 3429                                           NTT
Category: Informational                                    November 2002
        
Network Working Group                                            H. Ohta
Request for Comments: 3429                                           NTT
Category: Informational                                    November 2002
        

Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions

为多协议标签交换体系结构(MPLS)操作和维护(OAM)功能分配“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 (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

Abstract

摘要

This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label' that is used by user-plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets.

本文档描述了将RFC 3032(MPLS标签堆栈编码)中定义的一个保留标签值分配给用户平面多协议标签交换体系结构(MPLS)OAM功能用于识别MPLS OAM数据包的“操作和维护(OAM)警报标签”。

1. Introduction
1. 介绍

This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding [2]) to the 'OAM Alert Label' that is used by user-plane MPLS OAM functions for identification of MPLS OAM packets as described in the ITU-T Recommendation Y.1711 [1] (on MPLS OAM functions).

本文档描述了将RFC 3032(MPLS标签堆栈编码[2])中定义的一个保留标签值分配给“OAM警报标签”,用户平面MPLS OAM功能使用该标签来识别ITU-T建议Y.1711[1](关于MPLS OAM功能)中描述的MPLS OAM包。

2. OAM functions
2. OAM功能

MPLS OAM (Operation and Maintenance) functions provide necessary tools for network operators to operate and maintain the networks. MPLS OAM functionality is required at the MPLS layer, and more specifically at each MPLS level, independent of OAM functionality provided by the lower layers (SONET/SDH, etc.). The objectives of the OAM functions include the following:

MPLS OAM(操作和维护)功能为网络运营商操作和维护网络提供了必要的工具。MPLS层需要MPLS OAM功能,更具体地说,在每个MPLS级别,独立于较低层(SONET/SDH等)提供的OAM功能。OAM职能的目标包括:

- Defect and failure detection: Defect/failures affecting the transport of user information are detected by continuous or periodic checking. As a result, maintenance event information or appropriate alarms will be produced.

- 缺陷和故障检测:通过连续或定期检查来检测影响用户信息传输的缺陷/故障。因此,将产生维护事件信息或适当的警报。

- Reporting the defect/failure information: Defect information is given to other management entities (e.g., Operation Support System) in order to provide the appropriate indications to the maintenance staff for maintaining the Quality of Service (QoS) level offered to customers.

- 报告缺陷/故障信息:向其他管理实体(如运营支持系统)提供缺陷信息,以便向维护人员提供适当指示,以维持向客户提供的服务质量(QoS)水平。

- Defect/failure localization: Determination by internal or external test systems of a failed entity is performed if defect information is insufficient.

- 缺陷/故障定位:如果缺陷信息不足,则由内部或外部测试系统确定故障实体。

- Performance monitoring: Performance (packet losses, transfer delay, bit errors, etc.) of the user information transport is measured in order to estimate the transport integrity.

- 性能监控:测量用户信息传输的性能(数据包丢失、传输延迟、位错误等),以评估传输完整性。

3. OAM Packet Identification
3. OAM包识别

The user-plane MPLS OAM mechanisms as described in the ITU-T Recommendation Y.1711 [1] uses a special label called 'OAM Alert Label' to differentiate OAM packets from the normal user packets. One of the reserved label values defined in RFC 3032 (MPLS label stack encoding [2]) is assigned to 'OAM Alert Label'. A value of 14 is used for this purpose.

ITU-T建议Y.1711[1]中所述的用户平面MPLS OAM机制使用称为“OAM警报标签”的特殊标签来区分OAM数据包与正常用户数据包。RFC 3032(MPLS标签堆栈编码[2])中定义的一个保留标签值被分配给“OAM警报标签”。为此,使用值14。

4. MPLS OAM work in ITU-T SG13
4. ITU-tsg13中的MPLS-OAM工作

ITU-T Study Group 13, Question 3/13 is progressing work on user-plane MPLS OAM and has produced the following documents:

ITU-T研究组13,问题3/13正在进行关于用户平面MPLS OAM的工作,并编制了以下文件:

(1) Recommendation Y.1710 (Requirements for OAM functionality for MPLS networks) [3]

(1) 建议Y.1710(MPLS网络的OAM功能要求)[3]

(2) Corrigendum 1 to Recommendation Y.1710 [4]

(2) 建议Y.1710[4]的更正1

(3) Recommendation Y.1711 (OAM mechanisms for MPLS networks) [1]

(3) 建议Y.1711(MPLS网络的OAM机制)[1]

(4) Draft Recommendation Y.1720 (Protection switching for MPLS networks) [6] relies on OAM mechanisms in Y.1711, under last call as of Nov. 2002.

(4) 建议草案Y.1720(MPLS网络的保护交换)[6]依赖于Y.1711中的OAM机制,在2002年11月的最后一次呼叫中。

5. Considerations on penultimate hop popping (PHP)
5. 关于倒数第二跳弹出(PHP)的考虑

In response to concerns raised during IETF meetings and in related discussions, this section provides an explanation on how MPLS OAM functions defined in ITU-T Recommendation Y.1711 [1] are applied to MPLS networks where PHP is in effect.

针对IETF会议和相关讨论中提出的问题,本节解释了ITU-T建议Y.1711[1]中定义的MPLS OAM功能如何应用于PHP生效的MPLS网络。

5.1 Scope of ITU-T Recommendation Y.1711
5.1 ITU-T建议Y.1711的范围

The scope of ITU-T Recommendation Y.1711 includes application to both non-PHP and PHP cases as quoted below [1].

ITU-T建议Y.1711的范围包括适用于以下引用的非PHP和PHP情况[1]。

"1 Scope This Recommendation provides mechanisms for user-plane OAM (Operation and Maintenance) functionality in MPLS networks according to the requirements and principles given in Recommendation Y.1710. OAM functions specified in this Recommendation can be applied to both non-PHP and PHP cases unless otherwise stated. The current version of this recommendation is designed primarily to support point-to-point and multipoint-to-point explicit routed LSPs (ER-LSPs)."

“1范围本建议提供了用户平面OAM(操作和维护)的机制MPLS网络中的功能符合建议Y.1710中给出的要求和原则。除非另有说明,否则本建议中指定的OAM功能可应用于非PHP和PHP情况。本建议的当前版本主要设计为支持点对点和多点对点显式路由LSP(ER LSP)。”

5.2 Applicability of MPLS OAM to PHP
5.2 MPLS-OAM对PHP的适用性

There are two cases where PHP is used:

使用PHP的情况有两种:

Case 1: The ultimate node is an MPLS LSR, and implements both MPLS control-plane and data-plane, but is not able to perform 2 lookups at line rate. So it asks the penultimate node to pop the top label (rather than swapping it), using the MPLS reserved label 3 (implicit null label) as per defined in RFC 3032 [2].

案例1:最终节点是一个MPLS LSR,同时实现MPLS控制平面和数据平面,但不能以行速率执行2次查找。因此,它要求倒数第二个节点使用RFC 3032[2]中定义的MPLS保留标签3(隐式空标签)弹出顶部标签(而不是交换它)。

Case 2: The ultimate node has no MPLS label look up and processing capability and does not recognize labeled packets. This node asks for PHP, using the MPLS reserved label 3 (implicit null label) as defined in RFC 3032 [2].

案例2:最终节点没有MPLS标签查找和处理能力,并且不识别标签数据包。此节点使用RFC 3032[2]中定义的MPLS保留标签3(隐式空标签)请求PHP。

Currently, MPLS OAM functions defined in ITU-T Recommendation Y.1711 [1] can only be applied to Case 1. The next subsection describes the node behavior in Case 1. Application for Case 2 needs further study. Also, application to carrier supporting carrier scenarios is for future study.

目前,ITU-T建议Y.1711[1]中定义的MPLS OAM功能只能应用于情况1。下一小节描述案例1中的节点行为。案例2的申请需要进一步研究。此外,支持运营商场景的运营商应用程序还有待进一步研究。

5.3 Node behavior when OAM functions are activated
5.3 激活OAM功能时的节点行为

Where the ultimate LSR is an MPLS LSR and PHP is in effect, the penultimate LSR pops the top label and forwards the OAM packet (with the OAM label and the OAM payload intact) to the ultimate LSR [5].

当最终LSR是MPLS LSR且PHP有效时,倒数第二个LSR弹出顶部标签并将OAM数据包(OAM标签和OAM有效负载保持不变)转发给最终LSR[5]。

- If the ultimate LSR supports MPLS OAM, it understands that a received packet with an OAM label on top is an OAM packet, since the original top label has been removed by the penultimate LSR. It also knows the ingress LSR that originated the MPLS OAM packet from the TTSI (Trail Termination Source Identifier) value of the

- 如果最终LSR支持MPLS-OAM,则它理解顶部带有OAM标签的接收分组是OAM分组,因为倒数第二个LSR已经移除了原始的顶部标签。它还知道从MPLS的TTSI(Trail Termination Source Identifier)值发起MPLS OAM分组的入口LSR

received MPLS OAM packet. TTSI is a unique identifier for ingress LSR that is contained in MPLS OAM packets (see ITU-T Recommendation Y.1711 [1]).

接收到MPLS OAM数据包。TTSI是MPLS OAM数据包中包含的入口LSR的唯一标识符(参见ITU-T建议Y.1711[1])。

- If the ultimate LSR does not support MPLS OAM, the OAM packet is discarded as per section 3.18 of RFC 3031 [5].

- 如果最终LSR不支持MPLS OAM,则根据RFC 3031[5]第3.18节丢弃OAM数据包。

6. IANA Considerations
6. IANA考虑

The IANA has reserved the use of the MPLS label value of 14 as the 'OAM Alert Label'. See section 3 for additional information.

IANA保留使用MPLS标签值14作为“OAM警报标签”。更多信息请参见第3节。

7. Security Considerations
7. 安全考虑

This document does not raise any security issues that are not already present in either the MPLS architecture or in the architecture of the network layer protocol contained within the encapsulation.

本文档不会提出MPLS体系结构或封装中包含的网络层协议体系结构中尚未出现的任何安全问题。

OAM functions could enhance the security of MPLS networks. For example, Connectivity Verification (CV) function defined in ITU-T Recommendation Y.1711 [1] can detect mis-connections, and therefore can prevent customers' traffic being exposed to other customers.

OAM功能可以增强MPLS网络的安全性。例如,ITU-T建议Y.1711[1]中定义的连接验证(CV)功能可以检测错误连接,因此可以防止客户的流量暴露给其他客户。

8. Acknowledgements
8. 致谢

The author wishes to thank Shahram Davari with PMC-Sierra, Neil Harrison with British Telecom, Monique Morrow, Thomas D. Nadeau, Hari Rakotoranto and Chip Sharp with Cisco Systems, Khalid Ahmad and David Allan with Nortel Networks, and Mina Azad with Azad-Mohtaj Consulting for their valuable contributions and discussions.

作者要感谢PMC Sierra的Shahram Davari、英国电信的Neil Harrison、思科系统的Monique Morrow、Thomas D.Nadeau、Hari Rakotoranto和Chip Sharp、北电网络的Khalid Ahmad和David Allan,以及Azad Mohtaj Consulting的Mina Azad,感谢他们的宝贵贡献和讨论。

9. Normative References
9. 规范性引用文件

[1] ITU-T Recommendation Y.1711, "OAM mechanism for MPLS networks", November 2002.

[1] ITU-T建议Y.1711,“MPLS网络的OAM机制”,2002年11月。

[2] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinaccia, D., Li, T. and A. Conta, "MPLS label stack encoding", RFC 3032, January 2001.

[2] Rosen,E.,Tappan,D.,Fedorkow,G.,Rekhter,Y.,Farinacia,D.,Li,T.和A.Conta,“MPLS标签堆栈编码”,RFC 3032,2001年1月。

[3] ITU-T recommendation Y.1710, "Requirements for OAM functionality for MPLS networks" July 2001.

[3] ITU-T建议Y.1710,“MPLS网络的OAM功能要求”,2001年7月。

[4] ITU-T Corrigendum 1 to Recommendation Y.1710, November 2002.

[4] ITU-T对建议Y.1710的更正1,2002年11月。

[5] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

[5] Rosen,E.,Viswanathan,A.和R.Callon,“多协议标签交换体系结构”,RFC 30312001年1月。

10. Informative Reference
10. 资料性参考

[6] ITU-T Draft Recommendation Y.1720, "Protection switching for MPLS networks", under last call as of November 2002.

[6] ITU-T建议草案Y.1720,“MPLS网络的保护交换”,根据2002年11月的最后一次呼叫。

11. Author's Address
11. 作者地址

Hiroshi OHTA NTT 3-9-11 Midori-Cho, Musashino-Shi Tokyo 180-8585 Japan

日本东京武藏县大下广史NTT 3-9-11 Midori Cho,武藏县180-8585

   Phone: +81 422 59 3617
   Fax:   +81 422 59 3787
   EMail: ohta.hiroshi@lab.ntt.co.jp
        
   Phone: +81 422 59 3617
   Fax:   +81 422 59 3787
   EMail: ohta.hiroshi@lab.ntt.co.jp
        
12. Full Copyright Statement
12. 完整版权声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

版权所有(C)互联网协会(2002年)。版权所有。

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

本文件及其译本可复制并提供给他人,对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发,不受任何限制,前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是,不得以任何方式修改本文件本身,例如删除版权通知或对互联网协会或其他互联网组织的引用,除非出于制定互联网标准的需要,在这种情况下,必须遵循互联网标准过程中定义的版权程序,或根据需要将其翻译成英语以外的其他语言。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上述授予的有限许可是永久性的,互联网协会或其继承人或受让人不会撤销。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。