Network Working Group S.Vapiwala Internet Draft K.Ratnam Expires: October 2007 Cisco Systems R. Papneja Isocore April 12, 2007 Motivation for Benchmarking MPLS TE convergence draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt Intellectual Property Rights (IPR) statement: 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. Status of this Memo 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 October 12, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Vapiwala, Ratnam, Papneja Expires Sep, 2007 [Page 1] Internet-Draft Motivation for Benchmarking March-2007 MPLS TE Convergence Abstract This document describes the motivation for benchmarking MPLS traffic engineering (TE) convergence using RSVP, the Resource ReserVation Protocol as an underlying signaling protocol. This document provides an overview of the work item and a separate methodology and terminology document will be generated if there is enough interest in this area. This work complements MPLS protection benchmarking work, which is already being pursued in the Benchmarking working group at IETF. Table of Contents 1. Introduction...................................................3 2. Existing definitions...........................................3 3. Factors impacting MPLS TE Scalability and Performance..........4 3.1. RSVP Refresh reduction....................................4 3.2. RSVP Authentication.......................................4 3.3. RSVP Rate-limit parameter.................................4 3.4. CPU utilization at the time of signaling..................4 3.5. CPU Utilization at stead state............................4 3.6. Memory Usage..............................................4 4. MPLS TE Scalability and Convergence Performance cases..........5 4.1. Convergence MPLS TE Headend without Refresh Reduction.....5 4.2. Convergence MPLS TE Headend with Refresh Reduction........5 4.3. Convergence MPLS TE Mid-Point without Refresh Reduction...5 4.4. Convergence MPLS TE Mid-Point with Refresh Reduction......5 4.5. Convergence of 25% of LSP on MPLS TE Mid-Point............5 4.6. Convergence Authentication on MPLS TE Headend.............5 4.7. Convergence Authentication on MPLS TE Mid-Point...........5 4.8. Convergence time of a single LSP in a scale network.......6 5. MPLS TE Convergence Table......................................6 5.1. MPLS TE Headend...........................................6 5.2. MPLS TE Mid-point.........................................6 6. Security Considerations........................................6 7. IANA Considerations............................................7 This document requires no IANA considerations.....................7 8. Acknowledgments................................................7 9. References.....................................................7 9.1. Normative References......................................7 10. Author's Addresses............................................8 Intellectual Property Statement...................................9 Disclaimer of Validity............................................9 Vapiwala, Ratnam, Papneja Expires Oct, 2007 [Page 2] Internet-Draft Motivation for Benchmarking March-2007 MPLS TE Convergence 1. Introduction MPLS traffic engineering enables service providers to achieve efficient utilization of available network resources including available bandwidth without adding additional resources in proportion to the increased demand. In addition MPLS TE helps improve QoS and resiliency against unplanned node or link failures in the network. This in essence allows service providers to offer strict service level agreements (SLAs) to consumers. These high- availability and faster recovery capabilities of MPLS TE have motivated many service providers to consider migrating or have already migrated all their services (i.e. voice, data, video, and wireless) over IP/MPLS based networks. It is important, as network size grows, that MPLS TE enabled label switched paths (or tunnels) are able to scale to thousands of LSPs and converge the routes bound to the tunnels while keeping memory and CPU resource utilization to a minimal value. As MPLS TE becomes more widely accepted as the primary protocol for the network core, the need for common benchmarking of its performance and scalability is of great importance. In this motivational draft, we elaborate on the key performance and scalability metrics that one needs to consider for designing an MPLS traffic engineering network. 2. Existing definitions For the sake of clarity and continuity this RFC adopts the template or definitions set out in Section 2 of RFC 1242. Definitions are indexed and grouped together in sections for ease of reference. 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. The reader is encouraged to be familiar with the commonly used BFD terms, some of which are defined in the appendix. Vapiwala, Ratnam, Papneja Expires Oct, 2007 [Page 3] Internet-Draft Motivation for Benchmarking March-2007 MPLS TE Convergence 3. Factors impacting MPLS TE Scalability and Performance 3.1. RSVP Refresh reduction RSVP refresh reduction consists of reliable, summary and bundle messages to reduce the number of messages exchanged between the nodes. 3.2. RSVP Authentication Authentication is used for security purpose and has impact on the scalability and convergence performance of MPLS traffic engineering. 3.3. RSVP Rate-limit parameter Rate limiting is used by the vendors to pace the RSVP messages on the output queue. Rate limiting is also a key factor in MPLS TE scalability and performance. 3.4. CPU utilization at the time of signaling CPU Utilization of the DUT at the time of signaling is a key factor that one need to consider when designing the network. 3.5. CPU Utilization at stead state CPU Utilization of the DUT at stead state is also a key factor in designing the network. 3.6. Memory Usage Memory usage of the DUT is important to identify in a scale network. Vapiwala, Ratnam, Papneja Expires Oct, 2007 [Page 4] Internet-Draft Motivation for Benchmarking March-2007 MPLS TE Convergence 4. MPLS TE Scalability and Convergence Performance cases 4.1. Convergence MPLS TE Headend without Refresh Reduction Time taken to signal x no of LSPs after interface is up on DUT as MPLS TE Headend 4.2. Convergence MPLS TE Headend with Refresh Reduction Time taken to signal x no of LSPs after interface is up on DUT as MPLS TE Headend 4.3. Convergence MPLS TE Mid-Point without Refresh Reduction Time taken to signal x no of LSPs after interface is up on DUT as MPLS TE Mid-Point 4.4. Convergence MPLS TE Mid-Point with Refresh Reduction Time taken to signal x no of LSPs after interface is up on DUT as MPLS TE Mid-Point 4.5. Convergence of 25% of LSP on MPLS TE Mid-Point Time taken to signal only portion of LSPs after interface is up on DUT as MPLS TE Mid-Point. 4.6. Convergence Authentication on MPLS TE Headend Time taken to signal x no of LSPs after interface is up on DUT as MPLS TE Headend with Authentication 4.7. Convergence Authentication on MPLS TE Mid-Point Time taken to signal x no of LSPs after interface is up on DUT as MPLS TE Mid-Point with Authentication Vapiwala, Ratnam, Papneja Expires Oct, 2007 [Page 5] Internet-Draft Motivation for Benchmarking March-2007 MPLS TE Convergence 4.8. Convergence time of a single LSP in a scale network Time taken to signal a single LSP in a network with X number of LSPs in the network. 5. MPLS TE Convergence Table This section provides the recommended numbers of TE LSPs for evaluating the convergence of MPLS TE implementations. 5.1. MPLS TE Headend - 100 - 500 - 1000 - 2000 - Max 5.2. MPLS TE Mid-point - 5000 - 10000 - 20000 - 30000 - 40000 - Max 6. Security Considerations Vapiwala, Ratnam, Papneja Expires Oct, 2007 [Page 6] Internet-Draft Motivation for Benchmarking March-2007 MPLS TE Convergence Documents of this type do not directly affect the security of the Internet or of corporate networks as long as benchmarking is not performed on devices or systems connected to operating networks. 7. IANA Considerations This document requires no IANA considerations. 8. Acknowledgments We would like to thank Azhar Sayeed for his valuable input and also Aamer Akhter,Rajiv Asati, Gabor Feher, Krisztian Nemeth and Andras Korn for their contributions. 9. References 9.1. Normative References [RFC3209] D.Awduche, L.Berger, D.Gan, T.Li, V.Srinivasan, and G.Swallow, "Extensions to RSVP for LSP Tunnels", RFC- 3209, December, 2001 [RFC2961] L.Berger, D.Gan, G.Swallow, P.Pan, F.Tommasi and S.Molendini, " RSVP Refresh Overhead Reduction Extention” RFC-2961, April, 2001 Vapiwala, Ratnam, Papneja Expires Oct, 2007 [Page 7] Internet-Draft Motivation for Benchmarking March-2007 MPLS TE Convergence 10. Authors’ Addresses Samir Vapiwala Cisco System 300 Beaver Brook Road Boxborough, MA 01719 USA Phone: +1 978 936 1484 Email: svapiwal@cisco.com Karu Ratnam Cisco System 300 Beaver Brook Road Boxborough, MA 01719 USA Phone: +1 978 936 1551 Email: kratnam@cisco.com Rajiv Papneja Isocore 12359 Sunrise Valley Drive, STE 100 Reston, VA 20190 USA Phone: +1 703 860 9273 Email: rpapneja@isocore.com Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 Vapiwala, Ratnam, Papneja Expires Oct, 2007 [Page 8] Internet-Draft Motivation for Benchmarking March-2007 MPLS TE Convergence ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Vapiwala, Ratnam, Papneja Expires Oct, 2007 [Page 9]