idnits 2.17.1 draft-mirsky-ippm-epm-03.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: ---------------------------------------------------------------------------- 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 and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (26 March 2021) is 1126 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) == Outdated reference: A later version (-02) exists of draft-mmm-rtgwg-integrated-oam-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Mirsky 3 Internet-Draft X. Min 4 Intended status: Standards Track ZTE Corp. 5 Expires: 27 September 2021 L. Han 6 China Mobile 7 26 March 2021 9 Error Performance Measurement in Packet-switched Networks 10 draft-mirsky-ippm-epm-03 12 Abstract 14 This document describes the use of the error performance metric to 15 characterize a packet-switched network's conformance to the pre- 16 defined set of performance objectives. In this document, metrics 17 that characterize error performance in a packet-switched network 18 (PSN) are defined, as well as methods to measure and calculate them. 19 Also, the requirements for an active Operation, Administration, and 20 Maintenance protocol to support the error performance measurement in 21 PSN are discussed, and potential candidate protocols are analyzed. 22 All metrics and measurement methods are equally applicable to 23 underlay and overlay networks. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 27 September 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 2.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 61 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 3. Error Performance Metrics . . . . . . . . . . . . . . . . . . 4 63 3.1. Measure Error Performance Metrics . . . . . . . . . . . . 4 64 3.2. Calculate Error Performance Metrics . . . . . . . . . . . 5 65 4. Requirements to EPM . . . . . . . . . . . . . . . . . . . . . 5 66 5. Active OAM Protocol for EPM . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Operations, Administration, and Maintenance (OAM) is a collection of 78 methods to detect, characterize, localize failures in a network, and 79 monitor the network's performance using various measurement methods. 80 Traditionally, the former set of OAM tools identified as Fault 81 Management (FM) OAM. The latter - Performance Monitoring (PM) OAM. 82 Some OAM protocols can be used for both groups of tasks, while some 83 serve one particular group. But regardless of how many OAM protocols 84 are in use, network operators and network users are faced with 85 multiple metrics that characterize the network conditions. This 86 document describes a new component of packet-switched network (PSN) 87 OAM. 89 Error performance measurement (EPM) is a part of an OAM toolset that 90 provides an operator with information related to network measurements 91 for a uni-directional or a bidirectional connection between two 92 systems. In current technology, EPM has been defined only for data 93 communication methods that have a constant bit-rate transmission 94 [ITU.G.826] and not for PSN, where transmissions are statistically 95 random. As a statistically multiplexed network in a PSN, a receiver 96 node does not expect a packet to arrive from a sender node at a 97 specific moment, less from a particular sender. That is what 98 differentiates PSN from networks built on a constant bit-rate 99 transmission, where a stream of bits between two nodes is always 100 present, whether it represents data or not. That provides the 101 receiver with a predictable number of measurements in a series of 102 measurement intervals. In PSN, on-path OAM methods, i.e., 103 measurement methods that use data flow, cannot provide such 104 predictability and thus be used for EPM. In PSN, EPM needs to use 105 active OAM methods, per definition in [RFC7799]. This document 106 identifies metrics that characterize PSN error performance and 107 methods to measure and calculate them. Also, the requirements for an 108 active OAM protocol to support EPM in PSN are discussed, and 109 potential candidate protocols are analyzed. 111 2. Conventions used in this document 113 2.1. Terminology and Acronyms 115 OAM Operations, Administration, and Maintenance 117 EP Error Performance 119 EPM Error Performance Measurement 121 ES Errored Second 123 ESR Errored Second Ratio 125 SES Severely Errored Second 127 SESR Severely Errored Second Ratio 129 EFS Error-Free Second 131 PSN Packet-switched Network 133 FM Fault Management 135 PM Performance Monitoring 137 2.2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in BCP 142 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 3. Error Performance Metrics 147 When analyzing the error performance of a path between two nodes, we 148 need to select a time interval as the unit of EPM. In [ITU.G.826], a 149 time interval of one second is used. It is reasonable to use the 150 same time interval for EPM for PSNs. Further, for the purpose of 151 EPM, each time interval, i.e., second, is classified either as 152 Errored Second (ES), Severely Errored Second (SES), or Error-Free 153 Second (EFS). These are defined as follows: 155 * An ES is a time interval during which at least one of the 156 performance parameters degraded below its optimal level threshold 157 or a defect was detected. 159 * An SES is a time interval during which at least one the 160 performance parameters degraded below its critical threshold or a 161 defect was detected. 163 * Consequently, an EFS is a time interval during which all 164 performance objectives are at or above their respective optimal 165 levels, and no defect has been detected. 167 The definition of a state of a defect in the network is also 168 necessary for understanding the EPM. In this document, the defect is 169 interpreted as the state of inability to communicate between a 170 particular set of nodes. It is important to note that it is being 171 defined as a state, and thus, it has conditions that define entry 172 into it and exit out of it. Also, the state of defect exists only in 173 connection to the particular group of nodes in the network, not the 174 network as a domain. 176 3.1. Measure Error Performance Metrics 178 The definitions of ES, SES, and EFS allow for characterization of the 179 communication between two nodes relative to the level of required and 180 acceptable performance and when performance degrades below the 181 acceptable level. The former condition in this document referred to 182 as network availability. The latter - network unavailability. Based 183 on the definitions, SES is the one-second of network unavailability 184 while ES and EFS present an interval of network availability. But 185 since the conditions of network are everchanging periods of network 186 availability and unavailability need to be defined with duration 187 larger than one-second interval to reduce the number of state changes 188 while correctly reflecting the network condition. The method to 189 determine the state of the network in terms of EPM OAM is described 190 below: 192 * If ten consecutive SES intervals been detected, then the EPM state 193 of the network determined as unavailability and the beginning of 194 that period of unavailability state is at the start of the first 195 SES in the sequence of the consecutive SES intervals. 197 * Similarly, ten consecutive non-SES intervals, i.e., either ES or 198 EFS, indicate that the network is in the availability period, 199 i.e., available. The start of that period is at the beginning of 200 the first non-SES interval. 202 * Resulting from these two definitions, a sequence of less than ten 203 consecutive SES or non-SES intervals does not change the EPM state 204 of the network. For example, if the EPM state is determined as 205 unavailability, a sequence of seven EFS intervals is not viewed as 206 an availability period. 208 3.2. Calculate Error Performance Metrics 210 Determining the period in which the path is currently EP-wise is 211 helpful. But because switching between periods requires ten 212 consecutive one-second intervals, conditions that last shorter 213 intervals may not be adequately reflected. Two additional EP OAM 214 metrics can be used, and they are defined as follows: 216 * errored second ratio (ESR) is the ratio of ES to the total number 217 of seconds in a time of the availability periods during a fixed 218 measurement interval. 220 * severely errored second ratio (SESR) - is the ratio of SES to the 221 total number of seconds in a time of the availability periods 222 during a fixed measurement interval. 224 4. Requirements to EPM 226 TBA 228 5. Active OAM Protocol for EPM 230 Digital communication methods characterized as the constant-bit rate 231 digital paths and connections allow measurement of the error 232 performance without using an active OAM. That is possible because a 233 predictable flow of digital signals is expected at an egress system. 234 That is not the case for packet-switched networks that are based on 235 the principle of statistical multiplexing flows. The latter usually 236 improves the utilization of the communication network's resources, 237 but it also makes the flow unpredictable for the egress system. For 238 that reason, an active OAM has to be used in measuring the error 239 performance in a network. A combination of OAM protocols can provide 240 the necessary for EPM functionality. For example, Bidirectional 241 Forwarding Detection (BFD) [RFC5880] can be used to monitor the 242 continuity of a path between the ingress and egress systems. And 243 STAMP [RFC8762] can be used to measure and calculate performance 244 metrics that are used as Service Level Objectives. But using two 245 protocols and correlating the state of the network from them adds to 246 the complexity in network operation. 248 The Integrated OAM, described in [I-D.mmm-rtgwg-integrated-oam], 249 combines lightweight FM OAM with the comprehensive set of performance 250 measurement methods. PM component of the Integrated OAM is based on 251 [RFC6374] that supports, among other measurement methods, one-way and 252 two-way packet loss and packet delay measurements. 254 6. IANA Considerations 256 TBA 258 7. Security Considerations 260 TBA 262 8. Acknowledgments 264 TBA 266 9. References 268 9.1. Normative References 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, 272 DOI 10.17487/RFC2119, March 1997, 273 . 275 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 276 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 277 May 2017, . 279 9.2. Informative References 281 [I-D.mmm-rtgwg-integrated-oam] 282 Mirsky, G., Min, X., and G. Mishra, "Integrated Operation, 283 Administration, and Maintenance", Work in Progress, 284 Internet-Draft, draft-mmm-rtgwg-integrated-oam-00, 18 285 February 2021, . 288 [ITU.G.826] 289 ITU-T, "End-to-end error performance parameters and 290 objectives for international, constant bit-rate digital 291 paths and connections", ITU-T G.826, December 2002. 293 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 294 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 295 . 297 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 298 Measurement for MPLS Networks", RFC 6374, 299 DOI 10.17487/RFC6374, September 2011, 300 . 302 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 303 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 304 May 2016, . 306 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 307 Two-Way Active Measurement Protocol", RFC 8762, 308 DOI 10.17487/RFC8762, March 2020, 309 . 311 Authors' Addresses 313 Greg Mirsky 314 ZTE Corp. 316 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 318 Xiao Min 319 ZTE Corp. 321 Email: xiao.min2@zte.com.cn 322 Liuyan Han 323 China Mobile 324 32 XuanWuMenXi Street 325 Beijing 326 100053 327 China 329 Email: hanliuyan@chinamobile.com