idnits 2.17.00 (12 Aug 2021) /tmp/idnits16834/draft-chen-pce-forward-search-p2mp-path-21.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (10 January 2022) is 124 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 638, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 667, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Standards Track 10 January 2022 5 Expires: 14 July 2022 7 A Forward-Search P2MP TE LSP Inter-Domain Path Computation 8 draft-chen-pce-forward-search-p2mp-path-21 10 Abstract 12 This document presents a forward search procedure for computing a 13 path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label 14 Switched Path (LSP) crossing a number of domains through using 15 multiple Path Computation Elements (PCEs). In addition, extensions 16 to the Path Computation Element Communication Protocol (PCEP) for 17 supporting the 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 https://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 14 July 2022. 36 Copyright Notice 38 Copyright (c) 2022 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 (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Forward Search P2MP Path Computation . . . . . . . . . . . . 4 57 5.1. Overview of Procedure . . . . . . . . . . . . . . . . . . 5 58 5.2. Description of Procedure . . . . . . . . . . . . . . . . 5 59 5.3. Processing Request and Reply Messages . . . . . . . . . . 8 60 6. Comparing to BRPC . . . . . . . . . . . . . . . . . . . . . . 9 61 7. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 9 62 7.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 10 63 7.2. PCE Object . . . . . . . . . . . . . . . . . . . . . . . 11 64 7.3. Candidate Node List Object . . . . . . . . . . . . . . . 11 65 7.4. Node Flags Object . . . . . . . . . . . . . . . . . . . . 12 66 7.5. Request Message Extension . . . . . . . . . . . . . . . . 13 67 7.6. Reply Message Extension . . . . . . . . . . . . . . . . . 13 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 14 71 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 74 11.2. Informative References . . . . . . . . . . . . . . . . . 15 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 RFC 4105 "Requirements for Inter-Area MPLS TE" lists the requirements 80 for computing a shortest path for a TE LSP crossing multiple IGP 81 areas; and RFC 4216 "MPLS Inter-Autonomous System (AS) TE 82 Requirements" describes the requirements for computing a shortest 83 path for a TE LSP crossing multiple ASes. RFC 5671 "Applicability of 84 PCE to P2MP MPLS and GMPLS TE" examines the applicability of PCE to 85 path computation for P2MP TE LSPs in MPLS and GMPLS networks. 87 This document presents a forward search procedure to address these 88 requirements for computing a path for a P2MP TE LSP crossing domains 89 through using multiple Path Computation Elements (PCEs). 91 The procedure is called "Forward Search Shortest P2MP LSP Path 92 Crossing Domains" or FSPC for short. The major characteristics of 93 this procedure for computing a path for a P2MP TE LSP from a source 94 node to a number of destination nodes crossing multiple domains 95 include the following three ones. 97 1. It guarantees that the path computed from the source node to the 98 destination nodes is shortest. 100 2. It does not depend on any domain path tree or domain sequences 101 from the source node to the destination nodes. 103 3. Navigating a mesh of domains is simple and efficient. 105 2. Terminology 107 ABR: Area Border Router. Routers used to connect two IGP areas 108 (areas in OSPF or levels in IS-IS). 110 ASBR: Autonomous System Border Router. Routers used to connect 111 together ASes of the same or different service providers via one or 112 more inter-AS links. 114 Boundary Node (BN): a boundary node is either an ABR in the context 115 of inter-area Traffic Engineering or an ASBR in the context of inter- 116 AS Traffic Engineering. 118 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 119 the path found from the source node to the BN, where domain(n-1) is 120 the previous hop domain of domain(n). 122 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 123 the path found from the source node to the BN, where domain(n+1) is 124 the next hop domain of domain(n). 126 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 128 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 130 LSP: Label Switched Path. 132 LSR: Label Switching Router. 134 PCC: Path Computation Client. Any client application requesting a 135 path computation to be performed by a Path Computation Element. 137 PCE: Path Computation Element. An entity (component, application, or 138 network node) that is capable of computing a network path or route 139 based on a network graph and applying computational constraints. 141 PCE(i) is a PCE with the scope of domain(i). 143 TED: Traffic Engineering Database. 145 This document uses terminologies defined in RFC5440. 147 3. Conventions Used in This Document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC2119. 153 4. Requirements 155 This section summarizes the requirements specific for computing a 156 path for a Traffic Engineering (TE) LSP crossing multiple domains 157 (areas or ASes). More requirements for Inter-Area and Inter-AS MPLS 158 Traffic Engineering are described in RFC 4105 and RFC 4216. 160 A number of requirements specific for a solution to compute a path 161 for a TE LSP crossing multiple domains is listed as follows: 163 1. The solution SHOULD provide the capability to compute a shortest 164 path dynamically, satisfying a set of specified constraints 165 across multiple IGP areas. 167 2. The solution MUST provide the ability to reoptimize in a 168 minimally disruptive manner (make before break) an inter-area TE 169 LSP, should a more optimal path appear in any traversed IGP area. 171 3. The solution SHOULD provide mechanism(s) to compute a shortest 172 end-to-end path for a TE LSP crossing multiple ASes and 173 satisfying a set of specified constraints dynamically. 175 4. Once an inter-AS TE LSP has been established, and should there be 176 any resource or other changes inside anyone of the ASes, the 177 solution MUST be able to re-optimize the LSP accordingly and non- 178 disruptively, either upon expiration of a configurable timer or 179 upon being triggered by a network event or a manual request at 180 the TE tunnel Head-End. 182 5. Forward Search P2MP Path Computation 184 This section gives an overview of the forward search path computation 185 procedure (FSPC) to satisfy the requirements for computing a path for 186 a P2MP TE LSP crossing multiple domains described above and describes 187 the procedure in details. 189 5.1. Overview of Procedure 191 Simply speaking, the idea of FSPC for computing a path for an MPLS TE 192 P2MP LSP crossing multiple domains from a source node to a number of 193 destination nodes includes: 195 Start from the source node and the source domain. 197 Consider the optimal path segment from the source node to every exit 198 boundary and destination node of the source domain as a special link; 200 Consider the optimal path segment from an entry boundary node to 201 every exit boundary node and destination node of a domain as a 202 special link; and the optimal path segment is computed as needed. 204 The whole topology consisting of many domains can be considered as a 205 special virtual topology, which contains those special links and the 206 inter-domain links. 208 Compute a shortest path in this special topology from the source node 209 to the multiple destination nodes using CSPF. 211 FSPC running at any PCE just grows the result path list/tree in the 212 same way as normal CSPF on the special virtual topology. When the 213 result path list/tree reaches all the destination nodes, the shortest 214 path from the source node to the destination nodes is found and a 215 PCRep message with the path is sent to the PCE/PCC that sends the 216 PCReq message eventually. 218 5.2. Description of Procedure 220 Suppose that we have the following variables: 222 A current PCE named as CurrentPCE which is currently computing the 223 path. 225 A candidate node list named as CandidateNodeList, which contains the 226 nodes to each of which the temporary optimal path from the source 227 node is currently found and satisfies a set of given constraints. 228 Each node C in CandidateNodeList has the following information: 230 * the cost of the path from the source node to node C, 232 * the previous hop node P and the link between P and C, 234 * the PCE responsible for C (i.e., the PCE responsible for the 235 domain containing C. Alternatively, we may use the domain instead 236 of the PCE.), and 238 * the flags for C. 240 The flags include: 242 * bit D indicating that C is a Destination node if it is set; 244 * bit S indicating that C is the Source node if it is set; 246 * bit E indicating that C is an Exit boundary node if it is set; 248 * bit I indicating that C is an entry boundary node if it is set; 249 and 251 * bit T indicating that C is on result path Tree if it is set. 253 The nodes in CandidateNodeList are ordered by path cost. 255 Initially, CandidateNodeList contains a Source Node, with path cost 256 0, PCE responsible for the source domain, and flags with S bit set. 257 It also contains every destination node, with path cost infinity and 258 flags with D bit set. 260 A result path list or tree named as ResultPathTree, which contains 261 the shortest paths from the source node to the boundary nodes and 262 destination nodes. Initially, ResultPathTree is empty. 264 Alternatively, the result path list or tree can be combined into the 265 candidate node list. We may set bit T to one in the node flags for 266 the candidate node when grafting it into the existing result path 267 list or tree. Thus all the candidate nodes with bit T set to one in 268 the candidate list constitute the result path tree or list. 270 FSPC for computing a path for an MPLS TE P2MP LSP crossing a number 271 of domains from a source node to a number of destination nodes can be 272 described as follows: 274 Initially, a PCC sends a PCE responsible for the source domain a 275 request with CandidateNodeList and ResultPathTree initialized. 277 When the PCE responsible for a domain (called current domain) 278 receives a request for computing the path for the MPLS TE P2MP LSP, 279 it checks whether the current PCE is the PCE responsible for the node 280 C with the minimum cost in the CandidateNodeList. If it is, then 281 remove C from CandidateNodeList and graft it into ResultPathTree 282 (i.e., set flag bit T of node C to one); otherwise, a PCReq message 283 is sent to the PCE for node C. 285 Suppose that node C is in the current domain. The ResultPathTree is 286 built from C in the following steps. 288 If node C is a destination node (i.e., the Destination Node (D) bit 289 in the Flags is set), then check whether the path cost to node C is 290 infinity. If it is, then we can not find any path for the P2MP LSP, 291 and a repply message with failure reasons is sent; otherwise, if all 292 the destinations are on the result path tree, then the shortest path 293 is found and a PCRep message with the path is sent to the PCE/PCC 294 which sends the request to the current PCE. 296 If node C is an entry boundary node or the source node, then the 297 optimal path segments from node C to every destination node and every 298 exit boundary node of the current domain that is not on the result 299 path tree and satisfies the given constraints are computed through 300 using CSPF and as special links. 302 For every node N connected to node C through a special link (i.e., 303 the optimal path segment satisfying the given constraints), it is 304 merged into CandidateNodeList. The cost to node N is the sum of the 305 cost to node C and the cost of the special link (i.e., the path 306 segment) between C and N. If node N is not in the candidate node 307 list, then node N is added into the list with the cost to node N, 308 node C as its previous hop node and a PCE for node N. The PCE for 309 node N is the current PCE if node N is an ASBR; otherwise (node N is 310 an ABR, an exit boundary node of the current domain and an entry 311 boundary node of the domain next to the current domain) the PCE for 312 node N is the PCE for the next domain. If node N is in the candidate 313 node list and the cost to node N through node C is less than the cost 314 to node N in the list, then replace the cost to node N in the list 315 with the cost to node N through node C and the previous hop to node N 316 in the list with node C. 318 If node C is an exit boundary node and there are inter-domain links 319 connecting to it (i.e., node C is an ASBR) and satisfying the 320 constraints, then for every node N connecting to C, satisfying the 321 constraints and not on the result path tree, it is merged into the 322 candidate node list. The cost to node N is the sum of the cost to 323 node C and the cost of the link between C and N. If node N is not in 324 the candidate node list, then node N is added into the list with the 325 cost to node N, node C as its previous hop node and the PCE for node 326 N. If node N is in the candidate node list and the cost to node N 327 through node C is less than the cost to node N in the list, then 328 replace the cost to node N in the list with the cost to node N 329 through node C and the previous hop to node N in the list with node 330 C. 332 If the CurrentPCE is the same as the PCE for the node D with the 333 minimum cost in CandidateNodeList, then the node D is removed from 334 CandidateNodeList and grafted to ResultPathTree (i.e., set flag bit T 335 of node D to one), and the above steps are repeated; otherwise, a 336 request message is to be sent to the PCE for node D. 338 5.3. Processing Request and Reply Messages 340 In this section, we describe the processing of the request and reply 341 messages with Forward search bit set for FSPC. Each of the request 342 and reply messages mentioned below has its Forward search bit set 343 even though we do not indicate this explicitly. 345 In the case that a reply message is a final reply, which contains the 346 optimal path from the source to the destination, the reply message is 347 sent toward the PCC along the path that the request message goes from 348 the PCC to the current PCE in reverse direction. 350 In the case that a request message is to be sent to the PCE for node 351 D with the minimum cost in the candidate node list and there is a PCE 352 session between the current domain and the next domain containing 353 node D, the current PCE sends the PCE for node D through the session 354 a request message with the source node, the destination node, 355 CandidateNodeList and ResultPathTree. 357 In the case that a request message is to be sent to the PCE for node 358 D and there is not any PCE session between the current PCE and the 359 PCE for node D, a reply message is sent toward a branch point on the 360 result path tree from the current domain along the path that the 361 request message goes from the PCC to the current PCE in reverse 362 direction. From the branch point, there is a downward path to the 363 domain containing the previous hop node of node D on the result path 364 tree and to the domain containing node D. At this branch point, the 365 request message is sent to the PCE for node D along the downward 366 path. 368 Suppose that node D has the minimum cost in CandidateNodeList when a 369 PCE receives a request message or a reply message containing 370 CandidateNodeList. 372 When a PCE (current PCE) for a domain (current domain) receives a 373 reply message PCRep, it checks whether the reply is a final reply 374 with the optimal path from the source to the destination. If the 375 reply is the final reply, the current PCE sends the reply to the PCE 376 that sends the request to the current PCE; otherwise, it checks 377 whether there is a path from the current domain to the domain 378 containing the previous hop node of node D on ResultPathTree and to 379 the domain containing node D. If there is a path, the PCE sends a 380 request PCReq to the PCE responsible for the next domain along the 381 path; otherwise, it sends a reply PCRep to the PCE that sends the 382 request to the current PCE. 384 When a PCE receives a request PCReq, it checks whether the current 385 domain contains node D. If it does, then node D is removed from 386 CandidateNodeList and grafted to ResultPathTree (i.e., set flag bit T 387 of node D to one), and the above steps in the previous sub section 388 are repeated; otherwise, the PCE sends a request PCReq to the PCE 389 responsible for the next domain along the path from the current 390 domain to the domain containing the previous hop node of node D on 391 ResultPathTree and to the domain containing node D. 393 6. Comparing to BRPC 395 RFC 5441 describes the Backward Recursive Path Computation (BRPC) 396 algorithm or procedure for computing an MPLS TE P2P LSP path from a 397 source node to a destination node crossing multiple domains. 398 Comparing to BRPC, there are a number of differences between BRPC and 399 the Forward-Search P2MP TE LSP Inter-Domain Path Computation (FSPC). 400 Some of the differences are briefed below. 402 At first, BRPC is for computing a shortest path from a source node to 403 a destination node crossing multiple domains. FSPC is for computing 404 a shortest path from a source node to a number of destination nodes 405 crossing multiple domains. 407 Secondly, for BRPC to compute a shortest path from a source node to a 408 destination node crossing multiple domains, we MUST provide a 409 sequence of domains from the source node to the destination node to 410 BRPC in advance. FSPC does not need any sequence of domains for 411 computing a shortest inter-domain P2MP path. 413 Moreover, for a given sequence of domains domain(1), domain(2), ... , 414 domain(n), BRPC searches the shortest path from domain(n), to 415 domain(n-1), until domain(1). Thus it is hard for BRPC to be 416 extended for computing a shortest path from a source node to a number 417 of destination nodes crossing multiple domains. FSPC calculates a 418 shortest path in a special topology from the source node to the 419 destination nodes using CSPF. 421 7. Extensions to PCEP 423 The extensions to PCEP for FSPC include the definition of a new flag 424 in the RP object, a result path list/tree and a candidate node list 425 in a request message. 427 7.1. RP Object Extension 429 The following flag is added into the RP Object: 431 The F bit is added in the flag bits field of the RP object to tell 432 the receiver of the message that the request/reply is for FSPC. 434 o F (FSPC bit - 1 bit): 435 0: This indicates that this is not PCReq/PCRep for FSPC. 436 1: This indicates that this is PCReq or PCRep message for FSPC. 438 The T bit is added in the flag bits field of the RP object to tell 439 the receiver of the message that the reply is for transferring a 440 request message to the domain containing the node with minimum cost 441 in the candidate list. 443 o T (Transfer request bit - 1 bit): 444 0: This indicates that this is not a PCRep 445 for transferring a request message. 446 1: This indicates that this is a PCRep message 447 for transferring a request message. 449 Setting Transfer request T-bit in a RP Object to one indicates that a 450 reply message containing the RP Object is for transferring a request 451 message to the domain containing the node with minimum cost in the 452 candidate list. 454 The IANA request is referenced in Section below (Request Parameter 455 Bit Flags) of this document. 457 This F bit with the N bit defined in RFC6006 can indicate whether the 458 request/reply is for FSPC of an MPLS TE P2MP LSP or an MPLS TE P2P 459 LSP. 461 o F = 1 and N = 1: This indicates that this is a PCReq/PCRep 462 message for FSPC of an MPLS TE P2MP LSP. 463 o F = 1 and N = 0: This indicates that this is a PCReq/PCRep 464 message for FSPC of an MPLS TE P2P LSP. 466 7.2. PCE Object 468 The figure below illustrates a PCE IPv4 object body (Object-Type=1), 469 which comprises a PCE IPv4 address. The PCE IPv4 address object 470 indicates the IPv4 address of a PCE , with which a PCE session may be 471 established and to which a request message may be sent. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | PCE IPv4 address | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 The format of the PCE object body for IPv6 (Object-Type=2) is as 480 follows: 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | | 486 | PCE IPv6 address (16 bytes) | 487 | | 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 7.3. Candidate Node List Object 493 The candidate-node-list-obj object contains a list of candidate 494 nodes. A new PCEP object class and type are requested for it. The 495 format of the candidate-node-list-obj object body is as follows: 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | 501 // // 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 The following is the definition of the candidate node list. 507 ::= 508 [] 509 ::= 510 512 ::= [] 513 [] 514 [] 516 The ERO in a candidate node contain just the path segment of the last 517 link of the path, which is from the previous hop node of the tail end 518 node of the path to the tail end node. With this information, we can 519 graft the candidate node into the existing result path list or tree. 521 Simply speaking, a candidate node has the same or similar format of a 522 path defined in RFC 5440, but the ERO in the candidate node just 523 contain the tail end node of the path and its previous hop, and the 524 candidate node may contain two new objects PCE and node flags. 526 7.4. Node Flags Object 528 The Node Flags object is used to indicate the characteristics of the 529 node in a candidate node list in a request or reply message for FSPC. 530 The Node Flags object comprises a Reserved field, and a number of 531 Flags. 533 The format of the Node Flags object body is as follows: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |D|S|I|E|N| Flags | Reserved | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 where 543 o D = 1: The node is a destination node. 544 o S = 1: The node is a source node. 545 o I = 1: The node is an entry boundary node. 546 o E = 1: The node is an exit boundary node. 547 o T = 1: The node is on the result path tree. 549 7.5. Request Message Extension 551 Below is the message format for a request message with the extension 552 of a result path list and a candidate node list: 554 ::= 555 556 ::= [] [] 557 [] [] [[]] 558 [] [] 559 [] 560 [] 561 where: 562 ::=[] 563 ::= 564 ::=[] [] [] 565 [] 567 contains a 569 ::= 570 [] 571 ::= 572 574 ::= [] 575 [] 576 [] 578 Figure 1: The Format for a Request Message 580 The definition for the result path list that may be added into a 581 request message is the same as that for the path list in a reply 582 message that is described in RFC5440. 584 7.6. Reply Message Extension 586 Below is the message format for a reply message with the extension of 587 a result path list and a candidate node list: 589 ::= 590 591 ::= [] 592 [] [] 593 [] 594 [] 595 where: 596 contains a 598 If the path from the source to the destinations is not found yet and 599 there are still chances to find a path (i.e., the candidate list is 600 not empty), the reply message contains candidate-node-list-obj 601 consisting of the information of the candidate list, which is 602 encoded. In this case, the Transfer request T-bit in the RP Object 603 is set to one. 605 If the path from the source to the destination is found, the reply 606 message contains path-list comprising the information of the path. 608 8. Security Considerations 610 The mechanism described in this document does not raise any new 611 security issues for the PCEP protocols. 613 9. IANA Considerations 615 This section specifies requests for IANA allocation. 617 9.1. Request Parameter Bit Flags 619 A new RP Object Flag has been defined in this document. IANA is 620 requested to make the following allocation from the "PCEP RP Object 621 Flag Field" Sub-Registry: 623 Bit Description Reference 624 18 FSPC (F-bit) This I-D 625 19 Transfer Request (T-bit) This I-D 627 10. Acknowledgement 629 The author would like to appreciate Dhruv Dhody for his great 630 contributions and to thank Julien Meuric, Daniel King, Cyril 631 Margaria, Ramon Casellas, Olivier Dugeon and Oscar Gonzalez de Dios 632 for their valuable comments on this draft. 634 11. References 636 11.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 644 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 645 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 646 . 648 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 649 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 650 DOI 10.17487/RFC5440, March 2009, 651 . 653 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 654 Ali, Z., and J. Meuric, "Extensions to the Path 655 Computation Element Communication Protocol (PCEP) for 656 Point-to-Multipoint Traffic Engineering Label Switched 657 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 658 . 660 11.2. Informative References 662 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 663 Computation Element (PCE)-Based Architecture", RFC 4655, 664 DOI 10.17487/RFC4655, August 2006, 665 . 667 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 668 (PCC) - Path Computation Element (PCE) Requirements for 669 Point-to-Multipoint MPLS-TE", RFC 5862, 670 DOI 10.17487/RFC5862, June 2010, 671 . 673 Author's Address 675 Huaimo Chen 676 Futurewei 677 Boston, MA, 678 United States of America 680 Email: Huaimo.chen@futurewei.com