Internet DRAFT - draft-wu-l2vpn-vpms-dual-access

draft-wu-l2vpn-vpms-dual-access






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]