[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-pce-dste

     Network Working Group                                 S. Sivabalan, Ed.
     Internet Draft                                                J. Parker
     Intended status: Standards Track                             S. Boutros
     Expires: January 4, 2008                            Cisco Systems, Inc.
     
                                                                   K. Kumaki
                                                             KDDI Corporation
     
                                                                July 8, 2007
     
     
     
           Diff-Serv Aware Class Type Object for Path Computation Element
                               Communication Protocol
                           draft-sivabalan-pce-dste-01.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.
     
        This document may not be modified, and derivative works of it may not
        be created, except to publish it as an RFC and to translate it into
        languages other than English.
     
        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 August 17, 2007.
     
     Copyright Notice
     
     
     
     S. Sivabalan           Expires January 4, 2008                 [Page 1]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
        Copyright (C) The IETF Trust (2007).
     
     Abstract
     
        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",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in RFC-2119.
     
     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....5
           3.3. Handling of the 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..........................7
        4. Security Considerations........................................7
        5. IANA Considerations............................................7
        6. Acknowledgments................................................7
        7. References.....................................................7
           7.1. Normative References......................................7
           7.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 and
        describes mechanisms to achieve per-class traffic engineering, rather
        than on an aggregate basis across all classes by enforcing Bandwidth
     
     
     S. Sivabalan           Expires January 8, 2008                 [Page 2]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
        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 [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
        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.
     
     
     S. Sivabalan           Expires January 8, 2008                 [Page 3]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
     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 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
        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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           | Object-Class  |   OT  |Res|P|I|   Object Length (bytes)       |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |            Reserved                                     | CT  |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
                          Figure 1 CLASSTYPE object format.
     
        The fields in the object common header are processed as specified in
        [PCEP-ID]. We explain these fields again for completion. For more
        details, please refer to [PCEP-ID].
     
        Object-Class is to be assigned by IANA (recommended value=16).
     
        Object-Type (OT) is to be assigned by IANA (recommended value=1).
     
        Res flags (2 bits). Reserved field. This field MUST be set to zero on
        transmission and MUST be ignored on receipt.
     
        P flag (1 bit): When the P flag is set, the CLASSTYPE object MUST be
        taken into account by the PCE. Conversely, when the P flag is
        cleared, the object is optional and the PCE is free to ignore it if
        not supported.
     
        I flag (1 bit): The PCE MAY include the ignored optional object in
        its reply and set the I flag to indicate that the optional object was
        ignored during path computation.
     
     
     
     
     S. Sivabalan           Expires January 8, 2008                 [Page 4]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
        Object Length (16 bits).  Specifies the total object length including
        the header, in bytes.  The Object Length field MUST always be a
        multiple of 4, and at least 4.  The maximum object content length is
        65528 bytes.
     
        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
     
        The draft [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
        below:
     
        The format of a 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>]
     
     3.3. Handling of the 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.
     
     
     
     S. Sivabalan           Expires January 8, 2008                 [Page 5]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
        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 receiving a path computation request message with the CLASSTYPE
        object with P flag set 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].
     
        A PCE receiving a path computation request message with the CLASSTYPE
        object 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 an error
        value of "Unsupported Class-Type" (new error code provided below).
     
        A PCE receiving a path computation request message with the CLASSTYPE
        object 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.
     
     
     S. Sivabalan           Expires January 8, 2008                 [Page 6]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
        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
     
           11         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.
     
     
     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 assigns value to PCEP parameters.  Each PCEP object has an
        Object-Class and an Object-Type. For the CLASSTYPE object, the
        suggested values for Object-Class and Object-Type are 16 and 1
        respectively.
     
     6. Acknowledgments
     
        The authors would like to thank Jean Philippe Vasseur for his
        valuable comments.
     
     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.
     
        [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T.,Srinivasan, V.,
                  and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                  Tunnels", RFC 3209, December 2001.
     
     
     
     
     S. Sivabalan           Expires January 8, 2008                 [Page 7]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
         [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-07.txt (work in progress),
                  February 2007.
     
     7.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.
     
     Author's Addresses
     
        Siva Sivabalan
        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.
        2000 Innovation Drive
        Kanata, Ontario, K2K 3E8
        Canada
     
        Email: sboutros@cisco.com
     
     
     
     
     S. Sivabalan           Expires January 8, 2008                 [Page 8]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
        Kenji Kumaki
        KDDI Corporation
        Garden Air Tower Iidabashi, Chiyoda-ku
        Tokyo, 102-8460
        Japan
     
        Email: ke-kumaki@kddi.com
     
     
     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
        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.
     
     Disclaimer of Validity
     
        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, THE IETF TRUST AND
        THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
        OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
        THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
        WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
     
     Copyright Statement
     
        Copyright (C) The IETF Trust (2007).
     
     
     
     S. Sivabalan           Expires January 8, 2008                 [Page 9]
     

     Internet-Draft     draft-sivabalan-pce-dste-01.txt            July 2007
     
     
        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.
     
     Acknowledgment
     
        Funding for the RFC Editor function is currently provided by the
        Internet Society.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     S. Sivabalan           Expires January 8, 2008                [Page 10]
     

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/