idnits 2.17.1 draft-chen-pce-forward-search-p2mp-path-12.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. ** 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 (May 4, 2017) is 2547 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 636, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC6006' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC5862' is defined on line 665, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 3 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: November 5, 2017 May 4, 2017 7 A Forward-Search P2MP TE LSP Inter-Domain Path Computation 8 draft-chen-pce-forward-search-p2mp-path-12.txt 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 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 November 5, 2017. 36 Copyright Notice 38 Copyright (c) 2017 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 P2MP Path Computation . . . . . . . . . . . . . 5 58 5.1. Overview of Procedure . . . . . . . . . . . . . . . . . . 5 59 5.2. Description of Procedure . . . . . . . . . . . . . . . . . 6 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. Candidate Node List Object . . . . . . . . . . . . . . . . 11 66 7.4. Node Flags Object . . . . . . . . . . . . . . . . . . . . 12 67 7.5. Request Message Extension . . . . . . . . . . . . . . . . 13 68 7.6. Reply Message Extension . . . . . . . . . . . . . . . . . 14 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 14 72 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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 117 inter-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. The flags include: 241 * bit D indicating that C is a Destination node if it is set; 243 * bit S indicating that C is the Source node if it is set; 245 * bit E indicating that C is an Exit boundary node if it is set; 247 * bit I indicating that C is an entry boundary node if it is set; 248 and 250 * bit T indicating that C is on result path Tree if it is set. 252 The nodes in CandidateNodeList are ordered by path cost. 254 Initially, CandidateNodeList contains a Source Node, with path cost 255 0, PCE responsible for the source domain, and flags with S bit set. 256 It also contains every destination node, with path cost infinity and 257 flags with D bit set. 259 A result path list or tree named as ResultPathTree, which contains 260 the shortest paths from the source node to the boundary nodes and 261 destination nodes. Initially, ResultPathTree is empty. 263 Alternatively, the result path list or tree can be combined into the 264 candidate node list. We may set bit T to one in the node flags for 265 the candidate node when grafting it into the existing result path 266 list or tree. Thus all the candidate nodes with bit T set to one in 267 the candidate list constitute the result path tree or list. 269 FSPC for computing a path for an MPLS TE P2MP LSP crossing a number 270 of domains from a source node to a number of destination nodes can be 271 described as follows: 273 Initially, a PCC sends a PCE responsible for the source domain a 274 request with CandidateNodeList and ResultPathTree initialized. 276 When the PCE responsible for a domain (called current domain) 277 receives a request for computing the path for the MPLS TE P2MP LSP, 278 it checks whether the current PCE is the PCE responsible for the node 279 C with the minimum cost in the CandidateNodeList. If it is, then 280 remove C from CandidateNodeList and graft it into ResultPathTree 281 (i.e., set flag bit T of node C to one); otherwise, a PCReq message 282 is sent to the PCE for node C. 284 Suppose that node C is in the current domain. The ResultPathTree is 285 built from C in the following steps. 287 If node C is a destination node (i.e., the Destination Node (D) bit 288 in the Flags is set), then check whether the path cost to node C is 289 infinity. If it is, then we can not find any path for the P2MP LSP, 290 and a repply message with failure reasons is sent; otherwise, if all 291 the destinations are on the result path tree, then the shortest path 292 is found and a PCRep message with the path is sent to the PCE/PCC 293 which sends the request to the current PCE. 295 If node C is an entry boundary node or the source node, then the 296 optimal path segments from node C to every destination node and every 297 exit boundary node of the current domain that is not on the result 298 path tree and satisfies the given constraints are computed through 299 using CSPF and as special links. 301 For every node N connected to node C through a special link (i.e., 302 the optimal path segment satisfying the given constraints), it is 303 merged into CandidateNodeList. The cost to node N is the sum of the 304 cost to node C and the cost of the special link (i.e., the path 305 segment) between C and N. If node N is not in the candidate node 306 list, then node N is added into the list with the cost to node N, 307 node C as its previous hop node and a PCE for node N. The PCE for 308 node N is the current PCE if node N is an ASBR; otherwise (node N is 309 an ABR, an exit boundary node of the current domain and an entry 310 boundary node of the domain next to the current domain) the PCE for 311 node N is the PCE for the next domain. If node N is in the candidate 312 node list and the cost to node N through node C is less than the cost 313 to node N in the list, then replace the cost to node N in the list 314 with the cost to node N through node C and the previous hop to node N 315 in the list with node C. 317 If node C is an exit boundary node and there are inter-domain links 318 connecting to it (i.e., node C is an ASBR) and satisfying the 319 constraints, then for every node N connecting to C, satisfying the 320 constraints and not on the result path tree, it is merged into the 321 candidate node list. The cost to node N is the sum of the cost to 322 node C and the cost of the link between C and N. If node N is not in 323 the candidate node list, then node N is added into the list with the 324 cost to node N, node C as its previous hop node and the PCE for node 325 N. If node N is in the candidate node list and the cost to node N 326 through node C is less than the cost to node N in the list, then 327 replace the cost to node N in the list with the cost to node N 328 through node C and the previous hop to node N in the list with node 329 C. 331 If the CurrentPCE is the same as the PCE for the node D with the 332 minimum cost in CandidateNodeList, then the node D is removed from 333 CandidateNodeList and grafted to ResultPathTree (i.e., set flag bit T 334 of node D to one), and the above steps are repeated; otherwise, a 335 request message is to be sent to the PCE for node D. 337 5.3. Processing Request and Reply Messages 339 In this section, we describe the processing of the request and reply 340 messages with Forward search bit set for FSPC. Each of the request 341 and reply messages mentioned below has its Forward search bit set 342 even though we do not indicate this explicitly. 344 In the case that a reply message is a final reply, which contains the 345 optimal path from the source to the destination, the reply message is 346 sent toward the PCC along the path that the request message goes from 347 the PCC to the current PCE in reverse direction. 349 In the case that a request message is to be sent to the PCE for node 350 D with the minimum cost in the candidate node list and there is a PCE 351 session between the current domain and the next domain containing 352 node D, the current PCE sends the PCE for node D through the session 353 a request message with the source node, the destination node, 354 CandidateNodeList and ResultPathTree. 356 In the case that a request message is to be sent to the PCE for node 357 D and there is not any PCE session between the current PCE and the 358 PCE for node D, a reply message is sent toward a branch point on the 359 result path tree from the current domain along the path that the 360 request message goes from the PCC to the current PCE in reverse 361 direction. From the branch point, there is a downward path to the 362 domain containing the previous hop node of node D on the result path 363 tree and to the domain containing node D. At this branch point, the 364 request message is sent to the PCE for node D along the downward 365 path. 367 Suppose that node D has the minimum cost in CandidateNodeList when a 368 PCE receives a request message or a reply message containing 369 CandidateNodeList. 371 When a PCE (current PCE) for a domain (current domain) receives a 372 reply message PCRep, it checks whether the reply is a final reply 373 with the optimal path from the source to the destination. If the 374 reply is the final reply, the current PCE sends the reply to the PCE 375 that sends the request to the current PCE; otherwise, it checks 376 whether there is a path from the current domain to the domain 377 containing the previous hop node of node D on ResultPathTree and to 378 the domain containing node D. If there is a path, the PCE sends a 379 request PCReq to the PCE responsible for the next domain along the 380 path; otherwise, it sends a reply PCRep to the PCE that sends the 381 request to the current PCE. 383 When a PCE receives a request PCReq, it checks whether the current 384 domain contains node D. If it does, then node D is removed from 385 CandidateNodeList and grafted to ResultPathTree (i.e., set flag bit T 386 of node D to one), and the above steps in the previous sub section 387 are repeated; otherwise, the PCE sends a request PCReq to the PCE 388 responsible for the next domain along the path from the current 389 domain to the domain containing the previous hop node of node D on 390 ResultPathTree and to the domain containing node D. 392 6. Comparing to BRPC 394 RFC 5441 describes the Backward Recursive Path Computation (BRPC) 395 algorithm or procedure for computing an MPLS TE P2P LSP path from a 396 source node to a destination node crossing multiple domains. 397 Comparing to BRPC, there are a number of differences between BRPC and 398 the Forward-Search P2MP TE LSP Inter-Domain Path Computation (FSPC). 399 Some of the differences are briefed below. 401 At first, BRPC is for computing a shortest path from a source node to 402 a destination node crossing multiple domains. FSPC is for computing 403 a shortest path from a source node to a number of destination nodes 404 crossing multiple domains. 406 Secondly, for BRPC to compute a shortest path from a source node to a 407 destination node crossing multiple domains, we MUST provide a 408 sequence of domains from the source node to the destination node to 409 BRPC in advance. FSPC does not need any sequence of domains for 410 computing a shortest inter-domain P2MP path. 412 Moreover, for a given sequence of domains domain(1), domain(2), ... , 413 domain(n), BRPC searches the shortest path from domain(n), to 414 domain(n-1), until domain(1). Thus it is hard for BRPC to be 415 extended for computing a shortest path from a source node to a number 416 of destination nodes crossing multiple domains. FSPC calculates a 417 shortest path in a special topology from the source node to the 418 destination nodes using CSPF. 420 7. Extensions to PCEP 422 The extensions to PCEP for FSPC include the definition of a new flag 423 in the RP object, a result path list/tree and a candidate node list 424 in a request message. 426 7.1. RP Object Extension 428 The following flag is added into the RP Object: 430 The F bit is added in the flag bits field of the RP object to tell 431 the receiver of the message that the request/reply is for FSPC. 433 o F (FSPC bit - 1 bit): 434 0: This indicates that this is not PCReq/PCRep for FSPC. 435 1: This indicates that this is PCReq or PCRep message for FSPC. 437 The T bit is added in the flag bits field of the RP object to tell 438 the receiver of the message that the reply is for transferring a 439 request message to the domain containing the node with minimum cost 440 in the candidate list. 442 o T (Transfer request bit - 1 bit): 443 0: This indicates that this is not a PCRep 444 for transferring a request message. 445 1: This indicates that this is a PCRep message 446 for transferring a request message. 448 Setting Transfer request T-bit in a RP Object to one indicates that a 449 reply message containing the RP Object is for transferring a request 450 message to the domain containing the node with minimum cost in the 451 candidate list. 453 The IANA request is referenced in Section below (Request Parameter 454 Bit Flags) of this document. 456 This F bit with the N bit defined in RFC6006 can indicate whether the 457 request/reply is for FSPC of an MPLS TE P2MP LSP or an MPLS TE P2P 458 LSP. 460 o F = 1 and N = 1: This indicates that this is a PCReq/PCRep 461 message for FSPC of an MPLS TE P2MP LSP. 462 o F = 1 and N = 0: This indicates that this is a PCReq/PCRep 463 message for FSPC of an MPLS TE P2P 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 The format of the PCE object body for IPv6 (Object-Type=2) is as 479 follows: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 | PCE IPv6 address (16 bytes) | 486 | | 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 7.3. Candidate Node List Object 492 The candidate-node-list-obj object contains a list of candidate 493 nodes. A new PCEP object class and type are requested for it. The 494 format of the candidate-node-list-obj object body is as follows: 496 0 1 2 3 497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 // // 501 | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 The following is the definition of the candidate node list. 506 ::= 507 [] 508 ::= 509 511 ::= [] 512 [] 513 [] 515 The ERO in a candidate node contain just the path segment of the last 516 link of the path, which is from the previous hop node of the tail end 517 node of the path to the tail end node. With this information, we can 518 graft the candidate node into the existing result path list or tree. 520 Simply speaking, a candidate node has the same or similar format of a 521 path defined in RFC 5440, but the ERO in the candidate node just 522 contain the tail end node of the path and its previous hop, and the 523 candidate node may contain two new objects PCE and node flags. 525 7.4. Node Flags Object 527 The Node Flags object is used to indicate the characteristics of the 528 node in a candidate node list in a request or reply message for FSPC. 529 The Node Flags object comprises a Reserved field, and a number of 530 Flags. 532 The format of the Node Flags object body is as follows: 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 |D|S|I|E|N| Flags | Reserved | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 where 542 o D = 1: The node is a destination node. 543 o S = 1: The node is a source node. 544 o I = 1: The node is an entry boundary node. 545 o E = 1: The node is an exit boundary node. 546 o T = 1: The node is on the result path tree. 548 7.5. Request Message Extension 550 Below is the message format for a request message with the extension 551 of a result path list and a candidate node list: 553 ::= 554 555 ::= [] [] 556 [] [] [[]] 557 [] [] 558 [] 559 [] 560 where: 561 ::=[] 562 ::= 563 ::=[] [] [] 564 [] 566 contains a 568 ::= 569 [] 570 ::= 571 573 ::= [] 574 [] 575 [] 577 Figure 1: The Format for a Request Message 579 The definition for the result path list that may be added into a 580 request message is the same as that for the path list in a reply 581 message that is described in RFC5440. 583 7.6. Reply Message Extension 585 Below is the message format for a reply message with the extension of 586 a result path list and a candidate node list: 588 ::= 589 590 ::= [] 591 [] [] 592 [] 593 [] 594 where: 595 contains a 597 If the path from the source to the destinations is not found yet and 598 there are still chances to find a path (i.e., the candidate list is 599 not empty), the reply message contains candidate-node-list-obj 600 consisting of the information of the candidate list, which is 601 encoded. In this case, the Transfer request T-bit in the RP Object 602 is set to one. 604 If the path from the source to the destination is found, the reply 605 message contains path-list comprising the information of the path. 607 8. Security Considerations 609 The mechanism described in this document does not raise any new 610 security issues for the PCEP protocols. 612 9. IANA Considerations 614 This section specifies requests for IANA allocation. 616 9.1. Request Parameter Bit Flags 618 A new RP Object Flag has been defined in this document. IANA is 619 requested to make the following allocation from the "PCEP RP Object 620 Flag Field" Sub-Registry: 622 Bit Description Reference 623 18 FSPC (F-bit) This I-D 624 19 Transfer Request (T-bit) This I-D 626 10. Acknowledgement 628 The author would like to thank Julien Meuric, Daniel King, Cyril 629 Margaria, Ramon Casellas, Olivier Dugeon and Oscar Gonzalez de Dios 630 for their valuable comments on this draft. 632 11. References 634 11.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 638 RFC2119, March 1997, 639 . 641 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 642 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 643 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 644 . 646 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 647 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 648 DOI 10.17487/RFC5440, March 2009, 649 . 651 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 652 Ali, Z., and J. Meuric, "Extensions to the Path 653 Computation Element Communication Protocol (PCEP) for 654 Point-to-Multipoint Traffic Engineering Label Switched 655 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 656 . 658 11.2. Informative References 660 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 661 Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/ 662 RFC4655, August 2006, 663 . 665 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 666 (PCC) - Path Computation Element (PCE) Requirements for 667 Point-to-Multipoint MPLS-TE", RFC 5862, DOI 10.17487/ 668 RFC5862, June 2010, 669 . 671 Authors' Addresses 673 Huaimo Chen 674 Huawei Technologies 675 Boston, MA 676 USA 678 Email: Huaimo.chen@huawei.com 680 Dhruv Dhody 681 Huawei Technologies 682 Leela Palace, Bangalore, Karnataka 560008 683 INDIA 685 Email: dhruv.dhody@huawei.com