summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5455.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5455.txt')
-rw-r--r--doc/rfc/rfc5455.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5455.txt b/doc/rfc/rfc5455.txt
new file mode 100644
index 0000000..d1705f6
--- /dev/null
+++ b/doc/rfc/rfc5455.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+