Network Working Group Z. Li Internet-Draft Z. Zhuang Intended status: Informational J. Dong Expires: April 18, 2013 Huawei Technologies October 15, 2012 A Framework for Service-Driven Co-Routed MPLS Traffic Engineering LSPs draft-li-mpls-serv-driven-co-lsp-fmwk-00 Abstract This document provides a framework for setting up service-driven co- routed MPLS Traffic-Engineered Label-Switched Paths(TE LSP) in Multi- Protocol Label Switching (MPLS) networks. 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 [RFC2119]. 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 April 18, 2013. 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 publication of this document. Please review these documents Li, et al. Expires April 18, 2013 [Page 1] Internet-Draft A Framework for SD Co-Routed LSPs October 2012 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 3.1. MPLS TE Configuration . . . . . . . . . . . . . . . . . . . 3 3.2. Return Path of BFD for LSP . . . . . . . . . . . . . . . . 3 3.3. Upgrading of Co-routed Bidirectional LSP . . . . . . . . . 4 4. Framework and Procedures . . . . . . . . . . . . . . . . . . . 4 4.1. Service-Driven Co-Routed Unidirectional LSPs for L2VPN . . 4 4.1.1. Framework . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.2. Procedures . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Service-Driven Co-Routed Unidirectional LSPs for L3VPN . . 6 4.2.1. Framework . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Li, et al. Expires April 18, 2013 [Page 2] Internet-Draft A Framework for SD Co-Routed LSPs October 2012 1. Introduction MPLS Traffic Engineering (TE) has been widely deployed to support packet-based services. Rich Traffic Engineering properties can be provied to satisfy different requirements of services. As the MPLS TE LSP is deployed in networks of service providers, several challenges has been proposed about esay operation and management. This document propose a solution to set up co-routed MPLS TE LSPs on demand to faciliate the deployment for services. 2. Terminology This document uses terminology from the MPLS architecture document [RFC3031] and from the RSVP-TE protocol specification [RFC3209] which inherits from the RSVP specification [RFC2205]. The PEs can be generally categorized into two types: 1. Active PE: the PE which primarily triggers to set up the LSPs and informs the remote PE; 2. Passive PE: the PE which secondarily complies with the active PE's suggestion. 3. Problem Statement 3.1. MPLS TE Configuration It is a common deployment scenario to set up MPLS Traffic Engineering(TE) LSPs among a set of Label Switch Routers (LSR). Such deployment may require the configuration of a potentially large number of TE tunnels. The operation is not only time consuming but also prone to misconfiguration for Service Providers. Hence, an automatic mechanism for setting up MPLS TE tunnels is desirable which can simplify the complexity of MPLS TE configuration. 3.2. Return Path of BFD for LSP BFD for LSP ([RFC5884]) is used to detect the possible failure fast and the failure detected can trigger traffic switch between the primary LSP and the backup LSP. When BFD for LSP is deployed, the return path may take IP path which is different from the forwarding path. The failure that happens in the return path may trigger wrong traffic switch. Li, et al. Expires April 18, 2013 [Page 3] Internet-Draft A Framework for SD Co-Routed LSPs October 2012 3.3. Upgrading of Co-routed Bidirectional LSP Co-routed bidirectional LSPs can simplify operation and management for Service Providers. Moreover co-routed bidirectional LSPs require less states comparing with two unidirectional MPLS TE LSPs. .But the unidirectlional LSP has been deployed widely and it is difficult for the service provider to upgrade all possible routers to support co- routed bidirectional LSPs. 4. Framework and Procedures The section proposes the solution to trigger setting up MPLS TE LSP by services. The framework an procedures of the solution are introduced. With the solution, MPLS TE LSPs can setup on demand which can reduce the statical configuration. In addition, the signalling for the service will advertise the tunnel information between the active PE and the passive PE. The LSP on the passive side can setup according to RRO information of the LSP setup from the active PE to the passive PE. Thus the path of the reverse LSP can be co-routed with the path of the LSP from the active PE to the passive PE. 4.1. Service-Driven Co-Routed Unidirectional LSPs for L2VPN 4.1.1. Framework Active PE Passive PE | | |<------Signalling Tunnel----->| | | | TE LSP1 for PW | |----------------------------->| | PW | |<---------------------------->| | TE LSP2 for PW | |<-----------------------------| +----+ +--+ +--+ +----+ | PE1|===|P1|======|P2|===| PE2| +----+ +--+ +--+ +----+ | | Figure 2: Signalling Tunnel Framework of L2VPN Figure 2 shows a framework for co-routed MPLS TE LSPs driven by PW. L2VPN is provisioned on PEs and PW is setup. A pair of PEs for a specific PW will be identified as the active PE and the passive PE. Li, et al. Expires April 18, 2013 [Page 4] Internet-Draft A Framework for SD Co-Routed LSPs October 2012 The active PE triggers setting up the primary LSP to the passive PE and advertises the tunnel information to the passive PE. According to the information advertised the passive PE will set up the return MPLS TE LSP which path is co-routed with that of the primary LSP. 4.1.2. Procedures | (1) Active/passive role election | | (Here Set PE1 as active role ) | |<----------------------------------------->| | | Active Passive (2)PE1's PW drives RSVP-TE (2) PE2 waits for Tunnel info to Create TE LSP: LSP1 advertised from PE1 |(3) PE1 advertises LSP1 Tunnel info to PE2 | |------------------------------------------>| | | (4) PE2 gets Tunnel info from PE1, Create TE LSP (eg. LSP2) according to RRO information of LSPl, Binds LSP1 and LSP2 for PW; |(5) PE2 advertises LSP2 Tunnel info to PE1 | |<------------------------------------------| | | (6)PE1 binds LSP1 and LSP2 for PW; | Co-routed TE LSP Established | |<----------------------------------------->| | | Figure 3: Signalling Procedures of L2VPN Figure 3 shows the detailed signalling procedures for L2VPN to drive setup of co-routed MPLS TE LSPs: (1) Active/passive role election through signalling for a pair of PEs of a PW (Assume PE1 as active PE and PE2 as passive PE after election ); (2) PE1's PW drives RSVP-TE to create TE LSP(LSP1) while PE2 waits for tunnel information advertised by PE1; Li, et al. Expires April 18, 2013 [Page 5] Internet-Draft A Framework for SD Co-Routed LSPs October 2012 (3) PE1 advertises tunnel information related with LSP1 to PE2; (4) PE2 gets tunnel information from PE1 and createS TE LSP (eg. LSP2) according to RRO information derived from LSP1. PE2 binds LSP1 and LSP2 for PW; (5) PE2 advertises tunnel information related with LSP2 to PE1; (6) PE1 binds LSP1 and LSP2 for PW. Through the above signalling procedure, the co-routed MPLS TE LSPs driven by the PW are established. 4.2. Service-Driven Co-Routed Unidirectional LSPs for L3VPN 4.2.1. Framework Active PE Passive PE | | |<------Signalling Tunnel----->| | | | TE LSP1 for L3VPN | |----------------------------->| | L3VPN | |<---------------------------->| | TE LSP2 for L3VPN | |<-----------------------------| +----+ +--+ +--+ +----+ | PE1|===|P1|======|P2|===| PE2| +----+ +--+ +--+ +----+ | | Figure 4: Signalling Tunnel Framework of L3VPN Figure 4 shows a framework for co-routed MPLS TE LSPs driven by L3VPN. L3VPN is provisioned on PEs and VPN members are discovered. A pair of PEs for L3VPN members will be identified as the active PE and the passive PE. The active PE triggers set up the primary LSP to the passive PE and advertises the tunnel information to the passive PE. According to the information advertised the passive PE will set up the return MPLS TE LSP which path is co-routed with that of the primary LSP. 4.2.1.1. Procedures Li, et al. Expires April 18, 2013 [Page 6] Internet-Draft A Framework for SD Co-Routed LSPs October 2012 | (0) VPN Member Auto-Discorvery | |<----------------------------------------->| | | | (1) active/passive role election | | (Here Set PE1 as active role ) | |<----------------------------------------->| | | Active Passive (2)PE1's L3VPN drives RSVP-TE (2) PE2 waits for Tunnel info to Create TE LSP: LSP1 advertised from PE1 |(3) PE1 advertises LSP1 Tunnel info to PE2 | |------------------------------------------>| | | (4) PE2 gets Tunnel info from PE1, Create TE LSP (eg. LSP2) according to RRO information of LSPl, Binds LSP1 and LSP2 for L3VPN; |(5) PE2 advertises LSP2 Tunnel info to PE1 | |<------------------------------------------| | | (6)PE1 binds LSP1 and LSP2 for L3VPN; | Co-routed TE LSP Established | |<----------------------------------------->| | | Figure 5: Signalling Procedures of L3VPN Figure 5 shows the detailed signalling procedures for L3VPN to drive setup of co-routed MPLS TE LSPs : (0) VPN member auto-discovery process is done through signalling to identify a pair of VPN members; (1) Active/passive role election through signalling for a pair of PEs of a PW (Assume PE1 as active PE and PE2 as passive PE after election ); (2) PE1's PW drives RSVP-TE to create TE LSP(LSP1) while PE2 waits for tunnel information advertised by PE1; (3) PE1 advertises tunnel information related with LSP1 to PE2; Li, et al. Expires April 18, 2013 [Page 7] Internet-Draft A Framework for SD Co-Routed LSPs October 2012 (4) PE2 gets tunnel information from PE1 and createS TE LSP (eg. LSP2) according to RRO information derived from LSP1. PE2 binds LSP1 and LSP2 for L3VPN; (5) PE2 advertises tunnel information related with LSP2 to PE1; (6) PE1 binds LSP1 and LSP2 for L3VPN. Through the above signalling procedure, the co-routed MPLS TE LSPs driven by the L3VPN are established. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations This document does not change the security properties of L2VPN & L3VPN. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [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. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. Li, et al. Expires April 18, 2013 [Page 8] Internet-Draft A Framework for SD Co-Routed LSPs October 2012 Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com URI: jie.dong@huawei.com Jie Dong Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Li, et al. Expires April 18, 2013 [Page 9]