idnits 2.17.1 draft-jacquenet-mpls-rd-p2mp-te-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: REQ-25 Any Make-Before-Break operation MUST not impact the rest of the RD P2MP LSP, from both a signaling and operational standpoints. -- The document date (July 10, 2013) is 3914 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 525, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 532, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 545, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 551, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 564, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 568, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 589, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 593, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 597, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 601, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4420 (ref. '7') (Obsoleted by RFC 5420) ** Obsolete normative reference: RFC 4601 (ref. '16') (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5467 (ref. '20') (Obsoleted by RFC 6387) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Jacquenet 3 Internet-Draft France Telecom Orange 4 Intended status: Informational Q. Zhao 5 Expires: January 11, 2014 Huawei Technology 6 B. Zhang 7 Telus Communications 8 E. Metz 9 KPN 10 July 10, 2013 12 Requirements for Receiver-Driven Traffic Engineered Point-to-Multi-Point 13 (P2MP) MPLS Tree Structures 14 draft-jacquenet-mpls-rd-p2mp-te-requirements-03.txt 16 Abstract 18 This document presents a set of requirements for the establishment 19 and maintenance of Receiver-Driven Point-to-Multipoint (RD-P2MP) and 20 Multipoint-to-Multipoint (RD-MP2MP) Traffic-Engineered (TE) 21 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 11, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.2. Typical Use Case: Interconnecting PIM Islands Through A 60 MPLS Backbone . . . . . . . . . . . . . . . . . . . . . . 3 61 1.3. Scope and Assumptions . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.4. Robustness . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.5. Performance and Scalability . . . . . . . . . . . . . . . 8 69 3.6. Management . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 10 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 7.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 1.1. Rationale 83 The dramatic growth of multicast-based IP services such as live TV 84 broadcasting raises new challenges for network operators. The sole 85 use of IP multicast becomes challenging, given the QoS-demanding 86 nature of the applications, especially in light of the deployment of 87 High Definition or 3D TV. 89 The specification of traffic-engineered, MPLS-based, Point-to-Multi- 90 Point (P2MP) tree structures [6] is meant to address both quality and 91 robustness issues, but failed to be massively adopted and deployed by 92 operators so far, mostly because the current standard assumes a 93 priori knowledge of all the routers involved in the establishment and 94 the maintenance of the tree structure, at the cost of extra 95 management complexity. 97 Current technological state-of-the-art shows that most of 98 implementations assume the static configuration of the basic 99 information that will be used by routers to build a traffic- 100 engineered P2MP LSP path a la [6]. Scalability issues may also be 101 raised by the current standard as core routers are likely to maintain 102 a number of RSVP states that will grow with the number of leaf 103 routers. 105 The receiver-initiated paradigm of IP multicast is also a true 106 incentive for faster convergence in MPLS environments, yielding an 107 improved computation and establishment of traffic-engineered P2MP 108 MPLS tree structures. 110 In addition, the inability to take into account the network access 111 capabilities of the receivers, so that the computation of the tree 112 structure can dynamically adapt to such access conditions becomes 113 even more challenging with the ever-growing number of multicast 114 channels that need to be delivered to the receivers. 116 Thus, we believe that the combination of the dynamics of receiver- 117 initiated IP multicast distribution trees with the hard QoS 118 guarantees brought by a MPLS-based traffic engineered tree 119 computation scheme is promising, for the sake of optimized 120 convergence and facilitated (if not automated) hard-guaranteed 121 service design and operation. 123 Taking the best of breed between PIM-computed [16], receiver-driven 124 multicast distribution trees and MPLS traffic engineering 125 capabilities can indeed significantly improve 127 1.2. Typical Use Case: Interconnecting PIM Islands Through A MPLS 128 Backbone 130 Taking the best of breed between PIM-computed, receiver-driven 131 multicast distribution trees and MPLS traffic engineering 132 capabilities can indeed significantly improve the level of quality 133 associated to the delivery of multicast services. 135 One typical example would be a network design where PIM "islands" 136 (for example, PIM-enabled access infratsructures that connect 137 multicast receivers, as well as the IPTV head end that connects the 138 multicast source) connect to a MPLS backbone infrastructure. 139 Multicast traffic is forwarded along the RD-P2MP LSP paths without 140 soliciting an additional routing protocol such as BGP ([14], [15]) to 141 learn the multicast routes and exchange the PIM multicast states of 142 each PIM island, so that P2MP LSP paths can be established 143 accordingly. 145 The Receiver-Driven approach should solely rely upon the PIM protocol 146 and the use of a PIM/MPLS inter-working function at the border 147 between the PIM islands and the MPLS backbone infrastructure, so that 148 no PIM state has to be maintained by the MPLS routers of the 149 backbone. 151 1.3. Scope and Assumptions 153 This document details the requirements for the dynamic establishment 154 and maintenance of receiver-driven, traffic-engineered Point-to- 155 Multi-Point (RD-P2MP) tree structures. As such, considerations about 156 Label Distribution Protocol (LDP) extensions for the computation of 157 P2MP tree structures [10] are out of the scope of this draft. 159 Likewise, this document exclusively focuses on traffic-engineered 160 P2MP MPLS tree structures. As such, traffic-engineered Multi-Point- 161 to-Multi-Point (MP2MP) MPLS tree structures are not taken into 162 consideration, mostly because it is believed that the primary 163 applicability of MPLS traffic engineering capabilities for multicast- 164 enabled services remains IPTV services that assume a 1:N group 165 communication scheme that is typical of Source-Specific Multicast 166 designs. Nevertheless, the requirements detailed in this document 167 are also valid for receiver-driven, traffic-engineered MP2MP tree 168 structures. 170 2. Terminology 172 The following terms are used in this document: 174 o Sender: The source of the content, as in [9]. 176 o Receiver: The Receiver of the content multicast by the source, as 177 in [9]. 179 o Upstream: The direction of a given traffic from a Receiver towards 180 a Sender, as defined in [9]. 182 o Downstream: The direction of multicast traffic from a Sender 183 towards a Receiver, as defined in [9]. 185 o Path-Sender: The sender of a RSVP_PATH message, with NO 186 correlation to the directionality of the corresponding multicast 187 traffic. 189 o Path-Receiver: The receiver of a RSVP_PATH message, with NO 190 correlation to the directionality of the corresponding multicast 191 traffic. 193 o Path-Initiator: The Path-Sender that originated a RSVP_PATH 194 message. A Path-Initiator is different from a Path-Sender in that 195 an intermediate node (a node that is part of the receiver-driven 196 P2MP tree structure) can be a Path-Sender. 198 o Path-Terminator: The Path-Receiver that does NOT propagate a 199 RSVP_PATH message. A Path-Terminator is different from the Path- 200 Receiver in that an intermediate node (a node that is part of the 201 receiver-driven P2MP tree structure) can be a Path-Receiver. 203 o Receiver-Driven P2MP Label Switched Path (RD P2MP LSP): A traffic- 204 engineered P2MP MPLS Label Switched Path that is dynamically 205 computed and established at the initiative of the receivers. 207 3. Requirements 209 [5] specifies requirements for P2MP traffic-engineered MPLS Label 210 Switched Paths. These requirements are equally applicable to 211 Receiver-Driven traffic-engineered MPLS Label Switched Paths. This 212 section details the additional requirements raised by the dynamic 213 computation and establishment of RD P2MP LSPs. 215 3.1. Operation 217 REQ-1 Grafting and pruning of branches of any given RD P2MP tree 218 structure MUST be dynamic and receiver-initiated. 220 REQ-2 Leaves of RD P2MP LSP paths MUST be aware of the corresponding 221 P2MP LSP identifiers for tree computation and maintenance 222 purposes. 224 REQ-3 A leaf router MUST initiate RSVP_PATH messages that will be 225 sent towards the root router. RSVP_PATH messages are triggered by 226 typical signaling subcription procedures originated by receivers, 227 such as IGMP/MLD Report messages that may be directly processed by 228 the leaf routers of a given RD P2MP LSP. 230 REQ-4 A node that receives a RSVP_PATH message MUST first decide if 231 this message will make itself a branch Label Switch Router (LSR) 232 or not. In the case that it will become a transit LSR because of 233 this RSVP_PATH message, the router will allocate required 234 resources on the interface through which the RSVP_PATH message is 235 received, before forwarding it upstream (for the sake of multicast 236 traffic delivery efficiency). 238 REQ-5 In case the node that received the RSVP_PATH message is 239 already a branch or transit node for the multicast content 240 associated to the said RSVP_PATH message, the node MUST allocate 241 required resources (if available) on the interface through which 242 the RSVP_PATH message is received. This node MUST NOT send the 243 RSVP_PATH message upstream. 245 REQ-6 Upon receipt of a RSVP_PATH message, a Path-Terminator MUST 246 send back a RSVP_RESV message that MUST be forwarded along the RD 247 P2MP LSP to the Path-Sender. 249 REQ-7 A node receiving a RSVP_RESV message SHOULD interpret it as a 250 successful resource reservation from the upstream node for the 251 establishment of the RD P2MP LSP. 253 REQ-8 The termination of a L2S (Leaf-to-Source) sub-path that 254 belongs to a given RD P2MP LSP MUST be one of the ingress routers 255 where multicast data sent by a source enter the said RD P2MP LSP. 257 REQ-9 Label allocation MUST be done prior to sending RSVP_PATH 258 messages upstream. 260 REQ-10 To facilitate the computation of RD P2MP LSP paths within a 261 network whose LSRs do not all support the same capabilities with 262 respect to RD P2MP LSP signaling and data forwarding, the 263 capability of a given LSR to support the RSVP-TE signaling and 264 forwarding features for RD P2MP LSP path computation purposes MUST 265 be advertised to its neighbor LSRs. 267 3.2. Forwarding 269 REQ-11 Just like typical P2P MPLS [3], any given multicast traffic 270 characterized by a multicast group address is associated with a 271 FEC (Forwarding Equivalence Class). All packets that belong to a 272 particular FEC MUST be forwarded along the corresponding RD P2MP 273 LSP. 275 REQ-12 RD P2MPLSPs MAY be deployed over multi-access media such as 276 Ethernet. In these environments, it is possible that the entry 277 point to the network segment is a branch LSR of the RD P2MPLSP. 278 To avoid all replicated data are sent through the same port and 279 carried on the same segment, a mechanism SHOULD be supported by 280 the said branch LSR so as to send a single copy of the multicast 281 data onto the multi-access network to reach several downstream 282 nodes 284 REQ-13 The RD P2MP LSP computation scheme SHOULD provide a means for 285 a Branch LSR to send a single copy of the multicast data through 286 an Ethernet LAN interface to reach several downstream nodes. 288 REQ-14 As a consequence of the previous requirement, the same label 289 MUST be negotiated with all downstream LSRs for any given RD P2MP 290 LSP. 292 REQ-15 When there are several candidate upstream LSRs conected to a 293 given LAN segment, the RD P2MP LSP path computation scheme SHOULD 294 provide a means for all downstream LSRs to select the same 295 upstream LSR, so as to avoid traffic replication. 297 REQ-16 The RD P2MP LSP path computation scheme SHOULD allow for an 298 efficient balancing of a set of P2MP LSPs among a set of candidate 299 upstream LSRs connected to a LAN segment. 301 3.3. Signaling 303 Certain parameters (such as priority and bandwidth) are associated 304 with an LSP. The parameters are installed by means of the RSVP 305 signalling specific to the establishment and the maintenance of RD 306 P2MP LSPS. As such: 308 REQ-17 Downstream or upstream LSRs MUST NOT alter the attributes set 309 and signaled by a leaf router of any given RD P2MP LSP. 311 REQ-18 A consistent QoS policy SHOULD be enforced from the root to 312 all leaves of a single P2MP/MP2MP LSP. 314 REQ-19 Some leaves of a given tree may yield the enforcement of a 315 different QoS policy, depending on the various access capabilities 316 of the receivers. Still, content will be delivered to these 317 receivers by using the same (core) P2MP/MP2MP tree structure. 319 REQ-20 Changing the parameters for the whole tree MAY be supported, 320 but the change MUST apply to the whole tree from ingress LSR to 321 all egress LSRs. 323 3.4. Robustness 325 REQ-21 The detection of a more optimal path (e.g., from a cost 326 standpoint) is an example of a situation where re-routing of the 327 RD P2MP LSP MAY be required. While re-routing is in progress, 328 duplicate bandwidth reservation over the common parts between the 329 old and new RD P2MP LSP MUST be avoided. 331 REQ-22 RD P2MP LSP path computation, establishment and maintenance 332 MUST support a Make-Before-Break procedure to ensure that there is 333 minimal traffic disruption during re-routing operations. 335 REQ-23 Scope of Make-Before-Break procedures MUST be restricted to 336 the relevant sub-LSP portion of any given RD P2MP LSP, for the 337 sake of resource optimization and overall service performance. 339 REQ-24 The support of a Make-Before-Break procedure MUST include re- 340 optimization facilities for any impacted sub-LSP portion of a 341 given RD P2MP LSP. 343 REQ-25 Any Make-Before-Break operation MUST not impact the rest of 344 the RD P2MP LSP, from both a signaling and operational 345 standpoints. 347 REQ-26 Where sub-LSP re-optimization is allowed by the ingress LSR, 348 such re- optimization MAY be initiated by a downstream LSR that is 349 the root of the sub-LSP to be re-optimized. Sub-LSP re- 350 optimization initiated by a downstream LSR MUST be carried out 351 without dramatically impacting the forwarding of multicast traffic 352 along the corresponding RD P2MP LSP. 354 REQ-27 Any downstream node located on the sub-LSP that is being re- 355 optimized SHOULD have control on the re-optimization procedure. 357 REQ-28 Overtime, a given optimized path may become sub-optimized. 358 Path re-computation capabilities SHOULD be supported and they 359 could be triggered by updated IGP cost metrics, time interval or a 360 combination thereof. 362 REQ-29 Traffic load balancing capabilities SHOULD be supported by 363 the RD P2MP LSP path computation scheme, to enforce least-fill- 364 based load sharing computation strategies. 366 3.5. Performance and Scalability 368 REQ-30 The RD P2MP LSP computation, establishment and maintenance 369 MUST be scalable: The switching performances of the routers that 370 are part of a RD P2MP LSP MUST NOT be affected during RD P2MP LSP 371 path computation, establishment and operation. 373 REQ-31 Likewise, scalability of RD P2MP LSP path design and 374 operation MUST NOT be jeopardized by the number of receivers, nor 375 by the number of RD P2MP LSPs maintained at any given time by the 376 routers of the network. in particular, RD P2MP LSP path 377 computation, establishment and operation SHOULD accommodate the 378 need to deliver multicast traffic to several millions of 379 receivers, without any perceived overall service performance 380 degradtion, including the preservation of customer's Quality of 381 Experience. 383 REQ-32 Dynamic grafting and pruning operations pertaining to any 384 given RD P2MP LSP MUST NOT affect multicast traffic forwarding 385 efficiency, from a packet loss and one-way transit delay 386 perspectives, among other possible Quality of Service metrics. 388 REQ-33 Dynamic grafting and pruning operations pertaining to any 389 given RD P2MP LSP SHOULD NOT infer any other additional processing 390 than the processing specific to the portion of the RD P2MP LSP 391 from the added/removed leaf LSR to the corresponding branch LSR. 393 REQ-34 Dynamic grafting and pruning operations pertaining to any 394 given RD P2MP LSP MUST NOT disrupt the forwarding of multicast 395 traffic along the RD P2MP LSP at any given time. 397 REQ-35 In order to scale to a large number of branches, RD P2MP LSPs 398 SHOULD be unambiguously identified by means of P2MP ID identifiers 399 that MUST be persistent for the whole RD P2MP LSP, regardless of 400 the number of branches and leaves. 402 REQ-36 In order to accommodate a growing number of leaves, the 403 amount of a P2MP LSP states on a given LSR, for one particular RD 404 P2MPLSP SHOULD only depend on the number of adjacent LSRs that 405 belong to the same RD P2MP LSP. 407 REQ-37 RD P2MP LSP performance and scalability assessment SHOULD 408 rely upon the following metrics (and a combination thereof): 410 o Number of receivers 412 o Number of sources 414 o Number of leaf routers 416 o Number of branch routers 418 o Number of branches 420 o Number of RD P2MP LSPs to be deployed over the MPLS network 422 REQ-38 Scalability of control plane operation (setup, maintenance, 423 modification, and teardown) MUST be considered. In particular: 425 o The amount of refresh processing associated with maintaining a RD 426 P2MP LSP. 428 o The amount of protocol state that must be maintained by ingress 429 and transit LSRs along a RD P2MP LSP. 431 o The number of protocol messages required to set up or tear down a 432 RD P2MP LSP as a function of the number of egress LSRs. 434 o The number of protocol messages required to repair a RD P2MP LSP 435 after failure or to perform make-before-break. 437 o The amount of protocol information transmitted to manage a RD P2MP 438 LSP (i.e., the amount of management traffic as a function of the 439 global bandwidth resources available). 441 o The amount of signaling traffic required for RD P2MP LSP path 442 compuation, setup and operation. 444 o The amount of additional control plane processing required in the 445 network to detect whether an add/delete of a new branch is 446 required, and in particular, the amount of processing in steady 447 state when no add/delete is requested. 449 o The amount of control plane processing required by the ingress, 450 transit, and egress LSRs to add/delete a branch LSP to/from an 451 existing RD P2MP LSP. 453 3.6. Management 455 REQ-39 Design and operation of RD P2MP TE LSP paths MUST support 456 management capabilities as per the Specific Management Functional 457 Areas (SMFAs), namely Fault, Configuration, Accounting, 458 Performance and Security management capabilities. In particular, 459 RD P2MP TE LSP-based and Source-to-Leaf (S2L) traffic statistics 460 management MUST be supported. 462 3.7. Backward Compatibility 464 REQ-40 The RD P2MP LSP path computation scheme MUST allow the 465 continued use of existing techniques to establish P2P and legacy 466 P2MP LSPs (Traffic-engineered or not) within the same network,.and 467 MUST allow the coexistence of Receiver-Driven P2MP/MP2MP LSPSs 468 with P2P and legacy P2MP LSPs within the same network. 470 REQ-41 RD P2MP LSP paths MUST be able to coexist with legacy P2P and 471 P2MP LSPs within the same network. 473 REQ-42 Signaling capabilities of the RD P2MP LSP path computation 474 scheme MUST NOT prevent the signaling of "legacy" P2P and P2MP LSP 475 paths. 477 4. Acknowledgements 478 We would like to thank authors of [5] and [13] who inspired some of 479 the text of this draft. 481 5. IANA Considerations 483 This draft makes no request to IANA. 485 6. Security Considerations 487 This document does not define any protocol extensions and does not, 488 therefore, make any changes to any security models. It is a 489 requirement that any RD P2MP LSP design MUST include mechanisms to 490 enable the secure establishment and management. of RD P2MP LSPs. 491 This means in particular that: 493 o A receiver MUST be authenticated before it is allowed to trigger 494 the grafting of an additional leaf of a RD P2MP LSP tree 495 structure, 497 o Mechanisms to provide some guarantees about the identity of an 498 ingress LSR that belongs to a given RD P2MP LSP SHOULD be 499 supported, 501 o Mechanisms to ensure that communicating signaling entities can 502 verify each other's identities SHOULD be supported, 504 o Mechanisms to ensure that control plane messages are protected 505 against spoofing and tampering SHOULD be supported, 507 o Mechanisms to ensure that unauthorized leaves or branches are not 508 added to any given RD P2MP/ LSP; and mechanisms to protect 509 signaling messages from snooping MUST be supported. 511 Note that RD P2MP LSP signaling mechanisms built on P2P RSVP-TE 512 signaling and RSVP-TE P2MP signalling are likely to inherit all the 513 security techniques and problems associated with RSVP-TE. These 514 problems may be exacerbated in P2MP situations where security 515 associations may need to be maintained between any given ingress LSR 516 and multiple egress LSRs. Such issues are similar to security issues 517 raised by the IP multicast transmission scheme. 519 7. References 520 7.1. Normative References 522 [1] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 [2] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 526 McManus, "Requirements for Traffic Engineering Over MPLS", 527 RFC 2702, September 1999. 529 [3] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 530 Label Switching Architecture", RFC 3031, January 2001. 532 [4] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 533 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 534 Tunnels", RFC 3209, December 2001. 536 [5] Yasukawa, S., "Signaling Requirements for Point-to- 537 Multipoint Traffic-Engineered MPLS Label Switched Paths 538 (LSPs)", RFC 4461, April 2006. 540 [6] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 541 "Extensions to Resource Reservation Protocol - Traffic 542 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 543 Switched Paths (LSPs)", RFC 4875, May 2007. 545 [7] Farrel, A., Papadimitriou, D., Vasseur, J., and A. 546 Ayyangar, "Encoding of Attributes for Multiprotocol Label 547 Switching (MPLS) Label Switched Path (LSP) Establishment 548 Using Resource ReserVation Protocol-Traffic Engineering 549 (RSVP-TE)", RFC 4420, February 2006. 551 [8] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 552 Hierarchy with Generalized Multi-Protocol Label Switching 553 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 555 [9] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 556 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 557 Functional Specification", RFC 2205, September 1997. 559 [10] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 560 "Label Distribution Protocol Extensions for Point-to- 561 Multipoint and Multipoint-to-Multipoint Label Switched 562 Paths", RFC 6388, November 2011. 564 [11] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 565 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 566 2005. 568 [12] Berger, L., "Generalized Multi-Protocol Label Switching 569 (GMPLS) Signaling Functional Description", RFC 3471, 570 January 2003. 572 [13] Le Roux, JL. and T. Morin, "Requirements for Point-to- 573 Multipoint Extensions to the Label Distribution Protocol", 574 RFC 6348, September 2011. 576 [14] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 577 VPNs", RFC 6513, February 2012. 579 [15] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 580 Encodings and Procedures for Multicast in MPLS/BGP IP 581 VPNs", RFC 6514, February 2012. 583 [16] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 584 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 585 Protocol Specification (Revised)", RFC 4601, August 2006. 587 7.2. Informative References 589 [17] Andersson, L. and G. Swallow, "The Multiprotocol Label 590 Switching (MPLS) Working Group decision on MPLS signaling 591 protocols", RFC 3468, February 2003. 593 [18] Berger, L., "Generalized Multi-Protocol Label Switching 594 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 595 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 597 [19] Le Faucheur, F. and W. Lai, "Requirements for Support of 598 Differentiated Services-aware MPLS Traffic Engineering", 599 RFC 3564, July 2003. 601 [20] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. 602 Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 603 Switched Paths (LSPs)", RFC 5467, March 2009. 605 Authors' Addresses 607 Christian Jacquenet 608 France Telecom Orange 609 4 rue du Clos Courtel 610 35512 Cesson Sevigne 611 France 613 Phone: +33 2 99 12 43 82 614 Email: christian.jacquenet@orange.com 615 Quintin Zhao 616 Huawei Technology 617 125 Nagog Park 618 Acton, MA 01919 619 US 621 Email: qzhao@huawei.com 623 Boris Zhang 624 Telus Communications 625 200 Consilium Pl. Floor 15 626 Toronto, ON M1H 3J3 627 Canada 629 Email: Boris.Zhang@telus.com 631 Eduard Metz 632 KPN 633 Netherlands 635 Email: eduard.metz@kpn.com