Network Working Group R. Li Internet-Draft Q. Zhao Intended status: Standards Track Huawei Technologies Expires: August 30, 2012 C. Jacquenet France Telecom March 4, 2012 Receiver-Driven Multicast Traffic Engineered Label Switched Paths draft-lzj-mpls-receiver-driven-multicast-rsvp-te-00.txt Abstract This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven Traffic Engineered(TE) point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS)networks. 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 August 30, 2012. Copyright Notice Copyright (c) 2012 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Li, et al. Expires August 30, 2012 [Page 1] Internet-Draft RD Multicast RSVP-TE February 2012 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 August 30, 2012 [Page 2] Internet-Draft RD Multicast RSVP-TE February 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Receiver-Driven mRSVP-TE LSP Exampls . . . . . . . . . . . 8 2. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 10 2.1. L2S Sub-LSPs . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Explicit Routing . . . . . . . . . . . . . . . . . . . . . 12 2.3. L2S Sub-LSPs and Path Messages . . . . . . . . . . . . . . 12 2.4. Resv Message Extensions . . . . . . . . . . . . . . . . . 13 2.5. PathErr Message Extensions . . . . . . . . . . . . . . . . 14 2.6. ResvErr Message Extensions . . . . . . . . . . . . . . . . 14 2.7. PathTear Message Extensions . . . . . . . . . . . . . . . 14 2.8. SESSION Object . . . . . . . . . . . . . . . . . . . . . . 15 2.8.1. mRSVP-TE LSP Tunnel IPv4 SESSION Object . . . . . . . 16 2.8.2. mRSVP-TE LSP Tunnel IPv6 SESSION Object . . . . . . . 16 2.9. SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . . 17 2.9.1. mRSVP-TE LSP Tunnel IPv4 SENDER_TEMPLATE Object . . . 17 2.9.2. mRSVP-TE LSP Tunnel IPv6 SENDER_TEMPLATE Object . . . 17 2.10. L2S_SUB_LSP Object . . . . . . . . . . . . . . . . . . . . 18 2.10.1. L2S_SUB_LSP IPv4 Object . . . . . . . . . . . . . . . 18 2.10.2. L2S_SUB_LSP IPv6 Object . . . . . . . . . . . . . . . 19 2.11. FILTER_SPEC Object . . . . . . . . . . . . . . . . . . . . 19 2.11.1. P2MP LSP_IPv4 FILTER_SPEC Object . . . . . . . . . . . 19 2.11.2. mRSVP-TE LSP_IPv6 FILTER_SPEC Object . . . . . . . . . 19 2.11.3. mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object (SERO) . . . 20 2.11.4. mRSVP-TE SECONDARY_RECORD_ROUTE Object (SRRO) . . . . 20 3. In-Band and Out-Band Signalling . . . . . . . . . . . . . . . 20 3.1. In-Band Signalling . . . . . . . . . . . . . . . . . . . . 20 3.2. Out-Band Signalling . . . . . . . . . . . . . . . . . . . 20 4. Broadcast Interfaces . . . . . . . . . . . . . . . . . . . . . 21 5. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 21 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Li, et al. Expires August 30, 2012 [Page 3] Internet-Draft RD Multicast RSVP-TE February 2012 1. Introduction Multiparty multimedia applications are getting greater attention in the telecom world. Such applications are QoS-demanding and can therefore benefit from the activation of MPLS traffic engineering capabilities that lead to the dynamic computation and establishment of MPLS LSPs whose characteristics comply with application-specific QoS requirements. P2MP-TE [RFC4875] defines a procedure to set up point-to-multipoint LSPs from sender to receivers. This document extends RSVP-TE for the dynamic computation of receiver-driven P2MP and MP2MP LSP tree structures. 1.1. Motivation 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, and the LSP signalling is initiated and driven by the data sender(headend). Receiver-driven MPLS P2MP/MP2MP tree structures do not require sender to maintain/discover receiver information a priori, and their design should better accommodate the receiver-specific QoS conditions, such as network access capabilities. 1.2. Terminology The following terms are used in this document: o Sender: Sender refers to the Originator (and hence) 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]. Li, et al. Expires August 30, 2012 [Page 4] Internet-Draft RD Multicast RSVP-TE February 2012 o Path-Sender: The sender of RSVP PATH messages, with NO correlation to the direction of content/payload flows. Its flow direction is irrelevant to that of Sender defined above. All other control messages discussed in this document will use this as the reference. o Path-Receiver: The receiver of RSVP PATH messages, with NO correlation to the direction of content/payload flows. o Path-Initiator: The Path-Sender that originated a RSVP PATH message. This is different from Path-Sender in that an intermediate node can be a Path-Sender, but such an intermediate node cannot create and initiate the RSVP PATH message. o Path-Terminator: The Path-Receiver that does NOT propagate the Path message any further. This is different from 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 multcast LSP is rooted at. Data enters the root and then is distributed to leaves along the P2MP/MP2MP LSP 1.3. Overview Although receiver-driven P2MP LSPs as defined in this document use existing sender-driven syntax, there are important semantic differences that need to be defined for correct interpretation and interoperability. In the receiver-driven approach, we inverted the semantics of P2MP-TE RSVP [RFC4875] messages, while keeping the syntax unchanged. Following are some key differences that are specific to the receiver- driven paradigm: o The leaf router the receiver is connected to: that is, upon receipt of an IGMP/MLD Report message, the router that embeds the IGMP/MLD Querier would typically trigger a RSVP_PATH message towards the source. We keep the same convention with respect to data flows, which are opposite to control flows. o L2S (Leaf-to-Source) Destinations (the sender or root) are routers where user data payload traffic enters the LSP. o RSVP P2MP PATH messages traverse from receivers to the root. o RSVP P2MP RESV messages traverse from the root to the leaf routers of the P2MP tree strcuture. Li, et al. Expires August 30, 2012 [Page 5] Internet-Draft RD Multicast RSVP-TE March , 2012 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 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 a MP2MP tree structure. o Label allocation on incoming interfaces is done prior to sending RSVP PATH messages upstream for P2MP tree structures. o Label allocation on incoming interfaces is done prior to sending RSVP RESV messages upstream for MP2MP tree structures. o For 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, then it will, before sending the RSVP PATH message upstream, allocate required bandwidth 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 before it receives the PATH message, then it will allocate required 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 P2MP LSPs, a label is carried by the PATH message and should be used by the upstream node when distributing the data from upstream to downstream. o For MP2MP LSP tree structures, a node will allocate required 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, then it will allocate required bandwidth on the interface on which the RSVP PATH message is received and will allocate required bandwidth 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 a already a branch or a transit node before it receives the PATH message, then it will allocate required resources on the interface on which the RSVP PATH message is received, and send the RESV message to the node Li, et al. Expires August 30, 2012 [Page 6] Internet-Draft RD Multicast RSVP-TE March , 2012 which sends 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 deliver data from the Path- Sender node to the Path-Receiver node. o For the sake of readability, from now on, all mRSVP-TE messages will be used to represent all the RSVP-TE messages which are used for the computation of receiver-driven P2MP/MP2MP tree structures. o For the sake of readability, from now on all mRSVP-TE LSPs will be used to represent all P2MP and/or MP2MP LSPs in receiver-driven (RD) multicast P2MP/MP2MP MPLS environments. We will sometimes use RD P2MP TE LSP or RD MP2MP TE LSP to represent such receiver-driven multicast LSPs. Li, et al. Expires August 30, 2012 [Page 7] Internet-Draft RD Multicast RSVP-TE March , 2012 1.4. Receiver-Driven mRSVP-TE LSP Exampls 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: P2MP EXAMPLE Figure 1 shows that R5 is added as the first leaf of the RD P2MP TE 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 the RD P2MP LSP has already been set up for R5: therefore, R3 finds itself a branch node for leaf R4 and R5, so it will terminate the PATH message and 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 on the processing of the session object from the mRSVP-TE message. This session object is further documented in Section 2 of this draft. Li, et al. Expires August 30, 2012 [Page 8] Internet-Draft RD Multicast RSVP-TE March , 2012 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 \ \ \ w/ Label OBJECT (msg6) / / / \ \ \ 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: MP2MP Example Figure 2 shows that R5 is added as the first leaf (as both a sender and a receiver) of the RD MP2MP TE LSP, the message flow goes from R5->msg1->R3->msg2->R1->msg3->R3->msg4->R5. When the leaf R4 (both receiver and sender)is added, the message flow goes from R4->msg5->R3->msg6. In this case, when R3 receives msg5, R3 finds out that the RD MP2MP LSP has already been set up for R5, and R3 will become the branch LSR for the leaf R4 and R5, so it will terminate the PATH message, build a RESV message and send the RESV message back to R4. The association of the LSP initiated by R4 to Li, et al. Expires August 30, 2012 [Page 9] Internet-Draft RD Multicast RSVP-TE March , 2012 the existing MP2MP LSP is determined based on the processing of the session object from the mRSVP-TE message. This session object is further documented in Section 2 of this draft. 2. Signaling Protocol Extensions mRSVP-TE is similar to the RSVP-TE protocol as specified in [RFC4875], [RFC3473] and [RFC3209], but differs in that the receivers (or the leaf routers they are connected to) initiate the RSVP PATH messages toward the sender. Compared with [RFC4875], mRSVP-TE to be specified in this document can also be used to set up MP2MP LSPs. Within RD P2MP/MP2MP LSP tree structure environments, the Receiver is the Path-Originator. The RSVP RESV messages flow in the opposite direction as compared to the RSVP PATH messages, i.e. RSVP RESV messages are generated by the Sender or a branch LSR. Within this receiver-driven context, the processing of receiver- initiated mRSVP-TE P2MP messages is different from that of the other RSVP messages. Following the method used by RSVP-TE and P2MP RSVP-TE, this draft documents the use of new SESSION C-Type 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. The new SESSION C-Type MUST be used in all receiver-driven P2MP RSVP-TE messages. The following sections describe the receiver-driven P2MP RSVP-TE extensions to the P2MP RSVP-TE protocol. When there is no difference in the protocol, usage of [RFC4875] is assumed. Li, et al. Expires August 30, 2012 [Page 10] Internet-Draft RD Multicast RSVP-TE March , 2012 2.1. L2S Sub-LSPs A RD P2MP or MP2MP LSP is composed of one or more L2S sub-LSPs, which are merged together at the branch nodes. An L2S sub-LSP exists within the context of a RD P2MP or MP2MP LSP. There are two ways to identify each 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 [RFC 4875]. The SESSION object encodes P2MP ID, which is unique within the scope of the sender (ingress LSR) and remains constant throughout the lifetime of the P2MP tree structure. The Extended Tunnel ID, which remains constant throughout the lifetime of the P2MP tree structure, and which should contain the sender's address to make sure the identifier is globally unique identifier. Finally, the Tunnel ID, also remains constant throughout the lifetime of the P2MP tree structure. The SENDER_TEMPLATE object contains the ingress LSR source address. The S2L_SUB_LSP contains the destination address of the sub-LSP. o From the Receiver's perspective, each sub-LSP is identified by a new SESSION object specified in this document, the SENDER_TEMPLATE object and L2S_SUB_LSP. The SESSION object, different from the one used in typical sender-driven environments, contains some opaque values to be used as the key to associate different PATH messages originated from different leaves. The SENDER_TEMPLATE object contains the Path-Sender's address, which is actually the Data Receiver. The L2S_SUB_LSP contains the source address of the sub-LSP, i.e. the data Sender's address. This document takes the approach from the Receiver's perspective. The approach from the Sender's perspective is documented in [RFC 4875]. In this draft, the SESSION object will encode multicast information such as multicast source and group addresses as the opaque value. Once either the Sender LSR, a transit LSR, or a branch LSR receives a PATH message containing SESSION object, the LSR should be able to use the opaque values encoded in the SESSION object to determine whether the sub-LSP signaled by this PATH message should be merged with existing LSPs. An EXPLICIT_ROUTE Object (ERO) or mRSVP-TE_SECONDARY_EXPLICIT_ROUTE Object (SERO) is used to optionally specify the explicit route of a L2S sub-LSP. Each ERO or SERO that is signaled corresponds to a particular L2S_SUB_LSP object. Details of explicit route encoding are specified in section 4.5 of [RFC4875]. The Li, et al. Expires August 30, 2012 [Page 11] Internet-Draft RD Multicast RSVP-TE March , 2012 SECONDARY_EXPLICIT_ROUTE Object is defined in [RFC4873], the mRSVP-TE SECONDARY_EXPLICIT_ROUTE Object C-type and the matching mRSVP- TE_SECONDARY_RECORD_ROUTE Object C-type is defined in this docuemnt. 2.2. Explicit Routing When a 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 <(EXPLICIT_ROUTE), (L2S_SUB_LSP)> tuple represents the L2S sub-LSP and is referred to as the sub-LSP descriptor. The absence of the ERO should be interpreted as requiring hop-by-hop routing for the sub-LSP based on the L2S sub-LSP root address field of the L2S_SUB_LSP object. 2.3. L2S Sub-LSPs and Path Messages The mechanism specified in this document allows a RD P2MP/MP2MP LSP to be signaled using one or more Path messages. Each Path message may signal one L2S sub-LSPs. Receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the LABEL object upstream towards the Sender. With a receiver-driven usage of the RSVP PATH message, the LABEL_REQUEST object carried by the PATH message is no longer mandatory, it becomes optional for receiver-driven PATH messages, as mentioned in Figure 4: ::= [ ] [ [ | ] ...] [ ] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ... ] [] Figure 4: PATH Message Extensions. The SESSION object encodes an opaque value which is used as a key to associate different PATHs to the same RD P2MP/MP2MP tree structure. Li, et al. Expires August 30, 2012 [Page 12] Internet-Draft RD Multicast RSVP-TE March , 2012 Using [RFC4875] as the base specification, with the LABEL object being added to the SENDER DESCRIPTOR object (Figure 5): ::= [ ] [ ] [ ] [ ]