idnits 2.17.1 draft-ietf-mpls-p2mp-sig-requirement-04.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1353. ** 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. 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 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 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 (December 2005) is 6704 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3468' is mentioned on line 441, but not defined Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Seisho Yasukawa (NTT) 2 Internet Draft Editor 3 Category: Informational 4 Expiration Date: June 2006 December 2005 6 Signaling Requirements for Point to Multipoint 7 Traffic Engineered MPLS LSPs 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 The requirements presented in this document apply equally to packet 44 switched networks under the control of MPLS protocols and to but also 45 encompass the requirements of Layer two Switching (L2SC), Time 46 Division Multiplexing (TDM), lambda, and port switching networks 47 managed by Generalized MPLS (GMPLS) protocols. Protocol solutions 48 developed to meet the requirements set out in this document must 49 attempt to be equally applicable to MPLS and GMPLS. 51 Table of Contents 53 1. Introduction ................................................... 3 54 1.1 Non-Objectives ................................................ 5 55 2. Definitions .................................................... 6 56 2.1 Acronyms ...................................................... 6 57 2.2 Terminology ................................................... 6 58 2.2.1 Terminology for Partial LSPs ................................ 7 59 2.3 Conventions ................................................... 8 60 3. Problem Statement .............................................. 9 61 3.1 Motivation .................................................... 9 62 3.2. Requirements Overview......................................... 9 63 4. Detailed requirements for P2MP TE extensions .................. 11 64 4.1 P2MP LSP ..................................................... 11 65 4.2 P2MP explicit routing......................................... 11 66 4.3 Explicit Path Loose Hops and Widely Scoped Abstract Nodes .... 12 67 4.4 P2MP TE LSP establishment, teardown, and modification mechanisms 68 ............................................................ 13 69 4.5 Fragmentation ................................................ 14 70 4.6 Failure Reporting and Error Recovery ......................... 14 71 4.7 Record route of P2MP TE LSP .................................. 15 72 4.8 Call Admission Control (CAC) and QoS Control mechanism of 73 P2MP TE LSPs ............................................... 16 74 4.9 Variation of LSP Parameters .................................. 16 75 4.10 Re-optimization of P2MP TE LSPs ............................. 17 76 4.11 Merging of Tree Branches .................................... 17 77 4.12 Data Duplication ............................................ 18 78 4.13 IPv4/IPv6 support ........................................... 19 79 4.14 P2MP MPLS Label ............................................. 19 80 4.15 Advertisement of P2MP capability ............................ 19 81 4.16 Multi-access LANs ........................................... 20 82 4.17 P2MP MPLS OAM ............................................... 20 83 4.18 Scalability ................................................. 20 84 4.18.1 Absolute Limits ........................................... 21 85 4.19 Backwards Compatibility ..................................... 23 86 4.20 GMPLS ....................................................... 23 87 4.21 P2MP Crankback routing ...................................... 24 88 5. Security Considerations ....................................... 24 89 6. IANA Considerations ........................................... 25 90 7. Acknowledgements .............................................. 25 91 8. References .................................................... 25 92 8.1 Normative References ......................................... 25 93 8.2 Informational References ..................................... 25 94 9. Editor's Address .............................................. 26 95 10. Authors' Addresses ........................................... 26 96 11. Intellectual Property Consideration .......................... 28 97 12. Full Copyright Statement ..................................... 28 99 1. Introduction 101 Existing MPLS Traffic Engineering (MPLS-TE) allows for strict QoS 102 guarantees, resources optimization, and fast failure recovery, but 103 is limited to point-to-point (P2P) LSPs. There is a desire to support 104 point-to-multipoint (P2MP) services using traffic engineered LSPs and 105 this clearly motivates enhancements of the base MPLS-TE tool box in 106 order to support P2MP MPLS-TE LSPs. 108 A P2MP TE LSP is a TE LSP in the definitions of [RFC2702] and 109 [RFC3031] that has a single ingress LSR, one or more egress LSRs, and 110 is unidirectional. P2MP services (that deliver data from a single 111 source to one or more receivers) may be supported by any combination 112 of P2P and P2MP LSPs depending on the degree of optimization required 113 within the network, and such LSPs may be Traffic Engineered again 114 depending on the requirements of the network. Further, multipoint-to- 115 multipoint (MP2MP) services (that deliver data from more than one 116 source to one or more receivers) may be supported by a combination 117 of P2P and P2MP LSPs. 119 [RFC2702] specifies requirements for traffic engineering over MPLS. 120 In Section 2, it describes traffic engineering in some detail, and 121 those definitions are equally applicable to traffic engineering in a 122 point-to-multipoint service environment. They are not repeated here, 123 but it is assumed that the reader is fully familiar with them. 125 Section 3.0 of [RFC2702] also explains how MPLS is particularly 126 suited to traffic engineering, and presents the following eight 127 reasons. 129 1. Explicit label switched paths which are not constrained by the 130 destination based forwarding paradigm can be easily created 131 through manual administrative action or through automated 132 action by the underlying protocols. 133 2. LSPs can potentially be efficiently maintained. 134 3. Traffic trunks can be instantiated and mapped onto LSPs. 135 4. A set of attributes can be associated with traffic trunks which 136 modulate their behavioral characteristics. 137 5. A set of attributes can be associated with resources which 138 constrain the placement of LSPs and traffic trunks across them. 139 6. MPLS allows for both traffic aggregation and disaggregation 140 whereas classical destination only based IP forwarding permits 141 only aggregation. 142 7. It is relatively easy to integrate a "constraint-based routing" 143 framework with MPLS. 144 8. A good implementation of MPLS can offer significantly lower 145 overhead than competing alternatives for Traffic Engineering. 147 These points are equally applicable to point-to-multipoint traffic 148 engineering. Points 1. and 7. are particularly important. Note that 149 point 3. implies that the concept of a point-to-multipoint traffic 150 trunk is defined and is supported by (or mapped onto) P2MP LSPs. 152 That is, the traffic flow for a point-to-multipoint LSP is not 153 constrained to the path or paths that it would follow during 154 multicast routing or shortest path destination-based routing, but can 155 be explicitly controlled through manual or automated action. 157 Further, the explicit paths that are used may be computed using 158 algorithms based on a variety of constraints to produce all manner 159 of tree shapes. For example, an explicit path may be cost-based 160 [STEINER], shortest path, QoS-based, or may use some fair-cost QoS 161 algorithm. 163 [RFC2702] also describes the functional capabilities required to 164 fully support Traffic Engineering over MPLS in large networks. 166 This document presents a set of requirements for Point-to-Multipoint 167 (P2MP) Traffic Engineering (TE) extensions to Multiprotocol Label 168 Switching (MPLS). It specifies functional requirements for solutions 169 to deliver P2MP TE LSPs. 171 Solutions that specify procedures for P2MP TE LSP setup MUST satisfy 172 these requirements. There is no intent to specify solution-specific 173 details nor application-specific requirements in this document. 175 The requirements presented in this document apply equally to packet 176 packet switched networks under the control of MPLS protocols and to 177 packet switched, TDM, lambda, and port switching networks managed 178 by Generalized MPLS (GMPLS) protocols. Protocol solutions developed 179 to meet the requirements set out in this document MUST attempt to be 180 equally applicable to MPLS and GMPLS. 182 Existing MPLS TE mechanisms such as [RFC3209] do not support P2MP TE 183 LSPs so new mechanisms need to be developed. This SHOULD be achieved 184 with maximum re-use of existing MPLS protocols. 186 Note that there is a separation between routing and signaling in 187 MPLS TE. In particular, the path of the MPLS TE LSP is determined by 188 performing a constraint-based computation (such as CSPF) on a traffic 189 engineering database (TED). The contents of the TED may be collected 190 through a variety of mechanisms. 192 This document focuses on requirements for establishing and 193 maintaining P2MP MPLS TE LSPs through signaling protocols; and 194 routing protocols are out of scope. No assumptions are made about 195 how the TED used as the basis for path computations for P2MP LSPs is 196 formed. 198 This requirements document assumes the following conditions for P2MP 199 MPLS TE LSP establishment and maintenance: 201 o A P2MP TE LSP will be set up with TE constraints and will allow 202 efficient packet or data replication at various branching points in 203 the network. Although replication is a data plane issue, it is the 204 responsibility of the control plane (acting in conjunction with the 205 path computation component) to install LSPs in the network such 206 that replication can be performed efficiently. Note that the notion 207 of "efficient" replication is relative and may have different 208 meanings depending on the objectives (see section 4.2). 210 o P2MP TE LSP setup mechanisms must include the ability to add/remove 211 receivers to/from the P2MP service supported by an existing P2MP TE 212 LSP. 214 o Tunnel endpoints of P2MP TE LSP will be modified by adding/removing 215 egress LSRs to/from an existing P2MP TE LSP. It is assumed that the 216 rate of change of leaves of a P2MP LSP (that is, the rate at 217 which new egress LSRs join, or old egress LSRs are pruned) is "not 218 so high" because P2MP TE LSPs are assumed to be utilized for TE 219 applications. This issue is discussed at greater length in section 220 4.18.1. 222 o A P2MP TE LSP may be protected by fast error recovery mechanisms 223 to minimize disconnection of a P2MP service. 225 o And a set of attributes of the P2MP TE LSP (e.g. bandwidth, etc.) 226 may be modified by some mechanism (e.g. make-before-break etc.) 227 to accommodate attribute changes to the P2MP service without 228 impacting data traffic. These issues are discussed in section 4.6 229 and 4.10. 231 It is not a requirement that the ingress LSR must control the 232 addition or removal of leaves from the P2MP tree. 234 It is this document's objective that a solution compliant to the 235 requirements set out in this document MUST operate these P2MP 236 TE capabilities in a scalable fashion. 238 1.1 Non-Objectives 240 For clarity, this section lists some items that are out of scope of 241 this document. 243 It is assumed that some information elements describing the P2MP TE 244 LSP are known to the ingress LSR prior to LSP establishment. For 245 example, the ingress LSRs knows the IP addresses that identify the 246 egress LSRs of the P2MP TE LSP. The mechanisms by which the ingress 247 LSR obtains this information is outside the scope of P2MP TE 248 signaling and so is not included in this document. Other documents 249 may complete the description of this function by providing 250 automated, protocol-based ways of passing this information to the 251 ingress LSR. 253 This document does not specify any requirements for the following 254 functions. 256 - Non-TE LSPs (such as per-hop, routing-based LSPs). 257 - Discovery of egress leaves for a P2MP LSP. 259 - Hierarchical P2MP LSPs. 260 - OAM for P2MP LSPs. 261 - Inter-area and inter-AS P2MP TE LSPs. 263 - Applicability of P2MP MPLS TE LSPs to service scenarios. 264 - Specific application or application requirements. 266 - Algorithms for computing P2MP distribution trees. 268 - Multipoint-to-point LSPs. 269 - Multipoint-to-multipoint LSPs. 270 - Routing protocols. 271 - Construction of the traffic engineering database. 272 - Distribution of the information used to construct the traffic 273 engineering database. 275 2. Definitions 277 2.1 Acronyms 279 P2P: 281 Point-to-point 283 P2MP: 285 Point-to-multipoint 287 2.2 Terminology 289 The reader is assumed to be familiar with the terminology in 290 [RFC3031] and [RFC3209]. 292 The following terms are defined for use in the context of P2MP TE 293 LSPs only. 295 P2MP tree: 297 The ordered set of LSRs and TE links that comprise the path of a 298 P2MP TE LSP from its ingress LSR to all of its egress LSRs. 300 ingress LSR: 302 The LSR that is responsible for initiating the signaling messages 303 that set up the P2MP TE LSP. 305 egress LSR: 307 One of potentially many destinations of the P2MP TE LSP. Egress 308 LSRs may also be referred to as leaf nodes or leaves. 310 bud LSR: 312 An LSR that is an egress LSR, but also has one or more directly 313 connected downstream LSRs. 315 branch LSR: 317 An LSR that has more than one directly connected downstream LSR. 319 P2MP-ID (P2ID): 321 A unique identifier of a P2MP TE LSP, that is constant for the 322 whole LSP regardless of the number of branches and/or leaves. 324 source: 326 The sender of traffic that is carried on a P2MP service supported 327 by a P2MP LSP. The sender is not necessarily the ingress LSR of 328 the P2MP LSP. 330 receiver: 332 A recipient of traffic carried on a P2MP service supported by a 333 P2MP LSP. A receiver is not necessarily an egress LSR of the P2MP 334 LSP. Zero, one or more receivers may receive data through a given 335 egress LSR. 337 2.2.1 Terminology for Partial LSPs 339 It is convenient to sub-divide P2MP trees for functional and 340 representational reasons. A tree may be divided in two dimensions: 342 - A division may be made along the length of the tree. For example, 343 the tree may be split into two components each running from the 344 ingress LSR to a discrete set of egress LSRs. Upstream LSRs (for 345 example, the ingress LSR) may be members of both components. 347 - A tree may be divided at a branch LSR (or any transit LSR) to 348 produce a component of the tree that runs from the branch (or 349 transit) LSR to all egress LSRs downstream of this point. 351 These two methods of splitting the P2MP tree can be combined, so it 352 is useful to introduce some terminology to allow the partitioned 353 trees to be clearly described. 355 Use the following designations: 356 Source (ingress) LSR - S 357 Leaf (egress) LSR - L 358 Branch LSR - B 359 Transit LSR - X (any single, arbitrary LSR that is not a source, 360 leaf or branch) 361 All - A 362 Partial (i.e. not all) - P 364 Define a new term: 366 Sub-LSP 368 A segment of a P2MP TE LSP that runs from one of the LSP's LSRs 369 to one or more of its other LSRs. 371 Using these new concepts we can define any combination or split of 372 the P2MP tree. For example: 374 S2L sub-LSP 375 The path from the source to one specific leaf. 377 S2PL sub-LSP 378 The path from the source to a set of leaves. 380 B2AL sub-LSP 381 The path from a branch LSR to all downstream leaves. 383 X2X sub-LSP 384 A component of the P2MP LSP that is a simple path thatwith 385 does not branches. 387 Note that the S2AL sub-LSP is equivalent to the P2MP LSP. 389 2.3 Conventions 391 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 392 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 393 this document are to be interpreted as described in [RFC2119]. 395 3. Problem Statement 397 3.1 Motivation 399 As described in section 1, Traffic Engineering and Constraint Based 400 Routing (including Call Admission Control(CAC), explicit source 401 routing, and bandwidth reservation) are required to enable efficient 402 resource usage and strict QoS guarantees. Such mechanisms also make 403 it possible to provide services across a congested network where 404 conventional "shortest path first" forwarding paradigms would fail. 406 Existing MPLS TE mechanisms [RFC3209] and GMPLS TE mechanisms 407 [RFC3473] only provide support for P2P TE LSPs. While it is possible 408 to provide P2MP TE services using P2P TE LSPs, any such approach is 409 potentially suboptimal since it may result in data replication at 410 the ingress LSR, or in duplicate data traffic within the network. 412 Hence, to provide P2MP MPLS TE services in a fully efficient manner 413 it is necessary to specify specific requirements. These requirements 414 can then be used when defining mechanisms for the use of existing 415 protocols and/or extensions to existing protocols and/or new 416 protocols. 418 3.2. Requirements Overview 420 This document states basic requirements for the setup of P2MP TE 421 LSPs. The requirements apply to the signaling techniques only, and 422 no assumptions are made about which routing protocols are run within 423 the network, nor about how the information that is used to construct 424 the Traffic Engineering Database (TED) is distributed. These factors 425 are out of the scope of this document. 427 A P2MP TE LSP path computation will take into account various 428 constraints such as bandwidth, affinities, required level of 429 protection and so on. The solution MUST allow for the computation of 430 P2MP TE LSP paths satisfying constraints with the objective of 431 supporting various optimization criteria such as delays, bandwidth 432 consumption in the network, or any other combinations. This is likely 433 to require the presence of a TED, as well as the ability to signal 434 the explicit path of an LSP. 436 A desired requirement is also to maximize the re-use of existing 437 MPLS TE techniques and protocols where doing so does not adversely 438 impact the function, simplicity or scalability of the solution. 440 This document does not restrict the choice of signaling protocol 441 used to set up a P2MP TE LSP, but it should be noted that [RFC3468] 442 states 443 ... the consensus reached by the Multiprotocol Label Switching 444 (MPLS) Working Group within the IETF to focus its efforts on 445 "Resource Reservation Protocol (RSVP)-TE: Extensions to RSVP for 446 Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signaling 447 protocol for traffic engineering applications... 449 The P2MP TE LSP setup mechanism MUST include the ability to 450 add/remove egress LSRs to/from an existing P2MP TE LSP and MUST 451 allow for the support of all the TE LSP management procedures 452 already defined for P2P TE LSP. Further, when new TE LSP procedures 453 are developed for P2P TE LSPs, equivalent or identical procedures 454 SHOULD be developed for P2MP TE LSPs. 456 The computation of P2MP trees is implementation dependent and is 457 beyond the scope of the solutions that are built with this document 458 as a guideline. 460 Consider the following figure. 462 Source 1 (S1) 463 | 464 I-LSR1 465 | | 466 | | 467 R2----E-LSR3--LSR1 LSR2---E-LSR2--Receiver 1 (R1) 468 | : 469 R3----E-LSR4 E-LSR5 470 | : 471 | : 472 R4 R5 474 Figure 1 476 Figure 1 shows a single ingress LSR (I-LSR1), and four egress LSRs 477 (E-LSR2, E-LSR3, E-LSR4 and E-LSR5). I-LSR1 is attached to a traffic 478 source that is generating traffic for a P2MP application. Receivers 479 R1, R2, R3 and R4 are attached to E-LSR2, E-LSR3 and E-LSR4. 481 The following are the objectives of P2MP LSP establishment and use. 483 a) A P2MP tree which satisfies various constraints is 484 pre-determined and details are supplied to I-LSR1. 486 Note that no assumption is made on whether the tree is 487 provided to I-LSR1 or computed by I-LSR1. The 488 solution SHOULD also allow for the support of a partial path by 489 means of loose routing. 491 Typical constraints are bandwidth requirements, resource class 492 affinities, fast rerouting, preemption. There should not be any 493 restriction on the possibility to support the set of 494 constraints already defined for point to point TE LSPs. A new 495 constraint may specify which LSRs should be used as branch LSRs 496 for the P2MP LSR in order to take into account LSR capabilities 497 or network constraints. 499 b) A P2MP TE LSP is set up from I-LSR1 to E-LSR2, E-LSR3 and 500 E-LSR4 using the tree information. 502 c) In this case, the branch LSR1 should replicate incoming 503 packets or data and send them to E-LSR3 and E-LSR4. 505 d) If a new receiver (R5) expresses an interest in receiving 506 traffic, a new tree is determined and a B2L sub-LSP from LSR2 507 to E-LSR5 is grafted onto the P2MP TE LSP. LSR2 becomes a 508 branch LSR. 510 4. Detailed requirements for P2MP TE extensions 512 4.1 P2MP LSP 514 The P2MP TE extensions MUST be applicable to the signaling of LSPs 515 for different switching types. For example, it MUST be possible to 516 signal a P2MP TE LSP in any switching medium being packet or 517 non-packet based (including frame, cell, TDM, lambda, etc.). 519 As with P2P MPLS technology [RFC3031], traffic is classified with a 520 FEC in this extension. All packets which belong to a particular FEC 521 and which travel from a particular node MUST follow the same P2MP 522 tree. 524 In order to scale to a large number of branches, P2MP TE LSPs SHOULD 525 be identified by a unique identifier (the P2MP ID or P2ID) that is 526 constant for the whole LSP regardless of the number of branches 527 and/or leaves. 529 4.2 P2MP explicit routing 531 Various optimizations in P2MP tree formation need to be applied to 532 meet various QoS requirements and operational constraints. 534 Some P2MP applications may request a bandwidth guaranteed P2MP tree 535 which satisfies end-to-end delay requirements. And some operators 536 may want to set up a cost minimum P2MP tree by specifying branch 537 LSRs explicitly. 539 The P2MP TE solution therefore MUST provide a means of establishing 540 arbitrary P2MP trees under the control of an external tree 541 computation process or path configuration process or dynamic tree 542 computation process located on the ingress LSR. Figure 2 shows two 543 typical examples. 545 A A 546 | / \ 547 B B C 548 | / \ / \ 549 C D E F G 550 | / \ / \/ \ / \ 551 D--E*-F*-G*-H*-I*-J*-K*--L H I J KL M N O 553 Steiner P2MP tree SPF P2MP tree 555 Figure 2 Examples of P2MP TE LSP topology 557 One example is the Steiner P2MP tree (Cost minimum P2MP tree) 558 [STEINER]. This P2MP tree is suitable for constructing a cost 559 minimum P2MP tree so as to minimize the bandwidth consumption in 560 the core. To realize this P2MP tree, several intermediate LSRs must 561 be both MPLS data terminating LSRs and transit LSRs (LSRs E, F, G, 562 H, I, J and K in the figure 2). Therefore, the P2MP TE solution MUST 563 support a mechanism that can setup this kind of bud LSR between an 564 ingress LSR and egress LSRs. Note that this includes constrained 565 Steiner trees that allow for the computation of a minimal cost trees 566 with some other constraints such as a bounded delay between the 567 source and every receiver. 569 Another example is a CSPF (Constraint Shortest Path First) P2MP 570 tree. By some metric (which can be set upon any specific criteria 571 like the delay, bandwidth, a combination of those), one can 572 calculate a shortest path P2MP tree. This P2MP tree is suitable for 573 carrying real-time traffic. 575 The solution MUST allow the operator to make use of any tree 576 computation technique. In the former case an efficient/optimal tree 577 is defined as a minimal cost tree (Steiner tree) whereas in the 578 later case it is defined as the tree that provides shortest path 579 between the source and any receiver. 581 To support explicit setup of any reasonable P2MP tree shape, a P2MP 582 TE solution MUST support some form of explicit source-based control 583 of the P2MP tree which can explicitly include particular LSRs as 584 branch LSRs. This can be used by the ingress LSR to setup the P2MP 585 TE LSP. For instance, a P2MP TE LSP can be simply represented as a 586 whole tree or by its individual branches. 588 4.3 Explicit Path Loose Hops and Widely Scoped Abstract Nodes 590 A P2MP tree is completely specified if all of the required branches 591 and hops between a sender and leaf LSR are indicated. 593 A P2MP tree is partially specified if only a subset of intermediate 594 branches and hops are indicated. This may be achieved using loose 595 hops in the explicit path, or using widely scoped abstract nodes 596 (that is, abstract nodes that are not simple [RFC3209]) such as IPv4 597 prefixes shorter than 32 bits, or AS numbers. A partially specified 598 P2MP tree might be particularly useful in inter-area and inter-AS 599 situations although P2MP requirements for inter-area and inter-AS are 600 beyond the scope of this document. 602 Protocol solutions SHOULD include a way to specify loose hops and 603 widely scoped abstract nodes in the explicit source-based control of 604 the P2MP tree as defined in the previous section. Where this support 605 is provided, protocol solutions MUST allow downstream LSRs to apply 606 further explicit control to the P2MP tree to resolve a partially 607 specified tree into a (more) completely specified tree. 609 Protocol solutions MUST allow the P2MP tree to be completely 610 specified at the ingress LSR where sufficient information exists to 611 allow the full tree to be computed and where policies along the path 612 (such as at domain boundaries) support full specification. 614 In all cases, the egress LSRs of the P2MP TE LSP must be fully 615 specified either individually or through some collective identifier. 616 Without this information, it is impossible to know to where the TE 617 LSP should be routed. 619 In case of a tree being computed by some downstream LSRs (e.g. the 620 case of hops specified as loose hops), the solution MUST provide 621 protocol mechanisms for the ingress LSR of the P2MP TE LSP to learn 622 the full P2MP tree. Note that this information may not always be 623 obtainable owing to policy considerations, but where part of the path 624 remains confidential it MUST be reported through aggregation (for 625 example, using an AS number). 627 4.4 P2MP TE LSP establishment, teardown, and modification mechanisms 629 The P2MP TE solution MUST support establishment, maintenance and 630 teardown of P2MP TE LSPs in a manner that is at least scalable in a 631 linear way. This MUST include both the existence of very many LSPs at 632 once, and the existence of very many destinations for a single P2MP 633 LSP. 635 In addition to P2MP TE LSP establishment and teardown mechanisms, it 636 SHOULD support a partial P2MP tree modification mechanism. 638 For the purpose of adding sub-P2MP TE LSPs to an existing P2MP TE 639 LSP, the extensions SHOULD support a grafting mechanism. For the 640 purpose of deleting a sub-P2MP TE LSPs from an existing P2MP TE LSP, 641 the extensions SHOULD support a pruning mechanism. 643 It is RECOMMENDED that these grafting and pruning operations cause 644 no additional processing in nodes that are not along the path to 645 the grafting or pruning node, or that are downstream of the grafting 646 or pruning node toward the grafted or pruned leaves. Moreover, both 647 grafting and pruning operations MUST NOT disrupt traffic currently 648 forwarded along the P2MP tree. 650 There is no assumption that the explicitly routed P2MP LSP remains on 651 an optimal path after several grafts and prunes have occurred. In 652 this context, scalable refers to the signaling process for the P2MP 653 TE LSP. The TE nature of the LSP allows that re-optimization may take 654 place from time to time to restore the optimality of the LSP. 656 4.5 Fragmentation 658 The P2MP TE solution MUST handle the situation where a single 659 protocol message cannot contain all of the information necessary to 660 signal the establishment of the P2MP LSP. It MUST be possible to 661 establish the LSP in these circumstances. 663 This situation may arise in either of the following circumstances. 665 a. The ingress LSR cannot signal the whole tree in a single 666 message. 668 b. The information in a message expands to be too large (or is 669 discovered to be too large) at some transit node. This may 670 occur because of some increase in the information that needs 671 to be signaled or because of a reduction in the size of 672 signaling message that is supported. 674 The solution to these problems SHOULD NOT rely on IP fragmentation of 675 protocol messages and it is RECOMMENDED to rely on some protocol 676 procedures specific to the signaling solution. 678 In the event that fragmented IP packets containing protocol messages 679 are received, it is NOT RECOMMENDED that they are reassembled at the 680 receiving LSR. 682 4.6 Failure Reporting and Error Recovery 684 Failure events may cause egress LSRs or sub-P2MP LSPs to become 685 detached from the P2MP TE LSP. These events MUST be reported upstream 686 as for a P2P LSP. 688 The solution SHOULD provide recovery techniques such as protection 689 and restoration allowing recovery of any impacted sub-P2MP TE LSPs. 690 In particular, a solution MUST provide fast protection mechanisms 691 applicable to P2MP TE LSP similar to the solutions specified in 692 [RFC4090] for P2P TE LSPs. Note also that no assumption is made on 693 whether backup paths for P2MP TE LSPs should or should not be shared 694 with P2P TE LSPs backup paths. 696 Note that the functions specified in [RFC4090] are currently specific 697 to packet environments and do not apply to non-packet environments. 698 Thus, while solutions MUST provide fast protection mechanisms similar 699 to those specified in [RFC4090], this requirement is limited to the 700 subset of the solution space that applies to packet switched networks 701 only. 703 Note that the requirements expressed in this document are general to 704 all MPLS TE P2MP signaling, and any solution that meets them will 705 therefore be general. Specific applications may have additional 706 requirements, or may want to relax some requirements stated in this 707 document. This may lead to variations in the solution. 709 The solution SHOULD also support the ability to meet other network 710 recovery requirements such as bandwidth protection and bounded 711 propagation delay increase along the backup path during failure. 713 A P2MP TE solution MUST support P2MP fast protection mechanism to 714 handle P2MP applications sensitive to traffic disruption. 716 If the ingress LSR is informed of the failure of delivery to fewer 717 than all of the egress LSRs this SHOULD NOT cause automatic teardown 718 of the P2MP TE LSP. That is, while some egress LSRs remain connected 719 to the P2MP tree it SHOULD be a matter of local policy at the ingress 720 LSR whether the P2MP LSP is retained. 722 When all egress LSRs downstream of a branch LSR have become 723 disconnected from the P2MP tree, and some branch LSR is unable 724 to restore connectivity to any of them by means of some recovery or 725 protection mechanisms, the branch LSR MAY remove itself from the 726 P2MP tree provided that it is not also an egress LSR (that is, a 727 bud). Since the faults that severed the various downstream egress 728 LSRs from the P2MP tree may be disparate, the branch LSR MUST 729 report all such errors to its upstream neighbor. An upstream LSR or 730 the ingress LSR can then decide to re-compute the path to those 731 particular egress LSRs, around the failure point. 733 Solutions MAY include the facility for transit LSRs and particularly 734 branch LSRs to recompute sub-P2MP trees to restore them after 735 failures. In the event of successful repair, error notifications 736 SHOULD NOT be reported to upstream nodes, but the new paths are 737 reported if route recording is in use. Crankback requirements are 738 discussed in Section 4.21. 740 4.7 Record route of P2MP TE LSP 742 Being able to identify the established topology of P2MP TE LSP is 743 very important for various purposes such as management and operation 744 of some local recovery mechanisms like Fast Reroute [RFC4090]. A 745 network operator uses this information to manage P2MP TE LSPs. 747 Therefore the P2MP TE solution MUST support a mechanism which can 748 collect and update P2MP tree topology information after P2MP LSP 749 establishment and modification process. 751 It is RECOMMENDED that the information is collected in a data format 752 which allows easy recognition of the P2MP tree topology. 754 The solution MUST support mechanisms for the recording of both 755 outgoing interfaces and node-ids. 757 The solution MUST gracefully handle scaling issues concerned with the 758 collection of P2MP tree information including the case where the 759 collected information is too large to be carried in a single protocol 760 message. 762 4.8 Call Admission Control (CAC) and QoS Control mechanism of 763 P2MP TE LSPs 765 P2MP TE LSPs may share network resource with P2P TE LSPs. Therefore 766 it is important to use CAC and QoS in the same way as P2P TE LSPs 767 for easy and scalable operation. 769 P2MP TE solutions MUST support both resource sharing and exclusive 770 resource utilization to facilitate co-existence with other LSPs to 771 the same destination(s). 773 P2MP TE solutions MUST be applicable to DiffServ-enabled networks 774 that can provide consistent QoS control in P2MP LSP traffic. 776 Any solution SHOULD also satisfy the DS-TE requirements [RFC3564] 777 and interoperate smoothly with current P2P DS-TE protocol 778 specifications. 780 Note that this requirement document does not make any assumption on 781 the type of bandwidth pool used for P2MP TE LSPs which can either be 782 shared with P2P TE LSP or be dedicated for P2MP use. 784 4.9 Variation of LSP Parameters 786 Certain parameters (such as priority and bandwidth) are associated 787 with an LSP. The parameters are installed by the signaling exchanges 788 associated with establishing and maintaining the LSP. 790 Any solution MUST NOT allow for variance of these parameters within 791 a single P2MP LSP. That is: 793 - No attributes set and signaled by the ingress LSR of a P2MP LSP may 794 be varied by downstream LSRs. 795 - There MUST be homogeneous QoS from the root to all leaves of a 796 single P2MP LSP. 798 Changing the parameters for the whole tree MAY be supported, but the 799 change MUST apply to the whole tree from ingress LSR to all egress 800 LSRs. 802 4.10 Re-optimization of P2MP TE LSPs 804 The detection of a more optimal path (for example, one with a lower 805 overall cost) is an example of a situation where P2MP TE LSP 806 re-routing may be required. While re-routing is in progress, an 807 important requirement is avoiding double bandwidth reservation 808 (over the common parts between the old and new LSP) thorough the use 809 of resource sharing. 811 Make-before-break MUST be supported for a P2MP TE LSP to ensure that 812 there is minimal traffic disruption when the P2MP TE LSP is 813 re-routed. 815 Make-before-break that only applies to a sub-P2MP tree without 816 impacting the data on all of the other parts of the P2MP tree MUST be 817 supported. 819 The solution SHOULD allow for make-before-break re-optimization of 820 any subdivision of the P2MP LSP (S2PL sub-LSP, S2X sub-LSP, S2L 821 sub-LSP, X2AL sub-LSP, B2PL sub-LSP, X2AL sub-LSP, or B2AL tree). 822 Further it SHOULD do so minimizing the signaling impact on the rest 823 of the P2MP LSP, and without affecting the ability of the management 824 plane to manage the LSP. 826 The solution SHOULD also provide the ability for the ingress LSR to 827 have strict control over the re-optimization process. The ingress 828 LSR SHOULD be able to limit all re-optimization to be 829 source-initiated. 831 Where sub-LSP re-optimization is allowed by the ingress LSR, such 832 re-optimization MAY be initiated by a downstream LSR that is the 833 root of the sub-LSP that is to be re-optimized. Sub-LSP 834 re-optimization initiated by a downstream LSR MUST be carried out 835 with the same regard to minimizing the impact on active traffic as 836 was described above for other re-optimization. 838 4.11 Merging of Tree Branches 840 It is possible for a single transit LSR to receive multiple signaling 841 messages for the same P2MP LSP but for different sets of 842 destinations. These messages may be received from the same or 843 different upstream nodes and may need to be passed on to the same or 844 different downstream nodes. 846 This situation may arise as the result of the signaling solution 847 definition or implementation options within the signaling solution. 848 Further, it may happen during make-before-break reoptimization 849 (section 4.10). 851 It is even possible that it is necessary to construct distinct 852 upstream branches in order to achieve the correct label choices in 853 certain switching technologies managed by GMPLS (for example, 854 photonic cross-connects where the selection of a particular lambda 855 for the downstream branches is only available on different upstream 856 switches). 858 The solution MUST support the case where multiple signaling 859 messages for the same P2MP LSP are received at a single transit LSR 860 and refer to the same upstream interface. In this case the result of 861 the protocol procedures SHOULD be a single data flow on the upstream 862 interface. 864 The solution SHOULD support the case where multiple signaling 865 messages for the same P2MP LSP are received at a single transit LSR 866 and refer to different upstream interfaces, and where each signaling 867 message results in the use of different downstream interfaces. This 868 case represents data flows that cross at the LSR but which do not 869 merge. 871 The solution MAY support the case where multiple signaling messages 872 for the same P2MP LSP are received at a single transit LSR and refer 873 to different upstream interfaces, and where the downstream interfaces 874 are shared across the received signaling messages. This case 875 represents the merging of data flows. A solution that supports this 876 case MUST ensure that data is not replicated on the downstream 877 interfaces. 879 An alternative to supporting this last case is for the signaling 880 protocol to indicate an error such that the merge may be resolved by 881 the upstream LSRs. 883 4.12 Data Duplication 885 Data duplication refers to the receipt by any recipient of duplicate 886 instances of the data. In a packet environment this means the 887 receipt of duplicate packets. Although small-scale packet duplication 888 (that is, a few packets over a relatively short period of time) 889 should be a harmless (if inefficient) situation, certain existing and 890 deployed applications will not tolerate packet duplication. Sustained 891 packet duplication is, at best, a waste of network and processing 892 resources, and at worst may cause congestion and the inability to 893 process the data correctly. 895 In a non-packet environment data duplication means the duplication of 896 some part of the signal that may lead to the replication of data or 897 to the scrambling of data. 899 Data duplication may legitimately arise in various scenarios 900 including re-optimization of active LSPs as described in the 901 previous section, and protection of LSPs. Thus, it is impractical to 902 regulate against data duplication in this document. 904 Instead, the solution: 906 - SHOULD limit to bounded transitory conditions the cases where 907 network bandwidth is wasted by the existence of duplicate delivery 908 paths. 910 - MUST limit the cases where duplicate data is delivered to an 911 application to bounded transitory conditions. 913 4.13 IPv4/IPv6 support 915 Any P2MP TE solution MUST support IPv4 and IPv6 addressing. 917 4.14 P2MP MPLS Label 919 A P2MP TE solution MUST allow the continued use of existing 920 techniques to establish P2P LSPs (TE and otherwise) within the same 921 network, and MUST allow the co-existence of P2P LSPs within the same 922 network as P2MP TE LSPs. 924 A P2MP TE solution MUST be specified in such a way that it allows 925 P2MP and P2P TE LSPs to be signaled on the same interface. 927 4.15 Advertisement of P2MP capability 929 Several high-level requirements have been identified to determine the 930 capabilities of LSRs within a P2MP network. The aim of such 931 information is to facilitate the computation of P2MP trees using TE 932 constraints within a network that contains LSRs that do not all have 933 the same capabilities levels with respect to P2MP signaling and data 934 forwarding. 936 These capabilities include, but are not limited to: 938 - The ability of an LSR to support branching. 939 - The ability of an LSR to act as an egress LSR and a branch LSR for 940 the same LSP. 941 - The ability of an LSR to support P2MP MPLS-TE signaling. 943 4.16 Multi-access LANs 945 P2MP MPLS TE may be used to traverse network segments that are 946 provided by multi-access media such as Ethernet. In these cases, it 947 is also possible that the entry point to the network segment is a 948 branch LSR of the P2MP LSP. 950 Two options clearly exist: 952 - the branch LSR replicates the data and transmits multiple copies 953 onto the segment 954 - the branch LSR sends a single copy of the data to the segment 955 and relies on the exit points to determine whether to receive and 956 forward the data. 958 The first option has a significant data plane scaling issue since all 959 replicated data must be sent through the same port and carried on the 960 same segment. Thus, a solution SHOULD provide a mechanism for a 961 branch LSR to send a single copy of the data onto a multi-access 962 network and reach multiple (adjacent) downstream nodes. The second 963 option may have control plane scaling issues. 965 4.17 P2MP MPLS OAM 967 The MPLS and GMPLS MIB modules MUST be enhanced to provide P2MP TE 968 LSP management in line with whatever signaling solutions are 969 developed. 971 In order to facilitate correct management, P2MP TE LSPs MUST have 972 unique identifiers since otherwise it is impossible to determine 973 which LSP is being managed. 975 Further discussions of OAM are out of scope for this document. 976 See [P2MP-OAM] for more details. 978 4.18 Scalability 980 Scalability is a key requirement in P2MP MPLS systems. Solutions MUST 981 be designed to scale well with an increase in the number of any of 982 the following: 984 - the number of recipients 985 - the number of egress LSRs 986 - the number of branch LSRs 987 - the number of branches. 989 Both scalability of control plane operation (setup, maintenance, 990 modification and teardown) MUST be considered. 992 Key considerations MUST include: 993 - the amount of refresh processing associated with maintaining 994 a P2MP TE LSP. 995 - the amount of protocol state that must be maintained by ingress 996 and transit LSRs along a P2MP tree. 997 - the number of protocol messages required to set up or tear down a 998 P2MP LSP as a function of the number of egress LSRs. 999 - the number of protocol messages required to repair a P2MP LSP after 1000 failure or perform make-before-break. 1001 - the amount of protocol information transmitted to manage 1002 a P2MP TE LSP (i.e. the message size). 1003 - the amount of additional data distributed in potential routing 1004 extensions. 1005 - the amount of additional control plane processing required in 1006 the network to detect whether an add/delete of a new branch is 1007 required, and in particular, the amount of processing in steady 1008 state when no add/delete is requested 1009 - the amount of control plane processing required by the ingress, 1010 transit and egress LSRs to add/delete a branch LSP to/from an 1011 existing P2MP LSP. 1013 It is expected that the applicability of each solution will be 1014 evaluated with regards to the aforementioned scalability criteria. 1016 4.18.1 Absolute Limits 1018 In order to achieve the best solution for the problem space it is 1019 helpful to clarify the boundaries for P2MP TE LSPs. 1021 - Number of egress LSRs. 1023 A scaling bound is placed on the solution mechanism such that a 1024 P2MP TE LSP MUST reduce to similar scaling properties as a P2P LSP 1025 when the number of egress LSRs reduces to one. That is, 1026 establishing a P2MP TE LSP to a single egress LSR should cost 1027 approximately as much as establishing a P2P LSP. 1029 It is important to classify the issues of scaling within the 1030 context of Traffic Engineering. It is anticipated that the initial 1031 deployments of P2MP TE LSPs will be limited to a maximum of around 1032 a hundred egress LSRs, but that within five years deployments may 1033 increase this to several hundred, and that future deployments may 1034 require significantly larger numbers. 1036 An acceptable upper bound for a solution, therefore, is one that 1037 scales linearly with the number of egress LSRs. It is expected that 1038 solutions will scale better than linearly. 1040 Solutions that scale worse than linear (that is, exponential or 1041 polynomial) are not acceptable whatever the number of egress LSRs 1042 they could support. 1044 - Number of branch LSRs. 1046 Solutions MUST support all possibilities from one extreme of a 1047 single branch LSR that forks to all leaves on a separate branch, 1048 to the greatest number of branch LSRs which is (n-1) for n egress 1049 LSRs. Assumptions MUST NOT be made in the solution regarding which 1050 topology is more common, and the solution MUST be designed to 1051 ensure scalability in all topologies. 1053 - Dynamics of P2MP tree. 1055 Recall that the mechanisms for determining which egress LSRs should 1056 be added to an LSP, and for adding and removing egress LSRs from 1057 that group are out of the scope of this document. Nevertheless, it 1058 is useful to understand the expected rates of arrival and 1059 departure of egress LSRs since this can impact the selection of 1060 solution techniques. 1062 Again, it must be recalled that this document is limited to Traffic 1063 Engineering, and in this model the rate of change of LSP egress 1064 LSRs may be expected to be lower than the rate of change of 1065 recipients in an IP multicast group. 1067 Although the absolute number of egress LSRs coming and going is the 1068 important element for determining the scalability of a solution, 1069 it may be noted that a percentage may be a more comprehensible 1070 measure, but that this is not as significant for LSPs with a small 1071 number of recipients. 1073 A working figure for an established P2MP TE LSP is less than 10% 1074 churn per day. That is, a relatively slow rate of churn. 1076 We could say that a P2MP LSP would be shared by multiple multicast 1077 groups and so the dynamics of the P2MP LSP would be relatively 1078 small. 1080 Solutions MUST optimize for such relatively low rates of change and 1081 are not required to optimize for significantly higher rates of 1082 change. 1084 - Rate of change within the network. 1086 It is also important to understand the scaling with regard to 1087 changes within the network. That is, one of the features of a P2MP 1088 TE LSP is that it can be robust or protected against network 1089 failures, and can be re-optimized to take advantage of newly 1090 available network resources. 1092 It is more important that a solution be optimized for scaling with 1093 respect to recovery and re-optimization of the LSP than for change 1094 in the egress LSRs, because P2MP is used as a TE tool. 1096 The solution MUST follow this distinction and optimize accordingly. 1098 4.19 Backwards Compatibility 1100 It SHOULD be an aim of any P2MP solution to offer as much backward 1101 compatibility as possible. An ideal which is probably impossible to 1102 achieve would be to offer P2MP services across legacy MPLS networks 1103 without any change to any LSR in the network. 1105 If this ideal cannot be achieved, the aim SHOULD be to use legacy 1106 nodes as both transit non-branch LSRs and egress LSRs. 1108 It is a further requirement for the solution that any LSR that 1109 implements the solution SHALL NOT be prohibited by that act from 1110 supporting P2P TE LSPs using existing signaling mechanisms. That is, 1111 unless administratively prohibited, P2P TE LSPs MUST be supported 1112 through a P2MP network. 1114 Also, it is a requirement that P2MP TE LSPs MUST be able to co-exist 1115 with IP unicast and IP multicast networks. 1117 4.20 GMPLS 1119 The requirement for P2MP services for non-packet switch interfaces 1120 is similar to that for Packet-Switch Capable (PSC) interfaces. 1121 Therefore, it is a requirement that reasonable attempts must be made 1122 to make all the features/mechanisms (and protocol extensions) that 1123 will be defined to provide MPLS P2MP TE LSPs equally applicable to 1124 P2MP PSC and non-PSC TE-LSPs. If the requirements of non-PSC networks 1125 over-complicate the PSC solution a decision may be taken to separate 1126 the solutions. 1128 Solutions for MPLS P2MP TE-LSPs when applied to GMPLS P2MP PSC or 1129 non-PSC TE-LSPs MUST be compatible with the other features of GMPLS 1130 including: 1132 - control and data plane separation, 1133 - full support of numbered and unnumbered TE links, 1134 - use of the arbitrary labels and labels for specific technologies, 1135 as well as negotiation of labels where necessary to support limited 1136 label processing and swapping capabilities, 1137 - the ability to apply external control to the labels selected on 1138 each hop of the LSP, and to control the next hop 1139 label/port/interface for data after it reaches the egress LSR, 1141 - support for graceful and alarm-free enablement and termination of 1142 LSPs, 1143 - full support for protection including link level protection, 1144 end-to-end protection and segment protection, 1145 - the ability to teardown an LSP from a downstream LSR, in particular 1146 from the egress LSR, 1147 - handling of Graceful Deletion procedures, 1148 - support for failure and restart or reconnection of the control 1149 plane without any disruption of the data plane. 1151 In addition, since non-PSC TE-LSPs may have to be processed in 1152 environments where the "P2MP capability" could be limited, specific 1153 constraints may also apply during the P2MP TE Path computation. 1154 Being technology specific, these constraints are outside the scope 1155 of this document. However, technology independent constraints 1156 (i.e. constraints that are applicable independently of the LSP 1157 class) SHOULD be allowed during P2MP TE LSP message processing. 1158 It has to be emphasized that path computation and management 1159 techniques shall be as close as possible to those being used for 1160 PSC P2P TE LSPs and P2MP TE LSPs. 1162 4.21 P2MP Crankback routing 1164 P2MP solutions SHOULD support crankback requirements as defined in 1165 [CRANKBACK]. In particular, they SHOULD provide sufficient 1166 information to a branch LSR from downstream LSRs to allow the branch 1167 LSR to re-route a sub-LSP around any failures or problems in the 1168 network. 1170 5. Security Considerations 1172 This requirements document does not define any protocol extensions 1173 and does not, therefore, make any changes to any security models. 1175 It is a requirement that any P2MP solution developed to meet some or 1176 all of the requirements expressed in this document MUST include 1177 mechanisms to enable the secure establishment and management of P2MP 1178 MPLS-TE LSPs. This includes, but is not limited to: 1179 - mechanisms to ensure that the ingress LSR of a P2MP LSP is 1180 identified 1181 - mechanisms to ensure that communicating signaling entities can 1182 verify each other's identities 1183 - mechanisms to ensure that control plane messages are protected 1184 against spoofing and tampering 1185 - mechanisms to ensure that unauthorized leaves or branches are not 1186 added to the P2MP LSP 1187 - mechanisms to protect signaling messages from snooping. 1189 It should be noted that P2MP signaling mechanisms built on P2P 1190 RSVP-TE signaling are likely to inherit all of the security 1191 techniques and problems associated with RSVP-TE. These problems may 1192 be exacerbated in P2MP situations where security relationships may 1193 need to maintained between an ingress LSR and multiple egress LSRs. 1194 Such issues are similar to security issues for IP multicast. 1196 It is a requirement that documents offering solutions for P2MP LSPs 1197 MUST have detailed security sections. 1199 6. IANA Considerations 1201 This informational draft does not introduce any new encodings or code 1202 points. It requires no action from IANA. 1204 7. Acknowledgements 1206 The authors would like to thank George Swallow, Ichiro Inoue, Dean 1207 Cheng, Lou Berger and Eric Rosen for their review and suggestions. 1209 Thanks to Loa Andersson for his help resolving the final issues in 1210 this document and to Harald Alvestrand for a thorough GenArt review. 1212 8. References 1214 8.1 Normative References 1216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1217 Requirement Levels", BCP 14, RFC 2119, March 1997. 1219 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. 1220 McManus, "Requirements for Traffic Engineering Over 1221 MPLS", RFC2702, September 1999. 1223 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, 1224 "Multiprotocol Label Switching Architecture", RFC 3031, 1225 January 2001. 1227 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 1228 V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1229 Tunnels", RFC 3209, December 2001. 1231 8.2 Informational References 1233 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 1234 Switching (GMPLS) Signaling - Resource ReserVation 1235 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1236 RFC 3473, January 2003. 1238 [RFC3564] F. Le Faucheur, W. Lai, "Requirements for Support of 1239 Differentiated Services-aware MPLS Traffic 1240 Engineering", RFC 3564, July 2003. 1242 [RFC4090] P. Pan, G. Swallow, A. Atlas, "Fast Reroute Extensions 1243 to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 1245 [STEINER] H. Salama, et al., "Evaluation of Multicast Routing 1246 Algorithm for Real-Time Communication on High-Speed 1247 Networks," IEEE Journal on Selected Area in 1248 Communications, pp.332-345, 1997. 1250 [CRANKBACK] A. Farrel, A. Satyanarayana, A. Iwata, N. Fujita, G. 1251 Ash, S. Marshall, "Crankback Signaling Extensions for 1252 MPLS Signaling", draft-ietf-ccamp-crankback, work in 1253 progress. 1255 [P2MP-OAM] S. Yasukawa, A. Farrel, D. King, and T. Nadeau, "OAM 1256 Requirements for Point-to-Multipoint MPLS Networks", 1257 draft-yasukawa-mpls-p2mp-oam-reqs, work in progress. 1259 9. Editor's Address 1261 Seisho Yasukawa 1262 NTT Corporation 1263 9-11, Midori-Cho 3-Chome 1264 Musashino-Shi, Tokyo 180-8585, 1265 Japan 1266 Phone: +81 422 59 4769 1267 Email: yasukawa.seisho@lab.ntt.co.jp 1269 10. Authors' Addresses 1271 Dimitri Papadimitriou 1272 Alcatel 1273 Francis Wellensplein 1, 1274 B-2018 Antwerpen, 1275 Belgium 1276 Phone : +32 3 240 8491 1277 Email: dimitri.papadimitriou@alcatel.be 1279 JP Vasseur 1280 Cisco Systems, Inc. 1281 300 Beaver Brook Road 1283 Boxborough, MA 01719, 1284 USA 1285 Email: jpv@cisco.com 1286 Yuji Kamite 1287 NTT Communications Corporation 1288 Tokyo Opera City Tower 1289 3-20-2 Nishi Shinjuku, Shinjuku-ku, 1290 Tokyo 163-1421, 1291 Japan 1292 Email: y.kamite@ntt.com 1294 Rahul Aggarwal 1295 Juniper Networks 1296 1194 North Mathilda Ave. 1297 Sunnyvale, CA 94089 1298 Email: rahul@juniper.net 1300 Alan Kullberg 1301 Motorola Computer Group 1302 120 Turnpike Rd. 1303 Southborough, MA 01772 1304 Email: alan.kullberg@motorola.com 1306 Adrian Farrel 1307 Old Dog Consulting 1308 Phone: +44 (0) 1978 860944 1309 Email: adrian@olddog.co.uk 1311 Markus Jork 1312 Quarry Technologies 1313 8 New England Executive Park 1314 Burlington, MA 01803 1315 EMail: mjork@quarrytech.com 1317 Andrew G. Malis 1318 Tellabs 1319 2730 Orchard Parkway 1320 San Jose, CA 95134 1321 Phone: +1 408 383 7223 1322 Email: andy.malis@tellabs.com 1324 Jean-Louis Le Roux 1325 France Telecom 1326 2, avenue Pierre-Marzin 1327 22307 Lannion Cedex 1328 France 1329 Email: jeanlouis.leroux@francetelecom.com 1331 11. Intellectual Property Consideration 1333 The IETF takes no position regarding the validity or scope of any 1334 Intellectual Property Rights or other rights that might be claimed 1335 to pertain to the implementation or use of the technology 1336 described in this document or the extent to which any license 1337 under such rights might or might not be available; nor does it 1338 represent that it has made any independent effort to identify any 1339 such rights. Information on the procedures with respect to rights 1340 in RFC documents can be found in BCP 78 and BCP 79. 1342 Copies of IPR disclosures made to the IETF Secretariat and any 1343 assurances of licenses to be made available, or the result of an 1344 attempt made to obtain a general license or permission for the use 1345 of such proprietary rights by implementers or users of this 1346 specification can be obtained from the IETF on-line IPR repository 1347 at http://www.ietf.org/ipr. 1349 The IETF invites any interested party to bring to its attention 1350 any copyrights, patents or patent applications, or other 1351 proprietary rights that may cover technology that may be required 1352 to implement this standard. Please address the information to the 1353 IETF at ietf-ipr@ietf.org. 1355 12. Full Copyright Statement 1357 Copyright (C) The Internet Society (2005). This document is 1358 subject to the rights, licenses and restrictions contained in BCP 1359 78, and except as set forth therein, the authors retain all their 1360 rights. 1362 This document and the information contained herein are provided 1363 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1364 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1365 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1366 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1367 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1368 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1369 PARTICULAR PURPOSE.