One document matched: draft-wu-l2vpn-vpms-dual-access-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 04:42:38 |