idnits 2.17.1 draft-chen-pce-forward-search-p2p-path-computation-16.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 7, 2019) is 1753 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 D. Dhody 5 Expires: January 8, 2020 Huawei Technologies 6 July 7, 2019 8 A Forward-Search P2P TE LSP Inter-Domain Path Computation 9 draft-chen-pce-forward-search-p2p-path-computation-16 11 Abstract 13 This document presents a forward search procedure for computing paths 14 for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched 15 Paths (LSPs) crossing a number of domains using multiple Path 16 Computation Elements (PCEs). In addition, extensions to the Path 17 Computation Element Communication Protocol (PCEP) for supporting the 18 forward search procedure are described. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 8, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 57 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Forward Search Path Computation . . . . . . . . . . . . . . . 5 59 5.1. Overview of Procedure . . . . . . . . . . . . . . . . . . 5 60 5.2. Description of Procedure . . . . . . . . . . . . . . . . 5 61 5.3. Processing Request and Reply Messages . . . . . . . . . . 8 62 6. Comparing to BRPC . . . . . . . . . . . . . . . . . . . . . . 9 63 7. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 9 64 7.1. RP Object Extension . . . . . . . . . . . . . . . . . . . 9 65 7.2. NODE-FLAGS Object . . . . . . . . . . . . . . . . . . . . 10 66 7.2.1. PREVIOUS-NODE TLV . . . . . . . . . . . . . . . . . . 11 67 7.2.2. DOMAIN-ID TLV . . . . . . . . . . . . . . . . . . . . 11 68 7.2.3. PCE-ID TLV . . . . . . . . . . . . . . . . . . . . . 12 69 7.3. Candidate Node List . . . . . . . . . . . . . . . . . . . 13 70 7.4. Result Path List . . . . . . . . . . . . . . . . . . . . 14 71 7.5. Request Message Extension . . . . . . . . . . . . . . . . 14 72 7.6. Reply Message Extension . . . . . . . . . . . . . . . . . 15 73 8. Suggestion to improve performance . . . . . . . . . . . . . . 15 74 9. Manageability Considerations . . . . . . . . . . . . . . . . 15 75 9.1. Control of Function and Policy . . . . . . . . . . . . . 15 76 9.2. Information and Data Models . . . . . . . . . . . . . . . 15 77 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 78 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 15 79 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 80 9.6. Impact On Network Operations . . . . . . . . . . . . . . 16 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 11.1. Request Parameter Bit Flags . . . . . . . . . . . . . . 16 84 11.2. New PCEP Object . . . . . . . . . . . . . . . . . . . . 16 85 11.2.1. NODE-FLAGS Object . . . . . . . . . . . . . . . . . 16 86 11.3. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 17 87 11.3.1. DOMAIN-ID TLV . . . . . . . . . . . . . . . . . . . 17 88 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 91 13.2. Informative References . . . . . . . . . . . . . . . . . 18 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 It would be useful to extend MPLS TE capabilities across multiple 97 domains (i.e., IGP areas or Autonomous Systems) to support inter- 98 domain resources optimization, to provide strict QoS guarantees 99 between two edge routers located within distinct domains. 101 [RFC4105] "Requirements for Inter-Area MPLS TE" lists the 102 requirements for computing a shortest path for a TE LSP crossing 103 multiple IGP areas; and [RFC4216] "MPLS Inter-Autonomous System (AS) 104 TE Requirements" describes the requirements for computing a shortest 105 path for a TE LSP crossing multiple ASes. [RFC4655] "A PCE-Based 106 Architecture" discusses centralized and distributed computation 107 models for the computation of a path for a TE LSP crossing multiple 108 domains. 110 This document presents a forward search procedure to address these 111 requirements using multiple Path Computation Elements (PCEs). This 112 procedure guarantees that the path found from the source to the 113 destination is shortest. It does not depend on any sequence of 114 domains from the source node to the destination node. Navigating a 115 mesh of domains is simple and efficient. 117 2. Terminology 119 The following terminology is used in this document. 121 ABR: Area Border Router. Router used to connect two IGP areas 122 (Areas in OSPF or levels in IS-IS). 124 ASBR: Autonomous System Border Router. Router used to connect 125 together ASes of the same or different service providers via one 126 or more inter-AS links. 128 BN: Boundary Node. A boundary node is either an ABR in the context 129 of inter-area Traffic Engineering or an ASBR in the context of 130 inter-AS Traffic Engineering. 132 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) 133 along the path found from the source node to the BN, where 134 domain(n-1) is the previous hop domain of domain(n). 136 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 137 the path found from the source node to the BN, where domain(n+1) 138 is the next hop domain of domain(n). 140 Inter-area TE LSP: a TE LSP that crosses an IGP area boundary. 142 Inter-AS TE LSP: a TE LSP that crosses an AS boundary. 144 LSP: Label Switched Path 146 LSR: Label Switching Router 148 PCC: Path Computation Client. Any client application requesting a 149 path computation to be performed by a Path Computation Element. 151 PCE: Path Computation Element. An entity (component, application, 152 or network node) that is capable of computing a network path or 153 route based on a network graph and applying computational 154 constraints. 156 PCE(i): a PCE with the scope of domain(i). 158 TED: Traffic Engineering Database. 160 This document uses terminology defined in [RFC5440]. 162 3. Conventions Used in This Document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 4. Requirements 170 This section summarizes the requirements specific for computing a 171 path for a P2P Traffic Engineering (TE) LSP crossing multiple domains 172 (areas or ASes). More requirements for Inter-Area and Inter-AS MPLS 173 Traffic Engineering are described in [RFC4105] and [RFC4216]. 175 A number of requirements specific for a solution to compute a path 176 for a P2P TE LSP crossing multiple domains is listed as follows: 178 1. The solution SHOULD provide the capability to compute a shortest 179 path dynamically, satisfying a set of specified constraints 180 across multiple IGP areas. 182 2. The solution MUST provide the ability to reoptimize in a 183 minimally disruptive manner (make before break) an inter-area TE 184 LSP, should a more optimal path appear in any traversed IGP area. 186 3. The solution SHOULD provide mechanism(s) to compute a shortest 187 end-to-end path for a TE LSP crossing multiple ASes and 188 satisfying a set of specified constraints dynamically. 190 4. Once an inter-AS TE LSP has been established, and should there be 191 any resource or other changes inside anyone of the ASes, the 192 solution MUST be able to re-optimize the LSP accordingly and non- 193 disruptively, either upon expiration of a configurable timer or 194 upon being triggered by a network event or a manual request at 195 the TE tunnel Head-End. 197 5. Forward Search Path Computation 199 This section gives an overview of the forward search path computation 200 procedure (FSPC for short) to satisfy the requirements described 201 above and describes the procedure in detail. 203 5.1. Overview of Procedure 205 Simply speaking, the idea of FSPC for computing a path for an MPLS TE 206 P2P LSP crossing multiple domains from a source node to a destination 207 node includes: 209 Start from the source node and the source domain. 211 Consider the optimal path segment from the source node to every exit 212 boundary node of the source domain as a special link; 214 Consider the optimal path segment from an entry boundary node to 215 every exit boundary node and the destination node of a domain as a 216 special link; and the optimal path segment is computed as needed. 218 The whole topology consisting of many domains can be considered as a 219 special topology, which contains those special links and the inter- 220 domain links. 222 Compute an optimal path in this special topology from the source node 223 to the destination node using CSPF. 225 5.2. Description of Procedure 227 Suppose that we have the following variables: 229 A current PCE named as CurrentPCE which is currently computing the 230 path. 232 A candidate node list named as CandidateNodeList, which contains the 233 nodes to each of which the temporary optimal path from the source 234 node is currently found and satisfies a set of given constraints. 235 The information about each node C in CandidateNodeList consists of: 237 o the cost of the path from the source node to node C, 238 o the hopcount of the path from the source node to node C, 240 o the previous hop node P and the link between P and C, 242 o the domain list of C (ABR or ASBR) where C has visibility to 243 multiple domains and clearly mark the domain by which C is added 244 to CandidateNodeList, 246 o the PCE responsible for C (i.e., the PCE responsible for the 247 domain containing C. Alternatively, we may use the above 248 mentioned domain instead of the PCE.), and 250 o the flags for C. 252 The flags include: 254 o bit D indicating that C is a Destination node if it is set, 256 o bit S indicating that C is the Source node if it is set, 258 o bit T indicating that C is on result path Tree if it is set. 260 The nodes in CandidateNodeList are ordered by path cost. Initially, 261 CandidateNodeList contains only a Source Node, with path cost 0, PCE 262 responsible for the source domain. 264 A result path list or tree named as ResultPathTree, which contains 265 the final optimal paths from the source node to the boundary nodes or 266 the destination node. Initially, ResultPathTree is empty. 268 Alternatively, the result path list or tree can be combined into the 269 CandidateNodeList. We may set bit T to one in the NODE-FLAGS object 270 for the candidate node when grafting it into the existing result path 271 list or tree. Thus all the candidate nodes with bit T set to one in 272 the CandidateNodeList constitute the result path tree or list. 274 FSPC for computing the path for the MPLS TE P2P LSP is described as 275 follows: 277 Initially, a PCC sets ResultPathTree to empty and CandidateNodeList 278 to contain the source node and sends PCE responsible for the source 279 domain a PCReq with the source node, the destination node, 280 CandidateNodeList and ResultPathTree. 282 When the PCE responsible for a domain (called current domain) 283 receives a request for computing the path for the MPLS TE P2P LSP, it 284 obtains node Cm with the minimum path cost in the CandidateNodeList. 285 The node Cm is the first node in the CandidateNodeList, which is 286 sorted by path cost. It checks whether the CurrentPCE is the PCE 287 responsible for the node Cm(always expand node Cm only if it is an 288 entry boundary node). If it is, then remove Cm from 289 CandidateNodeList and graft it into ResultPathTree (i.e., set flag 290 bit T of node Cm to one); otherwise, a PCReq message is sent to the 291 PCE for node Cm (see Section 5.3 for the case that there is not any 292 direct session between the CurrentPCE and the PCE for node Cm). 294 Suppose that node Cm is in the current domain. The ResultPathTree is 295 built from Cm in the following steps. 297 If node Cm is the destination node, then the optimal path from the 298 source node to the destination node is found, and a PCRep message 299 with the path is sent to the PCE/PCC which sends the request to the 300 CurrentPCE. 302 If node Cm is an entry boundary node or the source node, then the 303 optimal path segments from node Cm to the destination node (if it is 304 in the current domain) and every exit boundary node of the current 305 domain that is not on the result path tree and satisfies the given 306 constraints are computed through using CSPF and as special links. 308 For every node N connected to node Cm through a special link (i.e., 309 the optimal path segment satisfying the given constraints), it is 310 merged into CandidateNodeList. The cost to node N is the sum of the 311 cost to node Cm and the cost of the special link (i.e., the path 312 segment) between Cm and N. If node N is not in the 313 CandidateNodeList, then node N is added into the list with the cost 314 to node N, node Cm as its previous hop node and the PCE for node N. 315 The PCE for node N is the CurrentPCE if node N is an ASBR; otherwise 316 (node N is an ABR, an exit boundary node of the current domain and an 317 entry boundary node of the domain next to the current domain) the PCE 318 for node N is the PCE for the next domain. If node N is in the 319 CandidateNodeList and the cost to node N through node Cm is less than 320 the cost to node N in the list, then replace the cost to node N in 321 the list with the cost to node N through node Cm and the previous hop 322 to node N in the list with node Cm. 324 If node Cm is an exit boundary node and there are inter-domain links 325 connecting to it (i.e., node Cm is an ASBR) and satisfying the 326 constraints, then for every node N connecting to Cm, satisfying the 327 constraints and not on the result path tree, it is merged into the 328 CandidateNodeList. The cost to node N is the sum of the cost to node 329 Cm and the cost of the link between Cm and N. If node N is not in 330 the CandidateNodeList, then node N is added into the list with the 331 cost to node N, node Cm as its previous hop node and the PCE for node 332 N. If node N is in the CandidateNodeList and the cost to node N 333 through node Cm is less than the cost to node N in the list, then 334 replace the cost to node N in the list with the cost to node N 335 through node Cm and the previous hop to node N in the list with node 336 Cm. 338 After the CandidateNodeList is updated, there will be a new node Cm 339 with the minimum cost in the updated CandidateNodeList. If the 340 CurrentPCE is the same as the PCE for the new node Cm, then the node 341 Cm is removed from the CandidateNodeList and grafted to 342 ResultPathTree (i.e., set flag bit T of node Cm to one), and the 343 above steps are repeated; otherwise, a request message is to be sent 344 to the PCE for node Cm. 346 Note that if node Cm has visibility to multiple domains, do not 347 remove it from the CandidateNodeList until it is expanded in all 348 domains. Also mark in the domain list of node Cm, for which domains 349 it is already expanded. 351 5.3. Processing Request and Reply Messages 353 In this section, we describe the processing of the request and reply 354 messages with Forward search bit set for FSPC. Each of the request 355 and reply messages mentioned below has its Forward search bit set 356 even though we do not indicate this explicitly. 358 In the case that a reply message is a final reply, which contains the 359 optimal path from the source to the destination, the reply message is 360 sent toward the PCC along the path that the request message goes from 361 the PCC to the current PCE in reverse direction. 363 In the case that a request message is to be sent to the PCE for node 364 Cm with the minimum cost in the CandidateNodeList and there is a PCE 365 session between the current domain and the next domain containing 366 node Cm, the CurrentPCE sends the PCE for node Cm through the session 367 a request message with the source node, the destination node, 368 CandidateNodeList and ResultPathTree. 370 In the case that a request message is to be sent to the PCE for node 371 Cm and there is not any PCE session between the CurrentPCE and the 372 PCE for node Cm, a request message with T bit set to one in RP is 373 sent toward a branch point on the result path tree from the current 374 domain along the path that the request message goes from the PCC to 375 the CurrentPCE in reverse direction. From the branch point, there is 376 a downward path to the domain containing the previous hop node of 377 node Cm on the result path tree and to the domain containing node Cm. 378 At this branch point, the request message with T bit set to zero is 379 sent to the PCE for node Cm along the downward path. 381 6. Comparing to BRPC 383 [RFC5441] describes the Backward Recursive Path Computation (BRPC) 384 algorithm or procedure for computing an MPLS TE P2P LSP path from a 385 source node to a destination node crossing multiple domains. 386 Comparing to BRPC, there are a number of differences between BRPC and 387 the Forward-Search P2P TE LSP Inter-Domain Path Computation (FSPC). 388 Some of the differences are briefed below. 390 First, for BRPC to compute a shortest path from a source node to a 391 destination node crossing multiple domains, we MUST provide a 392 sequence of domains from the source node to the destination node to 393 BRPC in advance. It is a big burden and very challenging for users 394 to provide a sequence of domains for every LSP path crossing domains 395 in general. In addition, it increases the cost of operation and 396 maintenance of the network. FSPC does not need any sequence of 397 domains for computing a shortest path. 399 Secondly, for a given sequence of domains domain(1), domain(2), ... 400 ,domain(n), BRPC searches the shortest path from domain(n), to 401 domain(n-1), until domain(1) along the reverse order of the given 402 sequence of domain. It will get the shortest path within the given 403 domain sesuence. FSPC calculates an optimal path in a special 404 topology from the source node to the destination node. It will find 405 the shortest path within all the domains. 407 Moreover, if the sequence of domains from the source node to the 408 destination node provided to BRPC does not contain the shortest path 409 from the source to the destination, then the path computed by BRPC is 410 not optimal. FSPC guarantees that the path found is optimal. 412 7. Extensions to PCEP 414 This section describes the extensions to PCEP for FSPC. The 415 extensions include the definition of a new flag in the RP object, a 416 result path list and a candidate node list in the PCReq and PCRep 417 message. 419 7.1. RP Object Extension 421 The following flags are added into the RP Object: 423 The F bit is added in the flag bits field of the RP object to tell 424 the receiver of the message that the request/reply is for FSPC. 426 o F (FSPC bit - 1 bit): 427 0: This indicates that this is not a PCReq/PCRep for FSPC. 428 1: This indicates that this is a PCReq or PCRep for FSPC. 430 The T bit is added in the flag bits field of the RP object to tell 431 the receiver of the message that the request is for transferring a 432 request message to the domain containing the node with minimum cost 433 in the candidate list. 435 o T (Transfer request bit - 1 bit): 436 0: This indicates that this is not a PCReq 437 for transferring a request message. 438 1: This indicates that this is a PCReq message 439 for transferring a request message. 441 Setting Transfer request T-bit in a RP Object to one indicates that a 442 reqest message containing the RP Object is for transferring a request 443 message to the domain containing the node with minimum cost in the 444 candidate list. 446 The IANA request is referenced in Section below (Request Parameter 447 Bit Flags) of this document. 449 This F bit with the N bit defined in [RFC6006] can indicate whether 450 the request/reply is for FSPC of an MPLS TE P2P LSP or an MPLS TE 451 P2MP LSP. 453 o F = 1 and N = 0: This indicates that this is a PCReq/PCRep 454 message for FSPC of an MPLS TE P2P LSP. 455 o F = 1 and N = 1: This indicates that this is a PCReq/PCRep 456 message for FSPC of an MPLS TE P2MP LSP. 458 7.2. NODE-FLAGS Object 460 The NODE-FLAGS object is used to indicate the characteristics of the 461 node in a Candidate Node List in a request or reply message for FSPC. 462 The NODE-FLAGS object comprises a Reserved field, and a number of 463 Flags. The NODE-FLAGS object may also contain a set of TLVs. 465 The format of the NODE-FLAGS object body is as follows: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 |D|S|T| Flags | Reserved | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | | 473 ~ Optional TLVs ~ 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 NODE-FLAGS Object Body 478 where 480 o D = 1: The node is a destination node. 482 o S = 1: The node is a source node. 484 o T = 1: The node is on the result path tree. 486 Following are the TLVs defined to convey the characteristics of the 487 candidate node. 489 7.2.1. PREVIOUS-NODE TLV 491 The PREVIOUS-NODE TLV contains the Previous Node Id of the candidate 492 node. The PREVIOUS-NODE TLV has the following format: 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | address-type | Reserved | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 ~ Previous Node Id ~ 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 PREVIOUS-NODE TLV format 505 The Type of PREVIOUS-NODE TLV is to be assigned by IANA. 507 The length is 8 if the address type is IPv4 or 20 if the address type 508 is IPV6. 510 Address Type (16 bits): Indicates the address type of Previous Node 511 Id. 1 means IPv4 address type, 2 means IPv6 address type. 513 Reserved(16 bits): SHOULD be set to zero on transmission and MUST be 514 ignored on receipt. 516 Previous Node Id : IP address of the node. 518 7.2.2. DOMAIN-ID TLV 520 The DOMAIN-ID TLV contains the domain Id of the candidate node (ABR 521 or ASBR). The NODE-FLAG Object may include multiple DOMAIN-ID TLVs 522 when the candidate node has visibility into multiple Domains. 524 The DOMAIN-ID TLV has the following format: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Domain Type | Flags |C|V| 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Domain ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 DOMAIN-ID TLV format 536 The Type of DOMAIN-ID TLV is to be assigned by IANA. 538 The length is 8. 540 Domain Type (8 bits): Indicates the domain type. There are two types 541 of domain defined currently: 543 o Type=1: the Domain ID field carries an IGP Area ID. 545 o Type=2: the Domain ID field carries an AS number. 547 C Flag (1 bit): If the flag is set to 1, it indicates the candidate 548 node is added into Candidate Node List by this domain. 550 V Flag (1 bit): If the flag is set to 1, it indicates the candidate 551 node has been expanded in this domain. 553 Domain ID (32 bits): With the Domain Type set to 1, this indicates 554 the 32-bit Area ID of an IGP area where the candidate belongs. With 555 Domain Type set to 2, this indicates an AS number of an AS where the 556 candidate belongs. When the AS number is coded in two octets, the AS 557 Number field MUST have its first two octets set to 0. 559 [Editor's note: [PCE-HIERARCHY-EXT], section 3.1.3 deals with the 560 encoding of Domain-Id TLV in OPEN Object. Later on DOMAIN-ID TLV 561 defined here can be incorporate with this draft] 563 7.2.3. PCE-ID TLV 565 The PCE-ID TLV is used to indicate the PCE that added this node to 566 the CandidateList. The PCE-ID TLV has the following format: 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Address Type | Reserved | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | | 574 ~ PCE IP Address ~ 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 PCE-ID TLV format 579 The type of PCE-ID TLV is to be assigned by IANA. 581 The length is 8. 583 Address Type (16 bits): Indicates the address type of PCE IP Address. 584 1 means IPv4 address type, 2 means IPv6 address type. 586 PCE IP Address: Indicates the reachable address of a PCE. 588 [Editor's note: [PCE-HIERARCHY-EXT], section 3.1.4 deals with the 589 encoding of PCE-Id TLV in OPEN Object. Later on PCE-ID TLV defined 590 here can be incorporate with this draft] 592 7.3. Candidate Node List 594 The Candidate Node List has the following format: 596 ::= 597 [] 598 where 600 ::= 601 603 ::= 604 [] 606 ::=[] 608 The ERO in a candidate node contain just the path segment of the last 609 link of the path, which is from the previous hop node of the tail end 610 node of the path to the tail end node. With this information, we can 611 graft the candidate node into the existing result path list or tree. 613 Simply speaking, a candidate node has the same or similar format of a 614 path defined in [RFC5440], but the ERO in the candidate node just 615 contain the tail end node of the path and its previous hop, and the 616 candidate path may contain a new object NODE-FLAGS along with new 617 TLVs. 619 7.4. Result Path List 621 The Result Path List has the following format: 623 ::= 624 [] 625 where 627 ::= 628 630 ::= 631 [] 633 ::=[] 635 The usage of ERO, NODE-FLAGS objects etc, is similar to Candidate 636 Node List. The T-bit of NODE-FLAGS Object would be set denoting that 637 the best path to this node is already found. 639 7.5. Request Message Extension 641 Below is the message format for a request message with the extension 642 of result-path-list and candidate-node-list: 644 ::= 645 [] 646 648 ::=[] 650 ::= [] [] [] 651 [] [[]] [] 652 [] 653 [] 654 [] 655 where: 656 and 657 are as defined above. 659 7.6. Reply Message Extension 661 Below is the message format for a reply message with the extension of 662 result-path-list and candidate-node-list: 664 ::= 665 667 ::=[] 669 ::= [] [] 670 [] 671 [] 672 [] 673 where: 674 and 675 are as defined above. 677 If the path from the source to the destination is found, the reply 678 message contains path-list comprising the information of the path. 680 8. Suggestion to improve performance 682 To get much better performance all the candidate nodes of current 683 domain can be expanded before moving on to a new domain. Note in 684 this case, after expanding the least cost candidate node, PCE can 685 look for and expand any other candidates in this domain. 687 9. Manageability Considerations 689 9.1. Control of Function and Policy 691 TBD 693 9.2. Information and Data Models 695 TBD 697 9.3. Liveness Detection and Monitoring 699 TBD 701 9.4. Verify Correct Operations 703 TBD 705 9.5. Requirements On Other Protocols 707 TBD 709 9.6. Impact On Network Operations 711 TBD 713 10. Security Considerations 715 The mechanism described in this document does not raise any new 716 security issues for the PCEP protocols. 718 11. IANA Considerations 720 This section specifies requests for IANA allocation. 722 11.1. Request Parameter Bit Flags 724 Two new RP Object Flags have been defined in this document. IANA is 725 requested to make the following allocation from the "PCEP RP Object 726 Flag Field" Sub-Registry: 728 Bit Description Reference 729 TBA FSPC (F-bit) This I-D 730 TBA Transfer Request (T-bit) This I-D 732 Setting FSPC F-bit in a RP Object to one indicates that a request/ 733 reply message containing the RP Object is for FSPC. 735 Setting Transfer Request T-bit in a RP Object to one indicates that a 736 request message containing the RP Object is for transferring a 737 request message to the domain containing the node with minimum cost 738 in the candidate list. 740 11.2. New PCEP Object 742 11.2.1. NODE-FLAGS Object 744 The NODE-FLAGS Object-Type and Object-Class has been defined in this 745 document. IANA is requested to make the following allocation: 747 NODE-FLAGS Object-Type : TBA 749 NODE-FLAGS Object-Class: TBA 751 Flag field of the NODE-FLAG Object: 753 Bit Description Reference 754 0 The node is a destination node This I-D 755 1 The node is a source node This I-D 756 2 The node is on the result path tree This I-D 758 Each bit should be tracked with the following qualities: 760 o Bit number (counting from bit 0 as the most significant bit) 762 o Name flag 764 o Reference 766 11.3. New PCEP TLV 768 IANA is requested to make the following allocation: 770 Value Meaning Reference 771 TBA DOMAIN-ID TLV This I-D 772 TBA PCE-ID TLV This I-D 773 TBA PREVIOUS-NODE TLV This I-D 775 11.3.1. DOMAIN-ID TLV 777 IANA is requested to make the following allocation: 779 Flag field of the DOMAIN-ID TLV 781 Bit Name Description Reference 782 15 V-bit Candidate Node has been expanded by This I-D 783 the domain 784 14 C-bit Candidate Node added by the domain This I-D 786 Each bit should be tracked with the following qualities: 788 o Bit number (counting from bit 0 as the most significant bit) 790 o Name flag 792 o Reference 794 12. Acknowledgement 796 The authors would like 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 Authors' Addresses 855 Huaimo Chen 856 Futurewei 857 Boston, MA 858 USA 860 EMail: Huaimo.chen@futurewei.com 862 Dhruv Dhody 863 Huawei Technologies 864 Leela Palace 865 Bangalore, Karnataka 560008 866 INDIA 868 EMail: dhruv.dhody@huawei.com