From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5455.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc5455.txt (limited to 'doc/rfc/rfc5455.txt') 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: + + ::= + [] + + where: + ::=[] + ::=[] + ::= + + [] + [] + [] + [] + [] + [] + [] + where: + ::=[] + + 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] + -- cgit v1.2.3