path: root/doc/rfc/rfc5455.txt

Network Working Group                                  S. Sivabalan, Ed.
Request for Comments: 5455                                     J. Parker
Category: Standards Track                                     S. Boutros
                                                     Cisco Systems, Inc.
                                                               K. Kumaki
                                             KDDI R&D Laboratories, Inc.
                                                              March 2009


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

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

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



Sivabalan, et al.           Standards Track                     [Page 1]
^L
RFC 5455              DS Aware CT Object for PCEP             March 2009


Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. Terminology .....................................................3
   3. CLASSTYPE Object ................................................3
      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
   7. References ......................................................8
      7.1. Normative References .......................................8
      7.2. Informative References .....................................8

1.  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].

   Diffserv-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
   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 [RFC5440]
   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.







Sivabalan, et al.           Standards Track                     [Page 2]
^L
RFC 5455              DS Aware CT Object for PCEP             March 2009


1.1.  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].

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: Diffserv-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
   PCE).

   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.

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




Sivabalan, et al.           Standards Track                     [Page 3]
^L
RFC 5455              DS Aware CT Object for PCEP             March 2009


   path computation request MUST NOT contain the CLASSTYPE object.  This
   allows backward compatibility with a 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 [RFC5440] 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 common object header are processed as specified in
   [RFC5440].  The values of object class and object type are 22 and 1,
   respectively.  If included, the CLASSTYPE object must be taken into
   account by the PCE.  As such, the P flag MUST be set.  The 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.  The 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

   [RFC5440] specifies the order 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 below:












Sivabalan, et al.           Standards Track                     [Page 4]
^L
RFC 5455              DS Aware CT Object for PCEP             March 2009


   The format of a Path Computation Request (PCReq) message is as
   follows:

      <PCReq Message>::= <Common Header>
                         [<SVEC-list>]
                         <request-list>
      where:
         <svec-list>::=<SVEC>[<svec-list>]
         <request-list>::=<request>[<request-list>]
         <request>::= <RP>
                      <END-POINTS>
                      [<CLASSTYPE>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<RRO>]
                      [<IRO>]
                      [<LOAD-BALANCING>]
      where:
      <metric-list>::=<METRIC>[<metric-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.

3.3.  Processing CLASSTYPE Object

   If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC
   originating the PCReq MUST include the CLASSTYPE object in the PCReq
   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.

   A 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
   [RFC5440].



Sivabalan, et al.           Standards Track                     [Page 5]
^L
RFC 5455              DS Aware CT Object for PCEP             March 2009


   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 (i.e., Class-Type value 0), 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.4.  Determination of Traffic Engineering Class (TE-Class)

   As specified in RFC 4124, 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 the 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 Class-Type and TE-class.
   If a path computation request crosses an Autonomous System (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         Diffserv-aware TE error
                    Error-value=1: Unsupported Class-Type
                    Error-value=2: Invalid Class-Type
                    Error-value=3: Class-Type and setup priority do
                                   not form a configured TE-class





Sivabalan, et al.           Standards Track                     [Page 6]
^L
RFC 5455              DS Aware CT Object for PCEP             March 2009


4.  Security Considerations

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

5.  IANA Considerations

   IANA maintains a registry of parameters for PCEP.  This contains a
   sub-registry for PCEP objects.  IANA has made allocations from this
   registry as follows:

      Object-Class     Name                  Reference

          22           CLASSTYPE             RFC 5455

                         Object-Type

                         1: Class-Type       RFC 5455

   IANA has allocated error types and values as follows:

      Error-Type  Meaning                    Reference

          12      Diffserv-aware TE error    RFC 5455

                  Error-value = 1:           RFC 5455

                    Unsupported Class-Type

                  Error-value = 2:           RFC 5455

                    Invalid Class-Type

                  Error-value = 3:           RFC 5455

                    Class-Type and setup priority
                    do 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, et al.           Standards Track                     [Page 7]
^L
RFC 5455              DS Aware CT Object for PCEP             March 2009


7.  References

7.1.  Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
             Element (PCE) Communication Protocol (PCEP)", RFC 5440,
             March 2009.

7.2.  Informative References

   [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "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", Work in Progress,
             November 2008.























Sivabalan, et al.           Standards Track                     [Page 8]
^L
RFC 5455              DS Aware CT Object for PCEP             March 2009


Authors' Addresses

   Siva Sivabalan (editor)
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, Ontario, K2K 3E8
   Canada

   EMail: msiva@cisco.com


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

   EMail: jdparker@cisco.com


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

   EMail: sboutros@cisco.com


   Kenji Kumaki
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara Fujimino
   Saitama 356-8502, JAPAN

   EMail: ke-kumaki@kddi.com
















Sivabalan, et al.           Standards Track                     [Page 9]
^L