Siva Sivabalan
Francois Le Faucheur
Cisco Systems, Inc.
Raymond Zhang
Infonet Services Corporation
IETF Internet Draft
Expires: December, 2003
Document: draft-sivabalan-diff-te-bundling-02.txt June, 2003
Link Bundling support for
Diff-Serv aware Traffic Engineering
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.
Abstract
This document describes how bandwidth-related MPLS Traffic
Engineering parameters need to be advertised for a bundled link in
order to support Diff-Serv aware Traffic Engineering.
Summary for Sub-IP related Internet Drafts
RELATED DOCUMENTS:
See references.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
This ID is intended for the TEWG.
Link Bundling Support for DS-TE June 2003
WHY IS IT TARGETED AT THIS WG(s)
TEWG is responsible for specifying protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering.
JUSTIFICATION
The TEWG charter states that "This will entail verification and
review of the Diffserv requirements in the WG Framework document and
initial specification of how these requirements can be met through
use and potentially expansion of existing protocols."
In line with this, the TEWG is progressing a Working Group document
specifying protocol extensions for Diff-Serv-aware MPLS Traffic
Engineering.
This ID discusses how these protocol extensions need to be used in
the particular case of bundled links, which are not currently covered
by the Working Group document.
1. Introduction
As defined in [BUNDLE], a Traffic Engineering (TE) link bundle is a
logical entity that represents a group of physical and/or logical TE
links connecting Label Switching Routers (LSRs). The TE links making
up a TE bundle link are called component links. As with ordinary TE
links, TE parameters associated with a bundled TE link are advertised
(e.g., via OSPF) to allow Constraint Based Routing. However, TE
parameters for individual component links are not flooded. As such,
an LSR that is not directly attached to a bundled link views that
bundled link as a single link for path computation purpose.
As stated in [DSTE-REQ] and [DSTE-PROTO], Diff-Serv Traffic
Engineering (DS-TE) provides the capability to engineer network
traffic on a per "class" basis instead of on an aggregate basis. With
DS-TE, CSPF and admission control are done on a per class basis
instead of on an aggregate basis as with ordinary TE. Consequently,
DS-TE requires that certain bandwidth parameters are advertised on a
per class basis. [DSTE-PROTO] specifies how those TE parameters are
advertised on a per class basis on non-bundled links.
[BUNDLE] specifies how to derive TE parameters for a bundled link
from those of its component links. Currently, [BUNDLE] assumes that
traffic engineering is performed on an aggregate basis only.
This document captures the relevant enhancements to [BUNDLE] so that
the necessary TE parameters are advertised on a per-class basis for a
TE link bundle. This allows DS-TE to be supported over bundled links.
Sivabalan, Le Faucheur, and Zhang 2
Link Bundling Support for DS-TE June 2003
2. Terminology
For readability a number of definitions from [DSTE-REQ] are repeated
here:
Class-Type (CT): the set of Traffic Trunks crossing a link that is
governed by a specific set of Bandwidth constraints. CT is used for
the purposes of link bandwidth allocation, constraint based routing
and admission control. A given Traffic Trunk belongs to the same CT
on all links.
TE-Class: A pair of:
i. a Class-Type
ii. a preemption priority allowed for that Class-Type. This
means that an LSP transporting a Traffic Trunk from
that Class-Type can use that preemption priority as the
set-up priority, as the holding priority or both.
3. Bandwidth-related TE parameters
In this section we refine the definitions provided in [BUNDLE] for
bandwidth-related TE parameters that are advertised for bundled
links, in order to support DS-TE on these bundled links.
3.1. Bandwidth Constraints
[DSTE-PROTO] specifies that the existing Maximum Reservable Bandwidth
parameter for a link is retained but its semantic is generalized and
interpreted as the aggregate bandwidth constraints across all Class
Types, independently of the Bandwidth Constraint Model in use (see
[DSTE-REQ] for definition and examples of Bandwidth Constraints
Model). Thus, for DS-TE over bundle link, the Maximum Reservable
Bandwidth for the bundled link in [BUNDLE] is also retained and its
semantic is also generalized and interpreted as the aggregate
bandwidth constraints across all Class Types over bundled link,
independently of the bandwidth constraint model in use.
DS-TE provides support for up to 8 Bandwidth Constraints. Those are
referred to as BC0, BC1, ..., BC7.
For a bundle link, the value of BCi (7 >= i >= 0) can be configured
either separately for each of the component links or for the whole
bundle link. In the former case, the value of BCi for the bundle
equals to the sum of the BCi value for each of the component link.
The set of Bandwidth Constraints applicable to a particular TE-Class
depends on the Bandwidth Constraints Model in use on the link.
Sivabalan, Le Faucheur, and Zhang 3
Link Bundling Support for DS-TE June 2003
The values of BCi for the bundled link MAY be advertised. When
advertised for a bundled link, they MUST be advertised as specified
in [DSTE-PROTO]. In particular, a DS-TE LSR which does advertise
bandwidth Constraints MUST use the new "Bandwidth Constraints" sub-TLV
to do so (in addition to the "Maximum Reservable Bandwidth" sub-TLV).
3.2. Unreserved Bandwidth for TE-class
DS-TE requires that unreserved bandwidth be advertised on a per TE-
class basis.
Unreserved Bandwidth of a bundle link for a given TE-class i (where
7 >= i >= 0) is the sum of the Unreserved Bandwidth for that TE-class
on all the associated component links.
The Unreserved Bandwidth for every active TE-class MUST be advertised
for a bundled link as specified in [DSTE-PROTO] using the Unreserved
Bandwidth sub-TLV (with a generalized definition).
3.3. Maximum LSP Bandwidth
For a simple (unbundled) link its Maximum LSP Bandwidth at priority p
is defined to be the smaller of its unreserved bandwidth at priority
p and a locally configured parameter which we call "Maximum LSP Size".
The default value of Maximum LSP Size is equal to the Max Link
Bandwidth. Maximum LSP Size is not advertised separately because it is
factored into the advertised Maximum LSP Bandwidth. This parameter may
exist merely to enforce an upper bound on the amount of bandwidth
available to a single LSP over a link.
[Editor's notes: we are in discussion with the [GMPLS-ROUTE] authors
in order to update the current Maximum LSP Bandwidth definition in
[GMPLS-ROUTE]in alignment with the text of the previous paragraph.
We hope to get a resolution at the upcoming IETF meeting].
[BUNDLE] defines Maximum LSP Bandwidth for a bundled link on a per
priority basis. It is assumed that Maximum LSP Bandwidth value is
available for each component link, and the Maximum LSP Bandwidth for
a bundle is defined as the Maximum of Maximum LSP Bandwidth among all
component links.
For supporting DS-TE, Maximum LSP Bandwidth must be computable on a
per TE-class basis. Extending the above definitions, we define Maximum
LSP Bandwidth for TE class i (where 7 >= i >= 0) for a component link
as the smaller of the Unreserved Bandwidth for TE class i and the
Maximum LSP Size applicable to TE-class i on that component link. The
method of enforcing Maximum LSP Size for a component link for a given
TE-class is a matter of local policy.
Sivabalan, Le Faucheur, and Zhang 4
Link Bundling Support for DS-TE June 2003
The Maximum LSP Bandwidth for an active TE-class i (where 7 >=i >=0)
on a bundled link is the maximum of the Maximum LSP Bandwidth for the
TE-class i across all of the associated component links.
[GMPLS-ISIS] and [GMPLS-OSPF] currently specify how the Maximum LSP
Bandwidth for each of the 8 preemption priorities are advertised,
respectively in ISIS and OSPF, inside the Interface Switching
Capability Descriptor sub-TLV. For support of DS-TE, each of the
"Maximum LSP bandwidth at preemption i" field (7 >= i >= 0) in that
sub-TLV has its semantic generalized into the "Maximum LSP Bandwidth
for TE-class i". This generalization MAY be used for advertising the
Maximum LSP Bandwidth for each TE-class both on simple (unbundled)
links and on bundled links. Note that when DS-TE is not used, the 8
TE-classes revert to the 8 preemption priorities (of the single
bandwidth constraint) so that the generalized definition above reverts
to the one currently defined in [GMPLS-ISIS] and [GMPLS-OSPF].
4. Bandwidth Accounting
An LSP belonging to TE-class i (where 7 >= i >= 0) with a bandwidth
requirement b fits in a bundled link if at least one component link
has its Maximum LSP bandwidth for TE-class i >= b. If there are
several such links, the choice of which link is used for the LSP is
up to the implementation.
In order to know the Maximum LSP bandwidth for each TE-class on each
component link, the unreserved bandwidth for each TE-class must be
tracked on each component link.
5. Security Considerations
No new security considerations are raised by this document. Those are
the same as the ones discussed in [DSTE-REQ] and in [BUNDLE].
6. Normative References
[BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in
MPLS Traffic Engineering", draft-ietf-mpls-bunle-04.txt, work in
progress.
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-reqts-07.txt,
work in progress.
[DSTE-PROTO] Le Faucheur et al, Protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering, draft-ietf-tewg-diff-te-
proto-04.txt, June 2003.
Sivabalan, Le Faucheur, and Zhang 5
Link Bundling Support for DS-TE June 2003
[GMPLS-ROUTE] Kompella et al, Routing Extensions in Support of
Generalized MPLS, draft-ietf-ccamp-gmpls-routing-05.txt, work in
progress.
[GMPLS-ISIS] Kompella et al, IS-IS Extensions in Support of
Generalized MPLS, draft-ietf-isis-gmpls-extensions-16.txt, work in
progress.
[GMPLS-OSPF] Kompella et al, OSPF Extensions in Support of
Generalized MPLS, draft-ietf-ccamp-ospf-gmpls-extensions-09.txt,
work in progress.
7. Informative References
[DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraint
Model for DS-TE, draft-ietf-tewg-diff-te-russian-03.txt, June 2003.
[DSTE-MAM] Le Faucheur et al, Maximum Allocation Bandwidth Constraint
Model for DS-TE, draft-ietf-tewg-diff-te-mam-01.txt, June 2003.
Authors' Address:
Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario, K2K 3E8
Canada
msiva@cisco.com
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
Email: flefauch@cisco.com
Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90025
USA
Email: raymond_zhang@infonet.com
Sivabalan, Le Faucheur, and Zhang 6