Internet DRAFT - draft-ohta-mpls-label-value

draft-ohta-mpls-label-value




                                                                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