idnits 2.17.1 draft-ietf-bier-pmmm-oam-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 date (October 3, 2017) is 2394 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 (-12) exists of draft-ietf-bier-mpls-encapsulation-09 == Outdated reference: A later version (-14) exists of draft-ietf-ippm-alt-mark-12 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track L. Zheng 5 Expires: April 6, 2018 M. Chen 6 Huawei Technologies 7 G. Fioccola 8 Telecom Italia 9 October 3, 2017 11 Performance Measurement (PM) with Marking Method in Bit Index Explicit 12 Replication (BIER) Layer 13 draft-ietf-bier-pmmm-oam-03 15 Abstract 17 This document describes a hybrid performance measurement method for 18 multicast service over Bit Index Explicit Replication (BIER) domain. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 6, 2018. 37 Copyright Notice 39 Copyright (c) 2017 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 2 56 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 57 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 3. OAM Field in BIER Header . . . . . . . . . . . . . . . . . . 3 59 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Single Mark Enabled Measurement . . . . . . . . . . . . . 4 61 4.2. Double Mark Enabled Measurement . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 [I-D.ietf-bier-architecture] introduces and explains Bit Index 73 Explicit Replication (BIER) architecture and how it supports 74 forwarding of multicast data packets. 75 [I-D.ietf-bier-mpls-encapsulation] specified that in case of BIER 76 encapsulation in MPLS network a BIER-MPLS label, label that is at the 77 bottom of the label stack, uniquely identifies the multicast flow. 78 [I-D.ietf-ippm-alt-mark] describes hybrid performance measurement 79 method, per [RFC7799] classification of measurement methods. Packet 80 Network Performance Monitoring (PNPM), which can be used to measure 81 packet loss, latency and jitter on live traffic. Because this method 82 is based on marking consecutive batches of packets the method often 83 referred as Marking Method (MM). 85 This document defines how marking method can be used on BIER layer to 86 measure packet loss and delay metrics of a multicast flow in MPLS 87 network. 89 2. Conventions used in this document 91 2.1. Terminology 93 BFR: Bit-Forwarding Router 95 BFER: Bit-Forwarding Egress Router 96 BFIR: Bit-Forwarding Ingress Router 98 BIER: Bit Index Explicit Replication 100 MM: Marking Method 102 OAM: Operations, Administration and Maintenance 104 2.2. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 3. OAM Field in BIER Header 114 [I-D.ietf-bier-mpls-encapsulation] defined two bit long field, 115 referred as OAM, designated for the marking performance measurement 116 method. The OAM field MUST NOT be used in defining forwarding and/or 117 quality of service treatment of a BIER packet. The OAM field MUST be 118 used only for the performance measurement of data traffic in BIER 119 layer. Because setting of the field to any value does not affect 120 forwarding and/or quality of service treatment of a packet, the 121 marking method in BIER layer can be viewed as example of hybrid 122 performance measurement method. 124 The Figure 1 displays format of the OAM field 126 0 127 0 1 128 +-+-+-+-+ 129 | L | D | 130 +-+-+-+-+ 132 Figure 1: OAM field of BIER Header format 134 where: 136 o L - Loss flag; 138 o D - Delay flag. 140 4. Theory of Operation 142 The marking method can be successfully used in the multicast 143 environment supported by BIER layer. Without limiting any generality 144 consider multicast network presented in Figure 2. Any combination of 145 markings, Loss and/or Delay, can be applied to a multicast flow by 146 any Bit Forwarding Router (BFR) at either ingress or egress point to 147 perform node, link, segment or end-to-end measurement to detect 148 performance degradation defect and localize it efficiently. 150 ----- 151 --| D | 152 ----- / ----- 153 --| B |-- 154 / ----- \ ----- 155 / --| E | 156 ----- / ----- 157 | A |--- ----- 158 ----- \ --| F | 159 \ ----- / ----- 160 --| C |-- 161 ----- \ ----- 162 --| G | 163 ----- 165 Figure 2: Multicast network 167 Using the marking method a BFR creates distinct sub-flows in the 168 particular multicast traffic over BIER layer. Each sub-flow consists 169 of consecutive blocks that are unambiguously recognizable by a 170 monitoring point at any BFR and can be measured to calculate packet 171 loss and/or packet delay metrics. 173 4.1. Single Mark Enabled Measurement 175 As explained in the [I-D.ietf-ippm-alt-mark], marking can be applied 176 to delineate blocks of packets based either on equal number of 177 packets in a block or based on equal time interval. The latter 178 method offers better control as it allows better account for 179 capabilities of downstream nodes to report statistics related to 180 batches of packets and, at the same time, time resolution that 181 affects defect detection interval. 183 If the Single Mark measurement used to measure pcket loss, then the D 184 flag MUST be set to zero on transmit and ignored by monitoring point. 186 The L flag is used to create alternate flows to measure the packet 187 loss by switching value of the L flag every N-th packet or at certain 188 time intervals. Delay metrics MAY be calculated with the alternate 189 flow using any of the following methods: 191 o First/Last Packet Delay calculation: whenever the marking, i.e. 192 value of L flag, changes a BFR can store the timestamp of the 193 first/last packet of the block. The timestamp can be compared 194 with the timestamp of the packet that arrived in the same order 195 through a monitoring point at downstream BFR to compute packet 196 delay. Because timestamps collected based on order of arrival 197 this method is sensitive to packet loss and re-ordering of packets 199 o Average Packet Delay calculation: an average delay is calculated 200 by considering the average arrival time of the packets within a 201 single block. A BFR may collect timestamps for each packet 202 received within a single block. Average of the timestamp is the 203 sum of all the timestamps divided by the total number of packets 204 received. Then difference between averages calculated at two 205 monitoring points is the average packet delay on that segment. 206 This method is robust to out of order packets and also to packet 207 loss (only a small error is introduced). This method only 208 provides single metric for the duration of the block and it 209 doesn't give the minimum and maximum delay values. This 210 limitation could be overcome by reducing the duration of the block 211 by means of an highly optimized implementation of the method. 213 4.2. Double Mark Enabled Measurement 215 Double Mark method allows measurement of minimum and maximum delays 216 for the monitored flow but it requires more nodal and network 217 resources. If the Double Mark method used, then the L flag MUST be 218 used to create the alternate flow, i.e. mark larger batches of 219 packets. The D flag MUST be used to mark single packets to measure 220 delay jitter. 222 The first marking (L flag alternation) is needed for packet loss and 223 also for average delay measurement. The second marking (D flag is 224 put to one) creates a new set of marked packets that are fully 225 identified over the BIER network, so that a BFR can store the 226 timestamps of these packets; these timestamps can be compared with 227 the timestamps of the same packets on a second BFR to compute packet 228 delay values for each packet. The number of measurements can be 229 easily increased by changing the frequency of the second marking. 230 But the frequency of the second marking must be not too high in order 231 to avoid out of order issues. This method is useful to have not only 232 the average delay but also the minimum and maximum delay values and, 233 in wider terms, to know more about the statistic distribution of 234 delay values. 236 5. IANA Considerations 238 This document requests IANA to register format of the OAM field of 239 BIER Header as the following: 241 +--------------+---------+--------------------------+---------------+ 242 | Bit Position | Marking | Description | Reference | 243 +--------------+---------+--------------------------+---------------+ 244 | 0 | S | Single Mark Measurement | This document | 245 | 1 | D | Double Mark Measurement | This document | 246 +--------------+---------+--------------------------+---------------+ 248 Table 1: OAM field of BIER Header 250 6. Security Considerations 252 This document list the OAM requirement for BIER-enabled domain and 253 does not raise any security concerns or issues in addition to ones 254 common to networking. 256 7. Acknowledgement 258 TBD 260 8. References 262 8.1. Normative References 264 [I-D.ietf-bier-mpls-encapsulation] 265 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 266 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 267 Explicit Replication in MPLS and non-MPLS Networks", 268 draft-ietf-bier-mpls-encapsulation-09 (work in progress), 269 September 2017. 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 277 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 278 May 2017, . 280 8.2. Informative References 282 [I-D.ietf-bier-architecture] 283 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 284 S. Aldrin, "Multicast using Bit Index Explicit 285 Replication", draft-ietf-bier-architecture-08 (work in 286 progress), September 2017. 288 [I-D.ietf-ippm-alt-mark] 289 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 290 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 291 "Alternate Marking method for passive and hybrid 292 performance monitoring", draft-ietf-ippm-alt-mark-12 (work 293 in progress), October 2017. 295 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 296 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 297 May 2016, . 299 Authors' Addresses 301 Greg Mirsky 302 ZTE Corp. 304 Email: gregimirsky@gmail.com 306 Lianshu Zheng 307 Huawei Technologies 309 Email: vero.zheng@huawei.com 311 Mach Chen 312 Huawei Technologies 314 Email: mach.chen@huawei.com 316 Giuseppe Fioccola 317 Telecom Italia 319 Email: giuseppe.fioccola@telecomitalia.it