Networking Working Group JP. Vasseur Internet-Draft Cisco Systems, Inc Intended status: Standards Track October 18, 2006 Expires: April 21, 2007 A set of monitoring tools for Path Computation Element based Architecture draft-vasseur-pce-monitoring-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 21, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract A Path Computation Element (PCE) based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Vasseur Expires April 21, 2007 [Page 1] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 Systems). In such PCE-based environment it is thus critical to monitor the state of the path computation chain and potentially gather various performance metrics with regards to the set of involved PCE(s) that can be used for performance monitoring and troubleshooting purposes. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. 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]. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Path Computation Monitoring messages . . . . . . . . . . . . . 4 3.1. Path Computation Monitoring Request message (PCMonReq) . . 4 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 6 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 6 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 7 4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 8 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 9 4.4. TIMESTAMP Object . . . . . . . . . . . . . . . . . . . . . 11 5. Multi-destination monitoring . . . . . . . . . . . . . . . . . 11 6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Elements of procedure . . . . . . . . . . . . . . . . . . . . 12 8. Manageability Considerations . . . . . . . . . . . . . . . . . 13 9. To be considered in a further revision of this document . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Vasseur Expires April 21, 2007 [Page 2] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 1. Terminology LSR: Label Switching Router. PCC: Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element. PCE (Path Computation Element): an entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. TE LSP: Traffic Engineering Label Switched Path. TED: Traffic Engineering Database. 2. Introduction The Path Computation Element (PCE) based architecture has been specified in [RFC4655] for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains where a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. In such PCE-based environment it is thus critical to monitor the state of the path computation chain and potentially gather various performance metrics with regards to the set of involved PCE(s) that can used for performance monitoring and troubleshooting purposes. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in order to monitor the path computation chain and gather various performance metrics. As discussed in [RFC4655], a TE LSP may be computed by one PCE (referred to as single PCE path computation) or several PCE (referred to as multiple PCE path computation). In the former case, the PCC may be able to use IGP extensions to check the availability of the PCE (see [I-D.ietf-pce-disco-proto-ospf] and [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive messages. In contrast, when multiple PCEs are involved in the path computation chain an example of which being the use of the BRPC procedure defined in [I-D.ietf-pce-brpc], the PCC's visibility is limited to the first involved PCE. Thus, it is critical to define mechanisms in order to gather performance metrics along the path computation chain (e.g. liveness, path computation time at each PCE, propagation delays Vasseur Expires April 21, 2007 [Page 3] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 experienced by the path computation request betwen each PCE involved in the path computation chain and so on). 3. Path Computation Monitoring messages As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a common header followed by a variable length body made of a set of objects that can either be mandatory or optional. As a reminder, an object is said to be mandatory in a PCEP message when the object must be included for the message to be considered as valid. The P flag (defined in [I-D.ietf-pce-pcep]) is located in the common header of each PCEP object and can be set by a PCEP peer to enforce a PCE to take into account the related information during the path computation. Because the P flag exclusively relates to a path computation request, it MUST be cleared in the two PCEP messages (PCEMonReq and PCMonRep message) defined in this document. For each PCEP message type a set of rules is defined that specify the set of objects that the message can carry. We use the Backus-Naur Form (BNF) to specify such rules. Square brackets refer to optional sub-sequences. An implementation MUST form the PCEP messages using the object ordering specified in this document. In this document we define two new PCEP messages referred to as the Path Computation Monitoring request (PCMonReq) and Path Computation Monitoring Reply (PCMonRep) message. The aim of the PCMonReq message sent by a PCC to a PCE is to gather performance metrics on a set of PCEs involved in a path computation chain. The PCMonRep message sent by a PCE to a PCC is used to provide such data. 3.1. Path Computation Monitoring Request message (PCMonReq) The Message-Type field of the PCEP common header for the PCMonReq message is set to 8 (To be confirmed by IANA). There is one mandatory object that MUST be included within a PCMonReq message: the Monitoring object (see section Section 4.1). If the Monitoring object is missing, the receiving PCE MUST send an error message to the sender. Other objects are optional. Vasseur Expires April 21, 2007 [Page 4] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 The format of a PCMonReq message is as follows: ::= [] [] where: ::= [] [] [] [] [] [] ::=[] ::= [] The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- BALANCING objects are defined in [I-D.ietf-pce-pcep]. A PCMonReq message is sent to gather various performance metrics along a path computation chain. Such metrics may relate to a specific path computation chain encoded in the form of a series of PCE-ID objects defined in Section 4.2. Alternatively, it may be desired to collect such performance metrics along the path computation chain involved to compute a TE LSP. In that case, the TE LSP attributes are characterized by the set of objects present in a PCEP Path Computation request (PCReq) message (see [I-D.ietf-pce-pcep]). Several metrics may be requested that are specified by a set of objects defined in section Section 4. Note that this set of objects is by all means not limitative and may be extended in further revision of this document. The most simplest form of metric is PCE liveness. For the sake of illustraion, consider the two following examples: Example 1: PCC1 requests to check the path computation chain should a path computation be requested for a specific TE LSP named T1. A PCMonReq message is sent that contains a MONITORING object specifying a path computation check, along with the appropriate set of objects (e.g. RP, END-POINTS, ...) that would be included in a PCReq message for T1. Example 2: PCC1 request to gather the processing time along the path Vasseur Expires April 21, 2007 [Page 5] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 computation chain selected for the computation of T1. In addition to the objects listed in example 1, the PCMonReq message also contains the PROC-TIME object defined in section Section 4.1. Example 3: PCC2 request to gather performance metrics along the specific path computation chain . A PCMonreq message is sent to PCE1 that contains a set of PCE-ID objects that identify PCE1, PCE2, PCE3 and PCE7 respectively. 3.2. Path Monitoring Reply message (PCMonRep) The Message-Type field of the PCEP common header for the PCMonRep message is set to 9 (To be confirmed by IANA). There is one mandatory objects that MUST be included within a PCMonRep message: the Monitoring object (see sectionSection 4.1). If the Monitoring object is missing, the receiving PCE MUST send an error message to the requesting PCC. Other objects are optional. The format of a PCReq message is as follows: ::= [] [] where: ::=[] ::=[] [] [] The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- BALANCING objects are defined in [I-D.ietf-pce-pcep]. 4. Path Computation Monitoring Objects Each new PCEP object defined in the document is compliant to the PCEP object format defined in [I-D.ietf-pce-pcep], with the P flag and the I flag cleared since these flags are exclusively related to path computation request. Several objects are defined in this section that may be also be carried within the PCEP PCReq or PCRep messages defined in [I-D.ietf-pce-pcep] when TE LSP path computation must be peformed in addition to gathering peformance metrics. For example, when a PCC Vasseur Expires April 21, 2007 [Page 6] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 only requires performance metric gathering, the objects defined in this section will be carried within PCMonReq and PCMonRep messages. Conversely, if the PCC requires the computation of the TE LSP in addition to gathering performance metrics, these objects will be carried within PCReq and PCRep messages. 4.1. MONITORING Object The MONITORING object MUST be carried within each PCMonReq and PCMonRep messages and MAY be carried within PCERep and PCReq messages (defined in [I-D.ietf-pce-pcep]) TE LSP path computation must be peformed in addition to gathering peformance metrics. The MONITORING object is used to specify the set of requested performance metrics. The MONITORING Object-Class is to be assigned by IANA (recommended value=16) The MONITORING Object-Type is to be assigned by IANA (recommended value=1) The format of the MONITORING object body 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 |I|P|G|R|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | monitoring-id-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 18 bits - The following flags are currently defined: C (Check) - 1 bit: when set, this indicates that the performance metric of interest is the PCE's availability. R (Record) - 1 bit: when set, this indicates that the PCE's indentifier MUST be included in the corresponding PCMonRep message in the form of a PCE-ID object. G (General) - 1 bit: when set, this indicates that the set of requested performance metric is not related to a particular TE LSP computation: this is a general performance metric, such as the average processing time computed over the X last minutes, ... When the requested performance metric is related to a particular TE LSP Vasseur Expires April 21, 2007 [Page 7] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 computation, the G bit MUST be cleared. P (Processing Time) - 1 bit: the P bit of the MONITORING object carried in a PCMonReq message is set to indicate that the processing times is a metric of interest, in which case a PROC-TIME object MUST be inserted in the corresponding PCMonRep message. The P bit MUST always be set in a PCMonRep message if also set in the corresponding PCMonReq message. I (Incomplete) - 1 bit: the I bit MUST be set by a PCE that supports the PCMonReq message, which does not trigger any policy violation but that cannot provide the set of requested performance metrics for unspecified reasons. Monitoring-id-number (32 bits). The monitoring-id-number value combined with the source IP address of the PCC and the PCE address uniquely identify the monitoring request context. The monitoring-id- number MUST be incremented each time a new monitoring is sent to a PCE. The value 0x0000000 is considered as invalid. If no reply to a monitoring request is received from the PCE, and the PCC wishes to resend its path computation monitoring request, the same monitoring- id-number MUST be used. Conversely, different monitoring-id-number MUST be used for different requests sent to a PCE. The same monitoring-id-number may be used for path computation monitoring requests sent to different PCEs. The path computation monitoring reply is unambiguously identified by the IP source address of the replying PCE. No optional TLVs are currently defined. 4.2. PCE-ID Object The PCE-ID Object is used in a PCMonReq or a message to record the IP address of the PCE for which performance metrics are collected and in a PCMonRep or a PCRep message to record the IP address of the PCE reporting performance metrics or that was involved in the path computation chain. The PCE-ID Object-Class is to be assigned by IANA (recommended value=17) The PCE-ID Object-Type is to be assigned by IANA (recommended value=1) The format of the PCE-ID Object is as follows: Vasseur Expires April 21, 2007 [Page 8] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address-type | Lenght | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // PCE IP Address // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address-type: 1 IPv4 2 IPv6 Length 4 (IPv4) or 16 (IPv6) PCE IP Address: The PCE IP address. It is RECOMMENDED to use the same IP address as the address used in the PCE-ADDRESS sub-TLV defined in [I-D.ietf-pce-disco-proto-ospf] and [I-D.ietf-pce-disco-proto-isis]should a dynamic discovery mechanism be used for PCE discovery. 4.3. PROC-TIME Object The PROC-TIME object MUST be present within a PCMonRep or a PCRep message if the P bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set. The PROC-TIME object is used to report various processing time related metrics. A PCC may request processing time metrics that are not related to a particular request, in which case the request is qualified as a "general" request. For example, the PCC may want to know the minimum, maximum and average processing times on a particular PCE (in this case, general requests can only be made by using PCMonReq/ PCMonRep messages). The Current-processing-time field is used to report the processing time for a particular request the characteristics of which are specified in the corresponding PCMonReq or PCReq message. The algorithm(s) used by a PCE to compute such metrics are out of the scope of this document but a flag is specified that is used to indicate to the requester whether the processing time values were estimated or computed. For example, if the processing time for a specific TE LSP computation is requested, the PCE may either (1) estimate the processing time without performing an actual path computation or (2) effectively perform the computation to report the processing time. Vasseur Expires April 21, 2007 [Page 9] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 When the processing time is requested in addition to a path computation, the PROC-TIME object always report the actual processing time for that request and thus the E bits MUST be cleared. Furthermore, the same object can be used to report the processing time for a particular request in addition to the general processing times computed for a set of requests over a period of time. The PROC-TIME Object-Class is to be assigned by IANA (recommended value=18) The PROC-TIME Object-Type is to be assigned by IANA (recommended value=1) The format of the PROC-TIME object body 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Current-processing-time |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min-processing-time |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-processing-time |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average-processing time |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variance-processing-time |E| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: 18 bits - No Flags are currently defined: E (Estimated) - 1 bit: when set, this indicates that the reported metric value is based on estimated processing time as opposed to actual computation(s). Current-processing-time: This field indicates in milliseconds the processing time for the path computation of interest characterized in the corresponding PCMonReq message and MUST be set to 0x00000000 if the request is a general request (does not relate to a particular path computation request). If the G flag of the MONITORING object is set then this field MUST be set to 0x00000000. Min-processing-time: This field indicates in milliseconds the minimum processing time. The equation/algorithm used to compute this value is implementation specific and outside of the scope of this document Vasseur Expires April 21, 2007 [Page 10] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 (A PCE may decide to compute the minimum processing time over a period of times, for the last N path computation requests, ...). If the G flag of the MONITORING object is cleared then this field MUST be set to 0x00000000. Max-processing-time: This field indicates in milliseconds the maximum processing time. The equation/algorithm used to compute this value is implementation specific and outside of the scope of this document (A PCE may decide to compute the maximum processing time over a period of times, for the last N path computation requests, ...). If the G flag of the MONITORING object if cleared then this field MUST be set to 0x00000000. Average-processing-time: This field indicates in milliseconds the average processing time. The equation/algorithm used to compute this value is implementation specific and outside of the scope of this document (A PCE may decide to compute the average processing time over a period of times, for the last N path computation requests, ...). If the G flag of the MONITORING object if cleared then this field MUST be set to 0x00000000. Variance-processing-time: This field indicates in milliseconds the variance of the processing times. The equation/algorithm used to compute this value is implementation specific and outside of the scope of this document (A PCE may decide to compute the variance processing time over a period of times, for the last N path computation requests, ...). If the G flag of the MONITORING object if cleared then this field MUST be set to 0x00000000. More granularity may be introduced in further revision of this document to get a monitoring metric for a general request of a particular class (e.g. all PCReq of priority X). 4.4. TIMESTAMP Object A TIMESTAMP object will be specified in a further revision of this document that could be used to provide indication on the time at which a PCMonReq message has been received by a PCE and the time at which the PCMonReq message has been relayed to the next-hop PCE or the time at which a PCMonRep message has been sent to the requester. 5. Multi-destination monitoring In a further revision of this document, a new object will be specified allowing a PCC or a user to gather performance metrics for a set of destinations using a single PCMonReq message. For example, using a single PCMonreq message originated by the PCC, performance Vasseur Expires April 21, 2007 [Page 11] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 metrics for the set of path computation chains involved in the computation of a set of TE LSPs will be gathered. Such set of destinations could be specified in the form of a subnets. 6. Policy The receipt of a PCMonReq message may trigger a policy violation on some PCE in which case the PCE MUST send a PCErr message with Error- Type=4 and Error-value=3. 7. Elements of procedure I bit processing: as indicated in section Section 4.1, the I bit MUST be set by a PCE that supports the PCMonReq message, which does not trigger any policy violation but that cannot provide the set of required performance metrics for unspecified reasons. Once set, the I bit MUST NOT be changed by a receiving PCE. Reception of a PCMonReq message: upon receiving a PCMonReq message, if the PCE does not support the PCMonReq message, the PCE MUST send a PCErr message with Error-type=11 and Error-value=1 If the PCE supports the PCMonReq message but the request is prohibited by policy, the PCE MUST send a PCErr message with Error- Type=12 and Error-value=1. If the PCE supports the PCMonReq and the request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain the process of which is being outside of this document. If the PCE is not the last element of the path computation chain, the PCMonReq message is relayed to the next hop PCE: such next-hop may either be specified by means of a PCE-ID object present in the PCMonReq message or dynamically determined by means of a procedure outside of the scope of this document. Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCMonRep message that contains the requested objects according to the set of requested performance metrics listed in the MONITORING object carried in the corresponding PCMonReq message. Reception of a PCMonRep message: upon receiving a PCMonRep message, the PCE processes the request, adds the relevant objects to the PCMonRep message and forwards the PCMonRep message to the upstream requesting PCE or PCC. Vasseur Expires April 21, 2007 [Page 12] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 Special case of Multi-destination monitoring: performance monitoring request related to more than one destinations may lead to involve a set of path computation chains. In that case, a PCE sends each copy of the PCMonReq message to each downstream PCE of each path computation chain. 8. Manageability Considerations To be addressed in a further revision of this document. 9. To be considered in a further revision of this document IT might be desirable to modify the format of the PCMonReq and PCMonRep messages to support the bundling of multiple performance metrics collection for a set of TE LSPs. 10. IANA Considerations Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined in this document: Value Meaning 8 Path Computation Monitoring Request (PCMonReq) 9 Path Computation Monitoring Reply (PCMonRep) The following new PCEP objects are defined in this document. Object-Class Name 16 MONITORING Object-Type 1 17 PCE-ID Object-Type 1 18 PROC-TIME Object-Type 1 A new Error type for the PCErr message (see [I-D.ietf-pce-pcep]) is defined in this document (Error-Type and Error-value to be assigned by IANA). Vasseur Expires April 21, 2007 [Page 13] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 Error-type Meaning 11 Performance Monitoring not supported Error-value 1: Monitoring message not supported by one of PCEs along the domain path 2: MONITORING object missing in a PCMonReq message A new Error-value for the PCErr message Error-types=4 (see [I-D.ietf-pce-pcep]) is defined in this document (Error-Type and Error-value to be assigned by IANA). Error-type Meaning 4 Performance Monitoring Policy violation 3: Monitoring message supported but rejected due to policy violation 11. Security Considerations To be addressed in a further revision of this document. 12. Acknowledgements The author would like to thanks Jean-Louis Le Roux for his useful comments. 13. References 13.1. Normative References [I-D.ietf-pce-pcep] Vasseur, J., "Path Computation Element (PCE) communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep-02 (work in progress), June 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. 13.2. Informative References [I-D.ietf-pce-brpc] Vasseur, J., "A Backward Recursive PCE-based Computation Vasseur Expires April 21, 2007 [Page 14] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc-00 (work in progress), August 2006. [I-D.ietf-pce-disco-proto-isis] Roux, J., "IS-IS protocol extensions for Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-proto-isis-00 (work in progress), September 2006. [I-D.ietf-pce-disco-proto-ospf] Roux, J., "OSPF protocol extensions for Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-proto-ospf-00 (work in progress), September 2006. Author's Address JP Vasseur Cisco Systems, Inc 1414 Massachusetts Avenue Boxborough, MA 01719 USA Email: jpv@cisco.com Vasseur Expires April 21, 2007 [Page 15] Internet-Draft draft-vasseur-pce-monitoring-01.txt October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Vasseur Expires April 21, 2007 [Page 16]