Network Working Group S. Sivabalan, Ed.
Internet Draft J. Parker
Intended status: Standards Track S. Boutros
Expires: April 15, 2008 Cisco Systems, Inc.
K. Kumaki
KDDI Corporation
October 23, 2007
Diff-Serv Aware Class Type Object for Path Computation Element
Communication Protocol
draft-ietf-pce-dste-00.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 April 15, 2007.
S. Sivabalan Expires April 15, 2008 [Page 1]
Internet-Draft draft-ietf-pce-dste-00.txt October 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............................................3
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..........................6
4. Security Considerations.....................................7
5. IANA Considerations.........................................7
6. Acknowledgments.............................................7
7. References..................................................7
7.1. Normative References......................................7
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 Constraints (BCs) on different
classes. Requirements for DS-TE and the associated protocol
extensions are specified in [RFC3564] and [RFC4124]
respectively.
S. Sivabalan Expires April 23, 2008 Page 2]
Internet-Draft draft-ietf-pce-dste-00.txt October 2007
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.
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
S. Sivabalan Expires April 23, 2008 Page 3]
Internet-Draft draft-ietf-pce-dste-00.txt October 2007
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.
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:
S. Sivabalan Expires April 23, 2008 Page 4]
Internet-Draft draft-ietf-pce-dste-00.txt October 2007
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.
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
S. Sivabalan Expires April 23, 2008 Page 5]
Internet-Draft draft-ietf-pce-dste-00.txt October 2007
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. 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
S. Sivabalan Expires April 23, 2008 Page 6]
Internet-Draft draft-ietf-pce-dste-00.txt October 2007
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.
[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-08.txt (work in
progress), February 2007.
S. Sivabalan Expires April 23, 2008 Page 7]
Internet-Draft draft-ietf-pce-dste-00.txt October 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 April 23, 2008 Page 8]
Internet-Draft draft-ietf-pce-dste-00.txt October 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 April 23, 2008 Page 9]
Internet-Draft draft-ietf-pce-dste-00.txt October 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 April 23, 2008 Page 10]
