H. Ohta Internet Draft NTT Document: draft-ohta-mpls-label-value-03.txt Expires: March 2003 September 2002 Assignment of the 'OAM Alert Label' for MPLS Operation and Maintenance (OAM) functions Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. This document requests IANA to allocate a label value. Distribution of this memo is unlimited. This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the 'OAM Alert Label' that is used by user-plane MPLS Operation and Maintenance (OAM) functions for identification of MPLS OAM packets. Ohta Informational - Expires March 2003 1 Assignment of the "OAM Alert Label" Sept. 2002 for MPLS Operation and Maintenance (OAM) functions 1. Introduction 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 Operation and Maintenance (OAM) functions for identification of MPLS OAM packets as described in the ITU-T draft Recommendation Y.1711[1] (on MPLS OAM functions). 2. OAM functions 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: - 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. - 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 The user-plane MPLS OAM mechanisms as described in the ITU-T draft 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. Ohta Informational - Expires March 2003 2 Assignment of the "OAM Alert Label" Sept. 2002 for MPLS Operation and Maintenance (OAM) functions 4. MPLS OAM work in ITU-T SG13 ITU-T Study Group 13, Question 3/13 is progressing work on user-plane MPLS OAM and has produced the following documents: (1) Recommendation Y.1710 (Requirements for OAM functionality for MPLS networks)[3] (2) Draft Corrigendum 1 to Recommendation Y.1710[4], completed last call (July 2002) and is targeted for approval (Nov. 2002) (3) Draft Recommendation Y.1711 (OAM mechanisms for MPLS networks)[1], completed last call (July 2002) and is targeted for approval (Nov. 2002) (4) Draft Recommendation Y.1720 (Protection switching for MPLS networks)[6] which relies on OAM mechanisms in Y.1711, targeted for last call as of Nov. 2002 (following approval of Y.1711). 5. Considerations on penultimate hop popping (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. 5.1 Scope of ITU-T Recommendation Y.1711 The scope of ITU-T Recommendation Y.1711 includes application to both non-PHP and PHP cases as quoted below[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)." 5.2 Applicability of MPLS OAM to PHP There are two cases where PHP is used: Case 1: The ultimate node is an MPLS LSR, and implements both MPLS control-plane and data-plane, but is not able to do 2 lookups at line Ohta Informational - Expires March 2003 3 Assignment of the "OAM Alert Label" Sept. 2002 for MPLS Operation and Maintenance (OAM) functions 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 RFC3032[2]. 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 per defined in RFC3032[2]. Currently, MPLS OAM functions defined in ITU-T Recommendation Y.1711[1] can be applied to the case 1 only. Next subsection describes the node behavior in case 1. Application to case 2 is for further study. Also, application to carrier supporting carrier scenarios is for future study. 5.3 Node behavior when OAM functions are activated 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 OAM payload intact) to the ultimate LSR [5]. - If the ultimate LSR supports MPLS OAM, it understands that received packet with OAM label on top is an OAM packet knowing original top label has been removed by the penultimate LSR. It also knows the ingress LSR which originated the MPLS OAM packet from the TTSI (Trail Termination Source Identifier) value of the received MPLS OAM packet. TTSI is a unique identifier for ingress LSR which is contained in MPLS OAM packets (see ITU-T Recommendation Y.1711[1]). - If the ultimate LSR does not support MPLS OAM, the OAM packet is discarded as per section 3.18 of RFC3031[5]. 6. IANA considerations It is requested that IANA consider if the use of the MPLS reserved label value of 14 as the 'OAM Alert Label' is acceptable. If it is acceptable, it is requested that this value is officially assigned as the 'OAM Alert Label'. Should the said value not be acceptable by IANA, ITU-T SG13 is ready to accept another reserved label value (as per IANA's recommendation). ITU-T SG13 appreciates if IANA will advise the author of any problem with the use of the value of 14, and if necessary recommends an alternative reserved label value no later than October 25, 2002. Ohta Informational - Expires March 2003 4 Assignment of the "OAM Alert Label" Sept. 2002 for MPLS Operation and Maintenance (OAM) functions 7. Security considerations 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. 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 to be exposed to other customers. 8. Acknowledgement 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 and Mina Azad, Khalid Ahmad and David Allan with Nortel Networks for their valuable contributions and discussions. 9. Normative references [1] ITU-T Draft Recommendation Y.1711, "OAM mechanism for MPLS networks", Chitose, Japan, July 2002 [2] IETF, RFC 3032, "MPLS label stack encoding", Category: Standards Track, January 2001. [3] ITU-T recommendation Y.1710, "Requirements for OAM functionality for MPLS networks" Caracas, Venezuela, May 2001 [4] ITU-T Draft Corrigendum 1 to Recommendation Y.1710, Chitose, Japan, July 2002. [5] IETF, RFC 3031, " Multiprotocol Label Switching Architecture", Category: Standards Track, January 2001. 10. Informative reference [6] ITU-T Draft Recommendation Y.1720, "Protection switching for MPLS networks", Chitose, Japan, July 2002. Ohta Informational - Expires March 2003 5 Assignment of the "OAM Alert Label" Sept. 2002 for MPLS Operation and Maintenance (OAM) functions 11. Author's Address Hiroshi OHTA NTT 3-9-11 Midori-Cho, Musashino-Shi Tokyo 180-8585 Japan Tel: +81 422 59 3617 Fax: +81 422 59 3787 Email: ohta.hiroshi@lab.ntt.co.jp Ohta Informational - Expires March 2003 6