Network Working Group S. Sivabalan, Ed.
Internet Draft J. Parker
Intended status: Standards Track S. Boutros
Expires: Auguest 17, 2007 Cisco Systems, Inc.
K. Kumaki
KDDI Corporation
February 26, 2007
Diff-Serv Aware Class Type Object for Path Computation Element
Communication Protocol
draft-sivabalan-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 August 17, 2007.
Copyright Notice
S. Sivabalan Expires Auguest 17, 2007 [Page 1]
Internet-Draft draft-sivabalan-pce-dste-00.txt February 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
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 Error!
Reference source not found..
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. Error Codes for CLASSTYPE object..........................6
4. Security Considerations........................................6
5. IANA Considerations............................................6
6. Acknowledgments................................................7
7. References.....................................................7
7.1. Normative References......................................7
Author's Addresses................................................8
Intellectual Property Statement...................................8
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 (Diffserv)-aware MPLS Traffic Engineering (DS-
TE). This includes the fundamental requirement to be able to enforce
different bandwidth constraints for different classes of traffic.
S. Sivabalan Expires August 26, 2007 [Page 2]
Internet-Draft draft-sivabalan-pce-dste-00.txt February 2007
Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering
(DS-TE) 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 references
[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
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 LSP: Traffic Engineering Label Switched Path.
LSR: Label Switching Router.
LSP: Label Switched Path.
DS-TE: Diff-Serv Aware Traffic Engineering.
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.
S. Sivabalan Expires August 26, 2007 [Page 3]
Internet-Draft draft-sivabalan-pce-dste-00.txt February 2007
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:
CT: 3-bit field that indicates the class-type. Values allowed are 1,
2, ... , 7. Value of 0 is Reserved.
S. Sivabalan Expires August 26, 2007 [Page 4]
Internet-Draft draft-sivabalan-pce-dste-00.txt February 2007
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 containing the
CLASSTYPE object to another PCE, it MUST store the class-type of the
S. Sivabalan Expires August 26, 2007 [Page 5]
Internet-Draft draft-sivabalan-pce-dste-00.txt February 2007
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 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. 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.
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
S. Sivabalan Expires August 26, 2007 [Page 6]
Internet-Draft draft-sivabalan-pce-dste-00.txt February 2007
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.
[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.
[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-06.txt (work in progress),
February 2007.
S. Sivabalan Expires August 26, 2007 [Page 7]
Internet-Draft draft-sivabalan-pce-dste-00.txt February 2007
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
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
S. Sivabalan Expires August 26, 2007 [Page 8]
Internet-Draft draft-sivabalan-pce-dste-00.txt February 2007
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).
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 August 26, 2007 [Page 9]