idnits 2.17.1 draft-chen-pce-forward-search-p2p-path-computation-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (October 31, 2016) is 2724 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 D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 4, 2017 October 31, 2016 7 A Forward-Search P2P TE LSP Inter-Domain Path Computation 8 draft-chen-pce-forward-search-p2p-path-computation-12 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 http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Conventions Used in This Document . . . . . . . . . . . . . . 4 56 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Forward Search 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 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 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 mentioned 247 domain instead of the PCE.), and 249 o the flags for C. The flags include: 251 * bit D indicating that C is a Destination node if it is set, 253 * bit S indicating that C is the Source node if it is set, 255 * bit T indicating that C is on result path Tree if it is set. 257 The nodes in CandidateNodeList are ordered by path cost. Initially, 258 CandidateNodeList contains only a Source Node, with path cost 0, PCE 259 responsible for the source domain. 261 A result path list or tree named as ResultPathTree, which contains 262 the final optimal paths from the source node to the boundary nodes or 263 the destination node. Initially, ResultPathTree is empty. 265 Alternatively, the result path list or tree can be combined into the 266 CandidateNodeList. We may set bit T to one in the NODE-FLAGS object 267 for the candidate node when grafting it into the existing result path 268 list or tree. Thus all the candidate nodes with bit T set to one in 269 the CandidateNodeList constitute the result path tree or list. 271 FSPC for computing the path for the MPLS TE P2P LSP is described as 272 follows: 274 Initially, a PCC sets ResultPathTree to empty and CandidateNodeList 275 to contain the source node and sends PCE responsible for the source 276 domain a PCReq with the source node, the destination node, 277 CandidateNodeList and ResultPathTree. 279 When the PCE responsible for a domain (called current domain) 280 receives a request for computing the path for the MPLS TE P2P LSP, it 281 obtains node Cm with the minimum path cost in the CandidateNodeList. 282 The node Cm is the first node in the CandidateNodeList, which is 283 sorted by path cost. It checks whether the CurrentPCE is the PCE 284 responsible for the node Cm(always expand node Cm only if it is an 285 entry boundary node). If it is, then remove Cm from 286 CandidateNodeList and graft it into ResultPathTree (i.e., set flag 287 bit T of node Cm to one); otherwise, a PCReq message is sent to the 288 PCE for node Cm (see Section 5.3 for the case that there is not any 289 direct session between the CurrentPCE and the PCE for node Cm). 291 Suppose that node Cm is in the current domain. The ResultPathTree is 292 built from Cm in the following steps. 294 If node Cm is the destination node, then the optimal path from the 295 source node to the destination node is found, and a PCRep message 296 with the path is sent to the PCE/PCC which sends the request to the 297 CurrentPCE. 299 If node Cm is an entry boundary node or the source node, then the 300 optimal path segments from node Cm to the destination node (if it is 301 in the current domain) and every exit boundary node of the current 302 domain that is not on the result path tree and satisfies the given 303 constraints are computed through using CSPF and as special links. 305 For every node N connected to node Cm through a special link (i.e., 306 the optimal path segment satisfying the given constraints), it is 307 merged into CandidateNodeList. The cost to node N is the sum of the 308 cost to node Cm and the cost of the special link (i.e., the path 309 segment) between Cm and N. If node N is not in the CandidateNodeList, 310 then node N is added into the list with the cost to node N, node Cm 311 as its previous hop node and the PCE for node N. The PCE for node N 312 is the CurrentPCE if node N is an ASBR; otherwise (node N is an ABR, 313 an exit boundary node of the current domain and an entry boundary 314 node of the domain next to the current domain) the PCE for node N is 315 the PCE for the next domain. If node N is in the CandidateNodeList 316 and the cost to node N through node Cm is less than the cost to node 317 N in the list, then replace the cost to node N in the list with the 318 cost to node N through node Cm and the previous hop to node N in the 319 list with node Cm. 321 If node Cm is an exit boundary node and there are inter-domain links 322 connecting to it (i.e., node Cm is an ASBR) and satisfying the 323 constraints, then for every node N connecting to Cm, satisfying the 324 constraints and not on the result path tree, it is merged into the 325 CandidateNodeList. The cost to node N is the sum of the cost to node 326 Cm and the cost of the link between Cm and N. If node N is not in the 327 CandidateNodeList, then node N is added into the list with the cost 328 to node N, node Cm as its previous hop node and the PCE for node N. 329 If node N is in the CandidateNodeList and the cost to node N through 330 node Cm is less than the cost to node N in the list, then replace the 331 cost to node N in the list with the cost to node N through node Cm 332 and the previous hop to node N in the list with node Cm. 334 After the CandidateNodeList is updated, there will be a new node Cm 335 with the minimum cost in the updated CandidateNodeList. If the 336 CurrentPCE is the same as the PCE for the new node Cm, then the node 337 Cm is removed from the CandidateNodeList and grafted to 338 ResultPathTree (i.e., set flag bit T of node Cm to one), and the 339 above steps are repeated; otherwise, a request message is to be sent 340 to the PCE for node Cm. 342 Note that if node Cm has visibility to multiple domains, do not 343 remove it from the CandidateNodeList until it is expanded in all 344 domains. Also mark in the domain list of node Cm, for which domains 345 it is already expanded. 347 5.3. Processing Request and Reply Messages 349 In this section, we describe the processing of the request and reply 350 messages with Forward search bit set for FSPC. Each of the request 351 and reply messages mentioned below has its Forward search bit set 352 even though we do not indicate this explicitly. 354 In the case that a reply message is a final reply, which contains the 355 optimal path from the source to the destination, the reply message is 356 sent toward the PCC along the path that the request message goes from 357 the PCC to the current PCE in reverse direction. 359 In the case that a request message is to be sent to the PCE for node 360 Cm with the minimum cost in the CandidateNodeList and there is a PCE 361 session between the current domain and the next domain containing 362 node Cm, the CurrentPCE sends the PCE for node Cm through the session 363 a request message with the source node, the destination node, 364 CandidateNodeList and ResultPathTree. 366 In the case that a request message is to be sent to the PCE for node 367 Cm and there is not any PCE session between the CurrentPCE and the 368 PCE for node Cm, a request message with T bit set to one in RP is 369 sent toward a branch point on the result path tree from the current 370 domain along the path that the request message goes from the PCC to 371 the CurrentPCE in reverse direction. From the branch point, there is 372 a downward path to the domain containing the previous hop node of 373 node Cm on the result path tree and to the domain containing node Cm. 374 At this branch point, the request message with T bit set to zero is 375 sent to the PCE for node Cm along the downward path. 377 6. Comparing to BRPC 379 [RFC5441] describes the Backward Recursive Path Computation (BRPC) 380 algorithm or procedure for computing an MPLS TE P2P LSP path from a 381 source node to a destination node crossing multiple domains. 382 Comparing to BRPC, there are a number of differences between BRPC and 383 the Forward-Search P2P TE LSP Inter-Domain Path Computation (FSPC). 384 Some of the differences are briefed below. 386 First, for BRPC to compute a shortest path from a source node to a 387 destination node crossing multiple domains, we MUST provide a 388 sequence of domains from the source node to the destination node to 389 BRPC in advance. It is a big burden and very challenging for users 390 to provide a sequence of domains for every LSP path crossing domains 391 in general. In addition, it increases the cost of operation and 392 maintenance of the network. FSPC does not need any sequence of 393 domains for computing a shortest path. 395 Secondly, for a given sequence of domains domain(1), domain(2), ... 396 ,domain(n), BRPC searches the shortest path from domain(n), to 397 domain(n-1), until domain(1) along the reverse order of the given 398 sequence of domain. It will get the shortest path within the given 399 domain sesuence. FSPC calculates an optimal path in a special 400 topology from the source node to the destination node. It will find 401 the shortest path within all the domains. 403 Moreover, if the sequence of domains from the source node to the 404 destination node provided to BRPC does not contain the shortest path 405 from the source to the destination, then the path computed by BRPC is 406 not optimal. FSPC guarantees that the path found is optimal. 408 7. Extensions to PCEP 410 This section describes the extensions to PCEP for FSPC. The 411 extensions include the definition of a new flag in the RP object, a 412 result path list and a candidate node list in the PCReq and PCRep 413 message. 415 7.1. RP Object Extension 417 The following flags are added into the RP Object: 419 The F bit is added in the flag bits field of the RP object to tell 420 the receiver of the message that the request/reply is for FSPC. 422 o F (FSPC bit - 1 bit): 423 0: This indicates that this is not a PCReq/PCRep for FSPC. 424 1: This indicates that this is a PCReq or PCRep for FSPC. 426 The T bit is added in the flag bits field of the RP object to tell 427 the receiver of the message that the request is for transferring a 428 request message to the domain containing the node with minimum cost 429 in the candidate list. 431 o T (Transfer request bit - 1 bit): 432 0: This indicates that this is not a PCReq 433 for transferring a request message. 434 1: This indicates that this is a PCReq message 435 for transferring a request message. 437 Setting Transfer request T-bit in a RP Object to one indicates that a 438 reqest message containing the RP Object is for transferring a request 439 message to the domain containing the node with minimum cost in the 440 candidate list. 442 The IANA request is referenced in Section below (Request Parameter 443 Bit Flags) of this document. 445 This F bit with the N bit defined in [RFC6006] can indicate whether 446 the request/reply is for FSPC of an MPLS TE P2P LSP or an MPLS TE 447 P2MP LSP. 449 o F = 1 and N = 0: This indicates that this is a PCReq/PCRep 450 message for FSPC of an MPLS TE P2P LSP. 451 o F = 1 and N = 1: This indicates that this is a PCReq/PCRep 452 message for FSPC of an MPLS TE P2MP LSP. 454 7.2. NODE-FLAGS Object 456 The NODE-FLAGS object is used to indicate the characteristics of the 457 node in a Candidate Node List in a request or reply message for FSPC. 458 The NODE-FLAGS object comprises a Reserved field, and a number of 459 Flags. The NODE-FLAGS object may also contain a set of TLVs. 461 The format of the NODE-FLAGS object body is as follows: 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 |D|S|T| Flags | Reserved | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 ~ Optional TLVs ~ 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 NODE-FLAGS Object Body 474 where 476 o D = 1: The node is a destination node. 478 o S = 1: The node is a source node. 480 o T = 1: The node is on the result path tree. 482 Following are the TLVs defined to convey the characteristics of the 483 candidate node. 485 7.2.1. PREVIOUS-NODE TLV 487 The PREVIOUS-NODE TLV contains the Previous Node Id of the candidate 488 node. The PREVIOUS-NODE TLV has the following format: 490 0 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | address-type | Reserved | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 ~ Previous Node Id ~ 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 PREVIOUS-NODE TLV format 501 The Type of PREVIOUS-NODE TLV is to be assigned by IANA. 503 The length is 8 if the address type is IPv4 or 20 if the address type 504 is IPV6. 506 Address Type (16 bits): Indicates the address type of Previous Node 507 Id. 1 means IPv4 address type, 2 means IPv6 address type. 509 Reserved(16 bits): SHOULD be set to zero on transmission and MUST be 510 ignored on receipt. 512 Previous Node Id : IP address of the node. 514 7.2.2. DOMAIN-ID TLV 516 The DOMAIN-ID TLV contains the domain Id of the candidate node (ABR 517 or ASBR). The NODE-FLAG Object may include multiple DOMAIN-ID TLVs 518 when the candidate node has visibility into multiple Domains. 520 The DOMAIN-ID TLV has the following format: 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Domain Type | Flags |C|V| 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Domain ID | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 DOMAIN-ID TLV format 532 The Type of DOMAIN-ID TLV is to be assigned by IANA. 534 The length is 8. 536 Domain Type (8 bits): Indicates the domain type. There are two types 537 of domain defined currently: 539 o Type=1: the Domain ID field carries an IGP Area ID. 541 o Type=2: the Domain ID field carries an AS number. 543 C Flag (1 bit): If the flag is set to 1, it indicates the candidate 544 node is added into Candidate Node List by this domain. 546 V Flag (1 bit): If the flag is set to 1, it indicates the candidate 547 node has been expanded in this domain. 549 Domain ID (32 bits): With the Domain Type set to 1, this indicates 550 the 32-bit Area ID of an IGP area where the candidate belongs. With 551 Domain Type set to 2, this indicates an AS number of an AS where the 552 candidate belongs. When the AS number is coded in two octets, the AS 553 Number field MUST have its first two octets set to 0. 555 [Editor's note: [PCE-HIERARCHY-EXT], section 3.1.3 deals with the 556 encoding of Domain-Id TLV in OPEN Object. Later on DOMAIN-ID TLV 557 defined here can be incorporate with this draft] 559 7.2.3. PCE-ID TLV 561 The PCE-ID TLV is used to indicate the PCE that added this node to 562 the CandidateList. The PCE-ID TLV has the following format: 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Address Type | Reserved | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 ~ PCE IP Address ~ 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 PCE-ID TLV format 575 The type of PCE-ID TLV is to be assigned by IANA. 577 The length is 8. 579 Address Type (16 bits): Indicates the address type of PCE IP Address. 580 1 means IPv4 address type, 2 means IPv6 address type. 582 PCE IP Address: Indicates the reachable address of a PCE. 584 [Editor's note: [PCE-HIERARCHY-EXT], section 3.1.4 deals with the 585 encoding of PCE-Id TLV in OPEN Object. Later on PCE-ID TLV defined 586 here can be incorporate with this draft] 588 7.3. Candidate Node List 590 The Candidate Node List has the following format: 592 ::= 593 [] 594 where 596 ::= 597 599 ::= 600 [] 602 ::=[] 604 The ERO in a candidate node contain just the path segment of the last 605 link of the path, which is from the previous hop node of the tail end 606 node of the path to the tail end node. With this information, we can 607 graft the candidate node into the existing result path list or tree. 609 Simply speaking, a candidate node has the same or similar format of a 610 path defined in [RFC5440], but the ERO in the candidate node just 611 contain the tail end node of the path and its previous hop, and the 612 candidate path may contain a new object NODE-FLAGS along with new 613 TLVs. 615 7.4. Result Path List 617 The Result Path List has the following format: 619 ::= 620 [] 621 where 623 ::= 624 626 ::= 627 [] 629 ::=[] 631 The usage of ERO, NODE-FLAGS objects etc, is similar to Candidate 632 Node List. The T-bit of NODE-FLAGS Object would be set denoting that 633 the best path to this node is already found. 635 7.5. Request Message Extension 637 Below is the message format for a request message with the extension 638 of result-path-list and candidate-node-list: 640 ::= 641 [] 642 644 ::=[] 646 ::= [] [] [] 647 [] [[]] [] 648 [] 649 [] 650 [] 651 where: 652 and 653 are as defined above. 655 7.6. Reply Message Extension 657 Below is the message format for a reply message with the extension of 658 result-path-list and candidate-node-list: 660 ::= 661 663 ::=[] 665 ::= [] [] 666 [] 667 [] 668 [] 669 where: 670 and 671 are as defined above. 673 If the path from the source to the destination is found, the reply 674 message contains path-list comprising the information of the path. 676 8. Suggestion to improve performance 678 To get much better performance all the candidate nodes of current 679 domain can be expanded before moving on to a new domain. Note in 680 this case, after expanding the least cost candidate node, PCE can 681 look for and expand any other candidates in this domain. 683 9. Manageability Considerations 685 9.1. Control of Function and Policy 687 TBD 689 9.2. Information and Data Models 691 TBD 693 9.3. Liveness Detection and Monitoring 695 TBD 697 9.4. Verify Correct Operations 699 TBD 701 9.5. Requirements On Other Protocols 703 TBD 705 9.6. Impact On Network Operations 707 TBD 709 10. Security Considerations 711 The mechanism described in this document does not raise any new 712 security issues for the PCEP protocols. 714 11. IANA Considerations 716 This section specifies requests for IANA allocation. 718 11.1. Request Parameter Bit Flags 720 Two new RP Object Flags have been defined in this document. IANA is 721 requested to make the following allocation from the "PCEP RP Object 722 Flag Field" Sub-Registry: 724 Bit Description Reference 725 TBA FSPC (F-bit) This I-D 726 TBA Transfer Request (T-bit) This I-D 728 Setting FSPC F-bit in a RP Object to one indicates that a request/ 729 reply message containing the RP Object is for FSPC. 731 Setting Transfer Request T-bit in a RP Object to one indicates that a 732 request message containing the RP Object is for transferring a 733 request message to the domain containing the node with minimum cost 734 in the candidate list. 736 11.2. New PCEP Object 738 11.2.1. NODE-FLAGS Object 740 The NODE-FLAGS Object-Type and Object-Class has been defined in this 741 document. IANA is requested to make the following allocation: 743 NODE-FLAGS Object-Type : TBA 745 NODE-FLAGS Object-Class: TBA 747 Flag field of the NODE-FLAG Object: 749 Bit Description Reference 750 0 The node is a destination node This I-D 751 1 The node is a source node This I-D 752 2 The node is on the result path tree This I-D 754 Each bit should be tracked with the following qualities: 756 o Bit number (counting from bit 0 as the most significant bit) 758 o Name flag 760 o Reference 762 11.3. New PCEP TLV 764 IANA is requested to make the following allocation: 766 Value Meaning Reference 767 TBA DOMAIN-ID TLV This I-D 768 TBA PCE-ID TLV This I-D 769 TBA PREVIOUS-NODE TLV This I-D 771 11.3.1. DOMAIN-ID TLV 773 IANA is requested to make the following allocation: 775 Flag field of the DOMAIN-ID TLV 777 Bit Name Description Reference 778 15 V-bit Candidate Node has been expanded by This I-D 779 the domain 780 14 C-bit Candidate Node added by the domain This I-D 782 Each bit should be tracked with the following qualities: 784 o Bit number (counting from bit 0 as the most significant bit) 786 o Name flag 788 o Reference 790 12. Acknowledgement 792 The authors would like to thank Julien Meuric, Daniel King, Ramon 793 Casellas, Cyril Margaria,Olivier Dugeon, Oscar Gonzalez de Dios, 794 Udayasree Palle, Reeja Paul and Sandeep Kumar Boina for their 795 valuable comments on this draft. 797 13. References 799 13.1. Normative References 801 [RFC2119] Bradner, S., "Key words for use in RFCs to 802 Indicate Requirement Levels", BCP 14, RFC 2119, 803 DOI 10.17487/RFC2119, March 1997, 804 . 806 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 807 Computation Element (PCE)-Based Architecture", 808 RFC 4655, DOI 10.17487/RFC4655, August 2006, 809 . 811 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path 812 Computation Element (PCE) Communication Protocol 813 (PCEP)", RFC 5440, DOI 10.17487/RFC5440, 814 March 2009, 815 . 817 13.2. Informative References 819 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. 820 Boyle, Ed., "Requirements for Inter-Area MPLS 821 Traffic Engineering", RFC 4105, DOI 10.17487/ 822 RFC4105, June 2005, 823 . 825 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter- 826 Autonomous System (AS) Traffic Engineering (TE) 827 Requirements", RFC 4216, DOI 10.17487/RFC4216, 828 November 2005, 829 . 831 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. 832 Le Roux, "A Backward-Recursive PCE-Based 833 Computation (BRPC) Procedure to Compute Shortest 834 Constrained Inter-Domain Traffic Engineering 835 Label Switched Paths", RFC 5441, DOI 10.17487/ 836 RFC5441, April 2009, 837 . 839 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., 840 Takeda, T., Ali, Z., and J. Meuric, "Extensions 841 to the Path Computation Element Communication 842 Protocol (PCEP) for Point-to-Multipoint Traffic 843 Engineering Label Switched Paths", RFC 6006, 844 DOI 10.17487/RFC6006, September 2010, 845 . 847 [PCE-HIERARCHY-EXT] Zhang, F., Zhao, Q., King, O., Casellas, R., and 848 D. King, "Extensions to Path Computation Element 849 Communication Protocol (PCEP) for Hierarchical 850 Path Computation Elements (PCE) 851 (draft-zhang-pce-hierarchy-extensions-02)", 852 August 2012. 854 Authors' Addresses 856 Huaimo Chen 857 Huawei Technologies 858 Boston, MA, 859 USA 861 EMail: Huaimo.chen@huawei.com 863 Dhruv Dhody 864 Huawei Technologies 865 Leela Palace 866 Bangalore, Karnataka 560008 867 INDIA 869 EMail: dhruv.dhody@huawei.com