Internet Draft MAC Hiding in an H-VPLS Environment September 2006 Internet-Draft Ian Cowburn L2VPN Working Group (Editor) Expires: March, 2007 September, 2006 MAC Hiding in an H-VPLS Environment draft-cowburn-l2vpn-vpls-ldp-mac-hiding-01.txt Status of this Memo 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. IPR Disclosure Acknowledgement By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This Internet-Draft will expire March, 2007. Abstract This document describes a mechanism for hiding customer MAC addresses on a PE-rs in an H-VPLS environment. In the H-VPLS hierarchy, a PE-rs is exposed to the MAC addresses for customers on its directly attached MTU-s and the remote MAC addresses for all of its configured VPLS instances. This can result in the requirement to store a large number of a MAC addresses. This document introduces the concept of an MTU-id per MTU-s which is included with the customer frame sent by an MTU-s. The PE-rs is then able to switch based on the MTU-id rather than the customer MAC addresses, thereby reducing the address storage requirements on the PE-rs to be of the order of the number of MTU-s. Cowburn Expires March, 2007 [Page 1] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 1. 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]. 2. Table of Contents 1. Conventions used in this document............................2 2. Table of Contents............................................2 3. Acronyms.....................................................2 4. Introduction.................................................3 5. Overview.....................................................3 6. MAC Hiding Control Word Format...............................4 7. Reserved MTUids..............................................5 8. Signaling MAC Hiding Capability via LDP......................5 9. Customer Separation..........................................6 10. Maintaining the Forwarding Paradigm.........................7 11. Handling Broadcast, Unknown and Multicast...................7 12. MAC Withdraws...............................................7 12.1. Optional MTUid TLV in MAC Withdraw........................8 12.2. Processing MTUid TLV......................................8 13. Operation of MAC Hiding.....................................9 13.1. On an MTU-s...............................................9 13.2. On a PE-rs................................................9 13.3 On a PE-rs with Directly Connected Customers..............10 14. Interoperability with Non MAC Hiding Devices...............10 15. Inter-Provider Communications..............................10 16. Contributors...............................................12 17. Security Considerations....................................12 18. IANA Considerations........................................12 19. References.................................................12 19.1. Normative References.....................................12 120. Appendix: Adding MAC Hiding to an H-VPLS Network..........13 21. Author's Address...........................................13 3. Acronyms LDP Label Distribution Protocol MTUid A unique 14 bit identifier assigned to an MTU-s or PE-rs within an H-VPLS network MTU-s Multi-Tenant Unit switch PE-rs Provider Edge device capable of routing and bridging PW Pseudo-wire Cowburn Expires March, 2007 [Page 2] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 VLAN Virtual LAN 4. Introduction The Virtual Private LAN Service (VPLS) solution [VPLSLDP] includes a hierarchical model to provide hub and spoke connectivity and thus more scalability in terms of the number of devices in a VPLS network. In such an H-VPLS network, the MTU-s must learn all of the MAC addresses related to its directly connected customers in order to perform the correct switching, therefore MAC hiding is not possible on the MTU-s. The PE-rs is also exposed to customer MAC addresses as it terminates pseudowires from the MTU-s and other PE-rs. Therefore the PE-rs needs to learn MAC addresses for customers on its directly attached MTU-s and the remote MAC addresses for all of its configured VPLS instances. This can result in the requirement to store a large number of a MAC addresses. When H-VPLS is extended to multi-domain, the border PE-rs needs to learn MAC addresses for all of its inter- domain customers, possibly leading to an even larger storage requirement. To reduce the MAC storage requirements on the PE-rs, each MTU-s is assigned an identifier (MTUid) which is included with the customer frames sent from the MTU-s. After learning the MTUids related to a given customer, the PE-rs is able to switch frames based on the destination MTUid for that customer. At this point, the PE-rs need only learn MTUids and not all of the MAC addresses on the MTU-s. This will drastically reduce the storage requirements on the PE-rs with a scaling of the order of NxC (N=number of MTU-s per customer, C=number of customers). The mechanism described aims to utilize existing protocols and standards as far as possible, minimize the additional overhead per frame and maintain the current forwarding paradigm used for switching L2 frames. It also continues with the benefits of an MPLS based infrastructure, such as fast failover and traffic engineering. Consideration is given to interoperating with non-MAC-hiding capable devices. A description of how an existing network could be migrated to MAC hiding is given in an appendix. 5. Overview Each device participating in the MAC hiding mechanism in the H-VPLS network is assigned a unique identifier (MTUid). This is a 14 bit number which needs to be managed and assigned by the service provider, allowing approximately 16 thousand MTU-s per H-VPLS network (noting that some of the MTUid space is reserved). Cowburn Expires March, 2007 [Page 3] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 The destination and source MTUids are sent using a pseudowire control word of a new type that is pre-pended to customer frames. [RFC4385] currently defines two code points, 0x0 and 0x1. This proposal extends [RFC4385] by introducing a new code point. This results in an extra 4 byte overhead for customer frames using the MAC hiding mechanism. The ability to send and receive frames containing this control word is signaled via LDP. The MTU-s sends frames with the control word to the adjacent PE-rs on a customer specific pseudowire. The PE-rs receives these frames, removes the MPLS header and examines the control word. The source MTUid (if unknown) is learned and then the frame is forwarded (including the control word) on the appropriate pseudowire towards the MTU-s identified by the destination MTUid. When the frame is received by the egress MTU-s, the MPLS headers and control word are removed, the source MTUid learned (if unknown) and the frame is sent to the destination customer based on the input pseudowire, VLAN and destination MAC address. The following sections will describe the format of the control word added, the signaling of the MAC hiding capability and the detailed operation of the network using MAC hiding. 6. MAC Hiding Control Word Format The MAC hiding control word (MHCW) used to carry the MTUids with the customer frames is based on the definition in [RFC4385], the format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x| dest MTUid | src MTUid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bits 0 to 3 represent a new code point to indicate the use of the MHCW. Its value will be assigned by IANA (e.g. 0x2). Bits 4 to 17 represent the destination MTUid. This will be either the MTUid of the destination MTU-s for unicast traffic, or one of the reserved MTUids (see section 7). Bits 18 to 31 represent the source MTUid. This will be the MTUid of the source MTU-s. Cowburn Expires March, 2007 [Page 4] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 7. Reserved MTUids The following MTUids are reserved 3FFF Destination MTUid for broadcast MAC destination 3FFE Destination MTUid for multicast MAC destination 3FFD Destination MTUid for unknown MAC destination 3FFC Destination MTUid for frames to be processed by the PE-rs. 3F00-3FFB Future use The broadcast destination MTUid MUST be supported and it MUST be used for broadcast frames. The broadcast MTUid SHOULD by default also be used for multicast and unknown destination frames, alternatively, the multicast and unknown destination MTUids MAY be supported for multicast and unknown destination frames respectively. A device not supporting the multicast or unknown MTUids MUST process them when received in the same way as the broadcast MTUid. The PE-rs processing MTUid MAY be supported to identify frames that need to be processed by PE-rs. This can be viewed as similar to an IP Router Alert. The details of the processing performed are beyond the scope of this document but are expected to be based on the contents of the frame beyond the MTUid. The processing may involve consuming the frame with or without forwarding it. An application of this could be for OAM purposes. These frames may be discarded or forwarded to another provider based on local policies. A device not supporting this MTUid MUST process it when received in the same way as a broadcast MTUid within the provider’s network. These reserved MTUids MUST not be used for the source MTU-id. Uniquely identifying broadcast, multicast and unknown destinations would allow control and visibility of these frames types on the PE- rs, e.g. for statistics gathering. Section 13 describes the operation for these MTUids. 8. Signaling MAC Hiding Capability via LDP The ability to send and receive frames with a control word containing the source and destination MTUid is signaled via an optional parameter in the PWid FEC TLV (FEC=128) or in an Interface Parameters TLV in the LDP Generalized PWid FEC TLV(FEC 129) as a sub-TLV as defined in [RFC4447]. The MAC hiding parameter ID is defined in [RFC4446] (to be assigned). Cowburn Expires March, 2007 [Page 5] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLV | Length | MTUid |0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bits 0 to 7 represent the sub-TLV type and MUST be set to 0x0D (subject to IANA approval). This identifies the MAC hiding parameter ID. Bits 8 to 15 represent the length of the interface parameter including the parameter id and length field itself. This MUST be set to 0x04 Bits 16 to 29 represent the MTUid of this device. If both peers indicate the support of MAC hiding by including this parameter then control words MUST be added/removed to/from frames switched on this pseudowire after it has been enabled. If both peers do not indicate the support of MAC hiding the PW MUST NOT be enabled. 9. Customer Separation Pseudowires are used to provide customer separation, specifically the traffic for each customer is switched in a single pseudowire between each MTU-s/PE-rs. Consequently the MTUids are learned on the PE-rs on a pseudowire basis, i.e. MTUids are learned for each set of pseudowires belonging to a given customer, hence minimizing storage requirements on the PE-rs for MTUids. Since PE-rs are VLAN-unaware, flooding can be sub-optimal. If all of the customer's VLANs span all of its sites then this is not an issue, however, if this is not the case then traffic may be flooded to an MTU-s/PE-rs on which its VLAN is not configured. Three options are possible: a) If the amount of flooding is minimal, then maintain a pseudowire per customer with traffic flooded to an MTU-s/PE-rs without the VLAN(s) concerned. The MTU-s/PE-rs would drop this traffic. b) Use a set of pseudowires per customer topology (instead of per customer). This will result in optimal flooding but will increase the storage requirements for MTUids to the order of NxT (N=number of MTU-s per customer, T=number of topologies). c) Allow learning on MTUids on the PE-rs per VLAN per pseudowire. This will result in optimal flooding but will increase the storage requirements for MTUids to the order of NxCxV (N=number of MTU-s per customer, C=number of customers, V=number of VLANs per customer). Cowburn Expires March, 2007 [Page 6] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 Option (a) will use bandwidth un-necessarily while options (b) and (c) will require more storage space for MTUids. 10. Maintaining the Forwarding Paradigm In order to preserve existing frame forwarding implementations based on destination MAC address lookup, as defined in [VPLSLDP], a PE-rs MAY pre-pend a locally significant OUI to the MTUids to expand the MTUid to 48 bits for internal processing, i.e. pre-pend a 34 bit value. This allows the PE-rs to internally treat the MTUids in the same manner as MAC addresses, specifically the learning, switching and aging mechanisms of standard L2 forwarding can be preserved. Note that this pre-pended OUI is only locally significant so is not included with the MTUids in frames sent out of the PE-rs. 11. Handling Broadcast, Unknown and Multicast Broadcast frames MUST be sent by the MTU-s using the broadcast MTUid and these frames are flooded by the PE-rs to all pseudowires belonging to this customer. Unknown and multicast frames SHOULD by default be sent by an MTU-s using the broadcast MTUid and be flooded by the PE-rs to all pseudowires belonging to this customer. The multicast MTUid MAY be used when a more efficient distribution of multicast traffic is needed. This is for further study. The unknown MTUid type MAY be used when it is useful to separately identify unknown unicast destination traffic at the PE-rs. This is for further study. Section 7 defined these reserved MTUids. 12. MAC Withdraws [VPLSLDP] defines the processing for flushing learned MAC addresses using MAC withdraws with a MAC list TLV containing explicit MAC addresses or with an empty MAC list TLV. Given that PE-rs do not learn the customer MAC addresses when using MAC hiding, the MAC list TLV containing explicit MAC addresses SHOULD not be sent by an MTU-s on a pseudowire using MAC hiding. An MTU-s MAY send an empty MAC list TLV and the processing on the PE-rs would continue as defined in [VPLSLDP]. Cowburn Expires March, 2007 [Page 7] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 As the source MTUid in the MHCW identifies the MTU-s involved in the topology change, a new MAC withdraw option is defined to allow the flushing of MAC addresses to be specific to the MTU-s concerned in the topology change. 12.1. Optional MTUid TLV in MAC Withdraw A new MTUid TLV is defined which MAY be included as an optional parameter in the LDP Address withdraw message, as defined in [RFC3036], with an empty MAC list TLV. The MTUid TLV contains the MTUid of the device generating the MAC withdraw. The format is as follows and is based on the standard LDP TLV encoding as defined in [RFC3036] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| MTUid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U bit: Unknown bit. This bit MUST be set to 1. F bit: Forward bit. This bit MUST be set to 0. Since the LDP mechanism used here is targeted, the TLV MUST NOT be forwarded. Type: Type field. This field MUST be set to 0x0002 (subject to IANA approval). This identifies the TLV type an MTUid TLV. Length: Length field. This field specifies the total length in octets of the MTUid in the TLV. The length MUST be 2. 12.2. Processing MTUid TLV The MTUid TLV MAY be added to MAC withdraw message containing an empty MAC list TLV when such a message is sent by an MTU-s over a pseudowire on which MAC hiding is enabled (see section 8). When a PE-rs receives a MAC withdraw containing an MTUid TLV it flushes the specified MTUid, or alternatively a more optimal action is to move the association of the MTUid (if one exists) to the pseudowire on which the MAC withdraw was received. If the PE-rs is operating in MTU-s mode (see section 13.2) the MTUid TLV MUST be ignored and the empty MAC list TLV processed as defined in [VPLSLDP]. Note that if a PE-rs receives a MTUid TLV and does not support or understand it, it MUST ignore the message. Cowburn Expires March, 2007 [Page 8] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 13. Operation of MAC Hiding This section describes the detailed operation for MAC hiding on an MTU-s and a PE-rs. 13.1. On an MTU-s When a customer frame is to be switched from a local port to a PE-rs, the MTU-s firstly learns the source MAC address of the frame in the related VLAN as it would with standard H-VPLS, this is used to forward frames back to that source address. The MTU-s MUST then pre-pend a MHCW before forwarding it on the pseudowire to the PE-rs. The MHCW MUST contain the MTU-id of this MTU-s as the source MTUid and one of the following for the destination MTUid a) If the frame has a destination MAC of ff:ff:ff:ff:ff:ff then the destination MTUid MUST be 3FFF b) If the frame destination MAC is a multicast address then the destination MTUid MUST be either 3FFF or 3FFE c) If the frame destination MAC is an unknown address then the destination MTUid MUST be either 3FFF or 3FFD d) If it is required that the downstream PE-rs should process the frame, then the destination MTUid SHOULD be 3FFC e) If the destination MAC has been learned in this VLAN from a remote MTU-s/PE-rs then the destination MTUid MUST be set to the MTUid of that remote device. When a customer frame is received from a PE-rs on a pseudowire, the MPLS header and MHCW are removed. The frame is then switched to the customer port(s) based on the destination MAC address and VLAN. The MTU-s MUST maintain a mapping between the source MAC of the received frame and the pseudowire/VLAN and source MTUid. This mapping is used to obtain the destination MTUid when sending frames to this source MAC for this pseudowire/VLAN combination. 13.2. On a PE-rs When a frame is received on a pseudowire, the MPLS header is removed and the MHCW examined. If the source MTUid is unknown on this pseudowire, then this MTUid is learned to be reachable via this inbound pseudowire. The frame is switched, together with the received MHCW (i.e. the MHCW remains unchanged), as follows: a) If the destination MTUid is 3FFF (broadcast) or 3FFD (unknown), or if the destination MTUid is unknown, the frame MUST be flooded Cowburn Expires March, 2007 [Page 9] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 to all other pseudowires belonging to this customer as defined by the normal H-VPLS procedures. b) If the destination MTUid is unknown, the frame MAY be discarded if received over an inter-provider link (see section 15), otherwise the frame SHOULD be flooded to all other pseudowires belonging to this customer as defined by the normal H-VPLS procedures. c) If the destination MTUid is 3FFE (multicast) the frame SHOULD be flooded to all other pseudowires belonging to this customer as defined by the normal H-VPLS procedures. Note that allowing a more efficient distribution of multicast is for further study. d) If the destination MTUid is 3FFC the frame SHOULD be processed by the PE-rs. e) If the destination MTUid has been learned on a pseudowire for this customer, the frame is forwarded on that pseudowire. The PE-rs MAY be VLAN-aware, in which case the MTUid learning and frame forwarding is based on pseudowire AND VLAN. 13.3 On a PE-rs with Directly Connected Customers If a PE-rs has directly connected customers then it must be exposed to the MAC addresses associated with those customers in order to switch their frames correctly. Therefore the PE-rs MUST operate in MTU-s mode for these customers, i.e. the PE-rs performs the MAC hiding operation of an MTU-s. While this allows directly connected customers, it also eliminates the benefits of MAC hiding on this PE- rs for this customer. 14. Interoperability with Non MAC Hiding Devices An MTU-s without MAC hiding support can be connected to a PE-rs using MAC hiding. The PE-rs will operate in MTU-s mode for the customers residing on this MTU-s, loosing the benefits of MAC hiding for these customers only on this PE-rs. Similarly, a PE-rs without MAC hiding support can be connected to other PE-rs using MAC hiding. The MAC hiding PE-rs will operate in MTU-s mode for the customers residing on the PE-rs without MAC hiding and it's directly connected MTU-s. Again the benefits of MAC hiding are lost for these customers throughout the H-VPLS network. 15. Inter-Provider Communications This mechanism is also applicable to inter-provider communication where customers span multiple providers. If two providers are using MAC hiding then it may be useful to extend it to the inter-provider Cowburn Expires March, 2007 [Page 10] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 connection between the two in order to reduce MAC address storage requirements at that point. The two provider networks interconnect via one or more PE-rs from each network; the mechanism used is beyond the scope of this document. Each provider will have assigned the MTUids within their network. At the inter-connection point there needs to be a translation function between MTUids in each network. To perform the translation, each provider assigns one virtual MTUid (from its MTUid space) for each MTUid with which it will communicate in the other provider’s network. This maintains local control over MTUid assignment. As frames exit from one provider, the destination MTUid in the MHCW is translated from the virtual MTUid to its corresponding MTUid in the other provider’s network (unless it is one of the reserved MTUids). Any frames for which there is no translation for the destination MTUid (excluding the reserved MTUids) MUST not be transmitted over the inter-provider link. Subsequently when frames are received by the other provider, the source MTUid is translated to the corresponding virtual MTUid within its network. Any frames for which there is no translation for the source MTUid at this point MUST be discarded. Any frames with a destination MTUid not configured within this customer's VPLS instance MAY be discarded to police incoming frames and avoid flooding them throughout the customer’s VPLS instance within the receiving provider's network. While it is possible to implement more complex filtering rules such as based upon a subset of the customer's sites/MTU-s that can communicate between them, it is not in the scope of this document to describe such capabilities. Each provider sees within their network only MTUids that they have assigned, these being for their devices and the virtual MTUids for devices in the other provider’s network with which some of their customers communicate. It is expected that the translation table is manually provisioned by each provider on the PE-rs which has an inter-provider link. As an example, consider a customer with one site connected to device X (MTUid=101) in provider A and another site connected to device Y (MTUid=200) in provider B. Provider A assigns Y a virtual MTUid=501, while provider B assigns X a virtual MTUid=800. The translation table for each provider is as follows Provider A: Device Local Remote Provider B: Device Local Remote X 101 X 800 101 Y 501 200 Y 200 Cowburn Expires March, 2007 [Page 11] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 When a frame is sent from X to Y, as it leaves X the source MTUid is 101 and the destination MTUid is 501. On the PE-rs connected to the inter-provider link in provider A, the destination MTUid is translated from 501 to 200. The frame is then sent to provider B. On the entry PE-rs in provider B, the source MTUid is translated from 101 to 800. Therefore, the MHCW of the frame as it arrives at Y has a source MTUid of 800 and destination MTUid of 200. 16. Contributors Richard Foote, Lucent Prashanth Ishwar, Lucent Vipin Jain, Lucent Marc Lasserre, Lucent Koosh Mohajeri, Lucent John Rigby, Lucent 17. Security Considerations This document does not introduce new security issues. The security considerations pertaining to the original [VPLSLDP] specification remain relevant. 18. IANA Considerations The code point used to indicate the use of the control word for MAC hiding is defined as 0x2 in section 6 and is subject to IANA approval. The MAC hiding parameter ID used to signal the MAC hiding capability is defined as 0x0D in section 8 and is subject to IANA approval. 19. References 19.1. Normative References [VPLSLDP] "Virtual Private LAN Services Using LDP", draft-ietf-l2vpn-vpls-ldp-09.txt, Work in Progress, June 2006. [RFC4385] "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", Bryant et al., RFC 4385, February 2006. [RFC4447] "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) ", L. Martini et al., RFC4447, April 2006 Cowburn Expires March, 2007 [Page 12] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 [RFC4446] "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", L. Martini, RFC 4446, April 2006. [RFC3036] " LDP Specification ", L. Andersson et al., RFC 3036, January 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 20. Appendix: Adding MAC Hiding to an H-VPLS Network The following are proposed steps to add MAC hiding to an existing H- VPLS network. a) Upgrade the devices to MAC hiding capable software b) Configure the MTUid on the devices, with directly connected customers, that are performing MAC hiding c) Enable MAC hiding on the pseudowires This signals the MAC hiding capability to the LDP peer. If both peers support MAC hiding then control words MUST be added/removed to/from frames switched on this pseudowire. It SHOULD be possible to view the relationship between the MAC addresses/VLANs/pseudowire and the MTUids to verify their mapping is correct. d) Enable switching frames on the PE-rs based on MTUids instead of MAC addresses. This can be enabled a. EITHER On an on-going basis as pseudowires are enabled for MAC hiding. If a PE-rs has any pseudowire for a given customer that is not MAC hiding enabled then it MUST operate as an MTU- s for that customer, specifically it MUST forward frames on the non-MAC hiding pseudowires without a control word. b. OR When all pseudowires for this customer on all MTU-s/PE-rs have MAC hiding enabled. This would allow verification of the MAC addresses/VLANs/pseudowire to MTUids mapping before switching based on MTUids. 21. Author's Address Ian Cowburn Lucent Technologies Email: cowburn@lucent.com IPR Disclosure Acknowledgement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such Cowburn Expires March, 2007 [Page 13] Internet Draft MAC Hiding in an H-VPLS Environment September 2006 rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Copyright Notice Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cowburn Expires March, 2007 [Page 14]