idnits 2.17.1 draft-mirsky-sfc-pmamm-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 (June 22, 2018) is 2132 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 SFC Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track G. Fioccola 5 Expires: December 24, 2018 Telecom Italia 6 T. Mizrahi 7 Marvell 8 June 22, 2018 10 Performance Measurement (PM) with Alternate Marking Method in Service 11 Function Chaining (SFC) Domain 12 draft-mirsky-sfc-pmamm-03 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 December 24, 2018. 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. Mark Field in NSH Base 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 4.3. Residence Time Measurement with the Alternate Marking 63 Method . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Mark Field in NSH Base Header . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 [RFC7665] introduced architecture of a Service Function Chain (SFC) 76 in the network and defined its components as classifier, Service 77 Function Forwarder (SFF), and Service Function (SF). [RFC8321] 78 describes passive performance measurement method, which can be used 79 to measure packet loss, latency and jitter on live traffic. Because 80 this method is based on marking consecutive batches of packets the 81 method often referred to as Alternate Marking Method (AMM). 83 This document defines how the alternate marking method can be used to 84 measure packet loss and delay metrics of a service flow over e2e or 85 any segment of the SFC. 87 2. Conventions used in this document 89 2.1. Terminology 91 MM: Marking Method 93 OAM: Operations, Administration and Maintenance 95 SFC: Service Function Chain 96 SF: Service Function 98 SFF: Service Function Forwarder 100 SFP: Service Function Path 102 NSH: Network Service Header 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. Mark Field in NSH Base Header 114 [RFC8300] defines the format of the Network Service Header (NSH). 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |Ver|O|R| TTL | Length | M |R|R|MD Type| Proto | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Figure 1: NSH Base format 124 This document defines the two-bit long field, referred to as Mark 125 field (M in Figure 1, as part of NSH Base and designated for the 126 alternate marking performance measurement method [RFC8321]. The Mark 127 field MUST NOT be used in defining forwarding and/or quality of 128 service treatment of an SFC packet. The Mark field MUST be used only 129 for the performance measurement of data traffic in SFC layer. 130 Because the setting of the field to any value does not affect 131 forwarding and/or quality of service treatment of a packet, the 132 alternate marking method in SFC layer can be viewed as a true example 133 of passive performance measurement method. 135 The Figure 2 displays format of the Mark field. 137 0 138 0 1 139 +-+-+-+-+ 140 | L | D | 141 +-+-+-+-+ 143 Figure 2: Mark field format 145 where: 147 o L- Loss flag; 149 o D - Delay flag. 151 4. Theory of Operation 153 The marking method can be successfully used in the SFC. Without 154 limiting any generality consider SFC presented in Figure 3. Any 155 combination of markings, Loss and/or Delay, can be applied to a 156 service flow by any component of the SFC at either ingress or egress 157 point to perform node, link, segment or end-to-end measurement to 158 detect performance degradation defect and localize it efficiently. 160 +---+ +---+ +---+ +---+ +---+ +---+ 161 |SF1| |SF2| |SF3| |SF4| |SF5| |SF6| 162 +---+ +---+ +---+ +---+ +---+ +---+ 163 \ / \ / \ / 164 +----------+ +----+ +----+ +----+ 165 |Classifier|---|SFF1|---------|SFF2|---------|SFF3| 166 +----------+ +----+ +----+ +----+ 168 Figure 3: SFC network 170 Using the marking method a component of the SFC creates distinct sub- 171 flows in the particular service traffic over SFC. Each sub-flow 172 consists of consecutive blocks that are unambiguously recognizable by 173 a monitoring point at any component of the SFC and can be measured to 174 calculate packet loss and/or packet delay metrics. 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, then the Delay flag Figure 2 187 MUST be set to zero on transmit and ignored on reception by 188 monitoring point. 190 The Loss flag is used to create alternate flows to measure the packet 191 loss by switching the value of the Loss 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 the value of Loss flag, changes a component of the SFC can store 197 the timestamp of the first/last packet of the block. The 198 timestamp can be compared with the timestamp of the packet that 199 arrived in the same order through a monitoring point at a 200 downstream component of the SFC to compute packet delay. Because 201 timestamps collected based on order of arrival this method is 202 sensitive to packet loss and re-ordering of packets 204 o Average Packet Delay calculation: an average delay is calculated 205 by considering the average arrival time of the packets within a 206 single block. A component of the SFC may collect timestamps for 207 each packet received within a single block. Average of the 208 timestamp is the sum of all the timestamps divided by the total 209 number of packets received. Then the difference between averages 210 calculated at two monitoring points is the average packet delay on 211 that segment. This method is robust to out of order packets and 212 also to packet loss (only a small error is introduced). This 213 method only provides a single metric for the duration of the block 214 and it doesn't give the minimum and maximum delay values. This 215 limitation could be overcome by reducing the duration of the block 216 by means of a highly optimized implementation of the method. 218 4.2. Double Mark Enabled Measurement 220 Double Mark method allows measurement of minimum and maximum delays 221 for the monitored flow but it requires more nodal and network 222 resources. If the Double Mark method used, then the Loss flag MUST 223 be used to create the alternate flow, i.e. mark larger batches of 224 packets. The Delay flag MUST be used to mark single packets to 225 measure delay jitter. 227 The first marking (Loss flag alternation) is needed for packet loss 228 and also for average delay measurement. The second marking (Delay 229 flag is put to one) creates a new set of marked packets that are 230 fully identified over the SFC, so that a component can store the 231 timestamps of these packets; these timestamps can be compared with 232 the timestamps of the same packets on another component of the SFC to 233 compute packet delay values for each packet. The number of 234 measurements can be easily increased by changing the frequency of the 235 second marking. But the frequency of the second marking must be not 236 too high in order to avoid out of order issues. This method supports 237 calculation of not only the average delay but also the minimum and 238 maximum delay values and, in wider terms, to know more about the 239 statistic distribution of delay values. 241 4.3. Residence Time Measurement with the Alternate Marking Method 243 Residence time is the variable part of the propagation delay that a 244 packet experiences traversing a network, e.g. SFC. Residence Time 245 over an SFC is the sum of the nodal residence times, i.e. periods 246 that the packet spent in each of SFFs that compose the SFC. The 247 nodal residence time in SFC itself is the sum of sub-nodal residence 248 times that the packet spent in each of SFs that are part of the given 249 SFC and are mapped to the SFF. The residence time and deviation of 250 the residence time metrics may include any combination of minimum, 251 maximum, values over measurement period, as well as mean, median, 252 percentile. These metrics may be used to evaluate the performance of 253 the SFC and its elements before and during its operation. 255 Use of the specially marked packets simplifies residence time 256 measurement and correlation of the measured metrics over the SFC end- 257 to-end. For example, the alternate marking method may be used as 258 described in Section 4.2 to identify packets in the data flow to be 259 used to measure the residence time. The nodal and sub-nodal 260 residence time metrics can be locally calculated and then collected 261 using either in-band or out-band OAM mechanisms. 263 5. IANA Considerations 265 5.1. Mark Field in NSH Base Header 267 This document requests IANA to allocate Mark field as two bits-long 268 field from NSH Base Header Reserved Bits [RFC8300]. 270 This document requests IANA to register values of the Mark field of 271 NSH as the following: 273 +--------------+---------+--------------------------+---------------+ 274 | Bit Position | Marking | Description | Reference | 275 +--------------+---------+--------------------------+---------------+ 276 | 0 | S | Single Mark Measurement | This document | 277 | 1 | D | Double Mark Measurement | This document | 278 +--------------+---------+--------------------------+---------------+ 280 Table 1: Mark field of SFC NSH 282 6. Security Considerations 284 This document lists the OAM requirement for SFC domain and does not 285 raise any security concerns or issues in addition to ones common to 286 networking and SFC. 288 7. Acknowledgment 290 TBD 292 8. References 294 8.1. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 302 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 303 May 2017, . 305 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 306 "Network Service Header (NSH)", RFC 8300, 307 DOI 10.17487/RFC8300, January 2018, 308 . 310 8.2. Informative References 312 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 313 Chaining (SFC) Architecture", RFC 7665, 314 DOI 10.17487/RFC7665, October 2015, 315 . 317 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 318 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 319 "Alternate-Marking Method for Passive and Hybrid 320 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 321 January 2018, . 323 Authors' Addresses 325 Greg Mirsky 326 ZTE Corp. 328 Email: gregimirsky@gmail.com 329 Giuseppe Fioccola 330 Telecom Italia 332 Email: giuseppe.fioccola@telecomitalia.it 334 Tal Mizrahi 335 Marvell 336 6 Hamada St. 337 Yokneam 338 Israel 340 Email: talmi@marvell.com