[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
   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]