Internet DRAFT - draft-dong-teas-inter-layer-abstract-error-report

draft-dong-teas-inter-layer-abstract-error-report







Network Working Group                                            J. Dong
Internet-Draft                                                    X. Wei
Intended status: Standards Track                     Huawei Technologies
Expires: January 5, 2016                                        V. Lopez
                                                     O. Gonzalez de Dios
                                                          Telefonica I+D
                                                            July 4, 2015


  RSVP-TE Extensions for Abstract Error Report in Multi-Layer Traffic
                          Engineered Networks
          draft-dong-teas-inter-layer-abstract-error-report-01

Abstract

   This document provides extensions to the Resource ReserVation
   Protocol-Traffic Engineering (RSVP-TE) to support the report of
   abstract error information across the multi-layer network boundary
   using Generalized Multiprotocol Label Switching (GMPLS) User Network
   Interface (UNI).  Such abstract error information is useful for
   efficient protection and restoration coordination of multi-layer
   Label Switched Paths (LSPs), and is helpful to the fault localization
   and diagnostics in the multi-layer networks.

Requirements Language

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

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 5, 2016.





Dong, et al.             Expires January 5, 2016                [Page 1]

Internet-Draft       GMPLS UNI Abstract Error Report           July 2015


Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  RSVP-TE Extensions for Abstract Error Report  . . . . . . . .   4
   3.  Operation Procedures  . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  IF_ID ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . .   7
     4.2.  RSVP Error Value Sub-codes  . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   In multi-layer Traffic Engineered (TE) networks, end-to-end Traffic
   Engineered (TE) LSPs are established across more than one network
   layers.  If some failure occurs in the network, according to the type
   and location of the failure, different recovery mechanisms could be
   used to provide efficient inter-layer protection and restoration for
   the end-to-end TE LSPs.  Such error information is also helpful for
   fault localization, diagnostics and troubleshooting in the multi-
   layer networks.  However, in multi-layer networks, the exchange of
   detailed error information across the layer boundary should be
   avoided due to the concerns about confidentiality, scalability and
   stability.  This document defines RSVP-TE extensions for the abstract
   error information report for inter-layer TE LSPs, which can meet the
   requirement of efficient protection and fault localization, and the
   constraints on information exchange across the multi-layer network
   boundaries are not violated .




Dong, et al.             Expires January 5, 2016                [Page 2]

Internet-Draft       GMPLS UNI Abstract Error Report           July 2015


   In multi-layer TE networks, several protection mechanisms could be
   deployed to protect the end-to-end inter-layer LSPs, such as local
   protection in the server layer, end-to-end protection/restoration in
   the server layer, and end-to-end protection/restoration initiated in
   the client layer.  In order to achieve multi-layer protection with
   efficient utilization of network resources, appropriate protection
   mechanism should be invoked according to the type and location of the
   failure.

       Client                                                   Client
      Network       +----------------------------------+       Network
    +---------+     |                                  |     +---------+
    |  +----+ |     |  +-----+    +-----+    +-----+   |     | +----+  |
    |  |    | |     |  |     |    |     |    |     |   |UNI-1| |    |  |
    | -+ EN1+-+-----+--+ CN1 +----+ CN3 +----+ CN4 +---+-----+-+ EN3+- |
    |  |    | |  +--+--|     |    |     |    |     |---+-----+-|    |  |
    |  +----+ |  |  |  +--+--+    +--+--+    +--+--+   |UNI-2| +----+  |
    |         |  |  |     |          |          |      |     |         |
    +---------+  |  |     |          |          |      |     +---------+
                 |  |     |          |          |      |
    +---------+  |  |     |          |          |      |     +---------+
    |         |  |  |  +--+--+       |       +--+--+   |     |         |
    |  +----+ |  |  |  |     |       +-------+     |   |     | +----+  |
    |  |    +-+--+  |  | CN2 +---------------+ CN5 |   |     | |    |  |
    | -+ EN2+-+-----+--+     |               |     +---+-----+-+ EN4+- |
    |  |    | |     |  +-----+               +-----+   |     | |    |  |
    |  +----+ |     |                                  |     | +----+  |
    |         |     +----------------------------------+     |         |
    +---------+                Core Network                  +---------+
       Client                                                   Client
      Network                                                  Network
                         Legend:   EN  -  Edge Node
                                   CN  -  Core Node

                   Figure 1:  Multi-layer Network Topology

   Figure 1 shows a multi-layer network topology which is modified based
   on the overlay reference model in [RFC4208] to describe the different
   failure and protection scenarios of an inter-layer LSP.  Assume in
   normal state there is an end-to-end LSP from EN2 to EN3 which
   traverses the path: EN2-CN1-CN3-CN4-EN3.  There are several failure
   cases in which different protection and report behavior should be
   performed.

   o  If a failure occurs in the server layer link CN3-CN4, and the
      server layer protection/restoration could recover this by setting
      up a new path between CN3 and CN4, then the end-to-end LSP between
      EN2 and EN3 will traverse a new path: EN2-CN1-CN3-CN5-CN4-EN3.  In



Dong, et al.             Expires January 5, 2016                [Page 3]

Internet-Draft       GMPLS UNI Abstract Error Report           July 2015


      this case the client layer protection or restoration is not
      needed, while the client layer still SHOULD be informed of the
      failure and restoration happened in the server layer for fault
      localization and diagnostics, and the characteristics of the new
      server layer path may be changed and need to be updated to the
      client layer.

   o  If a failure occurs in the server layer link CN3-CN4, and the
      server layer protection/restoration mechanism cannot recover this
      failure, then the client layer MUST be informed of this situation
      to trigger the client layer protection/restoration mechanism.

   o  If the UNI interface UNI-1 between the edge node EN3 and the
      server layer node CN4 fails, it may be restored efficiently by
      using a stand-by UNI interface UNI-2 along with the existing
      resources in the server layer.  Such restoration may be initiated
      either by the ingress edge node of the end-to-end LSP (EN2 in
      figure 1), or by the nodes adjacent to the failed UNI link (CN4
      and EN3).  In both cases the client layer SHOULD be informed of
      the failure and recovery happened on the UNI link of the end-to-
      end LSP.

   o  If a failure occurs on the UNI link between EN3 and CN4, and
      stand-by UNI interface recovery is not available, the client layer
      node EN2 SHOULD be informed of this failure and trigger the client
      layer protection/restoration mechanism.

   In summary, necessary information about the failure happens in the
   end-to-end inter-layer LSPs SHOULD be exchanged between different
   network layers for appropriate protection/restoration, fault
   localization and diagnostics.  The confidentiality concerns in multi-
   layer networks SHOULD also be considered.

2.  RSVP-TE Extensions for Abstract Error Report

   This section specifies the RSVP-TE extensions for abstracted error
   information report on the end-to-end inter-layer TE LSPs.

   In the IF_ID ERROR_SPEC Object defined in [RFC3473], one new
   Interface_ID TLV "ABSTRACT_LOC" is defined to indicate the abstracted
   failure location:

   Type  Length  Format     Description
   -------------------------------------
   TBD     4    See below   ABSTRACT_LOC






Dong, et al.             Expires January 5, 2016                [Page 4]

Internet-Draft       GMPLS UNI Abstract Error Report           July 2015


   The value field of the "ABSTRACT_LOC" TLV is 32 bit flags numbered
   from the most significant bit as bit zero.  Two flags are defined in
   this document:

   o  Server Layer Internal (I): When set, it indicates the failure
      happens inside the server layer.

   o  UNI (U): When set, it indicates the failure happens on an UNI
      interface between the server layer and the client layer.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved                           |U|I|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Besides, two new Error Values are defined for Error Code 34 "Reroute"
   in [RFC5710] :

   o  Error Value = TBD1, reroute accomplished

   o  Error Value = TBD2, upper layer reroute required

3.  Operation Procedures

   This section describes the procedures of exchanging the abstracted
   error report between interconnected server and client network layers.

   When a failure occurs in the server layer network, and the server
   layer protection/restoration could recover the failure by setting up
   a new server layer path, the ingress client layer edge node of the
   end-to-end LSP does not need to trigger client layer protection
   mechanisms, but it SHOULD be aware of the event happened on the end-
   to-end path.  The server layer node which recovered the failure MUST
   send a PathErr message which carries the ABSTRACT_LOC TLV in the
   IF_ID ERROR_SPEC Object, in which the "I" bit is set.  The error node
   address field MUST be set to zero to indicate this is not to identify
   an error of a particular node.  The error code SHOULD be "Reroute
   (34)" and the Error Value SHOULD be "reroute accomplished".  The
   upstream server layer nodes SHOULD propagate the received PathErr
   message to the previous hop, until the PathErr message reaches the
   client layer edge node.  Upon receipt of this PathErr message, the
   client layer edge node SHOULD not trigger any client layer
   protection/restoration mechanism, as it is indicated in the message
   that the reroute is accomplished.  In this case, the client layer
   edge node and the server layer edge node may also exchange the
   characteristics of the updated server layer path, details of which is
   outside the scope of this document.



Dong, et al.             Expires January 5, 2016                [Page 5]

Internet-Draft       GMPLS UNI Abstract Error Report           July 2015


   When a failure occurs in the server layer network, and the server
   layer protection/restoration mechanism cannot recover the failure,
   the server layer edge node which connects to the ingress client layer
   edge node MUST send a PathErr message which carries the ABSTRACT_LOC
   TLV in the IF_ID ERROR_SPEC Object, in which the "I" bit is set.  The
   error node address field MUST be set to zero to indicate this is not
   to identify an error of a particular node.  The Error Code SHOULD be
   "Reroute (34)" and the Error Value SHOULD be "upper layer reroute
   required".  Upon receipt of this PathErr message, the ingress client
   layer edge node SHOULD trigger the client layer protection/
   restoration mechanism to recover the end-to-end LSP.

   When the UNI interface which connects the remote server layer edge
   and the remote client layer edge fails, and is recovered by a stand-
   by UNI interface, the server layer edge node which connects to the
   recovered UNI interface MUST send a PathErr message which carries the
   ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "U" bit
   is set.  The error node address field MUST be set to zero to indicate
   this is not to identify an error of a particular node.  The Error
   Code SHOULD be "Reroute (34)", the Error Value SHOULD be "reroute
   accomplished".  The upstream server layer nodes SHOULD propagate the
   received PathErr message to the previous hop, until the PathErr
   message reaches the client layer edge node.  Upon receipt of this
   PathErr message, the ingress client layer edge node may send a new
   Path message to refresh the end-to-end inter-layer LSP.

   When a failure happens on the UNI link between the remote server
   layer and client layer edge nodes, and the stand-by UNI interface
   recovery is not available, the server layer edge node which connects
   to the failed UNI interface MUST send a PathErr message which carries
   the ABSTRACT_LOC TLV in the IF_ID ERROR_SPEC Object, in which the "U"
   bit is set.  The error node address field MUST be set to zero to
   indicate this is not to identify an error of a particular node.  The
   Error Code SHOULD be "Reroute (34)" and the Error Value SHOULD be
   "upper layer reroute required".  The upstream server layer nodes
   SHOULD propagate the received PathErr message to the previous hop,
   until the PathErr message reaches the client layer edge node.  The
   client layer edge node SHOULD trigger the client layer protection/
   restoration mechanism based on the received PathErr message.

4.  IANA Considerations

   IANA is requested to administer the assignment of new values defined
   in this document and summarized in this section.







Dong, et al.             Expires January 5, 2016                [Page 6]

Internet-Draft       GMPLS UNI Abstract Error Report           July 2015


4.1.  IF_ID ERROR_SPEC TLVs

   IANA maintains a registry called "GMPLS Signaling Parameters" with a
   sub-registry called "Interface_ID Types".

   IANA is requested to assign a new TLV type for the "ABSTRACT_LOC" TLV
   defined in this document.

4.2.  RSVP Error Value Sub-codes

   IANA maintains a registry called "Resource Reservation Protocol
   (RSVP) Parameters" with a sub-registry called "Error Codes and
   Globally-Defined Error Value Sub-Codes".

   IANA is requested to assign two new Error Value sub-codes for the
   "Reroute" Error Code:

      Value   |  Description                   | Reference
   -----------+--------------------------------+--------------
       TBA    |  reroute accomplished          | this document
       TBA    |  upper layer reroute required  | this document

5.  Security Considerations

   This document does not introduce any new security issues above those
   identified in [RFC3209] and [RFC3473].  For a more comprehensive
   discussion of GMPLS security and attack mitigation techniques, please
   see the Security Framework for MPLS and GMPLS Networks [RFC5920].

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.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 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.




Dong, et al.             Expires January 5, 2016                [Page 7]

Internet-Draft       GMPLS UNI Abstract Error Report           July 2015


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

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

   [RFC5710]  Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr
              Message Triggered MPLS and GMPLS LSP Reroutes", RFC 5710,
              January 2010.

7.2.  Informative References

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

Authors' Addresses

   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com


   Xiugang Wei
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: weixiugang@huawei.com


   Victor Lopez
   Telefonica I+D
   Don Ramon de la Cruz 82-84
   Madrid  28045
   Spain

   Email: victor.lopezalvarez@telefonica.com





Dong, et al.             Expires January 5, 2016                [Page 8]

Internet-Draft       GMPLS UNI Abstract Error Report           July 2015


   Oscar Gonzalez de Dios
   Telefonica I+D
   Don Ramon de la Cruz 82-84
   Madrid  28045
   Spain

   Email: oscar.gonzalezdedios@telefonica.com












































Dong, et al.             Expires January 5, 2016                [Page 9]