Internet DRAFT - draft-vigoureux-mpls-tp-gal

draft-vigoureux-mpls-tp-gal



MPLS Working Group                                M. Vigoureux (Editor) 
Internet Draft                                           Alcatel-Lucent 
Intended status: Standard Track 
Expires: December 2008                              G. Swallow (Editor) 
                                                    Cisco Systems, Inc. 
 
                                                   R. Aggarwal (Editor) 
                                                       Juniper Networks 
 
                                                          June 26, 2008 
 
 
                                      
      Assignment of the Generic Associated Channel Header Label (GAL) 
                      draft-vigoureux-mpls-tp-gal-00 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 

   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. 

   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/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on December 26, 2008. 

Copyright Notice 

   Copyright (C) The IETF Trust (2008). 

 

 
 
 
 
Vigoureux et al.      Expires December 26, 2008                [Page 1] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

Abstract 

   This document describes the assignment of one of the reserved label 
   values, defined in RFC 3032 [3], to the 'Generic-ACH Label (GAL)', 
   that is used as generic exception mechanism, for example by MPLS 
   Transport Profile (MPLS-TP) for Operations and Management (OAM) 
   functions. 

Conventions used in this document 

   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 RFC 2119 [1]. 

Table of Contents 

   1. Introduction...................................................2 
   2. Generic Exception Mechanism....................................3 
   3. Relationship with RFC 3429.....................................3 
   4. Relationship with Existing MPLS OAM Alert Mechanisms...........4 
   5. Applicability and Usages.......................................4 
      5.1. GAL Processing............................................5 
         5.1.1. Section..............................................5 
         5.1.2. Label Switched Paths.................................6 
         5.1.3. LSP Tandem Connection Monitoring Entity..............7 
      5.2. Considerations on Penultimate Hop Popping.................7 
      5.3. Compatibility.............................................8 
   6. Security Considerations........................................8 
   7. IANA Considerations............................................8 
   8. Acknowledgments................................................8 
   9. References.....................................................8 
      9.1. Normative References......................................8 
      9.2. Informative References....................................9 
   Authors' Addresses................................................9 
   Contributing Authors' Addresses..................................10 
   Intellectual Property Statement..................................10 
   Disclaimer of Validity...........................................11 
    

1. Introduction 

   This document describes the assignment of one of the reserved label 
   values, defined in RFC 3032 [3], to the 'Generic-ACH Label (GAL)', 
   that is used as generic exception mechanism, for example by MPLS 
   Transport Profile (MPLS-TP) for Operations and Management (OAM) 
   functions. 

 
 
Vigoureux et al.      Expires December 26, 2008                [Page 2] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

2. Generic Exception Mechanism 

   MPLS-TP requires [12] a mechanism to differentiate specific packets 
   (e.g. OAM) from others, such as normal user-plane ones. This document 
   proposes that a label be used and calls this special label the 
   'Generic-ACH Label (GAL)'. One of the reserved label values defined 
   in RFC 3032 [3] is assigned to the 'Generic-ACH Label (GAL)'. The 
   value of the label is to be allocated by IANA; this document suggests 
   the value 13. 

   The 'Generic-ACH Label (GAL)' is a generic exception mechanism used 

     firstly to differentiate specific packets (e.g. OAM) from others, 
     such as normal user-plane ones, 

     and secondly, to indicate that the Generic Associated Channel 
     Header (GE-ACH) [10] appears immediately after the bottom of the 
     label stack. 

   The 'Generic-ACH Label (GAL)' MUST only be used if those two purposes 
   are fulfilled simultaneously. 

   Note that, in this document, MPLS-TP OAM (functions, packets) should 
   be understood in the broad sense, that is, as a set of mechanisms 
   including Automatic Protection Switching (APS), Signalling Control 
   Channel (SCC) and Management Control Channel (MCC). 

   Further, while transport applications are expected to be the first to 
   use the 'Generic-ACH Label (GAL)', the use of this label is by no 
   means restricted to MPLS-TP. 

3. Relationship with RFC 3429 

   RFC 3429 [11] describes the assignment of one of the reserved label 
   values, defined in RFC 3032 [3], to the 'OAM Alert Label' that is 
   used by user-plane MPLS OAM functions for the identification of MPLS 
   OAM packets. The value of 14 is used for that purpose. 

   This document and RFC 3429 [11], thus describe the assignment of 
   reserved label values for similar purposes. The rationales for the 
   assignment of a new reserved label can be summarized as follows: 






 
 
Vigoureux et al.      Expires December 26, 2008                [Page 3] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

   o  Unlike the mechanisms described and referenced in RFC 3429 [11], 
      MPLS-TP OAM packets will not reside immediately after the 
      'Generic-ACH Label (GAL)' but behind the Generic Associated 
      Channel Header (GE-ACH) [10] which, itself, resides immediately 
      after the bottom of the label stack when the 'Generic-ACH Label 
      (GAL)' appears in this label stack. This will ensure that MPLS-TP 
      OAM complies with RFC 4928 [7]. 

   o  The set of OAM functions potentially operated in the context of 
      MPLS-TP is wider than the set of OAM functions referenced in RFC 
      3429 [11]. 

   o  It has been reported that there are existing implementations and 
      running deployments using the 'OAM Alert Label' as described in 
      RFC 3429 [11]. It is therefore not possible to modify the 'OAM 
      Alert Label' allocation, purpose or usage. Nevertheless, it is 
      RECOMMENDED by this document that no further OAM extensions based 
      on 'OAM Alert Label' (Label 14) usage be specified or developed. 

4. Relationship with Existing MPLS OAM Alert Mechanisms 

   RFC 4379 [6] and BFD for MPLS LSPs [8] have defined alert 
   mechanisms that enable a MPLS LSR to identify and process MPLS OAM 
   packets when the OAM packets are encapsulated in an IP header. These 
   alert mechanisms are based on TTL expiration and/or use an IP 
   destination address in the range 127/8. 

   These alert mechanisms SHOULD preferably be used in non MPLS-TP 
   environments. The mechanism defined in this document MAY also be 
   used. 

5. Applicability and Usages 

   The 'Generic-ACH Label (GAL)' MUST only be used with Label Switched 
   Paths (LSPs), with their associated Tandem Connection Monitoring 
   Entities (see [12] for definitions of TCMEs) and with MPLS Sections. 
   A MPLS Section is a network segment between two LSRs that are 
   immediately adjacent at the MPLS layer. 

   The 'Generic-ACH Label (GAL)' applies to both P2P and P2MP LSPs, 
   unless otherwise stated. 

   In MPLS-TP, the 'Generic-ACH Label (GAL)' MUST always be at the 
   bottom of the label stack (i.e. S bit set to 1). However, in other 
   MPLS environments, this document places no restrictions on where the 
   'Generic-ACH Label (GAL)' may appear within the label stack. 

 
 
Vigoureux et al.      Expires December 26, 2008                [Page 4] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

   The 'Generic-ACH Label (GAL)' MUST NOT be used with Pseudowires (PWs) 
   neither with their associated Tandem Connection Monitoring Entities. 

   The 'Generic-ACH Label (GAL)' MUST NOT appear in the label stack when 
   transporting normal user-plane packets. Furthermore, the 'Generic-ACH 
   Label (GAL)' MUST only appear once in the label stack. 

5.1. GAL Processing 

   The Class of Service (CoS) field (former EXP field) of the 'Generic-
   ACH Label (GAL)' follows the definition and processing rules 
   specified and referenced in [9]. 

   The Time To Live (TTL) field of the 'Generic-ACH Label (GAL)' follows 
   the definition and processing rules specified in [4]. 

   For detailed information on the Generic-ACH (GE-ACH) mentioned in the 
   following sub-sections, please see [10]. 

5.1.1. Section 

   The following figure (Figure 1) depicts two MPLS LSRs immediately 
   adjacent at the MPLS layer. 

                          +---+             +---+ 
                          | A |-------------| Z | 
                          +---+             +---+ 
    
                Figure 1 : MPLS-TP OAM over a MPLS Section 

   With regards to the MPLS Section, both LERs are Maintenance End 
   Points (see [12] for definitions of MEPs). 

   The following figure (Figure 2) depicts the format of a labelled 
   MPLS-TP OAM packet when used for MPLS Section OAM. 












 
 
Vigoureux et al.      Expires December 26, 2008                [Page 5] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                  GAL                  | CoS |S|       TTL     | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                          Generic-ACH                          | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               . 
     .                       MPLS-TP OAM packet                      . 
     .                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
        Figure 2 : Labelled MPLS-TP OAM packet for MPLS Section OAM 

   To perform MPLS-TP OAM functions on the MPLS Section, the head-end 
   LSR (A) of the MPLS Section generates a MPLS-TP OAM packet with a GE-
   ACH to which it prepends a 'Generic-ACH Label (GAL)'. 

   o  The TTL field of the 'Generic-ACH Label (GAL)' SHOULD be set to 1. 

   o  The S bit of the 'Generic-ACH Label (GAL)' MUST be set to 1. 

   The MPLS-TP OAM packet, the GE-ACH or the 'Generic-ACH Label (GAL)' 
   SHOULD NOT be modified towards the tail-end LSR (Z). Upon reception 
   of the labelled packet, the tail-end LSR (Z), after having checked 
   the 'Generic-ACH Label (GAL)' fields, SHOULD pass the whole packet to 
   the appropriate processing entity. 

5.1.2. Label Switched Paths 

   The following figure (Figure 3) depicts four LSRs. A LSP is 
   established from A to D and switched in B and C. 

        +---+             +---+             +---+             +---+ 
        | A |-------------| B |-------------| C |-------------| D | 
        +---+             +---+             +---+             +---+ 
    
                     Figure 3 : MPLS-TP OAM over a LSP 

   With regards to the considered LSP, LERs A and D are MEPs. 
   Furthermore, LSRs B and C could be Maintenance Intermediate Points 
   (see [12] for definitions of MEPs and MIPs). 

   The following figure (Figure 4) depicts the format of a labelled 
   MPLS-TP OAM packet when used for LSP OAM. 


 
 
Vigoureux et al.      Expires December 26, 2008                [Page 6] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

      0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |               LSP Label               | CoS |S|       TTL     | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                  GAL                  | CoS |S|       TTL     | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                          Generic-ACH                          | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               . 
     .                       MPLS-TP OAM packet                      . 
     .                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
            Figure 4 : Labelled MPLS-TP OAM packet for LSP OAM 

   Note that, in the general case, the considered LSP MAY be tunnelled 
   (e.g. in a MPLS Tunnel existing between B and C), and as such, other 
   labels MAY be present above in the label stack. 

   To perform MPLS-TP OAM functions on the LSP, the head-end LSR (A) of 
   the LSP generates a MPLS-TP OAM packet with a GE-ACH to which it 
   prepends a 'Generic-ACH Label (GAL)' to which it prepends the label 
   of the LSP. 

   o  The TTL field of the 'Generic-ACH Label (GAL)' SHOULD be set to 1. 

   o  The S bit of the 'Generic-ACH Label (GAL)' SHOULD be set to 1, in 
      MPLS-TP. 

   The MPLS-TP OAM packet, the GE-ACH or the 'Generic-ACH Label (GAL)' 
   SHOULD NOT be modified towards the targeted destination. Upon 
   reception of the labelled packet, the targeted destination, after 
   having checked both the LSP label and 'Generic-ACH Label (GAL)' 
   fields, SHOULD pass the whole packet to the appropriate processing 
   entity. 

5.1.3. LSP Tandem Connection Monitoring Entity 

   To be covered in a next version of this document. 

5.2. Considerations on Penultimate Hop Popping 

   OAM operations require context awareness. The label, immediately 
   above the 'Generic-ACH Label (GAL)' in the label stack, provides this 
   context. Additionally, a requirement of MPLS-TP OAM is that user-
   plane and OAM packets share the same fate [12]. As such, when 
 
 
Vigoureux et al.      Expires December 26, 2008                [Page 7] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

   operating MPLS-TP OAM, Penultimate Hop Popping (PHP) SHOULD be 
   disabled by default for the label immediately above the 'Generic-ACH 
   Label (GAL)' in the label stack, otherwise neither all MPLS-TP OAM 
   requirements [12] nor all MPLS-TP OAM functions can be satisfied. 

   In case PHP is enabled, the context, normally provided by the label 
   immediately above the 'Generic-ACH Label (GAL)' in the label stack, 
   SHALL be provided by other means. 

   Moreover, PHP MUST NOT be applied to the 'Generic-ACH Label (GAL)' 
   itself. 

5.3. Compatibility 

   LERs and LSRs not capable of processing the 'Generic-ACH Label (GAL)' 
   SHOULD silently discard the packet. 

6. Security Considerations 

   This document does not raise any security issue that is not already 
   present in either the MPLS architecture [2], the PWE3 architecture .
   [5] or the MPLS-TP framework [ref]. Security considerations, for the 
   GE-ACH, can be found in [10]. 

7. IANA Considerations 

   This document requests that IANA allocates a Label value, to the 
   'Generic-ACH Label (GAL)', from the pool of reserved labels, and 
   suggests this value to be 13. 

8. Acknowledgments 

   The authors would like to thank all members of the teams (the Joint 
   Working Team, the MPLS Interoperability Design Team in IETF and the 
   T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 
   specification of MPLS Transport Profile. 

9. References 

9.1. Normative References 

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement 
         Levels", BCP 14, RFC 2119, March 1997 

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

 
 
Vigoureux et al.      Expires December 26, 2008                [Page 8] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

   [3]   Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, 
         January 2001 

   [4]   Agarwal, P., Akyol, B., "Time To Live (TTL) Processing in 
         Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, 
         January 2003 

   [5]   Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge 
         (PWE3) Architecture", RFC 3985, March 2005 

   [6]   Kompella, K., Swallow, G., "Detecting Multi-Protocol Label 
         Switched (MPLS) Data Plane Failures", RFC 4379, February 2006 

   [7]   Swallow, G., Bryant, S., Andersson, L., "Avoiding Equal Cost 
         Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 
         2007 

   [8]   Aggarwal, R., Kompella, K., Swallow, G., Nadeau, T., "BFD For 
         MPLS LSPs", draft-ietf-bfd-mpls-07, June 2008 

   [9]   Andersson, L., ""EXP field" renamed to "CoS Field"", draft-
         ietf-mpls-cosfield-def-02, June 2008 

   [10]  Bocci, M., Ward, D., "MPLS Generic Associated Channel", draft-
         bocci-pwe3-ge-ach-00, June 2008 

9.2. Informative References 

   [11]  Ohta, H., "Assignment of the 'OAM Alert Label' for 
         Multiprotocol Label Switching Architecture (MPLS) Operation and 
         Maintenance (OAM) Functions", RFC 3429, November 2002 

   [12]  Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 
         MPLS Transport Networks", draft-vigoureux-mpls-tp-oam-
         requirements-00, July 2008 

Authors' Addresses 

   Martin Vigoureux (Editor) 
   Alcatel-Lucent 
    
   Email: martin.vigoureux@alcatel-lucent.com 
    




 
 
Vigoureux et al.      Expires December 26, 2008                [Page 9] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

   George Swallow (Editor) 
   Cisco Systems, Inc. 
    
   Email: swallow@cisco.com 
    

   Rahul Aggarwal (Editor) 
   Juniper Networks 
    
   Email: rahul@juniper.net 
    

Contributing Authors' Addresses 

   David Ward 
   Cisco Systems, Inc. 
    
   Email: dward@cisco.com 
    

   Matthew Bocci 
   Alcatel-Lucent 
    
   Email: matthew.bocci@alcatel-lucent.co.uk 
    

   Italo Busi 
   Alcatel-Lucent 
    
   Email: italo.busi@alcatel-lucent.it 
    

   Marc Lasserre 
   Alcatel-Lucent 
    
   Email: mlasserre@alcatel-lucent.com 
    

Intellectual Property Statement 

   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 

 
 
Vigoureux et al.      Expires December 26, 2008               [Page 10] 

Internet-Draft Generic Associated Channel Header Label        June 2008 
    

   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and 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. 

   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. 

Disclaimer of Validity 

   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, THE IETF TRUST 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. 

Copyright Statement 

   Copyright (C) The IETF Trust (2008). 

   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. 

Acknowledgment 

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









 
 
Vigoureux et al.      Expires December 26, 2008               [Page 11]