Internet DRAFT - draft-cowburn-l2vpn-vpls-ldp-mac-hiding
draft-cowburn-l2vpn-vpls-ldp-mac-hiding
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]
