Internet DRAFT - draft-augustyn-vpls-bw
draft-augustyn-vpls-bw
PPVPN Working Group Waldemar Augustyn
Internet Draft
Document: draft-augustyn-vpls-bw-00.txt
Category: Informational November, 2001
Bandwidth Management in VPLS Networks
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
Summary for Sub-IP related Internet Drafts
RELATED DOCUMENTS:
Requirement for PPVPN, Requirements for VPLS, See references.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
This ID is intended for the PPVPN WG.
WHY IS IT TARGETED AT THIS WG(s)
This document discusses bandwidth management issues vital to L2
Virtual Private Network solutions such as Virtual Private LAN
Service, (VPLS) [4]. VPLS is a class of Provider Provisioned VPN,
(PPVPN)[2].
Augustyn, W. Expires May 2002 1
draft-augustyn-vpls-bw-00.txt November 2001
JUSTIFICATION
The bandwidth management issues are of paramount importance in L2
VPN services. This document proposes a solution suitable for a
many-to-many L2 VPNs such as VPLS.
1. Abstract
This document describes a method for controlling customer traffic
for L2 VPN services which support broadcast, multicast or implied
broadcast such as Virtual Private LAN Service (VPLS), or other L2
Provider Provisioned VPNs. The method guarantees stability of the
provider network regardless of the behavior of customer traffic,
benign or malicious.
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 [3].
3. Introduction.
A proper bandwidth management, always an important topic in data
networks, becomes a critical issue in designing scalable L2 networks
services, such as VPLS [4]. Customer broadcast traffic, whether
explicit or implicit due to unknown L2 destinations, as well as
certain native L2 protocols run by customers, are frequently seen as
a threat to the stability of providers' networks.
The solution described in this document places the provider in the
position to control all customer L2 traffic. In this way, a provider
can guarantee its network's stability regardless of the stability,
or lack thereof, of its customers' networks.
Additionally, the solution makes it easier to structure commercial
services that can properly match the requested level of service with
the cost of providing it.
The focus of the document is on the operations of provider networks
but a provider, as a value added service, may also offer help
maintaining stable networks to its customers.
4. Service Capacity.
The starting point for all considerations regarding bandwidth
management is the context of Provider Provisioned VPNs [2]. In this
Augustyn, W. Expires May 2002 2
draft-augustyn-vpls-bw-00.txt November 2001
context, a provider builds a network for a commercial purpose of
selling its capabilities to customers. A provider makes binding
promises with respect to the particular characteristics of the
network services being offered.
This leads to key observations:
o Known total capacity. A provider knows the total available
service capacity of its network prior to offering any
service.
o Known capacity share of services. A provider knows how much
of the total capacity the offered services take.
The actual capacity may fluctuate and a provider may use various
technological means to determine available capacity at any given
time and place in the network, but all discovery and determination
is made prior to offering services.
5. Transport Modes.
Once services have been offered to customers, a provider's concern
is to make sure customer traffic, whether benign or malicious, does
not exceed the allocated share of network capacity. This can be
accomplished by dividing all transfers into two modes of operations
and then by proper management of each of the modes:
o Committed Rate Transport Mode, CRTM.
o Best Effort Transport Mode, BETM.
5.1. Committed Rate Transport Mode, CRTM.
The CRTM mode represents a provider's commitment to a particular
service level. All packets falling into the CRTM category will be
forwarded according to the advertised characteristics associated
with them. These could include delay, bandwidth, jitter, etc. In
this mode, all transport parameters have been determined and all
necessary network resources have been allocated and guaranteed for
the duration of the service prior to offering it to the customer.
5.2. Best Effort Transport Mode, BETM.
In contrast, the BETM mode is representative of a provider's
unwillingness to commit to any specific characteristics of the
service beyond a promise to try. The packets could be forwarded as
intended but they could just as well be delayed or dropped
altogether based on arbitrary decisions made by the provider's
network. In this mode, the transport parameters are not
Augustyn, W. Expires May 2002 3
draft-augustyn-vpls-bw-00.txt November 2001
deterministic and may change at any time after the service has been
offered.
5.3. Transport Priorities.
There is no priority relationship between the transport modes. The
CRTM is not "higher" priority than BETM. These two fundamental
modes are independent of each other. Vendors may utilize priority
schemes available in their devices' hardware for implementation but
the resulting transport modes must remain independent.
The prioritization of traffic is strictly a value added option for
customers and applicable only in the context of their traffic. There
is no priority relationship between traffic belonging to different
customers, or even belonging the same customer that uses two or more
disjoint VPN services.
6. Service Topology.
Many L2 service requirements specify some particular types of
connectivity between sites without mandating uniformity in the
traffic parameters. Such is the case with VPLS. It defines the
service as LAN-style, many-to-many connectivity between all points
but it does not require the traffic characteristics be identical
between all points in a VPLS.
For services such as VPLS and other with similar issues, the precise
specification of traffic characteristics is made in terms of the
transport modes discussed in the previous section. In addition to
network connectivity topology, a service topology is supplied. The
service topology refers to commercial offer from the provider to the
customer.
6.1. Base Service Topology.
The base service topology describes the existence of direct
connectivity between nodes as mandated by particular type of L2
service. For VPLS, the base service topology is a full mesh or
many-to-many.
The transport mode for base service topology is BETM. This is the
default.
6.2. Committed Service Topology.
With BETM being the default, a provider only needs to specify those
parts of the network that operates in the committed rate mode, CRTM.
The configuration of the network where CRTM is applicable is
referred to as Committed Service Topology.
Augustyn, W. Expires May 2002 4
draft-augustyn-vpls-bw-00.txt November 2001
In case of VPLS, this means the many-to-many connectivity topology
will be covered at least by the best effort mode, BETM. A provider
may guarantee certain traffic characteristics on this network
through CRTM. For example, it can offer CRTM for traffic from one
particular site, say company headquarters, to all others, say
company branches. All traffic to and from the headquarters is
guaranteed, but traffic between the branches is best effort.
The Committed Service Topology can take all forms: point-to-point,
point-to-multipoint a.k.a. hub-and-spoke, partial mesh, and full
mesh.
6.3. Preferred Service Topology Construct.
It is useful to select a simple base construct for describing
complex service topologies. A good candidate is a symmetric hub-
and-spoke.
A symmetric hub and spoke lists all relevant traffic characteristics
between a single customer access point, the hub, and a number of
connecting access points, spokes. The traffic going from the hub
has the same characteristics as the traffic going to the hub.
A provider can use this construct to describe all possible service
configurations:
o Point-to-point. A special case of hub-and-spoke, only one hub
and only one spoke.
o Point-to-multipoint. Exact hub-and-spoke, probably the most
common configuration.
o Partial mesh. A collection of hub-and-spoke where some spokes
are also hubs.
o Full mesh. A collection of hub-and-spoke where all spokes are also
hubs.
7. Traffic Policing and Shaping.
7.1. Traffic Policing.
The solution requires traffic policing at certain strategic points
in the provider's network. The details depend on implementation. A
good guideline is to drop excess traffic as soon as it is known to
be exceeding committed rate.
Augustyn, W. Expires May 2002 5
draft-augustyn-vpls-bw-00.txt November 2001
Typically there are three logical policing points in the network.
For example, let's assume a VPLS network where all PEs are fully
meshed with one another.
The policing points are:
o provider ingress
o tunnel ingress
o provider egress
Customer traffic is first checked at the entry to the provider's
network. Soon after that, it is evaluated again after the tunnel to
the destination PE has been determined. If the packet is following a
Committed Service Topology path, it is evaluated against committed
traffic characteristics and it could be dropped if it exceeds them.
If the packet travels along a best effort path, it is still
evaluated and possibly dropped with the difference that the criteria
are totally at the discretion of the provider.
After the packet reaches the destination PE, it is evaluated for the
last time before it is sent to the customer CE. Unlike the previous
policing points, this one does not play any vital role in protecting
the stability of the provider's network, rather, it enforces the
terms of the agreement with the customer. Of course, a provider may
elect to let all traffic go to the customer if it has already made
it to the destination PE. However, the service should offer means to
control it fully.
7.2. Traffic Shaping.
Traffic shaping is encouraged but it is not required for proper
operation of the service. It is easy to see that the arrangement of
traffic policing benefits the customer sites that employ shaping. A
provider managed traffic shaping can be offered as a value added
service.
8. Security Considerations.
This memo does not discuss security issues.
9. Intellectual Property Considerations.
The author may seek patents or other intellectual property
protection for some or all of the technologies disclosed in this
document. If any standards arising from this document are or become
protected by one or more patents assigned to the author, the author
intends to disclose those patents and license them on reasonable and
non-discriminatory terms.
Augustyn, W. Expires May 2002 6
draft-augustyn-vpls-bw-00.txt November 2001
10. References.
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2. Carugi, M., et. al., "Service requirements for Provider
Provisioned Virtual Private Networks", Work in Progress, June
2001.
3. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
4. Augustyn, W., et al., "Requirements for Virtual Private LAN
Services (VPLS)", Work in Progress, October 2001.
11. Author's Contact.
Waldemar Augustyn
email: waldemar@nxp.com
Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards 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."
Augustyn, W. Expires May 2002 7
