idnits 2.17.00 (12 Aug 2021) /tmp/idnits10202/draft-chen-pce-forward-search-p2p-path-computation-22.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 : ---------------------------------------------------------------------------- No issues found here. 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) ** Downref: Normative reference to an Informational RFC: RFC 4655 -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) == Outdated reference: A later version (-04) exists of draft-zhang-pce-hierarchy-extensions-02 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 P2P TE LSP Inter-Domain Path Computation 8 draft-chen-pce-forward-search-p2p-path-computation-22 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 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 Path Computation . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 9 63 7.2. NODE-FLAGS Object . . . . . . . . . . . . . . . . . . . . 10 64 7.2.1. PREVIOUS-NODE TLV . . . . . . . . . . . . . . . . . . 11 65 7.2.2. DOMAIN-ID TLV . . . . . . . . . . . . . . . . . . . . 11 66 7.2.3. PCE-ID TLV . . . . . . . . . . . . . . . . . . . . . 12 67 7.3. Candidate Node List . . . . . . . . . . . . . . . . . . . 13 68 7.4. Result Path List . . . . . . . . . . . . . . . . . . . . 14 69 7.5. Request Message Extension . . . . . . . . . . . . . . . . 14 70 7.6. Reply Message Extension . . . . . . . . . . . . . . . . . 15 71 8. Suggestion to improve performance . . . . . . . . . . . . . . 15 72 9. Manageability Considerations . . . . . . . . . . . . . . . . 15 73 9.1. Control of Function and Policy . . . . . . . . . . . . . 15 74 9.2. Information and Data Models . . . . . . . . . . . . . . . 15 75 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 76 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 77 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 78 9.6. Impact On Network Operations . . . . . . . . . . . . . . 16 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 11.1. Request Parameter Bit Flags . . . . . . . . . . . . . . 16 82 11.2. New PCEP Object . . . . . . . . . . . . . . . . . . . . 16 83 11.2.1. NODE-FLAGS Object . . . . . . . . . . . . . . . . . 16 84 11.3. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 17 85 11.3.1. DOMAIN-ID TLV . . . . . . . . . . . . . . . . . . . 17 86 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 13.2. Informative References . . . . . . . . . . . . . . . . . 18 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 It would be useful to extend MPLS TE capabilities across multiple 95 domains (i.e., IGP areas or Autonomous Systems) to support inter- 96 domain resources optimization, to provide strict QoS guarantees 97 between two edge routers located within distinct domains. 99 [RFC4105] "Requirements for Inter-Area MPLS TE" lists the 100 requirements for computing a shortest path for a TE LSP crossing 101 multiple IGP areas; and [RFC4216] "MPLS Inter-Autonomous System (AS) 102 TE Requirements" describes the requirements for computing a shortest 103 path for a TE LSP crossing multiple ASes. [RFC4655] "A PCE-Based 104 Architecture" discusses centralized and distributed computation 105 models for the computation of a path for a TE LSP crossing multiple 106 domains. 108 This document presents a forward search procedure to address these 109 requirements using multiple Path Computation Elements (PCEs). This 110 procedure guarantees that the path found from the source to the 111 destination is shortest. It does not depend on any sequence of 112 domains from the source node to the destination node. Navigating a 113 mesh of domains is simple and efficient. 115 2. Terminology 117 The following terminology is used in this document. 119 ABR: Area Border Router. Router used to connect two IGP areas 120 (Areas in OSPF or levels in IS-IS). 122 ASBR: Autonomous System Border Router. Router used to connect 123 together ASes of the same or different service providers via one 124 or more inter-AS links. 126 BN: Boundary Node. A boundary node is either an ABR in the context 127 of inter-area Traffic Engineering or an ASBR in the context of 128 inter-AS Traffic Engineering. 130 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) 131 along the path found from the source node to the BN, where 132 domain(n-1) is the previous hop domain of domain(n). 134 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 135 the path found from the source node to the BN, where domain(n+1) 136 is the next hop domain of domain(n). 138 Inter-area TE LSP: a TE LSP that crosses an IGP area boundary. 140 Inter-AS TE LSP: a TE LSP that crosses an AS boundary. 142 LSP: Label Switched Path 144 LSR: Label Switching Router 146 PCC: Path Computation Client. Any client application requesting a 147 path computation to be performed by a Path Computation Element. 149 PCE: Path Computation Element. An entity (component, application, 150 or network node) that is capable of computing a network path or 151 route based on a network graph and applying computational 152 constraints. 154 PCE(i): a PCE with the scope of domain(i). 156 TED: Traffic Engineering Database. 158 This document uses terminology defined in [RFC5440]. 160 3. Conventions Used in This Document 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 4. Requirements 168 This section summarizes the requirements specific for computing a 169 path for a P2P Traffic Engineering (TE) LSP crossing multiple domains 170 (areas or ASes). More requirements for Inter-Area and Inter-AS MPLS 171 Traffic Engineering are described in [RFC4105] and [RFC4216]. 173 A number of requirements specific for a solution to compute a path 174 for a P2P TE LSP crossing multiple domains is listed as follows: 176 1. The solution SHOULD provide the capability to compute a shortest 177 path dynamically, satisfying a set of specified constraints 178 across multiple IGP areas. 180 2. The solution MUST provide the ability to reoptimize in a 181 minimally disruptive manner (make before break) an inter-area TE 182 LSP, should a more optimal path appear in any traversed IGP area. 184 3. The solution SHOULD provide mechanism(s) to compute a shortest 185 end-to-end path for a TE LSP crossing multiple ASes and 186 satisfying a set of specified constraints dynamically. 188 4. Once an inter-AS TE LSP has been established, and should there be 189 any resource or other changes inside anyone of the ASes, the 190 solution MUST be able to re-optimize the LSP accordingly and non- 191 disruptively, either upon expiration of a configurable timer or 192 upon being triggered by a network event or a manual request at 193 the TE tunnel Head-End. 195 5. Forward Search Path Computation 197 This section gives an overview of the forward search path computation 198 procedure (FSPC for short) to satisfy the requirements described 199 above and describes the procedure in detail. 201 5.1. Overview of Procedure 203 Simply speaking, the idea of FSPC for computing a path for an MPLS TE 204 P2P LSP crossing multiple domains from a source node to a destination 205 node includes: 207 Start from the source node and the source domain. 209 Consider the optimal path segment from the source node to every exit 210 boundary node of the source domain as a special link; 212 Consider the optimal path segment from an entry boundary node to 213 every exit boundary node and the destination node of a domain as a 214 special link; and the optimal path segment is computed as needed. 216 The whole topology consisting of many domains can be considered as a 217 special topology, which contains those special links and the inter- 218 domain links. 220 Compute an optimal path in this special topology from the source node 221 to the destination node using CSPF. 223 5.2. Description of Procedure 225 Suppose that we have the following variables: 227 A current PCE named as CurrentPCE which is currently computing the 228 path. 230 A candidate node list named as CandidateNodeList, which contains the 231 nodes to each of which the temporary optimal path from the source 232 node is currently found and satisfies a set of given constraints. 233 The information about each node C in CandidateNodeList consists of: 235 * the cost of the path from the source node to node C, 237 * the hopcount of the path from the source node to node C, 239 * the previous hop node P and the link between P and C, 240 * the domain list of C (ABR or ASBR) where C has visibility to 241 multiple domains and clearly mark the domain by which C is added 242 to CandidateNodeList, 244 * the PCE responsible for C (i.e., the PCE responsible for the 245 domain containing C. Alternatively, we may use the above 246 mentioned domain instead of the PCE.), and 248 * the flags for C. 250 The flags include: 252 * bit D indicating that C is a Destination node if it is set, 254 * bit S indicating that C is the Source node if it is set, 256 * bit T indicating that C is on result path Tree if it is set. 258 The nodes in CandidateNodeList are ordered by path cost. Initially, 259 CandidateNodeList contains only a Source Node, with path cost 0, PCE 260 responsible for the source domain. 262 A result path list or tree named as ResultPathTree, which contains 263 the final optimal paths from the source node to the boundary nodes or 264 the destination node. Initially, ResultPathTree is empty. 266 Alternatively, the result path list or tree can be combined into the 267 CandidateNodeList. We may set bit T to one in the NODE-FLAGS object 268 for the candidate node when grafting it into the existing result path 269 list or tree. Thus all the candidate nodes with bit T set to one in 270 the CandidateNodeList constitute the result path tree or list. 272 FSPC for computing the path for the MPLS TE P2P LSP is described as 273 follows: 275 Initially, a PCC sets ResultPathTree to empty and CandidateNodeList 276 to contain the source node and sends PCE responsible for the source 277 domain a PCReq with the source node, the destination node, 278 CandidateNodeList and ResultPathTree. 280 When the PCE responsible for a domain (called current domain) 281 receives a request for computing the path for the MPLS TE P2P LSP, it 282 obtains node Cm with the minimum path cost in the CandidateNodeList. 283 The node Cm is the first node in the CandidateNodeList, which is 284 sorted by path cost. It checks whether the CurrentPCE is the PCE 285 responsible for the node Cm(always expand node Cm only if it is an 286 entry boundary node). If it is, then remove Cm from 287 CandidateNodeList and graft it into ResultPathTree (i.e., set flag 288 bit T of node Cm to one); otherwise, a PCReq message is sent to the 289 PCE for node Cm (see Section 5.3 for the case that there is not any 290 direct session between the CurrentPCE and the PCE for node Cm). 292 Suppose that node Cm is in the current domain. The ResultPathTree is 293 built from Cm in the following steps. 295 If node Cm is the destination node, then the optimal path from the 296 source node to the destination node is found, and a PCRep message 297 with the path is sent to the PCE/PCC which sends the request to the 298 CurrentPCE. 300 If node Cm is an entry boundary node or the source node, then the 301 optimal path segments from node Cm to the destination node (if it is 302 in the current domain) and every exit boundary node of the current 303 domain that is not on the result path tree and satisfies the given 304 constraints are computed through using CSPF and as special links. 306 For every node N connected to node Cm through a special link (i.e., 307 the optimal path segment satisfying the given constraints), it is 308 merged into CandidateNodeList. The cost to node N is the sum of the 309 cost to node Cm and the cost of the special link (i.e., the path 310 segment) between Cm and N. If node N is not in the 311 CandidateNodeList, then node N is added into the list with the cost 312 to node N, node Cm as its previous hop node and the PCE for node N. 313 The PCE for node N is the CurrentPCE if node N is an ASBR; otherwise 314 (node N is an ABR, an exit boundary node of the current domain and an 315 entry boundary node of the domain next to the current domain) the PCE 316 for node N is the PCE for the next domain. If node N is in the 317 CandidateNodeList and the cost to node N through node Cm is less than 318 the cost to node N in the list, then replace the cost to node N in 319 the list with the cost to node N through node Cm and the previous hop 320 to node N in the list with node Cm. 322 If node Cm is an exit boundary node and there are inter-domain links 323 connecting to it (i.e., node Cm is an ASBR) and satisfying the 324 constraints, then for every node N connecting to Cm, satisfying the 325 constraints and not on the result path tree, it is merged into the 326 CandidateNodeList. The cost to node N is the sum of the cost to node 327 Cm and the cost of the link between Cm and N. If node N is not in 328 the CandidateNodeList, then node N is added into the list with the 329 cost to node N, node Cm as its previous hop node and the PCE for node 330 N. If node N is in the CandidateNodeList and the cost to node N 331 through node Cm is less than the cost to node N in the list, then 332 replace the cost to node N in the list with the cost to node N 333 through node Cm and the previous hop to node N in the list with node 334 Cm. 336 After the CandidateNodeList is updated, there will be a new node Cm 337 with the minimum cost in the updated CandidateNodeList. If the 338 CurrentPCE is the same as the PCE for the new node Cm, then the node 339 Cm is removed from the CandidateNodeList and grafted to 340 ResultPathTree (i.e., set flag bit T of node Cm to one), and the 341 above steps are repeated; otherwise, a request message is to be sent 342 to the PCE for node Cm. 344 Note that if node Cm has visibility to multiple domains, do not 345 remove it from the CandidateNodeList until it is expanded in all 346 domains. Also mark in the domain list of node Cm, for which domains 347 it is already expanded. 349 5.3. Processing Request and Reply Messages 351 In this section, we describe the processing of the request and reply 352 messages with Forward search bit set for FSPC. Each of the request 353 and reply messages mentioned below has its Forward search bit set 354 even though we do not indicate this explicitly. 356 In the case that a reply message is a final reply, which contains the 357 optimal path from the source to the destination, the reply message is 358 sent toward the PCC along the path that the request message goes from 359 the PCC to the current PCE in reverse direction. 361 In the case that a request message is to be sent to the PCE for node 362 Cm with the minimum cost in the CandidateNodeList and there is a PCE 363 session between the current domain and the next domain containing 364 node Cm, the CurrentPCE sends the PCE for node Cm through the session 365 a request message with the source node, the destination node, 366 CandidateNodeList and ResultPathTree. 368 In the case that a request message is to be sent to the PCE for node 369 Cm and there is not any PCE session between the CurrentPCE and the 370 PCE for node Cm, a request message with T bit set to one in RP is 371 sent toward a branch point on the result path tree from the current 372 domain along the path that the request message goes from the PCC to 373 the CurrentPCE in reverse direction. From the branch point, there is 374 a downward path to the domain containing the previous hop node of 375 node Cm on the result path tree and to the domain containing node Cm. 376 At this branch point, the request message with T bit set to zero is 377 sent to the PCE for node Cm along the downward path. 379 6. Comparing to BRPC 381 [RFC5441] describes the Backward Recursive Path Computation (BRPC) 382 algorithm or procedure for computing an MPLS TE P2P LSP path from a 383 source node to a destination node crossing multiple domains. 384 Comparing to BRPC, there are a number of differences between BRPC and 385 the Forward-Search P2P TE LSP Inter-Domain Path Computation (FSPC). 386 Some of the differences are briefed below. 388 First, for BRPC to compute a shortest path from a source node to a 389 destination node crossing multiple domains, we MUST provide a 390 sequence of domains from the source node to the destination node to 391 BRPC in advance. It is a big burden and very challenging for users 392 to provide a sequence of domains for every LSP path crossing domains 393 in general. In addition, it increases the cost of operation and 394 maintenance of the network. FSPC does not need any sequence of 395 domains for computing a shortest path. 397 Secondly, for a given sequence of domains domain(1), domain(2), ... 398 ,domain(n), BRPC searches the shortest path from domain(n), to 399 domain(n-1), until domain(1) along the reverse order of the given 400 sequence of domain. It will get the shortest path within the given 401 domain sesuence. FSPC calculates an optimal path in a special 402 topology from the source node to the destination node. It will find 403 the shortest path within all the domains. 405 Moreover, if the sequence of domains from the source node to the 406 destination node provided to BRPC does not contain the shortest path 407 from the source to the destination, then the path computed by BRPC is 408 not optimal. FSPC guarantees that the path found is optimal. 410 7. Extensions to PCEP 412 This section describes the extensions to PCEP for FSPC. The 413 extensions include the definition of a new flag in the RP object, a 414 result path list and a candidate node list in the PCReq and PCRep 415 message. 417 7.1. RP Object Extension 419 The following flags are added into the RP Object: 421 The F bit is added in the flag bits field of the RP object to tell 422 the receiver of the message that the request/reply is for FSPC. 424 o F (FSPC bit - 1 bit): 425 0: This indicates that this is not a PCReq/PCRep for FSPC. 426 1: This indicates that this is a PCReq or PCRep for FSPC. 428 The T bit is added in the flag bits field of the RP object to tell 429 the receiver of the message that the request is for transferring a 430 request message to the domain containing the node with minimum cost 431 in the candidate list. 433 o T (Transfer request bit - 1 bit): 434 0: This indicates that this is not a PCReq 435 for transferring a request message. 436 1: This indicates that this is a PCReq message 437 for transferring a request message. 439 Setting Transfer request T-bit in a RP Object to one indicates that a 440 reqest message containing the RP Object is for transferring a request 441 message to the domain containing the node with minimum cost in the 442 candidate list. 444 The IANA request is referenced in Section below (Request Parameter 445 Bit Flags) of this document. 447 This F bit with the N bit defined in [RFC6006] can indicate whether 448 the request/reply is for FSPC of an MPLS TE P2P LSP or an MPLS TE 449 P2MP LSP. 451 o F = 1 and N = 0: This indicates that this is a PCReq/PCRep 452 message for FSPC of an MPLS TE P2P LSP. 453 o F = 1 and N = 1: This indicates that this is a PCReq/PCRep 454 message for FSPC of an MPLS TE P2MP LSP. 456 7.2. NODE-FLAGS Object 458 The NODE-FLAGS object is used to indicate the characteristics of the 459 node in a Candidate Node List in a request or reply message for FSPC. 460 The NODE-FLAGS object comprises a Reserved field, and a number of 461 Flags. The NODE-FLAGS object may also contain a set of TLVs. 463 The format of the NODE-FLAGS object body is as follows: 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 |D|S|T| Flags | Reserved | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | | 471 ~ Optional TLVs ~ 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 1: NODE-FLAGS Object Body 476 where 478 * D = 1: The node is a destination node. 480 * S = 1: The node is a source node. 482 * T = 1: The node is on the result path tree. 484 Following are the TLVs defined to convey the characteristics of the 485 candidate node. 487 7.2.1. PREVIOUS-NODE TLV 489 The PREVIOUS-NODE TLV contains the Previous Node Id of the candidate 490 node. The PREVIOUS-NODE TLV has the following format: 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | address-type | Reserved | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 ~ Previous Node Id ~ 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 2: PREVIOUS-NODE TLV format 503 The Type of PREVIOUS-NODE TLV is to be assigned by IANA. 505 The length is 8 if the address type is IPv4 or 20 if the address type 506 is IPV6. 508 Address Type (16 bits): Indicates the address type of Previous Node 509 Id. 1 means IPv4 address type, 2 means IPv6 address type. 511 Reserved(16 bits): SHOULD be set to zero on transmission and MUST be 512 ignored on receipt. 514 Previous Node Id : IP address of the node. 516 7.2.2. DOMAIN-ID TLV 518 The DOMAIN-ID TLV contains the domain Id of the candidate node (ABR 519 or ASBR). The NODE-FLAG Object may include multiple DOMAIN-ID TLVs 520 when the candidate node has visibility into multiple Domains. 522 The DOMAIN-ID TLV has the following format: 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Domain Type | Flags |C|V| 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Domain ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 3: DOMAIN-ID TLV format 534 The Type of DOMAIN-ID TLV is to be assigned by IANA. 536 The length is 8. 538 Domain Type (8 bits): Indicates the domain type. There are two types 539 of domain defined currently: 541 * Type=1: the Domain ID field carries an IGP Area ID. 543 * Type=2: the Domain ID field carries an AS number. 545 C Flag (1 bit): If the flag is set to 1, it indicates the candidate 546 node is added into Candidate Node List by this domain. 548 V Flag (1 bit): If the flag is set to 1, it indicates the candidate 549 node has been expanded in this domain. 551 Domain ID (32 bits): With the Domain Type set to 1, this indicates 552 the 32-bit Area ID of an IGP area where the candidate belongs. With 553 Domain Type set to 2, this indicates an AS number of an AS where the 554 candidate belongs. When the AS number is coded in two octets, the AS 555 Number field MUST have its first two octets set to 0. 557 [Editor's note: [PCE-HIERARCHY-EXT], section 3.1.3 deals with the 558 encoding of Domain-Id TLV in OPEN Object. Later on DOMAIN-ID TLV 559 defined here can be incorporate with this draft] 561 7.2.3. PCE-ID TLV 563 The PCE-ID TLV is used to indicate the PCE that added this node to 564 the CandidateList. The PCE-ID TLV has the following format: 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Address Type | Reserved | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | 572 ~ PCE IP Address ~ 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 4: PCE-ID TLV format 577 The type of PCE-ID TLV is to be assigned by IANA. 579 The length is 8. 581 Address Type (16 bits): Indicates the address type of PCE IP Address. 582 1 means IPv4 address type, 2 means IPv6 address type. 584 PCE IP Address: Indicates the reachable address of a PCE. 586 [Editor's note: [PCE-HIERARCHY-EXT], section 3.1.4 deals with the 587 encoding of PCE-Id TLV in OPEN Object. Later on PCE-ID TLV defined 588 here can be incorporate with this draft] 590 7.3. Candidate Node List 592 The Candidate Node List has the following format: 594 ::= 595 [] 596 where 598 ::= 599 601 ::= 602 [] 604 ::=[] 606 The ERO in a candidate node contain just the path segment of the last 607 link of the path, which is from the previous hop node of the tail end 608 node of the path to the tail end node. With this information, we can 609 graft the candidate node into the existing result path list or tree. 611 Simply speaking, a candidate node has the same or similar format of a 612 path defined in [RFC5440], but the ERO in the candidate node just 613 contain the tail end node of the path and its previous hop, and the 614 candidate path may contain a new object NODE-FLAGS along with new 615 TLVs. 617 7.4. Result Path List 619 The Result Path List has the following format: 621 ::= 622 [] 623 where 625 ::= 626 628 ::= 629 [] 631 ::=[] 633 The usage of ERO, NODE-FLAGS objects etc, is similar to Candidate 634 Node List. The T-bit of NODE-FLAGS Object would be set denoting that 635 the best path to this node is already found. 637 7.5. Request Message Extension 639 Below is the message format for a request message with the extension 640 of result-path-list and candidate-node-list: 642 ::= 643 [] 644 646 ::=[] 648 ::= [] [] [] 649 [] [[]] [] 650 [] 651 [] 652 [] 653 where: 654 and 655 are as defined above. 657 7.6. Reply Message Extension 659 Below is the message format for a reply message with the extension of 660 result-path-list and candidate-node-list: 662 ::= 663 665 ::=[] 667 ::= [] [] 668 [] 669 [] 670 [] 671 where: 672 and 673 are as defined above. 675 If the path from the source to the destination is found, the reply 676 message contains path-list comprising the information of the path. 678 8. Suggestion to improve performance 680 To get much better performance all the candidate nodes of current 681 domain can be expanded before moving on to a new domain. Note in 682 this case, after expanding the least cost candidate node, PCE can 683 look for and expand any other candidates in this domain. 685 9. Manageability Considerations 687 9.1. Control of Function and Policy 689 TBD 691 9.2. Information and Data Models 693 TBD 695 9.3. Liveness Detection and Monitoring 697 TBD 699 9.4. Verify Correct Operations 701 TBD 703 9.5. Requirements On Other Protocols 705 TBD 707 9.6. Impact On Network Operations 709 TBD 711 10. Security Considerations 713 The mechanism described in this document does not raise any new 714 security issues for the PCEP protocols. 716 11. IANA Considerations 718 This section specifies requests for IANA allocation. 720 11.1. Request Parameter Bit Flags 722 Two new RP Object Flags have been defined in this document. IANA is 723 requested to make the following allocation from the "PCEP RP Object 724 Flag Field" Sub-Registry: 726 Bit Description Reference 727 TBA FSPC (F-bit) This I-D 728 TBA Transfer Request (T-bit) This I-D 730 Setting FSPC F-bit in a RP Object to one indicates that a request/ 731 reply message containing the RP Object is for FSPC. 733 Setting Transfer Request T-bit in a RP Object to one indicates that a 734 request message containing the RP Object is for transferring a 735 request message to the domain containing the node with minimum cost 736 in the candidate list. 738 11.2. New PCEP Object 740 11.2.1. NODE-FLAGS Object 742 The NODE-FLAGS Object-Type and Object-Class has been defined in this 743 document. IANA is requested to make the following allocation: 745 NODE-FLAGS Object-Type : TBA 747 NODE-FLAGS Object-Class: TBA 749 Flag field of the NODE-FLAG Object: 751 Bit Description Reference 752 0 The node is a destination node This I-D 753 1 The node is a source node This I-D 754 2 The node is on the result path tree This I-D 756 Each bit should be tracked with the following qualities: 758 * Bit number (counting from bit 0 as the most significant bit) 760 * Name flag 762 * Reference 764 11.3. New PCEP TLV 766 IANA is requested to make the following allocation: 768 Value Meaning Reference 769 TBA DOMAIN-ID TLV This I-D 770 TBA PCE-ID TLV This I-D 771 TBA PREVIOUS-NODE TLV This I-D 773 11.3.1. DOMAIN-ID TLV 775 IANA is requested to make the following allocation: 777 Flag field of the DOMAIN-ID TLV 779 Bit Name Description Reference 780 15 V-bit Candidate Node has been expanded by This I-D 781 the domain 782 14 C-bit Candidate Node added by the domain This I-D 784 Each bit should be tracked with the following qualities: 786 * Bit number (counting from bit 0 as the most significant bit) 788 * Name flag 790 * Reference 792 12. Acknowledgement 794 The authors would like to appreciate Dhruv Dhody for his great 795 contributions and to thank Julien Meuric, Daniel King, Ramon 796 Casellas, Cyril Margaria,Olivier Dugeon, Oscar Gonzalez de Dios, 797 Udayasree Palle, Reeja Paul and Sandeep Kumar Boina for their 798 valuable comments on this draft. 800 13. References 802 13.1. Normative References 804 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 805 Requirement Levels", BCP 14, RFC 2119, 806 DOI 10.17487/RFC2119, March 1997, 807 . 809 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 810 Computation Element (PCE)-Based Architecture", RFC 4655, 811 DOI 10.17487/RFC4655, August 2006, 812 . 814 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 815 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 816 DOI 10.17487/RFC5440, March 2009, 817 . 819 13.2. Informative References 821 [RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle, 822 Ed., "Requirements for Inter-Area MPLS Traffic 823 Engineering", RFC 4105, DOI 10.17487/RFC4105, June 2005, 824 . 826 [RFC4216] Zhang, R., Ed. and J.-P. Vasseur, Ed., "MPLS Inter- 827 Autonomous System (AS) Traffic Engineering (TE) 828 Requirements", RFC 4216, DOI 10.17487/RFC4216, November 829 2005, . 831 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 832 "A Backward-Recursive PCE-Based Computation (BRPC) 833 Procedure to Compute Shortest Constrained Inter-Domain 834 Traffic Engineering Label Switched Paths", RFC 5441, 835 DOI 10.17487/RFC5441, April 2009, 836 . 838 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 839 Ali, Z., and J. Meuric, "Extensions to the Path 840 Computation Element Communication Protocol (PCEP) for 841 Point-to-Multipoint Traffic Engineering Label Switched 842 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 843 . 845 [PCE-HIERARCHY-EXT] 846 Zhang, F., Zhao, Q., King, O., Casellas, R., and D. King, 847 "Extensions to Path Computation Element Communication 848 Protocol (PCEP) for Hierarchical Path Computation Elements 849 (PCE) (draft-zhang-pce-hierarchy-extensions-02)", August 850 2012. 852 Author's Address 854 Huaimo Chen 855 Futurewei 856 Boston, MA, 857 United States of America 859 Email: Huaimo.chen@futurewei.com