Internet DRAFT - draft-minei-diffserv-te-multi-class
draft-minei-diffserv-te-multi-class
Network Working Group Ina Minei
Internet Draft Der-Hwa Gan
Expiration Date: December 2006 Kireeti Kompella
Category: Informational Juniper Networks
Xiaoming Li
China Unicom
June 2006
Extensions for Differentiated Services-aware Traffic Engineered LSPs
draft-minei-diffserv-te-multi-class-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 specifies the extensions necessary to set up multi-
class diffserv-aware traffic engineered label switched paths (LSPs).
A multi-class diffserv-te LSP carries traffic from multiple traffic
classes and is set up along a path that satisfies the bandwidth
constraints defined for each of the classes it carries.
Minei, et al. [Page 1]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
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 [RFC2119].
Table of Contents
1 Definitions ........................................... 3
2 Introduction .......................................... 3
3 Setup and holding preemption priorities ............... 4
4 Setting up multi-class RSVP-signaled LSPs ............. 5
4.1 The extended classtype object ......................... 5
4.2 RSVP signaling ........................................ 6
4.3 RSVP error processing ................................. 7
5 The extended-MAM bandwidth constraints model .......... 8
6 IGP extensions ........................................ 8
7 Migration issues ...................................... 8
8 Security considerations ............................... 9
9 Intellectual Property Statement ....................... 9
10 Acknowledgments ....................................... 9
11 References ............................................ 9
11.1 Normative References .................................. 10
12 Authors' Addresses .................................... 10
Full Copyright Statement .............................. 11
Minei, et al. [Page 2]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
1. Definitions
For readability a number of definitions from [RFC3564] are repeated
here:
Traffic Trunk: an aggregation of traffic flows of the same class
[i.e. which are to be treated equivalently from the DS-TE perspec-
tive] which are placed inside a Label Switched Path.
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:
1. a Class-Type
2. 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.
2. Introduction
[RFC4124] defines the protocol extensions for setting up diffserv-
aware traffic engineered LSPs. An LSP set up according to [RFC4124]
carries traffic from a single diffserv class and is set up along a
path that satisfies the bandwidth constraints specified for this
class. In this case, a single Class-Type is configured per LSP. In
the rest of this document such an LSP is called single-class diff-
serv-TE LSP. Note that from a diffserv point of view, a single-class
LSP can be either an L-LSP or an E-LSP (as defined in [RFC3270]).
In some scenarios it is required to allow traffic with different
diffserv behaviors to be mapped to the same LSP and to traffic engi-
neer the LSP according to the bandwidth constraints for each one of
these classes. In this case, multiple Class-Types are configured per
LSP. In the rest of the document such an LSP is called a multi-class
diffserv-TE LSP. From a diffserv point of view, a multi-class LSP is
always an E-LSP.
An example scenario for multi-class LSPs comes in the context of ATM
trunk emulation using MPLS LSPs. In this case, it is preferable to
have all the traffic classes following the same path and exhibit the
same behavior in case of failure.
Another application of multi-class diffserv-TE LSPs is for reducing
Minei, et al. [Page 3]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
the number of LSPs in a network by setting up reservations for sev-
eral classes in one LSP rather than one reservation per class. With
single class LSPs, the total number of LSPs in the network is equal
to the number of classes times the number of LSPs in the mesh. With
multi-class LSPs, the total number of LSPs is equal to the size of
the LSP mesh. The reduction in the number of LSPs is important from a
scaling and manageability point of view.
Here are a few observations regarding single-class and multi-class
LSPs:
o An LSP that is signaled using the extensions defined in this doc-
ument is not required to request bandwidth from multiple Class-
Types. As a special case, when the request is from a single
Class-Type, the LSP behaves as a single-class LSP and from a
diffserv point of view can be either an L-LSP or an E-LSP. There-
fore, conceptually, multi-class LSPs are a superset of single-
class LSPs.
o In order to achieve bandwidth reservation from several traffic
classes, two approaches can be taken: 1) create one multi-class
LSP or 2) create several single-class LSPs. Note however that the
two approaches have different properties in terms of: the number
of LSPs established, the path that is taken by traffic belonging
to different classes and the fate sharing between the different
classes. The choice of single-class or multi-class LSP is made
based on the requirements of the application and on the network
design.
o Both single-class and multi-class LSPs must integrate smoothly
with non-diffserv-te LSPs.
3. Setup and holding preemption priorities
As per existing TE, multi-class LSPs can be configured with a setup
and holding priority, each with a value between 0 and 7. The combi-
nation of the setup priority and each of the Class-Types for which
the multi-class LSP is set up and of the hold priority and each of
the Class-Types for which the multi-class LSP is set up, MUST be such
that together they form one of the (up to) 8 TE-Classes configured in
the TE-Class Mapping. This requirement is similar to the requirement
spelled out in [RFC4124] regarding the combination of priority and
class-type for single-class LSPs.
Minei, et al. [Page 4]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
4. Setting up multi-class RSVP-signaled LSPs
4.1. The extended classtype object
To request LSP setup along a path with bandwidth constraints from
more than one Class-Type, a new object is defined, the extended-
classtype-object. This object has a class_num that ensures that a
node that doesn't recognize it will reject it and return an "Unknown
Object Num" error. According to the guidelines in [RFC3936], the val-
ues used are class_num 124 and "class class_type" 1.
The contents are a set of subobjects, each encoded as a TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subobjects |
. ... .
. ... .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ | CTi |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BW requested for CTi (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits
The length contains the total length of the subobject in
bytes, including the type, length, mbz, CTi fields.
The length MUST be at least 8, and MUST be a multiple of 4.
Type : 8 bits
The type of the contents of the subobject. Currently defined
value is
1 - bandwidth
MBZ: 3 bits
This field is reserved. It must be set to zero on transmission
and must be ignored on receipt.
CT : 3 bits
Minei, et al. [Page 5]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
Indicates the Class-Type. Values currently allowed are 0, 1,
2, ... , 7. Note that this is different from the definition
given in [RFC4124] where the value 0 is not allowed.
BW requested : 32 bits
Indicates the number of bytes (not bits) per second that need
to be reserved for the CT indicated.
4.2. RSVP signaling
The extended-classtype object is signaled in the PATH message, and
saved in the PSB at every hop. The extended-classtype object MUST NOT
be included in a RESV message.
The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <TIME_VALUES> [
<EXPLICIT_ROUTE> ]
<LABEL_REQUEST> [ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <EXTENDED_CLASSTYPE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
When the classtype object is present, the values in the tspec are
ignored for admission control purposes and SHOULD be 0.
Admission control is performed for the requirements specified in each
of the (CT, BW) pairs in the extended-classtype object. Admission
control succeeds only if the requirements for all the (CT, BW) pairs
are satisfied.
Merging MUST NOT be performed among reservations that belong to LSPs
for which the extended-classtype object was signaled.
If the extended-classtype object is not present in the PATH message,
the LSR associates the LSP with CT0 and performs admission control
from the bandwidth/priority values for CT0. In the case where the LSP
is from a single class, and the class is CT0, the extended-classtype
Minei, et al. [Page 6]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
object MAY be included in the PATH message.
4.3. RSVP error processing
If the extended-classtype object is not understood, an "Unknown
Object Num' error is returned.
An LSR that recognizes the extended-classtype object and that
receives a path message which contains the extended-classtype object
but which does not contain a LABEL_REQUEST object or which does not
have a session type of LSP_Tunnel_IPv4, MUST send a PathErr towards
the sender with the error code 'extended-classtype Error' and an
error value of 'Unexpected extended-classtype object'. These are
defined below.
An LSR receiving a Path message with the extended-classtype object,
which recognizes the object but does not support the particular
Class-Type, MUST send a PathErr towards the sender with the error
code 'extended-classtype Error' and an error value of 'Unsupported
Class-Type'.
An LSR receiving a Path message with the extended-classtype object,
which:
- recognizes the object,
- supports the particular Class-Type, but
- determines that the tuple formed by (i)this Class-Type and (ii)
the holding priority signaled in the same Path message, is not
one of the eight TE-classes configured in the TE-class mapping,
MUST send a PathErr towards the sender with an error value of 'CT and
holding priority do not form a configured TE-Class'. For setup prior-
ity, return 'CT and setup priority do not form a configured TE-class'
The error checking ensures that multi-class LSPs get established only
through LSRs that support multi-class diffserv-te LSPs and have con-
sistent TE-mappings with the ingress.
Errors related to the processing of the extended-classtype-object are
reported using the vendor-specific Error-Code "extended-classtype-
error" 252. The first four octets following the Error Value are 2636
- the vendor's SMI enterprise code in network octet order (as
required by [RFC3936])
The error values are the same as defined in [RFC4124] for the
classtype object. The values 3, 6, 7 are not used with multi-class-
LSPs.
Minei, et al. [Page 7]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
5. The extended-MAM bandwidth constraints model
A new BC model-id is defined, the extended-mam bandwidth model, with
value 254. The extended-mam model has the same behavior as the MAM
model [RFC4125].
6. IGP extensions
[RFC4124] defines the bandwidth-constraint (BC) sub-tlv. The BC sub-
tlv includes the bandwidth model and a list of bandwidth-constraints.
In [RFC4124], the semantic of the "Unreserved Bandwidth" sub-TLV is
changed such that the eight bandwidth values advertised correspond to
the unreserved bandwidth for each of the TE-Class (instead of for
each preemption priority as per existing TE). This approach has two
drawbacks:
o It creates a flag day in the network with regards to the existing
TE LSPs set up without any diffserv properties, as explained in
[RFC4124].
o It requires that LSPs from CT0 be set up at priorities such that
the combination of (CT0, priority) is one of the configured TE-
classes. Thus, the priorities asssigned to pre-existing CT0 LSPs
use up some of the TE-classes.
In the method documented here, when the bandwidth-model is extended-
mam, the semantic of the "Unreserved Bandwidth" sub-TLV is the same
as in existing TE and the bandwidth available per TE-class is adver-
tised in the BC sub-tlv. This approach achieves the following:
o There is no interference between the diffserv-aware LSPs and the
plain TE LSPs
o There are no migration issues when deploying this feature in a
network where TE LSPs are deployed.
o A total of 16 TE-classes are effectively created.
7. Migration issues
Since the semantics of the "Unreserved Bandwidth" sub-TLV are main-
tained unchanged, there are no migration issues when deploying multi-
class LSPs in a network where traffic engineering is already in use.
Single-class and multi-class LSPs cannot co-exist in the same net-
work. When both the multi-class and the single-class functionality
is required, the semantics of single-class LSPs can be provided by
the multi-class LSPs.
Minei, et al. [Page 8]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
8. Security considerations
The same security considerations apply as for single-class diffserv-
TE LSPs [RFC4124].
9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assur-
ances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
10. Acknowledgments
This work is the outcome of discussions with Arthi Ayyangar and Chai-
tanya Kodeboyina. The authors would like to thank them for their
suggestions and insight. The authors would like to thank Yakov
Rekhter and Peter Busschbach for their review.
11. References
Minei, et al. [Page 9]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.
[RFC3270] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270.
[RFC3564] Le Faucheur et al, "Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering", RFC3564.
[RFC3936] Kompella, K., Lang, J., "Procedures for Modifying the
Resource reSerVation Protocol (RSVP)", RFC3936.
[RFC4125] Le Faucheur, Lai, "Maximum Allocation Bandwidth Constraints
Model for DS-TE", RFC4125.
[RFC4124] Le Faucheur et al, "Protocol extensions for support of
Diff-Serv-aware MPLS Traffic Engineering", RFC4124.
12. Authors' Addresses
Ina Minei
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: ina@juniper.net
Der-Hwa Gan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: dhg@juniper.net
Kireeti Kompella
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089
e-mail: kireeti@juniper.net
Xiaoming Li
China United Telecommunications Corporation
No.133A, Xidan North Street,
Xicheng District, Beijing 100032, China
email: lixm@chinaunicom.com.cn
Minei, et al. [Page 10]
Internet Draft draft-minei-diffserv-te-multi-class-02.txt June 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Additional copyright notices are not permitted in IETF Documents
except in the case where such document is the product of a joint
development effort between the IETF and another standards development
organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on
an individual basis by the IAB.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Minei, et al. [Page 11]
