idnits 2.17.1 draft-ietf-pce-monitoring-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (December 16, 2009) is 5237 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: June 19, 2010 France Telecom 5 Y. Ikejiri 6 NTT Communications Corporation 7 December 16, 2009 9 A set of monitoring tools for Path Computation Element based 10 Architecture 11 draft-ietf-pce-monitoring-07.txt 13 Abstract 15 A Path Computation Element (PCE) based architecture has been 16 specified for the computation of Traffic Engineering (TE) Label 17 Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and 18 Generalized MPLS (GMPLS) networks in the context of single or 19 multiple domains (where a domain refers to a collection of network 20 elements within a common sphere of address management or path 21 computational responsibility such as IGP areas and Autonomous 22 Systems). Path Computation Clients (PCCs) send computation requests 23 to PCEs, and these may forward the requests to and cooperate with 24 other PCEs forming a "path computation chain". 26 In PCE-based environments, it is thus critical to monitor the state 27 of the path computation chain for troubleshooting and performance 28 monitoring purposes: liveness of each element (PCE) involved in the 29 PCE chain, detection of potential resource contention states and 30 statistics in term of path computation times are examples of such 31 metrics of interest. This document specifies procedures and 32 extensions to the Path Computation Element Protocol (PCEP) in order 33 to gather such information. 35 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt. 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html. 56 This Internet-Draft will expire on June 19, 2010. 58 Copyright Notice 60 Copyright (c) 2009 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Path Computation Monitoring messages . . . . . . . . . . . . . 6 79 3.1. Path Computation Monitoring Request message (PCMonReq) . . 6 80 3.2. Path Monitoring Reply message (PCMonRep) . . . . . . . . . 9 81 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 11 82 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12 83 4.2. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 14 84 4.3. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 15 85 4.4. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 17 86 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 18 88 7. Manageability Considerations . . . . . . . . . . . . . . . . . 20 89 7.1. Control of Function and Policy . . . . . . . . . . . . . . 20 90 7.2. Information and Data Models . . . . . . . . . . . . . . . 20 91 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 92 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 20 93 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 20 94 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 21 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 21 97 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 21 98 8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 21 99 8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 22 100 8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 22 101 8.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 23 102 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 103 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 109 1. Introduction 111 The Path Computation Element (PCE) based architecture has been 112 specified in [RFC4655] for the computation of Traffic Engineering 113 (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching 114 (MPLS) and Generalized MPLS (GMPLS) networks in the context of single 115 or multiple domains where a domain refers to a collection of network 116 elements within a common sphere of address management or path 117 computational responsibility such Interior Gateway Protocol (IGP) 118 areas and Autonomous Systems. 120 Path Computation Clients (PCCs) send computation requests to PCEs 121 using PCReq messages, and these may forward the requests to and 122 cooperate with other PCEs forming a "path computation chain". In 123 case of succesful path computation the computed paths are then 124 provided to the requesting PCC using PCRep messages. The PCReq and 125 PCRep messages are defined in [RFC5440]. 127 In PCE-based environments, it is critical to monitor the state of the 128 path computation chain for troubleshooting and performance monitoring 129 purposes: liveness of each element (PCE) involved in the PCE chain, 130 detection of potential resource contention states and statistics in 131 term of path computation times are examples of such metrics of 132 interest. 134 As defined in [RFC4655], there are circumstances where more than one 135 PCE are involved in the computation of a TE LSP. A typical example 136 is when the PCC requires the computation of a TE LSP where the head- 137 end and the tail-end of the TE LSP do not reside in adjacent domains 138 and there is no single PCE with the visibility of both the head-end 139 and tail-end domain. We call the set of PCEs involved in the 140 computation of a TE LSP a "path computation chain". As further 141 discussed in Section 3.1, the PCE chain may either be static (pre- 142 configured) or dynamically determined during the path computation 143 process. 145 As discussed in [RFC4655], a TE LSP may be computed by one PCE 146 (referred to as single PCE path computation) or several PCEs 147 (referred to as multiple PCE path computation). In the former case, 148 the PCC may be able to use IGP extensions to check the liveness of 149 the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive 150 messages. In contrast, when multiple PCEs are involved in the path 151 computation chain an example of which is the Backward Recursive PCE- 152 based Computation (BRPC) procedure defined in [RFC5441], the PCC's 153 visibility may be limited to the first PCE involved in the path 154 computation chain. Thus, it is critical to define mechanisms in 155 order to monitor the state of the path computation chain. 157 This document specifies PCEP extensions in order to gather various 158 state metrics along the path computation chain. In this document we 159 call a "state metric" a metric that characterizes a PCE state. For 160 example, such metric can have a form of a boolean (PCE is alive or 161 not, PCE is congested or not) or a performance metric (path 162 computation time at each PCE). 164 PCE state metrics can be gathered in two different contexts: in band 165 or out of band. By "in band" we refer to the situation whereby a PCC 166 requests to gather metrics in the context of a path computation 167 request. For example, a PCC may send a path computation request to a 168 PCE and may want to know the processing time of that request in 169 addition to the computed path. Conversely, if the request is "out of 170 band", PCE state metric collection is performed as a standalone 171 request (e.g., check the liveness of a specific PCE chain, collect 172 the average processing time computed over the last 5mn period on one 173 or more PCEs"). 175 In this document we define two monitoring request types: general and 176 specific. A general monitoring request relates to the collection of 177 a PCE state metrics that is not coupled to a particular path 178 computation request (e.g., average CPU load on a PCE). Conversely, a 179 specific monitoring request relates to a particular path computation 180 request (processing time to complete the path computation for a TE 181 LSP). 183 This document specifies procedures and extensions to the Path 184 Computation Element Protocol (PCEP) ([RFC5440]), including new 185 objects and new PCEP messages, in order to monitor the path 186 computation chain and gather various performance metrics. 188 The message formats in this document are specified using Backus Naur 189 Format (BNF) encoding as specified in [RFC5511]. 191 1.1. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in RFC 2119 [RFC2119]. 197 2. Terminology 199 PCC (Path Computation Client): any client application requesting a 200 path computation to be performed by a Path Computation Element. 202 PCE (Path Computation Element): an entity (component, application or 203 network node) that is capable of computing a network path or route 204 based on a network graph and applying computational constraints. 206 TE LSP: Traffic Engineering Label Switched Path. 208 3. Path Computation Monitoring messages 210 As defined in [RFC5440], a PCEP message consists of a common header 211 followed by a variable length body made of a set of objects that can 212 either be mandatory or optional. As a reminder, an object is said to 213 be mandatory in a PCEP message when the object must be included for 214 the message to be considered as valid. The P flag (defined in 215 [RFC5440]) is located in the common header of each PCEP object and 216 can be set by a PCEP peer to require a PCE to take into account the 217 related information during the path computation. Because the P flag 218 exclusively relates to a path computation request, it MUST be cleared 219 in the two PCEP messages (PCMonReq and PCMonRep message). 221 For each PCEP message type a set of rules is defined that specify the 222 set of objects that the message can carry. An implementation MUST 223 form the PCEP messages using the object ordering specified in this 224 document. 226 In this document we define two PCEP messages referred to as the Path 227 Computation Monitoring Request (PCMonReq) and Path Computation 228 Monitoring Reply (PCMonRep) messages so as to handle "out of band" 229 monitoring request. The aim of the PCMonReq message sent by a PCC to 230 a PCE is to gather one or more PCE state metrics on a set of PCEs 231 involved in a path computation chain. The PCMonRep message sent by a 232 PCE to a PCC is used to provide such data. 234 3.1. Path Computation Monitoring Request message (PCMonReq) 236 The Message-Type field of the PCEP common header for the PCMonReq 237 message is set to 8 (To be confirmed by IANA). 239 There is one mandatory object that MUST be included within a PCMonReq 240 message: the MONITORING object (see section Section 4.1). If the 241 MONITORING object is missing, the receiving PCE MUST send a PCErr 242 message with Error-type=6 (Mandatory Object missing) and Error- 243 value=4 (MONITORING Object missing). Other objects are optional. 245 Format of a PCMonReq message (out of band request): 246 ::= 247 248 [] 249 [] 250 [] 251 where: 253 ::= 254 [] 255 [] 257 ::=[] 259 ::= 260 261 [] 262 [] 263 [] 264 [] 265 [] 266 [] 267 [] 269 ::=[] 271 ::=[] 272 Format of a PCReq message with monitoring data requested (in band 273 request): 274 ::= 275 276 [] 277 [] 278 280 where: 281 ::=[] 283 ::=[] 285 ::= 286 287 [] 288 [] 289 [] 290 [[]] 291 [] 292 [] 293 where: 295 ::=[] 297 ::=[] 299 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 300 BALANCING objects are defined in [RFC5440]. The XRO object is 301 defined in [RFC5521] and the OF object is defined in [RFC5541]. 303 The PCMonReq message is used to gather various PCE state metrics 304 along a path computation chain. The path computation chain may be 305 determined by the PCC (in the form of a series of a series of PCE-ID 306 objects defined in Section 4.2.) or may alternatively be determined 307 by the path computation procedure. For example, if the BRPC 308 procedure ([RFC5441]) is used to compute an inter-domain TE LSP, the 309 PCE chain may be determined dynamically. In that case, the PCC sends 310 a PCMonReq message that contains the PCEP objects that characterize 311 the TE LSP attributes along with the MONITORING object (see 312 Section 4.1) that lists the set of metrics of interest. 314 Several PCE state metrics may be requested that are specified by a 315 set of objects defined in Section 4. Note that this set of objects 316 may be extended in the future. 318 As pointed out in [RFC5440] several situations can arise: 320 o Bundle of a set of independent and non-synchronized path 321 computation requests, 323 o Bundle of a set of independent and synchronized path computation 324 requests (SVEC object defined below required), 326 o Bundle of a set of dependent and synchronized path computation 327 requests (SVEC object defined below required). 329 In the case of a bundle of a set of request, the MONITORING object 330 SHOULD only be present in the first PCReq or PCMonReq message and the 331 monitoring request applies to all the requests of the bundle, even in 332 the case of dependent and/or synchronized requests sent using more 333 than one PCReq or PCMonReq message. 335 Examples of requests. For the sake of illustration, consider the 336 three following examples: 338 Example 1 (out of band request): PCC1 requests to check the path 339 computation chain that would be used should it request a path 340 computation for a specific TE LSP named T1. A PCMonReq message is 341 sent that contains a MONITORING object specifying a path computation 342 check, along with the appropriate set of objects (e.g., RP, END- 343 POINTS, ...) that would be included in a PCReq message for T1. 345 Example 2 (in band request): PCC1 requests a path computation for a 346 TE LSP and also request to gather the processing time along the path 347 computation chain selected for the computation of T1. A PCReq 348 message is sent that also contains a MONITORING object that specifies 349 the performance metrics of interest. 351 Example 3 (out of band request): PCC2 requests to gather performance 352 metrics along the specific path computation chain . A PCMonReq message is sent to PCE1 that contains a MONITORING 354 object and a sequence of PCE-ID objects that identify PCE1, PCE2, 355 PCE3 and PCE7 respectively. 357 In all of the examples above, a PCRep message (in-band request) or 358 PCMonReq message (out of band request) is sent in response to the 359 request that reports the computed metrics. 361 3.2. Path Monitoring Reply message (PCMonRep) 363 The PCMonRep message is used to provide PCE state metrics back to the 364 requester for "out of band" monitoring requests. The Message-Type 365 field of the PCEP common header for the PCMonRep message is set to 9 366 (To be confirmed by IANA). 368 There is one mandatory object that MUST be included within a PCMonRep 369 message: the MONITORING object (see Section 4.1). If the MONITORING 370 object is missing, the receiving PCE MUST send a PCErr message with 371 Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING 372 Object missing). 374 Other objects are optional. 376 Format of a PCMonRep (out of band request): 377 ::= 378 379 [] 380 [] 382 where: 384 ::=[] 386 ::= 387 [] 388 [] 390 Format of a PCRep message with monitoring data (in band): 391 ::= 392 394 where: 395 ::=[] 397 ::= 398 399 [] 400 [] 401 [] 402 [] 404 ::=[] 406 ::= 408 where: 410 ::=[] 411 [] 412 [] 413 [] 415 ::=[] 417 ::=[] 419 ::= 420 [] 421 [] 423 The RP and the NO-PATH objects are defined in [RFC5440]. 425 4. Path Computation Monitoring Objects 427 The PCEP objects defined in the document are compliant with the PCEP 428 object format defined in [RFC5440]. The P flag and the I flag of the 429 PCEP objects defined in this document SHOULD always be set to 0 on 430 transmission and MUST be ignored on receipt since these flags are 431 exclusively related to path computation requests. 433 Several objects are defined in this section that can be carried 434 within the PCEP PCReq or PCRep messages defined in [RFC5440] in case 435 of "in band" monitoring requests (the PCC requests the computation of 436 the TE LSP in addition to gathering PCE state metrics). In case of 437 "out of band" monitoring requests, the objects defined in this 438 section are carried within PCMonReq and PCMonRep messages. 440 All TLVs carried in objects defined in this document have the TLV 441 format defined in [RFC5440] 443 o Type: 2 bytes 445 o Length: 2 bytes 447 o Value: variable 449 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 450 specifying the TLV length, and a value field. The Length field 451 defines the length of the value portion in bytes. The TLV is padded 452 to 4-bytes alignment; padding is not included in the Length field (so 453 a 3-byte value would have a length of 3, but the total size of the 454 TLV would be 8 bytes). Unrecognized TLVs MUST be ignored. 456 4.1. MONITORING Object 458 The MONITORING object MUST be present within PCMonReq and PCMonRep 459 messages ("out of band" monitoring requests) and MAY be carried 460 within PCRep and PCReq messages ("in band" monitoring requests). 461 There SHOULD NOT be more than one instance of the MONITORING object 462 in a PCMonReq or PCMonRep message: if more than one instance of the 463 MONITORING object is present, the recipient MUST process the first 464 instance and MUST ignore other instances. 466 The MONITORING object is used to specify the set of requested PCE 467 state metrics. 469 The MONITORING Object-Class is to be assigned by IANA (recommended 470 value=19) 472 The MONITORING Object-Type is to be assigned by IANA (recommended 473 value=1) 474 The format of the MONITORING object body is as follows: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Reserved | Flags |I|C|P|G|L| 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Monitoring-id-number | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 // Optional TLV(s) // 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Flags: 24 bits 489 The following flags are currently defined: 491 L (Liveness) - 1 bit: when set, this indicates that the state metric 492 of interest is the PCE's liveness and thus the PCE MUST include a 493 PCE-ID object in the corresponding reply. The L bit MUST always be 494 ignored in a PCMonRep or PCRep message. 496 G (General) - 1 bit: when set, this indicates that the monitoring 497 request is a general monitoring request. When the requested 498 performance metric is specific, the G bit MUST be cleared. The G bit 499 MUST always be ignored in a PCMonRep or PCRep message. 501 P (Processing Time) - 1 bit: the P bit of the MONITORING object 502 carried in a PCMonReq or a PCReq message is set to indicate that the 503 processing times is a metric of interest. If allowed by policy, a 504 PROC-TIME object MUST be inserted in the corresponding PCMonRep or 505 PCRep message. The P bit MUST always be ignored in a PCMonRep or 506 PCRep message. 508 C (Overload) - 1 bit: The C bit of the MONITORING object carried in a 509 PCMonReq or a PCReq message is set to indicate that the overload 510 status is a metric of interest, in which case a OVERLOAD object MUST 511 be inserted in the corresponding PCMonRep or PCRep message. The C 512 bit MUST always be ignored in a PCMonRep or PCRep message. 514 I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message 515 and that message does not trigger any policy violation, but the PCE 516 cannot provide any of the set of requested performance metrics for 517 unspecified reasons, the PCE MUST set the I bit. The I bit has no 518 meaning in a request and SHOULD be ignored on receipt. 520 Monitoring-id-number (32 bits): The monitoring-id-number value 521 combined with the PCEP-ID of the PCC identifies the monitoring 522 request context. The monitoring-id-number MUST start at a non-zero 523 value and MUST be incremented each time a new monitoring request is 524 sent to a PCE. Each increment SHOULD have a value of 1 and may cause 525 a wrap back to zero. If no reply to a monitoring request is received 526 from the PCE, and the PCC wishes to resend its path computation 527 monitoring request, the same monitoring-id-number MUST be used. 528 Conversely, a different monitoring-id-number MUST be used for 529 different requests sent to a PCE. The path computation monitoring 530 reply is unambiguously identified by the monitoring-id-number and the 531 PCEP-ID of the replying PCE. A PCEP implementation SHOULD checkpoint 532 the Monitoring-id-number of pending monitoring requests in case of 533 restart thus avoiding the re-use of a Monitoring-id-number of an in- 534 process monitoring request. 536 Unassigned bits are considered as reserved and MUST be set to zero on 537 transmission and ignored on reception. 539 No optional TLVs are currently defined. 541 4.2. PCE-ID Object 543 The PCE-ID Object is used to specify a PCE's IP address. 545 A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq 546 message to specify the PCE for which PCE state metrics are requested 547 and in a PCMonRep or a PCRep message to record the IP address of the 548 PCE reporting PCE state metrics or that was involved in the path 549 computation chain. 551 Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- 552 Class is to be assigned by IANA (recommended value=20) PCE-ID Object- 553 Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 554 for IPv6) 556 The format of the PCE-ID Object is as follows: 558 The format of the PCE-ID object body for IPv4 and IPv6 are as 559 follows: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | IPv4 Address | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | | 571 | IPv6 Address | 572 | | 573 | | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 576 octets for IPv6. 578 When a dynamic discovery mechanism is used for PCE discovery, a PCE 579 advertises its PCE address in the PCE-ADDRESS sub-TLV defined in 580 [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and 581 PCMonReq messages and a PCE MUST also use this address in PCRep and 582 PCMonRep messages. 584 4.3. PROC-TIME Object 586 If allowed by policy, the PCE includes a PROC-TIME object within a 587 PCMonRep or a PCRep message if the P bit of the MONITORING object 588 carried within the corresponding PCMonReq or PCReq message is set. 589 The PROC-TIME object is used to report various processing time 590 related metrics. 592 1) Case of general monitoring requests 594 A PCC may request processing time metrics for general monitoring 595 requests (e.g., the PCC may want to know the minimum, maximum and 596 average processing times on a particular PCE). In this case, general 597 requests can only be made by using PCMonReq/PCMonRep messages. The 598 Current-processing-time field (as explained below) is exclusively 599 used for specific monitoring requests and MUST be cleared for general 600 monitoring requests. The algorithms used by a PCE to compute the 601 minimum, maximum, average and variance of the processing times are 602 out of the scope of this document (A PCE may decide to compute the 603 minimum processing time over a period of times, for the last N path 604 computation requests, ...). 606 2) Case of specific monitoring requests 608 In the case of a specific request, the algorithms used by a PCE to 609 compute the Processing-time metrics are out of the scope of this 610 document but a flag is specified that is used to indicate to the 611 requester whether the processing time value was estimated or 612 computed. The PCE may either (1) estimate the processing time 613 without performing an actual path computation or (2) effectively 614 perform the computation to report the processing time. In the former 615 case, the E bit of the PROC-TIME object MUST be set. The G bit MUST 616 be cleared and the Min-processing-time, Max-processing-time, Average- 617 processing-time and Variance-processing-time MUST be set to 618 0x00000000. 620 When the processing time is requested in addition to a path 621 computation (case where the MONITORING object is carried within a 622 PCReq message), the PROC-TIME object always reports the actual 623 processing time for that request and thus the E bit MUST be cleared. 625 The PROC-TIME Object-Class is to be assigned by IANA (recommended 626 value=21) 628 The PROC-TIME Object-Type is to be assigned by IANA (recommended 629 value=1) 631 The format of the PROC-TIME object body is as follows: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Reserved | Flags |E| 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Current-processing-time | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Min-processing-time | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Max-processing-time | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Average-processing time | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Variance-processing-time | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Flags: 16 bits - one flag is currently defined: 650 E (Estimated) - 1 bit: when set, this indicates that the reported 651 metric value is based on estimated processing time as opposed to 652 actual computations. 654 Unassigned bits are considered as reserved and MUST be set to zero on 655 transmission. 657 Current-processing-time: This field indicates in milliseconds the 658 processing time for the path computation of interest characterized in 659 the corresponding PCMonReq message. 661 Min-processing-time: This field indicates in milliseconds the minimum 662 processing time. 664 Max-processing-time: This field indicates in milliseconds the maximum 665 processing time. 667 Average-processing-time: This field indicates in milliseconds the 668 average processing time. 670 Variance-processing-time: This field indicates in milliseconds the 671 variance of the processing times. 673 4.4. OVERLOAD Object 675 The OVERLOAD object is used to report a PCE processing congestion 676 state. Note that "overload" as indicated by this object refers to 677 the processing state of the PCE and its ability to handle new PCEP 678 requests. A PCE is overloaded when it has a backlog of PCEP requests 679 such that it cannot immediately start to process a new request thus 680 leading to waiting times. The overload duration is quantified as 681 being the (estimated) time until the PCE expects to be able to 682 immediately process a new PCEP request. 684 The OVERLOAD object MUST be present within a PCMonRep or a PCRep 685 message if the C bit of the MONITORING object carried within the 686 corresponding PCMonReq or PCReq message is set and the PCE is 687 experiencing a congested state. The OVERLOAD Object-Class is to be 688 assigned by IANA (recommended value=22). The OVERLOAD Object-Type is 689 to be assigned by IANA (recommended value=1) 691 The format of the CONGESTION object body is as follows: 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Flags | Reserved | Overload Duration | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Flags: 8 bits - No flag is currently defined. 700 Overload duration - 16 bits: This field indicates in the amount of 701 time in seconds that the responding PCE expects that it may continue 702 to be overloaded from the time that the response message was 703 generated. The receiver MAY use this value to decide whether or not 704 so send further requests to the same PCE. 706 It is worth noting that a PCE along a PCE chain involved in the 707 monitoring request may decide to learn from the overload information 708 received by one of downstream PCE in the chain. 710 5. Policy 712 The receipt of a PCMonReq message may trigger a policy violation on 713 some PCE in which case the PCE MUST send a PCErr message with Error- 714 Type=5 and Error-value=3 (To be Confirmed by IANA). 716 6. Elements of Procedure 718 I bit processing: as indicated in section Section 4.1, if a PCE 719 supports a received PCMonReq message and that message does not 720 trigger any policy violation, but the PCE cannot provide any of the 721 set of requested performance metrics for unspecified reasons, the PCE 722 MUST set the I bit. Once set, the I bit MUST NOT be changed by a 723 receiving PCE. 725 Upon receiving a PCMonReq message: 727 1) As specified in [RFC5440], if the PCE does not support the 728 PCMonReq message, the PCE peer MUST send a PCErr message with Error- 729 value=2 (capability not supported). According to the procedure 730 defined in section 6.9 of [RFC5440], if a PCC/PCE receives 731 unrecognized messages at a rate equal of greater than specified rate, 732 the PCC/PCE must send a PCEP CLOSE message with close value=5 733 "Reception of an unacceptable number of unrecognized PCEP messages". 734 In this case, the PCC/PCE must also close the TCP session and must 735 not send any further PCEP messages on the PCEP session. 737 2) If the PCE supports the PCMonReq message but the monitoring 738 request is prohibited by policy, the PCE must follow the procedure 739 specified in section 5. As pointed out in section 4.3, a PCE may 740 still partially satisfy a request, leaving out some of the required 741 data if not allowed by policy. 743 3) If the PCE supports the PCMonReq and the monitoring request is not 744 prohibited by policy, the receiving PCE MUST first determine whether 745 it is the last PCE of the path computation chain. If the PCE is not 746 the last element of the path computation chain, the PCMonReq message 747 is relayed to the next hop PCE: such next hop may either be specified 748 by means of a PCE-ID object present in the PCMonReq message or 749 dynamically determined by means of a procedure outside of the scope 750 of this document. Conversely, if the PCE is the last PCE of the path 751 computation chain, the PCE originates a PCMonRep message that 752 contains the requested objects according to the set of requested PCE 753 states metrics listed in the MONITORING object carried in the 754 corresponding PCMonReq message. 756 Upon receiving a PCReq message that carries a MONITORING and 757 potentially other monitoring objects (e.g., PCE-ID object): 759 1) As specified in [RFC5440], if the PCE does not support (in band) 760 monitoring, the PCE peer MUST send a PCErr message with Error-value=2 761 (capability not supported). According to the procedure defined in 762 section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages 763 at a rate equal of greater than specified rate, the PCC/PCE must send 764 a PCEP CLOSE message with close value=5 "Reception of an unacceptable 765 number of unrecognized PCEP messages". In this case, the PCC/PCE 766 must also close the TCP session and must not send any further PCEP 767 messages on the PCEP session. 769 2) If the PCE supports the monitoring request but the monitoring 770 request is prohibited by policy, the PCE must follow the procedure 771 specified in section 5. As pointed out in section 4.3, a PCE may 772 still partially satisfy a request, leaving out some of the required 773 data if not allowed by policy. 775 3) If the PCE supports the monitoring request and that request is not 776 prohibited by policy, the receiving PCE MUST first determine whether 777 it is the last PCE of the path computation chain. If the PCE is not 778 the last element of the path computation chain, the PCReq message 779 (with the MONITORING object and potentially other monitoring objects 780 such as the PCE-ID) is relayed to the next hop PCE: such next hop may 781 either be specified by means of a PCE-ID object present in the PCReq 782 message or dynamically determined by means of a procedure outside of 783 the scope of this document. Conversely, if the PCE is the last PCE 784 of the path computation chain, the PCE originates a PCRep message 785 that contains the requested objects according to the set of requested 786 PCE states metrics listed in the MONITORING and potentially other 787 monitoring objects carried in the corresponding PCReq message. 789 Upon receiving a PCMonRep message, the PCE processes the request, 790 adds the relevant objects to the PCMonRep message and forwards the 791 PCMonRep message to the upstream requesting PCE or PCC. 793 Upon receiving a PCRep message that carries monitoring data, the 794 message is processed, additional monitoring data is added according 795 to this specification and the message is forwarded upstream to the 796 requesting PCE or PCC. 798 Special case of multi-destination monitoring: monitoring request 799 related to more than one destinations may involve a set of path 800 computation chains. In that case, a PCE sends each copy of the 801 PCMonReq message to each downstream PCE of each path computation 802 chain. 804 7. Manageability Considerations 806 7.1. Control of Function and Policy 808 It MUST be possible to configure the activation/deactivation of PCEP 809 monitoring on a PCEP speaker. In addition to the parameters already 810 listed in section 8.1 of [RFC5440], a PCEP implementation SHOULD 811 allow configuring on a PCE whether specific, generic, in band and out 812 of band monitoring requests are allowed or not. Also a PCEP 813 implementation SHOULD allow configuring on a PCE a list of authorized 814 state metrics (aliveness, overload, processing time, etc). This may 815 apply to any session the PCEP speaker participates in, to a specific 816 session with a given PCEP peer or to a specific group of sessions 817 with a specific group of PCEP peers, for instance the PCEP peers of a 818 neighbor AS. 820 7.2. Information and Data Models 822 A new MIB Module may be defined that provides local PCE state 823 metrics, as well as state metrics of other PCEs gathered using 824 mechanisms defined in this document. 826 7.3. Liveness Detection and Monitoring 828 This document provides mechanisms to monitor the liveliness and 829 performances of a given PCE chain. 831 7.4. Verify Correct Operations 833 Mechanisms defined in this document do not imply any new operation 834 verification requirements in addition to those already listed in 835 [RFC5440]. 837 7.5. Requirements On Other Protocols 839 Mechanisms defined in this document do not imply any requirements on 840 other protocols in addition to those already listed in [RFC5440]. 842 7.6. Impact On Network Operations 844 The frequency of PCMonReq messages may impact the operations of PCEs. 845 An implementation SHOULD allow a limit to be placed on the rate of 846 PCMonReq messages sent by a PCEP speaker and processed from a peer. 847 It SHOULD also allow sending a notification when a rate threshold is 848 reached. An implementation SHOULD allow handling PCReq messages with 849 a higher priority than PCMonReq messages. An implementation SHOULD 850 allow the configuration of a second limit for the PCReq message 851 requesting monitoring data. 853 8. IANA Considerations 855 8.1. New PCEP Message 857 Each PCEP message has a message type value. 859 Two new PCEP (specified in [RFC5440]) messages are defined in this 860 document: 862 Value Description Reference 863 8 Path Computation Monitoring Request (PCMonReq) This document 864 9 Path Computation Monitoring Reply (PCMonRep) This document 866 8.2. New PCEP Objects 868 Each PCEP object has an Object-Class and an Object-Type. The 869 following new PCEP objects are defined in this document: 871 Object-Class Value Name Object-Type Reference 873 19 MONITORING 1 This document 875 20 PCE-ID 1: IPv4 addresses This document 876 2: IPv6 addresses This document 878 21 PROC-TIME 1 This document 880 22 OVERLOAD 1 This document 882 8.3. New Error-Values 884 A registry was created for the Error-type and Error-value of the PCEP 885 Error Object. 887 A new Error-value for the PCErr message Error-types=5 (Policy 888 Violation) (see [RFC5440]) is defined in this document (Error-value 889 to be assigned by IANA). 891 Error-Type Meaning Error-value Reference 892 5 Policy violation 3 This document 893 Monitoring message supported 894 but rejected due to 895 policy violation 897 A new Error-value for the PCErr message Error-types=6 (Mandatory 898 Object missing) (see [RFC5440]) is defined in this document (Error- 899 Type and Error-value to be assigned by IANA). 901 Error-type Meaning Error-value Reference 902 6 Mandatory Object missing 4 This document 903 MONITORING Object missing 905 8.4. MONITORING Object Flag Field 907 IANA is requested to create a registry to manage the Flag field of 908 the MONITORING object. 910 New bit numbers may be allocated only by an IETF review. Each bit 911 should be tracked with the following qualities: 913 o Bit number (counting from bit 0 as the most significant bit) 915 o Capability Description 917 o Defining RFC 919 Several bits are defined for the MONITORING Object flag field in this 920 document: 922 Codespace of the Flag field (MONITORING Object) 923 Bit Description Reference 924 0-18 Unassigned 925 19 Incomplete This document 926 20 Overload This document 927 21 Processing Time This document 928 22 General This document 929 23 Liveness This document 931 8.5. PROC-TIME Object Flag Field 933 IANA is requested to create a registry to manage the Flag field of 934 the PROC-TIME object. 936 New bit numbers may be allocated only by an IETF review. Each bit 937 should be tracked with the following qualities: 939 o Bit number (counting from bit 0 as the most significant bit) 941 o Capability Description 943 o Defining RFC 945 One bit is defined for the PROC-TIME Object flag field in this 946 document: 948 Codespace of the Flag field (PROC-TIME Object) 949 Bit Description Reference 950 0-14 Unassigned 951 15 Estimated This document 953 8.6. OVERLOAD Object Flag field 955 IANA is requested to create a registry to manage the Flag field of 956 the OVERLOAD object. 958 New bit numbers may be allocated only by an IETF review. Each bit 959 should be tracked with the following qualities: 961 o Bit number (counting from bit 0 as the most significant bit) 963 o Capability Description 965 o Defining RFC 967 No Flag are currently defined for the OVERLOAD Object flag field in 968 this document. 970 Codespace of the Flag field (OVERLOAD Object) 971 Bit Description Reference 972 0-7 Unassigned 974 9. Security Considerations 976 The use of monitoring data can be used for various attacks such as 977 denial of service attacks (for example by setting the C bit and 978 overload duration field of the OVERLOAD object to stop PCCs from 979 using a PCE). Thus it is recommended to make use of the security 980 mechanisms discussed in [RFC5440] to secure a PCEP session 981 (authenticity, integrity, privacy, DoS protection, etc) to secure the 982 PCMonReq, PCMonRep messages and PCE state metric objects defined in 983 this document. An implementation SHOULD allow limiting the rate at 984 which PCMonReq or PCReq messages carrying monitoring requests 985 received from a specific peer are processed (input shaping), or from 986 another domain (see also section 7.6). 988 10. Acknowledgments 990 The authors would like to thank Eiji Oki, Mach Chen, Fabien 991 Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful 992 comments. Special thank to Adrian Farrel for his detailed review. 994 11. References 996 11.1. Normative References 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, March 1997. 1001 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1002 (PCE) Communication Protocol (PCEP)", RFC 5440, 1003 March 2009. 1005 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1006 Used to Form Encoding Rules in Various Routing Protocol 1007 Specifications", RFC 5511, April 2009. 1009 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1010 Path Computation Element Communication Protocol (PCEP) for 1011 Route Exclusions", RFC 5521, April 2009. 1013 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1014 Objective Functions in the Path Computation Element 1015 Communication Protocol (PCEP)", RFC 5541, June 2009. 1017 11.2. Informative References 1019 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1020 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1022 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1023 "OSPF Protocol Extensions for Path Computation Element 1024 (PCE) Discovery", RFC 5088, January 2008. 1026 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1027 "IS-IS Protocol Extensions for Path Computation Element 1028 (PCE) Discovery", RFC 5089, January 2008. 1030 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 1031 Backward-Recursive PCE-Based Computation (BRPC) Procedure 1032 to Compute Shortest Constrained Inter-Domain Traffic 1033 Engineering Label Switched Paths", RFC 5441, April 2009. 1035 Authors' Addresses 1037 JP Vasseur (editor) 1038 Cisco Systems, Inc 1039 1414 Massachusetts Avenue 1040 Boxborough, MA 01719 1041 USA 1043 Email: jpv@cisco.com 1045 JL Le Roux 1046 France Telecom 1047 2, Avenue Pierre-Marzin 1048 Lannion, 22307 1049 FRANCE 1051 Email: jeanlouis.leroux@orange-ftgroup.com 1053 Yuichi Ikejiri 1054 NTT Communications Corporation 1055 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1056 Tokyo, 100-8019 1057 Japan 1059 Email: : y.ikejiri@ntt.com