MPLS R. Torvi Internet-Draft K. Chan, Ed. Expires: April 22, 2010 Huawei Technologies C. Jacquenet France Telecom October 19, 2009 Receiver Driven Point-To-Multi-Point Traffic Engineered Label Switched Paths draft-chan-torvi-jacquenet-mpls-rd-p2mp-te-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Torvi, et al. Expires April 22, 2010 [Page 1] Internet-Draft Document October 2009 Abstract For content delivery services that rely upon the IP multicast transmission scheme, the distribution trees are receiver initiated. The delivery of such services over MPLS networking infrastructures may rely upon P2MP LSP tree structures that are sender initiated, with the root of the P2MP tree being at the LSR router directly connected to the sender. This document describes a mechanism that aims at establishing MPLS P2MP tree structures that are receiver initiated. This mechanism builds on the works of Point-to-MultiPoint Traffic Engineered Lable Swithched Paths (P2MP-TE LSPs). This mechanism can also be used to establish receiver driven BiDirectional P2MP TE LSPs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Signaling Protocol Extensions . . . . . . . . . . . . . . . . 6 2.1. Path Message Extensions . . . . . . . . . . . . . . . . . 6 2.2. Resv Message Extensions . . . . . . . . . . . . . . . . . 7 2.3. PathErr Message Extensions . . . . . . . . . . . . . . . . 8 2.4. ResvErr Message Extensions . . . . . . . . . . . . . . . . 8 2.5. PathTear Message Extensions . . . . . . . . . . . . . . . 9 3. Broadcast Interfaces . . . . . . . . . . . . . . . . . . . . . 9 4. Fast Re-Route Considerations . . . . . . . . . . . . . . . . . 9 5. Re-Merging and Crossover . . . . . . . . . . . . . . . . . . . 10 6. Receiver-Driven Bidirectional LSPs . . . . . . . . . . . . . . 10 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 8. Security Implications . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Torvi, et al. Expires April 22, 2010 [Page 2] Internet-Draft Document October 2009 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 the procedure to setup multipoint LSPs from sender to receiver. This document extends P2MP-TE to be used for receiver-driven P2MP-TE LSPs. This document complements P2MP-TE [RFC4875], allowing P2MP-TE LSPs to be established either from a sender or from a receiver, unidirectional or bidirectional. 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 several hundreds of thousands of IPTV receivers need to be served with the appropriate level of quality. Current source-driven P2MP LSP establishment assumes a prior knowledge of receiver(s) location for the sake of the P2MP LSP tree structure's forwarding efficiency. But the receiver's location information is not available a priori for the root MPLS router to compute and establish the relevant P2MP tree structure. Receiver-driven MPLS P2MP tree structure do not require sender to maintain/discover receiver information a priori, and their design should better reflect the receiver-specific QoS conditions, such as network access capabilities. 1.2. Terminology With the receiver-driven concept, we have re-defined the following terms: o Sender: Sender refers to the Originator (and hence) Sender of the content/payload. As in [RFC2205]. o Receiver: Receiver refers to the Receiver of the content/payload. As 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]. Torvi, et al. Expires April 22, 2010 [Page 3] Internet-Draft Document October 2009 o Path-Sender: The sender of the RSVP PATH message, with NO correlation to direction of content/payload flow. All other control messages flow direction discussed in this document will use this as the reference. o Path-Receiver: The receiver of the RSVP PATH message, with NO correlation to direction of content/payload flow. o Path-Initiator: The Path-Sender that originated the RSVP PATH message. This being different from Path-Sender because an intermediate node can be a Path-Sender, but different from the node that created and initiated the RSVP PATH message, the Path- Initiator. o Path-Terminator: The Path-Receiver that does NOT propagate the Path message. This being different from Path-Receiver because an intermediate node can be a Path-Receiver. 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: 1. Receiver initiates RSVP PATH message towards the one or more senders. We keep same convention with respect to data flows, which are opposite to control flows. 2. S2L Destinations (the leaves) are ingress routers where user data payload traffic enter the LSP. 3. RSVP P2MP PATH messages traverse from receiver to senders. 4. RSVP P2MP RESV messages traverse from sender to receiver. 5. A node receiving a RSVP RESV message is interpreted as successful resource reservation from the upstream node. 6. A node receiving a RSVP PATH message would first allocate required resources on the interface through which the RSVP PATH message is received, before sending the RSVP PATH message upstream. So that the upstream node can send traffic soon after Torvi, et al. Expires April 22, 2010 [Page 4] Internet-Draft Document October 2009 successfully reserving resources on the downstream link, on which the RSVP PATH message is received. 7. Label allocation on incoming interface is done prior to sending RSVP PATH messages upstream. The syntax details are defined in Section 2. Path Terminator/Ingress Router +---------+ | R1 | +-----+---+ _ \ \ /\ Path Message w/ Label OBJECT \ \ \ Resv \ \ \ Message \ \ \ \ \ \ _\/ \ \ Path Remerge +------------+ Creates Branch Point | R3 | +------------+ _ / \ /\ / / \ \ Path Message Resv Message / / \ \ w/ Label OBJECT / / \ \ / / \ \ \/_ / \ \ / +---+-----+ +----------+ | R5 | | R4 | +---------+ +----------+ Path Initiator/Egress Router Path Initiator LSP_ID = X LSP_ID = X Originator ID = R5 Originator ID = R4 Destination = R1 Destination = R1 Session ID = A Session ID = A Figure 1: Receiver-Driven P2MP RSVP-TE LSP Overview Torvi, et al. Expires April 22, 2010 [Page 5] Internet-Draft Document October 2009 2. Signaling Protocol Extensions Receiver-driven P2MP MPLS-TE LSP uses the RSVP-TE protocol as specified in [RFC4875], [RFC3473], and [RFC3209], but unlike what is specified in [RFC4875], receivers initiate the RSVP PATH messages toward the sender. With receiver-driven P2MP MPLS-TE LSP, the content 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 content Sender or the MPLS router it is directly attached to. All other RSVP messages flow in reference to this picture. Within this receiver-driven context, the processing of receiver- initiated P2MP RSVP-TE messages should be differentiated from the other RSVP messages. Following the method used by RSVP-TE and P2MP RSVP-TE, this document recommends the use of new SESSION C-Type as follows: Class Name = SESSION C-Type XX+0 RcvrD_P2MP_LSP_TUNNEL_IPv4 C-Type XX+1 RcvrD_P2MP_LSP_TUNNEL_IPv6 C-Type XX+2 BiDi_P2MP_LSP_TUNNEL_IPv4 C-Type XX+4 BiDi_P2MP_LSP_TUNNEL_IPv6 C-Type Where XX is a number 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. 2.1. Path Message Extensions Receiver-driven P2MP MPLS-TE LSP uses the Path message to carry the LABEL object upstream towards the Sender. With 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 indicated below: Torvi, et al. Expires April 22, 2010 [Page 6] Internet-Draft Document October 2009 ::= [ ] [ [ | ] ...] [ ] [ ] [ ] [ ] [ ... ] [ ] [ ] [ ] [ ... ] [] Using [RFC4875] as the base specification, with the LABEL object being added to the SENDER DESCRIPTOR object: ::= [ ] [ ] [ ] [ ]