idnits 2.17.1 draft-chen-pce-forward-search-p2p-path-computation-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2012) is 4400 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) == Unused Reference: 'RFC2119' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 685, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Chen 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 12, 2012 March 11, 2012 7 A Forward-Search P2P TE LSP Inter-Domain Path Computation 8 draft-chen-pce-forward-search-p2p-path-computation-03.txt 10 Abstract 12 This document presents a forward search procedure for computing paths 13 for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched 14 Paths (LSPs) crossing a number of domains using multiple Path 15 Computation Elements (PCEs). In addition, extensions to the Path 16 Computation Element Communication Protocol (PCEP) for supporting the 17 forward search procedure are described. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 12, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Forward Search Path Computation . . . . . . . . . . . . . . . 5 58 5.1. Overview of Procedure . . . . . . . . . . . . . . . . . . 5 59 5.2. Description of Procedure . . . . . . . . . . . . . . . . . 5 60 5.3. Processing Request and Reply Messages . . . . . . . . . . 8 61 6. Comparing to BRPC . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 10 63 7.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 10 64 7.2. PCE Object . . . . . . . . . . . . . . . . . . . . . . . . 11 65 7.3. Node Flags Object . . . . . . . . . . . . . . . . . . . . 11 66 7.4. Candidate Node List Object . . . . . . . . . . . . . . . . 12 67 7.5. Request Message Extension . . . . . . . . . . . . . . . . 13 68 7.6. Reply Message Extension . . . . . . . . . . . . . . . . . 14 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 15 72 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 It would be useful to extend MPLS TE capabilities across multiple 81 domains (i.e., IGP areas or Autonomous Systems) to support inter- 82 domain resources optimization, to provide strict QoS guarantees 83 between two edge routers located within distinct domains. 85 RFC 4105 "Requirements for Inter-Area MPLS TE" lists the requirements 86 for computing a shortest path for a TE LSP crossing multiple IGP 87 areas; and RFC 4216 "MPLS Inter-Autonomous System (AS) TE 88 Requirements" describes the requirements for computing a shortest 89 path for a TE LSP crossing multiple ASes. RFC 4655 "A PCE-Based 90 Architecture" discusses centralized and distributed computation 91 models for the computation of a path for a TE LSP crossing multiple 92 domains. 94 This document presents a forward search procedure to address these 95 requirements using multiple Path Computation Elements (PCEs). This 96 procedure guarantees that the path found from the source to the 97 destination is shortest. It does not depend on any sequence of 98 domains from the source node to the destination node. Navigating a 99 mesh of domains is simple and efficient. 101 2. Terminology 103 ABR: Area Border Router. Routers used to connect two IGP areas 104 (areas in OSPF or levels in IS-IS). 106 ASBR: Autonomous System Border Router. Routers used to connect 107 together ASes of the same or different service providers via one or 108 more inter-AS links. 110 Boundary Node (BN): a boundary node is either an ABR in the context 111 of inter-area Traffic Engineering or an ASBR in the context of 112 inter-AS Traffic Engineering. 114 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 115 the path found from the source node to the BN, where domain(n-1) is 116 the previous hop domain of domain(n). 118 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 119 the path found from the source node to the BN, where domain(n+1) is 120 the next hop domain of domain(n). 122 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 124 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 126 LSP: Label Switched Path. 128 LSR: Label Switching Router. 130 PCC: Path Computation Client. Any client application requesting a 131 path computation to be performed by a Path Computation Element. 133 PCE: Path Computation Element. An entity (component, application, or 134 network node) that is capable of computing a network path or route 135 based on a network graph and applying computational constraints. 137 PCE(i) is a PCE with the scope of domain(i). 139 TED: Traffic Engineering Database. 141 This document uses terminologies defined in RFC 5440. 143 3. Conventions Used in This Document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC2119. 149 4. Requirements 151 This section summarizes the requirements specific for computing a 152 path for a P2P Traffic Engineering (TE) LSP crossing multiple domains 153 (areas or ASes). More requirements for Inter-Area and Inter-AS MPLS 154 Traffic Engineering are described in RFC 4105 and RFC 4216. 156 A number of requirements specific for a solution to compute a path 157 for a P2P TE LSP crossing multiple domains is listed as follows: 159 1. The solution SHOULD provide the capability to compute a shortest 160 path dynamically, satisfying a set of specified constraints 161 across multiple IGP areas. 163 2. The solution MUST provide the ability to reoptimize in a 164 minimally disruptive manner (make before break) an inter-area TE 165 LSP, should a more optimal path appear in any traversed IGP area. 167 3. The solution SHOULD provide mechanism(s) to compute a shortest 168 end-to-end path for a TE LSP crossing multiple ASes and 169 satisfying a set of specified constraints dynamically. 171 4. Once an inter-AS TE LSP has been established, and should there be 172 any resource or other changes inside anyone of the ASes, the 173 solution MUST be able to re-optimize the LSP accordingly and non- 174 disruptively, either upon expiration of a configurable timer or 175 upon being triggered by a network event or a manual request at 176 the TE tunnel Head-End. 178 5. Forward Search Path Computation 180 This section gives an overview of the forward search path computation 181 procedure to satisfy the requirements described above and describes 182 the procedure in details. 184 5.1. Overview of Procedure 186 Simply speaking, the idea of the forward search path computation 187 procedure for computing a path for an MPLS TE P2P LSP crossing 188 multiple domains from a source node to a destination node includes: 190 Start from the source node and the source domain. 192 Consider the optimal path segment from the source node to every exit 193 boundary node of the source domain as a special link; 195 Consider the optimal path segment from an entry boundary node to 196 every exit boundary node and the destination node of a domain as a 197 special link; and the optimal path segment is computed as needed. 199 The whole topology consisting of many domains can be considered as a 200 special topology, which contains those special links and the inter- 201 domain links. 203 Compute an optimal path in this special topology from the source node 204 to the destination node using CSPF. 206 5.2. Description of Procedure 208 Suppose that we have the following variables: 210 A current PCE named as CurrentPCE which is currently computing the 211 path. 213 A candidate node list named as CandidateNodeList, which contains the 214 nodes to each of which the temporary optimal path from the source 215 node is currently found and satisfies a set of given constraints. 216 The information about each node C in CandidateNodeList consists of: 218 o the cost of the path from the source node to node C, 220 o the previous hop node P and the link between P and C, 222 o the PCE responsible for C (i.e., the PCE responsible for the 223 domain containing C. Alternatively, we may use the domain instead 224 of the PCE.), and 226 o the flags for C. The flags include: 228 * bit D indicating that C is a Destination node if it is set, 230 * bit S indicating that C is the Source node if it is set, 232 * bit E indicating that C is an Exit boundary node if it is set, 234 * bit I indicating that C is an entry boundary node if it is set, 235 and 237 * bit T indicating that C is on result path Tree if it is set. 239 The nodes in CandidateNodeList are ordered by path cost. Initially, 240 CandidateNodeList contains only a Source Node, with path cost 0, PCE 241 responsible for the source domain. 243 A result path list or tree named as ResultPathTree, which contains 244 the final optimal paths from the source node to the boundary nodes or 245 the destination node. Initially, ResultPathTree is empty. 247 Alternatively, the result path list or tree can be combined into the 248 candidate node list. We may set bit T to one in the node flags for 249 the candidate node when grafting it into the existing result path 250 list or tree. Thus all the candidate nodes with bit T set to one in 251 the candidate list constitute the result path tree or list. 253 The Forward Search Path Computation procedure for computing the path 254 for the MPLS TE P2P LSP is described as follows: 256 Initially, a PCC sets ResultPathTree to empty and CandidateNodeList 257 to contain the source node and sends PCE responsible for the source 258 domain a PCReq with the source node, the destination node, 259 CandidateNodeList and ResultPathTree. 261 When the PCE responsible for a domain (called current domain) 262 receives a request for computing the path for the MPLS TE P2P LSP, it 263 checks whether the current PCE is the PCE responsible for the node C 264 with the minimum cost in the CandidateNodeList. If it is, then 265 remove C from CandidateNodeList and graft it into ResultPathTree 266 (i.e., set flag bit T of node C to one); otherwise, a PCReq message 267 is sent to the PCE for node C. 269 Suppose that node C is in the current domain. The ResultPathTree is 270 built from C in the following steps. 272 If node C is the destination node, then the optimal path from the 273 source node to the destination node is found, and a PCRep message 274 with the path is sent to the PCE/PCC which sends the request to the 275 current PCE. 277 If node C is an entry boundary node or the source node, then the 278 optimal path segments from node C to the destination node (if it is 279 in the current domain) and every exit boundary node of the current 280 domain that is not on the result path tree and satisfies the given 281 constraints are computed through using CSPF and as special links. 283 For every node N connected to node C through a special link (i.e., 284 the optimal path segment satisfying the given constraints), it is 285 merged into CandidateNodeList. The cost to node N is the sum of the 286 cost to node C and the cost of the special link (i.e., the path 287 segment) between C and N. If node N is not in the candidate node 288 list, then node N is added into the list with the cost to node N, 289 node C as its previous hop node and the PCE for node N. The PCE for 290 node N is the current PCE if node N is an ASBR; otherwise (node N is 291 an ABR, an exit boundary node of the current domain and an entry 292 boundary node of the domain next to the current domain) the PCE for 293 node N is the PCE for the next domain. If node N is in the candidate 294 node list and the cost to node N through node C is less than the cost 295 to node N in the list, then replace the cost to node N in the list 296 with the cost to node N through node C and the previous hop to node N 297 in the list with node C. 299 If node C is an exit boundary node and there are inter-domain links 300 connecting to it (i.e., node C is an ASBR) and satisfying the 301 constraints, then for every node N connecting to C, satisfying the 302 constraints and not on the result path tree, it is merged into the 303 candidate node list. The cost to node N is the sum of the cost to 304 node C and the cost of the link between C and N. If node N is not in 305 the candidate node list, then node N is added into the list with the 306 cost to node N, node C as its previous hop node and the PCE for node 307 N. If node N is in the candidate node list and the cost to node N 308 through node C is less than the cost to node N in the list, then 309 replace the cost to node N in the list with the cost to node N 310 through node C and the previous hop to node N in the list with node 311 C. 313 If the CurrentPCE is the same as the PCE for the node D with the 314 minimum cost in CandidateNodeList, then the node D is removed from 315 CandidateNodeList and grafted to ResultPathTree (i.e., set flag bit T 316 of node D to one), and the above steps are repeated; otherwise, a 317 request message is to be sent to the PCE for node D. 319 5.3. Processing Request and Reply Messages 321 In this section, we describe the processing of the request and reply 322 messages with Forward search bit set for forward search inter-domain 323 path computation. Each of the request and reply messages mentioned 324 below has its Forward search bit set even though we do not indicate 325 this explicitly. 327 In the case that a reply message is a final reply, which contains the 328 optimal path from the source to the destination, the reply message is 329 sent toward the PCC along the path that the request message goes from 330 the PCC to the current PCE in reverse direction. 332 In the case that a request message is to be sent to the PCE for node 333 D with the minimum cost in the candidate node list and there is a PCE 334 session between the current domain and the next domain containing 335 node D, the current PCE sends the PCE for node D through the session 336 a request message with the source node, the destination node, 337 CandidateNodeList and ResultPathTree. 339 In the case that a request message is to be sent to the PCE for node 340 D and there is not any PCE session between the current PCE and the 341 PCE for node D, a reply message is sent toward a branch point on the 342 result path tree from the current domain along the path that the 343 request message goes from the PCC to the current PCE in reverse 344 direction. From the branch point, there is a downward path to the 345 domain containing the previous hop node of node D on the result path 346 tree and to the domain containing node D. At this branch point, the 347 request message is sent to the PCE for node D along the downward 348 path. 350 Suppose that node D has the minimum cost in CandidateNodeList when a 351 PCE receives a request message or a reply message containing 352 CandidateNodeList. 354 When a PCE (current PCE) for a domain (current domain) receives a 355 reply message PCRep, it checks whether the reply is a final reply 356 with the optimal path from the source to the destination. If the 357 reply is the final reply, the current PCE sends the reply to the PCE 358 that sends the request to the current PCE; otherwise, it checks 359 whether there is a path from the current domain to the domain 360 containing the previous hop node of node D on ResultPathTree and to 361 the domain containing node D. If there is a path, the PCE sends a 362 request PCReq to the PCE responsible for the next domain along the 363 path; otherwise, it sends a reply PCRep to the PCE that sends the 364 request to the current PCE. 366 When a PCE receives a request PCReq, it checks whether the current 367 domain contains node D. If it does, then node D is removed from 368 CandidateNodeList and grafted to ResultPathTree (i.e., set flag bit T 369 of node D to one), and the above steps in the previous sub section 370 are repeated; otherwise, the PCE sends a request PCReq to the PCE 371 responsible for the next domain along the path from the current 372 domain to the domain containing the previous hop node of node D on 373 ResultPathTree and to the domain containing node D. 375 6. Comparing to BRPC 377 RFC 5441 describes the Backward Recursive Path Computation (BRPC) 378 algorithm or procedure for computing an MPLS TE P2P LSP path from a 379 source node to a destination node crossing multiple domains. 380 Comparing to BRPC, there are a number of differences between BRPC and 381 the Forward-Search P2P TE LSP Inter-Domain Path Computation. Some of 382 the differences are briefed below. 384 First, for BRPC to compute a shortest path from a source node to a 385 destination node crossing multiple domains, we MUST provide a 386 sequence of domains from the source node to the destination node to 387 BRPC in advance. It is a big burden and very challenging for users 388 to provide a sequence of domains for every LSP path crossing domains 389 in general. In addition, it increases the cost of operation and 390 maintenance of the network. The Forward-Search P2P TE LSP Inter- 391 Domain Path Computation does not need any sequence of domains for 392 computing a shortest path. 394 Secondly, for a given sequence of domains domain(1), domain(2), ... , 395 domain(n), BRPC searches the shortest path from domain(n), to 396 domain(n-1), until domain(1) along the reverse order of the given 397 sequence of domain. It will get the shortest path within the given 398 domain sesuence. The Forward-Search P2P TE LSP Inter-Domain Path 399 Computation calculates an optimal path in a special topology from the 400 source node to the destination node using CSPF. It will find the 401 shortest path within all the domains. 403 Moreover, if the sequence of domains from the source node to the 404 destination node provided to BRPC does not contain the shortest path 405 from the source to the destination, then the path computed by BRPC is 406 not optimal. The Forward-Search P2P TE LSP Inter-Domain Path 407 Computation guarantees that the path found is optimal. 409 7. Extensions to PCEP 411 This section describes the extensions to PCEP for Forward Search Path 412 Computation. The extensions include the definition of a new flag in 413 the RP object, a result path list and a candidate node list in the 414 PCReq message. 416 7.1. RP Object Extension 418 The following flags are added into the RP Object: 420 The F bit is added in the flag bits field of the RP object to tell 421 the receiver of the message that the request/reply is for Forward 422 Search Path Computation. 424 o F (Forward search Path Computation bit - 1 bit): 426 0: This indicates that this is not a PCReq/PCRep 427 for Forward Search Path Computation. 429 1: This indicates that this is a PCReq or PCRep message 430 for Forward Search Path Computation. 432 The T bit is added in the flag bits field of the RP object to tell 433 the receiver of the message that the reply is for transferring a 434 request message to the domain containing the node with minimum cost 435 in the candidate list. 437 o T (Transfer request bit - 1 bit): 439 0: This indicates that this is not a PCRep 440 for transferring a request message. 442 1: This indicates that this is a PCRep message 443 for transferring a request message. 445 Setting Transfer request T-bit in a RP Object to one indicates that a 446 reply message containing the RP Object is for transferring a request 447 message to the domain containing the node with minimum cost in the 448 candidate list. 450 The IANA request is referenced in Section below (Request Parameter 451 Bit Flags) of this document. 453 This F bit with the N bit defined in RFC6006 can indicate whether the 454 request/reply is for Forward Search Path Computation of an MPLS TE 455 P2P LSP or an MPLS TE P2MP LSP. 457 o F = 1 and N = 0: This indicates that this is a PCReq/PCRep 458 message for Forward Search Path Computation 459 of an MPLS TE P2P LSP. 461 o F = 1 and N = 1: This indicates that this is a PCReq/PCRep 462 message for Forward Search Path Computation 463 of an MPLS TE P2MP LSP. 465 7.2. PCE Object 467 The figure below illustrates a PCE IPv4 object body (Object-Type=1), 468 which comprises a PCE IPv4 address. The PCE IPv4 address object 469 indicates the IPv4 address of a PCE , with which a PCE session may be 470 established and to which a request message may be sent. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | PCE IPv4 address | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 1: PCE Object Body for IPv4 480 The format of the PCE object body for IPv6 (Object-Type=2) is as 481 follows: 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 | PCE IPv6 address (16 bytes) | 488 | | 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 2: PCE Object Body for IPv6 494 7.3. Node Flags Object 496 The Node Flags object is used to indicate the characteristics of the 497 node in a candidate node list in a request or reply message for 498 Forward Search Inter-domain Path Computation. The Node Flags object 499 comprises a Reserved field, and a number of Flags. 501 The format of the Node Flags object body is as follows: 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |D|S|I|E|T| Flags | Reserved | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Figure 3: Node Flags Object Body 511 where 513 o D = 1: The node is a destination node. 514 o S = 1: The node is a source node. 515 o I = 1: The node is an entry boundary node. 516 o E = 1: The node is an exit boundary node. 517 o T = 1: The node is on the result path tree. 519 7.4. Candidate Node List Object 521 The candidate-node-list-obj object contains the nodes in the 522 candidate node list. A new PCEP object class and type are requested 523 for it. The format of the candidate-node-list-obj object body is as 524 follows: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 // (a list of s) // 531 | | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Figure 4: Candidate Node List Object 536 The following is the definition of candidate node list, which may 537 contain Node Flags. 539 ::= 540 [] 541 ::= 542 544 ::= [] 545 [] 546 [] 547 ::=[] 548 [] 549 [] 550 [] 552 The ERO in a candidate node contain just the path segment of the last 553 link of the path, which is from the previous hop node of the tail end 554 node of the path to the tail end node. With this information, we can 555 graft the candidate node into the existing result path list or tree. 557 Simply speaking, a candidate node has the same or similar format of a 558 path defined in RFC 5440, but the ERO in the candidate node just 559 contain the tail end node of the path and its previous hop, and the 560 candidate path may contain two new objects PCE and node flags. 562 7.5. Request Message Extension 564 Below is the message format for a request message with the extension 565 of a result path list and a candidate node list: 567 ::= 568 [] 569 570 ::=[] 571 ::= 572 573 [] 574 [] 575 [] 576 [] 577 [[]] 578 [] 579 [] 580 [] 581 [] 583 where: 584 ::=[] 585 ::= 586 ::=[] 587 [] 588 [] 589 [] 591 contains a 593 The definition for the result path list that may be added into a 594 request message is the same as that for the path list in a reply 595 message that is described in RFC5440. 597 7.6. Reply Message Extension 599 Below is the message format for a reply message with the extension of 600 a result path list and a candidate node list: 602 ::= 603 604 ::=[] 605 ::= 606 [] 607 [] 608 [] 609 [] 610 [] 612 where: 613 contains a 615 If the path from the source to the destination is not found yet and 616 there are still chances to find a path (i.e., the candidate list is 617 not empty), the reply message contains candidate-node-list-obj 618 consisting of the information of the candidate list, which is 619 encoded. In this case, the Transfer request T-bit in the RP Object 620 is set to one. 622 If the path from the source to the destination is found, the reply 623 message contains path-list comprising the information of the path. 625 8. Security Considerations 627 The mechanism described in this document does not raise any new 628 security issues for the PCEP protocols. 630 9. IANA Considerations 632 This section specifies requests for IANA allocation. 634 9.1. Request Parameter Bit Flags 636 Two new RP Object Flags have been defined in this document. IANA is 637 requested to make the following allocation from the "PCEP RP Object 638 Flag Field" Sub-Registry: 640 Bit Description Reference 641 18 Forward Path Computation (F-bit) This I-D 642 19 Transfer Request (T-bit) This I-D 644 Setting Forward Path Computation F-bit in a RP Object to one 645 indicates that a request/reply message containing the RP Object is 646 for forward path computation. 648 Setting Transfer Request T-bit in a RP Object to one indicates that a 649 reply message containing the RP Object is for transferring a request 650 message to the domain containing the node with minimum cost in the 651 candidate list. 653 10. Acknowledgement 655 The authors would like to thank Julien Meuric, Daniel King, Cyril 656 Margaria, Ramon Casellas, Olivier Dugeon, and Oscar Gonzalez de Dios 657 for their valuable comments on this draft. 659 11. References 661 11.1. Normative References 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, March 1997. 666 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 667 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 668 Tunnels", RFC 3209, December 2001. 670 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 671 (PCE) Communication Protocol (PCEP)", RFC 5440, 672 March 2009. 674 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 675 and J. Meuric, "Extensions to the Path Computation Element 676 Communication Protocol (PCEP) for Point-to-Multipoint 677 Traffic Engineering Label Switched Paths", RFC 6006, 678 September 2010. 680 11.2. Informative References 682 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 683 Element (PCE)-Based Architecture", RFC 4655, August 2006. 685 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 686 (PCC) - Path Computation Element (PCE) Requirements for 687 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 689 Authors' Addresses 691 Huaimo Chen 692 Huawei Technologies 693 Boston, MA 694 USA 696 Email: Huaimochen@huawei.com 698 Dhruv Dhody 699 Huawei Technologies 700 Leela Palace, Bangalore, Karnataka 560008 701 INDIA 703 Email: dhruv.dhody@huawei.com