Provider Provisioned VPN WG Michael Chen
Dinesh Mohan
Internet Draft Nortel Networks
draft-chen-ppvpn-dvpls-compare-00.txt
Expiration Date: September 2002 Pascal Menezes
Terabeam
Loa Andersson
Utfors
March 2002
Decoupled/Hierarchical VPLS: Commonalities and Differences
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
This draft describes commonalities and differences between decoupled
and hierarchical architectures to support scalable Virtual Private
LAN Services (VPLS). The need to maintain a full mesh of control
connections (e.g. LDP, BGP, etcà) and transport paths between all PEs
that are service aware may impose a scalability limit on the non
decoupled VPLS architecture. On the other hand, a VPLS based solution
Chen, et. al Expires September 2002 [Page 1]
Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002
is required to meet the scaling requirement where the PEs facing
customer devices and attached to a core network need to perform MAC
learning for all the VPLS services
Proposed decoupled and hierarchical architectures are aimed towards
improving customer MAC address management on the provider core
network and reducing the number of control and transport connections
needed between service aware devices by introducing levels in the
network. This draft is an attempt to describe commonalities and
differences between these architectures.
Table of Contents
Abstract
1. Convention used in this document.........................2
2. Introduction.............................................2
3. Functions to support VPLS................................3
3.1 Control Plane functions.................................3
3.2 Forwarding Plane functions..............................3
4. Control Plane Architecture...............................4
4.1 Architecture Between "Core" Devices.....................4
4.2 Architecture Between "Core" and "Edge" Devices..........4
4.3 Configurations of Decoupled VPLS........................5
5. Forwarding Plane Architecture............................6
5.1 MAC learning............................................6
5.2 Customer VLAN processing................................6
5.3 Customer traffic prioritizing, policing, and shaping....6
5.4 Customer packet encapsulation...........................6
5.5 Packet replication/Flooding.............................7
5.6 Service label de-multiplexing...........................7
6. Security Considerations..................................7
7. References...............................................7
8. Acknowledgments..........................................7
9. Author's Addresses.......................................7
Full Copyright Statement....................................8
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
2. Introduction
This draft describes commonalities and differences between decoupled
and hierarchical architectures to support VPLS. In the non-decoupled
and non-hierarchical VPLS architecture model, it is required that a
full mesh of signaling connections (e.g. LDP) and transport paths
exist between service aware devices (i.e. PE). The need to maintain a
full mesh of control connections (e.g. LDP, BGP, etcà) and transport
Chen, et. al Expires September 2002 [Page 2]
Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002
paths between all service aware devices may impose a scalability
limit on the VPLS architecture. On the other hand, a VPLS based
solution is required to meet the scaling requirement where the PEs
facing customer devices and attached to a core network need to
perform MAC learning for all the VPLS services.
Proposed decoupled and hierarchical architectures ([LPE ARCH],
[DTLS], and [HVPLS]) are aimed towards improving customer MAC address
management on the provider core network and reducing the number of
control and transport connections needed between service aware
devices by introducing levels in the network. This draft is an
attempt to describe commonalities and differences between these
architectures.
This draft is not an attempt to endorse any single architecture over
the other architectures. As discussed later, the differences among
the three architectures are not critical and this draft could
facilitate discussion towards merging and enhancing the current
decoupled/hierarchical VPLS proposals. This draft is viewed as a
step towards a unified decoupled/hierarchical VPLS solution.
Figure 1 illustrates a general decoupled/hierarchical VPLS
architecture.
+------+ +------+ +----------------+ +------+ +------+
|"Edge"| û |"Core"| û |Backbone Network| û |"Core"| û |"Edge"|
+------+ +------+ +----------------+ +------+ +------+
Figure 1
This document will first describe the functions required to support
VPLS. In section 4, a description of the commonalities and
differences between the architectures in the control plane will be
given. In section 5, a description of the commonalities and
differences between the architectures in the forwarding plane will be
given.
3. Functions to support VPLS
Following are some of the functions needed to create VPLS. [LPE-
ARCH] describes most of these functions in more detail.
3.1 Control Plane functions
o VPLS membership auto-discovery
o Transport tunnel signaling
o Service label signaling
o VPLS Configurations
3.2 Forwarding Plane functions
o MAC learning
o Customer VLAN processing
Chen, et. al Expires September 2002 [Page 3]
Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002
o Customer traffic prioritizing, policing, and shaping
o Customer packet encapsulation
o Packet replication/Flooding
o Service label de-multiplexing
4. Control Plane Architecture
The VPN membership auto-discovery and service label signaling
functions described in [LPE ARCH], [DTLS], and [HVPLS] contain both
point-to-point and point-to-multipoint signaling. Point-to-point
signaling connectivity implies that every device has a signaling
connection to all its peer devices. An example of point-to-point
signaling is targeted LDP. Point-to-Multipoint signaling refers to
that there exist some mechanism where a device has only a few
signaling connections to some entity. The mechanism then relays the
information to all the peers of the device. An example of point-to-
multipoint signaling is BGP with RR.
In both decoupled and hierarchical architectures, there is a need to
distinguish between the control plane functions between the "Core"
devices and control plane functions between "Edge" and "Core"
devices. Creating levels in control plane connections to enhance
control plane scalability is the common theme in all proposed
decoupled and hierarchical VPLS architectures. "Core" devices serve
as signaling gateway between its subtending "Edge" devices and the
rest of the provider network.
4.1 Architecture Between "Core" Devices
Proposals [LPE ARCH], [DTLS], and [HVPLS] all describe a full mesh
transport tunnel signaling connections between "Core" devices.
[HVPLS] combines its auto-discovery signaling with service label
signaling and uses point-to-point signaling connections. Targeted
LDP is the mechanism described in [HVPLS]. HVPLS architecture
creates a full mesh of auto-discovery/service label signaling
connections between "Core" devices.
[DTLS] also combines its auto-discovery signaling with service label
signaling. However it can use point-to-point or point-to-multipoint
signaling connections to convey auto-discovery information to its
peer "Core" devices. BGP is the mechanism described in [DTLS].
[LPE ARCH] describes more of an architecture framework. The document
does not describe a particular auto-discovery and service label
signaling scheme.
4.2 Architecture Between "Core" and "Edge" Devices
[HVPLS] and [DTLS] describes "Edge" devices connected to "Core"
devices via point-to-point links. However, these point-to-point
links can be either physical or virtual (e.g. FR, ATM, etcà). With
physical links, it does not require any transport tunnel signaling
Chen, et. al Expires September 2002 [Page 4]
Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002
between "Core" and "Edge" devices. However, sets of point-to-point
transport tunnel signaling connections between "Core" and "Edge"
devices are required for creating and maintaining point-to-point
virtual links.
[LPE ARCH] uses switched Ethernet transport as the mechanism to move
traffic between "Core" and "Edge" devices. This scheme is similar to
MPLS-in-IP [MPLS-IN-IP] where transport tunnels do not exist thus
there is no need for a transport tunnel signaling scheme.
[HVPLS] combines its auto-discovery signaling with service label
signaling and uses point-to-point signaling connections. There is a
single auto-discovery/service label signaling connection between
"Core" and every "Edge" devices. The mechanism described again is
targeted LDP.
[LPE ARCH] does not specifically describe a particular auto-
discovery and service label signaling scheme between "Core" and
"Edge" devices. However, [LPE AD] describes a point-to-multipoint
mechanism utilizing the broadcast capability of the switched
Ethernet transport. All "Core" and "Edge" devices in the same
switched Ethernet transport domain can receive auto-discovery and
service label information from other service aware devices within
the same switched Ethernet transport.
[DTLS] does not specifically describe a particular auto-discovery
and service label signaling scheme between "Core" and "Edge"
devices.
4.3 Configurations of Decoupled VPLS
Proposal [HVPLS] requires Edge devices to create a single point-to-
point spoke VC, for each VPLS service supported on this Edge device,
to Core device using [MARTINI-SIG]. The Edge device negotiates the
VC labels with the Core device. Addition of other Edge devices to
add new customer sites requires configuration of the new Edge device
but no configuration changes to existing Edge devices.
Proposal [DTLS] describes both mechanisms where configurations can
be partly carried out on Edge and Core devices and only on Core
devices. However the focus is on having a protocol between Edge and
Core device such that configuration information can be carried from
Core device to the Edge devices. With over provisioning, addition of
new Edge devices need not require additional configuration. But when
not over provisioned, configuration needs to be done on Core devices
and/or new Edge device.
[LPE ARCH] proposes VPLS configurations to be carried out at Edge
device or at Core device. The objective is to configure customer
facing ports on Edge devices and associating the port/endpoints to
the VPLS service. It supports use of signaling between Edge device
and Core device to distribute configuration information or use of
auto-discovery mechanism. [LPE AD] is an example of signaling and
Chen, et. al Expires September 2002 [Page 5]
Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002
auto-discovery mechanism for Edge devices to distribute information
within the LPE. [LPE ARCH] also supports dual VPN membership schemes
within the Edge and Core devices and among the Core devices. In such
cases, VPN membership mapping function is configured at the Core
devices.
5. Forwarding Plane Architecture
In [DTLS], all virtual bridge (VB) instances only exist in "Edge"
devices. DTLS scheme basically creates full mesh tunnels through
service labels between all VBs that have membership to the same
VPLS.
Like [DTLS], all VB instances in [LPE ARCH] only exist in the "Edge"
devices. [LPE ARCH] also creates full mesh tunnels through service
labels between all VBs that have membership to the same VPLS.
However, unlike [DTLS], traffic between two "Edge" devices in the
same switched Ethernet transport domain does not need to go through
the "Core" device. If one reduces the switched Ethernet transport to
a point-to-point Ethernet connection, then [DTLS] and [LPE ARCH]
have similar forwarding plane architecture.
In [HVPLS], VB instances exist in both "Edge" and "Core" devices.
[HVPLS] creates full mesh tunnels through service labels between all
VBs in "Core" devices that have membership to the same VPLS. Each VB
in the "Core" also have a hub and spoke structure to its "Edge"
devices. The hub is the "Core" VB and the spokes are the "Edge" VBs.
[HVPLS] basically creates a tree structure in forwarding plane where
the base of the tree composes of a full mesh of "Core" VBs. Each
"Core" VB then has branches to its relatd "Edge" VBs.
5.1 MAC learning
[LPE ARCH]: "Edge" devices only
[DTLS]: "Edge" devices only
[HVPLS]: Both "Edge" and "Core" devices
5.2 Customer VLAN processing
[LPE ARCH]: "Edge" devices only
[DTLS]: "Edge" devices only
[HVPLS]: Both "Edge" and "Core" devices
5.3 Customer traffic prioritizing, policing, and shaping
[LPE ARCH]: "Edge" devices only
[DTLS]: "Edge" devices only
[HVPLS]: Both "Edge" and "Core" devices
5.4 Customer packet encapsulation
[LPE ARCH]: "Edge" devices only
[DTLS]: "Edge" devices only
[HVPLS]: Both "Edge" and "Core" devices
Chen, et. al Expires September 2002 [Page 6]
Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002
5.5 Packet replication/Flooding
[LPE ARCH]: "Edge" devices, switched Ethernet transport and "Core"
devices
[DTLS]: "Edge" devices only
[HVPLS]: Both "Edge" and "Core" devices
5.6 Service label de-multiplexing
[LPE ARCH]: "Edge" devices only
[DTLS]: "Edge" devices only
[HVPLS]: Both "Edge" and "Core" devices
6. Security Considerations
This document describes commonalities and differences between
decoupled and hierarchical architectures to support Virtual Private
LAN Service (VPLS). Implementations of the architectures may have
their own set of security issues. However, the architectures
themselves do not contain security issues.
7. References
[DTLS] Kompella, K., et al. "Decoupled Transparent LAN Services",
draft-kompella-ppvpn-dtls-00.txt, work in progress, October 2001.
[HVPLS] Khandekar, S., et al., "Hierarchical Virtual Private LAN
Service", draft-khandekar-ppvpn-hvpls-mpls-00.txt, work in
progress, November 2001.
[LPE ARCH] Ould-Brahim, H., et al., "VPLS/LPE: Virtual Private LAN
service using the logical PE architecture", draft-ouldbrahim-
l2vpn-lpe-00.txt, work in progress, November 2001.
[LPE AD] Knight, P., et al., "Logical PE Auto-Discovery Mechanism",
draft-knight-l2vpn-lpe-ad-00.txt, work in progress, November
2001.
[MARTINI-SIG] Martini, L., et al., "Transport of Layer 2 Frames Over
MPLS", draft-martini-l2circuit-trans-mpls-08.txt, work in
progress, November 2001.
[MPLS-IN-IP] Worster, T., et al., "MPLS Label Stack Encapsulation in
IP ", draft-worster-mpls-in-ip-05.txt, work in progress, July
2001.
8. Acknowledgments
Many thanks to Hamid Ould-Brahim who contributed heavily into this
draft and helped to refine the contents.
9. Author's Addresses
Michael Chen
Chen, et. al Expires September 2002 [Page 7]
Internet Draft draft-chen-ppvpn-DVPLS-compare-00.txt March 2002
Nortel Networks
4010 E Chapel Hill-Nelson Hwy
Research Triangle Park, NC 27709 USA
Phone: +1 (919) 997 3840
Email: mchen@nortelnetworks.com
Dinesh Mohan
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 763 4794
Email: mohand@nortelnetworks.com
Pascal Menezes
Terabeam
14833 NE 87th St.
Redmond, WA, USA
Phone: +1 (206) 686 2001
Email: pascal.menezes@terabeam.com
Loa Andersson
Utfors AB
Rasundavagen 12
Box 525, 169 29 Solna
Sweden
Phone: +46 8 5270 2000
Email: loa.andersson@utfors.se
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 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.
Chen, et. al Expires September 2002 [Page 8]