idnits 2.17.1 draft-ietf-pce-monitoring-09.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 (March 21, 2010) is 5112 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: September 22, 2010 France Telecom 5 Y. Ikejiri 6 NTT Communications Corporation 7 March 21, 2010 9 A set of monitoring tools for Path Computation Element based 10 Architecture 11 draft-ietf-pce-monitoring-09.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 September 22, 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. Guidelines to Avoid Overload Thrashing . . . . . . . . . . . . 22 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 98 9.1. New PCEP Message . . . . . . . . . . . . . . . . . . . . . 23 99 9.2. New PCEP Objects . . . . . . . . . . . . . . . . . . . . . 23 100 9.3. New Error-Values . . . . . . . . . . . . . . . . . . . . . 24 101 9.4. MONITORING Object Flag Field . . . . . . . . . . . . . . . 24 102 9.5. PROC-TIME Object Flag Field . . . . . . . . . . . . . . . 25 103 9.6. OVERLOAD Object Flag field . . . . . . . . . . . . . . . . 25 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 105 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 107 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 108 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 111 1. Introduction 113 The Path Computation Element (PCE) based architecture has been 114 specified in [RFC4655] for the computation of Traffic Engineering 115 (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching 116 (MPLS) and Generalized MPLS (GMPLS) networks in the context of single 117 or multiple domains where a domain refers to a collection of network 118 elements within a common sphere of address management or path 119 computational responsibility such Interior Gateway Protocol (IGP) 120 areas and Autonomous Systems. 122 Path Computation Clients (PCCs) send computation requests to PCEs 123 using PCReq messages, and these may forward the requests to and 124 cooperate with other PCEs forming a "path computation chain". In 125 case of succesful path computation the computed paths are then 126 provided to the requesting PCC using PCRep messages. The PCReq and 127 PCRep messages are defined in [RFC5440]. 129 In PCE-based environments, it is critical to monitor the state of the 130 path computation chain for troubleshooting and performance monitoring 131 purposes: liveness of each element (PCE) involved in the PCE chain, 132 detection of potential resource contention states and statistics in 133 term of path computation times are examples of such metrics of 134 interest. 136 As defined in [RFC4655], there are circumstances where more than one 137 PCE are involved in the computation of a TE LSP. A typical example 138 is when the PCC requires the computation of a TE LSP where the head- 139 end and the tail-end of the TE LSP do not reside in adjacent domains 140 and there is no single PCE with the visibility of both the head-end 141 and tail-end domain. We call the set of PCEs involved in the 142 computation of a TE LSP a "path computation chain". As further 143 discussed in Section 3.1, the path computation chain may either be 144 static (pre-configured) or dynamically determined during the path 145 computation process. 147 As discussed in [RFC4655], a TE LSP may be computed by one PCE 148 (referred to as single PCE path computation) or several PCEs 149 (referred to as multiple PCE path computation). In the former case, 150 the PCC may be able to use IGP extensions to check the liveness of 151 the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive 152 messages. In contrast, when multiple PCEs are involved in the path 153 computation chain an example of which is the Backward Recursive PCE- 154 based Computation (BRPC) procedure defined in [RFC5441], the PCC's 155 visibility may be limited to the first PCE involved in the path 156 computation chain. Thus, it is critical to define mechanisms in 157 order to monitor the state of the path computation chain. 159 This document specifies PCEP extensions in order to gather various 160 state metrics along the path computation chain. In this document we 161 call a "state metric" a metric that characterizes a PCE state. For 162 example, such metric can have a form of a boolean (PCE is alive or 163 not, PCE is congested or not) or a performance metric (path 164 computation time at each PCE). 166 PCE state metrics can be gathered in two different contexts: in band 167 or out of band. By "in band" we refer to the situation whereby a PCC 168 requests to gather metrics in the context of a path computation 169 request. For example, a PCC may send a path computation request to a 170 PCE and may want to know the processing time of that request in 171 addition to the computed path. Conversely, if the request is "out of 172 band", PCE state metric collection is performed as a standalone 173 request (e.g., check the liveness of a specific path computation 174 chain, collect the average processing time computed over the last 5mn 175 period on one or more PCEs"). 177 In this document we define two monitoring request types: general and 178 specific. A general monitoring request relates to the collection of 179 a PCE state metrics that is not coupled to a particular path 180 computation request (e.g., average CPU load on a PCE). Conversely, a 181 specific monitoring request relates to a particular path computation 182 request (processing time to complete the path computation for a TE 183 LSP). 185 This document specifies procedures and extensions to the Path 186 Computation Element Protocol (PCEP) ([RFC5440]), including new 187 objects and new PCEP messages, in order to monitor the path 188 computation chain and gather various performance metrics. 190 The message formats in this document are specified using Backus Naur 191 Format (BNF) encoding as specified in [RFC5511]. 193 1.1. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in RFC 2119 [RFC2119]. 199 2. Terminology 201 PCC (Path Computation Client): any client application requesting a 202 path computation to be performed by a Path Computation Element. 204 PCE (Path Computation Element): an entity (component, application or 205 network node) that is capable of computing a network path or route 206 based on a network graph and applying computational constraints. 208 TE LSP: Traffic Engineering Label Switched Path. 210 3. Path Computation Monitoring messages 212 As defined in [RFC5440], a PCEP message consists of a common header 213 followed by a variable length body made of a set of objects that can 214 either be mandatory or optional. As a reminder, an object is said to 215 be mandatory in a PCEP message when the object must be included for 216 the message to be considered as valid. The P flag (defined in 217 [RFC5440]) is located in the common header of each PCEP object and 218 can be set by a PCEP peer to require a PCE to take into account the 219 related information during the path computation. Because the P flag 220 exclusively relates to a path computation request, it MUST be cleared 221 in the two PCEP messages (PCMonReq and PCMonRep message) defined in 222 this document. 224 For each PCEP message type a set of rules is defined that specify the 225 set of objects that the message can carry. An implementation MUST 226 form the PCEP messages using the object ordering specified in this 227 document. 229 In this document we define two PCEP messages referred to as the Path 230 Computation Monitoring Request (PCMonReq) and Path Computation 231 Monitoring Reply (PCMonRep) messages so as to handle "out of band" 232 monitoring request. The aim of the PCMonReq message sent by a PCC to 233 a PCE is to gather one or more PCE state metrics on a set of PCEs 234 involved in a path computation chain. The PCMonRep message sent by a 235 PCE to a PCC is used to provide such data. 237 3.1. Path Computation Monitoring Request message (PCMonReq) 239 The Message-Type field of the PCEP common header for the PCMonReq 240 message is set to 8 (To be confirmed by IANA). 242 There is one mandatory object that MUST be included within a PCMonReq 243 message: the MONITORING object (see section Section 4.1). If the 244 MONITORING object is missing, the receiving PCE MUST send a PCErr 245 message with Error-type=6 (Mandatory Object missing) and Error- 246 value=4 (MONITORING Object missing). Other objects are optional. 248 Format of a PCMonReq message (out of band request): 249 ::= 250 251 252 [] 253 [] 254 [] 255 where: 257 ::=[] 259 ::= 260 [] 261 [] 263 ::=[] 265 ::= 266 267 [] 268 [] 269 [] 270 [] 271 [] 272 [] 273 [] 275 ::=[] 276 Format of a PCReq message with monitoring data requested (in band 277 request): 278 ::= 279 280 281 [] 282 [] 283 285 where: 286 ::=[] 288 ::=[] 290 ::=[] 292 ::= 293 294 [] 295 [] 296 [] 297 [[]] 298 [] 299 [] 300 where: 302 ::=[] 304 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO and LOAD- 305 BALANCING objects are defined in [RFC5440]. The XRO object is 306 defined in [RFC5521] and the OF object is defined in [RFC5541]. The 307 PCC-ID-REQ object is defined in Section 4.2. 309 The PCMonReq message is used to gather various PCE state metrics 310 along a path computation chain. The path computation chain may be 311 determined by the PCC (in the form of a series of a series of PCE-ID 312 objects defined in Section 4.3.) according to policy specified on the 313 PCC or may alternatively be determined by the path computation 314 procedure. For example, if the BRPC procedure ([RFC5441]) is used to 315 compute an inter-domain TE LSP, the path computation chain may be 316 determined dynamically. In that case, the PCC sends a PCMonReq 317 message that contains the PCEP objects that characterize the TE LSP 318 attributes along with the MONITORING object (see Section 4.1) that 319 lists the set of metrics of interest. if a list of PCE is present in 320 the monitoring request, it takes precedence over mechanisms used to 321 dynamicaly determine the path computation chain. If a PCE receives a 322 monitoring request that specifies a next hop PCE in the PCE list that 323 is unreachable, the request MUST be silently discarded. 325 Several PCE state metrics may be requested that are specified by a 326 set of objects defined in Section 4. Note that this set of objects 327 may be extended in the future. 329 As pointed out in [RFC5440] several situations can arise: 331 o Bundle of a set of independent and non-synchronized path 332 computation requests, 334 o Bundle of a set of independent and synchronized path computation 335 requests (SVEC object defined below required), 337 o Bundle of a set of dependent and synchronized path computation 338 requests (SVEC object defined below required). 340 In the case of a bundle of a set of request, the MONITORING object 341 SHOULD only be present in the first PCReq or PCMonReq message and the 342 monitoring request applies to all the requests of the bundle, even in 343 the case of dependent and/or synchronized requests sent using more 344 than one PCReq or PCMonReq message. 346 Examples of requests. For the sake of illustration, consider the 347 three following examples: 349 Example 1 (out of band request): PCC1 requests to check the path 350 computation chain that would be used should it request a path 351 computation for a specific TE LSP named T1. A PCMonReq message is 352 sent that contains a MONITORING object specifying a path computation 353 check, along with the appropriate set of objects (e.g., RP, END- 354 POINTS, ...) that would be included in a PCReq message for T1. 356 Example 2 (in band request): PCC1 requests a path computation for a 357 TE LSP and also request to gather the processing time along the path 358 computation chain selected for the computation of T1. A PCReq 359 message is sent that also contains a MONITORING object that specifies 360 the performance metrics of interest. 362 Example 3 (out of band request): PCC2 requests to gather performance 363 metrics along the specific path computation chain . A PCMonReq message is sent to PCE1 that contains a MONITORING 365 object and a sequence of PCE-ID objects that identify PCE1, PCE2, 366 PCE3 and PCE7 respectively. 368 In all of the examples above, a PCRep message (in-band request) or 369 PCMonReq message (out of band request) is sent in response to the 370 request that reports the computed metrics. 372 3.2. Path Monitoring Reply message (PCMonRep) 374 The PCMonRep message is used to provide PCE state metrics back to the 375 requester for "out of band" monitoring requests. The Message-Type 376 field of the PCEP common header for the PCMonRep message is set to 9 377 (To be confirmed by IANA). 379 There is one mandatory object that MUST be included within a PCMonRep 380 message: the MONITORING object (see Section 4.1). If the MONITORING 381 object is missing, the receiving PCE MUST send a PCErr message with 382 Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING 383 Object missing). 385 Other objects are optional. 387 Format of a PCMonRep (out of band request): 388 ::= 389 390 391 [] 392 [] 394 where: 396 ::=[] 398 ::= 399 [] 400 [] 402 Format of a PCRep message with monitoring data (in band): 403 ::= 404 406 where: 407 ::=[] 409 ::= 410 411 412 [] 413 [] 414 [] 415 [] 417 ::=[] 419 ::= 421 where: 423 ::=[] 424 [] 425 [] 426 [] 428 ::=[] 430 ::=[] 432 ::= 433 [] 434 [] 436 The RP and the NO-PATH objects are defined in [RFC5440]. The PCC-ID- 437 REQ object is defined in Section 4.2. 439 If the path computation chain has been statically specified in the 440 corresponding monitoring request using the series of a series of 441 PCE-ID objects defined in Section 4.3 the monitoring request MUST use 442 the same path computation chain (using the pce-list but in the 443 reverse order). 445 4. Path Computation Monitoring Objects 447 The PCEP objects defined in the document are compliant with the PCEP 448 object format defined in [RFC5440]. The P flag and the I flag of the 449 PCEP objects defined in this document SHOULD always be set to 0 on 450 transmission and MUST be ignored on receipt since these flags are 451 exclusively related to path computation requests. 453 Several objects are defined in this section that can be carried 454 within the PCEP PCReq or PCRep messages defined in [RFC5440] in case 455 of "in band" monitoring requests (the PCC requests the computation of 456 the TE LSP in addition to gathering PCE state metrics). In case of 457 "out of band" monitoring requests, the objects defined in this 458 section are carried within PCMonReq and PCMonRep messages. 460 All TLVs carried in objects defined in this document have the TLV 461 format defined in [RFC5440] 463 o Type: 2 bytes 465 o Length: 2 bytes 467 o Value: variable 469 A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes 470 specifying the TLV length, and a value field. The Length field 471 defines the length of the value portion in bytes. The TLV is padded 472 to 4-bytes alignment; padding is not included in the Length field (so 473 a 3-byte value would have a length of 3, but the total size of the 474 TLV would be 8 bytes). Unrecognized TLVs MUST be ignored. 476 4.1. MONITORING Object 478 The MONITORING object MUST be present within PCMonReq and PCMonRep 479 messages ("out of band" monitoring requests) and MAY be carried 480 within PCRep and PCReq messages ("in band" monitoring requests). 481 There SHOULD NOT be more than one instance of the MONITORING object 482 in a PCMonReq or PCMonRep message: if more than one instance of the 483 MONITORING object is present, the recipient MUST process the first 484 instance and MUST ignore other instances. 486 The MONITORING object is used to specify the set of requested PCE 487 state metrics. 489 The MONITORING Object-Class is to be assigned by IANA (recommended 490 value=19) 492 The MONITORING Object-Type is to be assigned by IANA (recommended 493 value=1) 495 The format of the MONITORING object body is as follows: 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Reserved | Flags |I|C|P|G|L| 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Monitoring-id-number | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | | 504 // Optional TLV(s) // 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Flags: 24 bits 510 The following flags are currently defined: 512 L (Liveness) - 1 bit: when set, this indicates that the state metric 513 of interest is the PCE's liveness and thus the PCE MUST include a 514 PCE-ID object in the corresponding reply. The L bit MUST always be 515 ignored in a PCMonRep or PCRep message. 517 G (General) - 1 bit: when set, this indicates that the monitoring 518 request is a general monitoring request. When the requested 519 performance metric is specific, the G bit MUST be cleared. The G bit 520 MUST always be ignored in a PCMonRep or PCRep message. 522 P (Processing Time) - 1 bit: the P bit of the MONITORING object 523 carried in a PCMonReq or a PCReq message is set to indicate that the 524 processing times is a metric of interest. If allowed by policy, a 525 PROC-TIME object MUST be inserted in the corresponding PCMonRep or 526 PCRep message. The P bit MUST always be ignored in a PCMonRep or 527 PCRep message. 529 C (Overload) - 1 bit: The C bit of the MONITORING object carried in a 530 PCMonReq or a PCReq message is set to indicate that the overload 531 status is a metric of interest, in which case a OVERLOAD object MUST 532 be inserted in the corresponding PCMonRep or PCRep message. The C 533 bit MUST always be ignored in a PCMonRep or PCRep message. 535 I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message 536 and that message does not trigger any policy violation, but the PCE 537 cannot provide any of the set of requested performance metrics for 538 unspecified reasons, the PCE MUST set the I bit. The I bit has no 539 meaning in a request and SHOULD be ignored on receipt. 541 Monitoring-id-number (32 bits): The monitoring-id-number value 542 combined with the PCC-REQ-ID identifying the requesting PCC uniquely 543 identifies the monitoring request context. The monitoring-id-number 544 MUST start at a non-zero value and MUST be incremented each time a 545 new monitoring request is sent to a PCE. Each increment SHOULD have 546 a value of 1 and may cause a wrap back to zero. If no reply to a 547 monitoring request is received from the PCE, and the PCC wishes to 548 resend its path computation monitoring request, the same monitoring- 549 id-number MUST be used. Conversely, a different monitoring-id-number 550 MUST be used for different requests sent to a PCE. A PCEP 551 implementation SHOULD checkpoint the Monitoring-id-number of pending 552 monitoring requests in case of restart thus avoiding the re-use of a 553 Monitoring-id-number of an in-process monitoring request. 555 Unassigned bits are considered as reserved and MUST be set to zero on 556 transmission and ignored on reception. 558 No optional TLVs are currently defined. 560 4.2. PCC-ID-REQ Object 562 The PCC-ID-REQ Object is used to specify the IP address of the 563 requesting PCC. 565 The PCC-ID-REQ MUST be inserted within a PCReq or a PCMonReq message 566 to specify the IP address of the requesting PCC. 568 Two PCC-ID-REQ objects (for IPv4 and IPv6) are defined. PCC-ID-REQ 569 Object-Class is to be assigned by IANA (recommended value=20) PCC-ID- 570 REQ Object-Type is to be assigned by IANA (recommended value=1 for 571 IPv4 and 2 for IPv6) 573 The format of the PCE-ID-REQ Object is as follows: 575 The format of the PCC-ID-REQ object body for IPv4 and IPv6 are as 576 follows: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | IPv4 Address | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 0 1 2 3 585 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 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 | IPv6 Address | 589 | | 590 | | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 The PCC-ID-REQ object body has a fixed length of 4 octets for IPv4 593 and 16 octets for IPv6. 595 4.3. PCE-ID Object 597 The PCE-ID Object is used to specify a PCE's IP address. The PCE-ID 598 object can either be used to specifyt the list of PCE for which 599 monitoring data is requested and to specify the IP address of the 600 requesting PCC. 602 A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq 603 message to specify the PCE for which PCE state metrics are requested 604 and in a PCMonRep or a PCRep message to record the IP address of the 605 PCE reporting PCE state metrics or that was involved in the path 606 computation chain. 608 Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object- 609 Class is to be assigned by IANA (recommended value=21) PCE-ID Object- 610 Type is to be assigned by IANA (recommended value=1 for IPv4 and 2 611 for IPv6) 613 The format of the PCE-ID Object is as follows: 615 The format of the PCE-ID object body for IPv4 and IPv6 are as 616 follows: 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | IPv4 Address | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | | 628 | IPv6 Address | 629 | | 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 633 octets for IPv6. 635 When a dynamic discovery mechanism is used for PCE discovery, a PCE 636 advertises its PCE address in the PCE-ADDRESS sub-TLV defined in 637 [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and 638 PCMonReq messages and a PCE MUST also use this address in PCRep and 639 PCMonRep messages. 641 4.4. PROC-TIME Object 643 If allowed by policy, the PCE includes a PROC-TIME object within a 644 PCMonRep or a PCRep message if the P bit of the MONITORING object 645 carried within the corresponding PCMonReq or PCReq message is set. 646 The PROC-TIME object is used to report various processing time 647 related metrics. 649 1) Case of general monitoring requests 651 A PCC may request processing time metrics for general monitoring 652 requests (e.g., the PCC may want to know the minimum, maximum and 653 average processing times on a particular PCE). In this case, general 654 requests can only be made by using PCMonReq/PCMonRep messages. The 655 Current-processing-time field (as explained below) is exclusively 656 used for specific monitoring requests and MUST be cleared for general 657 monitoring requests. The algorithms used by a PCE to compute the 658 minimum, maximum, average and variance of the processing times are 659 out of the scope of this document (A PCE may decide to compute the 660 minimum processing time over a period of times, for the last N path 661 computation requests, ...). 663 2) Case of specific monitoring requests 665 In the case of a specific request, the algorithms used by a PCE to 666 compute the Processing-time metrics are out of the scope of this 667 document but a flag is specified that is used to indicate to the 668 requester whether the processing time value was estimated or 669 computed. The PCE may either (1) estimate the processing time 670 without performing an actual path computation or (2) effectively 671 perform the computation to report the processing time. In the former 672 case, the E bit of the PROC-TIME object MUST be set. The G bit MUST 673 be cleared and the Min-processing-time, Max-processing-time, Average- 674 processing-time and Variance-processing-time MUST be set to 675 0x00000000. 677 When the processing time is requested in addition to a path 678 computation (case where the MONITORING object is carried within a 679 PCReq message), the PROC-TIME object always reports the actual 680 processing time for that request and thus the E bit MUST be cleared. 682 The PROC-TIME Object-Class is to be assigned by IANA (recommended 683 value=22) 685 The PROC-TIME Object-Type is to be assigned by IANA (recommended 686 value=1) 688 The format of the PROC-TIME object body is as follows: 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Reserved | Flags |E| 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Current-processing-time | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Min-processing-time | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Max-processing-time | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Average-processing time | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Variance-processing-time | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Flags: 16 bits - one flag is currently defined: 707 E (Estimated) - 1 bit: when set, this indicates that the reported 708 metric value is based on estimated processing time as opposed to 709 actual computations. 711 Unassigned bits are considered as reserved and MUST be set to zero on 712 transmission. 714 Current-processing-time: This field indicates in milliseconds the 715 processing time for the path computation of interest characterized in 716 the corresponding PCMonReq message. 718 Min-processing-time: This field indicates in milliseconds the minimum 719 processing time. 721 Max-processing-time: This field indicates in milliseconds the maximum 722 processing time. 724 Average-processing-time: This field indicates in milliseconds the 725 average processing time. 727 Variance-processing-time: This field indicates in milliseconds the 728 variance of the processing times. 730 Since PCC may potentially use monitoring metrics as input to their 731 PCE selection, it MAY be required to normalize how time metrics 732 (along with others metrics described in further revision of this 733 document) are computed to ensure consistency between the monitoring 734 metrics computed by a set of PCEs. 736 4.5. OVERLOAD Object 738 The OVERLOAD object is used to report a PCE processing congestion 739 state. Note that "overload" as indicated by this object refers to 740 the processing state of the PCE and its ability to handle new PCEP 741 requests. A PCE is overloaded when it has a backlog of PCEP requests 742 such that it cannot immediately start to process a new request thus 743 leading to waiting times. The overload duration is quantified as 744 being the (estimated) time until the PCE expects to be able to 745 immediately process a new PCEP request. 747 The OVERLOAD object MUST be present within a PCMonRep or a PCRep 748 message if the C bit of the MONITORING object carried within the 749 corresponding PCMonReq or PCReq message is set and the PCE is 750 experiencing a congested state. The OVERLOAD Object-Class is to be 751 assigned by IANA (recommended value=23). The OVERLOAD Object-Type is 752 to be assigned by IANA (recommended value=1) 753 The format of the CONGESTION object body is as follows: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Flags | Reserved | Overload Duration | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Flags: 8 bits - No flag is currently defined. 762 Overload duration - 16 bits: This field indicates in the amount of 763 time in seconds that the responding PCE expects that it may continue 764 to be overloaded from the time that the response message was 765 generated. The receiver MAY use this value to decide whether or not 766 so send further requests to the same PCE. 768 It is worth noting that a PCE along a path computation chain involved 769 in the monitoring request may decide to learn from the overload 770 information received by one of downstream PCE in the chain. 772 5. Policy 774 The receipt of a PCMonReq message may trigger a policy violation on 775 some PCE in which case the PCE MUST send a PCErr message with Error- 776 Type=5 and Error-value=3 (To be Confirmed by IANA). 778 6. Elements of Procedure 780 I bit processing: as indicated in section Section 4.1, if a PCE 781 supports a received PCMonReq message and that message does not 782 trigger any policy violation, but the PCE cannot provide any of the 783 set of requested performance metrics for unspecified reasons, the PCE 784 MUST set the I bit. Once set, the I bit MUST NOT be changed by a 785 receiving PCE. 787 Upon receiving a PCMonReq message: 789 1) As specified in [RFC5440], if the PCE does not support the 790 PCMonReq message, the PCE peer MUST send a PCErr message with Error- 791 value=2 (capability not supported). According to the procedure 792 defined in section 6.9 of [RFC5440], if a PCC/PCE receives 793 unrecognized messages at a rate equal of greater than specified rate, 794 the PCC/PCE must send a PCEP CLOSE message with close value=5 795 "Reception of an unacceptable number of unrecognized PCEP messages". 796 In this case, the PCC/PCE must also close the TCP session and must 797 not send any further PCEP messages on the PCEP session. 799 2) If the PCE supports the PCMonReq message but the monitoring 800 request is prohibited by policy, the PCE must follow the procedure 801 specified in section 5. As pointed out in section 4.3, a PCE may 802 still partially satisfy a request, leaving out some of the required 803 data if not allowed by policy. 805 3) If the PCE supports the PCMonReq and the monitoring request is not 806 prohibited by policy, the receiving PCE MUST first determine whether 807 it is the last PCE of the path computation chain. If the PCE is not 808 the last element of the path computation chain, the PCMonReq message 809 is relayed to the next hop PCE: such next hop may either be specified 810 by means of a PCE-ID object present in the PCMonReq message or 811 dynamically determined by means of a procedure outside of the scope 812 of this document. Conversely, if the PCE is the last PCE of the path 813 computation chain, the PCE originates a PCMonRep message that 814 contains the requested objects according to the set of requested PCE 815 states metrics listed in the MONITORING object carried in the 816 corresponding PCMonReq message. 818 Upon receiving a PCReq message that carries a MONITORING and 819 potentially other monitoring objects (e.g., PCE-ID object): 821 1) As specified in [RFC5440], if the PCE does not support (in band) 822 monitoring, the PCE peer MUST send a PCErr message with Error-value=2 823 (capability not supported). According to the procedure defined in 824 section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages 825 at a rate equal of greater than specified rate, the PCC/PCE must send 826 a PCEP CLOSE message with close value=5 "Reception of an unacceptable 827 number of unrecognized PCEP messages". In this case, the PCC/PCE 828 must also close the TCP session and must not send any further PCEP 829 messages on the PCEP session. 831 2) If the PCE supports the monitoring request but the monitoring 832 request is prohibited by policy, the PCE must follow the procedure 833 specified in section 5. As pointed out in section 4.3, a PCE may 834 still partially satisfy a request, leaving out some of the required 835 data if not allowed by policy. 837 3) If the PCE supports the monitoring request and that request is not 838 prohibited by policy, the receiving PCE MUST first determine whether 839 it is the last PCE of the path computation chain. If the PCE is not 840 the last element of the path computation chain, the PCReq message 841 (with the MONITORING object and potentially other monitoring objects 842 such as the PCE-ID) is relayed to the next hop PCE: such next hop may 843 either be specified by means of a PCE-ID object present in the PCReq 844 message or dynamically determined by means of a procedure outside of 845 the scope of this document. Conversely, if the PCE is the last PCE 846 of the path computation chain, the PCE originates a PCRep message 847 that contains the requested objects according to the set of requested 848 PCE states metrics listed in the MONITORING and potentially other 849 monitoring objects carried in the corresponding PCReq message. 851 Upon receiving a PCMonRep message, the PCE processes the request, 852 adds the relevant objects to the PCMonRep message and forwards the 853 PCMonRep message to the upstream requesting PCE or PCC. 855 Upon receiving a PCRep message that carries monitoring data, the 856 message is processed, additional monitoring data is added according 857 to this specification and the message is forwarded upstream to the 858 requesting PCE or PCC. 860 7. Manageability Considerations 862 7.1. Control of Function and Policy 864 It MUST be possible to configure the activation/deactivation of PCEP 865 monitoring on a PCEP speaker. In addition to the parameters already 866 listed in section 8.1 of [RFC5440], a PCEP implementation SHOULD 867 allow configuring on a PCE whether specific, generic, in band and out 868 of band monitoring requests are allowed or not. Also a PCEP 869 implementation SHOULD allow configuring on a PCE a list of authorized 870 state metrics (aliveness, overload, processing time, etc). This may 871 apply to any session the PCEP speaker participates in, to a specific 872 session with a given PCEP peer or to a specific group of sessions 873 with a specific group of PCEP peers, for instance the PCEP peers of a 874 neighbor AS. 876 7.2. Information and Data Models 878 A new MIB Module may be defined that provides local PCE state 879 metrics, as well as state metrics of other PCEs gathered using 880 mechanisms defined in this document. 882 7.3. Liveness Detection and Monitoring 884 This document provides mechanisms to monitor the liveliness and 885 performances of a given path computation chain. 887 7.4. Verify Correct Operations 889 Mechanisms defined in this document do not imply any new operation 890 verification requirements in addition to those already listed in 891 [RFC5440]. 893 7.5. Requirements On Other Protocols 895 Mechanisms defined in this document do not imply any requirements on 896 other protocols in addition to those already listed in [RFC5440]. 898 7.6. Impact On Network Operations 900 The frequency of PCMonReq messages may impact the operations of PCEs. 901 An implementation SHOULD allow a limit to be placed on the rate of 902 PCMonReq messages sent by a PCEP speaker and processed from a peer. 903 It SHOULD also allow sending a notification when a rate threshold is 904 reached. An implementation SHOULD allow handling PCReq messages with 905 a higher priority than PCMonReq messages. An implementation SHOULD 906 allow the configuration of a second limit for the PCReq message 907 requesting monitoring data. 909 8. Guidelines to Avoid Overload Thrashing 911 An important concern while processing overload information is to 912 prevent the overload condition on one PCE simply being moved to 913 another PCE. Indeed, there is a risk that the reaction to an 914 indication of overload will act to increase the amount of overload 915 within the network. Furthermore, this may lead to oscillations 916 between PCEs if the overload information is not handled properly. 918 This section presents some brief guidance on how a PCC (which term 919 includes a PCE making requests of another PCE) should react when it 920 receives an indication that a PCE is overloaded. 922 When an overload indication is received (on a PCRep message or on a 923 PCMonRep message), it identifies that new PCReq messages sent to the 924 PCE might be subject to a delay equal to the value in the Overload 925 Duration field (when present). 927 It also indicates that PCReq messages already queued at the PCE might 928 be subject to a delay. The PCC must decide how to handle new PCReq 929 messages, and what to do about PCReq messages already queued at the 930 PCE. 932 It is RECOMMENDED that a PCC does not cancel a queued PCReq and re- 933 issue it to another PCE because of the PCE being overloaded. 935 Such behavior is likely to result in overload thrashing as multiple 936 PCCs move the PCE queue to another PCE. This would simply introduce 937 additional delay in the processing of all requests. A PCC MAY choose 938 to cancel a queued PCE request if it is willing to sacrifice the 939 request, maybe re-issuing it later (after the overload condition has 940 been determined to have cleared by use of a PCMonReq/Rep exchange). 942 It is then RECOMMENDED to send the cancellation request with a higher 943 priority in order for the PCE overloaded PCE to detect the request 944 cancellation before processing the related request. 946 A PCC that is aware of PCE overload at one PCE MAY select a different 947 PCE to service its next PCReq message. In doing so it is RECOMMENDED 948 that the PCC consider whether the other PCE is overloaded or might be 949 likely to become overloaded by other PCCs similarly directing new 950 PCReq messages. 952 Furthermore, should the second PCE be also overloaded, it is 953 RECOMMENDED not to make any attempt to switch back to the other PCE 954 without knowing that the first PCE is no longer overloaded. 956 9. IANA Considerations 958 9.1. New PCEP Message 960 Each PCEP message has a message type value. 962 Two new PCEP (specified in [RFC5440]) messages are defined in this 963 document: 965 Value Description Reference 966 8 Path Computation Monitoring Request (PCMonReq) This document 967 9 Path Computation Monitoring Reply (PCMonRep) This document 969 9.2. New PCEP Objects 971 Each PCEP object has an Object-Class and an Object-Type. The 972 following new PCEP objects are defined in this document: 974 Object-Class Value Name Object-Type Reference 976 19 MONITORING 1 This document 978 20 PCC-REQ-ID 1: IPv4 addresses This document 979 2: IPv6 addresses 981 21 PCE-ID 1: IPv4 addresses This document 982 2: IPv6 addresses This document 984 22 PROC-TIME 1 This document 986 23 OVERLOAD 1 This document 988 9.3. New Error-Values 990 A registry was created for the Error-type and Error-value of the PCEP 991 Error Object. 993 A new Error-value for the PCErr message Error-types=5 (Policy 994 Violation) (see [RFC5440]) is defined in this document (Error-value 995 to be assigned by IANA). 997 Error-Type Meaning Error-value Reference 998 5 Policy violation 3 This document 999 Monitoring message supported 1000 but rejected due to 1001 policy violation 1003 A new Error-value for the PCErr message Error-types=6 (Mandatory 1004 Object missing) (see [RFC5440]) is defined in this document (Error- 1005 Type and Error-value to be assigned by IANA). 1007 Error-type Meaning Error-value Reference 1008 6 Mandatory Object missing 4 This document 1009 MONITORING Object missing 1011 9.4. MONITORING Object Flag Field 1013 IANA is requested to create a registry to manage the Flag field of 1014 the MONITORING object. 1016 New bit numbers may be allocated only by an IETF review. Each bit 1017 should be tracked with the following qualities: 1019 o Bit number (counting from bit 0 as the most significant bit) 1020 o Capability Description 1022 o Defining RFC 1024 Several bits are defined for the MONITORING Object flag field in this 1025 document: 1027 Codespace of the Flag field (MONITORING Object) 1028 Bit Description Reference 1029 0-18 Unassigned 1030 19 Incomplete This document 1031 20 Overload This document 1032 21 Processing Time This document 1033 22 General This document 1034 23 Liveness This document 1036 9.5. PROC-TIME Object Flag Field 1038 IANA is requested to create a registry to manage the Flag field of 1039 the PROC-TIME object. 1041 New bit numbers may be allocated only by an IETF review. Each bit 1042 should be tracked with the following qualities: 1044 o Bit number (counting from bit 0 as the most significant bit) 1046 o Capability Description 1048 o Defining RFC 1050 One bit is defined for the PROC-TIME Object flag field in this 1051 document: 1053 Codespace of the Flag field (PROC-TIME Object) 1054 Bit Description Reference 1055 0-14 Unassigned 1056 15 Estimated This document 1058 9.6. OVERLOAD Object Flag field 1060 IANA is requested to create a registry to manage the Flag field of 1061 the OVERLOAD object. 1063 New bit numbers may be allocated only by an IETF review. Each bit 1064 should be tracked with the following qualities: 1066 o Bit number (counting from bit 0 as the most significant bit) 1068 o Capability Description 1070 o Defining RFC 1072 No Flag are currently defined for the OVERLOAD Object flag field in 1073 this document. 1075 Codespace of the Flag field (OVERLOAD Object) 1076 Bit Description Reference 1077 0-7 Unassigned 1079 10. Security Considerations 1081 The use of monitoring data can be used for various attacks such as 1082 denial of service attacks (for example by setting the C bit and 1083 overload duration field of the OVERLOAD object to stop PCCs from 1084 using a PCE). Thus it is recommended to make use of the security 1085 mechanisms discussed in [RFC5440] to secure a PCEP session 1086 (authenticity, integrity, privacy, DoS protection, etc) to secure the 1087 PCMonReq, PCMonRep messages and PCE state metric objects defined in 1088 this document. An implementation SHOULD allow limiting the rate at 1089 which PCMonReq or PCReq messages carrying monitoring requests 1090 received from a specific peer are processed (input shaping) as 1091 discussed in section 10.7.2 of [RFC5440], or from another domain (see 1092 also section 7.6). 1094 11. Acknowledgments 1096 The authors would like to thank Eiji Oki, Mach Chen, Fabien 1097 Verhaeghe, Dimitri Papadimitriou and Francis Dupont for their useful 1098 comments. Special thank to Adrian Farrel for his detailed review. 1100 12. References 1102 12.1. Normative References 1104 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1105 Requirement Levels", BCP 14, RFC 2119, March 1997. 1107 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 1108 (PCE) Communication Protocol (PCEP)", RFC 5440, 1109 March 2009. 1111 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1112 Used to Form Encoding Rules in Various Routing Protocol 1113 Specifications", RFC 5511, April 2009. 1115 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1116 Path Computation Element Communication Protocol (PCEP) for 1117 Route Exclusions", RFC 5521, April 2009. 1119 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1120 Objective Functions in the Path Computation Element 1121 Communication Protocol (PCEP)", RFC 5541, June 2009. 1123 12.2. Informative References 1125 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1126 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1128 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1129 "OSPF Protocol Extensions for Path Computation Element 1130 (PCE) Discovery", RFC 5088, January 2008. 1132 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1133 "IS-IS Protocol Extensions for Path Computation Element 1134 (PCE) Discovery", RFC 5089, January 2008. 1136 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 1137 Backward-Recursive PCE-Based Computation (BRPC) Procedure 1138 to Compute Shortest Constrained Inter-Domain Traffic 1139 Engineering Label Switched Paths", RFC 5441, April 2009. 1141 Authors' Addresses 1143 JP Vasseur (editor) 1144 Cisco Systems, Inc 1145 1414 Massachusetts Avenue 1146 Boxborough, MA 01719 1147 USA 1149 Email: jpv@cisco.com 1150 JL Le Roux 1151 France Telecom 1152 2, Avenue Pierre-Marzin 1153 Lannion, 22307 1154 FRANCE 1156 Email: jeanlouis.leroux@orange-ftgroup.com 1158 Yuichi Ikejiri 1159 NTT Communications Corporation 1160 1-1-6, Uchisaiwai-cho, Chiyoda-ku 1161 Tokyo, 100-8019 1162 Japan 1164 Email: : y.ikejiri@ntt.com