Network working group J. Dong Internet Draft M. Chen Intended status: Standards Track C. Liu Expires: April 25, 2011 Huawei Technologies S. Luo China Telecom October 25, 2010 Flexible MPLS-TE Fast Reroute draft-dong-mpls-rsvp-te-plr-designation-01.txt Abstract This document defines RSVP-TE extensions which enable the ingress node to designate particular LSRs along the path as Points of Local Repair (PLRs) of the protected LSP, and further indicate the protection type of each PLR. These mechanisms could enhance the control over the establishment of backup LSPs, achieve more flexible TE FRR and also could save the resources needed for establishing and maintaining unnecessary backup LSPs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on April 25, 2011. Dong, et al. Expires April 25, 2011 [Page 1] Internet-Draft Designation of PLRs in TE FRR October 2010 Copyright Notice Copyright (c) 2010 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 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 ................................................ 2 2. Conventions used in this document ........................... 3 3. Problem Statement ........................................... 3 4. Possible Solutions .......................................... 4 4.1. SERO Based Mechanism ................................... 4 4.2. ERO Based Mechanism .................................... 5 4.2.1. Extensions to IPv4 Prefix Subobject ............... 5 4.2.2. Extensions to IPv6 Prefix Subobject ............... 6 4.2.3. Backward Compatibility ............................ 6 5. Selection of PLRs and Protection Type ....................... 7 6. Operations of ERO Based Mechanism ........................... 7 6.1. Operation of Head End .................................. 7 6.2. Operation of Other LSRs ................................ 7 7. Security Considerations ..................................... 7 8. IANA Considerations ......................................... 7 9. References .................................................. 7 9.1. Normative References ................................... 7 9.2. Informative References ................................. 8 Authors' Addresses ............................................. 9 1. Introduction Currently the fast reroute mechanisms of RSVP-TE [RFC4090] enable the ingress node of protected LSP to indicate whether local protection is desired and whether node protection is desired for this LSP. However, such indication is relevant to the whole LSP, the ingress node cannot indicate which LSRs on the path are required to be Points of Local Repair (PLRs), and the protection type of each PLR. Dong, et al. Expires April 25, 2011 [Page 2] Internet-Draft Designation of PLRs in TE FRR October 2010 This document describes possible solutions for PLR designation in TE fast reroute, and defines simple extensions to RSVP-TE to achieve flexible TE FRR which is backward compatible with RFC 4090. These mechanisms could provide the operators with more control of the backup LSPs, this is useful when only a subset of the LSRs on the path are required to operate as PLRs. Also, this could avoid unnecessary signaling and bandwidth reservation for protection of components which are not quite likely to fail. Thirdly, this could relieve the burden on LSRs which may not have enough resources to perform local protection functions. 2. 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 [RFC2119]. 3. Problem Statement RFC 4090 has defined mechanisms to establish local protection for a particular LSP. The fast reroute mechanisms of RFC 4090 enable the ingress node of the protected LSP to indicate whether local protection is desired and what protection type is needed for this LSP. However, such specification is at the granularity of LSP level, the ingress node cannot explicitly designate which LSRs along the path are required to be PLRs, and the protection type on each PLR. In some networks some of the links and nodes can be more reliable than the others, e.g. some links may reside in the same building or have redundancy in the physical layer, and some nodes can have good redundancy in both data plane and control plane. Thus there are fewer requirements to protect such links and nodes on LSP level. Based on the reliability information of the network and service providers' local policy, the operators may prefer to protect only a subset of the links and nodes along the path, thus the ingress node needs to specify particular LSRs as PLRs, and the protection type on each PLR. This can be helpful in many aspects. Firstly, this enables the operators to setup the backup LSPs they need in a more controllable way. Secondly, this could avoid unnecessary signaling and bandwidth reservation for protection of links and nodes which are unlikely to fail. Thirdly, this could relieve the burden on LSRs which may not have enough resources to perform local protection functions. Dong, et al. Expires April 25, 2011 [Page 3] Internet-Draft Designation of PLRs in TE FRR October 2010 This document describes possible solutions for PLR designation, and defines simple extensions to RSVP-TE to achieve flexible TE FRR which is backward compatible with RFC 4090. 4. Possible Solutions 4.1. SERO Based Mechanism GMPLS Segment Recovery [RFC4873] provides one mechanism to specify segment recovery LSPs using SECONDARY_EXPLICIT_ROUTE Object (SERO). An SERO can indicate a recovery LSP's initiator and terminator, standard ERO semantics can optionally be used in SERO to explicitly control the recovery LSP, and a new subobject called Protection is defined to indicate the type of protection or restoration to be provided. Another new Object called SECONDARY_RECORD_ROUTE Object (SRRO) is also defined for this procedure. Detailed mechanisms are specified in section 4 of RFC 4873. For MPLS networks which support extensions and Objects defined for GMPLS such as SERO, SRRO and PROTECTION, and the operators desire to explicitly specify the path of the recovery LSPs, the SERO based mechanism can be used. Currently there is no detailed specification about the combination use of MPLS-TE FRR [RFC4090] and GMPLS segment recovery [RFC4873]. This section only gives some brief instructions to this mechanism, detailed specification is for further study. Association between protected LSP and backup LSP: according to RFC 4090, the association is based on the same SESSION Object and the same LSP ID in SENDER_TEMPLATE Object, the only field that varies is the IPv4 (or IPv6) tunnel sender address in SENDER_TEMPLATE Object. The ASSOCIATION Object defined in [RFC4872] MUST not be used. Designation of PLR and MP: SERO is used to indicate the PLR and the Merge point (MP) of the backup LSP, and optionally to explicitly specify the path of the backup LSP. Note that explicitly designating PLR and MP implies the protection type of TE FRR, i.e. Node Protection or Link Protection. The PROTECTION subobject in SERO is used to create the PROTECTION object for the recovery LSP. For TE fast reroute, the protection type SHOULD be set to 0x04 (1:N Protection with Extra-Traffic). Note a node receiving a Path message containing one or more SEROs SHOULD examine each SERO to see if it indicates a local branch point. In scenarios where many backup LSPs are specified using SEROs, this may bring extra burden to nodes which do not have enough control plane resources. Dong, et al. Expires April 25, 2011 [Page 4] Internet-Draft Designation of PLRs in TE FRR October 2010 4.2. ERO Based Mechanism For MPLS networks which do not support the RSVP extensions for GMPLS, the SERO based mechanism may not be applicable. And for operators which do not desire to explicitly specify each node of the backup LSPs, the procedures of SERO based mechanism seems a bit complicated. This section defines simple extensions to Explicit_Route Object (ERO) to achieve flexible PLR designation and protection type indication. The Explicit_Route Object (ERO) is extended to carry information of PLR designation and type of local protection. The low order bits of the Reserved field in IPv4 prefix and IPv6 prefix subobjects are used as flags to indicate whether the LSR represented by the subobject should operate as a PLR and the desired protection type. 4.2.1. Extensions to IPv4 Prefix Subobject Two new flags are defined in this subobject. The structure of extended IPv4 prefix subobject is as below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | Prefix Length | Reserved |P|N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P: Local Protection flag. The P bit indicates whether this subobject is designated as a PLR. It will be set to 0 if the node is designated to be a PLR for the protected LSP, and set to 1 otherwise. If the "Local Protection Desired" flag in the SESSION_ATTRIBUTE Object is not set, no local protection will be used for the whole LSP, and the value of the P bit is insignificant. N: Node Protection flag. The N bit indicates whether node protection is required for this subobject. It will be set to 1 if node protection is desired, and set to zero if the protection type is indicated by the Node Protection Flag in the SESSION_ATTRIBUTE Object. Note the N bit makes sense only when the "Local Protection Desired" flag in the SESSION_ATTRIBUTE Object is set and the above P bit is set to 0. Dong, et al. Expires April 25, 2011 [Page 5] Internet-Draft Designation of PLRs in TE FRR October 2010 4.2.2. Extensions to IPv6 Prefix Subobject Two new flags are defined in this subobject. The structure of extended IPv6 prefix subobject is as below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | Prefix Length | Reserved |P|N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P: Local Protection flag. The P bit indicates whether this subobject is designated as a PLR. It will be set to 0 if the node is designated to be a PLR for the protected LSP, and set to 1 otherwise. If the "Local Protection Desired" flag in the SESSION_ATTRIBUTE Object is not set, no local protection will be used for the whole LSP, and the value of the P bit is insignificant. N: Node Protection flag. The N bit indicates whether node protection is required for this subobject. It will be set to 1 if node protection is desired, and set to zero if the protection type is indicated by the Node Protection Flag in the SESSION_ATTRIBUTE Object. Note the N bit makes sense only when the "Local Protection Desired" flag in the SESSION_ATTRIBUTE Object is set and the above P bit is set to 0. 4.2.3. Backward Compatibility The P bit and N bit are designed to be backward compatible with current protection mechanisms. LSRs which do not support this extension will treat these bits as reserved bit and ignore the value of them. When both the 2 bits are set to 0 by head end LSR, the protection behavior of all other LSRs on the path (no matter support this extension or not) is the same as current TE FRR mechanisms. Dong, et al. Expires April 25, 2011 [Page 6] Internet-Draft Designation of PLRs in TE FRR October 2010 5. Selection of PLRs and Protection Type The selection of PLRs and the protection type on each PLR are based on the reliability information of the network and local policy of the service provider. Service providers may have knowledge about which links and nodes in the network are more reliable, and which nodes are not suitable to be PLRs. This kind of information may be obtained by some information advertisement mechanism, or through methods outside the scope of protocols. Based on this information, the operator or the ingress node could designate a subset of LSRs as PLRs and specify the protection type. 6. Operations of ERO Based Mechanism 6.1. Operation of Head End Based on the result of PLR selection and the required protection type on each PLR, the head-end LSR SHOULD appropriately set the P bit and N bit in corresponding ERO subobjects in the PATH message. 6.2. Operation of Other LSRs On receipt of a PATH message, the LSR SHOULD check the "Local Protection Desired" and "Node protection desired" flags in the SESSION Attribute Object along with the P bit and N bit in corresponding ERO subobjects, and perform local protection based on these flags. If some LSR on the path needs to add subobjects to the ERO, it MAY set the P bit and N bit of the subobjects based on local policy. 7. Security Considerations This document does not introduce new security issues. 8. IANA Considerations There is no IANA action required by this draft. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Dong, et al. Expires April 25, 2011 [Page 7] Internet-Draft Designation of PLRs in TE FRR October 2010 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4090] Pan, P., Swallow, G. and Atlas, A., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC4090, May 2005. 9.2. Informative References [RFC4872] Lang, J.P., Rekhter, Y. and Papadimitriou, D., "RSVP-TE Extensions in Support of End-to-End GMPLS Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, A., "GMPLS Segment Recovery", RFC 4873, May 2007. Dong, et al. Expires April 25, 2011 [Page 8] Internet-Draft Designation of PLRs in TE FRR October 2010 Authors' Addresses Jie Dong Huawei Technologies Co.,Ltd Huawei Building, No.3 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China EMail: dongjie_dj@huawei.com Mach(Guoyi) Chen Huawei Technologies Co.,Ltd Huawei Building, No.3 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China EMail: mach@huawei.com Chun Liu Huawei Technologies Co.,Ltd Huawei Building, No.156 Beiqing Rd. Hai-Dian District Beijing, 100095 P.R. China EMail: liuchuner1981@huawei.com SongFeng Luo China Telecom 109 West Zhongshan Ave, Tianhe District, Guanghou, 510630, P.R.C EMail: luosf08@163.com Dong, et al. Expires April 25, 2011 [Page 9]