idnits 2.17.1 draft-ietf-pce-monitoring-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 780. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 791. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 798. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 804. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2, 2008) is 5715 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-pce-disco-proto-isis' is defined on line 715, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-14 ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-06) exists of draft-ietf-pce-of-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Intended status: Standards Track JL. Le Roux 4 Expires: March 6, 2009 France Telecom 5 Y. Ikejiri 6 NTT Communications Corporation 7 September 2, 2008 9 A set of monitoring tools for Path Computation Element based 10 Architecture 11 draft-ietf-pce-monitoring-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 6, 2009. 38 Abstract 40 A Path Computation Element (PCE) based architecture has been 41 specified for the computation of Traffic Engineering (TE) Label 42 Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and 43 Generalized MPLS (GMPLS) networks in the context of single or 44 multiple domains (where a domain refers to a collection of network 45 elements within a common sphere of address management or path 46 computational responsibility such as IGP areas and Autonomous 47 Systems). In PCE-based environments, it is thus critical to monitor 48 the state of the path computation chain for troubleshooting and 49 performance monitoring purposes: liveness of each element (PCE) 50 involved in the PCE chain, detection of potential resource contention 51 states and statistics in term of path computation times are examples 52 of such metrics of interest. This document specifies procedures and 53 extensions to the Path Computation Element Protocol (PCEP) in order 54 to gather such information. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Path Computation Monitoring messages . . . . . . . . . . . . . 4 67 3.1. Path Computation Monitoring Request message (PCMonReq) . . 5 68 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 7 69 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 8 70 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 8 71 4.2. PCEP-ID Object . . . . . . . . . . . . . . . . . . . . . . 10 72 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 11 73 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 13 74 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 14 76 7. Manageability Considerations . . . . . . . . . . . . . . . . . 15 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Intellectual Property and Copyright Statements . . . . . . . . . . 19 86 1. Introduction 88 The Path Computation Element (PCE) based architecture has been 89 specified in [RFC4655] for the computation of Traffic Engineering 90 (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching 91 (MPLS) and Generalized MPLS (GMPLS) networks in the context of single 92 or multiple domains where a domain refers to a collection of network 93 elements within a common sphere of address management or path 94 computational responsibility such as IGP areas and Autonomous 95 Systems. 97 As defined in [RFC4655], there are circumstances where more than one 98 PCE is involved in the computation of a TE LSP. A typical example is 99 when the PCC requires the computation of a TE LSP where the head-end 100 and the tail-end of the TE LSP do not reside in adjacent domains and 101 there is no single PCE with the visibility of both the head-end and 102 tail-end domain. We call the set of PCEs involved in the computation 103 of a TE LSP a "path computation chain". As further discussed in 104 Section 3.1, the PCE chain may either be static (pre-configured) or 105 dynamically determined during the path computation process. 107 In PCE-based environments, it is critical to monitor the state of the 108 path computation chain for troubeshooting and performance monitoring 109 purposes: liveness of each element (PCE) involved in the PCE chain, 110 detection of potential resource contention states and statistics in 111 term of path computation times are examples of such metrics of 112 interest. This document specifies procedures and extensions to the 113 Path Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in 114 order to monitor the path computation chain and gather various 115 performance metrics. 117 As discussed in [RFC4655], a TE LSP may be computed by one PCE 118 (referred to as single PCE path computation) or several PCEs 119 (referred to as multiple PCE path computation). In the former case, 120 the PCC may be able to use IGP extensions to check the liveness of 121 the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive 122 messages. In contrast, when multiple PCEs are involved in the path 123 computation chain an example of which is the BRPC procedure defined 124 in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the 125 first PCE involved in the path computation chain. Thus, it is 126 critical to define mechanisms in order to monitor the state of the 127 path computation chain. 129 This document specifies PCEP extensions in order to gather various 130 state metrics along the path computation chain. In this document we 131 call a "state metric" a metric that characterizes a PCE state. For 132 example, such metric can have a form of a bolean (PCE is alive or 133 not, PCE is congested or not) or a performance metric (path 134 computation time at each PCE). 136 PCE state metrics can be gathered in two different contexts: in band 137 or out of band. By "In band" we refer to the situation whereby a PCC 138 requests to gather metrics in the context of a path computation 139 request. For example, a PCC may send a path computation request to a 140 PCE and may want to know the processing time of that request in 141 addition to the computed path. Conversely, if the request is "out of 142 band", PCE state metric collection is performed as a standalone 143 request (e.g. check the liveness of a specific PCE chain, collect the 144 average processing time computed over the last 5mn period on one or 145 more PCEs"). 147 In this document we define two monitoring request types: general and 148 specific. A general monitoring request relates to the collection of 149 a PCE state metrics that is not coupled to a particular path 150 computation request (e.g. average CPU load on a PCE). Conversely, a 151 specific monitoring request relates to a particular path computation 152 request (processing time to complete the path computation for a TE 153 LSP). 155 2. Terminology 157 PCC (Path Computation Client): any client application requesting a 158 path computation to be performed by a Path Computation Element. 160 PCE (Path Computation Element): an entity (component, application or 161 network node) that is capable of computing a network path or route 162 based on a network graph and applying computational constraints. 164 TE LSP: Traffic Engineering Label Switched Path. 166 3. Path Computation Monitoring messages 168 As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a 169 common header followed by a variable length body made of a set of 170 objects that can either be mandatory or optional. As a reminder, an 171 object is said to be mandatory in a PCEP message when the object must 172 be included for the message to be considered as valid. The P flag 173 (defined in [I-D.ietf-pce-pcep]) is located in the common header of 174 each PCEP object and can be set by a PCEP peer to require a PCE to 175 take into account the related information during the path 176 computation. Because the P flag exclusively relates to a path 177 computation request, it MUST be cleared in the two PCEP messages 178 (PCEMonReq and PCMonRep message) defined in this document. 180 For each PCEP message type a set of rules is defined that specify the 181 set of objects that the message can carry. We use the Backus-Naur 182 Form (BNF) to specify such rules. Square brackets refer to optional 183 sub-sequences. An implementation MUST form the PCEP messages using 184 the object ordering specified in this document. 186 In this document we define two PCEP messages referred to as the Path 187 Computation Monitoring request (PCMonReq) and Path Computation 188 Monitoring Reply (PCMonRep) messages so as to handle "out of band" 189 monitoring request. The aim of the PCMonReq message sent by a PCC to 190 a PCE is to gather one or more PCE state metrics on a set of PCEs 191 involved in a path computation chain. The PCMonRep message sent by a 192 PCE to a PCC is used to provide such data. 194 3.1. Path Computation Monitoring Request message (PCMonReq) 196 The Message-Type field of the PCEP common header for the PCMonReq 197 message is set to 8 (To be confirmed by IANA). 199 There is one mandatory object that MUST be included within a PCMonReq 200 message: the Monitoring object (see section Section 4.1). If the 201 Monitoring object is missing, the receiving PCE MUST send a PCErr 202 message with Error-type=6 (Mandatory Object missing) and Error- 203 value=4 (MONITORING Object missing). Other objects are optional. 205 The format of a PCMonReq message is as follows: 206 ::= 207 208 [] 209 [] 210 [] 211 where: 213 ::= 214 [] 215 [] 217 ::=[] 219 ::= 220 221 [] 222 [] 223 [] 224 [] 225 [] 226 [] 227 [] 229 ::=[] 231 ::=[] 233 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- 234 BALANCING objects are defined in [I-D.ietf-pce-pcep]. The XRO object 235 is defined in [I-D.ietf-pce-pcep-xro] and the OF object is defined in 236 [I-D.ietf-pce-of]. 238 The PCMonReq message is used to gather various PCE state metrics 239 along a path computation chain. The path computation chain may be 240 determined by the PCC (in the form of a series of a series of PCE-ID 241 objects defined in Section 4.2.) or may alternatively be determined 242 by the path computation procedure. For example, if the BRPC 243 procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE 244 LSP, the PCE chain may be determined dynamically. In that case, the 245 PCC sends a PCMonReq message that contains the PCEP objects that 246 charaterize the TE LSP attributes along with the monitoring objects 247 (see Section 4.1) that list the set of metric(s) of interest. 249 Several PCE state metrics may be requested that are specified by a 250 set of objects defined in Section 4. Note that this set of objects 251 may be extended in the future. 253 For the sake of illustraion, consider the three following examples: 255 Example 1: PCC1 requests to check the path computation chain that 256 would be used should it request a path computation for a specific TE 257 LSP named T1. A PCMonReq message is sent that contains a MONITORING 258 object specifying a path computation check, along with the 259 appropriate set of objects (e.g. RP, END-POINTS, ...) that would be 260 included in a PCReq message for T1. 262 Example 2: PCC1 requests a path computation for a TE LSP and also 263 request to gather the processing time along the path computation 264 chain selected for the computation of T1. A PCReq message is sent 265 that also contains a MONITORING object that specifies the performance 266 metric of interest. The PCRep message also carries a PROC-TIME 267 object defined in section Section 4.1 that reports the computed 268 metrics. 270 Example 3: PCC2 requests to gather performance metrics along the 271 specific path computation chain . A PCMonreq 272 message is sent to PCE1 that contains a sequence of PCE-ID objects 273 that identify PCE1, PCE2, PCE3 and PCE7 respectively. 275 3.2. Path Monitoring Reply message (PCMonRep) 277 The PCMonRep message is used to provide PCE state metrics back to the 278 requester for "out of band" monitoring requests. The Message-Type 279 field of the PCEP common header for the PCMonRep message is set to 9 280 (To be confirmed by IANA). 282 There is one mandatory object that MUST be included within a PCMonRep 283 message: the Monitoring object (see Section 4.1). If the Monitoring 284 object is missing, the receiving PCE MUST send a PCErr message with 285 Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING 286 Object missing). 288 Other objects are optional. 290 The format of a PCReq message is as follows: 291 ::= 292 293 [] 294 [] 296 where: 298 ::=[] 300 ::=[] 301 [] 302 [] 303 [] 305 4. Path Computation Monitoring Objects 307 The PCEP objects defined in the document are compliant with the PCEP 308 object format defined in [I-D.ietf-pce-pcep], with the P flag and the 309 I flag cleared since these flags are exclusively related to path 310 computation requests. 312 Several objects are defined in this section that can be carried 313 within the PCEP PCReq or PCRep messages defined in 314 [I-D.ietf-pce-pcep] in case of "in band" monitoring requests. In 315 case of "out of band" monitoring requests, the objects defined in 316 this section are carried within PCMonReq and PCMonRep messages. 317 Conversely, if the PCC requests the computation of the TE LSP in 318 addition to gathering PCE state metrics (i.e. "In band" requests), 319 these objects are carried within PCReq and PCRep messages. 321 4.1. MONITORING Object 323 The MONITORING object MUST be present within PCMonReq and PCMonRep 324 messages ("out of band" monitoring requests) and MAY be carried 325 within PCRep and PCReq messages ("in band" monitoring requests). The 326 MONITORING object MUST be present within PCMonReq and PCMonRep 327 messages ("out of band" monitoring requests) and MAY be carried 328 within PCERep and PCReq messages ("in band" monitoring requests). 329 There SHOULD NOT be more than one instance of the MONITORING object: 330 if more than one instance of the MONITORING object is present, the 331 recipient MUST process the first instance and MUST ignore other 332 instances. 334 The MONITORING object is used to specify the set of requested PCE 335 state metrics. 337 The MONITORING Object-Class is to be assigned by IANA (recommended 338 value=19) 340 The MONITORING Object-Type is to be assigned by IANA (recommended 341 value=1) 343 The format of the MONITORING object body is as follows: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Reserved | Flags |I|C|P|G|L| 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Monitoring-id-number | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 // Optional TLV(s) // 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Flags: 24 bits 358 The following flags are currently defined: 360 L (Liveness) - 1 bit: when set, this indicates that the state metric 361 of interest is the PCE's liveness and thus the PCE MUST include a 362 PCE-ID object in the corresponding reply. The L bit MUST always be 363 ignored in a PCMonRep or PCRep message. 365 G (General) - 1 bit: when set, this indicates that the monitoring 366 request is a general monitoring request. When the requested 367 performance metric is specific, the G bit MUST be cleared. The G bit 368 MUST always be ignored in a PCMonRep or PCRep message. 370 P (Processing Time) - 1 bit: the P bit of the MONITORING object 371 carried in a PCMonReq or a PCReq message is set to indicate that the 372 processing times is a metric of interest, in which case a PROC-TIME 373 object MUST be inserted in the corresponding PCMonRep or PCRep 374 message. The P bit MUST always be ignored in a PCMonRep or PCRep 375 message. 377 C (Congestion) - 1 bit: The C bit of the MONITORING object carried in 378 a PCMonReq or a PCReq message is set to indicate that the congestion 379 status is a metric of interest, in which case a CONGESTION object 380 MUST be inserted in the corresponding PCMonRep or PCRep message. The 381 C bit MUST always be ignored in a PCMonRep or PCRep message. 383 I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message 384 and that message does not trigger any policy violation, but the PCE 385 cannot provide any of the set of requested performance metrics for 386 unspecified reasons, the PCE MUST set the I bit. The I bit has no 387 meaning in a request and SHOULD be ignored on receipt. 389 Monitoring-id-number (32 bits): The monitoring-id-number value 390 combined with the PCEP-ID of the PCC identifies the monitoring 391 request context. The monitoring-id-number MUST start at a non-zero 392 value and MUST be incremented each time a new monitoring request is 393 sent to a PCE. Each increment SHOULD have a value of 1 and may cause 394 a wrap back to one. If no reply to a monitoring request is received 395 from the PCE, and the PCC wishes to resend its path computation 396 monitoring request, the same monitoring-id-number MUST be used. 397 Conversely, a different monitoring-id-number MUST be used for 398 different requests sent to a PCE. The path computation monitoring 399 reply is unambiguously identified by the monitoring-id-number and the 400 PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint 401 the Monitoring-id-number of pending monitoring requests in case of 402 restart thus avoiding the re-use of a Monitoring-id-number of an in- 403 process monitoring request. 405 Unassigned bits are considered as reserved and MUST be set to zero on 406 transmission and ignored on reception. 408 No optional TLVs are currently defined. 410 4.2. PCEP-ID Object 412 The PCEP-ID Object is used to specify a PCE's IP address. 414 A set of PCEP-ID objects may be inserted within a PCReq or a PCMonReq 415 message to specify the PCE for which PCE state metrics are requested 416 and in a PCMonRep or a PCRep message to record the IP address of the 417 PCE reporting PCE state metrics or that was involved in the path 418 computation chain. 420 Two PCEP-ID objects (for IPv4 and IPv6) are defined. PCEP-ID Object- 421 Class is to be assigned by IANA (recommended value=20) PCEP-ID 422 Object-Type is to be assigned by IANA (recommended value=1 for IPv4 423 and 2 for IPv6) 425 The format of the PCEP-ID Object is as follows: 427 The format of the PCEP-ID object body for IPv4 and IPv6 are as 428 follows: 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | IPv4 Address | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 | IPv6 Address | 441 | | 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 The PCEP-ID object body has a fixed length of 4 octets for IPv4 and 445 16 octets for IPv6. 447 When a dynamic discovery mechanism is used for PCE discovery, a PCE 448 advertises its PCE address in the PCE-ADDRESS sub-TLV defined in 449 [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and 450 PCMonReq messages and a PCE MUST also use this address in PCRep and 451 PCMonRep messages. 453 4.3. PROC-TIME Object 455 If allowed by policy, the PCE includes a PROC-TIME object within a 456 PCMonRep or a PCRep message if the P bit of the MONITORING object 457 carried within the corresponding PCMonReq or PCReq message is set. 458 The PROC-TIME object is used to report various processing time 459 related metrics. 461 1) Case of general monitoring requests 463 A PCC may request processing time metrics for general monitoring 464 requests (e.g. the PCC may want to know the minimum, maximum and 465 average processing times on a particular PCE). In this case, general 466 requests can only be made by using PCMonReq/PCMonRep messages. The 467 processing-time field (as explained below) is exclusively used for 468 specific monitoring requests and MUST be cleared for general 469 monitoring requests. The algorithm(s) used by a PCE to compute the 470 Min, Average, Max and Variance of the processing times are out of the 471 scope of this document (A PCE may decide to compute the minimum 472 processing time over a period of times, for the last N path 473 computation requests, ...). 475 2) Case of specific monitoring requests 477 In the case of a specific request, the algorithm(s) used by a PCE to 478 compute the Procesing-time metrics are out of the scope of this 479 document but a flag is specified that is used to indicate to the 480 requester whether the processing time value was estimated or 481 computed. The PCE may either (1) estimate the processing time 482 without performing an actual path computation or (2) effectively 483 perform the computation to report the processing time. In the former 484 case, the E bit of the PROC-TIME object MUST be set. The G bit MUST 485 be cleared and the Min-processing-time, Max-processing-time, Average- 486 processing-time and Variance-processing-time MUST be set to 487 0x00000000. 489 When the processing time is requested in addition to a path 490 computation (case where the MONITORING object is carried within a 491 PCReq message), the PROC-TIME object always reports the actual 492 processing time for that request and thus the E bit MUST be cleared. 494 The PROC-TIME Object-Class is to be assigned by IANA (recommended 495 value=21) 497 The PROC-TIME Object-Type is to be assigned by IANA (recommended 498 value=1) 500 The format of the PROC-TIME object body is as follows: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Reserved | Flags |E| 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Current-processing-time | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Min-processing-time | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Max-processing-time | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Average-processing time | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Variance-processing-time | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Flags: 18 bits - No Flags are currently defined: 519 E (Estimated) - 1 bit: when set, this indicates that the reported 520 metric value is based on estimated processing time as opposed to 521 actual computation(s). 523 Current-processing-time: This field indicates in milliseconds the 524 processing time for the path computation of interest characterized in 525 the corresponding PCMonReq message. 527 Min-processing-time: This field indicates in milliseconds the minimum 528 processing time. 530 Max-processing-time: This field indicates in milliseconds the maximum 531 processing time. 533 Average-processing-time: This field indicates in milliseconds the 534 average processing time. 536 Variance-processing-time: This field indicates in milliseconds the 537 variance of the processing times. 539 Unassigned bits are considered as reserved and MUST be set to zero on 540 transmission. 542 More granularity may be introduced in further revision of this 543 document to get a monitoring metric for a general request of a 544 particular class (e.g. all PCReq of priority X). 546 4.4. CONGESTION Object 548 The CONGESTION object MUST be present within a PCMonRep or a PCRep 549 message if the C bit of the MONITORING object carried within the 550 corresponding PCMonReq or PCReq message is set. The CONGESTION 551 object is used to report a PCE processing congestion state. The 552 CONGESTION Object-Class is to be assigned by IANA (recommended 553 value=22) The CONGESTION Object-Type is to be assigned by IANA 554 (recommended value=1) 556 The format of the CONGESTION object body is as follows: 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |C| Reserved | Congestion Duration | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 C (Congestion) - 1 bit: when set, this indicates that PCE is 564 congested, in which case the congestion duration may be non nul. 565 When cleared this indicates that the PCE is not congested and the 566 "Congestion Duration" field MUST be set to 0x0000. 568 Congestion duration - 16 bits: This field indicates in seconds the 569 estimated congestion duration. 571 5. Policy 573 The receipt of a PCMonReq message may trigger a policy violation on 574 some PCE in which case the PCE MUST send a PCErr message with Error- 575 Type=5 and Error-value=3 (To be Confirmed by IANA). 577 6. Elements of Procedure 579 I bit processing: as indicated in section Section 4.1, if a PCE 580 supports a received PCMonReq message and that message does not 581 trigger any policy violation, but the PCE cannot provide any of the 582 set of requested performance metrics for unspecified reasons, the PCE 583 MUST set the I bit. Once set, the I bit MUST NOT be changed by a 584 receiving PCE. 586 Reception of a PCMonReq message: upon receiving a PCMonReq message: 588 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support 589 the PCMonReq message, the PCE peer must send a PCErr message with 590 Error-value=2 (capability not supported). 592 2) If the PCE supports the PCMonReq message but the request is 593 prohibited by policy, the PCE MUST send a PCErr message with Error- 594 Type=5 and Error-value=3. 596 3) If the PCE supports the PCMonReq and the monitoring request is not 597 prohibited by policy, the receiving PCE MUST first determine whether 598 it is the last PCE of the path computation chain. If the PCE is not 599 the last element of the path computation chain, the PCMonReq message 600 is relayed to the next hop PCE: such next-hop may either be specified 601 by means of a PCEP-ID object present in the PCMonReq message or 602 dynamically determined by means of a procedure outside of the scope 603 of this document. Conversely, if the PCE is the last PCE of the path 604 computation chain, the PCE originates a PCMonRep message that 605 contains the requested objects according to the set of requested PCE 606 states metrics listed in the MONITORING object carried in the 607 corresponding PCMonReq message. 609 Upon receiving a PCMonRep message: upon receiving a PCMonRep message, 610 the PCE processes the request, adds the relevant objects to the 611 PCMonRep message and forwards the PCMonRep message to the upstream 612 requesting PCE or PCC. 614 Special case of Multi-destination monitoring: monitoring request 615 related to more than one destinations may involve a set of path 616 computation chains. In that case, a PCE sends each copy of the 617 PCMonReq message to each downstream PCE of each path computation 618 chain. 620 7. Manageability Considerations 622 To be addressed in a further revision of this document. 624 8. IANA Considerations 626 Each PCEP message has a message type value. 628 Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined 629 in this document: 631 Value Meaning 632 8 Path Computation Monitoring Request (PCMonReq) 633 9 Path Computation Monitoring Reply (PCMonRep) 635 Each PCEP object has an Object-Class and an Object-Type. The 636 following new PCEP objects are defined in this document. 638 Object-Class Name 640 19 MONITORING 641 Object-Type 642 1 644 20 PCEP-ID 645 Object-Type 646 1: IPv4 addresses 647 2: IPv6 addresses 649 21 PROC-TIME 650 Object-Type 651 1 653 22 CONGESTION 654 Object-Type 655 1 657 A registry has been created for the Error-type and Error-value of the 658 PCEP Error Object. 660 A new Error-value for the PCErr message Error-types=5 (Policy 661 Violation) (see [I-D.ietf-pce-pcep]) is defined in this document 662 (Error-Type and Error-value to be assigned by IANA). 664 Error-type Meaning 665 5 Policy violation 666 Error-value=3 [This document] 667 Monitoring message supported but rejected 668 due to policy violation 670 A new Error-value for the PCErr message Error-types=6 (Mandatory 671 Object missing) (see [I-D.ietf-pce-pcep]) is defined in this document 672 (Error-Type and Error-value to be assigned by IANA). 674 Error-type Meaning 675 6 Mandatory Object missing 676 Error-value=4 [This document] 677 MONITORING Object missing 679 9. Security Considerations 681 To be addressed in a further revision of this document. 683 10. Acknowledgements 685 The authors would like to thank Eiji Oki, Mach Chen and Dimitri 686 Papadimitriou for their useful comments. Special thank to Adrian 687 Farrel for his detailed review. 689 11. References 691 11.1. Normative References 693 [I-D.ietf-pce-pcep] 694 Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, 695 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, 696 "Path Computation Element (PCE) Communication Protocol 697 (PCEP)", draft-ietf-pce-pcep-14 (work in progress), 698 September 2008. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 704 Element (PCE)-Based Architecture", RFC 4655, August 2006. 706 11.2. Informative References 708 [I-D.ietf-pce-brpc] 709 Vasseur, J., Zhang, R., Bitar, N., and J. Roux, "A 710 Backward Recursive PCE-based Computation (BRPC) Procedure 711 To Compute Shortest Constrained Inter-domain Traffic 712 Engineering Label Switched Paths", draft-ietf-pce-brpc-09 713 (work in progress), April 2008. 715 [I-D.ietf-pce-disco-proto-isis] 716 Roux, J., "IS-IS Protocol Extensions for Path Computation 717 Element (PCE) Discovery", 718 draft-ietf-pce-disco-proto-isis-08 (work in progress), 719 September 2007. 721 [I-D.ietf-pce-of] 722 Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective 723 Functions in the Path Computation Element Communication 724 Protocol (PCEP)", draft-ietf-pce-of-04 (work in progress), 725 August 2008. 727 [I-D.ietf-pce-pcep-xro] 728 Takeda, T., Oki, E., and A. Farrel, "Extensions to the 729 Path Computation Element Communication Protocol (PCEP) for 730 Route Exclusions", draft-ietf-pce-pcep-xro-06 (work in 731 progress), July 2008. 733 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 734 "OSPF Protocol Extensions for Path Computation Element 735 (PCE) Discovery", RFC 5088, January 2008. 737 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 738 "IS-IS Protocol Extensions for Path Computation Element 739 (PCE) Discovery", RFC 5089, January 2008. 741 Authors' Addresses 743 JP Vasseur (editor) 744 Cisco Systems, Inc 745 1414 Massachusetts Avenue 746 Boxborough, MA 01719 747 USA 749 Email: jpv@cisco.com 750 JL Le Roux 751 France Telecom 752 2, Avenue Pierre-Marzin 753 Lannion, 22307 754 FRANCE 756 Email: jeanlouis.leroux@orange-ftgroup.com 758 Yuichi Ikejiri 759 NTT Communications Corporation 760 1-1-6, Uchisaiwai-cho, Chiyoda-ku 761 Tokyo, 100-8019 762 Japan 764 Email: : y.ikejiri@ntt.com 766 Full Copyright Statement 768 Copyright (C) The IETF Trust (2008). 770 This document is subject to the rights, licenses and restrictions 771 contained in BCP 78, and except as set forth therein, the authors 772 retain all their rights. 774 This document and the information contained herein are provided on an 775 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 776 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 777 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 778 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 779 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 780 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 782 Intellectual Property 784 The IETF takes no position regarding the validity or scope of any 785 Intellectual Property Rights or other rights that might be claimed to 786 pertain to the implementation or use of the technology described in 787 this document or the extent to which any license under such rights 788 might or might not be available; nor does it represent that it has 789 made any independent effort to identify any such rights. Information 790 on the procedures with respect to rights in RFC documents can be 791 found in BCP 78 and BCP 79. 793 Copies of IPR disclosures made to the IETF Secretariat and any 794 assurances of licenses to be made available, or the result of an 795 attempt made to obtain a general license or permission for the use of 796 such proprietary rights by implementers or users of this 797 specification can be obtained from the IETF on-line IPR repository at 798 http://www.ietf.org/ipr. 800 The IETF invites any interested party to bring to its attention any 801 copyrights, patents or patent applications, or other proprietary 802 rights that may cover technology that may be required to implement 803 this standard. Please address the information to the IETF at 804 ietf-ipr@ietf.org.