idnits 2.17.1 draft-dhody-pce-pcep-domain-sequence-02.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 (February 9, 2012) is 4454 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 10589' -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) == Outdated reference: A later version (-08) exists of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-02 == Outdated reference: A later version (-05) exists of draft-ietf-pce-hierarchy-fwk-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft U. Palle 4 Intended status: Standards Track Huawei Technologies India Pvt 5 Expires: August 12, 2012 Ltd 6 R. Casellas 7 CTTC - Centre Tecnologic de 8 Telecomunicacions de Catalunya 9 February 9, 2012 11 Standard Representation Of Domain Sequence 12 draft-dhody-pce-pcep-domain-sequence-02 14 Abstract 16 The ability to compute shortest constrained Traffic Engineering Label 17 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 18 Generalized MPLS (GMPLS) networks across multiple domains has been 19 identified as a key requirement for P2P and P2MP scenarios. In this 20 context, a domain is a collection of network elements within a common 21 sphere of address management or path computational responsibility 22 such as an IGP area or an Autonomous Systems. This document 23 specifies a standard representation and encoding of a domain 24 sequence, which is defined as an ordered sequence of domains 25 traversed to reach the destination domain. This document also 26 defines new sub-objects to be used to encode domain identifiers. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 12, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Detail Description . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Standard Representation . . . . . . . . . . . . . . . . . 6 69 3.4. Mode of Operation . . . . . . . . . . . . . . . . . . . . 8 70 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.5.1. Inter-Area Path Computation . . . . . . . . . . . . . 9 72 3.5.2. Inter-AS Path Computation . . . . . . . . . . . . . . 11 73 3.5.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . 11 74 3.5.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . 13 75 3.5.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . 15 76 3.5.4. PCE serving multiple domains . . . . . . . . . . . . . 16 77 3.5.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 3.5.6. HPCE . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 3.5.7. Relationship to PCE Sequence . . . . . . . . . . . . . 18 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 81 4.1. New IRO Object Type . . . . . . . . . . . . . . . . . . . 19 82 4.2. Sub-Objects . . . . . . . . . . . . . . . . . . . . . . . 19 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 6. Manageability Considerations . . . . . . . . . . . . . . . . . 19 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 A PCE may be used to compute end-to-end paths across multi-domain 93 environments using a per-domain path computation technique [RFC5152]. 94 The so called backward recursive path computation (BRPC) mechanism 95 [RFC5441] defines a PCE-based path computation procedure to compute 96 inter-domain constrained (G)MPLS TE LSPs. However, both per-domain 97 and BRPC techniques assume that the sequence of domains to be crossed 98 from source to destination is known, either fixed by the network 99 operator or obtained by other means. For inter-domain point-to- 100 multi-point (P2MP) tree, [PCE-P2MP-PROCEDURES] assumes the domain- 101 tree is known. 103 The list of domains in a point-to-point (P2P) path or a point-to- 104 multi-point (P2MP) tree is usually a constraint in the path 105 computation request. The PCE decouples the domain to determine the 106 next PCE to forward the request. 108 According to BRPC mechanism the PCC MAY indicate the sequence of 109 domains to be traversed using the Include Route Object (IRO) defined 110 in [RFC5440]. 112 This document proposes a standard way to represent and encode a 113 domain sequence using IRO in various deployment scenarios including 114 P2P, P2MP and Hierarchical PCE (HPCE) [PCE-HIERARCHY-FWK]. 116 The domain sequence (the set of domains traversed to reach the 117 destination domain) is either administratively predetermined or 118 discovered by some means (H-PCE) that is outside of the scope of this 119 document. Here the focus is only on a standard representation of the 120 domain sequence in all possible scenarios. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Terminology 130 The following terminology is used in this document. 132 ABR: OSPF Area Border Router. Routers used to connect two IGP 133 areas. 135 AS: Autonomous System. 137 ASBR: Autonomous System Boundary Router. 139 BN: Boundary Node, Can be an ABR or ASBR. 141 BRPC: Backward Recursive Path Computation 143 Domain: Any collection of network elements within a common sphere of 144 address management or path computational responsibility. Examples 145 of domains include Interior Gateway Protocol (IGP) areas and 146 Autonomous Systems (ASs). 148 Domain-Seq: An ordered sequence of domains traversed to reach the 149 destination domain. 151 ERO: Explicit Route Object 153 H-PCE: Hierarchical PCE 155 IGP: Interior Gateway Protocol. Either of the two routing 156 protocols, Open Shortest Path First (OSPF) or Intermediate System 157 to Intermediate System (IS-IS). 159 IRO: Include Route Object 161 IS-IS: Intermediate System to Intermediate System. 163 OSPF: Open Shortest Path First. 165 PCC: Path Computation Client: any client application requesting a 166 path computation to be performed by a Path Computation Element. 168 PCE: Path Computation Element. An entity (component, application, 169 or network node) that is capable of computing a network path or 170 route based on a network graph and applying computational 171 constraints. 173 P2MP: Point-to-Multipoint 175 P2P: Point-to-Point 177 TE LSP: Traffic Engineering Label Switched Path. 179 3. Detail Description 181 3.1. Domains 183 A domain can be defined as a separate administrative or geographic 184 environment within the network. A domain may be further defined as a 185 zone of routing or computational ability. Under these definitions a 186 domain might be categorized as an Antonymous System (AS) or an 187 Interior Gateway Protocol (IGP) area ( as per [RFC4726] and 188 [RFC4655]). To uniquely identify a domain in the domain sequence 189 both AS and Area-id is important. 191 3.2. Domain-Sequence 193 A domain-sequence is an ordered sequence of domains traversed to 194 reach the destination domain. In this context a Domain could be an 195 Autonomous System (AS) or an IGP Area. Note that an AS can be 196 further made of multiple Area. 198 Domain Sequence can be applied as a constraint and carried in path 199 computation request to PCE(s). In case of HPCE [PCE-HIERARCHY-FWK] 200 Parent PCE MAY send the domain sequence as a result in path 201 computation reply. 203 In this context, ordered sequence is important, in a P2P path, the 204 domains listed appear in the order that they are crossed. In a P2MP 205 path, the domain tree is represented as list of domain sequences. 207 One main goal of the Domain-Sequence is to enable a PCE to select the 208 next PCE to forward the path computation request based on the domain 209 information. 211 A PCC or PCE MAY add an additional constraints covering which 212 Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be 213 traversed while defining a domain sequence. 215 Thus a Domain-Sequence MAY be made up of one or more of - 217 o AS Number 219 o Area ID 221 o Boundary Node ID 223 o Inter-AS-Link Address 225 3.3. Standard Representation 227 The IRO (Include Route Object) [RFC5440] is an optional object used 228 to specify a set of specified network elements that the computed path 229 MUST traverse. [RFC5440] in its description of IRO does not 230 constrain the sub-objects to be in a given particular order. When 231 considering a domain sequence, the domain relative ordering is a 232 basic criterion and, as such, this document specifies a new IRO 233 object type. 235 We define a new type of IRO Object to define Domain Sequence. 237 IRO Object-Class is 10. 238 IRO Object-Type is TBD. (2 suggested value to IANA) 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 244 // (Subobjects) // 245 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Sub-objects: The IRO is made of sub-objects identical to the ones 249 defined in [RFC3209], [RFC3473], and [RFC3477], where the IRO sub- 250 object type is identical to the sub-object type defined in the 251 related documents. Some new sub-objects related to Domain-Sequence 252 are also added in this document. 254 The following sub-object types are used. 255 Type Sub-object 256 1 IPv4 prefix 257 2 IPv6 prefix 258 4 Unnumbered Interface ID 259 32 Autonomous system number (2 Byte) 260 TBD Autonomous system number (4 Byte) 261 TBD OSPF Area id 262 TBD ISIS Area id 264 [RFC3209] defines sub-objects for IPv4, IPv6 and unnumbered Interface 265 ID, which in the context of domain-sequence is used to specify 266 Boundary Node (ABR/ASBR) and Inter-AS-Links. 268 [RFC3209] also defines 2 octet AS number. 270 To support 4 octet AS number [RFC4893] following subobject is 271 defined: 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |L| Type | Length | Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | AS Id (4 bytes) | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Since the length of Area-id is different for OSPF and ISIS, we 282 propose different sub-objects. 284 For OSPF, the area-id is a 32 bit number. The Subobject looks 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 |L| Type | Length | Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Area Id (4 bytes) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 The length if fixed. 294 For ISIS, the area-id is of variable length and thus the length of 295 the Subobject is variable. The Area-id is as described in ISIS by 296 ISO standard [ISO 10589]. The Length MUST be at least 4, and MUST be 297 a multiple of 4. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |L| Type | Length | Reserved | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | | 305 // ISIS Area ID // 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 The above sub-objects in various combinations can be used to encode 310 the domain-sequence. When the domain-sequence is used as a 311 constraint in path computation request it is carried in IRO Domain 312 Sequence Object Type. The same sub-objects and their encoding can be 313 used in ERO and path reply message when the domain sequence is 314 computed from Parent PCE. 316 All other rules of PCEP objects and message processing is as per 318 [RFC5440]. 320 3.4. Mode of Operation 322 A domain sequence IRO object constraints or defines the domains 323 involved in a muti-domain path computation, typically involving two 324 or more collaborative PCEs. 326 Consequently, a Domain-Sequence can be used: 328 1. by a PCE in order to discover or select the next PCE in a 329 collaborative path computation, such as in BRPC [RFC5441]; 331 2. by the Parent PCE to return the domain sequence when unknown, 332 this can further be an input to BRPC procedure; 334 3. By a PCC (or PCE) to constraint the domains used in a H-PCE path 335 computation, explicitly specifying which domains to be expanded; 337 A domain sequence can have varying degrees on granularity; it is 338 possible to have a domain sequence composed of, uniquely, AS 339 identifiers. It is also possible to list the involved areas for a 340 given AS. 342 In any case, the mapping between domains and responsible PCEs is not 343 defined in this document. It is assumed that a PCE that needs to 344 obtain a "next PCE" from a domain sequence is able to do so (e.g. via 345 administrative configuration, or discovery). 347 The following algorithm can be applied to select the next domain and, 348 if need be, the PCE responsible for that domain. Note the PCC select 349 the PCE(1) based on its own domain information. 351 START 352 Get the first Sub-Object S1 from the Domain-Sequence 353 IF S1's Type is Area (OSPF or ISIS) 354 IF S1's Domain is same as current PCE's Area 355 Remove S1 from Domain-Sequence and Goto START 356 ELSE 357 Find the next PCE based on S1's Area within the AS 358 ENDIF 359 ELSEIF S1's Type is AS (2 or 4 Byte) 360 IF S1's Domain is same as current PCE's AS 361 Remove S1 from Domain-Sequence and Goto START 362 ELSE 363 Get the next Sub-Object S2 from the Domain-Sequence 364 IF the S2 is NULL or S2's type is AS 365 Find the next PCE based on S1's Domain (AS) only 366 ELSEIF S1's Type is Area 367 Find the next PCE based on S1's Domain (AS) 368 and S2's Domain (Area) 369 ELSE 370 ENDIF 371 ENDIF 372 ENDIF 373 IF Domain-Sequence is empty or next PCE is not found 374 Send PCRep with NO-Path 375 ENDIF 377 If the Sub-Object is of other type representing Boundary Node or 378 Inter-As-Link, it is not used to select the next PCE, but used only 379 while applying BRPC or any other inter-domain procedure. 381 3.5. Examples 383 3.5.1. Inter-Area Path Computation 385 In an inter-area path computation where ingress and egress belong to 386 different IGP area, the domain sequence MAYBE represented using a 387 ordered list of AREA sub-objects. AS number MAYBE skipped, as area 388 information is enough to select the next PCE. 390 +-------------------+ +-------------------+ 391 | | | | 392 | +--+ | | +--+ | 393 | +--+ | | | | | | | 394 | | | +--+ | | +--+ +--+ | 395 | +--* + + | | | 396 | | | +--+ | 397 | *--+ + + | 398 | | | | | +--+ | 399 | +--+ | | | | | 400 | |+--------------------------+| +--+ | 401 | ++++ +-++ | 402 | |||| +--+ | || | 403 | Area 2 ++++ | | +-++ Area 4 | 404 +-------------------+| +--+ |+-------------------+ 405 | | 406 | +--+ | 407 | +--+ | | | 408 | | | +--+ | 409 | +--+ | 410 | | 411 | | 412 | | 413 | | 414 | +--+ | 415 | | | | 416 | +--+ | 417 +------------------+| |+--------------------+ 418 | ++-+ +-++ | 419 | || | | || | 420 | ++-+ Area 0 +-++ | 421 | |+--------------------------+| +--+ | 422 | +--+ | | | | | 423 | | | | | +--+ | 424 | +--+ +--+ | | | 425 | | | + + +--+ | 426 | +--+ | | | | | 427 | + + +--+ | 428 | +--+ | | | 429 | | | | | +--+ | 430 | +--+ | | | | | 431 | | | +--+ | 432 | | | | 433 | Area 1 | | Area 5 | 434 +------------------+ +--------------------+ 436 AS Number is 100. 438 Figure 1: Inter-Area Path Computation 440 This could be represented as as: 442 +---------+ +---------+ +---------+ +---------+ 443 |IRO | |Sub | |Sub | |Sub | 444 |Object | |Object | |Object | |Object | 445 |Header | |Area 2 | |Area 0 | |Area 4 | 446 | | | | | | | | 447 | | | | | | | | 448 +---------+ +---------+ +---------+ +---------+ 450 +---------+ +---------+ +---------+ +---------+ +---------+ 451 |IRO | |Sub | |Sub | |Sub | |Sub | 452 |Object | |Object As| |Object | |Object | |Object | 453 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 454 | | | | | | | | | | 455 | | | | | | | | | | 456 +---------+ +---------+ +---------+ +---------+ +---------+ 458 AS is optional and it MAY be skipped. PCE should be able to 459 understand both notations. 461 3.5.2. Inter-AS Path Computation 463 In inter-AS path computation, where ingress and egress belong to 464 different AS, the domain sequence is represented using an ordered 465 list of AS sub-objects. The domain sequence MAY further include 466 decomposed area information in AREA sub-objects. 468 3.5.2.1. Example 1 470 As shown in Figure 2, where AS to be made of a single area, the area 471 subobject MAY be skipped in the domain sequence as AS is enough to 472 uniquely identify the next domain and PCE. 474 +---------------------------------+ 475 |AS 200 | 476 | +------+ | 477 | | | | 478 +------------------------+ | | | +------+ | 479 | AS 100 | | +------+ | | | 480 | +------+ | | +------+ | | | 481 | | +-+-----+-+ | +------+ | 482 | | | | | | | | 483 | +------+ | | +------+ | 484 | +------+ | | +------+ | 485 | | | | | | | | 486 | | | | | | | | 487 | +------+ | | +------+ | 488 | | | | 489 | +------+ | | +------+ | 490 | | +-+-----+-+ | +------+ | 491 | | | | | | | | | | 492 | +------+ | | +------+ | | | 493 | | | +------+ | 494 | | | | 495 | | | | 496 | +------+ | | +------+ | 497 | | | | | | | | 498 | |PCE | | | |PCE | | 499 | +------+ | | +------+ | 500 | | | | 501 +------------------------+ | | 502 +---------------------------------+ 504 Both AS are made of Area 0. 506 Figure 2: Inter-AS Path Computation 508 This could be represented as as: 510 +---------+ +---------+ +---------+ 511 |IRO | |Sub | |Sub | 512 |Object | |Object As| |Object As| 513 |Header | |100 | |200 | 514 | | | | | | 515 | | | | | | 516 +---------+ +---------+ +---------+ 518 +---------+ +---------+ +---------+ +---------+ +---------+ 519 |IRO | |Sub | |Sub | |Sub | |Sub | 520 |Object | |Object As| |Object | |Object As| |Object | 521 |Header | |100 | |Area 0 | |200 | |Area 0 | 522 | | | | | | | | | | 523 | | | | | | | | | | 524 +---------+ +---------+ +---------+ +---------+ +---------+ 525 Area is optional and it MAY be skipped. PCE should be able to 526 understand both notations. 528 3.5.2.2. Example 2 530 As shown in Figure 3, where AS 200 is made up of multiple areas and 531 multiple domain-sequence exist, PCE MAY include both AS and AREA 532 subobject to uniquely identify the next domain and PCE. 534 | 535 | +-------------+ +----------------+ 536 | |Area 2 | |Area 4 | 537 | | +--+| | +--+ | 538 | | | || | | | | 539 | | +--+ +--+| | +--+ +--+ | 540 | | | | | | | | | 541 | | *--+ | | +--+ | 542 | | / +--+ | | +--+ | 543 | |/ | | | | | | | 544 | / +--+ | | +--+ +--+ | 545 | /| +--+ |+--------------+| | | | 546 |/ | | | ++-+ +-++ +--+ | 547 +-------------+/ | +--+ || | | || | 548 | /| | ++-+ +-++ | 549 | +--*|| +-------------+| |+----------------+ 550 | | ||| | +--+ | 551 | +--+|| | | | | 552 | +--+ || | +--+ | 553 | | | || | | 554 | +--+ || | | 555 | || | +--+ | 556 |+--+ || | | | | 557 || | || | +--+ | 558 |+--+ || | | 559 | || | +--+ | 560 | +--+ || +------------+ | | | |+----------------+ 561 | | | || |Area 3 +-++ +--+ +-++ Area 5 | 562 | +--+ || | | || | || | 563 | || | +-++ +-++ | 564 | +--+|| | +--+ | | Area 0 || +--+ | 565 | | ||| | | | | +--------------+| | | | 566 | +--*|| | +--+ | | +--+ | 567 | \| | | | +--+ | 568 |Area 1 |\ | +--+ | | +--+ | | | 569 +-------------+|\ | | | | | | | +--+ | 570 | \| +--+ +--+ | +--+ | 571 | \ | | | | 572 | |\ +--+ | +--+ | 573 | | \ +--+ | | | | | 574 | | \| | | | +--+ | 575 | | *--+ | | | 576 | | | | | 577 | +------------+ +----------------+ 578 | 579 | 580 As 100 | AS 200 581 | 582 Figure 3: Inter-AS Path Computation 584 The domain sequence can be carried in IRO as shown below: 586 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 587 |IRO | |Sub | |Sub | |Sub | |Sub | |Sub | |Sub | 588 |Object | |Object | |Object | |Object | |Object | |Object | |Object | 589 |Header | |As 100 | |Area 1 | |AS 200 | |Area 3 | |Area 0 | |Area 4 | 590 | | | | | | | | | | | | | | 591 +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ 592 Combination of both AS and Area uniquely identify a domain in the domain 593 sequence. 595 Note that an Area domain identifier always belongs to the previous AS 596 that appear before it or, if no AS sub-objects are present, it is 597 assumed to be the current AS. 599 If the area information cannot be provided, PCE MAY forward the path 600 computation request to the next PCE based on AS only. If multiple 601 PCEs of different area domain exist, PCE MAY apply local policy to 602 select the next PCE. Furthermore the domain sequence (list of areas 603 within AS) in the next PCE MAYBE pre-administered or MAYBE discovered 604 via some mechanism (ex. HPCE). 606 3.5.3. Boundary Node and Inter-AS-Link 608 A PCC or PCE MAY add additional constraints covering which Boundary 609 Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed 610 while defining a domain sequence. In which case the Boundary Node or 611 Link MAY be encoded as a part of the domain-sequence using the 612 existing sub-objects. 614 Boundary Node (ABR / ASBR) can be encoded using the IPv4 or IPv6 615 prefix sub-objects. The Inter-AS link can be encoded using the IPv4 616 or IPv6 prefix or unnumbered interface sub-objects. 618 For Figure 1, an ABR to be traversed can be specified as: 620 +---------+ +---------+ +---------++---------+ +---------+ 621 |IRO | |Sub | |Sub ||Sub | |Sub | 622 |Object | |Object | |Object ||Object | |Object | 623 |Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 | 624 | | | | |x.x.x.x || | | | 625 | | | | | || | | | 626 +---------+ +---------+ +---------++---------+ +---------+ 628 For Figure 2, an inter-AS-link to be traversed can be specified as: 630 +---------+ +---------+ +---------+ +---------+ +---------+ 631 |IRO | |Sub | |Sub | |Sub | |Sub | 632 |Object | |Object As| |Object | |Object | |Object As| 633 |Header | |100 | |IPv4 | |IPv4 | |200 | 634 | | | | |x.x.x.x | |x.x.x.x | | | 635 | | | | | | | | | | 636 +---------+ +---------+ +---------+ +---------+ +---------+ 638 3.5.4. PCE serving multiple domains 640 A single PCE MAYBE responsible for multiple domains; for example PCE 641 function deployed on an ABR. Domain sequence should have no impact 642 on this. PCE which can support 2 adjacent domains can internally 643 handle this situation without any impact on the neighboring domains. 645 3.5.5. P2MP 647 In case of P2MP the path domain tree is nothing but a series of 648 Domain Sequences, as shown in the below figure: 650 D1-D3-D6, D1-D3-D5 and D1-D2-D4. 651 D1 652 / \ 653 D2 D3 654 / / \ 655 D4 D5 D6 657 3.5.6. HPCE 659 As per [PCE-HIERARCHY-FWK], consider a case as shown in Figure 4 660 consisting of multiple child PCEs and a parent PCE. 662 +--------+ 663 | Parent | 664 | PCE | 665 +--------+ 667 +-------------------+ +-------------------+ 668 | +--+ | | +--+ | 669 | +--+ | | | | | | | 670 | | | +--+ | | +--+ +--+ | 671 | +--* + + | | | 672 | | | +--+ | 673 | *--+ + + | 674 | | | | | +--+ | 675 | +--+ | | | | | 676 | |+--------------------------+| +--+ | 677 | ++++ +-++ | 678 | |||| +--+ | || | 679 | Area 2 ++++ | | +-++ Area 4 | 680 +-------------------+| +--+ |+-------------------+ 681 | +--+ | 682 | +--+ | | | 683 | | | +--+ | 684 | +--+ | 685 | | 686 | +--+ | 687 | | | | 688 | +--+ | 689 +------------------+| |+--------------------+ 690 | ++-+ +-++ | 691 | || | | || | 692 | ++-+ Area 0 +-++ | 693 | |+--------------------------+| +--+ | 694 | +--+ | | | | | 695 | | | | | +--+ | 696 | +--+ +--+ | | | 697 | | | + + +--+ | 698 | +--+ | | | | | 699 | + + +--+ | 700 | +--+ | | | 701 | | | | | +--+ | 702 | +--+ | | | | | 703 | | | +--+ | 704 | Area 1 | | Area 5 | 705 +------------------+ +--------------------+ 707 Figure 4: Hierarchical PCE 709 In HPCE implementation the initiator PCE - PCE(1) can request the 710 parent PCE to determine the domain sequence and return in the path 711 computation reply message (PCRep), using the ERO Object. The ERO can 712 contain an ordered sequence of sub-object such as AS and Area (OSPF/ 713 ISIS). In this case, the PCRep would carry the domain sequence 714 result as: 716 +---------+ +---------+ +---------+ +---------+ 717 |ERO | |Sub | |Sub | |Sub | 718 |Object | |Object | |Object | |Object | 719 |Header | |Area 2 | |Area 0 | |Area 4 | 720 | | | | | | | | 721 | | | | | | | | 722 +---------+ +---------+ +---------+ +---------+ 724 +---------+ +---------+ +---------+ +---------+ +---------+ 725 |ERO | |Sub | |Sub | |Sub | |Sub | 726 |Object | |Object As| |Object | |Object | |Object | 727 |Header | |100 | |Area 2 | |Area 0 | |Area 4 | 728 | | | | | | | | | | 729 | | | | | | | | | | 730 +---------+ +---------+ +---------+ +---------+ +---------+ 732 Note that, in the case of ERO objects, no new PCEP object type is 733 required since the ordering constraint is assumed. 735 3.5.7. Relationship to PCE Sequence 737 [RFC5886] and [PCE-P2MP-PROCEDURES] along with Domain Sequence 738 introduces the concept of PCE-Sequence, where a sequence of PCEs, 739 based on the domain sequence, should be decided and attached in the 740 PCReq at the very beginning of path computation. An alternative 741 would be to use domain sequences, which simplifies as explained 742 below: 744 Advantages 746 o All PCE must be aware of all other PCEs in all domain for PCE- 747 Sequence. There is no clear method for this. In domain-sequence 748 PCE should be aware of the domains and not all the PCEs serving 749 the domain. PCE needs to be aware of the neighboring PCEs as done 750 by discovery protocols. 752 o There maybe multiple PCE in a domain, the selection of PCE should 753 not be made at the PCC/PCE(1). This decision is made only at the 754 neighboring PCE which is aware of state of PCEs via notification 755 messages. 757 o Domain sequence would be compatible to P2P inter-domain BRPC 758 method as described in [RFC5441]. 760 4. IANA Considerations 762 4.1. New IRO Object Type 764 IANA has defined a registry for Domain-Sequence. 766 IRO Object-Class 10 768 IRO Object-Type 2 770 4.2. Sub-Objects 772 IANA has defined a registry for following sub-objects. 774 Type Sub-object 775 TBD AS Number (4 Byte) 776 TBD OSPF Area id 777 TBD ISIS Area id 779 5. Security Considerations 781 This document specifies a standard representation of domain sequence, 782 which is used in all inter-domain PCE scenarios as explained in other 783 RFC and drafts. It does not introduce any new security 784 considerations. 786 6. Manageability Considerations 788 TBD 790 7. Acknowledgments 792 We would like to thank Pradeep Shastry, Suresh babu, Quintin Zhao, 793 Fatai Zhang, Daniel King, Oscar Gonzalez and Chen Huaimo for their 794 useful comments and suggestions. 796 8. References 798 8.1. Normative References 800 [RFC2119] Bradner, S., "Key words for use in RFCs to 801 Indicate Requirement Levels", BCP 14, 802 RFC 2119, March 1997. 804 [ISO 10589] ISO, "Intermediate system to Intermediate 805 system routeing information exchange protocol 806 for use in conjunction with the Protocol for 807 providing the Connectionless-mode Network 808 Service (ISO 8473)", ISO/IEC 10589:2002. 810 8.2. Informative References 812 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 813 Srinivasan, V., and G. Swallow, "RSVP-TE: 814 Extensions to RSVP for LSP Tunnels", RFC 3209, 815 December 2001. 817 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 818 Switching (GMPLS) Signaling Resource 819 ReserVation Protocol-Traffic Engineering 820 (RSVP-TE) Extensions", RFC 3473, January 2003. 822 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling 823 Unnumbered Links in Resource ReSerVation 824 Protocol - Traffic Engineering (RSVP-TE)", 825 RFC 3477, January 2003. 827 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 828 Computation Element (PCE)-Based Architecture", 829 RFC 4655, August 2006. 831 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A 832 Framework for Inter-Domain Multiprotocol Label 833 Switching Traffic Engineering", RFC 4726, 834 November 2006. 836 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four- 837 octet AS Number Space", RFC 4893, May 2007. 839 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A 840 Per-Domain Path Computation Method for 841 Establishing Inter-Domain Traffic Engineering 842 (TE) Label Switched Paths (LSPs)", RFC 5152, 843 February 2008. 845 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path 846 Computation Element (PCE) Communication 847 Protocol (PCEP)", RFC 5440, March 2009. 849 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le 850 Roux, "A Backward-Recursive PCE-Based 851 Computation (BRPC) Procedure to Compute 852 Shortest Constrained Inter-Domain Traffic 853 Engineering Label Switched Paths", RFC 5441, 854 April 2009. 856 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A 857 Set of Monitoring Tools for Path Computation 858 Element (PCE)-Based Architecture", RFC 5886, 859 June 2010. 861 [PCE-P2MP-PROCEDURES] Zhao, Q., Dhody, D., Ali, Z., Saad,, T., 862 Sivabalan,, S., and R. Casellas, "PCE-based 863 Computation Procedure To Compute Shortest 864 Constrained P2MP Inter-domain Traffic 865 Engineering Label Switched Paths (draft-ietf- 866 pce-pcep-inter-domain-p2mp-procedures-02)", 867 February 2012. 869 [PCE-HIERARCHY-FWK] King, D. and A. Farrel, "The Application of 870 the Path Computation Element Architecture to 871 the Determination of a Sequence of Domains in 872 MPLS and GMPLS. 873 (draft-ietf-pce-hierarchy-fwk-00)", 874 October 2011. 876 Authors' Addresses 878 Dhruv Dhody 879 Huawei Technologies India Pvt Ltd 880 Leela Palace 881 Bangalore, Karnataka 560008 882 INDIA 884 EMail: dhruv.dhody@huawei.com 886 Udayasree Palle 887 Huawei Technologies India Pvt Ltd 888 Leela Palace 889 Bangalore, Karnataka 560008 890 INDIA 892 EMail: udayasree.palle@huawei.com 893 Ramon Casellas 894 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 895 Av. Carl Friedrich Gauss n7 896 Castelldefels, Barcelona 08860 897 SPAIN 899 EMail: ramon.casellas@cttc.es