Skip to main content

Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5455.
Authors Kenji Kumaki , Jon Parker , Sami Boutros , Siva Sivabalan
Last updated 2020-01-21 (Latest revision 2008-11-03)
Replaces draft-sivabalan-pce-dste
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5455 (Proposed Standard)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Ross Callon
Send notices to (None)
Network Working Group                                  S. Sivabalan, Ed. 
Internet Draft                                                 J. Parker 
Intended status: Standards Track                              S. Boutros 
Expires: May 2, 2009                                 Cisco Systems, Inc. 
                                                               K. Kumaki 
                                                        KDDI Corporation 
                                                        November 3, 2008 
                   Diff-Serv Aware Class Type Object for  
              Path Computation Element Communication Protocol 

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-

   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 

   The list of Internet-Draft Shadow Directories can be accessed at 

   This Internet-Draft will expire on May 2, 2009. 

Copyright Notice 

   Copyright (C) The IETF Trust (2008). 




Sivabalan                Expires May 3, 2009                   [Page 1] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 


   This document specifies a CLASSTYPE object to support Diff-Serve 
   Aware Traffic Engineering (DS-TE) where path computation is performed 
   with an aid of Path Computation Element (PCE).  

Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   document are to be interpreted as described in RFC-2119 Error! 
   Reference source not found.. 

Table of Contents 

   1. Introduction...................................................2 
   2. Terminology....................................................3 
   3. CLASSTYPE Object...............................................4 
      3.1. Object Definition.........................................4 
      3.2. Path Computation Request message with CLASSTYPE Object....4 
      3.3. Processing CLASSTYPE Object...............................5 
      3.4. Determination of Traffic Engineering Class (TE-Class).....6 
      3.5. Significance of Class-Type and TE-Class...................6 
      3.6. Error Codes for CLASSTYPE Object..........................6 
   4. Security Considerations........................................7 
   5. IANA Considerations............................................7 
   6. Acknowledgments................................................7 
      6.1. Normative References......................................8 
      6.2. Informative References....................................8 
   Author's Addresses................................................8 
   Intellectual Property Statement...................................9 
   Disclaimer of Validity............................................9 
1. Introduction 

   The Internet Draft [PCEP-ID] 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].  

   Differentiated Service aware MPLS Traffic Engineering (DS-TE) 
   addresses the fundamental requirement to be able to enforce different 
   bandwidth constraints for different classes of traffic. It describes 
   mechanisms to achieve per-class traffic engineering, rather than on 
   an aggregate basis across all classes by enforcing Bandwidth 
   Constraints (BCs) on different classes. Requirements for DS-TE and 
Sivabalan                Expires May 3, 2009                   [Page 2] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 

   the associated protocol extensions are specified in [RFC3564] and 
   [RFC4124] respectively. 

   As per [RFC4657], PCEP must support traffic class-type as an MPLS TE 
   specific constraint. However, in the present form, PCEP [PCEP-ID] 
   does not have the capability to specify the class-type in the path 
   computation request. 

   In this document, we define a new 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. 

2. Terminology 

   CT: Class type: A set of Traffic Trunks governed by a set of 
   bandwidth constraints. Used for the purpose of link bandwidth 
   allocation, constraint based routing and admission control. A given 
   Traffic Trunk belongs to the same CT on all links. 

   DS-TE: Diff-Serv Aware Traffic Engineering. 

   LSR: Label Switching Router. 

   LSP: Label Switched Path. 

   PCC: Path Computation Client: any client application requesting a 
   path computation to be performed by a Path Computation Element. 

   PCE: Path Computation Element: an entity (component, application or 
   network node) that is capable of computing a network path or route 
   based on a network graph and applying computational constraints. 

   PCEP Peer: an element involved in a PCEP session (i.e. a PCC or the 

   TE-Class: A pair consisting of a class-type and a preemption priority 
   allowed for that class type. An LSP transporting a Traffic Trunk from 
   that class type can use that preemption priority as the setup 
   priority, the holding priority, or both. 

   TE LSP: Traffic Engineering Label Switched Path. 

   Traffic Trunk: An aggregation of traffic flows of the same class 
   (i.e. treated equivalently from the DS-TE perspective) which is 
   placed inside a TE LSP. 

Sivabalan                Expires May 3, 2009                   [Page 3] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 

3. CLASSTYPE Object 

   The CLASSTYPE object is optional and is used to specify the class-
   type of a TE LSP. This object is meaningful only within the path 
   computation request, and is ignored in the path reply message. If the 
   TE LSP for which the path is to be computed belongs to Class 0, the 
   path computation request MUST NOT contain the CLASSTYPE object. This 
   allows backward compatibility with PCE that does not support the 
   CLASSTYPE object. 

3.1. Object Definition 

   The CLASSTYPE object contains a 32-bit word PCEP common object header 
   defined in [PCEP-ID] followed by another 32-bit word object body as 
   shown in Figure 1. 

   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                                     | CT  | 
                   Figure 1 CLASSTYPE object format. 

   The fields in the object common header are processed as specified in 
   [PCEP-ID]. The values of object class and object type are 22 and 1 
   respectively. If included, CLASSTYPE object must be taken into 
   account by PCE. As such, the P flag MUST be set. I flag is ignored. 

   The CLASSTYPE object body contains the following fields: 

   CT: 3-bit field that indicates the class-type. Values allowed are 1, 
   2, ... , 7. Value of 0 is Reserved. 

   Reserved: 29-bit reserved field. It MUST be set to zero on 
   transmission and MUST be ignored on receipt. 

3.2. Path Computation Request message with CLASSTYPE Object 

   [PCEP-ID] specifies the object orders in which objects must be 
   inserted in the PCEP messages. This document specifies that the 
   CLASSTYPE object be inserted after the END-POINT objects as shown 

   The format of a PCReq message is as follows: 
Sivabalan                Expires May 3, 2009                   [Page 4] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 

      <PCReq Message>::= <Common Header> 
         <request>::= <RP> 
   Note that an implementation MUST form the PCEP messages using the 
   object ordering rules specified using Backus-Naur Form. Please refer 
   [OBJ-ORD] for more details.  
3.3. Processing CLASSTYPE Object 

   If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC 
   originating the path computation request MUST include the CLASSTYPE 
   object in the Path computation request message with the Class-Type 
   (CT) field set to N.  

   If a path computation request contains multiple CLASSTYPE objects, 
   only the first one is meaningful; subsequent CLASSTYPE object(s) MUST 
   be ignored and MUST NOT be forwarded. 

   If the CLASSTYPE object is not present in the path computation 
   request message, the LSR MUST associate the Class-Type 0 to the LSP. 

   Path computation reply message MUST NOT include a CLASSTYPE object. 
   If a PCE needs to forward a path computation request containing the 
   CLASSTYPE object 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-
   Type="Unknown Object" or "Not supported Object" defined in [PCEP-ID]. 

Sivabalan                Expires May 3, 2009                   [Page 5] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 

   A PCE that recognizes the CLASSTYPE object finds that P flag is not 
   set in the CLASSTYPE object, it MUST send PCE error message towards 
   the sender with the with the error type and error value specified in 

   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  "Diff-Serv aware TE Error" and the error 
   value of "Unsupported Class-Type" (new error code provided below). 

   A PCE that recognizes the CLASSTYPE object, but determines that the 
   Class-Type value is not valid (i.e., Class Type value 0), MUST send a 
   PCE error towards the sender with the error type "Diff-Serve aware TE 
   Error" and an error value of "Invalid Class-Type value" (new error 
   code provided below). 

3.4. Determination of Traffic Engineering Class (TE-Class) 

   As specified in RFC4124, a CT and a Preemption priority map to a 
   Traffic Engineering Class (TE-Class), and there can be up to 8 TE-
   classes. The TE-class value is used to determine the unreserved 
   bandwidth on the links during path computation. In the case of a PCE, 
   the CT value carried in the CLASSTYPE object and the setup priority 
   in the LSP Attribute (LSPA) object are used to determine the TE-class 
   corresponding to the path computation request. If LSPA object is 
   absent, the setup priority is assumed to be 0.  

3.5. Significance of Class-Type and TE-Class 

   To ensure coherent DS-TE operation, a PCE and a PCC should have a 
   common understanding of a particular DS-TE classtype and TE-Class.  
   If a path computation request crosses an AS boundary, these should 
   have global significance in all domains.  Enforcement of this global 
   significance is outside the scope of this document. 

3.6. Error Codes for CLASSTYPE Object 

   This document defines the following error type and values: 

   Error-Type    Meaning 

      12         Diff-Serve aware TE Error 
                 Error-value=1: unsupported class-type. 
                 Error-value=2: invalid class-type. 
                 Error-value=3: class-type and setup priority does not 
                 form a configured TE class. 
Sivabalan                Expires May 3, 2009                   [Page 6] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 

4. Security Considerations 

   This document does not introduce new security issues.  The security 
   considerations pertaining to PCEP [PCEP-ID] remain relevant. 

5. IANA Considerations 

   IANA maintains a registry of parameters for PCEP. This contains a 
   sub-registry for PCEP objects. IANA is requested to make new 
   allocation from this registry as follows: 

   Object-Class     Name                  Reference 

       22           CLASSTYPE             draft-ietf-pce-dste-02.txt 


                      1: Class Type       draft-ietf-pce-dste-02.txt   

   IANA is requested to make new allocation for error types and values 
   as follows: 

   Error-Type  Meaning                    Reference 

       12      Diff-Serv aware TE error   draft-ietf-pce-dste-02.txt 

               Error-value = 1:           draft-ietf-pce-dste-02.txt 

                 Unsupported class-type  

               Error-value = 2:           draft-ietf-pce-dste-02.txt 

                 Invalid class-type  

               Error-value = 3:           draft-ietf-pce-dste-02.txt 

                 Class type and setup priority  

                 does not form a configured TE class  

6. Acknowledgments 

   The authors would like to thank Jean Philippe Vasseur, Adrian 
   Farrel and Zafar Ali for their valuable comments. 


Sivabalan                Expires May 3, 2009                   [Page 7] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 

6.1. Normative References 

   [RFC4124] Le Faucheur, F. and W. Lai, "Protocol Extensions for 
             Support of Diffserv-aware MPLS Traffic Engineering", RFC 
             4124, June 2005. 

   [PCEP-ID] Path Computation Element (PCE) communication  Protocol 
             (PCEP)", draft-ietf-pce-pcep-18.txt (work in progress), 
             November 2008. 

6.2. Informative References 

   [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element   (PCE) 
             Communication Protocol Generic Requirements", RFC 4657, 
             September 2006. 

   [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of 
             Differentiated Services-aware MPLS Traffic Engineering", 
             RFC 3564, July 2003. 

   [OBJ-ORD] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 
             in Various Protocol Specifications", draft-farrel-rtg-
             common-bnf-07.txt, November 2008. 


Author's Addresses 

   Siva Sivabalan 
   Cisco Systems, Inc. 
   2000 Innovation Drive 
   Kanata, Ontario, K2K 3E8 

   Jon Parker 
   Cisco Systems, Inc. 
   2000 Innovation Drive 
   Kanata, Ontario, K2K 3E8 

Sivabalan                Expires May 3, 2009                   [Page 8] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 

   Sami Boutros 
   Cisco Systems, Inc. 
   3750 Cisco Way 
   San Jose, California 95134 

   Kenji Kumaki 
   KDDI Corporation 
   Garden Air Tower Iidabashi, Chiyoda-ku 
   Tokyo, 102-8460 
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 
   assurances 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 

   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 

Disclaimer of Validity 

   This document and the information contained herein are provided on an 
Sivabalan                Expires May 3, 2009                   [Page 9] 

Internet-Draft        draft-ietf-pce-dste-02.txt          November 2008 


Copyright Statement 

   Copyright (C) The IETF Trust (2008). 

   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. 


   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 


Sivabalan                Expires May 3, 2009                  [Page 10]