idnits 2.17.1 draft-ietf-pce-monitoring-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (June 12, 2009) is 5429 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) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 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: December 14, 2009 France Telecom 5 Y. Ikejiri 6 NTT Communications Corporation 7 June 12, 2009 9 A set of monitoring tools for Path Computation Element based 10 Architecture 11 draft-ietf-pce-monitoring-05.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 14, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 A Path Computation Element (PCE) based architecture has been 50 specified for the computation of Traffic Engineering (TE) Label 51 Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and 52 Generalized MPLS (GMPLS) networks in the context of single or 53 multiple domains (where a domain refers to a collection of network 54 elements within a common sphere of address management or path 55 computational responsibility such as IGP areas and Autonomous 56 Systems). Path Computation Clients (PCCs) send computation requests 57 to PCEs, and these may forward the requests to and cooperate with 58 other PCEs forming a "path computation chain". 60 In PCE-based environments, it is thus critical to monitor the state 61 of the path computation chain for troubleshooting and performance 62 monitoring purposes: liveness of each element (PCE) involved in the 63 PCE chain, detection of potential resource contention states and 64 statistics in term of path computation times are examples of such 65 metrics of interest. This document specifies procedures and 66 extensions to the Path Computation Element Protocol (PCEP) in order 67 to gather such information. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Path Computation Monitoring messages . . . . . . . . . . . . . 6 75 3.1. Path Computation Monitoring Request message (PCMonReq) . . 6 76 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9 77 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11 78 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12 79 4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14 80 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15 81 4.4. CONGESTION Object . . . . . . . . . . . . . . . . . . . . 17 82 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18 84 7. Manageability Considerations . . . . . . . . . . . . . . . . . 20 85 7.1. Control of Function and Policy . . . . . . . . . . . . . . 20 86 7.2. Information and Data Models . . . . . . . . . . . . . . . 20 87 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 88 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 89 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 90 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 20 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21 93 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21 94 8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21 95 8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22 96 8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22 97 8.6. CONGESTION Object Flag field . . . . . . . . . . . . . . . 23 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 100 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 102 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 105 1. Introduction 107 The Path Computation Element (PCE) based architecture has been 108 specified in [RFC4655] for the computation of Traffic Engineering 109 (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching 110 (MPLS) and Generalized MPLS (GMPLS) networks in the context of single 111 or multiple domains where a domain refers to a collection of network 112 elements within a common sphere of address management or path 113 computational responsibility such Interior Gateway Protocol (IGP) 114 areas and Autonomous Systems. 116 Path Computation Clients (PCCs) send computation requests to PCEs 117 using PCReq messages, and these may forward the requests to and 118 cooperate with other PCEs forming a "path computation chain". In 119 case of succesful path computation the computed paths are then 120 provided to the requesting PCC using PCRep messages. The PCReq and 121 PCRep messages are defined in [RFC5440]. 123 In PCE-based environments, it is critical to monitor the state of the 124 path computation chain for troubleshooting and performance monitoring 125 purposes: liveness of each element (PCE) involved in the PCE chain, 126 detection of potential resource contention states and statistics in 127 term of path computation times are examples of such metrics of 128 interest. 130 As defined in [RFC4655], there are circumstances where more than one 131 PCE are involved in the computation of a TE LSP. A typical example 132 is when the PCC requires the computation of a TE LSP where the head- 133 end and the tail-end of the TE LSP do not reside in adjacent domains 134 and there is no single PCE with the visibility of both the head-end 135 and tail-end domain. We call the set of PCEs involved in the 136 computation of a TE LSP a "path computation chain". As further 137 discussed in Section 3.1, the PCE chain may either be static (pre- 138 configured) or dynamically determined during the path computation 139 process. 141 As discussed in [RFC4655], a TE LSP may be computed by one PCE 142 (referred to as single PCE path computation) or several PCEs 143 (referred to as multiple PCE path computation). In the former case, 144 the PCC may be able to use IGP extensions to check the liveness of 145 the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive 146 messages. In contrast, when multiple PCEs are involved in the path 147 computation chain an example of which is the Backward Recursive PCE- 148 based Computation (BRPC) procedure defined in [RFC5441], the PCC's 149 visibility may be limited to the first PCE involved in the path 150 computation chain. Thus, it is critical to define mechanisms in 151 order to monitor the state of the path computation chain. 153 This document specifies PCEP extensions in order to gather various 154 state metrics along the path computation chain. In this document we 155 call a "state metric" a metric that characterizes a PCE state. For 156 example, such metric can have a form of a boolean (PCE is alive or 157 not, PCE is congested or not) or a performance metric (path 158 computation time at each PCE). 160 PCE state metrics can be gathered in two different contexts: in band 161 or out of band. By "in band" we refer to the situation whereby a PCC 162 requests to gather metrics in the context of a path computation 163 request. For example, a PCC may send a path computation request to a 164 PCE and may want to know the processing time of that request in 165 addition to the computed path. Conversely, if the request is "out of 166 band", PCE state metric collection is performed as a standalone 167 request (e.g., check the liveness of a specific PCE chain, collect 168 the average processing time computed over the last 5mn period on one 169 or more PCEs"). 171 In this document we define two monitoring request types: general and 172 specific. A general monitoring request relates to the collection of 173 a PCE state metrics that is not coupled to a particular path 174 computation request (e.g., average CPU load on a PCE). Conversely, a 175 specific monitoring request relates to a particular path computation 176 request (processing time to complete the path computation for a TE 177 LSP). 179 This document specifies procedures and extensions to the Path 180 Computation Element Protocol (PCEP) ([RFC5440]), including new 181 objects and new PCEP messages, in order to monitor the path 182 computation chain and gather various performance metrics. 184 The message formats in this document are specified using Backus Naur 185 Format (BNF) encoding as specified in [RFC5511]. 187 1.1. Requirements Language 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 2. Terminology 195 PCC (Path Computation Client): any client application requesting a 196 path computation to be performed by a Path Computation Element. 198 PCE (Path Computation Element): an entity (component, application or 199 network node) that is capable of computing a network path or route 200 based on a network graph and applying computational constraints. 202 TE LSP: Traffic Engineering Label Switched Path. 204 3. Path Computation Monitoring messages 206 As defined in [RFC5440], a PCEP message consists of a common header 207 followed by a variable length body made of a set of objects that can 208 either be mandatory or optional. As a reminder, an object is said to 209 be mandatory in a PCEP message when the object must be included for 210 the message to be considered as valid. The P flag (defined in 211 [RFC5440]) is located in the common header of each PCEP object and 212 can be set by a PCEP peer to require a PCE to take into account the 213 related information during the path computation. Because the P flag 214 exclusively relates to a path computation request, it MUST be cleared 215 in the two PCEP messages (PCMonReq and PCMonRep message). 217 For each PCEP message type a set of rules is defined that specify the 218 set of objects that the message can carry. An implementation MUST 219 form the PCEP messages using the object ordering specified in this 220 document. 222 In this document we define two PCEP messages referred to as the Path 223 Computation Monitoring Request (PCMonReq) and Path Computation 224 Monitoring Reply (PCMonRep) messages so as to handle "out of band" 225 monitoring request. The aim of the PCMonReq message sent by a PCC to 226 a PCE is to gather one or more PCE state metrics on a set of PCEs 227 involved in a path computation chain. The PCMonRep message sent by a 228 PCE to a PCC is used to provide such data. 230 3.1. Path Computation Monitoring Request message (PCMonReq) 232 The Message-Type field of the PCEP common header for the PCMonReq 233 message is set to 8 (To be confirmed by IANA). 235 There is one mandatory object that MUST be included within a PCMonReq 236 message: the MONITORING object (see section Section 4.1). If the 237 MONITORING object is missing, the receiving PCE MUST send a PCErr 238 message with Error-type=6 (Mandatory Object missing) and Error- 239 value=4 (MONITORING Object missing). Other objects are optional. 241 Format of a PCMonReq message (out of band request): 242 ::= 243 244 [] 245 [] 246 [] 247 where: 249 ::= 250 [] 251 [] 253 ::=[] 255 ::= 256 257 [] 258 [] 259 [] 260 [] 261 [] 262 [] 263 [] 265 ::=[] 267 ::=[] 268 Format of a PCReq message with monitoring data requested (in band 269 request): 270 ::= 271 272 [] 273 [] 274 276 where: 277 ::=[] 279 ::=[] 281 ::= 282 283 [] 284 [] 285 [] 286 [[]] 287 [] 288 [] 289 where: 291 ::=[] 293 ::=[] 295 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 296 BALANCING objects are defined in [RFC5440]. The XRO object is 297 defined in [RFC5521] and the OF object is defined in [RFC5541]. 299 The PCMonReq message is used to gather various PCE state metrics 300 along a path computation chain. The path computation chain may be 301 determined by the PCC (in the form of a series of a series of PCE-ID 302 objects defined in Section 4.2.) or may alternatively be determined 303 by the path computation procedure. For example, if the BRPC 304 procedure ([RFC5441]) is used to compute an inter-domain TE LSP, the 305 PCE chain may be determined dynamically. In that case, the PCC sends 306 a PCMonReq message that contains the PCEP objects that characterize 307 the TE LSP attributes along with the MONITORING object (see 308 Section 4.1) that lists the set of metrics of interest. 310 Several PCE state metrics may be requested that are specified by a 311 set of objects defined in Section 4. Note that this set of objects 312 may be extended in the future. 314 As pointed out in [RFC5440] several situations can arise: 316 o Bundle of a set of independent and non-synchronized path 317 computation requests, 319 o Bundle of a set of independent and synchronized path computation 320 requests (SVEC object defined below required), 322 o Bundle of a set of dependent and synchronized path computation 323 requests (SVEC object defined below required). 325 In the case of a bundle of a set of request, the MONITORING object 326 SHOULD only be present in the first PCReq or PCMonReq message and the 327 monitoring request applies to all the requests of the bundle, even in 328 the case of dependent and/or synchronized requests sent using more 329 than one PCReq or PCMonReq message. 331 Examples of requests. For the sake of illustration, consider the 332 three following examples: 334 Example 1 (out of band request): PCC1 requests to check the path 335 computation chain that would be used should it request a path 336 computation for a specific TE LSP named T1. A PCMonReq message is 337 sent that contains a MONITORING object specifying a path computation 338 check, along with the appropriate set of objects (e.g., RP, END- 339 POINTS, ...) that would be included in a PCReq message for T1. 341 Example 2 (in band request): PCC1 requests a path computation for a 342 TE LSP and also request to gather the processing time along the path 343 computation chain selected for the computation of T1. A PCReq 344 message is sent that also contains a MONITORING object that specifies 345 the performance metrics of interest. 347 Example 3 (out of band request): PCC2 requests to gather performance 348 metrics along the specific path computation chain . A PCMonReq message is sent to PCE1 that contains a MONITORING 350 object and a sequence of PCE-ID objects that identify PCE1, PCE2, 351 PCE3 and PCE7 respectively. 353 In all of the examples above, a PCRep message (in-band request) or 354 PCMonReq message (out of band request) is sent in response to the 355 request that reports the computed metrics. 357 3.2. Path Monitoring Reply message (PCMonRep) 359 The PCMonRep message is used to provide PCE state metrics back to the 360 requester for "out of band" monitoring requests. The Message-Type 361 field of the PCEP common header for the PCMonRep message is set to 9 362 (To be confirmed by IANA). 364 There is one mandatory object that MUST be included within a PCMonRep 365 message: the MONITORING object (see Section 4.1). If the MONITORING 366 object is missing, the receiving PCE MUST send a PCErr message with 367 Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING 368 Object missing). 370 Other objects are optional. 372 Format of a PCMonRep (out of band request): 373 ::= 374 375 [] 376 [] 378 where: 380 ::=[] 382 ::= 383 [] 384 [] 386 Format of a PCRep message with monitoring data (in band): 387 ::= 388 390 where: 391 ::=[] 393 ::= 394 395 [] 396 [] 397 [] 398 [] 400 ::=[] 402 ::= 404 where: 406 ::=[] 407 [] 408 [] 409 [] 411 ::=[] 413 ::=[] 415 ::= 416 [] 417 [] 419 The RP and the NO-PATH objects are defined in [RFC5440]. 421 4. Path Computation Monitoring Objects 423 The PCEP objects defined in the document are compliant with the PCEP 424 object format defined in [RFC5440]. The P flag and the I flag of the 425 PCEP objects defined in this document SHOULD always be set to 0 on 426 transmission and MUST be ignored on receipt since these flags are 427 exclusively related to path computation requests. 429 Several objects are defined in this section that can be carried 430 within the PCEP PCReq or PCRep messages defined in [RFC5440] in case 431 of "in band" monitoring requests (the PCC requests the computation of 432 the TE LSP in addition to gathering PCE state metrics). In case of 433 "out of band" monitoring requests, the objects defined in this 434 section are carried within PCMonReq and PCMonRep messages. 436 All TLVs carried in objects defined in this document have the TLV 437 format defined in [RFC5440] 439 o Type: 2 bytes 441 o Length: 2 bytes 443 o Value: variable 445 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 446 specifying the TLV length, and a value field. The Length field 447 defines the length of the value portion in bytes. The TLV is padded 448 to 4-bytes alignment; padding is not included in the Length field (so 449 a 3-byte value would have a length of 3, but the total size of the 450 TLV would be 8 bytes). Unrecognized TLVs MUST be ignored. 452 4.1. MONITORING Object 454 The MONITORING object MUST be present within PCMonReq and PCMonRep 455 messages ("out of band" monitoring requests) and MAY be carried 456 within PCRep and PCReq messages ("in band" monitoring requests). 457 There SHOULD NOT be more than one instance of the MONITORING object 458 in a PCMonReq or PCMonRep message: if more than one instance of the 459 MONITORING object is present, the recipient MUST process the first 460 instance and MUST ignore other instances. 462 The MONITORING object is used to specify the set of requested PCE 463 state metrics. 465 The MONITORING Object-Class is to be assigned by IANA (recommended 466 value=19) 468 The MONITORING Object-Type is to be assigned by IANA (recommended 469 value=1) 470 The format of the MONITORING object body is as follows: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Reserved | Flags |I|C|P|G|L| 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Monitoring-id-number | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | | 479 // Optional TLV(s) // 480 | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Flags: 24 bits 485 The following flags are currently defined: 487 L (Liveness) - 1 bit: when set, this indicates that the state metric 488 of interest is the PCE's liveness and thus the PCE MUST include a 489 PCE-ID object in the corresponding reply. The L bit MUST always be 490 ignored in a PCMonRep or PCRep message. 492 G (General) - 1 bit: when set, this indicates that the monitoring 493 request is a general monitoring request. When the requested 494 performance metric is specific, the G bit MUST be cleared. The G bit 495 MUST always be ignored in a PCMonRep or PCRep message. 497 P (Processing Time) - 1 bit: the P bit of the MONITORING object 498 carried in a PCMonReq or a PCReq message is set to indicate that the 499 processing times is a metric of interest. If allowed by policy, a 500 PROC-TIME object MUST be inserted in the corresponding PCMonRep or 501 PCRep message. The P bit MUST always be ignored in a PCMonRep or 502 PCRep message. 504 C (Congestion) - 1 bit: The C bit of the MONITORING object carried in 505 a PCMonReq or a PCReq message is set to indicate that the congestion 506 status is a metric of interest, in which case a CONGESTION object 507 MUST be inserted in the corresponding PCMonRep or PCRep message. The 508 C bit MUST always be ignored in a PCMonRep or PCRep message. 510 I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message 511 and that message does not trigger any policy violation, but the PCE 512 cannot provide any of the set of requested performance metrics for 513 unspecified reasons, the PCE MUST set the I bit. The I bit has no 514 meaning in a request and SHOULD be ignored on receipt. 516 Monitoring-id-number (32 bits): The monitoring-id-number value 517 combined with the PCEP-ID of the PCC identifies the monitoring 518 request context. The monitoring-id-number MUST start at a non-zero 519 value and MUST be incremented each time a new monitoring request is 520 sent to a PCE. Each increment SHOULD have a value of 1 and may cause 521 a wrap back to zero. If no reply to a monitoring request is received 522 from the PCE, and the PCC wishes to resend its path computation 523 monitoring request, the same monitoring-id-number MUST be used. 524 Conversely, a different monitoring-id-number MUST be used for 525 different requests sent to a PCE. The path computation monitoring 526 reply is unambiguously identified by the monitoring-id-number and the 527 PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint 528 the Monitoring-id-number of pending monitoring requests in case of 529 restart thus avoiding the re-use of a Monitoring-id-number of an in- 530 process monitoring request. 532 Unassigned bits are considered as reserved and MUST be set to zero on 533 transmission and ignored on reception. 535 No optional TLVs are currently defined. 537 4.2. PCE-ID Object 539 The PCE-ID Object is used to specify a PCE's IP address. 541 A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq 542 message to specify the PCE for which PCE state metrics are requested 543 and in a PCMonRep or a PCRep message to record the IP address of the 544 PCE reporting PCE state metrics or that was involved in the path 545 computation chain. 547 Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- 548 Class is to be assigned by IANA (recommended value=20) PCE-ID Object- 549 Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 550 for IPv6) 552 The format of the PCE-ID Object is as follows: 554 The format of the PCE-ID object body for IPv4 and IPv6 are as 555 follows: 557 0 1 2 3 558 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | IPv4 Address | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | | 567 | IPv6 Address | 568 | | 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 572 octets for IPv6. 574 When a dynamic discovery mechanism is used for PCE discovery, a PCE 575 advertises its PCE address in the PCE-ADDRESS sub-TLV defined in 576 [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and 577 PCMonReq messages and a PCE MUST also use this address in PCRep and 578 PCMonRep messages. 580 4.3. PROC-TIME Object 582 If allowed by policy, the PCE includes a PROC-TIME object within a 583 PCMonRep or a PCRep message if the P bit of the MONITORING object 584 carried within the corresponding PCMonReq or PCReq message is set. 585 The PROC-TIME object is used to report various processing time 586 related metrics. 588 1) Case of general monitoring requests 590 A PCC may request processing time metrics for general monitoring 591 requests (e.g., the PCC may want to know the minimum, maximum and 592 average processing times on a particular PCE). In this case, general 593 requests can only be made by using PCMonReq/PCMonRep messages. The 594 Current-processing-time field (as explained below) is exclusively 595 used for specific monitoring requests and MUST be cleared for general 596 monitoring requests. The algorithms used by a PCE to compute the 597 minimum, maximum, average and variance of the processing times are 598 out of the scope of this document (A PCE may decide to compute the 599 minimum processing time over a period of times, for the last N path 600 computation requests, ...). 602 2) Case of specific monitoring requests 604 In the case of a specific request, the algorithms used by a PCE to 605 compute the Processing-time metrics are out of the scope of this 606 document but a flag is specified that is used to indicate to the 607 requester whether the processing time value was estimated or 608 computed. The PCE may either (1) estimate the processing time 609 without performing an actual path computation or (2) effectively 610 perform the computation to report the processing time. In the former 611 case, the E bit of the PROC-TIME object MUST be set. The G bit MUST 612 be cleared and the Min-processing-time, Max-processing-time, Average- 613 processing-time and Variance-processing-time MUST be set to 614 0x00000000. 616 When the processing time is requested in addition to a path 617 computation (case where the MONITORING object is carried within a 618 PCReq message), the PROC-TIME object always reports the actual 619 processing time for that request and thus the E bit MUST be cleared. 621 The PROC-TIME Object-Class is to be assigned by IANA (recommended 622 value=21) 624 The PROC-TIME Object-Type is to be assigned by IANA (recommended 625 value=1) 627 The format of the PROC-TIME object body is as follows: 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Reserved | Flags |E| 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Current-processing-time | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Min-processing-time | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Max-processing-time | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Average-processing time | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Variance-processing-time | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Flags: 16 bits - one flag is currently defined: 646 E (Estimated) - 1 bit: when set, this indicates that the reported 647 metric value is based on estimated processing time as opposed to 648 actual computations. 650 Unassigned bits are considered as reserved and MUST be set to zero on 651 transmission. 653 Current-processing-time: This field indicates in milliseconds the 654 processing time for the path computation of interest characterized in 655 the corresponding PCMonReq message. 657 Min-processing-time: This field indicates in milliseconds the minimum 658 processing time. 660 Max-processing-time: This field indicates in milliseconds the maximum 661 processing time. 663 Average-processing-time: This field indicates in milliseconds the 664 average processing time. 666 Variance-processing-time: This field indicates in milliseconds the 667 variance of the processing times. 669 4.4. CONGESTION Object 671 The CONGESTION object is used to report a PCE processing congestion 672 state. The CONGESTION object MUST be present within a PCMonRep or a 673 PCRep message if the C bit of the MONITORING object carried within 674 the corresponding PCMonReq or PCReq message is set and the PCE is 675 experiencing a congested state. The CONGESTION Object-Class is to be 676 assigned by IANA (recommended value=22) The CONGESTION Object-Type is 677 to be assigned by IANA (recommended value=1) 679 The format of the CONGESTION object body is as follows: 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Flags | Reserved | Congestion Duration | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Flags: 8 bits - No flag is currently defined. 688 Congestion duration - 16 bits: This field indicates in the amount of 689 time in seconds that the responding PCE expects that it may continue 690 to be congested from the time that the response message was 691 generated. The receiver MAY use this value to decide whether or not 692 so send further requests to the same PCE. 694 It is worth noting that a PCE along a PCE chain involved in the 695 monitoring request may decide to learn from the congestion 696 information received by one of downstream PCE in the chain. 698 5. Policy 700 The receipt of a PCMonReq message may trigger a policy violation on 701 some PCE in which case the PCE MUST send a PCErr message with Error- 702 Type=5 and Error-value=3 (To be Confirmed by IANA). 704 6. Elements of Procedure 706 I bit processing: as indicated in section Section 4.1, if a PCE 707 supports a received PCMonReq message and that message does not 708 trigger any policy violation, but the PCE cannot provide any of the 709 set of requested performance metrics for unspecified reasons, the PCE 710 MUST set the I bit. Once set, the I bit MUST NOT be changed by a 711 receiving PCE. 713 Upon receiving a PCMonReq message: 715 1) As specified in [RFC5440], if the PCE does not support the 716 PCMonReq message, the PCE peer MUST send a PCErr message with Error- 717 value=2 (capability not supported). According to the procedure 718 defined in section 6.9 of [RFC5440], if a PCC/PCE receives 719 unrecognized messages at a rate equal of greater than specified rate, 720 the PCC/PCE must send a PCEP CLOSE message with close value=5 721 "Reception of an unacceptable number of unrecognized PCEP messages". 722 In this case, the PCC/PCE must also close the TCP session and must 723 not send any further PCEP messages on the PCEP session. 725 2) If the PCE supports the PCMonReq message but the monitoring 726 request is prohibited by policy, the PCE must follow the procedure 727 specified in section 5. As pointed out in section 4.3, a PCE may 728 still partially satisfy a request, leaving out some of the required 729 data if not allowed by policy. 731 3) If the PCE supports the PCMonReq and the monitoring request is not 732 prohibited by policy, the receiving PCE MUST first determine whether 733 it is the last PCE of the path computation chain. If the PCE is not 734 the last element of the path computation chain, the PCMonReq message 735 is relayed to the next hop PCE: such next hop may either be specified 736 by means of a PCE-ID object present in the PCMonReq message or 737 dynamically determined by means of a procedure outside of the scope 738 of this document. Conversely, if the PCE is the last PCE of the path 739 computation chain, the PCE originates a PCMonRep message that 740 contains the requested objects according to the set of requested PCE 741 states metrics listed in the MONITORING object carried in the 742 corresponding PCMonReq message. 744 Upon receiving a PCReq message that carries a MONITORING and 745 potentially other monitoring objects (e.g., PCE-ID object): 747 1) As specified in [RFC5440], if the PCE does not support (in band) 748 monitoring, the PCE peer MUST send a PCErr message with Error-value=2 749 (capability not supported). According to the procedure defined in 750 section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages 751 at a rate equal of greater than specified rate, the PCC/PCE must send 752 a PCEP CLOSE message with close value=5 "Reception of an unacceptable 753 number of unrecognized PCEP messages". In this case, the PCC/PCE 754 must also close the TCP session and must not send any further PCEP 755 messages on the PCEP session. 757 2) If the PCE supports the monitoring request but the monitoring 758 request is prohibited by policy, the PCE must follow the procedure 759 specified in section 5. As pointed out in section 4.3, a PCE may 760 still partially satisfy a request, leaving out some of the required 761 data if not allowed by policy. 763 3) If the PCE supports the monitoring request and that request is not 764 prohibited by policy, the receiving PCE MUST first determine whether 765 it is the last PCE of the path computation chain. If the PCE is not 766 the last element of the path computation chain, the PCReq message 767 (with the MONITORING object and potentially other monitoring objects 768 such as the PCE-ID) is relayed to the next hop PCE: such next hop may 769 either be specified by means of a PCE-ID object present in the PCReq 770 message or dynamically determined by means of a procedure outside of 771 the scope of this document. Conversely, if the PCE is the last PCE 772 of the path computation chain, the PCE originates a PCRep message 773 that contains the requested objects according to the set of requested 774 PCE states metrics listed in the MONITORING and potentially other 775 monitoring objects carried in the corresponding PCReq message. 777 Upon receiving a PCMonRep message, the PCE processes the request, 778 adds the relevant objects to the PCMonRep message and forwards the 779 PCMonRep message to the upstream requesting PCE or PCC. 781 Upon receiving a PCRep message that carries monitoring data, the 782 message is processed, additional monitoring data is added according 783 to this specification and the message is forwarded upstream to the 784 requesting PCE or PCC. 786 Special case of multi-destination monitoring: monitoring request 787 related to more than one destinations may involve a set of path 788 computation chains. In that case, a PCE sends each copy of the 789 PCMonReq message to each downstream PCE of each path computation 790 chain. 792 7. Manageability Considerations 794 7.1. Control of Function and Policy 796 It MUST be possible to configure the activation/deactivation of PCEP 797 monitoring on a PCEP speaker. In addition to the parameters already 798 listed in section 8.1 of [RFC5440], a PCEP implementation SHOULD 799 allow configuring on a PCE whether specific, generic, in band and out 800 of band monitoring requests are allowed or not. Also a PCEP 801 implementation SHOULD allow configuring on a PCE a list of authorized 802 state metrics (aliveness, congestion, processing time, etc). This 803 may apply to any session the PCEP speaker participates in, to a 804 specific session with a given PCEP peer or to a specific group of 805 sessions with a specific group of PCEP peers, for instance the PCEP 806 peers of a neighbor AS. 808 7.2. Information and Data Models 810 A new MIB Module may be defined that provides local PCE state 811 metrics, as well as state metrics of other PCEs gathered using 812 mechanisms defined in this document. 814 7.3. Liveness Detection and Monitoring 816 This document provides mechanisms to monitor the liveliness and 817 performances of a given PCE chain. 819 7.4. Verify Correct Operations 821 Mechanisms defined in this document do not imply any new operation 822 verification requirements in addition to those already listed in 823 [RFC5440]. 825 7.5. Requirements On Other Protocols 827 Mechanisms defined in this document do not imply any requirements on 828 other protocols in addition to those already listed in [RFC5440]. 830 7.6. Impact On Network Operations 832 The frequency of PCMonReq messages may impact the operations of PCEs. 833 An implementation SHOULD allow a limit to be placed on the rate of 834 PCMonReq messages sent by a PCEP speaker and processed from a peer. 835 It SHOULD also allow sending a notification when a rate threshold is 836 reached. An implementation SHOULD allow handling PCReq messages with 837 a higher priority than PCMonReq messages. An implementation SHOULD 838 allow the configuration of a second limit for the PCReq message 839 requesting monitoring data. 841 8. IANA Considerations 843 8.1. New PCEP Message 845 Each PCEP message has a message type value. 847 Two new PCEP (specified in [RFC5440]) messages are defined in this 848 document: 850 Value Description Reference 851 8 Path Computation Monitoring Request (PCMonReq) This document 852 9 Path Computation Monitoring Reply (PCMonRep) This document 854 8.2. New PCEP Objects 856 Each PCEP object has an Object-Class and an Object-Type. The 857 following new PCEP objects are defined in this document: 859 Object-Class Value Name Object-Type Reference 861 19 MONITORING 1 This document 863 20 PCE-ID 1: IPv4 addresses This document 864 2: IPv6 addresses This document 866 21 PROC-TIME 1 This document 868 22 CONGESTION 1 This document 870 8.3. New Error-Values 872 A registry was created for the Error-type and Error-value of the PCEP 873 Error Object. 875 A new Error-value for the PCErr message Error-types=5 (Policy 876 Violation) (see [RFC5440]) is defined in this document (Error-value 877 to be assigned by IANA). 879 Error-Type Meaning Error-value Reference 880 5 Policy violation 3 This document 881 Monitoring message supported 882 but rejected due to 883 policy violation 885 A new Error-value for the PCErr message Error-types=6 (Mandatory 886 Object missing) (see [RFC5440]) is defined in this document (Error- 887 Type and Error-value to be assigned by IANA). 889 Error-type Meaning Error-value Reference 890 6 Mandatory Object missing 4 This document 891 MONITORING Object missing 893 8.4. MONITORING Object Flag Field 895 IANA is requested to create a registry to manage the Flag field of 896 the MONITORING object. 898 New bit numbers may be allocated only by an IETF Consensus action. 899 Each bit should be tracked with the following qualities: 901 o Bit number (counting from bit 0 as the most significant bit) 903 o Capability Description 905 o Defining RFC 907 Several bits are defined for the MONITORING Object flag field in this 908 document: 910 Codespace of the Flag field (MONITORING Object) 911 Bit Description Reference 912 0-18 Unassigned 913 19 Incomplete This document 914 20 Congestion This document 915 21 Processing Time This document 916 22 General This document 917 23 Liveness This document 919 8.5. PROC-TIME Object Flag Field 921 IANA is requested to create a registry to manage the Flag field of 922 the PROC-TIME object. 924 New bit numbers may be allocated only by an IETF Consensus action. 925 Each bit should be tracked with the following qualities: 927 o Bit number (counting from bit 0 as the most significant bit) 929 o Capability Description 931 o Defining RFC 933 One bit is defined for the PROC-TIME Object flag field in this 934 document: 936 Codespace of the Flag field (PROC-TIME Object) 937 Bit Description Reference 938 0-14 Unassigned 939 15 Estimated This document 941 8.6. CONGESTION Object Flag field 943 IANA is requested to create a registry to manage the Flag field of 944 the CONGESTION object. 946 New bit numbers may be allocated only by an IETF Consensus action. 947 Each bit should be tracked with the following qualities: 949 o Bit number (counting from bit 0 as the most significant bit) 951 o Capability Description 953 o Defining RFC 955 One bit is defined for the CONGESTION Object flag field in this 956 document: 958 Codespace of the Flag field (CONGESTION Object) 959 Bit Description Reference 960 0-7 Unassigned 962 9. Security Considerations 964 The use of monitoring data can be used for various attacks such as 965 denial of service attacks (for example by setting the C bit and 966 congestion during field of the CONGESTION object to stop PCCs from 967 using a PCE). Thus it is recommended to make use of the security 968 mechanisms discussed in [RFC5440] to secure a PCEP session 969 (authenticity, integrity, privacy, DoS protection, etc) to secure the 970 PCMonReq, PCMonRep messages and PCE state metric objects defined in 971 this document. An implementation SHOULD allow limiting the rate at 972 which PCMonReq or PCReq messages carrying monitoring requests 973 received from a specific peer are processed (input shaping), or from 974 another domain (see also section 7.6). 976 10. Acknowledgments 978 The authors would like to thank Eiji Oki, Mach Chen, Fabien 979 Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful 980 comments. Special thank to Adrian Farrel for his detailed review. 982 11. References 984 11.1. Normative References 986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 987 Requirement Levels", BCP 14, RFC 2119, March 1997. 989 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 990 (PCE) Communication Protocol (PCEP)", RFC 5440, 991 March 2009. 993 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 994 Used to Form Encoding Rules in Various Routing Protocol 995 Specifications", RFC 5511, April 2009. 997 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 998 Path Computation Element Communication Protocol (PCEP) for 999 Route Exclusions", RFC 5521, April 2009. 1001 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1002 Objective Functions in the Path Computation Element 1003 Communication Protocol (PCEP)", RFC 5541, June 2009. 1005 11.2. Informative References 1007 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1008 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1010 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1011 "OSPF Protocol Extensions for Path Computation Element 1012 (PCE) Discovery", RFC 5088, January 2008. 1014 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1015 "IS-IS Protocol Extensions for Path Computation Element 1016 (PCE) Discovery", RFC 5089, January 2008. 1018 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 1019 Backward-Recursive PCE-Based Computation (BRPC) Procedure 1020 to Compute Shortest Constrained Inter-Domain Traffic 1021 Engineering Label Switched Paths", RFC 5441, April 2009. 1023 Authors' Addresses 1025 JP Vasseur (editor) 1026 Cisco Systems, Inc 1027 1414 Massachusetts Avenue 1028 Boxborough, MA 01719 1029 USA 1031 Email: jpv@cisco.com 1033 JL Le Roux 1034 France Telecom 1035 2, Avenue Pierre-Marzin 1036 Lannion, 22307 1037 FRANCE 1039 Email: jeanlouis.leroux@orange-ftgroup.com 1041 Yuichi Ikejiri 1042 NTT Communications Corporation 1043 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1044 Tokyo, 100-8019 1045 Japan 1047 Email: : y.ikejiri@ntt.com