Network Working Group R. Aggarwal (Juniper) Internet Draft D. Papadimitriou (Alcatel) Expiration Date: January 2005 S. Yasukawa (NTT) Editors Extensions to RSVP-TE for Point to Multipoint TE LSPs draft-raggarwa-mpls-rsvp-te-p2mp-00.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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 extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the setup of point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 1] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 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............................................. 4 3 Mechanisms.............................................. 4 3.1 P2MP Tunnels............................................ 4 3.2 P2P Sub-LSPs............................................ 5 3.2.1 Representation of a P2P sub-LSP......................... 5 3.2.2 P2P Sub-LSPs and Path Messages.......................... 5 3.3 Explicit Route Encoding................................. 6 4 Path Message Format..................................... 8 5 Path Message Processing................................. 9 5.1 Multiple Path Messages.................................. 10 5.2 Multiple P2P Sub-LSPs in One Path Message............... 10 6 RESV Message Format..................................... 12 7 RESV Message Processing................................. 13 7.1 RRO Processing.......................................... 13 7.2 Resv Message Throttling................................. 14 8 Grafting................................................ 14 9 Pruning................................................. 15 9.1 P2MP TE LSP Teardown.................................... 15 10 Refresh Reduction....................................... 15 11 Incremental State Update................................ 16 11.1 Using Refresh Reduction................................. 16 11.2 New Incremental State Procedures........................ 18 12 Error Processing........................................ 19 12.1 Branch Failure Handling................................. 20 13 Control of Branch Fate Sharing.......................... 21 14 Admin Status Change..................................... 21 15 Label Allocation on LANs with Multiple Downstream Nodes. 22 16 Make-Before-Break....................................... 22 16.1 P2MP Tree re-optimization............................... 22 16.2 Re-optimization of a subset of P2P sub-LSPs ............ 22 16.3 Control of Re-optimization.............................. 23 17 Fast Reroute............................................ 23 17.1 Facility Backpup........................................ 23 17.2 One to One Backup....................................... 24 18 Support for LSRs that are not P2MP Capable.............. 25 19 Reduction in Control Plane Processing with LSP Hierarchy 26 20 Re-merging Considerations............................... 27 21 New and Updated Message Objects......................... 27 draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 2] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 21.1 P2MP LSP SESSION Object................................. 27 21.1.1 P2MP IPv4 LSP SESSION Object............................ 28 21.1.2 P2MP IPv6 LSP SESSION Object............................ 28 21.2 Sender Template......................................... 29 21.3 P2P Sub-LSP Object...................................... 29 21.3.1 P2P IPv4 P2P Sub-LSP Object............................. 29 21.3.2 P2P IPv6 P2P Sub-LSP Object............................. 30 21.4 Filter Specification.................................... 30 21.5 SERO and SRRO........................................... 30 21.6 Sub-Group ID............................................ 30 22 IANA Considerations..................................... 31 23 Security Considerations................................. 32 24 Acknowledgements........................................ 32 25 Appendix................................................ 33 25.1 Example................................................. 33 26 References.............................................. 34 27 Authors................................................. 35 28 Intellectual Property................................... 38 29 Full Copyright Statement................................ 39 30 Acknowledgement......................................... 40 1. Introduction [RFC3209] defines a mechanism for setting up P2P TE tunnels in MPLS networks. [RFC3473] defines extensions to [RFC3209] for setting up P2P TE tunnels in GMPLS networks. However these specifications do not provide a mechanism for building P2MP TE tunnels. This document defines extensions to RSVP-TE [RFC3209] and [RFC3473] protocol to support P2MP TE LSPs satisfying the set of requirements described in [P2MP-REQ]. This document relies on the semantics of RSVP that RSVP-TE inherits for building P2MP TE LSPs. A P2MP TE LSP is comprised of multiple P2P TE sub-LSPs. These P2P sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple P2P sub-LSPs. Hence the P2P sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages. Path computation and P2MP application specific aspects are outside of the scope of this document. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 3] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 2. Terminology This document uses terminologies defined in [RFC3031], [RFC2205], [RFC3209], [RFC3473] and [P2MP-REQ]. In addition the following terms are used in this document. P2P sub-LSP: A P2MP TE LSP is constituted of one or more P2P sub- LSPs. A P2P sub-LSP refers to the label switched path from the ingress LSR to a particular egress LSR. The egress LSR is the destination of the P2P sub-LSP. 3. Mechanism A solution to the requirements specified in [P2MP-REQ] is to set up a full mesh of RSVP-TE P2P tunnels and replicate data intended, for a set of egress LSRs, at the ingress LSR. This has the obvious disadvantage of replication only at the edge of the network. This document describes a solution that optimizes data replication by allowing non-ingress nodes in the network to be replication/branch nodes. A branch node is a LSR that is capable of replicating the incoming data on one or more outgoing interfaces. The solution uses RSVP-TE in the core of the network for setting up a P2MP TE LSP. The P2MP TE LSP is set up by associating multiple P2P TE sub-LSPs and relying on data replication at branch nodes. This is described further in the following sub-sections by describing P2MP tunnels and how they relate to P2P sub-LSPs. 3.1. P2MP Tunnels The specific aspect related to P2MP TE LSP is the action required at a branch node, where data replication occurs. For instance, in the MPLS case, incoming labeled data is appropriately replicated to several outgoing interfaces with different labels. A P2MP TE tunnel comprises of one or more P2MP LSPs referred to as P2MP LSP tunnels. A P2MP TE Tunnel is identified by a P2MP SESSION object. This object contains the P2MP ID defined as a destination identifier, a tunnel ID and an extended tunnel ID. Note that the fields of this object are the same as the SESSION object (defined in [RFC 3209]) other than the fact that the destination address is a P2MP identifier and not an IP address of the egress node. This identifier encodes the P2MP ID and identifies the set of destination(s) of the P2MP LSP. A P2MP LSP tunnel is identified by the combination of the P2MP draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 4] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 SESSION object and the SENDER_TEMPLATE object. The SENDER_TEMPLATE object is the same as in [RFC3209]. The SENDER_TEMPLATE object contains the ingress LSR source address and the LSP ID. Multiple instances of the P2MP TE tunnel i.e. multiple P2MP LSP tunnels can be created, each with a different LSP ID. These P2MP LSP tunnels use different labels. If they are signaled using FF style reservation, they do not share QoS resources with each other. If they are signaled using SE style reservation, they can share QoS resources with each other. 3.2. P2P Sub-LSPs A P2MP LSP tunnel is constituted of one or more P2P sub-LSPs. The P2P sub-LSPs share the same P2MP session and have the same sender template. Label and QoS resources are shared between the P2P sub-LSPs that belong to the same P2MP LSP. The P2P sub-LSPs are identified uniquely as described below. 3.2.1. Representation of a P2P Sub-LSP Representation of a P2P sub-LSP consists of identifying the egress of the P2P sub-LSP and optionally specifying the explicit route of the P2P sub-LSP. As part of the identification of the egress of the P2P sub-LSP the destination address of the egress node is included. Identification of a P2P may also require assigning an identifier to each P2P sub-LSP as discussed in section 16. A new P2P_SUB_LSP object is used for identifying a P2P sub-LSP. The P2P_SUB_LSP object identifies a particular P2P sub-LSP belonging to the P2MP LSP. This object contains the IP destination address of the sub-LSP, i.e. the egress IP address, and it MAY contain an identifier of the sub-LSP. The need to encode a P2P sub-LSP identifier will depend on the outcome of the ongoing discussions on re-optimizing a subset of P2P sub-LSPs belonging to the same P2MP LSP (see Section 16). An EXPLICIT_ROUTE Object (ERO) or SUB_EXPLICIT_ROUTE Object (SERO) is used to specify the explicit route of a P2P sub-LSP. Each ERO or a SERO that is signaled corresponds to a particular P2P_SUB_LSP object. Details of explicit route encoding are specified in section 3.3 3.2.2. P2P Sub-LSPs and Path Messages The mechanism in this document allows a P2MP LSP to be signaled using one or more Path messages. Each Path message may signal one or more P2P sub-LSPs. Multiple Path messages are desirable as one Path message may not be large enough to fit all the P2P sub-LSPs; and they also allow separate manipulation of sub-trees of the P2MP LSP. The draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 5] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 reason for allowing a single Path message, to signal multiple P2P sub-LSPs, is to optimize the number of control messages needed to setup a P2MP LSP. 3.3. Explicit Route Encoding When a Path message signals a single P2P sub-LSP the EXPLICIT_ROUTE object encodes the path from the ingress LSR to the egress LSR. The Path message also encodes the P2P_SUB_LSP object for the P2P sub-LSP being signaled. The [] tuple represents the P2P sub-LSP. The absence of the ERO should be interpreted as requiring hop-by-hop routing for the sub-LSP. When a Path message signals multiple P2P sub-LSPs the path of the first P2P sub-LSP, from the ingress LSR to the egress LSR, is encoded in the ERO. The first P2P sub-LSP is the one that corresponds to the first P2P_SUB_LSP object in the Path message. The P2P sub-LSPs corresponding to the P2P_SUB_LSP objects that follow are termed as subsequent P2P sub-LSPs. The path of each subsequent P2P sub-LSP is encoded in a SUB_EXPLICIT_ROUTE object (SERO). The format of the SERO is the same as an ERO (as defined in [RFC3209]). Each subsequent P2P sub-LSP is represented by tuples of the form [] . There is a one to one correspondence between a P2P_SUB_LSP object and a SERO. The absence of a SERO should be interpreted as requiring hop-by-hop routing for that sub-LSP. Note that the destination address is carried in the P2P sub-LSP object. The encoding of the SERO and P2P sub-LSP object are described in detail in section 21. The motivation behind the use of the SERO object is to provide explicit route compression when a Path message signals simultaneously multiple P2P sub-LSPs. One approach to encode the explicit route of a subsequent P2P sub-LSP is to include the path from the ingress to the egress of the P2P sub-LSP. However this implies potential repetition of hops that can be learned from the ERO or explicit routes of other P2P sub-LSPs. Explicit route compression using SEROs attempts to minimize such repetition. A SERO for a particular P2P sub-LSP includes only the path from a certain branch LSR to the egress LSR if the path to that branch LSR can be derived from the ERO or other SEROs. Explicit route compression is illustrated using the following figure. A | | B draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 6] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 | | C----D----E | | | | | | F G H-------I | | | | | | J K L M | | | | | | | | N O P Q--R Figure 1. Explicit Route Compression Figure 1. shows a P2MP LSP with LSR A as the ingress LSR and six egress LSRs: (F, N, O, P, Q and R). When all the six P2P sub-LSPs are signaled in one Path message let us assume that the P2P sub-LSP to LSR F is the first P2P sub-LSP and the rest are subsequent P2P sub- LSPs. Following is one way for the ingress LSR A to encode the P2P sub-LSP explicit routes using compression: P2P sub-LSP-F: ERO = {B, E, D, C, F}, P2P_SUB_LSP Object-F P2P sub-LSP-N: SERO = {D, G, J, N}, P2P_SUB_LSP Object-N P2P sub-LSP-O: SERO = {E, H, K, O}, P2P_SUB_LSP Object-O P2P sub-LSP-P: SERO = {H, L, P}, P2P_SUB_LSP Object-P, P2P sub-LSP-Q: SERO = {H, I, M, Q}, P2P_SUB_LSP Object-Q, P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R, After LSR E processes the incoming Path message from LSR B it sends a Path message to LSR D with the P2P sub-LSP explicit routes encoded as follows: P2P sub-LSP-F: ERO = {D, C, F}, P2P_SUB_LSP Object-F P2P sub-LSP-N: SERO = {D, G, J, N}, P2P_SUB_LSP Object-N LSR E also sends a Path message to LSR H and following is one way to encode the P2P sub-LSP explicit routes using compression: P2P sub-LSP-O: ERO = {H, K, O}, P2P_SUB_LSP Object-O P2P sub-LSP-P: SERO = {H, L, P}, P2P_SUB_LSP Object-P, P2P sub-LSP-Q: SERO = {H, I, M, Q}, P2P_SUB_LSP Object-Q, P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R, After LSR H processes the incoming Path message from E it sends a Path message to LSR K, LSR L and LSR I. The encoding for the Path message to LSR K is as follows: draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 7] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 P2P sub-LSP-O: ERO = {K, O}, P2P_SUB_LSP Object-O The encoding of the Path message sent by LSR H to LSR L is as follows: P2P sub-LSP-P: ERO = {L, P}, P2P_SUB_LSP Object-P, Following is one way for LSR H to encode the P2P sub-LSP explicit routes in the Path message sent to LSR I: P2P sub-LSP-Q: ERO = {I, M, Q}, P2P_SUB_LSP Object-Q, P2P sub-LSP-R: SERO = {Q, R}, P2P_SUB_LSP Object-R, The explicit route encodings in the Path messages sent by LSRs D and Q are left as an exercise to the reader. This compression mechanism reduces the Path message size. It also reduces extra processing that can result if explicit routes are encoded from ingress to egress for each P2P sub-LSP. No assumptions are placed on the ordering of the subsequent P2P sub-LSPs and hence on the ordering of the SEROs in the Path message. All LSRs need to process the ERO corresponding to the first P2P sub-LSP. A LSR needs to process a P2P sub-LSP descriptor for a subsequent P2P sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of a SERO propagates the corresponding P2P sub-LSP downstream. Further processing details regarding the compression mechanism will be specified in the next revision of this document. 4. Path Message Format This section describes modifications made to the Path message format as specified in [RFC3209] and [RFC3473]. The Path message is enhanced to signal one or more P2P sub-LSPs. This is done by including the P2P sub-LSP descriptor list in the Path message as shown below. ::= [ ] [ [ | ] ...] [ ] [ ] [ ] [ ... ] [ ] draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 8] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 [ ] [ ] [ ... ] [P2P sub-LSP descriptor list] Following is the format of the P2P sub-LSP descriptor list. ::= | ::= [ ] Each LSR MUST use the common objects in the Path message and the P2P sub-LSP descriptors to process each P2P sub-LSP represented by the P2P sub-LSP object and the SUB/EXPLICIT_ROUTE object combination. The first P2P_SUB_LSP object's explicit route is specified by the ERO. Explicit routes of subsequent P2P sub-LSPs are specified by the corresponding SERO. A SERO corresponds to the following P2P_SUB_LSP object. The RRO in the sender descriptor contains the hops traversed by the Path message and applies to all the P2P sub-LSPs signaled in the Path message. Note that bi-directional P2MP TE LSPs are for further study. Path message processing is described in the next section. 5. Path Message Processing The ingress-LSR initiates the set up of a P2P sub-LSP to each egress- LSR that is the destination of the P2MP LSP. Each P2P sub-LSP is associated with the same P2MP LSP using a common P2MP SESSION object. Hence it can be combined with other P2P sub-LSPs to form a P2MP LSP. Another P2P sub-LSP belonging to the same instance of this P2P sub- LSP (i.e. the same P2MP LSP) can share resources with this LSP. The session corresponding to the P2MP TE tunnel is determined based on the P2MP SESSION object. Each P2P sub-LSP is identified using the P2P_SUB_LSP object. Explicit routing for the P2P sub-LSPs is done using the ERO and SEROs. As mentioned earlier it is possible to signal P2P sub-LSPs for a given P2MP LSP in one or more Path messages. And a given Path message can contain one or more P2P sub-LSPs. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 9] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 5.1. Multiple Path messages As described in section 4, or combination is used to specify a P2P sub-LSP. Multiple Path messages can be used to signal a P2MP LSP. Each Path message can signal one or more P2P sub-LSPs. If a Path message contains only one P2P sub-LSP, each LSR along the P2P sub-LSP follows [RFC3209] procedures for processing the Path message besides the P2P SUB-LSP object processing described in this document. Note that even though different P2P sub-LSPs are signaled in separate ath messages, their state can be refreshed using the same Path message that contains multiple P2P sub-LSPs. Processing of Path messages containing more than one P2P sub-LSP is described in Section 5.2. (There is NO-CONSENSUS between the authors on rest of the text in this subsection and it needs further discussion.) Some ingress LSRs MAY choose to break the P2MP tree into separate manageable P2MP trees. These trees share the same root and may share the trunk and certain branches. The scope of this management decomposition of P2MP trees is bounded by a single tree (as described above) and multiple trees with a single leaf each. Each decomposed tree is signaled with a separate Path message sent by the ingress LSR. The resulting LSPs SHOULD share labels where they share hops to prevent multiple copies of the data being sent. Where (and only where) labels are shared, the LSPs MUST share resources. In order that resource sharing can be supported using conventional mechanisms, the decomposed trees MUST be signaled using the same session. In order to distinguish between Path messages, however, some difference is required within the SENDER_TEMPLATE object. In make- before- break and other functions, multiple LSPs within a session differ in the LSP ID, however, this results in the allocation of different labels. Thus a new 'Sub-Group ID' field is introduced as part of the SENDER_TEMPLATE object to distinguish the Path messages to support decomposed trees. 5.2. Multiple P2P Sub-LSPs in one Path message P2P sub-LSP descriptor list allows the signaling of one or more P2P sub-LSPs in one Path message. It is possible to signal multiple P2P sub-LSP object and ERO/SERO combinations in a single Path message. Note that these two objects are the ones that differentiate a P2P draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 10] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 sub-LSP. Each LSR can use the common objects in the Path message and the P2P sub-LSP descriptors to process each P2P sub-LSP. All LSRs need to process, when it is present, the ERO corresponding to the first P2P sub-LSP. If one or more SEROs are present an ERO must be present. The first P2P sub-LSP is propagated in a Path message by each LSR along the explicit route specified by the ERO. A LSR needs to process a P2P sub-LSP descriptor for a subsequent P2P sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. If this is not the case the P2P sub-LSP descriptor is included in the Path message sent to LSR that is the next hop to reach the first hop in the SERO. This next hop is determined by using the ERO or other SEROs that encode the path to the SERO's first hop. If this is the case and the LSR is also the egress the P2P sub-LSP descriptor is not propagated downstream. If this is the case and the LSR is not the egress the P2P sub-LSP descriptor is included in a Path message sent to the next-hop determined from the SERO. Hence a branch LSR only propagates the relevant P2P sub-LSP descriptors on each downstream link. A P2P sub- LSP descriptor that is propagated on a downstream link only contains those P2P sub-LSPs that are routed using that link. This processing may result in a subsequent P2P sub-LSP in an incoming Path message to become the first P2P sub-LSP in an outgoing Path message. Note that if one or more SEROs contain loose hops, expansion of such loose hops may result in overflowing the Path message size. Section 12 describes how signaling of the set of P2P sub-LSPs can be split in more than one Path message. The Record Route Object (RRO) contains the hops traversed by the Path message and applies to all the P2P sub-LSPs signaled in the path message. A transit LSR appends its address in an incoming RRO and propagates it downstream. A branch LSR forms a new RRO for each of the outgoing Path messages. Each such updated RRO is formed by appending the branch LSR's address to the incoming RRO. If a LSR is unable to support a P2P sub-LSP setup, a PathErr message MUST be sent for the impacted P2P sub-LSP, and normal processing of the rest of the P2MP LSP SHOULD continue. The default behavior is that the remainder of the LSP is not impacted (that is, all other branches are allowed to set up) and the failed branches are reported in PathErr messages in which the Path_State_Reomved flag MUST NOT be set. However, the ingress LSR may set a LSP Integrity flag (see section 21.6.2) to request that if there is a setup failure on any branch the entire LSP should fail to set up. draft-raggarwa-mpls-rsvp-te-p2mp-00.txt [Page 11] Internet Draft draft-raggarwa-mpls-rsvp-te-p2mp-00.txt July 2004 6. Resv Message Format The Resv message follows the [RFC3209] and [RFC3473] format: ::= [ ] [ [ | ] ... ] [ ] [ ] [ ] [ ] [ ] [ ... ]