idnits 2.17.1 draft-chen-pce-forward-search-p2mp-path-17.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 6, 2020) is 1543 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 639, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 668, 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 PCE Working Group H. Chen 3 Internet-Draft Futurewei 4 Intended status: Standards Track January 6, 2020 5 Expires: July 9, 2020 7 A Forward-Search P2MP TE LSP Inter-Domain Path Computation 8 draft-chen-pce-forward-search-p2mp-path-17 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 July 9, 2020. 36 Copyright Notice 38 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Forward Search P2MP Path Computation . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 9 63 7.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 10 64 7.2. PCE Object . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.3. Candidate Node List Object . . . . . . . . . . . . . . . 11 66 7.4. Node Flags Object . . . . . . . . . . . . . . . . . . . . 12 67 7.5. Request Message Extension . . . . . . . . . . . . . . . . 12 68 7.6. Reply Message Extension . . . . . . . . . . . . . . . . . 13 69 8. Security Considerations . . . . . . . . . . . . . . . . . . 14 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 14 72 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 11.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 RFC 4105 "Requirements for Inter-Area MPLS TE" lists the requirements 81 for computing a shortest path for a TE LSP crossing multiple IGP 82 areas; and RFC 4216 "MPLS Inter-Autonomous System (AS) TE 83 Requirements" describes the requirements for computing a shortest 84 path for a TE LSP crossing multiple ASes. RFC 5671 "Applicability of 85 PCE to P2MP MPLS and GMPLS TE" examines the applicability of PCE to 86 path computation for P2MP TE LSPs in MPLS and GMPLS networks. 88 This document presents a forward search procedure to address these 89 requirements for computing a path for a P2MP TE LSP crossing domains 90 through using multiple Path Computation Elements (PCEs). 92 The procedure is called "Forward Search Shortest P2MP LSP Path 93 Crossing Domains" or FSPC for short. The major characteristics of 94 this procedure for computing a path for a P2MP TE LSP from a source 95 node to a number of destination nodes crossing multiple domains 96 include the following three ones. 98 1. It guarantees that the path computed from the source node to the 99 destination nodes is shortest. 101 2. It does not depend on any domain path tree or domain sequences 102 from the source node to the destination nodes. 104 3. Navigating a mesh of domains is simple and efficient. 106 2. Terminology 108 ABR: Area Border Router. Routers used to connect two IGP areas 109 (areas in OSPF or levels in IS-IS). 111 ASBR: Autonomous System Border Router. Routers used to connect 112 together ASes of the same or different service providers via one or 113 more inter-AS links. 115 Boundary Node (BN): a boundary node is either an ABR in the context 116 of inter-area Traffic Engineering or an ASBR in the context of inter- 117 AS Traffic Engineering. 119 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 120 the path found from the source node to the BN, where domain(n-1) is 121 the previous hop domain of domain(n). 123 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 124 the path found from the source node to the BN, where domain(n+1) is 125 the next hop domain of domain(n). 127 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 129 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 131 LSP: Label Switched Path. 133 LSR: Label Switching Router. 135 PCC: Path Computation Client. Any client application requesting a 136 path computation to be performed by a Path Computation Element. 138 PCE: Path Computation Element. An entity (component, application, or 139 network node) that is capable of computing a network path or route 140 based on a network graph and applying computational constraints. 142 PCE(i) is a PCE with the scope of domain(i). 144 TED: Traffic Engineering Database. 146 This document uses terminologies defined in RFC5440. 148 3. Conventions Used in This Document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC2119. 154 4. Requirements 156 This section summarizes the requirements specific for computing a 157 path for a Traffic Engineering (TE) LSP crossing multiple domains 158 (areas or ASes). More requirements for Inter-Area and Inter-AS MPLS 159 Traffic Engineering are described in RFC 4105 and RFC 4216. 161 A number of requirements specific for a solution to compute a path 162 for a TE LSP crossing multiple domains is listed as follows: 164 1. The solution SHOULD provide the capability to compute a shortest 165 path dynamically, satisfying a set of specified constraints 166 across multiple IGP areas. 168 2. The solution MUST provide the ability to reoptimize in a 169 minimally disruptive manner (make before break) an inter-area TE 170 LSP, should a more optimal path appear in any traversed IGP area. 172 3. The solution SHOULD provide mechanism(s) to compute a shortest 173 end-to-end path for a TE LSP crossing multiple ASes and 174 satisfying a set of specified constraints dynamically. 176 4. Once an inter-AS TE LSP has been established, and should there be 177 any resource or other changes inside anyone of the ASes, the 178 solution MUST be able to re-optimize the LSP accordingly and non- 179 disruptively, either upon expiration of a configurable timer or 180 upon being triggered by a network event or a manual request at 181 the TE tunnel Head-End. 183 5. Forward Search P2MP Path Computation 185 This section gives an overview of the forward search path computation 186 procedure (FSPC) to satisfy the requirements for computing a path for 187 a P2MP TE LSP crossing multiple domains described above and describes 188 the procedure in details. 190 5.1. Overview of Procedure 192 Simply speaking, the idea of FSPC for computing a path for an MPLS TE 193 P2MP LSP crossing multiple domains from a source node to a number of 194 destination nodes includes: 196 Start from the source node and the source domain. 198 Consider the optimal path segment from the source node to every exit 199 boundary and destination node of the source domain as a special link; 201 Consider the optimal path segment from an entry boundary node to 202 every exit boundary node and destination node of a domain as a 203 special link; and the optimal path segment is computed as needed. 205 The whole topology consisting of many domains can be considered as a 206 special virtual topology, which contains those special links and the 207 inter-domain links. 209 Compute a shortest path in this special topology from the source node 210 to the multiple destination nodes using CSPF. 212 FSPC running at any PCE just grows the result path list/tree in the 213 same way as normal CSPF on the special virtual topology. When the 214 result path list/tree reaches all the destination nodes, the shortest 215 path from the source node to the destination nodes is found and a 216 PCRep message with the path is sent to the PCE/PCC that sends the 217 PCReq message eventually. 219 5.2. Description of Procedure 221 Suppose that we have the following variables: 223 A current PCE named as CurrentPCE which is currently computing the 224 path. 226 A candidate node list named as CandidateNodeList, which contains the 227 nodes to each of which the temporary optimal path from the source 228 node is currently found and satisfies a set of given constraints. 229 Each node C in CandidateNodeList has the following information: 231 o the cost of the path from the source node to node C, 233 o the previous hop node P and the link between P and C, 235 o the PCE responsible for C (i.e., the PCE responsible for the 236 domain containing C. Alternatively, we may use the domain instead 237 of the PCE.), and 239 o the flags for C. 241 The flags include: 243 o bit D indicating that C is a Destination node if it is set; 245 o bit S indicating that C is the Source node if it is set; 247 o bit E indicating that C is an Exit boundary node if it is set; 249 o bit I indicating that C is an entry boundary node if it is set; 250 and 252 o bit T indicating that C is on result path Tree if it is set. 254 The nodes in CandidateNodeList are ordered by path cost. 256 Initially, CandidateNodeList contains a Source Node, with path cost 257 0, PCE responsible for the source domain, and flags with S bit set. 258 It also contains every destination node, with path cost infinity and 259 flags with D bit set. 261 A result path list or tree named as ResultPathTree, which contains 262 the shortest paths from the source node to the boundary nodes and 263 destination nodes. Initially, ResultPathTree is empty. 265 Alternatively, the result path list or tree can be combined into the 266 candidate node list. We may set bit T to one in the node flags for 267 the candidate node when grafting it into the existing result path 268 list or tree. Thus all the candidate nodes with bit T set to one in 269 the candidate list constitute the result path tree or list. 271 FSPC for computing a path for an MPLS TE P2MP LSP crossing a number 272 of domains from a source node to a number of destination nodes can be 273 described as follows: 275 Initially, a PCC sends a PCE responsible for the source domain a 276 request with CandidateNodeList and ResultPathTree initialized. 278 When the PCE responsible for a domain (called current domain) 279 receives a request for computing the path for the MPLS TE P2MP LSP, 280 it checks whether the current PCE is the PCE responsible for the node 281 C with the minimum cost in the CandidateNodeList. If it is, then 282 remove C from CandidateNodeList and graft it into ResultPathTree 283 (i.e., set flag bit T of node C to one); otherwise, a PCReq message 284 is sent to the PCE for node C. 286 Suppose that node C is in the current domain. The ResultPathTree is 287 built from C in the following steps. 289 If node C is a destination node (i.e., the Destination Node (D) bit 290 in the Flags is set), then check whether the path cost to node C is 291 infinity. If it is, then we can not find any path for the P2MP LSP, 292 and a repply message with failure reasons is sent; otherwise, if all 293 the destinations are on the result path tree, then the shortest path 294 is found and a PCRep message with the path is sent to the PCE/PCC 295 which sends the request to the current PCE. 297 If node C is an entry boundary node or the source node, then the 298 optimal path segments from node C to every destination node and every 299 exit boundary node of the current domain that is not on the result 300 path tree and satisfies the given constraints are computed through 301 using CSPF and as special links. 303 For every node N connected to node C through a special link (i.e., 304 the optimal path segment satisfying the given constraints), it is 305 merged into CandidateNodeList. The cost to node N is the sum of the 306 cost to node C and the cost of the special link (i.e., the path 307 segment) between C and N. If node N is not in the candidate node 308 list, then node N is added into the list with the cost to node N, 309 node C as its previous hop node and a PCE for node N. The PCE for 310 node N is the current PCE if node N is an ASBR; otherwise (node N is 311 an ABR, an exit boundary node of the current domain and an entry 312 boundary node of the domain next to the current domain) the PCE for 313 node N is the PCE for the next domain. If node N is in the candidate 314 node list and the cost to node N through node C is less than the cost 315 to node N in the list, then replace the cost to node N in the list 316 with the cost to node N through node C and the previous hop to node N 317 in the list with node C. 319 If node C is an exit boundary node and there are inter-domain links 320 connecting to it (i.e., node C is an ASBR) and satisfying the 321 constraints, then for every node N connecting to C, satisfying the 322 constraints and not on the result path tree, it is merged into the 323 candidate node list. The cost to node N is the sum of the cost to 324 node C and the cost of the link between C and N. If node N is not in 325 the candidate node list, then node N is added into the list with the 326 cost to node N, node C as its previous hop node and the PCE for node 327 N. If node N is in the candidate node list and the cost to node N 328 through node C is less than the cost to node N in the list, then 329 replace the cost to node N in the list with the cost to node N 330 through node C and the previous hop to node N in the list with node 331 C. 333 If the CurrentPCE is the same as the PCE for the node D with the 334 minimum cost in CandidateNodeList, then the node D is removed from 335 CandidateNodeList and grafted to ResultPathTree (i.e., set flag bit T 336 of node D to one), and the above steps are repeated; otherwise, a 337 request message is to be sent to the PCE for node D. 339 5.3. Processing Request and Reply Messages 341 In this section, we describe the processing of the request and reply 342 messages with Forward search bit set for FSPC. Each of the request 343 and reply messages mentioned below has its Forward search bit set 344 even though we do not indicate this explicitly. 346 In the case that a reply message is a final reply, which contains the 347 optimal path from the source to the destination, the reply message is 348 sent toward the PCC along the path that the request message goes from 349 the PCC to the current PCE in reverse direction. 351 In the case that a request message is to be sent to the PCE for node 352 D with the minimum cost in the candidate node list and there is a PCE 353 session between the current domain and the next domain containing 354 node D, the current PCE sends the PCE for node D through the session 355 a request message with the source node, the destination node, 356 CandidateNodeList and ResultPathTree. 358 In the case that a request message is to be sent to the PCE for node 359 D and there is not any PCE session between the current PCE and the 360 PCE for node D, a reply message is sent toward a branch point on the 361 result path tree from the current domain along the path that the 362 request message goes from the PCC to the current PCE in reverse 363 direction. From the branch point, there is a downward path to the 364 domain containing the previous hop node of node D on the result path 365 tree and to the domain containing node D. At this branch point, the 366 request message is sent to the PCE for node D along the downward 367 path. 369 Suppose that node D has the minimum cost in CandidateNodeList when a 370 PCE receives a request message or a reply message containing 371 CandidateNodeList. 373 When a PCE (current PCE) for a domain (current domain) receives a 374 reply message PCRep, it checks whether the reply is a final reply 375 with the optimal path from the source to the destination. If the 376 reply is the final reply, the current PCE sends the reply to the PCE 377 that sends the request to the current PCE; otherwise, it checks 378 whether there is a path from the current domain to the domain 379 containing the previous hop node of node D on ResultPathTree and to 380 the domain containing node D. If there is a path, the PCE sends a 381 request PCReq to the PCE responsible for the next domain along the 382 path; otherwise, it sends a reply PCRep to the PCE that sends the 383 request to the current PCE. 385 When a PCE receives a request PCReq, it checks whether the current 386 domain contains node D. If it does, then node D is removed from 387 CandidateNodeList and grafted to ResultPathTree (i.e., set flag bit T 388 of node D to one), and the above steps in the previous sub section 389 are repeated; otherwise, the PCE sends a request PCReq to the PCE 390 responsible for the next domain along the path from the current 391 domain to the domain containing the previous hop node of node D on 392 ResultPathTree and to the domain containing node D. 394 6. Comparing to BRPC 396 RFC 5441 describes the Backward Recursive Path Computation (BRPC) 397 algorithm or procedure for computing an MPLS TE P2P LSP path from a 398 source node to a destination node crossing multiple domains. 399 Comparing to BRPC, there are a number of differences between BRPC and 400 the Forward-Search P2MP TE LSP Inter-Domain Path Computation (FSPC). 401 Some of the differences are briefed below. 403 At first, BRPC is for computing a shortest path from a source node to 404 a destination node crossing multiple domains. FSPC is for computing 405 a shortest path from a source node to a number of destination nodes 406 crossing multiple domains. 408 Secondly, for BRPC to compute a shortest path from a source node to a 409 destination node crossing multiple domains, we MUST provide a 410 sequence of domains from the source node to the destination node to 411 BRPC in advance. FSPC does not need any sequence of domains for 412 computing a shortest inter-domain P2MP path. 414 Moreover, for a given sequence of domains domain(1), domain(2), ... , 415 domain(n), BRPC searches the shortest path from domain(n), to 416 domain(n-1), until domain(1). Thus it is hard for BRPC to be 417 extended for computing a shortest path from a source node to a number 418 of destination nodes crossing multiple domains. FSPC calculates a 419 shortest path in a special topology from the source node to the 420 destination nodes using CSPF. 422 7. Extensions to PCEP 424 The extensions to PCEP for FSPC include the definition of a new flag 425 in the RP object, a result path list/tree and a candidate node list 426 in a request message. 428 7.1. RP Object Extension 430 The following flag is added into the RP Object: 432 The F bit is added in the flag bits field of the RP object to tell 433 the receiver of the message that the request/reply is for FSPC. 435 o F (FSPC bit - 1 bit): 436 0: This indicates that this is not PCReq/PCRep for FSPC. 437 1: This indicates that this is PCReq or PCRep message for FSPC. 439 The T bit is added in the flag bits field of the RP object to tell 440 the receiver of the message that the reply is for transferring a 441 request message to the domain containing the node with minimum cost 442 in the candidate list. 444 o T (Transfer request bit - 1 bit): 445 0: This indicates that this is not a PCRep 446 for transferring a request message. 447 1: This indicates that this is a PCRep message 448 for transferring a request message. 450 Setting Transfer request T-bit in a RP Object to one indicates that a 451 reply message containing the RP Object is for transferring a request 452 message to the domain containing the node with minimum cost in the 453 candidate list. 455 The IANA request is referenced in Section below (Request Parameter 456 Bit Flags) of this document. 458 This F bit with the N bit defined in RFC6006 can indicate whether the 459 request/reply is for FSPC of an MPLS TE P2MP LSP or an MPLS TE P2P 460 LSP. 462 o F = 1 and N = 1: This indicates that this is a PCReq/PCRep 463 message for FSPC of an MPLS TE P2MP LSP. 464 o F = 1 and N = 0: This indicates that this is a PCReq/PCRep 465 message for FSPC of an MPLS TE P2P LSP. 467 7.2. PCE Object 469 The figure below illustrates a PCE IPv4 object body (Object-Type=1), 470 which comprises a PCE IPv4 address. The PCE IPv4 address object 471 indicates the IPv4 address of a PCE , with which a PCE session may be 472 established and to which a request message may be sent. 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 | PCE IPv4 address | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 7.3. Candidate Node List Object 494 The candidate-node-list-obj object contains a list of candidate 495 nodes. A new PCEP object class and type are requested for it. The 496 format of the candidate-node-list-obj object body is as follows: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | | 502 // // 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 The following is the definition of the candidate node list. 508 ::= 509 [] 510 ::= 511 513 ::= [] 514 [] 515 [] 517 The ERO in a candidate node contain just the path segment of the last 518 link of the path, which is from the previous hop node of the tail end 519 node of the path to the tail end node. With this information, we can 520 graft the candidate node into the existing result path list or tree. 522 Simply speaking, a candidate node has the same or similar format of a 523 path defined in RFC 5440, but the ERO in the candidate node just 524 contain the tail end node of the path and its previous hop, and the 525 candidate node may contain two new objects PCE and node flags. 527 7.4. Node Flags Object 529 The Node Flags object is used to indicate the characteristics of the 530 node in a candidate node list in a request or reply message for FSPC. 531 The Node Flags object comprises a Reserved field, and a number of 532 Flags. 534 The format of the Node Flags object body is as follows: 536 0 1 2 3 537 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 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 |D|S|I|E|N| Flags | Reserved | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 where 544 o D = 1: The node is a destination node. 545 o S = 1: The node is a source node. 546 o I = 1: The node is an entry boundary node. 547 o E = 1: The node is an exit boundary node. 548 o T = 1: The node is on the result path tree. 550 7.5. Request Message Extension 552 Below is the message format for a request message with the extension 553 of a result path list and a candidate node list: 555 ::= 556 557 ::= [] [] 558 [] [] [[]] 559 [] [] 560 [] 561 [] 562 where: 563 ::=[] 564 ::= 565 ::=[] [] [] 566 [] 568 contains a 570 ::= 571 [] 572 ::= 573 575 ::= [] 576 [] 577 [] 579 Figure 1: The Format for a Request Message 581 The definition for the result path list that may be added into a 582 request message is the same as that for the path list in a reply 583 message that is described in RFC5440. 585 7.6. Reply Message Extension 587 Below is the message format for a reply message with the extension of 588 a result path list and a candidate node list: 590 ::= 591 592 ::= [] 593 [] [] 594 [] 595 [] 596 where: 597 contains a 599 If the path from the source to the destinations is not found yet and 600 there are still chances to find a path (i.e., the candidate list is 601 not empty), the reply message contains candidate-node-list-obj 602 consisting of the information of the candidate list, which is 603 encoded. In this case, the Transfer request T-bit in the RP Object 604 is set to one. 606 If the path from the source to the destination is found, the reply 607 message contains path-list comprising the information of the path. 609 8. Security Considerations 611 The mechanism described in this document does not raise any new 612 security issues for the PCEP protocols. 614 9. IANA Considerations 616 This section specifies requests for IANA allocation. 618 9.1. Request Parameter Bit Flags 620 A new RP Object Flag has been defined in this document. IANA is 621 requested to make the following allocation from the "PCEP RP Object 622 Flag Field" Sub-Registry: 624 Bit Description Reference 625 18 FSPC (F-bit) This I-D 626 19 Transfer Request (T-bit) This I-D 628 10. Acknowledgement 630 The author would like to appreciate Dhruv Dhody for his great 631 contributions and to thank Julien Meuric, Daniel King, Cyril 632 Margaria, Ramon Casellas, Olivier Dugeon and Oscar Gonzalez de Dios 633 for their valuable comments on this draft. 635 11. References 637 11.1. Normative References 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 645 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 646 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 647 . 649 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 650 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 651 DOI 10.17487/RFC5440, March 2009, 652 . 654 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 655 Ali, Z., and J. Meuric, "Extensions to the Path 656 Computation Element Communication Protocol (PCEP) for 657 Point-to-Multipoint Traffic Engineering Label Switched 658 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 659 . 661 11.2. Informative References 663 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 664 Element (PCE)-Based Architecture", RFC 4655, 665 DOI 10.17487/RFC4655, August 2006, 666 . 668 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 669 (PCC) - Path Computation Element (PCE) Requirements for 670 Point-to-Multipoint MPLS-TE", RFC 5862, 671 DOI 10.17487/RFC5862, June 2010, 672 . 674 Author's Address 676 Huaimo Chen 677 Futurewei 678 Boston, MA 679 USA 681 EMail: Huaimo.chen@futurewei.com