Internet Engineering Task Force Quintin Zhao
Internet-Draft Suresh Babu
Intended status: Standards Track Huawei Technology
Expires: December 3, 2009 Daniel King
Old Dog Consulting
July 3, 2009
Multi-Class DSTE Support for the Path Computation Element Communication
Protocol
draft-zhao-pce-pcep-multiclass-type-dste-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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.
This Internet-Draft will expire on December 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zhao, et al. Expires December 3, 2009 [Page 1]
Internet-Draft Multi-Class DSTE Extension for PCEP June 2009
Abstract
Diffserv-Aware Traffic Engineering (DS-TE) can be used by Service
Providers to perform fine grain bandwidth management of a subset, or
sub-pool, of traffic flows. Typically in DS-TE a diffserv class will
use a single Label Switch Path (LSP) that satisfies the bandwidth
required. Where traffic with different diffserv characteristics must
be mapped to a single LSP. Multi-Class DS-TE can be used to select
an LSP that satisfy the bandwidth requirement of all classes
required.
This document specifies the PCEP extentions to support Multi-Class
Type DS-TE where path computation is performed with the aid of a Path
Computation Element (PCE).
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Chioces to Support the Multi-Class Type Object . . . 4
3.1. Solution Choice 1: Using the Existing Class Type
Object to Support the Multi-Class Type Object . . . . . . 4
3.1.1. Request Message Format Extension . . . . . . . . . . . 4
3.1.2. Processing of CLASSTYPE Object and BANDWITH Object . . 5
3.2. Solution Chioces 2: Adding a new Multi Class DSTE
Object to Support the Multi-Class Type . . . . . . . . . . 6
3.2.1. Request Message Format Extension . . . . . . . . . . . 6
3.2.2. New MULTICLASSDSTE Object Definition . . . . . . . . . 7
3.2.3. Processing of MULTICLASSDSTE Object . . . . . . . . . 8
4. Error Codes for CLASSTYPE Object . . . . . . . . . . . . . . . 9
5. Impact on Network Operation . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Zhao, et al. Expires December 3, 2009 [Page 2]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
1. Terminology
Terminology used in this document
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.
Multiclass LSP: an LSP that can carry several class types.
This document also uses the terminology defined in [RFC4655],
[RFC4875], and [PCEP].
2. Introduction
[RFC5440] specifies the Path Computation Element Communication
Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs, in
compliance with [RFC4657].
[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 some scenarios it is required to allow traffic with different
diffserv behaviors to be mapped to the same LSP and to traffic
engineer the LSP according to the bandwidth constraints for each one
Zhao, et al. Expires December 3, 2009 [Page 3]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
of these classes. In this case, multiple Class-Types are configured
per LSP. For further analysis and explanation of multi-class
diffserv-TE LSPs see [MULTICLASS].
As defined in [RFC4657], PCEP must support traffic Class-Type as an
MPLSTE-specific constraint. As per [RFC5455], it has defined a PCEP
object called CLASSTYPE, which carries the Class-Type of the TE LSP
in the path computation request. During path computation, a PCE uses
the Class-Type to identify the bandwidth constraint of the TE LSP.
But the Class-Type object only applies a single class type to the
computation request.
In this document, we will define extend the class-type object and the
procedures to handle the requirement for the LSP path calculation
which supports multiple class types [MULTICLASS].
3. Solution Chioces to Support the Multi-Class Type Object
There are two possible solutions proposed in this version of the
draft. One solution is that we use the class object defined in
[RFC5044] already and extend the request message to include multiple
of the class type object in the request message and correspondingly
includes multiple of bandwidth objects at the same time.
The second choice is to add a new class type object for the multi
class type. In this case the single class type will be signaled
using the original class type object defined in [RFC5044] and it can
also signal the class type using the new class type object defined
here to signal multi class type or a single class type.
[Editor Note] As this document evolves and working group feedback is
gained, the authors identify and adopt a single solution.
3.1. Solution Choice 1: Using the Existing Class Type Object to Support
the Multi-Class Type Object
Path Computation Request Message with CLASSTYPE Object [RFC5440]
specifies the order in which objects must be inserted in the PCEP
messages. [RFC5044] specifies that the CLASSTYPE object be inserted
after the END-POINT objects to signal a single class type.
3.1.1. Request Message Format Extension
In this solution choice, we propose to expand the request message to
support the multi class types to the following:
Zhao, et al. Expires December 3, 2009 [Page 4]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<classtype-list>]
[<LSPA>]
[<bandwith-list>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]
<classtype-list>::=<CLASSTYPE>[<classtype-list>]
<bandwith-list>>::=<BANDWITH>[<bandwith-list>]
Note that an implementation MUST form the PCEP messages using the
object ordering rules specified using Backus-Naur Form. Please refer
to [OBJ-ORD] for more details.
Figure 1: Extended Request Message Format
3.1.2. Processing of CLASSTYPE Object and BANDWITH Object
If the LSP is associated with m of Class-Type N (0 <= N <= 7), the
PCC originating the PCReq MUST include m of CLASSTYPE objects in the
PCReq message with the Class-Type (CT) field set to its corresponding
class type. If a path computation request contains multiple
CLASSTYPE objects. At the same time,m of BANDWIDTH objects are
needed incldued in the request message.
If the CLASSTYPE object is not present in the path computation
request message, the LSR MUST associate the Class-Type 0 to the LSP.
A path computation reply message MUST NOT include a CLASSTYPE object.
If a PCE needs to forward a path computation request containing a
number of CLASSTYPE objects to another PCE, it MUST store the Class-
Type of the TE LSP in order to complete the path computation when the
path computation reply arrives.
A PCE that does not recognize the CLASSTYPE object MUST reject the
entire PCEP message and MUST send a PCE error message with Error-
Zhao, et al. Expires December 3, 2009 [Page 5]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
Type="Unknown Object" or "Not supported object", defined in
[RFC5440].
A PCE that recognizes the CLASSTYPE object, but finds that the P flag
is not set in the CLASSTYPE object, MUST send PCE error message
towards the sender with the error type and error value specified in
[RFC5440].
A PCE that recognizes the CLASSTYPE object, but does not support the
particular Class-Type, MUST send a PCE error message towards the
sender with the error type "Diffserv-aware TE error" and the error
value of "Unsupported Class-Type" (Error-value 1).
A PCE that recognizes the CLASSTYPE object, but determines that the
Class-Type value is not valid, MUST send a PCE error towards the
sender with the error type "Diffserv-aware TE error" and an error
value of "Invalid Class-Type" (Error-value 2).
3.2. Solution Chioces 2: Adding a new Multi Class DSTE Object to
Support the Multi-Class Type
3.2.1. Request Message Format Extension
In this solution chioce, we propose to expand the request message to
support the multi class types to the following:
Zhao, et al. Expires December 3, 2009 [Page 6]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<CLASSTYPE>]
[<MUTICLASSDSTE>]
[<LSPA>]
[<BANDWITH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]
The defination of the MULTICLASSDSTE is explained in the next section in detail.
Note that an implementation MUST form the PCEP messages using the
object ordering rules specified using Backus-Naur Form. Please refer
to [OBJ-ORD] for more details.
Figure 2: Extended Request Message Format
3.2.2. New MULTICLASSDSTE Object Definition
The MULTICLASSDSTE object contains a 32-bit word PCEP common object
header defined in [RFC5440] followed by another one pair or more but
not more than 8 pair of 32-bit word object body for the class type
and the bandwidth body for each class type:
Zhao, et al. Expires December 3, 2009 [Page 7]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCEP common header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | bitmap of CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BW requested for CT1 (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Muti CLass DSTE Object
The fields in the common object header are processed as specified in
[RFC5440]. The values of object class and object type are to be
defined, respectively. If included, the MULTICLASSDSTE object must
be taken into account by the PCE. As such, the P flag MUST be set.
The I flag is ignored.
The MULTICLASSDSTE object body contains the following fields:
o Bit map of CT: 8-bit field that indicates each Class-Type. Each
"bit" represents the presence of request for the CT. For example,
if the bitmap is 00011010, that indicates CT1, CT3, CT4.
o Reserved: 24-bit reserved field. It MUST be set to zero on
transmission and MUST be ignored on receipt.
o BW: The bandwidth request is for 32-bit IEEE floating point
number. The number of the requested BW and the order of the BW
requested are corresponding to the bitmap. For example, if the
bitmap is 00011010, then there will be three BWs and they are in
the order of BW1 for CT1, BW3 for CT3 and BW4 for CT4.
3.2.3. Processing of MULTICLASSDSTE Object
If the LSP is associated with m of Class-Type N (0 <= N <= 7), the
PCC originating the PCReq MUST include a MULTICLASSDSTE object in the
PCReq message with m Class-Type (CT) field set to its corresponding
class type and with the corresponding bandwidth requested for each
CT.
Zhao, et al. Expires December 3, 2009 [Page 8]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
If the CLASSTYPE object and MULTICLASSDSTE are present in the path
computation request message, A PCE MUST send PCE error message
towards the sender with the error type and error value specified in
the later section of the document.
If the CLASSTYPE object and MULTICLASSDSTE are not present in the
path computation request message, the LSR MUST associate the Class-
Type 0 to the LSP. A path computation reply message MUST NOT include
a CLASSTYPE object.
If a PCE needs to forward a path computation request containing a
number of CLASSTYPE objects to another PCE, it MUST store the Class-
Type of the TE LSP in order to complete the path computation when the
path computation reply arrives.
A PCE that does not recognize the MULTICLASSDSTE object MUST reject
the entire PCEP message and MUST send a PCE error message with Error-
Type="Unknown Object" or "Not supported object", defined in
[RFC5440].
A PCE that recognizes the MULTICLASSDSTE object, but finds that the P
flag is not set in the CLASSTYPE object, MUST send PCE error message
towards the sender with the error type and error value specified in
[RFC5440].
A PCE that recognizes the MULTICLASS object, but does not support the
particular Class-Type, MUST send a PCE error message towards the
sender with the error type "Diffserv-aware TE error" and the error
value of "Unsupported Class-Type" (Error-value 1).
A PCE that recognizes the MULTICLASS object, but determines that the
Class-Type value is not valid, MUST send a PCE error towards the
sender with the error type "Diffserv-aware TE error" and an error
value of "Invalid Class-Type" (Error-value 2).
4. Error Codes for CLASSTYPE Object
TBD
5. Impact on Network Operation
It is expected that use of PCEP extensions specified in this document
does not have significant impact on network operations.
Zhao, et al. Expires December 3, 2009 [Page 9]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
6. Security Considerations
It is expected that use of PCEP extensions specified in this document
does not have significant impact on Securitiy.
7. IANA Considerations
A number of IANA considerations have been highlighted in the relevent
sections of this document. Further clarifications of these requests
will be made in a future version of this document.
8. Acknowledgement
The authors would like to thank P Shastry for his inputs in this
draft.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5044] Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
Carrier, "Marker PDU Aligned Framing for TCP
Specification", RFC 5044, October 2007.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5455] Sivabalan, S., Parker, J., Boutros, S., and K. Kumaki,
Zhao, et al. Expires December 3, 2009 [Page 10]
Internet-Draft Multi Class DSTE Support for PCEP June 2009
"Diffserv-Aware Class-Type Object for the Path Computation
Element Communication Protocol", RFC 5455, March 2009.
9.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[MULTICLASS] Minei, I., et al., "Extensions for Differentiated
Services-aware Traffic Engineered LSPs", draft-minei-
diffserv-te-multi-class, work in progress.
Authors' Addresses
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: qzhao@huawei.com
Suresh Babu
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
Email: sureshbr@huawei.com
Daniel King
Old Dog Consulting
Email: daniel@olddog.co.uk
Zhao, et al. Expires December 3, 2009 [Page 11]
Internet-Draft Multi Class DSTE Support for PCEP June 2009