MPLS Working Group R. Li Internet-Draft Q. Zhao Intended status: Standards Track Huawei Technologies Expires: April 26, 2013 C. Jacquenet France Telecom Orange R. Tao Huawei Technologies B. Zhang Telus Communications October 23, 2012 Receiver-Driven Multicast Traffic-Engineered Label-Switched Paths draft-lzj-mpls-receiver-driven-multicast-rsvp-te-02.txt Abstract This document describes the receiver-driven RSVP-TE P2MP LSP signaling protocol (mRSVP-TE) which is an extension to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the computation and establishment of Receiver-Driven Traffic-Engineered point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The document also describes the mRSVP-TE extensions and procedures for the interworking between mRSVP-TE and the Protocol Independent Multicast (PIM) protocol. 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 April 26, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Li, et al. Expires April 26, 2013 [Page 1] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 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 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Li, et al. Expires April 26, 2013 [Page 2] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. mRSVP-TE . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2. The Need For PIM and mRSVP-TE Interworking . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Receiver-Driven mRSVP-TE LSP Examples . . . . . . . . . . . . 9 2.1. RD P2MP LSP Example . . . . . . . . . . . . . . . . . . . 9 2.2. RD MP2MP LSP Example . . . . . . . . . . . . . . . . . . . 11 3. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 12 3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1. Sessions . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2. L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . 13 3.1.3. Path Originator and Data Receiver . . . . . . . . . . 14 3.1.4. Explicit Routing . . . . . . . . . . . . . . . . . . . 14 3.2. PIM-mRSVP TE Interworking Operation . . . . . . . . . . . 15 3.2.1. New M-Flow Spec Types . . . . . . . . . . . . . . . . 15 3.2.2. Signaling An Unidentified Sub-LSP . . . . . . . . . . 16 3.3. Path Messages . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Resv Messages . . . . . . . . . . . . . . . . . . . . . . 18 3.5. PathErr Messages . . . . . . . . . . . . . . . . . . . . . 19 3.6. ResvErr Message . . . . . . . . . . . . . . . . . . . . . 19 3.7. PathTear Messages . . . . . . . . . . . . . . . . . . . . 19 4. New and Updated Objects . . . . . . . . . . . . . . . . . . . 19 4.1. SESSION Object . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1. mRSVP-TE IPv4 LSP Tunnel SESSION Object . . . . . . . 20 4.1.2. mRSVP-TE IPv6 LSP Tunnel SESSION Object . . . . . . . 21 4.2. SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . . 21 4.2.1. mRSVP-TE LSP IPv4 Tunnel SENDER_TEMPLATE Object . . . 21 4.2.2. SENDER_TEMPLATE Objects . . . . . . . . . . . . . . . 22 4.3. L2S_SUB_LSP Objects . . . . . . . . . . . . . . . . . . . 23 4.3.1. L2S_SUB_LSP IPv4 Objects . . . . . . . . . . . . . . . 23 4.3.2. L2S_SUB_LSP IPv6 Objects . . . . . . . . . . . . . . . 24 4.4. FILTER_SPEC Objects . . . . . . . . . . . . . . . . . . . 24 4.4.1. mRSVP-TE LSP_IPv4 FILTER_SPEC Objects . . . . . . . . 24 4.4.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Objects . . . . . . . . 24 4.5. MFLOW Object . . . . . . . . . . . . . . . . . . . . . . . 24 5. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 27 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Li, et al. Expires April 26, 2013 [Page 3] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 1. Introduction 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. The specification of traffic-engineered, MPLS-based, Point-to-Multi-Point (P2MP) tree structures ([RFC4875] is meant to address both quality and robustness issues, but failed to be massively adopted and deployed 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. However, it is possible and intuitively more efficient to start the signaling of a LSP as soon as a receiver notifies interest about a multicast content. Thus, the signaling path relies upon a receiver- initiated paradigm, all the way from the receiver to the source. This means that the information conveyed in IGMP/MLD Report messages sent by the receiver towards the IGMP/MLD Querier which is often embedded in the PIM Designated Router that is located as close to the receiver as possible and typically at the edge of the PIM network will be used to compute the receiver-initiated, PIM-derived signaled, P2MP MPLS LSP. This document extends RSVP-TE for the dynamic computation of receiver- driven P2MP and MP2MP LSP tree structures. It also specifies the mRSVP-TE extenstions and procedures for the interworking between mRSVP-TE and the Protocol Independent Multicast PIM protocol [RFC4601]. 1.1. Motivation 1.1.1. mRSVP-TE IP multicast distribution trees are receiver-initiated and dynamic by nature. IP multicast-enabled applications are also bandwidth savvy, especially in the area of residential IPTV services, where the delivery of multicast contents to several hundreds of thousands of IPTV receivers assumes the appropriate level of quality. Current source-driven P2MP LSP establishment, as defined as in [RFC4875], assumes a priori knowledge of receiver locations. Typically, the LSP signaling is initiated by the MPLS router connected to the source (headend) in such environments. The a priori knowledge of receiver locations is obtained either through static configuration or by using another protocol to discover the receivers and their Join/Prune states for each data stream. On the other hand, there is no straightforward way to support MP2MP applications by Li, et al. Expires April 26, 2013 [Page 4] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 using P2MP LSP unless full-meshed P2MP LSPs are set up. The receiver-driven extension to RSVP-TE defined in this document will support both P2MP LSPs and MP2MP LSPs. Moreover, it does not require the root router to know all the receivers' locations a priori. A protocol for receiver discovery is therefore not needed. 1.1.2. The Need For PIM and mRSVP-TE Interworking Service providers use IP multicast for the delivery of live TV broadcasting services. IP multicast traffic is generally forwarded over core MPLS infrastructures, along PIM- computed multicast distribution trees. For the sake of overall service performance, scalability and robustness, it is recognized that the PIM machinery should be restricted to the edge of the MPLS network, while IP multicast traffic is forwarded along P2MP MPLS LSP paths in the MPLS core network. Such a design assumes that: o PIM multicast trees are dynamically computed and established at PIM edge(s), and o MPLS P2MP LSPs are dynamically computed and established according to the information conveyed in PIM signaling messages. Subsequently, IP multicast traffic is forwarded along a PIM multicast tree from a source connected somewhere at the edge of the MPLS network, then forwarded along the corresponding Receiver-Driven P2MP LSP within the MPLS network so that it ultimately reaches receivers through PIM Designated Routers connected somewhere at the edge of the MPLS network. The purpose of such design that combine the dynamics of PIM signaling with the robustness of traffic-engineered P2MP MPLS tree structures is to encourage PIM-free core infrastructures for the sake of operational simplification and performance optimization. In this document we describe PIM/mRSVP-TE interworking procedures derived from the framework documented in [I-D.tao-mpls-pim-interworking]]. [I-D.tao-mpls-pim-interworking]] defines a framework for interworking procedures between PIM and an MPLS P2MP LSP signaling protocol to accommodate all PIM operations with an MPLS network in an optimal and scalable manner, thereby avoiding the need for a third protocol to dynamically discover and propagate PIM multicast states across the MPLS network. The general interworking mechanisms and procedures are those defined Li, et al. Expires April 26, 2013 [Page 5] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 in [I-D.tao-mpls-pim-interworking] and MUST be implemented as part of the interworking solution. Therefore, this document only describes the mRSVP-TE-specific procedures to be implemented. 1.2. Terminology The following terms are used in this document: o Sender: Sender refers to the Originator (and hence the Sender) of the content/payload, as defined in [RFC2205]. o Receiver: Receiver refers to the Receiver of the content/payload, as defined in [RFC2205]. o Upstream: The direction of flow from content Receiver toward content Sender, as defined in [RFC2205]. o Downstream: The direction of flow from content Sender toward content Receiver, as defined in [RFC2205]. o Path-Sender: The sender of RSVP PATH messages, with no correlation to the direction of multicast content flows. Its flow direction is irrelevant to that of the Sender, as defined above. o Path-Receiver: The receiver of RSVP PATH messages, with no correlation to the direction of multicast content flows. 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 can be a Path-Sender, but such an intermediate node cannot create and initiate RSVP PATH messages. A Path-Initator is a Path-Sender, but a Path-Sender doesn't have to be a Path-Initiator. o Path-Terminator: The Path-Receiver that does NOT propagate the Path message any further. A Path-Terminator is different from a Path-Receiver in that an intermediate node can be a Path-Receiver, but such an intermediate node will propagate the Path message to the next hop. o Root: A router where a RD P2MP LSP is rooted at. Multicast content data enter are forwarded along the RD P2MP LSP from the root to the leaves. o mPMBR: MPLS-PIM Multicast Border Router where MPLS-PIM interworking takes place. Li, et al. Expires April 26, 2013 [Page 6] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 o Leaf or Leaf mPMBR: In the context of a RD P2MP LSP, it is the mPMBR acting as a leaf for the said LSP. o Root or Root mPMBR: In the context of a RD P2MP LSP, it is the mPMBR acting as the root of the said LSP. o M-Flow Spec: The Multicast Flow Spec (from a mRSVP TE standpoint) that corresponds to a PIM forwarding rule 1.3. Overview Although the receiver-driven extensions to RSVP-TE as defined in this document use the existing sender-driven syntax, there are important semantic differences that need to be defined for correct interpretation and interoperability purposes. In the receiver-driven context, some semantics of RSVP-TE messages are inverted, but the syntax remains unchanged as much as possible. In this document, mRSVP-TE denotes the use of the receiver-driven multicast extensions to RSVP-TE. The following are some key differences that are specific to the receiver-driven paradigm: o The leaf router: The router that receives multicast contents which will be eventually delivered to the receiver. In this document, the leaf router will initiate PATH messages. o L2S (Leaf-To-Source) Destinations: Routers where multicast content data enter the RD P2MP LSP. o RSVP P2MP PATH messages are sent by leaf routers of the RD P2MP LSP towards the root of the said LSP. o RSVP P2MP RESV messages are sent by the root towards the leaf routers of the RD P2MP tree structure. o A RSVP RESV message received by a router is interpreted as a successful resource reservation made by the upstream node for the establishment of the RD P2MP tree structure. o A RSVP RESV message received by a router is interpreted as successful resource reservation made by the downstream node for the establishment of an RD MP2MP tree structure. o Label allocation on incoming interfaces is done prior to sending RSVP PATH messages upstream for RD P2MP tree structures. Li, et al. Expires April 26, 2013 [Page 7] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 o Label allocation on incoming interfaces is done prior to sending RSVP RESV messages upstream for RD MP2MP tree structures. o For RD P2MP LSP tree structures, a node receiving a RSVP PATH message first decides if this RSVP PATH message will make the said node a branch LSR or not. If it is not a branch LSR, it is a transit LSR. In the case that it will become a transit LSR because of this PATH message, it will, before sending the RSVP PATH message upstream, allocate the requested bandwidth as signaled in the RSVP PATH message on the interface on which the RSVP PATH message is received. The upstream node can send traffic soon after successfully reserving resources on the downstream link, on which the RSVP PATH message SHOULD be received. In the case that the node is already a branch or a transit node for a given multicast group before it receives the PATH message, it will then allocate the requested bandwidth on the interface on which the RSVP PATH message is received, and send the RESV message to the node which sends the PATH message without propagating the PATH message further to the upstream node. For RD P2MP LSPs, a label is carried by the PATH message and should be used by the upstream node to forward multicast content downstream. o For RD MP2MP LSP tree structures, a node will allocate the requested bandwidth on the interface through which the RSVP PATH message is sent before sending the RSVP PATH message upstream. A node receiving a RSVP PATH message MUST first decide if this RSVP PATH message will make the said node a branch LSR or not. In the case it will become a transit LSR because of this PATH message, it will then allocate the requested bandwidth on the interface on which the RSVP PATH message is received as well as on the interface through which the RSVP PATH message is sent, before sending the RSVP PATH message upstream. The downstream node can send traffic soon after successfully reserving bandwidth on the upstream link through which the RSVP PATH message SHOULD be sent. The upstream node can send traffic soon after successfully reserving bandwidth on the downstream link on which the RSVP PATH message SHOULD be received. In the case that the node is already a branch or a transit node for a given multicast group before it receives the PATH message, it will then allocate the requested resources on the interface on which the RSVP PATH message is received, and send back the RESV message to the node that sent the PATH message without propagating the PATH message further to the upstream node. The label carried by the PATH message should be used by the Path-Receiver node to forward data from the Path- Receiver node to the Path-Sender node, and the label carried by RESV messages should be used by its corresponding Path-Sender node to send data from the Path-Sender node to the Path-Receiver node. Li, et al. Expires April 26, 2013 [Page 8] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 2. Receiver-Driven mRSVP-TE LSP Examples This section illustrates by two examples how RD P2MP and RD MP2MP LSP paths are set up, respectively. In both examples, RSVP PATH messages are initiated by the leaf routers of the LSP. For the RD P2MP example, a RSVP PATH message carries a label for sending multicast data downstream. And for the RD MP2MP example, both RSVP PATH and RESV messages carry a label for sending data downstream and upstream. 2.1. RD P2MP LSP Example Sender/Source/Path Terminator/Ingress Router +---------+ | R1 | +-----+---+ _ \ \ /\ \ \ \ Path Message w/ Label OBJECT Resv \ \ \ (msg2) Message \ \ \ (msg3) \ \ \ _\/ \ \ +----------------+ Path Remerge | R3 | Creates Branch Point +----------------+ _ _ / / /\ \ \ /\ / / / \ \ \ Path Message (msg1) Resv Message / / / msg4 \ \ \ w/ Label OBJECT (msg6) / / / \ \ \ / / /Path Msg \ \ \ / / / (msg5) \ \ \ \/_ / / w/Label OBJ _\/ \ \ +----------+ +---+-----+ | R4 | | R5 | +----------+ +---------+ Path Initiator Path Initiator Originator ID = R4 Originator ID = R5 L2S Destination = R1 L2S Destination = R1 Session = S Session = S Figure 1: RD P2MP LSP Example Li, et al. Expires April 26, 2013 [Page 9] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 In Figure 1, when R5 is added as the first leaf of a mulitcast distribution tree (multicast LSP), the message flow goes as follows: R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. When the leaf R4 is added, the message flow goes from R4->msg5->R3->msg6->R4. In this case, when R3 receives msg5, R3 finds out that a RD P2MP LSP has already been set up for the same multicast group (and the same source). Therefore, R3 is a branch node for leaves R4 and R5, and R3 will therefore be the last router to receive and process the PATH message. R3 will then build the corresponding RESV message and send it back to R4. The association of the LSP initiated by R4 to the existing RD P2MP LSP is determined based upon the processing of the SESSION and L2S_SUB_LSP objects conveyed in the mRSVP-TE messages. The SESSION and the L2S_SUB_LSP objects are documented later in this draft. Li, et al. Expires April 26, 2013 [Page 10] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 2.2. RD MP2MP LSP Example Root/Path Terminator/Ingress Router +---------+ | R1 | +-----+---+ _ \ \ /\ \ \ \ Path-mp2mp Message w/ Label OBJECT Resv \ \ \ (msg2) Message \ \ \ (msg3) \ \ \ w/ Label OBJECT _\/ \ \ +----------------+ Path-mp2mp | R3 | (Branch Point) +----------------+ _ _ / / /\ \ \ /\ / / / \ \ \ Path-mp2mp Message (msg1) Resv Message / / / msg4 \ \ \ (msg1) (msg6) / / / \ \ \ w/ Label OBJECT w/ Label OBJECT/ / /Path-mp2mp \ \ \ / / / Message \ \ \ / / / (msg5) \ \ \ \/_ / / w/ Label OBJ _\/ \ \ +----------+ +---+-----+ | R4 | | R5 | +----------+ +---------+ Path-mp2mp Initiator Path-mp2mp Initiator Originator ID = R4 Originator ID = R5 L2S Destination = R1 L2S Destination = R1 Session = S Session = S Figure 2: RD MP2MP LSP Example In Figure 2, when R5 is added as the first leaf (acting as both a sender and a receiver of multicast content) of a RD MP2MP LSP, the message flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. When the leaf R4 is added, the message flow goes from R4->msg5->R3->msg6->R4. In this case, when R3 receives msg5, R3 finds out that a RD MP2MP LSP has already been set up for the same multicast group, and R3 therefore becomes a branch LSR for leaves R4 and R5. R3 will be the last router to receive and process the corresponding PATH message, R3 will then build a RESV message accordingly, and send it back to R4. Li, et al. Expires April 26, 2013 [Page 11] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 The association of the LSP initiated by R4 to the existing RD MP2MP LSP is determined based upon the processing of the SESSION and the S2L_SUB_LSP objects conveyed in the mRSVP-TE messages. The SESSION and the L2S_SUB_LSP objects are documented in this draft. 3. Signaling Protocol Extensions The mRSVP-TE protocol is similar to RSVP-TE protocol as specified in [RFC4875], [RFC3473], and [RFC3209]. The main difference is that the leaf routers of a P2MP LSP initiate the RSVP PATH messages toward the root of the said LSP. Unlike [RFC4875], mRSVP-TE can also be used to set up RD MP2MP LSPs. In the context of the mRSVP-TE, the leaf router is the Path- Originator. The RSVP RESV messages flow in the opposite direction, and are generated by the root or a branch LSR. RSVP PATH messages are forwarded in the opposite direction of the multicast traffic. A RSVP PATH message will be terminated at the root of the RD P2MP LSP or at an intermediate node if this intermediate node has already received another PATH message from another leaf router for the same multicast group. When an intermediate node receives two or more PATH messages for the same multicast group, the intermediate node will merge them together. Whether two PATH messages should be merged depends on the information encoded in the SESSION and L2S-SUB-LSP objects. The SESSION object encodes multicast group information and the L2S-SUB-LSP (leaf-to-source sub-LSP) object encodes the multicast source or multicast root information. The following sections describe the receiver-driven extensions to the RSVP-TE protocol. When there is no difference in the protocol, the usage of [RFC4875] is assumed. 3.1. Operation 3.1.1. Sessions As specified in [RFC2205], a session is a data flow with a particular destination and transport-layer protocol. In the context of multicast, the data flow is essentially a multicast distribution tree rooted at the RD P2MP LSP or RD MP2MP LSP sources. For the sake of reliability, two or more sources/roots may be deployed to distribute the same multicast streams identified by a mulitcast group address (and possibly the address of the multicast source, in typical SSM environments). In this document, the mulitcast group address is encoded in the SESSION object and the Li, et al. Expires April 26, 2013 [Page 12] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 mulitcast source/root address in the Leaf-to-Source (L2S) sub-LSP object. Note that the same session can have different sources/roots, and the same sources/roots can have different sessions. The processing of SESSION objects in mRSVP TE is different from that of SESSION objects in RSVP-TE [RFC4875]. In order to uniquely identify mRSVP TE SESSION objects, different C-Types of SESSION objects are introduced. This draft documents SESSION objects for native IPv4/IPv6 multicast applications. Additional SESSION object types MAY be added in the future. The new SESSION C-Types are described as follows: Class Name = SESSION C-Type XX+0 mRSVP_TE_P2MP_LSP_TUNNEL_IPv4 C-Type XX+1 mRSVP_TE_P2MP_LSP_TUNNEL_IPv6 C-Type XX+2 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv4 C-Type XX+3 mRSVP_TE_MP2MP_LSP_TUNNEL_IPv6 C-Type Where XX is a number to be allocated by IANA. Figure 3: New SESSION C-Types The new SESSION C-Type MUST be used in all mRSVP-TE messages. 3.1.2. L2S Sub-LSPs A RD P2MP LSP is composed of one or more L2S sub-LSPs, which are merged together at the branch nodes. There are two ways to identify each L2S sub-LSP: o From the Sender's perspective, each sub-LSP is identified by the SESSION object, the SENDER_TEMPLATE object and S2L_SUB_LSP object, as specified in [RFC4875]. The SESSION object encodes the P2MP ID, Tunnel ID, and Extended Tunnel ID. The P2MP ID is unique within the scope of the sender (ingress LSR) and remains constant throughout the lifetime of the RD P2MP tree structure. The Extended Tunnel ID, which remains constant throughout the lifetime of the RD P2MP tree structure, contains the sender's address to make sure the identifier is globally unique. Finally, the Tunnel ID also remains constant throughout the lifetime of the RD P2MP tree structure. The SENDER_TEMPLATE object contains the ingress LSR source address. The S2L_SUB_LSP object contains the destination address of the sub-LSP. Li, et al. Expires April 26, 2013 [Page 13] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 o From the Receiver's perspective, each sub-LSP is identified by a new SESSION object, a new SENDER_TEMPLATE object and a new L2S_SUB_LSP object. The SESSION object, different from the one used in typical sender-driven environments, contains information to be used as the key to associate different PATH messages originated from different leaves. The SENDER_TEMPLATE object contains the Path-Originator's address, which is actually the leaf router of the corresponding RD P2MP LSP. The L2S_SUB_LSP object contains the source or root address of the sub-LSP, i.e., the data Sender's address. The SESSION, SENDER_TEMPLATE and L2S_SUB_LSP objects all together will identify the multicast group address, the multicast address source, and a mulitcast leaf router. This document assumes the receiver-driven approach. Once an LSR receives a receiver-driven PATH message that contains both the SESSION and L2S_SUB_LSP objects, the LSR will use these objects to determine whether the sub-LSP signaled by this PATH message should be merged with an existing RD P2MP LSP. 3.1.3. Path Originator and Data Receiver This draft documents a new type of SENDER_TEMPLATE object, which contains the Path-Originator's IP address and describes the identity of the Path Originator. In [RFC2205] and [RFC4875], the sender is a Path Originator that also forwards multicast data. In the receiver-driven context, Path Originators and data senders may be different. For RD P2MP LSPs, Path Originators are actually the leaf routers. For RD MP2MP LSPs, Path Originators are also both the data senders and leaf routers. In this document, the same Object Class SENDER_TEMPLATE with a different C-Type is used to represent and identify a Path Originator. In the case of RD P2MP LSPs, the SENDER_TEMPLATE object describes the identify of a leaf router. In the case of RD MP2MP LSPs, the SENDER_TEMPLATE object describes the identify of an LSR that behaves as both a data sender and a data receiver. All the SESSION, L2S_SUB_LSP and SENDER_TEMPLATE objects together contained in a RSVP PATH message will uniquely identify a L2S sub- LSP. 3.1.4. Explicit Routing An EXPLICIT_ROUTE Object (ERO) is used to optionally specify the explicit route of an L2S sub-LSP. Each signaled ERO corresponds to a particular L2S_SUB_LSP object. Details of ERO encoding are specified Li, et al. Expires April 26, 2013 [Page 14] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 in Section 4.5 of [RFC4875]. Within the Receiver-Driven context, ERO objects are encoded in a reverse order. When a RSVP PATH message signals a L2S sub-LSP, the EXPLICIT_ROUTE object encodes the path from the leaf to the root LSR. The PATH message also includes the L2S_SUB_LSP object for the L2S sub-LSP being signaled. The < [], > tuple represents the L2S sub-LSP and is referred to as the sub-LSP descriptor. The absence of an ERO should be interpreted as requiring hop-by-hop reverse forwarding for the sub-LSP based on the root address field of the L2S_SUB_LSP object. 3.2. PIM-mRSVP TE Interworking Operation 3.2.1. New M-Flow Spec Types [I-D.tao-mpls-pim-interworking] introduces four types of M-Flow specs, each corresponding to a type of PIM forwarding state: o M-Flow Spec Type-1(value 1) for (*, *, RP); o M-Flow Spec Type-2(value 2) for (*, G); o M-Flow Spec Type-3(value 3) for (S, G); o M-Flow Spec Type-4(value 4) for (S, G, RPT); These M-Flow Spec types will be signaled in-band across the MPLS network by mRSVP-TE. Their formats are specified in [I-D.tao-mpls-pim-interworking]. mRSVP-TE is used to (1) initiate the signaling of a RD P2MP LSP or a sub-LSP, (2) merge a sub-LSP into an existing LSP, or (3) delete it when a downstream router does not need it, based upon the information conveyed in the said M-Flow Specs. This implies that: o M-Flow specs are encapsulated into mRSVP-TE PATH messages, and o M-Flow specs are used to identify a given multicast session so that a receiver-driven, traffic-engineered P2MP LSP path will be computed and established accordingly. When an M-Flow spec is generated and passed to mRSVP-TE based upon the MPLS-PIM interworking procedures enforced by an mPMBR, mRSVP-TE first determines if this M-Flow spec leads to the grafting of an additional sub-LSP, by using the procedure described in [I-D.tao-mpls-pim-interworking]. If the contents of the signaled Li, et al. Expires April 26, 2013 [Page 15] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 M-Flow Spec does not mandate the grafting of an additional sub-LSP, the M-Flow is then bound to an existing RD P2MP LSP. If a new sub-LSP needs to be grafted to an existing receiver-driven, traffic engineered P2MP MPLS LSP according to the information conveyed in the M-Flow spec, the procedures documented in the following subsections MUST be followed. 3.2.2. Signaling An Unidentified Sub-LSP When a sub-LSP is signaled from a leaf mPMBR towards the root, mRSVP-TE may not have determined if this sub-LSP would lead to the computation and the establishment of a new RD P2MP LSP or the grafting of an additional sub-LSP to an existing RD P2MP MPLS LSP. This sub-LSP is denoted as an "Unidentified" sub-LSP. mRSVP-TE then works as follows to signal an unidentified sub-LSP. 3.2.2.1. Sending A Path Message For An Unidentified Sub-LSP o Set 0 as the tunnel ID field in the session object o Set the "Tunnel Identifier with M-Flow Spec Session" attribute flag to 1 o Encode the M-Flow spec in the mflow spec object list according to the "Path Message Change and Encoding". 3.2.2.2. Receiving A Path Message For An Unidentified Sub-LSP When a LSR receives a PATH message with 0 as the tunnel ID and the "Tunnel Identifier with MFLOW spec" flag set to 1, it processes the sub-LSP grafting request as an unidentified sub-LSP as follows: o Use the included M-Flow spec and binding policy to determine which RD P2MP LSP the sub-LSP belongs to. See Sections 3.1.2 and 3.1.3 of [I-D.tao-mpls-pim-interworking]. o When the sub-LSP does not merge into an existing RD P2MP MPLS LSP, the PATH message will reach the root, which can then determine if the sub-LSP assumes the computation of a new RD P2MP MPLS LSP, or merges into an existing RD P2MP MPLS LSP. o The sub-LSP is then assigned the tunnel ID. The root sets the "Tunnel Identifier with MFLOW spec" session attribute flag to 0, and completes the rest of the signaling using mRSVP-TE procedures. Li, et al. Expires April 26, 2013 [Page 16] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 o Each LSR merges the M-Flow spec in the mflow spec object list using mflow_specs_merge(T, F) when the tunnel is identified. 3.3. Path Messages The mechanism specified in this document allows a RD P2MP/MP2MP LSP to be signaled using one or more RSVP PATH messages. Each PATH message MAY signal one or several L2S sub-LSPs. A receiver-driven P2MP MPLS LSP uses the PATH message to carry the LABEL object upstream from the leaf router towards the Sender. With a receiver-driven usage of the RSVP PATH messages, the LABEL_REQUEST object carried by the PATH message is no longer mandatory. It becomes optional for receiver-driven PATH messages, as specified in Figure 4 below. The PIM/mRSVP-TE inter-working procedures introduce a new session attribute called "Tunnel Identifier with MFLOW spec". By default, it is set to 0. For an unidentified sub-LSP, the attribute is set by the Path Sender to indicate that a router receiving this message must process the information conveyed in M-Flow specs to identify the corresponding session and make a decision accordingly (e.g., contribute to the grafting of a new sub-LSP to the relevant RD P2MP MPLS LSP). The mRSVP-TE PATH message is extended to include a list of M-Flow Spec Objects: ::= [ ] [ [ | ] ...] [ ] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ... ] [] [mflow spec list] < mflow spec list > ::= [< mflow spec list >] Figure 4: Path Message Extensions Li, et al. Expires April 26, 2013 [Page 17] Internet-Draft Receiver-Driven Multicast RSVP-TE October 2012 The SESSION object encodes information about the being-signalled multicast group address. The SESSION object together with the L2S_SUB_LSP object will be used as the key to associate different sub-LSPs to the same RD P2MP LSP. Using [RFC4875] as the reference specification, the LABEL object is added to the as specified in Figure 5. ::= [ ] [ ] [ ] [ ]