idnits 2.17.1 draft-ietf-pce-monitoring-08.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 (January 20, 2010) is 5203 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: July 24, 2010 France Telecom 5 Y. Ikejiri 6 NTT Communications Corporation 7 January 20, 2010 9 A set of monitoring tools for Path Computation Element based 10 Architecture 11 draft-ietf-pce-monitoring-08.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 July 24, 2010. 58 Copyright Notice 60 Copyright (c) 2010 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) . . . . . . . . . 10 81 4. Path Computation Monitoring Objects . . . . . . . . . . . . . 12 82 4.1. MONITORING Object . . . . . . . . . . . . . . . . . . . . 12 83 4.2. PCC-ID-REQ Object . . . . . . . . . . . . . . . . . . . . 14 84 4.3. PCE-ID Object . . . . . . . . . . . . . . . . . . . . . . 15 85 4.4. PROC-TIME Object . . . . . . . . . . . . . . . . . . . . . 16 86 4.5. OVERLOAD Object . . . . . . . . . . . . . . . . . . . . . 18 87 5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 89 7. Manageability Considerations . . . . . . . . . . . . . . . . . 21 90 7.1. Control of Function and Policy . . . . . . . . . . . . . . 21 91 7.2. Information and Data Models . . . . . . . . . . . . . . . 21 92 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 93 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 21 94 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 22 95 7.6. Impact On Network Operations . . . . . . . . . . . . . . . 22 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 97 8.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 22 98 8.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 22 99 8.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 23 100 8.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 23 101 8.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 24 102 8.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 24 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 104 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 106 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 107 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 110 1. Introduction 112 The Path Computation Element (PCE) based architecture has been 113 specified in [RFC4655] for the computation of Traffic Engineering 114 (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching 115 (MPLS) and Generalized MPLS (GMPLS) networks in the context of single 116 or multiple domains where a domain refers to a collection of network 117 elements within a common sphere of address management or path 118 computational responsibility such Interior Gateway Protocol (IGP) 119 areas and Autonomous Systems. 121 Path Computation Clients (PCCs) send computation requests to PCEs 122 using PCReq messages, and these may forward the requests to and 123 cooperate with other PCEs forming a "path computation chain". In 124 case of succesful path computation the computed paths are then 125 provided to the requesting PCC using PCRep messages. The PCReq and 126 PCRep messages are defined in [RFC5440]. 128 In PCE-based environments, it is critical to monitor the state of the 129 path computation chain for troubleshooting and performance monitoring 130 purposes: liveness of each element (PCE) involved in the PCE chain, 131 detection of potential resource contention states and statistics in 132 term of path computation times are examples of such metrics of 133 interest. 135 As defined in [RFC4655], there are circumstances where more than one 136 PCE are involved in the computation of a TE LSP. A typical example 137 is when the PCC requires the computation of a TE LSP where the head- 138 end and the tail-end of the TE LSP do not reside in adjacent domains 139 and there is no single PCE with the visibility of both the head-end 140 and tail-end domain. We call the set of PCEs involved in the 141 computation of a TE LSP a "path computation chain". As further 142 discussed in Section 3.1, the path computation chain may either be 143 static (pre-configured) or dynamically determined during the path 144 computation process. 146 As discussed in [RFC4655], a TE LSP may be computed by one PCE 147 (referred to as single PCE path computation) or several PCEs 148 (referred to as multiple PCE path computation). In the former case, 149 the PCC may be able to use IGP extensions to check the liveness of 150 the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive 151 messages. In contrast, when multiple PCEs are involved in the path 152 computation chain an example of which is the Backward Recursive PCE- 153 based Computation (BRPC) procedure defined in [RFC5441], the PCC's 154 visibility may be limited to the first PCE involved in the path 155 computation chain. Thus, it is critical to define mechanisms in 156 order to monitor the state of the path computation chain. 158 This document specifies PCEP extensions in order to gather various 159 state metrics along the path computation chain. In this document we 160 call a "state metric" a metric that characterizes a PCE state. For 161 example, such metric can have a form of a boolean (PCE is alive or 162 not, PCE is congested or not) or a performance metric (path 163 computation time at each PCE). 165 PCE state metrics can be gathered in two different contexts: in band 166 or out of band. By "in band" we refer to the situation whereby a PCC 167 requests to gather metrics in the context of a path computation 168 request. For example, a PCC may send a path computation request to a 169 PCE and may want to know the processing time of that request in 170 addition to the computed path. Conversely, if the request is "out of 171 band", PCE state metric collection is performed as a standalone 172 request (e.g., check the liveness of a specific path computation 173 chain, collect the average processing time computed over the last 5mn 174 period on one or more PCEs"). 176 In this document we define two monitoring request types: general and 177 specific. A general monitoring request relates to the collection of 178 a PCE state metrics that is not coupled to a particular path 179 computation request (e.g., average CPU load on a PCE). Conversely, a 180 specific monitoring request relates to a particular path computation 181 request (processing time to complete the path computation for a TE 182 LSP). 184 This document specifies procedures and extensions to the Path 185 Computation Element Protocol (PCEP) ([RFC5440]), including new 186 objects and new PCEP messages, in order to monitor the path 187 computation chain and gather various performance metrics. 189 The message formats in this document are specified using Backus Naur 190 Format (BNF) encoding as specified in [RFC5511]. 192 1.1. Requirements Language 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in RFC 2119 [RFC2119]. 198 2. Terminology 200 PCC (Path Computation Client): any client application requesting a 201 path computation to be performed by a Path Computation Element. 203 PCE (Path Computation Element): an entity (component, application or 204 network node) that is capable of computing a network path or route 205 based on a network graph and applying computational constraints. 207 TE LSP: Traffic Engineering Label Switched Path. 209 3. Path Computation Monitoring messages 211 As defined in [RFC5440], a PCEP message consists of a common header 212 followed by a variable length body made of a set of objects that can 213 either be mandatory or optional. As a reminder, an object is said to 214 be mandatory in a PCEP message when the object must be included for 215 the message to be considered as valid. The P flag (defined in 216 [RFC5440]) is located in the common header of each PCEP object and 217 can be set by a PCEP peer to require a PCE to take into account the 218 related information during the path computation. Because the P flag 219 exclusively relates to a path computation request, it MUST be cleared 220 in the two PCEP messages (PCMonReq and PCMonRep message) defined in 221 this document. 223 For each PCEP message type a set of rules is defined that specify the 224 set of objects that the message can carry. An implementation MUST 225 form the PCEP messages using the object ordering specified in this 226 document. 228 In this document we define two PCEP messages referred to as the Path 229 Computation Monitoring Request (PCMonReq) and Path Computation 230 Monitoring Reply (PCMonRep) messages so as to handle "out of band" 231 monitoring request. The aim of the PCMonReq message sent by a PCC to 232 a PCE is to gather one or more PCE state metrics on a set of PCEs 233 involved in a path computation chain. The PCMonRep message sent by a 234 PCE to a PCC is used to provide such data. 236 3.1. Path Computation Monitoring Request message (PCMonReq) 238 The Message-Type field of the PCEP common header for the PCMonReq 239 message is set to 8 (To be confirmed by IANA). 241 There is one mandatory object that MUST be included within a PCMonReq 242 message: the MONITORING object (see section Section 4.1). If the 243 MONITORING object is missing, the receiving PCE MUST send a PCErr 244 message with Error-type=6 (Mandatory Object missing) and Error- 245 value=4 (MONITORING Object missing). Other objects are optional. 247 Format of a PCMonReq message (out of band request): 248 ::= 249 250 251 [] 252 [] 253 [] 254 where: 256 ::=[] 258 ::= 259 [] 260 [] 262 ::=[] 264 ::= 265 266 [] 267 [] 268 [] 269 [] 270 [] 271 [] 272 [] 274 ::=[] 275 Format of a PCReq message with monitoring data requested (in band 276 request): 277 ::= 278 279 280 [] 281 [] 282 284 where: 285 ::=[] 287 ::=[] 289 ::=[] 291 ::= 292 293 [] 294 [] 295 [] 296 [[]] 297 [] 298 [] 299 where: 301 ::=[] 303 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 304 BALANCING objects are defined in [RFC5440]. The XRO object is 305 defined in [RFC5521] and the OF object is defined in [RFC5541]. The 306 PCC-ID-REQ object is defined in Section 4.2. 308 The PCMonReq message is used to gather various PCE state metrics 309 along a path computation chain. The path computation chain may be 310 determined by the PCC (in the form of a series of a series of PCE-ID 311 objects defined in Section 4.3.) according to policy specified on the 312 PCC or may alternatively be determined by the path computation 313 procedure. For example, if the BRPC procedure ([RFC5441]) is used to 314 compute an inter-domain TE LSP, the path computation chain may be 315 determined dynamically. In that case, the PCC sends a PCMonReq 316 message that contains the PCEP objects that characterize the TE LSP 317 attributes along with the MONITORING object (see Section 4.1) that 318 lists the set of metrics of interest. if a list of PCE is present in 319 the monitoring request, it takes precedence over mechanisms used to 320 dynamicaly determine the path computation chain. If a PCE receives a 321 monitoring request that specifies a next hop PCE in the PCE list that 322 is unreachable, the request MUST be silently discarded. 324 Several PCE state metrics may be requested that are specified by a 325 set of objects defined in Section 4. Note that this set of objects 326 may be extended in the future. 328 As pointed out in [RFC5440] several situations can arise: 330 o Bundle of a set of independent and non-synchronized path 331 computation requests, 333 o Bundle of a set of independent and synchronized path computation 334 requests (SVEC object defined below required), 336 o Bundle of a set of dependent and synchronized path computation 337 requests (SVEC object defined below required). 339 In the case of a bundle of a set of request, the MONITORING object 340 SHOULD only be present in the first PCReq or PCMonReq message and the 341 monitoring request applies to all the requests of the bundle, even in 342 the case of dependent and/or synchronized requests sent using more 343 than one PCReq or PCMonReq message. 345 Examples of requests. For the sake of illustration, consider the 346 three following examples: 348 Example 1 (out of band request): PCC1 requests to check the path 349 computation chain that would be used should it request a path 350 computation for a specific TE LSP named T1. A PCMonReq message is 351 sent that contains a MONITORING object specifying a path computation 352 check, along with the appropriate set of objects (e.g., RP, END- 353 POINTS, ...) that would be included in a PCReq message for T1. 355 Example 2 (in band request): PCC1 requests a path computation for a 356 TE LSP and also request to gather the processing time along the path 357 computation chain selected for the computation of T1. A PCReq 358 message is sent that also contains a MONITORING object that specifies 359 the performance metrics of interest. 361 Example 3 (out of band request): PCC2 requests to gather performance 362 metrics along the specific path computation chain . A PCMonReq message is sent to PCE1 that contains a MONITORING 364 object and a sequence of PCE-ID objects that identify PCE1, PCE2, 365 PCE3 and PCE7 respectively. 367 In all of the examples above, a PCRep message (in-band request) or 368 PCMonReq message (out of band request) is sent in response to the 369 request that reports the computed metrics. 371 3.2. Path Monitoring Reply message (PCMonRep) 373 The PCMonRep message is used to provide PCE state metrics back to the 374 requester for "out of band" monitoring requests. The Message-Type 375 field of the PCEP common header for the PCMonRep message is set to 9 376 (To be confirmed by IANA). 378 There is one mandatory object that MUST be included within a PCMonRep 379 message: the MONITORING object (see Section 4.1). If the MONITORING 380 object is missing, the receiving PCE MUST send a PCErr message with 381 Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING 382 Object missing). 384 Other objects are optional. 386 Format of a PCMonRep (out of band request): 387 ::= 388 389 390 [] 391 [] 393 where: 395 ::=[] 397 ::= 398 [] 399 [] 401 Format of a PCRep message with monitoring data (in band): 402 ::= 403 405 where: 406 ::=[] 408 ::= 409 410 411 [] 412 [] 413 [] 414 [] 416 ::=[] 418 ::= 420 where: 422 ::=[] 423 [] 424 [] 425 [] 427 ::=[] 429 ::=[] 431 ::= 432 [] 433 [] 435 The RP and the NO-PATH objects are defined in [RFC5440]. The PCC-ID- 436 REQ object is defined in Section 4.2. 438 If the path computation chain has been statically specified in the 439 corresponding monitoring request using the series of a series of 440 PCE-ID objects defined in Section 4.3 the monitoring request MUST use 441 the same path computation chain (using the pce-list but in the 442 reverse order). 444 4. Path Computation Monitoring Objects 446 The PCEP objects defined in the document are compliant with the PCEP 447 object format defined in [RFC5440]. The P flag and the I flag of the 448 PCEP objects defined in this document SHOULD always be set to 0 on 449 transmission and MUST be ignored on receipt since these flags are 450 exclusively related to path computation requests. 452 Several objects are defined in this section that can be carried 453 within the PCEP PCReq or PCRep messages defined in [RFC5440] in case 454 of "in band" monitoring requests (the PCC requests the computation of 455 the TE LSP in addition to gathering PCE state metrics). In case of 456 "out of band" monitoring requests, the objects defined in this 457 section are carried within PCMonReq and PCMonRep messages. 459 All TLVs carried in objects defined in this document have the TLV 460 format defined in [RFC5440] 462 o Type: 2 bytes 464 o Length: 2 bytes 466 o Value: variable 468 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 469 specifying the TLV length, and a value field. The Length field 470 defines the length of the value portion in bytes. The TLV is padded 471 to 4-bytes alignment; padding is not included in the Length field (so 472 a 3-byte value would have a length of 3, but the total size of the 473 TLV would be 8 bytes). Unrecognized TLVs MUST be ignored. 475 4.1. MONITORING Object 477 The MONITORING object MUST be present within PCMonReq and PCMonRep 478 messages ("out of band" monitoring requests) and MAY be carried 479 within PCRep and PCReq messages ("in band" monitoring requests). 480 There SHOULD NOT be more than one instance of the MONITORING object 481 in a PCMonReq or PCMonRep message: if more than one instance of the 482 MONITORING object is present, the recipient MUST process the first 483 instance and MUST ignore other instances. 485 The MONITORING object is used to specify the set of requested PCE 486 state metrics. 488 The MONITORING Object-Class is to be assigned by IANA (recommended 489 value=19) 491 The MONITORING Object-Type is to be assigned by IANA (recommended 492 value=1) 494 The format of the MONITORING object body is as follows: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Reserved | Flags |I|C|P|G|L| 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Monitoring-id-number | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | | 503 // Optional TLV(s) // 504 | | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Flags: 24 bits 509 The following flags are currently defined: 511 L (Liveness) - 1 bit: when set, this indicates that the state metric 512 of interest is the PCE's liveness and thus the PCE MUST include a 513 PCE-ID object in the corresponding reply. The L bit MUST always be 514 ignored in a PCMonRep or PCRep message. 516 G (General) - 1 bit: when set, this indicates that the monitoring 517 request is a general monitoring request. When the requested 518 performance metric is specific, the G bit MUST be cleared. The G bit 519 MUST always be ignored in a PCMonRep or PCRep message. 521 P (Processing Time) - 1 bit: the P bit of the MONITORING object 522 carried in a PCMonReq or a PCReq message is set to indicate that the 523 processing times is a metric of interest. If allowed by policy, a 524 PROC-TIME object MUST be inserted in the corresponding PCMonRep or 525 PCRep message. The P bit MUST always be ignored in a PCMonRep or 526 PCRep message. 528 C (Overload) - 1 bit: The C bit of the MONITORING object carried in a 529 PCMonReq or a PCReq message is set to indicate that the overload 530 status is a metric of interest, in which case a OVERLOAD object MUST 531 be inserted in the corresponding PCMonRep or PCRep message. The C 532 bit MUST always be ignored in a PCMonRep or PCRep message. 534 I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message 535 and that message does not trigger any policy violation, but the PCE 536 cannot provide any of the set of requested performance metrics for 537 unspecified reasons, the PCE MUST set the I bit. The I bit has no 538 meaning in a request and SHOULD be ignored on receipt. 540 Monitoring-id-number (32 bits): The monitoring-id-number value 541 combined with the PCC-REQ-ID identifying the requesting PCC uniquely 542 identifies the monitoring request context. The monitoring-id-number 543 MUST start at a non-zero value and MUST be incremented each time a 544 new monitoring request is sent to a PCE. Each increment SHOULD have 545 a value of 1 and may cause a wrap back to zero. If no reply to a 546 monitoring request is received from the PCE, and the PCC wishes to 547 resend its path computation monitoring request, the same monitoring- 548 id-number MUST be used. Conversely, a different monitoring-id-number 549 MUST be used for different requests sent to a PCE. A PCEP 550 implementation SHOULD checkpoint the Monitoring-id-number of pending 551 monitoring requests in case of restart thus avoiding the re-use of a 552 Monitoring-id-number of an in-process monitoring request. 554 Unassigned bits are considered as reserved and MUST be set to zero on 555 transmission and ignored on reception. 557 No optional TLVs are currently defined. 559 4.2. PCC-ID-REQ Object 561 The PCC-ID-REQ Object is used to specify the IP address of the 562 requesting PCC. 564 The PCC-ID-REQ MUST be inserted within a PCReq or a PCMonReq message 565 to specify the IP address of the requesting PCC. 567 Two PCC-ID-REQ objects (for IPv4 and IPv6) are defined. PCC-ID-REQ 568 Object-Class is to be assigned by IANA (recommended value=20) PCC-ID- 569 REQ Object-Type is to be assigned by IANA (recommended value=1 for 570 IPv4 and 2 for IPv6) 572 The format of the PCE-ID-REQ Object is as follows: 574 The format of the PCC-ID-REQ object body for IPv4 and IPv6 are as 575 follows: 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | IPv4 Address | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | | 587 | IPv6 Address | 588 | | 589 | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 The PCC-ID-REQ object body has a fixed length of 4 octets for IPv4 592 and 16 octets for IPv6. 594 4.3. PCE-ID Object 596 The PCE-ID Object is used to specify a PCE's IP address. The PCE-ID 597 object can either be used to specifyt the list of PCE for which 598 monitoring data is requested and to specify the IP address of the 599 requesting PCC. 601 A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq 602 message to specify the PCE for which PCE state metrics are requested 603 and in a PCMonRep or a PCRep message to record the IP address of the 604 PCE reporting PCE state metrics or that was involved in the path 605 computation chain. 607 Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- 608 Class is to be assigned by IANA (recommended value=21) PCE-ID Object- 609 Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 610 for IPv6) 612 The format of the PCE-ID Object is as follows: 614 The format of the PCE-ID object body for IPv4 and IPv6 are as 615 follows: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | IPv4 Address | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | | 627 | IPv6 Address | 628 | | 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 632 octets for IPv6. 634 When a dynamic discovery mechanism is used for PCE discovery, a PCE 635 advertises its PCE address in the PCE-ADDRESS sub-TLV defined in 636 [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and 637 PCMonReq messages and a PCE MUST also use this address in PCRep and 638 PCMonRep messages. 640 4.4. PROC-TIME Object 642 If allowed by policy, the PCE includes a PROC-TIME object within a 643 PCMonRep or a PCRep message if the P bit of the MONITORING object 644 carried within the corresponding PCMonReq or PCReq message is set. 645 The PROC-TIME object is used to report various processing time 646 related metrics. 648 1) Case of general monitoring requests 650 A PCC may request processing time metrics for general monitoring 651 requests (e.g., the PCC may want to know the minimum, maximum and 652 average processing times on a particular PCE). In this case, general 653 requests can only be made by using PCMonReq/PCMonRep messages. The 654 Current-processing-time field (as explained below) is exclusively 655 used for specific monitoring requests and MUST be cleared for general 656 monitoring requests. The algorithms used by a PCE to compute the 657 minimum, maximum, average and variance of the processing times are 658 out of the scope of this document (A PCE may decide to compute the 659 minimum processing time over a period of times, for the last N path 660 computation requests, ...). 662 2) Case of specific monitoring requests 664 In the case of a specific request, the algorithms used by a PCE to 665 compute the Processing-time metrics are out of the scope of this 666 document but a flag is specified that is used to indicate to the 667 requester whether the processing time value was estimated or 668 computed. The PCE may either (1) estimate the processing time 669 without performing an actual path computation or (2) effectively 670 perform the computation to report the processing time. In the former 671 case, the E bit of the PROC-TIME object MUST be set. The G bit MUST 672 be cleared and the Min-processing-time, Max-processing-time, Average- 673 processing-time and Variance-processing-time MUST be set to 674 0x00000000. 676 When the processing time is requested in addition to a path 677 computation (case where the MONITORING object is carried within a 678 PCReq message), the PROC-TIME object always reports the actual 679 processing time for that request and thus the E bit MUST be cleared. 681 The PROC-TIME Object-Class is to be assigned by IANA (recommended 682 value=22) 684 The PROC-TIME Object-Type is to be assigned by IANA (recommended 685 value=1) 687 The format of the PROC-TIME object body is as follows: 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Reserved | Flags |E| 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Current-processing-time | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Min-processing-time | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Max-processing-time | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Average-processing time | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Variance-processing-time | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Flags: 16 bits - one flag is currently defined: 706 E (Estimated) - 1 bit: when set, this indicates that the reported 707 metric value is based on estimated processing time as opposed to 708 actual computations. 710 Unassigned bits are considered as reserved and MUST be set to zero on 711 transmission. 713 Current-processing-time: This field indicates in milliseconds the 714 processing time for the path computation of interest characterized in 715 the corresponding PCMonReq message. 717 Min-processing-time: This field indicates in milliseconds the minimum 718 processing time. 720 Max-processing-time: This field indicates in milliseconds the maximum 721 processing time. 723 Average-processing-time: This field indicates in milliseconds the 724 average processing time. 726 Variance-processing-time: This field indicates in milliseconds the 727 variance of the processing times. 729 Since PCC may potentially use monitoring metrics as input to their 730 PCE selection, it MAY be required to normalize how time metrics 731 (along with others metrics described in further revision of this 732 document) are computed to ensure consistency between the monitoring 733 metrics computed by a set of PCEs. 735 4.5. OVERLOAD Object 737 The OVERLOAD object is used to report a PCE processing congestion 738 state. Note that "overload" as indicated by this object refers to 739 the processing state of the PCE and its ability to handle new PCEP 740 requests. A PCE is overloaded when it has a backlog of PCEP requests 741 such that it cannot immediately start to process a new request thus 742 leading to waiting times. The overload duration is quantified as 743 being the (estimated) time until the PCE expects to be able to 744 immediately process a new PCEP request. 746 The OVERLOAD object MUST be present within a PCMonRep or a PCRep 747 message if the C bit of the MONITORING object carried within the 748 corresponding PCMonReq or PCReq message is set and the PCE is 749 experiencing a congested state. The OVERLOAD Object-Class is to be 750 assigned by IANA (recommended value=23). The OVERLOAD Object-Type is 751 to be assigned by IANA (recommended value=1) 752 The format of the CONGESTION object body is as follows: 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Flags | Reserved | Overload Duration | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Flags: 8 bits - No flag is currently defined. 761 Overload duration - 16 bits: This field indicates in the amount of 762 time in seconds that the responding PCE expects that it may continue 763 to be overloaded from the time that the response message was 764 generated. The receiver MAY use this value to decide whether or not 765 so send further requests to the same PCE. 767 It is worth noting that a PCE along a path computation chain involved 768 in the monitoring request may decide to learn from the overload 769 information received by one of downstream PCE in the chain. 771 5. Policy 773 The receipt of a PCMonReq message may trigger a policy violation on 774 some PCE in which case the PCE MUST send a PCErr message with Error- 775 Type=5 and Error-value=3 (To be Confirmed by IANA). 777 6. Elements of Procedure 779 I bit processing: as indicated in section Section 4.1, if a PCE 780 supports a received PCMonReq message and that message does not 781 trigger any policy violation, but the PCE cannot provide any of the 782 set of requested performance metrics for unspecified reasons, the PCE 783 MUST set the I bit. Once set, the I bit MUST NOT be changed by a 784 receiving PCE. 786 Upon receiving a PCMonReq message: 788 1) As specified in [RFC5440], if the PCE does not support the 789 PCMonReq message, the PCE peer MUST send a PCErr message with Error- 790 value=2 (capability not supported). According to the procedure 791 defined in section 6.9 of [RFC5440], if a PCC/PCE receives 792 unrecognized messages at a rate equal of greater than specified rate, 793 the PCC/PCE must send a PCEP CLOSE message with close value=5 794 "Reception of an unacceptable number of unrecognized PCEP messages". 795 In this case, the PCC/PCE must also close the TCP session and must 796 not send any further PCEP messages on the PCEP session. 798 2) If the PCE supports the PCMonReq message but the monitoring 799 request is prohibited by policy, the PCE must follow the procedure 800 specified in section 5. As pointed out in section 4.3, a PCE may 801 still partially satisfy a request, leaving out some of the required 802 data if not allowed by policy. 804 3) If the PCE supports the PCMonReq and the monitoring request is not 805 prohibited by policy, the receiving PCE MUST first determine whether 806 it is the last PCE of the path computation chain. If the PCE is not 807 the last element of the path computation chain, the PCMonReq message 808 is relayed to the next hop PCE: such next hop may either be specified 809 by means of a PCE-ID object present in the PCMonReq message or 810 dynamically determined by means of a procedure outside of the scope 811 of this document. Conversely, if the PCE is the last PCE of the path 812 computation chain, the PCE originates a PCMonRep message that 813 contains the requested objects according to the set of requested PCE 814 states metrics listed in the MONITORING object carried in the 815 corresponding PCMonReq message. 817 Upon receiving a PCReq message that carries a MONITORING and 818 potentially other monitoring objects (e.g., PCE-ID object): 820 1) As specified in [RFC5440], if the PCE does not support (in band) 821 monitoring, the PCE peer MUST send a PCErr message with Error-value=2 822 (capability not supported). According to the procedure defined in 823 section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages 824 at a rate equal of greater than specified rate, the PCC/PCE must send 825 a PCEP CLOSE message with close value=5 "Reception of an unacceptable 826 number of unrecognized PCEP messages". In this case, the PCC/PCE 827 must also close the TCP session and must not send any further PCEP 828 messages on the PCEP session. 830 2) If the PCE supports the monitoring request but the monitoring 831 request is prohibited by policy, the PCE must follow the procedure 832 specified in section 5. As pointed out in section 4.3, a PCE may 833 still partially satisfy a request, leaving out some of the required 834 data if not allowed by policy. 836 3) If the PCE supports the monitoring request and that request is not 837 prohibited by policy, the receiving PCE MUST first determine whether 838 it is the last PCE of the path computation chain. If the PCE is not 839 the last element of the path computation chain, the PCReq message 840 (with the MONITORING object and potentially other monitoring objects 841 such as the PCE-ID) is relayed to the next hop PCE: such next hop may 842 either be specified by means of a PCE-ID object present in the PCReq 843 message or dynamically determined by means of a procedure outside of 844 the scope of this document. Conversely, if the PCE is the last PCE 845 of the path computation chain, the PCE originates a PCRep message 846 that contains the requested objects according to the set of requested 847 PCE states metrics listed in the MONITORING and potentially other 848 monitoring objects carried in the corresponding PCReq message. 850 Upon receiving a PCMonRep message, the PCE processes the request, 851 adds the relevant objects to the PCMonRep message and forwards the 852 PCMonRep message to the upstream requesting PCE or PCC. 854 Upon receiving a PCRep message that carries monitoring data, the 855 message is processed, additional monitoring data is added according 856 to this specification and the message is forwarded upstream to the 857 requesting PCE or PCC. 859 7. Manageability Considerations 861 7.1. Control of Function and Policy 863 It MUST be possible to configure the activation/deactivation of PCEP 864 monitoring on a PCEP speaker. In addition to the parameters already 865 listed in section 8.1 of [RFC5440], a PCEP implementation SHOULD 866 allow configuring on a PCE whether specific, generic, in band and out 867 of band monitoring requests are allowed or not. Also a PCEP 868 implementation SHOULD allow configuring on a PCE a list of authorized 869 state metrics (aliveness, overload, processing time, etc). This may 870 apply to any session the PCEP speaker participates in, to a specific 871 session with a given PCEP peer or to a specific group of sessions 872 with a specific group of PCEP peers, for instance the PCEP peers of a 873 neighbor AS. 875 7.2. Information and Data Models 877 A new MIB Module may be defined that provides local PCE state 878 metrics, as well as state metrics of other PCEs gathered using 879 mechanisms defined in this document. 881 7.3. Liveness Detection and Monitoring 883 This document provides mechanisms to monitor the liveliness and 884 performances of a given path computation chain. 886 7.4. Verify Correct Operations 888 Mechanisms defined in this document do not imply any new operation 889 verification requirements in addition to those already listed in 890 [RFC5440]. 892 7.5. Requirements On Other Protocols 894 Mechanisms defined in this document do not imply any requirements on 895 other protocols in addition to those already listed in [RFC5440]. 897 7.6. Impact On Network Operations 899 The frequency of PCMonReq messages may impact the operations of PCEs. 900 An implementation SHOULD allow a limit to be placed on the rate of 901 PCMonReq messages sent by a PCEP speaker and processed from a peer. 902 It SHOULD also allow sending a notification when a rate threshold is 903 reached. An implementation SHOULD allow handling PCReq messages with 904 a higher priority than PCMonReq messages. An implementation SHOULD 905 allow the configuration of a second limit for the PCReq message 906 requesting monitoring data. 908 8. IANA Considerations 910 8.1. New PCEP Message 912 Each PCEP message has a message type value. 914 Two new PCEP (specified in [RFC5440]) messages are defined in this 915 document: 917 Value Description Reference 918 8 Path Computation Monitoring Request (PCMonReq) This document 919 9 Path Computation Monitoring Reply (PCMonRep) This document 921 8.2. New PCEP Objects 923 Each PCEP object has an Object-Class and an Object-Type. The 924 following new PCEP objects are defined in this document: 926 Object-Class Value Name Object-Type Reference 928 19 MONITORING 1 This document 930 20 PCC-REQ-ID 1: IPv4 addresses This document 931 2: IPv6 addresses 933 21 PCE-ID 1: IPv4 addresses This document 934 2: IPv6 addresses This document 936 22 PROC-TIME 1 This document 938 23 OVERLOAD 1 This document 940 8.3. New Error-Values 942 A registry was created for the Error-type and Error-value of the PCEP 943 Error Object. 945 A new Error-value for the PCErr message Error-types=5 (Policy 946 Violation) (see [RFC5440]) is defined in this document (Error-value 947 to be assigned by IANA). 949 Error-Type Meaning Error-value Reference 950 5 Policy violation 3 This document 951 Monitoring message supported 952 but rejected due to 953 policy violation 955 A new Error-value for the PCErr message Error-types=6 (Mandatory 956 Object missing) (see [RFC5440]) is defined in this document (Error- 957 Type and Error-value to be assigned by IANA). 959 Error-type Meaning Error-value Reference 960 6 Mandatory Object missing 4 This document 961 MONITORING Object missing 963 8.4. MONITORING Object Flag Field 965 IANA is requested to create a registry to manage the Flag field of 966 the MONITORING object. 968 New bit numbers may be allocated only by an IETF review. Each bit 969 should be tracked with the following qualities: 971 o Bit number (counting from bit 0 as the most significant bit) 972 o Capability Description 974 o Defining RFC 976 Several bits are defined for the MONITORING Object flag field in this 977 document: 979 Codespace of the Flag field (MONITORING Object) 980 Bit Description Reference 981 0-18 Unassigned 982 19 Incomplete This document 983 20 Overload This document 984 21 Processing Time This document 985 22 General This document 986 23 Liveness This document 988 8.5. PROC-TIME Object Flag Field 990 IANA is requested to create a registry to manage the Flag field of 991 the PROC-TIME object. 993 New bit numbers may be allocated only by an IETF review. Each bit 994 should be tracked with the following qualities: 996 o Bit number (counting from bit 0 as the most significant bit) 998 o Capability Description 1000 o Defining RFC 1002 One bit is defined for the PROC-TIME Object flag field in this 1003 document: 1005 Codespace of the Flag field (PROC-TIME Object) 1006 Bit Description Reference 1007 0-14 Unassigned 1008 15 Estimated This document 1010 8.6. OVERLOAD Object Flag field 1012 IANA is requested to create a registry to manage the Flag field of 1013 the OVERLOAD object. 1015 New bit numbers may be allocated only by an IETF review. Each bit 1016 should be tracked with the following qualities: 1018 o Bit number (counting from bit 0 as the most significant bit) 1020 o Capability Description 1022 o Defining RFC 1024 No Flag are currently defined for the OVERLOAD Object flag field in 1025 this document. 1027 Codespace of the Flag field (OVERLOAD Object) 1028 Bit Description Reference 1029 0-7 Unassigned 1031 9. Security Considerations 1033 The use of monitoring data can be used for various attacks such as 1034 denial of service attacks (for example by setting the C bit and 1035 overload duration field of the OVERLOAD object to stop PCCs from 1036 using a PCE). Thus it is recommended to make use of the security 1037 mechanisms discussed in [RFC5440] to secure a PCEP session 1038 (authenticity, integrity, privacy, DoS protection, etc) to secure the 1039 PCMonReq, PCMonRep messages and PCE state metric objects defined in 1040 this document. An implementation SHOULD allow limiting the rate at 1041 which PCMonReq or PCReq messages carrying monitoring requests 1042 received from a specific peer are processed (input shaping) as 1043 discussed in section 10.7.2 of [RFC5440], or from another domain (see 1044 also section 7.6). 1046 10. Acknowledgments 1048 The authors would like to thank Eiji Oki, Mach Chen, Fabien 1049 Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful 1050 comments. Special thank to Adrian Farrel for his detailed review. 1052 11. References 1054 11.1. Normative References 1056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", BCP 14, RFC 2119, March 1997. 1059 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1060 (PCE) Communication Protocol (PCEP)", RFC 5440, 1061 March 2009. 1063 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1064 Used to Form Encoding Rules in Various Routing Protocol 1065 Specifications", RFC 5511, April 2009. 1067 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1068 Path Computation Element Communication Protocol (PCEP) for 1069 Route Exclusions", RFC 5521, April 2009. 1071 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1072 Objective Functions in the Path Computation Element 1073 Communication Protocol (PCEP)", RFC 5541, June 2009. 1075 11.2. Informative References 1077 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1078 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1080 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1081 "OSPF Protocol Extensions for Path Computation Element 1082 (PCE) Discovery", RFC 5088, January 2008. 1084 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1085 "IS-IS Protocol Extensions for Path Computation Element 1086 (PCE) Discovery", RFC 5089, January 2008. 1088 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 1089 Backward-Recursive PCE-Based Computation (BRPC) Procedure 1090 to Compute Shortest Constrained Inter-Domain Traffic 1091 Engineering Label Switched Paths", RFC 5441, April 2009. 1093 Authors' Addresses 1095 JP Vasseur (editor) 1096 Cisco Systems, Inc 1097 1414 Massachusetts Avenue 1098 Boxborough, MA 01719 1099 USA 1101 Email: jpv@cisco.com 1102 JL Le Roux 1103 France Telecom 1104 2, Avenue Pierre-Marzin 1105 Lannion, 22307 1106 FRANCE 1108 Email: jeanlouis.leroux@orange-ftgroup.com 1110 Yuichi Ikejiri 1111 NTT Communications Corporation 1112 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1113 Tokyo, 100-8019 1114 Japan 1116 Email: : y.ikejiri@ntt.com