--- 1/draft-ietf-pce-monitoring-03.txt 2009-01-20 14:12:04.000000000 +0100 +++ 2/draft-ietf-pce-monitoring-04.txt 2009-01-20 14:12:04.000000000 +0100 @@ -1,133 +1,153 @@ Networking Working Group JP. Vasseur, Ed. Internet-Draft Cisco Systems, Inc Intended status: Standards Track JL. Le Roux -Expires: May 6, 2009 France Telecom +Expires: July 24, 2009 France Telecom Y. Ikejiri NTT Communications Corporation - November 2, 2008 + January 20, 2009 A set of monitoring tools for Path Computation Element based Architecture - draft-ietf-pce-monitoring-03.txt + draft-ietf-pce-monitoring-04.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. + 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 May 6, 2009. + This Internet-Draft will expire on July 24, 2009. + +Copyright Notice + + Copyright (c) 2009 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. 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 refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous - Systems). In PCE-based environments, it is thus critical to monitor - the state of the path computation chain for troubleshooting and - performance monitoring purposes: liveness of each element (PCE) - involved in the PCE chain, detection of potential resource contention - states and statistics in term of path computation times are examples - of such metrics of interest. This document specifies procedures and - extensions to the Path Computation Element Protocol (PCEP) in order - to gather such information. + Systems). Path Computation Clients (PCCs) send computation requests + to PCEs, and these may forward the requests to and cooperate with + other PCEs forming a "path computation chain". In PCE-based + environments, it is thus critical to monitor the state of the path + computation chain for troubleshooting and performance monitoring + purposes: liveness of each element (PCE) involved in the PCE chain, + detection of potential resource contention states and statistics in + term of path computation times are examples of such metrics of + interest. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Path Computation Monitoring messages . . . . . . . . . . . . . 4 - 3.1. Path Computation Monitoring Request message (PCMonReq) . . 5 - 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 7 - 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 8 - 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 8 - 4.2. PCEP-ID Object . . . . . . . . . . . . . . . . . . . . . . 10 - 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 11 - 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 13 - 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 14 - 7. Manageability Considerations . . . . . . . . . . . . . . . . . 15 - 7.1. Control of Function and Policy . . . . . . . . . . . . . . 15 - 7.2. Information and Data Models . . . . . . . . . . . . . . . 15 - 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 - 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 - 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 15 - 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 15 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . . . . . 20 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Path Computation Monitoring messages . . . . . . . . . . . . . 5 + 3.1. Path Computation Monitoring Request message (PCMonReq) . . 6 + 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9 + 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11 + 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12 + 4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14 + 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 14 + 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 16 + 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 17 + 7. Manageability Considerations . . . . . . . . . . . . . . . . . 19 + 7.1. Control of Function and Policy . . . . . . . . . . . . . . 19 + 7.2. Information and Data Models . . . . . . . . . . . . . . . 19 + 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 + 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 + 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 + 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 20 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 20 + 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 20 + 8.3. New Error-Type and Error-Values . . . . . . . . . . . . . 21 + 8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 21 + 8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22 + 8.6. CONGESTION Object Flag field . . . . . . . . . . . . . . . 22 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 1. 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 refers to a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. + Path Computation Clients (PCCs) send computation requests to PCEs, + and these may forward the requests to and cooperate with other PCEs + forming a "path computation chain". In PCE-based environments, it is + critical to monitor the state of the path computation chain for + troubeshooting and performance monitoring purposes: liveness of each + element (PCE) involved in the PCE chain, detection of potential + resource contention states and statistics in term of path computation + times are examples of such metrics of interest. 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 defined in [RFC4655], there are circumstances where more than one PCE is involved in the computation of a TE LSP. A typical example is when the PCC requires the computation of a TE LSP where the head-end and the tail-end of the TE LSP do not reside in adjacent domains and there is no single PCE with the visibility of both the head-end and tail-end domain. We call the set of PCEs involved in the computation of a TE LSP a "path computation chain". As further discussed in Section 3.1, the PCE chain may either be static (pre-configured) or dynamically determined during the path computation process. - In PCE-based environments, it is critical to monitor the state of the - path computation chain for troubeshooting and performance monitoring - purposes: liveness of each element (PCE) involved in the PCE chain, - detection of potential resource contention states and statistics in - term of path computation times are examples of such metrics of - interest. 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 PCEs (referred to as multiple PCE path computation). In the former case, the PCC may be able to use IGP extensions to check the liveness of the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive messages. In contrast, when multiple PCEs are involved in the path computation chain an example of which is the BRPC procedure defined in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the first PCE involved in the path computation chain. Thus, it is critical to define mechanisms in order to monitor the state of the @@ -152,20 +172,23 @@ more PCEs"). In this document we define two monitoring request types: general and specific. A general monitoring request relates to the collection of a PCE state metrics that is not coupled to a particular path computation request (e.g. average CPU load on a PCE). Conversely, a specific monitoring request relates to a particular path computation request (processing time to complete the path computation for a TE LSP). + The message formats in this document are specified using Backus Naur + Format (BNF) encoding as specified in [I-D.farrel-rtg-common-bnf]. + 2. Terminology 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. @@ -178,45 +201,44 @@ 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 require 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. + set of objects that the message can carry. An implementation MUST + form the PCEP messages using the object ordering specified in this + document. In this document we define two PCEP messages referred to as the Path - Computation Monitoring request (PCMonReq) and Path Computation + Computation Monitoring Request (PCMonReq) and Path Computation Monitoring Reply (PCMonRep) messages so as to handle "out of band" monitoring request. The aim of the PCMonReq message sent by a PCC to a PCE is to gather one or more PCE state 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 a PCErr + message: the MONITORING object (see section Section 4.1). If the + MONITORING object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error- value=4 (MONITORING Object missing). Other objects are optional. - The format of a PCMonReq message is as follows: + Format of a PCMonReq message (out of band request): ::= [] [] [] where: ::= [] [] @@ -229,113 +251,193 @@ [] [] [] [] [] [] ::=[] ::=[] + Format of a PCReq message with monitoring data requested (in band + request): + ::= + + [] + [] + - The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- + where: + ::=[] + ::=[] + + ::= + + [] + [] + [] + [[]] + [] + [] + where: + + ::=[] + + ::=[] + + The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- BALANCING objects are defined in [I-D.ietf-pce-pcep]. The XRO object is defined in [I-D.ietf-pce-pcep-xro] and the OF object is defined in [I-D.ietf-pce-of]. The PCMonReq message is used to gather various PCE state metrics along a path computation chain. The path computation chain may be determined by the PCC (in the form of a series of a series of PCE-ID objects defined in Section 4.2.) or may alternatively be determined by the path computation procedure. For example, if the BRPC procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE LSP, the PCE chain may be determined dynamically. In that case, the PCC sends a PCMonReq message that contains the PCEP objects that - charaterize the TE LSP attributes along with the monitoring objects - (see Section 4.1) that list the set of metric(s) of interest. + charaterize the TE LSP attributes along with the MONITORING object + (see Section 4.1) that lists the set of metrics of interest. Several PCE state metrics may be requested that are specified by a set of objects defined in Section 4. Note that this set of objects may be extended in the future. - For the sake of illustraion, consider the three following examples: + As pointed out in [I-D.ietf-pce-pcep] several situations can arise: - Example 1: PCC1 requests to check the path computation chain that - would be used should it request a path computation 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. + o Bundle of a set of independent and non-synchronized path + computation requests, - Example 2: PCC1 requests a path computation for a TE LSP and also - request to gather the processing time along the path computation - chain selected for the computation of T1. A PCReq message is sent - that also contains a MONITORING object that specifies the performance - metric of interest. The PCRep message also carries a PROC-TIME - object defined in section Section 4.1 that reports the computed - metrics. + o Bundle of a set of independent and synchronized path computation + requests (SVEC object defined below required), - Example 3: PCC2 requests to gather performance metrics along the - specific path computation chain . A PCMonreq - message is sent to PCE1 that contains a sequence of PCE-ID objects - that identify PCE1, PCE2, PCE3 and PCE7 respectively. + o Bundle of a set of dependent and synchronized path computation + requests (SVEC object defined below required). + + In the case of a bundle of a set of request, the MONITORING object + SHOULD only be present in the first PCReq or PCMonReq message and the + monitoring request applies to all the requests of the bundle, even in + the case of dependent and/or synchronized requests sent using more + than one PCReq or PCMonReq message. + + Examples of requests. For the sake of illustration, consider the + three following examples: + + Example 1 (out of band request): PCC1 requests to check the path + computation chain that would be used should it request a path + computation 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 (in band request): PCC1 requests a path computation for a + TE LSP and also request to gather the processing time along the path + computation chain selected for the computation of T1. A PCReq + message is sent that also contains a MONITORING object that specifies + the performance metrics of interest. + + Example 3 (out of band request): PCC2 requests to gather performance + metrics along the specific path computation chain . A PCMonreq message is sent to PCE1 that contains a MONITORING + object and a sequence of PCE-ID objects that identify PCE1, PCE2, + PCE3 and PCE7 respectively. + + In all of the examples above, a PCRep message (in-band request) or + PCMonReq message (out of band request) is sent in response to the + request that reports the computed metrics. 3.2. Path Monitoring Reply message (PCMonRep) The PCMonRep message is used to provide PCE state metrics back to the requester for "out of band" monitoring requests. 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 object that MUST be included within a PCMonRep - message: the Monitoring object (see Section 4.1). If the Monitoring + message: the MONITORING object (see Section 4.1). If the MONITORING object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING Object missing). Other objects are optional. - The format of a PCReq message is as follows: + Format of a PCMonRep (out of band request): ::= [] [] where: ::=[] - ::=[] + ::= [] [] + Format of a PCRep message with monitoring data (in band): + ::= + + + where: + ::=[] + + ::= + + [] + [] + [] + [] + + ::=[] + + ::= + + where: + + ::=[] + [] + [] + [] + + ::=[] + + ::=[] + + ::= + [] + [] + + The RP object is defined in [I-D.ietf-pce-pcep]. 4. Path Computation Monitoring Objects The PCEP objects defined in the document are compliant with 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 requests. + object format defined in [I-D.ietf-pce-pcep]. The P flag and the I + flag of the PCEP objects defined in this document SHOULD always be + set to 0 on transmission and MUST be ignored on receipt since these + flags are exclusively related to path computation requests. Several objects are defined in this section that can be carried within the PCEP PCReq or PCRep messages defined in - [I-D.ietf-pce-pcep] in case of "in band" monitoring requests. In - case of "out of band" monitoring requests, the objects defined in - this section are carried within PCMonReq and PCMonRep messages. - Conversely, if the PCC requests the computation of the TE LSP in - addition to gathering PCE state metrics (i.e. "In band" requests), - these objects are carried within PCReq and PCRep messages. + [I-D.ietf-pce-pcep] in case of "in band" monitoring requests (the PCC + requests the computation of the TE LSP in addition to gathering PCE + state metrics). In case of "out of band" monitoring requests, the + objects defined in this section are carried within PCMonReq and + PCMonRep messages. 4.1. MONITORING Object The MONITORING object MUST be present within PCMonReq and PCMonRep messages ("out of band" monitoring requests) and MAY be carried - within PCERep and PCReq messages ("in band" monitoring requests). + within PCRep and PCReq messages ("in band" monitoring requests). There SHOULD NOT be more than one instance of the MONITORING object: if more than one instance of the MONITORING object is present, the recipient MUST process the first instance and MUST ignore other instances. The MONITORING object is used to specify the set of requested PCE state metrics. The MONITORING Object-Class is to be assigned by IANA (recommended value=19) @@ -365,24 +467,24 @@ PCE-ID object in the corresponding reply. The L bit MUST always be ignored in a PCMonRep or PCRep message. G (General) - 1 bit: when set, this indicates that the monitoring request is a general monitoring request. When the requested performance metric is specific, the G bit MUST be cleared. The G bit MUST always be ignored in a PCMonRep or PCRep message. P (Processing Time) - 1 bit: the P bit of the MONITORING object carried in a PCMonReq or a PCReq 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 or PCRep - message. The P bit MUST always be ignored in a PCMonRep or PCRep - message. + processing times is a metric of interest. If allowed by policy, a + PROC-TIME object MUST be inserted in the corresponding PCMonRep or + PCRep message. The P bit MUST always be ignored in a PCMonRep or + PCRep message. C (Congestion) - 1 bit: The C bit of the MONITORING object carried in a PCMonReq or a PCReq message is set to indicate that the congestion status is a metric of interest, in which case a CONGESTION object MUST be inserted in the corresponding PCMonRep or PCRep message. The C bit MUST always be ignored in a PCMonRep or PCRep message. I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message and that message does not trigger any policy violation, but the PCE cannot provide any of the set of requested performance metrics for @@ -403,56 +505,56 @@ PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint the Monitoring-id-number of pending monitoring requests in case of restart thus avoiding the re-use of a Monitoring-id-number of an in- process monitoring request. Unassigned bits are considered as reserved and MUST be set to zero on transmission and ignored on reception. No optional TLVs are currently defined. -4.2. PCEP-ID Object +4.2. PCE-ID Object - The PCEP-ID Object is used to specify a PCE's IP address. + The PCE-ID Object is used to specify a PCE's IP address. - A set of PCEP-ID objects may be inserted within a PCReq or a PCMonReq + A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq message to specify the PCE for which PCE state metrics are requested and in a PCMonRep or a PCRep message to record the IP address of the PCE reporting PCE state metrics or that was involved in the path computation chain. - Two PCEP-ID objects (for IPv4 and IPv6) are defined. PCEP-ID Object- - Class is to be assigned by IANA (recommended value=20) PCEP-ID - Object-Type is to be assigned by IANA (recommended value=1 for IPv4 - and 2 for IPv6) + Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- + Class is to be assigned by IANA (recommended value=20) PCE-ID Object- + Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 + for IPv6) - The format of the PCEP-ID Object is as follows: + The format of the PCE-ID Object is as follows: - The format of the PCEP-ID object body for IPv4 and IPv6 are as + The format of the PCE-ID object body for IPv4 and IPv6 are 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The PCEP-ID object body has a fixed length of 4 octets for IPv4 and - 16 octets for IPv6. + The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 + octets for IPv6. When a dynamic discovery mechanism is used for PCE discovery, a PCE advertises its PCE address in the PCE-ADDRESS sub-TLV defined in [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and PCMonReq messages and a PCE MUST also use this address in PCRep and PCMonRep messages. 4.3. PROC-TIME Object If allowed by policy, the PCE includes a PROC-TIME object within a @@ -462,29 +565,29 @@ related metrics. 1) Case of general monitoring requests A PCC may request processing time metrics for general monitoring requests (e.g. 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 (as explained below) is exclusively used for specific monitoring requests and MUST be cleared for general - monitoring requests. The algorithm(s) used by a PCE to compute the + monitoring requests. The algorithms used by a PCE to compute the Min, Average, Max and Variance of the processing times are out of the scope of this document (A PCE may decide to compute the minimum processing time over a period of times, for the last N path computation requests, ...). 2) Case of specific monitoring requests - In the case of a specific request, the algorithm(s) used by a PCE to + In the case of a specific request, the algorithms used by a PCE to compute the Procesing-time 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 value was estimated or computed. 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. In the former case, the E bit of the PROC-TIME object MUST be set. The G bit MUST be cleared and the Min-processing-time, Max-processing-time, Average- processing-time and Variance-processing-time MUST be set to 0x00000000. @@ -510,142 +612,188 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min-processing-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-processing-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Average-processing time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variance-processing-time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Flags: 18 bits - No Flags are currently defined: + Flags: 16 bits - one flag is 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). + actual computations. + + Unassigned bits are considered as reserved and MUST be set to zero on + transmission. Current-processing-time: This field indicates in milliseconds the processing time for the path computation of interest characterized in the corresponding PCMonReq message. Min-processing-time: This field indicates in milliseconds the minimum processing time. Max-processing-time: This field indicates in milliseconds the maximum processing time. Average-processing-time: This field indicates in milliseconds the average processing time. Variance-processing-time: This field indicates in milliseconds the variance of the processing times. - Unassigned bits are considered as reserved and MUST be set to zero on - transmission. - - 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. CONGESTION Object - The CONGESTION object MUST be present within a PCMonRep or a PCRep - message if the C bit of the MONITORING object carried within the - corresponding PCMonReq or PCReq message is set. The CONGESTION - object is used to report a PCE processing congestion state. The - CONGESTION Object-Class is to be assigned by IANA (recommended - value=22) The CONGESTION Object-Type is to be assigned by IANA - (recommended value=1) + The CONGESTION object is used to report a PCE processing congestion + state. The CONGESTION object MUST be present within a PCMonRep or a + PCRep message if the C bit of the MONITORING object carried within + the corresponding PCMonReq or PCReq message is set and the PCE is + experiencing a congested state. The CONGESTION Object-Class is to be + assigned by IANA (recommended value=22) The CONGESTION Object-Type is + to be assigned by IANA (recommended value=1) The format of the CONGESTION 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |C| Reserved | Congestion Duration | + | Flags | Reserved | Congestion Duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - C (Congestion) - 1 bit: when set, this indicates that PCE is - congested, in which case the congestion duration may be non nul. - When cleared this indicates that the PCE is not congested and the - "Congestion Duration" field MUST be set to 0x0000. + Flags: 8 bits - No flag is currently defined: - Congestion duration - 16 bits: This field indicates in seconds the - estimated congestion duration. + Congestion duration - 16 bits: This field indicates in the amount of + time in seconds that the responding PCE expects that it may continue + to be congested from the time that the response message was + generated. The receiver MAY use this value to decide whether or not + so send further requests to the same PCE. + + It is worth noting that a PCE along a PCE chain involved in the + monitoring request may decide to learn from the congestion + information received by one of downstream PCE in the chain. 5. 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=5 and Error-value=3 (To be Confirmed by IANA). 6. Elements of Procedure I bit processing: as indicated in section Section 4.1, if a PCE supports a received PCMonReq message and that message does not trigger any policy violation, but the PCE cannot provide any of the set of requested performance metrics for unspecified reasons, the PCE MUST set the I bit. Once set, the I bit MUST NOT be changed by a receiving PCE. - Reception of a PCMonReq message: upon receiving a PCMonReq message: + Upon receiving a PCMonReq message: 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support - the PCMonReq message, the PCE peer must send a PCErr message with - Error-value=2 (capability not supported). + the PCMonReq message, the PCE peer MUST send a PCErr message with + Error-value=2 (capability not supported). According to the procedure + defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives + unrecognized messages at a rate equal of greater than specified rate, + the PCC/PCE must send a PCEP CLOSE message with close + value="Reception of an unacceptable number of unknown PCEP message. + In this case, the PCC/PCE must also close the TCP session and must + not send any further PCEP messages on the PCEP session. - 2) If the PCE supports the PCMonReq message but the request is - prohibited by policy, the PCE MUST send a PCErr message with Error- - Type=5 and Error-value=3. + 2) If the PCE supports the PCMonReq message but the monitoring + request is prohibited by policy, the PCE must follow the procedure + specified in section 5. As pointed out in section 4.3, a PCE may + still partially satisfy a request, leaving out some of the required + data if not allowed by policy. 3) If the PCE supports the PCMonReq and the monitoring request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. 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 PCEP-ID object present in the PCMonReq message or + 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 PCE states metrics listed in the MONITORING object carried in the corresponding PCMonReq message. + Upon receiving a PCReq message that carries a MONITORING and + potentially other monitoring objects (e.g. PCE-ID object): + + 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support + (in band) monitoring, the PCE peer MUST send a PCErr message with + Error-value=2 (capability not supported). According to the procedure + defined in section 6.9 of [I-D.ietf-pce-pcep], if a PCC/PCE receives + unrecognized messages at a rate equal of greater than specified rate, + the PCC/PCE must send a PCEP CLOSE message with close + value="Reception of an unacceptable number of unknown PCEP message. + In this case, the PCC/PCE must also close the TCP session and must + not send any further PCEP messages on the PCEP session. + + 2) If the PCE supports the monitoring request but the monitoring + request is prohibited by policy, the PCE must follow the procedure + specified in section 5. As pointed out in section 4.3, a PCE may + still partially satisfy a request, leaving out some of the required + data if not allowed by policy. + + 3) If the PCE supports the monitoring request and that request is not + prohibited by policy, the receiving PCE MUST first determine whether + it is the last PCE of the path computation chain. If the PCE is not + the last element of the path computation chain, the PCReq message + (with the MONITORING object and potentially other monitoring objects + such as the PCE-ID) is relayed to the next hop PCE: such next-hop may + either be specified by means of a PCE-ID object present in the PCReq + 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 PCRep message + that contains the requested objects according to the set of requested + PCE states metrics listed in the MONITORING and potentially other + monitoring objects carried in the corresponding PCReq message. + Upon receiving 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. + Upon receiving a PCRep message that carrries monitoring data, the + message is processed, additional monitoring data is added according + to this specification and the message is forwarded upstream to the + requesting PCE or PCC. + Special case of Multi-destination monitoring: monitoring request related to more than one destinations may 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. 7. Manageability Considerations 7.1. Control of Function and Policy It MUST be possible to configure the activation/deactivation of PCEP monitoring on a PCEP speaker. In addition to the parameters already listed in section 8.1 of [I-D.ietf-pce-pcep], a PCEP implementation - SHOULD allow configuring on a PCE whether specific, generic, in-band - and out-of-band monitoring requests are allowed or not. Also a PCEP + SHOULD allow configuring on a PCE whether specific, generic, in band + and out of band monitoring requests are allowed or not. Also a PCEP implementation SHOULD allow configuring on a PCE a list of authorized state metrics (aliveness, congestion, processing time, etc). This may apply to any session the PCEP speaker participates in, to a specific session with a given PCEP peer or to a specific group of sessions with a specific group of PCEP peers, for instance the PCEP peers of a neighbor AS. 7.2. Information and Data Models - A new MIB Module MAY be defined that provides local PCE state + A new MIB Module may be defined that provides local PCE state metrics, as well as state metrics of other PCEs gathered using mechanisms defined in this document. 7.3. Liveness Detection and Monitoring This document provides mechanisms to monitor the liveliness and performances of a given PCE chain. 7.4. Verify Correct Operations @@ -659,137 +807,207 @@ other protocols in addition to those already listed in [I-D.ietf-pce-pcep]. 7.6. Impact On Network Operations The frequency of PCMonReq messages may impact the operations of PCEs. An implementation SHOULD allow a limit to be placed on the rate of PCMonReq messages sent by a PCEP speaker and processed from a peer. It SHOULD also allow sending a notification when a rate threshold is reached. An implementation SHOULD allow handling PCReq messages with - a higher priority than PCMonReq messages. + a higher priority than PCMonReq messages. An implementation SHOULD + allow the configuration of a second limit for the PCReq message + requesting monitoring data. 8. IANA Considerations +8.1. New PCEP Message + Each PCEP message has a message type value. 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) + Value Description Reference + 8 Path Computation Monitoring Request (PCMonReq) This document + 9 Path Computation Monitoring Reply (PCMonRep) This document + +8.2. New PCEP Objects Each PCEP object has an Object-Class and an Object-Type. The following new PCEP objects are defined in this document. - Object-Class Name + Object-Class Value Name Object-Type Reference - 19 MONITORING - Object-Type - 1 + 19 MONITORING 1 This document - 20 PCEP-ID - Object-Type - 1: IPv4 addresses - 2: IPv6 addresses + 20 PCE-ID 1: IPv4 addresses This document + 2: IPv6 addresses This document - 21 PROC-TIME - Object-Type - 1 + 21 PROC-TIME 1 This document - 22 CONGESTION - Object-Type - 1 + 22 CONGESTION 1 This document + +8.3. New Error-Type and Error-Values A registry has been created for the Error-type and Error-value of the PCEP Error Object. A new Error-value for the PCErr message Error-types=5 (Policy Violation) (see [I-D.ietf-pce-pcep]) is defined in this document - (Error-Type and Error-value to be assigned by IANA). + (Error-value to be assigned by IANA). - Error-type Meaning - 5 Policy violation - Error-value=3 [This document] - Monitoring message supported but rejected - due to policy violation + Error-Type Meaning Error-value Reference + 5 Policy violation 3 This document + Monitoring message supported + but rejected due to + policy violation A new Error-value for the PCErr message Error-types=6 (Mandatory Object missing) (see [I-D.ietf-pce-pcep]) is defined in this document (Error-Type and Error-value to be assigned by IANA). - Error-type Meaning - 6 Mandatory Object missing - Error-value=4 [This document] + Error-type Meaning Error-value Reference + 6 Mandatory Object missing 4 This document MONITORING Object missing +8.4. MONITORING Object Flag Field + + IANA is requested to create a registry to manage the Flag field of + the MONITORING object. + + New bit numbers may be allocated only by an IETF Consensus action. + Each bit should be tracked with the following qualities: + + o Bit number (counting from bit 0 as the most significant bit) + + o Capability Description + + o Defining RFC + Several bits are defined for the MONITORING Object flag field in this + document: + + Codespace of the Flag field (MONITORING Object) + Bit Description Reference + 0-18 Unassigned + 19 Incomplete This document + 20 Congestion This document + 21 Processing Time This document + 22 General This document + 23 Liveness This document + +8.5. PROC-TIME Object Flag Field + + IANA is requested to create a registry to manage the Flag field of + the PROC-TIME object. + + New bit numbers may be allocated only by an IETF Consensus action. + Each bit should be tracked with the following qualities: + + o Bit number (counting from bit 0 as the most significant bit) + + o Capability Description + + o Defining RFC + + One bit is defined for the PROC-TIME Object flag field in this + document: + + Codespace of the Flag field (PROC-TIME Object) + Bit Description Reference + 0-14 Unassigned + 15 Estimated This document + +8.6. CONGESTION Object Flag field + + IANA is requested to create a registry to manage the Flag field of + the CONGESTION object. + + New bit numbers may be allocated only by an IETF Consensus action. + Each bit should be tracked with the following qualities: + + o Bit number (counting from bit 0 as the most significant bit) + + o Capability Description + o Defining RFC + + One bit is defined for the CONGESTION Object flag field in this + document: + + Codespace of the Flag field (CONGESTION Object) + Bit Description Reference + 0-6 Unassigned + 7 Congestion This document + 9. Security Considerations - Mechanisms discussed in [I-D.ietf-pce-pcep] to secure a PCEP session - (authenticity, integrity, privacy, DoS protection, etc) can be used - to secure the PCMonReq, PCMonRep messages and PCE state metric - objects defined in this document as well. A PCE may face a denial of - service attack with PCMonReq messages. An implementation SHOULD - allow limiting the rate at which PCMonReq messages received from a - specific peer are processed (input shapping), or from another domain - (see also section 7.6). + The use of monitoring data can be used for various attacks such as + denail of service attacks (for example by setting the C bit and + congestion during field of the CONGESTION object to stop PCCs from + using a PCE). Thus it is recommended to make use of the security + mechanisms discussed in [I-D.ietf-pce-pcep] to secure a PCEP session + (authenticity, integrity, privacy, DoS protection, etc) to secure the + PCMonReq, PCMonRep messages and PCE state metric objects defined in + this document. An implementation SHOULD allow limiting the rate at + which PCMonReq or PCReq messages carrying monitoring requests + received from a specific peer are processed (input shapping), or from + another domain (see also section 7.6). 10. Acknowledgements - The authors would like to thank Eiji Oki, Mach Chen and Dimitri - Papadimitriou for their useful comments. Special thank to Adrian - Farrel for his detailed review. + The authors would like to thank Eiji Oki, Mach Chen, Fabien Verhaeghe + and Dimitri Papadimitriou for their useful comments. Special thank + to Adrian Farrel for his detailed review. 11. References 11.1. Normative References + [I-D.farrel-rtg-common-bnf] + Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used + in Various Protocol Specifications", + draft-farrel-rtg-common-bnf-07 (work in progress), + November 2008. + + [I-D.ietf-pce-of] + Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective + Functions in the Path Computation Element Communication + Protocol (PCEP)", draft-ietf-pce-of-06 (work in progress), + December 2008. + [I-D.ietf-pce-pcep] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Computation Element (PCE) Communication Protocol - (PCEP)", draft-ietf-pce-pcep-18 (work in progress), + (PCEP)", draft-ietf-pce-pcep-19 (work in progress), November 2008. + [I-D.ietf-pce-pcep-xro] + Takeda, T., Oki, E., and A. Farrel, "Extensions to the + Path Computation Element Communication Protocol (PCEP) for + Route Exclusions", draft-ietf-pce-pcep-xro-06 (work in + progress), July 2008. + [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. - 11.2. Informative References [I-D.ietf-pce-brpc] Vasseur, J., Zhang, R., Bitar, N., and J. Roux, "A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc-09 (work in progress), April 2008. - [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-08 (work in progress), - September 2007. - - [I-D.ietf-pce-of] - Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective - Functions in the Path Computation Element Communication - Protocol (PCEP)", draft-ietf-pce-of-05 (work in progress), - September 2008. - - [I-D.ietf-pce-pcep-xro] - Takeda, T., Oki, E., and A. Farrel, "Extensions to the - Path Computation Element Communication Protocol (PCEP) for - Route Exclusions", draft-ietf-pce-pcep-xro-06 (work in - progress), July 2008. + [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation + Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. Authors' Addresses @@ -810,50 +1028,10 @@ Email: jeanlouis.leroux@orange-ftgroup.com Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-8019 Japan Email: : y.ikejiri@ntt.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - 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, THE IETF TRUST 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.