idnits 2.17.1 draft-chen-pce-interas-pce-sequence-autoexplore-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 627. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 640. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([PCE-DISCO-ISIS], [PCE-DISCO-OSPF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 12, 2006) is 6404 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) == Missing Reference: 'INERAS-TE-REG' is mentioned on line 106, but not defined == Missing Reference: 'BPRC' is mentioned on line 132, but not defined == Missing Reference: 'PCEP' is mentioned on line 471, but not defined == Missing Reference: 'RFC3473' is mentioned on line 525, but not defined == Missing Reference: 'RFC3477' is mentioned on line 526, but not defined == Unused Reference: 'BGP-4' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'BRPC' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'INTERAS-TE-REQ' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'CCAMP-INTER-DOMAIN-TE' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'PCE-COMM-GEN-REQ' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'PCE-DISCO-REQ' is defined on line 600, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 (ref. 'PCE-ARCH') == Outdated reference: A later version (-02) exists of draft-vasseur-pce-brpc-01 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-ospf-00 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-isis-00 == Outdated reference: A later version (-04) exists of draft-vijay-somen-pce-disco-proto-bgp-00 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-03 == Outdated reference: A later version (-07) exists of draft-ietf-pce-comm-protocol-gen-reqs-06 == Outdated reference: A later version (-01) exists of draft-bitar-zhang-interas-pce-req-00 Summary: 6 errors (**), 0 flaws (~~), 22 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network work group Mach Chen 2 Internet Draft Huawei Technologies Co.,Ltd 3 Expires: April 2007 October 12, 2006 5 Inter-AS PCE Path Sequence Autoexplore 6 draft-chen-pce-interas-pce-sequence-autoexplore-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that 11 any applicable patent or other IPR claims of which he or she is 12 aware have been or will be disclosed, and any of which he or she 13 becomes aware will be disclosed, in accordance with Section 6 of 14 BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on April 12, 2007. 33 Abstract 35 In Inter-AS scenario, as usual, multiple Path Computation Elements 36 (PCEs) will take part in path computation. [PCE-DISCO-OSPF], [PCE- 37 DISCO-ISIS],PCE-DISCO-BGP] or some other means can be used to 38 discover all underling PCEs, but there is lack of solutions to find 39 out those PCEs and their sequence which are engaged in computing an 40 end-to-end inter-AS TE LSP. This document proposes a solution to 41 identify these PCEs and their sequence which can be used to compute a 42 TE LSP across multiple ASes. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC-2119. 50 Table of Contents 52 1. Introduction..................................................3 53 2. General assumptions...........................................4 54 3. Procedure.....................................................4 55 3.1. PCEP extension...........................................4 56 3.1.1. PCE Path Sequence Explore Request(PCPSReq) message..5 57 3.1.2. PCE Path Sequence Explore Reply(PCPSRep) message....5 58 3.1.3. Extension to PCReq message..........................6 59 3.2. PCE Path Sequence Explore................................7 60 3.3. PCE Path Sequence Explore flows..........................10 61 4. Objects format................................................12 62 4.1. END-POINTS object........................................12 63 4.2. SVEC object..............................................12 64 4.3. RP object................................................12 65 4.4. RRO object...............................................13 66 4.5. PCPSO object.............................................13 67 5. Security Considerations.......................................13 68 6. IANA Considerations...........................................13 69 6.1. PCPS Messages............................................13 70 7. References....................................................14 71 7.1. Normative References.....................................14 72 7.2. Informative References...................................14 73 Author's Addresses...............................................15 74 Intellectual Property Statement..................................15 75 Disclaimer of Validity...........................................16 76 Copyright Statement..............................................16 77 Acknowledgment...................................................16 79 1. Introduction 81 +--------+ +--------+ +--------+ 82 | AS1 | | AS2 | | AS5 | 83 | | | | | | 84 | +====+ | | | | +====+ | 85 | | Ra | |-------| |-------| | Rb | | 86 | +====+ | | | | +====+ | 87 | +====+ | | +====+ | | +====+ | 88 | |PCE1| | | |PCE2| | | |PCE5| | 89 | +====+ | | +====+ | | +====+ | 90 +--------+ +--------+ +--------+ 91 \ / / 92 \ / / 93 \ / / 94 \ / / 95 +--------+ +--------+ 96 | AS3 | | AS4 | 97 | | | | 98 | |-------| | 99 | +====+ | | +====+ | 100 | |PCE3| | | |PCE4| | 101 | +====+ | | +====+ | 102 +--------+ +--------+ 103 Figure 1: Inter-AS TE and multiple PCE scenario 105 Multiple Protocol Label Switching (MPLS) Inter-AS Traffic Engineering 106 as a key requirement has been stated in [INERAS-TE-REG], and Path 107 Computation Element (PCE) has the ability to compute a TE LSP 108 spanning multiple ASes. These ASes MAY be under one Service 109 Provider(SP) administration or the administration of different SPs. 110 [PCE-ARCH] has defined several models which can be used to satisfy 111 different scenarios, one of them is "multiple PCE path computation" 112 where multiple PCEs cooperate in computing a TE LSP across multiple 113 domains. 115 [PCE-DISCO-OSPF], [PCE-DISCO-ISIS] and [PCE-DISCO-BGP] has proposed 116 some mechanisms to discover all underling PCEs automatically, but it 117 is not enough to know this information only. Consider that we want to 118 compute a TE LSP spanning multiple ASes and each AS has its own PCE 119 responsible for path computation. As illustrated above in Figure 1, 120 there are five ASes and five PCEs. We want to set up an end-to-end TE 121 LSP from Ra to Rb. Obviously, there are several possible paths we MAY 122 get, such as AS1->AS2->AS5, AS1->AS3-AS4->AS5, etc. According to 123 existing PCE discovery mechanisms we only know that a specific PCE 124 belongs to an AS and the PCE has some special capabilities. But we 125 SHOULD also know which PCEs are engaged to compute such an end-to-end 126 path and where is the next PCE when we need to send a PCE Path 127 Request message. Otherwise, we will fail to compute such a end-to-end 128 path. 130 So, in order to perform path computation in such scenario, we need to 131 find out those PCEs which are engaged in computing a specific TE LSP, 132 and the sequence of those PCEs. As pointed out in [BPRC], before 133 sending path computation request to the next PCE, we need to know 134 where the next PCE is. Static configuration is an alternative method, 135 but it may not be desirable in some cases. 137 Therefore, it is desirable to find a way that can explore those 138 underling PCEs and their sequence for a specific TE LSP dynamically. 139 This document proposes a method which could easily explore those 140 underling PCEs and their sequence for a specific end-to-end TE LSP 141 automatically. The main idea is that a PCE uses the BGP AS_PATH 142 attribute to find out those PCEs and track their sequence. 144 2. General assumptions 146 In the rest of this document, there are some assumptions as follows: 148 - All the underling PCEs can be discovered by [PCE-DISCO-OSPF], 149 [PCE-DISCO-ISIS], [PCE-DISCO-BGP] or some other means (which is 150 outside the scope of this document), and each PCE is identified 151 with the AS which it belongs to. 153 - As stated in [INTER-AS-PCE] each Inter-AS PCE is assumed to run 154 BGP protocol (In fact, an Inter-AS PCE only needs to receive 155 routing updates and almost doesn't send any updates if it just is 156 a path computation engine. So, running BGP in an Inter-AS PCE is 157 not a problem.), so each Inter-AS PCE has full routing information. 159 - Each AS MAY have multiple PCEs, but for a specific TE LSP 160 computation we can make a decision according to the capability of 161 the PCE which one is the best(how to choose the best PCE is 162 outside the scope of this document). 164 3. Procedure 166 3.1. PCEP extension 168 In order to explore those PCEs and their sequence for a specific TE 169 LSP, in this document we define two new PCEP messages, namely PCE 170 Path Sequence Explore Request (PCPSReq) message and PCE Path Sequence 171 Explore Reply (PCPSRep) message. At the same time, we need to do some 172 extensions to PCReq message. 174 3.1.1. PCE Path Sequence Explore Request(PCPSReq) message 176 A PCE Path Sequence Explore Request message (also referred to as a 177 PCPSReq message) is a message sent by a PCE to other PCEs(also 178 referred to as helper PCE) to explore the PCE Path Sequence (also 179 referred to as PCPS) for a specific TE LSP computation. The Message- 180 Type field of the PCEP common header for the PCPSReq message is set 181 to . 183 A PCPSReq message MUST contain two objects: the END-POINTS object and 184 the RP object. Other objects are optional. 186 The format of a PCPSReq message is as follows: 188 ::= 189 [] 190 191 Where: 193 ::=[] 194 ::=[] 196 ::= 197 [] 198 [] 199 The SVEC, RP, END-POINTS, and RRO objects are defined in Section 4. 201 3.1.2. PCE Path Sequence Explore Reply(PCPSRep) message 203 A PCE Path Sequence Explore Reply message (also referred to as a 204 PCPSReq message) is a message sent by a PCE to a requesting PCE in 205 response to a previously received PCPSReq message. The Message-Type 206 field of the PCEP common header for the PCPSRep message is set to 207 . 209 A PCPSRep message MUST contain two objects: the RP object and RRO 210 object. Other objects are optional. 212 The format of PCPSRep message is as follows: 214 ::= 215 [] 216 218 where: 220 ::=[] 221 ::=[] 223 ::= 224 [] 225 [] 227 ::=[] 229 ::= 231 The SVEC, RP, and RRO objects are defined in Section 4. 233 3.1.3. Extension to PCReq message 235 In order to finish the computation of a TE LSP spanning multiple ASes, 236 a PCReq message SHOULD carry a new object termed PCE Path Sequence 237 Object (PCPSO). 239 The format of a PCReq message is as follows: 241 ::= 242 [] 243 245 where: 247 ::=[] 248 ::=[] 249 ::= 250 [] 251 [] 252 [] 253 [] 254 [] 255 [] 256 [] 257 [] 259 The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, ERO, and IRO 260 objects are defined in [PCEP] Section 7. The PCPSO object is defined 261 in Section 4. 263 3.2. PCE Path Sequence Explore 265 In section 2, we have made an assumption that each PCE needs to run 266 BGP protocol, so each PCE has full routing information. 268 When a PCE receives a Path Computation Request (PCReq) message from a 269 PCC, it MUST make a decision whether it could finish the path 270 computation by itself or need the help of other PCEs (the destination 271 node is in anther AS or some other factors, the detail procedure is 272 outside the scope of this document). If it is latter, the PCE MUST 273 find out those PCEs (also referred to as helper PCE) and the PCPS of 274 those PCES. The detail procedure is as follows: 276 First of all, according to the destination address where a specific 277 TE LSP will reach, the PCE (also referred to as an original PCE) 278 finds out all routes which can reach the destination by looking up 279 its local BGP rib. These routes not only include the best route, but 280 also non best routes. Then, the original PCE iterates these BGP 281 routes and checks their AS_PATH attribute. If the first segment of 282 AS_PATH of type is AS_SEQUENCE, the last element of the AS_SEQUENCE 283 is the AS (referred to as next AS) where the BGP route traversed 284 lastly. According to this AS number, it's easy to find out the PCE 285 identified by this AS number from its local PCE database which 286 contains all underling PCE infomation collected by [PCE-DISCO-OSPF], 287 [PCE-DISCO-ISIS], [PCE-DISCO-BGP] or some other means. There MAY be 288 multiple routes which could reach the destination node, so multiple 289 PCEs MAY be found out. After finding these helper PCEs, the original 290 PCE sends a PCPSReq message to these helper PCEs respectively. 292 When a helper PCE receives a PCPSReq message, the helper PCE checks 293 the PCPSReq message and extracts the address info of destination node 294 from END-POINTS object, according the destination address the helper 295 PCE continues doing the same operation as the original PCE does. That 296 is looking up its local BGP rib to find out specific BGP routes which 297 can reach the destination node, iterating these BGP routes to find 298 out specific next AS numbers and according to these next AS numbers 299 to find out relative helper PCEs from their local PCE databases. 300 After that, the helper PCE will send a PCPSReq message to its helper 301 PCEs respectively. 303 If a helper PCE finds that the routes in its local BGP rib doesn't 304 contain any AS_PATH information, it concludes that this helper PCE 305 itself is the final PCE we want to track. Then the final PCE sends a 306 PCPSRep message with RRO object containing its PCE address to the 307 requesting PCE in response to a previously received PCPSReq message. 309 When a PCE (referred to as intermediate PCE) receives a PCPSRep 310 message, after adding its PCE address into the RRO object, the 311 intermediate PCE relays the PCPSRep to the requesting PCE in response 312 to a previously received PCPSReq message. All the intermediate PCEs 313 will do the same operation until the PCPSRep message relayed to the 314 original PCE. On receiving all PCPSRep messages, the original PCE can 315 get all underling PCE Path Sequences (PCPSes) from the RRO object in 316 each PCPSRep message. 318 If the received PCPSReq message has errors, a PCE MUST reply with 319 PCErr message immediately. The PCErr messages are defined in [PCEP] 320 section 6.7. 322 Here we give an example to detail the procedure of PCPS exploring. As 323 illustrated above in Figure 1, there are five ASes (from AS1 to AS5) 324 and every AS has its own PCE. Let's consider this scenario, says that 325 Ra wants to establish a TE LSP to Rb, Ra as Path Computation 326 Client(PCC) sends a path computation request to its default PCE, 327 namely PCE1(how to choose the default PCE is outside the scope of 328 this document). As usual, consider the confidentiality and 329 administration requirements, PCE1 MAY hasn't the fully TE information 330 about other ASes. So PCE1 can't compute such a TE LSP spanning 331 multiple ASes only by itself, it needs to cooperate with other PCEs. 333 When PCE1 receives the PCReq from its PCC Ra, PCE1 is the original 334 PCE. At first, PCE1 looks up its local BGP rib according to Rb's IP 335 address. Suppose that PCE1 finds out two BGP routes, one is from AS2, 336 the other is from AS3. According to these BGP routes' AS_PATH 337 attribute, PCE1 can find out two helper PCEs relative to AS2 and AS3 338 respectively. One is PCE2, and the other is PCE3. Then, PCE1 sends a 339 PCPSReq message to PCE2 and PCE3 respectively. 341 When PCE2 or PCE3 receives the PCPSReq message, they will check if 342 the request message is valid or not. If the message has errors, they 343 will send a PCErr message to PCE1 immediately. If the message is 344 valid, they will extract Rb's IP address from the PCPSReq message and 345 continue to do the same operation as PCE1 does. That is PCE2 will try 346 to find out its helper PCEs(MAY be PCE3 and PCE5) and PCE3 will try 347 to find out its helper PCEs(MAY be PCE2 and PCE4) too. The PCE2 will 348 send a PCPSReq message to PCE3 and PCE5 respectively, and PCE3 will 349 send a PCPSReq message to PCE2 and PCE4 respectively. When all 350 PCPSReq messages reach PCE5, PCE5 will find out the final PCE is 351 itself. So PCE5 as the final PCE sends a PCPSRep message with RRO 352 object containing its IP address to every requesting PCE in response 353 to every previously received PCPSReq message. After adding their IP 354 address into RRO objects, PCE2, PCE3 and PCE4 as the intermediate PCE 355 will relay these PCPSReq messages till to the original PCE, namely 356 PCE1. Finally, there MAY be several PCPSes found, they are probably 357 as follows: 359 PCE1-PCE2 PCE5 360 PCE1-PCE3 PCE4 PCE5 361 PCE1-PCE3 PCE2-PCE5 362 PCE1-PCE2 PCE3-PCE4-PCE5 364 When PCE1 get these PCPSes info, PCE1 can choose one or multiple 365 PCPSes (MAY be based on the best shortest path, how to choose is 366 outside the scope of this document) to perform path computation for 367 the TE LSP from Ra to Rb. At the same time, when PCE1 sends a PCReq 368 message to its helper PCEs, it SHOULD carry a PCPSO object and before 369 these helper PCEs send or relay the PCReq message to their helper 370 PCEs, they SHOULD omit themselves from the PCPSO object. The PCReq 371 message will be sent along with the chosen PCPS to a final PCE, so we 372 have enough information to finish an end-to-end Inter-AS path 373 computation. 375 PCPSO object is defined in Section 4.5. 377 3.3. PCE Path Sequence Explore flows 379 +-+-+-+ +-+-+-+ +-+-+-+ 380 |O-PCE| |I-PCE| ...... |F-PCE| 381 +-+-+-+ +-+-+-+ +-+-+-+ 382 | | | 383 |PCPSReq message->| | 384 | |1) PCPSReq received | 385 | | | 386 | |2) Not the final PCE | 387 | | | 388 | |3) Send a PCPSReq to next | 389 | |I-PCE based on AS-PATH | 390 | | |1) PCPSReq received 391 | |----- PCPSReq message---->| 392 | | |2) Is the final PCE 393 | | | 394 | | |3) Positive reply 395 | |<---- PCPSRep message ----|send to a requesting 396 | | (Positive reply) |I-PCE(with its IP 397 | | |address) 398 | |1) PCPSRep received | 399 | | | 400 | |2) Relay positive reply to| 401 | |a requesting O-PCE(adding | 402 | |its IP address into the | 403 | |reply message before send | 404 | | | 405 |<-PCPSRep message| | 406 | (Positive reply)| | 407 Figure 2: Successful Path Sequence Explore 409 +-+-+-+ +-+-+-+ +-+-+-+ 410 |O-PCE| |I-PCE| ...... |F-PCE| 411 +-+-+-+ +-+-+-+ +-+-+-+ 412 | | | 413 |PCPSReq message->| | 414 | |1) PCPSReq received | 415 | | | 416 | |2) Some errors | 417 | | | 418 | |3) Negative reply sent to | 419 | |O-PCE | 420 |<-PCPSRep message| |1) PCPSReq received 421 | (Negetive reply)|----- PCPSReq message---->| 422 | | |2) Some errors 423 | | | 424 | | |3) Negative reply 425 | | |send to a requesting 426 | |<---- PCPSRep message ----|I-PCE 427 | | (Negetive reply) | 428 | | | 429 | |1) PCPSRep received | 430 | | | 431 | |2) Relay Negative reply to| 432 | |a requesting O-PCE | 433 | | | 434 | | | 435 |<-PCPSRep message| | 436 | (Negative reply)| | 437 Figure 3: Unsuccessful Path Sequence Explore 439 The above figures are the general description about PCE Path 440 exploring. 442 O-PCE: means original PCE. 444 I-PCE: means intermediate PCE. 446 F-PCE: means final PCE. 448 F-PCE and I-PCEs are helper PCEs of O-PCE as described in Section 3.2. 450 Positive and Negative has same means as described in Section 5.2.3 of 451 [PCEP]. 453 4. Objects format 455 In this document, it just defines a new object named PCPSO object. 456 The other objects have been defined in [PCEP] section 7, and here we 457 only do a little bit extension to some of them. 459 4.1. END-POINTS object 461 The contents of this object are identical in encoding to the contents 462 of the END-POINTS Object defined in [PCEP]. 464 4.2. SVEC object 466 The contents of this object are identical in encoding to the contents 467 of the SVEC Object defined in [PCEP]. 469 4.3. RP object 471 RP object has been defined in [PCEP] section 7, the format of the RP 472 object body is as follows: 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Reserved | Flags |C|Q|R|N|O|B|R| Pri | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Request-ID-number | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | 482 // Optional TLV(s) // 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 2: RP object body format 488 In this document, we add 3 new bits to flag field of RP object. They 489 are defined as follows: 491 C (Synchronization, 1 bit): when set, a PCE receives a PCPSReq 492 message, it can't reply to the requesting PCE until it received the 493 specific PCPSRep message from its helper PCE. But when a PCE receives 494 a PCPSReq message with errors, it will reply with PCErr message to 495 the requesting PCE immediately. Default C bit is set. 497 Q (PCPSReq carry RRO or not, 1 bit): when set, PCPSReq MUST carry RRO 498 object, the original PCE and helper PCE will add their IP address 499 into the RRO object before sending a PCPSReq message to their helper 500 or final PCE. So when a PCPSReq message reaches to a final PCE, the 501 final PCE can get the PCPS from RRO object in PCPSReq message. 502 Therefore, the final PCE can send this info direct to original PCE 503 without the helping of intermediate PCEs. This is an alternative 504 method to get the PCPS information. Default Q bit is cleared. 506 R (PCPSRep carry RRO or not, 1 bit): when set, PCPSRep MUST carry RRO 507 object, the final PCE and intermediate PCE will add their IP address 508 into the RRO object before sending a PCPSRep message to a requesting 509 PCE. Default R bit is set. 511 4.4. RRO object 513 The RRO object is used to record PCE Path Seqeunce (PCPS). 515 The contents of this object are identical in encoding to the contents 516 of the Route Record Object defined in [RFC3209], [RFC3473] and 517 [RFC3477]. That is, the object is constructed from a series of sub- 518 objects. 520 4.5. PCPSO object 522 The PCPSO object is optional and can be used to carry PCPS info which 523 can be used to direct where a PCE sends a PCReq message to. The 524 contents of this object are identical in encoding to the contents 525 of the Explicit Route Object defined in [RFC3209], [RFC3473] and 526 [RFC3477]. That is, the object is constructed from a series of sub- 527 objects. Each sub-object expresses a PCE. 529 5. Security Considerations 531 This extension to PCE does not change the underlying security issues. 533 6. IANA Considerations 535 6.1. PCPS Messages 537 Each PCPS message has a Message-Type. 539 Value Meaning 541 8 PCE Path Sequence Explore Request. 543 9 PCE Path Sequence Explore Reply. 545 7. References 547 7.1. Normative References 549 [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 550 4 (BGP-4)", RFC 4271, January 2006. 552 [PCE-ARCH] A. Farrel, J.-P. Vasseur, J. Ash, " A Path Computation 553 Element (PCE)-Based Architecture ", RFC 4655, August 2006. 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 559 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 560 Functional Specification", RFC 2205, September 1997. 562 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 563 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 564 Tunnels", RFC 3209, December 2001. 566 7.2. Informative References 568 [BRPC] Vasseur,J., Zhang,R., Bitar, N., Le Roux,JL., "A Backward 569 Recursive PCE-based Computation (BRPC) procedure to compute 570 shortest inter-domain Traffic Engineering Label Switched 571 Paths" draft-vasseur-pce-brpc-01 ( work in progress )June 572 2006 574 [PCE-DISCO-OSPF] Le Roux,JL., Vasseur,J., Ikejiri,Y., and Zhang,R., 575 "OSPF protocol extensions for Path Computation Element (PCE) 576 Discovery" draft-ietf-pce-disco-proto-ospf-00 (work in 577 progress) Sep 2006. 579 [PCE-DISCO-ISIS] Le Roux,JL., Vasseur,J., Ikejiri,Y., and Zhang,R., 580 "ISIS protocol extensions for Path Computation Element (PCE) 581 Discovery" draft-ietf-pce-disco-proto-isis-00 (work in 582 progress) Sep 2006. 584 [PCE-DISCO-BGP] Vijayanand,C., and Bhattacharya,S., "BGP Protocol 585 extensions for PCE Discovery across Autonomous systems" 586 draft-vijay-somen-pce-disco-proto-bgp-00.txt June 2006. 588 [INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic 589 Engineering Requirements", RFC4216, November 2005. 591 [CCAMP-INTER-DOMAIN-TE] Ayyangar, A. and J. Vasseur, "Inter domain 592 GMPLS Traffic Engineering - RSVP-TE extensions",draft-ietf- 593 ccamp-inter-domain-rsvp-te-03 (work in progress), March 594 2006. 596 [PCE-COMM-GEN-REQ] Roux,J. and J. Ash, "PCE Communication Protocol 597 Generic Requirements", draft-ietf-pce-comm-protocol-gen- 598 reqs-06 (work in progress), May 2006. 600 [PCE-DISCO-REQ] Roux,J., "Requirements for Path Computation Element 601 (PCE) Discovery", draft-ietf-pce-discovery-reqs-05 (work in 602 progress), June 2006. 604 [INTER-AS-PCE] Bitar,N., Zhang,R., Kumaki,K., "Inter-AS PCE 605 Requirements", draft-bitar-zhang-interas-pce-req-00.txt 606 (work in progress), October 2005. 608 Author's Addresses 610 Mach Chen 611 Huawei Technologies Co.,Ltd 612 KuiKe Building, No.9 Xinxi Rd., 613 Shang-Di Information Industry Base, 614 Hai-Dian District Beijing P.R. China 100085 616 Email: mach@huawei.com 618 Intellectual Property Statement 620 The IETF takes no position regarding the validity or scope of any 621 Intellectual Property Rights or other rights that might be claimed to 622 pertain to the implementation or use of the technology described in 623 this document or the extent to which any license under such rights 624 might or might not be available; nor does it represent that it has 625 made any independent effort to identify any such rights. Information 626 on the procedures with respect to rights in RFC documents can be 627 found in BCP 78 and BCP 79. 629 Copies of IPR disclosures made to the IETF Secretariat and any 630 assurances of licenses to be made available, or the result of an 631 attempt made to obtain a general license or permission for the use of 632 such proprietary rights by implementers or users of this 633 specification can be obtained from the IETF on-line IPR repository at 634 http://www.ietf.org/ipr. 636 The IETF invites any interested party to bring to its attention any 637 copyrights, patents or patent applications, or other proprietary 638 rights that may cover technology that may be required to implement 639 this standard. Please address the information to the IETF at 640 ietf-ipr@ietf.org. 642 Disclaimer of Validity 644 This document and the information contained herein are provided on an 645 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 646 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 647 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 648 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 649 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 650 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Copyright Statement 654 Copyright (C) The Internet Society (2006). 656 This document is subject to the rights, licenses and restrictions 657 contained in BCP 78, and except as set forth therein, the authors 658 retain all their rights. 660 Acknowledgment 662 Funding for the RFC Editor function is currently provided by the 663 Internet Society.