idnits 2.17.1 draft-chen-pce-forward-search-p2p-path-computation-19.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2020) is 1383 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 (~~), 2 warnings (==), 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 July 10, 2020 5 Expires: January 11, 2021 7 A Forward-Search P2P TE LSP Inter-Domain Path Computation 8 draft-chen-pce-forward-search-p2p-path-computation-19 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 January 11, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Forward Search Path Computation . . . . . . . . . . . . . . . 5 58 5.1. Overview of Procedure . . . . . . . . . . . . . . . . . . 5 59 5.2. Description of Procedure . . . . . . . . . . . . . . . . 5 60 5.3. Processing Request and Reply Messages . . . . . . . . . . 8 61 6. Comparing to BRPC . . . . . . . . . . . . . . . . . . . . . . 9 62 7. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 9 63 7.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 9 64 7.2. NODE-FLAGS Object . . . . . . . . . . . . . . . . . . . . 10 65 7.2.1. PREVIOUS-NODE TLV . . . . . . . . . . . . . . . . . . 11 66 7.2.2. DOMAIN-ID TLV . . . . . . . . . . . . . . . . . . . . 11 67 7.2.3. PCE-ID TLV . . . . . . . . . . . . . . . . . . . . . 12 68 7.3. Candidate Node List . . . . . . . . . . . . . . . . . . . 13 69 7.4. Result Path List . . . . . . . . . . . . . . . . . . . . 14 70 7.5. Request Message Extension . . . . . . . . . . . . . . . . 14 71 7.6. Reply Message Extension . . . . . . . . . . . . . . . . . 15 72 8. Suggestion to improve performance . . . . . . . . . . . . . . 15 73 9. Manageability Considerations . . . . . . . . . . . . . . . . 15 74 9.1. Control of Function and Policy . . . . . . . . . . . . . 15 75 9.2. Information and Data Models . . . . . . . . . . . . . . . 15 76 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 77 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 78 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 79 9.6. Impact On Network Operations . . . . . . . . . . . . . . 16 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 11.1. Request Parameter Bit Flags . . . . . . . . . . . . . . 16 83 11.2. New PCEP Object . . . . . . . . . . . . . . . . . . . . 16 84 11.2.1. NODE-FLAGS Object . . . . . . . . . . . . . . . . . 16 85 11.3. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 17 86 11.3.1. DOMAIN-ID TLV . . . . . . . . . . . . . . . . . . . 17 87 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 90 13.2. Informative References . . . . . . . . . . . . . . . . . 18 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 It would be useful to extend MPLS TE capabilities across multiple 96 domains (i.e., IGP areas or Autonomous Systems) to support inter- 97 domain resources optimization, to provide strict QoS guarantees 98 between two edge routers located within distinct domains. 100 [RFC4105] "Requirements for Inter-Area MPLS TE" lists the 101 requirements for computing a shortest path for a TE LSP crossing 102 multiple IGP areas; and [RFC4216] "MPLS Inter-Autonomous System (AS) 103 TE Requirements" describes the requirements for computing a shortest 104 path for a TE LSP crossing multiple ASes. [RFC4655] "A PCE-Based 105 Architecture" discusses centralized and distributed computation 106 models for the computation of a path for a TE LSP crossing multiple 107 domains. 109 This document presents a forward search procedure to address these 110 requirements using multiple Path Computation Elements (PCEs). This 111 procedure guarantees that the path found from the source to the 112 destination is shortest. It does not depend on any sequence of 113 domains from the source node to the destination node. Navigating a 114 mesh of domains is simple and efficient. 116 2. Terminology 118 The following terminology is used in this document. 120 ABR: Area Border Router. Router used to connect two IGP areas 121 (Areas in OSPF or levels in IS-IS). 123 ASBR: Autonomous System Border Router. Router used to connect 124 together ASes of the same or different service providers via one 125 or more inter-AS links. 127 BN: Boundary Node. A boundary node is either an ABR in the context 128 of inter-area Traffic Engineering or an ASBR in the context of 129 inter-AS Traffic Engineering. 131 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) 132 along the path found from the source node to the BN, where 133 domain(n-1) is the previous hop domain of domain(n). 135 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 136 the path found from the source node to the BN, where domain(n+1) 137 is the next hop domain of domain(n). 139 Inter-area TE LSP: a TE LSP that crosses an IGP area boundary. 141 Inter-AS TE LSP: a TE LSP that crosses an AS boundary. 143 LSP: Label Switched Path 145 LSR: Label Switching Router 147 PCC: Path Computation Client. Any client application requesting a 148 path computation to be performed by a Path Computation Element. 150 PCE: Path Computation Element. An entity (component, application, 151 or network node) that is capable of computing a network path or 152 route based on a network graph and applying computational 153 constraints. 155 PCE(i): a PCE with the scope of domain(i). 157 TED: Traffic Engineering Database. 159 This document uses terminology defined in [RFC5440]. 161 3. Conventions Used in This Document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 4. Requirements 169 This section summarizes the requirements specific for computing a 170 path for a P2P Traffic Engineering (TE) LSP crossing multiple domains 171 (areas or ASes). More requirements for Inter-Area and Inter-AS MPLS 172 Traffic Engineering are described in [RFC4105] and [RFC4216]. 174 A number of requirements specific for a solution to compute a path 175 for a P2P TE LSP crossing multiple domains is listed as follows: 177 1. The solution SHOULD provide the capability to compute a shortest 178 path dynamically, satisfying a set of specified constraints 179 across multiple IGP areas. 181 2. The solution MUST provide the ability to reoptimize in a 182 minimally disruptive manner (make before break) an inter-area TE 183 LSP, should a more optimal path appear in any traversed IGP area. 185 3. The solution SHOULD provide mechanism(s) to compute a shortest 186 end-to-end path for a TE LSP crossing multiple ASes and 187 satisfying a set of specified constraints dynamically. 189 4. Once an inter-AS TE LSP has been established, and should there be 190 any resource or other changes inside anyone of the ASes, the 191 solution MUST be able to re-optimize the LSP accordingly and non- 192 disruptively, either upon expiration of a configurable timer or 193 upon being triggered by a network event or a manual request at 194 the TE tunnel Head-End. 196 5. Forward Search Path Computation 198 This section gives an overview of the forward search path computation 199 procedure (FSPC for short) to satisfy the requirements described 200 above and describes the procedure in detail. 202 5.1. Overview of Procedure 204 Simply speaking, the idea of FSPC for computing a path for an MPLS TE 205 P2P LSP crossing multiple domains from a source node to a destination 206 node includes: 208 Start from the source node and the source domain. 210 Consider the optimal path segment from the source node to every exit 211 boundary node of the source domain as a special link; 213 Consider the optimal path segment from an entry boundary node to 214 every exit boundary node and the destination node of a domain as a 215 special link; and the optimal path segment is computed as needed. 217 The whole topology consisting of many domains can be considered as a 218 special topology, which contains those special links and the inter- 219 domain links. 221 Compute an optimal path in this special topology from the source node 222 to the destination node using CSPF. 224 5.2. Description of Procedure 226 Suppose that we have the following variables: 228 A current PCE named as CurrentPCE which is currently computing the 229 path. 231 A candidate node list named as CandidateNodeList, which contains the 232 nodes to each of which the temporary optimal path from the source 233 node is currently found and satisfies a set of given constraints. 234 The information about each node C in CandidateNodeList consists of: 236 o the cost of the path from the source node to node C, 237 o the hopcount of the path from the source node to node C, 239 o the previous hop node P and the link between P and C, 241 o the domain list of C (ABR or ASBR) where C has visibility to 242 multiple domains and clearly mark the domain by which C is added 243 to CandidateNodeList, 245 o the PCE responsible for C (i.e., the PCE responsible for the 246 domain containing C. Alternatively, we may use the above 247 mentioned domain instead of the PCE.), and 249 o the flags for C. 251 The flags include: 253 o bit D indicating that C is a Destination node if it is set, 255 o bit S indicating that C is the Source node if it is set, 257 o bit T indicating that C is on result path Tree if it is set. 259 The nodes in CandidateNodeList are ordered by path cost. Initially, 260 CandidateNodeList contains only a Source Node, with path cost 0, PCE 261 responsible for the source domain. 263 A result path list or tree named as ResultPathTree, which contains 264 the final optimal paths from the source node to the boundary nodes or 265 the destination node. Initially, ResultPathTree is empty. 267 Alternatively, the result path list or tree can be combined into the 268 CandidateNodeList. We may set bit T to one in the NODE-FLAGS object 269 for the candidate node when grafting it into the existing result path 270 list or tree. Thus all the candidate nodes with bit T set to one in 271 the CandidateNodeList constitute the result path tree or list. 273 FSPC for computing the path for the MPLS TE P2P LSP is described as 274 follows: 276 Initially, a PCC sets ResultPathTree to empty and CandidateNodeList 277 to contain the source node and sends PCE responsible for the source 278 domain a PCReq with the source node, the destination node, 279 CandidateNodeList and ResultPathTree. 281 When the PCE responsible for a domain (called current domain) 282 receives a request for computing the path for the MPLS TE P2P LSP, it 283 obtains node Cm with the minimum path cost in the CandidateNodeList. 284 The node Cm is the first node in the CandidateNodeList, which is 285 sorted by path cost. It checks whether the CurrentPCE is the PCE 286 responsible for the node Cm(always expand node Cm only if it is an 287 entry boundary node). If it is, then remove Cm from 288 CandidateNodeList and graft it into ResultPathTree (i.e., set flag 289 bit T of node Cm to one); otherwise, a PCReq message is sent to the 290 PCE for node Cm (see Section 5.3 for the case that there is not any 291 direct session between the CurrentPCE and the PCE for node Cm). 293 Suppose that node Cm is in the current domain. The ResultPathTree is 294 built from Cm in the following steps. 296 If node Cm is the destination node, then the optimal path from the 297 source node to the destination node is found, and a PCRep message 298 with the path is sent to the PCE/PCC which sends the request to the 299 CurrentPCE. 301 If node Cm is an entry boundary node or the source node, then the 302 optimal path segments from node Cm to the destination node (if it is 303 in the current domain) and every exit boundary node of the current 304 domain that is not on the result path tree and satisfies the given 305 constraints are computed through using CSPF and as special links. 307 For every node N connected to node Cm through a special link (i.e., 308 the optimal path segment satisfying the given constraints), it is 309 merged into CandidateNodeList. The cost to node N is the sum of the 310 cost to node Cm and the cost of the special link (i.e., the path 311 segment) between Cm and N. If node N is not in the 312 CandidateNodeList, then node N is added into the list with the cost 313 to node N, node Cm as its previous hop node and the PCE for node N. 314 The PCE for node N is the CurrentPCE if node N is an ASBR; otherwise 315 (node N is an ABR, an exit boundary node of the current domain and an 316 entry boundary node of the domain next to the current domain) the PCE 317 for node N is the PCE for the next domain. If node N is in the 318 CandidateNodeList and the cost to node N through node Cm is less than 319 the cost to node N in the list, then replace the cost to node N in 320 the list with the cost to node N through node Cm and the previous hop 321 to node N in the list with node Cm. 323 If node Cm is an exit boundary node and there are inter-domain links 324 connecting to it (i.e., node Cm is an ASBR) and satisfying the 325 constraints, then for every node N connecting to Cm, satisfying the 326 constraints and not on the result path tree, it is merged into the 327 CandidateNodeList. The cost to node N is the sum of the cost to node 328 Cm and the cost of the link between Cm and N. If node N is not in 329 the CandidateNodeList, then node N is added into the list with the 330 cost to node N, node Cm as its previous hop node and the PCE for node 331 N. If node N is in the CandidateNodeList and the cost to node N 332 through node Cm is less than the cost to node N in the list, then 333 replace the cost to node N in the list with the cost to node N 334 through node Cm and the previous hop to node N in the list with node 335 Cm. 337 After the CandidateNodeList is updated, there will be a new node Cm 338 with the minimum cost in the updated CandidateNodeList. If the 339 CurrentPCE is the same as the PCE for the new node Cm, then the node 340 Cm is removed from the CandidateNodeList and grafted to 341 ResultPathTree (i.e., set flag bit T of node Cm to one), and the 342 above steps are repeated; otherwise, a request message is to be sent 343 to the PCE for node Cm. 345 Note that if node Cm has visibility to multiple domains, do not 346 remove it from the CandidateNodeList until it is expanded in all 347 domains. Also mark in the domain list of node Cm, for which domains 348 it is already expanded. 350 5.3. Processing Request and Reply Messages 352 In this section, we describe the processing of the request and reply 353 messages with Forward search bit set for FSPC. Each of the request 354 and reply messages mentioned below has its Forward search bit set 355 even though we do not indicate this explicitly. 357 In the case that a reply message is a final reply, which contains the 358 optimal path from the source to the destination, the reply message is 359 sent toward the PCC along the path that the request message goes from 360 the PCC to the current PCE in reverse direction. 362 In the case that a request message is to be sent to the PCE for node 363 Cm with the minimum cost in the CandidateNodeList and there is a PCE 364 session between the current domain and the next domain containing 365 node Cm, the CurrentPCE sends the PCE for node Cm through the session 366 a request message with the source node, the destination node, 367 CandidateNodeList and ResultPathTree. 369 In the case that a request message is to be sent to the PCE for node 370 Cm and there is not any PCE session between the CurrentPCE and the 371 PCE for node Cm, a request message with T bit set to one in RP is 372 sent toward a branch point on the result path tree from the current 373 domain along the path that the request message goes from the PCC to 374 the CurrentPCE in reverse direction. From the branch point, there is 375 a downward path to the domain containing the previous hop node of 376 node Cm on the result path tree and to the domain containing node Cm. 377 At this branch point, the request message with T bit set to zero is 378 sent to the PCE for node Cm along the downward path. 380 6. Comparing to BRPC 382 [RFC5441] describes the Backward Recursive Path Computation (BRPC) 383 algorithm or procedure for computing an MPLS TE P2P LSP path from a 384 source node to a destination node crossing multiple domains. 385 Comparing to BRPC, there are a number of differences between BRPC and 386 the Forward-Search P2P TE LSP Inter-Domain Path Computation (FSPC). 387 Some of the differences are briefed below. 389 First, for BRPC to compute a shortest path from a source node to a 390 destination node crossing multiple domains, we MUST provide a 391 sequence of domains from the source node to the destination node to 392 BRPC in advance. It is a big burden and very challenging for users 393 to provide a sequence of domains for every LSP path crossing domains 394 in general. In addition, it increases the cost of operation and 395 maintenance of the network. FSPC does not need any sequence of 396 domains for computing a shortest path. 398 Secondly, for a given sequence of domains domain(1), domain(2), ... 399 ,domain(n), BRPC searches the shortest path from domain(n), to 400 domain(n-1), until domain(1) along the reverse order of the given 401 sequence of domain. It will get the shortest path within the given 402 domain sesuence. FSPC calculates an optimal path in a special 403 topology from the source node to the destination node. It will find 404 the shortest path within all the domains. 406 Moreover, if the sequence of domains from the source node to the 407 destination node provided to BRPC does not contain the shortest path 408 from the source to the destination, then the path computed by BRPC is 409 not optimal. FSPC guarantees that the path found is optimal. 411 7. Extensions to PCEP 413 This section describes the extensions to PCEP for FSPC. The 414 extensions include the definition of a new flag in the RP object, a 415 result path list and a candidate node list in the PCReq and PCRep 416 message. 418 7.1. RP Object Extension 420 The following flags are added into the RP Object: 422 The F bit is added in the flag bits field of the RP object to tell 423 the receiver of the message that the request/reply is for FSPC. 425 o F (FSPC bit - 1 bit): 426 0: This indicates that this is not a PCReq/PCRep for FSPC. 427 1: This indicates that this is a PCReq or PCRep for FSPC. 429 The T bit is added in the flag bits field of the RP object to tell 430 the receiver of the message that the request is for transferring a 431 request message to the domain containing the node with minimum cost 432 in the candidate list. 434 o T (Transfer request bit - 1 bit): 435 0: This indicates that this is not a PCReq 436 for transferring a request message. 437 1: This indicates that this is a PCReq message 438 for transferring a request message. 440 Setting Transfer request T-bit in a RP Object to one indicates that a 441 reqest message containing the RP Object is for transferring a request 442 message to the domain containing the node with minimum cost in the 443 candidate list. 445 The IANA request is referenced in Section below (Request Parameter 446 Bit Flags) of this document. 448 This F bit with the N bit defined in [RFC6006] can indicate whether 449 the request/reply is for FSPC of an MPLS TE P2P LSP or an MPLS TE 450 P2MP LSP. 452 o F = 1 and N = 0: This indicates that this is a PCReq/PCRep 453 message for FSPC of an MPLS TE P2P LSP. 454 o F = 1 and N = 1: This indicates that this is a PCReq/PCRep 455 message for FSPC of an MPLS TE P2MP LSP. 457 7.2. NODE-FLAGS Object 459 The NODE-FLAGS object is used to indicate the characteristics of the 460 node in a Candidate Node List in a request or reply message for FSPC. 461 The NODE-FLAGS object comprises a Reserved field, and a number of 462 Flags. The NODE-FLAGS object may also contain a set of TLVs. 464 The format of the NODE-FLAGS object body is as follows: 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 |D|S|T| Flags | Reserved | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 ~ Optional TLVs ~ 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 NODE-FLAGS Object Body 477 where 479 o D = 1: The node is a destination node. 481 o S = 1: The node is a source node. 483 o T = 1: The node is on the result path tree. 485 Following are the TLVs defined to convey the characteristics of the 486 candidate node. 488 7.2.1. PREVIOUS-NODE TLV 490 The PREVIOUS-NODE TLV contains the Previous Node Id of the candidate 491 node. The PREVIOUS-NODE TLV has the following format: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | address-type | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | | 499 ~ Previous Node Id ~ 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 PREVIOUS-NODE TLV format 504 The Type of PREVIOUS-NODE TLV is to be assigned by IANA. 506 The length is 8 if the address type is IPv4 or 20 if the address type 507 is IPV6. 509 Address Type (16 bits): Indicates the address type of Previous Node 510 Id. 1 means IPv4 address type, 2 means IPv6 address type. 512 Reserved(16 bits): SHOULD be set to zero on transmission and MUST be 513 ignored on receipt. 515 Previous Node Id : IP address of the node. 517 7.2.2. DOMAIN-ID TLV 519 The DOMAIN-ID TLV contains the domain Id of the candidate node (ABR 520 or ASBR). The NODE-FLAG Object may include multiple DOMAIN-ID TLVs 521 when the candidate node has visibility into multiple Domains. 523 The DOMAIN-ID TLV has the following format: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Domain Type | Flags |C|V| 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Domain ID | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 DOMAIN-ID TLV format 535 The Type of DOMAIN-ID TLV is to be assigned by IANA. 537 The length is 8. 539 Domain Type (8 bits): Indicates the domain type. There are two types 540 of domain defined currently: 542 o Type=1: the Domain ID field carries an IGP Area ID. 544 o Type=2: the Domain ID field carries an AS number. 546 C Flag (1 bit): If the flag is set to 1, it indicates the candidate 547 node is added into Candidate Node List by this domain. 549 V Flag (1 bit): If the flag is set to 1, it indicates the candidate 550 node has been expanded in this domain. 552 Domain ID (32 bits): With the Domain Type set to 1, this indicates 553 the 32-bit Area ID of an IGP area where the candidate belongs. With 554 Domain Type set to 2, this indicates an AS number of an AS where the 555 candidate belongs. When the AS number is coded in two octets, the AS 556 Number field MUST have its first two octets set to 0. 558 [Editor's note: [PCE-HIERARCHY-EXT], section 3.1.3 deals with the 559 encoding of Domain-Id TLV in OPEN Object. Later on DOMAIN-ID TLV 560 defined here can be incorporate with this draft] 562 7.2.3. PCE-ID TLV 564 The PCE-ID TLV is used to indicate the PCE that added this node to 565 the CandidateList. The PCE-ID TLV has the following format: 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Address Type | Reserved | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | | 573 ~ PCE IP Address ~ 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 PCE-ID TLV format 578 The type of PCE-ID TLV is to be assigned by IANA. 580 The length is 8. 582 Address Type (16 bits): Indicates the address type of PCE IP Address. 583 1 means IPv4 address type, 2 means IPv6 address type. 585 PCE IP Address: Indicates the reachable address of a PCE. 587 [Editor's note: [PCE-HIERARCHY-EXT], section 3.1.4 deals with the 588 encoding of PCE-Id TLV in OPEN Object. Later on PCE-ID TLV defined 589 here can be incorporate with this draft] 591 7.3. Candidate Node List 593 The Candidate Node List has the following format: 595 ::= 596 [] 597 where 599 ::= 600 602 ::= 603 [] 605 ::=[] 607 The ERO in a candidate node contain just the path segment of the last 608 link of the path, which is from the previous hop node of the tail end 609 node of the path to the tail end node. With this information, we can 610 graft the candidate node into the existing result path list or tree. 612 Simply speaking, a candidate node has the same or similar format of a 613 path defined in [RFC5440], but the ERO in the candidate node just 614 contain the tail end node of the path and its previous hop, and the 615 candidate path may contain a new object NODE-FLAGS along with new 616 TLVs. 618 7.4. Result Path List 620 The Result Path List has the following format: 622 ::= 623 [] 624 where 626 ::= 627 629 ::= 630 [] 632 ::=[] 634 The usage of ERO, NODE-FLAGS objects etc, is similar to Candidate 635 Node List. The T-bit of NODE-FLAGS Object would be set denoting that 636 the best path to this node is already found. 638 7.5. Request Message Extension 640 Below is the message format for a request message with the extension 641 of result-path-list and candidate-node-list: 643 ::= 644 [] 645 647 ::=[] 649 ::= [] [] [] 650 [] [[]] [] 651 [] 652 [] 653 [] 654 where: 655 and 656 are as defined above. 658 7.6. Reply Message Extension 660 Below is the message format for a reply message with the extension of 661 result-path-list and candidate-node-list: 663 ::= 664 666 ::=[] 668 ::= [] [] 669 [] 670 [] 671 [] 672 where: 673 and 674 are as defined above. 676 If the path from the source to the destination is found, the reply 677 message contains path-list comprising the information of the path. 679 8. Suggestion to improve performance 681 To get much better performance all the candidate nodes of current 682 domain can be expanded before moving on to a new domain. Note in 683 this case, after expanding the least cost candidate node, PCE can 684 look for and expand any other candidates in this domain. 686 9. Manageability Considerations 688 9.1. Control of Function and Policy 690 TBD 692 9.2. Information and Data Models 694 TBD 696 9.3. Liveness Detection and Monitoring 698 TBD 700 9.4. Verify Correct Operations 702 TBD 704 9.5. Requirements On Other Protocols 706 TBD 708 9.6. Impact On Network Operations 710 TBD 712 10. Security Considerations 714 The mechanism described in this document does not raise any new 715 security issues for the PCEP protocols. 717 11. IANA Considerations 719 This section specifies requests for IANA allocation. 721 11.1. Request Parameter Bit Flags 723 Two new RP Object Flags have been defined in this document. IANA is 724 requested to make the following allocation from the "PCEP RP Object 725 Flag Field" Sub-Registry: 727 Bit Description Reference 728 TBA FSPC (F-bit) This I-D 729 TBA Transfer Request (T-bit) This I-D 731 Setting FSPC F-bit in a RP Object to one indicates that a request/ 732 reply message containing the RP Object is for FSPC. 734 Setting Transfer Request T-bit in a RP Object to one indicates that a 735 request message containing the RP Object is for transferring a 736 request message to the domain containing the node with minimum cost 737 in the candidate list. 739 11.2. New PCEP Object 741 11.2.1. NODE-FLAGS Object 743 The NODE-FLAGS Object-Type and Object-Class has been defined in this 744 document. IANA is requested to make the following allocation: 746 NODE-FLAGS Object-Type : TBA 748 NODE-FLAGS Object-Class: TBA 750 Flag field of the NODE-FLAG Object: 752 Bit Description Reference 753 0 The node is a destination node This I-D 754 1 The node is a source node This I-D 755 2 The node is on the result path tree This I-D 757 Each bit should be tracked with the following qualities: 759 o Bit number (counting from bit 0 as the most significant bit) 761 o Name flag 763 o Reference 765 11.3. New PCEP TLV 767 IANA is requested to make the following allocation: 769 Value Meaning Reference 770 TBA DOMAIN-ID TLV This I-D 771 TBA PCE-ID TLV This I-D 772 TBA PREVIOUS-NODE TLV This I-D 774 11.3.1. DOMAIN-ID TLV 776 IANA is requested to make the following allocation: 778 Flag field of the DOMAIN-ID TLV 780 Bit Name Description Reference 781 15 V-bit Candidate Node has been expanded by This I-D 782 the domain 783 14 C-bit Candidate Node added by the domain This I-D 785 Each bit should be tracked with the following qualities: 787 o Bit number (counting from bit 0 as the most significant bit) 789 o Name flag 791 o Reference 793 12. Acknowledgement 795 The authors would like to appreciate Dhruv Dhody for his great 796 contributions and to thank Julien Meuric, Daniel King, Ramon 797 Casellas, Cyril Margaria,Olivier Dugeon, Oscar Gonzalez de Dios, 798 Udayasree Palle, Reeja Paul and Sandeep Kumar Boina for their 799 valuable comments on this draft. 801 13. References 803 13.1. Normative References 805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 806 Requirement Levels", BCP 14, RFC 2119, 807 DOI 10.17487/RFC2119, March 1997, 808 . 810 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 811 Element (PCE)-Based Architecture", RFC 4655, 812 DOI 10.17487/RFC4655, August 2006, 813 . 815 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 816 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 817 DOI 10.17487/RFC5440, March 2009, 818 . 820 13.2. Informative References 822 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., 823 "Requirements for Inter-Area MPLS Traffic Engineering", 824 RFC 4105, DOI 10.17487/RFC4105, June 2005, 825 . 827 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous 828 System (AS) Traffic Engineering (TE) Requirements", 829 RFC 4216, DOI 10.17487/RFC4216, November 2005, 830 . 832 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 833 "A Backward-Recursive PCE-Based Computation (BRPC) 834 Procedure to Compute Shortest Constrained Inter-Domain 835 Traffic Engineering Label Switched Paths", RFC 5441, 836 DOI 10.17487/RFC5441, April 2009, 837 . 839 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 840 Ali, Z., and J. Meuric, "Extensions to the Path 841 Computation Element Communication Protocol (PCEP) for 842 Point-to-Multipoint Traffic Engineering Label Switched 843 Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, 844 . 846 [PCE-HIERARCHY-EXT] 847 Zhang, F., Zhao, Q., King, O., Casellas, R., and D. King, 848 "Extensions to Path Computation Element Communication 849 Protocol (PCEP) for Hierarchical Path Computation Elements 850 (PCE) (draft-zhang-pce-hierarchy-extensions-02)", August 851 2012. 853 Author's Address 855 Huaimo Chen 856 Futurewei 857 Boston, MA 858 USA 860 EMail: Huaimo.chen@futurewei.com