Alternative Constraints for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths(LSPs)
Author(s): Zhenbin Li, Tieying Huang
The document proposes a solution to be able to set up the alternative path for specific leaf nodes of a P2MP TE LSP. Corresponding RSVP-TE protocol extension is also defined. The solution is used to cope with the...
Network Working Group Z. Li Internet-Draft T. Huang Intended status: Experimental Huawei Technologies Expires: August 22, 2013 February 18, 2013 Alternative Constraints for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths(LSPs) draft-li-mpls-p2mp-te-alt-path-00 Abstract The document proposes a solution to be able to set up the alternative path for specific leaf nodes of a P2MP TE LSP. Corresponding RSVP-TE protocol extension is also defined. The solution is used to cope with the issue that in some scenarios traffic loss happens even if there exists possible path for the leaf nodes. Requirements Language 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 [RFC 2119]. 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 August 22, 2013. Copyright Notice Copyright (c) 2013 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 Li & Huang Expires August 22, 2013 [Page 1] Internet-Draft Alternative Path for P2MP TE LSP February 2013 (http://trustee.ietf.org/license-info) in effect on the date of 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 4. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Path Computation in Root Node . . . . . . . . . . . . . . . 5 4.2. Alternative Constraints Propagation . . . . . . . . . . . . 5 4.3. Resource Reservation . . . . . . . . . . . . . . . . . . . 6 5. Protocol Extension . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Path Message Format . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Li & Huang Expires August 22, 2013 [Page 2] Internet-Draft Alternative Path for P2MP TE LSP February 2013 1. Introduction [RFC4461] presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE) Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). [RFC4875] defines extensions to the RSVP-TE protocol for setup of P2MP TE LSPs. P2MP TE LSPs are set up with a series of traffic engineering constraints. These constraints are applied to all S2L sub-LSPs. This may cause the issue that some S2L sub-LSPs can be set up while others can not according to the constraints. There may be worse case that some S2L sub-LSPs can not be restored after link failure according to the constraints. When P2MP TE LSPs are used for specific applications, it will cause continuous traffic loss. This document identifies the applicability issue and proposes the solution and corresponding protocol extension. 2. Terminology This document uses terminologies defined in [RFC2205], [RFC3031], [RFC3209], [RFC3473], [RFC4090], [RFC4461] and [RFC4875]. 3. Problem Statement The P2MP TE LSP is set up with a series of traffic engineering constrains such as bandwidth, explicit path, affinity property(color), etc. These traffic engineering constraints are applied to path computation for all S2L sub-LSPs. Owing to the network provision some leaves of the P2MP LSP are not reachable according the required constraints ( it will be called primary constraints in the following ). There may be the worse case that all leaves are reachable at the beginning and they are not reachable when failure happens. In fact these leaves can be reachable if ignore some or all of the primary constraints . Li & Huang Expires August 22, 2013 [Page 3] Internet-Draft Alternative Path for P2MP TE LSP February 2013 A | | B | | C----D----E | | | | | | F G H*******I | | * | | * | | * J K*******L | | * | | * N M*******O Figure 1. Constraints for P2MP TE LSP An example for P2MP TE LSP setup is shown in the figure 1. A is the root node and F, N and M are leaf nodes. The link with '|' means the link with red color and the link with '*' means the link with green color. The constraint is that the link with red color should be chosen for the path. For the leaf node M, the path is A->B->E->H->K-M. When link between H and K fails, there is no path with red color can be found from A to M. This will cause the initial available traffic break until the link between H and K restores. The continuous traffic loss can cause bad user experience if the P2MP TE LSP is used for IPTV or other applications. In fact, during the course of failure, there is an alternative path from A to M ( A->B->E->H->I->L->K->M ) if the link with green color can be chosen. 4. Mechanisms In order to solve the above applicability issue for P2MP TE LSP, alternative constraints can be specified for the P2MP TE LSP to calculate paths to specific leaf nodes if the path with the primary constraints is not available. The P2MP TE LSP is set up with some S2L sub-LSPs using the primary constraints while the other S2L sub- LSPs using the alternative constraints. The constraints may be used in the downstream nodes, such as ASBR node, and the alternative constraints MUST be propagated to keep the consistence through RSVP-TE protocol extensions. Li & Huang Expires August 22, 2013 [Page 4] Internet-Draft Alternative Path for P2MP TE LSP February 2013 4.1. Path Computation in Root Node When alternative constraints is allowed for a specific P2MP TE LSP in the root node, the node MUST try to compute paths for all leaf nodes using the primary constraints. If paths with the primary constraints are available for all leaf nodes, the alternative constraints MUST NOT be used. When paths with the primary constraints are not available for specific leaf nodes, the alternative constraints SHOULD be used to calculate paths for these leaf nodes. In order to get available paths, the alternative constraints should be looser than the primary constraints. The alternative constraints can be set as zero to simplify the process and the best-effort path as routing is calculated. When calculate paths with the alternative constraints, the constraints MUST be applied to the whole S2L sub-LSP. That is, it is prohibited that some parts of the S2L sub-LSP satisfies the primary constraints while other parts satisfies the alternative constraints. If the root node can not calculate the whole S2L sub-LSP ( abstract node exists in the calculated path ), the alternative constraints MUST be used in the downstream nodes path calculation. The root node will keep trying to re-optimize to a better path to meet the primary constraints, and it is outside the scope of this document. 4.2. Alternative Constraints Propagation When setup P2MP LSP, the primary constraint is carried according to the RSVP-TE protocol extension which is defined in [RFC4875]. If the paths to specific leaf nodes are computed using alternative constraints, the alternative constraints MUST be carried corresponding to the S2L sub-LSPs to these leaf nodes in the Path message. These alternative constraints corresponding to S2L sub-LSPs are propagated along the paths from the root node to the leaf nodes. Both the primary and alternative constraints may be propagated in one Path message. a transit node SHOULD choose the correct constraints to calculate the rest path. If there are alternative constraints following the S2L sub-LSPs, it MUST be used when calculating for the S2L sub-LSPs, while the primary constraints MUST be used for the S2L sub-LSPs that is not followed. This will be described in detail in the section 5 of RSVP-TE protocol extensions. Li & Huang Expires August 22, 2013 [Page 5] Internet-Draft Alternative Path for P2MP TE LSP February 2013 4.3. Resource Reservation When the Resv message is propagated from the leaf nodes to the root node, the transit node MUST reserve resource according to the traffic parameters specified by the required constraints. However, the common upstream node, such as A, B node in figure 1, may have different traffic parameters required if both the primary and alternative constraints exist, and the primary constraints should be chosen in this case. 5. Protocol Extension There are two methods for RSVP-TE protocol to carry both the primary and alternative constraints. One is to separate the S2L sub-LSPs with alternative constraints from the S2L sub-LSPs with the primary constraints. The Sub-Group fields imported in [RFC4875] may evade the issue of section 4.2 naturally. It is assumed that the S2L sub- LSPs with the primary constraints and the S2L sub-LSPs with alternative constraints SHOULD not be propagated in a single IP packet. The other method will be described in detail in section 5.1 Path Message Format. 5.1. Path Message Format This section describes modifications made to the Path message format as specified in [RFC4875]. The Path message is enhanced to signal alternative constraints for specific S2L sub-LSPs. Li & Huang Expires August 22, 2013 [Page 6] Internet-Draft Alternative Path for P2MP TE LSP February 2013 <Path Message> ::= <Common Header> [ <INTEGRITY> ] [ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...] [ <MESSAGE_ID> ] <SESSION> <RSVP_HOP> <TIME_VALUES> [ <EXPLICIT_ROUTE> ] <LABEL_REQUEST> [ <PROTECTION> ] [ <LABEL_SET> ... ] [ <SESSION_ATTRIBUTE> ] [ <NOTIFY_REQUEST> ] [ <ADMIN_STATUS> ] [ <POLICY_DATA> ... ] <sender descriptor> [<S2L sub-LSP descriptor list>] The following is the format of the S2L sub-LSP descriptor list. <S2L sub-LSP descriptor list> ::= <S2L sub-LSP descriptor> [ <S2L sub-LSP descriptor list> ] <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP> [ <P2MP SECONDARY_EXPLICIT_ROUTE> ] [ <P2MP SECONDARY_SESSION_ATTRIBUTE> ] [ <P2MP SECONDARY_SENDER_TSPEC> ] In the modified Path message, S2L_SUB_LSP for specific leaf nodes can carry the alternative constraints besides the explicit route . <P2MP SECONDARY_SESSION_ATTRIBUTE> and <P2MP SECONDARY_SENDER_TSPEC> are added to specify the alternative constraints such as resource affinity, setup and holding priority and traffic parameters. The format of <P2MP SECONDARY_SESSION_ATTRIBUTE> and <P2MP SECONDARY_SENDER_TSPEC> are the same as <SESSION_ATTRIBUTE> defined by [RFC3209] and <SENDER_TSPEC> defined by [RFC2210]. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations TBD. Li & Huang Expires August 22, 2013 [Page 7] Internet-Draft Alternative Path for P2MP TE LSP February 2013 8. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC2210, September 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC3031, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC3473, January 2003. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC4090, May 2005. [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC4461, April 2006. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC4875, May 2007. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: email@example.com Li & Huang Expires August 22, 2013 [Page 8] Internet-Draft Alternative Path for P2MP TE LSP February 2013 Tieying Huang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: firstname.lastname@example.org Li & Huang Expires August 22, 2013 [Page 9]