Network Working Group Andrew Dolganow(Editor) Alcatel. JP Vasseur Cisco System Inc. Proposed Status: Standard Expires: April 2006 October 2005 A new object to specify a Traffic Engineering (TE) Label Switch Path (LSP) cost draft-dolganow-pce-cost-object-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. 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. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document proposes a new object (named the COST object) used to specify the cost of a Traffic Engineering (TE) Label Switched Path (LSP). The COST object can be carried within an RSVP message so as to record a TE LSP cost during LSP establishment or within a Path Computation Element (PCE) path computation protocol message so as to Dolganow, et al. [Page 1] Internet Draft draft-dolganow-pce-cost-object October 2005 provide the cost of a computed path to a Path Computation Client (PCC). 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. Note............................................................2 2. Terminology.....................................................2 3. Introduction....................................................3 4. Collecting path cost in RSVP signaling..........................3 5. Recording path cost in PCEP path computation reply messages.....4 6. Signalling details..............................................4 6.1. COST object body format.......................................4 6.2. Changes to RSVP signalling....................................4 6.2.1. COST Object format in RSVP..................................4 6.2.2. Changes to Attributes Flags TLV and RRO Attributes subobject 5 6.2.3. RSVP object and message applicability.......................5 6.3. Changes to PCEP signalling....................................5 6.3.1. COST object format in PCEP..................................6 6.3.2. PCEP message applicability..................................6 7. Elements of procedure...........................................6 7.1. Changes to RSVP signalling....................................7 7.2. Changes to PCEP signalling....................................8 8. Future work.....................................................8 9. IANA Considerations.............................................8 9.1. Changes required to RSVP......................................8 9.2. Changes required to PCEP......................................8 10. Intellectual Property Statement................................9 11. Acknowledgment.................................................9 12. References.....................................................9 12.1. Normative references.........................................9 13. Authors’ Addresses............................................10 1. Note This document contains proposal to extend both PCEP and RSVP protocols. The authors have the intention of splitting this document into two separate drafts (one for PCEP and one for RSVP) once the content stabilizes. A single draft is used for now to better coordinate comments coming on this proposal from various groups (PCE and CCAMP) and to focus discussion around a single point of reference. 2. Terminology Terminology used in this document Inter-domain TE LSP: A TE LSP whose path transits across at least Dolganow, et al. [Page 2] Internet Draft draft-dolganow-pce-cost-object October 2005 two different domains where a domain can either be an IGP area, an Autonomous System or a sub-AS (BGP confederations). 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: Path Computation Element communication Protocol PCEP Peer: a PCC or the PCE involved in a PCEP session. PLR: Point of Local Repair (as defined in [RSVP-FASTREROUTE]) Within this document, when PCE-PCE communications are being described, the requesting PCE fills the role of a PCC. This provides a saving in documentation without loss of function. 3. Introduction There are various circumstances whereby the head-end of a TE LSP does not have the ability to get the cost of a computed TE LSP. Inter- domain TE LSP computation using the per-domain path computation approach described in [INTER-DOMAIN-PD-PATH-COMP] is an example where each segment is computed by boundary nodes; consequently, although the head-end LSR can determine the computed path by means of an RSVP RRO object it cannot determine the path cost. Another example is when a PCE-based path computation is used to compute TE LSP (see [PCE- ARCH]). In such a case, the head-end LSR (acting as a PCC) may request the PCE to provide the cost of a computed path. The cases described above require the specification of a new object to be carried within an RSVP message upon signaling or within a path computation reply message as described in the Path Computation Element Communication Protocol (PCEP) [PCE-PCEP]. Providing a total path cost will allow the head-end LSR of TE LSP offer new services. Services using the collected path cost are out of scope for this document. 4. Collecting path cost in RSVP signaling To collect the cost of a TE LSP, the head-end LSR includes in the RSVP Path message an LSP-ATTRIBUTES object with Attribute Flags TLV with a “Path cost requested” flag set (see section 5 for definition). The TLV is passed transparently towards a tail-end LSR. When the tail-end LSR receives the RSVP Path message, the LSR places in the corresponding RSVP Resv message the RRO Attributes Subobject with the Dolganow, et al. [Page 3] Internet Draft draft-dolganow-pce-cost-object October 2005 “Path cost” flag set inside the RECORD ROUTE Object as described in the [RSVPTE-ATTR]. The cost value inside the COST object is set to 0. Every LSR the message traverses, increments the cost value inside the COST Object with the cost of its downstream link and adds RRO Attributes Subobject with the “Path cost” flag set to the RECORD ROUTE Object. The absence of the RRO Attributes Subobject with the “Request path cost” flag set for any hop indicates to the head end LSR that the accumulated path cost does not represent the total path cost. 5. Recording path cost in PCEP path computation reply messages In some cases a PCC may find it desirable to know the cost of the computed path returned by a PCE. Mechanism to request such a cost is already defined in the PCEP. To return the cost to the PCC upon successful path computation, the PCE includes in the PCRep message defined in [PCE-PCEP] the cost of the computed path using the COST object as defined later on in this document. PCC may then use the returned cost as required. When a PCE cannot return the computed path cost (e.g. because of policy) or when a PCRep message does not contain the COST object with the computed path cost, normal PCEP error procedures apply. 6. Signalling details 6.1. COST object body format The format of the COST object body is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cost value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 – COST object body format Cost value: 4 octets –A 32-bit unsigned integer specifying the computed path cost. 6.2. Changes to RSVP signalling 6.2.1. COST Object format in RSVP The COST object is an optional object carried in RSVP Resv message to collect the cost of a TE LSP. The object is added by a tail-end LSR that supports path cost accumulation when such an accumulation was requested by the head-end LSR and is updated by LSRs that support the Dolganow, et al. [Page 4] Internet Draft draft-dolganow-pce-cost-object October 2005 object and path cost accumulation for a given TE LSP. LSRs that do not understand the object or have elected not to participate in path cost accumulation for this LSP pass this object unchanged in the Resv message they generate. The COST Object class is TBD of the form 11bbbbbb. This C-num value ensures that LSRs that do not recognize the object pass it on transparently. One C-Type is defined, C-Type = 1 for Path Cost (TBD) The format of the COST object in RSVP is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (bytes) | Class-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Cost object body // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 – COST object format for RSVP Cost object body – Body of the cost object with format as defined in section 6.1 above 6.2.2. Changes to Attributes Flags TLV and RRO Attributes subobject The new flag is defined to allow head-end LSR requesting path cost accumulation and to allow LSRs reporting if the cost accumulation took place. Flag value: Bit 5 (TBD) – “Path cost” flag (to be assigned by IANA) 6.2.3. RSVP object and message applicability The Attribute Flags TLV with the “Path cost” flag set is included by head-end LSR in the LSP_ATTRIBUTES Object in the Path message to request path cost accumulation. The RRO Attributes Subobject with the “Path cost” flag set is included by every LSR in the RECORD ROUTE_ Object in the Resv message to indicate that the LSR performed the path accumulation. The COST object is included by tail-end LSR in the Resv message to accumulate TE-LSP path cost. 6.3. Changes to PCEP signalling Dolganow, et al. [Page 5] Internet Draft draft-dolganow-pce-cost-object October 2005 6.3.1. COST object format in PCEP A new PCEP object named the COST object is defined. When carried as part of a PCRep message, the COST object must be preceded by the Common object header format as defined in [PCE-PCEP] with the following coding points: COST Object-Class is to be assigned by IANA (recommended value=14) COST Object-Type is to be assigned by IANA (recommended value=1) The format of the COST object in PCEP is: 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 |Object-Type|P|R| Object Length (bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Cost object body // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 – COST object format for PCEP Cost object body – Body of the cost object with format as defined in section 6.1 above 6.3.2. PCEP message applicability The COST object is an optional object that may be carried as part of a PCRep message. The format of the defined in [PCE-PCEP] returned as part of PCRep message is modified as follows to account for the COST object: ::= [] [] [] [] [] [] [] [] When a COST object is part of any other PCEP message, the common PCEP error rules MUST apply. 7. Elements of procedure Dolganow, et al. [Page 6] Internet Draft draft-dolganow-pce-cost-object October 2005 7.1. Changes to RSVP signalling General rules for processing of LSP_ATTRIBUTES Object and RRO Attributes Subobject as defined in [RSVPTE-ATTR] apply with the following details: 1. Head-end LSR may include Attributes TLV with “Path cost” flag set within LSP-ATTRIBUTES object in the RSVP Path message to request path cost accumulation. The LSR must extract the path cost from the COST object in a corresponding RSVP Resv message and increment it by its downstream link to obtain the current path cost for the TE LSP. Head-end LSR should examine the RRO object to determine if the cost accumulated is of the entire path or not (based on RRO Attributes Subobjects added by each node along the LSP path). Actions performed by Head-end LSR when the total path cost is collected or is not known (as determined based on the received RSVP Resv message) are out of the scope of this document. 2. Any transit LSR MUST not modify the “Path cost” flag set within the Attributes TLV within LSP-ATTRIBUTES in the received RSVP Path message and: a. SHOULD include in the corresponding RSVP Resv message RRO Attributes Subobject with “Path cost” flag set and increment Cost value in the COST object with the cost of its downstream link, if it supports path cost accumulation as described in this document. b. MUST NOT update in the corresponding RSVP Resv message RRO Attributes Subobject with “Path cost” flag set and MUST pass COST object unchanged if it does not supports path cost accumulation as described in this document or if it elects not to provide path accumulation for this LSP setup. 3. Tail-end LSR upon receiving an RSVP Path message including Attributes TLV with “Path cost” flag set within the LSP ATTRIBUTES: a. SHOULD include in the corresponding RSVP Resv message RRO Attributes Subobject with “Path cost” flag set and COST object with cost value set to 0, if it supports path cost accumulation as described in this document. b. MUST NOT include in the RSVP Resv message RRO Attributes Subobject with “Path cost” flag set and MUST not include COST object if it does not supports path cost accumulation as described in this document or if it elects not to provide path accumulation for this LSP setup. When RSVP Fast Reroute is employed along the path, general rules for failure processing apply as specified in [RSVP-FASTREROUTE]. The updated Resv Message sent by PLR (Point of Local Repair) will include the LSP-ATTRIBUTES, COST, and RRO objects of the path being activated and the newly collected cost needs to be updated. Dolganow, et al. [Page 7] Internet Draft draft-dolganow-pce-cost-object October 2005 7.2. Changes to PCEP signalling The COST object is carried within PCRep messages defined in [PCE- PCEP]. As such elements of the procedures as applicable to optional objects that are part of those messages apply as defined in [PCE- PCEP] with the following details: 1. PCE SHOULD return the total cost of a computed path when requested to do so in a PCReq message (see [PCE-PCEP] for details on how to request the path cost to be returned). If the PCE decides not to return the cost as requested by the PCC, the Cost value inside the COST object SHOULD be set to 0. 2. The P bit value in the Common Object Header is not used and SHOULD be set to 0 by the PCE. 8. Future work Further revisions of this document will include the following functional extensions: 1. The ability for the Head-end LSR or PCC to request a per-hop cost recording function in addition to a cumulative TE LSP cost. 2. Specification of the metric to be used (IGP or TE metric) to record the TE LSP cost as part of the request. 3. Move of the request for return of a cost in PCRep from [PCE- PCEP] into this document. 4. Split of the document into two as indicated in Section 1 above. 9. IANA Considerations 9.1. Changes required to RSVP A new flag: “Path cost” for Attribute Flag TLV and RRO Attributes Subobject is defined in this document. The value of the flag should be assigned by IANA. The recommended value for the flag is Bit 5 (TBD). A new COST object is defined to accumulate TE-LSP path cost value. For that object: 1. The C-Num (To be assigned by IANA) should be of the form 11bbbbbb so that LSRs that do not recognize the object will ignore the object but forward it, unexamined and unmodified in all messages. 2. One C-Type is defined: C-Type = 1 (TBD) for Path Cost. 9.2. Changes required to PCEP A new PCEP object named the COST object is defined in this document that has a recommended Object-Class of 14 (TBD) and a recommended Object-Type of 1 (TBD). The new Object-Class and Object-Type should be assigned by IANA. Dolganow, et al. [Page 8] Internet Draft draft-dolganow-pce-cost-object October 2005 10. 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. 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. 11. Acknowledgment We would like to acknowledge input and helpful comments from Mustapha Aissaoui, Adrian Farrel, and Jean-Louis Le Roux. 12. References 12.1. Normative references [RFC] Bradner, S., "Key words for use in RFCs to indicate requirements levels", RFC 2119, March 1997. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. Dolganow, et al. [Page 9] Internet Draft draft-dolganow-pce-cost-object October 2005 [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. [PCE-PCEP] JP. Vasseur, et al, “Path Computation Element (PCE) communication Protocol (PCEP) – Version 1”, draft-vasseur-pce-pcep- 02.txt, September 2005. [INTER-DOMAIN-PATH-COMP] JP. Vasseur and A. Ayyangar, “A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP)”, draft-ietf-ccamp-inter- domain-pd-path-comp (work in progress). [PCE-ARCH] A. Farrel, J. Ash, JP. Vasseur, “Path Computation Element (PCE) Architecture”, draft-ietf-pce-architecture (work in progress). [RSVPTE-ATTR] draft-ietf-mpls-rsvpte-attributes, “Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSP) Establishment using RSVP_TE” (work in progress). [RSVP-FASTREROUTE] Pan, P. et al, “Fast Reroute Extensions to RSVP-TE for LSP Tunnels”, RFC 4090, May 2005. 13. Authors’ Addresses Andrew Dolganow Alcatel 600 March Rd., K2K 2E6 Ottawa, ON, Canada Phone: +1 (613)784 6285 Email: andrew.dolganow@alcatel.com Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Full Copyright Statement Copyright (C) The Internet Society (2005). 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." 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 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF Dolganow, et al. [Page 10] Internet Draft draft-dolganow-pce-cost-object October 2005 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Dolganow, et al. [Page 11]