L2VPN B. Wu, Ed. Internet-Draft X. Zhang, Ed. Intended status: Standards Track J. Luo Expires: September 4, 2009 ZTE Corporation R. Chen NJUPT March 3, 2009 Dual Homed Access in Virtual Private Multicast Service draft-wu-l2vpn-vpms-dual-access-00 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 September 4, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Wu, et al. Expires September 4, 2009 [Page 1] Internet-Draft Dual Homed Access in VPMS March 2009 Abstract Virtual Private Multicast Service (VPMS) is defined as a Layer 2 VPN service. It provides point-to-multipoint connectivity for a variety of Layer 2 technologies, including Frame Relay, ATM, Ethernet, PPP, etc, across an IP or MPLS-enabled IP Packet Switch Network (PSN). It is often required for redundant access between two VPMS PEs to which a CE is attached, called "dual-homed". This document describes how dual-homed access can be achieved in the context of BGP-based VPMS. Table of Contents 1. Specification of requirements . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Dual-homed Operation . . . . . . . . . . . . . . . . . . . . . 4 4.1. Sender Dual-homed Access . . . . . . . . . . . . . . . . . 5 4.2. Receiver Dual-homed Access . . . . . . . . . . . . . . . . 5 5. Handling Failures . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. PE-CE link error . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Sender Dual-homed Access . . . . . . . . . . . . . . . 6 5.1.2. Receiver Dual-homed Access . . . . . . . . . . . . . . 6 5.2. PE node error . . . . . . . . . . . . . . . . . . . . . . . 6 6. Multi-AS VPMS . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Wu, et al. Expires September 4, 2009 [Page 2] Internet-Draft Dual Homed Access in VPMS March 2009 1. Specification of requirements 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]. 2. Introduction Virtual Private Multicast Service (VPMS) is categorized as a class of provider-provisioned Layer 2 Virtual Private Networks (L2VPN). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. It is often required for redundant access between the different PEs to which a CE is attached, called "dual-homing". When CE dual-home to two VPMS PEs, it is desired to make a particular PE as the active PE and the other as the backup PE. In the case of the dual-homing access, the backup ingress PE SHOULD be able to filter the incoming traffic which is unnecessary to forward while active PE is working. [VPMS-REQ] explains the requirement of the dual-homing access. This document describes how dual-homing can be achieved in the context of BGP-based VPMS. Section 3 lays out the overview of dual-homing. Section 4 describes the procedures of electing a active PE between the PEs that are dual-homed by a customer site. Section 5 describes How to deal with scenarios in which VPMS spans multiple ASes. Section 6 is about how to do when the link fails to ensure that traffic continues to be transfered. 3. Overview This section describes the basic scenario where dual-homed may be required. Wu, et al. Expires September 4, 2009 [Page 3] Internet-Draft Dual Homed Access in VPMS March 2009 +-----+ | CE1 |--------------+ +-----+ \ VPMS A | | Sender | v AC1 (dual-homed)| +----+ | +-----|VPMS|--------+ | | | PE1| | \ | +----+ | \ AC2 +----+ +----+ AC4 +------>|VPMS| |VPMS|----------+ | PE2| Routed | PE3| \ +----+ Backbone +----+ | AC3 / | | v +-----+ / | | +----+ | CE2 |<-+ | | +-->| CE3| +-----+ | +----+ | | +----+ VPMS A +------|VPMS|-------+ AC5 / VPMSA Receiver | PE4|------------+ Receiver +----+ Figure 1: Dual-homed access support Figure 1 is an example for the dual-homing access topology. The sender CE1 is dual-homed to PE1 and PE2 for redundant connectivity,and receiver CE3 is dual-homed to PE3 and PE4 for redundant connectivity. Sender CE1 may transmit just a single copy of the traffic to either one of the two sender PEs,or to transmit a copy of the traffic to both the PEs simultaneously. According to the [VPMS-REQ], In the dual traffic case, the backup sender PE SHOULD be able to filter the incoming unnecessary traffic while active PE is working. In either case, a protection mechanism of sender PEs will be necessary to handle the traffic appropriately. According to the [VPMS-REQ], in the case of dual-homed access to receiver PEs, PE3 and PE4, a solution MAY allow a receiver CE to receive a single copy of the traffic from either one of the two egress PEs, or receive a copy of the traffic from both PEs simultaneously. This document only describes receiver backup PE will filter the unnecssary traffic while active receiver PE is working. 4. Dual-homed Operation Wu, et al. Expires September 4, 2009 [Page 4] Internet-Draft Dual Homed Access in VPMS March 2009 4.1. Sender Dual-homed Access In the case of dual-homed access to sender PEs, each sender PE belongs to different P2MP PW, and is based on different P2MP PSN, though both sender PEs are belonged to the same VPMS instance. Only one of the two sender PE will be the active PE in case of the sender CE send the traffic to both the PE. [raggarwa-l2vpn-p2mp-pw] provides auto-discovery and signalling based on BGP.This document uses the same procedures. [VPLS-MULTIHOMING] introduces a method to elect one single designated forwarder. This document reuses the procedures described in [VPLS-MULTIHOMING] for designated forwarder election. For details on the procedures, please refer to the above two documents. Based on [VPLS-MULTIHOMING],because all VPMS PEs within the same VPMS domain MUST elect one of the dual-homed sender PEs as the active PE, there SHOULD be an indicator which indicates that the PEs are multi- homed. Such an indicator can be achieved by assigning the same CE ID on PE1 and PE2 for CE1. When remote VPMS PEs receive NLRI advertisement from PE1 and PE2 for CE1, the two NLRI advertisements for CE1 are identified as candidates for designated forwarder selection due to the same CE ID. Thus, same CE ID MUST be assigned on all VPMS PEs that are dual-homed to the same customer site. This doucument assumes the active and backup PSNs are already established.After the election, all the receiver PEs including PE2 in Figure 1 will setup the signalling with the active PE. And all the receiver PEs except PE2 will setup the signalling with the backup PE. When Sender CE1 starts to transmit a copy of the traffic to both the PEs simultaneously.The backup sender PE2 will not forward traffic received from CE1, but as a receiver PE, it will forward the P2MP PW data from the PE1 while active PE is working,including the . 4.2. Receiver Dual-homed Access In the case of dual-homed access to receiver PEs, both receiver PEs belongs to the same P2MP PW. The election procedure is same with the upper section. After the election, the backup receiver PE4 will also setup the signalling with the sender PE like the active receiver PE3 ,but the backup receiver PE4 will filter the incoming unnecessary traffic while active PE3 is working. Wu, et al. Expires September 4, 2009 [Page 5] Internet-Draft Dual Homed Access in VPMS March 2009 5. Handling Failures There are three kinds of common failurs:PE-CE link error, PE node error and PSN core network error. this document only deals with former two error events. 5.1. PE-CE link error 5.1.1. Sender Dual-homed Access In case of link error, In Figure 1, when AC from CE1 to PE1 goes down, this document will use the method in [VPLS-MULTIHOMING], PE1 MUST re-advertise NLRI advertisements with 'D' bit set to one in the control flags instead of withdrawing the advertisements, which means that PE1 is no longer an active PE for CE1. When PE2 receives the advertisement from PE1 with the 'D' bit set, it MUST elect itself as an active PE for CE1 based on the dual-homing path selection rules. Assume that PE1 in figure 1 is the active PE and PE2 is the backup PE, then when PE1 fails, PE2 will deliver the traffic instead.PE2 deliver traffic directly to receiver CE2. 5.1.2. Receiver Dual-homed Access This document uses the same method in the upper section. When PE3 receives the advertisement from PE4 with the 'D' bit set, it MUST elect itself as an active receiver PE for CE4 based on the dual- homed path selection rules. Assume that PE3 in figure 1 is the active receiver PE and PE4 is the backup PE, then when PE3 fails, PE2 will deliver the traffic instead. 5.2. PE node error This section will be described in a future version. 6. Multi-AS VPMS This section will be described in a future version. 7. Security Considerations This section will be described in a future version. Wu, et al. Expires September 4, 2009 [Page 6] Internet-Draft Dual Homed Access in VPMS March 2009 8. IANA Considerations This section will be described in a future version. 9. Acknowledgement Acknowledgement of Fangwei Hu for his input and contributions to initial discussion on BGP. 10. References 10.1. Normative References [L2VPN-P2MP-PW] Aggarwal, R. and Y. Kamite, "draft-raggarwa-l2vpn-p2mp-pw-01", Nov. 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [VPLS-MULTIHOMING] Kompella, K., Kothari, B., and T. Spencer, "draft-kompella-l2vpn-vpls-multihoming-02", Nov. 2008. [VPMS-REQ] Kamite, Y., Jounay, F., Niven-Jenkins, B., Brungard, D., and L. Jin, "draft-ietf-l2vpn-vpms-frmwk-requirements-00", Jan. 2009. 10.2. Informative References [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP Wu, et al. Expires September 4, 2009 [Page 7] Internet-Draft Dual Homed Access in VPMS March 2009 (IBGP)", RFC 4456, April 2006. Authors' Addresses Wu Bo (editor) ZTE Corporation 68 zhijinghua Road,Yuhuatai distinct Nanjing 210000 P.R.China Phone: 86.25.52877276 Email: wu.bo@zte.com.cn URI: http://www.zte.com.cn Zhang Xinquan (editor) ZTE Corporation 68 zhijinghua Road,Yuhuatai distinct Nanjing 210012 P.R.China Phone: 86.25.52871963 Email: zhang.xinquan@zte.com.cn URI: http://www.zte.com.cn Luo Jian ZTE Corporation 68 zhijinghua Road,Yuhuatai distinct Nanjing 210012 P.R.China Phone: 86.25.52870622 Email: luo.jian@zte.com.cn URI: http://www.zte.com.cn Chen Ran NJUPT NO.66 Xinmofan Road,Xuanwu distinct Nanjing 210003 P.R.China Email: Y070912@njupt.edu.cn Wu, et al. Expires September 4, 2009 [Page 8]