H. Ohta Internet Draft NTT Document: draft-ohta-mpls-label-value-02.txt Expires: February 2003 August 2002 Use of a reserved label value defined in RFC 3032 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 except that the right to produce derivative works is not granted. 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 use of an MPLS reserved label value for identification of user-plane MPLS OAM (Operation and Maintenance) packets, and makes a request to IANA for allocation of a reserved label value for this purpose. Ohta Informational - Expires February 2003 1 Use of a reserved label value defined in RFC 3032 Feb 2002 for MPLS Operation and Maintenance (OAM) functions 1. Introduction This document describes use of an MPLS reserved label value for identification of user-plane MPLS OAM (Operation and Maintenance) packets as described in the ITU-T draft Recommendation Y.1711[1] (on MPLS OAM functions) and makes a request to IANA for allocation of a reserved label value for this purpose. ITU-T proposes use of the MPLS reserved label value of 14, referred to as the 'OAM Alert Label'. ITU-T SG13 appreciates if IANA advises the author of any problem with the use of this value no later than September 30, 2002. 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] rely on the use of a special label called Ohta Informational - Expires February 2003 2 Use of a reserved label value defined in RFC 3032 Feb 2002 for MPLS Operation and Maintenance (OAM) functions 'OAM Alert Label'. ITU-T SG13 has decided to use one of the reserved label values defined in RFC 3032(MPLS label stack encoding)[2] to differentiate OAM packets from the normal user packets. A value of 14 has been proposed for this purpose. IANA is requested to consider if the use of this value is acceptable. 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). 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 Ohta Informational - Expires February 2003 3 Use of a reserved label value defined in RFC 3032 Feb 2002 for MPLS Operation and Maintenance (OAM) functions 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 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 Ohta Informational - Expires February 2003 4 Use of a reserved label value defined in RFC 3032 Feb 2002 for MPLS Operation and Maintenance (OAM) functions the 'OAM Alert Label'. ITU-T SG13 appreciates if IANA will advise the author of any problem with the use of this value, and if necessary recommends an alternative reserved label value no later than September 30, 2002. 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 February 2003 5 Use of a reserved label value defined in RFC 3032 Feb 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 February 2003 6