Internet DRAFT - draft-radoaca-ppvpn-gvpls
draft-radoaca-ppvpn-gvpls
Provider Provisioned VPN WG Vasile Radoaca
Internet Draft: Dinesh Mohan
draft-radoaca-ppvpn-gvpls-02.txt Nortel Networks
Expiration Date: December 2003
Ananth Nagarajan
Sprint
Javier Achirica
Telefonica Data
Pascal Menezes
Terabeam Andrew Malis
Vivace Networks
Marty Borden
Yaron Raz
Yael Dayan
Simon Hunt Atrica
186k
Alain Vedrenne
Muneyoshi Suzuki Equant
NTT Corporation
Shah Himanshu
Tenor Networks
June 2003
GVPLS/LPE - Generalized VPLS Solution based on LPE Framework
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.
Radoaca, et. al Expires: April 2003 [Page 1]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
Abstract
This document describes distributed virtual private LAN service
(VPLS) solution over MPLS using LDP signaling.
For VPLS solutions, the VPLS Reference Model [VPLS-L2-FRW]
introduces two types of models: distributed and non-distributed.
While [VPLS] solution presents a non-distributed model, it is
recognized that both models may co-exist in the same SP network.
This implies a need of signaling mechanisms to support these new
classes of solutions.
The current draft presents the GVPLS solution that addresses such
issues. The term "Generalized" in this document is used to reflect
the unified aspect of the two models.
Conventions Used
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 [2].
Placement of this Memo in Sub-IP Area
RELATED DOCUMENTS
http://search.ietf.org/internet-drafts/draft-ietf-pwe3-control-
protocol-02.txt
http://search.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-
encap-02.txt
http://search.ietf.org/internet-drafts/draft-ietf-ppvpn-l2vpn-
requirements-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-vpls-ldp-
00.txt
http://www.ietf.org/internet-drafts/draft-ietf-ppvpn-l2-framework-
03.txt
http://search.ietf.org/internet-drafts/draft-rosen-ppvpn-l2-
signaling-03.txt
WHERE DOES THIS FIT IN THE PICTURE OF THE SUB-IP WORK
PPVPN
Radoaca, et. al Expires: December 2003 [Page 2]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
WHY IS IT TARGETTED AT THIS WG
The charter of the PPVPN WG includes L2 VPN services and this
draft specifies a distributed model for Ethernet L2 VPN services
over MPLS.
JUSTIFICATION
Existing Internet drafts specify how to provide point-to-point and
multi-point Ethernet L2 VPN services over MPLS. This draft defines
how multipoint Ethernet services can be provided using the
distributed model, a Generalized Signaling mechanism [PEW3-CTRL]
and scalability requirements to be implemented.
Table of Contents
Status of this Memo..............................................1
Abstract.........................................................2
Conventions Used.................................................2
1. Introduction..................................................3
1.1 Overview...................................................4
1.2 Attributes of the distributed model..........................5
1.3 Functional components........................................6
1.4 GVPLS Topological model......................................6
2.10 SP Address scheme mapping to the VPLS core..................9
2.11 N-PE's VSI and FIBs........................................10
3. Signaling....................................................10
3.1 Identify the SAII with the local or remote N-PE.............11
3.2 Egress N-PE processing......................................12
4. Data Plane Aspects...........................................12
4.1 Access Encapsulation........................................12
4.2 VPLS Core Encapsulation.....................................13
4.3 Forwarding..................................................13
4.4 Replication and flooding....................................13
4.5 OAM Mechanism...............................................13
5. VPLS Resiliency..............................................14
6. Security Considerations......................................14
7. Compliance with the PPVN Requirements........................14
8. References...................................................15
9. Acknowledgments..............................................15
10. Intellectual Property Considerations........................16
11. Authors' Addresses..........................................16
1. Introduction
Radoaca, et. al Expires: December 2003 [Page 3]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
This document describes virtual private LAN service (VPLS)
solution over MPLS, called Generalized VPLS/LPE (GVPLS), based on
the distributed model, and the Generalized signaling method [PWE3-
CTRL].
In the current landscape of VPLS solutions there are other
attempts to describe the distributed model, e.g. [DTLS] and
[ROSEN-LDP].
This draft is different from the approach taken in [ROSEN-LDP], as
follows:
. The proposed model uses a Service Provider address scheme that
is independent from the access network type. This would allow
use of different access connectionless protocols to be included
as part of the VPLS solution and to interwork seamlessly with
protocols like PW or Provider VLAN based Ethernet Access
Networks
. The algorithm used for selecting the VPLS core PWs presented in
[ROSEN-LDP] is a sub-set of the algorithm that is proposed in
the current solution. Also, the GVPLS algorithm is applicable
for non-distributed model and it allow further optimisations in
order to increase the scalability of the VPLS PWs
. It describes a complete VPLS solution
. The unknown and mulitcast traffic is well optimized
. Allows inter-working between [VPLS] and the distributed model
1.1 Overview
Following [L2-FRW], regardless of the signaling and auto-discovery
protocols, two paradigms can be identified for the VPLS solutions:
. Non-distributed model - the MAC learning/forwarding and VPLS
forwarding is done in a PE device
. Distributed model - the VPLS functionality like MAC
learning/forwarding and VPLS forwarding is distributed across
the U-PE and the N-PE devices
[VPLS] describes a non-distributed solution where the VPLS
functionality is concentrated in the PE device. The solution is
enhanced with a hierarchical model (called HVPLS), by using U-PE
and N-PE devices. The U-PE and N-PE devices are connected via P2P
PWs to address number of PW between PE devices or provider VLAN
based Ethernet access networks, however, both U-PE and N-PE
devices perform customers MAC learning and forwarding.
Following the Reference Model for VPLS in [L2-FRW] the
GVPLS solution extends and complements the non-distributed model
to support the distributed model. In this respect, GVPLS extends
the [VPLS] model in two key areas: access network and core
network.
Radoaca, et. al Expires: December 2003 [Page 4]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
The access network is extended with a new type of U-PE device that
is capable to perform the VPLS service, with or without the N-PE
devices. Therefore, such devices would perform MAC learning and
forwarding to other U-PE devices and may perform auto-discovery
and signaling of the VPN membership. In order to enable and scale
such model, besides PWs [PWE3-CTRL] usage, or provider VLAN based
ethernet access networks, new encapsulation methods may be
proposed in the future.
The U-PE devices can be connected with core network via Ethernet
access networks when the traffic between U-PEs can be switched
without the involvement of the N-PEs. Also, the U-PE devices can
be connected directly via PWs.
The VPLS core is built using PW, based on the Generalized PW model
[PWE3-CTRL].
1.2 Attributes of the distributed model
It is recognized that SP may deploy the non-distributed model
and/or the distributed model, based on different vendors
solutions, scalability, reachability and port density
requirements.
While the non-distributed model has values, like simplicity, easy
of deployment and manageability, it is well recognized that the
distributed model has some compelling attributes:
. Allows deploying, in flexible way, the U-PE devices in the COs
or close to the CPE devices. Also, by dividing the work between
the U-PE and N-PE devices, the N-PE single failure impact is
limited, compare to the non-distributed model.
. Allows creating access networks where a significant percentage
of the traffic would stay local, without involving the N-PE
devices in switching such traffic.
. Allow a large number of VPNs to be deployed in the SP domain,
when the CE devices are mainly L2 Bridges - this is a direct
result of eliminating MAC learning in the N-PE devices, hence
MAC explosion in the Metro core.
In addition, by mixing the two models, a SP can incrementally
deploy the VPLS service, based on the complex characteristics of
the metro [such as customer density, diversity of the Ethernet
ports, co-existence with legacy SDH/SONET infrastructure]. A VPLS
offer can start from an access network, only with the U-PE
devices, upgraded with an MPLS core, or can start from a non-
distributed model and upgraded to a distributed model if the
scalability parameters require such extension.
Radoaca, et. al Expires: December 2003 [Page 5]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
1.3 Functional components
GVPLS extends the functional components described in [VPLS] and
[PWE3-CTRL} in order to accommodate the distributed model. As such
the following components are discussed:
. Control plane
o Signaling
o Auto-discovery
. Data plane
The provisioning and auto-discovery components would be presented
in separate drafts. This draft focuses on the signaling and data
plane aspects.
1.4 GVPLS Topological model
The GVPLS topological model is described in the figure 1.
| |
| +----+ |
| /| P | |
| / +----+\ |
---------------------|-----/ \ |
| | /| \ |
+----+ | +-------+ | / | \ |
| CE |-|--| U-PE |\ | / | \ |
+----+ | +-------+ \ | / | \| +----+
| \ +---------+| +-------+ +-| CE |
+----+ | +-------+ \| || | | / +----+
| CE |-|--| U-PE |----| N-PE || | N-PE |<
+----+ | +-------+ /| || | | \ +----+
| / +---------+| +-------+ +-| CE |
+----+ | +-------+ / | \ | / | +----+
| CE |-|--| U-PE |/ | \| / |
+----+ |/ +-------+ | \ +---+ +---+ |
/ | |\| P |--| P | |
+----+/|--------------------|-----| +---+ +---+ |
| CE | Distributed model | |Non-distributed
+----+ | Core Network | model
| |
Figure 1
The VPLS model [VPLS] is extended with the new type of devices,
called U-PE [L2-FRW], that supports VPLS functionality. Such
devices would inter-work with the N-PE or [VPLS] PE-rs devices
capable of the VPLS functionality.
Radoaca, et. al Expires: December 2003 [Page 6]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
2. Information Model
The Information model describes the essential information for the
VPLS Service and the SP network in order to do consistent
provisioning, discovering and signaling tasks. Also, the same
information data should be used by competing protocols [e.g. BGP
versus LDP in signaling] for the same functionality.
2.1 VPN-ID
A SP refers to a given VPLS by a VPN-ID [VPLS]. Such VPN-ID should
be unique in the SP context. VPN-ID format can be similar to one
used in [VPLS], [RFC2685] etc.
2.2 Device Ids
In GVPLS, the following device ids are defined:
. N-PE-id, which identifies an N-PE device
. U-PE-id, which identifies a U-PE device
A device ID is unique in the SP scope and its representation is a
matter of the SP address scheme.
2.3 SP address scheme
A distributed model is built around a specific SP address scheme
that would allow the customer packets to be classified,
encapsulated and forwarded solely based on such scheme. Following
the [L2-FRW] reference model, the U-PE devices [or U-PE interface
ports] can be used to encode such SP address scheme.
The SP address scheme has the following basic attributes:
. SRC-ID [or SRC-U-PE-ID] represents the address of the ingress U-
PE [or N-PE] device, or U-PE Interface
. DST-ID [or DST-U-PE-ID] represents the address of the egress U-
PE [or N-PE] device, or U-PE Interface
. VPN-ID represents the ID of a given VPN
The SP address scheme can be mapped into underlying access
protocols, e.g. Provider VLAN based Ethernet access networks or
[PWE3-ETHERNET].
In the distributed model, the U-PE devices are enhanced to perform
SP encapsulation with the following information: (SRC-ID, DST-ID,
VPN-ID). In addition, the U-PE devices would perform MAC learning
and forwarding against the SRC-ID and DST-ID parameters.
Radoaca, et. al Expires: December 2003 [Page 7]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
Once a packet arrives to the destination U-PE, the device would
perform forwarding decision based on the customer MAC addresses.
2.4 VC-LSP
[PWE3-CTRL] defines how to carry L2 PDUs over point-to-point
MPLS LSPs, called VC LSPs. Such VC LSPs can be carried across MPLS
or GRE tunnels. The VC-LSPs can be distributed between the U-PE
and N-PE devices, and between the N-PE devices.
2.5 VC-Label
VC-Label (or Service Label) identifies the multiplexing value, or
the service label on top of the MPLS tunnels for VC-LSPs.
2.6 VPLS Port (VP)
It represents a physical or a logical port where a VPLS is
provisioned. Such port can reside on the U-PE or N-PE device. A CE
is connected to the VPLS Port. The VPLS Port can be provisioned
with a VLAN [IEEE802.1Q], a set of VLANs or untagged (in this
case, all the traffic on such port is accepted on the VPLS).
Untagged and VLAN ports can be mixed in a VPLS scope.
2.7 VPLS EndPoint (VEP)
The VPLS EndPoint is used to represents the destination where a
packet is to be forwarded, or from where the packet is coming, as
the originating source. The VEP represents:
. A U-PE and N-PE device which contains a minimum one VPLS port,
if the device is capable to forward the packet based on MAC
destination to its VPLS ports
. A VPLS port, if the above condition doesn't hold
2.8 Source Control Flag (src-cflag)
It identifies the encoding mechanism for the ingress VEP. The
VC-Labels calculation and the MAC source learning process behavior
can be determined based on this flag.
2.9 End-to-End Path Identification
An end-to-end path between a given U-PE source and a given U-PE
destination can be described as a tuple: (SRC-U-PE-ID, DST-U-PE-
ID, VPN-ID).
Radoaca, et. al Expires: December 2003 [Page 8]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
In the VPLS core, such path should be mapped on PWs. As we will
see later, there are possible multiple paths to same DST-ID, due
to the Traffic engineering or dual homing connections of the U-PE
devices.
Let's call the N-PE device that is attached to the SRC-U-PE device
as SRC-N-PE, and the N-PE device that is attached to the DST-U-PE
device as DST-N-PE.
A VPLS core PW path that is built between two different N-PE
devices (SRC and DST), is defined as a tuple with the following
information:
<<SRC-U-PE-id, SRC-N-PE-id, VPN-ID>, <DST-U-PE-id, DST-N-PE-id,
VPN-ID >>.
The above concepts are shown in the figure 2.
+-----------+ +--------+ +--------+ +--------+
| SRC-U-PE | |SRC-N-PE| |DST-N-PE| |DST-U-PE|
+-----------+ +--------+ +--------+ +--------+
VPLS PW (VPN-ID)
< --------------------- >
End-to-End Path (VPN-ID)
< --------------------------------------------------- >
Figure 2
2.10 SP Address scheme mapping to the VPLS core
As described in section above, the key aspect of the distributed
model is to provide some sort of SP address scheme, so the
customer packets can be forwarded in the SP domain, using only the
SP address scheme.
In the distributed model, the SP address scheme encompasses the
following attributes, SRC-ID, DST-ID, VPN-FLG, and VPN-ID.
Consequently, in the access network, the customer packets should
be encapsulated with the above information.
In order for the N-PE device to forward the traffic from the
access Network (that comes with VPN-ID, SRC-ID, DST-ID
information), toward the core, it needs to find a PW, with the
following match criteria:
. VPN-ID of the PW
. DST-ID equal with the DST-U-PE-ID of the PW
. SRC-ID equal with the SRC-U-PE-ID of the PW
Radoaca, et. al Expires: December 2003 [Page 9]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
2.11 N-PE's VSI and FIBs
The N-PE VSI [L2-FRW] can be decomposed in two logical entities:
. U-VSI that performs MAC learning, identification of DST-ID and
forwarding toward the DST-ID
. N-VSI that performs mapping between DST-ID and the PW (or Set of
PWs) that leads to the DST-ID.
3. Signaling
In the following section, the GVPLS Address Scheme is mapped to
PWE3 generalized signaling method [PWE3-CTRL] with some additional
enhancements.
[PWE3-ETHERNET] defines how to carry L2 PDUs over point-to-point
MPLS LSPs, called VC LSPs. Such VC LSPs can be carried across MPLS
or GRE tunnels.
In GVPLS, the U-PE may have one control connection per N-PE
device, regardless the number of VPLS provisioned. When the U-PE
is connected via dual homing, two control sessions may exist
between this U-PE and the two related N-PEs.
This simplifies the number of control connections that need to be
maintained by the U-PE device and the amount of information that
needs to be signaled to the other U-PE members in the VPLS space.
The N-PE devices, using LDP Extended Discovery mechanism, maintain
a full mesh of LDP sessions between them.
In the distributed model the U-PE devices are attached to the N-PE
devices via a layer 2 connection, called <U-PE link>: such link
can be connection less type (for example in the case of Provider
VLAN based Ethernet access networks, or Ethernet access) or
connection oriented type using PW (Martini's style). A connection
end-to-end between two U-PEs, is composed of two U-PE links, and
one PW from N-PE to N-PE.
At a given U-PE, in a given VPLS there is a list of tuple (SRC-ID,
DST-ID). Such list can be learned in the data plane or can be
distributed in the control plane via the configuration/discovery
process. Each element of the list tells the U-PE to build U-PE
connections between the U-PE and the N-PE (between VSI-U/U-PE and
VSI/N-PE).
At a given N-PE, the VSI-N FIB is built using two lists:
. Local-list <SRC-ID: SRC-U-PE-ID, SRC-N-PE-ID, VPN-ID>
. Remote-list <DST-ID: DST-U-PE-ID, DST-N-PE-ID, VPN-ID>
Radoaca, et. al Expires: December 2003 [Page 10]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
Each tuple <<SRC-U-PE-id, SRC-N-PE-id, VPN-ID>, <DST-U-PE-ID, DST-
N-PE-ID, VPN-ID>> tells to N-PE to set a PW that can forward the
customer traffic from the SRC-ID to the DST-ID and reverse.
Using generalized signaling mechanism [PWE3-CTRL]; the mapping is
done as following:
The Local N-PE that has knowledge of the remote N-PE initiates a
setup of the LSP in the incoming (remote N-PE -> local N-PE) by
sending a Label Mapping Message with the following info:
AGI = VPN-ID
SAII= DST-U-PE-ID
TAII= SRC-U-PE-ID
The remote N-PE that has knowledge of the local N-PE initiates a
setup of the LSP in the incoming (local N-PE -> remote N-PE) by
sending a Label Mapping Message with the following info:
AGI = VPN-ID;
SAII= SRC-U-PE-ID
TAII= DST-U-PE-ID
In order for the N-PE device to forward the traffic from the
access Network (that comes with VPN-ID, SRC-ID, DST-ID
information), toward the core, it needs to find a PW, with the
following match criteria:
. VPN-ID of the PW
. DST-ID equal with the TAII of the PW
. SRC-ID equal with the SAII of the PW
For example, when the traffic is forwarding from the SRC-ID to the
DST-ID, then on the local N-PE, the DST-ID needs to match the TAII
= DST-U-PE-ID. When the traffic is forwarding from the DST-ID to
the SRC-ID, then the remote N-PE needs to match the TAII = SRC-U-
PE-ID.
An LSP between local N-PE -> remote N-PE has the forwarders
defined as following: for the local N-PE is VSI/TAII and for the
remote N-PE is VSI/SAII. Similarly, an LSP between remote N-PE ->
local N-PE has the forwarders defined as following: for the remote
N-PE is VSI/SAII and for the local N-PE is VSI/TAII.
IF we combine the above statements, then it results that for each
N-PE and a given PW, the forwarder is defined as VSI/<TAII, SAII>.
3.1 Identify the SAII with the local or remote N-PE
Radoaca, et. al Expires: December 2003 [Page 11]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
For just MPLS forwarding in the VPLS core, the only field
important is the TAII. The SAII presence is to identify the Source
of the packet for the U-PE devices so these devices can do L2 MAC
forwarding and bridge learning.
For the LSP (remote N-PE -> local N-PE), we can consider the case
when SAII = Remote-N-PE-ID. For the LSP (local N-PE -> remote N-
PE), we can consider the case when SAII = Local-N-PE-ID. So, the
following relationships hold:
LSP(remote N-PE->local N-PE) : (SAII= remote-N-PE, TAII= SRC-U-PE-
ID)
LSP(local N-PE->remote N-PE) : (SAII= local-N-PE, TAII= DST-U-PE-
ID).
In this case, the number of PWs decreases significantly (one order
of magnitude). However, for U-PE devices to properly learn the
source of the packet, the N-PE needs to transport the source in
the date plane.
The Generalized ID FEC [PWE3-CTRL] is augmented with two new
parameters:
The SRC-CW-U-PE-ID is an ID encoded for the SRC-U-PE-ID, which is
unique in the scope of a given VPN-ID. This ID can be provisioned
or generated based on algorithm that will be described in a
subsequent version of the GVPLS.
As it was stated above, during the MAC learning process the SRC-ID
is needed in order that a receiver U-PE device (DST-ID) can
forward the traffic in the VPLS core. The src-cflag denotes the
encoding mechanism for the source U-PE or N-PE device that
originates the packet.
3.2 Egress N-PE processing
At the egress side, from the N-PE to the U-PE device, the packet
is coming with the PW encapsulation, from where the SRC-ID, DST-ID
and the VPN-ID information are mapped back to the underline access
protocol.
In the case of SAII identified with the N-PE then the SRC-ID is
derived from the Data Plane encapsulation.
4. Data Plane Aspects
4.1 Access Encapsulation
In the VPLS access network, the SP address scheme (SRC-U-PE, DST-
U-PE, VPN-ID) can be implemented using different underlying
Radoaca, et. al Expires: December 2003 [Page 12]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
protocols, such as PW [PWE3-ETHERNET], or connectionless protocols
(like, Provider VLAN based Ethernet access networks). The
specification of such mapping and a signaling protocol is out of
scope of this document.
4.2 VPLS Core Encapsulation
In the VPLS core, GVPLS employs the [PWE3-Ethernet] based
encapsulation. However the SRC-ID may be encapsulated in the data
plane in order to optimize the number of PWs; this would be
described in a separate draft.
4.3 Forwarding
The U-PE device is capable to do MAC learning and forwarding based
on the SP address scheme as such SRC-ID, DST-ID, VPN-FLG and VPN-
ID. The VPN-FLG has two bits, Continuity Check [C], and Multicast
Flag [M].
In the VPLS core, the N-PE device is doing packet forwarding by
mapping the incoming tuple (SRC-ID, DST-ID, VPN-ID, VPN-FLG) with
a specific PW TAII data.
4.4 Replication and flooding
The replication and flooding uses P2P PWs, denoted as Multicast
PWs, which are constructed among the N-PE devices (with SRC-ID =
SRC-N-PE-ID, DST-ID = DST-N-PE-ID). The packets that are coming
from the access side, would have a Multicast/Unknown indication.
Based on such indication the Multicast PWs are selected.
Note
If Multicast PWs are not used, the replication needs to be done
per P2P PW that connected the U-PE devices. When multiple U-PE
devices are attached to the same N-PE device, than multiple
customer packets need to be sent to that N-PE - this may impact
the bandwidth in the core.
4.5 OAM Mechanism
The GVPLS OAM mechanism is based on the Control Word extension.
The "C" flag is set by the ingress U-PE device [or N-PE device for
non-distributed] and can be used to trigger unicast, and multicast
packets between VPs, in order to check the status of the specific
VC-LSP(s), to calculate round trip delay and other values that can
be used for SLA. For normal encapsulated data traffic, the "C"
flag is always clear.
Radoaca, et. al Expires: December 2003 [Page 13]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
5. VPLS Resiliency
The GVPLS model allows greater flexibility in building resiliency
between U-PE and N-PE devices. When a U-PE device is connected to
a single N-PE device using multiple physical links, standard link
aggregation and load-distribution techniques can be used between
the two devices. The load-distribution should be done in such a
way so as to avoid packet reordering and duplicate packets within
a VPLS instance. The exact algorithm for load balancing between U-
PE and N-PE is really a matter of local decision.
When a U-PE device is dual-homed to two different N-PE devices,
only one of the N-PE devices should be elected as the primary for
any particular VPLS. This is so as to avoid duplicate multicast
packets being transmitted to the dual-homed U-PE device. It must
be ensured that no packet-reordering or duplicate multicast
packets are sent in steady state and in any failure recovery
scenario.
Since the GVPLS model defines a SP addressing scheme to identify
individual U-PE devices (and their ports if the U-PE device is not
bridge-capable), this information can be exchanged between a dual-
homed U-PE and its N-PEs a priori, i.e. before a failure happens.
When a failure happens, the N-PEs can intelligently perform
failure recovery in the access networks as they can independently
identify the dual-homed U-PE device using the SP addressing
scheme. The exact mechanisms for failure detection and recovery
will be described further in future.
6. Security Considerations
Security issues resulting from this draft will be discussed in
greater depth at a later point. It is recommended in [RFC3036]
that LDP authentication methods be applied. This would prevent
unauthorized participation by a PE in a VPLS. Traffic separation
for a VPLS is effected by using VC labels. However, for
additional levels of security, the customer MAY deploy end-to-end
security, which is out of the scope of this draft.
7. Compliance with the PPVN Requirements
The GVPLS solution is compliant with most of the requirements.
However, the design was chosen in order to allow large deployments
of VPNs, while maintaining the PE performance and security
constant.
Radoaca, et. al Expires: December 2003 [Page 14]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
8. References
[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
01.txt, Work in progress, November 2003-03-02
[PWE3-CTRL] "Transport of Layer 2 Frames Over MPLS", draft-ietf-
pwe3-control-protocol-02.txt, Work in progress, February 2003
[802.1D-REV] 802.1D - "Information technology - Telecommunications
and information exchange between systems - Local and metropolitan
area networks - Common specifications - Part 3: Media Access
Control (MAC) Bridges: Revision. This is a revision of ISO/IEC
10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates
P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998
[IEEE802.1Q] 802.1Q - ANSI/IEEE Draft Standard P802.1Q/D11, "IEEE
Standards for Local and Metropolitan Area Networks: Virtual
Bridged Local Area Networks", July 1998
[BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs" draft-ietf-ppvpn-
rfc2547bis-03.txt
[RFC3036] "LDP Specification", Andersson, et al RFC 3036, January
2001
[VPLS-REQ] "Requirements for Virtual Private LAN Services (VPLS)",
draft-ietf-ppvpn-vpn-requirements-01.txt, Work in progress,
October 2002
[VPLS] Lasserre, M. et al., " Virtual Private LAN Services over
MPLS", draft-ietf-ppvpn-vpls-ldp-00.txt, work in progress,
December 2003.
[LPE] Ould-Brahim, H., et al., "VPLS/LPE L2VPNS: Virtual Private
LAN Service using logical PE architecture", draft-ouldbrahim-
l2vpn-lpe-02.txt, work in progress, March 2002
[L2-FRW] L2 PPVN framework, draft-ietf-ppvn-l2-framework-03.txt,
work in progress, August 2003
[ROSEN-LDP] Eric Rosen "LDP-based signaling for L2VPNs", draft-
rosen-ppvpn-l2-sign-03.txt, work in progress, November 2003
[VPLS-COMP] Michael Chen, Mohan Dinesh, Vasile Radoaca "VPLS
solutions: Commonalities and Differences", work in progress,
draft-chen-ppvn-dvpls-compare-04.txt, February 2003
9. Acknowledgments
Radoaca, et. al Expires: December 2003 [Page 15]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
The GVPLS solution came out with the help, generous ideas, and
efforts from a lot of people. We would like to recognize the
involvement of Mirza Arifovic, and Hesahm Elbakouri in drafting
the solution. We would also like to acknowledge Hamid Ould-Brahim,
Lakkapragada, Shobhan from Nortel Networks, for their
contributions. In addition we like to thank to Eric Rosen, Ali
Sajassi from Cisco, Don O'Connor from Fujitsu for their comments
and participation during this work.
10. Intellectual Property Considerations
Nortel Networks may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or
become protected by one or more patents assigned to Nortel
Networks, Nortel Networks intends to disclose those patents and
license them on reasonable and non-discriminatory terms.
11. Authors' Addresses
Vasile Radoaca
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: (781) 856-0590/978-288-6097
Dinesh Mohan
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 763 4794
Email: mohand@nortelnetworks.com
Lakkapragada, Shobhan
Nortel Networks
600 Technology Park
Billerica, MA 01821
Javier Achirica
Telefonica Data
Email: javier.achirica@telefonica-data.com
Pascal Menezes
Terabeam Networks, Inc.
14833 NE 87th St.
Redmond, WA, USA
Phone: (206) 686-2001
Email: Pascal.Menezes@Terabeam.com
Ananth Nagarajan
Radoaca, et. al Expires: December 2003 [Page 16]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
Sprint
9300 Metcalf Ave,
Overland Park, KS 66212, USA
ananth.nagarajan@mail.sprint.com
Himanshu Shah
Tenor Networks
100 Nagog Park
Email : hshah@tenornetworks.com
Yaron Raz
Atrica
Email : yaron_raz@atrica.com
Andrew G. Malis
Vivace Networks, Inc.
2730 Orchard Parkway
San Jose, CA 95134
Andy.Malis@vivacenetworks.com
Simon Hunt
186k
Simon.Hunt@186k.co.uk
Muneyoshi Suzuki
NTT Information Sharing Platform Labs.
3-9-11, Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: suzuki.muneyoshi@lab.ntt.co.jp
Alain Vedrenne
Equant, Customer Service & Network
Strategic Technology Planning
Heraklion; 1041 route des Dolines; BP347
06906 Sophia Antipolis; Cedex; France
Phone: +33-(0)4-92-96-57-22 (7-223-5722)
12. 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 developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
Radoaca, et. al Expires: December 2003 [Page 17]
Internet Draft draft-radoaca-ppvpn-gvpls-02.txt June 2003
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.
