Internet DRAFT - draft-ganti-tewg-diffserv-multicos-elspreq
draft-ganti-tewg-diffserv-multicos-elspreq
S. Ganti
N. Seddigh
B. Nandy
Tropic Networks
N. Harrison
BT
INTERNET DRAFT S. Choudhury
Internet Engineering Task Force Marconi
Traffic Engineering Working Group
Expires August, 2002 February, 2002
DS-TE Requirements for Support of multiple-COS on an E-LSP
<draft-ganti-tewg-diffserv-multicos-elspreq-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Abstract
The current DS-TE requirements document [DSTEREQ] focuses on
solutions that enable carrying a single Class of Service on an LSP.
This document extends the work in [DSTEREQ] by motivating the need to
support a DS-TE solution that enables multiple COS on an E-LSP. The
document further defines the requirements for such an approach.
The requirements are developed such that this approach would be an
optional extension to the existing DS-TE.
1.0 Introduction
Recently there have emerged a number of initiatives with the goal of
improving on the current best-effort service model delivered by IP
networks. Traffic Engineering (TE) is one key element in the tool-kit
to deliver such improved service. Initial TE solutions [TEREQ] used
MPLS (Multi-Protocol Label Switching) [MPLSARCH] to steer best-effort
traffic away from shortest-path congested links. Such an approach is
intended to distribute load across the network and improve overall
network performance.
At the same time, DiffServ [DSARCH] has defined a number of traffic
conditioning mechanisms and Per-Hop-Behaviour which can be combined
to provide QoS assurance and multiple classes of service in IP
networks. The Diff-Serv approach has recently been extended to enable
multiple classes of service to be carried over a single LSP
[DIFFMPLS]. [DIFFMPLS] defines two types of LSPs to support DiffServ
over MPLS: E-LSPs (EXP-inferred-LSPs) and L-LSPs (Label-Only-
Inferred-LSPs). The L-LSP approach is intended to carry a single
class of traffic per LSP. LSRs use per-LSP state information to
determine the PHB to apply against packets of an LSP. E-LSPs allow
multiple classes of traffic to be carried over a single LSP. In this
case, the MPLS Label-Stack-Entry EXP bits indicate the PHB to be
applied against a particular packet. DS-TE using E-LSPs.
DiffServ-Aware Traffic Engineering (DS-TE) combines Diffserv and
Traffic Engineering in an effort to provide end-to-end service
guarantees within an MPLS network. Incoming traffic is mapped to
paths within the network that satisfy certain engineering constraints
on a per-class basis.
The current DS-TE Requirements document [DSTEREQ] focuses on the
requirements to support carrying a single class of traffic on LSPs.
This document expands on [DSTEREQ] to discuss the DS-TE requirements
to carry multiple classes of traffic on an LSP. We also elaborate and
consider various application scenarios where it may be desirable to
support DS-TE with multiple classes of traffic on an LSP. It is
understood that not all DS-TE networks will want to support multiple
classes of traffic per LSP. As such the requirements defined herein
are intended to be optional and to co-exist with [DSTEREQ].
The terms class and OA (ordered aggregate) are used inter-changeably
throughout this document.
2.0 Current DS-TE Requirements
[DSTEREQ] presents the service provider requirements for support of
Diff-serv aware traffic engineering using the LSPs. While [DSTEREQ]
discusses requirements for a network with multiple classes of
service, it focuses on using LSPs that carry essentially a single
class of service. In certain parts of the document it discusses use
of LSP with multiple classes of service however, for the purposes of
TE (route advertisements, MPLS signalling path computation and
admission control), these multiple classes are treated as a single
class.
Five possible options exist in relation to the usage of L-LSPs and
E-LSPs in a general DS-TE framework:
a) Using E-LSPs to carry traffic entirely from a single OA
b) Using E-LSPs to carry traffic for multiple OAs all sharing a
single set of traffic parameters and with single set of
pre-emption/protection attributes
c) Using E-LSPs to carry traffic from multiple OAs, each with
their own set of traffic parameters but with single set of
pre-emption/protection attributes.
d) Using E-LSPs to carry traffic from multiple OAs, each with
their own set of traffic parameters and pre-emption/protection
attributes.
e) Using L-LSP to carry traffic from a single OA
[DS-TE-REQ] describes mapping of single-OA traffic on to MPLS
tunnnels using options (a) and (e). It allows support for carrying
multiple-OA traffic using option (b) on an aggregate basis only. i.e
with a single set of constraints and thus to treat all the OAs as a
single class for the purposes of TE. The document does not discuss
options (c) and (d).
At the current time, it does not appear that there is any interest in
supporting option (d) as pre-emption priorities apply to the entire
LSP and not to a subset of traffic on that LSP.
This document therefore presents the requirements to support option
(c) above as an extension to [DSTEREQ]. The following section focuses
on various application scenarios where it may be desirable to utilize
the approach of (c).
3.0 DS-TE Application Scenarios - Multiple COS per LSP
There are a number of good reasons why service providers are
interested in using DS-TE to carry multiple classes of service on an
LSP. The key reaons can be summarized as follows:
a) Ability to carry multiple classes of a single customer
traffic on the same LSP
b) Reduction in number of LSPs in the network (one LSP instead
of "x" LSPs to carry "x"classes)
c) One DS traffic pipe that is easy to manage, apply path protection
and restoration capabilities.
The following are application scenarios where E-LSPs can be used in a
DS-TE framework to carry multiple classes of traffic each with their
own set of BW constraints.
3.1 Using E-LSPs based on aggregate traffic requirements:
An MPLS/IP network may desire to carry its VoIP data and signalling
on the same LSP yet treat the two traffic types as two different
classes. For example, it may want to map its VoIP data to be treated
by the EF PHB and the VoIP signaling to be treated by the AF1x PHB.
In such cases, the provider will likely not want to send the VoIP
data and signaling on different LSPs as they may have different delay
behaviour.
It can be argued that if the ratio of two different traffic types is
known/constant then it can be carried on multiple OAs but signalled
with a single traffic parameter and advertised with a single
advertisement. However, such a scheme is extremely inflexible.
Applications continually evolve as may the ratio of traffic mixes.
Thus, it is unwise to embed assumptions about application behaviour
in the DS-TE solutions.
3.2 Using E-LSPs with multiple class bandwidth requirements
A second example involves the use of Layer 2 VPNs. In this context,
service providers in the Metro space are looking to provide TLS
(Transparent LAN) services. The SP may provide Layer 2 VPNs for its
end customers where the key SLAs revolve around availability and QoS.
In such cases, the SLA may specify a single protection level for the
entire customer aggregate while specifying multiple classes of
service within the VPN aggregate. In such networks, sending different
classes of service on different LSPs will immensely complicate the
ability to offer robust and measurable availability and QoS SLAs to
such customers. Hence it is desirable to carry all the customer's
classes of traffic on a single LSP and yet to treat each class
differently.
A third example relates to an application where a service provider
wishes to provide bandwidth borrowing between the different classes
of traffic for a specific customer. Thus, service providers may want
to provide SLA gurantees for each of the classes carried in the E-
LSP. In addition, at the same time, the provider may wish to apply
queuing technology that allows bandwidth borrowing between the OAs of
a customer. Thus, if a customer is not using his allocated AF
capacity, he may wish to allow his BE traffic to use that capacity
that he has purchased from the service provider.
3.3 Using E-LSPs to reduce number of LSPs in the network
A fourth example relates to path protection and restoration which are
2 key requirements in next generation IP networks. Sending a single
customer's traffic on multiple LSPs causes a larger number of LSPs in
the network. It also causes issues with ensuring that the SONET like
restoration times are met due to the sheer volume of LSPs that have
to be resignalled or redialed when links go down. These mechanisms
are more easily applied to a single LSP than to a group of LSPs.
Yet another application scenario, as a fifth example could be, the
case of a small service provider with a simple network topology and a
limited set of service classes. Such a provider could be interested
in limited DS-TE capabilities (i.e. simple aggregate load balancing).
In this case, a simple path computation algorithm that routes all
classes together can be used to select a single LSP (e.g. a shortest
path applied on the pruned network). Limiting each LSP to only a
single OA would, at minimum, double the number of LSPs in the network
- which may be highly undesirable for the SP.
Another key benefit of E-LSPs has to do with scalability. L-LSP or
single OA per E-LSP will cause the number of LSPs in the network to
increase by a factor of at least two and in some cases, three, four
or larger. The number of LSPs is a scalability concern for a number
of reasons. Firstly, it increases the time required during hitless
restart. Secondly, it is of concern for RSVP state management.Another
important advantage of E-LSPs is in the area of network maintenance
and administration. When trouble-shooting issues related to a
customer's traffic, it is easier for the network operator to examine
a single LSP instead of multiple LSPs.
4.0 Technical Requirements To Support DS-TE with multiple COS per LSP
In general, the requirements to support DS-TE with multiple COS can
be considered as extensions to the existing requirements. To support
such an approach, the following are required:
(i) IGP extensions to advertise reserved or available
bandwidth on a per-OA, PSC or per-class or per-ClassType basis for
each link.
(ii) A path computation algorithm that computes a path at the LER
(iii) Extensions to allow signaling of per-class parameters
within an E-LSP
(iv) A Pre-emption priority (setup and hold) which is applied
to the whole E-LSP together (not per-OA).
(v) Admission Control is applied per-class per-link when the E-LSP
is signalled.
(vi) Traffic Conditioning is applied at the LER against traffic
mapped to the E-LSP.
(vii) EXP bits are used to signal the PHB treatment
for individual packets within the E-LSP
(viii) Diffserv PHB mechanisms are used in LSR routers
to differentially treat the traffic within a
single E-LSP.
There are no new requirements for IGP protocol extensions other than
the one already described in the document Protocol extensions for
support of DS-TE [DSPROTO].
Requirement (ii) is typically satisfied by a proprietary
implementation by vendor devices. When setting up an E-LSP, the path
is computed based on the available resources in the network and the
path that fits best the resource requirements of all the OAs
together, i.e, the path computation procedure has to a take a
bandwidth vector of all OAs, bandwidth vector of all available link
bandwidths per-OA and compute the path based on certain constraints.
Requirement (iii) is discussed in section 4.1 below. The per-OA
signaling is needed for proper bandwidth accounting and to advertise
available resources in the node to the network.
Requirement (iv), (v), (vi), (vii) and (viii) are currently addressed
by the mechanisms specified in [DIFF-MPLS].
4.1 LSP Signalling Extensions
The current Diffserv-MPLS extensions allow only a single set of
traffic parameters to be signalled per LSP. e.g in RSVP-TE, it is
allowable to signal only a single Tspec. To support E-LSP, the
signalling protocols need to be extended to allow specification of
multiple traffic parameters. Further, there needs to be a means of
mapping these traffic parameters to an OA, PSC or class.
There exist two current proposals to address this issue: [GANTI] and
[IOVANNA].
This document uses the terms BA, OA, PSC, E-LSP, L-LSP, and PHB as
they are defined in [DIFF-MPLS] and [DIFFTERM].
5.0 Other Requirements
The following are additional requirements for solutions to support
multiple COS on DS-TE:
(i) Any protocol extensions should be optional.
(ii) The solution should be an extension of the current [DSTEREQ]
documents
(iii) The solution should be backwards compatible with DS-TE, TE
and Diffserv
(iv) It should not introduce major scalability issues above and
beyond what is introduced by the current DS-TE
(v) It should allow dynamic adjustment of parameters for the
LSR's scheduler
(vi) It should satisfy the application scenarios outlined in [DSTEREQ]
6.0 Security Considerations
This document does not introduce any new security issues beyond those
inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms
proposed for those technologies.
7.0 References
[TEREQ] Awduche D et al, "Requirements for Traffic Engineering
Over MPLS", RFC 2702, January 2001
[DIFFMPLS] Rosen E et al, "MPLS Support of Differentiated Services"
draft-ietf-mpls-diff-ext-08.txt, February 2001.
[DIFFTERM] Grossman D, "New Terminology for Diffserv", Internet
Draft, draft-ietf-diffserv-new-terms-04.txt, March 2001
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", Internet draft,
<draft-ietf-mpls-rsvp-lsp-tunnel-08.txt>, February 2001
[CR-LDP] Jamoussi et al, "Constraint-Based LSP Setup using LDP",
Internet Draft, draft-ietf-mpls-cr-ldp-05.txt,
February 2001.
[PHBID] Brim S et al, "Per Hop Behaviour Identification Code",
RFC 2836, May 2000.
[MPLSARCH] Rosen E et al, "Multi-Protocol Label Switching
Architecture", RFC 3031, January 2001
[DSTEREQ] Le Faucheur F et al, "Requirements for support of Diff-
Serv-aware MPLS Traffic Engineering",
draft-ietf-tewg-diff-te-reqts-03.txt, February 2002.
[DS-PROTO] Le Faucheur F et al, "Protocol Extensions for support of
Diffserv-Aware MPLS Traffic Engineering,
draft-ietf-tewg-diff-te-proto-00.txt, February 2002
[GANTI] Ganti, Seddigh, Nandy, "MPLS Support of Differentiated
Services using E-LSP",
draft-ganti-mpls-diffserv-elsp-01.txt, November 2001.
[IOVANNA] Iovanna, et al, "Definition of the MPLS FlowSpec for
RSVP-TE",
draft-iovanna-rsvp-mpls-flowspec-00.txt, October 2001.
8.0 Author's Address
Sudhakar Ganti
Tropic Networks Inc.
135 Michael Cowpland Drive
Kanata, Ontario, Canada, K2M 2E9
Email: sganti@tropicnetworks.com
Nabil Seddigh
Tropic Networks Inc.
135 Michael Cowpland Drive
Kanata, Ontario, Canada, K2M 2E9
Email: nseddigh@tropicnetworks.com
Biswajit Nandy
Tropic Networks Inc.
135 Michael Cowpland Drive
Kanata, Ontario, Canada, K2M 2E9
Email: bnandy@tropicnetworks.com
Sanjaya Choudhury
Marconi
Email: sanjaya.choudhury@marconi.com
Neil Harrison
British Telecom
Heath Bank, Iugby Road, Harleston
South Hampton, UK
Email: neil.2.Harrison@bt.com
