Internet DRAFT - draft-jacquenet-mpls-rd-p2mp-te-requirements
draft-jacquenet-mpls-rd-p2mp-te-requirements
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 [6] 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 [6]. 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 [16], 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 ([14], [15]) 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 [10] 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 [9].
o Receiver: The Receiver of the content multicast by the source, as
in [9].
o Upstream: The direction of a given traffic from a Receiver towards
a Sender, as defined in [9].
o Downstream: The direction of multicast traffic from a Sender
towards a Receiver, as defined in [9].
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
[5] 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 [3], 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 [5] and [13] 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
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[3] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[4] 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.
[5] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006.
[6] 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.
[7] 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.
[8] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[9] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[10] 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.
[11] 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
[12] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[13] Le Roux, JL. and T. Morin, "Requirements for Point-to-
Multipoint Extensions to the Label Distribution Protocol",
RFC 6348, September 2011.
[14] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[15] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
[16] 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
[17] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003.
[18] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[19] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003.
[20] 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: christian.jacquenet@orange.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: qzhao@huawei.com
Boris Zhang
Telus Communications
200 Consilium Pl. Floor 15
Toronto, ON M1H 3J3
Canada
Email: Boris.Zhang@telus.com
Eduard Metz
KPN
Netherlands
Email: eduard.metz@kpn.com
Jacquenet, et al. Expires January 11, 2014 [Page 14]
