Internet-Draft Christopher Marty Expires: September 26, 2006 Mohamed A. Ali City University of New York March 25, 2006 RSVP Extensions for Explicit Rate Congestion Control in Multiprotocol Label Switched (MPLS) Networks draft-marty-mpls-rsvp-er-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. This Internet-Draft will expire on September 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This memo presents a set of extensions for supporting explicit rate congestion control using RSVP. It should be perceived as an extension to the RSVP functional specifications [RFC2205] These extensions include the standard format of the ER_SPEC object, and a description of RSVP's handling of the ER_SPEC object. This document does not advocate a particular distributed explicit rate congestion control algorithm. Marty and Ali Expires September 26, 2006 [Page 1] Internet-Draft RSVP ER Congesion Control in MPLS March 2006 Table of Contents 1. Introduction ................................................. 2 2. Terminology .................................................. 2 3. Conventions Used In This Document ............................ 2 4. Overview of Explicit Rate Congestion Control ................. 3 5. The EXPLICIT_RATE_SPEC Parameter Definition .................. 3 6. Use of the EXPLICIT_RATE_SPEC Parameter ...................... 4 7. Security Considerations ...................................... 5 8. References ................................................... 5 9. Authors' Addresses ........................................... 5 Intellectual Property Statement ................................. 5 Disclaimer of Validity .......................................... 6 Copyright Statement ............................................. 6 Acknowledgment .................................................. 6 1. Introduction This memo defines a message format and protocol for signaling explicit rate congestion control information using RSVP. This extension is designed for use in Multiprotocol Label Switched (MPLS) network as a mechanism for enabling the calculating of explicit weighted fair rates for point-to-point Label Switched Paths (LSPs). 2. Terminology The terminology used in this document is covered in the RSVP Specification [RFC2205] or the MPLS Architecture [RFC3031]. 3. 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]. 4. Overview of Explicit Rate Congestion Control MPLS LSPs created using the Controlled-Load service [RFC2211] are best effort. In best effort service, network connections are not prevented from offering traffic at an unconstrained rate. Networks will, in times of congestion, drop best effort traffic. Dropping packets arbitrarily leads to network inefficiencies (as packets are not dropped as early as possible), and unfairness for network LSPs. Marty and Ali Expires September 26, 2006 [Page 2] Internet-Draft RSVP ER Congesion Control in MPLS March 2006 Explicit Rate congestion control is a mechanism whereby explicit rates are assigned to best effort LSPs. Explicit rates change dynamically as network conditions change. An Explicit Rate congestion control system consists of a mechanism for periodically signaling explicit rates, and a distributed explicit rate algorithm for assigning rates. Distributed explicit rate congestion control algorithms work at each node in a network path to cooperatively set explicit rates for network connections using an appropriate signaling mechanism. This memo proposes a signaling mechanism for assigning explicit rates for point-to-point LSPs in MPLS networks. 5. The EXPLICIT_RATE_SPEC Parameter Definition The EXPLICIT_RATE_SPEC is carried as a parameter in the SENDER_TSPEC and FLOWSPEC objects (in a manner similar to the TOKEN_BUCKET_TSPEC [RFC2215]) for services requesting explicit rate congestion control feedback. This parameter is used by data senders to describe traffic it expects to generate, and by explicit rate control services to describe the explicit capacity available to the sender. It is defined as a general rather than service-specific parameter because the same traffic description may be used by several QoS control services [RFC2210] in some situations. The EXPLICIT_RATE_SPEC parameter is assigned parameter_number TBD. The format of the EXPLICIT_RATE_SPEC parameter is shown below. 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | TBD | 0 | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | Explicit Rate [e] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | Minimum Rate [m] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Weight [w] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The EXPLICIT_RATE_SPEC takes the form of an explicit rate [e], minimum rate [m], and a weight [w]. The values for [e] and [m] must be non-negative, the value for [w] must be positive. The explicit rate [r] and minimum rate [m] are measured in bytes of IP datagrams per second. Values of [r] and [m] range from 0 bytes per second to 40 terabytes per second. In practice, only the first few Marty and Ali Expires September 26, 2006 [Page 3] Internet-Draft RSVP ER Congesion Control in MPLS March 2006 digits of the [e] and [m] parameters are significant, so the use of floating point representations, accurate to at least 0.1% is encouraged. The range of values allowed for these parameters is intentionally large to allow for future network technologies. A particular network element is not expected to support the full range of values. The weight, [w], is a positive integer value without units. Its value indicates a relative weight for the connection. The XDR description of this parameter is: struct { float e; float m; unsigned w; } EXPLICIT_RATE_SPEC; For the fields [e] and [m] only valid non-negative floating point numbers are allowed. Negative numbers (including "negative zero), infinities, and NAN's are not allowed. NOTE: An implementation which utilizes general-purpose hardware or software IEEE floating-point support may wish to verify that arriving parameter values meet these requirements before using the values in floating-point computations, in order to avoid unexpected exceptions or traps. 6. Use of the EXPLICIT_RATE_SPEC Parameter The EXPLICIT_RATE_SPEC is a parameter to the SENDER_TSPEC object in the RSVP PATH message and the FLOWSPEC object in the RSVP RESV message. It is intended to be used as a mechanism for driving a distributed explicit rate algorithm for point-to-point LSPs in MPLS networks. It is expected that, for LSPs requiring explicit rate service, the source Label Switched Router (LSR) will, at regular intervals, forward an RSVP PATH message containing a EXPLICIT_RATE_SPEC. The source LSR will set the explicit rate field of the EXPLICIT_RATE_SPEC to a peak rate for the LSP. RSVP enabled LSRs receiving PATH and RESV messages containing an EXPLICIT_RATE_SPEC parameter MUST forward them immediately. Marty and Ali Expires September 26, 2006 [Page 4] Internet-Draft RSVP ER Congesion Control in MPLS March 2006 Destination LSRs receiving an RSVP PATH message containing an EXPLICIT_RATE_SPEC object MUST create a corresponding RSVP RESV message with an identical EXPLICIT_RATE_SPEC parameter and forward immediately. In the direction from source to destination (RSVP PATH), intermediate LSRs MAY update the explicit rate field of an EXPLICIT_RATE_SPEC to a value less than the received value. In the direction from destination to source (RSVP RESV), intermediate LSRs MUST leave the EXPLICIT_RATE_SPEC unchanged. 7. Security Considerations This memo describes the use of EXPLICIT_RATE_SPEC parameter to carry explicit rate congestion control information between RSVP nodes. To ensure message integrity, the RSVP integrity mechanism specified in [MD5] ca be used to provide a chain of trust when all RSVP nodes are policy capable 8. References [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification”, RFC 2205, September 1997. [RFC2210] J. Wroclawski, “The Use of RSVP with IETF Integrated Services”, RFC 2210, September 1997. [RFC2211] J. Wroclawski, “Specification of the Controlled-Load Network Element Service”, RFC 2211, September 1997. [RFC2215] S. Shenker, J. Wroclawski, “General Characterization Parameters for Integrated Service Network Elements”, RFC 2215, September 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. 9. Authors' Addresses Christopher Marty City University of New York 6 Twin Brook Court Marty and Ali Expires September 26, 2006 [Page 5] Internet-Draft RSVP ER Congesion Control in MPLS March 2006 Holmdel, NJ 07733 Phone: +1-732-241-5462 Email: cmarty@gc.cuny.edu Mohamed A. Ali Department of Electrical Engineering City College and Graduate School City University of New York Convent Avenue at 140th Street New York, NY 10031 Phone: +1-212-650-6737 Email: ali@ccny.cuny.edu 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. 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 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. Marty and Ali Expires September 26, 2006 [Page 6] Internet-Draft RSVP ER Congesion Control in MPLS March 2006 Copyright Statement Copyright (C) The Internet Society (2006). 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. Marty and Ali Expires September 26, 2006 [Page 7]