Network Working Group Rahul Aggarwal Internet Draft Liming Wei Expiration Date: December 2003 George Apostolopoulos Redback Networks Kireeti Kompella Juniper Networks May, 2003. Establishing Point to Multipoint MPLS TE LSPs draft-raggarwa-mpls-p2mp-te-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026, except that the right to produce derivative works is not granted. 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. Abstract This document describes a solution for point to multipoint (P2MP) Traffic Engineering (TE). The objective is to optimize packet replication and minimize state and intelligence in the core of the network, while performing P2MP TE. The solution relies on RSVP-TE in the core of the network. It is based on setting up a P2MP LSP by merging P2P LSPs in the network. The setup of P2P LSPs is source intiated. Simple enhancements are made to RSVP-TE to facilitate the set up of a P2MP TE LSP. There is no need to run a multicast routing protocol in the network core. There can be various applications for P2MP TE LSPs such as multicast. Specification of how such applications will use a P2MP LSP is outside the scope of this document. draft-raggarwa-mpls-p2mp-te-00.txt [Page 1] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 Table of Contents 1 Introduction........................................ 2 2 Terminology......................................... 2 3 Problem Statement................................... 3 4 Mechanism........................................... 3 4.1 Spe Initiated P2P LSPs.............................. 4 4.2 P2MP LSP Session Object............................. 5 4.2.1 P2MP IPv4 LSP Session Object........................ 5 4.2.2 P2MP IPv6 LSP Session Object........................ 5 4.3 Example............................................. 6 4.3.1 Spe Initiated P2P LSPs.............................. 7 5 Rpe Discovery....................................... 7 6 Label Allocation on LANs with Multiple Downstream Nodes 7 7 Signaling Considerations............................ 8 8 Path Computation.................................... 8 9 Make-before-break and Fast Reroute.................. 8 9.1 Make-before-break................................... 8 9.2 Fast Reroute........................................ 9 10 IANA Considerations................................. 9 11 Security Considerations............................. 9 12 Intellectual Property Considerations................ 9 13 Acknowledgements.................................... 9 14 References.......................................... 9 15 Author Information.................................. 10 1. Introduction [RSVP-TE] defines a mechanism for setting up point to point (P2P) TE tunnels. It does not provide a mechanism for building point to multipoint TE tunnels. However [RSVP-TE] is built on [RSVP] which does have mechanisms for supporting multiple receivers for the same session. This document describes how RSVP-TE can be used for P2MP TE. It relies on the semantics of RSVP that RSVP-TE inherits for building a P2MP TE tree. P2P TE LSPs are set up between the source and receiver PEs. These P2P TE LSPs are appropriately merged by the network using RSVP semantics to result in a P2MP TE LSP. The P2P LSPs are initiated using RSVP-TE by the PE attached to the source. MPLS label FIB is enhanced to support multicast of MPLS packets at the nodes where the P2P LSPs merge. 2. Terminology Source-PE (Spe): This is the PE that is connected to the traffic source. For instance this may be the multicast source. Receiver-PE (Rpe): This is the PE that is connected to one or more receivers. For instance these may be multicast receivers. draft-raggarwa-mpls-p2mp-te-00.txt [Page 2] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 P2MP-ID (Pid): This is the ID that can be used to map a set of Rpes to a P2MP tree for a particular application. Its usage is application dependent. 3. Problem Statement Source 1 (S1) | PE1 | | | | R2----PE3--P1 P2---PE2--Receiver 1 (R1) | PE4----R3 | | R4 Figure 1. The above figure shows PE1, PE2, PE3 and PE4. PE1 is the source-PE; PE2, PE3 and PE4 are receiver-PEs. The following are the objectives that we wish to achieve: a) Set up a P2MP TE LSP from PE1 to PE2, PE3 and PE4, where each Rpe is free to choose the QoS it desires. b) Follow RSVP-TE procedures with as little enhancements as possible while setting the P2MP LSP. c) Map a P2MP LSP to a Spe and a Pid, with the flexibility to setup multiple LSPs for the same Pid. 4. Mechanism It is desirable to achieve the objectives described in section 3 without running a multicast routing protocol in the network core. An obvious solution is to set up a full mesh of RSVP-TE P2P tunnels and replicate a packet intended, for a set of Rpes, at the Spe. This has the obvious disadvantage of replication only at the edge of the network. This can be improved by creating a network topology with RSVP-TE mesh in a certain part of the core surrounded by routers running a multicast routing protocol. However even this is not optimal and adds significant complexity. We describe a solution that uses RSVP-TE in the core of the network for setting up a P2MP TE LSP. The P2MP TE LSP is set up by merging individual P2P TE LSPs and relying on MPLS label multicast. The P2P LSPs are initiated by the Spe. Hence its as efficent as trees setup by a multicast routing protocol in an IP environment. This is achieved without burdening RSVP-TE with any of the mechanisms of a multicast routing protocol. draft-raggarwa-mpls-p2mp-te-00.txt [Page 3] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 Section 4.1 describes the steps as per this solution for achieving the objectives outlined in section 3 when the P2P LSPs are Spe initiated. It may be possible to have a mechanism where the P2P LSPs are Rpe initiated. Such a mechanism is for further study. 4.1. Spe Initiated P2P LSPs In this case the Spe is aware of all the Rpes interested in a given Pid. How the Spe discovers this is application dependent and should be specified in the application specific documents. a) The Spe initiates the set up of a RSVP-TE P2P LSP to each Rpe for a given Pid. Each P2P LSP is associated with the Pid. Hence it can merge with other P2P LSPs to form a P2MP LSP. A new P2MP session object is introduced for this purpose. The P2P LSP can be signaled with shared semantics. Hence another P2P LSP belonging to the same session can share resources with this LSP. The session is determined based on the new RSVP-TE P2MP session object. The PATH message for each P2P TE LSP carries the explicit route object. b) At each hop the RSVP-TE PATH message is processed using normal RSVP-TE procedures. c) The Rpe follows normal RSVP procedures while originating a RESV message. It can indicate a different QoS in the RESV from that received in the PATH message as long as the new QoS is lower. The RESV message carries the label allocated by the Rpe. d) A subsequent node allocates its own label and passes it in the RESV message. This label is the "multicast label" if that node is merging multiple RESV messages into one when sending the RESV upstream. This will happen if each of the RESVs, for a given session, received from downstream are using the same interface to reach the upstream next hop. This multicast label is associated by that node with all the labels received from downstream RESV messages for that session. A multicast label mapping is appropriately created at each node. Hence this results in the set up of a P2MP LSP from the Spe to the Rpes. It is to be noted that RSVP semantics preserve each record route object (RRO) associated with individual RESV messages when these RESV messages are merged as described in (d) above. The flow descriptor in the merged RESV messages contains the RRO list for SE style reservation. draft-raggarwa-mpls-p2mp-te-00.txt [Page 4] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 4.2. P2MP LSP Session Object A new P2MP LSP session object is defined in RSVP-TE. It is possible to simply use the existing RSVP-TE sssion object and indicate a P2MP LSP using session attributes. However its cleaner and may be easier for an implementation to associate the semantics for multicast with a new session object. This new session object format is the same as the existing session object with a new object type and different semantics. 4.2.1. P2MP IPv4 LSP Session Object Class = SESSION, LSP_P2MP_TUNNEL_IPv4 C-Type = TBD 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Spe Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Spe Address IPv4 address of the Spe. An implementation may have to ensure that this address is not used as the destination address. Infact the destination address will have to be determined from the explicit route. Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. P2MP ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. It encodes the Pid. 4.2.2. P2MP IPv6 LSP Session Object Class = SESSION, LSP_P2MP_TUNNEL_IPv6 C-Type = TBD draft-raggarwa-mpls-p2mp-te-00.txt [Page 5] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Spe Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Spe Address IPv4 address of the Spe. An implementation may have to ensure that this address is not used as the destination address. Infact the destination address will have to be determined from the explicit route. Tunnel ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. P2MP ID A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. It encodes the Pid. 4.3. Example Source 1 (S1) | PE1 | | L3 |L1 |L2 R2----PE3--P1 P2---PE2--Receiver 1 (R1) | L4 PE4----R3 | | R4 Figure 2. The mechanism is explained using Figure 2. PE1 is the Spe. PE3 and PE4 are Rpes in VPN1. draft-raggarwa-mpls-p2mp-te-00.txt [Page 6] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 4.3.1 Spe Intiated P2P LSPs a) PE1 learns that PE2, PE3 and PE4 are interested in joining a P2MP tree with a Pid of VPN1. PE1 may learn of the Rpes at different points, though in this example we will assume that it learns the Rpes at the same time. b) PE1 computes the P2P paths to reach PE2, PE3 and PE4. These paths are computed to share the same links where possible as they belong to the same session. c) PE1 sends a PATH message for each P2P LSP. d) PE2, PE3 and PE4 respond with a RESV message. e) P1 receives a RESV message from PE3 with label L3 and from PE4 with label L4. It allocates a label L1 and sends a RESV message to PE1. It also creates a multicast label mapping of (L1 -> {L3, L4}). f) PE1 also receives a RESV from P2 with a label of L2. 5. Rpe Discovery For Spe intiated P2P LSPs, the Spe has to discover all the Rpes interested in a given P2MP tree i.e. a particular Pid. Such discovery is application depenedent and should be specified in the application specific documents. 6. Label Allocation on LANs with Multiple Downstream Nodes It is desirable on a LAN to use the same label for sending a packet to multiple nodes belonging to the same P2MP LSP. As a result only one copy of a packet needs to be transimitted by a sender on a LAN. Achieving this requires certain modifications to the label allocation procedure on a LAN. For Spe initiated P2MP LSP, all routers on a LAN will snoop P2MP RESV messages. Hence the router alert option will be set on P2MP RESV messages sent on a LAN. When a router on a LAN 'snoops' RESV messages from other routers, it should use the label advertised in the snooped RESV, for its own RESV, if the following conditions are met: a) The snooped RESV belongs to the same session AND b) The snooped RESV's source address is lower than the source address of the RESV this router is originating AND c) The sooped RESV's next-hop is same as the next-hop to which this router is sending the RESV When multiple routers send RESVs at about the same time, the upstream router on the LAN will treat these as multiple P2P LSPs for a transient duration. Eventually all the routers will converge to announcing the same label and the upstream router will send out only one packet. Procedures in [RSVP-RR] can be used to ensure reliable delivery of RESV messages. draft-raggarwa-mpls-p2mp-te-00.txt [Page 7] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 Partitioning the label space amongst routers on a LAN is another potential means of achieving the above. This approach will be discussed in detail in a later revision. 7. Signaling Considerations As mentioned earlier, in this approach, individual P2P LSPs merge to form a P2MP LSP. A separate PATH message, with an explicit route object, is sent for each P2P LSP. Hence RSVP-TE is not burdened with P2MP explicit routes. This has the advantage of keeping RSVP-TE procedures as close as possible to existing TE procedures for P2P LSPs. It reduces complexity and makes it easier to enhance existing and deployed RSVP-TE implementations to support P2MP TE LSPs. It does increase the number of PATH messages sent. RSVP refresh reduction [RSVP-RR] can be used to reduce this overhead. 8. Path Computation A Spe when setting a P2MP LSP has a view of the entire network topology and can accordingly compute the path for each P2P LSP, sharing links where possible with other P2P LSPs belonging to the P2MP LSP. This can also be described as a P2MP CSPF, where a path to a Rpe is set up as a P2P LSP. Details of such a CSPF algorithm are beyond the scope of this document. 9. Make-before-break and Fast Reroute The building blocks for the mechanism described in this document are P2P LSPs that constitute the P2MP LSP. A big advantage of this is that Rpes can be added/removed very flexibly without disturbing rest of the network. This advantage also carries over to make-before-break and fast reroute. In the following discussion a P2P LSP refers to the constituent P2P LSP of a P2MP LSP as described in this document. 9.1. Make before break Let's consider the following cases where make-before-break is needed: 1. P2MP Tree re-optimization at the Spe. In this case all the P2P LSPs that need re-routing are signaled with a different LSP ID and follow the normal RSVP-TE make-before-break procedure. Infact the re-optimization can be triggerred only for a specific P2P LSP. 2. A link failure in the network. In this case all the P2P LSPs that are effected by the link failure are re-routed. Local repair is initiated to protect the constituent P2P LSPs. The granularity of the re-route operation is an individual constituent P2P LSP. As a result the existing make-before-break procedures don't change and the re-route can be done quite flexibly. draft-raggarwa-mpls-p2mp-te-00.txt [Page 8] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 9.2. Fast Reroute [RSVP-FR] extensions can be used to perform fast reroute for the mechanism described in this document. Details will be specified in a later revision. 10. IANA Considerations This document requires the use of a RSVP-TE P2MP session object. The C-Types for this object have to be assigned by IANA. 11. Security Considerations This document does not introduce any new security issues. The security issues identified in [RSVP-TE] are still relevant. 12. Intellectual Property Considerations Redback Networks, Inc. may seek patent protection on some of the technology described in this Internet-Draft. If technology in this document is adopted as a standard, Redback Networks agrees to license, on reasonable and non-discriminatory terms, any patent rights it obtains covering such technology to the extent necessary to comply with the standard. 13. Acknowledgements Many thanks to Yakov Rekhter and Dino Farninacci for their comments. 14. References [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001 [RFC] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [GMPLS] Lou Berger, et al., "Generalized MPLS - Signaling Functional Description", draft-ietf-mpls-generalized-signaling-08.txt, April 2002 [G-RSVP] L. Berger, "Generalized MPLS Signaling - RSVP-TE Extensions", draft-ietf-mpls-generalized-rsvp-te-09.txt, September 2002. draft-raggarwa-mpls-p2mp-te-00.txt [Page 9] Internet Draft draft-raggarwa-mpls-p2mp-te-00.txt May 2003 [RSVP-RR] L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [RSVP-FR] P. Pan, D. Gan, G. Swallow, J. P. Vasseur, D. Cooper, A. Atlas, M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt. 15. Author Information Rahul Aggarwal Redback Networks 350 Holger Way San Jose, CA 95134 Email: rahul@redback.com Liming Wei Redback Networks 350 Holger Way San Jose, CA 95134 Email: lwei@redback.com George Apostolopoulos Redback Networks 350 Holger Way San Jose, CA 95134 Email: georgeap@redback.com Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 kireeti@juniper.net draft-raggarwa-mpls-p2mp-te-00.txt [Page 10]