idnits 2.17.1 draft-ietf-pce-monitoring-01.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 == Line 711 has weird spacing: '...compute short...' -- 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 (February 6, 2008) is 5923 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-09 ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-09) exists of draft-ietf-pce-brpc-06 == Outdated reference: A later version (-06) exists of draft-ietf-pce-of-01 == Outdated reference: A later version (-06) exists of draft-ietf-pce-pcep-xro-02 Summary: 2 errors (**), 0 flaws (~~), 7 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: August 9, 2008 France Telecom 5 Y. Ikejiri 6 NTT Communications Corporation 7 February 6, 2008 9 A set of monitoring tools for Path Computation Element based 10 Architecture 11 draft-ietf-pce-monitoring-01.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 August 9, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 A Path Computation Element (PCE) based architecture has been 45 specified for the computation of Traffic Engineering (TE) Label 46 Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and 47 Generalized MPLS (GMPLS) networks in the context of single or 48 multiple domains (where a domain is referred to as a collection of 49 network elements within a common sphere of address management or path 50 computational responsibility such as IGP areas and Autonomous 51 Systems). In PCE-based environments it is thus critical to monitor 52 the state of the path computation chain for troubleshooting and 53 performance monitoring purposes: liveness of each element (PCE) 54 involved in the PCE chain, detection of potential resource contention 55 states, statistics in term of path computation times are examples of 56 such metrics of interest. This document specifies procedures and 57 extensions to the Path Computation Element Protocol (PCEP) in order 58 to gather such information. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 Table of Contents 68 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Path Computation Monitoring messages . . . . . . . . . . . . . 5 71 3.1. Path Computation Monitoring Request message (PCMonReq) . . 6 72 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 8 73 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 9 74 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 9 75 4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 11 76 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 12 77 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 14 78 4.5. TIMESTAMP Object . . . . . . . . . . . . . . . . . . . . . 15 79 5. Multi-destination monitoring . . . . . . . . . . . . . . . . . 15 80 6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7. Elements of procedure . . . . . . . . . . . . . . . . . . . . 15 82 8. Manageability Considerations . . . . . . . . . . . . . . . . . 16 83 9. To be considered in a further revision of this document . . . 16 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18 89 13.2. Informative References . . . . . . . . . . . . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 91 Intellectual Property and Copyright Statements . . . . . . . . . . 20 93 1. Terminology 95 AS: Autonomous System. 97 LSR: Label Switching Router. 99 PCC (Path Computation Client): any client application requesting a 100 path computation to be performed by a Path Computation Element. 102 PCE (Path Computation Element): an entity (component, application or 103 network node) that is capable of computing a network path or route 104 based on a network graph and applying computational constraints. 106 TE LSP: Traffic Engineering Label Switched Path. 108 TED: Traffic Engineering Database. 110 2. Introduction 112 The Path Computation Element (PCE) based architecture has been 113 specified in [RFC4655] for the computation of Traffic Engineering 114 (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching 115 (MPLS) and Generalized MPLS (GMPLS) networks in the context of single 116 or multiple domains where a domain is referred to as a collection of 117 network elements within a common sphere of address management or path 118 computational responsibility such as IGP areas and Autonomous 119 Systems. 121 In PCE-based environments, it is critical to monitor the state of the 122 path computation chain for troubeshooting and performance monitoring 123 purposes: liveness of each element (PCE) involved in the PCE chain, 124 detection of potential resource contention states, statistics in term 125 of path computation times are examples of such metrics of interest. 126 This document specifies procedures and extensions to the Path 127 Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in order to 128 monitor the path computation chain and gather various performance 129 metrics. 131 As discussed in [RFC4655], a TE LSP may be computed by one PCE 132 (referred to as single PCE path computation) or several PCEs 133 (referred to as multiple PCE path computation). In the former case, 134 the PCC may be able to use IGP extensions to check the liveness of 135 the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive 136 messages. In contrast, when multiple PCEs are involved in the path 137 computation chain an example of which is the BRPC procedure defined 138 in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the 139 first PCE involved in the path computation chain. Thus, it is 140 critical to define mechanisms in order to monitor the state of the 141 path computation chain. 143 The aim of this document is to specify PCEP extensions in order to 144 gather various state metrics along the path computation chain. In 145 this document we call a "state metric" a metric that characterizes a 146 PCE state. For example, such metric can have a form of a bolean (PCE 147 is alive or not, PCE is congested or not) or a performance metric 148 (path computation time at each PCE). 150 PCE state metrics collection can be gathered in two different 151 contexts: in band or out of band. By "In band" we refer to the 152 situation whereby a PCC requests to gather metrics in the context of 153 a path computation request. For example, a PCC may send a path 154 computation request to a PCE and may want to know the processing time 155 of that request in addition to the computed path. Conversely, if the 156 request is "out of band", PCE state metric collection is performed as 157 a standalone request (e.g. check the liveness of a specific PCE 158 chain, collect the average processing time computed over the last 5mn 159 period on one or more PCE(s)"). 161 In this document we define two monitoring request types: general and 162 specific. A general monitoring request relates to the collection of 163 a PCE state metric(s) that is not coupled to a particular path 164 computation request (e.g. average CPU load on a PCE). Conversely, a 165 specific monitoring request relates to a particular path computation 166 request (processing time to complete the path computation for a TE 167 LSP). 169 3. Path Computation Monitoring messages 171 As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a 172 common header followed by a variable length body made of a set of 173 objects that can either be mandatory or optional. As a reminder, an 174 object is said to be mandatory in a PCEP message when the object must 175 be included for the message to be considered as valid. The P flag 176 (defined in [I-D.ietf-pce-pcep]) is located in the common header of 177 each PCEP object and can be set by a PCEP peer to enforce a PCE to 178 take into account the related information during the path 179 computation. Because the P flag exclusively relates to a path 180 computation request, it MUST be cleared in the two PCEP messages 181 (PCEMonReq and PCMonRep message) defined in this document. 183 For each PCEP message type a set of rules is defined that specify the 184 set of objects that the message can carry. We use the Backus-Naur 185 Form (BNF) to specify such rules. Square brackets refer to optional 186 sub-sequences. An implementation MUST form the PCEP messages using 187 the object ordering specified in this document. 189 In this document we define two PCEP messages referred to as the Path 190 Computation Monitoring request (PCMonReq) and Path Computation 191 Monitoring Reply (PCMonRep) messages so as to handle "out of band" 192 monitoring request. The aim of the PCMonReq message sent by a PCC to 193 a PCE is to gather one or more PCE state metrics on a set of PCEs 194 involved in a path computation chain. The PCMonRep message sent by a 195 PCE to a PCC is used to provide such data. 197 3.1. Path Computation Monitoring Request message (PCMonReq) 199 The Message-Type field of the PCEP common header for the PCMonReq 200 message is set to 8 (To be confirmed by IANA). 202 There is one mandatory object that MUST be included within a PCMonReq 203 message: the Monitoring object (see section Section 4.1). If the 204 Monitoring object is missing, the receiving PCE MUST send an error 205 message to the sender. Other objects are optional. 207 The format of a PCMonReq message is as follows: 208 ::= 209 210 [] 211 [] 212 [] 213 where: 215 ::= 216 [] 217 [] 219 ::=[] 221 ::= 222 223 [] 224 [] 225 [] 226 [] 227 [] 228 [] 229 [] 231 ::=[] 233 ::=[] 235 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- 236 BALANCING objects are defined in [I-D.ietf-pce-pcep]. The XRO object 237 is defined in [I-D.ietf-pce-pcep-xro] and the OF object is defined in 238 [I-D.ietf-pce-of]. 240 The PCMonReq message is used to gather various PCE state metrics 241 along a path computation chain. The path computation chain may be 242 determined by the PCC (in the form of a series of a series of PCE-ID 243 objects defined in Section 4.2.) or may alternatively be determined 244 by the path computation procedure. For example, if the BRPC 245 procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE 246 LSP, the PCE chain may be determined dynamically. In that case, the 247 PCC sends a PCMonReq message that contains the PCEP objects that 248 charaterize the TE LSP attributes along with the monitoring objects 249 (see Section 4.1) that list the set of metric(s) of interest. 251 Several PCE state metrics may be requested that are specified by a 252 set of objects defined in Section 4. Note that this set of objects 253 is by all means not limitative and may be extended in further 254 revision of this document. 256 For the sake of illustraion, consider the three following examples: 258 Example 1: PCC1 requests to check the path computation chain should a 259 path computation be requested for a specific TE LSP named T1. A 260 PCMonReq message is sent that contains a MONITORING object specifying 261 a path computation check, along with the appropriate set of objects 262 (e.g. RP, END-POINTS, ...) that would be included in a PCReq message 263 for T1. 265 Example 2: PCC1 requests a path computation for a TE LSP and also 266 request to gather the processing time along the path computation 267 chain selected for the computation of T1. A PCReq message is sent 268 that also contains a MONITORING object that specifies the performance 269 metric of interest. The PCRep message also comprises a PROC-TIME 270 object defined in section Section 4.1 that reports the computed 271 metrics. 273 Example 3: PCC2 requests to gather performance metrics along the 274 specific path computation chain . A PCMonreq 275 message is sent to PCE1 that contains a set of PCE-ID objects that 276 identify PCE1, PCE2, PCE3 and PCE7 respectively. 278 3.2. Path Monitoring Reply message (PCMonRep) 280 The PCMonRep message is used to provide PCE state metrics back to the 281 requester for "out of band" monitoring requests. The Message-Type 282 field of the PCEP common header for the PCMonRep message is set to 9 283 (To be confirmed by IANA). 285 There is one mandatory object that MUST be included within a PCMonRep 286 message: the Monitoring object (see Section 4.1). If the Monitoring 287 object is missing, the receiving PCE MUST send an error message to 288 the requesting PCC. 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 request. 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 PCERep and PCReq messages ("in band" monitoring requests). 326 There MUST be exactly once instance of the MONITORING object: if more 327 than one instance of the MONITORING object is present, the recipient 328 MUST only process the first instance and ignore other instances. The 329 MONITORING object is used to specify the set of requested PCE state 330 metrics. 332 The MONITORING Object-Class is to be assigned by IANA (recommended 333 value=19) 335 The MONITORING Object-Type is to be assigned by IANA (recommended 336 value=1) 337 The format of the MONITORING object body is as follows: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Reserved | Flags |I|C|P|G|L| 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | monitoring-id-number | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 // Optional TLV(s) // 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Flags: 18 bits 352 The following flags are currently defined: 354 L (Liveness) - 1 bit: when set, this indicates that the state metric 355 of interest is the PCE's liveness and thus the PCE MUST include a 356 PCE-ID object in the corresponding reply. 358 G (General) - 1 bit: when set, this indicates that the monitoring 359 request is a general monitoring request. When the requested 360 performance metric is specific, the G bit MUST be cleared. 362 P (Processing Time) - 1 bit: the P bit of the MONITORING object 363 carried in a PCMonReq or a PCReq message is set to indicate that the 364 processing times is a metric of interest, in which case a PROC-TIME 365 object MUST be inserted in the corresponding PCMonRep or PCRep 366 message. The P bit MUST always be set in a PCMonRep message if also 367 set in the corresponding PCMonReq message. 369 C (Congestion) - 1 bit: The C bit of the MONITORING object carried in 370 a PCMonReq or a PCReq message is set to indicate that the congestion 371 status is a metric of interest, in which case a CONGESTION object 372 MUST be inserted in the corresponding PCMonRep or PCRep message. The 373 C bit MUST always be set in a PCMonRep message if also set in the 374 corresponding PCMonReq message. 376 I (Incomplete) - 1 bit: the I bit MUST be set by a PCE that supports 377 the PCMonReq message, which does not trigger any policy violation but 378 that cannot provide the set of requested performance metrics for 379 unspecified reasons. 381 Monitoring-id-number (32 bits). The monitoring-id-number value 382 combined with the source IP address of the PCC and the PCE address 383 uniquely identify the monitoring request context. The monitoring-id- 384 number MUST be incremented each time a new monitoring is sent to a 385 PCE. The value 0x0000000 is considered as invalid. If no reply to a 386 monitoring request is received from the PCE, and the PCC wishes to 387 resend its path computation monitoring request, the same monitoring- 388 id-number MUST be used. Conversely, different monitoring-id-number 389 MUST be used for different requests sent to a PCE. The same 390 monitoring-id-number may be used for path computation monitoring 391 requests sent to different PCEs. The path computation monitoring 392 reply is unambiguously identified by the IP source address of the 393 replying PCE. 395 Unassigned bits are considered as reserved and MUST be set to zero on 396 transmission. 398 No optional TLVs are currently defined. 400 4.2. PCE-ID Object 402 The PCE-ID Object is used to specify a PCE's IP address. 404 A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq 405 message to specify the PCE for which PCE state metrics are requested 406 and in a PCMonRep or a PCRep message to record the IP address of the 407 PCE reporting PCE state metrics or that was involved in the path 408 computation chain. 410 Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- 411 Class is to be assigned by IANA (recommended value=20) PCE-ID Object- 412 Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 413 for IPv6) 415 The format of the PCE-ID Object is as follows: 417 The format of the PCE-ID object body for IPv4 and IPv6 are as 418 follows: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | IPv4 Address | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | | 430 | IPv6 Address | 431 | | 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 435 octets for IPv6. 437 A PCE MUST use the same IP address as the address used in the PCE- 438 ADDRESS sub-TLV defined in [RFC5088] and [RFC5089] should a dynamic 439 discovery mechanism be used for PCE discovery. 441 4.3. PROC-TIME Object 443 The PROC-TIME object MUST be present within a PCMonRep or a PCRep 444 message if the P bit of the MONITORING object carried within the 445 corresponding PCMonReq or PCReq message is set. The PROC-TIME object 446 is used to report various processing time related metrics. 448 1) Case of general monitoring requests 450 A PCC may request processing time metrics for general monitoring 451 requests (e.g. the PCC may want to know the minimum, maximum and 452 average processing times on a particular PCE). In this case, general 453 requests can only be made by using PCMonReq/PCMonRep messages. The 454 processing-time field (as explained below) is exclusively used for 455 specific monitoring requests and MUST be cleared for general 456 monitoring requests. The algorithm(s) used by a PCE to compute the 457 Min, Average, Max and Variance of the processing times are out of the 458 scope of this document (A PCE may decide to compute the minimum 459 processing time over a period of times, for the last N path 460 computation requests, ...). 462 2) Case of specific monitoring requests 464 In the case of a specific request, the algorithm(s) used by a PCE to 465 compute the Procesing-time metrics are out of the scope of this 466 document but a flag is specified that is used to indicate to the 467 requester whether the processing time value was estimated or 468 computed. The PCE may either (1) estimate the processing time 469 without performing an actual path computation or (2) effectively 470 perform the computation to report the processing time. In the former 471 case, the E bit of the PROC-TIME object MUST be set. The G bit MUST 472 be cleared and the Min-processing-time, Max-processing-time, Average- 473 processing-time and Variance-processing-time MUST be set to 474 0x00000000. 476 When the processing time is requested in addition to a path 477 computation (case where the MONITORING object is carried within a 478 PCReq message), the PROC-TIME object always report the actual 479 processing time for that request and thus the E bits MUST be cleared. 481 The PROC-TIME Object-Class is to be assigned by IANA (recommended 482 value=21) 484 The PROC-TIME Object-Type is to be assigned by IANA (recommended 485 value=1) 487 The format of the PROC-TIME object body is as follows: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Reserved | Flags | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Processing-time |E| 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Min-processing-time | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Max-processing-time | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Average-processing time | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Variance-processing-time | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Flags: 18 bits - No Flags are currently defined: 506 E (Estimated) - 1 bit: when set, this indicates that the reported 507 metric value is based on estimated processing time as opposed to 508 actual computation(s). 510 Current-processing-time: This field indicates in milliseconds the 511 processing time for the path computation of interest characterized in 512 the corresponding PCMonReq message. 514 Min-processing-time: This field indicates in milliseconds the minimum 515 processing time. 517 Max-processing-time: This field indicates in milliseconds the maximum 518 processing time. 520 Average-processing-time: This field indicates in milliseconds the 521 average processing time. 523 Variance-processing-time: This field indicates in milliseconds the 524 variance of the processing times. 526 Unassigned bits are considered as reserved and MUST be set to zero on 527 transmission. 529 More granularity may be introduced in further revision of this 530 document to get a monitoring metric for a general request of a 531 particular class (e.g. all PCReq of priority X). 533 4.4. CONGESTION Object 535 The CONGESTIION object MUST be present within a PCMonRep or a PCRep 536 message if the C bit of the MONITORING object carried within the 537 corresponding PCMonReq or PCReq message is set. The CONGESTION 538 object is used to report a PCE processing congestion state. The 539 CONGESTION Object-Class is to be assigned by IANA (recommended 540 value=22) The CONGESTION Object-Type is to be assigned by IANA 541 (recommended value=1) 543 The format of the CONGESTION object body is as follows: 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 |C| Reserved | Congestion Duration | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 C (Congestion) - 1 bit: when set, this indicates that PCE is 551 congested, in which case the congestion duration may be non nul. 552 When cleared this indicates that the PCE is not congested. 553 Congestion duration - 16 bits: This field indicates in seconds the 554 estimated congestion duration. 556 4.5. TIMESTAMP Object 558 A TIMESTAMP object will be specified in a further revision of this 559 document that could be used to indicate when a PCMonReq message has 560 been received by a PCE and when the PCMonReq message has been relayed 561 to the next-hop PCE or the time at which a PCMonRep message has been 562 sent to the requester. 564 5. Multi-destination monitoring 566 In a further revision of this document, a new object will be 567 specified allowing a PCC or a user to gather PCE state metrics for a 568 set of destinations using a single PCMonReq message. For example, 569 using a single PCMonreq message originated by a PCC, PCE state 570 metrics for the set of path computation chains involved in the 571 computation of a set of TE LSPs will be gathered. Such set of 572 destinations could be specified in the form of a subnets. 574 6. Policy 576 The receipt of a PCMonReq message may trigger a policy violation on 577 some PCE in which case the PCE MUST send a PCErr message with Error- 578 Type=5 and Error-value=3 (To be Confirmed by IANA). 580 7. Elements of procedure 582 I bit processing: as indicated in section Section 4.1, the I bit MUST 583 be set by a PCE that supports the PCMonReq message, which does not 584 trigger any policy violation but that cannot provide the set of 585 required performance metrics for unspecified reasons. Once set, the 586 I bit MUST NOT be changed by a receiving PCE. 588 Reception of a PCMonReq message: upon receiving a PCMonReq message: 590 1) If the PCE does not support the PCMonReq message, the PCE MUST 591 send a PCErr message with Error-type=14 and Error-value=1. 593 2) If the PCE supports the PCMonReq message but the request is 594 prohibited by policy, the PCE MUST send a PCErr message with Error- 595 Type=5 and Error-value=3. 597 3) If the PCE supports the PCMonReq and the monitoring request is not 598 prohibited by policy, the receiving PCE MUST first determine whether 599 it is the last PCE of the path computation chain. If the PCE is not 600 the last element of the path computation chain, the PCMonReq message 601 is relayed to the next hop PCE: such next-hop may either be specified 602 by means of a PCE-ID object present in the PCMonReq message or 603 dynamically determined by means of a procedure outside of the scope 604 of this document. Conversely, if the PCE is the last PCE of the path 605 computation chain, the PCE originates a PCMonRep message that 606 contains the requested objects according to the set of requested PCE 607 states metrics listed in the MONITORING object carried in the 608 corresponding PCMonReq message. 610 Reception of a PCMonRep message: upon receiving a PCMonRep message, 611 the PCE processes the request, adds the relevant objects to the 612 PCMonRep message and forwards the PCMonRep message to the upstream 613 requesting PCE or PCC. 615 Special case of Multi-destination monitoring: monitoring request 616 related to more than one destinations may involve a set of path 617 computation chains. In that case, a PCE sends each copy of the 618 PCMonReq message to each downstream PCE of each path computation 619 chain. 621 8. Manageability Considerations 623 To be addressed in a further revision of this document. 625 9. To be considered in a further revision of this document 627 It might be desirable to modify the format of the PCMonReq and 628 PCMonRep messages to support the bundling of multiple performance 629 metrics collection for a set of TE LSPs. 631 10. IANA Considerations 633 Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined 634 in this document: 636 Value Meaning 637 8 Path Computation Monitoring Request (PCMonReq) 638 9 Path Computation Monitoring Reply (PCMonRep) 640 The following new PCEP objects are defined in this document. 642 Object-Class Name 644 19 MONITORING 645 Object-Type 646 1 648 20 PCE-ID 649 Object-Type 650 1: IPv4 addresses 651 2: IPv6 addresses 653 21 PROC-TIME 654 Object-Type 655 1 657 22 CONGESTION 658 Object-Type 659 1 661 A new Error type for the PCErr message (see [I-D.ietf-pce-pcep]) is 662 defined in this document (Error-Type and Error-value to be assigned 663 by IANA). 665 Error-type Meaning 666 14 Performance Monitoring not supported 667 Error-value 668 1: Monitoring message not supported by one 669 of PCEs along the domain path 670 2: MONITORING object missing in a PCMonReq 671 message 673 A new Error-value for the PCErr message Error-types=4 (see 674 [I-D.ietf-pce-pcep]) is defined in this document (Error-Type and 675 Error-value to be assigned by IANA). 677 Error-type Meaning 678 5 Performance Monitoring Policy violation 679 3: Monitoring message supported but rejected 680 due to policy violation 682 11. Security Considerations 684 To be addressed in a further revision of this document. 686 12. Acknowledgements 688 The authors would like to thank Eiji Oki, Mach Chen and Dimitri 689 Papadimitriou for their useful comments. 691 13. References 693 13.1. Normative References 695 [I-D.ietf-pce-pcep] 696 Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, 697 Y., Kumaki, K., Vasseur, J., and J. Roux, "Path 698 Computation Element (PCE) communication Protocol (PCEP)", 699 draft-ietf-pce-pcep-09 (work in progress), November 2007. 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, March 1997. 704 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 705 Element (PCE)-Based Architecture", RFC 4655, August 2006. 707 13.2. Informative References 709 [I-D.ietf-pce-brpc] 710 Vasseur, J., "A Backward Recursive PCE-based Computation 711 (BRPC) procedure to compute shortest inter-domain Traffic 712 Engineering Label Switched Paths", draft-ietf-pce-brpc-06 713 (work in progress), September 2007. 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., "Encoding of Objective Functions in Path 723 Computation Element communication Protocol (PCEP)", 724 draft-ietf-pce-of-01 (work in progress), November 2007. 726 [I-D.ietf-pce-pcep-xro] 727 Oki, E. and A. Farrel, "Extensions to the Path Computation 728 Element Communication Protocol (PCEP) for Route 729 Exclusions", draft-ietf-pce-pcep-xro-02 (work in 730 progress), September 2007. 732 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 733 "OSPF Protocol Extensions for Path Computation Element 734 (PCE) Discovery", RFC 5088, January 2008. 736 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 737 "IS-IS Protocol Extensions for Path Computation Element 738 (PCE) Discovery", RFC 5089, January 2008. 740 Authors' Addresses 742 JP Vasseur (editor) 743 Cisco Systems, Inc 744 1414 Massachusetts Avenue 745 Boxborough, MA 01719 746 USA 748 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. 806 Acknowledgment 808 Funding for the RFC Editor function is provided by the IETF 809 Administrative Support Activity (IASA).