[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 draft-ietf-pce-enhanced-errors

PCE Working Group                                         H. Pouyllau
Internet Draft                                          Alcatel-Lucent
Intended status: March 2, 2010
Expires: September 2010                                   R. Theillaud
                                                       Marben Products

                                                            J. Meuric
                                                        France Telecom

                                                         February 2010

      Extension to the Path Computation Element Communication Protocol
                   for Enhanced Error and Notifications
                <draft-pouyllau-pce-enhanced-errors-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 September 2, 2010.

Copyright Notice

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

Abstract



H.Pouyllau            Expires September 2, 2010               [Page 1]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


   This document defines new error and notification types and codes for
   the PCE Communication Protocol (PCEP) [RFC5440]. It identifies the
   possible PCEP behaviors in case of error or notification. Thus, this
   draft extends error and notification types in order to associate
   predefined PCEP behaviors.

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

Table of Contents

   1. Terminology.................................................2
   2. Introduction................................................3
      2.1. Examples...............................................3
         2.1.1. Error use-case.....................................3
         2.1.2. Notification use-case..............................4
      2.2. PCEP Description........................................4
      2.3. PCEP Behaviors.........................................5
         2.3.1. PCEP Behaviors in Case of Error....................5
         2.3.2. PCEP Behaviors in Case of Notification.............5
   3. Conventions used in this document............................6
   4. Error and Notification Handling in PCEP......................6
      4.1. Error Definition........................................6
      4.2. Notification Definition.................................7
      4.3. Propagation Restrictions................................8
         4.3.1. Time-To-Live object................................8
         4.3.2. DIFFUSION-LIST Object (DLO)........................8
   5. Security Considerations.....................................10
   6. IANA Considerations........................................10
      6.1. New Error-Type........................................10
      6.2. New Notification-Type..................................11
      6.3. New TTL object........................................11
      6.4. New DLO object........................................11
   7. References.................................................12
      7.1. Normative References...................................12
   8. Acknowledgments............................................12

1. Terminology


   PCE terminology is defined in [RFC4655].

   PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a
   PCE).



H.Pouyllau            Expires September 2, 2010               [Page 2]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


   Source PCC: the PCC which, for a given path computation request,
   initiates all the successive requests.

   Target PCE: the PCE with the scope of the destination node address.


2. Introduction

   The PCE Communication Protocol [RFC5440] is designed to be flexible
   and extensible in order to allow future evolutions or specific
   constraint support such as proposed in [vendor]. Crossing different
   PCE implementations (e.g. from different providers or due to
   different releases), a PCEP request may encounter unknown errors or
   notification messages. In such a case, the PCEP RFC [RFC5440]
   specifies to send a specific error code to the PCEP peer.

   In the context of path computation crossing different routing domains
   or autonomous systems, the number of different PCE system
   specificities is potentially high, thus possibly leading to divergent
   and unstable situations. Such phenomenon can also occur in
   homogeneous cases since PCE systems have their own policies that can
   introduce differences in requests treatment even for requests having
   the same destination. Extending error and notification codes allow
   generalizing PCEP behaviors over heterogeneous PCE systems. Dealing
   with heterogeneity is a major challenge considering PCE
   applicability, particularly in multi-domain contexts. Thus, extending
   such error codes and PCEP behaviors accordingly would improve
   interoperability among different PCEP implementations and would solve
   some of these unstable issues. However, note that, some of them would
   still remain (e.g. the divergences in request treatment introduced by
   different policies).

   The purpose of this draft is to specify some PCEP error codes in
   order to generalize PCEP behaviors.

2.1. Examples

   The two following scenarios underline the need for a normalization of
   the PCEP behaviors according to the error or notification type.


2.1.1. Error use-case

   PCE(i-1) has send a request to PCE(i) which has also sent a request
   to PCE(i+1). PCE(i-1) and PCE(i+1) have the same error semantic but
   not PCE(i). If PCE(i+1) throws an error type and value unknown by
   PCE(i). PCE(i) could then adopt any other behaviors and sends back to


H.Pouyllau            Expires September 2, 2010               [Page 3]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


   PCE(i-1) an error of type 2 (Capability not supported), 3 (Unknown
   Object) or 4 (Not supported Object) for instance. As a consequence,
   the path request would be cancelled but the error has no meaning for
   PCE(i-1) whereas a simple backward of the error sent by PCE(i+1)
   would have been understandable by PCE(i-1).

2.1.2. Notification use-case

   PCE(i-1) has sent a request to PCE(i) which has also sent a request
   to PCE(i+1) but PCE(i+1) is overloaded. Without extensions, PCE(i+1)
   should send a notification of type 2 and a value flag giving its
   estimated congestion duration. PCE(i) can choose to stop the path
   computation and send a NO_PATH reply to PCE(i-1). Hence, PCE(i-1)
   ignores the congestion duration on PCE(i+1) and could seek it for
   further requests.

2.2. PCEP Description

   One of the purposes of the PCE architecture is to compute paths
   across networks, but an added value is to compute such paths in
   inter-area/layer/domain environments. The PCE Communication Protocol
   [RFC5440] is based on the Transport Communication Protocol (TCP).
   Thus, to compute a path within the PCE architecture, several TCP/PCEP
   sessions have to be set up, in a peer-to-peer manner, along a set of
   identified PCEs.

   When the PCEP session is up for 2 PCEP peers, the PCC of the first
   PCE System (the source PCC) sends a PCEReq message. If the PCC does
   not receive any reply before the dead timer is out, then it goes back
   to the idle state. A PCC can expect two kinds of replies: a PCERep
   message containing one or more valid paths (EROs) or a negative
   PCERep message containing a NO-PATH object.

   Beside PCEReq and PCERep messages, notification and error messages,
   named respectively PCNtf and PCErr, can be sent. There are two types
   of notification messages: type 1 is for cancelling pending requests
   and type 2 for signaling a congestion of the PCE. Several error
   values are described in [RFC5440]. The error types concerning the
   session phase begin at 2, error type 1 values are dedicated to the
   initialization phase.

   As the PCE Communication Protocol is built to work in a peer-to-peer
   manner (i.e. supported by a TCP Connection), it supposes that the
   ''deadtimer'' of the source PCC is long enough to support the end-to-
   end distributed path computation process.




H.Pouyllau            Expires September 2, 2010               [Page 4]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


2.3. PCEP Behaviors

   The exchange of messages in the PCE Communication Protocol is
   described in details when PCEP is in states OpenWait and KeepWait in
   [RFC5440]. When the session is up, message exchange is defined in
   [RFC5440] but detailed behavior is mostly let free to any specific
   implementation. [RFC5441] describes the Backward Recursive Path
   Computation (BRPC) procedure, and, because it considers an inter-
   domain path computation, gives a bigger picture of the possible
   behaviors when the session is up.

2.3.1. PCEP Behaviors in Case of Error


   For a given request, on the reception of a PCErr, identified PCEP
   behaviors are the followings:

   o ''Propagation'': the received message requires to be propagated
      forwardly or backwardly (depending on which PCEP peer has sent the
      message); if the message is a notification, it might required to
      be propagated to any known PCEP peers;

   o ''Status quo'': the received message does not affect the PCEP
      connection but the path computation request is cancelled;

   o ''Unrecoverable'': the received message is an unrecoverable failure
      leading to cancel the path computation and close the TCP
      connection and release the PCEP resources;

   Note that some the behavior ''propagation'' can be combined with the
   others, thus leading to possibilities:

   o ''status quo'',

   o ''unrecoverable'',

   o ''propagation'' and ''status quo'',

   o ''propagation'' and ''unrecoverable''.

2.3.2. PCEP Behaviors in Case of Notification

   Notification messages can be employed in two different manners:
   during the treatment of a PCEP request, or independently from it to
   advertise information (in [RFC5440] the request id list within a
   PCNtf message is optional). Hence, three different behaviors can be
   identified:


H.Pouyllau            Expires September 2, 2010               [Page 5]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


   o ''Status quo'': the notification is or is not request-specific but
      does not imply any forward or backward propagation of the message;

   o ''Request-specific Propagation'': the received message requires to
      be propagated forwardly or backwardly (depending on which peer has
      sent the message) to the PCEP peers;

   o ''Non request-specific Propagation'': the received message must be
      propagated to any known peers (e.g. if PCE discovery is activated)
      or to a list of identified peers.

3. 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 [RFC2119].

4. Error and Notification Handling in PCEP

   This section describes error and notification messages with respect
   to the PCEP behavior description defined in section 2.2.

4.1. Error Definition

   Recall that Error-Type and Error-Value fields of a PCEP-ERROR Object
   are both limited to 8 bits. PCE errors are also always request-
   specific. To support specific behaviors, error types should be added
   w.r.t. [RFC5440] definitions as ensued:

   Error-type    Error-value

   16          0-255: The error is a non-failure error and can be
                    considered as a warning. The PCEP peer receiving
                    such an error can adopt any specific behavior but
                    its PCEP state MUST NOT change. The PCEP peer MUST
                    NOT propagate the message or close the TCP
                    connection.

   17          0-255: The error is a non-failure error and can be
                    considered as a warning. The PCEP peer receiving
                    such an error can adopt any specific behavior but
                    its PCEP state MUST NOT change. The PCEP peer MUST
                    backward (or forward depending on the request way
                    and state) the error message unless it is the source
                    PCC (or the target PCE respectively). The PCEP peer
                    MUST NOT close the TCP connection.



H.Pouyllau            Expires September 2, 2010               [Page 6]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


   18          0-255: The error is a failure error. The PCEP peer
                    receiving such an error can adopt any specific
                    behavior but it MUST NOT propagate the message.
                    Finally, it MUST close the TCP connection, release
                    the PCEP resources and turns into ''Idle'' state.

   19          0-255: The error is a failure error. The PCEP peer
                    receiving such an error can adopt any specific
                    behavior but, finally, it MUST backward (or forward,
                    depending on the request way and state) the error
                    message unless it is the source PCC (or the target
                    PCE respectively). Finally, it MUST close the TCP
                    connection, release the PCEP resources and turns to
                    ''Idle'' state.

4.2. Notification Definition

   Recall that Notification-Type and Notification-Value fields of a
   NOTIFICATION object are both limited to 8 bits. To support specific
   behaviors, notification types should be added with respect to
   [RFC5440] definitions as ensued:

   Notification-type   Notification-value

   3             0-255: The notification targets only one PCE. It
                        might be request-specific. Such a notification
                        MUST NOT be propagated.

   4             0-255: The notification targets the set of PCEs
                        involved in one or a set of path computation
                        requests. The PCE which receives it MUST
                        backward (or forward, depending on the request
                        way and state) it, unless it is the request
                        initiator (or the target PCE respectively). This
                        type of notification is obviously request-
                        specific.

   5             0-255: The notification MUST be forwarded to any
                        known PCEP peer or to a list of indicated PCEP
                        peers. To avoid flooding, such propagation could
                        be limited by fixing a maximal number of PCEP
                        peers and/or including a set of PCEP peers. This
                        type of notification is not request-specific and
                        might imply to open new PCEP sessions. But, a
                        PCEP peer MUST NOT forward such a notification
                        to the PCEP peer from which it received it.



H.Pouyllau            Expires September 2, 2010               [Page 7]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


4.3. Propagation Restrictions


   In order to limit the propagation of errors and notifications, the
   following mechanisms SHOULD be used:

   o A Time-To-Live object: to limit the number of PCEP peers that will
      recursively receive the message;

   o A Diffusion List Object (DLO): to indicate the PCEP peer addresses
      or domains of PCEP peers the message must be propagate to;

   o History mechanisms: if a PCEP peer keeps track of the messages it
      has relayed, it could avoid propagating an error or notification
      it already received.

   Such mechanisms SHOULD be used jointly or independently depending the
   error-type or notification-type they are associated to. Note that, a
   message of notification-type 5 MUST include a DLO and SHOULD include
   a TTL. The conditions of use for the TTL and Diffusion List Object
   are described in sections below.

4.3.1. Time-To-Live object

   The TTL value is set to any integer value to indicate the number of
   PCEP peers that will recursively receive the message. This TTL SHOULD
   be used with error-type 17 and 19 and notification-type 4 and 5. Each
   PCEP peer MUST decrement the TTL value before propagating the
   message. When the TTL value is at 0, the message is no more
   propagated.

   If the message is request-specific (error-type 17 and 19, and
   notification-type 4), and there is no TTL object included, the
   message MUST reach the source PCC (or alternatively the target PCE).

4.3.2. DIFFUSION-LIST Object (DLO)

   The DIFFUSION-LIST Object can be carried within a PCErr and a PCNtf
   message and can either be used in a message sent by a PCC to a PCE or
   by a PCE to a PCC. The DLO MAY be used with error-type 17 and 19 and
   notification-type 4, and it MUST be used with notification-type 5.

   If the error or notification codes target specific PCEP peers, a
   Diffusion list Object avoids partially flooding all PCEP peers. Any
   PCEP peers sending a message of error-type 17 or 19, or of
   notification-type 4 or 5, MUST remove the addresses of the PCEP peers
   from the DLO before propagating the message to them. If a Diffusion


H.Pouyllau            Expires September 2, 2010               [Page 8]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


   List Object is empty, the PCEP peer MUST NOT propagate the message to
   any peer.

   Note that, a Diffusion List Object could contain strict or loose
   addresses to refer to a network domain (e.g. an Autonomous System
   number, an OSPF area, an IP address). Hence, the PCEP peers targeted
   by the message would be the PCEP peers covering the corresponding
   domain. If an address is loose, each time a PCEP peer forwards a
   message to another PCEP peer of this address, it MUST add it to the
   Explicit eXclusion Route Sub-object (EXRS) of the DLO for any
   forwarded message. Hence, a PCE SHOULD avoid forwarding several times
   the same message to the same set of peers. Finally, when an address
   is loose, the forwarding SHOULD be restrained indicating what type of
   PCEP peers are targeted (i.e. PCE and/or PCC). Hence, a Target-Type
   is specified.

   DIFFUSION-LIST Object-Class is 25.

   DIFFUSION-LIST Object-Type is 1.

   The format of the DIFFUSION-LIST body object is as follows:


    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 |   Flags          | TT                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                          |
   //                 (Sub-objects)               //
   |                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Reserved (8 bits): This field MUST be set to zero on transmission and
   MUST be ignored on receipt.

   Flags (16 bits): No flags are currently defined. Unassigned flags
   MUST be set to zero on transmission and MUST be ignored on receipt.

   TT (8 bits): The Target-type restricts the diffusion to certain
   peers. The following values are currently defined:

   o 0: Any PCEP peer indicated in the list must be reached.

   o 1: Only PCEs must be reached (and not PCC).

   o 2: All PCEP peers with which a session is still opened must be
      reached


H.Pouyllau            Expires September 2, 2010               [Page 9]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


   The DLO is made of sub-objects similar to the IRO defined in
   [RFC5440]. The following sub-object types are supported.

       Type Sub-object

       1   IPv4 address

       2   IPv6 address

       4   Unnumbered Interface ID

       5   OSPF area ID

       32  Autonomous System number

       33  Explicit eXclusion Route Sub-object (EXRS)

5. Security Considerations

   Within the introduced set of error-type and notification-type, error-
   type 17 and 19, and notification-type 4 and 5 affects PCEP security
   considerations since they induce propagation behaviors. Thus, a PCEP
   implementation SHOULD activate stateful mechanism when receiving such
   error-type or notification-type in order to avoid DoS attacks.

6. IANA Considerations

   IANA maintains a registry of PCEP parameters. This includes a sub-
   registry for PCEP Objects.

   IANA is requested to make an allocation from the sub-registry as
   follows. The values here are suggested for use by IANA.

6.1. New Error-Type

   Error-type     Meaning and Values                 Reference
   16          Status quo error                     this document
               0-255: Unassigned

   17          Status quo error to be propagated    this document
               0-255: Unassigned

   18          Unrecoverable error                  this document
               0-255: Unassigned

   19          Unrecoverable error
               to be propagated                     this document


H.Pouyllau            Expires September 2, 2010              [Page 10]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


               0-255: Unassigned


6.2. New Notification-Type

   Notification-type   Meaning and Values          Reference
   3             Status quo notifications        this document
                 0-255: Unassigned

   4             Request-specific notification
                 to be propagated                this document
                 0-255: Unassigned

   5             General notification
                 to be propagated                this document
                 0-255: Unassigned

6.3. New TTL object

   TBC



6.4. New DLO object

   Object-class Value    Object-Type and Name       Reference
   25               1: Diffusion list object       this document


   Target-Type Value     Meaning               Reference
   0               Any PCEP peers            this document

   1               PCEs but excludes
                   PCC-only peers           this document

   2               PCEs and PCCs            this document
                   with which a session
                   is still opened


   Subobjects                             Reference
   1: IPv4 prefix                           this document
   2: IPv6 prefix                           this document
   4: Unnumbered Interface ID               this document
   5: OSPF Area ID                          this document
   32: Autonomous system number                 this document
   33: Explicit Exclusion Route subobject (EXRS)      this document


H.Pouyllau            Expires September 2, 2010              [Page 11]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010



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.

   [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path
             Computation Element (PCE)-Based Architecture", RFC 4655,
             August 2006.

   [RFC5440] JP. Vasseur, JL. Leroux, "Path Computation Element (PCE)
             Communication Protocol", RFC 5440, March 2009.

   [RFC5441] JP. Vasseur, R. Zhang, N. Bitar, JL. Leroux, "A Backward-
             Recursive PCE-Based Computation (BRPC) Procedure to Compute
             Shortest Constrained Inter-Domain Traffic Engineering Label
             Switched Paths", RFC 5441, April 2009.

   [vendor] G. Bernstein, A. Farrel, "Conveying Vendor-Specific
             Constraints in the Path Computation Element Protocol",
             Internet PCE working group Draft, draft-ietf-pce-vendor-
             constraints-00, July 2009.

8. Acknowledgments

   This work has been inspired by the French Systematic project
   CARRIOCAS and especially the contributors I. Hwang, A. Cavalli, M.
   Lallali and D. Verchere for their work titled Modelling, validation,
   and verification of PCEP using the IF language.

















H.Pouyllau            Expires September 2, 2010              [Page 12]


Internet-Draft
                       Extension to the PCE Protocol
                 for Enhanced Error and Notifications       March 2010


Authors' Addresses

   Helia Pouyllau
   Alcatel-Lucent
   Route de Villejust
   91620 NOZAY
   FRANCE
   Tel: + 33 (0)1 30 77 63 11
   Email: helia.pouyllau@alcatel-lucent.com

   Remi Theillaud
   Marben Products
   176 rue Jean Jaures
   92800 Puteaux
   FRANCE
   Tel: + 33 (0)1 79 62 10 22

   Email: remi.theillaud@marben-products.com

   Julien Meuric
   France Telecom
   2, avenue Pierre Marzin
   22307 Lannion Cedex
   FRANCE
   Tel: + 33 (0)2 96 05 28 28
   Email: julien.meuric@orange-ftgroup.com






















H.Pouyllau            Expires September 2, 2010              [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/