idnits 2.17.1 draft-ietf-bier-pmmm-oam-01.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 (January 23, 2017) is 2643 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 (-08) exists of draft-ietf-bier-architecture-05 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-06 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: July 27, 2017 M. Chen 6 Huawei Technologies 7 G. Fioccola 8 Telecom Italia 9 January 23, 2017 11 Performance Measurement (PM) with Marking Method in Bit Index Explicit 12 Replication (BIER) Layer 13 draft-ietf-bier-pmmm-oam-01 15 Abstract 17 This document describes a passive 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 http://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 July 27, 2017. 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 (http://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 . . . . . . . . . . . . . . . . . . . . . 5 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . 6 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.tempia-ippm-p3m] describes passive performance measurement 79 method , Packet Network Performance Monitoring (PNPM), which can be 80 used to measure packet loss, latency and jitter on live traffic. 81 Because this method is based on marking consecutive batches of 82 packets the method often referred as 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 108 [RFC2119]. 110 3. OAM Field in BIER Header 112 [I-D.ietf-bier-mpls-encapsulation] defined two bit long field, 113 referred as OAM, designated for the marking performance measurement 114 method. The OAM field MUST NOT be used in defining forwarding and/or 115 quality of service treatment of a BIER packet. The OAM field MUST be 116 used only for the performance measurement of data traffic in BIER 117 layer. Because setting of the field to any value does not affect 118 forwarding and/or quality of service treatment of a packet, the 119 marking method in BIER layer can be viewed as true example of passive 120 performance measurement method. 122 The Figure 1 displays format of the OAM field 124 0 125 0 1 126 +-+-+-+-+ 127 | S | D | 128 +-+-+-+-+ 130 Figure 1: OAM field of BIER Header format 132 where: 134 o S- Single mark method; 136 o D - Double mark method. 138 4. Theory of Operation 140 The marking method can be successfully used in the multicast 141 environment supported by BIER layer. Without limiting any generality 142 consider multicast network presented in Figure 2. Any combination of 143 markings, Loss and/or Delay, can be applied to a multicast flow by 144 any Bit Forwarding Router (BFR) at either ingress or egress point to 145 perform node, link, segment or end-to-end measurement to detect 146 performance degradation defect and localize it efficiently. 148 ----- 149 --| D | 150 ----- / ----- 151 --| B |-- 152 / ----- \ ----- 153 / --| E | 154 ----- / ----- 155 | A |--- ----- 156 ----- \ --| F | 157 \ ----- / ----- 158 --| C |-- 159 ----- \ ----- 160 --| G | 161 ----- 163 Figure 2: Multicast network 165 Using the marking method a BFR creates distinct sub-flows in the 166 particular multicast traffic over BIER layer. Each sub-flow consists 167 of consecutive blocks that are unambiguously recognizable by a 168 monitoring point at any BFR and can be measured to calculate packet 169 loss and/or packet delay metrics. 171 4.1. Single Mark Enabled Measurement 173 As explained in the [I-D.tempia-ippm-p3m], marking can be applied to 174 delineate blocks of packets based either on equal number of packets 175 in a block or based on equal time interval. The latter method offers 176 better control as it allows better account for capabilities of 177 downstream nodes to report statistics related to batches of packets 178 and, at the same time, time resolution that affects defect detection 179 interval. 181 If the Single Mark measurement used, then the D flag MUST be set to 182 zero on transmit and ignored by monitoring point. 184 The S flag is used to create alternate flows to measure the packet 185 loss by switching value of the S flag every N-th packet or at certain 186 time intervals. Delay metrics MAY be calculated with the alternate 187 flow using any of the following methods: 189 o First/Last Packet Delay calculation: whenever the marking, i.e. 190 value of S flag, changes a BFR can store the timestamp of the 191 first/last packet of the block. The timestamp can be compared 192 with the timestamp of the packet that arrived in the same order 193 through a monitoring point at downstream BFR to compute packet 194 delay. Because timestamps collected based on order of arrival 195 this method is sensitive to packet loss and re-ordering of packets 197 o Average Packet Delay calculation: an average delay is calculated 198 by considering the average arrival time of the packets within a 199 single block. A BFR may collect timestamps for each packet 200 received within a single block. Average of the timestamp is the 201 sum of all the timestamps divided by the total number of packets 202 received. Then difference between averages calculated at two 203 monitoring points is the average packet delay on that segment. 204 This method is robust to out of order packets and also to packet 205 loss (only a small error is introduced). This method only 206 provides single metric for the duration of the block and it 207 doesn't give the minimum and maximum delay values. This 208 limitation could be overcome by reducing the duration of the block 209 by means of an highly optimized implementation of the method. 211 4.2. Double Mark Enabled Measurement 213 Double Mark method allows measurement of minimum and maximum delays 214 for the monitored flow but it requires more nodal and network 215 resources. If the Double Mark method used, then the S flag MUST be 216 used to create the alternate flow, i.e. mark larger batches of 217 packets. The D flag MUST be used to mark single packets to measure 218 delay jitter. 220 The first marking (S flag alternation) is needed for packet loss and 221 also for average delay measurement. The second marking (D flag is 222 put to one) creates a new set of marked packets that are fully 223 identified over the BIER network, so that a BFR can store the 224 timestamps of these packets; these timestamps can be compared with 225 the timestamps of the same packets on a second BFR to compute packet 226 delay values for each packet. The number of measurements can be 227 easily increased by changing the frequency of the second marking. 228 But the frequency of the second marking must be not too high in order 229 to avoid out of order issues. This method is useful to have not only 230 the average delay but also the minimum and maximum delay values and, 231 in wider terms, to know more about the statistic distribution of 232 delay values. 234 5. IANA Considerations 236 This document requests IANA to register format of the OAM field of 237 BIER Header as the following: 239 +--------------+---------+--------------------------+---------------+ 240 | Bit Position | Marking | Description | Reference | 241 +--------------+---------+--------------------------+---------------+ 242 | 0 | S | Single Mark Measurement | This document | 243 | 1 | D | Double Mark Measurement | This document | 244 +--------------+---------+--------------------------+---------------+ 246 Table 1: OAM field of BIER Header 248 6. Security Considerations 250 This document list the OAM requirement for BIER-enabled domain and 251 does not raise any security concerns or issues in addition to ones 252 common to networking. 254 7. Acknowledgement 256 TBD 258 8. References 260 8.1. Normative References 262 [I-D.ietf-bier-architecture] 263 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 264 S. Aldrin, "Multicast using Bit Index Explicit 265 Replication", draft-ietf-bier-architecture-05 (work in 266 progress), October 2016. 268 [I-D.ietf-bier-mpls-encapsulation] 269 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 270 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 271 Explicit Replication in MPLS and non-MPLS Networks", 272 draft-ietf-bier-mpls-encapsulation-06 (work in progress), 273 December 2016. 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 8.2. Informative References 282 [I-D.tempia-ippm-p3m] 283 Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L., 284 and A. Bonda, "A packet based method for passive 285 performance monitoring", draft-tempia-ippm-p3m-03 (work in 286 progress), March 2016. 288 Authors' Addresses 290 Greg Mirsky 291 ZTE Corp. 293 Email: gregimirsky@gmail.com 295 Lianshu Zheng 296 Huawei Technologies 298 Email: vero.zheng@huawei.com 300 Mach Chen 301 Huawei Technologies 303 Email: mach.chen@huawei.com 305 Giuseppe Fioccola 306 Telecom Italia 308 Email: giuseppe.fioccola@telecomitalia.it