Internet Engineering Task Force CY Lee
INTERNET DRAFT M. Higashiyama
Informational
March 2003
CE-based Virtual Private LAN
<draft-lee-ce-based-vpl-02.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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This draft describes how a Virtual Private LAN (VPL) can be realized
by setting up point-to-point tunnels from CE (Customer Edge) or CLE
(Customer Located Equipment) to CE/CLE over a PSN, and bridging
Ethernet traffic at the CE/CLE. Regardless of the access technology
used (e.g. DSL or Ethernet) or the geographic distribution of
CEs/CLEs, an end customer may use an emulated LAN service via an
Ethernet interface, as long as the CEs/CLEs of the emulated LAN are
reachable over the PSN. When used in conjunction with IPSec, the
proposal allows secure transmission of Ethernet traffic, from one
site to another site of a VPL, over the PSN.
1. Introduction
CE-based VPL over different types of tunneling technologies has been
used for a number of years now, and could be viewed as a proven
technology. A network user provisions the required tunnels (or
circuits) at a CE to remote CE(s) and the CEs bridge Ethernet traffic
over the tunnels.
2. Topology
2.1 Reference Model
Figure 1 shows CE-based VPL topology. In a CE-based VPL, tunnels are
setup between sites of a VPL. A CE-based VPL can contain a single
IEEE 802.1q VLAN or multiple VLANs. Each site has either a CE or CLE
connected to the PSN. In a PPVPL, the provider provisions the VPL, a
tunnel MAY be setup from CLE to CLE, and the CLEs MAY be owned by the
provider, or the tunnels MAY be setup from CE to CE, and the CEs MAY
be owned by the customer. In a CPVPL, a customer provisions its own
VPL, a point to point tunnel from CE to CE may be provisioned by the
customer at CEs or alternatively, a point to point tunnel may be
provisioned by the provider from PE to PE. A tunnel appears as a
virtual port or interface to the bridge entity in a CE.
At a CE, Ethernet traffic from a VPL is encapsulated in for e.g. a
L2TPv3 or GRE or IPSec tunnel or FR VC or ATM VCC and transported
over the IP/FR/ATM network to another CE of the VPL. The receiving CE
decapsulates the Ethernet frame, and bridges the frame from virtual
port to the destination node in the VPL.
Emulated Service
(Broadcast Domain/"LAN", within dotted lines)
..................................
Native . . Native
Ethernet . . Ethernet
or . |<-- PSN Tunnel-->| . or
VLAN . . VLAN
Service . +----+ +----+ . Service
| . |CE/ | |CE/ | . |
Customer-------.--|CLE |=================|CLE |-.------- Customer
LAN | . | 1 | | 2 | . | LAN
Site 1 | . +----+ +----+ . | Site 2
. \\ // .
. \\ // .
. \\ // .
. PSN \\ // PSN .
. Tunnel \\ +----+ // Tunnel.
. \\|CE/ |// .
. \|CLE |/ .
. | 3 | .
. +----+ .
. | .
..................................
|
|
Native Ethernet or
VLAN Service
|
|
Customer LAN
Site 3
|
|
Customer ----------------|----------------Customer
LAN Site 1 | LAN Site 2
|
|----------------Customer
| LAN Site 3
Fig 1 Emulated Ethernet Segment
CLE1 CLE2
+-----------+ +-----------+
|\ /| |\ /|
| \ Relay / | | \ Relay / |
| \ / | | \ /<-|-----+
| \ / | | \ / | |ISS,E-ISS
| \ / | | \</----|-----+
| V | | V |
| MAC | E | | E | MAC |
+--+--+--+--+ +--+--+--+--+
| | virtual| |LAN port
| | port | |
| | PSN | |
| +------------------+ |
| |<---------PW----------->| |
| A A |
| |
................................................
. | | .
. | | .
................................................
Emulated LAN
Figure 2
The Encapsulation (E) Entity, is responsible for encapsulating frames
to be transported over the PSN. The Internal Sublayer Service (ISS)
and Enhanced Internal Sublayer Service (E-ISS), i.e. the indication
and request primitives provided by a MAC entity to the MAC Relay
Entity within a CE is as defined in 802.1d and 802.1q. The E entity
provides similar service primitives as the MAC entity, except that
the handling of the Frame Check Sequence (FCS) parameter may be
changed.
The Relay is a bridge as defined in 802.1d and optionally 802.1q.
CLEs process BPDUs, as defined in 802.1d and optionally 802.1q, and
MAC control frames as defined in IEEE specifications.
If a modified bridge (performing reverse split horizon forwarding on
a full-meshed of PWs, I.e. traffic received on a PW is not forwarded
to other PWs) is used, the modified bridge would reside between the
Relay and the VP. The use of a modified bridge in a CLE is being
reviewed, as it may introduce routing or briding issues in the
customer's network.
2.2 Terminology
CE Customer Edge [PPVPN-REQ]
CLE Customer Located Equipment
CPVPL Customer Provisioned VPL
LCCE L2TP Control Connection Endpoint [L2TPv3]
MAN Metropolitan Area Network
P Provider's Network Equipment (excluding PE)
PE Provider Edge [PPVPN-REQ]
PPVPL Provider Provisioned VPL
PSN Packet Switched Network
PW Pseudo-Wire
VPL Virtual Private LAN
3. Control Plane
For the CE-based VPL, control plane use [ETH-PW-L2TPv3]. Pseudo-wire
Ethernet over L2TPv3 is specified in [ETH-PW-L2TPv3] and describes
how network devices emulate ethernet over an IP network using L2TPv3
as the tunneling protocol. CEs supporting [ETH-PW-L2TPv3]in a PPVPL
or CPVPL are applications of [ETH-PW-L2TPv3].
Below additional functions of these applications are required.
- Tunnel Endpoints Information Configuration
- VPL Monitoring
3.1 Tunnel Endpoints Information Configuration
The required tunnel endpoint information at an LCCE (CE) are the IP
addresses and End Identifiers of peer LCCEs, and authentication keys.
The tunnel endpoints information may be pre-configured or remotely
provisioned or, a mechanism to discover and distribute the tunnel
endpoints information may be used or a mechanism where tunnel
endponts information are retrieved from a server may be used.
3.2 Discovery
Multiple tunnels to other CE sites can be automatically configured on
CEs if a tunnel endpoint information discovery mechanism is used.
To avoid having to provision deployed CEs, a mechanism to auto
discover and distribute VPL site information is useful. [CE-
AUTOCONFIG] or a directory query approach similar to [VPLS-DNS] are
examples of mechanisms that may be used for this purpose. In
particular for [CE-AUTOCONFIG], the Authentication Server/RADIUS
approach is applicable to both a PPVPL and CPVPL, while the DHCP
approach is only applicable to a PPVPL where the CEs are within one
domain (e.g for VPLs offered by a network provider).
3.3 VPL Monitoring
The session keep-alive mechanism of L2TPv3 can serve as a link status
monitoring mechanism for the point to point tunnels (session) that
make up the VPL. Testing of reachability of nodes in the VPL from
different sites may be performed at irregular intervals.
4. Data Plane
4.1 Encapsulation
Please see [ETH-L2TPv3].
4.2 Forwarding
A CE learns MAC addresses from the customer facing ports and the
virtual interfaces (or the tunnels to remote LCCE sites of a VPL).
When a new MAC address is learned, the MAC address is associated with
the virtual interface or ports where the frame arrives. When a frame
with the cached MAC address is received, the CE knows which virtual
interface or port to forward the frame to. When a frame with a new
MAC address is received, a CE floods the frame to all other ports or
virtual interfaces, except the interface where the frame is received
from.
The learning, bridging, filtering and forwarding procedures are as
defined in [802.1d] and [802.1q], except that the ports on a switch
in this case can be a virtual interface as well as a physical port.
CEs belonging to the same VPL learn, store, manage VPL forwarding
information and bridges traffic within the VPL, PEs do not have to
learn MAC addresses from different VPLs, hence this approach scales
for large number of VPLs and total MAC addresses in a network.
Bridging within a VPL does not affect other VPLs (or customers). A CE
bridge which is not functioning correctly will only affect a VPL. In
contrast, if bridging is also performed at PEs, a malfunctioning CE
may cause network instability and affect other VPLs as well. Hence a
CE-based VPL would be operationally stabler.
In a network based VPL, as the number of customers/VPLS and total MAC
addresses grow in a provider's network, existing devices in the
network will need to be upgraded or replaced by new devices. A CE-
based VPL approach scales as the number of VPLs and total number of
MAC addresses in VPLs grows and allows CEs in different MAN to be
interconnected seamlessly.
New VPLs can be added transparently in an IP/MPLS network, without
having to upgrade PEs with bridging functions.
CEs of a VPL may be located witin one domain or in different domains
as long as the CEs have IP reachability to each other. CEs of a VPL
in different MAN can send VPL traffic to each other without resorting
to VLAN Stacking as long as there is IP reachability in the network.
Tunnels may be setup using L2TP with IPSec [L2TP-IPSec] to provide
secure transmission of traffic from CE to CE in an IP PSN.
5. References
5.1 Normative References
[802.1D] IEEE, "ISO/IEC 15802-3:1998,(802.1D, 1998 Edition),
Information technology --Telecommunications and information exchange
between systems --IEEE standard for local and metropolitan area
networks --Common specifications-Media access control (MAC) Bridges",
June, 1998.
[802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area Networks",
1998 .
[802.3] IEEE, "ISO/IEC 8802-3: 2000 (E), Information technology--
Telecommunications and information exchange between systems --Local
and metropolitan area networks --Specific requirements --Part 3:
Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
Access Method and Physical Layer Specifications", 2000.
[L2TPv3] Lau, J., Townsley, M., Valencia, A., Zorn, G., Goyret, I.,
Pall, G., Rubens, A., Palter, B., "Layer Two Tunneling Protocol
"L2TP"", (draft-ietf-l2tpext- l2tp-base-01.txt), work in progress,
July 2001.
[L2TP-IPSEC] RFC 3193, B. Patel,B. Aboba,W. Dixon, G. Zorn, S. Booth
"Securing L2TP using IPSec"
[ETH-L2TPv3] Aggarwal, et al., Transport of Ethernet Frames over
L2TPv3, draft-ietf-l2tpext-pwe3-ethernet-00.txt, October 2002.
[ETH-PW-L2TPv3] CY Lee, M Higashiyama, Ethernet Pseudo-Wire over
L2TPv3, November 2002
5.2 Informative References
[L2VPN-REQ] W. Augustyn, Y. Serbest, Service Requirements for Layer 2
Provider Provisioned Virtual Private Networks, February 2003
[BCP] Mitsuru H. and Baker, "PPP Bridging Control Protocol (BCP)",
RFC 2878, July 2000.
[L2TP] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G., Zorn,
G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661
August 1999
Internet Architectural Guidelines and Philosophy.
http://www.ietf.org/internet-drafts/draft-ymbk-arch-guidelines-05.txt
[EOL2TP] M. Higashiyama, "Ethernet Over L2TP", (draft-higashiyama-
eol2tp-01.txt),
[PPVPN-REQ] M. Carugi,D. McDysan, L. Fang, F. Johansson, Ananth
Nagarajan, J. Sumimoto, R. Wilder, "Service requirements for Layer 3
Provider Provisioned Virtual Private Networks" (draft-ietf-ppvpn-
requirements-04.txt)
[CEVPN] De Clercq J., et al., "Provider Provisioned CE-based Virtual
Private Networks using IPsec", draft-ietf-ppvpn-ce-based-01.txt, work
in progress.
[Kompella] Kompella, K., Leelanivas, M., Vohra, Q., Bonica, R., Metz,
E., Ould-Brahim, H., Achirica, J., Z., "MPLS-based Layer 2 VPNs",
(draft-kompella- ppvpn-l2vpn-00.txt), work in progress, July 2001.
[Martini-encap] Martini, L., El-Aawar, N., Tappan, D., Rosen, E.,
Jayakumar, J., Vlachos, D., Liljenstolpe, C., Heron, G., Kompella,
K., Vogelsang, S., Shirron, J., Smith, T., Radoaca, V., Malis, A.,
Sirkay, V., Cooper, D., "Encapsulation Methods for Transport of
Layer 2 Frames Over IP and MPLS Networks", (draft-martini-
l2circuit-encap-mpls-03.txt), work in progress, July 2001.
[PWE3-frame] Pate, P., Xiao, X., So, T., Malis, A., Nadeau, T.,
White, C., Kompella, K., Johnson, T., "Framework for Pseudo Wire
Emulation Edge-to-Edge (PWE3)" (draft- pate-pwe3-framework-02.txt),
work in progress, July 2001.
[VPLS] Lasserre, M, Kompella, V, et al, "Virtual Private LAN Services
over MPLS" draft-lasserre-vkompella-ppvpn-vpls-01.txt, March 2002
[VPLS-DNS] Heinanen, "DNS/LDP Based VPLS". draft-heinanen-dns-ldp-
vpls-00.txt, January 2002.
[CE-AUTOCONFIG] CY Lee, "CE Auto-Configuration", (draft-lee-ppvpn-
ce-auto-config-01.txt), work in progress, July 2002
[RADIUS] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial in User Service (RADIUS)", RFC 2865, June 2000.
6. Security Considerations
It is recommended to use IPsec in conjunction with L2TPv3 to secure
communication. Please see the Appendix for further information on
Security Considerations.
7. IANA Consideration
A new PW Type for CE-based VPL is required.
8. Acknowledgment
The authors would like to thank Jeremy deClercq and Jeanne DeJaegher
for their helpful comments on the initial version of this draft. The
draft benefited from discussions with Sasha Cirkovic, Jeff Smith,
Raymond Chang, Roy Nighswander, Neil Harrison, Alexis Berthillier,
Dean Welsh and Arnold Jansen.
9. Author's Address
Cheng-Yin Lee Alcatel 600 March Rd, Ottawa Ontario, Canada K2K 2E6
e-mail: Cheng-Yin.Lee@alcatel.com
Mitsuru Higashiyama Anritsu Corporation 1800 Onna, Atsugi-shi,
Kanagawa-prf., 243-8555 Japan e-mail:
Mitsuru.Higashiyama@yy.anritsu.co.jp
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
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.
Appendix
This Appendix describes how CE-based VPL (CEVPL) satisfies [L2VPN-
REQ]. The sections are numbered as in [L2VPN-REQ].
3.2 Taxonomy of Layer 2 PPVPN Types
The requirements distinguish two major L2VPNs models, a Virtual
Private Wire Service (VPWS), and a Virtual Private LAN Service
(VPLS).
The following diagram shows a L2VPN reference model.
+-----+ +-----+
+ CE1 +--+ +---| CE2 |
+-----+ | ........................ | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |--- Service ---| PE |--+
+----+ Provider +----+
/ . Backbone . \ - /\-_
+-----+ / . | . \ / \ / \ +-----+
+ CE4 +--+ . | . +-- Access \----| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B .........| PE |......... \ / L2VPN B
+----+ ^ -------
| |
| |
+-----+ |
| CE3 | +-- Logical switching instance
+-----+
L2VPN A
Figure 1 L2VPN Reference Model
4. Service Requirements Common to CUstomers and Service Providers
4.1 Scope of emulation
CEVPL interoperates with the existing protocols and standards
(802.1d/q, 802.3 control frames handling) of the Ethernet network the
customer is managing.
Some possibly salient differences between CEVPL and a real LAN are:
- the reliability MAY likely be less -- a message sent to a remote
node may not be received by the remote bridge because the remote
bridge may be temporarily not reachable -- a message broadcast over
a CEVPL using a spanning tree may not be seen by one of the remote CE
if the PSN is partitioned -- the probability that a message broadcast
over a CEVPL using a spanning tree is not seen by one of the remote
CE is lower than if reverse split horizon forwarding is used (which
can occur whenever a PSN tunnel is broken)
- if sequencing is not turned on, BPDUs on a PW may get out of oerder
- Ethernet frames can get duplicated or received out of sequence if
the sequencing option is not turned on. - 802.3 Pause frames will be
handled by a CE/CLE as defined in 802.3
CEVPL interoperates with customer equipment as specified in IEEE
specifications.
4.2 Traffic Types
CE VPL support unicast, multicast, and broadcast traffic. It is
desirable that the CE/CLE support efficient replication of broadcast
and multicast traffic.
4.3 Topology
A CEVPL allows multipoint to multipoint connectivity over point to
point tunnels setup for different types topologies e.g. :
o Point-to-point
o Point-to-multipoint, a.k.a. hub and spoke
o Any-to-any, a.k.a. full mesh
o Mixed, a.k.a. partial mesh
o Hierarchical
Not all traffic characteristics (such as bandwidth, QoS, delay, etc.)
would necessarily be the same between any two end points of a CEVPL.
The SLS requirements of a service would have a bearing on the type of
topology that can be used.
A CEVPL is capable of crossing multiple administrative boundaries.
CEVPL services are independent of access network technology.
4.4 Isolated Exchange of Data and Forwarding Information
CEVPL has means to allow CE to authenticate each other during tunnel
setup. If a CE needs to obtain configuration information from e.g. a
server, a CE configuration solution which allows authentication and
authorization SHOULD be used.
CEVPL implemented according to specification SHOULD not introduce
undesired forwarding information that could corrupt the L2VPN
forwarding information base.
CEVPL constrains, or isolates, the distribution of addressed data to
only those VPLS sites determined either by MAC learning.
The internal structure of a CEVPL is not be advertised nor
discoverable from outside that L2VPN.
4.5 Security
A number of security concerns arise in the setup and operation of a
L2VPN, ranging from mis-configurations to attacks that may be
launched on a L2VPN. This section lists some potential security
hazards. Methods to protect against the following situations are
listed in >>.
- Protocol attacks
o Excessive protocol adjacency setup/teardown
>> This may not be applicable to CEVPL.
o Excessive protocol signaling/withdrawal
>> Setting a limit on the tunnel setup frequency
needs to be specified in CEVPL. A provider may also ingress rate-
limit tunnel setup messages.
- Resource Utilization
o Forwarding plane replication (VPLS)
>> emulated LAN topology/network engineering to limit
the
number of CEs that a CE shall be connected to
o Looping (VPLS primarily)
>> STP
o MAC learning table size limit (VPLS)
>> Same requirement as all bridges in the LAN, the
MAC table is not shared by other customers
- Unauthorized access
o Unauthorized member of VPN
>> A remote CE is authenticated during tunnel setup
o Incorrect customer interface
>> A remote CE is authenticated during tunnel setup
o Incorrect service delimiting VLAN tag
>> N/A
o Unauthorized access to PE
>> A PE may be protected from authorized in the same as
an existing NE in a provider's network
- Tampering with signaling
o Incorrect FEC signaling
>> N/A
o Incorrect PW ID assignment
>> See [L2TPv3]
o Incorrect signaled VPN parameters (e.g., QoS, MTU, etc.)
>> See [L2TPv3]
- Tampering with data forwarding
o Incorrect MAC learning entry
>> A CE can only be updated by authorized entites
o Incorrect Session ID/PW ID
>> See [L2TPv3]
o Incorrect customer facing encapsulation
>> See [L2TPv3]
o Incorrect pseudo-wire encapsulation
>> See [L2TP3]
o Hijacking pseudowires using the wrong tunnel
>> See [L2TPv3]
o Incorrect tunnel encapsulation
>> See [L2TPv3]
4.5.1 User data security
CEVPL provides traffic separation between different VPL.
in 0 4.5.2 Access control
A CEVPL MAY have the ability to activate the appropriate filtering
capabilities upon request of a customer, if CE configuration or
management such as LMI is used.
4.6 Addressing
CEVPL supports overlapping addresses of different L2VPNs. For
instance, customers are not prevented from using the same MAC
addresses and/or the same VLAN Ids when used with different L2VPNs. A
CEVPL is oblivious to customer VLANs, I.e. customers can have
overlapping VLAN Ids.
4.7 Quality of Service
A CEVPL QoS SHOULD be independent of the access network technology.
4.7.1 QoS Standards
A CEVPL SHALL be able to support QoS in one or more of the following
already standardized modes:
- Best Effort (support mandatory for all PPVPN types)
- Aggregate CE Interface Level QoS (i.e., hose level)
- Site-to-site, or pipe level QoS
This MAY require that the CE and/or PE perform shaping and/or
policing.
Mappings or translations of Layer 2 QoS parameters into
PacketSwitched work QoS (e.g., DSCPs or MPLS EXP field) as well as
QoS mapping based on VC (e.g., FR/ATM or VLAN) MAY be performed in
order to provide QoS transparency. The actual mechanisms for these
mappings or translations are outside the scope of this document. In
addition, the Diffserv support of underlying tunneling technologies
(e.g., [RFC3270] or [RFC3308]) and the Intserv model ([RFC2205]) MAY
be used. As such, the L2VPN SLS requirements should be supported by
appropriate core mechanisms.
4.7.2 Service Models
A service provider MUST be able to offer QoS service to a customer
for at least the following generic service types: managed access VPN
service or an edge-to-edge QoS service. The details of the service
models can be found in [PPVPN-REQTS] and in [L3REQTS]. In CEVPL
service, 802.1p fields shall be mapped to DSCP.
4.8 Service Level Specifications
For a CEVPL, the monitoring and reporting of the VPL is described in
"VPL Monitoring". Further work is required to fulfil the capabilities
for Service Level Specification (SLS) monitoring and reporting stated
in [PPVPN-REQTS].
4.9 Protection and Restoration
To assure high availability, the underlying PSN SHOULD be able to
provide fast failover to alternative paths or rerouting of traffic.
The intention is to keep the restoration time small. The restoration
time MUST be less than the time it takes the CE devices, or customer
Layer 2 control protocols as well as Layer 3 routing protocols, to
detect a failure in the L2VPN.
4.10 CE-to-CE and CE-to-PE link requirements
The CE-to-PE links MAY either be direct physical links, e.g.
100BaseTX, T1/E1 TDM or logical links, e.g. ATM PVC, or RFC2427-
encapsulated link, or transport networks carrying Ethernet, or a
Layer 2 tunnel that go through a layer 3 network (e.g., L2TP
sessions), over which Ethernet traffic is carried.
Ethernet frames MAY be tunneled through a layer 3 backbone from
CE/CLE to CE/CLE, using the following tunneling technologies (e.g.,
IP-in- IP, GRE, MPLS, L2TP, etc.).
4.11 Management
Standard interfaces to manage Ethernet services is provided (e.g.,
standard SNMP MIBs). These interfaces shall provide access to
configuration, verification and runtime monitoring protocols.
The Service management MAY include the TMN 'FCAPS' functionalities,
as follows: Fault, Configuration, Accounting, Provisioning, and
Security, as detailed in [L3REQTS]. Accounting is out of scope of
this draft.
4.12 Interoperability
If CEVPL is standardized, it should promote interoperability among
CEs/CLEs from different vendors. CEVPL is defined to interoperate
with existing 802.1d/q devices at customers' LAN sites.
A CEVPL is agnostic to different access technologies. For instance,
customer access connections to a CEVPL service MAY be different at
different CE/CLE devices (e.g. Ethernet, DSL, ATM)
4.13 Inter-working
CEVPL may inter-work with PE-based VPLS or Provider Bridges if the
customer facing port of a CLE is connected to the customer facing
side of a PE. The scalability of this inter-working is dependent on
the scalability of PE-based VPLS or Provider Bridges.
CEVPL may inter-work with Hybrid VPLS [HYBRID-VPLS] if the tunnel
from a CE/CLE is terminated at a PE. The PE switch the decapsulated
traffic onto an Attachment Circuit. The CE/CLE at the end of the
Attachment Circuit bridges the traffic accordingly. Inter-working in
this case scales as well as Hybrid VPLS. This allows CEs/CLEs with IP
access to peer with CEs/CLEs with Ethernet, FR or ATM access. The SLA
for CEs/CLEs with different types of access technologies may vary and
dependent on the customer's network requirements.
In both inter-working scenarios, customer traffic isolation is
maintained. CEVPL may encrypt transmission of traffic over an IP
network from CE/CLE to CE/CLE but when interworking with other VPLS
solutions which terminates tunnels at PEs, the traffic is encrypted
from a CE/CLE to a PE.
CEVPL is able to work independently of other VPLS solutions in a
network (Ships in the Night). Sites belonging to different VPLS
networks shall continue to have emulated LAN service while CEVPL
inter-working is being introduced.
5 Customer Requirements
This section captures requirements from a customer perspective.
5.1 Service Provider Independence
Customers MAY require L2VPN service that spans multiple
administrative domains or service provider networks. Sites of a CEVPL
is able to span multiple AS and SP networks, but still be able to act
and to appear as a single, homogenous emulated LAN from a customer
point of view.
A customer might also start with a VPL provided in a single AS with a
certain SLS but then ask for an expansion of the service spanning
multiple ASs/SPs. In this case, as well as for all kinds of multi-
AS/SP L2VPNs, a L2VPN service SHOULD be able to deliver the same SLS
to all sites in a VPN regardless of the AS/SP to which it homes, if
all AS and SP gives similar and consistent treatment of 802.1q p
bits, DSCP and COS, but this is not generally practiced.
5.2 Layer 3 Support
A CEVPL is agnostic to customer layer 3 traffic (e.g., IPv4/v6, IPX,
Appletalk) encapsulated within Layer 2 frames.
5.3 Quality of Service and Traffic Parameters
QoS is expected to be an important aspect of a L2VPN service for some
customers.
A customer requires that a CEVPL service provide the QoS applicable
to his or her application, which can range from voice and interactive
video to multimedia applications. Hence, best-effort as well as delay
and loss sensitive traffic MUST be supported over a L2VPN service.
The support of this requirement is dependent on the PSN QoS support.
A customer application SHOULD experience consistent QoS independent
of the access network technology used at different sites connected to
the same L2VPN. Again, this is dependent on the SP's network being
able to support QoS consistently independent of access network
technology.
5.4 Service Level Specification
Most customers simply want their applications to perform well. A SLS
is a vehicle for a customer to measuere the quality of the service
that SP(s) provide. Therefore, when purchasing a service, a customer
requires access to the measures from the SP(s) that support the SLS.
Standard interfaces to monitor usage of CEVPL services SHALL be
provided (e.g., standard SNMP MIBs).
5.5 Security
5.5.1 Isolation
A CEVPL service provides traffic as well as forwarding information
base isolation for customers similar to that obtained in private
lines, FR, or ATM services.
A CEVPL service MAY use customer VLAN identifications as service
delimiters. In that case, traffic separation is provided by 802.1q.
5.5.2 Access control
A CEVPL MAY have the mechanisms to activate the appropriate filtering
capabilities upon request of a customer. For instance, MAC and/or
VLAN filtering MAY be considered between CE/CLE and PE for a CEVPL.
5.5.3 Value added security services
CEVPL allows value added security services such as encryption and/or
authentication of customer packets, but does not restrict
implementation of customer based security add-ons.
5.6 Network Access
Every packet exchanged between the customer and the SP over the
access connection MUST appear as it would on a private network
providing an equivalent service to that offered by the L2VPN.
5.6.1 Physical/Link Layer Technology
CEVPL is agnostic to a broad range of physical and link layer access
technologies, such as PSTN, ISDN, xDSL, cable modem, leased line,
Ethernet, Ethernet VLAN, ATM, Frame Relay, Wireless local loop,
mobile radio access, etc, as long as the CEs/CLEs have reachability
in the PSN. The capacity and QoS achievable MAY be dependent on the
specific access technology in use.
5.6.2 Access Connectivity
Various types of physical connectivity scenarios MUST be supported,
such as multi-homed sites, backdoor links between customer sites,
devices homed to two or more SP networks. CEVPL supports multi- link
access for CE devices, the types of physical or link-layer
connectivity arrangements shown in Figure 2 (in addition to the case
shown in Figure 1). For example, in case (b) a CE/CLE MAY connect to
two different SPs via diverse access networks. Resiliency MAY be
further enhanced as shown in case (d), where CEs/CLEs, connected via
a "back door" connection, connect to different SPs. Furthermore,
arbitrary combinations of the above methods, with a few examples
shown in cases (e) and (f) is supported.
Note: In CEVPL, CEs/CLEs process BPDUs from other CEs/CLEs. A
customer BPDU is tunneled from CE/CLE to CE/CLE and is transparent to
the attached PE.
+---------------- +---------------
| |
+------+ +------+
+---------| PE | +---------| PE |
| |device| | |device| SP network
| +------+ | +------+
+------+ | +------+ |
| CE | | | CE | +---------------
|device| | SP network |device| +---------------
+------+ | +------+ |
| +------+ | +------+
| | PE | | | PE |
+---------|device| +---------|device| SP network
+------+ +------+
| |
+---------------- +---------------
(a) (b)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
| Backdoor | | Backdoor +---------------
| link | SP network | link +---------------
| | | |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(c) (d)
+---------------- +---------------
| |
+------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network
+------+ +------+ +------+ +------+
| | | |
|Back | |Back +---------------
|door | SP network |door +---------------
|link | |link |
+------+ +------+ +------+ +------+
| CE | | PE | | CE | | PE |
|device|-----|device| |device|-----|device| SP network
+------+ +------+ +------+ +------+
| |
+---------------- +---------------
(e) (f)
Figure 2 Representative types of access arrangements.
5.7 Customer traffic
5.7.1 Unicast, Unknown Unicast, Multicast, and Broadcast forwarding
CEVPL delivers every packet at least to its intended destination(s)
within the scope of the VPL subject to the ingress policing and
security policies.
5.7.2 Packet Re-ordering
The queuing and forwarding policies SHOULD preserve packet order for
packets with the same QoS parameters. Sequencing in [ETH-LT2Pv3]
should be turned on to preserve frame order.
5.7.3 Minimum MTU
CEVPL can support the theoretical MTU of the offered service.
The committed minimum MTU size can be the same for a given VPL
instance. Different CEVPL services MAY have different committed MTU
sizes. If the customer VLANs are used as service delimiters, all
VLANs within a given VPL would inherit the same MTU size.
CEVPL MAY fragment packets and it is transparent to the customer.
5.7.4 End-point VLAN tag translation
A CEVPL service does not translate customers' VLAN tags, when the
customer VLANs are used as service delimiter. It SHOULD be noted
that VLAN tag translation (may be supported in other PE-based VPLS)
affects the support for multiple spanning trees (i.e., 802.1s) but
this is not an issue with CEVPL.
5.7.5 Transparency
A CEVPL service emulates a LAN and appear to customer devices as a
bridged LAN. CEVPL does not require any special packet processing by
the end users before sending packets to the provider's network.
CEVPL does not require VLAN-ids to be assigned by the SP, hence the
issue with VLANs being not transparent if VLAN-ids are assigned by
the SP, is not applicable here.
5.8 Support for Layer 2 Control Protocols
CLEs process L2 control protocols as defined in IEEE specifications.
CEVPL ensure that loops be prevented. This can be accomplished
through Control protocols such as Spanning Tree (STP). A CEVPL does
not require indications from customer Layer 2 control protocols, e.g.
STP BPDU snooping, to improve the operation of a VPL, since CLEs
participate in STP.
5.9 CE Provisioning
A CEVPL requires configuration of the tunnel endpoint information on
CEs/CLES. Provisioning on CEs/CLEs can be minimized or automated
using the methods described in "Discovery" of this draft or an LMI
method.
6 Service Provider Network Requirements
This section describes the requirements from a service provider
perspective. How CEVPL behaves wrt these requirements are described
in text preceeded by >>.
6.1 Scalability
This section contains projections regarding L2VPN sizing projections
and scalability requirements and metrics specific to CEVPL.
6.1.1 Service Provider Capacity Sizing Projections
This section captures projections for scaling requirements over the
next several years in terms of number of L2VPNs, number of interfaces
per L2VPN, the size of forwarding information base per L2VPN, and the
rate of L2VPN configuration changes. The examples are provided in
[PPVPN-REQTS].
The numbers provided in this section are examples and MUST be treated
as such. A L2VPN solution MAY scale much more than the examples
provided here. Each requirement in this section MUST be considered
independently.
A L2VPN solution SHOULD be scalable to support a very large number of
L2VPNs per Service Provider network. The estimate is that a large
service provider will require support O(10^5) VPWSs and O(10^4) VPLSs
within the next four years.
>> The forwarding states for L2VPN forwarding in CEVPL are only
created at CLEs. Hence the number of VPL that can be supported in a
provider's network is independent of the number VPWSs or the number
of VPLSs. The limitation to the number of VPLSs shall be the amount
of traffic that can be handled by the provider's network.
A L2VPN solution SHOULD be scalable to support of a wide range of
number of site interfaces per VPLS, depending on the size and/or
structure of the customer organization. The number of site interfaces
SHOULD range from a few site interfaces to O(10^2) site interfaces
per VPLS.
>> A CEVPL is capable of supporting number of site interfaces ranging
from a few site interfaces to lower end O(10^2) site interfaces per
VPLS. It is recommended that a LAN (including emulated LAN) be
subnetted when then number of nodes (including CLEs) becomes large.
It is not clear how well bridging works in the case of higher end
O(10^2) site interfaces per VPLS. Note: In CEVPL, it is not
necessary to have a full-meshed of tunnels from CLE to CLE - traffic
is forwarded on a Spanning Tree. For e.g. a 5 site interfaces VPLS
may require 4 tunnels in a hub and spoke configuration with a few
additional tunnels for failover.
A L2VPN solution SHOULD be scalable to support a wide range of number
of customer addresses (e.g., MAC) per VPLS. The number of customer
addresses per VPLS MAY range from just a few (i.e., the number of
sites when the CE devices are routers or when the service is IPLS) to
a very large number such as 1,000 (i.e., when CE devices are
switches). The number of customer addresses would be on the order of
addresses supported in a typical native Layer 2 backbone.
>> Since MAC addresses are only stored in CLEs, CEVPLS can support a
wide range of number of customer addresses per VPLS from just a few
to a very large number such as 1000 or the number of MAC addresses in
a typical LAN can be easily supported.
A L2VPN solution SHOULD support high values of the frequency of
configuration setup and change, e.g., for real-time provisioning of
an on-demand videoconferencing or addition/deletion of sites.
>> With an auto-configuration mechanism, CEVPL can support high
values of frequency of configuration setup and change.
Approaches SHOULD articulate scaling and performance limits for more
complex deployment scenarios, such as inter-AS(S) L2VPNs and
carriers' carrier. Approaches SHOULD also describe other dimensions
of interest, such as capacity requirements or limits, number of
inter-working instances supported as well as any scalability
implications on management systems.
>> Since bridging and tunneling are performed on CLEs, CEVPL is
transparent to the provider's PEs and Ps and hence can be deployed
and scale well across different domains. No inter-working is
required across different domains.
The number of users per VPLS is the combination of servers and hosts
connected to the VPLS. It needs to scale from a handful to high
numbers. A VPLS MUST scale from 2 users to a few hundred.
>> CEVPL scales from 2 users to a few hundred.
The number of users per VPLS interface follows the same logic as for
users per VPLS. Further, it MUST be possible to have single user
sites connected to the same VPLS as very large sites are connected
to. VPLSs MUST scale from 1 user to a few hundred per site.
>> CEVPL scales from 1 user to a few hundred per site.
The number of sites per VPLS is clearly limited by the number of
users for a VPLS. The largest number of sites in a VPLS would be
equal to the largest number of users, distributed one per site.
The number of L2VPNs SHOULD scale linearly with the size of the
access network and with the number of PEs.
>> CEVPL is transparent to PEs and hence is independent of the size
of the access network or the number of PEs, I.e, CEVPL scales wrt to
these parameters.
6.1.2 Solution-Specific Metrics
Each L2VPN solution SHALL document its scalability characteristics in
quantitative terms.
6.2 Identifiers
A SP domain MUST be uniquely identified at least within the set of
all interconnected SP networks when supporting a L2VPN that spans
multiple SPs. Ideally, this identifier SHOULD be globally unique
(e.g., an AS number).
An identifier for each L2VPN SHOULD be unique, at least within each
SP's network, as it MAY be used in auto-discovery, management (e.g,
alarm and service correlation, troubleshooting, performance
statistics collection), and signaling. Ideally, the L2VPN identifier
SHOULD be globally unique to support the case, where a L2VPN spans
multiple SPs (e.g., [RFC2685]). Globally unique identifiers
facilitate the support of inter-AS/SP L2VPNs.
>> CEVPL work transparently across different domains, hence a
globally unique domain identifier for CEVPL that spans different
domains is not required.
6.3 Discovering L2VPN Related Information
Configuration of PE devices (i.e., U-PE and N-PE) is a significant
task for a service provider. Solutions SHOULD provide methods that
dynamically allow L2VPN information to be discovered by the PEs to
minimize the configuration steps.
>> CE Auto-configuration referred to in CEVPL can be used to minimize
configuration steps.
Each device in a L2VPN SHOULD be able to determine which other
devices belong to the same L2VPN. Such a membership discovery scheme
MUST prevent unauthorized access and allows authentication of the
source.
>> CE Auto-configuration referred to in CEVPL has means to prevent
unauthorized access and allows authentication of devices.
Distribution of L2VPN information SHOULD be limited to those devices
involved in that L2VPN. A L2VPN solution SHOULD employ discovery
mechanisms to minimize the amount of operational information
maintained by the SPs. For example, if a SP adds or removes a
customer port on a given PE, the remaining PEs SHOULD determine the
necessary actions to take without the SP having to explicitly
reconfigure those PEs.
>> Distribution of configuration information to CE is limited to CEs
of a VPLS only. CE Auto-configuration describes ways to minimize the
amount of operational information maintained and configured by SPs,
for e.g. if a CE is removed, other CEs should be updated accordingly.
A L2VPN solution SHOULD support the means for attached CEs to
authenticate each other and verify that the service provider L2VPN is
correctly configured.
>> CEVPL allows CEs to authenticate each other.
The mechanism SHOULD respond to L2VPN membership changes in a timely
manner. A "timely manner" is no longer than the provisioning
timeframe, typically on the order of minutes, and MAY be as short as
the timeframe required for "rerouting," typically on the order of
seconds.
>> Using a CE Auto-Configuration to dynamically update CEs of L2VPN
membership change should allow CEVPL to respond in a "timely manner".
Dynamically creating, changing, and managing multiple L2VPN
assignments to sites and/or customers is another aspect of membership
that MUST be addressed in a L2VPN solution.
>> CE Auto-Configuration can be used to dynamically update CEs of
different L2VPN membership changes. In general, this could be
addressed within a provisioning framework, independent of the CEVPL
proposal.
6.4 SLS Support
Typically, a SP offering a L2VPN service commits to specific Service
Level Specifications (SLS) as part of a contract with the customer.
Such a Service Level Agreement (SLA) drives the specific SP
requirements for measuring Specific Service Level Specifications
(SLS) for quality, availability, response time, and configuration
intervals.
6.5 Quality of Service (QoS)
A significant aspect of a PPVPN is support for QoS. A SP has control
over the provisioning of resources and configuration of parameters in
at least the PE and P devices, and in some cases, the CE devices as
well. Therefore, the SP is to provide either managed QoS access
service, or edge-to-edge QoS service, as defined in [L3REQTS].
6.6 Isolation of Traffic and Forwarding Information
From a high level SP perspective, a L2VPN MUST isolate the exchange
of traffic and forwarding information to only those sites that are
authenticated and authorized members of a L2VPN.
>> In CEVPL, the exchange of traffic and forwarding information only
occurs among those sites that are authenticated and authorized
members of the VPLS.
A L2VPN solution SHOULD provide a means for meeting PPVPN QoS SLS
requirements that isolates L2VPN traffic from the affects of traffic
offered by non-VPN customers. Also, L2VPN solutions SHOULD provide a
means so that traffic congestion produced by sites as part of one
L2VPN does not affect another L2VPN.
>> A provider can use existing methods to treat L2VPN traffic with
the appropriate priority or DSCP or CoS to differentiate them from
non-VPN traffic. Rate-limiting at ingress to provider's network can
also be used to prevent traffic from a L2VPN from exceeding its share
of bandwidth use.
6.7 Security
The security requirements are stated in Section 4.5. The requirements
provided in [PPVPN-REQTS] and in [L3REQTS] SHOULD be met as
appropriate.
In addition, a SP network MUST be immune to malformed or maliciously
constructed customer traffic. This includes but not limited to
duplicate or invalid Layer 2 addresses, customer side loops,
short/long packets, spoofed management packets, spoofed VLAN tags,
high volume traffic.
>> In CEVPL, internal customer addresses or customer BPDUs are
transparent to an SP network since trafffic is tunneled from CLE to
CLE, and one customer/s CLE does not communicate with another
customer's CLE. Hence malformed or maliciously consructed customer
traffic shall not affect an SP network.
The SP network devices MUST NOT be accessible from any L2VPN, unless
specifically authorized. The devices in the PPVPN network SHOULD
provide some means of reporting intrusion attempts to the SP, if the
intrusion is detected.
>> There is no reason to grant access of SP network devices to L2VPN.
Hence a provider may perform ingress filtering of traffic from L2VPN
towards the SP network addresses (subnet). A CLE only need to be able
to reach other CLEs of the same L2VPN.
6.8 Inter-AS (SP) L2VPNs
All applicable SP requirements, such as traffic and forwarding
information isolation, SLS's, management, security, provisioning,
etc. MUST be preserved across adjacent ASes. The solution MUST
describe the inter-SP network interface, encapsulation method(s),
routing protocol(s), and all applicable parameters [VPN-IW].
A L2VPN solution MUST provide the specifics of offering L2VPN
services spanning multiple ASs and/or SPs.
>> CEVPL works the same within a domain as it is across different
domains. It is not clear if there is any motivation for a CEVPL SP
to share management of a CEVPL with another CEVPL SP, since the
tunnels from a CE to another CE can be setup across different domains
without another SP cooperation or intervention, as long as the
different CEs are reachable.
A L2VPN solution MUST support proper dissemination of operational
parameters to all elements of a L2VPN service in the presence of
multiple ASs and/or SPs. A L2VPN solution MUST employ mechanisms for
sharing operational parameters between different ASs.
>> A CE Auto-Configuration mechanism which allows CEs to query a
server accessible from different ASs can be used for this purpose.
A L2VPN solution SHOULD support policies for proper selection of
operational parameters coming from different ASs. Similarly, a L2VPN
solution SHOULD support policies for selecting information to be
disseminated to different ASs.
6.8.1 Management
The general requirements for managing a single AS apply to a
concatenation of AS's. A minimum subset of such capabilities is the
following:
- Diagnostic tools
- Secured access to one AS management system by another
- Configuration request and status query tools
- Fault notification and trouble tracking tools
6.8.2 Bandwidth and QoS Brokering
When a L2VPN spans multiple AS's, there is a need for a brokering
mechanism that requests certain SLS parameters, such as bandwidth and
QoS, from the other domains and/or networks involved in transferring
traffic to various sites. The essential requirement is that a
solution MUST be able to determine whether a set of AS's can
establish and guarantee uniform QoS in support of a PPVPN.
6.9 L2VPN Wholesale
The architecture MUST support the possibility of one SP offering
L2VPN service to another SP. One example is when one SP sells L2VPN
service at wholesale to another SP, who then resells that L2VPN
service to his or her customers.
>> CEVPL allows one SP to sell a CEVPL at wholesale to another SP,
who then resells the emulated LAN to the 2nd SP's customers. In this
case, the "CE" would appear as a 802.1d/q bridge in the second SP's
network, providing one emulated LAN to all the 2nd SP's customers.
If the 2nd SP wishes to provide L2VPN to its customers', it is better
for the 2nd SP to provide the L2VPN service over a PSN than over the
wholesale L2VPN. The latter incurs additional encapsulation layers
and may be susceptible to forwarding loops.
6.10 Tunneling Requirements
Connectivity between CE sites or PE devices in the backbone SHOULD be
able to use a range of tunneling technologies, such as L2TP, GRE,
IP-in-IP, MPLS, etc.
>> Although CEVPL is specified for L2TPv3, it does not preclude the
use of other tunneling technologies.
Every PE MUST support a tunnel setup protocol, if tunneling is used.
A PE MAY support static configuration. If employed, a tunnel
establishment protocol SHOULD be capable of conveying information,
such as the following:
- Relevant identifiers
- QoS/SLS parameters
- Restoration parameters
- Multiplexing identifiers
- Security parameters
>> A CLE support a tunnel setup protocol. A CLE allows static
configuration of the tunnel. The multiplexing identifier is conveyed,
other information (TLV) may be added to L2TPv3 if necessary.
There MUST be a means to monitor the following aspects of tunnels:
- Statistics, such as amount of time spent in the up and down
state
- Count of transitions between the up and down state
- Events, such as transitions between the up and down states
>> Using the functions in "VPL Monitoring" the above statistics to be
collected.
The tunneling technology used by the VPN Service Provider and its
associated mechanisms for tunnel establishment, multiplexing, and
maintenance MUST meet the requirements on scaling, isolation,
security, QoS, manageability, etc.
Regardless of the tunneling choice, the existence of the tunnels and
their operations MUST be transparent to the customers. >> The
tunnels and their operations are transparent to customers.
6.11 Support for Access Technologies
>> A CE/CLE is connected to a PE via an access link. The access link
MAY span networks of other providers or public networks. Some
popular choices of access technologies include Ethernet, ATM (DSL),
Frame Relay, MPLS-based virtual circuits etc. The access link,
whether direct or virtual, MUST maintain all committed
characteristics of the customer traffic, such as QoS, priorities etc.
This provider may use existing methods to enforce this. The access
technology used is transparent to CEVPL.
>> The CLE connection to the customer network (or CE) is typically
Ethernet and is bi-directional in nature. The CLE uses Ethernet
frames as the Service Protocol Data Unit (SPDU).
6.12 Backbone Networks
Ideally, the backbone interconnecting SP PE and P devices SHOULD be
independent of physical and link layer technology. Nevertheless, the
characteristics of backbone technology MUST be taken into account
when specifying the QoS aspects of SLSs for VPN service offerings.
6.13 Network Resource Partitioning and Sharing Between L2VPNs
In case network resources such as memory space, FIB table, bandwidth
and CPU processing are shared between L2VPNs, the solution SHOULD
guarantee availability of resources necessary to prevent any specific
L2VPN instance from taking up available network resources and causing
others to fail. The solution SHOULD be able to limit the resources
consumed by a L2VPN instance. The solution SHOULD guarantee
availability of resources necessary to fulfill the obligation of
committed SLSs.
>> CEVPL L2VPN operation is transparent to the provider's network.
Hence L2VPN related resources and processing e.g. MAC table, Layer 2
protocol processing has no effect on the provider's network. A CEVPL
may share bandwidth in the provider's network with another CEVPL. A
provider may use rate-limiting at ingress to limit traffic from a
L2VPN and existing methods to manage bandwidth sharing. The may be
specified in a separate L2VPN QoS framework.
6.14 Interoperability
Service providers are interested in interoperability in at least the
following scenarios:
- To facilitate use of CLE and customer devices (CE)
>> The CLE and CE shall interoperate as specified in IEEE 802.1d
- To implement L2VPN services across two or more interconnected
SP
networks
>> As long as there is reachability from a CLE to another CLE,
traffic in a CEVPL can be tunneled in one domain or across different
domains. Hence there is no need to devise inter-working means when
CEVPL span different SP networks.
- To achieve inter-working or interconnection between customer
sites using different L2VPN solutions or different
implementations
of the same approach
>> CEVPL may inter-work with other VPLS solutions if the
customer facing side of a CLE in a CEVPL is connected to the customer
facing side of a PE of other VPLS solutions.
6.15 Testing
The L2VPN solution SHOULD provide the ability to test and verify
operational and maintenance activities on a per L2VPN service basis,
and in case of VPLS, on a per VLAN basis if customer VLANs are used
as service delimiters.
The L2VPN solution SHOULD provide mechanisms for connectivity
verification, and for detecting/locating faults.
Examples of testing mechanisms are as follows:
o Checking connectivity between "service-aware" network nodes
o Verifying data plane and control plane integrity
o Verifying service membership
The provided mechanisms MUST satisfy the following: the connectivity
checking for a given customer MUST enable the end-to- end testing of
the data path used by that customer's data packets and the test
packets MUST not propagate beyond the boundary of the SP network.
>> There are on-going work to address Ethernet "ping" and
"traceroute" functions. This may be adapted for CEVPL in future.
7 Service Provider Management Requirements
A service provider desires to have a means to view the topology,
operational state, and other parameters associated with each
customer's L2VPN. Furthermore, the service provider requires a means
to view the underlying logical and physical topology, operational
state, provisioning status, and other parameters associated with the
equipment providing the L2VPN service(s) to its customers.
Therefore, the devices SHOULD provide standards-based interfaces
(e.g., L2VPN MIBs) wherever feasible.
>> CEVPL shall provide standards-based interfaces for the above
purpose.
The details of service provider management requirements for a Network
Management System (NMS) in the traditional fault, configuration,
accounting, performance, and security (FCAPS) management categories
can be found in [Y.1311.1].
8 Engineering Requirements
These requirements are driven by implementation characteristics that
make service and SP requirements achievable.
8.1 Control Plane Requirements
A L2VPN service SHOULD be provisioned with minimum number of steps.
Therefore, the control protocols SHOULD provide methods for signaling
between PEs. The signaling SHOULD inform of membership, tunneling
information, and other relevant parameters. >> Using a suitable CE
Auto-Configuration, the provisioning of CEVPL can be minimized.
The infrastructure MAY employ manual configuration methods to provide
this type of information. >> CEVPL does not preclude the use of
manual configuration methods.
The infrastructure SHOULD use policies to scope the membership and
reachability advertisements for a particular L2VPN service. A
mechanism for isolating the distribution of reachability information
to only those sites associated with a L2VPN MUST be provided. >> CE
Auto-Configuration mechanisms only distribute reachability
information to only those sites associated with a CEVPL.
The control plane traffic increases with the growth of L2VPN
membership. Similarly, the control plane traffic increases with the
number of supported L2VPN services. The use of control plane
resources MAY increase as the number of hosts connected to a L2VPN
service grows.
A L2VPN solution SHOULD minimize control plane traffic and the
consumption of control plane resources. The control plane MAY offer
means for enforcing a limit on the number of customer hosts attached
to a L2VPN service.
>> In CEVPL, L2VPN control plane processing occurs only in CLE/CE,
hence L2VPN control plane resource consumption are restricted to CLEs
and customer devices (including CE) only. The number of customer
hosts that can be attached to a CEVPL is similar to the MAC table
size supported by customer devices (and CLEs).
8.2 Data Plane Requirements
8.2.1 Encapsulation
>> CEVPL utilizes the encapsulation techniques defined by PWE3
([PWE3-FR]), and does not impose any new requirements on these
techniques.
8.2.2 Responsiveness to Congestion
>> CEVPL utilize thes congestion avoidance techniques defined by PWE3
([PWE3-FR]).
8.2.3 Broadcast Domain
>> CEVPL maintains a separate Broadcast Domain for each VPLS.
In addition to VPLS Broadcast Domains, a L2VPN service MAY honor
customer VLAN Broadcast Domains, if customer VLANs are used as
service delimiters. In that case, the L2VPN solution SHOULD maintain
a separate VLAN Broadcast Domain for each customer VLAN. >> In the
case of CEVPL, customer VLANs are switched as defined by 802.1q.
8.2.4 Virtual Switching Instance
L2VPN Provider Edge devices MUST maintain a separate Virtual
Switching Instance (VSI) per each VPLS. Each VSI MUST have
capabilities to forward traffic based on customer's traffic
parameters such as MAC addresses, VLAN tags (if supported), etc. as
well as local policies.
L2VPN Provider Edge devices MUST have capabilities to classify
incoming customer traffic into the appropriate VSI.
>> In CEVPL, typically only one VSI may be required. Customer's VLAN
traffic may be switched as defined in IEEE 802.1q.
Each VSI MUST have flooding capabilities for its Broadcast Domain to
facilitate proper forwarding of Broadcast, Multicast and Unknown
Unicast customer traffic.
>> A CEVPL VSI has flooding capabilities for its Broadcast Domain to
facilitate Broadcast, Multicast and Unknown Unicast customer traffic.
8.2.5 MAC address learning
A VPLS SHOULD derive all topology and forwarding information from
packets originating at customer sites. Typically, MAC address
learning mechanisms are used for this purpose.
Dynamic population of the Forwarding Information Base (e.g. via MAC
address learning) MUST take place on a per Virtual Switching Instance
(VSI) basis, i.e. in the context of a VPLS and, if supported, in the
context of VLANs therein. >> CEVPL populates the FIB on a per VSI
basis, typically only one VSI is required.
9 Security Considerations
Security considerations occur at several levels and dimensions within
Layer 2 Provider Provisioned VPNs, as detailed within this document.
The requirements in this document separate the notion of traditional
security requirements, such as integrity, confidentiality, and
authentication as detailed in section 4.5 from that of isolating (or
separating) the exchange of forwarded packets and exchange of
forwarding information between specific sets of sites. Further
details on security requirements are given from the customer and
service provider perspectives in sections 5.5 and 6.7, respectively.
In an analogous manner, further detail on traffic and routing
isolation requirements are given from the customer and service
provider perspectives in sections 4.4 and 6.6, respectively.
Safeguards to protect network resources such as CPU, memory, and
bandwidth are required in section 6.13. >> CEVPL security
considerations are covered in the respective sections listed above.
IPSec can be also be applied after tunneling Layer-2 traffic to
provide additional security. >> CEVPL allows the use of IPSec with
L2TPv3.
11 References
11.1 Normative References
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[TERMINOLOGY] Andersson, L, Madsen, T. "PPVPN Terminology", work
in progress
11.2 Non-normative References
[GENERIC-REQTS] Nagarajan, A., et al. "Generic Requirements for
Provider Provisioned VPN", work in progress
[PPVPN-L2-FR] Andersson, L, et al. "PPVPN L2 Framework", work in
progress
[RFC3270] Le Faucheur, F., et al. "Multi-Protocol Label Switching
(MPLS) Support of Differentiated Services", RFC 3270,
May 2002.
[RFC3308] Calhoun, P., et al, "Layer 2 Tunneling Protocol (L2TP)
Differentiated Services Extension", RFC 3308, November
2002.
[RFC2205] Braden, R., et al, "Resource ReSerVation Protocol
(RSVP)", RFC 2205, September 1997.
[L3REQTS] Carugi, M., McDysan, D. et. al., "Service Requirements
for Layer 3 Provider Provisioned Virtual Private
Networks", work in progress
[Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS
architecture",Y.1311.1 ITU-T Recommendation, May 2001
(http://standards.nortelnetworks.com/ppvpn/relateditu.ht
m)
[RFC2685] Fox B., et al, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[VPN-IW] H. Kurakami et al, "Provider-Provisioned VPNs
Interworking," work in progress.
[PWE3-FR] Pate, P, et al. "Framework for Pseudo Wire Emulation
Edge-to-Edge (PWE3)", work in progress