Internet DRAFT - draft-declercq-vsn-arch
draft-declercq-vsn-arch
Network Working Group Jeremy De Clercq
INTERNET DRAFT Sven Van den Bosch
<draft-declercq-vsn-arch-01.txt> Alban Couturier
Alcatel
June 2003
Expires December, 2003
An architecture for a gradual deployment of end-to-end QoS on an
Internet-wide scale (Virtual Service-aware Networks)
<draft-declercq-vsn-arch-01.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
This document introduces Virtual Service-aware Networks (VSNs) as a
solution for inter-domain resource reservation with Quality-of-
Service (QoS) on an Internet-wide scale. A VSN is a single-domain
overlay network that consists of guaranteed QoS pipes. VSNs of
neighboring domains that offer the same level of QoS establish
peering relationships. As such, they form a network of QoS-enabled
networks with a specific (QoS) routing context. In this network,
admission control for traffic flows is performed in two phases. The
De Clercq et al. Expires December 2003 [Page 1]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
two-phase approach allows for the use of an off-path signaling
protocol, which enables the gradual introduction of this architecture
without changing the existing routers.
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 [1].
Table of Contents
1. Introduction...................................................2
1.1 QoS resource management....................................3
1.2 Scalability................................................3
1.3 Inter-domain aspects.......................................4
1.4 Deployment.................................................4
2. Terminology....................................................5
3. VSN concepts...................................................5
3.1 Two-level admission control................................6
3.2 Concatenation of QoS pipes.................................8
3.3 Data/control plane separation.............................10
4. VSN in a single-domain core network...........................12
4.1 Provisioning of QoS pipes.................................12
4.2 Per-flow admission-control................................12
4.3 Route Alignment...........................................13
5. VSN in a multiple-domain core network.........................14
5.1 BGP/MPLS VPN application..................................14
5.1.1 Creation of arbitrary overlay topologies..............15
5.1.2 VPN peering at border routers.........................15
5.1.3 End-to-end packet flow................................17
5.2 IP QoS application........................................18
5.3 Dynamic data/control plane alignment......................19
6. The QoS signaling protocol....................................20
7. Gradual VSN deployment........................................20
8. VSN assurance.................................................21
8.1 Performance monitoring....................................21
8.2 Resilience................................................22
9. Security and AAA Considerations...............................24
9.1 Trust issues..............................................24
9.2 Authentication, Authorization and Accounting..............25
9.3 Protocol security.........................................25
References.......................................................26
Acknowledgments..................................................27
Author's Addresses...............................................27
Full Copyright Statement.........................................27
1. Introduction
De Clercq et al. Expires December 2003 [Page 2]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
In 2000, a collaborative effort on the part of Internet Architecture
Board resulted in the specification of RFC 2990 [RFC2990],
identifying next steps for the IP QoS architecture. RFC 2990 was an
effort to identify essential precursors to widespread deployment and
use of QoS-aware networks, in order to identify missing sections and
additional refinements to the existing QoS model. The existing QoS
models at the time, Integrated Services [RFC1633] and Differentiated
Services [RFC2475], form two extremes of a continuum of control
models where the fine-grained precision of per-flow reservation can
be aggregated into larger more approximate reservation states and the
element-by-element reservation can be progressively approximated by
treating a collection of sub-networks or an entire transit network as
an aggregate service element. The architectural direction that was
pointed to was the adoption of an approach combining the per-flow
service elements at the edge and aggregated service elements in the
core. Examples of such an approach are RSVP aggregation [3175] and
IntServ-over-DiffServ [2998].
The development of an end-to-end signaling protocol was seen as an
essential step towards the combination of both types of architectures
into an end-to-end model. Currently, work is ongoing in the Next
Steps In Signaling (NSIS) working group to define such a protocol.
RFC 2990 further identifies a number of challenges that a potential
QoS architecture would need to address in order to be successful.
They can essentially be categorized as related to either QoS resource
management, scalability, inter-domain aspects or deployment.
1.1 QoS resource management
It is clear that any proposal for a wide-scale QoS architecture
cannot assume homogeneity of deployed QoS technology. As such, it
needs to be prepared to reuse existing QoS resource management
techniques. Additionally, it needs to be able to inter-work between
networks where different resource management techniques are used. The
VSN architecture strongly decouples resource management from resource
reservation by means of the overlay topology concept explained in
section 3.1.
1.2 Scalability
IntServ, IntServ-over-DiffServ and RSVP aggregation use packet
classifiers as an intrinsic part of their architecture. Fine-grained
classifiers isolate traffic from a micro-flow and may cause the need
to keep per-flow state where they are applied. With IntServ, this
would be in every network element on the data path. With IntServ-
over-DiffServ and RSVP aggregation, it would be at the edge of each
domain. The admission control principle of the VSN approach described
in this document (section 3.1) only requires per-flow state to be
De Clercq et al. Expires December 2003 [Page 3]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
kept at the origin and the end-point of a reservation, irrespective
of the number of domains in between the origin and end-point.
1.3 Inter-domain aspects
The assumption within both the IntServ and the DiffServ architecture
is that the Best-Effort routing path can be used for any service,
whether this path is able to sustain the required service load or
not. RFC 2990 points out that at least during the initial stages of
QoS roll-out, this may not be the case. As such, it identifies the
need for QoS routing and discovery of the service capabilities of a
path. In the VSN architecture, this is supported by the separation of
routing contexts for different deployed services. This allows for a
per-service concatenation of QoS segments as explained in section
3.2.
1.4 Deployment
Several issues are related to the architectural support of a certain
service set and service deployment. One attempt to deploy QoS was
made with the Qbone Premium Service [Qbone]. The effort was stopped
because of what was seen as largely non-technical obstacles to
deployment [Teitelbaum]: poor incremental deployment, intimidating
new complexity, missing functionality on routers and serious economic
challenges.
Poor incremental deployment resulted from the tight coupling between
data and control plane. This is exemplified by the need to upgrade
all edge routers and by the decision to give DSCP values local
significance only. Incremental deployment is considerably easier with
the data-control plane separation principle proposed in section 3.3.
The proposed architecture is built on a combination of techniques
that are widely accepted and along the process of being deployed.
More specifically, it can build on available VPN expertise and
deployment which strongly reduces new complexity and the risk of
non-compliant routers.
It also addresses some of the business logic behind the proposition.
For a network provider, deploying a VSN has no more impact than
accepting a new VPN customer.
Some issues raised in [RFC2990] and [Qbone] indeed require careful
attention. The signaling protocol (section 6) is an essential part of
the solution. VSN assurance (section 8) and security (section 9) will
be crucial to the success of the proposed architecture.
The VSN architecture is seen as an alternative implementation of the
De Clercq et al. Expires December 2003 [Page 4]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
trade-off between aggregation and per-flow awareness. It additionally
has better support for incremental deployment and supports more
flexible business models than other proposals, both of which are seen
as crucial aspects for the success of a QoS architecture.
2. Terminology
AC: Admission Control.
AP: Application Provider. The AP is a legal entity who uses a QoS-
aware network to offer applications to end-users.
BE: Best Effort.
BR: Border Router.
CE: Customer Edge device.
Flow (or traffic flow): A traffic flow is a stream of packets between
two end-points that can be isolated based on a packet classifier
containing e.g. source address, destination address, DSCP, ...
NAD: Network Access Device. An NAD is a device belonging to a AP that
is connected to a NP's backbone network via a NP's PE.
NP: Network Provider. The NP is the legal entity who owns and
operates the backbone network and its network elements (PE and P)
NSIS: Next Steps In Signaling Working Group.
PE: Provider Edge router. A PE is a router that belongs to the NP and
whereto access devices belonging to other entities (AP, customer) are
attached.
QC: QoS Controller.
QI: QoS Initiator.
QoS: Quality of Service.
QoS packet: an IP packet that belongs to an IP flow that has been
granted certain QoS guarantees.
QoS pipe: a virtual link between two edges of a backbone network that
has bandwidth and QoS guarantees associated with it.
QP: QoS Service Provider. The QP is a legal entity who leases an
overlay network with QoS guarantees from a Network Provider. The QP's
customers are Application Providers who use the QP's QoS-aware
network.
QR: QoS Receiver.
SLS: Service Level Specification. The SLS as used in this document is
the specification of the QoS guarantees that are associated with a
set of QoS pipes.
VSN: Virtual Service-aware Network. VSN is the abbreviation used for
the approach described in this document: a Network that allows to
provide (end-to-end guaranteed) Services, using a Virtual overlay
topology.
3. VSN concepts
The architecture described in this specification relies on 3 basic
concepts that will be described in the following subsections.
De Clercq et al. Expires December 2003 [Page 5]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
3.1 Two-level admission control
The first concept upon which this architecture is built, is a so-
called ''two-level admission control.''
It is clear, that performing end-to-end hop-by-hop resource
reservation in every node for every new (micro-)flow request is not
scalable in large scale multi-domain networks. Backbone transit
networks cannot keep per (micro-)flow state and do per (micro-)flow
policing in their network elements.
As such, this architecture proposes to distinguish two phases that
need to occur prior to forwarding packets into the network.
****** : ****** : ******
*AP-1* : _ _ _ _ _ _ _ _ _ _ _* QP *_ _ _ : *AP-2*
****** : | ****** | : ******
: | + | :
...... : | ...... + | : ......
. QI .-:----|------------>. QC .-----+-------|----:->. QR .
...... : | ...... SLS | : ......
: __|_ + _|__ :
: | |----------------------+-----| | :
: | | QoS pipe + | | :
: |____|----------------------+-----|____| :
: | + | :
: |_ _ _ _ _ _ _ _ _ _ _ _ + _ _ _ | :
: + :
.. .. :.. .. .. .. .. .. .. .. .. ..+ .. .. .. ..: .. .. .
: + :
: ****** :
: _ _ _ _ _ _ _ _ _ _ _* NP * _ _ _ :
: | ****** | :
: | ___ | :
: __|_ ___| | __|_ :
___ : | | / | P | ___ | | : ___
|NAD|--:-| PE |___/ ---\ | |________| PE |-:--|NAD|
--- : |____| \_| P | |____| : ---
: | --- | :
: | | :
: |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| :
Figure 1: AP, QP, NP and SLS between QP and NP.
In a first phase, ''QoS pipes'' are being provisioned between the
edge devices of the considered single network. The characteristics of
these QoS pipes are detailed in a Service Level Specification (SLS).
By provisioning QoS pipes between ingress-egress pairs within a
De Clercq et al. Expires December 2003 [Page 6]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
network, a virtual topology or ''overlay network'' is created. The
owner of the underlying network (the Network Provider, NP) can lease
such an overlay network to other entities that we will call QoS
Providers (QP). Note that these two entities will have a different
view on the network: the NP has a view of the complete network, with
all its individual network elements. The QP only has a view on the
overlay network of QoS pipes that it leases from the NP. The
considered SLS will then for example specify the amount of bandwidth
that is reserved for every QoS pipe of the overlay network.
Note that the distinction between NP and QP can be purely logical
(when the same legal entity plays both roles) or also effective (when
two different legal entities play the different roles).
The provisioning of a new QoS pipe takes into account any other
existing resource reservations in the network: a new QoS pipe will
only be allowed if there are enough unreserved resources available.
This is the first phase of the ''two-level admission control''.
The second phase is the actual admission or rejection of individual
flows. It is assumed that every individual flow is being served by a
QP, and as such will consume resources from that QP's logical
topology of QoS pipes. The QP has a view on the pre-provisioned QoS
pipes and on the resources consumed by existing flows. For every
incoming flow request, the responsible QP needs to determine the QoS
pipe that will be affected, and compare the available resources of
that QoS pipe with the requirements of the new request. If the QoS
pipe has enough resources available, the flow will be accepted, in
the other case, it will be denied. This is the second phase in the
two-level admission control procedure. Note that the NP doesn't need
to be aware of these individual flows, it has only an aggregate view
of the traffic.
This functional separation also has an impact on the necessary
traffic conditioning, which is also split in two phases.
The first phase of admission control results in a traffic
conditioning action on the QoS pipe by the NP. This traffic
conditioning is performed at the NP's border routers at the edges of
its network. By doing so, the NP makes sure that the QoS pipes behave
as specified within the SLS's and as such the NP maintains an
accurate view on the available resources in its backbone network.
The second phase of admission control results in a traffic
conditioning action that is performed at the NADs (Network Access
Devices). These devices are per-flow aware and are under control of
the Application Provider (AP) that signals resource requests to a QoS
Provider on a flow-per-flow basis.
De Clercq et al. Expires December 2003 [Page 7]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
The NAD should check whether both the resources consumed by the
flows, as well as the destination of the flows comply with the
resource request sent previously to the QP. This traffic conditioning
action is performed by the AP on behalf of its end-users that might
not be trusted to send traffic behaving according to what had been
requested before. A QP is not capable to detect individual
misbehaving flows as the data plane of the NP does not keep per-flow
information. As such, the QP needs to trust the fact that the flows
entering his QoS pipes have received appropriate traffic conditioning
at the NADs from the originating APs. Therefore the entities that
participate in this architecture need to trust the fact that they all
conform to this specification. As an obvious way to protect
themselves, a QP can always know whether an AP is not respecting the
trust specification by comparing the aggregate incoming resources
from each AP with the requested resources asked by each AP. This
aggregate monitoring information can be obtained from measurements
done by the NP and communicated to the QP. If there would be a
mismatch the QP can decide to terminate the peering agreement with
that particular AP. This in itself should be an incentive for all APs
to perform the appropriate traffic conditioning at their NADs such
that the QoS characteristics of the traffic requests match with the
effective resources consumed by the traffic sent over the QP's
overlay network. This trust specification is crucial to avoid per-
flow awareness in routers of the core network owned by the NP and
also applies to a multi-domain/multi-provider context as we will see
in the next section.
3.2 Concatenation of QoS pipes
It is feasible for a single network to provision and maintain QoS
pipes between its edge routers. One set of QoS pipes results in an
overlay QoS-aware network.
It is not feasible though to provision end-to-end QoS pipes on an
Internet-wide scope, in order to achieve global reachability. The
enormous number of ingress-egress pairs and the n-square nature of
the problem implies that this approach wouldn't scale. Moreover,
end-to-end pipes would need to be supported by different backbones
managed by different network providers.
In order to overcome this problem, the proposed end-to-end
architecture consists of a network of local (intra-domain) QoS pipes
and concatenation points between the pipes belonging to different
domains. These local QoS pipes can autonomously guarantee QoS. At
every concatenation point, for data packets leaving a certain pipe, a
selection of the next pipe to send data packets through needs to be
performed. As a concrete example, the concatenation points could be
the border routers of the Autonomous Systems (AS's), as shown in
De Clercq et al. Expires December 2003 [Page 8]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
figure 2.
In this way, end-to-end flows will transit a sequence of pipes and
the resource availability should be checked (before a particular flow
can be admitted in the very first pipe) for every pipe in the
sequence by the corresponding service provider owning the pipe or the
overlay network to which the pipe belongs.
<- autonomous system 1 -> <-- autonomous system 2 -->
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
| | | |
__|_ |_ _| _|__
| | | | | |-------------------| |
| |----------------| | | | QoS pipe 1 | |
| PE | local QoS pipe |BR |---|BR |-------------------| PE |
| |----------------| | . | |------------ | |
| | | | . | | QoS pipe 2 \ | |
|____| |__ | . |__ |---------\ \ |____|
| | . | \ \ |
| | . | _\___\_ |
|_ _ _ _ _ _ _ _ _ _| . |_ _ _ _ _ | |_ _|
. | PE/BR |
. |_______|
{___.___}
V
concatenation point
Figure 2: QoS pipes and concatenation points.
In order to achieve this, the different QPs that operate the overlay
networks (and thus use the QoS pipes) on top of the traversed
backbones need to agree on peering agreements.
These peering agreements specify the level of QoS that is being
offered by the overlay network, and the policy for the exchange of
reachability information.
Note that these peering agreements between service providers don't
specify the amount of (bandwidth) resources that might be made
available to each other. Only the *level* of QoS that *admitted*
flows will receive is specified; the admission of flows is done on a
per-flow basis. This architecture does not require bandwidth
agreements between peering NPs or peering QPs.
In order to implement such an inter-service provider behavior, a
selective route distribution system is necessary. Indeed, the
exchange of reachability information should only be performed between
De Clercq et al. Expires December 2003 [Page 9]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
those service providers that have a peering agreement, irrespective
of the physical peering points between network providers.
This selective route distribution will also guarantee that packets
are routed end-to-end along an unbroken chain of QoS pipes, even if
there would be alternative routes without these QoS pipes. This
implies that the routing for traffic requiring QoS and the routing
for best effort (BE) traffic needs to be separated as both may not
coincide: BE routes are determined by the peering agreements between
Service providers that own BE SLSs while QoS routes are determined by
the peering agreements between QoS providers that own QoS SLSs.
Note that within every of the traversed networks (or network parts),
QoS is only assured for each of the QoS pipes that reach from an
ingress point of the network to an egress point of the network. It is
the NP who offers this assurance by policing the traffic that uses
the QoS pipes on an aggregate level.
The QP will compare the aggregate incoming traffic from its peering
QPs (based on monitoring information received from the NP) with the
aggregate resources requested by these QPs. If there is a mismatch,
the QP might decided to terminate the peering relation. Therefore
every QP will carefully monitor the trust specification with its APs
and QPs, otherwise he runs the risk to loose his peering relation
with other QPs.
As such every business player in the chain (AP-QP-...-QP-AP) has a
strong incentive to respect the trust specification, and per-flow
traffic conditioning can be restricted to the access (traffic
ingress) and should not be repeated in the core networks at every
peering point between different providers. As such the trust
specification is key to preserve the scalability of the end-to-end
architecture.
3.3 Data/control plane separation
This architecture clearly separates the functionality of the flow
control plane from the functionality within the data plane. This
separation is not only logical but also effectively imbedded in the
architecture, which, as we will see later on, leads to enhanced
scaling properties and to an acceptable deployment strategy of the
approach in existing network infrastructures.
The architecture also maps two different ''roles'' on these separate
functions in the core of the network. The flow control plane role
belongs to the QP, while the data plane role belongs to the NP. Note
again that both roles may be effectively played by different
(business) entities, or that alternatively, the same entity may
De Clercq et al. Expires December 2003 [Page 10]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
perform both roles.
One of the key requirements for an end-to-end QoS solution is that
there should not be per-flow awareness in the data plane in the core
of the network.
By deploying the two-level admission control explained in section 3.1
and by clearly separating the data plane from the control plane
throughout the architecture, the per-flow awareness can be limited in
the data-plane to the ingress NADs and to the control plane of the
different involved APs and QPs.
The clear split between control plane and data plane has the
advantage that the signaling protocol should not be implemented on
the routers but can be implemented on a centralized device. This has
the additional advantage of leading to an approach that can be more
easily deployed in existing networks: no existing network elements
need to be upgraded with newly defined per-flow control plane
functions.
In this architecture, every QP has a specific QoS controller. When a
request for a new flow is processed, the QP's QoS controller needs to
find out which QoS pipe in its overlay network will be impacted, in
order to be able to perform the required per-flow admission control.
Therefore, the view of the flow signaling plane (the control plane)
on the network's reachability information needs to be aligned with
the reachability information maintained and used in the data plane.
In a multi-domain scenario, the QP's QoS controller needs to find out
which QoS pipe in its overlay topology will be affected by a new flow
(in order to perform per-flow admission control), and then it needs
to send the flow request to the QoS controller of the QP with which
it has a peering agreement in the next impacted network (the ''next-
hop'' QoS controller). The QP's QoS controller can identify the
impacted QoS pipe and the ''next-hop QoS controller'' using the QoS
request's destination information, because the information it has on
the global reachability is aligned with the reachability information
in the data plane (in the NP's routers).
De Clercq et al. Expires December 2003 [Page 11]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
___________ ___________
AC---> | QoS contr | --AC-> | QoS contr |-----AC
/ ----------- ----------- \
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
Q-I | | | | Q-R
_____ _|_ overlay |_ _| overlay _| _____
|S-NAD|-|PE | of |BR|--|BR| of |PE|-|D-NAD|
----- |___| QoS |__| |__| QoS |__| -----
| pipes | | pipes |
|_ _ _ _ _ _ _| |_ _ _ _ _ _ _|
Figure 3: admission control in a multi-domain scenario.
4. VSN in a single-domain core network
4.1 Provisioning of QoS pipes
In a first phase, the QP requests QoS pipes between the NP's edge
routers (PEs) to which it has NADs attached.
The NP then checks whether it has enough resources available in its
network to fulfill these requirements, and if so, provisions QoS
pipes between its PEs according to the requested SLS. The NP
effectively implements this behavior using any existing mechanism,
for example using the DiffServ capabilities of its network, by using
the QoS capabilities of the supporting Layer-2 network, or for
example by establishing traffic-engineered LSPs.
From this point on, the NP performs traffic conditioning on the
aggregate traffic that enters the QoS pipes, in order to accomplish
the behavior specified in the SLS.
The NP's PE devices need to decide about which traffic to send over
which overlay network over its core network as there could be
multiple overlay networks owned by multiple QPs. This could be
statically configured, as the AP's NADs are statically attached to
the PE devices and all traffic coming from a specific NAD will
probably go to one overlay network only, as part of the peering
relation between the AP and a particular QP owning that overlay
network. This decision is thus made on the basis of the incoming
(sub-)interface. The NP's PE devices need also to decide about what
traffic to send on which particular QoS pipe in a particular overlay
network. According to the granularity of the PE's view of the traffic
(PEs need not be per-flow aware), these PEs need to make this
decision on an aggregate level, i.e. via normal IP forwarding.
4.2 Per-flow admission-control
De Clercq et al. Expires December 2003 [Page 12]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
As mentioned previously, in this architecture, every QP maintains a
central control plane element that keeps track of the available
resources in the leased QoS pipes and that controls the admission
control of new flows. This central control element will be called
''QoS controller'' (QC) throughout this document.
When the QP needs to process a request for a new flow with associated
resource guarantees, the QC needs to do the following:
a. associate the considered request with a specific QoS pipe. The
QC uses its view on the overlay topology and its view on the
according routing information, together with the flow's
source/destination information specified in the request, to make
the required association;
b. check this identified QoS pipe for available resources. Indeed:
the QC has the necessary information on the total reserved
resources of the leased QoS pipes (as specified in the SLS's), and
on the resources consumed by existing flows. This information is
compiled based on the granted resource requests for ongoing flows
and is not based on the monitoring of the loading on each QoS
pipe. Monitoring information is only used for consistency checks
in the framework of the trust relation between service providers
c. if the new flow's requested resources can be assured, the flow
is admitted, and the QC's view on the available resources in the
QoS pipe must be adjusted accordingly.
Admitted flows will then be conditioned (policed, etc.) at the AP's
NAD.
4.3 Route Alignment
From the above description it follows clearly that the proposed
solution can use an out-of-band (flow establishment) signaling
protocol.
An important concern when using out-of-band signaling as proposed, is
the fact that the flow control plane must know the exact routing
information that will be used by the data packets (the routing
information in the routers' routing and forwarding tables).
Indeed, the routers' routing and forwarding tables dictate which path
the flows will take through the network. And, as was explained
earlier, the QC needs to know this information to be able to
associate a specific request for a QoS flow with the appropriate QoS
pipe.
De Clercq et al. Expires December 2003 [Page 13]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
One can think of different mechanisms to align the control plane's
view on the network's routing information with the effective data
plane's routing information. One method is by statically configuring
routing information in the QC. Other methods will be described
further in this document.
5. VSN in a multiple-domain core network
When sending an end-to-end flow over a multi-domain core network, we
need to deal with an environment where services are not offered by a
single AP or QP, and where traffic flows are not delivered using only
one NP's infrastructure.
The VSN architecture described in this document creates overlay
topologies over single-domain networks. In a multiple-domain
environment, every domain will implement the single-domain VSN
behavior described in the previous sections.
VSNs (operated by QPs) in neighboring domains that offer the same QoS
guarantees will establish peering relationships. As such, a multi-
domain QoS-aware network of pipes and concatenation points is
created. Now one must make sure that QoS packets are forwarded along
this concatenation of QoS pipes and concatenation points. Therefore a
specific routing context must be created for this multi-domain QoS-
aware network of pipes and concatenation points, sharing the same
level of QoS.
PE-based VPNs are a way of creating specific separate routing
contexts in a single-domain network. BGP/MPLS VPNs [2547bis] are one
implementation of PE-based VPNs (section 5.1). VR-based VPNs are
another implementation of PE-based VPNs (more details in a next
version of this document).
An advantage of the use of tunneling as in [2547bis] is that the
routing information pertaining to the different contexts are kept out
of the core (P) routers.
An additional advantage of the use of MPLS as a tunneling technique
is the ease of protection and restoration and the ability to optimize
networking through the use of explicit routed tunnels.
The architecture does not mandate the use of MPLS nor BGP/MPLS VPNs.
Indeed, there is no architectural reason why VSNs could not work with
with an IP QoS solution. A discussion on an IP QoS-based
implementation of the architecture is given in section 5.2.
5.1 BGP/MPLS VPN application
De Clercq et al. Expires December 2003 [Page 14]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
VPNs effectively implement separate routing contexts over a shared
network. Every customer (e.g. an enterprise) buying a VPN will be
handled in a different separate context, as such achieving routing
information segregation and user data segregation.
In this architecture, a QP can buy a VPN (or more precisely, a
context, implemented as a VPN) to offer a certain level of QoS. This
allows for a clear separation of the traffic requiring QoS and the BE
traffic over one and the same network infrastructure.
As such, the introduction of a QoS-enabling architecture as described
in this document, will not be disruptive for the existing BE
Internet.
In order to achieve the requested end-to-end behavior, following the
general VSN requirements, a certain form of ''stitching'' of VPNs
will be needed between VPNs in different domains where the
corresponding VSNs (or QPs) have a peering agreement.
Note that the terminology used in this specification differs from the
normal ''VPN terminology'': in this specification, a QP buys a VSN
(VPN) from a NP, while in VPN-terminology, a customer buys a VPN from
a SP.
Note that although BGP/MPLS VPNs are introduced here as a possible
implementation of VSNs in the context of multiple-domain networks,
BGP/MPLS VPNs can also be used as an implementation in a single-
domain scenario.
5.1.1 Creation of arbitrary overlay topologies
The overlay topology that the QP leases from the NP (i.e. the set of
QoS pipes) will thus be effectively implemented using BGP/MPLS VPNs:
- every PE that serves as an ingress or egress of a QoS pipe from
a certain QP, will implement a Virtual Router (or a VRF, in
BGP/MPLS VPN terminology) dedicated to the corresponding VSN;
- the routing information will be selectively distributed using
MP-BGP to those VRFs that belong to the appropriate (QoS) context,
using the filtering on Route Target attributes described in
[2547bis].
The VSN architecture as it is currently described, only needs the
basic ''fully meshed VPN'' mechanism of [2547bis], the applicability
of more complex scenarios such as ''hub and spoke'' topologies is for
further study.
De Clercq et al. Expires December 2003 [Page 15]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
5.1.2 VPN peering at border routers
The border routers of two interconnected networks that support the
VSN architecture, will also need to implement the [2547bis] PE
behavior. Moreover, the neighboring border routers' VRFs that
''belong'' to QPs (or VSNs) that have a peering agreement (in other
words, those VRFs that ''serve the same context'') need to be somehow
attached to each other via a specific (sub-)interface. This can be a
statically configured (sub-)interface such as an ATM PVC, an Ethernet
VLAN or a direct link. Alternatively, this may be a dynamically
established single-hop LSP as will be explained later.
By locally attaching the ''peering QPs'' VRFs of the border routers
of peering domains to each other, VPNs of the same context, operating
in neighboring domains, are effectively stitched together (keeping
the same context). In addition, as IP lookups will be performed in
these border routers' VRFs, they perform the ''concatenation point
function'' that this architecture needs.
The exchange of per-QoS context reachability information between the
peering VSNs in neighboring domains can be implemented in various
ways. As BGP is intensively used in [2547bis], and as E-BGP is the
most popular inter-domain routing protocol, E-BGP is the ideal
candidate for doing so in this architecture.
BGP/MPLS VPN proposes 3 approaches for the implementation of inter-
domain VPNs (see [2547bis], section 10). The BGP/MPLS VPN (scaling)
requirements for the inter-domain behavior of VPNs are different
though from the requirements put forward by this architecture.
In BGP/MPLS VPNs, the assumption is that it is probable that a very
large number of VPNs need to be supported by every network, and as
such that two peering networks might also have a large number of VPNs
in common. Therefor the architecture is optimized in such a way that
VPN routing information is only to be maintained in PE routers that
directly attach to customer sites, and as such not in autonomous
system border routers. A result of this design is that ''end-to-end''
(as in ingress PE (AS1) - egress PE(AS2)) BE LSPs need to be
established between PEs that are attached to the same VPNs.
On the other hand, in this VSN architecture, it is assumed that only
a limited number of VSNs need to be supported per network, and as
such that two peering networks will also have only a very limited
number of peering QPs. In addition, it is assumed that every AP will
have a large number of ''access points'' in the networks to which
their NAD's are attached. Therefore the architecture is optimized in
such a way that end-to-end tunnels (e.g. LSPs) are avoided, resulting
in the need for a (very limited) number of VRFs in the attachment
De Clercq et al. Expires December 2003 [Page 16]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
points. In the context of this architecture, option (a) in section 10
of [2547bis] (''VRF-to-VRF connections at the AS border routers'') is
the optimal solution for the stitching of VPNs in different domains.
_ _ _ _ _ _ _ _ _ _ _ _ _ _
| | | |
_| _|_ _|_ _|_
___ | | | |-EBGP->| | | | ___
|NAD|-|PE1|--IBGP-->|PE2|_______|PE3|--IBGP--->|PE4|-|NAD|
--- |___| |___|___ |___| |___| ---
| |\ \ | |
|_ _ _ _ _ _ | \ \ |_ _ _ _ _ _ _|
EBGP \ _ _ _ _ _ _
\ _\_| |__
-->| | | | ___
|PE5|--IBGP-->|PE6|-|NAD|
|___| |___| ---
|_ _ _ _ _ _|
Figure 4: inter-domain routing distribution.
As border routers are configured as BGP/MPLS VPN PE routers, they
will participate in the BGP-based routing exchange of VPN-routes. By
filtering on Route Target attributes, the border routers will insert
the routes received from their I-BGP peer PEs in the appropriate
VRFs. Following normal BGP behavior, a border router will then, if
necessary, send a BGP UPDATE message containing reachability
information via E-BGP to its neighboring border router. In order to
keep this BGP update in the correct context, different methods are
possible:
- VRFs are directly attached and both border router PEs treat each
other's VRF as a CE; normal unlabeled IPv4 routes are exchanged
via E-BGP (as in [2547bis], section 10, option a);
- directly attached border router PEs treat each other as PE
routers, and send each other labeled VPN-IPv4 routes via E-BGP;
filtering on route target attributes assures that the routing
updates are inserted in the correct VRFs; the border router PEs
use the BGP-announced MPLS labels in the MPLS encapsulation of
data packets they send to each other; this leads to a more dynamic
''attachment'' of VRFs.
A border router PE who has been updated by such an E-BGP update, will
run BGP's decision process and will then use I-BGP as described in
[2547bis] to distribute the necessary reachability information to its
I-BGP PE peers.
De Clercq et al. Expires December 2003 [Page 17]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
5.1.3 End-to-end packet flow
The implementation as described in the previous sections leads to the
following end-to-end processing of data packets, once admission
control has been performed.
A packet flow is injected in the AP's NAD. At this node, traffic
conditioning is done at a per-flow level. At the NAD, all the flows
are sent to its attached PE device. In that PE device, the considered
aggregate traffic is handled in a specific VRF, to which the NAD is
attached (by configuration).
In the VRF, packets are IP forwarded into the right LSP
(corresponding with a certain QoS pipe), based on the BGP/MPLS VPN
distributed routing information. The IP packets are encapsulated with
a ''VPN MPLS label'', identifying the VPN context, and a topmost
''tunnel label''. The PE device performs traffic conditioning at the
granularity of the QoS pipes.
Packets are then tunneled towards the egress PE of the first core
network. Let's assume that this PE is a border router.
Based on the ''VPN label'', the data packets are forwarded into the
appropriate VRF of that PE border router. In that VRF, a normal IP
lookup is performed and the packets are directed towards an outgoing
(sub-)interface, that is attached to a VRF of a directly attached
border router of a neighboring domain. Alternatively the packets can
be forwarded on an outgoing interface with the label that has been
announced by the attached border router in a labeled VPN-IPv4 E-BGP
message; that border router in the neighboring AS will then use this
label to send the packet to the appropriate VRF.
Next, in the VRF of the second border router (that is the ingress PE
of the next network), an IP lookup is performed in order to send the
packet into the correct LSP (or QoS pipe) towards its egress PE in
that particular network.
This sequence of actions is iteratively performed until the packets
finally arrive at the ultimate egress PE and are sent towards the
destination NAD.
5.2 IP QoS application
Even though the BGP/MPLS VPN implementation described in the previous
section offers many advantages for the implementation of the VSN
principles, we cannot and need not require or assume ubiquitous
deployment of MPLS or BGP/MPLS VPN techniques throughout the
Internet.
De Clercq et al. Expires December 2003 [Page 18]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
The essential requirement is the availability of different routing
contexts for different QoS classes. This can be implemented by any
means allowing the storage of multiple BGP routing table entries in a
router. For deployment reasons, intra-domain tunneling can be seen as
a very important requirement as well, in order to keep the different
routing context out of the intra-domain provider core routers. There
are several ways of implementing intra-domain tunnels without MPLS
(including GRE, IP-in-IP and IPsec).
A detailed description of a VSN implementation based on IP QoS only
is left for a future revision of this document.
5.3 Dynamic data/control plane alignment
As was explained earlier, the QC needs to perform multiple tasks when
performing admission control in a multi-domain scenario. For a
received flow admission request, it needs to (i) find the
corresponding QoS pipe in the overlay topology (VSN) it operates;
(ii) decide whether the considered single-domain QoS pipe can support
the additional flow; (iii) identify the ''next hop VSN'' that will
support the considered flow, and as such identify the ''next hop
QC''; (iv) send the flow admission request to the identified ''next
hop QC''. This sequence of actions is iteratively performed up to the
destination network's QC, and the considered flow is only to be
admitted if all the involved QCs have admitted the flow in their
overlay topology.
In order to perform (i) and (iii), the QC needs to have a consistent
view on the forwarding decisions that will be made in the
concatenation points (in the VRF of the ingress PE and in the VRFs of
every traversed border router).
One possible solution to achieve this, would be to require the PE
devices to establish an additional BGP session. Their peer for this
BGP session will be the QP's QC. Alternatively, a Route Reflector-QC
BGP session can be used for this purpose too. From the PE's point of
view, two implementations are possible: the QC can be seen as a CE
device belonging to the considered VPN (E-BGP will then be used);
alternatively, the PE can consider the QC as an extra PE device (and
thus BGP/MPLS VPN-based I-BGP will be used). Note however that, in
order to provide the QC with a consistent view of the BGP routing
information, the BGP NEXT_HOP information would need to be preserved
in the BGP UPDATE sent to the QC. Note also that the QC will only
perform a passive role with regards to BGP. The QC will never send
UPDATE messages, it will only passively snoop on the exchanged
reachability information, and build its view on the network's routing
from this snooped information.
De Clercq et al. Expires December 2003 [Page 19]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
Alternative methods for dynamic data/control plane alignment are TBD.
_____ _____
:---> | QoS |<--: :--> | QoS |<----:
: |contr| : : |contr| :
: ----- : : ----- :
BGP BGP BGP BGP
: _ _ _ _ _ _ : : _ _ _ _ _ _ _ :
: | |: : | |:
:_| _|:_ :_| _|:_
___ | | | |-BGP->| | | | ___
|NAD|-|PE1|---BGP-->|PE2|______|PE3|---BGP--->|PE4|-|NAD|
--- |___| |___|___ |___| |___| ---
| |\ \ | |
|_ _ _ _ _ _ | \ \ |_ _ _ _ _ _ _|
BGP \ _ _ _ _ _ _
\ _\_| |__
-->| | | |
|PE5| |PE6|
|___| |___|
: |_ _ _ _ _ _| :
: :
BGP _____ BGP
:--->| QoS | :
|contr|<---:
Figure 5: inter-domain route distribution and alignment.
6. The QoS signaling protocol
The QoS signaling protocol should allow for setup, refresh and tear-
down of (QoS) bandwidth reservations in one or more IP network(s).
Using the NSIS terminology, the protocol is said to be used between
the QoS Initiator, QoS Controller(s) and the QoS Receiver. The
important consequence of the VSN architecture on the signaling
protocol is that QoS controllers are not necessarily located in
routers. Consequently, the QoS controller chain for a QoS request is
no more necessarily on the date path. This property of the signaling
is called ''off-path'', while ''classical'' IP signaling like RSVP is
called ''on-path''.
General requirements for signaling were developed in the NSIS working
group [Brunner], and also apply on off-path signaling. For a
discussion on the advantages and issues with off-path signaling, we
refer to [Couturier].
7. Gradual VSN deployment
De Clercq et al. Expires December 2003 [Page 20]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
The primary design goal that this proposal has respected, is the
requirement that the proposed approach could be easily deployed in a
gradual way in the existing BE Internet: the proposed mechanisms
should be non-disruptive. This means among other things that it
doesn't require all the deployed network elements to be updated for
the solution to work, and that the solution brings added value even
if only a very limited part of all the existing networks have
implemented the described approach.
The following properties of the described approach illustrate this.
- VSNs only use tunnels (LSPs) within the boundaries of a single
domain: the architecture doesn't require inter-domain LSPs;
- VSNs rely on core networks that combine the DiffServ
architecture with the application of admission control on
aggregate traffic flows at the network edges in order to assure
QoS in a single domain;
- VSNs can use an out-of-band signaling protocol in order to
perform admission control for an end-to-end flow. As such, this
only impacts the control plane devices (the QCs), and not the
existing routers;
- VSNs can use the widely deployed PE-based VPN architecture as an
implementation of the necessary context separation and selective
route distribution.
As such, the VSN architecture allows for the gradual deployment of a
QoS-aware overlay internetwork without impacting the current BE
Internet. Every additional network that adopts the described concepts
will enlarge the reach of the QoS-aware internetwork, while backbone
networks that haven't adopted this architecture keep offering today's
services and keep playing their role in today's BE Internet with
today's BE peering relationships.
8. VSN assurance
8.1 Performance monitoring
Performance monitoring is defined as the acquisition of measurement
information from the network regarding the evolution of performance
parameters such as delay, delay variation, packet loss, throughput,
availability, etc. This information can be used to provide feedback
on actual QoS levels achieved in the network, either to a customer or
for internal use in a feedback loop towards provisioning.
There are essentially three ways in which monitoring can be achieved:
De Clercq et al. Expires December 2003 [Page 21]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
through concatenation of per-hop or per-segment information, through
active measurement by injecting dedicated test traffic or through
offline analysis of traffic traces. The choice of an intra-domain
monitoring method is irrelevant to the VSN architecture since it is
essentially a local decision of the Network Provider.
It is not clear if, and how, end-to-end monitoring should be
provided. It is not inconceivable that an end-user or a Service
Provider would like to monitor the actual QoS obtained for his flows.
It is also possible that the end-user or Service Provider will merely
detect service degradation but that the Service Provider or the
Network Provider will want to identify the responsible network. Both
of these applications require end-to-end monitoring information to be
available. Depending on the business and trust relations, a number of
possibilities are available:
- End-to-end monitoring by the customer: the customer has the
capability to monitor his own performance
- End-to-end monitoring by the Service Provider: the Service
Provider has the capability to monitor end-to-end performance
- End-to-end performance recording: in the signaling, monitoring
information is passed to the QoS Initiator and/or the user
- Third-party monitoring: A dedicated operator is responsible for
monitoring end-to-end performance of various connections. He is
recognized by both customers and providers. He must be able to
identify potential misbehaving networks.
All these options will have impact on the security architecture of
the proposed solution.
8.2 Resilience
The VSN architecture makes a clear separation between data and
control plane. This means that under failure conditions, we cannot
assume fate sharing between data and control plane. Data plane and
control plane failures can occur separately and independently and
need to be addressed as such.
Data plane failures will be either internal to a domain (internal
failures) or have an inter-domain impact (external failure) when
either the ingress or egress border node of a domain or an inter-
domain link is affected. It is reasonable to assume that (most)
internal failures will be solved locally. This can be part of the SLS
between Network Provider and Service Provider and can be supported by
means of e.g. intra-domain MPLS protection. External failures may
De Clercq et al. Expires December 2003 [Page 22]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
cause a route change, either because a different pipe and different
ingress/egress link in the domain need to be chosen or because an
upstream domain needs to select a different AS next hop. When the
control plane is still up, this situation can be notified and treated
as a normal route change. Note that the same can apply for
unrecoverable internal failures. Note that it would theoretically be
possible to avoid signaling impact if all domain are interconnected
by at least two fully meshed border routers and resource reservation
is made both on the primary and the protection path. The
interconnecting links should not be part of the same Shared Risk Link
Group. This situation is depicted on Figure 6.
+------------+ +------------+
| | | |
| +----+ +----+ |
| + BR +-----+ BR + |
| +----+\ /+----+ |
| | \ / | |
| AS1 | X | AS2 |
| | / \ | |
| +----+/ \+----+ |
| + BR +-----+ BR + |
| +----+ +----+ |
| | | |
+------------+ +------------+
Figure 6 depicts the inter-domain data plane resilience.
Because of the data control plane separation, it is possible that
while the control plane is down, the data plane is not. While this
requires coordination between protective actions at both layers, it
can be useful that the data plane can be left running while the
control plane heals. Indeed, tearing down all flows because of a
control plane failure seems a brute-force solution because of the
network-wide impact. Control plane failures can be further broken
down into signaling protocol failures and protocol entity failures.
Signaling protocol failures should be handled by the signaling
protocol itself. This means that the protocol should support reliable
end-to-end delivery of signaling messages. This may require
reliability both at the transport and at the messaging layer.
Reliability at the messaging layer is needed for end-to-end signaling
reliability when the transport layer operates by means of hop-by-hop
sessions. Protocol entity failures can be handled by duplication of
the control plane functionality. This requires back-up control plane
entities to be discovered and synchronized during normal operation.
End-host failures require special attention. When the QI is different
from the end-host, QI and end-host need to be aware of each others
De Clercq et al. Expires December 2003 [Page 23]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
failures. Two factors can complicate this problem. First, the QI may
keep hard-state related to the end-host requests because the overhead
of refreshes is deemed excessive. In this case, state refreshes can
not be used as a failure detection mechanism. Second, the-end host is
not necessarily a signaling protocol speaker, which means that the
detection mechanism must be supported outside of the signaling
protocol.
The failing reservation may be part of a service consisting of
multiple such flows. An obvious example is a bi-directional service.
It would seem appropriate for each flow to be protected separately
and for the service not to be impacted when the protection action is
successful. However, it would make little sense to keep one direction
up when the other goes down. This would imply notification of the
QI/QR of the flows making up the service in case of unsuccessful
protection.
The awareness of two flows being part of a single bi-directional
session is typically known at the level of the application provider
and such it should be the application provider's responsibility to
tear down the remaining direction when the other direction goes down.
Reversion is inextricably related to resilience. It describes the
behavior of a system or solution that returns from a failure
condition to normal operation. In the context of VSNs, reversion for
inter-domain data plane failures would mean allowing route changes
for optimization purposes (going back to the original state). For
inter-domain control plane failures it would mean resynchronization
with repaired entities and potentially re-setup of torn down flows.
9. Security and AAA Considerations
9.1 Trust issues
The VSN architecture is built on the notion of the trust model. This
implies that providers trust their peers to correctly police
aggregate traffic and expect micro-flows to be policed at the edge of
the network. In the context of security, several other trust issues
may arise.
Providers must, for instance, trust their peers' network provider to
correctly provision the network in order to support the overlay
topology. Since they do not have a contract with that network
provider, they have no way of knowing the required resources will
actually be available. Providers must also trust their peers to
correctly update and send protocol messages. Suppose for instance
that a route record functionality is supported, which is used to
route back messages along the reverse of the flow path. Suppose that,
De Clercq et al. Expires December 2003 [Page 24]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
in addition, this record route information must be concealed from
downstream domains. In that case, a provider has to trust his peer to
encrypt part of the message.
It is clear that the architecture will require a strong framework for
Authentication, authorization and accounting (AAA).
9.2 Authentication, Authorization and Accounting
The VSN architecture will be used to provide high-value Quality-of-
Service applications over and throughout the Internet. As such, it is
of prime importance to ensure that these services can be provisioned
and used in a secure way by the rightful parties.
Because of the trust model, the focus of the security architecture
can be put on authentication and integrity. Authentication provides a
way of identifying a user before access is granted to the offered
service. In the VSN architecture, authentication is needed between
the user and the QoS Initiator and/or the QoS Responder, between the
QoS Initiator and the QoS Controller and between QoS Controllers and
between the QoS Controller and the NP's network management system.
Integrity ensures that what is received from a peer has not been
modified by an adversary. It comprises both control plane integrity
(ensuring that all signaling protocol messages are received in their
original form) and data plane integrity (ensuring that data packets
are unaltered during their traversal of the network(s)).
9.3 Protocol security
Misusing the signaling protocol is an obvious way in which an
adversary could attempt to steal resources from legitimate customers.
It is therefore clear that the signaling messages need to be secured.
A detailed threat analysis for a signaling protocol in the context of
the Next Steps In Signaling (NSIS) working group is presented in
[Tschofenig].
Some control plane functionality will give rise to additional
security issues because of potential misuses. This will be the case
for the peer discovery protocol and if query functionality about the
capabilities of certain networks is provided.
The protocol, which can operate on an Internet-wide scale, may also
contain a lot of information, some of which may be desirable to keep
private. Confidentiality and privacy refer to the ability to keep
information hidden from certain parties in the chain. It applies to
encryption of (parts of) data or protocol message in order to avoid
their interpretation by other parties, keeping the identity of
certain users hidden and keeping the identity of certain Service
De Clercq et al. Expires December 2003 [Page 25]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
Providers hidden. As an example, it could be desirable to hide the
identity of the QoS Controllers in the chain from all but their peers
in order to protect their customer base.
References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[2547bis] Rosen, E., et al., 9BGP/MPLS VPN, PPVPN WG draft, work
in progress.
[Tschofenig] Tschofenig, H., "NSIS Threats", draft-tschofenig-nsis-
threats-01.txt (work in progress), July 2002
[RFC2990] Huston, G., " Next Steps for the IP QoS Architecture ",
RFC 2990, informational, November 2000
[RFC1633] Braden. R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC 1633,
June 1994.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated Services", RFC
2475, December 1998.
[RFC3175] Baker, F., Iturralde, C., Le Faucher, F., Davie, B.,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[RFC2998] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
Speer, M., Braden, R., Davie, B., Wroclawski, J. and E.
Felstaine, "A Framework for Integrated Services Operation Over
DiffServ Networks", RFC 2998, November 2000.
[Teitelbaum] Teitelbaum, B, Hares, S., Dunn, L., Narayan, V.,
Neilson, R., Reichmeyer, F., "Internet2 QBone: Building a Testbed
for Differentiated Services", IEEE Network Magazine, Special
Issue on Integrated and Differentiated Services for the Internet,
September 1999.
[Qbone] http://qbone.internet2.edu/papers/non-architectural-
problems.txt
[Brunner] Brunner, M., "Requirements for QoS Signaling Protocols",
draft-ietf-nsis-req-04.txt (work in progress), August 2002
[Couturier] Couturier, A., and Schelen, O., "On path and off path
De Clercq et al. Expires December 2003 [Page 26]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
signaling for NSIS ," draft-schelen-nsis-opopsig-00.txt (work in
progress), June 2002
Acknowledgments
The authors would like to thank Hans De Neve and Danny Goderis for
their valuable inputs.
Author's Addresses
Jeremy De Clercq
Alcatel
e-mail: jeremy.de_clercq@alcatel.be
Sven Van Den Bosch
Alcatel
e-mail: sven.van_den_bosch@alcatel.be
Francis Wellesplein 1
2018 Antwerpen
Belgium
Alban Couturier
Alcatel
e-mail: alban.couturier@alcatel.fr
Ets de Marcoussis R&I/ULC
Route de Nozay
91461 Marcoussis CEDEX, France
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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
De Clercq et al. Expires December 2003 [Page 27]
Internet Draft draft-declercq-vsn-arch-01.txt June 2003
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.
De Clercq et al. Expires December 2003 [Page 28]
