doc: Add RFC documents

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]
+