idnits 2.17.1 draft-ietf-bmwg-protection-term-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (October 2009) is 5306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 1367, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-16 ** Obsolete normative reference: RFC 3768 (ref. '11') (Obsoleted by RFC 5798) Summary: 3 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: April 2010 4 Intended Status: Informational Rajiv Papneja 5 Isocore 7 J. Karthik 8 S. Vapiwala 9 Cisco Systems 11 October 2009 13 Benchmarking Terminology 14 for Protection Performance 15 17 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 15, 2010. 38 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 49 This document provides common terminology and metrics for benchmarking 50 the performance of sub-IP layer protection mechanisms. The performance 51 benchmarks are measured at the IP-Layer, avoiding dependence on 52 specific sub-IP protection mechanisms. The benchmarks and terminology 53 can be applied in methodology documents for different sub-IP layer 54 protection mechanisms such as Automatic Protection Switching (APS), 55 Virtual Router Redundancy Protocol (VRRP), Stateful High Availability 56 (HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). 58 Protection Performance 59 Table of Contents 60 1. Introduction..............................................3 61 2. Existing definitions......................................6 62 3. Test Considerations.......................................7 63 3.1. Paths................................................7 64 3.1.1. Path............................................7 65 3.1.2. Working Path....................................8 66 3.1.3. Primary Path....................................8 67 3.1.4. Protected Primary Path..........................8 68 3.1.5. Backup Path.....................................9 69 3.1.6. Standby Backup Path.............................10 70 3.1.7. Dynamic Backup Path.............................10 71 3.1.8. Disjoint Paths..................................10 72 3.1.9. Point of Local repair (PLR).....................11 73 3.1.10. Shared Risk Link Group (SRLG)..................11 74 3.2. Protection Mechanisms................................12 75 3.2.1. Link Protection.................................12 76 3.2.2. Node Protection.................................12 77 3.2.3. Path Protection.................................12 78 3.2.4. Backup Span.....................................13 79 3.2.5. Local Link Protection...........................13 80 3.2.6. Redundant Node Protection.......................14 81 3.2.7 State Control Interface.........................14 82 3.2.8. Protected Interface.............................15 83 3.3. Protection Switching.................................15 84 3.3.1. Protection Switching System.....................15 85 3.3.2. Failover Event..................................15 86 3.3.3. Failure Detection...............................16 87 3.3.4. Failover........................................17 88 3.3.5. Restoration.....................................17 89 3.3.6. Reversion.......................................18 90 3.4. Nodes................................................18 91 3.4.1. Protection-Switching Node.......................18 92 3.4.2. Non-Protection Switching Node...................19 93 3.4.3. Headend Node....................................19 94 3.4.4. Backup Node.....................................19 95 3.4.5. Merge Node......................................20 96 3.4.6. Primary Node....................................20 97 3.4.7. Standby Node....................................21 98 3.5. Benchmarks...........................................21 99 3.5.1. Failover Packet Loss............................21 100 3.5.2. Reversion Packet Loss...........................22 101 3.5.3. Failover Time...................................22 102 3.5.4. Reversion Time..................................23 103 3.5.5. Additive Backup Delay...........................23 104 3.6 Failover Time Calculation Methods.....................24 105 3.6.1 Time-Based Loss Method...........................24 106 3.6.2 Packet-Loss Based Method.........................25 107 3.6.3 Timestamp-Based Method...........................25 108 4. Acknowledgments...........................................26 109 5. IANA Considerations.......................................26 110 6. Security Considerations...................................26 111 7. References................................................26 112 8. Authors' Addresses........................................27 113 Protection Performance 115 1. Introduction 117 The IP network layer provides route convergence to protect data 118 traffic against planned and unplanned failures in the internet. Fast 119 convergence times are critical to maintain reliable network 120 connectivity and performance. Convergence Events [7] are recognized 121 at the IP Layer so that Route Convergence [7] occurs. Technologies 122 that function at sub-IP layers can be enabled to provide further 123 protection of IP traffic by providing the failure recovery at the 124 sub-IP layers so that the outage is not observed at the IP-layer. 125 Such sub-IP protection technologies include, but are not limited to, 126 High Availability (HA) stateful failover, Virtual Router Redundancy 127 Protocol (VRRP) [11], Automatic Link Protection (APS) for SONET/SDH, 128 Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for 129 Multi-Protocol Label Switching (MPLS-FRR) [8]. 131 1.1 Scope 132 Benchmarking terminology was defined for IP-layer convergence in 133 [7]. Different terminology and methodologies specific to 134 benchmarking sub-IP layer protection mechanisms are required. The 135 metrics for benchmarking the performance of sub-IP protection 136 mechanisms are measured at the IP layer, so that the results are 137 always measured in reference to IP and independent of the specific 138 protection mechanism being used. The purpose of this document is 139 to provide a single terminology for benchmarking sub-IP protection 140 mechanisms. 142 A common terminology for Sub-IP layer protection mechanism 143 benchmarking enables different implementations of a protection 144 mechanism to be benchmarked and evaluated. In addition, 145 implementations of different protection mechanisms can be 146 benchmarked and evaluated. It is intended that there can exist 147 unique methodology documents for each sub-IP protection mechanism 148 based upon this common terminology document. The terminology 149 can be applied to methodologies that benchmark sub-IP protection 150 mechanism performance with a single stream of traffic or 151 multiple streams of traffic. The traffic flow may be 152 uni-directional or bi-directional as to be indicated in the 153 methodology. 155 1.2 General Model 156 The sequence of events to benchmark the performance of Sub-IP 157 Protection Mechanisms is as follows: 159 1. Failover Event - Primary Path fails 160 2. Failure Detection- Failover Event is detected 161 3. Failover - Backup Path becomes the Working Path due to Failover 162 Event 163 4. Restoration - Primary Path recovers from a Failover Event 164 5. Reversion (optional) - Primary Path becomes the Working Path 166 These terms are further defined in this document. 168 Protection Performance 170 Figures 1 through 5 show models that MAY be used when benchmarking 171 Sub-IP Protection mechanisms, which MUST use a Protection Switching 172 System that consists of a minimum of two Protection-Switching Nodes, 173 an Ingress Node known as the Headend Node and an Egress Node known 174 as the Merge Node. The Protection Switching System MUST include 175 either a Primary Path and Backup Path, as shown in Figures 1 through 176 4, or a Primary Node and Standby Node, as shown in Figure 5. A 177 Protection Switching System may provide link protection, node 178 protection, path protection, local link protection, and high 179 availability, as shown in Figures 1 through 5 respectively. A 180 Failover Event occurs along the Primary Path or at the Primary Node. 181 The Working Path is the Primary Path prior to the Failover Event and 182 the Backup Path after the Failover Event. A Tester is set outside 183 the two paths or nodes as it sends and receives IP traffic along the 184 Working Path. The tester MUST record the IP packet sequence numbers, 185 departure time, and arrival time so that the metrics of Failover 186 Time, Additive Latency, Packet Reordering, Duplicate Packets, and 187 Reversion Time can be measured. The Tester may be a single device 188 or a test system. If Reversion is supported then the Working Path is 189 the Primary Path after Restoration (Failure Recovery) of the Primary 190 Path. 192 Link Protection, as shown in Figure 1, provides protection when a 193 Failover Event occurs on the link between two nodes along the Primary 194 Path. Node Protection, as shown in Figure 2, provides protection 195 when a Failover Event occurs at a Node along the Primary Path. 196 Path Protection, as shown in Figure 3, provides protection for link 197 or node failures for multiple hops along the Primary Path. Local 198 Link Protection, as shown in Figure 4, provides Sub-IP Protection of 199 a link between two nodes, without a Backup Node. An example of such 200 a Sub-IP Protection mechanism is SONET APS. High Availability 201 Protection, as shown in Figure 5, provides protection of a Primary 202 Node with a redundant Standby Node. State Control is provided 203 between the Primary and Standby Nodes. Failure of the Primary Node 204 is detected at the Sub-IP layer to force traffic to switch to the 205 Standby Node, which has state maintained for zero or minimal packet 206 loss. 208 +-----------+ 209 +--------------| Tester |<-----------------------+ 210 | +-----------+ | 211 | IP Traffic | Failover IP Traffic | 212 | | Event | 213 | ------------ | ---------- | 214 +--->| Ingress/ | V | Egress/ |---+ 215 |Headend Node|------------------|Merge Node| Primary 216 ------------ ---------- Path 217 | ^ 218 | --------- | Backup 219 +--------| Backup |-------------+ Path 220 | Node | 221 --------- 222 Figure 1. System Under Test (SUT) for Sub-IP Link Protection 223 Protection Performance 225 +-----------+ 226 +--------------------| Tester |<-----------------+ 227 | +-----------+ | 228 | IP Traffic | Failover IP Traffic | 229 | | Event | 230 | V | 231 | ------------ -------- ---------- | 232 +--->| Ingress/ | |MidPoint| | Egress/ |---+ 233 |Headend Node|----| Node |----|Merge Node| Primary 234 ------------ -------- ---------- Path 235 | ^ 236 | --------- | Backup 237 +--------| Backup |-------------+ Path 238 | Node | 239 --------- 241 Figure 2. System Under Test (SUT) for Sub-IP Node Protection 243 +-----------+ 244 +---------------------------| Tester |<----------------------+ 245 | +-----------+ | 246 | IP Traffic | Failover IP Traffic | 247 | | Event | 248 | Primary Path | | 249 | ------------ -------- | -------- ---------- | 250 +--->| Ingress/ | |MidPoint| V |Midpoint| | Egress/ |---+ 251 |Headend Node|----| Node |---| Node |---|Merge Node| 252 ------------ -------- -------- ---------- 253 | ^ 254 | --------- -------- | Backup 255 +--------| Backup |----| Backup |--------+ Path 256 | Node | | Node | 257 --------- -------- 259 Figure 3. System Under Test (SUT) for Sub-IP Path Protection 261 +-----------+ 262 +--------------------| Tester |<-------------------+ 263 | +-----------+ | 264 | IP Traffic | Failover IP Traffic | 265 | | Event | 266 | Primary | | 267 | +--------+ Path v +--------+ | 268 | | |------------------------>| | | 269 +--->| Ingress| | Egress |----+ 270 | Node |- - - - - - - - - - - - >| Node | 271 +--------+ Backup Path +--------+ 272 ^ ^ 273 | IP-Layer Forwarding | 274 +-------------------------------------------+ 276 Figure 4. System Under Test (SUT) for Sub-IP Local Link Protection 277 Protection Performance 279 +-----------+ 280 +-----------------| Tester |<--------------------+ 281 | +-----------+ | 282 | IP Traffic | Failover IP Traffic | 283 | | Event | 284 | V | 285 | --------- -------- ---------- | 286 +--->| Ingress | |Primary | | Egress/ |------+ 287 | Node |----| Node |----|Merge Node| Primary 288 --------- -------- ---------- Path 289 | State |Control ^ 290 | Interface |(Optional) | 291 | --------- | 292 +---------| Standby |---------+ 293 | Node | 294 --------- 296 Figure 5. System Under Test (SUT) for Sub-IP Redundant Node Protection 298 2. Existing definitions 299 This document uses existing terminology defined in other BMWG 300 work. Examples include, but are not limited to: 302 Latency [Ref.[2], section 3.8] 303 Frame Loss Rate [Ref.[2], section 3.6] 304 Throughput [Ref.[2], section 3.17] 305 Device Under Test (DUT) [Ref.[3], section 3.1.1] 306 System Under Test (SUT) [Ref.[3], section 3.1.2] 307 Offered Load [Ref.[3], section 3.5.2] 308 Out-of-order Packet [Ref.[4], section 3.3.2] 309 Duplicate Packet [Ref.[4], section 3.3.3] 310 Forwarding Delay [Ref.[4], section 3.2.4] 311 Jitter [Ref.[4], section 3.2.5] 312 Packet Loss [Ref.[7], Section 3.5] 313 Packet Reordering [Ref.[10], section 3.3] 315 This document has the following frequently used acronyms: 316 DUT Device Under Test 317 SUT System Under Test 319 This document adopts the definition format in Section 2 of RFC 1242 320 [2]. Terms defined in this document are capitalized when used 321 within this document. 323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 325 document are to be interpreted as described in BCP 14, RFC 2119 [5]. 326 RFC 2119 defines the use of these key words to help make the 327 intent of standards track documents as clear as possible. While this 328 document uses these keywords, this document is not a standards track 329 document. 331 Protection Performance 333 3. Test Considerations 335 3.1. Paths 337 3.1.1 Path 339 Definition: 340 A unidirectional sequence of nodes, , and links 341 with the following properties: 343 a. R1 is the ingress node and forwards IP packets, which input 344 into DUT/SUT, to R2 as sub-IP frames over link L12. 346 b. Ri is a node which forwards data frames to R[i+1] over Link 347 Li[i+1] for all i, 1