One document matched: draft-lasserre-l2vpn-vpls-ldp-applic-00.txt
Internet Draft Document Marc Lasserre
Layer 2 VPN Working Group Xipeng Xiao
draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Riverstone Networks
Yetik Serbest Cesar Garrido
SBC Telefonica
Expires: August 2004 February 2004
VPLS Applicability
draft-lasserre-l2vpn-vpls-ldp-applic-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
Virtual Private LAN Service (VPLS) is a layer 2 VPN service that
provides multipoint connectivity in the form of an Ethernet emulated
LAN, while usual L2 VPN services are typically point-to-point. Such
Lasserre et al. [Page 1]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
emulated LANs can span metropolitan area networks as well as wide
area networks.
VPLS defines a method for signaling MPLS connections between member
PEs of a VPN and a method for forwarding Ethernet frames over such
connections. This document describes the applicability of such
procedures to provide VPLS services.
Conventions
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
RELATED DOCUMENTS
www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-01.txt
www.ietf.org/internet-drafts/draft-ietf-l3vpn-applicability-
guidelines-00.txt
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Conventions........................................................2
Intellectual Property Considerations...............................3
Full Copyright Statement...........................................3
1. VPLS Overview...................................................4
2. Operation of data, control and management planes................5
2.1. Control Plane.................................................5
2.1.1. Signaling...................................................5
2.2. Data Plane....................................................5
2.2.1. Ingress Processing..........................................5
2.2.2. Egress Processing...........................................5
2.2.3. Intermediate Node Processing................................6
2.3. Management plane..............................................6
2.3.1. VPLS OAM....................................................6
3. VPLS vs. alternative approaches.................................6
3.1. Ethernet switching............................................6
3.2. BGP VPN.......................................................7
4. Scalability.....................................................7
4.1. Mesh topology.................................................7
4.2. Signaling.....................................................7
4.3. MAC addresses and MAC learning................................7
4.4. Packet replication............................................7
Lasserre et al. [Page 2]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
4.5. Broadcast limiting............................................8
4.6. Multicast.....................................................8
5. Deployment Issues...............................................8
5.1. Provisioning..................................................8
5.1.1. VPLS membership management..................................8
5.1.2. Tunnel Provisioning.........................................9
5.2. PE Discovery..................................................9
5.3. Migration impacts............................................10
5.3.1. Existing L2 802.1Q VLAN Based Metro Infrastructure.........10
5.3.2. Existing IP Routed Environment.............................12
5.4. Multihoming..................................................12
5.5. Loop Prevention..............................................13
5.6. Packet re-ordering...........................................14
5.7. Multi-Domain VPLS Service....................................15
5.8. MTU (Maximum Transmission Unit) Issues.......................15
5.9. Interworking.................................................15
5.9.1. Interworking with BGP VPNs.................................15
5.9.2. Interworking with Frame Relay & ATM attachment circuits....15
5.10. Quality of Service..........................................15
5.11. Security....................................................16
5.11.1. Traffic Separation Between VPLS Instances.................16
5.11.2. Denial of Service (DoS)...................................16
6. Acknowledgments................................................17
7. References.....................................................17
8. Authors' Addresses.............................................18
Intellectual Property Considerations
This document is being submitted for use in IETF standards
discussions.
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
Lasserre et al. [Page 3]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
1. VPLS Overview
The primary motivation behind Virtual Private LAN Services (VPLS) is
to provide connectivity between geographically dispersed customer
sites across MAN/WAN network(s), as if they were connected using a
LAN. The intended applications for the end-user can be divided into
the following two categories:
- Connectivity between customer routers
- Connectivity between customer Ethernet switches
In addition, VPLS can also be used by the service provider to
deliver services (e.g. triple play) to connected end-users.
Unlike L3 VPNs such as BGP VPNs [BGP-VPN] where traffic exchanged
between customers and service providers must be IP, VPLS only
requires traffic to be Ethernet over which any protocol can be used,
e.g. Netbios or IPX.
The Service Provider Network is a packet switched network (PSN).
The PEs are assumed to be fully meshed with transport tunnels over
which customer frames that belong to a specific VPLS instance are
encapsulated and forwarded. IP-in-IP, L2TPv3, GRE, and MPLS are
examples of transport tunnels.
Specific labels used to identify end-to-end paths over such tunnel
LSPs are established via targeted LDP [VPLS-LDP]. These LSPs are
known as pseudo-wires (PWs).
VPLS defines the bridging rules required for PEs to provide an
emulated Ethernet LAN service. In particular it defines how a loop-
free topology must be built and the forwarding rules between PEs,
along with the signaling method to set up PWs between PEs.
Lasserre et al. [Page 4]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
The resulting service provides a unique broadcast domain per VPN,
with the ability to send unicast, multicast and broadcast traffic
(as well as flooding of unknown unicast traffic).
2. Operation of data, control and management planes
2.1. Control Plane
2.1.1. Signaling
As with [PWE3-ETHERNET], [VPLS-LDP] specifies the use of targeted
LDP for the signaling of PWs. PWs are established between PEs that
are part of the same VPLS instance.
2.2. Data Plane
2.2.1. Ingress Processing
VPLS provides an Ethernet emulated LAN service and hence customer
frames are encapsulated as Ethernet frames (Ethernet DIX or 802.1).
Note that such Ethernet frames can be carried over various access
transport technologies (Frame Relay, ATM, etc). Ingress PEs will
determine which Forwarding Information Base (FIB) to look up based
on the port, VLAN or port/VLAN combination frames come from. This
port to FIB mapping is performed at provisioning time. The
destination MAC address is then looked up to determine on which PW
this address has been learned from. If the lookup fails, i.e. if
this MAC address has not been learned yet, the frame needs to be
sent on all the PWs that are part of the corresponding VPLS
instance. If the address is known, the frame is sent only over the
associated PW. Before actually transmitting the customer frame, it
needs to be encapsulated as defined in [PWE3-ETHERNET], and is
further encapsulated with the appropriate transport header (e.g.
MPLS or GRE).
2.2.2. Egress Processing
Once the tunnel header has been removed, the egress PE determines
from the PW label which FIB to look up to determine the egress port,
VLAN or port/VLAN combination. The original Ethernet frame is then
encapsulated with the proper transmission header if necessary (e.g.
Frame Relay header) and sent over the corresponding port.
MAC addresses are learned dynamically as traffic is exchanged. New
source MAC addresses are learned on a per PW label per VPLS service
instance basis. An aging timer is used to remove such bindings after
a period of time. When user topology changes occur, MAC withdrawal
messages in the signaling plane may be used to unlearn MAC addresses
to improve convergence time.
Lasserre et al. [Page 5]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
Egress PEs might also be configured to perform specific egress
encapsulation functions (e.g. VLAN translation).
2.2.3. Intermediate Node Processing
Intermediate nodes (P routers) only act as pure forwarders based on
the outer tunnel header. Hence, they do not participate in any VPLS-
related processing. Only PE routers maintain VPN specific
information. This improves the scalability of VPLS service.
2.3. Management plane
2.3.1. VPLS OAM
VPLS OAM is used to verify whether the VPLS instance of a particular
customer works, and if not, where the fault is located. VPLS OAM is
very important for the operations of VPLS networks.
Currently there are two proposals for VPLS OAM. One proposal uses
the OAM mechanisms being defined by the IEEE 802.1ad, 802.3ah, and
ITU-T [Y.17ethoam] to verify MAC-layer connectivity status and
locate fault at the PEs and MTUs. This approach is agnostic to PW
type between the PEs or between PEs and the MTUs. The other
proposal [STOKES] defines an MPLS-based approach to verify
connectivity status and locate fault at the PEs and MTUs for VPLS
deployments that use MPLS PWs.
With VPLS OAM, ideally the OAM packets should always follow the same
path as the VPLS data packets. However, because the Ethernet MAC
layer has no TTL support, both approaches need to add something in
the OAM packets to achieve the traceroute capability. As a result,
neither approach can guarantee that traceroute packets always follow
the same path as the VPLS data packets (without requiring change of
existing network equipment). Therefore, both approaches are still
evolving. Nevertheless, they achieve the practical purpose of
verifying VPLS connectivity and locating fault to a good extent.
3. VPLS vs. alternative approaches
3.1. Ethernet switching
Ethernet can be used to provide multipoint connectivity within small
geographical areas such as small metropolitan networks. Pure
Ethernet based solutions have scalability issues (e.g. STP
limitations, 4095 VLAN limitations). Some enhancements such as QinQ,
STP extensions (RSTP, MSTP) provide additional scalability.
VPLS overcomes several of Ethernet based solutions by supporting
large numbers of VPNs, better traffic engineering, and better
quality of service.
Lasserre et al. [Page 6]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
It is not uncommon for VPLS networks to be complemented with
Ethernet switched networks as an aggregation layer.
3.2. BGP VPN
In metropolitan area networks (MANs), BGP is usually not enabled.
MANs provide a transport service to end-users. When multiple sites
need to be connected within a metro, VPLS offers the appropriate
multipoint transport solution. When multipoint connectivity is
required across wide area networks such as national backbones, BGP
VPNs can be more appropriate.
Section 5.8.1 describes how VPLS and BGP VPNs can be complementary.
4. Scalability
4.1. Mesh topology
A full mesh of tunnel LSPs, over which PWs are established –
resulting in a full mesh of PWs, is created between participating
PEs. When using hierarchical VPLS constructs, the size of this full
mesh can be reduced to hub PEs aggregating point-to-point spokes as
described in section 10 of [VPLS-LDP].
This reduces the number of tunnels and PWs from O(N*N) to O(N).
4.2. Signaling
Using HVPLS constructs also allows the total number of targeted LDP
sessions to be reduced from O(N*N) to O(N).
4.3. MAC addresses and MAC learning
Depending on the type of CE devices used, i.e. switches or routers,
the total number of MAC addresses to be learned by VPLS PEs can vary
from one address per site to a large number of MAC addresses.
When Ethernet networks exceed a large number of MAC addresses (e.g.
hundreds), routers are introduced to limit the size of such
broadcast domains. This reduces the total number of MAC addresses to
learn to such routers only.
In the case of large flat Ethernet networks, ingress PEs must be
able to limit the number of MAC addresses that can be learned on a
per VPLS basis.
4.4. Packet replication
With VPLS, broadcast, multicast and unknown destination frames get
replicated by the ingress PEs, i.e. close to the source of the
Lasserre et al. [Page 7]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
frame. Ideally such frames should be replicated as close to the
destination as possible to minimize bandwidth consumption. With
hierarchical VPLS, the replication process is distributed between
several ingress and egress MTUs and PEs. This helps not only
minimizing bandwidth resources but also improving multicast
performance and reducing latency.
4.5. Broadcast limiting
Ingress MTUs or PEs may be able to rate limit the amount of
broadcast traffic generated by end users in order to protect core
resources and to prevent a few users from using all the bandwidth
available.
4.6. Multicast
In order to optimize the replication of multicast traffic, it is
highly desirable for PEs to support multicast snooping techniques in
order to only forward traffic where needed. In the case where the CE
device is an L2 switch, IGMP snooping would be required, however, if
the CE device is a router PIM snooping would be more applicable.
5. Deployment Issues
5.1. Provisioning
5.1.1. VPLS membership management
As service providers start to provide Ethernet services to their
customers, they build more complex end-to-end services for which the
VPLS part plays a key role, but additional tools are also required:
- Bandwidth control on customer facing ports
- QoS classification and propagation
- Traffic engineering per customer service
- Activation of traffic monitoring and accounting mechanisms
Managing the membership of customer sites to this service is not
only keeping track of which PEs are part of a VPLS instance, but
also the detailed characteristics of those connections, the path the
customer traffic must use, the service profile it should have, etc.
Auto-discovery mechanisms help to simplify the VPLS to PE membership
management but are just a small part on the whole process for
completely activating the end-to-end service. Therefore, it is
highly convenient to make use of tools that can automate the
provisioning tasks, in such a way that the service provider can take
advantage, in a simplified way, of the traffic control mechanisms
that MPLS provides, like Traffic Engineering.
Lasserre et al. [Page 8]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
5.1.2. Tunnel Provisioning
One of the key points for service providers delivering VPLS services
is to take advantage of the capabilities provided by the LSPs
signaled by RSVP. Examples of that are Traffic Engineering and Fast
Restoration in case of failure, and being able to selectively use
these capabilities on a per customer or service basis. Therefore,
traffic engineered tunnels can become a service or customer
differentiation mechanism, and not only an infrastructure
communication path.
Taking into account the importance of tunnel provisioning when
activating VPLS services, it is highly desirable for service
providers to be able to automate the creation and definition of the
characteristics of the TE-LSPs, not only to take advantage of their
properties but also to use the resources more efficiently, by
creating LSPs only where needed and when needed.
5.2. PE Discovery
PE auto-discovery is the process that a PE uses to discover IP
addresses of other PEs in the network that participate in common
VPLS instances as itself, so that these IP addresses needs not be
configured by a network operator. Currently there are several
proposals for PE auto-discovery: the BGP-based approach [VPLS-BGP],
the RADIUS-based approach [RADIUS-DIS], and the Provisioning System-
based approach.
Because of the auto-discovery mechanism, at each PE, the network
operator needs not specify other PEs' addresses. To add or remove a
PE for a VPLS instance, the network operator may not need to touch
other PEs (it still may be necessary to touch the other PEs in order
to define customer specific service attributes such as per-PE QoS).
As their names suggest, both approaches mandate the use of BGP or
RADIUS in every PE, and rely on it to propagate the information of
which PEs participate in a VPLS instance. The pros and cons of both
approaches are discussed in their defining drafts. The key issues
here are whether BGP should be in every VPLS PE and how suitable BGP
is as a signaling protocol for VPLS.
With the Provisioning System-based approach, network operators do
not configure the PEs. Instead, they specify which PEs participate
in which VPLS instances at the Provisioning System. The
Provisioning System then translates such service information into PE
configuration commands and telnet/ssh to the PEs to execute such
commands. Because all information related to every VPLS instance is
centralized at the Provisioning System, PE auto-discovery is
automatically achieved. To add or remove a PE for a VPLS instance,
a network operator simply specifies it at the Provisioning System
Lasserre et al. [Page 9]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
which will then configure the PEs accordingly.
For VPLS deployments that span across multiple domains, because the
ASBRs (autonomous system border routers) of other domains can be
treated as CEs of the current domain, these auto-discovery
approaches can work in the inter-domain case as well. The
scalability issues of such a scenario are discussed in [VPLS-BGP].
5.3. Migration impacts
Migration impacts may be mitigated through the use of careful
planning when building and migrating the network. Also,
consideration must be taken when integrating with protocols such as
STP/MST and how control packets (BPDU’s) are handled. In addition,
one must also consider ongoing standards efforts within various
standards bodies such as the IEEE[802.1ad] and the Metro Ethernet
Forum to assess future impact of any changes within the provider
network.
5.3.1. Existing L2 802.1Q VLAN Based Metro Infrastructure
5.3.1.1. MPLS over 802.1Q(or QinQ) Tagged Infrastructure – Overlay
Providers that have already deployed VLAN based architecture may
choose to overlay an MPLS edge on top of this existing L2 domain.
In this method, provider .1q tags maybe assigned to MPLS backbone
links that are then used for carrying VPLS traffic. While this
approach may allow for a simple transition to solve some immediate
deficiencies of a pure L2 network, it still does not solve some of
the underlying problems associated with protocols such as spanning
tree. In this case, although MPLS may provide some scaling
advantages, the limitations associated with spanning tree can still
pose potential problems to the overall infrastructure.
CE1
------------------- ------ /
/ \ -|VPLS| /
/ \ / | PE |-
/ \ ------
/ \
| 802.1Q/ |
| QinQ |
\ /
----- \ /\ ------
|VPLS|_/ \ / \ |VPLS|
-| PE | \ / -| PE |-
/ ------ ------------------- ------ \
/ \ \
CE3 --CE4 CE5
Lasserre et al. [Page 10]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
5.3.1.2. L2 Ethernet Islands Interconnected with a MPLS based VPLS
core (HVPLS using Q or QinQ for spoke connections)
Another mechanism that may be used for a migration strategy is to
effectively utilize existing L2 (possibly .1Q based or QinQ)
networks as “islands” attached to an MPLS based VPLS core network.
In this particular case, the L2 network uses predetermined Provider
.1Q tags (P-tags) to transport a given customers traffic. This P-
tag is then utilized as a service delimiter that is then stripped
prior to being transported across the MPLS cloud. The service
delimiting P-tag is used to identify the VPLS instance to which the
traffic should be mapped. A potential issue that can arise is the
possibility of inadvertently creating an L2 loop in the event that
the Ethernet access network(s) have redundant connections to the
VPLS core. The assumption is that STP or another loop detection
mechanism is already being utilized within the L2 domain and as
such, should be utilized to perform loop avoidance when
interconnecting with the VPLS core.
----CE1
------- ------- / --------
CE2- / \ / PE1 / \
\ / \ / \ / \
---| QinQ \ / MPLS/ \ / QinQ |
| Domain PE VPLS PE Domain |
\ / \ Domain / \ /\
\ / \ / \ / \
------- ---------- -------- --CE3
Integration between VPLS and QinQ: A problem that may potentially
arise when using VPLS to interconnect a traditional 802.1q access
network to a QinQ access network revolves around the handling of .1q
tags between the two access mechanisms. Customer connectivity at
one site will be tied to a port on a VPLS PE/MTU that will utilize a
PW for tunneling this packet through the network. Customer
connectivity at another site will be interconnected to a port on a
QinQ switch that will utilize QinQ techniques for transporting
customer frames through the metro domain. The PE(s) responsible for
interconnecting the MPLS domain to the QinQ island must perform
additional operations to push or pop the QinQ Provider VLAN (P-VLAN)
depending upon which direction the frame is being transported. In
this particular case, on the VPLS egress facing the traditional CE,
the PE must be capable of stripping the outer P-VLAN. On the VPLS
egress facing the QinQ domain, the PE-rs must be capable of
appending an additional P-tag prior to sending to the QinQ domain.
Lasserre et al. [Page 11]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
-----
.-- Push P-VLAN / A1 \
---- ----CE1 |
/ \ ------- ------- / | |
| A2 CE2- / \ / PE1 \ /
\ / \ / \ / \ -----
---- ---| QinQ \ / MPLS/ |
| Domain PE2 VPLS |
\ / \ Domain /
----- \ / \ /
|QinQ|_/ ------- -------
-| | Pop P-VLAN --.
---- / ------ ----
/ \/ \ / \ CE = Customer Edge Router
| A3 CE3 --C4 A4 | PE = Provider Edge Router
\ / \ /
---- ----
5.3.2. Existing IP Routed Environment
Within an existing IP routed environment if the existing routers are
capable of supporting MPLS, they may then be utilized as traditional
P routers. If they are not MPLS capable, then alternate tunneling
means such as GRE may be used.
5.4. Multihoming
Multihoming is necessary in order to remove a VPLS PE as a single
point of failure for all devices attached to it. There are two
instances of multihoming that apply to VPLS:
1. When a CE device is connected to more than one PE,
2. In the case of hierarchical VPLS - when an MTU-s device is
connected to more than one PE-rs.
In both of these cases, the concern is that a particular MAC address
will appear as a source on more than one PE device, causing other PE
devices to continuously change their FIBs with regard to the true
location of the MAC. This will cause constant table thrashing on
the remote PEs, a behavior akin to a Layer 2 switch which
participates in a loop.
It is therefore required that any Layer 2 loops, created by
multihoming of a CE or an MTU-s, be resolved within the group of
devices participating in that loop. This group includes the
multihomed CE or MTU-s, and all PEs to which it is attached. The PEs
involved in such a loop are connected with a full mesh of
pseudowires per VPLS instance.
Lasserre et al. [Page 12]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
There are two approaches to resolving the loops created by the
multihomed devices:
1. Running an MSTP instance between all devices in the group. In
this case, the PEs within the group will need to utilize a P-VLAN
for the purposes of running MSTP in the group. This P-VLAN can be
re-used on non-overlapping groups of multihomed CE (or MTU-s) and
its PEs. It must be clear that the MSTP process discussed here is
a completely different and independent instance of STP than any STP
the customer may be running. Such customer STP is always tunneled
through the VPLS network, and is never acted upon by the PE or MTU-s
devices.
2. The MTU-s or the CE can designate its link to one of the PEs it
connects to as primary, and only send packets for this particular
VPLS instance over that link. In this case the MTU-s (CE) is
responsible for monitoring the state of that link and for switching
to an alternate link if the primary fails. No action is required
from the PEs participating in the group, though there should be an
indication given from the MTU-s to its connected PEs as to whether
the PE is connected to the primary or backup link. This is a very
lightweight approach, which is quite useful given the simple and
known topology between the CE (MTU-s) and its PEs. With this
approach the operator must ensure that pseudowires in the core
remain up, as long as the ingress PE they start from is up. This
can typically be ensured with MPLS TE tools, such as fast re-route
or back-up LSPs. If pseudowires in the core go down while their
ingress PE is up and accepting customer traffic, blackholes can
occur.
In each case, the PE nodes are most likely in two different physical
locations in the provider network providing network element
protection, last mile protection, fiber diversity and provider
facility backup. Customer STP traffic is always tunneled through
the provider network, and is never acted upon by the PE or MTU-s
devices.
Lastly, it should be observed that, since VPLS services provide
Ethernet switch-like transport level services, the customer is free
to connect any device they desire as a CE. This could be anything
from a simple host, hub, L2 switch, or a router. The operator has
to be cognizant of the different capabilities of each of those
devices to ensure loop-free environment when multi-homed.
5.5. Loop Prevention
Loops in the core VPLS network are prevented by creating a full mesh
of transport circuits between PEs and by applying a split-horizon
rule. The split-horizon approach prevents a frame received from the
Lasserre et al. [Page 13]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
backbone network from being sent out anything other than the
customer facing ports belonging to that VPLS instance on the
receiving PE. The frame MUST not be forwarded out other PW
connecting the receiving PE to other PEs participating in the VPLS
instance. This provides the necessary protection, network bandwidth
optimization and scalability in the carriers network as it does not
rely on link blocking technologies, like spanning tree type
protocols. This forwarding mechanism allows PEs to effectively
protect the core network from data loops.
Customer networks need to be able to transparently transport the
protocol information that allows their network to properly converge.
However, the provider should consider loop protection schemes
between the CE and PE that do not affect the customer functions.
This would be in addition to spanning tree when the PE connects to a
VLAN based L2 metro or when the customer is directly connected to
multiple PE nodes.
Methodologies providers can use to avoid loops when multi-homing CE
devices have been discussed in the previous section. Some of these
mechanisms involved running STP (or MSTP) between groups of PEs.
The provider should look at deploying a loop protection scheme that
would intervene automatically when it detects a loop condition. This
loop protection scheme serves as an additional line of defence
against protocol failures or misconfigurations, which can result in
data loops. The concern is that a particular MAC address will appear
as a source on more than one PE device, causing other PE devices to
continuously update there tables. An external loop protection scheme
adds a level of insurance above the customer link protection
schemes. Its function is to reduce unnecessary core bandwidth usage
when a loop condition occurs in an adjacent network and provide an
extra level of protection to multihomed networks. It is a compliment
but not a replacement for traditional loop protection mechanisms,
like spanning tree.
With directly connected customers, careful consideration needs to be
given to backdoor connections. Backdoor connections provide an
alternate path around a single provider. If a loop detection scheme
is invoked here the customer may be forced to traverse a link that
is not desired.
5.6. Packet re-ordering
Normally there is only one transmission path towards a destination
with VPLS so there is no packet re-ordering issue. But if some LSP
load sharing mechanisms are used, packets may be re-ordered inside
the PSN. If the users applications are sensitive to packet re-
ordering, care must be taken to ensure packets are delivered in
order.
Lasserre et al. [Page 14]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
5.7. Multi-Domain VPLS Service
As the use of VPLS grows, it is expected that customers will require
a single VPLS service delivered by different providers (e.g. either
for redundancy or physical location purposes). The different
providers would then need to interconnect their VPLS domains for
these customers. [VPLS-LDP] has provision for such a requirement,
utilizing a single LSP tunnel between VPLS gateway devices. However,
experience of such interconnection is not yet available.
5.8. MTU (Maximum Transmission Unit) Issues
VPLS uses the same encapsulation of Ethernet frames that is defined
in [PWE3-ETHERNET]. The MTU of transmission links used to transport
[PWE3-ETHERNET] and VPLS traffic needs to accommodate the extra
header used to carry the VC label and transport header.
5.9. Interworking
5.9.1. Interworking with BGP VPNs
Typically when interworking VPLS with BGP VPNs, BGP VPNs are used to
interconnect VPLS domains. In this type of scenario, BGP VPNs will
be used to carry inter-metro (long-haul) traffic whereas intra-
metro(local) traffic will be handled locally within the VPLS domain.
Access/transport networks such as VPLS can be interconnected with
BGP VPNs using various mechanisms such as Carriers-Carrier as
defined in [RFC-2547]. A very common method for interconnection
with BGP VPNs is to use a service delimiting tag (802.1Q VLAN-tag,
VC-label, ATM VC, FR DLCI) to identify a customer’s traffic. This
traffic is segregated and mapped to a given VRF using the delimiter.
5.9.2. Interworking with Frame Relay & ATM attachment circuits
Frame Relay (FR) and ATM attachment circuits with Ethernet bridged
encapsulation can be terminated within VPLS PEs. The resulting
Ethernet frames (i.e. once the FR/ATM encapsulation has been
stripped off) are processed as standard Ethernet frames.
In order to support a complete interworking model between FR and
Ethernet or between ATM and Ethernet, mapping service profiles and
OAM traffic from one to the next will be necessary. Additionally,
circuit management (e.g. LMI to PW state mapping) between the
various technologies will be required.
5.10. Quality of Service
Ingress PEs can classify incoming Ethernet traffic by either looking
at 802.1P markings or by looking at L3 and/or L4 fields (e.g.
Lasserre et al. [Page 15]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
ToS/DSCP field) contained within the payload to determine the frame
class of service.
The class of service determined during the classification phase can
be mapped onto a corresponding class of service offered by the
tunneling transport mechanism. For instance if MPLS tunneling is
used, the appropriate EXP marking can be performed. Alternatively,
the class of service can be mapped onto the appropriate tunnel which
would have been explicitly traffic engineered to match the desired
QoS.
5.11. Security
5.11.1. Traffic Separation Between VPLS Instances
VPLS instances maintain separation of broadcast domains between
themselves. Traffic entering a given VPLS instance at a given PE
device does not, under any circumstances, cross the boundaries of
the VPLS into another instance. VPLS devices (PEs and MTU-s) ensure
that by maintaining a FIB table on a per-VPLS instance basis.
The above statement is correct regardless of the learning mode
employed by a particular VPLS instance (qualified or unqualified),
or whether or not VLANs are treated as broadcast domain identifiers,
or simply as circuit IDs which have no significance in determining
the broadcast domain. In either of these cases, the VPLS instance
is the outer-most "envelope" which ensures that traffic within it
does not "leak" into another VPLS instance.
5.11.2. Denial of Service (DoS)
Two types of DoS attacks are of concern with VPLS:
1. Attacks against VPLS devices
2. Attacks against other devices, for which the VPLS network is a
transport.
Attacks of the first type are naturally of greater concern for a
VPLS operator, because they can destabilize the VPLS network as a
whole, and affect multiple customers. The tunneling nature of VPLS
by itself limits the possibilities for attacks via the data plane,
simply because such attacks will be tunneled through the VPLS
network, and will create the same load on the VPLS equipment as
legitimate traffic will.
Operators must watch for exception packet handling in VPLS
equipment. In many cases, exception packets are sent to the control
plane for handling. If that is the case, the operator must ensure
that such exception packets can be rate-limited in a fashion that
guarantees that the control plane will not be significantly burdened
by them.
Lasserre et al. [Page 16]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
The second type of DoS attacks, the ones that use the VPLS network
as a transport, are not really a threat to the VPLS devices
themselves, but are to devices behind them. VPLS PEs may be
configured with rate-limiting and rate-shaping capabilities which
permit them to limit the amount of traffic allowed into a particular
VPLS instance. Optionally, they can also be tasked with advanced
processing of the traffic they tunnel. For example, they may impose
access lists which deny traffic from particular sources or
protocols.
Such approaches however are highly vendor-specific and outside the
scope of [VPLS-LDP]. In addition, they may have significant design
and operational repercussions. Alternative approaches which hand-
off DoS protection activities to non-VPLS devices (such as customer
equipment) are preferred.
6. Acknowledgments
The authors wish to thank the following people for their
constructive contributions to the text in this document:
Javier Antich
Ian Cowburn
Richard Foote
Rob Nath
Nick Slabakov
7. References
[802.1ad] "IEEE standard for Provider Bridges", Work in progress,
December 2002.
[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
02.txt, Work in progress, February 2003.
[PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf-
pwe3-control-protocol-02.txt, Work in progress, February 2003.
[L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work
in progress, February 2003.
[L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn-l2vpn-requirements-
00.txt, Work in progress, May 2003.
[RADIUS-DIS] "Using Radius for PE-Based VPN Discovery", Work in
progress, Jun. 2003
Lasserre et al. [Page 17]
ID draft-lasserre-l2vpn-vpls-ldp-applic-00.txt Mar 2004
[STOKES] "Testing Hierarchical Virtual Private LAN Services", Work
in progress, Jun. 2003
[VPLS-LDP] "Virtual Private LAN Services over MPLS", draft-ietf-
ppvpn-vpls-ldp-01.txt, Work in progress, November 2003
[VPLS-BGP] "Virtual Private LAN Service", draft-ietf-ppvpn-vpls-bgp-
01.txt, Work in progress
[Y.17ethoam] "OAM mechanisms for Ethernet based networks", ITU-T,
SG13, Jul. 2003
8. Authors' Addresses
Marc Lasserre
Riverstone Networks
Email: marc@riverstonenet.com
Xipeng Xiao
Riverstone Networks
Email: xxiao@riverstonenet.com
Yetik Serbest
SBC Communications
serbest@tri.sbc.com
Cesar Garrido,
Telefonica
cesar.garridosanahuja@telefonica.es
Lasserre et al. [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-21 15:03:37 |