MPLS Working Group L. Jin Internet-Draft ZTE Corporation Intended status: Standards Track F. Jounay Expires: November 8, 2012 France Telecom M. Bhatia Alcatel-Lucent May 7, 2012 Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Hub and Spoke Multipoint Label Switched Paths (LSPs) draft-jjb-mpls-rsvp-te-hsmp-lsp-01 Abstract In Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) environment, the RSVP-TE based Point-to-Multipoint (P2MP) LSP allows traffic to transmit from root to leaf node, but there is no co-routed reverse path for traffic from leaf to root node. This draft introduces a Hub and Spoke Multipoint (HSMP) LSP, which allows traffic from both the root to the leaves through a P2MP LSP and also the leaves to the root along a co-routed reverse path. 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 November 8, 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 Jin, et al. Expires November 8, 2012 [Page 1] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 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 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. Table of Contents 1. Application . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Time Synchronization . . . . . . . . . . . . . . . . . . . 3 1.2. P2MP Pseudowire based L2VPNs (VPMS and VPLS) . . . . . . . 4 2. Comparing Hub-Spoke MP LSP with P2MP and Unidirectional Reverse LSP . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Number of Path and Resv State Blocks . . . . . . . . . . . 5 2.2. Hardware Programming and Label Utilization . . . . . . . . 6 2.3. RSVP Control Traffic . . . . . . . . . . . . . . . . . . . 7 3. Setting up a Hub and Spoke Multipoint LSP with RSVP-TE . . . . 7 3.1. Hub and Spoke Multipoint LSP and Path Messages . . . . . . 7 3.2. Procedures for Hub and Spoke Multipoint LSP . . . . . . . 7 3.3. Symmetric Bandwidth Allocation . . . . . . . . . . . . . . 8 3.4. Asymmetric bandwidth allocation . . . . . . . . . . . . . 8 3.4.1. Packet Format . . . . . . . . . . . . . . . . . . . . 9 3.4.2. UPSTREAM_FLOWSPEC processing . . . . . . . . . . . . . 10 3.4.3. UPSTREAM_TSPEC and UPSTREAM_ADSPEC processing . . . . 10 4. Setting up the Hub Spoke Multipoint LSP . . . . . . . . . . . 10 5. Grafting . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Pruning . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Refresh Reduction . . . . . . . . . . . . . . . . . . . . . . 13 8. Fast Reroute . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix 1. Appendix: Alternate Mechanism to set up a reverse LSP . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Jin, et al. Expires November 8, 2012 [Page 2] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 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 RFC2119 [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]. 1. Application The proposed technique targets one-to-many applications that require reverse one-to-one traffic flow (thus many one-to-one in the reverse direction). There are a few applications that could use such kind of Resource Reservation Protocol - Traffic Engineering (RSVP-TE) based Hub and Spoke Multipoint LSPs. 1.1. Time Synchronization The delivery of time synchronization to end equipments, such as base stations, can be achieved using a time protocol as [IEEE] (also known as PTP). This protocol defines Transparent Clock (TC) function, which can be used in transport nodes to improve the accuracy of time synchronization. Two types of TCs exist in [IEEE]: End-to-end Transparent Clock (E2E TC) and Peer-to-peer Transparent Clock (P2P TC). P2P TCs assume that the link delays between the different nodes are calculated Assuming that a chain of P2P TCs is used between a PTP master and a PTP slave, time synchronization can be delivered to the PTP slave by sending timestamps only in the direction master to slave (one way mode), via PTP Sync messages. This is possible because of the link delay calculation performed locally by each node, which enables it to calculate the propagation delay over the path. This scenario permits that the same PTP Sync messages would be sent by the PTP master to all the PTP slaves. In this scenario (chain of P2P TCs), the PTP slave might have to send also messages (not carrying timestamps) back to the PTP master in some cases. For instance, PTP Signaling messages could be sent back to the PTP master. These PTP Signaling messages are not intended to be received by the other PTP slaves. By using Point-to-Multipoint (P2MP) technology to transmit PTP Sync messages will greatly improve the bandwidth usage for above applications. This will also be useful for monitoring performance Jin, et al. Expires November 8, 2012 [Page 3] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 metrics for two-way delay and related metrics such as delay variation and loopback measurement. Current RSVP-TE based Point-to-Multipoint LSP mechanism only provides unidirectional path from the root to the leaf nodes, which cannot fulfill the above new requirement (i.e. need for a reverse path for the PTP Signaling messages). This draft attempts to solve this problem. RSVP-TE based Hub and Spoke P2MP LSP described in this draft provides a co-routed reverse path from the leaf to the root based on current unidirectional Point- to-Multipoint LSP. 1.2. P2MP Pseudowire based L2VPNs (VPMS and VPLS) Point-to-Multipoint (P2MP) Pseudowires (PW) described in [I-D.ietf-pwe3-p2mp-pw] requires an additional reverse LSP to be set up from the leaf node (referred as egress PE) to root node (referred as ingress PE). Instead, if HSMP LSP is used to multiplex P2MP PW, the reverse path can also be multiplexed to HSMP upstream path to avoid setting up an independent reverse path. In that case, the operational cost will be reduced for maintaining only one HSMP LSP, instead of P2MP LSP and n (number of leaf nodes) P2P reverse LSPs The VPMS defined in [I-D.ietf-l2vpn-vpms-frmwk-requirements] requires reverse path from the leaf to the root node. The P2MP PW multiplexed to HSMP LSP can provide VPMS with reverse path, without introducing independent reverse paths from each leaf to the root. The P2MP PW multiplexed to HSMP LSP can also be used for VPLS [RFC4672], which will reduce the overall broadcast/multicast utilization for VPLS. In current VPLS implementations with a full mesh of P2P LSPs between PEs, broadcast, unknown and multicast (BUM) traffic is efficiently distributed over the physical links between Provider (P) and Provider Edge (PE) routers. [I-D.ietf-l2vpn-vpls-mcast] and [I-D.ietf-l2vpn-ldp-vpls-broadcast-exten] leverages this constraint by introducing the usage of P2MP PW and/or P2MP LSP. But a specific P2P PW over P2P LSP is still needed for unicast traffic between the PEs. In the VPLS implementation scenario with P2MP PW multiplexed to HSMP LSPs, each PE signals a P2MP PW with itself as a root to all other PEs in the VPLS. Thereafter, all BUM traffic from this PE will use this P2MP PW. Unicast (learnt) traffic from a particular PE (e.g. PE1) to another PE (e.g. PE2) will be sent from leaf to root using the reverse path of P2MP PW where PE2 is the root. This simplifies the VPLS implementation by reducing (a) link utilization for the BUM traffic and (b) the total number of LSPs Jin, et al. Expires November 8, 2012 [Page 4] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 maintained by each PE (i.e. instead of requiring a full mesh of LSPs, PEs now only require one HSMP LSP). It also helps in avoiding the unnecessary MAC learning that happens on the hub PE routers in case of H-VPLS. 2. Comparing Hub-Spoke MP LSP with P2MP and Unidirectional Reverse LSP An HSMP LSP provides a Point-to-Multipoint reachability from the root node to the leaf nodes and a unicast reachability from all the leaf nodes back to the root node. An obvious question that comes up is that how is this better than setting up a P2MP LSP from a root node and Unidirectional reverse LSPs back from the leaves to the root node. This section compares the two mechanisms and demonstrates how establishing one HSMP LSP is better than establishing a P2MP LSP with reverse LSPs from the leaves back to the root. Consider the topology as shown in Figure 1. Router A wants to establish a Point-to-Multipoint connectivity to Routers E, F, G and H and also wants a Unicast path back from these routers to itself. There are two ways to accomplish this. In the first, we set up a HSMP LSP between A, E, F, G and H. In the second, we set up a P2MP LSP between A, E, F, G and H and establish regular LSPs back from these routers to A. A | B / \ C D / \ / \ E F G H Figure 1 2.1. Number of Path and Resv State Blocks When an RSVP-capable router receives an initial Path message, it creates a path state block (PSB) for that particular session. Each PSB consists of parameters derived from the received Path message such as SESSION, SENDER_TEMPLATE, SENDER_TSPEC, RSVP_HOP objects, and the outgoing interface provided by the IGP routing. Similarly, as a Resv message travels upstream toward the sender, it creates a reservation state block (RSB) in each RSVP-capable node along the way which stores information derived from the objects in the received Resv message, such as SESSION, RSVP_HOP, FLOWSPEC, FILTERSPEC, STYLE, etc objects. The PSB and the RSB need to be periodically refreshed by the Path and the Resv messages. Jin, et al. Expires November 8, 2012 [Page 5] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 In case of HSMP LSP, the number of PSBs and the RSBs is the same as that for establishing a single P2MP LSP and is a function of how the P2MP LSP is signaled. It is equal to the number of S2L sub-LSPs of the P2MP LSP if each S2L sub-lsp is signaled independently. It is one, if an aggregated mode is used where multiple sub-lsps of the P2MP LSP are signaled togethar. In the second case routers need to maintain this state for the P2MP LSP and all the Unidirectional LSPs that go via it. Lets look at the state that branch node B needs to maintain. In case of HSMP LSP it is the same as a P2MP LSP. In the other approach it needs to maintain state for the following LSPs: 1. P2MP LSP from A and E, F, G and H 2. Reverse LSP ECBA 3. Reverse LSP FCBA 4. Reverse LSP GDBA 5. Reverse LSP HDBA We can thus clearly see that the amount of state that routers need to maintain in the second approach is much more than the HSMP LSP. It becomes all the more pronounced when the P2MP LSP is signalled using the aggregated approach described in [RFC4875] where a single Path and Resv message is used to signal the entire P2MP LSP. In such cases the amount of state that such branch nodes need to maintain increase linearly with the leaf nodes that get added to the P2MP LSP. 2.2. Hardware Programming and Label Utilization In the HSMP LSP the LSR B advertises the same (upstream) label to C and D, thus consumes only one label and needs to only program one entry in the ILM table. In the second approach, LSR B needs to advertise two different labels to LSRs C and D and will thus consume 2 ILM entries in HW. We can clearly see that the number of labels consumed in the second approach will increase linearly with the amount of branching that happens on that LSR. It will further aggravate as the number of P2MP LSPs increase. Jin, et al. Expires November 8, 2012 [Page 6] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 2.3. RSVP Control Traffic In the second approach, LSR B will have RSVP control traffic for the P2MP LSP and all the Unidirectional reverse LSPs that pass through it. In case of HSMP LSR B will only have the RSVP traffic for the P2MP LSP. 3. Setting up a Hub and Spoke Multipoint LSP with RSVP-TE The Hub and Spoke Multipoint LSP comprises of one downstream unidirectional P2MP LSP from ingress LSR to each of egress LSR, and a co-routed upstream path from each of egress LSR to ingress LSR. [RFC3473] describes a point-to-point bidirectional LSP mechanism for the GMPLS architecture, where a bidirectional LSP setup is indicated by the presence of an Upstream_Label object in the Path message. The Upstream_Label object has the same format as the generalized label, and uses Class-Number 35 (of form 0bbbbbbb) and the C-Type of the label being used. Hub and Spoke Multipoint LSP describe in this draft will use similar mechanism, and reuse the Upstream_Label object defined in [RFC3473]. Note: the downstream label assignment is still applied, and upstream direction is based on the h&s topology (hub = upstream, spoke= downstream), rather on forwarding direction. 3.1. Hub and Spoke Multipoint LSP and Path Messages [RFC4875] allows a P2MP LSP to be signaled using one or more Path messages . Each Path message may signal one or more source to leaf (S2L) sub-LSPs. This document assumes that a unique Path message is being used to signal each individual sub-LSP of the HSMP LSP. Later versions of this document can describe mechanisms to use a single Path message to describe each component sub LSP of the HSMP LSP. 3.2. Procedures for Hub and Spoke Multipoint LSP The process of establishing a Hub and Spoke Multipoint LSP follows the establishment of a unidirectional P2MP LSP define in [RFC4875] with some additions. To support Hub and Spoke Multipoint LSPs an Upstream_Label object is added to the Path message. The Upstream_Label object MUST indicate a label that is valid for forwarding at the time the Path message is sent. When a Path message containing an Upstream_Label object is received, the receiver first verifies that the upstream label is acceptable. If the label is not acceptable, the receiver MUST issue a PathErr message with a "Routing problem/Unacceptable label value" indication. The generated PathErr message MAY include an Acceptable Label Set Jin, et al. Expires November 8, 2012 [Page 7] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 defined in [RFC3473] section 4.1. The transit node must also allocate one label for the co-routed upstream path before propagating the Path message to all downstream nodes. If a transit node is unable to allocate a label or internal resources, then it MUST issue a PathErr message with a "Routing problem/MPLS label allocation failure" indication. With regards to the co-routed return path from the leafs to the root, the forwarding table on transit node will have one incoming labels allocated for all of the outgoing interfaces, and one outgoing label received from Upstream_Label object in Path message sent by upstream node. That means the traffic from different egress LSRs will be merged at each transit node, and will be sent together to upstream node, see section 3.3 for more detail of bandwidth guarantee in this case. The Path messages sending downstream with same [P2MP ID, Tunnel ID, Extended Tunnel ID] tuple as part of the SESSION object and the [Tunnel Sender Address, LSP ID] tuple as part of the SENDER_TEMPLATE object, but may different [Sub-Group Originator ID, Sub-Group ID] MUST use same allocated label value for Upstream_Label object. Leaf nodes process Path messages as usual, with the exception that the upstream label should be used to transport data traffic associated with the Hub and Spoke Multipoint LSP upstream towards the root node. When a Hub and Spoke Multipoint LSP is removed, both upstream and downstream labels are invalidated and it is no longer valid to send data using the associated labels. 3.3. Symmetric Bandwidth Allocation The bandwidth allocation for upstream path from leaf to root could be same as the downstream path from root to leaf node [RFC3473], and the bandwidth will be guarantee only when there is no traffic merging happened on transit node. If there are cases where leaf nodes send traffic to root node at the same time which may cause traffic to be merged on one physical link at transit node, then traffic overload may happen on these links. 3.4. Asymmetric bandwidth allocation There are several casse to require asymmetric bandwidth allocation for HSMP LSP. For example, when HSMP LSP is used in VPLS application, each leaf node may send reverse traffic to root node at the same time. The reverse path bandwidth allocation MUST fullfill the traffic requirement, with the assumption that traffic from all leaf nodes will be merged at each link. Some applications may not Jin, et al. Expires November 8, 2012 [Page 8] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 require bandwidth guarantee for the upstream path from leaf to root (only use reverse path for signaling), then it is not necessary to allocate bandwidth for the upstream path. The mechanism of allocating asymmetric bandwidth for point-to-point link is described in[I-D.ietf-ccamp-asymm-bw-bidir-lsps-bis], and this draft will have some extension to support asymmetric bandwidth allocation for HSMP LSP. Each S2L sub-LSP should have its own traffic bandwidth requirement for the reverse path of HSMP LSP, and the S2L sub-LSP should carry the bandwidth information. 3.4.1. Packet Format The sender descriptor in path message is modified as follows to add bandwidth information to each S2L sub-LSPs. ::= [ ] [ ] [ ] [ ] S2L sub-LSP descriptor list in path message should have the following format. ::= [ ] ::= [ ] FF flow descriptor in resv message is modified as follows to add bandwidth information to each S2L sub-LSPs. Jin, et al. Expires November 8, 2012 [Page 9] Internet-Draft RSVP-TE Hub-Spoke Multipoint LSP May 2012 ::= [ ] [ ] [ ]