Internet DRAFT - draft-defeng-l3vpn-qos-crc
draft-defeng-l3vpn-qos-crc
Internet Draft Document Defeng Li
L3 VPN Working Group Huawei Technologies
draft-defeng-l3vpn-qos-crc-01.txt
Expires: August 2004 February 2004
QoS-guaranteed MPLS-based NBVPN with centralized resource controller
draft-defeng-l3vpn-qos-crc-01.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
This document focuses on the QoS problem in NBVPN, analyses the QoS
requirement for NBVPN, the insufficiency of QoS guarantee in the
current NBVPN schemes in the related IETF work group, and proposes
a QoS-guaranteed NBVPN reference model with centralized resource
controller, in this model, some new concepts are introduced,
such as VPN Logical Bearer Network(VPN-LBN), VPN Centralized
resource controller(VPN-CRC); and mechanism of guaranteeing the VPN
QoS is explained in details, including address space, isolation
between VPNs, VPN route distribution, forwarding, interface
requirement signaling requirement, hybrid QoS-VPN, intra-domain VPN,
inter-domain VPN.
3. Conventions
Defeng Li. [Page 1]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
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
JUSTIFICATION
As an important application, several kinds of NBVPN (L2/L3) have
been proposed in the industry, and MPLS technology has gained its
popularization in these NBVPN mechanisms, compared with ATM/FR/DDN
leased line, the resources of different NBVPNs accessed to the same
set of PEs are shared through multiplexing the outer label in MPLS
label stack. Though the resource of the outer tunnel can be
guaranteed in theory by deploying DiffServ Aware Traffic Engineering
(DS-Aware TE) or other similar mechanism, in their reference models,
there are no network element in individual VPN having the awareness
of the whole resource status in the backbone, owing to the
competition of the resources at every node between several VPNs and
the ignorance of the whole resource status in the backbone, it is
difficult to guarantee the resource for every VPN individually,
this share-and-competition mechanism introduced more complexity
in assurance of quality of service for VPN.
In [draft-martini-l2circuit-trans-mpls-10.txt],
[draft-martini-l2circuit-encap-mpls-04.txt], which are the basis of
the L2VPN, as to QoS problem, "QoS related issues are not discussed
in this draft" are stated in both drafts, and in
[draft-ietf-l3vpn-rfc2547bis-01.txt], which is basis of BGP/MPLS VPN,
it stated that "existing L3 QoS capabilities can be applied to
labeled packets through the use of the "experimental" bits in the
shim header", but it is embarrassed that existing L3 QoS is
intractable open problem. In other words, QoS problem in L2VPN/L3VPN
reference model is far from resolved.
Table of Contents
1. Status of this Memo.............................................1
2. Abstract........................................................1
3. Conventions.....................................................1
4. Definition .....................................................3
5. Mechanism ......................................................4
5.1. Key Points...................................................5
5.2. Architecture of Reference Model..............................6
5.3. VPN Logical Bearer Network(VPN-LBN) partition................7
5.4. VPN Centralized Resources Controller (VPN-CRC)...............8
Defeng Li. [Page 2]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
5.5. Provider Edge(PE)...........................................10
5.6. Intermediate Transit Router and Core Router.................10
5.7. Address Space...............................................10
5.8. Isolation between QoS-VPNs..................................11
5.9. Routing.....................................................11
5.10. Forwarding.................................................11
5.11. QoS-VPN Topology...........................................11
6. Interfaces and Protocols Requirements.........................12
6.1. Interface/protocol between CE and PE........................12
6.2. Interface/Protocol between VPN-CRC and PE/ITR/CR............13
6.3. Interface/Protocol between VPN-CRCs.........................13
7. Hybrid QoS-VPN ...............................................15
8. Intra-domain QoS-VPN and inter-domain QoS-VPN.................15
9. QoS-VPN across different network providers....................16
10. Security Consideration .......................................16
11. Full Copyright Statement......................................16
12. References....................................................17
13. Authors' Addresses...........................................17
4. Definition
QoS-VPN:
VPN with QoS requirements (limits of bandwidth, delay, jitter, packet
loss) between two or more of its sites, for the VPN in which some
sites have QoS requirements, and other sites have no QoS requirements,
it can be called hybrid QoS-VPN.
VPN-LBN:
The set of the resources planned in advance and singled out from the
underlying IP network by connecting a part of network element(
including PEs, ITRs, CRs) with LSP to exclusively bear QoS-VPN
services, it is an overlay logical bearer network.
VPN-CRC:
The centralized entity in a domain which is responsible for
intra-domain resource calculation, path selection, admission control,
and inter-domain services request, network topology, QoS-VPN
membership and visiting relationship information maintenance and
auto-discovery, signalling, and so on. Normally it is decoupled
with the forwarding network elements such as PE, ITR, CR.
ITR:
The provider routers apart from PE and at the border of a domain
which participate in the partition of VPN-LBN, which is connected
with CR or PE through LSP, ITR should be an LSR.
CR:
Defeng Li. [Page 3]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
The provider routers at the core of a domain which participate in
the partition of VPN-LBN, which is connected with ITR or PE through
LSP, CR should be an LSR.
VPN-ID:
The globally unique parameter in VPN-LBN to identify the
information of different QoS-VPN in PE and VPN-CRC.
Site-ID:
The unique parameter in the QoS-VPN scope to identify the different
sites.
QoS-path information table:
The information table maintained in PE, consists QoS-path
information for the local site (directly connected with PE) to the
remote sites with QoS requirements in the same QoS-VPN, this table
is two-leveled, first level is indexed with VPN-ID, the second
level is indexed with the local site ID and the remote site ID,
for every couple of local site and remote site, the contents in the
QoS-path information table is the MPLS label stack instructed by
VPN-CRC to denote the concatenated LSP through which QoS
requirements of services from local site to remote site can be
guaranteed. In addition, the VPN addresses (VPN-ID + private
addresses belong to the respective VPN) are attached to every
remote site ID, these VPN addressed are used to decide whether
admit the specific service flow from the local site to the remote
site.
QoS-VPN membership information table:
The information table maintained in VPN-CRC, consists of the
members of the same QoS-VPN, this table is indexed with VPN-ID.
QoS-VPN visiting relationship information table: The information
table maintained in VPN?CRC, consists of the visiting relationships
among the members of QoS-VPN, i.e. which site can visit other
sites, this table can derive from the membership information table
and Route Targets of the sites. This table is on the basis of per
QoS-VPN, and indexed with VPN-ID. If the export Route Target of a
site is identical to the import Route Target of the other site in
the same QoS-VPN, then these two sites have visiting relationship.
5. Mechanism
I propose to modify the architecture of the VPN reference model,
introduce some concepts, such as VPN Logical Bearer Network
(VPN-LBN), which is pre-provisioned through MPLS technology by
Defeng Li. [Page 4]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
singling out part of resources in the underlying IP network for
QoS-VPN to use exclusively, add some controlling elements to the
current VPN reference model, such as VPN Centralized resource
controller(VPN-CRC) maintaining the topology and resource table
separately for VPN-LBN and membership information and visiting
relationship information per QoS-VPN.
5.1. Key Points
(1) The NBVPN service requiring QoS guarantee is categorized as a
particular service class, temporarily called QoS-VPN service, and
such NBVPN is called QoS-VPN. Network operator should identify
these QoS-VPNs before accessing them, the simplest way (of course
not limited to it) is to identify the interface or sub-interface
accessing VPN sites with QoS requirements at PE and services from
these interface (sub-interface) are sorted as QoS-VPN service, and
network operator needs to plan the capacity of QoS-VPN service
including topology, path, bandwidth, etc, for QoS-VPN service to
use exclusively, considering the current and forecasted QoS-VPN
traffic.
(2) According to the results of capacity planning, MPLS technology
is deployed to pre-provision a logical bearer network (LBN) for
QoS-VPN service to use exclusively over the underlying IP network
by LSP configuration with resource reservation. And this LBN is
called VPN-LBN, it is an overlay logical network. For service flows
belonging to QoS?VPN service, the path selection, resource
allocation, admission control and label forwarding are handled only
within VPN-LBN. The service traffic of VPNs without QoS
requirements are still routed and forwarded according to the
existing VPN mechanisms within the un-pre-provisioned resources of
the underlying IP network.
(3) A centralized resource controller in every domain of the
VPN-LBN is deployed to maintain the topology and resource table
separately for VPN-LBN, and this function entity is temporarily
called VPN-CRC, normally, it is decoupled with the data plane
network elements. VPN-CRC is responsible for resource calculation,
admission control, resource allocation, path selection between VPN
sites, and instructs the MPLS label stack (signifies the selected
path, i.e. the concatenated LSP through which QoS requirements can
be met), and it maintains the membership information and visiting
relationship information and processed the necessary signaling at
per QoS-VPN level.
(4) MPLS TE technology can be deployed to dynamically adjust
Defeng Li. [Page 5]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
VPN-LBN topology and bandwidth for LSP protection or capacity
changes of VPN-LBN.
(5) In every QoS-VPN, though the paths of all its traffic between
two sites are all the same, the service traffic can be categorized
into different classes, such as voice, video, data, traffic class
can be identified and marked with different priority at ingress PE,
when these traffic classed with different priorities are
encapsulated in MPLS packets at PE, mapping the priority to EXP
bits of all the labels in the label stack(instructed by VPN-CRC) is
performed (this is done for the reason that in the case of POP the
outer label, the pen?outmost label has the same EXP bits, which can
guarantee the same forwarding priority under the MPLS-DiffServ
mechanism), thus after VPN-CRC decided the path and guaranteed the
bandwidth for QoS-VPN between two sites, different classes of
traffic between these two sites can be forwarded with MPLS-DiffServ
mechanism, which can guarantee the time delay/jitter/packet loss
requirements for different traffic classes.
(6) For Hybrid QoS-VPN, it can be classified into two parts, one
part is composed of the sites with QoS requirements, this the
above-mentioned mechanism applies to this part, the other part is
composed of the remaining sites of VPN, which follows the existing
VPN mechanisms.
5.2. Architecture of Reference Model
The QoS-VPN architecture is divided into two layers: VPN bearer
layer, VPN bearer control layer.
VPN-LBN is pre-provisioned with MPLS technology by configuring the
bandwidth reserved LSPs, which connect the Provider Edge(PE), Core
Router(CR), Intermediate Router(ITR) according to the capacity
planning in advance, and VPN-LBN is composed of PE,CR,ITR and the
LSPs.
VPN bearer control layer consists of VPN-CRCs, one for each VPN
domain (temporarily without considering the VPN-CRC backup).
VPN-CRC manages the network resources (including bandwidth,
processor, and buffer) of VPN-LBN and maintains the VPN-LBN network
topology, performs path selection and then sends path information
instruction to PE, resource allocation, admission control within
VPN-LBN, and maintains the membership information table, visiting
relationship information table at per QoS-VPN level, and related
signalling to achieve the membership auto-discovery and
Defeng Li. [Page 6]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
single-sided provisioning.
5.3. VPN Logical Bearer Network(VPN-LBN) partition
To strictly ensure reliable transmission of the QoS-VPN network, it
is necessary to separate QoS?VPN traffic from the best effort
traffic (VPN service or internet service without QoS requirements)
on the resource allocation and routing aspect, so that the
resources of QoS-VPN are allocated within the pre-provisioned
VPN-LBN and explicit paths are selected by VPN-CRCs. Whereas, the
best effort VPN traffic are still routed and forwarded within the
remaining resource of the IP network following conventional VPN
mechanisms.
VPN-LBN consists of PE, ITR, CR and LSPs connecting these LSRs. The
LSP bandwidth and other QoS attributes are configured. The LSPs may
be statically configured or automatically set up with
RSVP-TE/CR-LDP according to capacity planning and traffic metering
data.
For LSP protection or capacity change, MPLS TE can be deployed to
dynamically adjust and maintain the VPN-LBN topology and bandwidth
by applying such as LSP fast reroute technology and etc.
When QoS-VPN services request from the local site to the remote
site is passed from ingress PE to VPN-CRC, the corresponding QoS
requirements will attached to the services request according to the
SLA between customer and provider, VPN-CRC(if necessary together
with other VPN-CRCs in the VPN Bearer Control layer) decides
whether to permit the request or not, If permits the request , it
computes the path which can guarantee the QoS requirements, and
sends the path information to the ingress PE. The path information
is the label stack represents the concatenated LSPs from ingress
PE(connected with the local site) to the egress PE(connected with
the remote site) within VPN-LBN, the ingress PE should record this
path information, including the QoS-VPN(through VPN-ID) and the
sites couple(through Site ID) , and all the services belong to this
QoS-VPN and sites couple will follow the same path unless the
ingress PE received the otherwise instruction.
Ingress PE identify QoS-VPN from the relevant information, say, the
interface(sub-interface),when a QoS-VPN service flow enters the
network, the ingress PE identifies its traffic from the flow
description information (generally including source address, source
port, destination address, destination port, and protocol type).
Defeng Li. [Page 7]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
And then it encapsulates the packet/frame with the label stack
instructed by VPN-CRC, sets the different EXP bits for all the
labels in the label stack for different data types (Voice/Video/
Data) following RFC 3270 and leads the packets into the VPN-LBN
When the traffic transits across the intermediate transit routers
£šITR£© along its path, these ITRs forward its packets with
DiffServ-aware MPLS technology .
5.4. VPN Centralized Resources Controller (VPN-CRC)
The VPN bearer control layer consists of VPN-CRCs in multiple VPN
domains. It serves as a control and management plane for VPN
logical bearer layer. A VPN-CRC should have such functions as
intra-domain resource calculation, path selection, admission
control, and inter-domain resource request, network topology,
QoS-VPN membership information maintenance, visiting relationship
information maintenance and auto-discovery, single-sided provision
signalling. In addition, a VPN-CRC may also support policy
management, SLA management, LSP traffic metering, and interface
with authentication servers (if necessary).
In the VPN-CRC, the topology and resource table of VPN-LBN are
recorded and maintained independently from that of the underlying
IP network. It means that VPN-LBN has an independent table on the
VPN-CRC. The initial resource data of VPN-LBN needs to be manually
configured by administrator according to its capacity planning
results.
A VPN-CRC receives services requests (include information such as
VPN ID, local site ID, export Route target of local site, remote
site ID, QoS requirements) from the ingress PE within its
administrative domain or the resource request from other VPN-CRC.
It performs resource calculation, path selection and admission
control (if necessary, pass the resource request to the downstream
VPN-CRC), if the admission response is "reject", sends it back to
ingress PE, otherwise, sends the path information to the ingress
PE, where setting the EXP of the MPLS labels according to the flow
description of the service flow from CE to PE. The QoS-VPN traffic
from this local site to the remote site is forwarded following the
computed path, and different types of traffic in the same direction
are distinguished from EXP of the outer label and forwarded
following the MPLS-DiffServ mechanism.
VPN-CRC needs to maintain the membership information for all the
QoS-VPNs in the VPN-LBN, this can be achieved through directory
Defeng Li. [Page 8]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
based mechanisms or other similar signalling among PEs and
VPN-CRCs. This signalling requirement is depicted in Section 6.
To maintain and transfer the visiting relationship information per
QoS-VPN, VPN-CRC needs to maintain the visiting relation between
QoS-VPN members, i.e. the topology of QoS-VPN sites, this can be
achieved by (of course not limited to) recording two site lists per
sites per QoS-VPN, an admissible outgoing site list and an
admissible incoming site list. To support auto-discovery of
modification to the membership and visiting relationship in
QoS-VPN, in case of the addition or removal of sites to a PE in
QoS-VPN, the related update message should transfer between PE and
VPN-CRC, then related VPN-CRC should update the membership
information table and visiting relationship information table. By
implementing this mechanism, the single-sided provisioning can be
achieved, i.e. in the case of QoS-VPN sites addition or removal,
only the configuration to the PE where the addition or removal of
sites happens, and in the case of modification to the visiting
relationship among the VPN members, only one side of the connection
to which the modification happens needs to be configured, and the
modification will automatically pass to all the related VPN?CRCs by
membership update message and visiting relationship update message,
And VPN?CRCs received the update message will update its membership
and visiting relationship information table.
In the case of addition of QoS-VPN sites, the services request
(include information such as VPN-ID, local site ID, export Route
target of local site, remote site ID, QoS requirements) will pass
to VPN?CRCs, VPN-CRCs will calculate the resources for the added
sites to visit the other sites as desired, if such QoS-VPN sites
addition is permitted, the paths as to the added sites visiting the
different remote sites will be calculated, then instructed the
paths to the related PEs, these PEs should update their QoS-path
information table, when the remote PEs aware the sites additions
through the single-sided provisioning signalling passed by VPN-CRC,
they should initiate the contra-direction services requests for
their local sites to visit the added new sites, then the same
process will be performed, at last, all the sites gets its QoS-path
information as to visiting each other.
In the case of removal, VPN-CRCs release the resources for the
paths relevant to the removed sites, besides update the membership
information table and visiting relationship information table, and
notify the related PEs to remove the related entries and items in
the QoS-path information table, when the remote PEs aware the sites
removals, the resources for the contra-direction between the
Defeng Li. [Page 9]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
related sites will be released by the related VPN-CRC, The protocol
requirement to achieve such single-sided provisioning is depicted
in Section 6.
5.5. Provider Edge(PE)
In this architecture, PE should support static LSP configuration or
dynamic LSP setup through CR?LDP or RSVP-TE in order to implement
the pre-provision and dynamic adjustment of VPN?LBN. In addition,
traffic classification should be supported in order to set the EXP
bits of the labels in the label stacks.
When receiving the admission control response from VPN-CRC, if the
response of resource calculation is "acceptance", the path and QoS
information should be included, the ingress PE creates an entry in
the QoS-path information table to record these information, ingress
PE maintains the entries on per QoS-VPN basis by the index of
VPN-ID, and in every QoS-VPN entry, keeps every item for the
service from a local site to a remote site of the same QoS-VPN.
According to the QoS-path information table and the traffic class,
Ingress PE performs policing, shaping, queuing, scheduling,
marking, and MPLS encapsulating(adding the MPLS label stack and
setting the EXP bits), then forwards packets to the downstream
routers within VPN-LBN.
5.6. Intermediate Transit Router and Core Router
In this architecture, Intermediate transit routers should support
static LSP configuration or dynamic LSP setup through CR-LDP or
RSVP-TE in order to implement the pre-provision and dynamic
adjustment of VPN-LBN. And they should support DiffServ-aware MPLS
in E-LSP or L-LSP mode and process the traffic at a per-class level.
Other core routers in the IP-based backbone network only need
supporting DiffServ-aware MPLS in E-LSP or L-LSP mode and process
the traffic at a per-class level.
5.7. Address Space
VPN address can be composed of globally unique VPN-ID in VPN-LBN
and L3/L2/L1 VPN specific private address, such as IPv4/IPv6/IPX
address (for L3 VPN)/data link address(for L2 VPN)/cross-connect
identifier(for L1 VPN) of VPN site for the particular VPN, in this
VPN address scheme, the addresses for sites in the different VPN
can be the overlapped, with the globally unique VPN-ID in VPN-LBN,
the combined VPN address will be unique globally in VPN-LBN.
Defeng Li. [Page 10]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
5.8. Isolation between QoS-VPNs
QoS-path information table is two-leveled, first level is indexed
with VPN-ID, and the second level is indexed with the site-ID, the
information between VPNs can be isolated by this way.
5.9. Routing
The QoS-VPN routing is maintained in the QoS-path information table
of PE, the granularity is at per QoS-VPN site couple, i.e., the
services from the same local QoS-VPN site to the same remote
QoS-VPN site have the same route. The route search is two leveled
at the ingress PE, at first level, VPN-ID is indexed and searched
in the entries for different QoS-VPN, at the second level, the
items for the local site and remote site couples in the same
QoS-VPN are searched. It should be noted that for every such item,
the aggregated addresses of the related site is attached, only the
destination address of the service flow matches to the aggregated
addresses, the second level search can be thought as success,
only after both levels search succeed, ingress PE can assign the
route information for this service flow, the route information is
the MPLS label stack instructed by VPN?CRC according the resource
status in VPN-LBN, if one of the two levels search fails, PE will
reject the service flow.
5.10. Forwarding
QoS-VPN forwarding is based on MPLS technology, with the MPLS label
stack instructed by VPN-CRC and EXP bits set by ingress PE for the
different service class, the LSR (including PE, ITR, CR) forwards
the packets based on the outer-most label, and the EXP bits
following the MPLS-DiffServ mechanism, with these information, the
bandwidth and forwarding priority can be ensured, then the QoS(such
as bandwidth, time delay, jitter, packet loss rate) for QoS-VPN can
be guaranteed.
5.11. QoS-VPN Topology
QoS-VPN visiting relationship information is maintained at VPN-CRC,
VPN-ID and Route Target can be used to create the visiting
relationship information table, VPN-ID is used as the index for
different QoS-VPN, Route Target is classified into import Route
Target and export Route Target, the former is used to filter
visiting relationship in the incoming direction, the latter is used
to filter visiting relationship in the outgoing direction, which is
Defeng Li. [Page 11]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
attached to the services request from one VPN site to the remote
VPN site, if the export route target and VPN-ID of the services
request egress PE received is the same with one of the import route
targets and VPN-ID for one of sites directly connected to this PE
respectively , the services request can be accepted, and record
this item in the visiting relationship information table for this
QoS-VPN, with the visiting relationship information table, the
topology of QoS-VPN sites can be achieved. Such as full-meshed,
hub-spoke or any other topology can be provided by such QoS-VPN
mechanism.
6. Interfaces and Protocols Requirements
In this architecture of QoS-guaranteed MPLS-based NBVPN with
centralized resource controller, the interfaces between PE and CE,
VPN-CRC and provider routers (including PE,ITR, CR), VPN?CRC and
VPN-CRC and the related protocols need be specified.
6.1. Interface/protocol between CE and PE
Interface between PE and CE is used to pass the customer
information such as topology, aggregated private address, e.g.
private IPv4/IPv6/IPX address (for L3 VPN)/data link address(for L2
VPN)/cross-connect identifier(for L1 VPN) of VPN site behind CE and
VPN service request (including flow description) to PE¡£
It is noted that for the privacy of address information (including
L1/L2/L3 address in the VPN sites) and consideration of address
overlap between different QoS-VPN, it is proposed that network
provider assign a network-wide unique VPN-ID for every QoS-VPN,
this VPN-ID is prefixed by PEs to these addresses received from
CEs, and the VPN address is derived, and this VPN-ID can be used as
the index to maintain the membership information table in VPN-CRC.
6.2. Interface/Protocol between VPN-CRC and PE/ITR/CR
Interface between VPN-CRC and PE is used to allow the VPN-CRC to
instruct PE to process the traffic at a per-site level.
It is necessary to specify a unique protocol for this interface.
COPS may be a good candidate protocol as the basis to be extended
for this architecture to use.
This protocol should support the following functions.
(1) Ingress PE sends the services request (include information such
Defeng Li. [Page 12]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
as VPN ID, local site ID, export Route target of local site, remote
site ID, QoS requirements) to VPN-CRC, QoS requirements of each
service classes include service type, bandwidth, priority, delay
limit, jitter limit, loss rate limit, MTU, etc. on per QoS-VPN site
basis according to the SLA between customers and provider.
(2) VPN-CRC checks whether there is the visiting relationship from
the local site to the remote site (thus VPN-CRC should transfer the
necessary information to the related VPN-CRCs and PEs), then decide
whether it is necessary to compute the path for this services
request, and informs the ingress PE the result of admission control
as to the QoS-VPN, no matter it is "rejection" or "acceptance".
(3) VPN-CRC informs the ingress PE the path information for this
site couple, when the result of admission control is "acceptance",
the path information is a label stack for a concatenated LSP, PE
creates an entry recording such path information on per site couple
and QoS-VPN basis in the QoS path information table.
(4) In case of the addition or removal of sites to a particular
QoS-VPN, or modification of the visiting relationship between these
VPN sites, PEs where the change happens (through configuration)
should send the update message to the connected VPN-CRC. VPN-CRC
passes this update message to the adjacent VPN-CRC(if necessary)
through the interface between these VPN-CRC(the interface and
protocol between VPN-CRCs is defined in section 6.3), and the
VPN-CRCs influenced should update the membership information table
and visiting relationship information table of the QoS-VPN.
(5) PE sends all the aggregated VPN addresses information to
VPN-CRC, and VPN-CRC distributes these VPN addresses to the related
VPN-CRCs or PEs according to the membership information table and
visiting relationship information table per QoS-VPN. These
functions can be achieved by extending the current BGP. At last,
all the PEs get the aggregated VPN addresses, recording them in the
QoS-path information table per QoS?VPN per remote site with
visiting relationship, when PE receives the VPN service flow, it
can decide whether to transfer it , and then select the path and
set the EXP bits of packets.
Moreover, the following two functions should be supported between
VPN-CRC and all intra?domain routers including provider edge
routers(PE), intermediate transit routers(ITR) and core routers(CR).
(1) Enable VPN-CRC to configure the DiffServ PHB on the router for
each QoS service classes.
Defeng Li. [Page 13]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
(2) Enable the routers (PE/ITR/CR) to report the LSP status such as
normal or failure, in case that link or router failure occurs to the
intermediate transit router and core router, this router should pass
the relevant failure to VPN-CRC in the same domain, this VPN-CRC
passes this failure to all the VPN-CRCs in VPN-LBN, these VPN-CRCs
recalculate the paths for the QoS-VPNs they have already served, if
some paths need be updated, VPN-CRC should send the new paths to
ingress PEs which VPN-CRC connected with. This belongs to MPLS OAM
mechanism, which is out of the scope of this document.
6.3. Interface/Protocol between VPN-CRCs
Interface between VPN-CRCs is used to implement the resource
allocation and path selection for services between inter-domain
QoS-VPN sites.
It is necessary to specify a unique protocol for this interface.
There are a number of candidate protocols that could be chosen,
such as COPS, BGP and so on.
This protocol must support the following functions.
(1) Enable VPN-CRC to request downstream VPN-CRC to allocate the
bearer resource for services between inter-domain QoS-VPN sites.
(2) Enable VPN-CRC to inform downstream VPN-CRC of the
identification information of services between inter-domain VPN
sites including the local site ID, the remote site ID, VPN-ID.
(3) Enable VPN-CRC to inform downstream VPN-CRC of the QoS
requirements of services between inter-domain VPN sites including
service type, bandwidth, priority, delay limit, jitter limit, loss
rate limit, MTU, etc .
(4) Enable VPN-CRC to request another VPN-CRC to release the
bearer resource allocated for services between inter-domain QoS-VPN
sites.
(5) Enable VPN-CRC to query another VPN-CRC of the resource
allocation status for services between inter-domain QoS-VPN sites.
(6) Enable VPN-CRC to inform another VPN-CRC of the responses of
the query.
(7) Enable VPN-CRC to exchange inter-domain SLS and route
Defeng Li. [Page 14]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
information with another VPN-CRC.
7. Hybrid QoS-VPN
In some cases, some sites of a VPN have QoS requirements, and other
sites have no QoS requirements, this VPN is called hybrid QoS-VPN,
hybrid QoS-VPN can be partitioned into two parts, one part is
composed of those sites which have QoS requirements, the other part
is composed of the remained sites which have no QoS requirements,
the former part formed a sub-QoS-VPN, whose QoS requirements can be
guaranteed following the mechanism specified above, the latter part
formed another sub-VPN, which follows the mechanism specified in
the related RFC or Drafts in IETF L3VPN/L2VPN WG and ITU-T
recommendations for L1VPN(Y.l1vpnarch and Y.l1vpnsdr).
Correspondingly, QoS Route Targets is introduced for the VPN-CRC to
maintain the visiting relationship information for the sub-QoS-VPN,
QoS Route Targets follows the same format with Route Targets, for
the services request from the sites with QoS requirements, after
Route Targets comparison passed, QoS Route Targets of the will be
compared following the same method, only both of them passed the
comparison, the visiting will be permitted for sub-QoS-VPN,
otherwise the services will classified into sub-VPN, which has no
QoS guarantee.
8. Intra-domain QoS-VPN and inter-domain QoS-VPN
Intra-domain QoS-VPN path selection and inter-domain routing are
the basis of resource management and admission control.
The VPN-CRC makes the intra-domain path selection through resource
calculation within the topology and resource table of VPN-CRC. The
path selection algorithms might be fixed, time?dependent or
state-dependent. It need further study and experiment in different
network environment.
Besides, the VPN-CRC should maintain an inter-domain routing table
that is only used to find out the neighbouring downstream VPN-CRC
for services destined to inter-domain sites. Then it negotiates
with the neighbouring downstream VPN-CRC through a QoS signalling
protocol to determine an inter-domain LSP.
The inter-domain routing table on VPN-CRC might be manually
configured or automatically generated through running a dynamic
routing protocol between VPN-CRCs such as E-BGP or others. It need
further study and experiment in different network environment.
Defeng Li. [Page 15]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
9. QoS-VPN across different network providers
In order to support QoS-VPN services across multiple provider
networks, the ASBRs of different network providers must interwork
to transfer the VPN services request signalling and VPN traffic. If
both network operators deployed the VPN-CRCs, their VPN-CRCs can be
interworked, these VPN-CRCs only exchange and map the inter-network
SLA. In this case, VPN-CRCs only manage the intra-network link
resources, ASBRs manage the inter-network link resources by the
specified SLAs, perform the function of the Ingress PE in the
intra-provider case. If one of network providers doesn't deploy
VPN-CRC and deploy other QoS mechanism for VPN, the two ASBRs should
map the QoS requirements to each other, then the degree to guarantee
the QoS of VPN across these two network providers depends on the
mechanisms of the other network providers. This needs for further
study.
10. Security Consideration
It needs further study.
11. 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
Defeng Li. [Page 16]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
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.
12. References
[BGP-VPN] Rosen and Rekhter, "BGP/MPLS VPNs". draft-ietf-ppvpn-
rfc2547bis-04.txt, Work in Progress, May 2003.
[RFC3036] "LDP Specification", L. Andersson, et al. RFC 3036.
January 2001.
[BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network-
based VPNs", Ould-Brahim, et. al., draft-ietf-ppvpn-bgpvpn-auto-
05.txt, Work in Progress, May 2003.
[VPLS-BRIDGING] "Bridging and VPLS", draft-finn-ppvpn-bridging-vpls-
00.txt, Work in Progress, June 2002.
[L2VPN-SIG] "LDP-based Signaling for L2VPNs", draft-rosen-ppvpn-l2-
signaling-03.txt, Work in Progress, May 2003.
[L2FRAME] "L2VPN Framework", draft-ietf-ppvpn-l2-framework-03, Work
in Progress, February 2003.
[L2VPN-REQ] "Service Requirements for Layer 2 Provider Provisioned
Virtual Private Networks", draft-ietf-ppvpn-l2vpn-requirements-
00.txt, Work in Progress, May 2003.
13. Authors' Addresses
Defeng Li
Huawei Technologies
Email: lidefeng@huawei.com
Defeng Li. [Page 17]
Internet Draft draft-defeng-l3vpn-qos-crc-01.txt February 2004
