draft-ietf-l2vpn-vpls-ldp-00.txt   draft-ietf-l2vpn-vpls-ldp-01.txt 
Internet Draft Document Marc Lasserre Internet Draft Document Marc Lasserre
Provider Provisioned VPN Working Group Riverstone Networks Provider Provisioned VPN Working Group Riverstone Networks
draft-ietf-l2vpn-vpls-ldp-00.txt Vach Kompella draft-ietf-ppvpn-vpls-ldp-01.txt Vach Kompella
Nick Tingle Nick Tingle
Sunil Khandekar Sunil Khandekar
Timetra Networks Timetra Networks
Ali Sajassi Ali Sajassi
Cisco Systems Cisco Systems
Pascal Menezes Loa Andersson Pascal Menezes Loa Andersson
Terabeam Networks Consultant Terabeam Networks Consultant
skipping to change at page 1, line 29 skipping to change at page 1, line 29
Juha Heinanen Giles Heron Juha Heinanen Giles Heron
Song Networks PacketExchange Ltd. Song Networks PacketExchange Ltd.
Ron Haberman Tom S.C. Soon Ron Haberman Tom S.C. Soon
Masergy, Inc. Yetik Serbest Masergy, Inc. Yetik Serbest
Eric Puetz Eric Puetz
Nick Slabakov SBC Communications Nick Slabakov SBC Communications
Rob Nath Rob Nath
Riverstone Networks Riverstone Networks
Luca Martini Luca Martini
Vasile Radaoca Level 3 Vasile Radoaca Level 3
Nortel Networks Communications Nortel Networks Communications
Expires: December 2003 June 2003 Expires: May 2004 November 2003
Virtual Private LAN Services over MPLS Virtual Private LAN Services over MPLS
draft-ietf-l2vpn-vpls-ldp-00.txt draft-ietf-ppvpn-vpls-ldp-01.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 3, line 25 skipping to change at page 3, line 25
5.4. Loop free L2 VPN..............................................7 5.4. Loop free L2 VPN..............................................7
6. Discovery.......................................................7 6. Discovery.......................................................7
7. Control Plane...................................................7 7. Control Plane...................................................7
7.1. LDP Based Signaling of Demultiplexors.........................7 7.1. LDP Based Signaling of Demultiplexors.........................7
7.2. MAC Address Withdrawal........................................9 7.2. MAC Address Withdrawal........................................9
7.2.1. MAC TLV.....................................................9 7.2.1. MAC TLV.....................................................9
7.2.2. Address Withdraw Message Containing MAC TLV................10 7.2.2. Address Withdraw Message Containing MAC TLV................10
8. Data Forwarding on an Ethernet VC Type.........................11 8. Data Forwarding on an Ethernet VC Type.........................11
8.1. VPLS Encapsulation actions...................................11 8.1. VPLS Encapsulation actions...................................11
8.1.1. VPLS Learning actions......................................12 8.1.1. VPLS Learning actions......................................12
9. Operation of a VPLS............................................12 9. Operation of a VPLS............................................13
9.1. MAC Address Aging............................................13 9.1. MAC Address Aging............................................13
10. A Hierarchical VPLS Model.....................................13 10. A Hierarchical VPLS Model.....................................14
10.1. Hierarchical connectivity...................................14 10.1. Hierarchical connectivity...................................14
10.1.1. Spoke connectivity for bridging-capable devices...........14 10.1.1. Spoke connectivity for bridging-capable devices...........15
10.1.2. Advantages of spoke connectivity..........................16 10.1.2. Advantages of spoke connectivity..........................16
10.1.3. Spoke connectivity for non-bridging devices...............17 10.1.3. Spoke connectivity for non-bridging devices...............17
10.2. Redundant Spoke Connections.................................18 10.2. Redundant Spoke Connections.................................18
10.2.1. Dual-homed MTU device.....................................18 10.2.1. Dual-homed MTU device.....................................18
10.2.2. Failure detection and recovery............................19 10.2.2. Failure detection and recovery............................19
10.3. Multi-domain VPLS service...................................20 10.3. Multi-domain VPLS service...................................20
11. Hierarchical VPLS model using Ethernet Access Network.........20 11. Hierarchical VPLS model using Ethernet Access Network.........20
11.1. Scalability.................................................21 11.1. Scalability.................................................21
11.2. Dual Homing and Failure Recovery............................21 11.2. Dual Homing and Failure Recovery............................22
12. Significant Modifications.....................................22 12. Significant Modifications.....................................22
13. Acknowledgments...............................................22 13. Acknowledgments...............................................22
14. Security Considerations.......................................22 14. Security Considerations.......................................22
15. Intellectual Property Considerations..........................22 15. Intellectual Property Considerations..........................22
16. Full Copyright Statement......................................22 16. Full Copyright Statement......................................23
17. References....................................................23 17. References....................................................23
18. Authors' Addresses............................................24 18. Authors' Addresses............................................24
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). An Ethernet port is used to connect a and WAN respectively). An Ethernet port is used to connect a
customer to the Provider Edge (PE) router acting as an LER. Customer customer to the Provider Edge (PE) router acting as an LER. Customer
traffic is subsequently mapped to a specific MPLS L2 VPN by traffic is subsequently mapped to a specific MPLS L2 VPN by
skipping to change at page 5, line 8 skipping to change at page 5, line 8
The following discussion applies to devices that are VPLS capable The following discussion applies to devices that are VPLS capable
and have a means of tunneling labeled packets amongst each other. and have a means of tunneling labeled packets amongst each other.
While MPLS LSPs may be used to tunnel these labeled packets, other While MPLS LSPs may be used to tunnel these labeled packets, other
technologies may be used as well, e.g., GRE [MPLS-GRE]. The technologies may be used as well, e.g., GRE [MPLS-GRE]. The
resulting set of interconnected devices forms a private MPLS VPN. resulting set of interconnected devices forms a private MPLS VPN.
5. Topological Model for VPLS 5. Topological Model for VPLS
An interface participating in a VPLS must be able to flood, forward, An interface participating in a VPLS must be able to flood, forward,
and filter ethernet frames. and filter Ethernet frames.
+----+ +----+ +----+ +----+
+ C1 +---+ ........................... +---| C1 | + C1 +---+ ........................... +---| C1 |
+----+ | . . | +----+ +----+ | . . | +----+
Site A | +----+ +----+ | Site B Site A | +----+ +----+ | Site B
+---| PE |------ Cloud -------| PE |---+ +---| PE |------ Cloud -------| PE |---+
+----+ | +----+ +----+ | +----+
. | . . | .
. +----+ . . +----+ .
..........| PE |........... ..........| PE |...........
skipping to change at page 6, line 9 skipping to change at page 6, line 9
One of attributes of an Ethernet service is that all broadcast and One of attributes of an Ethernet service is that all broadcast and
destination unknown MAC addresses are flooded to all ports. To destination unknown MAC addresses are flooded to all ports. To
achieve flooding within the service provider network, all address achieve flooding within the service provider network, all address
unknown unicast, broadcast and multicast frames are flooded over the unknown unicast, broadcast and multicast frames are flooded over the
corresponding pseudowires to all relevant PE nodes participating in corresponding pseudowires to all relevant PE nodes participating in
the VPLS. the VPLS.
Note that multicast frames are a special case and do not necessarily Note that multicast frames are a special case and do not necessarily
have to be sent to all VPN members. For simplicity, the default have to be sent to all VPN members. For simplicity, the default
approach of broadcasting multicast frames can be used. Extensions approach of broadcasting multicast frames can be used. The use of
explaining how to interact with 802.1 GMRP protocol, IGMP snooping IGMP snooping and PIM snooping techniques should be used to improve
and static MAC multicast filters will be discussed in a future multicast efficiency.
revision if needed.
To forward a frame, a PE must be able to associate a destination MAC To forward a frame, a PE must be able to associate a destination MAC
address with a pseudowire. It is unreasonable and perhaps impossible address with a pseudowire. It is unreasonable and perhaps impossible
to require PEs to statically configure an association of every to require PEs to statically configure an association of every
possible destination MAC address with a pseudowire. Therefore, VPLS- possible destination MAC address with a pseudowire. Therefore, VPLS-
capable PEs must have the capability to dynamically learn MAC capable PEs must have the capability to dynamically learn MAC
addresses on both physical ports and virtual circuits and to forward addresses on both physical ports and virtual circuits and to forward
and replicate packets across both physical ports and pseudowires. and replicate packets across both physical ports and pseudowires.
5.2. Address Learning 5.2. Address Learning
skipping to change at page 6, line 43 skipping to change at page 6, line 42
are established. Similarly, it is considered operationally down are established. Similarly, it is considered operationally down
when one of these two VC LSPs is torn down. when one of these two VC LSPs is torn down.
Standard learning, filtering and forwarding actions, as defined in Standard learning, filtering and forwarding actions, as defined in
[802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a [802.1D-ORIG], [802.1D-REV] and [802.1Q], are required when a
logical link state changes. logical link state changes.
5.3. Tunnel Topology 5.3. Tunnel Topology
PE routers typically run an IGP between them, and are assumed to PE routers typically run an IGP between them, and are assumed to
have the capability to establish transport tunnels. Tunnel are set have the capability to establish transport tunnels. Tunnels are set
up between PEs to aggregate traffic. Pseudowires are signaled to up between PEs to aggregate traffic. Pseudowires are signaled to
demultiplex the L2 encapsulated packets that traverse the tunnels. demultiplex the L2 encapsulated packets that traverse the tunnels.
In an Ethernet L2VPN, it becomes the responsibility of the service In an Ethernet L2VPN, it becomes the responsibility of the service
provider to create the loop free topology. For the sake of provider to create the loop free topology. For the sake of
simplicity, we define that the topology of a VPLS is a full mesh of simplicity, we define that the topology of a VPLS is a full mesh of
tunnels and pseudowires. tunnels and pseudowires.
5.4. Loop free L2 VPN 5.4. Loop free L2 VPN
skipping to change at page 10, line 29 skipping to change at page 10, line 29
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.
No optional parameters have been defined for the MAC Address No optional parameters have been defined for the MAC Address
Withdraw signaling. Withdraw signaling.
7.2.2. Address Withdraw Message Containing MAC TLV 7.2.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 has failed, an Address
Withdraw Message can be sent with the list of MAC addresses to be Withdraw Message with the list of MAC addresses to be relearned can
relearned. be sent to all other PEs over the corresponding directed LDP
sessions.
The processing for MAC TLVs received in an Address Withdraw Message The processing for MAC TLVs received in an Address Withdraw Message
is: 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
- Send the same message to all other PEs over the corresponding
directed LDP sessions.
For an Address Withdraw message with empty list: For an 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)
- Send the same message to all other PEs over the corresponding
directed LDP sessions.
The scope of a MAC TLV is the VPLS specified in the FEC TLV in the The scope of a MAC TLV is the VPLS specified in the FEC TLV in the
Address Withdraw Message. The number of MAC addresses can be 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.
Further descriptions of how to deal with failures expeditiously with Further descriptions of how to deal with failures expeditiously with
different configurations will be described in other documents, such different configurations will be described in other documents, such
as [VPLS-BRIDGING]. as [VPLS-BRIDGING].
8. Data Forwarding on an Ethernet VC Type 8. Data Forwarding on an Ethernet VC Type
skipping to change at page 12, line 22 skipping to change at page 12, line 18
limiting the scope of locally significant encapsulations to the limiting the scope of locally significant encapsulations to the
edge, hierarchical VPLS models can be developed that provide the edge, hierarchical VPLS models can be developed that provide the
capability to network-engineer VPLS deployments, as described below. capability to network-engineer VPLS deployments, as described below.
8.1.1. VPLS Learning actions 8.1.1. VPLS Learning actions
Learning is done based on the customer Ethernet packet, as defined Learning is done based on the customer Ethernet packet, as defined
above. The Forwarding Information Base (FIB) keeps track of the above. The Forwarding Information Base (FIB) keeps track of the
mapping of customer Ethernet packet addressing and the appropriate mapping of customer Ethernet packet addressing and the appropriate
pseudowire to use. We define two modes of learning: qualified and pseudowire to use. We define two modes of learning: qualified and
unqualified learning. However, the model followed in this VPLS unqualified learning.
document is the unqualified learning model.
In unqualified learning, all the customer VLANs are handled by a In unqualified learning, all the customer VLANs are handled by a
single VPLS, which means they all share a single broadcast domain single VPLS, which means they all share a single broadcast domain
and a single MAC address space. This means that MAC addresses need and a single MAC address space. This means that MAC addresses need
to be unique and non-overlapping among customer VLANs or else they to be unique and non-overlapping among customer VLANs or else they
cannot be differentiated within the VPLS instance and this can cannot be differentiated within the VPLS instance and this can
result in loss of customer frames. An application of unqualified result in loss of customer frames. An application of unqualified
learning is port-based VPLS service for a given customer (e.g., learning is port-based VPLS service for a given customer (e.g.,
customer with non-multiplexed UNI interface where all the traffic on customer with non-multiplexed UNI interface where all the traffic on
a physical port, which may include multiple customer VLANs, is a physical port, which may include multiple customer VLANs, is
mapped to a single VPLS instance). mapped to a single VPLS instance).
In qualified learning, each customer VLAN is assigned to its own In qualified learning, each customer VLAN is assigned to its own
VPLS instance, which means each customer VLAN has its own broadcast VPLS instance, which means each customer VLAN has its own broadcast
domain and MAC address space. Therefore, in qualified learning, MAC domain and MAC address space. Therefore, in qualified learning, MAC
addresses among customer VLANs may overlap with each other, but they addresses among customer VLANs may overlap with each other, but they
will be handled correctly since each customer VLAN has its own FIB , will be handled correctly since each customer VLAN has its own FIB ,
i.e., each customer VLAN has its own MAC address space. Since VPLS i.e., each customer VLAN has its own MAC address space. Since VPLS
broadcasts multicast frames, qualified learning offers the advantage broadcasts multicast frames by default, qualified learning offers
of limiting the broadcast scope to a given customer VLAN. the advantage of limiting the broadcast scope to a given customer
VLAN.
For STP to work in qualified mode, a VPLS PE must be able to forward
STP BPDUs over the proper VPLS instance. In a hierarchical VPLS case
(see details in Section 10), service delimiting tags (Q-in-Q or
Martini) can be added by MTU-s nodes such that PEs can unambiguously
identify all customer traffic, including STP/MSTP BPDUs. In a basic
VPLS case, upstream switches must insert such service delimiting
tags. When an access port is shared among multiple customers, a
reserved VLAN per customer domain must be used to carry STP/MSTP
traffic. The STP/MSTP frames are encapsulated with a unique provider
tag per customer (as the regular customer traffic), and a PEs looks
up the provider tag to send such frames across the proper VPLS
instance.
9. Operation of a VPLS 9. Operation of a VPLS
We show here an example of how a VPLS works. The following We show here an example of how a VPLS works. The following
discussion uses the figure below, where a VPLS has been set up discussion uses the figure below, where a VPLS has been set up
between PE1, PE2 and PE3. between PE1, PE2 and PE3.
Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full- Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full-
mesh of Ethernet pseudowires. The VPLS instance is assigned a mesh of Ethernet pseudowires. The VPLS instance is assigned a
unique VCID. unique VCID.
skipping to change at page 19, line 48 skipping to change at page 20, line 11
Upon failure of the primary pseudowire, MTU-s device immediately Upon failure of the primary pseudowire, MTU-s device immediately
switches to the secondary pseudowire. At this point the PE3-rs switches to the secondary pseudowire. At this point the PE3-rs
device that terminates the secondary pseudowire starts learning MAC device that terminates the secondary pseudowire starts learning MAC
addresses on the spoke pseudowire. All other PE-rs nodes in the addresses on the spoke pseudowire. All other PE-rs nodes in the
network think that CE-1 and CE-2 are behind PE1-rs and may continue network think that CE-1 and CE-2 are behind PE1-rs and may continue
to send traffic to PE1-rs until they learn that the devices are now to send traffic to PE1-rs until they learn that the devices are now
behind PE3-rs. The relearning process can take a long time and may behind PE3-rs. The relearning process can take a long time and may
adversely affect the connectivity of higher level protocols from CE1 adversely affect the connectivity of higher level protocols from CE1
and CE2. To enable faster convergence, the PE3-rs device where the and CE2. To enable faster convergence, the PE3-rs device where the
secondary pseudowire got activated may send out a flush message, secondary pseudowire got activated may send out a flush message,
using the MAC TLV as defined in Section 6, to PE1-rs, who relays it using the MAC TLV as defined in Section 6, to all PE-rs nodes. Upon
to all other PE-rs devices participating in the VPLS service. Upon receiving the message, PE-rs nodes flush the MAC addresses
receiving the message, all PE-rs nodes flush the MAC addresses
associated with that VPLS instance. associated with that VPLS instance.
10.3. Multi-domain VPLS service 10.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 devices. Two fully meshed VPLS networks are connected together
using a single LSP tunnel between the VPLS gateway devices. A using a single LSP tunnel between the VPLS gateway devices. A
single spoke pseudowire is setup per VPLS service to connect the two single spoke pseudowire is setup per VPLS service to connect the two
skipping to change at page 22, line 12 skipping to change at page 22, line 22
more than one PE-rs, then a dedicated full-mesh of pseudowires is more than one PE-rs, then a dedicated full-mesh of pseudowires is
used among these PE-rs devices for carrying the SP BPDU packets for used among these PE-rs devices for carrying the SP BPDU packets for
that island. On a per P-VLAN basis, the MSTP will designate a single that island. On a per P-VLAN basis, the MSTP will designate a single
PE-rs to be used for carrying the traffic across the core. The loop- PE-rs to be used for carrying the traffic across the core. The loop-
free protection through the core is performed using split-horizon and free protection through the core is performed using split-horizon and
the failure protection in the core is performed through standard the failure protection in the core is performed through standard
IP/MPLS re-routing. IP/MPLS re-routing.
12. Significant Modifications 12. Significant Modifications
Between rev 04 and this one, these are the changes: Between rev 00 and this one, these are the changes:
o minor revisions of text o minor revisions of text
o cleanup of use of MPLS LSPs for tunnels o briefly explains qualified learning and STP interaction
o clearly states qualified learning is out of scope for current
model
o corrected MAC TLV description
13. Acknowledgments 13. Acknowledgments
We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel
Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt
Squire, Muneyoshi Suzuki, Waldemar Augustyn, and Eric Rosen for Squire, Muneyoshi Suzuki, Waldemar Augustyn, and Eric Rosen for
their valuable feedback. In addition, we would like to thank Rajiv their valuable feedback. In addition, we would like to thank Rajiv
Papneja (ISOCORE), Winston Liu (ISOCORE), and Charlie Hundall Papneja (ISOCORE), Winston Liu (ISOCORE), and Charlie Hundall
(Extreme) for identifying issues with the draft in the course of the (Extreme) for identifying issues with the draft in the course of the
interoperability tests. interoperability tests.
skipping to change at page 25, line 17 skipping to change at page 25, line 23
San Jose, CA 95134 San Jose, CA 95134
Email: sajassi@cisco.com Email: sajassi@cisco.com
Loa Andersson Loa Andersson
Email: loa@pi.se Email: loa@pi.se
Pascal Menezes Pascal Menezes
Email: pascalm1@yahoo.com Email: pascalm1@yahoo.com
Andrew Smith Andrew Smith
Consultant
Email: ah_smith@pacbell.net Email: ah_smith@pacbell.net
Giles Heron Giles Heron
PacketExchange Ltd. PacketExchange Ltd.
Email: giles@packetexchange.net Email: giles@packetexchange.net
Juha Heinanen Juha Heinanen
TutPro TutPro
Email: jh@tutpro.com Email: jh@tutpro.com
 End of changes. 

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