Internet Engineering Task Force (IETF) S. Poretsky Request for Comments: 6414 Allot Communications Category: Informational R. Papneja ISSN: 2070-1721 Huawei J. Karthik S. Vapiwala Cisco Systems November 2011 Benchmarking Terminology for Protection Performance Abstract This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6414. Poretsky, et al. Informational [Page 1] RFC 6414 Benchmarking Terms for Protection November 2011 Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. Table of Contents 1. Introduction ....................................................4 1.1. Scope ......................................................4 1.2. General Model ..............................................5 2. Existing Definitions ............................................8 3. Test Considerations .............................................9 3.1. Paths ......................................................9 3.1.1. Path ................................................9 3.1.2. Working Path .......................................10 3.1.3. Primary Path .......................................10 3.1.4. Protected Primary Path .............................11 3.1.5. Backup Path ........................................11 3.1.6. Standby Backup Path ................................12 3.1.7. Dynamic Backup Path ................................12 3.1.8. Disjoint Paths .....................................13 3.1.9. Point of Local Repair (PLR) ........................13 3.1.10. Shared Risk Link Group (SRLG) .....................14 3.2. Protection ................................................14 3.2.1. Link Protection ....................................14 3.2.2. Node Protection ....................................15 Poretsky, et al. Informational [Page 2] RFC 6414 Benchmarking Terms for Protection November 2011 3.2.3. Path Protection ....................................15 3.2.4. Backup Span ........................................16 3.2.5. Local Link Protection ..............................16 3.2.6. Redundant Node Protection ..........................17 3.2.7. State Control Interface ............................17 3.2.8. Protected Interface ................................18 3.3. Protection Switching ......................................18 3.3.1. Protection-Switching System ........................18 3.3.2. Failover Event .....................................19 3.3.3. Failure Detection ..................................19 3.3.4. Failover ...........................................20 3.3.5. Restoration ........................................20 3.3.6. Reversion ..........................................21 3.4. Nodes .....................................................22 3.4.1. Protection-Switching Node ..........................22 3.4.2. Non-Protection-Switching Node ......................22 3.4.3. Headend Node .......................................23 3.4.4. Backup Node ........................................23 3.4.5. Merge Node .........................................24 3.4.6. Primary Node .......................................24 3.4.7. Standby Node .......................................25 3.5. Benchmarks ................................................26 3.5.1. Failover Packet Loss ...............................26 3.5.2. Reversion Packet Loss ..............................26 3.5.3. Failover Time ......................................27 3.5.4. Reversion Time .....................................27 3.5.5. Additive Backup Delay ..............................28 3.6. Failover Time Calculation Methods .........................28 3.6.1. Time-Based Loss Method (TBLM) ......................29 3.6.2. Packet-Loss-Based Method (PLBM) ....................29 3.6.3. Timestamp-Based Method (TBM) .......................30 4. Security Considerations ........................................31 5. References .....................................................32 5.1. Normative References ......................................32 5.2. Informative References ....................................32 6. Acknowledgments ................................................32 Poretsky, et al. Informational [Page 3] RFC 6414 Benchmarking Terms for Protection November 2011 1. Introduction The IP network layer provides route convergence to protect data traffic against planned and unplanned failures in the Internet. Fast convergence times are critical to maintain reliable network connectivity and performance. Convergence Events [6] are recognized at the IP Layer so that Route Convergence [6] occurs. Technologies that function at sub-IP layers can be enabled to provide further protection of IP traffic by providing the failure recovery at the sub-IP layers so that the outage is not observed at the IP layer. Such sub-IP protection technologies include, but are not limited to, High Availability (HA) stateful failover, Virtual Router Redundancy Protocol (VRRP) [8], Automatic Link Protection (APS) for SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for Multiprotocol Label Switching (MPLS-FRR) [9]. 1.1. Scope Benchmarking terminology was defined for IP-layer convergence in [6]. Different terminology and methodologies specific to benchmarking sub- IP layer protection mechanisms are required. The metrics for benchmarking the performance of sub-IP protection mechanisms are measured at the IP layer, so that the results are always measured in reference to IP and independent of the specific protection mechanism being used. The purpose of this document is to provide a single terminology for benchmarking sub-IP protection mechanisms. A common terminology for sub-IP layer protection mechanism benchmarking enables different implementations of a protection mechanism to be benchmarked and evaluated. In addition, implementations of different protection mechanisms can be benchmarked and evaluated. It is intended that there can exist unique methodology documents for each sub-IP protection mechanism based upon this common terminology document. The terminology can be applied to methodologies that benchmark sub-IP protection mechanism performance with a single stream of traffic or multiple streams of traffic. The traffic flow may be unidirectional or bidirectional as to be indicated in the methodology. Poretsky, et al. Informational [Page 4] RFC 6414 Benchmarking Terms for Protection November 2011 1.2. General Model The sequence of events to benchmark the performance of sub-IP protection mechanisms is as follows: 1. Failover Event - Primary Path fails 2. Failure Detection - Failover Event is detected 3. Failover - Backup Path becomes the Working Path due to Failover Event 4. Restoration - Primary Path recovers from a Failover Event 5. Reversion (optional) - Primary Path becomes the Working Path These terms are further defined in this document. Figures 1 through 5 show models that MAY be used when benchmarking sub-IP protection mechanisms, which MUST use a Protection-Switching System that consists of a minimum of two Protection-Switching Nodes, an Ingress Node known as the Headend Node and an Egress Node known as the Merge Node. The Protection-Switching System MUST include either a Primary Path and Backup Path, as shown in Figures 1 through 4, or a Primary Node and Standby Node, as shown in Figure 5. A Protection- Switching System may provide link protection, node protection, path protection, local link protection, and high availability, as shown in Figures 1 through 5, respectively. A Failover Event occurs along the Primary Path or at the Primary Node. The Working Path is the Primary Path prior to the Failover Event and the Backup Path after the Failover Event. A Tester is set outside the two paths or nodes as it sends and receives IP traffic along the Working Path. The tester MUST record the IP packet sequence numbers, departure time, and arrival time so that the metrics of Failover Time, Additive Latency, Packet Reordering, Duplicate Packets, and Reversion Time can be measured. The Tester may be a single device or a test system. If Reversion is supported, then the Working Path is the Primary Path after Restoration (Failure Recovery) of the Primary Path. Link Protection, as shown in Figure 1, provides protection when a Failover Event occurs on the link between two nodes along the Primary Path. Node Protection, as shown in Figure 2, provides protection when a Failover Event occurs at a Node along the Primary Path. Path Protection, as shown in Figure 3, provides protection for link or node failures for multiple hops along the Primary Path. Local Link Protection, as shown in Figure 4, provides sub-IP protection of a link between two nodes, without a Backup Node. An example of such a sub-IP protection mechanism is SONET APS. High Availability Protection, as shown in Figure 5, provides protection of a Primary Node with a redundant Standby Node. State Control is provided between the Primary and Standby Nodes. Failure of the Primary Node Poretsky, et al. Informational [Page 5] RFC 6414 Benchmarking Terms for Protection November 2011 is detected at the sub-IP layer to force traffic to switch to the Standby Node, which has state maintained for zero or minimal packet loss. +-----------+ +--------------| Tester |<-----------------------+ | +-----------+ | | IP Traffic | Failover IP Traffic | | | Event | | ------------ | ---------- | +--->| Ingress/ | V | Egress/ |---+ |Headend Node|------------------|Merge Node| Primary ------------ ---------- Path | ^ | --------- | Backup +--------| Backup |-------------+ Path | Node | --------- Figure 1. System Under Test (SUT) for Sub-IP Link Protection +-----------+ +--------------------| Tester |<-----------------+ | +-----------+ | | IP Traffic | Failover IP Traffic | | | Event | | V | | ------------ -------- ---------- | +--->| Ingress/ | |Midpoint| | Egress/ |---+ |Headend Node|----| Node |----|Merge Node| Primary ------------ -------- ---------- Path | ^ | --------- | Backup +--------| Backup |-------------+ Path | Node | --------- Figure 2. System Under Test (SUT) for Sub-IP Node Protection Poretsky, et al. Informational [Page 6] RFC 6414 Benchmarking Terms for Protection November 2011 +-----------+ +---------------------------| Tester |<----------------------+ | +-----------+ | | IP Traffic | Failover IP Traffic | | | Event | | Primary Path | | | ------------ -------- | -------- ---------- | +--->| Ingress/ | |Midpoint| V |Midpoint| | Egress/ |---+ |Headend Node|----| Node |---| Node |---|Merge Node| ------------ -------- -------- ---------- | ^ | --------- -------- | Backup +--------| Backup |----| Backup |--------+ Path | Node | | Node | --------- -------- Figure 3. System Under Test (SUT) for Sub-IP Path Protection +-----------+ +--------------------| Tester |<-------------------+ | +-----------+ | | IP Traffic | Failover IP Traffic | | | Event | | Primary | | | +--------+ Path v +--------+ | | | |------------------------>| | | +--->| Ingress| | Egress |----+ | Node |- - - - - - - - - - - - >| Node | +--------+ Backup Path +--------+ | | | IP-Layer Forwarding | +<----------------------------------------->+ Figure 4. System Under Test (SUT) for Sub-IP Local Link Protection Poretsky, et al. Informational [Page 7] RFC 6414 Benchmarking Terms for Protection November 2011 +-----------+ +-----------------| Tester |<--------------------+ | +-----------+ | | IP Traffic | Failover IP Traffic | | | Event | | V | | --------- -------- ---------- | +--->| Ingress | |Primary | | Egress/ |------+ | Node |----| Node |----|Merge Node| Primary --------- -------- ---------- Path | State |Control ^ | Interface |(Optional) | | --------- | +---------| Standby |---------+ | Node | --------- Figure 5. System Under Test (SUT) for Sub-IP Redundant Node Protection Some protection-switching technologies may use a series of steps that differ from the general model. The specific differences SHOULD be highlighted in each technology-specific methodology. Note that some protection-switching technologies are endowed with the ability to re- optimize the working path after a node or link failure. 2. Existing Definitions This document uses existing terminology defined in other BMWG work. Examples include, but are not limited to: Latency [2], Section 3.8 Frame Loss Rate [2], Section 3.6 Throughput [2], Section 3.17 Device Under Test (DUT) [3], Section 3.1.1 System Under Test (SUT) [3], Section 3.1.2 Offered Load [3], Section 3.5.2 Out-of-order Packet [4], Section 3.3.4 Duplicate Packet [4], Section 3.3.5 Forwarding Delay [4], Section 3.2.4 Jitter [4], Section 3.2.5 Packet Loss [6], Section 3.5 Packet Reordering [7], Section 3.3 This document has the following frequently used acronyms: DUT Device Under Test SUT System Under Test Poretsky, et al. Informational [Page 8] RFC 6414 Benchmarking Terms for Protection November 2011 This document adopts the definition format in Section 2 of RFC 1242 [2]. Terms defined in this document are capitalized when used within this document. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [5]. RFC 2119 defines the use of these keywords to help make the intent of Standards Track documents as clear as possible. While this document uses these keywords, this document is not a Standards Track document. 3. Test Considerations 3.1. Paths 3.1.1. Path Definition: A unidirectional sequence of nodes and links with the following properties: a. R1 is the ingress node and forwards IP packets, which input into DUT/SUT, to R2 as sub-IP frames over link L12. b. Ri is a node which forwards data frames to R(i+1) over Link Li(i+1) for all i, 1