Network Working Group Tissa Senevirathne
Internet Draft (Force10)
Document: draft-tsenevir-l2-req-01.txt
Category: Informational Waldemar Augustyn
(Nortel)
Loa Anderson
Tove Madsen
(Utfors Bredband AB)
Pascal Menazes
(TeraBeam)
July, 2001
Requirements for Network Based Layer 2 VPN
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt
1. Abstract
Requirements that needed to be considered when implementing or
providing Layer 2 NBVPN services are presented. This document does
not suggest any specific solution, instead outline the
requirements that need to be satisfied.
Senevirathne et. al,Informational û December 2001 1
draft-tsenevir-l2-req-01.txt July 2001
2. 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].
Table of Content
1. Abstract........................................................1
2. Conventions used in this document...............................2
3. Introduction....................................................3
3.1 Background.....................................................3
4. Requirements for Network Based Layer 2 VPN......................5
5. Control Plane Requirements......................................6
5.1 Customer End-point and VLAN discovery (C).....................6
5.1.1 End-point-VLAN policies......................................7
5.2 End-point VLAN tag translation.................................7
5.3 Group (Multicast) Address Registration Services (C)............7
5.4 Support for Layer 2 control protocols such as GVRP and STP (C).8
5.5 Recovery and Restoration (C,B,F)...............................9
5.6 Dynamic Service Signaling (C)..................................9
6. Forwarding Plane Requirements..................................10
6.1 Layer 2 Virtual Forwarding Instance (F)......................10
6.2 MAC address learning (F,C)....................................10
6.3 Unknown, Multicast and Broadcast forwarding (F)..............10
6.4 Multi site spanning broadcast domains (F)....................11
6.5 Scope of Unknown MAC Addresses (F,C)..........................11
6.6 Mac address transparency in the core (F,B)....................11
6.7 Minimum MTU (F)...............................................12
6.8 Packet re-ordering or duplication (F).........................12
6.9 Support for MAC Services (G,F)................................12
6.9.1 Preservation of MAC services................................12
6.9.2 Quality of service maintenance..............................13
7. General/Architecture Requirements..............................15
7.1 Layer 2 Domain representation and VLAN allocation (G).........15
7.2 Customer end point inter connection (G,B).....................16
7.3 Class of Service Model (G)....................................16
7.4 L3, and higher, service access point (G)......................16
8. Management Plane Requirements..................................16
8.1 Graceful reconfiguration (M)..................................17
9. Security Plane Requirements....................................17
9.1 Immunity from malformed customer traffic (S)..................17
10. Back-End Tunneling Requirements (B)...........................17
Senevirathne et.al, Informational û December 2001 2
draft-tsenevir-l2-req-01.txt July 2001
11. Access Requirements:..........................................18
11.1 Security Requirements for Access Plane.......................19
12. References....................................................19
13. Acknowledgments...............................................19
14. Author's Addresses............................................19
Appendix A: Acronyms and Abbreviations............................20
Full Copyright Statement..........................................22
3. Introduction
Traditionally, the typical connectivity between a service provider
and a customer is a WAN link with some type of a point-to-point
protocol. This arrangement was borne out of the necessity to
traverse TDM circuits originally designed for voice traffic. The
introduction of WAN links to network architecture significantly
increased the complexity of the network topologies and required
high skilled personnel to manage and maintain the network.
The L2 protocols running over WAN networked served the sole
purpose of bringing customer traffic to the network core. These
protocols did not find any other use in a typical customer network
and only burdened the customer with the necessity to acquire
knowledge skills and maintenance ability.
With the explosive growth of the Internet, the metro and wide area
networks change and now offer data oriented connectivity. The
lower cost of fiber and the popularity of Optical Ethernet brings
the opportunity to eliminate unnecessary complexity of WAN
networks. More and more, the customers have the opportunity to
extend their networks via a service provider by running native L2
protocols, such as Ethernet, without having to go through a
complex and unnecessary transformation to WAN protocols.
It is anticipated that Network Based Layer 2 VPN services may be
more transparent to providers, easier to manage, and less
expensive to maintain. It is also anticipated that networks based
Layer 2 VPN may be a key service in future metro and wide area
service infrastructure.
In this document we attempt to outline the requirements for
network based Layer 2 VPN services. The work presented in this
document intends to serve as a guideline for equipment vendors and
service providers. This document does not discuss any specific
protocol, however it does specifies requirements that needed to be
satisfied by a given protocol.
3.1 Background
Senevirathne et.al, Informational û December 2001 3
draft-tsenevir-l2-req-01.txt July 2001
Typically Layer 2 NBVPN may be used to connect a local LAN segment
to multiple remote LAN segments. These LAN segments may contain
one or more Work stations. A pictorial representation of a typical
deployment is depicted below.
|
%
|
------- |----a'
| | PE | o
% -----| B |--o-o--|----b'
| / | | o
a-----| ------ / ------ |----c'
o | PE | / | CE B
b-----|-o-o-| A |--------- %
o | | \
b-----| ------ \ %
| \ ------- |----x
CE A % -----| PE | o
| | C |-o-o-- |----y
| | o
------- | ---z
| CE C
%
|
CE - Customer Edge (Represent one more Devices in a LAN)
PE - Provider Edge
-o- Physical Connection
--- Logical Connection
-%- Partition of Functionality
Fig: Typical Layer 2 NBVPN deployment
In general Layer 2 NBVPN contain multiple end points (sites).
These end points may or may not be within the same service
provider infrastructure. Within a given service provider
infrastructure there exists multiple Layer 2 NBVPN planes that
belongs to different customers. [3] Has logically represented this
as a tower of disks.
|
-----------------
| | Plane-2
-----------------
Senevirathne et.al, Informational û December 2001 4
draft-tsenevir-l2-req-01.txt July 2001
|
|
|
|
|
-----------------
| | Plane-1
-----------------
|
-----------------
| | Infrastructure
-----------------
Fig: Logical representation of Layer 2 NBVPN
Within each plane, multiple broadcast domains exist based on the
VLAN usage by the customers. A given VLAN in a given Layer 2 NBVPN
plane may span across a set of given end points.
4. Requirements for Network Based Layer 2 VPN
In this section we present key requirements in Network Based Layer
2 VPN services.
+-------------------------------------+----------+------+-----+
| Control Plane | | | |
+-------------------------------------+ | | |
| | | | | | |
| | | |General/ | | |
| Access | Forwarding | Back-end |Architecture | |
| Plane | Plane |tunneling |Plane | | |
| | | Plane | | | |
| | | | | | |
| | | | | | |
+-------------------------------------+----------+ | |
| | |
| Management Plane | |
+-------------------------------------------------------+ |
| |
| Security Plane |
+-------------------------------------------------------------+
Fig: Placement of Layer 2 NBVPN requirements.
The above diagram depicts placement of key requirements of Layer 2
VPN services. In this document we identify six major areas.
Underlying Layer 2 NBVPN requirements can be classified into one
or more of these areas. Classification of underlying requirements
into these major areas allows readers to co-relate stated
Senevirathne et.al, Informational û December 2001 5
draft-tsenevir-l2-req-01.txt July 2001
requirements into different components of the product or service
infrastructure, easily. On the other hand it allows readers to
properly evaluate requirements, technically.
General/Architecture Requirement Plane (G)
The requirements in this plane represent global or general
requirements that covers all other planes or requirements such as
concepts that specify the entire Layer 2 NBVPN infrastructure.
Control Plane (C)
Requirements in this plane represent signaling and control
functionality.
Access Plane (A)
Requirements in this plane specify the CPE-PE Access.
Forwarding Plane (F)
Requirements in this plane specify the Forwarding behavior and
architecture required to implement Layer 2 NBVPN.
Back-end tunneling Plane (B)
Requirements in this plane specify the requirements for back-end
tunneling protocols to properly implement Layer 2 NBVPN services.
Management Plane (M)
Management plane specifies management requirements for Layer 2
NBVPN services. Management plane covers all other planes in the
Layer 2 NBVPN infrastructure.
Security Plane (S)
Security plane specifies security aspects for Layer 2 VPN
services. Security plane covers all other planes in the Layer 2
VPN infrastructure.
NOTE: Some requirements may qualify for more than one plane such
requirements are identified by specifying the requirement scope
within (x). As an example a requirement that qualify for both
Access and Control plane are denoted with a qualifier of (A,C).
5. Control Plane Requirements
5.1 Customer End-point and VLAN discovery (C)
A given customer may have several VLANs spanning multiple sets of
sites. The L2 NBVPN infrastructure MUST NOT require all VLANs span
the same set of sites.
Senevirathne et.al, Informational û December 2001 6
draft-tsenevir-l2-req-01.txt July 2001
For the purpose of packet forwarding, address learning and tunnel
construction, the infrastructure MUST employ methods to discover
the end points that belong to different Layer 2 VLAN domains
within a single L2 NBVPN plane.
In simpler small-scale implementations, providers may configure
the remote end-points and VLAN span manually. Though such methods
works for smaller deployments, ability to discover and bind remote
sites is essential in larger deployments. Hence it is required to
have methods in place to distribute VLAN and domain information.
Automatic VLAN distribution methods are required to have ability
to limit the scope of distribution of customers VLAN information.
5.1.1 End-point-VLAN policies
End-point-VLAN policies are broadly classified in to two
categories; Announce Polices and Bind polices
Bind Policies
Bind polices specifies binding of incoming advertisements to the
local representation. The End-point-VLAN policies are required to
be flexible enough to cover different requirements.
Announce Policies
Announce policies apply when advertising L2NBVPN information. The
announce policies identify which reachability information need to
be advertised and the scope of the advertisement.
5.2 End-point VLAN tag translation
The infrastructure MAY support translation of customersÆ VLAN
tags. Such service simplifies connectivity of sites that want to
keep their tag assignments or sites that belong to different
administrative entities. In the latter case, the connectivity is
sometimes referred to as L2 extranet.
5.3 Group (Multicast) Address Registration Services (C)
Layer 2 NBVPN providers MAY provide Group Address Registration
service. The Group Address Registration service facilitates
customers to define applicable flooding scopes for multicast
addresses. Some available alternatives for Group Address
Registration services are, IGMP snooping, Generic Multicast
Address Registration Protocol (GMRP).
Senevirathne et.al, Informational û December 2001 7
draft-tsenevir-l2-req-01.txt July 2001
In the absence of Group Address Registration services either
Provider has to manually configure the scope of the multicast
addresses or flood the multicast addresses to all endpoints.
5.4 Support for Layer 2 control protocols such as GVRP and STP (C)
The Layer 2 NBVPN in theory emulates a LAN. Hence like physical
LAN Layer 2 NBVPN SHOULD be transparent to Layer 2 Control
protocols such as STP. However, optionally, Laver 2 NBVPN PE
device MAY participate in GVRP to create forwarding scope
dynamically, within a given customer domain. (This may be viewed
same as IGP in VPRN)
GVRP is used as a dynamic VLAN registration protocol. Traditional
Layer 2 devices create dynamic Layer 2 forwarding databases based
on the GVRP registrations from CPE. Layer 2 VPN PE devices are
required to maintain separate VFI instance for each customer's
VLAN. In addition, VFI defines binding between the Local VFI and
remote end points.
Hence, PE devices that support dynamic VLAN registration via GVRP
MUST have capabilities to create Layer 2 VFI instances based on
incoming GVRP registrations. Also PE devices MUST have
capabilities to bind GVRP registrations to Layer 2 VFI.
Spanning Tree Protocol (STP) is a widely used Layer 2 protocol to
prevent loops. Some customers may wish to implement the redundancy
using STP rather than purchasing a redundant Layer 2 VPN service
from the provider. The multi-point-to-multi-point Layer 2 VPN
services in theory emulates legacy LAN topology. Unlike GVRP, the
PE devices are not required to participate in STP processing. It
is sufficient to transparently pass incoming BPDU to remote sites.
Consider the following fully meshed Layer 2 VPN deployment and the
logical representation of the deployment. It is clear that ability
of all end devices to receive BPDU is sufficient for proper
operation of STP.
------- (F) -------
CPE | |--------------------------------| | CPE (B)
---- | PE |--------------- (F)| PE |-----
| (R) | | | | |
------- | ------- x
| | backup |
| | x
| ------- |
| | | CPE x
-------------- | PE |-----
(F) | | (F)
Senevirathne et.al, Informational û December 2001 8
draft-tsenevir-l2-req-01.txt July 2001
-------
Fig: Fully-meshed Layer 2 VPN topology
CPE CPE -x-x-x-x-x-x-x- CPE
| |(B) Backup (F)|
| | |
-------- --------- ---------
| | | | | |
| PE | | PE | | PE |
| | | | | |
-------- --------- ---------
|(F) | (F) | (F)
| | |
| | | Emulated LAN
------------------------------------------------------------
Fig: Logical Representation of Fully Meshed Layer 2 VPN
(R) - Root Bridge
(F) - Forwarding Port
(B) - Block Port
5.5 Recovery and Restoration (C,B,F)
Redundancy of Layer 2 topologies are mostly implemented using
Spanning Tree Protocols. Any major change in Layer 2 topology
requires STP to re-converge. Re-convergence of STP is in the order
of 10's of seconds. It is sufficient to have the same degree of
re-convergence capabilities in Layer 2 NBVPN.
Alternatively Layer 2 NBVPN MAY provide redundant paths to assure
high availability. The reaction to failures should result in an
attempt to restore the service using alternative paths. It is
desirable to make the restoration times as small as possible.
The restoration time SHOULD be less than the failure detection
time of L3 service running over the same VLAN.
When implementing fast-reroute methods in the Back-end, the
architecture MUST not violate requirements specified in this
document. As an example a fail-over may not cause any packet mis-
ordering.
5.6 Dynamic Service Signaling (C)
A provider MAY offer an in-band method for selecting services from
the list specified in the SLA.
Senevirathne et.al, Informational û December 2001 9
draft-tsenevir-l2-req-01.txt July 2001
6. Forwarding Plane Requirements
6.1 Layer 2 Virtual Forwarding Instance (F)
Traditional Layer 2 devices maintain a separate Layer 2 forwarding
database per VLAN instance. All forwarding decision for the VLAN
is made using the Layer 2 forwarding database of that VLAN.Layer 2
NBVPN providers are required separate forwarding decision between
customers. Within a given customer domain, forwarding decisions
are again separated based on VLAN usage. Thus Layer 2 NBVPN
requires two-level Layer 2 Virtual Forwarding Instance.
Layer 2 NBVPN, Provider Edge devices MUST have capabilities to
classify incoming customer traffic into the appropriate customer
domain and identification of the proper Layer 2 Virtual Forwarding
instance based on Customer domain and VLAN identifier.
6.2 MAC address learning (F,C)
The Layer2 NBVPN is intended to be transparent to L2 customer
networks.
Traditional Layer 2 devices learn MAC addresses in the context of
a VLAN. Such devices learn MAC addresses against a
physical/logical port.
In Layer 2 NBVPN MAC address learning takes place in the context
of Layer 2 Virtual Forwarding Instance. That is in the context of
Customer domain and a VLAN. The reachability of MAC addresses may
be either via a directly attached physical port or a virtual port
where remote MAC address may be reached. The virtual port may
represent a physical port, a tunnel or some other logical
representation. Hence, Layer 2 NBVPN PE devices are required to
support virtual port concepts.
It is expected that the Layer 2 NBVPN is able to derive all
topology and forwarding information from packets originating at
end user sites. The service MAY implement a MAC addresses
learning mechanism for this purpose.
The Layer 2 NBVPN is intended to be transparent to Layer 2 end
user networks. It MUST NOT require any special packet processing
by the end users before sending packets to the providerÆs network.
6.3 Unknown, Multicast and Broadcast forwarding (F)
Unknown, Broadcast and Multicast packets are required to be
forwarded to all endpoints of the given customers given VLAN. The
scope of Broadcast, Multicast and Unknown is called Broadcast
domain. For a given customer there are multiple Broadcast domains,
one for each VLAN.
Senevirathne et.al, Informational û December 2001 10
draft-tsenevir-l2-req-01.txt July 2001
The PE device is required to have capabilities to forward traffic
to multiple end points within a given Broadcast domain.
The PE device is required to separate traffic between different
broadcast domains.
Each Layer 2 Virtual Forwarding Instance (VFI) is required to
have flooding capabilities in the scope of its broadcast domain to
facilitate proper forwarding of Broadcast, Multicast and Unknown
traffic.
The Layer2 NBVPN MUST be aware of the existence and the designated
roles of special MAC addresses such as Multicast and Broadcast
addresses. The Layer 2 NBVPN MUST forward these packets according
to their intended functional meaning and scope.
If the Layer 2 NBVPN relies on MAC learning for its operations, it
MUST assure proper forwarding of packets with MAC addresses that
have not been learned.
6.4 Multi site spanning broadcast domains (F)
Broadcast domain is defined as the flooding scope of the Layer 2
network. Flooding scope of a Layer 2 network is the scope of end
points that are included in Multicast, Broadcast and Unknown
traffic forwarding. Each broadcast domain is defined in the
context of a give customer and the scope of a given VLAN. In other
words each Layer 2 VFI MUST contain its own Broadcast domain or a
flooding scope.
6.5 Scope of Unknown MAC Addresses (F,C)
In general, unknown MAC addresses are flooded to all end point of
the Layer 2 NBVPN. In order to conserve bandwidth and allow
security, some customers MAY require Layer 2 NBVPN PE devices
provide methods to define scope of unicast MAC addresses.
6.6 Mac address transparency in the core (F,B)
Traditionally, Layer 2 forwarding requires learning of MAC
addresses. A given device can only learn a finite set of MAC
addresses. If Layer 2 NBVPN is implemented with the requirement to
learn MAC addresses in the core; then the number of Layer 2 NBVPN
that could be supported in the core will depend on the total
number of MAC addresses a device can learn. On the other hand any
topology change in the core may require to relearn MAC addresses.
In order to keep data flow uninterrupted, during the interval of
relearning flooding of data is required. Flooding of customer data
in the network core may affect the available bandwidth. The Layer
2 address space of each customer is mutually exclusive from one-
another. Hence the devices in the core are required to maintain
multiple Layer 2 VFI.
Senevirathne et.al, Informational û December 2001 11
draft-tsenevir-l2-req-01.txt July 2001
Large scale Layer 2 NBVPN deployments MAY require to implement
tunneling methods that interconnect remote sites. Tunneling
protocol defines the forwarding in the core. Topology convergence
and recovery is part of the tunneling protocol. The customer MAC
addresses and VLAN are require to be transparent to the devices
in the core. Hence the devices in the core are not require to
implement Layer 2 VFI for all the customers in the network. On the
other hand the devices in the core may not be Layer 2 devices at
all in its configuration. Only the PE devices required having
Layer 2 forwarding capabilities in its configuration.
The Layer 2 NBVPN is intended to be transparent to all customers
per-VLAN basis. The Layer 2 NBVPN MUST NOT rely on global
uniqueness of MAC addresses.
6.7 Minimum MTU (F)
The service MUST support customer frames 1500 bytes long. The
service MAY offer support for longer frames.
The service MUST NOT fragment packets. Packets exceeding
committed MTU size MUST be discarded.
6.8 Packet re-ordering or duplication (F)
The service MUST preserve the order of packet sent from one end
point to another end point within given VLAN with given committed
topology.
The service MUST NOT duplicate packets.
6.9 Support for MAC Services (G,F)
Layer 2 NBVPN are required to provide MAC service as specified in
IEEE 802.1D specification [4] Section 6. Some of the MAC services
defined in [4] are directly applicable to Layer 2 NBVPN. Some
other MAC services require changes in order to be meaningful in
Layer 2 NBVPN applications. In this section each of the MAC
service requirements specified in [4] are revisited. All Layer 2
NBVPN devices are required to support MAC services presented in
this section. Compliance with this section facilitates proper
operation of 802.1 LAN and seamless integration of Layer 2 NBVPN
with bridged Local Area Networks.
A MAC service in the context of Layer 2 NBVPN is defined as;
Transfer of user data between source and a destination end
stations via the service access points using the information
specified in the Layer 2 NBVPN VFI.
6.9.1 Preservation of MAC services
Senevirathne et.al, Informational û December 2001 12
draft-tsenevir-l2-req-01.txt July 2001
MAC services offered by LAN's interconnected by Layer 2 NBVPN
devices must be similar to MAC services provided in a single LAN.
Hence,
1. A Layer 2 NBVPN must not be directly accessed by end stations
except for explicit management purposes.
2. All MAC addresses must be unique within a given customer domain
and a VLAN, i.e. within VFI.
3. The MAC addresses of end stations must not be restricted by the
topology and configuration of the Layer 2 NBVPN.
6.9.2 Quality of service maintenance
The quality of services provided by Layer 2 NBVPN must not be
significantly inferior to that of LAN or IEEE 802.1 bridges.
Following areas, at minimum, must be considered when evaluating
the quality of service maintenance in Layer 2 NBVPN. Section 4.14
above present quality of service requirements that may be specific
to Layer 2 NBVPN.
. Service availability
. Frame loss
. Frame misordering
. Frame duplication
. The transit delay experienced by frames
. Frame lifetime
. The undetected frame error rate
. MTU size support
. User priority
. Throughput
. Scope of Layer 2 forwarding
Service availability
Service availability is defined as a fraction of some total time
during which the Layer 2 NBVPN services are available.
Automatic reconfiguration and other methods may increase Service
availability. During service failures or automatic
reconfiguration, Layer 2 NBVPN devices may deny access and discard
frames to preserve forwarding aspects and other requirements of
Layer 2 NBVPN.
Frame loss
Layer 2 NBVPN devices do not guarantee frame delivery. Frames may
be discarded due to several reasons. PE device must provide
statistics on frame loss that occur within the PE. Layer NBVPN PE
devices are often connected via some tunneling method. Unlike
802.1 bridges the Layer 2 NBVPN PE devices may be separated by
several hops. Hence Frame loss can occur some where in the
Senevirathne et.al, Informational û December 2001 13
draft-tsenevir-l2-req-01.txt July 2001
transit. Collection of such loss of frames is OPTIONAL and some
implementation may not provide them.
Frame misordering
Layer 2 NBVPN must not permit misordering of frames of a given
customer domain, for a given VLAN with a given user priority.
Frame duplication
The Layer 2 NBVPN must not permit frame duplication. If there
exists multiple paths between PE devices forwarding pollicies of
the local PE must ensure that only a single copy of the frame is
transmitted to the remote PE device. Definition of frame
forwarding polices are beyond the scope of this document. Section
7.7 of [4] provides detail explanation of frame forwarding in IEEE
bridges. These forwarding policies may be extended to Layer 2
NBVPN.
Transit delay
It is difficult to measure the total transit time taken from end
station to end station. However, transit time of Layer NBVPN PE
devices may be measured in terms of total time taken for
reception, classification and transmission of the frame. Transit
delay of Layer 2 NBVPN MUST be in compliance with 802.1D
specification [4]. The transit delay introduced by Layer 2 NBVPN
must not be arbitrarily large.
Frame lifetime
In order to ensure proper operation of upper layer protocols,
Layer 2 NBVPN devices must specify an upper bound to the transit
delay specified above.
Traditional bridges consider transmit time as the time taken to
transmit the packet in to the wire. However, due to multi-hop
separation between PE devices, the transmission time of a frame at
PE device must take in to account the delay introduced by the
transit network (tunnels).
As per 801.1D[4] specification lower bound for maximum frame life
time is 1.0 seconds and upper bound for maximum frame life time is
4.0 seconds.
Layer 2 NBVPN MAY specify different set of frame life time
parameters.
MTU Size.
Layer 2 NBVPN PE devices and the network must be capable of
supporting the largest MTU size that customer is required to
transmit. In another words, customer is capable of transmitting
Senevirathne et.al, Informational û December 2001 14
draft-tsenevir-l2-req-01.txt July 2001
the smallest of all MTU sizes supported by the Layer 2 NBVPN
devices and the network.
Priority
Layer 2 NBVPN PE devices maps priority of incoming user traffic in
to different internal traffic classes. In the egress to the back
end (tunnels) PE device may map these traffic classes in to
different planes of the NBVPN. Each of these planes MAY be defined
with different traffic engineering parameters. Mapping of user
priorities to egress traffic planes is entirely a local policy and
beyond the scope of this publication.
Throughput
Based on the service level agreement and bandwidth provisioning,
the total throughput provided by Layer 2 NBVPN network may be
significantly less than that of the local LAN. Hence PE device may
discard frames that exceed the provisioned bandwidth.
Scope of Layer 2 forwarding
In order to optimize forwarding of MAC addresses, Layer 2 NBVPN PE
devices may provide methods to specify the scope of a MAC address.
The scope of the MAC address is defined as potential end-point
where such MAC address can appear or where potential stations that
wish to receive frames are located.
7. General/Architecture Requirements
7.1 Layer 2 Domain representation and VLAN allocation (G)
Layer 2 Network based VPN infrastructure MUST distinguish
different customer domains. Each of these customer domains MUST
appear as a L2 broadcast domain network behaving like a LAN (Local
Area Network).
Configurations within the provider MUST not constrain customers
ability to configure VLANs or any other Layer 2 parameters.
As explained in above section 3.1, Layer 2 NBVPN appears as a
logical plane in the service infrastructure. The Layer 2 NBVPN
plane MAY span across multiple service provider infrastructures.
Layer 2 NBVPN Domain Identifier (L2NBVPNDoamin) uniquely identify
a given Layer 2 NBVPN. The L2NBVPNDoamin identification is hence
required to be unique within all service providers.
It is suggested that L2NBVPNDoamin {AS:L2NBVPNdomain-ID} MAY be
derived as a combination of AS (Autonomous System) Number and a
unique number that represent the customer's domain (L2NBVPNdomain-
ID) within the AS.
Senevirathne et.al, Informational û December 2001 15
draft-tsenevir-l2-req-01.txt July 2001
Within a given AS L2NBVPNdomain-ID MUST be unique for all the end
points in a given L2NBVPN plane.
7.2 Customer end point inter connection (G,B)
Layer 2 networks require a symmetric connectivity between devices.
In other words each device MUST have connectivity to all other
devices.
Hub and spoke or point-to-multi-point is a popular deployment
model in legacy Frame Relay networks. When providing routed
services, inter site traffic is routed via the hub site.
When providing Layer 2 Connectivity, Hub is required to implement
complex forwarding policies to achieve symmetric connectivity. On
the other hand hub and spoke model may be used for deployment that
does not require symmetric connectivity. Example of such
deployment is - remote sites that requires connectivity to the
data center and does not require connectivity between remote
sites.
Many-to-many (either logical or physical) is required to be
deployed for Layer 2 services that require symmetric connectivity.
Enterprise networks that extend the private LAN using Layer2 NBVPN
require many-to-many connectivity.
7.3 Class of Service Model (G)
The VLAN service SHOULD define a graded selection of classes of
traffic. This includes, but is not limited to
o range of priorities
o best effort vs. guaranteed effort
o range of minimum delay characteristics
7.4 L3, and higher, service access point (G)
The VLAN SHOULD a allow for a Provider based Service Access Point
for orderly injection of L3 or higher services to the customerÆs
VLAN.
As a value added service, L2 NBVPN may provide access to other
services such as, IP gateways, Storage networks, Content delivery
etc..
8. Management Plane Requirements
Layer 2 NBVPN infrastructure MUST have capabilities to manage and
monitor different components.
Senevirathne et.al, Informational û December 2001 16
draft-tsenevir-l2-req-01.txt July 2001
Layer 2 NBVPN infrastructure MAY provide methods between CPE-PE
devices for self provisioning and management.
8.1 Graceful reconfiguration (M)
In cases where the provider knows a priori about impending fault,
the network SHOULD be reconfigured without a loss, duplication, or
re-ordering of customer packets. This situation typically arises
with planned network upgrades, or scheduled maintenance
activities.
9. Security Plane Requirements
All layer 2 NBVPN devices MUST require to have ability to isolate
traffic for each Layer 2 VFI. Ingress classification MUST be well
defined such that there exists one and only one VFI for each VLAN
of each customer domain. In other words, provider MUST provide
traffic separation between different customers and between
different VLANs of the same customer. The traffic separation MUST
prevent leaking of the traffic in or out of VLANs in a normally
functioning Layer 2 NBVPN.
Optionally; PE devices may offer data encryption and
authentication services. Protection against denial of service
attacks. Protection against bandwidth and connection hijacking.
Ability to provide some of these optional security requirements
may depend on tunneling protocol used in the core.
In addition, each key requirement plane may specify itÆs own
security requirements. Such requirements are discussed under each
of those sections. As an example, Access plane MAY have very
specific set of requirements that are not related to security
requirements of Management plane.
9.1 Immunity from malformed customer traffic (S)
The providerÆs infrastructure MUST NOT be compromised by
malformed, or maliciously altered, customer traffic. This
includes, but is not limited to, duplicate or invalid MAC
addresses, short packets, long packets, etc.
10. Back-End Tunneling Requirements (B)
The main difference of Layer 2 NBVPN with traditional bridging is
use of back-end tunneling.
The tunneling protocol used MUST be capable of providing a logical
connectivity between PE device in the NBVPN domain.
Tunneling protocol MUST be capable of providing required
connectivity. If the chosen Layer 2 NBVPN service requires many-
Senevirathne et.al, Informational û December 2001 17
draft-tsenevir-l2-req-01.txt July 2001
to-many connectivity then PE device SHOULD require to support the
many-to-many connectivity in the back-end. If the tunneling
protocol is not capable of providing the required connectivity
then PE device MUST have capability to support appropriate
forwarding behavior.
The back-end tunneling protocol SHALL not affect the scalability
of Layer 2 NBVPN service.
The back-end tunneling protocol MUST not require customers to use
special equipment or alteration to the normal network
topology/protocols or other..
There are several choices for back-end tunneling protocols. The
choice of tunneling protocol depends on various factors. Popular
choices are MPLS, IP-tunneling. There are proposals to use
variations of 802.1Q to achieve required tunneling behavior,
discussion of such tunneling protocols are beyond the scope of
this document.
11. Access Requirements:
Access requirements broadly specifies the requirements for CPE to
PE connection.
CPE-PE access connection MAY require spanning other providers or
public networks.
CPE-PE access MAY require to support different technologies such
as Ethernet, ATM (DSL), Frame Relay etc.
PE device that provide Layer 2 NBVPN services MAY require to
support multiple logical access connections over a single physical
access connection. The logical connection MAY be either in the
Form IEEE802.1Q VLAN Tagged format or MPLS Label Switched Path or
ATM connection or some other technology. When providing logical
access, PE devices MUST honor QoS and other properties of the
logical connection. As an example when logical connections are
provided using IEEE 802.1Q VLAN Tagging, PE device MUST provide
capabilities honor QoS parameters of the logical connection.
PE device MUST have capabilities to translate properties of
logical connections to corresponding properties of the back-end
tunneling. Translation of these properties are a local policy and
beyond the scope of this document.
PE devices SHOULD not restrict the physical connectivity of the
access to a single technology such as optical Ethernet (10G). PE
device SHOULD have capabilities to provide different physical
access technologies.
Senevirathne et.al, Informational û December 2001 18
draft-tsenevir-l2-req-01.txt July 2001
Access speeds
The Layer 2 NBVPN service shall allow for sites specific access
speeds, i.e. it shall be possible to interconnect sites operating
on and accessing to the backbone on any of the different standard
access speeds. Neither the access speed to the backbone or the
bandwidth on the LANs on the sites needs to be identical.
11.1 Security Requirements for Access Plane
The PE device SHOULD support all the security requirements
mandated by the technology used to specify access connections.
The PE device MAY provide additional security features based on
the SLA (Service Level Agreement).
The PE device MAY require to provide additional security services
based on the access is a direct connection or over a public
network.
The security methods used in the access plane MAY not depend on
the security mechanisms in the back-end.
12. References
1 Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 Senevirathne, T., and et.al., Framework For Virtual
Metropolitan Internetworks (VMI), Work in Progress, February
2001
4 ANSI/IEEE Std 802.1D, Media Access Control (MAC) Bridges,
Internatyional Electrotechnical Commission, 1998.
13. Acknowledgments
Ongoing discussion in PPVPN has influenced work presented in this
document.
14. Author's Addresses
Tissa Senevirathne
Force10 Networks
1475 McCarthy Blvd
Senevirathne et.al, Informational û December 2001 19
draft-tsenevir-l2-req-01.txt July 2001
Milpitas, CA
Phone: 408-965-5103
Email: tissa@force10networks.com
Waldemar Augustyn
Nortel Networks
600 Technology Park
Billerica, MA 01821
Phone: 978 288 4993
Email: waldemar@nortelnetworks.com
Loa Andersson
Utfors Bredband AB
Box 525
SE-169 29 Solna
Sweden
Phone: +46 8 5270 5038
Email: loa.Andersson@utfors.se
Tove Madse
Utfors Bredband AB
Box 525
SE-169 29 Solna
Sweden
Phone: +46 8 5270 5038
Email: tove.madsen@utfors.se
Pascal Menezes
TeraBeam Networks
2300 Seventh Ave Seattle, WA 98121
Email: Pascal.Menezes@Terabeam.com
Appendix A: Acronyms and Abbreviations
NBVPN û Network Based Virtual Private Networks
PE û Provider Edge Device
CE û Customer Edge Device
VFI û Virtual Forwarding Instance
GVRP û Generic VLAN registration Protocol
Senevirathne et.al, Informational û December 2001 20
draft-tsenevir-l2-req-01.txt July 2001
SLA û Service Level Agreement
STP û Spanning Tree Protocol
VLAN û Virtual Local Area Network. VLAN in this document refers to
VLAN identifiers assigned by customers
Senevirathne et.al, Informational û December 2001 21
draft-tsenevir-l2-req-01.txt July 2001
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 implmentation 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
Senevirathne et.al, Informational û December 2001 22