idnits 2.17.1 draft-ietf-bmwg-protection-term-00.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1094. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1101. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1107. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 42 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 2006) is 6395 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '9' is mentioned on line 128, but not defined == Unused Reference: '1' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1027, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '3') ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-dsmterm (ref. '4') -- Duplicate reference: RFC2026, mentioned in '6', was also mentioned in '1'. == Outdated reference: A later version (-23) exists of draft-ietf-bmwg-igp-dataplane-conv-term-09 ** Downref: Normative reference to an Informational draft: draft-ietf-bmwg-igp-dataplane-conv-term (ref. '7') Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft 3 Expires: April 2007 4 S. Poretsky 5 Reef Point Systems 7 R. Papneja 8 Isocore 10 J. Karthik 11 Cisco Systems 13 October 2006 15 Benchmarking Terminology for Protection Performance 16 18 Intellectual Property Rights (IPR) statement: 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Status of this Memo 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use 34 Internet-Drafts as reference material or to cite them other 35 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 Internet Society (2006). 46 Protection Performance 48 Abstract 49 This document provides common terminology and metrics for 50 benchmarking the performance of sub-IP layer protection 51 mechanisms. The performance benchmarks are measured at the 52 IP-Layer, so avoid dependence on specific sub-IP protections 53 mechanisms. The benchmarks and terminology can be applied in 54 methodology documents for different sub-IP layer protection 55 mechanisms such as Automatic Protection Switching (APS), 56 Virtual Router Redundancy Protocol (VRRP), and Multi-Protocol 57 Label Switching Fast Reroute (MPLS-FRR). 59 Table of Contents 60 1. Introduction..............................................3 61 2. Existing definitions......................................4 62 3. Test Considerations.......................................5 63 3.1. Path.................................................6 64 3.1.1. Path............................................6 65 3.1.2. Tunnel..........................................7 66 3.1.3. Working Path....................................7 67 3.1.4. Primary Path....................................8 68 3.1.5. Protected Primary Path..........................8 69 3.1.6. Backup Path.....................................9 70 3.1.7. Standby Backup Path.............................9 71 3.1.8. Dynamic Backup Path.............................10 72 3.1.9. Disjoint Paths..................................10 73 3.1.10. Shared Risk Link Group (SRLG)..................11 74 3.2. Protection...........................................11 75 3.2.1. Protection Switching System.....................11 76 3.2.2. Link Protection.................................12 77 3.2.3. Node Protection.................................12 78 3.2.4. Path Protection.................................13 79 3.2.5. Backup Span.....................................13 80 3.3. Failure..............................................14 81 3.3.1. Failure Detection...............................14 82 3.3.2. Failover Event..................................14 83 3.3.3. Failover........................................15 84 3.3.4. Restoration (Failover recovery).................16 85 3.3.5. Reversion.......................................16 86 3.4. Nodes................................................17 87 3.4.1. Protection-Switching Node.......................17 88 3.4.2. Non-Protection Switching Node...................17 89 3.4.3. Failover Node...................................18 90 3.4.4. Merge Node......................................19 91 Protection Performance 93 3.4.5. Point of Local repair (PLR).....................19 94 3.4.6. Head-end Failover Node..........................20 95 3.5. Metrics..............................................20 96 3.5.1. Failover Packet Loss............................20 97 3.5.2. Reversion Packet Loss...........................21 98 3.5.3. Primary Path Latency............................22 99 3.5.4. Backup Path Latency.............................22 100 3.5.5. Metrics.........................................22 101 3.6. Benchmarks...........................................20 102 3.6.1. Failover Time...................................20 103 3.6.2. Additive Backup Latency.........................21 104 3.6.3. Reversion Time..................................21 105 4. Acknowledgments...........................................22 106 5. IANA Considerations.......................................22 107 6. Security Considerations...................................22 108 7. References................................................23 109 7.1. Normative References.................................23 110 7.2. Informative References...............................24 111 8. Author's Address..........................................24 113 1. Introduction 115 The IP network layer provides route convergence to protect data 116 traffic against planned and unplanned failures in the internet. 117 Fast convergence times are critical to maintain reliable network 118 connectivity and performance. Technologies that function at sub-IP 119 layers can be enabled to provide further protection of IP 120 traffic by providing the failure recovery at the sub-IP layers so 121 that the outage is not observed at the IP-layer. Such technologies 122 include High Availability (HA) stateful failover. Virtual Router 123 Redundancy Protocol (VRRP), Automatic Link Protection (APS) for 124 SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast 125 Reroute for Multi-Protocol Label Switching (MPLS). 127 Benchmarking terminology and methodology have been defined for 128 IP-layer route convergence [7,8,9]. New terminology and 129 methodologies specific to benchmarking sub-IP layer protection 130 mechanisms are required. This will enable different implementations 131 of the same protection mechanisms to be benchmarked and evaluated. 132 In addition, different protection mechanisms can be benchmarked and 133 evaluated. The metrics for benchmarking the performance of sub-IP 134 protection mechanisms are measured at the IP layer, so that the 135 results are always measured in reference to IP and independent of 136 Protection Performance 138 the specific protection mechanism being used. The purpose of this 139 document is to provide a single terminology for benchmarking sub-IP 140 protection mechanisms. It is intended that there can exist unique 141 methodology documents for each sub-IP protection mechanism. 143 Figure 1 shows the fundamental model that is to be used in 144 benchmarking sub-IP protection mechanisms. Protection Switching 145 consists of a minimum of two Protection-Switching Nodes with a 146 Primary Path and a Backup Path. A Failover Event occurs along the 147 Primary Path. A tester is set outside the two nodes as it sends 148 and receives IP traffic along the Working Path. The Working Path 149 is the Primary Path prior to the Failover Event and the Backup Path 150 following the Failover Event. If Reversion is supported then the 152 +-----------+ 153 +--------------------| Tester |<-------------------+ 154 | +-----------+ | 155 | IP Traffic | Failover IP Traffic | 156 | | Event | 157 | Primary | | 158 | +--------+ Path v +--------+ | 159 | | |------------------------>| | | 160 +--->| Node 1 | | Node 2 |----+ 161 | |- - - - - - - - - - - - >| | 162 +--------+ Backup Path +--------+ 163 | | 164 | IP-Layer Forwarding | 165 +-------------------------------------------+ 167 Figure 1. System Under Test (SUT) for Sub-IP Protection Mechanisms 169 Working Path is the Primary Path after Failure Recovery. The 170 tester MUST record the IP packet sequence numbers, departure time, 171 and arrival time so that the metrics of Failover Time, Additive 172 Latency, and Reversion Time can be measured. The Tester may be a 173 single device or a test system. 175 Protection Performance 177 2. Existing definitions 178 This document draws on existing terminology defined in other BMWG 179 work. Examples include, but are not limited to: 181 Latency [RFC 1242, section 3.8] 182 Frame Loss Rate [RFC 1242, section 3.6] 183 Throughput [RFC 1242, section 3.17] 184 Device Under Test (DUT) [RFC 2285, section 3.1.1] 185 System Under Test (SUT) [RFC 2285, section 3.1.2] 186 Out-of-order Packet [Ref.[4], section 3.3.2] 187 Duplicate Packet [Ref.[4], section 3.3.3] 189 This document adopts the definition format in Section 2 of RFC 1242. 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in BCP 14, RFC 2119. 194 RFC 2119 defines the use of these key words to help make the 195 intent of standards track documents as clear as possible. While this 196 document uses these keywords, this document is not a standards track 197 document. 199 3. Test Considerations 201 3.1. Path 203 3.1.1 Path 205 Definition: 206 A sequence of nodes, , with the following 207 properties: 208 - R1 is the ingress node and forwards IP packets, which input 209 into DUT/SUT, to R2 as sub-IP frames. 210 - Ri is a node which forwards data frames to R[i+1] for all i, 211 1, with the following 254 properties: 255 - R1 is the ingress node and forwards IP packets, which input 256 into DUT/SUT, to R2 as sub-IP frames. 257 - Ri is a node which forwards data frames to R[i+1] for all i, 258 1