idnits 2.17.1 draft-ietf-mpls-p2mp-sig-requirement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1337. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 74 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: It is RECOMMENDED that these grafting and pruning operations do not cause any additional processing in nodes except along the path to the grafting and pruning node and its downstream nodes. Moreover, both grafting and pruning operations MUST not be traffic disruptive for the traffic currently forwarded along the P2MP tree. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7008 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3468' is mentioned on line 416, but not defined == Missing Reference: 'RFC 3477' is mentioned on line 1085, but not defined == Unused Reference: 'RFC2475' is defined on line 1163, but no explicit reference was found in the text == Unused Reference: 'RFC2597' is defined on line 1167, but no explicit reference was found in the text == Unused Reference: 'RFC3246' is defined on line 1182, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 1187, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1190, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1195, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 1204, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-crankback-03 Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Seisho Yasukawa (NTT) 3 Internet Draft Editor 4 Category: Informational 5 Expiration Date: August 2005 February 2005 7 Signaling Requirements for Point to Multipoint 8 Traffic Engineered MPLS LSPs 9 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document presents a set of requirements for the establishment 37 and maintenance of Point-to-Multipoint (P2MP) Traffic Engineered (TE) 38 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). 40 There is no intent to specify solution specific details nor 41 application specific requirements in this document. 43 It is intended that the requirements presented in this document are 44 not limited to the requirements of packet switched networks, but also 45 encompass the requirements of L2SC, TDM, lambda and port switching 46 networks managed by Generalized MPLS (GMPLS) protocols. Protocol 47 solutions developed to meet the requirements set out in this document 48 must attempt to be equally applicable to MPLS and GMPLS. 50 Table of Contents 52 1. Introduction .................................................. 03 53 1.1 Non-Objectives ............................................ 05 54 2. Definitions ................................................... 06 55 2.1 Acronyms .................................................. 06 56 2.2 Terminology ............................................... 06 57 2.2.1 Terminology for Partial LSPs ......................... 07 58 2.3 Conventions ............................................... 08 59 3. Problem Statement ............................................. 08 60 3.1 Motivation ................................................ 08 61 3.2. Requirements Overview .................................... 09 62 4. Detailed requirements for P2MP TE extensions .................. 11 63 4.1 P2MP LSP tunnels .......................................... 11 64 4.2 P2MP explicit routing ..................................... 11 65 4.3 Explicit Path Loose Hops and Widely Scoped Abstract Nodes . 12 66 4.4 P2MP TE LSP establishment, teardown, and modification 67 mechanisms ................................................ 13 68 4.5 Fragmentation ............................................. 14 69 4.6 Failure Reporting and Error Recovery ...................... 14 70 4.7 Record route of P2MP TE LSP tunnels ....................... 15 71 4.8 Call Admission Control (CAC) and QoS Control mechanism 72 of P2MP TE LSPs ........................................... 16 73 4.9 Variation of LSP Parameters ............................... 16 74 4.10 Re-optimization of P2MP TE LSPs .......................... 16 75 4.11 Tree Remerge ............................................. 17 76 4.12 Data Duplication ......................................... 18 77 4.13 IPv4/IPv6 support ........................................ 19 78 4.14 P2MP MPLS Label .......................................... 19 79 4.15 Routing advertisement of P2MP capability ................. 19 80 4.16 Multi-Area/AS LSP ........................................ 19 81 4.17 Multi-access LANs ........................................ 20 82 4.18 P2MP MPLS OAM ............................................ 20 83 4.19 Scalability .............................................. 20 84 4.19.1 Absolute Limits ..................................... 21 85 4.20 Backwards Compatibility .................................. 22 86 4.21 GMPLS .................................................... 23 87 4.22 Requirements for Hierarchical P2MP TE LSPs ............... 24 88 4.23 P2MP Crankback routing ................................... 24 89 5. Security Considerations ....................................... 24 90 6. Acknowledgements .............................................. 25 91 7. References .................................................... 25 92 7.1 Normative References ...................................... 25 93 7.2 Informational References .................................. 26 94 8. Editor's Address .............................................. 27 95 9. Authors' Addresses ............................................ 27 96 10. Intellectual Property Consideration .......................... 28 97 11. Full Copyright Statement ..................................... 29 99 1. Introduction 101 Existing MPLS Traffic Engineering (MPLS-TE) allows for strict QoS 102 guarantees, resources optimization, and fast failure recovery, but is 103 limited to point-to-point (P2P) applications. Requirements have been 104 expressed for the provision of services over point-to-multipoint 105 (P2MP) traffic engineered tunnels and this clearly motivates 106 enhancements of the base MPLS-TE tool box in order to support P2MP 107 MPLS-TE LSPs. 109 [RFC2702] specifies requirements for traffic engineering over MPLS. 110 It describes traffic engineering in some detail, and those 111 definitions and objectives are equally applicable to traffic 112 engineering in a point-to-multipoint service environment. They are 113 not repeated here, but it is assumed that the reader is fully 114 familiar with them. 116 [RFC2702] also explains how MPLS is particularly suited to traffic 117 engineering, and presents the following eight reason. 119 1. Explicit label switched paths which are not constrained by 120 the destination based forwarding paradigm can be easily created 121 through manual administrative action or through automated 122 action by the underlying protocols. 123 2. LSPs can potentially be efficiently maintained. 124 3. Traffic trunks can be instantiated and mapped onto LSPs. 125 4. A set of attributes can be associated with traffic trunks 126 which modulate their behavioral characteristics. 127 5. A set of attributes can be associated with resources which 128 constrain the placement of LSPs and traffic trunks across 129 them. 130 6. MPLS allows for both traffic aggregation and disaggregation 131 whereas classical destination only based IP forwarding 132 permits only aggregation. 133 7. It is relatively easy to integrate a "constraint-based routing" 134 framework with MPLS. 135 8. A good implementation of MPLS can offer significantly lower 136 overhead than competing alternatives for Traffic Engineering. 138 These points are equally applicable to point-to-multipoint 139 traffic engineering. Points 1. and 7. are particularly important. 141 That is, the traffic flow for a point-to-multipoint LSP is not 142 constrained to the path or paths that it would follow during 143 multicast routing or shortest path destination-based routing, but 144 can be explicitly controlled through manual or automated action. 146 Further, the explicit paths that are used may be computed using 147 algorithms based on a variety of constraints to produce all manner of 148 tree shapes. For example, an explicit path may be cost-based 149 [STEINER], shortest path, QoS-based, or may use some fair-cost QoS 150 algorithm. 152 [RFC2702] also describes the functional capabilities required to 153 fully support Traffic Engineering over MPLS in large networks. 155 1. A set of attributes associated with traffic trunks which 156 collectively specify their behavioral characteristics. 158 2. A set of attributes associated with resources which constrain 159 the placement of traffic trunks through them. These can also be 160 viewed as topology attribute constraints. 162 3. A "constraint-based routing" framework which is used to select 163 paths for traffic trunks subject to constraints imposed by 164 items 1) and 2) above. The constraint-based routing framework 165 does not have to be part of MPLS. However, the two need to be 166 tightly integrated together. 168 These basic requirements should also be supported by P2MP traffic 169 engineering. 171 This document presents a set of requirements for 172 Point-to-Multipoint(P2MP) Traffic Engineering (TE) extensions to 173 Multiprotocol Label Switching (MPLS). It specifies functional 174 requirements for solutions to deliver P2MP TE LSPs. 176 It is intended that solutions that specify procedures for P2MP TE LSP 177 setup satisfy these requirements. There is no intent to specify 178 solution specific details nor application specific requirements in 179 this document. 181 It is intended that the requirements presented in this document are 182 not limited to the requirements of packet switched networks, but 183 also encompass the requirements of TDM, lambda and port switching 184 networks managed by Generalized MPLS (GMPLS) protocols. Protocol 185 solutions developed to meet the requirements set out in this 186 document must attempt to be equally applicable to MPLS and GMPLS. 188 Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE 189 LSPs so new mechanisms must be developed. This should be achieved 190 with maximum re-use of existing MPLS protocols. 192 Note that there is a separation between routing and signaling in 193 MPLS TE. In particular, the path of the MPLS TE LSP is determined by 194 performing a constraint-based computation (such as CSPF) on a traffic 195 engineering database (TED). The contents of the TED may be collected 196 through a variety of mechanism - extensions to the IGPs are a 197 popular mechanism for P2P MPLS TE. 199 This document focuses on requirements for establishing and 200 maintaining P2MP MPLS TE LSPs through signaling protocols; and 201 routing protocols are out of scope. No assumptions are made about how 202 the TED used as the basis for path computations for P2MP LSPs is 203 formed. 205 A P2MP TE LSP will be set up with TE constraints and will allow 206 efficient packet or data replication at various branching points in 207 the network. Note that the notion of "efficient" packet replication 208 is relative and may have different meanings depending on the 209 objectives (see section 4.2). 211 P2MP TE LSP setup mechanisms MUST include the ability to add/remove 212 receivers to/from an existing P2MP TE LSP. 214 1.1 Non-Objectives 216 For clarity, this section lists some items that are out of scope of 217 this document. 219 It is assumed that some information elements describing the P2MP TE 220 LSP are known to the ingress LSR prior to LSP establishment. 221 For example, the ingress LSRs knows the IP addresses that identify 222 the egress LSRs of the P2MP TE LSP. The mechanisms by which the 223 ingress LSR obtains this information is outside the scope of P2MP TE 224 signaling and so is not included in this document. Other documents 225 may complete the description of this function by providing 226 automated, protocol-based ways of passing this information to the 227 ingress LSR. 229 The following are non-objectives of this document. 231 - Non-TE LSPs (such as per-hop, routing-based LSPs). 232 - Discovery of egress leaves for a P2MP LSP 234 - Hierarchical P2MP LSPs 235 - OAM for P2MP LSPs 236 - Inter-area and inter-AS P2MP TE LSPs 238 - Applicability of P2MP MPLS TE LSPs to service scenarios 239 - Specific application or application requirements 241 - Algorithms for computing P2MP distribution trees 242 - Multipoint-to-point LSPs 243 - Multipoint-to-multipoint LSPs 244 - Routing protocols 245 - Construction of the traffic engineering database 246 - Distirbution of the information used to construct the traffic 247 engineering database 249 2. Definitions 251 2.1 Acronyms 253 P2P: 255 Point-to-point 257 P2MP: 259 Point-to-multipoint 261 2.2 Terminology 263 The reader is assumed to be familiar with the terminology in 264 [RFC3031] and [RFC3209]. 266 P2MP TE LSP: 268 A traffic engineered label switched path that has one unique 269 ingress LSR (also referred to as the root) and one or more 270 egress LSRs (also referred to as the leaf). 272 P2MP tree: 274 The ordered set of LSRs and links that comprise the path of a 275 P2MP TE LSP from its ingress LSR to all of its egress LSRs. 277 ingress LSR: 279 The LSR that is responsible for initiating the signaling 280 messages that set up the P2MP TE LSP. 282 egress LSR: 284 One of potentially many destinations of the P2MP TE LSP. 285 Egress LSRs may also be referred to as leaf nodes or leaves. 287 bud LSR: 289 An LSR that is an egress, but also has one or more directly 290 connected downstream LSRs. 292 branch LSR: 294 An LSR that has more than one directly connected downstream LSR. 296 graft LSR: 298 An LSR that is already a member of the P2MP tree and is in 299 process of signaling a new sub-P2MP tree. 301 prune LSR: 303 An LSR that is a member of the P2MP tree and is in 304 process of tearing down an existing sub-P2MP tree. 306 P2MP-ID (Pid): 308 A unique identifier of a P2MP TE LSP, that is constant for the 309 whole LSP regardless of the number of branches and/or leaves. 311 2.2.1 Terminology for Partial LSPs 313 It is convenient to sub-divide P2MP trees for functional and 314 representational reasons. A tree may be divided in two dimensions: 316 - A division may be made along the length of the tree. For example, 317 the tree may be split into two components each running from the 318 ingress LSR to a discrete set of egress LSRs 319 - A tree may be divided at a branch LSR (or any transit LSR) to 320 produce a component of the tree that runs from the branch (or 321 transit) LSR to all downstream egress LSRs. 323 These two methods of splitting the P2MP tree can be combined, so it 324 is useful to introduce some terminology to allow the partitioned 325 trees to be clearly described. 327 Use the following designations: 328 Source (ingress) LSR - S 329 Leaf (egress) LSR - L 330 Branch LSR - B 331 Transit LSR - X 333 Define three terms: 335 Sub-LSP 336 A component of the P2MP LSP that runs from one LSR to another 337 without (or ignoring) any branches. 339 Sub-tree 340 A component of the P2MP LSP that runs from one LSR to more than 341 one other LSR by branching. 343 Tree 344 A component of the P2MP LSP that runs from one LSR to all 345 downstream LSRs. 347 Using these new concepts we can define any combination or split of 348 the P2MP tree. For example: 350 S2L sub-LSP 351 The path from the source to one specific leaf. 353 S2L sub-tree 354 The path from the source to a set of leaves. 356 B2L tree 357 The path from a branch LSR to all downstream leaves. 359 X2X sub-LSP 360 A component of the P2MP LSP that is a simple path with 361 no branches. 363 2.3 Conventions 365 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 366 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 367 this document are to be interpreted as described in [RFC2119]. 369 3. Problem Statement 371 3.1 Motivation 373 As described in section 1, Traffic Engineering and Constraint Based 374 Routing, including Call Admission Control(CAC), explicit source 375 routing and bandwidth reservation, are required to enable efficient 376 resource usage and strict QoS guarantees. Such mechanisms also make 377 it possible to provide services across a congested network where 378 conventional "shortest path first" forwarding paradigms would fail. 380 Existing MPLS TE mechanisms [RFC3209] and GMPLS TE mechanisms 382 [RFC3473] only provide support for P2P TE LSPs. While it is possible 383 to provide P2MP TE services using P2P TE LSPs, any such approach is 384 potentially suboptimal since it may result in data replication at 385 the ingress LSR, or in duplicate data traffic within the network. 387 Hence, to provide P2MP MPLS TE services in a fully efficient manner 388 it is necessary to specify specific requirements. These requirements 389 can then be used to define mechanisms for the use of existing 390 protocols and/or extensions to existing protocols and/or new 391 protocols. 393 3.2. Requirements Overview 395 This document states basic requirements for the setup of P2MP TE 396 LSPs. The requirements apply to the signaling techniques only, and no 397 assumptions are made about which routing protocols are run within the 398 network, nor about how the information that is used to construct the 399 Traffic Engineering Database (TED) is distributed. These factors are 400 out of the scope of this document. 402 A P2MP TE LSP path will be computed taking into account various 403 constraints such as bandwidth, affinities, required level of 404 protection and so on. The solution MUST allow for the computation 405 of P2MP TE LSP paths satisfying constraints with the objective of 406 supporting various optimization criteria such as delays, bandwidth 407 consumption in the network, or any other combinations. This is likely 408 to require the presence of a TED, as well as the ability to signal 409 the explicit path of an LSP. 411 A desired requirement is also to maximize the re-use of existing 412 MPLS TE techniques and protocols where doing so does not adversely 413 impact the function, simplicity or scalability of the solution. 415 This document does not restrict the choice of signaling protocol 416 used to set up a P2MP TE LSP, but it should be noted that [RFC3468] 417 states 418 ... the consensus reached by the Multiprotocol Label Switching 419 (MPLS) Working Group within the IETF to focus its efforts on 420 "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for 421 Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signaling 422 protocol for traffic engineering applications... 424 The P2MP TE LSP setup mechanism MUST include the ability to 425 add/remove egress LSRs to/from an existing P2MP TE LSP and MUST 426 allow for the support of all the TE LSP management procedures 427 already defined for P2P TE LSP such as the non disruptive rerouting 428 (the so called "Make before break" procedure). 430 The computation of P2MP TE trees is implementation dependent and is 431 beyond the scope of the solutions that are built with this document 432 as a guideline. 434 Consider the following figure. 436 Source 1 (S1) 437 | 438 I-LSR1 439 | | 440 | | 441 R2----E-LSR3--LSR1 LSR2---E-LSR2--Receiver 1 (R1) 442 | : 443 R3----E-LSR4 E-LSR5 444 | : 445 | : 446 R4 R5 448 Figure 1 450 Figure 1 shows a single ingress (I-LSR1), and four egresses(E-LSR2, 451 E-LSR3, E-LSR4 and E-LSR5). I-LSR1 is attached to a traffic source 452 that is generating traffic for a P2MP application. 453 Receivers R1, R2, R3 and R4 are attached to E-LSR2, E-LSR3 and 454 E-LSR4. 456 The following are the objectives of P2MP LSP establishment and use. 458 a) A P2MP TE LSP tree which satisfies various constraints is 459 pre-determined and supplied to ingress I-LSR1. 461 Note that no assumption is made on whether the tree is 462 provided to I-LSR1 or computed by I-LSR1. Note that the 463 solution SHOULD also allow for the support of partial path by 464 means of loose routing. 466 Typical constraints are bandwidth requirements, resource class 467 affinities, fast rerouting, preemption, to mention a few of 468 them. There should not be any restriction on the possibility 469 to support the set of constraints already defined for point to 470 point TE LSPs. A new constraint may specify which LSRs should 471 be used as branch points for the P2MP LSR in order to take 472 into account some LSR capabilities or network constraints. 474 b) A P2MP TE LSP is set up from I-LSR1 to E-LSR2, E-LSR3 and 475 E-LSR4 using the tree information. 477 c) In this case, the branch LSR1 should replicate incoming 478 packets or data and send them to E-LSR3 and E-LSR4. 480 d) If a new receiver (R5) expresses an interest in receiving 481 traffic, a new tree is determined and a sub-P2MP tree from 482 LSR2 to E-LSR5 is grafted onto the P2MP tree. LSR2 becomes a 483 branch LSR. 485 4. Detailed requirements for P2MP TE extensions 487 4.1 P2MP LSP tunnels 489 The P2MP TE extensions MUST be applicable to the signaling of LSPs 490 of different traffic types. For example, it MUST be possible to 491 signal a P2MP TE LSP to carry any kind of payload being packet or 492 non-packet based (including frame, cell, TDM un/structured, etc.) 494 As with P2P MPLS technology [RFC3031], traffic is classified with a 495 FEC in this extension. All packets which belong to a particular FEC 496 and which travel from a particular node MUST follow the same P2MP 497 tree. 499 In order to scale to a large number of branches, P2MP TE LSPs SHOULD 500 be identified by a unique identifier (the P2MP ID or Pid) that is 501 constant for the whole LSP regardless of the number of branches 502 and/or leaves. Therefore, the identification of the P2MP session by 503 its destination addresses is not adequate. 505 4.2 P2MP explicit routing 507 Various optimizations in P2MP tree formation need to be applied to 508 meet various QoS requirements and operational constraints. 510 Some P2MP applications may request a bandwidth guaranteed P2MP tree 511 which satisfies end-to-end delay requirements. And some operators 512 may want to set up a cost minimum P2MP tree by specifying branch 513 LSRs explicitly. 515 The P2MP TE solution therefore MUST provide a means of establishing 516 arbitrary P2MP trees under the control of an external tree 517 computation process or path configuration process or dynamic tree 518 computation process located on the ingress LSR. Figure 4 shows two 519 typical examples. 521 A A 522 | / \ 523 B B C 524 | / \ / \ 525 C D E F G 526 | / \ / \/ \ / \ 527 D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O 529 Steiner P2MP tree SPF P2MP tree 531 Figure 4 Examples of P2MP TE LSP topology 533 One example is the Steiner P2MP tree (Cost minimum P2MP tree) 534 [STEINER]. This P2MP tree is suitable for constructing a cost 535 minimum P2MP tree so as to minimize the bandwidth consumption in 536 the core. To realize this P2MP tree, several intermediate LSRs must 537 be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G, 538 H, I, J and K in the figure 4). This means that the LSRs must perform 539 both label swapping and popping at the same time. Therefore, the P2MP 540 TE solution MUST support a mechanism that can setup this kind of bud 541 LSR between an ingress LSR and egress LSRs. Note that this includes 542 constrained Steiner trees that allow for the computation of a minimal 543 cost trees with some other constraints such as a bounded delay 544 between the source and every receiver. 546 Another example is a CSPF (Constraint Shortest Path First) P2MP 547 tree. By some metric (which can be set upon any specific criteria 548 like the delay, bandwidth, a combination of those), one can 549 calculate a shortest path P2MP tree. This P2MP tree is suitable for 550 carrying real time traffic. 552 The solution MUST allow the operator to make use of any tree 553 computation technique. In the former case an efficient/optimal tree 554 is defined as a minimal cost tree (Steiner tree) whereas in the 555 later case it is defined as the tree that provides shortest path 556 between the source and any receiver. 558 To support explicit setup of any reasonable P2MP tree shape, a P2MP 559 TE solution MUST support some form of explicit source-based control 560 of the P2MP tree which can explicitly include particular LSRs as 561 branch nodes. This can be used by the ingress LSR to setup the P2MP 562 TE LSP. For instance, a P2MP TE LSP can be simply represented as a 563 whole tree or by its individual branches. 565 4.3 Explicit Path Loose Hops and Widely Scoped Abstract Nodes 567 A P2MP tree is completely specified if all of the required branches 568 and hops between a sender and leaf LSR are indicated. 570 A P2MP tree is partially specified if only a subset of intermediate 571 branches and hops are indicated. This may be achieved using loose 572 hops in the explicit path, or using widely scoped abstract nodes 573 such as IPv4 prefixes shorter than 32 bits, or AS numbers. 574 A partially specified P2MP tree might be particularly useful in 575 inter-area and inter-AS situations although P2MP requirements for 576 inter-area and inter-AS are beyond the scope of this document. 578 Protocol solutions SHOULD include a way to specify loose hops and 579 widely scoped abstract nodes in the explicit source-based control 580 of the P2MP tree as defined in the previous section. Where this 581 support is provided, protocol solutions MUST allow downstream LSRs 582 to apply further explicit control to the P2MP tree to resolve a 583 partially specified tree into a (more) completely specified tree. 585 Protocol solutions MUST allow the P2MP tree to be completely 586 specified at the ingress where sufficient information exists to 587 allow the full tree to be computed. 589 In all cases, the egress nodes of the P2MP TE LSP must be fully 590 specified. 592 In case of a tree being computed by some downstream LSRs (e.g. the 593 case of hops specified as loose hops), the solution MUST provide 594 the ability for the ingress LSR of the P2MP TE LSP to learn the full 595 P2MP tree. Note that this requirement MAY be relaxed in some 596 environments (e.g. Inter-AS) where confidentiality must be preserved. 598 4.4 P2MP TE LSP establishment, teardown, and modification mechanisms 600 The P2MP TE solution MUST support establishment, maintenance and 601 teardown of P2MP TE LSPs in a scalable manner. This MUST include 602 both the existence of very many LSPs at once, and the existence of 603 very many destinations for a single P2MP LSP. 605 In addition to P2MP TE LSP establishment and teardown mechanism, it 606 SHOULD implement partial P2MP tree modification mechanism. 608 For the purpose of adding sub-P2MP TE LSPs to an existing P2MP TE 609 LSP, the extensions SHOULD support a grafting mechanism. For the 610 purpose of deleting a sub-P2MP TE LSPs from an existing P2MP TE LSP, 611 the extensions SHOULD support a pruning mechanism. 613 It is RECOMMENDED that these grafting and pruning operations do not 614 cause any additional processing in nodes except along the path to 615 the grafting and pruning node and its downstream nodes. Moreover, 616 both grafting and pruning operations MUST not be traffic disruptive 617 for the traffic currently forwarded along the P2MP tree. 619 4.5 Fragmentation 621 The P2MP TE solution MUST handle the situation where a single 622 protocol message cannot contain all of the information necessary to 623 signal the establishment of the P2MP LSP. It MUST be possible to 624 establish the LSP in these circumstances. 626 This situation may arise in either of the following circumstances. 627 a. The ingress LSR cannot signal the whole tree in a single 628 message. 630 b. The information in a message expands to be too large (or is 631 discovered to be too large) at some transit node. This may 632 occur because of some increase in the information that needs 633 to be signaled or because of a reduction in the size of 634 signaling message that is supported. 636 The solution to these problems SHOULD NOT rely on IP fragmentation, 637 it is RECOMMENDED to rely on some protocol procedures specific to 638 the signaling solution. 640 It is NOT RECOMMENDED that fragmented protocol messages are 641 re-combined at any downstream LSR. 643 4.6 Failure Reporting and Error Recovery 645 Failure events may cause egress nodes or sub-P2MP LSPs to become 646 detached from the P2MP TE LSP. These events MUST be reported 647 upstream as for a P2P LSP. 649 The solution SHOULD provide recovery techniques such as protection 650 and restoration allowing recovery of any impacted sub-P2MP TE 651 LSPs. In particular, a solution MUST provide fast protection 652 mechanisms applicable to P2MP TE LSP similar to the solutions 653 specified in [FRR] for P2P TE LSPs. Note also that no assumption is 654 made on whether backup paths for P2MP TE LSPs should or should not 655 be shared with P2P TE LSPs backup paths. 657 Note that the functions specified in [FRR] are currently specific to 658 packet environments and do not apply to non-packet environments. 659 Thus, while solutions MUST provide fast protection mechanisms 660 similar to those specified in [FRR], this requirement is limited to 661 the subset of the solution space that applies to packet switched 662 networks only. 664 Note that application-specific requirement documents may introduce 665 even more stringent requirement, such as no packet loss, as a 666 trade-off for the relaxation of other requirements, such as increased 667 bandwidth consumption. 669 The solution SHOULD also support the ability to meet other network 670 recovery requirements such as bandwidth protection and bounded 671 propagation delay increase along the backup path during failure. 673 A P2MP TE solution MUST support P2MP fast protection mechanism to 674 handle P2MP applications sensitive to traffic disruption. 676 The report of the failure of delivery to fewer than all of the 677 egress nodes SHOULD NOT cause automatic teardown of the P2MP TE LSP. 678 That is, while some egress nodes remain connected to the P2MP tree 679 it should be a matter of local policy at the ingress whether the 680 P2MP LSP is retained. 682 When all egress nodes downstream of a branch node have become 683 disconnected from the P2MP tree, and the some branch node is unable 684 to restore connectivity to any of them by means of some recovery or 685 protection mechanisms, the branch node MAY remove itself from the 686 P2MP tree provided that it is not also an egress LSR. Since the 687 faults that severed the various downstream egress nodes from the 688 P2MP tree may be disparate, the branch node MUST report all such 689 errors to its upstream neighbor. The ingress node can then decide 690 to re-compute the path to those particular egress nodes, around the 691 failure point. 693 Solutions MAY include the facility for transit LSRs and particularly 694 branch nodes to recompute sub-P2MP trees to restore them after 695 failures. In the event of successful repair, error notifications 696 SHOULD NOT be reported to upstream nodes, but the new paths are 697 reported if route recording is in use. Crankback requirements are 698 discussed in Section 4.23. 700 4.7 Record route of P2MP TE LSP tunnels 702 Being able to identify the established topology of P2MP TE LSP is 703 very important for various purposes such as management and operation 704 of some local recovery mechanisms like Fast Reroute [FRR]. A network 705 operator uses this information to manage P2MP TE LSPs. Therefore, 706 topology information MUST be collected and updated after P2MP TE LSP 707 establishment and modification process. 709 The P2MP TE solution MUST support a mechanism which can collect and 710 update P2MP tree topology information after P2MP LSP establishment 711 and modification process. For example, the P2P MPLS TE mechanism of 712 route recording could be extended and used if RSVP-TE was used as 713 the P2MP signaling protocol. 715 It is RECOMMENDED that the information is collected in a data format 716 by which the sender node can recognize the P2MP tree topology 717 without involving some complicated data calculation process. 719 The solution MUST support the recording of both outgoing interfaces 720 and node-id. 722 4.8 Call Admission Control (CAC) and QoS Control mechanism 723 of P2MP TE LSPs 725 P2MP TE LSPs may share network resource with P2P TE LSPs. Therefore 726 it is important to use CAC and QoS in the same way as P2P TE LSPs 727 for easy and scalable operation. 729 P2MP TE solutions MUST support both resource sharing and exclusive 730 resource utilization to facilitate co-existence with other LSPs to 731 the same destination(s). 733 P2MP TE solution MUST be applicable to DiffServ-enabled networks 734 that can provide consistent QoS control in P2MP LSP traffic. 736 Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] 737 and interoperate smoothly with current P2P DS-TE protocol 738 specifications. 740 Note that this requirement document does not make any assumption on 741 the type of bandwidth pool used for P2MP TE LSPs which can either be 742 shared with P2P TE LSP or be dedicated for P2MP use. 744 4.9 Variation of LSP Parameters 746 Certain parameters (such as priority and bandwidth) are associated 747 with an LSP. The parameters are installed by the signaling exchanges 748 associated with establishing and maintaining the LSP 750 Any solution MUST NOT allow for variance of these parameters within 751 a single P2MP LSP. That is: 752 - No attributes set and signaled by the ingress of a P2MP LSP may be 753 varied by downstream LSRs. 754 - There MUST be homogeneous QoS from the root to all leaves of a 755 single P2MP LSP. 757 Variation of parameters may be allowed so long as it applies to the 758 whole LSP from ingress to all egresses. 760 4.10 Re-optimization of P2MP TE LSPs 762 The detection of a more optimal path (for example, one with a lower 763 overall cost) is an example of a situation where P2MP TE LSP 764 re-routing may be required. While re-routing is in progress, an 765 important requirement is avoiding double bandwidth reservation 766 (over the common parts between the old and new LSP) thorough the use 767 of resource sharing. 769 Make-before-break MUST be supported for a P2MP TE LSP to ensure that 770 there is minimal traffic disruption when the P2MP TE LSP is 771 re-routed. 773 It is possible to achieve make-before-break that only applies to a 774 sub-P2MP tree without impacting the data on all of the other parts 775 of the P2MP tree. 777 The solution SHOULD allow for make-before-break re-optimization of 778 any subdivision of the P2MP LSP (S2L sub-tree, S2X sub-LSP, S2L 779 sub-LSP, X2L sub-tree, B2L sub-tree, X2L tree, or B2L tree) with no 780 impact on the rest of the P2MP LSP (no label reallocation, no change 781 in identifiers, etc.). 783 The solution SHOULD also provide the ability for the ingress LSR to 784 have a strict control on the re-optimization process. The ingress 785 LSR SHOULD be able to limit all re-optimization to be 786 source-initiated. 788 Where sub-tree re-optimization is allowed by the ingress LSR, such 789 re-optimization MAY be initiated by a downstream LSR that is the 790 root of the sub-tree that is to be re-optimized. Sub-tree 791 re-optimization initiated by a downstream LSR MUST be carried out 792 with the same regard to minimizing the hit on active traffic as 793 was described above for other re-optimization. 795 4.11 Tree Remerge 797 It is possible for a single transit LSR to receive multiple 798 signaling messages for the same P2MP LSP but for different 799 sets of destinations. These messages may be received from the 800 same or different upstream nodes and may need to be passed on 801 to the same or different downstream nodes. 803 This situation may arise as the result of the signaling solution 804 definition or implementation options within the signaling 805 solution. Further, it may happen during make-before-break 806 reoptimization (section 4.10), or as a result of signaling 807 message fragmentation (section 4.5). 809 It is even possible that it is necessary to construct distinct 810 upstream branches in order to achieve the correct label choices 811 in certain switching technologies managed by GMPLS (for example, 812 photonic cross-connects where the selection of a particular 813 lambda for the downstream branches is only available on different 814 upstream switches). 816 The solution MUST support the case where of multiple signaling 817 messages for the same P2MP LSP are received at a single transit 818 LSR and refer to the same upstream interface. In this case the 819 result of the protocol procedures SHOULD be a single data flow 820 on the upstream interface. 822 The solution SHOULD support the case where multiple signaling 823 messages for the same P2MP LSP are received at a single transit 824 LSR and refer to different upstream interfaces, and where each 825 signaling message results in the use of different downstream 826 interfaces. This case represents data flows that cross at the LSR 827 but which do not merge. 829 The solution MAY support the case where multiple signaling 830 messages for the same P2MP LSP are received at a single transit 831 LSR and refer to different upstream interfaces, and where the 832 downstream interfaces are shared across the received signaling 833 messages. This case represents the merging of data flows. A 834 solution that supports this case MUST ensure that data is not 835 replicated on the downstream interfaces. 837 An alternative to supporting this last case is for the signaling 838 protocol to indicate an error such that the merge may be 839 resolved by the upstream LSRs. 841 4.12 Data Duplication 843 Data duplication refers to the receipt by any recipient of duplicate 844 instances of the data. In a packet environment this means the 845 receipt of duplicate packets - although this should be a benign (if 846 inefficient) situation, it may be catastrophic in certain existing 847 and deployed applications. In a non-packet environment this means 848 the duplication in time of some part of the signal that may lead to 849 the replication of data or to the scrambling of data. 851 Data duplication may legitimately arise in various scenarios 852 including re-optimization of active LSPs as described in the 853 previous section, and protection of LSPs. Thus, it is impractical to 854 regulate against data duplication in this document. 856 Instead, the solution MUST provide a mechanism to resolve, limit or 857 avoid data duplication at either or both of: 858 - the point at which the data path diverges 859 - the point at which the data paths converge. 861 THE EXTENT TO WHICH DATA DUPLICATION MAY BE TOLERATED (in time or in 862 a count of bits or packets) IS FOR FURTHER STUDY. 864 4.13 IPv4/IPv6 support 866 Any P2MP TE solution MUST be equally applicable to IPv4 and IPv6. 868 4.14 P2MP MPLS Label 870 A P2MP TE solution MUST support establishment of both P2P and P2MP 871 TE LSPs and MUST NOT impede the operation of P2P TE LSPs within the 872 same network. A P2MP TE solution MUST be specified in such a way 873 that it allows P2MP and P2P TE LSPs to be signaled on the same 874 interface. Labels for P2MP TE LSPs and P2P TE LSPs MAY be assigned 875 from shared or dedicated label space(s). Label space shareability is 876 implementation specific. 878 4.15 Routing advertisement of P2MP capability 880 Several high-level requirements have been identified to determine 881 the capabilities of LSRs within a P2MP network. The aim of such 882 information is to facilitate the computation of P2MP trees using TE 883 constraints within a network that contains LSRs that do not all have 884 the same capabilities levels with respect to P2MP signaling and data 885 forwarding. 887 These capabilities include, but are not limited to: 889 - the ability of an LSR to support branching. 890 - the ability of an LSR to act as an egress and a branch for the 891 same LSP. 892 - the ability of an LSR to support P2MP MPLS-TE signaling. 894 It is expected that it may be appropriate to gather this information 895 through extensions to TE IGPs (see [RFC3630] and [IS-IS-TE]), but 896 the precise requirements and mechanisms are out of the scope of this 897 document. It is expected that a separate document will cover this 898 requirement. 900 4.16 Multi-Area/AS LSP 902 P2MP TE solutions SHOULD support multi-area/AS P2MP TE LSPs. 904 The precise requirements in support of multi-area/AS P2MP TE LSPs is 905 out of the scope of this document. It is expected that a separate 906 document will cover this requirement. 908 4.17 Multi-access LANs 910 P2MP MPLS TE may be used to traverse network segments that are 911 provided by multi-access media such as Ethernet. In these cases, it 912 is also possible that the entry point to the network segment is a 913 branch point of the P2MP LSP. 915 Two options clearly exist: 917 - the branch point replicates the data and transmits multiple 918 copies onto the segment 919 - the branch point sends a single copy of the data to the segment 920 and relies on the exit points to discriminate the reception of 921 the data. 923 The first option has a significant scaling issue since all 924 replicated data must be sent through the same port and carried on 925 the same segment. Thus, a solution SHOULD provide a mechanism for a 926 branch node to send a single copy of the data onto a multi-access 927 network and reach multiple (adjacent) downstream nodes. 929 4.18 P2MP MPLS OAM 931 Management of P2MP LSPs is as important as the management of P2P 932 LSPs. 934 The MPLS and GMPLS MIB modules will be enhanced to provide P2MP TE 935 LSP management in line with whatever signaling solutions are 936 developed. 938 In order to facilitate correct management, P2MP TE LSPs MUST have 939 unique identifiers since otherwise it is impossible to determine 940 which LSP is being managed. 942 OAM facilities will have special demands in P2MP environments 943 especially within the context of tracing the paths and connectivity 944 of P2MP TE LSPs. Further and precise requirements and mechanisms for 945 OAM are out of the scope of this document. It is expected that 946 separate documents will cover these requirements and mechanisms. 948 4.19 Scalability 950 Scalability is a key requirement in P2MP MPLS systems. Solutions 951 MUST be designed to scale well with an increase in the number of any 952 of the following: 954 - the number of recipients 955 - the number of branch points 956 - the number of branches. 958 Both scalability of performance and operation MUST be considered. 960 Key considerations SHOULD include: 961 - the amount of refresh processing associated with maintaining 962 a P2MP TE LSP. 963 - the amount of protocol state that must be maintained by ingress 964 and transit LSRs along a P2MP tree. 965 - the number of protocol messages required to set up or tear down a 966 P2MP LSP as a function of the number of egress LSRs. 967 - the number of protocol messages required to repair a P2MP LSP 968 after failure or perform make-before-break. 969 - the amount of protocol information transmitted to manage 970 a P2MP TE LSP (i.e. the message size). 971 - the amount of potential routing extensions. 972 - the amount of control plane processing required by the ingress, 973 transit and egress LSRs to add/delete a branch LSP to/from an 974 existing P2MP LSP. 976 It is expected that the applicability of each solution will be 977 evaluated with regards to the aforementioned scalability criteria. 979 4.19.1 Absolute Limits 981 THIS IS SECTION DESCRIBES PROVISIONAL REQUIREMENTS STILL OPEN FOR 982 DISCUSSION. 984 In order to achieve the best solution for the problem space it is 985 helpful to clarify the boundaries for P2MP TE LSPs. 987 - Number of recipients. 988 A P2MP TE LSP MUST reduce to similar scaling properties as a P2P 989 LSP when the number of recipients reduces to one. 990 It is important to classify the problem as a Traffic Engineering 991 problem. It is anticipated that the initial deployments of P2MP TE 992 LSPs may be limited to only several hundred recipients, but also 993 that future deployments may require significantly larger numbers. 994 An acceptable solution, therefore, is one that scales linearly 995 with the number of recipients. 997 Solutions that scale worse than linear (that is, exponential or 998 polynomial) are not acceptable whatever the number of recipients 999 they could support 1001 - Number of branch points. 1002 Solutions MUST support all possibilities from one extreme of a 1003 single branch point that forks to all leaves on a separate branch, 1004 to the greatest number of branch points which is (n-1) for n 1005 recipients. Assumptions MUST NOT be made in the solution regarding 1006 which topology is more common, and the solution MUST be designed 1007 to ensure scalability in all topologies. 1009 - Dynamics of P2MP tree. 1010 Recall that the mechanisms for determining which recipients should 1011 be added to an LSP, and for adding and removing recipients from 1012 that group are out of the scope of this document. Nevertheless, it 1013 is useful to understand the expected rates of arrival and 1014 departure of recipients since this can impact the selection of 1015 solution techniques. 1016 Again, it must be recalled that this document is limited to Traffic 1017 Engineering, and in this model the rate of change of recipients 1018 may be expected to be lower than in an IP multicast group. 1019 Although the absolute number of recipients coming and going is the 1020 important element for determining the scalability of a solution, 1021 it may be noted that a percentage may be a more comprehensible 1022 measure but that this is not as significant for LSPs with a small 1023 number of recipients. 1024 A working figure for an established P2MP TE LSP is less than 10% 1025 churn per day. That is, a relatively slow rate of churn. 1026 We could say that a P2MP LSP would be shared by multiple multicast 1027 groups and dynamics of P2MP LSP would be relatively small. 1028 Considering applicability that P2MP LSP to use L2 multi-access 1029 path technology, we can consider stable P2MP L2 path even when we 1030 transfer IP multicast traffic over the path. 1032 Solutions MUST optimize around such relatively low rates of change 1033 and are NOT REQUIRED to optimize for significantly higher rates 1034 of change. 1036 - Rate of change within the network. 1037 It is also important to understand the scaling with regard to 1038 changes within the network. That is, one of the features of a 1039 P2MP TE LSP is that it can be robust or protected against network 1040 failures, and can be re-optimized to take advantage of newly 1041 available network resources. 1043 It is more important that a solution be optimized for scaling with 1044 respect to recovery and re-optimization of the LSP, than for change 1045 in the recipients, because P2MP is used as a TE tool. 1046 The solution MUST follow this distinction. 1048 4.20 Backwards Compatibility 1050 It SHOULD be an aim of any P2MP solution to offer as much backward 1051 compatibility as possible. An ideal which is probably impossible to 1052 achieve would be to offer P2MP services across legacy MPLS networks 1053 without any change to any LSR in the network. 1055 If this ideal cannot be achieved, the aim SHOULD be to use legacy 1056 nodes as both transit non-branch LSRs and egress LSRs. 1058 It is a further requirement for the solution that any LSR that 1059 implements the solution SHALL NOT be prohibited by that act from 1060 supporting P2P TE LSPs using existing signaling mechanisms. That is, 1061 unless administratively prohibited, P2P TE LSPs MUST be supported 1062 through a P2MP network. 1064 Also, it is a requirement that P2MP TE LSPs MUST be able to co-exist 1065 with IP unicast and IP multicast networks. 1067 4.21 GMPLS 1069 The requirement for P2MP services for non-packet switch interfaces 1070 is similar to that for PSC interfaces. Therefore, it is a requirement 1071 that reasonable attempts must be made to make all the features/ 1072 mechanisms (and protocol extensions) that will be defined to provide 1073 MPLS P2MP TE LSPs equally applicable to P2MP PSC and non-PSC TE-LSPs. 1074 If the requirements of non-PSC networks over-complicate the PSC 1075 solution a decision may be taken to separate the solutions. This 1076 decision must be taken in full consultation with the MPLS and CCAMP 1077 working groups. 1079 Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or 1080 non-PSC TE-LSPs MUST be backward and forward compatible with the 1081 other features of GMPLS including: 1083 - control and data plane separation (IF_ID RSVP_HOP and IF_ID 1084 ERROR_SPEC), 1085 - full support of numbered and unnumbered TE links (see [RFC 3477] 1086 and [GMPLS-ROUTE]), 1087 - use of the GENERALIZED_LABEL_REQUEST, the GENERALIZED_LABEL 1088 (C-Type 2 and 3), the SUGGESTED_LABEL and the RECOVERY_LABEL, 1089 in conjunction with the LABEL_SET and the ACCEPTABLE_LABEL_SET 1090 object, 1091 - processing of the ADMIN_STATUS object, 1092 - processing of the PROTECTION object, 1093 - support of Explicit Label Control, 1094 - processing of the Path_State_Removed Flag, 1095 - handling of Graceful Deletion procedures. 1096 - E2E and Segment Recovery procedures. 1097 - support of Graceful Restart 1099 In addition, since non-PSC TE-LSPs may have to be processed in 1100 environments where the "P2MP capability" could be limited, specific 1101 constraints may also apply during the P2MP TE Path computation. 1102 Being technology specific, these constraints are outside the scope 1103 of this document. However, technology independent constraints 1104 (i.e. constraints that are applicable independently of the LSP 1105 class) SHOULD be allowed during P2MP TE LSP message processing. 1106 It has to be emphasized that path computation and management 1107 techniques shall be as close as possible to those being used for 1108 PSC P2P TE LSPs and P2MP TE LSPs. 1110 4.22 Requirements for Hierarchical P2MP TE LSPs 1112 [LSP-HIER] defines concepts and procedures for P2P LSP hierarchy. 1114 The P2MP MPLS-TE solution SHOULD support the concept of region and 1115 region hierarchy (PSC1