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