PCE Working Group H. Pouyllau Internet-Draft Alcatel-Lucent Intended status: Standards Track R. Theillaud Expires: September 9, 2010 Marben Products J. Meuric France Telecom March 8, 2010 Extension to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications draft-pouyllau-pce-enhanced-errors-01.txt Abstract 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Pouyllau, et al. Expires September 9, 2010 [Page 1] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Error use-case . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. Notification use-case . . . . . . . . . . . . . . . . . . 5 2.2. PCEP Description . . . . . . . . . . . . . . . . . . . . . 5 2.3. PCEP Behaviors . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1. PCEP Behaviors in Case of Error . . . . . . . . . . . . . 6 2.3.2. PCEP Behaviors in Case of Notification . . . . . . . . . . 6 3. Conventions used in this document . . . . . . . . . . . . 8 4. Error and Notification Handling in PCEP . . . . . . . . . 9 4.1. Error definition . . . . . . . . . . . . . . . . . . . . . 9 4.2. Notification definition . . . . . . . . . . . . . . . . . 10 4.3. Propagation Restrictions . . . . . . . . . . . . . . . . . 10 4.3.1. Time-To-Live object . . . . . . . . . . . . . . . . . . . 11 4.3.2. DIFFUSION-LIST Object (DLO) . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 6.1. New Error-Type . . . . . . . . . . . . . . . . . . . . . . 14 6.2. New Notification-Type . . . . . . . . . . . . . . . . . . 14 6.3. New TTL object . . . . . . . . . . . . . . . . . . . . . . 14 6.4. New DLO object . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informational References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 Pouyllau, et al. Expires September 9, 2010 [Page 2] Internet-Draft Extension to PCEP for Enhanced errors March 2010 1. Terminology PCE terminology is defined in [RFC4655]. PCEP Peer: An element involved in a PCEP session (i.e. a PCC or a PCE). 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. Pouyllau, et al. Expires September 9, 2010 [Page 3] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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 [I-D.ietf-pce-vendor-constraints]. 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 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). Pouyllau, et al. Expires September 9, 2010 [Page 4] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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. 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- Pouyllau, et al. Expires September 9, 2010 [Page 5] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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: 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) Pouyllau, et al. Expires September 9, 2010 [Page 6] Internet-Draft Extension to PCEP for Enhanced errors March 2010 or to a list of identified peers. Pouyllau, et al. Expires September 9, 2010 [Page 7] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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]. Pouyllau, et al. Expires September 9, 2010 [Page 8] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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. Note that, this document does not reconsider the ones previously defined in [RFC5440]. 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. 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. Pouyllau, et al. Expires September 9, 2010 [Page 9] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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. 4.3. Propagation Restrictions In order to limit the propagation of errors and notifications, the following mechanisms SHOULD be used: A Time-To-Live object: to limit the number of PCEP peers that will recursively receive the message; A Diffusion List Object (DLO): to indicate the PCEP peer addresses or domains of PCEP peers the message must be propagate to; 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. Pouyllau, et al. Expires September 9, 2010 [Page 10] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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. 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 Pouyllau, et al. Expires September 9, 2010 [Page 11] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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: 0: Any PCEP peer indicated in the list must be reached. 1: Only PCEs must be reached (and not PCC). 2: All PCEP peers with which a session is still opened must be reached 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) If the error or notification codes target specific PCEP peers, a Diffusion list Object avoids partially flooding all PCEP peers. Any PCEP peer receiving a message of error-type 17 or 19 or notification- type 4 or 5 and where a DLO appears MUST remove from the DLO the addresses of the PCEP peers to whom it will propagate the message, before sending them the message. This is performed adding the PCEP peer addresses to the Explicit eXclusion Route Sub-object of the DLO. If a Diffusion 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. Pouyllau, et al. Expires September 9, 2010 [Page 12] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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. Pouyllau, et al. Expires September 9, 2010 [Page 13] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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 this document to be propagated 0-255: Unassigned 18 Unrecoverable error this document 0-255: Unassigned 19 Unrecoverable error to be propagated this document 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 Pouyllau, et al. Expires September 9, 2010 [Page 14] Internet-Draft Extension to PCEP for Enhanced errors March 2010 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 Pouyllau, et al. Expires September 9, 2010 [Page 15] Internet-Draft Extension to PCEP for Enhanced errors March 2010 7. Acknowledgements 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. Pouyllau, et al. Expires September 9, 2010 [Page 16] Internet-Draft Extension to PCEP for Enhanced errors March 2010 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. 8.2. Informational References [I-D.ietf-pce-vendor-constraints] Farrel, A. and G. Bernstein, "Conveying Vendor-Specific Constraints in the Path Computation Element Protocol", draft-ietf-pce-vendor-constraints-01 (work in progress), March 2010. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. Pouyllau, et al. Expires September 9, 2010 [Page 17] Internet-Draft Extension to PCEP for Enhanced errors March 2010 Authors' Addresses Helia Pouyllau Alcatel-Lucent Route de Villejust NOZAY 91620 FRANCE Phone: + 33 (0)1 30 77 63 11 Email: helia.pouyllau@alcatel-lucent.com Remi Theillaud Marben Products 176 rue Jean Jaures Puteaux 92800 FRANCE Phone: + 33 (0)1 79 62 10 22 Email: remi.theillaud@marben-products.com Julien Meuric France Telecom 2, avenue Pierre Marzin Lannion 22307 FRANCE Email: julien.meuric@orange-ftgroup.com Pouyllau, et al. Expires September 9, 2010 [Page 18]