idnits 2.17.1 draft-ietf-pce-monitoring-03.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 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 858. 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 (November 2, 2008) is 5648 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 768, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-18 ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-06) exists of draft-ietf-pce-of-05 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: May 6, 2009 France Telecom 5 Y. Ikejiri 6 NTT Communications Corporation 7 November 2, 2008 9 A set of monitoring tools for Path Computation Element based 10 Architecture 11 draft-ietf-pce-monitoring-03.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 May 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 7.1. Control of Function and Policy . . . . . . . . . . . . . . 15 78 7.2. Information and Data Models . . . . . . . . . . . . . . . 15 79 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 80 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 81 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 15 82 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 15 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 90 Intellectual Property and Copyright Statements . . . . . . . . . . 20 92 1. Introduction 94 The Path Computation Element (PCE) based architecture has been 95 specified in [RFC4655] for the computation of Traffic Engineering 96 (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching 97 (MPLS) and Generalized MPLS (GMPLS) networks in the context of single 98 or multiple domains where a domain refers to a collection of network 99 elements within a common sphere of address management or path 100 computational responsibility such as IGP areas and Autonomous 101 Systems. 103 As defined in [RFC4655], there are circumstances where more than one 104 PCE is involved in the computation of a TE LSP. A typical example is 105 when the PCC requires the computation of a TE LSP where the head-end 106 and the tail-end of the TE LSP do not reside in adjacent domains and 107 there is no single PCE with the visibility of both the head-end and 108 tail-end domain. We call the set of PCEs involved in the computation 109 of a TE LSP a "path computation chain". As further discussed in 110 Section 3.1, the PCE chain may either be static (pre-configured) or 111 dynamically determined during the path computation process. 113 In PCE-based environments, it is critical to monitor the state of the 114 path computation chain for troubeshooting and performance monitoring 115 purposes: liveness of each element (PCE) involved in the PCE chain, 116 detection of potential resource contention states and statistics in 117 term of path computation times are examples of such metrics of 118 interest. This document specifies procedures and extensions to the 119 Path Computation Element Protocol (PCEP) ([I-D.ietf-pce-pcep]) in 120 order to monitor the path computation chain and gather various 121 performance metrics. 123 As discussed in [RFC4655], a TE LSP may be computed by one PCE 124 (referred to as single PCE path computation) or several PCEs 125 (referred to as multiple PCE path computation). In the former case, 126 the PCC may be able to use IGP extensions to check the liveness of 127 the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive 128 messages. In contrast, when multiple PCEs are involved in the path 129 computation chain an example of which is the BRPC procedure defined 130 in [I-D.ietf-pce-brpc], the PCC's visibility may be limited to the 131 first PCE involved in the path computation chain. Thus, it is 132 critical to define mechanisms in order to monitor the state of the 133 path computation chain. 135 This document specifies PCEP extensions in order to gather various 136 state metrics along the path computation chain. In this document we 137 call a "state metric" a metric that characterizes a PCE state. For 138 example, such metric can have a form of a bolean (PCE is alive or 139 not, PCE is congested or not) or a performance metric (path 140 computation time at each PCE). 142 PCE state metrics can be gathered in two different contexts: in band 143 or out of band. By "In band" we refer to the situation whereby a PCC 144 requests to gather metrics in the context of a path computation 145 request. For example, a PCC may send a path computation request to a 146 PCE and may want to know the processing time of that request in 147 addition to the computed path. Conversely, if the request is "out of 148 band", PCE state metric collection is performed as a standalone 149 request (e.g. check the liveness of a specific PCE chain, collect the 150 average processing time computed over the last 5mn period on one or 151 more PCEs"). 153 In this document we define two monitoring request types: general and 154 specific. A general monitoring request relates to the collection of 155 a PCE state metrics that is not coupled to a particular path 156 computation request (e.g. average CPU load on a PCE). Conversely, a 157 specific monitoring request relates to a particular path computation 158 request (processing time to complete the path computation for a TE 159 LSP). 161 2. Terminology 163 PCC (Path Computation Client): any client application requesting a 164 path computation to be performed by a Path Computation Element. 166 PCE (Path Computation Element): an entity (component, application or 167 network node) that is capable of computing a network path or route 168 based on a network graph and applying computational constraints. 170 TE LSP: Traffic Engineering Label Switched Path. 172 3. Path Computation Monitoring messages 174 As defined in [I-D.ietf-pce-pcep], a PCEP message consists of a 175 common header followed by a variable length body made of a set of 176 objects that can either be mandatory or optional. As a reminder, an 177 object is said to be mandatory in a PCEP message when the object must 178 be included for the message to be considered as valid. The P flag 179 (defined in [I-D.ietf-pce-pcep]) is located in the common header of 180 each PCEP object and can be set by a PCEP peer to require a PCE to 181 take into account the related information during the path 182 computation. Because the P flag exclusively relates to a path 183 computation request, it MUST be cleared in the two PCEP messages 184 (PCEMonReq and PCMonRep message) defined in this document. 186 For each PCEP message type a set of rules is defined that specify the 187 set of objects that the message can carry. We use the Backus-Naur 188 Form (BNF) to specify such rules. Square brackets refer to optional 189 sub-sequences. An implementation MUST form the PCEP messages using 190 the object ordering specified in this document. 192 In this document we define two PCEP messages referred to as the Path 193 Computation Monitoring request (PCMonReq) and Path Computation 194 Monitoring Reply (PCMonRep) messages so as to handle "out of band" 195 monitoring request. The aim of the PCMonReq message sent by a PCC to 196 a PCE is to gather one or more PCE state metrics on a set of PCEs 197 involved in a path computation chain. The PCMonRep message sent by a 198 PCE to a PCC is used to provide such data. 200 3.1. Path Computation Monitoring Request message (PCMonReq) 202 The Message-Type field of the PCEP common header for the PCMonReq 203 message is set to 8 (To be confirmed by IANA). 205 There is one mandatory object that MUST be included within a PCMonReq 206 message: the Monitoring object (see section Section 4.1). If the 207 Monitoring object is missing, the receiving PCE MUST send a PCErr 208 message with Error-type=6 (Mandatory Object missing) and Error- 209 value=4 (MONITORING Object missing). Other objects are optional. 211 The format of a PCMonReq message is as follows: 212 ::= 213 214 [] 215 [] 216 [] 217 where: 219 ::= 220 [] 221 [] 223 ::=[] 225 ::= 226 227 [] 228 [] 229 [] 230 [] 231 [] 232 [] 233 [] 235 ::=[] 237 ::=[] 239 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, IRO and LOAD- 240 BALANCING objects are defined in [I-D.ietf-pce-pcep]. The XRO object 241 is defined in [I-D.ietf-pce-pcep-xro] and the OF object is defined in 242 [I-D.ietf-pce-of]. 244 The PCMonReq message is used to gather various PCE state metrics 245 along a path computation chain. The path computation chain may be 246 determined by the PCC (in the form of a series of a series of PCE-ID 247 objects defined in Section 4.2.) or may alternatively be determined 248 by the path computation procedure. For example, if the BRPC 249 procedure ([I-D.ietf-pce-brpc]) is used to compute an inter-domain TE 250 LSP, the PCE chain may be determined dynamically. In that case, the 251 PCC sends a PCMonReq message that contains the PCEP objects that 252 charaterize the TE LSP attributes along with the monitoring objects 253 (see Section 4.1) that list the set of metric(s) of interest. 255 Several PCE state metrics may be requested that are specified by a 256 set of objects defined in Section 4. Note that this set of objects 257 may be extended in the future. 259 For the sake of illustraion, consider the three following examples: 261 Example 1: PCC1 requests to check the path computation chain that 262 would be used should it request a path computation for a specific TE 263 LSP named T1. A PCMonReq message is sent that contains a MONITORING 264 object specifying a path computation check, along with the 265 appropriate set of objects (e.g. RP, END-POINTS, ...) that would be 266 included in a PCReq message for T1. 268 Example 2: PCC1 requests a path computation for a TE LSP and also 269 request to gather the processing time along the path computation 270 chain selected for the computation of T1. A PCReq message is sent 271 that also contains a MONITORING object that specifies the performance 272 metric of interest. The PCRep message also carries a PROC-TIME 273 object defined in section Section 4.1 that reports the computed 274 metrics. 276 Example 3: PCC2 requests to gather performance metrics along the 277 specific path computation chain . A PCMonreq 278 message is sent to PCE1 that contains a sequence of PCE-ID objects 279 that identify PCE1, PCE2, PCE3 and PCE7 respectively. 281 3.2. Path Monitoring Reply message (PCMonRep) 283 The PCMonRep message is used to provide PCE state metrics back to the 284 requester for "out of band" monitoring requests. The Message-Type 285 field of the PCEP common header for the PCMonRep message is set to 9 286 (To be confirmed by IANA). 288 There is one mandatory object that MUST be included within a PCMonRep 289 message: the Monitoring object (see Section 4.1). If the Monitoring 290 object is missing, the receiving PCE MUST send a PCErr message with 291 Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING 292 Object missing). 294 Other objects are optional. 296 The format of a PCReq message is as follows: 297 ::= 298 299 [] 300 [] 302 where: 304 ::=[] 306 ::=[] 307 [] 308 [] 310 4. Path Computation Monitoring Objects 312 The PCEP objects defined in the document are compliant with the PCEP 313 object format defined in [I-D.ietf-pce-pcep], with the P flag and the 314 I flag cleared since these flags are exclusively related to path 315 computation requests. 317 Several objects are defined in this section that can be carried 318 within the PCEP PCReq or PCRep messages defined in 319 [I-D.ietf-pce-pcep] in case of "in band" monitoring requests. In 320 case of "out of band" monitoring requests, the objects defined in 321 this section are carried within PCMonReq and PCMonRep messages. 322 Conversely, if the PCC requests the computation of the TE LSP in 323 addition to gathering PCE state metrics (i.e. "In band" requests), 324 these objects are carried within PCReq and PCRep messages. 326 4.1. MONITORING Object 328 The MONITORING object MUST be present within PCMonReq and PCMonRep 329 messages ("out of band" monitoring requests) and MAY be carried 330 within PCERep and PCReq messages ("in band" monitoring requests). 331 There SHOULD NOT be more than one instance of the MONITORING object: 332 if more than one instance of the MONITORING object is present, the 333 recipient MUST process the first instance and MUST ignore other 334 instances. 336 The MONITORING object is used to specify the set of requested PCE 337 state metrics. 339 The MONITORING Object-Class is to be assigned by IANA (recommended 340 value=19) 342 The MONITORING Object-Type is to be assigned by IANA (recommended 343 value=1) 345 The format of the MONITORING object body is as follows: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Reserved | Flags |I|C|P|G|L| 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Monitoring-id-number | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 // Optional TLV(s) // 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Flags: 24 bits 360 The following flags are currently defined: 362 L (Liveness) - 1 bit: when set, this indicates that the state metric 363 of interest is the PCE's liveness and thus the PCE MUST include a 364 PCE-ID object in the corresponding reply. The L bit MUST always be 365 ignored in a PCMonRep or PCRep message. 367 G (General) - 1 bit: when set, this indicates that the monitoring 368 request is a general monitoring request. When the requested 369 performance metric is specific, the G bit MUST be cleared. The G bit 370 MUST always be ignored in a PCMonRep or PCRep message. 372 P (Processing Time) - 1 bit: the P bit of the MONITORING object 373 carried in a PCMonReq or a PCReq message is set to indicate that the 374 processing times is a metric of interest, in which case a PROC-TIME 375 object MUST be inserted in the corresponding PCMonRep or PCRep 376 message. The P bit MUST always be ignored in a PCMonRep or PCRep 377 message. 379 C (Congestion) - 1 bit: The C bit of the MONITORING object carried in 380 a PCMonReq or a PCReq message is set to indicate that the congestion 381 status is a metric of interest, in which case a CONGESTION object 382 MUST be inserted in the corresponding PCMonRep or PCRep message. The 383 C bit MUST always be ignored in a PCMonRep or PCRep message. 385 I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message 386 and that message does not trigger any policy violation, but the PCE 387 cannot provide any of the set of requested performance metrics for 388 unspecified reasons, the PCE MUST set the I bit. The I bit has no 389 meaning in a request and SHOULD be ignored on receipt. 391 Monitoring-id-number (32 bits): The monitoring-id-number value 392 combined with the PCEP-ID of the PCC identifies the monitoring 393 request context. The monitoring-id-number MUST start at a non-zero 394 value and MUST be incremented each time a new monitoring request is 395 sent to a PCE. Each increment SHOULD have a value of 1 and may cause 396 a wrap back to one. If no reply to a monitoring request is received 397 from the PCE, and the PCC wishes to resend its path computation 398 monitoring request, the same monitoring-id-number MUST be used. 399 Conversely, a different monitoring-id-number MUST be used for 400 different requests sent to a PCE. The path computation monitoring 401 reply is unambiguously identified by the monitoring-id-number and the 402 PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint 403 the Monitoring-id-number of pending monitoring requests in case of 404 restart thus avoiding the re-use of a Monitoring-id-number of an in- 405 process monitoring request. 407 Unassigned bits are considered as reserved and MUST be set to zero on 408 transmission and ignored on reception. 410 No optional TLVs are currently defined. 412 4.2. PCEP-ID Object 414 The PCEP-ID Object is used to specify a PCE's IP address. 416 A set of PCEP-ID objects may be inserted within a PCReq or a PCMonReq 417 message to specify the PCE for which PCE state metrics are requested 418 and in a PCMonRep or a PCRep message to record the IP address of the 419 PCE reporting PCE state metrics or that was involved in the path 420 computation chain. 422 Two PCEP-ID objects (for IPv4 and IPv6) are defined. PCEP-ID Object- 423 Class is to be assigned by IANA (recommended value=20) PCEP-ID 424 Object-Type is to be assigned by IANA (recommended value=1 for IPv4 425 and 2 for IPv6) 427 The format of the PCEP-ID Object is as follows: 429 The format of the PCEP-ID object body for IPv4 and IPv6 are as 430 follows: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | IPv4 Address | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | 442 | IPv6 Address | 443 | | 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 The PCEP-ID object body has a fixed length of 4 octets for IPv4 and 447 16 octets for IPv6. 449 When a dynamic discovery mechanism is used for PCE discovery, a PCE 450 advertises its PCE address in the PCE-ADDRESS sub-TLV defined in 451 [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and 452 PCMonReq messages and a PCE MUST also use this address in PCRep and 453 PCMonRep messages. 455 4.3. PROC-TIME Object 457 If allowed by policy, the PCE includes a PROC-TIME object within a 458 PCMonRep or a PCRep message if the P bit of the MONITORING object 459 carried within the corresponding PCMonReq or PCReq message is set. 460 The PROC-TIME object is used to report various processing time 461 related metrics. 463 1) Case of general monitoring requests 465 A PCC may request processing time metrics for general monitoring 466 requests (e.g. the PCC may want to know the minimum, maximum and 467 average processing times on a particular PCE). In this case, general 468 requests can only be made by using PCMonReq/PCMonRep messages. The 469 Current-processing-time field (as explained below) is exclusively 470 used for specific monitoring requests and MUST be cleared for general 471 monitoring requests. The algorithm(s) used by a PCE to compute the 472 Min, Average, Max and Variance of the processing times are out of the 473 scope of this document (A PCE may decide to compute the minimum 474 processing time over a period of times, for the last N path 475 computation requests, ...). 477 2) Case of specific monitoring requests 479 In the case of a specific request, the algorithm(s) used by a PCE to 480 compute the Procesing-time metrics are out of the scope of this 481 document but a flag is specified that is used to indicate to the 482 requester whether the processing time value was estimated or 483 computed. The PCE may either (1) estimate the processing time 484 without performing an actual path computation or (2) effectively 485 perform the computation to report the processing time. In the former 486 case, the E bit of the PROC-TIME object MUST be set. The G bit MUST 487 be cleared and the Min-processing-time, Max-processing-time, Average- 488 processing-time and Variance-processing-time MUST be set to 489 0x00000000. 491 When the processing time is requested in addition to a path 492 computation (case where the MONITORING object is carried within a 493 PCReq message), the PROC-TIME object always reports the actual 494 processing time for that request and thus the E bit MUST be cleared. 496 The PROC-TIME Object-Class is to be assigned by IANA (recommended 497 value=21) 499 The PROC-TIME Object-Type is to be assigned by IANA (recommended 500 value=1) 502 The format of the PROC-TIME object body is as follows: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Reserved | Flags |E| 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Current-processing-time | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Min-processing-time | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Max-processing-time | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Average-processing time | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Variance-processing-time | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Flags: 18 bits - No Flags are currently defined: 521 E (Estimated) - 1 bit: when set, this indicates that the reported 522 metric value is based on estimated processing time as opposed to 523 actual computation(s). 525 Current-processing-time: This field indicates in milliseconds the 526 processing time for the path computation of interest characterized in 527 the corresponding PCMonReq message. 529 Min-processing-time: This field indicates in milliseconds the minimum 530 processing time. 532 Max-processing-time: This field indicates in milliseconds the maximum 533 processing time. 535 Average-processing-time: This field indicates in milliseconds the 536 average processing time. 538 Variance-processing-time: This field indicates in milliseconds the 539 variance of the processing times. 541 Unassigned bits are considered as reserved and MUST be set to zero on 542 transmission. 544 More granularity may be introduced in further revision of this 545 document to get a monitoring metric for a general request of a 546 particular class (e.g. all PCReq of priority X). 548 4.4. CONGESTION Object 550 The CONGESTION object MUST be present within a PCMonRep or a PCRep 551 message if the C bit of the MONITORING object carried within the 552 corresponding PCMonReq or PCReq message is set. The CONGESTION 553 object is used to report a PCE processing congestion state. The 554 CONGESTION Object-Class is to be assigned by IANA (recommended 555 value=22) The CONGESTION Object-Type is to be assigned by IANA 556 (recommended value=1) 558 The format of the CONGESTION object body is as follows: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |C| Reserved | Congestion Duration | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 C (Congestion) - 1 bit: when set, this indicates that PCE is 566 congested, in which case the congestion duration may be non nul. 567 When cleared this indicates that the PCE is not congested and the 568 "Congestion Duration" field MUST be set to 0x0000. 570 Congestion duration - 16 bits: This field indicates in seconds the 571 estimated congestion duration. 573 5. Policy 575 The receipt of a PCMonReq message may trigger a policy violation on 576 some PCE in which case the PCE MUST send a PCErr message with Error- 577 Type=5 and Error-value=3 (To be Confirmed by IANA). 579 6. Elements of Procedure 581 I bit processing: as indicated in section Section 4.1, if a PCE 582 supports a received PCMonReq message and that message does not 583 trigger any policy violation, but the PCE cannot provide any of the 584 set of requested performance metrics for unspecified reasons, the PCE 585 MUST set the I bit. Once set, the I bit MUST NOT be changed by a 586 receiving PCE. 588 Reception of a PCMonReq message: upon receiving a PCMonReq message: 590 1) As specified in [I-D.ietf-pce-pcep], if the PCE does not support 591 the PCMonReq message, the PCE peer must send a PCErr message with 592 Error-value=2 (capability not supported). 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 PCEP-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 Upon receiving 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 7. Manageability Considerations 624 7.1. Control of Function and Policy 626 It MUST be possible to configure the activation/deactivation of PCEP 627 monitoring on a PCEP speaker. In addition to the parameters already 628 listed in section 8.1 of [I-D.ietf-pce-pcep], a PCEP implementation 629 SHOULD allow configuring on a PCE whether specific, generic, in-band 630 and out-of-band monitoring requests are allowed or not. Also a PCEP 631 implementation SHOULD allow configuring on a PCE a list of authorized 632 state metrics (aliveness, congestion, processing time, etc). This 633 may apply to any session the PCEP speaker participates in, to a 634 specific session with a given PCEP peer or to a specific group of 635 sessions with a specific group of PCEP peers, for instance the PCEP 636 peers of a neighbor AS. 638 7.2. Information and Data Models 640 A new MIB Module MAY be defined that provides local PCE state 641 metrics, as well as state metrics of other PCEs gathered using 642 mechanisms defined in this document. 644 7.3. Liveness Detection and Monitoring 646 This document provides mechanisms to monitor the liveliness and 647 performances of a given PCE chain. 649 7.4. Verify Correct Operations 651 Mechanisms defined in this document do not imply any new operation 652 verification requirements in addition to those already listed in 653 [I-D.ietf-pce-pcep]. 655 7.5. Requirements On Other Protocols 657 Mechanisms defined in this document do not imply any requirements on 658 other protocols in addition to those already listed in 659 [I-D.ietf-pce-pcep]. 661 7.6. Impact On Network Operations 663 The frequency of PCMonReq messages may impact the operations of PCEs. 664 An implementation SHOULD allow a limit to be placed on the rate of 665 PCMonReq messages sent by a PCEP speaker and processed from a peer. 666 It SHOULD also allow sending a notification when a rate threshold is 667 reached. An implementation SHOULD allow handling PCReq messages with 668 a higher priority than PCMonReq messages. 670 8. IANA Considerations 672 Each PCEP message has a message type value. 674 Two new PCEP (specified in [I-D.ietf-pce-pcep]) messages are defined 675 in this document: 677 Value Meaning 678 8 Path Computation Monitoring Request (PCMonReq) 679 9 Path Computation Monitoring Reply (PCMonRep) 681 Each PCEP object has an Object-Class and an Object-Type. The 682 following new PCEP objects are defined in this document. 684 Object-Class Name 686 19 MONITORING 687 Object-Type 688 1 690 20 PCEP-ID 691 Object-Type 692 1: IPv4 addresses 693 2: IPv6 addresses 695 21 PROC-TIME 696 Object-Type 697 1 699 22 CONGESTION 700 Object-Type 701 1 703 A registry has been created for the Error-type and Error-value of the 704 PCEP Error Object. 706 A new Error-value for the PCErr message Error-types=5 (Policy 707 Violation) (see [I-D.ietf-pce-pcep]) is defined in this document 708 (Error-Type and Error-value to be assigned by IANA). 710 Error-type Meaning 711 5 Policy violation 712 Error-value=3 [This document] 713 Monitoring message supported but rejected 714 due to policy violation 716 A new Error-value for the PCErr message Error-types=6 (Mandatory 717 Object missing) (see [I-D.ietf-pce-pcep]) is defined in this document 718 (Error-Type and Error-value to be assigned by IANA). 720 Error-type Meaning 721 6 Mandatory Object missing 722 Error-value=4 [This document] 723 MONITORING Object missing 725 9. Security Considerations 727 Mechanisms discussed in [I-D.ietf-pce-pcep] to secure a PCEP session 728 (authenticity, integrity, privacy, DoS protection, etc) can be used 729 to secure the PCMonReq, PCMonRep messages and PCE state metric 730 objects defined in this document as well. A PCE may face a denial of 731 service attack with PCMonReq messages. An implementation SHOULD 732 allow limiting the rate at which PCMonReq messages received from a 733 specific peer are processed (input shapping), or from another domain 734 (see also section 7.6). 736 10. Acknowledgements 738 The authors would like to thank Eiji Oki, Mach Chen and Dimitri 739 Papadimitriou for their useful comments. Special thank to Adrian 740 Farrel for his detailed review. 742 11. References 744 11.1. Normative References 746 [I-D.ietf-pce-pcep] 747 Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, 748 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, 749 "Path Computation Element (PCE) Communication Protocol 750 (PCEP)", draft-ietf-pce-pcep-18 (work in progress), 751 November 2008. 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, March 1997. 756 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 757 Element (PCE)-Based Architecture", RFC 4655, August 2006. 759 11.2. Informative References 761 [I-D.ietf-pce-brpc] 762 Vasseur, J., Zhang, R., Bitar, N., and J. Roux, "A 763 Backward Recursive PCE-based Computation (BRPC) Procedure 764 To Compute Shortest Constrained Inter-domain Traffic 765 Engineering Label Switched Paths", draft-ietf-pce-brpc-09 766 (work in progress), April 2008. 768 [I-D.ietf-pce-disco-proto-isis] 769 Roux, J., "IS-IS Protocol Extensions for Path Computation 770 Element (PCE) Discovery", 771 draft-ietf-pce-disco-proto-isis-08 (work in progress), 772 September 2007. 774 [I-D.ietf-pce-of] 775 Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective 776 Functions in the Path Computation Element Communication 777 Protocol (PCEP)", draft-ietf-pce-of-05 (work in progress), 778 September 2008. 780 [I-D.ietf-pce-pcep-xro] 781 Takeda, T., Oki, E., and A. Farrel, "Extensions to the 782 Path Computation Element Communication Protocol (PCEP) for 783 Route Exclusions", draft-ietf-pce-pcep-xro-06 (work in 784 progress), July 2008. 786 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 787 "OSPF Protocol Extensions for Path Computation Element 788 (PCE) Discovery", RFC 5088, January 2008. 790 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 791 "IS-IS Protocol Extensions for Path Computation Element 792 (PCE) Discovery", RFC 5089, January 2008. 794 Authors' Addresses 796 JP Vasseur (editor) 797 Cisco Systems, Inc 798 1414 Massachusetts Avenue 799 Boxborough, MA 01719 800 USA 802 Email: jpv@cisco.com 804 JL Le Roux 805 France Telecom 806 2, Avenue Pierre-Marzin 807 Lannion, 22307 808 FRANCE 810 Email: jeanlouis.leroux@orange-ftgroup.com 812 Yuichi Ikejiri 813 NTT Communications Corporation 814 1-1-6, Uchisaiwai-cho, Chiyoda-ku 815 Tokyo, 100-8019 816 Japan 818 Email: : y.ikejiri@ntt.com 820 Full Copyright Statement 822 Copyright (C) The IETF Trust (2008). 824 This document is subject to the rights, licenses and restrictions 825 contained in BCP 78, and except as set forth therein, the authors 826 retain all their rights. 828 This document and the information contained herein are provided on an 829 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 830 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 831 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 832 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 833 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 834 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 836 Intellectual Property 838 The IETF takes no position regarding the validity or scope of any 839 Intellectual Property Rights or other rights that might be claimed to 840 pertain to the implementation or use of the technology described in 841 this document or the extent to which any license under such rights 842 might or might not be available; nor does it represent that it has 843 made any independent effort to identify any such rights. Information 844 on the procedures with respect to rights in RFC documents can be 845 found in BCP 78 and BCP 79. 847 Copies of IPR disclosures made to the IETF Secretariat and any 848 assurances of licenses to be made available, or the result of an 849 attempt made to obtain a general license or permission for the use of 850 such proprietary rights by implementers or users of this 851 specification can be obtained from the IETF on-line IPR repository at 852 http://www.ietf.org/ipr. 854 The IETF invites any interested party to bring to its attention any 855 copyrights, patents or patent applications, or other proprietary 856 rights that may cover technology that may be required to implement 857 this standard. Please address the information to the IETF at 858 ietf-ipr@ietf.org.