Internet DRAFT - draft-ali-ccamp-gmpls-uni-error-notification

draft-ali-ccamp-gmpls-uni-error-notification










   CCAMP Working Group                                        Zafar Ali 
   Internet Draft                                        George Swallow 
   Intended status: Standard Track                         Matt Hartley  
   Expires: January 11, 2014                          Clarence Filsfils  
                                                           Cisco Systems 
                                                                         
                                                            Kenji Kumaki 
                                                        KDDI Corporation 
                                                           July 12, 2013                       
    
        Extensions to Resource ReserVation Protocol-Traffic Engineering 
       (RSVP-TE) for Error Notication in Generalized Multiprotocol Label 
                Switching (GMPLS) User-Network Interface (UNI) 

              draft-ali-ccamp-gmpls-uni-error-notification-00.txt 


   Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 11, 2014. 
       
   Copyright Notice 

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.    
    
    
   Ali, Swallow, Hartley, et al    Expires January 2014        [Page 1] 
    






   Internet Draft   draft-ali-ccamp-gmpls-uni-error-notification-00.txt 


 

   Abstract 

   There are many scenarios in which extensions to Resource ReserVation 
   Protocol-Traffic Engineering (RSVP-TE) are required for error 
   notication in Generalized Multiprotocol Label Switching (GMPLS) 
   User-Network Interface (UNI). This document outlines these scenarios 
   and specifies the required extensions to RSVP-TE. Although the 
   GMPLS-UNI reference model is used to describe requirements and 
   solutions in the document, the proposed extensions are equally 
   applicable to other deployment scenarios such as inter-domain RSVP-
   TE.  
    
   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 [RFC2119]. 

   Table of Contents 

      1. Introduction...............................................3 
      2. Requirements...............................................4 
         2.1. Error Node Address in ERROR_SPEC object 
                                                      ...............4 
         2.2. Restoration Notification..............................4 
      3. RSVP-TE extensions for Error Notication....................5 
         3.1. Error Node Address Modification in ERROR_SPEC object 
                                                                   ..5 
            3.1.1. Error Node Address Modification Flag 
                                                        ................ 5 
            3.1.2. Processing rules................................ 5 
            3.1.3. Example......................................... 6 
         3.2. Restoration Notification..............................6 
            3.2.1. Error sub-code.................................. 6 
            3.2.2. Processing rules................................ 6 
      4. Security Considerations....................................6 
      5. IANA Considerations........................................6 
         5.1. New ERROR_SPEC.Flags..................................6 
    
    
   Ali, Swallow, Hartley, et al  Expires January 2014        [Page 2] 
       






   Internet Draft   draft-ali-ccamp-gmpls-uni-error-notification-00.txt 


         5.2. New RSVP error sub-codes..............................7 
      6. Acknowledgements...........................................7 
      7. References.................................................7 
         7.1. Normative References..................................7 
         7.2. Informative References................................8 
       

   1. Introduction 

   [RFC4208] provides mechanisms for GMPLS UNI signaling. Figure 1 
   borrows the reference network model of [RFC4208]. 
    
        Overlay                                                  Overlay 
        Network       +----------------------------------+       Network 
      +---------+     |                                  |     +---------+ 
      |  +----+ |     |  +-----+    +-----+    +-----+   |     | +----+  | 
      |  |    | | UNI |  |     |    |     |    |     |   | UNI | |    |  | 
      | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- | 
      |  |    | |  +--+--+     |    |     |    |     |   |     | |    |  | 
      |  +----+ |  |  |  +--+--+    +--+--+    +--+--+   |     | +----+  | 
      +---------+  |  |     |          |          |      |     +---------+ 
                   |  |     |          |          |      | 
      +---------+  |  |  +--+--+       |       +--+--+   |     +---------+ 
      |  +----+ |  |  |  |     |       +-------+     |   |     | +----+  | 
      |  |    +-+--+  |  | CN4 +---------------+ CN5 |   |     | |    |  | 
      | -+ EN2+-+-----+--+     |               |     +---+-----+-+ EN4+- | 
      |  |    | | UNI |  +-----+               +-----+   | UNI | |    |  | 
      |  +----+ |     |                                  |     | +----+  | 
      +---------+     +----------------------------------+     +---------+ 
        Overlay                 Core Network                     Overlay 
        Network                                                  Network 
    
                          Legend:   EN  -  Edge Node 
                                    CN  -  Core Node 
     
                       Figure 1:  GMPLS UNI Reference Model 
    
   For convenience, some terms used in [RFC4208] are re-stated below: 
    
      -  "source EN": the edge node which initiates the connection 
   (e.g., EN1); 
    
      -  "destination EN": the edge node where the connection is 
   terminated (e.g., EN3); 
    
      -  "ingress CN": the core node to which the source EN is attached 
    
    
   Ali, Swallow, Hartley, et al  Expires January 2014        [Page 3] 
       






   Internet Draft   draft-ali-ccamp-gmpls-uni-error-notification-00.txt 


   (e.g., CN1); 
    
      -  "egress CN": the core node to which the destination EN is 
   attached (e.g., CN3). 
    
   [RFC4208] provides mechanisms for UNI signaling whereby a single 
   end-to-end RSVP session between source EN and destination EN is used 
   for the user connection, just as it would be for connection creation 
   between two core nodes. However, when considering policy 
   considerations such as a requirement to preserve the confidentiality 
   of topological information of the core network, additional 
   requirements for UNI signaling exist that are not addressed by 
   [RFC4208]. This document focuses on error notification aspects of 
   these additional requirements.  
    
   2. Requirements 

   This sections outlines addition requirements related to error 
   notification in GMPLS UNI. For the purpose of illustration, an end-
   to-end UNI connection that passes through EN1-CN1-CN2-CN3-EN3 is 
   used as an example.  
    
   2.1. Error Node Address in ERROR_SPEC object 

   The IPv4 and IPv6 ERROR_SPEC objects are defined in [RFC2205]; both 
   objects contain an Error Node Address of the appropriate type, 
   defined as the IP address of the error originating node [RFC2205]. 
   However, for confidentiality reasons, service provider of the core 
   network may not wish to expose addresses used in the core network 
   (other than the UNI link addresses) to edge nodes. To meet this 
   requirement, a core node should be allowed to change the Error Node 
   Address in the ERROR_SPEC. When such an address modification is made 
   by a core node, the edge node should be informed that Error Node 
   Address field in the ERROR_SPEC has been modified.  

   2.2. Restoration Notification 

   The ability to dynamically restore a Label Switched Path (LSP) is 
   one of the fundamental features of GMPLS, including GMPLS UNI. In 
   the context of GMPLS UNI, restoration of an LSP after a failure may 
   be performed by the core network alone, or may be triggered by the 
   edge nodes. There is a requirement that the two methods of 
   restoration co-exist.  
    
    
   Ali, Swallow, Hartley, et al  Expires January 2014        [Page 4] 
       






   Internet Draft   draft-ali-ccamp-gmpls-uni-error-notification-00.txt 


    
   When the core network restores an LSP, in many cases there is no 
   need to re-signal the LSP. However, in order to avoid a concurrent 
   restoration process triggered by an edge node, it is required that 
   the core network notify the edge network that the LSP has been 
   restored.  
    
   3. RSVP-TE extensions for Error Notication 

   3.1. Error Node Address Modification in ERROR_SPEC object 

   3.1.1. Error Node Address Modification Flag 

   To allow a core node to change the Error Node Address in the 
   ERROR_SPEC object, the following new flag value is defined for the 
   Flags field of the IPv4 and IPv6 ERROR_SPEC objects [RFC2205], and 
   for the IPv4 IF_ID and IPv6 IF_ID objects [RFC3477]. 
    
   ERROR_SPEC.Flags = 0x08 (value to be assigned by IANA): Error Node 
   Address Modified.  
    
   The "Error Node Address Modified" flag is applicable to all RSVP-TE 
   messages that use the ERROR_SPEC object.  

   3.1.2. Processing rules 

      When processing an ERROR_SPEC object received in a message from 
      another node, the processing node MAY replace the IPv4 or IPv6 
      address in the ERROR_SPEC object with another address relating to 
      itself if its local policy requires it to do so. 

      When making an address substitution in this manner, the 
      processing node SHOULD set the Error Node Address Modified flag 
      in the Flags field of the ERROR_SPEC object to indicate that a 
      change has been made. 

      When processing a received ERROR_SPEC object, a node SHOULD 
      examine the ERROR_SPEC.Flags field and check for the "Error Node 
      Address Modified" flag before processing the 
      ERROR_SPEC.Error_Node_Address field. The processing node MAY 
      alter its handling of the ERROR_SPEC object if this flag is set, 
      but any such variation in handling is implementation-dependent 
      and beyond the scope of this document. 


    
    
   Ali, Swallow, Hartley, et al  Expires January 2014        [Page 5] 
       






   Internet Draft   draft-ali-ccamp-gmpls-uni-error-notification-00.txt 


   3.1.3. Example 

   To illustrate usage of this flag, consider an example connection 
   EN1-CN1-CN2-CN3-EN3 in the network specified by figure 1. In this 
   example, the CN2 detects a failure and sends a PathErr message 
   towards EN1, using a local address associated with the failed 
   resource in the ERROR_SPEC.  

   However, CN1's local policy is to conceal the topology of the core 
   network from edge nodes. When CN1 processes the PathErr message, it 
   changes the address in the ERROR_SPEC to CN1's address of the EN1-
   CN1 UNI link. It also sets the Error Node Address Modified flag in 
   the Flags field of the ERROR_SPEC to indicate that a change has been 
   made. The PathErr message is then sent to EN1.  

   3.2. Restoration Notification 

   3.2.1. Error sub-code 

   In order to satisfy restoration notification requirement mentioned 
   above, a new path error sub-code "LSP restored" (value to be 
   assigned by IANA; suggested value: 16) for the error code "Notify 
   Error" (25) is defined.  

   3.2.2. Processing rules 

   When a core node restores an existing LSP after a failure, it SHOULD 
   send a PathErr message with the error code "Notify Error" (25) and 
   error sub-code "LSP restored" (suggested: 16) for the LSP.  

   When an edge node receives a PathErr message with the error code 
   "Notify Error" (25) and error sub-code "LSP restored" (suggested: 
   16), it MAY avoid triggering any other restoration process. 

   4.  Security Considerations 

      This document does not introduce any additional security issues 
      above those identified in [RFC5920], [RFC2205], [RFC3209], 
      [RFC3473] and [RFC4874].  

   5. IANA Considerations 

   5.1. New ERROR_SPEC.Flags 

      This document defines the following new flag value for the Flags 
      field of the IPv4 and IPv6 ERROR_SPEC object defined in 
      [RFC2205].  
    
    
   Ali, Swallow, Hartley, et al  Expires January 2014        [Page 6] 
       






   Internet Draft   draft-ali-ccamp-gmpls-uni-error-notification-00.txt 


       
      ERROR_SPEC.Flags: Error Node Address Modified. Value is to be 
      assigned by IANA (suggested value: 0x08).  
    
   5.2. New RSVP error sub-codes  

      IANA registry: RSVP PARAMETERS 
      Subsection: Error Codes and Globally-Defined Error Value Sub-
      Codes  
       
      For Error Code "Notify Error" (25) (see [RFC3209]) the following 
      sub-code is defined. 
       
         Sub-code                            Value 
         --------                            ----- 
    
         LSP Restored                           To be assigned by IANA. 
                                             Suggested value: 16 
       
   6. Acknowledgements 

      TBD.  
       
   7. References 

   7.1. Normative References 

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

      [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 
                V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 
                LSP Tunnels", RFC 3209, December 2001. 

      [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 
                (GMPLS) Signaling Resource ReserVation Protocol-Traffic 
                Engineering (RSVP-TE) Extensions", RFC 3473, January 
                2003.  

      [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 
                Routes - Extension to Resource ReserVation Protocol-
                Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 




    
    
   Ali, Swallow, Hartley, et al  Expires January 2014        [Page 7] 
       






   Internet Draft   draft-ali-ccamp-gmpls-uni-error-notification-00.txt 


   7.2. Informative References 

      [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 
                "Generalized Multiprotocol Label Switching (GMPLS) 
                User-Network Interface (UNI): Resource ReserVation 
                Protocol-Traffic Engineering (RSVP-TE) Support for the 
                Overlay Model", RFC 4208, October 2005. 

      [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol 
                (RSVP) -- Version 1 Message Processing Rules", RFC 
                2209, September 1997. 

      [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 
                Networks", RFC 5920, July 2010. 

       

   Authors' Addresses 

      Zafar Ali 
      Cisco Systems. 
      Email: zali@cisco.com 
       
      George Swallow 
      Cisco Systems 
      swallow@cisco.com 
       
      Matt Hartley 
      Cisco Systems 
      Email: mhartley@cisco.com  
       
      Clarence Filsfils  
      Cisco Systems, Inc. 
      cfilsfil@cisco.com  
    
    
      Kenji Kumaki  
      KDDI Corporation  
      Email: ke-kumaki@kddi.com   
       
    






    
    
   Ali, Swallow, Hartley, et al  Expires January 2014        [Page 8]