Requirements for Receiver-Driven Traffic Engineered Point-to-Multi-Point (P2MP) MPLS Tree Structures
Author(s): Telus Communications, Quintin Zhao, Christian Jacquenet, Eduard Metz
This document presents a set of requirements for the establishment and maintenance of Receiver-Driven Point-to-Multipoint (RD-P2MP) and Multipoint-to-Multipoint (RD-MP2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)....
Internet Engineering Task Force C. Jacquenet Internet-Draft France Telecom Orange Intended status: Informational Q. Zhao Expires: January 11, 2014 Huawei Technology B. Zhang Telus Communications E. Metz KPN July 10, 2013 Requirements for Receiver-Driven Traffic Engineered Point-to-Multi-Point (P2MP) MPLS Tree Structures draft-jacquenet-mpls-rd-p2mp-te-requirements-03.txt Abstract This document presents a set of requirements for the establishment and maintenance of Receiver-Driven Point-to-Multipoint (RD-P2MP) and Multipoint-to-Multipoint (RD-MP2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 11, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jacquenet, et al. Expires January 11, 2014 [Page 1] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Typical Use Case: Interconnecting PIM Islands Through A MPLS Backbone . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Scope and Assumptions . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Robustness . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Performance and Scalability . . . . . . . . . . . . . . . 8 3.6. Management . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 10 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction 1.1. Rationale The dramatic growth of multicast-based IP services such as live TV broadcasting raises new challenges for network operators. The sole use of IP multicast becomes challenging, given the QoS-demanding nature of the applications, especially in light of the deployment of High Definition or 3D TV. The specification of traffic-engineered, MPLS-based, Point-to-Multi- Point (P2MP) tree structures  is meant to address both quality and robustness issues, but failed to be massively adopted and deployed by operators so far, mostly because the current standard assumes a priori knowledge of all the routers involved in the establishment and the maintenance of the tree structure, at the cost of extra management complexity. Jacquenet, et al. Expires January 11, 2014 [Page 2] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 Current technological state-of-the-art shows that most of implementations assume the static configuration of the basic information that will be used by routers to build a traffic- engineered P2MP LSP path a la . Scalability issues may also be raised by the current standard as core routers are likely to maintain a number of RSVP states that will grow with the number of leaf routers. The receiver-initiated paradigm of IP multicast is also a true incentive for faster convergence in MPLS environments, yielding an improved computation and establishment of traffic-engineered P2MP MPLS tree structures. In addition, the inability to take into account the network access capabilities of the receivers, so that the computation of the tree structure can dynamically adapt to such access conditions becomes even more challenging with the ever-growing number of multicast channels that need to be delivered to the receivers. Thus, we believe that the combination of the dynamics of receiver- initiated IP multicast distribution trees with the hard QoS guarantees brought by a MPLS-based traffic engineered tree computation scheme is promising, for the sake of optimized convergence and facilitated (if not automated) hard-guaranteed service design and operation. Taking the best of breed between PIM-computed , receiver-driven multicast distribution trees and MPLS traffic engineering capabilities can indeed significantly improve 1.2. Typical Use Case: Interconnecting PIM Islands Through A MPLS Backbone Taking the best of breed between PIM-computed, receiver-driven multicast distribution trees and MPLS traffic engineering capabilities can indeed significantly improve the level of quality associated to the delivery of multicast services. One typical example would be a network design where PIM "islands" (for example, PIM-enabled access infratsructures that connect multicast receivers, as well as the IPTV head end that connects the multicast source) connect to a MPLS backbone infrastructure. Multicast traffic is forwarded along the RD-P2MP LSP paths without soliciting an additional routing protocol such as BGP (, ) to learn the multicast routes and exchange the PIM multicast states of each PIM island, so that P2MP LSP paths can be established accordingly. Jacquenet, et al. Expires January 11, 2014 [Page 3] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 The Receiver-Driven approach should solely rely upon the PIM protocol and the use of a PIM/MPLS inter-working function at the border between the PIM islands and the MPLS backbone infrastructure, so that no PIM state has to be maintained by the MPLS routers of the backbone. 1.3. Scope and Assumptions This document details the requirements for the dynamic establishment and maintenance of receiver-driven, traffic-engineered Point-to- Multi-Point (RD-P2MP) tree structures. As such, considerations about Label Distribution Protocol (LDP) extensions for the computation of P2MP tree structures  are out of the scope of this draft. Likewise, this document exclusively focuses on traffic-engineered P2MP MPLS tree structures. As such, traffic-engineered Multi-Point- to-Multi-Point (MP2MP) MPLS tree structures are not taken into consideration, mostly because it is believed that the primary applicability of MPLS traffic engineering capabilities for multicast- enabled services remains IPTV services that assume a 1:N group communication scheme that is typical of Source-Specific Multicast designs. Nevertheless, the requirements detailed in this document are also valid for receiver-driven, traffic-engineered MP2MP tree structures. 2. Terminology The following terms are used in this document: o Sender: The source of the content, as in . o Receiver: The Receiver of the content multicast by the source, as in . o Upstream: The direction of a given traffic from a Receiver towards a Sender, as defined in . o Downstream: The direction of multicast traffic from a Sender towards a Receiver, as defined in . o Path-Sender: The sender of a RSVP_PATH message, with NO correlation to the directionality of the corresponding multicast traffic. o Path-Receiver: The receiver of a RSVP_PATH message, with NO correlation to the directionality of the corresponding multicast traffic. Jacquenet, et al. Expires January 11, 2014 [Page 4] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 o Path-Initiator: The Path-Sender that originated a RSVP_PATH message. A Path-Initiator is different from a Path-Sender in that an intermediate node (a node that is part of the receiver-driven P2MP tree structure) can be a Path-Sender. o Path-Terminator: The Path-Receiver that does NOT propagate a RSVP_PATH message. A Path-Terminator is different from the Path- Receiver in that an intermediate node (a node that is part of the receiver-driven P2MP tree structure) can be a Path-Receiver. o Receiver-Driven P2MP Label Switched Path (RD P2MP LSP): A traffic- engineered P2MP MPLS Label Switched Path that is dynamically computed and established at the initiative of the receivers. 3. Requirements  specifies requirements for P2MP traffic-engineered MPLS Label Switched Paths. These requirements are equally applicable to Receiver-Driven traffic-engineered MPLS Label Switched Paths. This section details the additional requirements raised by the dynamic computation and establishment of RD P2MP LSPs. 3.1. Operation REQ-1 Grafting and pruning of branches of any given RD P2MP tree structure MUST be dynamic and receiver-initiated. REQ-2 Leaves of RD P2MP LSP paths MUST be aware of the corresponding P2MP LSP identifiers for tree computation and maintenance purposes. REQ-3 A leaf router MUST initiate RSVP_PATH messages that will be sent towards the root router. RSVP_PATH messages are triggered by typical signaling subcription procedures originated by receivers, such as IGMP/MLD Report messages that may be directly processed by the leaf routers of a given RD P2MP LSP. REQ-4 A node that receives a RSVP_PATH message MUST first decide if this message will make itself a branch Label Switch Router (LSR) or not. In the case that it will become a transit LSR because of this RSVP_PATH message, the router will allocate required resources on the interface through which the RSVP_PATH message is received, before forwarding it upstream (for the sake of multicast traffic delivery efficiency). REQ-5 In case the node that received the RSVP_PATH message is already a branch or transit node for the multicast content associated to the said RSVP_PATH message, the node MUST allocate Jacquenet, et al. Expires January 11, 2014 [Page 5] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 required resources (if available) on the interface through which the RSVP_PATH message is received. This node MUST NOT send the RSVP_PATH message upstream. REQ-6 Upon receipt of a RSVP_PATH message, a Path-Terminator MUST send back a RSVP_RESV message that MUST be forwarded along the RD P2MP LSP to the Path-Sender. REQ-7 A node receiving a RSVP_RESV message SHOULD interpret it as a successful resource reservation from the upstream node for the establishment of the RD P2MP LSP. REQ-8 The termination of a L2S (Leaf-to-Source) sub-path that belongs to a given RD P2MP LSP MUST be one of the ingress routers where multicast data sent by a source enter the said RD P2MP LSP. REQ-9 Label allocation MUST be done prior to sending RSVP_PATH messages upstream. REQ-10 To facilitate the computation of RD P2MP LSP paths within a network whose LSRs do not all support the same capabilities with respect to RD P2MP LSP signaling and data forwarding, the capability of a given LSR to support the RSVP-TE signaling and forwarding features for RD P2MP LSP path computation purposes MUST be advertised to its neighbor LSRs. 3.2. Forwarding REQ-11 Just like typical P2P MPLS , any given multicast traffic characterized by a multicast group address is associated with a FEC (Forwarding Equivalence Class). All packets that belong to a particular FEC MUST be forwarded along the corresponding RD P2MP LSP. REQ-12 RD P2MPLSPs MAY be deployed over multi-access media such as Ethernet. In these environments, it is possible that the entry point to the network segment is a branch LSR of the RD P2MPLSP. To avoid all replicated data are sent through the same port and carried on the same segment, a mechanism SHOULD be supported by the said branch LSR so as to send a single copy of the multicast data onto the multi-access network to reach several downstream nodes REQ-13 The RD P2MP LSP computation scheme SHOULD provide a means for a Branch LSR to send a single copy of the multicast data through an Ethernet LAN interface to reach several downstream nodes. Jacquenet, et al. Expires January 11, 2014 [Page 6] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 REQ-14 As a consequence of the previous requirement, the same label MUST be negotiated with all downstream LSRs for any given RD P2MP LSP. REQ-15 When there are several candidate upstream LSRs conected to a given LAN segment, the RD P2MP LSP path computation scheme SHOULD provide a means for all downstream LSRs to select the same upstream LSR, so as to avoid traffic replication. REQ-16 The RD P2MP LSP path computation scheme SHOULD allow for an efficient balancing of a set of P2MP LSPs among a set of candidate upstream LSRs connected to a LAN segment. 3.3. Signaling Certain parameters (such as priority and bandwidth) are associated with an LSP. The parameters are installed by means of the RSVP signalling specific to the establishment and the maintenance of RD P2MP LSPS. As such: REQ-17 Downstream or upstream LSRs MUST NOT alter the attributes set and signaled by a leaf router of any given RD P2MP LSP. REQ-18 A consistent QoS policy SHOULD be enforced from the root to all leaves of a single P2MP/MP2MP LSP. REQ-19 Some leaves of a given tree may yield the enforcement of a different QoS policy, depending on the various access capabilities of the receivers. Still, content will be delivered to these receivers by using the same (core) P2MP/MP2MP tree structure. REQ-20 Changing the parameters for the whole tree MAY be supported, but the change MUST apply to the whole tree from ingress LSR to all egress LSRs. 3.4. Robustness REQ-21 The detection of a more optimal path (e.g., from a cost standpoint) is an example of a situation where re-routing of the RD P2MP LSP MAY be required. While re-routing is in progress, duplicate bandwidth reservation over the common parts between the old and new RD P2MP LSP MUST be avoided. REQ-22 RD P2MP LSP path computation, establishment and maintenance MUST support a Make-Before-Break procedure to ensure that there is minimal traffic disruption during re-routing operations. Jacquenet, et al. Expires January 11, 2014 [Page 7] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 REQ-23 Scope of Make-Before-Break procedures MUST be restricted to the relevant sub-LSP portion of any given RD P2MP LSP, for the sake of resource optimization and overall service performance. REQ-24 The support of a Make-Before-Break procedure MUST include re- optimization facilities for any impacted sub-LSP portion of a given RD P2MP LSP. REQ-25 Any Make-Before-Break operation MUST not impact the rest of the RD P2MP LSP, from both a signaling and operational standpoints. REQ-26 Where sub-LSP re-optimization is allowed by the ingress LSR, such re- optimization MAY be initiated by a downstream LSR that is the root of the sub-LSP to be re-optimized. Sub-LSP re- optimization initiated by a downstream LSR MUST be carried out without dramatically impacting the forwarding of multicast traffic along the corresponding RD P2MP LSP. REQ-27 Any downstream node located on the sub-LSP that is being re- optimized SHOULD have control on the re-optimization procedure. REQ-28 Overtime, a given optimized path may become sub-optimized. Path re-computation capabilities SHOULD be supported and they could be triggered by updated IGP cost metrics, time interval or a combination thereof. REQ-29 Traffic load balancing capabilities SHOULD be supported by the RD P2MP LSP path computation scheme, to enforce least-fill- based load sharing computation strategies. 3.5. Performance and Scalability REQ-30 The RD P2MP LSP computation, establishment and maintenance MUST be scalable: The switching performances of the routers that are part of a RD P2MP LSP MUST NOT be affected during RD P2MP LSP path computation, establishment and operation. REQ-31 Likewise, scalability of RD P2MP LSP path design and operation MUST NOT be jeopardized by the number of receivers, nor by the number of RD P2MP LSPs maintained at any given time by the routers of the network. in particular, RD P2MP LSP path computation, establishment and operation SHOULD accommodate the need to deliver multicast traffic to several millions of receivers, without any perceived overall service performance degradtion, including the preservation of customer's Quality of Experience. Jacquenet, et al. Expires January 11, 2014 [Page 8] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 REQ-32 Dynamic grafting and pruning operations pertaining to any given RD P2MP LSP MUST NOT affect multicast traffic forwarding efficiency, from a packet loss and one-way transit delay perspectives, among other possible Quality of Service metrics. REQ-33 Dynamic grafting and pruning operations pertaining to any given RD P2MP LSP SHOULD NOT infer any other additional processing than the processing specific to the portion of the RD P2MP LSP from the added/removed leaf LSR to the corresponding branch LSR. REQ-34 Dynamic grafting and pruning operations pertaining to any given RD P2MP LSP MUST NOT disrupt the forwarding of multicast traffic along the RD P2MP LSP at any given time. REQ-35 In order to scale to a large number of branches, RD P2MP LSPs SHOULD be unambiguously identified by means of P2MP ID identifiers that MUST be persistent for the whole RD P2MP LSP, regardless of the number of branches and leaves. REQ-36 In order to accommodate a growing number of leaves, the amount of a P2MP LSP states on a given LSR, for one particular RD P2MPLSP SHOULD only depend on the number of adjacent LSRs that belong to the same RD P2MP LSP. REQ-37 RD P2MP LSP performance and scalability assessment SHOULD rely upon the following metrics (and a combination thereof): o Number of receivers o Number of sources o Number of leaf routers o Number of branch routers o Number of branches o Number of RD P2MP LSPs to be deployed over the MPLS network REQ-38 Scalability of control plane operation (setup, maintenance, modification, and teardown) MUST be considered. In particular: o The amount of refresh processing associated with maintaining a RD P2MP LSP. o The amount of protocol state that must be maintained by ingress and transit LSRs along a RD P2MP LSP. Jacquenet, et al. Expires January 11, 2014 [Page 9] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 o The number of protocol messages required to set up or tear down a RD P2MP LSP as a function of the number of egress LSRs. o The number of protocol messages required to repair a RD P2MP LSP after failure or to perform make-before-break. o The amount of protocol information transmitted to manage a RD P2MP LSP (i.e., the amount of management traffic as a function of the global bandwidth resources available). o The amount of signaling traffic required for RD P2MP LSP path compuation, setup and operation. o The amount of additional control plane processing required in the network to detect whether an add/delete of a new branch is required, and in particular, the amount of processing in steady state when no add/delete is requested. o The amount of control plane processing required by the ingress, transit, and egress LSRs to add/delete a branch LSP to/from an existing RD P2MP LSP. 3.6. Management REQ-39 Design and operation of RD P2MP TE LSP paths MUST support management capabilities as per the Specific Management Functional Areas (SMFAs), namely Fault, Configuration, Accounting, Performance and Security management capabilities. In particular, RD P2MP TE LSP-based and Source-to-Leaf (S2L) traffic statistics management MUST be supported. 3.7. Backward Compatibility REQ-40 The RD P2MP LSP path computation scheme MUST allow the continued use of existing techniques to establish P2P and legacy P2MP LSPs (Traffic-engineered or not) within the same network,.and MUST allow the coexistence of Receiver-Driven P2MP/MP2MP LSPSs with P2P and legacy P2MP LSPs within the same network. REQ-41 RD P2MP LSP paths MUST be able to coexist with legacy P2P and P2MP LSPs within the same network. REQ-42 Signaling capabilities of the RD P2MP LSP path computation scheme MUST NOT prevent the signaling of "legacy" P2P and P2MP LSP paths. 4. Acknowledgements Jacquenet, et al. Expires January 11, 2014 [Page 10] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 We would like to thank authors of  and  who inspired some of the text of this draft. 5. IANA Considerations This draft makes no request to IANA. 6. Security Considerations This document does not define any protocol extensions and does not, therefore, make any changes to any security models. It is a requirement that any RD P2MP LSP design MUST include mechanisms to enable the secure establishment and management. of RD P2MP LSPs. This means in particular that: o A receiver MUST be authenticated before it is allowed to trigger the grafting of an additional leaf of a RD P2MP LSP tree structure, o Mechanisms to provide some guarantees about the identity of an ingress LSR that belongs to a given RD P2MP LSP SHOULD be supported, o Mechanisms to ensure that communicating signaling entities can verify each other's identities SHOULD be supported, o Mechanisms to ensure that control plane messages are protected against spoofing and tampering SHOULD be supported, o Mechanisms to ensure that unauthorized leaves or branches are not added to any given RD P2MP/ LSP; and mechanisms to protect signaling messages from snooping MUST be supported. Note that RD P2MP LSP signaling mechanisms built on P2P RSVP-TE signaling and RSVP-TE P2MP signalling are likely to inherit all the security techniques and problems associated with RSVP-TE. These problems may be exacerbated in P2MP situations where security associations may need to be maintained between any given ingress LSR and multiple egress LSRs. Such issues are similar to security issues raised by the IP multicast transmission scheme. 7. References Jacquenet, et al. Expires January 11, 2014 [Page 11] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 7.1. Normative References  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997.  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.  Yasukawa, S., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.  Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.  Farrel, A., Papadimitriou, D., Vasseur, J., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.  Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. Jacquenet, et al. Expires January 11, 2014 [Page 12] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.  Le Roux, JL. and T. Morin, "Requirements for Point-to- Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011.  Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. 7.2. Informative References  Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003.  Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.  Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003.  Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 5467, March 2009. Authors' Addresses Christian Jacquenet France Telecom Orange 4 rue du Clos Courtel 35512 Cesson Sevigne France Phone: +33 2 99 12 43 82 Email: email@example.com Jacquenet, et al. Expires January 11, 2014 [Page 13] Internet-Draft Receiver-Driven P2MP LSP Requirements July 2013 Quintin Zhao Huawei Technology 125 Nagog Park Acton, MA 01919 US Email: firstname.lastname@example.org Boris Zhang Telus Communications 200 Consilium Pl. Floor 15 Toronto, ON M1H 3J3 Canada Email: Boris.Zhang@telus.com Eduard Metz KPN Netherlands Email: email@example.com Jacquenet, et al. Expires January 11, 2014 [Page 14]