Network Working Group Z. Li Internet-Draft Z. Zhuang Intended status: Informational J. Dong Expires: July 20, 2014 Huawei Technologies January 16, 2014 A Framework for Service-Driven Co-Routed MPLS Traffic Engineering LSPs draft-li-mpls-serv-driven-co-lsp-fmwk-02 Abstract MPLS TE has been widely deployed to provide traffic engineering and traffic protection. The complexity in configuration has much effect on the MPLS TE deployment in the large-scale network. The document identifies the configuration issues for MPLS TE deployment and proposes a new mechanism, the service-driven mechanism, by which the setup of co-routed MPLS TE LSPs is triggered by the bidirectional service. Then the document provides the framework for setting up service-driven co-routed MPLS Traffic-Engineered Label-Switched Paths(TE LSPs) for L2VPN and L3VPN. 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 July 20, 2014. Li, et al. Expires July 20, 2014 [Page 1] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 Copyright Notice Copyright (c) 2014 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Massive Configuration Issue of TE LSPs . . . . . . . . . 4 3.2. Return Path Issue of BFD for MPLS LSPs . . . . . . . . . 5 3.3. Upgrading Issue of Co-routed Bidirectional LSP . . . . . 6 4. Framework and Procedures . . . . . . . . . . . . . . . . . . 6 4.1. Service-Driven Co-Routed Unidirectional LSPs for L2VPN . 7 4.1.1. Framework . . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Procedures . . . . . . . . . . . . . . . . . . . . . 8 4.2. Service-Driven Co-Routed Unidirectional LSPs for L3VPN . 9 4.2.1. Framework . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Procedures . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Multiprotocol Label Switching (MPLS) traffic engineering (TE) effectively schedules, allocates, and uses existing network resources to provide bandwidth guarantee and traffic protection. MPLS TE establishes label switched paths (LSPs) satisfying specific traffic engineering attributes [RFC2702]. MPLS TE is being widely deployed to support packet-based services. Since rich set of traffic engineering attributes have to be specified for each LSP and a great deal of configuration has to be done as the number of MPLS TE LSPs increases, a scalable and simple solution is required to implement TE Li, et al. Expires July 20, 2014 [Page 2] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 on a large-scale network and reduce the complexity in operation and management of TE LSPs. LDP LSP setup is topology-driven which is a scalable way to adapt to the large-scale network. The similar way cannot be used for MPLS TE since the traffic engineering attributes should be specified for the MPLS TE tunnel which is not necessary for LDP LSP. On the other hand, MPLS TE LSP is always setup to bear specific services such as L3VPN and L2VPN. That is, MPLS TE LSPs will not be setup aimlessly which is always inevitable for MPLS topology-driven LSP if there is no policy exerted on it. So it seems a natural way to combine the MPLS TE LSP setup with the service it beared. The MPLS TE LSP setup can be triggered automatically by the service instead of explicitly configuring each tunnel and its traffic engineering attributes. We call this method as service-driven comparing to topology-driven. In addition the service-driven method has much advantage in the process of setting up co-routed TE LSPs. The service beared by MPLS TE LSPs is always bi-directional. The characteristic can be utilized to setup the forward MPLS TE LSP and the co-routed reverse MPLS TE LSP. This document describes the framework of automatically setting up co- routed TE LSPs, in which the co-routed MPLS TE LSPs are automatically setting up on demand of the services, e.g. VPNs. This mechanism facilitates the provisioning of services and the TE LSPs. 2. Terminology This document uses terminology from the MPLS architecture document [RFC3031], the RSVP-TE protocol specification [RFC3209] which inherits from the RSVP specification [RFC2205] and the Provider Provisioned VPN terminology document [RFC4026]. The document introduces two new concepts by which VPN PEs can be generally categorized into two types: 1. Active PE: the PE which primarily triggers the set up of the LSPs and informs the remote PE; 2. Passive PE: the PE which secondarily complies with the active PE's suggestion to set up LSPs. In this document, the terminology of "tunnel" is identical to the "TE Tunnel" defined in Section 2.1 of [RFC3209], which is uniquely identified by a SESSION object that includes Tunnel end point address, Tunnel ID and Extended Tunnel ID. The terminology "LSP" is identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209], which is uniquely identified by the SESSION object together with Li, et al. Expires July 20, 2014 [Page 3] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 SENDER_TEMPLATE (or FILTER_SPEC) object that consists of LSP ID and Tunnel end point address. 3. Problem Statement 3.1. Massive Configuration Issue of TE LSPs It is a common deployment scenario to set up MPLS TE LSPs among a set of Label Switching Routers (LSR). Such deployment may require the configuration of a potentially large number of TE tunnels. ---------------- / \ / \ / \ +----+ Access +----+ |CSG1| Ring 1 |ASG1|------------- +----+ +----+ \ \ / \ \ / +----+ \ +----+ |RSG1| -------------| | Aggregate +----+ |ASG2| Ring | -------------| | +----+ / +----+ |RSG2| / \ +----+ / \ / +----+ Access +----+ / |CSG2| Ring 2 |ASG3|------------- +----+ +----+ \ / \ / \ / ----------------- Figure 1 Mobile Backhaul Network Figure 1 shows an example of the mobile backhaul network. Mobile multimedia devices such as smartphones are ubiquitous now which runs a wide variety of bandwidth-intensive applications and causes unprecedented growth in mobile data traffic. In order to cope with the growth, more cell sites are introduced into the network: more LTE eNodeBs and associated Cell Site Gateways(CSGs) are added in the networks. This causes the network scale expands fast and more and more MPLS TE tunnels need setup between Cell Site Gateways(CSGs) connects the eNodeBs and RNC site gateways(RSGs) connects the RNCs. Typically, we assume that: Li, et al. Expires July 20, 2014 [Page 4] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 1. There are 1,000 CSGs need to connect to one RSG. 2. There are three types of bi-directional services beared between one CSG and one RSG. Each type of service needs one VPN and one TE tunnel. 3. There are 10 command lines to configure necessary attributes for each TE tunnel and at least one command line to bind one VPN to one TE tunnel. Then there are at least 66,000 command lines to configure MPLS TE tunnels and VPN and TE tunnel bindings. It is truly a huge configuration work. The operation is not only time consuming but also prone to mis-configuration for Service Providers. Hence, a mechanism to set up MPLS TE tunnels automatically is desirable which can significantly reduce the complexity of MPLS TE configuration. 3.2. Return Path Issue of BFD for MPLS LSPs | | |<--------Dynamic BFD--------->| | | | (1) TE Primary LSP | |----------------------------->| | (2) TE Backup LSP | |----------------------------->| +----+ +--+ +--+ +----+ | PE1|===|P1|======|P2|===| PE2| +----+ +--+ +--+ +----+ | (3) IP Path (Return Path) | |<-----------------------------| Figure 2: BFD for TE LSPs Scenario As shown in Figure 2, BFD for MPLS LSPs ([RFC5884]) is used to detect the possible failure fast which can trigger traffic switch between the primary LSP and the backup LSP. When BFD for MPLS LSPs is deployed, the return path may take IP path which is different from the forward path. The failure that happens in the return path may cause wrong traffic switch. In order to solve the return path issue of BFD for MPLS LSPs, it has to be guaranteed that the forward path and the return path must be co-routed. For MPLS TE LSPs explicit path has to be configured for the forward LSP and the return LSP. In addition, there is at least one configuration to bind the return BFD traffic corresponding to the forward BFD traffic to the right return MPLS TE tunnel at the ingress node or the egress node. This will deteriorate the configuration Li, et al. Expires July 20, 2014 [Page 5] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 work described above. In addition, if the forward path changes, the return path may not change accordingly owing to statically binding the forward path and the return path. It will cause that the return path issue of BFD for MPLS LSPs happens again. 3.3. Upgrading Issue of Co-routed Bidirectional LSP The co-routed bidirectional LSP is defined in [RFC3945]. If co- routed bidirectional LSP is used, the return path is not necessary to configure and the return path issue of BFD for LSPs can be solved naturally. This can simplify operation and management for Service Providers to some extent. But as to the example described in sec 3.2 it is still necessary to configure each tunnel and configure explicit binding of each tunnel and VPN pair. The configuration work is still a little complex. In addition, the unidirectional LSPs have been deployed widely and it is difficult for the service providers to upgrade all possible routers to support co-routed bidirectional LSPs. 4. Framework and Procedures MPLS TE LSPs depend heavily on manual configuration. So some auto configuration method (e.g. auto mesh [RFC4972]) has been proposed. This document proposes a new mechanism, the service-driven mechanism, to reduce the operation cost of MPLS TE networks. It is well known that LDP LSP setup is topology-driven which is a scalable way to adapt to the large-scale network. The similar way cannot be used for MPLS TE since the traffic engineering attributes has to be specified for the MPLS TE tunnel. On the other hand, MPLS TE LSP is always setup to bear specific services such as L3VPN and L2VPN. That is, MPLS TE LSPs will not be setup aimlessly which is always inevitable for MPLS topology-driven LSP if there is no policy exerted on it. So it is a natural way to trigger MPLS TE LSP setup by the service instead of explicitly configuring each tunnel. We call this method as service-driven comparing to topology-driven. BGP-based MVPN ([RFC6513] and [RFC6514]) provides an example of service-driven tunnel which can trigger P2MP TE tunnel setup after MVPN membership auto-discovery. The service-driven method also has much advantage in the process of setting up co-routed TE LSPs. The service beared by MPLS TE LSPs is always bi-directional. The characteristic can be utilized to setup the forward MPLS TE LSP and the co-routed reverse MPLS TE LSP. This section describes the framework and procedures of setting up the co- routed MPLS TE LSPs. In this method, MPLS TE LSPs can be set up on demand which can reduce the manual configuration. The signaling of the service will advertise the tunnel information between the active PE and the passive PE. The PE on the passive side can set up the Li, et al. Expires July 20, 2014 [Page 6] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 reverse LSP based on RRO information of the LSP 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. Service-driven co-routed MPLS TE LSP has following advantages: 1) Setup LSP on demand and save massive configuration effort. 2) Reuse current mechanism instead of whole network upgrading. 4.1. Service-Driven Co-Routed Unidirectional LSPs for L2VPN 4.1.1. Framework Active PE Passive PE PE1 PE2 | | |<--Signaling of Tunnel Info-->| | | | TE LSP1 for PW | |----------------------------->| | PW | |<---------------------------->| | TE LSP2 for PW | |<-----------------------------| +----+ +--+ +--+ +----+ | PE1|===|P1|======|P2|===| PE2| +----+ +--+ +--+ +----+ | | Figure 3: Framework of L2VPN driven TE LSP L2VPN, as defined in [RFC4664], is a proven and widely deployed technology. Figure 3 shows a framework for co-routed MPLS TE LSPs driven by L2VPN service. L2VPN is provisioned on PEs and the PW is setup. A pair of PEs for a specific PW will be identified as the active PE and the passive PE respectively. The active PE triggers the set up of the primary LSP to the passive PE and advertises the tunnel information to the passive PE. According to the information advertised by the active PE, the passive PE will set up the reverse MPLS TE LSP which is co-routed with the LSP from the active PE to the passive PE LSP. Li, et al. Expires July 20, 2014 [Page 7] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 4.1.2. Procedures PE1 PE2 | (1) Active/passive role election | | (Here PE1 is elected as active PE) | |<----------------------------------------->| | | Active PE Passive PE (2)PE1's PW drives RSVP-TE (2) PE2 waits for Tunnel info to create TE LSP(e.g. LSP1) advertised from PE1 |(3) PE1 advertises LSP1 Tunnel info | | to PE2 through PW signaling | |------------------------------------------>| | | (4) PE2 gets forward Tunnel info from PE1, Create TE LSP (e.g. LSP2) according to RRO information of LSP1, Binds LSP1 and LSP2 for PW; |(5) PE2 advertises LSP2 Tunnel info to PE1 | |<------------------------------------------| | | (6)PE1 binds LSP1 and LSP2 for the PW; | Co-routed TE LSP Established | |<----------------------------------------->| | | Figure 4: Signaling Procedures of L2VPN driven co-routed TE LSPs Figure 4 shows the detailed procedures for L2VPN driven co-routed MPLS TE LSPs. Through the above procedure, the co-routed MPLS TE LSPs driven by the PW are established. 4.1.2.1. Active/Passive Role Election The active and passive role of PEs can be determined through manual configuration or dynamic election between two PEs. If the dynamic election method is used, LSR IDs of a pair of PEs between which PW is setup are compared as unsigned integers and the PE with the larger value of LSR ID assumes the active role. Li, et al. Expires July 20, 2014 [Page 8] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 4.1.2.2. Signaling Tunnel Information In the service-driven co-routed MPLS TE framework for L2VPN, the tunnel information need to be advertised between the active PE and the passive PE. The passive PE uses the tunnel information to get corresponding MPLS TE tunnel and RRO information which is used to setup the reverse co-routed MPLS TE LSP. [I-D.ietf-pwe3-mpls-tp-pw-over-bidir-lsp] defines how the bidirectional Tunnel/LSP identifier information is advertised between a pair of PEs for PW. The similar mechanism can be reused for advertising MPLS TE tunnel/LSP identifier information for service- driven MPLS TE LSPs for L2VPN. 4.1.2.3. Operation Step 1: Active/passive role election through signaling between PEs of a PW. In this case, assume PE1 as active PE and PE2 as passive PE after election; Step 2: As the active role, the PW service on PE1 drives RSVP-TE to create TE LSP(e.g. LSP1), as the passive role, PE2 waits for tunnel information advertised by PE1; Step 3: PE1 advertises tunnel information related with LSP1 to PE2; Step 4: PE2 gets tunnel information from PE1 and creates TE LSP (e.g. LSP2) according to RRO information derived from LSP1. PE2 binds LSP1 and LSP2 for PW; Step 5: PE2 advertises tunnel information related with LSP2 to PE1; Step 6: PE1 binds LSP1 and LSP2 for PW. Through the above 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 Li, et al. Expires July 20, 2014 [Page 9] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 Active PE Passive PE PE1 PE2 | | |<----Signaling Tunnel Info--->| | | | TE LSP1 for L3VPN | |----------------------------->| | L3VPN | |<---------------------------->| | TE LSP2 for L3VPN | |<-----------------------------| +----+ +--+ +--+ +----+ | PE1|===|P1|======|P2|===| PE2| +----+ +--+ +--+ +----+ | | Figure 5: Framework of L3VPN driven TE Tunnel L3VPN services are provided by [RFC4110]. Figure 5 shows a framework for co-routed MPLS TE LSPs driven by L3VPN. L3VPN is provisioned on PEs and VPN membership is discovered. A pair of PEs for a specific L3VPN are identified as the active PE and the passive PE respectively. The active PE initiates the set up of the primary LSP to the passive PE and advertises the tunnel information to the passive PE. According to the information advertised by the active PE, the passive PE will set up the reverse MPLS TE LSP which is co-routed with the forward LSP from the active PE to the passive PE. 4.2.2. Procedures Li, et al. Expires July 20, 2014 [Page 10] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 PE1 PE2 | (1) VPN Membership Auto-Discorvery | |<----------------------------------------->| | | | (2) active/passive role election | | (Here PE1 is elected as active PE) | |<----------------------------------------->| | | Active PE Passive PE (3)PE1's L3VPN drives RSVP-TE (3) PE2 waits for Tunnel info to create TE LSP(e.g. LSP1) advertised from PE1 |(4) PE1 advertises LSP1 Tunnel info | | to PE2 through L3VPN signaling | |------------------------------------------>| | | (5) PE2 gets forward Tunnel info from PE1, Create TE LSP (e.g. LSP2) according to RRO information of LSP1, Binds LSP1 and LSP2 for L3VPN; |(6) PE2 advertises LSP2 Tunnel info to PE1 | |<------------------------------------------| | | (7)PE1 binds LSP1 and LSP2 for L3VPN; | Co-routed TE LSP Established | |<----------------------------------------->| | | Figure 6: Signaling Procedures of L3VPN driven co-routed TE LSPs Figure 6 shows the detailed procedures for L3VPN to drive the set up of co-routed MPLS TE LSPs. Through the above procedure, the co- routed MPLS TE LSPs driven by the L3VPN are established. 4.2.2.1. VPN Membership Auto-Discovery In order to set up co-routed MPLS TE LSPs in L3VPN, a point-to-point connection between any two VRFs of a particular VPN needs to be established. VPN membership auto-discovery should be done firstly and the mechanism defined in [I-D.dong-l3vpn-pm-framework] can be used. Li, et al. Expires July 20, 2014 [Page 11] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 4.2.2.2. Active/Passive Role Election After obtaining the VPN membership information via VPN membership auto-discovery process, we can identify a pair of VPN members. The active and passive role of PEs can be determined through manual configuration or dynamic election between two PEs. If the dynamic election method is used, LSR IDs of a pair of PEs corresponding to the pair of VPN members are compared as unsigned integers and the PE with the larger value of LSR ID assumes the active role. 4.2.2.3. Signaling Tunnel Information In the service-driven co-routed MPLS TE framework for L3VPN, the tunnel information need to be advertised between the active PE and the passive PE. The passive PE uses the tunnel information to get corresponding MPLS TE tunnel and RRO information which is used to setup the reverse co-routed MPLS TE LSP. MP-BGP signaling need extensions to advertise the MPLS TE tunnel/LSP identifier information for service-driven MPLS TE LSPs for L3VPN. 4.2.2.4. Operation Step 1: VPN membership auto-discovery process is done through signaling to identify a pair of VPN members; Step 2: Active/passive role election through signaling between a pair of PEs of a L3VPN. In this case, assume PE1 as active PE and PE2 as passive PE after election; Step 3: As the active role, L3VPN service on PE1 drives RSVP-TE to create TE LSP(e.g. LSP1), as the passive role, PE2 waits for tunnel information advertised by PE1; Step 4: PE1 advertises tunnel information related with LSP1 to PE2; Step 5: PE2 gets tunnel information from PE1 and creates TE LSP (e.g. LSP2) according to RRO information derived from LSP1. PE2 binds LSP1 and LSP2 for L3VPN; Step 6: PE2 advertises tunnel information related with LSP2 to PE1; Step 7: PE1 binds LSP1 and LSP2 for L3VPN. Through the above procedure, the co-routed MPLS TE LSPs driven by the L3VPN are established. Li, et al. Expires July 20, 2014 [Page 12] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 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. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, 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. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. 7.2. Informative References [I-D.dong-l3vpn-pm-framework] Dong, J., Li, Z., and B. Parise, "A Framework for L3VPN Performance Monitoring", draft-dong-l3vpn-pm-framework-01 (work in progress), April 2013. [I-D.ietf-mpls-return-path-specified-lsp-ping] Chen, M., Cao, W., Ning, S., JOUNAY, F., and S. DeLord, "Return Path Specified LSP Ping", draft-ietf-mpls-return- path-specified-lsp-ping-15 (work in progress), October 2013. Li, et al. Expires July 20, 2014 [Page 13] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 [I-D.ietf-pwe3-mpls-tp-pw-over-bidir-lsp] Chen, M., Cao, W., Takacs, A., and P. Pan, "LDP extensions for Pseudowire Binding to LSP Tunnels", draft-ietf-pwe3 -mpls-tp-pw-over-bidir-lsp-02 (work in progress), November 2013. [I-D.zheng-l3vpn-pm-analysis] Zheng, L., Li, Z., Aldrin, S., and B. Parise, "Performance Monitoring Analysis for L3VPN", draft-zheng-l3vpn-pm- analysis-02 (work in progress), October 2013. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005. [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006. Li, et al. Expires July 20, 2014 [Page 14] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 [RFC4972] Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, "Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, July 2007. [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 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 Li, et al. Expires July 20, 2014 [Page 15] Internet-Draft A Framework for SD Co-Routed LSPs January 2014 Jie Dong Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Li, et al. Expires July 20, 2014 [Page 16]