idnits 2.17.1 draft-ietf-pce-monitoring-00.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 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 803. 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 (September 18, 2007) is 6057 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) == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-08 ** 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 (-08) exists of draft-ietf-pce-disco-proto-isis-07 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-ospf-07 Summary: 2 errors (**), 0 flaws (~~), 6 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 21, 2008 France Telecom 5 Y. Ikejiri 6 NTT Communications Corporation 7 September 18, 2007 9 A set of monitoring tools for Path Computation Element based 10 Architecture 11 draft-ietf-pce-monitoring-00.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 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 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 [I-D.ietf-pce-disco-proto-ospf] and 136 [I-D.ietf-pce-disco-proto-isis]) or PCEP using Keepalive messages. 137 In contrast, when multiple PCEs are involved in the path computation 138 chain an example of which is the BRPC procedure defined in 139 [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the first 140 PCE involved in the path computation chain. Thus, it is critical to 141 define mechanisms in order to monitor the state of the path 142 computation chain. 144 The aim of this document is to specify PCEP extensions in order to 145 gather various state metrics along the path computation chain. In 146 this document we call a "state metric" a metric that characterizes a 147 PCE state. For example, such metric can have a form of a bolean (PCE 148 is alive or not, PCE is congested or not) or a performance metric 149 (path computation time at each PCE). 151 PCE state metrics collection can be gathered in two different 152 contexts: in band or out of band. By "In band" we refer to the 153 situation whereby a PCC requests to gather metrics in the context of 154 a path computation request. For example, a PCC may send a path 155 computation request to a PCE and may want to know the processing time 156 of that request in addition to the computed path. Conversely, if the 157 request is "out of band", PCE state metric collection is performed as 158 a standalone request (e.g. check the liveness of a specific PCE 159 chain, collect the average processing time computed over the last 5mn 160 period on one or more PCE(s)"). 162 In this document we define two monitoring request types: general and 163 specific. A general monitoring request relates to the collection of 164 a PCE state metric(s) that is not coupled to a particular path 165 computation request (e.g. average CPU load on a PCE). Conversely, a 166 specific monitoring request relates to a particular path computation 167 request (processing time to complete the path computation for a TE 168 LSP). 170 3. Path Computation Monitoring messages 172 As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a 173 common header followed by a variable length body made of a set of 174 objects that can either be mandatory or optional. As a reminder, an 175 object is said to be mandatory in a PCEP message when the object must 176 be included for the message to be considered as valid. The P flag 177 (defined in [I-D.ietf-pce-pcep]) is located in the common header of 178 each PCEP object and can be set by a PCEP peer to enforce a PCE to 179 take into account the related information during the path 180 computation. Because the P flag exclusively relates to a path 181 computation request, it MUST be cleared in the two PCEP messages 182 (PCEMonReq and PCMonRep message) defined in this document. 184 For each PCEP message type a set of rules is defined that specify the 185 set of objects that the message can carry. We use the Backus-Naur 186 Form (BNF) to specify such rules. Square brackets refer to optional 187 sub-sequences. An implementation MUST form the PCEP messages using 188 the object ordering specified in this document. 190 In this document we define two PCEP messages referred to as the Path 191 Computation Monitoring request (PCMonReq) and Path Computation 192 Monitoring Reply (PCMonRep) messages so as to handle "out of band" 193 monitoring request. The aim of the PCMonReq message sent by a PCC to 194 a PCE is to gather one or more PCE state metrics on a set of PCEs 195 involved in a path computation chain. The PCMonRep message sent by a 196 PCE to a PCC is used to provide such data. 198 3.1. Path Computation Monitoring Request message (PCMonReq) 200 The Message-Type field of the PCEP common header for the PCMonReq 201 message is set to 8 (To be confirmed by IANA). 203 There is one mandatory object that MUST be included within a PCMonReq 204 message: the Monitoring object (see section Section 4.1). If the 205 Monitoring object is missing, the receiving PCE MUST send an error 206 message to the sender. Other objects are optional. 208 The format of a PCMonReq message is as follows: 209 ::= 210 211 [] 212 [] 213 [] 214 where: 216 ::= 217 [] 218 [] 220 ::=[] 222 ::= 223 224 [] 225 [] 226 [] 227 [] 228 [] 229 [] 230 [] 232 ::=[] 234 ::=[] 236 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- 237 BALANCING objects are defined in [I-D.ietf-pce-pcep]. The XRO object 238 is defined in [I-D.oki-pce-pcep-xro] and the OF object is defined in 239 [I-D.leroux-pce-of]. 241 The PCMonReq message is used to gather various PCE state metrics 242 along a path computation chain. The path computation chain may be 243 determined by the PCC (in the form of a series of a series of PCE-ID 244 objects defined in Section 4.2.) or may alternatively be determined 245 by the path computation procedure. For example, if the BRPC 246 procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE 247 LSP, the PCE chain may be determined dynamically. In that case, the 248 PCC sends a PCMonReq message that contains the PCEP objects that 249 charaterize the TE LSP attributes along with the monitoring objects 250 (see Section 4.1) that list the set of metric(s) of interest. 252 Several PCE state metrics may be requested that are specified by a 253 set of objects defined in Section 4. Note that this set of objects 254 is by all means not limitative and may be extended in further 255 revision of this document. 257 For the sake of illustraion, consider the three following examples: 259 Example 1: PCC1 requests to check the path computation chain should a 260 path computation be requested for a specific TE LSP named T1. A 261 PCMonReq message is sent that contains a MONITORING object specifying 262 a path computation check, along with the appropriate set of objects 263 (e.g. RP, END-POINTS, ...) that would be included in a PCReq message 264 for T1. 266 Example 2: PCC1 requests a path computation for a TE LSP and also 267 request to gather the processing time along the path computation 268 chain selected for the computation of T1. A PCReq message is sent 269 that also contains a MONITORING object that specifies the performance 270 metric of interest. The PCRep message also comprises a PROC-TIME 271 object defined in section Section 4.1 that reports the computed 272 metrics. 274 Example 3: PCC2 requests to gather performance metrics along the 275 specific path computation chain . A PCMonreq 276 message is sent to PCE1 that contains a set of PCE-ID objects that 277 identify PCE1, PCE2, PCE3 and PCE7 respectively. 279 3.2. Path Monitoring Reply message (PCMonRep) 281 The PCMonRep message is used to provide PCE state metrics back to the 282 requester for "out of band" monitoring requests. The Message-Type 283 field of the PCEP common header for the PCMonRep message is set to 9 284 (To be confirmed by IANA). 286 There is one mandatory object that MUST be included within a PCMonRep 287 message: the Monitoring object (see Section 4.1). If the Monitoring 288 object is missing, the receiving PCE MUST send an error message to 289 the requesting PCC. Other objects are optional. 291 The format of a PCReq message is as follows: 292 ::= 293 294 [] 295 [] 297 where: 299 ::=[] 301 ::=[] 302 [] 303 [] 304 [] 306 4. Path Computation Monitoring Objects 308 The PCEP objects defined in the document are compliant with the PCEP 309 object format defined in [I-D.ietf-pce-pcep], with the P flag and the 310 I flag cleared since these flags are exclusively related to path 311 computation request. 313 Several objects are defined in this section that can be carried 314 within the PCEP PCReq or PCRep messages defined in 315 [I-D.ietf-pce-pcep] in case of "in band" monitoring requests. In 316 case of "out of band" monitoring requests, the objects defined in 317 this section are carried within PCMonReq and PCMonRep messages. 318 Conversely, if the PCC requests the computation of the TE LSP in 319 addition to gathering PCE state metrics (i.e. "In band" requests), 320 these objects are carried within PCReq and PCRep messages. 322 4.1. MONITORING Object 324 The MONITORING object MUST be present within PCMonReq and PCMonRep 325 messages ("out of band" monitoring requests) and MAY be carried 326 within PCERep and PCReq messages ("in band" monitoring requests). 327 There MUST be exactly once instance of the MONITORING object: if more 328 than one instance of the MONITORING object is present, the recipient 329 MUST only process the first instance and ignore other instances. The 330 MONITORING object is used to specify the set of requested PCE state 331 metrics. 333 The MONITORING Object-Class is to be assigned by IANA (recommended 334 value=19) 336 The MONITORING Object-Type is to be assigned by IANA (recommended 337 value=1) 338 The format of the MONITORING object body is as follows: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Reserved | Flags |I|C|P|G|L| 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | monitoring-id-number | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 // Optional TLV(s) // 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Flags: 18 bits 353 The following flags are currently defined: 355 L (Liveness) - 1 bit: when set, this indicates that the state metric 356 of interest is the PCE's liveness and thus the PCE MUST include a 357 PCE-ID object in the corresponding reply. 359 G (General) - 1 bit: when set, this indicates that the monitoring 360 request is a general monitoring request. When the requested 361 performance metric is specific, the G bit MUST be cleared. 363 P (Processing Time) - 1 bit: the P bit of the MONITORING object 364 carried in a PCMonReq or a PCReq message is set to indicate that the 365 processing times is a metric of interest, in which case a PROC-TIME 366 object MUST be inserted in the corresponding PCMonRep or PCRep 367 message. The P bit MUST always be set in a PCMonRep message if also 368 set in the corresponding PCMonReq message. 370 C (Congestion) - 1 bit: The C bit of the MONITORING object carried in 371 a PCMonReq or a PCReq message is set to indicate that the congestion 372 status is a metric of interest, in which case a CONGESTION object 373 MUST be inserted in the corresponding PCMonRep or PCRep message. The 374 C bit MUST always be set in a PCMonRep message if also set in the 375 corresponding PCMonReq message. 377 I (Incomplete) - 1 bit: the I bit MUST be set by a PCE that supports 378 the PCMonReq message, which does not trigger any policy violation but 379 that cannot provide the set of requested performance metrics for 380 unspecified reasons. 382 Monitoring-id-number (32 bits). The monitoring-id-number value 383 combined with the source IP address of the PCC and the PCE address 384 uniquely identify the monitoring request context. The monitoring-id- 385 number MUST be incremented each time a new monitoring is sent to a 386 PCE. The value 0x0000000 is considered as invalid. If no reply to a 387 monitoring request is received from the PCE, and the PCC wishes to 388 resend its path computation monitoring request, the same monitoring- 389 id-number MUST be used. Conversely, different monitoring-id-number 390 MUST be used for different requests sent to a PCE. The same 391 monitoring-id-number may be used for path computation monitoring 392 requests sent to different PCEs. The path computation monitoring 393 reply is unambiguously identified by the IP source address of the 394 replying PCE. 396 Unassigned bits are considered as reserved and MUST be set to zero on 397 transmission. 399 No optional TLVs are currently defined. 401 4.2. PCE-ID Object 403 The PCE-ID Object is used to specify a PCE's IP address. 405 A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq 406 message to specify the PCE for which PCE state metrics are requested 407 and in a PCMonRep or a PCRep message to record the IP address of the 408 PCE reporting PCE state metrics or that was involved in the path 409 computation chain. 411 Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- 412 Class is to be assigned by IANA (recommended value=20) PCE-ID Object- 413 Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 414 for IPv6) 416 The format of the PCE-ID Object is as follows: 418 The format of the PCE-ID object body for IPv4 and IPv6 are as 419 follows: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | IPv4 Address | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 | IPv6 Address | 432 | | 433 | | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 436 octets for IPv6. 438 A PCE MUST use the same IP address as the address used in the PCE- 439 ADDRESS sub-TLV defined in [I-D.ietf-pce-disco-proto-ospf] and 440 [I-D.ietf-pce-disco-proto-isis] should a dynamic discovery mechanism 441 be used for PCE discovery. 443 4.3. PROC-TIME Object 445 The PROC-TIME object MUST be present within a PCMonRep or a PCRep 446 message if the P bit of the MONITORING object carried within the 447 corresponding PCMonReq or PCReq message is set. The PROC-TIME object 448 is used to report various processing time related metrics. 450 1) Case of general monitoring requests 452 A PCC may request processing time metrics for general monitoring 453 requests (e.g. the PCC may want to know the minimum, maximum and 454 average processing times on a particular PCE). In this case, general 455 requests can only be made by using PCMonReq/PCMonRep messages. The 456 processing-time field (as explained below) is exclusively used for 457 specific monitoring requests and MUST be cleared for general 458 monitoring requests. The algorithm(s) used by a PCE to compute the 459 Min, Average, Max and Variance of the processing times are out of the 460 scope of this document (A PCE may decide to compute the minimum 461 processing time over a period of times, for the last N path 462 computation requests, ...). 464 2) Case of specific monitoring requests 465 In the case of a specific request, the algorithm(s) used by a PCE to 466 compute the Procesing-time metrics are out of the scope of this 467 document but a flag is specified that is used to indicate to the 468 requester whether the processing time value was estimated or 469 computed. The PCE may either (1) estimate the processing time 470 without performing an actual path computation or (2) effectively 471 perform the computation to report the processing time. In the former 472 case, the E bit of the PROC-TIME object MUST be set. The G bit MUST 473 be cleared and the Min-processing-time, Max-processing-time, Average- 474 processing-time and Variance-processing-time MUST be set to 475 0x00000000. 477 When the processing time is requested in addition to a path 478 computation (case where the MONITORING object is carried within a 479 PCReq message), the PROC-TIME object always report the actual 480 processing time for that request and thus the E bits MUST be cleared. 482 The PROC-TIME Object-Class is to be assigned by IANA (recommended 483 value=21) 485 The PROC-TIME Object-Type is to be assigned by IANA (recommended 486 value=1) 488 The format of the PROC-TIME object body is as follows: 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Reserved | Flags | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Processing-time |E| 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Min-processing-time | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Max-processing-time | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Average-processing time | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Variance-processing-time | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Flags: 18 bits - No Flags are currently defined: 507 E (Estimated) - 1 bit: when set, this indicates that the reported 508 metric value is based on estimated processing time as opposed to 509 actual computation(s). 511 Current-processing-time: This field indicates in milliseconds the 512 processing time for the path computation of interest characterized in 513 the corresponding PCMonReq message. 515 Min-processing-time: This field indicates in milliseconds the minimum 516 processing time. 518 Max-processing-time: This field indicates in milliseconds the maximum 519 processing time. 521 Average-processing-time: This field indicates in milliseconds the 522 average processing time. 524 Variance-processing-time: This field indicates in milliseconds the 525 variance of the processing times. 527 Unassigned bits are considered as reserved and MUST be set to zero on 528 transmission. 530 More granularity may be introduced in further revision of this 531 document to get a monitoring metric for a general request of a 532 particular class (e.g. all PCReq of priority X). 534 4.4. CONGESTION Object 536 The CONGESTIION object MUST be present within a PCMonRep or a PCRep 537 message if the C bit of the MONITORING object carried within the 538 corresponding PCMonReq or PCReq message is set. The CONGESTION 539 object is used to report a PCE processing congestion state. The 540 CONGESTION Object-Class is to be assigned by IANA (recommended 541 value=22) The CONGESTION Object-Type is to be assigned by IANA 542 (recommended value=1) 544 The format of the CONGESTION object body is as follows: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |C| Reserved | Congestion Duration | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 C (Congestion) - 1 bit: when set, this indicates that PCE is 552 congested, in which case the congestion duration may be non nul. 553 When cleared this indicates that the PCE is not congested. 554 Congestion duration - 16 bits: This field indicates in seconds the 555 estimated congestion duration. 557 4.5. TIMESTAMP Object 559 A TIMESTAMP object will be specified in a further revision of this 560 document that could be used to indicate when a PCMonReq message has 561 been received by a PCE and when the PCMonReq message has been relayed 562 to the next-hop PCE or the time at which a PCMonRep message has been 563 sent to the requester. 565 5. Multi-destination monitoring 567 In a further revision of this document, a new object will be 568 specified allowing a PCC or a user to gather PCE state metrics for a 569 set of destinations using a single PCMonReq message. For example, 570 using a single PCMonreq message originated by a PCC, PCE state 571 metrics for the set of path computation chains involved in the 572 computation of a set of TE LSPs will be gathered. Such set of 573 destinations could be specified in the form of a subnets. 575 6. Policy 577 The receipt of a PCMonReq message may trigger a policy violation on 578 some PCE in which case the PCE MUST send a PCErr message with Error- 579 Type=5 and Error-value=3 (To be Confirmed by IANA). 581 7. Elements of procedure 583 I bit processing: as indicated in section Section 4.1, the I bit MUST 584 be set by a PCE that supports the PCMonReq message, which does not 585 trigger any policy violation but that cannot provide the set of 586 required performance metrics for unspecified reasons. Once set, the 587 I bit MUST NOT be changed by a receiving PCE. 589 Reception of a PCMonReq message: upon receiving a PCMonReq message: 591 1) If the PCE does not support the PCMonReq message, the PCE MUST 592 send a PCErr message with Error-type=14 and Error-value=1. 594 2) If the PCE supports the PCMonReq message but the request is 595 prohibited by policy, the PCE MUST send a PCErr message with Error- 596 Type=5 and Error-value=3. 598 3) If the PCE supports the PCMonReq and the monitoring request is not 599 prohibited by policy, the receiving PCE MUST first determine whether 600 it is the last PCE of the path computation chain. If the PCE is not 601 the last element of the path computation chain, the PCMonReq message 602 is relayed to the next hop PCE: such next-hop may either be specified 603 by means of a PCE-ID object present in the PCMonReq message or 604 dynamically determined by means of a procedure outside of the scope 605 of this document. Conversely, if the PCE is the last PCE of the path 606 computation chain, the PCE originates a PCMonRep message that 607 contains the requested objects according to the set of requested PCE 608 states metrics listed in the MONITORING object carried in the 609 corresponding PCMonReq message. 611 Reception of a PCMonRep message: upon receiving a PCMonRep message, 612 the PCE processes the request, adds the relevant objects to the 613 PCMonRep message and forwards the PCMonRep message to the upstream 614 requesting PCE or PCC. 616 Special case of Multi-destination monitoring: monitoring request 617 related to more than one destinations may involve a set of path 618 computation chains. In that case, a PCE sends each copy of the 619 PCMonReq message to each downstream PCE of each path computation 620 chain. 622 8. Manageability Considerations 624 To be addressed in a further revision of this document. 626 9. To be considered in a further revision of this document 628 It might be desirable to modify the format of the PCMonReq and 629 PCMonRep messages to support the bundling of multiple performance 630 metrics collection for a set of TE LSPs. 632 10. IANA Considerations 634 Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined 635 in this document: 637 Value Meaning 638 8 Path Computation Monitoring Request (PCMonReq) 639 9 Path Computation Monitoring Reply (PCMonRep) 641 The following new PCEP objects are defined in this document. 643 Object-Class Name 645 19 MONITORING 646 Object-Type 647 1 649 20 PCE-ID 650 Object-Type 651 1: IPv4 addresses 652 2: IPv6 addresses 654 21 PROC-TIME 655 Object-Type 656 1 658 22 CONGESTION 659 Object-Type 660 1 662 A new Error type for the PCErr message (see [I-D.ietf-pce-pcep]) is 663 defined in this document (Error-Type and Error-value to be assigned 664 by IANA). 666 Error-type Meaning 667 14 Performance Monitoring not supported 668 Error-value 669 1: Monitoring message not supported by one 670 of PCEs along the domain path 671 2: MONITORING object missing in a PCMonReq 672 message 674 A new Error-value for the PCErr message Error-types=4 (see 675 [I-D.ietf-pce-pcep]) is defined in this document (Error-Type and 676 Error-value to be assigned by IANA). 678 Error-type Meaning 679 5 Performance Monitoring Policy violation 680 3: Monitoring message supported but rejected 681 due to policy violation 683 11. Security Considerations 685 To be addressed in a further revision of this document. 687 12. Acknowledgements 689 The authors would like to thank Eiji Oki, Mach Chen and Dimitri 690 Papadimitriou for their useful comments. 692 13. References 694 13.1. Normative References 696 [I-D.ietf-pce-pcep] 697 Roux, J. and J. Vasseur, "Path Computation Element (PCE) 698 communication Protocol (PCEP)", draft-ietf-pce-pcep-08 699 (work in progress), July 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-07 (work in progress), 719 September 2007. 721 [I-D.ietf-pce-disco-proto-ospf] 722 Roux, J., "OSPF protocol extensions for Path Computation 723 Element (PCE) Discovery", 724 draft-ietf-pce-disco-proto-ospf-07 (work in progress), 725 September 2007. 727 [I-D.leroux-pce-of] 728 Roux, J., "Encoding of Objective Functions in Path 729 Computation Element (PCE) communication and discovery 730 protocols", draft-leroux-pce-of-01 (work in progress), 731 July 2007. 733 [I-D.oki-pce-pcep-xro] 734 Oki, E. and A. Farrel, "Extensions to the Path Computation 735 Element Communication Protocol (PCEP) for Route 736 Exclusions", draft-oki-pce-pcep-xro-00 (work in progress), 737 January 2007. 739 Authors' Addresses 741 JP Vasseur (editor) 742 Cisco Systems, Inc 743 1414 Massachusetts Avenue 744 Boxborough, MA 01719 745 USA 747 Email: jpv@cisco.com 749 JL Le Roux 750 France Telecom 751 2, Avenue Pierre-Marzin 752 Lannion, 22307 753 FRANCE 755 Email: jeanlouis.leroux@orange-ftgroup.com 757 Yuichi Ikejiri 758 NTT Communications Corporation 759 1-1-6, Uchisaiwai-cho, Chiyoda-ku 760 Tokyo, 100-8019 761 Japan 763 Email: : y.ikejiri@ntt.com 765 Full Copyright Statement 767 Copyright (C) The IETF Trust (2007). 769 This document is subject to the rights, licenses and restrictions 770 contained in BCP 78, and except as set forth therein, the authors 771 retain all their rights. 773 This document and the information contained herein are provided on an 774 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 775 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 776 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 777 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 778 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 779 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 781 Intellectual Property 783 The IETF takes no position regarding the validity or scope of any 784 Intellectual Property Rights or other rights that might be claimed to 785 pertain to the implementation or use of the technology described in 786 this document or the extent to which any license under such rights 787 might or might not be available; nor does it represent that it has 788 made any independent effort to identify any such rights. Information 789 on the procedures with respect to rights in RFC documents can be 790 found in BCP 78 and BCP 79. 792 Copies of IPR disclosures made to the IETF Secretariat and any 793 assurances of licenses to be made available, or the result of an 794 attempt made to obtain a general license or permission for the use of 795 such proprietary rights by implementers or users of this 796 specification can be obtained from the IETF on-line IPR repository at 797 http://www.ietf.org/ipr. 799 The IETF invites any interested party to bring to its attention any 800 copyrights, patents or patent applications, or other proprietary 801 rights that may cover technology that may be required to implement 802 this standard. Please address the information to the IETF at 803 ietf-ipr@ietf.org. 805 Acknowledgment 807 Funding for the RFC Editor function is provided by the IETF 808 Administrative Support Activity (IASA).