draft-ietf-l2vpn-vpls-ldp-03.txt   draft-ietf-l2vpn-vpls-ldp-04.txt 
Internet Draft Document Marc Lasserre Internet Draft Document Marc Lasserre
Provider Provisioned VPN Working Group Vach Kompella Provider Provisioned VPN Working Group Vach Kompella
draft-ietf-l2vpn-vpls-ldp-03.txt (Editors) draft-ietf-l2vpn-vpls-ldp-04.txt (Editors)
Expires: October 2004 April 2004 Expires: February 2005 August 2004
Virtual Private LAN Services over MPLS Virtual Private LAN Services over MPLS
draft-ietf-l2vpn-vpls-ldp-03.txt draft-ietf-l2vpn-vpls-ldp-04.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 13 skipping to change at page 2, line 13
ETHERNET]. ETHERNET].
3. Conventions 3. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 document are to be interpreted as described in RFC 2119
RELATED DOCUMENTS RELATED DOCUMENTS
www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2vpn-requirements- www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-01.txt
01.txt www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-03.txt
www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2-framework-03.txt
www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-02.txt www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-02.txt
www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt www.ietf.org/internet-drafts/draft-ietf-pwe3-control-protocol-01.txt
Table of Contents
4. Overview 4. Overview
Ethernet has become the predominant technology for Local Area Ethernet has become the predominant technology for Local Area
Networks (LANs) connectivity and is gaining acceptance as an access Networks (LANs) connectivity and is gaining acceptance as an access
technology, specifically in Metropolitan and Wide Area Networks (MAN technology, specifically in Metropolitan and Wide Area Networks (MAN
and WAN respectively). The primary motivation behind Virtual and WAN respectively). The primary motivation behind Virtual
Private LAN Services (VPLS) is to provide connectivity between Private LAN Services (VPLS) is to provide connectivity between
geographically dispersed customer sites across MAN/WAN network(s), as geographically dispersed customer sites across MAN/WAN network(s), as
if they were connected using a LAN. The intended application for the if they were connected using a LAN. The intended application for the
end-user can be divided into the following two categories: end-user can be divided into the following two categories:
- Connectivity between customer routers LAN routing application - Connectivity between customer routers ű LAN routing application
- Connectivity between customer Ethernet switches LAN switching - Connectivity between customer Ethernet switches ű LAN switching
application application
Broadcast and multicast services are available over traditional Broadcast and multicast services are available over traditional
LANs. Sites that belong to the same broadcast domain and that are LANs. Sites that belong to the same broadcast domain and that are
connected via an MPLS network expect broadcast, multicast and connected via an MPLS network expect broadcast, multicast and
unicast traffic to be forwarded to the proper location(s). This unicast traffic to be forwarded to the proper location(s). This
requires MAC address learning/aging on a per LSP basis, packet requires MAC address learning/aging on a per LSP basis, packet
replication across LSPs for multicast/broadcast traffic and for replication across LSPs for multicast/broadcast traffic and for
flooding of unknown unicast destination traffic. flooding of unknown unicast destination traffic.
skipping to change at page 6, line 52 skipping to change at page 6, line 52
MTU: the MTU of the VPLS MUST be the same across all the PWs in MTU: the MTU of the VPLS MUST be the same across all the PWs in
the mesh. the mesh.
Optional Description String: same as [PWE3-CTRL]. Optional Description String: same as [PWE3-CTRL].
Requested VLAN ID: If the PW type is Ethernet VLAN, this Requested VLAN ID: If the PW type is Ethernet VLAN, this
parameter may be used to signal the insertion of the parameter may be used to signal the insertion of the
appropriate VLAN ID. appropriate VLAN ID.
7.1.2. Address Withdraw Message Containing MAC TLV 7.1.2. Address Withdraw Message Containing MAC TLV
When MAC addresses are being removed or relearned explicitly, e.g., When MAC addresses are being removed or relearned explicitly, e.g.,
the primary link of a dual-homed MTU-s has failed, an Address the primary link of a dual-homed MTU-s (Multi-Tenant Unit switch)
Withdraw Message with the list of MAC addresses to be relearned can has failed, an MAC Address Withdraw Message with the list of MAC
be sent to all other PEs over the corresponding directed LDP addresses to be relearned can be sent to all other PEs over the
sessions. corresponding directed LDP sessions.
The processing for MAC TLVs received in an Address Withdraw Message The processing for MAC List TLVs received in an Address Withdraw
is: Message is:
For each MAC address in the TLV: For each MAC address in the TLV:
- Relearn the association between the MAC address and the - Relearn the association between the MAC address and the
interface/pseudowire over which this message is received interface/pseudowire over which this message is received
For an Address Withdraw message with empty list: For a MAC Address Withdraw message with empty list:
- Remove all the MAC addresses associated with the VPLS instance - Remove all the MAC addresses associated with the VPLS instance
(specified by the FEC TLV) except the MAC addresses learned (specified by the FEC TLV) except the MAC addresses learned
over this link (over the pseudowire associated with the over this link (over the pseudowire associated with the
signaling link over which the message is received) signaling link over which the message is received)
The scope of a MAC TLV is the VPLS specified in the FEC TLV in the The scope of a MAC List TLV is the VPLS specified in the FEC TLV in
Address Withdraw Message. The number of MAC addresses can be the MAC Address Withdraw Message. The number of MAC addresses can be
deduced from the length field in the TLV. deduced from the length field in the TLV.
7.2. MAC Address Withdrawal 7.2. MAC Address Withdrawal
It MAY be desirable to remove or relearn MAC addresses that have It MAY be desirable to remove or relearn MAC addresses that have
been dynamically learned for faster convergence. been dynamically learned for faster convergence.
We introduce an optional MAC TLV that is used to specify a list of We introduce an optional MAC List TLV that is used to specify a list
MAC addresses that can be removed or relearned using the Address of MAC addresses that can be removed or relearned using the LDP
Withdraw Message. Address Withdraw Message.
The Address Withdraw message with MAC TLVs MAY be supported in order The Address Withdraw message with MAC TLVs MAY be supported in order
to expedite removal of MAC addresses as the result of a topology to expedite removal of MAC addresses as the result of a topology
change (e.g., failure of the primary link for a dual-homed MTU-s). change (e.g., failure of the primary link for a dual-homed MTU-s).
If a notification message is sent on the backup link (blocked link), If a notification message is sent on the backup link (blocked link),
which has transitioned into an active state (e.g., similar to which has transitioned into an active state (e.g., similar to
Topology Change Notification message of 802.1w RSTP), with a list of Topology Change Notification message of 802.1w RSTP), with a list of
MAC entries to be relearned, the PE will update the MAC entries in MAC entries to be relearned, the PE will update the MAC entries in
its FIB for that VPLS instance and send the message to other PEs its FIB for that VPLS instance and send the message to other PEs
over the corresponding directed LDP sessions. over the corresponding directed LDP sessions.
If the notification message contains an empty list, this tells the If the notification message contains an empty list, this tells the
receiving PE to remove all the MAC addresses learned for the receiving PE to remove all the MAC addresses learned for the
specified VPLS instance except the ones it learned from the sending specified VPLS instance except the ones it learned from the sending
PE (MAC address removal is required for all VPLS instances that are PE (MAC address removal is required for all VPLS instances that are
affected). Note that the definition of such a notification message affected). Note that the definition of such a notification message
is outside the scope of the document, unless it happens to come from is outside the scope of the document, unless it happens to come from
an MTU connected to the PE as a spoke. In such a scenario, the an MTU connected to the PE as a spoke. In such a scenario, the
message will be just an Address Withdraw message as noted above. message will be just an Address Withdraw message as noted above.
7.2.1. MAC TLV 7.2.1. MAC List TLV
MAC addresses to be relearned can be signaled using an LDP Address MAC addresses to be relearned can be signaled using an LDP Address
Withdraw Message that contains a new TLV, the MAC TLV. Its format Withdraw Message that contains a new TLV, the MAC List TLV. Its
is described below. The encoding of a MAC TLV address is the 6-byte format is described below. The encoding of a MAC List TLV address
MAC address specified by IEEE 802 documents [g-ORIG] [802.1D-REV]. is the 6-byte MAC address specified by IEEE 802 documents [g-ORIG]
[802.1D-REV].
0 1 2 3 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 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 | |U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #1 | | MAC address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC address #n | | MAC address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit U bit
Unknown bit. This bit MUST be set to 0. If the MAC address Unknown bit. This bit MUST be set to 1. If the MAC address
format is not understood, then the TLV is not understood, and MUST format is not understood, then the TLV is not understood, and MUST
be ignored. be ignored.
F bit F bit
Forward bit. This bit MUST be set to 0. Since the LDP Forward bit. This bit MUST be set to 0. Since the LDP
mechanism used here is Targeted, the TLV MUST NOT be forwarded. mechanism used here is Targeted, the TLV MUST NOT be forwarded.
Type Type
Type field. This field MUST be set to 0x0404 (subject to IANA Type field. This field MUST be set to 0x0404 (subject to IANA
approval). This identifies the TLV type as MAC TLV. approval). This identifies the TLV type as MAC List TLV.
Length Length
Length field. This field specifies the total length of the MAC Length field. This field specifies the total length of the MAC
addresses in the TLV. addresses in the TLV.
MAC Address MAC Address
The MAC address(es) being removed. The MAC address(es) being removed.
The LDP Address Withdraw Message contains a FEC TLV (to identify the The LDP Address Withdraw Message contains a FEC TLV (to identify the
VPLS in consideration), a MAC Address TLV and optional parameters. VPLS in consideration), a MAC Address TLV and optional parameters.
skipping to change at page 15, line 41 skipping to change at page 15, line 41
ability to offer all the functionality of the VPLS service. ability to offer all the functionality of the VPLS service.
- Eliminates the need for a full mesh of tunnels and full mesh of - Eliminates the need for a full mesh of tunnels and full mesh of
pseudowires per service between all devices participating in the pseudowires per service between all devices participating in the
VPLS service. VPLS service.
- Minimizes signaling overhead since fewer pseudowires are required - Minimizes signaling overhead since fewer pseudowires are required
for the VPLS service. for the VPLS service.
- Segments VPLS nodal discovery. MTU-s needs to be aware of only - Segments VPLS nodal discovery. MTU-s needs to be aware of only
the PE-rs node although it is participating in the VPLS service the PE-rs node although it is participating in the VPLS service
that spans multiple devices. On the other hand, every VPLS PE-rs that spans multiple devices. On the other hand, every VPLS PE-rs
must be aware of every other VPLS PE-rs device and all of its must be aware of every other VPLS PE-rs device and all of itĆs
locally connected MTU-s and PE-r. locally connected MTU-s and PE-r.
- Addition of other sites requires configuration of the new MTU-s - Addition of other sites requires configuration of the new MTU-s
device but does not require any provisioning of the existing MTU-s device but does not require any provisioning of the existing MTU-s
devices on that service. devices on that service.
- Hierarchical connections can be used to create VPLS service that - Hierarchical connections can be used to create VPLS service that
spans multiple service provider domains. This is explained in a spans multiple service provider domains. This is explained in a
later section. later section.
11.1.3. Spoke connectivity for non-bridging devices 11.1.3. Spoke connectivity for non-bridging devices
skipping to change at page 19, line 11 skipping to change at page 19, line 11
using the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon using the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon
receiving the message, PE-rs nodes flush the MAC addresses receiving the message, PE-rs nodes flush the MAC addresses
associated with that VPLS instance. associated with that VPLS instance.
11.3. Multi-domain VPLS service 11.3. Multi-domain VPLS service
Hierarchy can also be used to create a large scale VPLS service Hierarchy can also be used to create a large scale VPLS service
within a single domain or a service that spans multiple domains within a single domain or a service that spans multiple domains
without requiring full mesh connectivity between all VPLS capable without requiring full mesh connectivity between all VPLS capable
devices. Two fully meshed VPLS networks are connected together using devices. Two fully meshed VPLS networks are connected together using
a single LSP tunnel between the VPLS “border” devices. A single a single LSP tunnel between the VPLS ôborderö devices. A single
spoke pseudowire per VPLS service is set up to connect the two spoke pseudowire per VPLS service is set up to connect the two
domains together. domains together.
When more than two domains need to be connected, a full mesh of When more than two domains need to be connected, a full mesh of
inter-domain spokes is created between border PEs. Forwarding rules inter-domain spokes is created between border PEs. Forwarding rules
over this mesh are identical to the rules defined in section 5. over this mesh are identical to the rules defined in section 5.
This creates a three-tier hierarchical model that consists of a hub- This creates a three-tier hierarchical model that consists of a hub-
and-spoke topology between MTU-s and PE-rs devices, a full-mesh and-spoke topology between MTU-s and PE-rs devices, a full-mesh
topology between PE-rs, and a full mesh of inter-domain spokes topology between PE-rs, and a full mesh of inter-domain spokes
skipping to change at page 20, line 18 skipping to change at page 20, line 18
that corresponds to a VPLS instance would look just like a P-VLAN to that corresponds to a VPLS instance would look just like a P-VLAN to
the bridge portion of the PE-rs and that is why sometimes it is the bridge portion of the PE-rs and that is why sometimes it is
referred to as Emulated VLAN. In this model the PE-rs may need to run referred to as Emulated VLAN. In this model the PE-rs may need to run
STP protocol in addition to split-horizon. Split horizon is run over STP protocol in addition to split-horizon. Split horizon is run over
MPLS-core; whereas, STP is run over the access network to accommodate MPLS-core; whereas, STP is run over the access network to accommodate
any arbitrary access topology. In this model, the PE-rs needs to map any arbitrary access topology. In this model, the PE-rs needs to map
a P-VLAN to a VPLS-instance and its associated pseudowires and vise a P-VLAN to a VPLS-instance and its associated pseudowires and vise
versa. versa.
The details regarding bridge operation for MTU-s and PE-rs (e.g., The details regarding bridge operation for MTU-s and PE-rs (e.g.,
encapsulation format for QinQ messages, customers Ethernet control encapsulation format for QinQ messages, customerĆs Ethernet control
protocol handling, etc.) are outside of the scope of this document protocol handling, etc.) are outside of the scope of this document
and they are covered in [802.1ad]. However, the relevant part is the and they are covered in [802.1ad]. However, the relevant part is the
interaction between the bridge module and the MPLS/IP pseudowires in interaction between the bridge module and the MPLS/IP pseudowires in
the PE-rs device. the PE-rs device.
12.1. Scalability 12.1. Scalability
Given that each P-VLAN corresponds to a VPLS instance, one may think Given that each P-VLAN corresponds to a VPLS instance, one may think
that the total number of VPLS instances supported is limited to 4K. that the total number of VPLS instances supported is limited to 4K.
However, the 4K limit applies only to each Ethernet access network However, the 4K limit applies only to each Ethernet access network
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/