idnits 2.17.1 draft-ietf-bmwg-protection-term-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 25) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2010) is 5032 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-21 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Poretsky 2 Internet Draft Allot Communications 3 Expires: Jan 2011 Rajiv Papneja 4 Intended Status: Informational Isocore 5 J. Karthik 6 S. Vapiwala 7 Cisco Systems 8 July 2010 10 Benchmarking Terminology 11 for Protection Performance 12 14 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on 7 Jan, 2011. 35 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described 46 in Section 4.e of the Trust Legal Provisions and are provided 47 without warranty as described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) 55 controlling the copyright in such materials, this document may not 56 be modified outside the IETF Standards Process, and derivative 57 works of it may not be created outside the IETF Standards Process, 58 except to format it for publication as an RFC or to translate it 59 into languages other than English. 61 Protection Performance 63 Abstract 64 This document provides common terminology and metrics for benchmarking 65 the performance of sub-IP layer protection mechanisms. The performance 66 benchmarks are measured at the IP-Layer with protection may be 67 provided at the Sub-IP layer. The benchmarks and terminology can be 68 applied in methodology documents for different sub-IP layer protection 69 mechanisms such as Automatic Protection Switching (APS), Virtual Router 70 Redundancy Protocol (VRRP), Stateful High Availability (HA), and 71 Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). 73 Protection Performance 74 Table of Contents 75 1. Introduction..............................................3 76 2. Existing definitions......................................6 77 3. Test Considerations.......................................7 78 3.1. Paths................................................7 79 3.1.1. Path............................................7 80 3.1.2. Working Path....................................8 81 3.1.3. Primary Path....................................8 82 3.1.4. Protected Primary Path..........................8 83 3.1.5. Backup Path.....................................9 84 3.1.6. Standby Backup Path.............................10 85 3.1.7. Dynamic Backup Path.............................10 86 3.1.8. Disjoint Paths..................................10 87 3.1.9. Point of Local repair (PLR).....................11 88 3.1.10. Shared Risk Link Group (SRLG)..................11 89 3.2. Protection Mechanisms................................12 90 3.2.1. Link Protection.................................12 91 3.2.2. Node Protection.................................12 92 3.2.3. Path Protection.................................12 93 3.2.4. Backup Span.....................................13 94 3.2.5. Local Link Protection...........................13 95 3.2.6. Redundant Node Protection.......................14 96 3.2.7 State Control Interface.........................14 97 3.2.8. Protected Interface.............................15 98 3.3. Protection Switching.................................15 99 3.3.1. Protection Switching System.....................15 100 3.3.2. Failover Event..................................15 101 3.3.3. Failure Detection...............................16 102 3.3.4. Failover........................................17 103 3.3.5. Restoration.....................................17 104 3.3.6. Reversion.......................................18 105 3.4. Nodes................................................18 106 3.4.1. Protection-Switching Node.......................18 107 3.4.2. Non-Protection Switching Node...................19 108 3.4.3. Headend Node....................................19 109 3.4.4. Backup Node.....................................19 110 3.4.5. Merge Node......................................20 111 3.4.6. Primary Node....................................20 112 3.4.7. Standby Node....................................21 113 3.5. Benchmarks...........................................21 114 3.5.1. Failover Packet Loss............................21 115 3.5.2. Reversion Packet Loss...........................22 116 3.5.3. Failover Time...................................22 117 3.5.4. Reversion Time..................................23 118 3.5.5. Additive Backup Delay...........................23 119 3.6 Failover Time Calculation Methods.....................24 120 3.6.1 Time-Based Loss Method...........................24 121 3.6.2 Packet-Loss Based Method.........................25 122 3.6.3 Timestamp-Based Method...........................25 123 4. Acknowledgments...........................................26 124 5. IANA Considerations.......................................26 125 6. Security Considerations...................................26 126 7. References................................................26 127 8. Authors' Addresses........................................27 128 Protection Performance 130 1. Introduction 132 The IP network layer provides route convergence to protect data 133 traffic against planned and unplanned failures in the internet. Fast 134 convergence times are critical to maintain reliable network 135 connectivity and performance. Convergence Events [6] are recognized 136 at the IP Layer so that Route Convergence [6] occurs. Technologies 137 that function at sub-IP layers can be enabled to provide further 138 protection of IP traffic by providing the failure recovery at the 139 sub-IP layers so that the outage is not observed at the IP-layer. 140 Such sub-IP protection technologies include, but are not limited to, 141 High Availability (HA) stateful failover, Virtual Router Redundancy 142 Protocol (VRRP) [8], Automatic Link Protection (APS) for SONET/SDH, 143 Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for 144 Multi-Protocol Label Switching (MPLS-FRR) [9]. 146 1.1 Scope 147 Benchmarking terminology was defined for IP-layer convergence in 148 [6]. Different terminology and methodologies specific to 149 benchmarking sub-IP layer protection mechanisms are required. The 150 metrics for benchmarking the performance of sub-IP protection 151 mechanisms are measured at the IP layer, so that the results are 152 always measured in reference to IP and independent of the specific 153 protection mechanism being used. The purpose of this document is 154 to provide a single terminology for benchmarking sub-IP protection 155 mechanisms. 157 A common terminology for Sub-IP layer protection mechanism 158 benchmarking enables different implementations of a protection 159 mechanism to be benchmarked and evaluated. In addition, 160 implementations of different protection mechanisms can be 161 benchmarked and evaluated. It is intended that there can exist 162 unique methodology documents for each sub-IP protection mechanism 163 based upon this common terminology document. The terminology 164 can be applied to methodologies that benchmark sub-IP protection 165 mechanism performance with a single stream of traffic or 166 multiple streams of traffic. The traffic flow may be 167 uni-directional or bi-directional as to be indicated in the 168 methodology. 170 1.2 General Model 171 The sequence of events to benchmark the performance of Sub-IP 172 Protection Mechanisms is as follows: 174 1. Failover Event - Primary Path fails 175 2. Failure Detection- Failover Event is detected 176 3. Failover - Backup Path becomes the Working Path due to Failover 177 Event 178 4. Restoration - Primary Path recovers from a Failover Event 179 5. Reversion (optional) - Primary Path becomes the Working Path 181 These terms are further defined in this document. 183 Protection Performance 185 Figures 1 through 5 show models that MAY be used when benchmarking 186 Sub-IP Protection mechanisms, which MUST use a Protection Switching 187 System that consists of a minimum of two Protection-Switching Nodes, 188 an Ingress Node known as the Headend Node and an Egress Node known 189 as the Merge Node. The Protection Switching System MUST include 190 either a Primary Path and Backup Path, as shown in Figures 1 through 191 4, or a Primary Node and Standby Node, as shown in Figure 5. A 192 Protection Switching System may provide link protection, node 193 protection, path protection, local link protection, and high 194 availability, as shown in Figures 1 through 5 respectively. A 195 Failover Event occurs along the Primary Path or at the Primary Node. 196 The Working Path is the Primary Path prior to the Failover Event and 197 the Backup Path after the Failover Event. A Tester is set outside 198 the two paths or nodes as it sends and receives IP traffic along the 199 Working Path. The tester MUST record the IP packet sequence numbers, 200 departure time, and arrival time so that the metrics of Failover 201 Time, Additive Latency, Packet Reordering, Duplicate Packets, and 202 Reversion Time can be measured. The Tester may be a single device 203 or a test system. If Reversion is supported then the Working Path is 204 the Primary Path after Restoration (Failure Recovery) of the Primary 205 Path. 207 Link Protection, as shown in Figure 1, provides protection when a 208 Failover Event occurs on the link between two nodes along the Primary 209 Path. Node Protection, as shown in Figure 2, provides protection 210 when a Failover Event occurs at a Node along the Primary Path. 211 Path Protection, as shown in Figure 3, provides protection for link 212 or node failures for multiple hops along the Primary Path. Local 213 Link Protection, as shown in Figure 4, provides Sub-IP Protection of 214 a link between two nodes, without a Backup Node. An example of such 215 a Sub-IP Protection mechanism is SONET APS. High Availability 216 Protection, as shown in Figure 5, provides protection of a Primary 217 Node with a redundant Standby Node. State Control is provided 218 between the Primary and Standby Nodes. Failure of the Primary Node 219 is detected at the Sub-IP layer to force traffic to switch to the 220 Standby Node, which has state maintained for zero or minimal packet 221 loss. 223 +-----------+ 224 +--------------| Tester |<-----------------------+ 225 | +-----------+ | 226 | IP Traffic | Failover IP Traffic | 227 | | Event | 228 | ------------ | ---------- | 229 +--->| Ingress/ | V | Egress/ |---+ 230 |Headend Node|------------------|Merge Node| Primary 231 ------------ ---------- Path 232 | ^ 233 | --------- | Backup 234 +--------| Backup |-------------+ Path 235 | Node | 236 --------- 237 Figure 1. System Under Test (SUT) for Sub-IP Link Protection 238 Protection Performance 240 +-----------+ 241 +--------------------| Tester |<-----------------+ 242 | +-----------+ | 243 | IP Traffic | Failover IP Traffic | 244 | | Event | 245 | V | 246 | ------------ -------- ---------- | 247 +--->| Ingress/ | |MidPoint| | Egress/ |---+ 248 |Headend Node|----| Node |----|Merge Node| Primary 249 ------------ -------- ---------- Path 250 | ^ 251 | --------- | Backup 252 +--------| Backup |-------------+ Path 253 | Node | 254 --------- 256 Figure 2. System Under Test (SUT) for Sub-IP Node Protection 258 +-----------+ 259 +---------------------------| Tester |<----------------------+ 260 | +-----------+ | 261 | IP Traffic | Failover IP Traffic | 262 | | Event | 263 | Primary Path | | 264 | ------------ -------- | -------- ---------- | 265 +--->| Ingress/ | |MidPoint| V |Midpoint| | Egress/ |---+ 266 |Headend Node|----| Node |---| Node |---|Merge Node| 267 ------------ -------- -------- ---------- 268 | ^ 269 | --------- -------- | Backup 270 +--------| Backup |----| Backup |--------+ Path 271 | Node | | Node | 272 --------- -------- 274 Figure 3. System Under Test (SUT) for Sub-IP Path Protection 276 +-----------+ 277 +--------------------| Tester |<-------------------+ 278 | +-----------+ | 279 | IP Traffic | Failover IP Traffic | 280 | | Event | 281 | Primary | | 282 | +--------+ Path v +--------+ | 283 | | |------------------------>| | | 284 +--->| Ingress| | Egress |----+ 285 | Node |- - - - - - - - - - - - >| Node | 286 +--------+ Backup Path +--------+ 287 | | 288 | IP-Layer Forwarding | 289 +<----------------------------------------->+ 291 Figure 4. System Under Test (SUT) for Sub-IP Local Link Protection 292 Protection Performance 294 +-----------+ 295 +-----------------| Tester |<--------------------+ 296 | +-----------+ | 297 | IP Traffic | Failover IP Traffic | 298 | | Event | 299 | V | 300 | --------- -------- ---------- | 301 +--->| Ingress | |Primary | | Egress/ |------+ 302 | Node |----| Node |----|Merge Node| Primary 303 --------- -------- ---------- Path 304 | State |Control ^ 305 | Interface |(Optional) | 306 | --------- | 307 +---------| Standby |---------+ 308 | Node | 309 --------- 311 Figure 5. System Under Test (SUT) for Sub-IP Redundant Node Protection 313 Some protection switching technologies may use a series of 314 steps that differ from the general model. The specific differences 315 SHOULD be highlighted in each technology-specific methodology. 316 Note that some protection switching technologies are endowed 317 with the ability to re-optimize the working path after a 318 node or link failure. 320 2. Existing definitions 321 This document uses existing terminology defined in other BMWG 322 work. Examples include, but are not limited to: 324 Latency [Ref.[2], section 3.8] 325 Frame Loss Rate [Ref.[2], section 3.6] 326 Throughput [Ref.[2], section 3.17] 327 Device Under Test (DUT) [Ref.[3], section 3.1.1] 328 System Under Test (SUT) [Ref.[3], section 3.1.2] 329 Offered Load [Ref.[3], section 3.5.2] 330 Out-of-order Packet [Ref.[4], section 3.3.2] 331 Duplicate Packet [Ref.[4], section 3.3.3] 332 Forwarding Delay [Ref.[4], section 3.2.4] 333 Jitter [Ref.[4], section 3.2.5] 334 Packet Loss [Ref.[6], Section 3.5] 335 Packet Reordering [Ref.[7], section 3.3] 337 This document has the following frequently used acronyms: 338 DUT Device Under Test 339 SUT System Under Test 341 This document adopts the definition format in Section 2 of RFC 1242 342 [2]. Terms defined in this document are capitalized when used 343 within this document. 345 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 346 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 347 document are to be interpreted as described in BCP 14, RFC 2119 [5]. 349 Protection Performance 351 RFC 2119 defines the use of these key words to help make the 352 intent of standards track documents as clear as possible. While this 353 document uses these keywords, this document is not a standards track 354 document. 356 3. Test Considerations 358 3.1. Paths 360 3.1.1 Path 362 Definition: 363 A unidirectional sequence of nodes, , and links 364 with the following properties: 366 a. R1 is the ingress node and forwards IP packets, which input 367 into DUT/SUT, to R2 as sub-IP frames over link L12. 369 b. Ri is a node which forwards data frames to R(i+1) over Link 370 Li(i+1) for all i, 1