idnits 2.17.1 draft-ietf-ccamp-rsvp-te-domain-subobjects-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 (July 1, 2014) is 3580 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Dhody 3 Internet-Draft U. Palle 4 Intended status: Experimental V. Kondreddy 5 Expires: January 2, 2015 Huawei Technologies 6 R. Casellas 7 CTTC 8 July 1, 2014 10 Domain Subobjects for Resource ReserVation Protocol - Traffic 11 Engineering (RSVP-TE) 12 draft-ietf-ccamp-rsvp-te-domain-subobjects-02 14 Abstract 16 The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) 17 specification and the Generalized Multiprotocol Label Switching 18 (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to 19 be explicitly included in a path setup. Further Exclude Routes 20 extensions to RSVP-TE allow abstract nodes and resources to be 21 explicitly excluded in a path setup. 23 This document specifies new subobjects to include or exclude domains 24 during path setup where domain is a collection of network elements 25 within a common sphere of address management or path computational 26 responsibility (such as an Interior Gateway Protocol (IGP) area or an 27 Autonomous System (AS)). Note that the use of AS as an abstract node 28 representing domain is already defined in existing RSVP-TE 29 specefications, albeit with a 2-Byte AS number. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 2, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Subobjects for Domains . . . . . . . . . . . . . . . . . . . 4 69 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Explicit Route Object (ERO)'s Subobjects . . . . . . . . 5 71 3.2.1. Autonomous system . . . . . . . . . . . . . . . . . . 6 72 3.2.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2.3. Mode of Operation . . . . . . . . . . . . . . . . . . 7 74 3.3. Exclude Route Object (XRO)'s Subobjects . . . . . . . . . 8 75 3.3.1. Autonomous system . . . . . . . . . . . . . . . . . . 8 76 3.3.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 8 77 3.3.3. Mode of Operation . . . . . . . . . . . . . . . . . . 9 78 3.4. Explicit Exclusion Route Subobject . . . . . . . . . . . 9 79 4. Interaction with Path Computation Element (PCE) . . . . . . . 9 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 10 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 8.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 88 A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 13 89 A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 14 90 A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 14 91 A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 The RSVP-TE specification [RFC3209] and the GMPLS extensions to RSVP- 96 TE [RFC3473] allow abstract nodes and resources to be explicitly 97 included in a path setup using the Explicit Route Object (ERO). 99 Further Exclude Routes extensions [RFC4874] allow abstract nodes or 100 resources to be excluded from the whole path using the Exclude Route 101 object (XRO). To exclude certain abstract nodes or resources between 102 a specific pair of abstract nodes present in an ERO, a Explicit 103 Exclusion Route Subobject (EXRS) is used. 105 [RFC3209] already describes the notion of abstract nodes, where an 106 abstract node is a group of nodes whose internal topology is opaque 107 to the ingress node of the Label Switched Path (LSP). It further 108 defines a subobject for AS, but with a 2-Byte AS number only. 110 This document extends the notion of abstract nodes by adding new 111 subobjects for IGP Areas and 4-byte AS numbers (as per [RFC6793]). 112 These subobjects MAY be included in Explicit Route Object (ERO), 113 Exclude Route Object (XRO) or Explicit Exclusion Route Subobject 114 (EXRS). 116 In case of per-domain path computation [RFC5152], where the full path 117 of an inter-domain TE LSP cannot be or is not determined at the 118 ingress node, and signaling message may use domain identifiers. The 119 use of these new subobjects is illustrated in Appendix A. 121 Further, the domain identifier may simply act as delimiter to specify 122 where the domain boundary starts and ends. 124 This is a companion document to Path Computation Element Protocol 125 (PCEP) extensions for the domain sequence [PCE-DOMAIN]. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. Terminology 135 The following terminology is used in this document. 137 AS: Autonomous System. 139 Domain: As per [RFC4655], any collection of network elements within 140 a common sphere of address management or path computational 141 responsibility. Examples of domains include Interior Gateway 142 Protocol (IGP) areas and Autonomous Systems (ASs). 144 ERO: Explicit Route Object 146 EXRS: Explicit Exclusion Route Subobject 148 IGP: Interior Gateway Protocol. Either of the two routing 149 protocols, Open Shortest Path First (OSPF) or Intermediate System 150 to Intermediate System (IS-IS). 152 IS-IS: Intermediate System to Intermediate System. 154 OSPF: Open Shortest Path First. 156 PCE: Path Computation Element. An entity (component, application, 157 or network node) that is capable of computing a network path or 158 route based on a network graph and applying computational 159 constraints. 161 PCEP: Path Computation Element Protocol. 163 RSVP: Resource Reservation Protocol 165 TE LSP: Traffic Engineering Label Switched Path. 167 XRO: Exclude Route Object 169 3. Subobjects for Domains 171 3.1. Domains 173 [RFC4726] and [RFC4655] define domain as a separate administrative or 174 geographic environment within the network. A domain may be further 175 defined as a zone of routing or computational ability. Under these 176 definitions a domain might be categorized as an AS or an IGP area. 178 As per [RFC3209], an abstract node is a group of nodes whose internal 179 topology is opaque to the ingress node of the LSP. Using this 180 concept of abstraction, an explicitly routed LSP can be specified as 181 a sequence of IP prefixes or a sequence of Autonomous Systems. In 182 this document we extend the notion to include IGP area and 4-Byte AS 183 number. 185 The sub-objects MAY appear in RSVP-TE, notably in - 186 o Explicit Route Object (ERO): As per [RFC3209], an explicit route 187 is a particular path in the network topology including abstract 188 nodes (domains). 190 o Exclude Route Object (XRO): As per [RFC4874], an exclude route 191 identifies a list of abstract nodes (domains) that should not be 192 traversed along the path of the LSP being established. 194 o Explicit Exclusion Route Subobject (EXRS): As per [RFC4874], used 195 to specify exclusion of certain abstract nodes between a specific 196 pair of nodes. EXRS are a subobject carried inside the ERO. 197 These subobjects are used to specify the domains that must be 198 excluded between two abstract nodes. 200 3.2. Explicit Route Object (ERO)'s Subobjects 202 As stated in [RFC3209], an explicit route is a particular path in the 203 network topology. In addition to the ability to identify specific 204 nodes along the path, an explicit route can identify a group of nodes 205 (abstract nodes) that must be traversed along the path. 207 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477], 208 [RFC4874] and [RFC5553] but new subobjects related to domains are 209 needed. 211 The following subobject types are used in ERO. 213 Type Subobject 214 1 IPv4 prefix 215 2 IPv6 prefix 216 3 Label 217 4 Unnumbered Interface ID 218 32 Autonomous system number (2 Byte) 219 33 Explicit Exclusion (EXRS) 220 34 SRLG 221 64 IPv4 Path Key 222 65 IPv6 Path Key 224 This document extends the above list to support 4-Byte AS numbers and 225 IGP Areas. 227 Type Subobject 228 TBD Autonomous system number (4 Byte) 229 TBD OSPF Area id 230 TBD ISIS Area id 232 3.2.1. Autonomous system 234 [RFC3209] already defines 2-Byte AS number. 236 To support 4-Byte AS numbers as per [RFC6793], the following 237 subobject is defined: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |L| Type | Length | Reserved | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | AS-ID (4 bytes) | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 L: The L bit is an attribute of the subobject as defined in 248 [RFC3209]. 250 Type: (TBA by IANA) indicating a 4-Byte AS Number. 252 Length: 8 (Total length of the subobject in bytes). 254 Reserved: Zero at transmission, ignored at receipt. 256 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 257 use, the low order bits (16 through 31) should be used and the 258 high order bits (0 through 15) should be set to zero. 260 3.2.2. IGP Area 262 Since the length and format of Area-id is different for OSPF and 263 ISIS, the following two subobjects are defined: 265 For OSPF, the area-id is a 32 bit number. The subobject is encoded 266 as follows: 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 |L| Type | Length | Reserved | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | OSPF Area Id (4 bytes) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 L: The L bit is an attribute of the subobject as defined in 277 [RFC3209]. 279 Type: (TBA by IANA) indicating a 4-Byte OSPF Area ID. 281 Length: 8 (Total length of the subobject in bytes). 283 Reserved: Zero at transmission, ignored at receipt. 285 OSPF Area Id: The 4-Byte OSPF Area ID. 287 For IS-IS, the area-id is of variable length and thus the length of 288 the subobject is variable. The Area-id is as described in IS-IS by 289 ISO standard [ISO10589]. The subobject is encoded as follows: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |L| Type | Length | Area-Len | Reserved | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | | 297 // IS-IS Area ID // 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 L: The L bit is an attribute of the subobject as defined in 302 [RFC3209]. 304 Type: (TBA by IANA) indicating IS-IS Area ID. 306 Length: Variable. As per [RFC3209], the total length of the 307 subobject in bytes, including the L, Type and Length fields. The 308 Length MUST be at least 4, and MUST be a multiple of 4. 310 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 311 Identifier in octets; Valid values are from 2 to 11 inclusive). 313 Reserved: Zero at transmission, ignored at receipt. 315 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 316 with trailing zeroes to a four-byte boundary. 318 3.2.3. Mode of Operation 320 The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area 321 MAY also be used in the ERO to specify an abstract node (a group of 322 nodes whose internal topology is opaque to the ingress node of the 323 LSP). 325 All the rules of processing (for example Next Hop Selection, L bit 326 processing, unrecognized subobjects etc) are as per the [RFC3209]. 328 3.3. Exclude Route Object (XRO)'s Subobjects 330 As stated in [RFC4874], the exclude route identifies a list of 331 abstract nodes that should not be traversed along the path of the LSP 332 being established. 334 Some subobjects are defined in [RFC3209], [RFC3477], [RFC4874] and 335 [RFC6001] but new subobjects related to domains are needed. 337 The following subobject types are used in XRO. 339 Type Subobject 340 1 IPv4 prefix 341 2 IPv6 prefix 342 3 Label 343 4 Unnumbered Interface ID 344 32 Autonomous system number (2 Byte) 345 34 SRLG 347 This document extends the above list to support 4-Byte AS numbers and 348 IGP Areas. 350 Type Subobject 351 TBD Autonomous system number (4 Byte) 352 TBD OSPF Area id 353 TBD ISIS Area id 355 3.3.1. Autonomous system 357 [RFC3209] and [RFC4874] already define a 2-Byte AS number. 359 To support 4-Byte AS numbers as per [RFC6793], a subobject is with 360 the same format as defined in Section 3.2.1 with following 361 difference: 363 The meaning of the L bit (similar to [RFC4874]). 365 0: indicates that the abstract node (AS) specified MUST be excluded. 367 1: indicates that the abstract node (AS) specified SHOULD be avoided. 369 3.3.2. IGP Area 371 Since the length and format of Area-id is different for OSPF and 372 ISIS, the following two subobjects are defined: 374 For OSPF, the area-id is a 32 bit number. Subobjects for OSPF and 375 IS-IS are of the same format as defined in Section 3.2.2 with 376 following difference: 378 The meaning of the L bit (similar to [RFC4874]). 380 0: indicates that the abstract node (OSPF or IS-IS Area) specified 381 MUST be excluded. 383 1: indicates that the abstract node (OSPF or IS-IS Area) specified 384 SHOULD be avoided. 386 3.3.3. Mode of Operation 388 The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area 389 MAY also be used in the XRO to specify exclusion of an abstract node 390 (a group of nodes whose internal topology is opaque to the ingress 391 node of the LSP). 393 All the rules of processing are as per the [RFC4874]. 395 3.4. Explicit Exclusion Route Subobject 397 As per [RFC4874], the Explicit Exclusion Route defines abstract nodes 398 or resources that must not or should not be used on the path between 399 two inclusive abstract nodes or resources in the explicit route. 400 EXRS is an ERO subobject that contains one or more subobjects of its 401 own, called EXRS subobjects. 403 The EXRS subobject may carry any of the subobjects defined for XRO, 404 thus the new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) 405 Area MAY also be used in the EXRS. The meanings of the fields of the 406 new XRO subobjects are unchanged when the subobjects are included in 407 an EXRS, except that scope of the exclusion is limited to the single 408 hop between the previous and subsequent elements in the ERO. 410 All the rules of processing are as per the [RFC4874]. 412 4. Interaction with Path Computation Element (PCE) 414 The domain subobjects to be used in Path Computation Element Protocol 415 (PCEP) are referred to in [PCE-DOMAIN]. Note that the new domain 416 subobjects follow the principle that subobjects used in PCEP 417 [RFC5440] are identical to the subobjects used in RSVP-TE and thus 418 are interchangeable between PCEP and RSVP-TE. 420 5. IANA Considerations 422 5.1. New Subobjects 424 IANA registry: RSVP PARAMETERS 426 Subsection: Class Names, Class Numbers, and Class Types 428 IANA is requested to add further subobjects to the existing entry 429 for: 431 20 EXPLICIT_ROUTE 432 232 EXCLUDE_ROUTE 434 Subobject Type Reference 435 TBA 4-Byte AS number [This I.D.] 436 TBA OSPF Area ID [This I.D.] 437 TBA IS-IS Area ID [This I.D.] 439 6. Security Considerations 441 Security considerations for MPLS-TE and GMPLS signaling are covered 442 in [RFC3209] and [RFC3473]. This document does not introduce any new 443 messages or any substantive new processing, and so those security 444 considerations continue to apply. 446 The route exclusion security consideration are covered in [RFC4874] 447 and continue to apply. 449 7. Acknowledgments 451 We would like to thank Adrian Farrel, Lou Berger, George Swallow, 452 Chirag Shah, Reeja Paul Sandeep Boina and Avantika for their useful 453 comments and suggestions. 455 8. References 457 8.1. Normative References 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, March 1997. 462 8.2. Informative References 464 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 465 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 466 Tunnels", RFC 3209, December 2001. 468 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 469 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 470 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 472 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 473 in Resource ReSerVation Protocol - Traffic Engineering 474 (RSVP-TE)", RFC 3477, January 2003. 476 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 477 Element (PCE)-Based Architecture", RFC 4655, August 2006. 479 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 480 Inter-Domain Multiprotocol Label Switching Traffic 481 Engineering", RFC 4726, November 2006. 483 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 484 Extension to Resource ReserVation Protocol-Traffic 485 Engineering (RSVP-TE)", RFC 4874, April 2007. 487 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 488 Path Computation Method for Establishing Inter-Domain 489 Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 490 5152, February 2008. 492 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 493 (PCE) Communication Protocol (PCEP)", RFC 5440, March 494 2009. 496 [RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource 497 Reservation Protocol (RSVP) Extensions for Path Key 498 Support", RFC 5553, May 2009. 500 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 501 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 502 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 503 MRN)", RFC 6001, October 2010. 505 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 506 Autonomous System (AS) Number Space", RFC 6793, December 507 2012. 509 [PCE-DOMAIN] 510 Dhody, D., Palle, U., and R. Casellas, "Standard 511 Representation Of Domain Sequence. (draft-ietf-pce-pcep- 512 domain-sequence)", July 2014. 514 [ISO10589] 515 ISO, "Intermediate system to Intermediate system routing 516 information exchange protocol for use in conjunction with 517 the Protocol for providing the Connectionless-mode Network 518 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 520 Appendix A. Examples 522 These examples are for illustration purposes only, to show how the 523 new subobjects may be encoded. 525 A.1. Inter-Area LSP Path Setup 527 In an inter-area LSP path setup where the ingress and the egress 528 belong to different IGP areas within the same AS, the domain 529 subobjects MAY be represented using an ordered list of IGP area 530 subobjects in an ERO. 532 D2 Area D 533 | 534 | 535 D1 536 | 537 | 538 ********BD1****** 539 * | * 540 * | * Area C 541 Area A * | * 542 * | * 543 Ingress------A1-----ABF1------B1------BC1------C1------Egress 544 / * | * 545 / * | * 546 / * Area | B * 547 F1 * | * 548 / ********BE1****** 549 / | 550 / | 551 F2 E1 552 | 553 Area F | 554 E2 Area E 556 * All IGP Area in one AS (AS 100) 558 Figure 1: Domain Corresponding to IGP Area 560 As per Figure 1, the signaling at Ingress MAY be - 562 ERO:(A1, ABF1, Area B, Area C, Egress); or 564 ERO:(A1, ABF1, AS 100, Area B, AS 100, Area C, Egress). 566 The AS subobject is optional and it MAY be skipped. An RSVP-TE 567 implementation should be able to understand both notations and there 568 is no change in the processing rules as mentioned in [RFC3209]. 570 A.2. Inter-AS LSP Path Setup 572 A.2.1. Example 1 574 In an inter-AS LSP path setup where the ingress and the egress belong 575 to different AS, the domain subobjects MAY be represented using an 576 ordered list of AS subobjects in an ERO. 578 AS A AS E AS C 579 <-------------> <----------> <-------------> 581 A4----------E1---E2---E3---------C4 582 / / \ 583 / / \ 584 / / AS B \ 585 / / <----------> \ 586 Ingress------A1---A2------B1---B2---B3------C1---C2------Egress 587 \ / / 588 \ / / 589 \ / / 590 \ / / 591 A3----------D1---D2---D3---------C3 593 <----------> 594 AS D 596 * All AS have one area (area 0) 598 Figure 2: Domain Corresponding to AS 600 As per Figure 2, the signaling at Ingress MAY be - 602 ERO:(A1, A2, AS B, AS C, Egress); or 604 ERO:(A1, A2, AS B, Area 0, AS C, Area 0, Egress). 606 Each AS has a single IGP area (area 0), Area subobject is optional 607 and it MAY be skipped as AS is enough to uniquely identify a domain. 608 An RSVP-TE implementation should be able to understand both notations 609 and there is no change in the processing rules as mentioned in 610 [RFC3209]. 612 Note that to get a domain disjoint path, the ingress may also signal 613 the backup path with - 615 XRO:(AS B) 617 A.2.2. Example 2 619 As shown in Figure 3, where AS 200 is made up of multiple areas, the 620 signaling MAY include both AS and Area subobject to uniquely identify 621 a domain. 623 Ingress * 624 | * 625 | * 626 X1 * 627 | \ * 628 | * \ 629 |* \ 630 * | \ Inter-AS 631 AS 100 * | \ Link 632 * | \ 633 * | \ 634 * | \ 635 | D2 Area D 636 AS 200 | | 637 | | 638 Inter | D1 639 -AS | | 640 Link | | 641 A3 ********BD1****** 642 | * | * 643 | * | * Area C 644 | Area A * | * 645 | * | * 646 A2------A1------AB1------B1------BC1------C1------Egress 647 * | * 648 * | * 649 * | * 650 * Area | B * 651 ********BE1****** 652 | 653 | 654 E1 655 | 656 | 657 E2 Area E 659 Figure 3: Domain Corresponding to AS and Area 661 As per Figure 3, the signaling at Ingress MAY be - 663 ERO:(X1, AS 200, Area D, Area B, Area C, Egress). 665 The combination of both an AS and an Area uniquely identifies a 666 domain, note that an Area domain identifier always belongs to the 667 previous AS that appears before it or, if no AS subobjects are 668 present, it is assumed to be the current AS. Also note that there 669 are no changes in the processing rules as mentioned in [RFC3209] with 670 respect to subobjects. 672 Authors' Addresses 674 Dhruv Dhody 675 Huawei Technologies 676 Leela Palace 677 Bangalore, Karnataka 560008 678 INDIA 680 EMail: dhruv.ietf@gmail.com 682 Udayasree Palle 683 Huawei Technologies 684 Leela Palace 685 Bangalore, Karnataka 560008 686 INDIA 688 EMail: udayasree.palle@huawei.com 690 Venugopal Reddy Kondreddy 691 Huawei Technologies 692 Leela Palace 693 Bangalore, Karnataka 560008 694 INDIA 696 EMail: venugopalreddyk@huawei.com 698 Ramon Casellas 699 CTTC 700 Av. Carl Friedrich Gauss n7 701 Castelldefels, Barcelona 08860 702 SPAIN 704 EMail: ramon.casellas@cttc.es