Network Working Group Rahul Aggarwal (Editor) Internet Draft Juniper Networks Expiration Date: August 2004 Liming Wei George Apostolopoulos Redback Networks Kireeti Kompella Juniper Networks John Drake Calient Networks Establishing Point to Multipoint MPLS TE LSPs draft-raggarwa-mpls-p2mp-te-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. draft-raggarwa-mpls-p2mp-te-02.txt [Page 1] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 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. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. Table of Contents 1 Introduction........................................ 3 2 Terminology......................................... 3 3 Problem Statement................................... 4 4 Mechanism........................................... 4 4.1 Spe Initiated Branch LSPs........................... 5 4.2 P2MP LSP Session Object............................. 5 4.2.1 P2MP IPv4 LSP Session Object........................ 6 4.2.2 P2MP IPv6 LSP Session Object........................ 7 4.3 Sender Template..................................... 7 4.3.1 P2MP IPv4 Branch LSP Sender Template Object......... 7 4.3.2 P2MP IPv6 Branch LSP Sender Template Object......... 8 4.4 Example............................................. 8 4.4.1 Spe Initiated Branch LSPs........................... 8 5 Rpe Discovery....................................... 9 6 Label Allocation on LANs with Multiple Downstream Nodes 9 7 Signaling Considerations............................ 9 7.1 Non-Adjacent Signaling for branch LSPs.............. 10 8 Path Computation.................................... 10 9 Make-before-break and Fast Reroute.................. 11 9.1 Make-before-break................................... 11 9.2 Fast Reroute........................................ 11 9.2.1 Facility Backup..................................... 11 9.2.2 One to One Backup................................... 12 draft-raggarwa-mpls-p2mp-te-02.txt [Page 2] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 10 LSP Hierarchy Using P2P LSPs........................ 12 10.1 Reduction in Control Plane PRocessing............... 13 10.2 Support for LSRs that are not P2MP Capable.......... 13 11 IANA Considerations................................. 13 12 Security Considerations............................. 14 13 Acknowledgements.................................... 14 14 References.......................................... 14 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. 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. Branch LSP: A P2P TE LSP that is a constituent of a P2MP TE LSP. A P2MP TE LSP is constituted of one or more branch LSPs. draft-raggarwa-mpls-p2mp-te-02.txt [Page 3] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 3. Problem Statement Source 1 (S1) | PE1 | | | | P3 | | | | | 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 TE LSPs that are merged to form the P2MP TE LSP are termed as branch LSPs. The branch LSPs are initiated by the Spe. Hence the solution draft-raggarwa-mpls-p2mp-te-02.txt [Page 4] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 is 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. Section 4.1 describes the steps as per this solution for achieving the objectives outlined in section 3 when the branch LSPs are Spe initiated. 4.1. Spe Initiated Branch LSPs In this case the Spe is aware of all the Rpes interested in a given Pid. For instance the Pid may be a multicast group that all the Rpes are interested in. How the Spe discovers this is application dependent and should be specified in the application specific documents. The following are the procedures followed by the Spe to setup a P2MP LSP that is mapped to a particular Pid. a) The Spe initiates the set up of a RSVP-TE Branch LSP to each Rpe that is the destination of the P2MP LSP. Each branch LSP is associated with the same P2MP LSP. Hence it can merge with other branch LSPs to form a P2MP LSP. A new P2MP session object is introduced for this purpose. The branch LSP is signaled with shared semantics. Hence another branch 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. Each branch LSP is identified using the sender template. A new P2MP sender template is introduced. The PATH message for each branch 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. Each of the RESV messages, for a given session, received from downtstream that use the same interface to reach the upstream next hop are allocated the same label. This label is the "multicast label". 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 setup of a P2MP LSP from the Spe to the Rpes. draft-raggarwa-mpls-p2mp-te-02.txt [Page 5] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 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 conceptually simpler and also easier for an implementation to associate the semantics for P2MP MPLS with a new session object. This new session object has a similar structure as the existing point to point RSVP-TE session object. All branch LSPs share the same session object. 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 use the router ID for this purpose. It is to be noted the corresponding field in P2P RSVP-TE session object is the destination address of the session. The destination address of a P2MP branch LSP will be determined from the sender template as described below. 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. draft-raggarwa-mpls-p2mp-te-02.txt [Page 6] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 4.2.2. P2MP IPv6 LSP Session Object Class = SESSION, LSP_P2MP_TUNNEL_IPv6 C-Type = TBD This is same as the P2MP IPv4 LSP Session Object with the difference that the Spe Address is a 16 byte IPv6 address. 4.3. Sender Template The sender template identifies a particular branch LSP belonging to the P2MP LSP. 4.3.1. P2MP IPv4 Branch LSP Sender Template Object Class = SENDER_TEMPLATE, P2MP_LSP_BRANCH_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 branch LSP destination address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Branch ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 tunnel sender address IPv4 address of the branch LSP destination. LSP ID A 16-bit identifier that can be changed to allow a sender to share resources with itself. Thus multiple instances of the P2MP tunnel can be created, each with a different LSP ID. The instances can share resources with each other, but use different labels. The branch LSPs corresponding to a particular instance use the same LSP ID. Branch ID A 16-bit identifier that identifies a particular branch LSP. Different branch LSPs, with the same LSP ID, follow the label merge semantics described in section 4.1 to form a particular instance of the P2MP tunnel. draft-raggarwa-mpls-p2mp-te-02.txt [Page 7] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 4.3.2. P2MP IPv6 Branch LSP Sender Template Object Class = SENDER_TEMPLATE, P2MP_LSP_BRANCH_IPv6 C-Type = TBD This is same as the P2MP IPv4 Branch LSP Sender Template Object, with the difference that the destination address is a 16 byte IPv6 address. 4.4. Example Source 1 (S1) | PE1 | | |L5 | P3 | | | 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. 4.4.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 branch 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 the RESV messages to P3. It also creates a multicast label mapping of (L1 -> {L3, L4}). P3 allocates a label L5 and sends the RESV messages to PE1, each with label L5. It creates a label mapping of {L5 -> L1}. f) PE1 also receives a RESV from P2 with a label of L2. draft-raggarwa-mpls-p2mp-te-02.txt [Page 8] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 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 A sender on a LAN uses a different label for sending a packet to each node on the LAN that belongs to the P2MP LSP. Thus the sender performs packet replication. It may be considered desirable on a LAN to use the same label for sending a packet to multiple nodes belonging to the same P2MP LSP, to avoid packet replication. Given the relatively small number of LANs in MPLS networks, this is not seen as a practical problem. Furthermore avoiding packet replication at the sender on a LAN requires significant complexity in the control plane. Given the tradeoff we propose the use of packet replication by the sender on a LAN. 7. Signaling Considerations As mentioned earlier, in this approach, individual branch LSPs merge to form a P2MP LSP. A separate PATH message, with an explicit route object, is sent for each branch 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. RSVP refresh reduction [RSVP-RR] can be used to reduce the signaling overhead. Below we describe how non-adjacent signaling can be used to reduce PATH message processing and state on nodes that are along the commong path of two or more branch LSPs. Section 10 also describes how LSP hierarchy can be used to reduce P2MP control plane processing on transit LSRs. 7.1. Non-adjacent Signaling for Branch LSPs As described in section 4.1, a separate PATH message has to be processed for a branch LSP by each node along the explicit route of the branch LSP. This is indeed true for the first branch LSP to be setup along a given explicit route. The next branch LSP may follow the same path as the first branch LSP upto a certain branch LSR. There is no need for routers along this common path to process the draft-raggarwa-mpls-p2mp-te-02.txt [Page 9] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 PATH message corresponding to the second branch LSP. The same holds true for successive branch LSPs. The P2MP LSP ingress can send the PATH message directly to the branch LSR where the second branch LSP branches from the first one. The ERO will contain hops along the path beyond the branch LSR. Furthermore a Label Request object is not inserted in such a PATH message. This mechanism is also referred to as non-adjacent signaling. This is done by sending the PATH message directly to the branch LSR as described in [LSP-HIER]. Hence while sending the PATH message for a particular branch LSP, the P2MP ingress can determine the first branch LSR where the path of this branch LSP, branches from the existing P2MP LSP. It can then use non- adjacent signaling to send the PATH message to the branch LSR. The branch LSR in turn, will send the RESV message directly to the ingress. Hence with respect to figure 2, assume that PE1 sets up the branch LSP to PE3 first followed by the branch LSP to PE4. In this case the PATH message for the branch LSP to PE4, can be sent directly to P1, bypassing P3. This mechanism reduces PATH message processing and state along nodes that are on the common path of two or more branch LSPs. 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 branch 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. 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 branch LSPs are signaled with a different LSP ID and follow the normal RSVP- draft-raggarwa-mpls-p2mp-te-02.txt [Page 10] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 TE make-before-break procedure. Thus a new instance of the P2MP tunnel is established. The ingress can, after moving traffic to the new instance, tear down the previous P2MP tunnel instance. 2. Re-optimization of one or more branch LSPs. In this case each re- optimized branch LSP is signaled with a different branch ID and hence a new branch LSP is established. Once the new setup is complete, the old branch LSP can be torn down. 3. A link failure in the network. In this case all the branch LSPs that are effected by the link failure are re-routed. Local repair is initiated to protect the constituent branch LSPs. 9.2. Fast Reroute [RSVP-FR] extensions can be used to perform fast reroute for the mechanism described in this document. 9.2.1. Facility Backup Facility backup as described in [RSVP-FR] can be used to protect a set of branch LSPs, potentially belonging to different P2MP LSPs. If link protection is desired, a bypass tunnel is used to protect the link between the PLR and next-hop. Thus all branch LSPs that use the link can be protected in the event of link failure. Note that all such branch LSPs belonging to a particular instance of a P2MP tunnel will share the same outgoing label on the link between the PLR and the next-hop. This is the P2MP LSP label on the link. Label stacking is used to send packets for each P2MP LSP in the bypass tunnel. The inner label is the P2MP LSP label allocated by the nhop. During failure PATH messages for each branch LSP, that is effected, will be sent to the MP, by the PLR. It is recommended that the PLR use the sender template specific method to identify these PATH messages. Hence the PLR will set the branch LSP destination address to a local PLR address. The MP will determine the protected branch LSP using the LSP-id and the branch-id. If node protection is desired, the bypass tunnel must intersect the path of the protected branch LSPs somewhere downstream of the PLR. This constrains the set of branch LSPs being backed-up via that bypass tunnel to those that pass through a common downstream MP. The MP will allocate the same label to all such branch LSPs belonging to a particular instance of a P2MP tunnel. This will be the inner label used during label stacking. draft-raggarwa-mpls-p2mp-te-02.txt [Page 11] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 9.2.2. One to One Backup One to one backup as described in [RSVP-FR] can be used to protect a particular branch LSP against link and next-hop failure. Protection may be used for one or more branch LSPs between the PLR and the next- hop. All the branch LSPs corresponding to the same instance of the P2MP tunnel, between the PLR and the next-hop share the same P2MP LSP label. All or some of these branch LSPs may be protected. The detour branch LSPs may or may not share labels, depending on the detour path. Thus the set of outgoing labels and next-hops for a P2MP LSP that was using a single next-hop and label between the PLR and next- hop before protection, may change once protection is triggerred. Its is recommended that the path specific method be used to identify a backup branch LSP. Hence the DETOUR object will be inserted in the backup PATH message. A backup branch LSP MUST be treated as belonging to a different P2MP tunnel instance than the one specified by the LSP-id. Furthermore multiple backup branch LSPs MUST be treated as part of the same P2MP tunnel instance if they have the same LSP-id and the same DETOUR objects. Note that as specified in section 4.3 branch LSPs between different P2MP tunnel instances use different labels. 10. LSP Hierarchy Using P2P LSPs It is possible to take advantage of LSP hierarchy [LSP-HIER] while building P2MP LSPs. One mechanism to do this is the use of P2P LSPs as links of the P2MP LSP. A P2P LSP can be advertised as a Forwarding Adjacency (FA) by the ingress of the P2P LSP. The FA can then be used by the headend of the P2MP LSP while computing the path of each branch LSP. If a FA is used by a branch LSP the corresponding ERO contains a list of objects upto the FA head-end followed by a loose object with the address of the FA tail-end. The FA head-end on receiving the branch LSP PATH message determines the FA from its Traffic Engineering Database (TED) and tunnels the PATH message over the FA. The FA tail-end on receiving the PATH message follows procedures specified in previous sections. The FA tail-end sends a RESV message to the FA head-end with a P2MP LSP label. The RESV message is sent using the procedures in [LSP-HIER]. For example in Figure 2, PE1 can setup a P2P LSP to P1 and use that as a FA. The PATH messages for PE3 and PE4 can now be tunneled over the FA. Thus P3 is not aware of the P2MP LSP and does not process the P2MP control messages. LSP hierearchy as described above has several advantages, some of which are discussed below. draft-raggarwa-mpls-p2mp-te-02.txt [Page 12] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 10.1. Reduction in Control Plane Processing Transit LSRs along a FA, being used by a P2MP LSP, do not process control plane messages associated with the P2MP LSP. Infact they are not aware of these messages as they are tunneled over the FA. This reduces the amount of control plane processing required on these transit LSRs. Hence the use of P2P LSPs as FAs can increase the overall control plane scalability while setting up P2MP LSPs. 10.2. Support for LSRs that are not P2MP Capable Its conceivable that some LSRs, in a network deploying P2MP MPLS TE, may not be capable of P2MP MPLS. The use of FAs allows to build P2MP LSPs in such an environment. As mentioned above transit LSRs along a FA do not process control plane messages associated with a P2MP LSP. Futhermore these LSRs also do not need to have P2MP MPLS data plane capability as they only need to process MPLS data plane packets belonging to the P2P LSP that is being used as a FA. Hence these LSRs do not need to support P2MP MPLS. It is to be noted that such LSRs can not act as branch points along the P2MP LSP. 11. IANA Considerations This document requires the use of a RSVP-TE P2MP session object and a RSVP-TE P2MP branch LSP sender template object. The C-Types for these objects have to be assigned by IANA. 12. Security Considerations This document does not introduce any new security issues. The security issues identified in [RSVP-TE] are still relevant. 13. Acknowledgements We would like to thank George Swallow for his contribution and suggestions. Thanks to Yakov Rekhter, Der-Hwa Gan, Arthi Ayyanger and Nischal Sheth for their suggestions and comments. Thanks also to Dino Farninacci for his comments. draft-raggarwa-mpls-p2mp-te-02.txt [Page 13] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 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. [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. [LSP-HIER] K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt. Author Information Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Liming Wei Redback Networks 350 Holger Way San Jose, CA 95134 Email: lwei@redback.com draft-raggarwa-mpls-p2mp-te-02.txt [Page 14] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 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 Email: kireeti@juniper.net John Drake Calient Networks Email: jdrake@calient.net IPR Notice The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. draft-raggarwa-mpls-p2mp-te-02.txt [Page 15] Internet Draft draft-raggarwa-mpls-p2mp-te-02.txt January 2004 Full Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. draft-raggarwa-mpls-p2mp-te-02.txt [Page 16]