idnits 2.17.1 draft-ietf-bmwg-protection-term-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1067. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1078. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1091. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6251 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1013, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-12 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft 3 Expires: September 2007 4 Intended Status: Informational 6 S. Poretsky 7 Reef Point Systems 9 R. Papneja 10 Isocore 12 J. Karthik 13 Cisco Systems 15 March 2007 17 Benchmarking Terminology for Protection Performance 18 20 Intellectual Property Rights (IPR) statement: 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Status of this Memo 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use 36 Internet-Drafts as reference material or to cite them other 37 than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Protection Performance 50 Abstract 51 This document provides common terminology and metrics for 52 benchmarking the performance of sub-IP layer protection 53 mechanisms. The performance benchmarks are measured at the 54 IP-Layer, so avoid dependence on specific sub-IP protections 55 mechanisms. The benchmarks and terminology can be applied in 56 methodology documents for different sub-IP layer protection 57 mechanisms such as Automatic Protection Switching (APS), 58 Virtual Router Redundancy Protocol (VRRP), and Multi-Protocol 59 Label Switching Fast Reroute (MPLS-FRR). 61 Table of Contents 62 1. Introduction..............................................3 63 2. Existing definitions......................................4 64 3. Test Considerations.......................................4 65 3.1. Path.................................................5 66 3.1.1. Path............................................5 67 3.1.2. Tunnel..........................................6 68 3.1.3. Working Path....................................6 69 3.1.4. Primary Path....................................7 70 3.1.5. Protected Primary Path..........................7 71 3.1.6. Backup Path.....................................8 72 3.1.7. Standby Backup Path.............................8 73 3.1.8. Dynamic Backup Path.............................9 74 3.1.9. Disjoint Paths..................................9 75 3.1.10. Shared Risk Link Group (SRLG)..................10 76 3.2. Protection...........................................10 77 3.2.1. Protection Switching System.....................10 78 3.2.2. Link Protection.................................11 79 3.2.3. Node Protection.................................11 80 3.2.4. Path Protection.................................12 81 3.2.5. Backup Span.....................................12 82 3.3. Failure..............................................13 83 3.3.1. Failure Detection...............................13 84 3.3.2. Failover Event..................................13 85 3.3.3. Failover........................................14 86 3.3.4. Restoration (Failover recovery).................14 87 3.3.5. Reversion.......................................15 88 3.4. Nodes................................................15 89 3.4.1. Protection-Switching Node.......................15 90 3.4.2. Non-Protection Switching Node...................15 91 3.4.3. Failover Node...................................16 92 3.4.4. Merge Node......................................16 93 Protection Performance 95 3.4.5. Point of Local repair (PLR).....................17 96 3.4.6. Head-end Failover Node..........................17 97 3.5. Metrics..............................................18 98 3.5.1. Failover Packet Loss............................18 99 3.5.2. Reversion Packet Loss...........................18 100 3.5.3. Primary Path Latency............................19 101 3.5.4. Backup Path Latency.............................19 102 3.6. Benchmarks...........................................19 103 3.6.1. Failover Time...................................19 104 3.6.2. Additive Backup Latency.........................20 105 3.6.3. Reversion Time..................................21 106 4. Acknowledgments...........................................22 107 5. IANA Considerations.......................................22 108 6. Security Considerations...................................22 109 7. References................................................22 110 7.1. Normative References.................................22 111 7.2. Informative References...............................23 112 8. Author's Address..........................................23 114 1. Introduction 116 The IP network layer provides route convergence to protect data 117 traffic against planned and unplanned failures in the internet. 118 Fast convergence times are critical to maintain reliable network 119 connectivity and performance. Technologies that function at sub-IP 120 layers can be enabled to provide further protection of IP 121 traffic by providing the failure recovery at the sub-IP layers so 122 that the outage is not observed at the IP-layer. Such technologies 123 includes High Availability (HA) stateful failover. Virtual Router 124 Redundancy Protocol (VRRP), Automatic Link Protection (APS) for 125 SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast 126 Reroute for Multi-Protocol Label Switching (MPLS). 128 Benchmarking terminology have been defined for IP-layer route 129 convergence [7]. New terminology and methodologies specific 130 to benchmarking sub-IP layer protection mechanisms are required. 131 This will enable different implementations of the same 132 protection mechanisms to be benchmarked and evaluated. In 133 addition, different protection mechanisms can be benchmarked and 134 evaluated. The metrics for benchmarking the performance of sub-IP 135 protection mechanisms are measured at the IP layer, so that the 136 results are always measured in reference to IP and independent of 137 Protection Performance 139 the specific protection mechanism being used. The purpose of this 140 document is to provide a single terminology for benchmarking sub-IP 141 protection mechanisms. It is intended that there can exist unique 142 methodology documents for each sub-IP protection mechanism. 144 Figure 1 shows the fundamental model that is to be used in 145 benchmarking sub-IP protection mechanisms. Protection Switching 146 consists of a minimum of two Protection-Switching Nodes with a 147 Primary Path and a Backup Path. A Failover Event occurs along the 148 Primary Path. A tester is set outside the two nodes as it sends 149 and receives IP traffic along the Working Path. The Working Path 150 is the Primary Path prior to the Failover Event and the Backup Path 151 following the Failover Event. If Reversion is supported then the 153 +-----------+ 154 +--------------------| Tester |<-------------------+ 155 | +-----------+ | 156 | IP Traffic | Failover IP Traffic | 157 | | Event | 158 | Primary | | 159 | +--------+ Path v +--------+ | 160 | | |------------------------>| | | 161 +--->| Node 1 | | Node 2 |----+ 162 | |- - - - - - - - - - - - >| | 163 +--------+ Backup Path +--------+ 164 | | 165 | IP-Layer Forwarding | 166 +-------------------------------------------+ 168 Figure 1. System Under Test (SUT) for Sub-IP Protection Mechanisms 170 Working Path is the Primary Path after Failure Recovery. The 171 tester MUST record the IP packet sequence numbers, departure time, 172 and arrival time so that the metrics of Failover Time, Additive 173 Latency, and Reversion Time can be measured. The Tester may be a 174 single device or a test system. 176 Protection Performance 178 2. Existing definitions 179 This document draws on existing terminology defined in other BMWG 180 work. Examples include, but are not limited to: 182 Latency [Ref.[2], section 3.8] 183 Frame Loss Rate [Ref.[2], section 3.6] 184 Throughput [Ref.[2], section 3.17] 185 Device Under Test (DUT) [Ref.[3], section 3.1.1] 186 System Under Test (SUT) [Ref.[3], section 3.1.2] 187 Out-of-order Packet [Ref.[4], section 3.3.2] 188 Duplicate Packet [Ref.[4], section 3.3.3] 190 This document adopts the definition format in Section 2 of RFC 1242 191 [2]. 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in BCP 14, RFC 2119 [5]. 196 RFC 2119 defines the use of these key words to help make the 197 intent of standards track documents as clear as possible. While this 198 document uses these keywords, this document is not a standards track 199 document. 201 3. Test Considerations 203 This section discusses the fundamentals of MPLS Protection 204 testing: 205 -The types of network events that causes failover 206 -Indications for failover 207 -the use of data traffic 208 -Traffic generation 209 -LSP Scaling 210 -Reversion of LSP 211 -IGP Selection 213 3.1. Path 215 3.1.1 Path 217 Definition: 218 A sequence of nodes, , with the following 219 properties: 220 - R1 is the ingress node and forwards IP packets, which input 221 into DUT/SUT, to R2 as sub-IP frames. 222 - Ri is a node which forwards data frames to R[i+1] for all i, 223 1