idnits 2.17.1 draft-mirsky-sfc-pmamm-07.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 (April 3, 2019) is 1849 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 (-05) exists of draft-mizrahi-ippm-compact-alternate-marking-03 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track G. Fioccola 5 Expires: October 5, 2019 Huawei Technologies 6 T. Mizrahi 7 Huawei Network.IO Innovation Lab 8 April 3, 2019 10 Performance Measurement (PM) with Alternate Marking Method in Service 11 Function Chaining (SFC) Domain 12 draft-mirsky-sfc-pmamm-07 14 Abstract 16 This document describes how the alternate marking method be used as 17 the passive performance measurement method in a Service Function 18 Chaining (SFC) 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 October 5, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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. Mark Field in NSH Base 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 4.3. Multiplexed Mark Enabled Measurement . . . . . . . . . . 5 63 4.4. Residence Time Measurement with the Alternate Marking 64 Method . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. Mark Field in NSH Base Header . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 [RFC7665] introduced architecture of a Service Function Chain (SFC) 77 in the network and defined its components as classifier, Service 78 Function Forwarder (SFF), and Service Function (SF). [RFC8321] 79 describes the passive performance measurement method, 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 to as Alternate Marking Method 83 (AMM). 85 This document defines how the alternate marking method can be used to 86 measure packet loss and delay metrics of a service flow over e2e or 87 any segment of the SFC. 89 2. Conventions used in this document 91 2.1. Terminology 93 MM: Marking Method 95 OAM: Operations, Administration and Maintenance 96 SFC: Service Function Chain 98 SF: Service Function 100 SFF: Service Function Forwarder 102 SFP: Service Function Path 104 NSH: Network Service Header 106 2.2. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Mark Field in NSH Base Header 116 [RFC8300] defines the format of the Network Service Header (NSH). 118 0 1 2 3 119 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |Ver|O|M| TTL | Length |R|R|R|R|MD Type| Proto | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 1: NSH Base format 126 This document defines the one-bit long field, referred to as Mark 127 field (M in Figure 1, as part of NSH Base and designated for the 128 alternate marking performance measurement method [RFC8321]. The Mark 129 field MUST NOT be used in defining forwarding and/or quality of 130 service treatment of an SFC packet. The Mark field MUST be used only 131 for the performance measurement of data traffic in the SFC layer. 132 Because the setting of the field to any value does not affect 133 forwarding and/or quality of service treatment of a packet, the 134 alternate marking method in SFC layer can be viewed as a real example 135 of passive performance measurement method. 137 4. Theory of Operation 139 The marking method can be successfully used in the SFC. Without 140 limiting any generality consider SFC presented in Figure 2. Any 141 combination of markings, Loss and/or Delay, can be applied to a 142 service flow by any component of the SFC at either ingress or egress 143 point to perform node, link, segment or end-to-end measurement to 144 detect performance degradation defect and localize it efficiently. 146 +---+ +---+ +---+ +---+ +---+ +---+ 147 |SF1| |SF2| |SF3| |SF4| |SF5| |SF6| 148 +---+ +---+ +---+ +---+ +---+ +---+ 149 \ / \ / \ / 150 +----------+ +----+ +----+ +----+ 151 |Classifier|---|SFF1|---------|SFF2|---------|SFF3| 152 +----------+ +----+ +----+ +----+ 154 Figure 2: SFC network 156 Using the marking method a component of the SFC creates distinct sub- 157 flows in the particular service traffic over SFC. Each sub-flow 158 consists of consecutive blocks that are unambiguously recognizable by 159 a monitoring point at any component of the SFC and can be measured to 160 calculate packet loss and/or packet delay metrics. 162 4.1. Single Mark Enabled Measurement 164 As explained in the [RFC8321], marking can be applied to delineate 165 blocks of packets based either on the equal number of packets in a 166 block or based on the same time interval. The latter method offers 167 better control as it allows better account for capabilities of 168 downstream nodes to report statistics related to batches of packets 169 and, at the same time, time resolution that affects defect detection 170 interval. 172 The Loss flag is used to create alternate flows to measure the packet 173 loss by switching the value of the Loss flag every N-th packet or at 174 specified time intervals. Delay metrics MAY be calculated with the 175 alternate flow using any of the following methods: 177 o First/Last Packet Delay calculation: whenever the marking, i.e., 178 the value of Loss flag, changes a component of the SFC can store 179 the timestamp of the first/last packet of the block. The 180 timestamp can be compared with the timestamp of the packet that 181 arrived in the same order through a monitoring point at a 182 downstream component of the SFC to compute packet delay. Because 183 timestamps collected based on order of arrival, this method is 184 sensitive to packet loss and re-ordering of packets 186 o Average Packet Delay calculation: an average delay is calculated 187 by considering the average arrival time of the packets within a 188 single block. A component of the SFC may collect timestamps for 189 each packet received within a single block. Average of the 190 timestamp is the sum of all the timestamps divided by the total 191 number of packets received. Then the difference between averages 192 calculated at two monitoring points is the average packet delay on 193 that segment. This method is robust to out of order packets and 194 also to packet loss (only a small error is introduced). This 195 method only provides a single metric for the duration of the 196 block, and it doesn't give the minimum and maximum delay values. 197 Highly optimized implementation of the method can reduce the 198 duration of the block and thus overcome the limitation. 200 4.2. Double Mark Enabled Measurement 202 Double Mark method allows measurement of minimum and maximum delays 203 for the monitored flow, but it requires more nodal and network 204 resources. If the Double Mark method used, then the Loss flag MUST 205 be used to create the alternate flow, i.e., mark larger batches of 206 packets. The Delay flag MUST be used to denote single packets to 207 measure delay jitter. 209 The first marking (Loss flag alternation) is needed for packet loss 210 and also for average delay measurement. The second marking (Delay 211 flag is put to one) creates a new set of marked packets that are 212 fully identified over the SFC, so that a component can store the 213 timestamps of these packets; these timestamps can be compared with 214 the timestamps of the same packets on another element of the SFC to 215 compute packet delay values for each packet. The number of 216 measurements can be easily increased by changing the frequency of the 217 second marking. But the rate of the second marking must be not too 218 high to avoid out of order issues. This method supports the 219 calculation of not only the average delay but also the minimum and 220 maximum delay values and, in broader terms, to know more about the 221 statistic distribution of delay values. 223 4.3. Multiplexed Mark Enabled Measurement 225 There is also a scheme that provides the benefits of Double Mark 226 method, but uses only one bit like Single Mark. This methodology is 227 described in [I-D.mizrahi-ippm-compact-alternate-marking]. The 228 concept is that in the middle of each block of packets with a certain 229 value of the L flag, a single packet has the L flag inverted. So, by 230 examining the stream, the packets with the inverted bit can be easily 231 identified and employed for delay measurement. This Alternate 232 Marking variation is advantageous because it requires only one bit 233 from each packet, and such bits are always in short supply. 235 4.4. Residence Time Measurement with the Alternate Marking Method 237 Residence time is the variable part of the propagation delay that a 238 packet experiences while traversing a network, e.g., SFC. Residence 239 Time over an SFC is the sum of the nodal residence times, i.e., 240 periods that the packet spent in each of SFFs that compose the SFC. 241 The nodal residence time in SFC itself is the sum of sub-nodal 242 residence times that the packet spent in each of SFs that are part of 243 the given SFC and are mapped to the SFF. The residence time and 244 deviation of the residence time metrics may include any combination 245 of minimum, maximum, values over measurement period, as well as mean, 246 median, percentile. These metrics may be used to evaluate the 247 performance of the SFC and its elements before and during its 248 operation. 250 Use of the specially marked packets simplifies residence time 251 measurement and correlation of the measured metrics over the SFC end- 252 to-end. For example, the alternate marking method may be used as 253 described in Section 4.2 to identify packets in the data flow to be 254 used to measure the residence time. The nodal and sub-nodal 255 residence time metrics can be locally calculated and then collected 256 using either in-band or out-band OAM mechanisms. 258 5. IANA Considerations 260 5.1. Mark Field in NSH Base Header 262 This document requests IANA to allocate the one-bit field from NSH 263 Base Header Bits [RFC8300] as the Mark field of NSH as the following: 265 +--------------+-------------+---------------+ 266 | Bit Position | Description | Reference | 267 +--------------+-------------+---------------+ 268 | TBA | Mark field | This document | 269 +--------------+-------------+---------------+ 271 Table 1: Mark field of SFC NSH 273 6. Security Considerations 275 This document lists the OAM requirement for SFC domain and does not 276 raise any security concerns or issues in addition to ones common to 277 networking and SFC. 279 7. Acknowledgment 281 TBD 283 8. References 285 8.1. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 293 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 294 May 2017, . 296 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 297 "Network Service Header (NSH)", RFC 8300, 298 DOI 10.17487/RFC8300, January 2018, 299 . 301 8.2. Informative References 303 [I-D.mizrahi-ippm-compact-alternate-marking] 304 Mizrahi, T., Arad, C., Fioccola, G., Cociglio, M., Chen, 305 M., Zheng, L., and G. Mirsky, "Compact Alternate Marking 306 Methods for Passive and Hybrid Performance Monitoring", 307 draft-mizrahi-ippm-compact-alternate-marking-03 (work in 308 progress), October 2018. 310 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 311 Chaining (SFC) Architecture", RFC 7665, 312 DOI 10.17487/RFC7665, October 2015, 313 . 315 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 316 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 317 "Alternate-Marking Method for Passive and Hybrid 318 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 319 January 2018, . 321 Authors' Addresses 323 Greg Mirsky 324 ZTE Corp. 326 Email: gregimirsky@gmail.com 327 Giuseppe Fioccola 328 Huawei Technologies 330 Email: giuseppe.fioccola@huawei.com 332 Tal Mizrahi 333 Huawei Network.IO Innovation Lab 334 Israel 336 Email: tal.mizrahi.phd@gmail.com