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]