One document matched: draft-jiang-l2vpn-vpls-mac-operation-01.txt
Differences from draft-jiang-l2vpn-vpls-mac-operation-00.txt
Network Working Group Y.L., Jiang
Internet Draft Y., Yang
Huawei
Intended status: Standards Track July 3, 2009
Expires: January 3, 2010
Flushing-free MAC Address Operations in VPLS with Redundancy
draft-jiang-l2vpn-vpls-mac-operation-01.txt
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 January 3, 2010.
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.
Jiang Expires Jan 2010 [Page 1]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
Abstract
The Virtual Private LAN Service (VPLS) using Label Distribution
Protocol (LDP) signaling is described in RFC 4762. That document
describes a mechanism called MAC Address Withdrawal to remove or
unlearn MAC addresses which have been dynamically learned in a VPLS
instance. Further work in progress defines an extension to MAC
Address Withdrawal procedure which can greatly restrict the scope of
MAC flushing. This document provides a flushing-free mechanism which
removes the need for MAC address flushing in a VPLS instance. This
mechanism is called MAC Address Switching.
Conventions used in this document
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].
Table of Contents
1. Introduction...................................................2
2. Scenarios......................................................3
3. Flushing-free MAC Address Operations...........................5
4. LDP Extensions.................................................6
5. Sending a MAC Address Switching Message........................7
6. Receiving a MAC Address Switching Message......................8
7. Applicability..................................................9
8. Security Considerations........................................9
9. IANA Considerations...........................................10
10. Acknowledgments..............................................10
11. References...................................................11
11.1. Normative References....................................11
11.2. Informative References..................................11
Author's Addresses...............................................12
1. Introduction
A Virtual Private LAN Service (VPLS) [RFC4664] is created using a
collection of one or more point-to-point pseudowires (PWs)
configured in a flat, full-mesh topology. The mesh topology provides
Jiang Expires Jan 2010 [Page 2]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
a LAN segment or broadcast domain that is fully capable of learning
and forwarding on Ethernet MAC addresses at the PE devices.
A MAC Address Withdrawal mechanism is described in [RFC4762] to
remove or unlearn MAC addresses for faster convergence on topology
changes [RFC4762]. But when a PE device in VPLS receives a MAC Flush
message it may also flush the MAC addresses which are not affected
by the topology change, thus leading to unnecessary flooding and MAC
relearning. [MAC-OPT] describes a solution to optimize the MAC flush
procedure so that only the MAC addresses affected by topology change
are flushed. This may greatly restrict the scope of MAC flushing.
Both of the methods provided by [RFC4762] and [MAC-OPT] must flush
the MAC addresses first, and then re-learn them by flooding all
frames with these MAC addresses as layer 2 destinations. For
traditional Ethernet access network, the number of MAC addresses to
be learned may be very large. For PBB access network, fewer Macs
need to be learnt, but the aggregated flooding frames may be quite a
large amount as the traffic speed is higher. For some unidirectional
unicast service, learning may not be achieved until the service
restarts again. Therefore, this incurs a waste of bandwidth and may
pose a problem of scalability both in the MPLS core and the access
network.
Furthermore, as the IP/MPLS Forum is defining the architecture for
mobile backhaul using MPLS [MPLS20], VPLS plays a more vital role in
the mobile backhaul, with more stringent requirements on service
reliability and availability. For a typical VPLS mobile backhaul
deployment scenario, hundreds or even thousands of base stations are
connected to the RNC and BSC which are dual-homing protected. It is
preferable to keep the VPLS service traffic as intact as possible
while the RNC and the BSC switch their attaching circuits.
This document provides a mechanism which completely removes the
need for MAC address flushing in VPLS instances, thus faster network
convergence can be realized.
2. Scenarios
Dual-homing protection is a common practice in a packet switching
network. It can provide redundancy for VPLS to protect the failure
of an attaching circuit or a spoke PW as described in [RFC4664].
Figure 1 demonstrates a VPLS model where a CE is dual-homed to two
PEs by attaching circuits, while Figure 2 describes a Multi-Tenant
Unit switch (MTU-s) dual-homing protected in an H-VPLS by two spoke
Jiang Expires Jan 2010 [Page 3]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
PWs. In both figures, PW1, PW2 ... till PW6, form the full mesh of
PWs for a VPLS.
For simplicity, both AC and spoke PW are called access link in this
document.
PE1 PE3
+--------+ +--------+
CE5 -----| | | |
| -- | PW1 | -- | CE3
AC1 | / \ |----------------| / \ |--->
/------| \ s/ | PW2 | \S / |
/ | -- | /------| -- |
/ +--------+\ / +--------+
CE1 / | \ / |
+--------+/ | \ / |
| | | \ / |
| | PW5| VPLS Full Mesh Core |PW6
| | | / \ |
| | | / \ |
| | | / \ |
+--------+\ | / \ |
\ +--------+/ \ PW3 +--------+
\ | | \-----| |
\------| -- | PW4 | -- | CE4
AC2 | / \ |-----------------| / \ |--->
| \s / | | \S / |
| -- | | -- |
+--------+ +--------+
PE2 PE4
Figure 1 Dual homed CE in VPLS
Normally, only the primary access link is active, thus PE1 is the
sole PE device for site CE1 or MTU-s to reach the full mesh VPLS.
The MAC addresses located at customer sites (such as CE1 and CE2)
are learned at PE1 over the primary access link. PE2, PE3 and PE4
learn those MAC addresses on their respective PW terminating at PE1
(i.e., PW5, PW1, PW3). This is the MAC learning mechanism described
in [RFC4762].
When the primary access link fails or changes to standby state for
some administration policies, the backup access link is activated,
and then PE2 takes up the role of PE1 to forward the service between
CE1 and the full mesh VPLS. PE1 and PE2 are called the primary PE
and secondary PE respectively in this document.
Jiang Expires Jan 2010 [Page 4]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
For faster convergence, once the backup PW has been made active, PE1
or PE2 should send out a MAC Address Withdraw message to all its
peers in the VPLS, so that the specific MAC addresses are flushed.
According to [RFC4762], PE3 may flush the specified MAC addresses if
MAC list is not empty, or otherwise flush all the MAC addresses
except those learnt over PW2. Whereas in [MAC-OPT], PE3 will only
flush those MAC addresses learnt over PW1. Later, the flooding and
learning procedure are utilized to re-install those flushed FIB
items in both mechanisms.
PE1 PE3
+--------+ +--------+
CE5 -----| | | |
| -- | PW1 | -- | CE3
primary spoke PW | / \ |----------------| / \ |--->
/------| \ s/ | PW2 | \S / |
CE1 / | -- | /------| -- |
\ / +--------+\ / +--------+
\ MTU-s / | \ / |
\+--------+/ | \ / |
| | | \ / |
| -- | PW5| H-VPLS Full Mesh Core |PW6
| / \ | | / \ |
| \S / | | / \ |
| -- | | / \ |
/+--------+\ | / \ |
/ \ +--------+/ \ PW3 +--------+
/ \ | | \-----| |
CE2 \------| -- | PW4 | -- | CE4
backup spoke PW| / \ |-----------------| / \ |--->
| \s / | | \S / |
| -- | | -- |
+--------+ +--------+
PE2 PE4
Figure 2 Dual homed MTU-s in H-VPLS
3. Flushing-free MAC Address Operations
PEs may switch those forwarding items affected by the topology
change rather than flushing them, this mechanism is called MAC
address switching in this document.
After detection of the failure of the primary access link, PE1 sends
out a "MAC Address Switching" message to all its peer PEs in the
VPLS, with addresses of PE1 and PE2 in the message, and with a MAC
list of the MAC addresses associated with the access link to be
Jiang Expires Jan 2010 [Page 5]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
switched, or with a null MAC list when all access link attached to
PE1 in the same VPLS are to be switched. The message format for MAC
Address Switching is defined in section 4.
If PE1 fails, and all access links in the same VPLS are switched to
PE2, then PE2 may send out a "MAC Address Switching" message with a
null MAC list.
Upon receipt of this message, a PE other than the dual-homing peer
(such as PE3) can identify two PWs, one terminating on the primary
PE, and the other terminating on the secondary PE. As there is only
one unique PW between any PE pair in a VPLS, this is a
straightforward PE lookup. Then the PE should switch the MAC
addresses in its MAC table based on MAC list carried in the message
and these PWs. The same process also applies to PE4 when it receives
the message.
PE1 can actively switch the MAC addresses in its MAC table which are
associated with the failed access link to the PW between PE1 and PE2
(i.e., PW5), so that traffic from CE5 to CE1 can take the new route
consists of PW5 and the secondary access link. As the split horizon
rule always prevents PE1 from forwarding packets received over the
core oriented PWs on the PW mesh again, no loops can be formed in
the VPLS. The MTU-s in Fig. 2 may also switch its MAC tables from
the primary spoke PW to the secondary spoke PW. As no signaling is
required for this kind of switching, it will not be discussed
further.
For each dual-homing access link, PE1 and PE2 should be configured
with its dual-homing peer's address, otherwise, service provider
cannot protect the CE proactively. The configuration may be
provisioned statically or dynamically by protocols such as [ICCP],
but this is out scope of this document.
4. LDP Extensions
A new MAC Address Switching message is defined in this section.
Jiang Expires Jan 2010 [Page 6]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Address Switching (0x0302) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address List TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWid FEC TLV or Generalized PWid FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC Address List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 MAC Address Switching Message
Message Type, this field identifies the type of LDP message "Address
Switching" and MUST be set to 0x0302. This value needs IANA approval.
Message Length, Specifies the cumulative length in octets of the
Message ID, Address List TLV, PWid FEC TLV or Generalized PWid FEC
TLV, and MAC list TLV.
Message ID, a 32-bit value used to identify this message.
Address List TLV, this TLV is defined in section 3.4.3 of [RFC5036],
it MUST carry two addresses each uniquely identifies one of the
dual-homing PEs, the first MUST be set as the PE where the access
link being switched terminates, and the second MUST be set as the PE
where the access link switched to terminates.
PWid FEC TLV or Generalized PWid FEC TLV, these TLVs are first
defined in section 5 of [RFC4447] and then extended in section 6 of
[RFC4762]. This field identifies the VPLS instance for this message.
MAC List TLV, this field is defined in section 6.2.1 of [RFC4762].
This TLV SHOULD carry all the MAC addresses learned on the access
link being switched. If all the access links for this VPLS instance
terminating on the primary PE are to be switched to the same
secondary PE (PE2), then the MAC List TLV SHOULD be null.
5. Sending a MAC Address Switching Message
If the primary access link fails, or turns to standby for some
administration reasons, the primary PE node (i.e., PE1 in Fig.1 and
Fig.2) MAY send out a MAC Address Switching message to its peer PEs
Jiang Expires Jan 2010 [Page 7]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
in the same VPLS instance (i.e. PE2, PE3, and PE4). This MAC Address
Switching message MUST carry the addresses of the dual-homing peers
in the Address List TLV, the VPLS identifier in the PWid TLV or
Generalized PWid TLV, and the MAC addresses learned on the access
link being switched in a MAC List TLV. If all the access links
terminated on PE1 for this VPLS instance are to be switched to the
same secondary PE (PE2), then the MAC List TLV SHOULD be null.
Upon the failure of the primary PE (PE1), the secondary PE (PE2) can
also trigger the MAC switching signaling when it has the knowledge
that all access links in a VPLS on PE1 will be switched to itself.
On that condition, it MAY send out a MAC Address Switching message
with a null MAC List TLV to all its peers in this VPLS.
6. Receiving a MAC Address Switching Message
Upon receipt of a MAC Address Switching message, a PE node SHOULD:
- Extract the VPLS identifier from the PWid or Generalized PWid TLV;
- Extract the two addresses from the Address List TLV, and lookup
the PWs terminating on these addresses in the VPLS instance.
- If two PWs, PW1 and PW2, are found, then
. If MAC List TLV is null, then for each MAC addresses in the MAC
address table which is associated with PW1:
Associate the MAC address with PW2 in the MAC address table.
. Otherwise, for each MAC address in the MAC List TLV:
Associate the MAC address with PW2 in the MAC address table.
- Else if only one PW is found, then
. If MAC List TLV is null, then for each MAC addresses in the MAC
address table which is associated this PW:
Remove the MAC address in the MAC address table.
. Otherwise, for each MAC address in the MAC List TLV:
Remove the MAC address in the MAC address table.
- Else the PE MUST ignore this message and MAY log an error locally.
Jiang Expires Jan 2010 [Page 8]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
If the Message Type is unknown, a notification message MUST be
returned to the message originator.
7. Applicability
This document defines a MAC Address Switching procedure. Its
application SHOULD be in the VPLS deployment where the least
disturbance on the service is needed. The use of MAC Address
Switching procedure is OPTIONAL and MAY be combined with other MAC
Address Withdraw procedures, such as sending a MAC Address Switching
message to some PE nodes and sending a MAC Address Withdraw message
to some other PE nodes. The policy for this mechanism is out of
scope of this document.
8. Security Considerations
This section is to be enhanced in a future revision of this document.
- Control plane aspects
- LDP security (authentication) methods as described in
[RFC5036] are applicable here. Further security
considerations in [RFC4447] and [RFC4762] also apply to this
document.
- Data plane aspects
- The mechanism specified in this document can mitigate the
flooding behavior in VPLS.
Jiang Expires Jan 2010 [Page 9]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
9. IANA Considerations
IANA maintains a registry of LDP code-points at "Label Distribution
Protocol (LDP) Name Spaces". There is a sub-registry for LDP message
types called "Message Type Name Space".
IANA is requested to allocate a new message types from the range
0x300-0x3ff. The following value is suggested:
Message Name Type
Address Switching 0x0302
10. Acknowledgments
The authors would like to thank Adrian Farrel, Ben Mack-Crane, Shane
Amante and Dan Li for their valuable comments and suggestions.
This document was prepared using 2-Word-v2.0.template.dot.
Jiang Expires Jan 2010 [Page 10]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] Martini, L., et al, "Pseudowire Setup and Maintenance
Using Label Distribution Protocol (LDP)", RFC 4447, April
2006.
[RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN
Services using LDP", RFC 4762, January 2007.
[RFC5036] Andersson, L., Minei, I., et al, "LDP Specification", RFC
5036, October 2007.
11.2. Informative References
[RFC4664] Andersson, L., and Rosen, E., "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664, September
2006.
[MPLS20] IP/MPLS Forum 20.0.0, "MPLS in Mobile Backhaul Networks
Framework and Requirements", October, 2008
[MAC-OPT] Dutta, P., and Lasserre, M., "LDP Extensions for Optimized
MAC Address Withdrawal in H-VPLS", draft-ietf-l2vpn-vpls-
ldp-mac-opt-00, work in progress.
[ICCP] Martini, L., et al, "Inter-Chassis Communication Protocol
for L2VPN PE Redundancy", draft-ietf-pwe3-iccp-00, work in
progress
Jiang Expires Jan 2010 [Page 11]
Internet-Draft draft-jiang-l2vpn-vpls-mac-operation-01.txt July 2009
Author's Addresses
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: yljiang@huawei.com
Yang Yang
Huawei Technologies Co., Ltd.
Bantian industry base, Longgang district
Shenzhen, China
Email: Y.Yang@huawei.com
Jiang Expires Jan 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 04:14:15 |