idnits 2.17.1 draft-ietf-bier-pmmm-oam-05.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 (December 10, 2018) is 1964 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) -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: June 13, 2019 M. Chen 6 Huawei Technologies 7 G. Fioccola 8 Telecom Italia 9 December 10, 2018 11 Performance Measurement (PM) with Marking Method in Bit Index Explicit 12 Replication (BIER) Layer 13 draft-ietf-bier-pmmm-oam-05 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 June 13, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 3 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 [RFC8279] introduces and explains Bit Index Explicit Replication 73 (BIER) architecture and how it supports forwarding of multicast data 74 packets. [RFC8296] specified that in case of BIER encapsulation in 75 MPLS network a BIER-MPLS label, the label that is at the bottom of 76 the label stack, uniquely identifies the multicast flow. [RFC8321] 77 describes hybrid performance measurement method, per [RFC7799] 78 classification of measurement methods. Packet Network Performance 79 Monitoring (PNPM), which can be used to measure packet loss, latency, 80 and jitter on live traffic. Because this method is based on marking 81 consecutive batches of packets the method often referred to as 82 Marking Method (MM). 84 This document defines how marking method can be used on BIER layer to 85 measure packet loss and delay metrics of a multicast flow in MPLS 86 network. 88 2. Conventions used in this document 90 2.1. Terminology 92 BFR: Bit-Forwarding Router 94 BFER: Bit-Forwarding Egress Router 96 BFIR: Bit-Forwarding Ingress Router 97 BIER: Bit Index Explicit Replication 99 MM: Marking Method 101 OAM: Operations, Administration and Maintenance 103 2.2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. OAM Field in BIER Header 113 [RFC8296] defined the two-bit long field, referred to as OAM, 114 designated for the marking performance measurement method. The OAM 115 field MUST NOT be used in defining forwarding and/or quality of 116 service treatment of a BIER packet. The OAM field MUST be used only 117 for the performance measurement of data traffic in BIER layer. 118 Because the setting of the field to any value does not affect 119 forwarding and/or quality of service treatment of a packet, the 120 marking method in BIER layer can be viewed as the example of the 121 hybrid performance measurement method. 123 The Figure 1 displays format of the OAM field 125 0 126 0 1 127 +-+-+-+-+ 128 | L | D | 129 +-+-+-+-+ 131 Figure 1: OAM field of BIER Header format 133 where: 135 o L - Loss flag; 137 o D - Delay flag. 139 4. Theory of Operation 141 The marking method can be successfully used in the multicast 142 environment supported by BIER layer. Without limiting any generality 143 consider multicast network presented in Figure 2. Any combination of 144 markings, Loss and/or Delay, can be applied to a multicast flow by 145 any Bit Forwarding Router (BFR) at either ingress or egress point to 146 perform node, link, segment or end-to-end measurement to detect 147 performance degradation defect and localize it efficiently. 149 ----- 150 --| D | 151 ----- / ----- 152 --| B |-- 153 / ----- \ ----- 154 / --| E | 155 ----- / ----- 156 | A |--- ----- 157 ----- \ --| F | 158 \ ----- / ----- 159 --| C |-- 160 ----- \ ----- 161 --| G | 162 ----- 164 Figure 2: Multicast network 166 Using the marking method, a BFR creates distinct sub-flows in the 167 particular multicast traffic over BIER layer. Each sub-flow consists 168 of consecutive blocks, consisting of identically marked packets, that 169 are unambiguously recognizable by a monitoring point at any BFR and 170 can be measured to calculate packet loss and/or packet delay metrics. 171 It is expected that the marking values be set and cleared at the edge 172 of BIER domain. Thus for the scenario presented in Figure 2 if the 173 operator initially monitors A-C-G and A-B-D segments he may enable 174 measurements on segments C-F and B-E at any time. 176 4.1. Single Mark Enabled Measurement 178 As explained in the [RFC8321], marking can be applied to delineate 179 blocks of packets based either on the equal number of packets in a 180 block or based on equal time interval. The latter method offers 181 better control as it allows better account for capabilities of 182 downstream nodes to report statistics related to batches of packets 183 and, at the same time, time resolution that affects defect detection 184 interval. 186 If the Single Mark measurement used to measure packet loss, then the 187 D flag MUST be set to zero on transmit and ignored by monitoring 188 point. 190 The L flag is used to create alternate flows to measure the packet 191 loss by switching the value of the L flag every N-th packet or at 192 certain time intervals. Delay metrics MAY be calculated with the 193 alternate flow using any of the following methods: 195 o First/Last Packet Delay calculation: whenever the marking, i.e. 196 value of L flag changes, a BFR can store the timestamp of the 197 first/last packet of the block. The timestamp can be compared 198 with the timestamp of the packet that arrived in the same order 199 through a monitoring point at downstream BFR to compute packet 200 delay. Because timestamps collected based on order of arrival 201 this method is sensitive to packet loss and re-ordering of packets 203 o Average Packet Delay calculation: an average delay is calculated 204 by considering the average arrival time of the packets within a 205 single block. A BFR may collect timestamps for each packet 206 received within a single block. Average of the timestamp is the 207 sum of all the timestamps divided by the total number of packets 208 received. Then the difference between averages calculated at two 209 monitoring points is the average packet delay on that segment. 210 This method is robust to out of order packets and also to packet 211 loss (only a small error is introduced). This method only 212 provides a single metric for the duration of the block and it 213 doesn't give the minimum and maximum delay values. This 214 limitation could be overcome by reducing the duration of the block 215 by means of a highly optimized implementation of the method. 217 4.2. Double Mark Enabled Measurement 219 Double Mark method allows measurement of minimum and maximum delays 220 for the monitored flow but it requires more nodal and network 221 resources. If the Double Mark method used, then the L flag MUST be 222 used to create the alternate flow, i.e. mark larger batches of 223 packets. The D flag MUST be used to mark single packets to measure 224 delay jitter. 226 The first marking (L flag alternation) is needed for packet loss and 227 also for average delay measurement. The second marking (D flag is 228 put to one) creates a new set of marked packets that are fully 229 identified over the BIER network, so that a BFR can store the 230 timestamps of these packets; these timestamps can be compared with 231 the timestamps of the same packets on a second BFR to compute packet 232 delay values for each packet. The number of measurements can be 233 easily increased by changing the frequency of the second marking. 234 But the frequency of the second marking must be not too high in order 235 to avoid out of order issues. This method is useful to measure not 236 only the average delay but also the minimum and maximum delay values 237 and, in wider terms, to know more about the statistic distribution of 238 delay values. 240 5. IANA Considerations 242 This document requests IANA to register format of the OAM field of 243 BIER Header as the following: 245 +--------------+---------+--------------------------+---------------+ 246 | Bit Position | Marking | Description | Reference | 247 +--------------+---------+--------------------------+---------------+ 248 | 0 | S | Single Mark Measurement | This document | 249 | 1 | D | Double Mark Measurement | This document | 250 +--------------+---------+--------------------------+---------------+ 252 Table 1: OAM field of BIER Header 254 6. Security Considerations 256 This document list the OAM requirement for BIER-enabled domain and 257 does not raise any security concerns or issues in addition to ones 258 common to networking. 260 7. Acknowledgement 262 TBD 264 8. References 266 8.1. Normative References 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, 270 DOI 10.17487/RFC2119, March 1997, 271 . 273 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 274 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 275 May 2017, . 277 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 278 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 279 for Bit Index Explicit Replication (BIER) in MPLS and Non- 280 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 281 2018, . 283 8.2. Informative References 285 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 286 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 287 May 2016, . 289 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 290 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 291 Explicit Replication (BIER)", RFC 8279, 292 DOI 10.17487/RFC8279, November 2017, 293 . 295 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 296 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 297 "Alternate-Marking Method for Passive and Hybrid 298 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 299 January 2018, . 301 Authors' Addresses 303 Greg Mirsky 304 ZTE Corp. 306 Email: gregimirsky@gmail.com 308 Lianshu Zheng 309 Huawei Technologies 311 Email: vero.zheng@huawei.com 313 Mach Chen 314 Huawei Technologies 316 Email: mach.chen@huawei.com 318 Giuseppe Fioccola 319 Telecom Italia 321 Email: giuseppe.fioccola@telecomitalia.it