Internet DRAFT - draft-declercq-ppvpn-l3vpn-qos
draft-declercq-ppvpn-l3vpn-qos
Network Working Group Jeremy De Clercq
INTERNET DRAFT Alcatel
<draft-declercq-ppvpn-l3vpn-qos-00.txt>
February 2003
Expires August, 2003
QoS considerations for L3 PPVPNs
<draft-declercq-ppvpn-l3vpn-qos-00.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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
Although QoS is identified as a very important requirement for L3
PPVPNs (see for example [PPVPN-REQ]), the proposed L3 PPVPN solutions
([2547bis], [VR], [CE-based]) have paid very little attention to
describing how the proposed approach fulfills the QoS requirements.
This document explores different points of view, describes
dependencies and orthogonalities, and details a number of solutions
and guidelines.
Table of Contents
De Clercq Expires August 2003 [Page 1]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
0. Sub-IP Area Section ......................................... 2
1. Introduction ................................................ 3
2. Potential QoS-related issues with L3 PPVPNs ................. 4
2.1 Default use of LDP-DU and LSP merge ......................... 4
2.2 Default use of one PE-PE tunnel for all QoS classes and for
all VPNs .................................................... 6
2.3 Use of Penultimate Hop Popping (PHP) ........................ 8
2.4 BGP Signalling .............................................. 9
2.5 PPVPNs in non-MPLS networks ................................. 11
3. Example ..................................................... 12
3.1 QoS pre-provisioning of SP's network ........................ 12
3.2 VPN SLS and Configuration of QoS-enabled L3 PPVPN ........... 12
3.3 Adding a VPN site ........................................... 13
4. Conclusion .................................................. 13
5. Acknowledgements ............................................ 14
6. References .................................................. 14
7. Authors' Addresses .......................................... 14
0. SubIP-Area Section
SUMMARY
This document acknowledges the fact that QoS is a very important part
of a VPN service, and demonstrates that for L3 VPNs, offering QoS to
the VPN customers may be seen as a rather orthogonal issue from
building the VPN topology and managing the connectivity.
Nevertheless, some potential issues are discussed and possible
solutions or prefered practices are identified. It is explained how
to make advantage of the MPLS-DiffServ mechanisms to differentiate
between customers and traffic classes (including level of traffic
protection). It is also explained that establishing VR-to-VR non-
multiplexed core LSPs is nor scalable nor necessary. In addition, the
impact of the possible use of PHP is identified and the prefered way
to handle this is explained. Finally, we state that the use of BGP to
signal intra-domain per-VPN QoS parameters is not useful.
RELATED DOCUMENTS
See References section (especially [PPVPN-REQ], [2547bis], [VR]).
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
PPVPN box.
WHY IS IT TARGETED AT THIS WG
This document discusses PPVPN-specific QoS matters.
De Clercq Expires August 2003 [Page 2]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
JUSTIFICATION
QoS is identified as a very important requirement for L3 PPVPNs (see
for example [PPVPN-REQ]), while the proposed L3 PPVPN solution
documents have paid very little attention to describing how the
proposed approach fulfills the QoS requirements.
1. Introduction
Although QoS is identified as a very important requirement for L3
PPVPNs (see for example [PPVPN-REQ]), the proposed L3 PPVPN solutions
([2547bis], [VR], [CE-based]) have paid very little attention to
describing how the proposed approach fulfills the QoS requirements.
There are a number of possible explanations for this apparent
contradiction: (i) provisioning an IP VPN over a shared backbone on
one hand and offering Differentiated treatment and QoS guarantees to
traffic flows over a SP's backbone on the other hand are orthogonal
issues (this would mean that SP's offering VPN services using the
approaches defined in the PPVPN WG can add QoS assurances to these
VPNs using QoS mechanisms defined elsewhere), (ii) the VPN solutions
have focussed on providing restricted connectivity first and will
elaborate on the QoS issue later, (iii) the discussed solutions do
not acknowledge QoS as an important requirement for VPNs and are
happy with a solution for Best Effort VPNs. This document assumes (i)
or (ii) is applicable and explores different points of view,
describes dependencies and orthogonalities, and details a number of
solutions.
When QoS guarantees are offered as a service to VPN customers, the
details of this offering are described in the SLS between the SP and
the VPN customer (the Service Level Specification is the technical
part of the Service Level Agreement). Such an SLS will describe the
QoS guarantees (in terms of bandwidth, delay, jitter, drop
probability, etc.) and the availability/survivability guarantees of a
VPN customer's various types of traffic. As a VPN consists of a set
of sites attached to a SP's core network, a VPN SLS is often
described as a collection of pipe and/or hose service specifications.
On one hand, VPNs segregate the traffic of different customers (this
means for example that the behaviour of one VPN customer must not
affect the traffic of other VPN customers served by the same SP
backbone), and on the other hand, QoS/CoS segregates the different
types of traffic travelling over a network as to treat them
appropriately. And of course, one VPN customer may send different
types of traffic. Important to note is that, as SLSs are VPN
customer-specific, the same type of traffic belonging to different
VPN customers may need to be treated differently in the SP's core
network (both with regards to QoS and availability/survivability).
De Clercq Expires August 2003 [Page 3]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
This means that the traffic class (a traffic class contains all the
traffic from a certain network portion that will be QoS/CoS treated
identically in that specific portion of the network) of a specific
packet in the SP's core network is a function of (i) the traffic
class of a packet in the customer's network and (ii) the VPN the
packet belongs to.
Instantiating a pipe or hose SLS in a provider's core network
requires specific provisioning of some network elements and possibly
specific QoS-signalling in the core network. One important question
is whether these QoS provisioning actions are "compatible" with the
VPN provisioning and auto-discovery mechanisms. Indeed, the current
L3 PPVPN approaches have been designed as to optimize scalability (in
usage of core network resources (e.g. "no per-VPN state in the
core"), in provisioning burden (e.g. "VPN membership auto-
discovery"), etc.). So the question is whether the provisioning of
QoS parameters (dictated by the SLS), that is often a task that is
distributed over multiple network elements, can be optimized as to
fit within the scalable local VPN provisioning tasks.
A last initial consideration is that the default VPN signalling used
by the SP is a point-to-multipoint signalling that has a per VPN-
route granularity (or per set of destination addresses) in [2547bis].
This in contradiction to QoS signalling that typically is a point-
to-point signalling with a per-flow (or per-aggregate flows - type of
traffic) granularity.
Section 2 of this document discusses several "potential QoS-related
issues with L3 PPVPNs": the goal is to identify which issues can be
solved using (or combining) existing mechanisms, which issues have
been raised but are irrelevant and which issues could benefit from
the definition of additional protocol extensions or specifications.
Section 3 gives an example of the provisioning and operation of a
QoS-enabled L3 PPVPN. Section 4 gives an overall conclusion.
2. Potential QoS-related issues with L3 PPVPNs
2.1 Default use of LDP-DU and LSP merge
o description
MPLS-based VPNs (e.g. [2547bis])use a two-label stack to forward
packets accross the SP's backbone. The specification assumes that
every PE knows which 'outer' label to push on data packets to make
them reach a particular egress PE, identified by its /32 "BGP NEXT
HOP". There is no requirement on how this PE-to-PE "tunnel LSP" is
established. In order to improve interoperability, the
specification states that every router MUST support LDP. Using
De Clercq Expires August 2003 [Page 4]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
LDP, the distribution of each router's /32 address into the core's
IGP automatically results in the establishment of a full mesh of
LSPs between PE devices (1 single LSP per direction between each
pair of PE devices). Where applicable, these LSPs will be merged
as to preserve the routers' label space as much as possible.
In many aspects, an LDP-signalled MPLS core network behaves like
an IP-forwarded core network. This is the case too for the QoS
aspects: RFC3270 explains how to make an MPLS network DiffServ-
aware. Although differentiated treatment of different classes of
service is possible, LDP doesn't allow to explicitly signal
bandwidth reservations, to establish traffic engineered paths or
to establish multiple paths between the same destination with
different levels of protection.
o solution
As was mentioned before, there is no requirement on the way the
PE-PE LSPs are established: the routers must support LDP but may
use e.g. RSVP-TE to establish traffic engineered LSPs with certain
signalled bandwidth guarantees. In addition, nothing precludes a
SP to establish more than one LSP per pair of PE devices (for a
certain direction), and let the ingress decide which tunnel to use
on a per-packet basis. Other architectures that use a traffic-
engineered core in addition to a LDP-signalled scalable MPLS edge
can prove to be very usefull too. Alternatively, in an
intelligently over-provisioned network with under-utilized links
(possibly using DiffServ for service differentiation), the overall
performance of an LDP-established mesh may be high enough as to
satisfy every customer's SLS.
o impact
Using traffic engineered/bandwidth guaranteed (RSVP-TE) LSPs from
PE to PE instead of a full mesh of automatically established LDP
LSPs results in a higher label consumption, an increase of the
state maintained in the network elements and an increase of the
signalling load for the SP's routers. Also the management burden
may likely increase. These implications are orthogonal to the fact
that MPLS VPNs is the service transported by the MPLS network, and
has as such no impact on the VPN specification (e.g. [2547bis]).
o conclusion
By offering PPVPNs based on MPLS VPN approaches, a SP has the
complete freedom to use the range of capabilities of the
underlying MPLS network. BGP/MPLS VPNs need PE-to-PE tunnels.
These tunnels may be automatically established using LDP (and
De Clercq Expires August 2003 [Page 5]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
eventually enhanced with DiffServ capabilities [3270]), or
alternatively using RSVP-TE. The latter approach allows the SP to
take advantage of the available traffic engineering, bandwidth
reservation signalling and dedicated protection capabilities of
RSVP-TE established LSPs.
2.2 Default use of one PE-PE tunnel for all QoS classes and for all VPNs
o description
In BGP/MPLS VPNs, VPN routes are distributed among PE devices
using BGP. The BGP Route Target attribute identifies which VPN the
routes belong to; the MPLS label carried with the routes in the
BGP updates is the 'inner label' to be used for packets sent on
these announced routes, and the BGP NEXT_HOP attribute identifies
the egress PE for these routes.
In the forwarding plane, when a site sends a packet to its
attached PE, an IP destination address look-up in the associated
VRF results in a 'inner label' and a NEXT_HOP address. Based on
this NEXT_HOP address, the tunnel LSP to send the packet on is
identified. As such, in the most simple and default
implementation, the NEXT_HOP address uniquely identifies a PE to
PE LSP. As such, all packets destined for destinations advertised
by the egress PE will be sent on a particular LSP, independent of
the VPN the packets belong to and independent of the class of
service associated with the packets. This means that all traffic
from all VPNs would be treated and protected equally. With one
single LSP between two PEs, even when this LSP is associated with
certain reserved resources, when congestion occurs, all traffic
classes of all VPNs will be affected in a non-deterministic way.
o solution
(A) In order to accomplish a differentiated treatment, RFC 3270
can be used: the PE-PE LSPs can be E-LSPs (one LSP carries traffic
from a set of BAs) or L-LSPs (one LSP carries traffic belonging to
one PSC), with or without bandwidth reservations. Upon congestion,
differentiated treatment for different classes of traffic will be
applied. Using RFC3270, it is also possible (using multiple L-LSPs
between a couple of PEs) to give different survivability
assurances to different DiffServ classes.
Using DiffServ E-LSPs and L-LSPs, possibly associated with
explicit bandwidth reservations and specific protection
characteristics per LSP, a SP can guarantee different specific
levels of service for different classes of traffic between any two
PE devices. In order to optimize the scalability of the
De Clercq Expires August 2003 [Page 6]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
architecture, it is of prime import to aggregate the traffic
belonging to the same class of service and that is associated with
the same survivability guarantees.
Note that this class of service (and survivability class) is the
class to which the packets are associated within the SP's core
network.
The SLS of every customer describes which treatment (service
guarantees) will be associated with which traffic types. This is
VPN-dependent: the same traffic type (e.g. with the same DSCP, or
from the same application), belonging to different VPNs, may be
associated with different service guarantees in the SP's core. As
such, data packets that will be carried by the SP's network will
be associated with a specific SP's traffic class, depending on (i)
the VPN they belong to and (ii) the packet's "traffic type". The
packet's traffic type may be identified by it's DSCP or
alternatively by a combination of other fields (e.g. source and
destination IP addresses, protocol, port numbers etc.). This means
that, as an extreme example, based on the specifics of the
considered SLSs, the 'gold' traffic of VPN-blue can be associated
with the same SP's traffic class as the 'best effort' traffic from
VPN-red.
So the result is one ("traffic type"[in the context of one VPN] =>
"traffic class in the SP's network") translation table per VPN. In
addition there will be one (<"traffic class in the SP's network",
BGP NEXT_HOP> => <"outer MPLS label", EXP-bit setting, outgoing
interface>) table per PE device. In the data forwarding plane,
this means that, processing of a VPN packet in a VRF sent by a
directly attached customer site will result in the identification
of (i) 'inner label', (ii) BGP NEXT_HOP and (iii) "traffic class
in the SP's network". Resolving the BGP NEXT_HOP and "traffic
class in the SP's network" information will uniquely identify the
'tunnel label' to use and the setting of the EXP bits in that
outer label.
(B) An alternative way to differentiate traffic from different
VPNs is to establish end-to-end bandwidth guaranteed VRF-to-VRF
hop-by-hop LSPs. This would result in a one-label MPLS stack in
the core network and is obviously a non-scalable solution.
o impact
The impact of using the approach described in (A) is that PE
devices need to be able to implement different policies for
mapping packets into traffic classes, depending on the VPN the
packets belong to. The enforcement of customer SLSs implies the
De Clercq Expires August 2003 [Page 7]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
ability to establish per-VRF policers, shapers and markers in the
PE device. There is no impact on the BGP/MPLS VPN or VR-based VPN
specification.
The impact of implementing something according to (B) is
important: the scalability would drastically decrease (a very
large amount of LSPs to maintain, the distribution of /32
addresses per VRF, etc.). This method contrasts with the
separation of the "tunneling architecture" vs the "VPN
architecture" as used by e.g. BGP/MPLS VPNs. As such (B) is not
compatible with [2547bis], while it could be implemented in the
[VR] framework.
o conclusion
By implementing differentiated treatment for a set of specified
traffic classes in the SP's core network (using RFC3270 and/or
using traffic engineered LSPs and/or using explicitely reserved
bandwidth guarantees per LSP and/or using different protection
rules for different LSPs between the same couple of PEs), and by
defining VPN-dependent mappings for packets into these traffic
classes (according to the VPN SLSs), a SP has all necessary
freedom to fully support VPN- and traffic-dependent QoS
guarantees.
2.3 Use of Penultimate Hop Popping (PHP)
o description
The use of PHP has implications on the way a DiffServ-aware MPLS
network operates (see [3270]). Application of the "pipe model",
that is intuitively the most appropriate model for a PPVPN
service, is not possible. By applying the "pipe model" on the LSP
(PE-to-PE) tunnel, the core network's DiffServ information would
be lost at the egress PE in case of PHP.
o solution
As explained in [3270], the use of the "tunneling model" (pipe,
short pipe or unified model) is configurable on a per "nested LSP"
level: the DiffServ treatment of every label in the MPLS label
stack can be according to a different "tunneling model". An
important requirement for PPVPNs is that the VPN packet's eventual
QoS marking (DSCP) can be transported transparantly over the SP's
backbone.
For a specific PE-to-PE LSP, if PHP is not used:
De Clercq Expires August 2003 [Page 8]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
- the "tunnel LSP" is allowed to operate in the "pipe model".
In this scenario, the DiffServ treatment of the "inner label"
may be ignored. Use of the EXP-bits of the "inner label" is
TBD.
- the "tunnel LSP" is allowed to operate in the "unified
model". In this scenario, the "inner label" must operate in the
"pipe model".
- the "tunnel LSP" is allowed to operate in the "short pipe
model". In this scenario, the "inner label" must operate in the
"pipe model".
For a specific PE-to-PE LSP, if PHP is used:
- the "tunnel LSP" is NOT allowed to operate in the "pipe
model", because the impact of the forwarding of the packet
through the SP's network on the packet's DiffServ information
would be lost at the penultimate hop and unusable to the egress
PE.
- the "tunnel LSP" is allowed to operate in the "unified
model". In this scenario, the "inner label" must operate in the
"pipe model".
- the "tunnel LSP" is allowed to operate in the "short pipe
model". In this scenario, the "inner label" must operate in the
"pipe model".
o conclusion
The SP should make consistent choices with regards to the use of
PHP and the use of the different "DiffServ tunneling models" at
each depth of the MPLS label stack.
2.4 BGP Signalling
o description
In PE-based PPVPNs ([2547bis],[VR]), the addition of one new site
to an existing VPN requires only local configuration at the PE to
which the new site will be attached. The other PEs that serve the
same VPN will auto-discover the presence of a new VPN site. This
auto-discovery is BGP-based. On the other hand, the addition of a
new VPN site that is associated with a guaranteed SLS will require
the provisioning of QoS-specific attributes at the directly
attached PE, but eventually also at other PEs. This would then
compromize the "auto-discovery" mechanism and the "local
De Clercq Expires August 2003 [Page 9]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
provisioning only"-paradigm.
o solution and impact
In many situations, the addition of a VPN site with QoS guarantees
will not require provisioning of other PE devices than the one to
which the site is to be directly attached.
Indeed, this is the case for the addition of a VPN site
- that is associated with a hose (+funnel) SLS that doesn't
contrast with the SLSs of the other existing sites in the same VPN
(meaning that these SLS's don't need to be re-defined),
- whose SLS guarantees (for the different types of traffic) can be
assured by the SP's core network without re-provisioning of
resources (as it "fits" within the pre-provisioned QoS trunks in
the network; as identified e.g. by an admission control procedure
on an aggregate level)
Such a scenario can be assured by intelligent planning and network
(pre-)provisioning.
In some situations, the addition of one VPN site with QoS
guarantees will require provisioning of other PE devices than the
one to which the site is to be directly attached. For example, the
addition of a new VPN site that is associated with a pipe SLS
towards a particular other site will often require the
provisioning of specific traffic conditioners at both the local PE
and the peer PE. In some situations, where this exercice of
distributed provisioning is a non-frequent task and/or only
involves a restricted number of PEs, this is acceptable, in other
situations this can translate to a large management burden for the
SP.
Intelligent network planning and pre-provisioning, combined with
the definition of appropriate SLSs looks like the preferred
approach. Alternatively, signalling could be used in order to
dynamically communicate the QoS characteristics of the inter-site
VPN traffic.
Although BGP has become the default inter-PE VPN signalling
protocol, it is not a good candidate to perform the discussed QoS
signalling for a number of reasons:
- (I-)BGP is a point-to-multipoint routing protocol: this means
that all the peer PEs attached to a certain VPN will receive the
same information; signalling QoS characteristics with such a
De Clercq Expires August 2003 [Page 10]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
mechanism would only be effective when the QoS parameters for all
pairs <existing VPN site (i), new VPN site> would be identical for
a specific VPN. As this only covers a small subset of the possible
deployments, such a mechanism would not be very useful.
- BGP signalling as used for VPNs has a per-route [2547bis] or a
per-VR [VR] granularity. Adding QoS parameters to 2547bis-like BGP
signalling would mean sending the QoS information with every
exchange of reachability information, which is not efficient;
adding QoS parameters to VR-like BGP signalling would apply on a
VR-to-VR scope while different sites may be connected to the same
VR and it is probable for customer SLSs to be defined on the
granularity of site-to-site rather than VR-to-VR. In addition, BGP
has no affinity with QoS signalling: the definition of the
necessary extensions would require serious standardization
efforts, and the interaction between a router's BGP process and
the provisioning of signalled QoS attributes would need to be
studied.
An alternative solution would be to not to couple the VPN
(topology and membership) signalling with an eventual QoS
signalling. This would mean signalling VPN QoS characteristics
(with e.g. RSVP) within the VPN, after the VPN topology has been
created/discovered with the known VPN BGP mechanisms.
o conclusion
Intelligent network planning and pre-provisioning, combined with
the definition of appropriate SLSs looks like the preferred
approach. Using hose and funnel SLSs for IP VPNs looks like a
natural fit, and eases the SP's provisioning tasks. The
provisioning of QoS parameters associated with "pipe SLSs" is a
feasible task in 'stable' environments (where additions of new
sites is a non-frequent task).
Signalling QoS attributes using the VPN BGP-based auto-discovery
mechanisms does not seem appropriate.
2.5 PPVPNs in non-MPLS networks
o description
[2547-IP-GRE] describes how to deploy BGP/MPLS VPNs in a non-MPLS
network, and [VR] does the same for VR-based VPNs. In both
approaches, forwarding in the SP's core network is based on the IP
addresses of the packets' "outer IP header". In such a deployment,
the SP cannot take advantage of MPLS-specific features such as
MPLS traffic engineering, fast protection and restauration
De Clercq Expires August 2003 [Page 11]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
mechanisms. On the other hand, many SPs may want to offer QoS VPNs
over a non-MPLS, pure IP network.
o solution
A SP offering VPN services can provision and operate its IP
backbone network in the same way as he does for other services
that are associated with strict SLSs (e.g. by intelligent network
dimensioning, traffic conditioning at the network edges and using
DiffServ in the core network). The SP's IGP and lower layer
technology will take care of routing traffic around network
failures (the eventual disruption of user service should be taken
into account in the SLS).
The SP can use an approach such as described in section 2.2 for
the mapping of user-defined traffic class to the traffic classes
used in the SP's core. There is no such concept as PHP in an IP-
tunneling environment (section 2.3).
The same remarks for VPN signalling as described in section 2.4
apply for VPN services over non-MPLS core networks.
3. Example
3.1 QoS pre-provisioning of SP's network
In a first phase, the SP will define the QoS classes and the
protection levels to be used in its core network, independently of
any customer SLS, and provision its routers, and define the PHBs and
eventually establish the tunnel LSPs. For example the SP may choose
to create a DiffServ-aware LDP-DU established LSP mesh to carry the
(i) Best Effort, the (ii) low packet loss and the (iii) low delay and
jitter classes, and in addition to that to establish traffic-
engineered and protected RSVP-TE LSPs to carry the (iv) high
availability and 'very strict SLS' traffic. The SP will also
provision traffic conditioners at the network edges for the non-VPN
traffic.
3.2 VPN SLS and Configuration of QoS-enabled L3 PPVPN
An SLS will be defined when a new customer is added to the SP's
network. This SLS will be based on customer input and finalized after
negotiation with the SP. Before accepting the SLS, the SP will
control wether its core network is able to support the described SLS
without compromising the other services that the network currently
supports (e.g. without introducing congestion that would affect
priority traffic). If this is not the case, the SP may want to re-
dimension its network or reject the customer's request.
De Clercq Expires August 2003 [Page 12]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
If the SLS is finally accepted, the SP will configure the VRFs in the
affected PE routers (e.g. access connections, Route Target
attributes, Route Distinguishers) and provision the QoS parameters
(e.g. traffic conditioners in the PEs) according to the SLS. More
precicely, the SP will define mappings between the customer's packets
traffic types and the traffic classes it has defined in its core
network ((i), .., (iv)), and then provision policers for these
classes according to the agreed SLS. Every PE to which a new site is
to be attached, is to be provisioned.
3.3 Adding a site
Assume that at a later point in time, the VPN customer decides to add
a new site to its VPN. After negotiation, an SLS will be associated
with this new site. The SP will again control wether its network can
support the SLS (possibly after re-dimensioning and provisioning)
before accepting it.
If the SLS is accepted, the SP will configure the necessary
parameters (access connections, possibly RD, RT, etc.) at the PE to
which the new site is to be attached, define the mappings and
provision the local QoS parameters (traffic conditioners at that
particular PE).
If the SLS is such that no QoS provisioning at peering PEs is
necessary (e.g. a compatible hose SLS), than the provisioning effort
is done and remains a purely local effort. Alternatively, while the
auto-discovery mechanism will make sure the other PEs will discover
the new site, re-provisioning of QoS parameters at the other PEs
might be necessary (e.g. for the addition of a guaranteed QoS pipe to
a VPN).
4. Conclusion
This document acknowledges the fact that QoS is a very important part
of a VPN service, and demonstrates that for L3 VPNs, offering QoS to
the VPN customers may be seen as a rather orthogonal issue from
building the VPN topology and managing the connectivity.
Nevertheless, some potential issues are discussed and possible
solutions or prefered practices are identified. It is explained how
to make advantage of the (MPLS-)DiffServ mechanisms to differentiate
between customers and traffic classes (including level of traffic
protection). It is also explained that establishing VR-to-VR non-
multiplexed core LSPs is nor scalable nor necessary. In addition, the
impact of the possible use of PHP is identified and the prefered way
to handle this is explained. Finally, we state that the use of BGP to
signal intra-domain per-L3VPN QoS parameters is not useful.
De Clercq Expires August 2003 [Page 13]
Internet Draft draft-declercq-ppvpn-l3vpn-qos-00.txt February 2003
5. Acknowledgements
The author would like to thank the following persons for their
valuable contributions to this document: Mustapha Aissaoui, Sven Van
Den Bosch, Arnold Jansen.
6. References
[CE-based] De Clercq, J. et al., "An Architecture for Provider
Provisioned CE-based VPNs using IPsec", Work in Progress
[FRAMEWORK] Callon, R. et al., "A Framework for Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn-framework-0x.txt, Work in
progress
[PPVPN-REQ] Carugi, M., McDysan, D., "Service Requirements for
Layer-3 Provider Provisioned VPNs", draft-ietf-ppvpn-requirements,
Work in Progress
[VR] Knight, P., et al., "Network-Based IP VPN Architecture using
Virtual Routers", Work in Progress
[2547bis] Rosen, E., et al., "BGP/MPLS VPNs", Work in Progress
7. Authors' Addresses
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: jeremy.de_clercq@alcatel.be
De Clercq Expires August 2003 [Page 14]
